GithubHelp home page GithubHelp logo

Comments (5)

cameronmore avatar cameronmore commented on September 22, 2024

It seems like there should be a roughly one-to-one correspondence of artifacts to their functions in the ontologies. If there are more of one than the other, or significant underlap, then this is worth investigating. Why include a function but not include (at least one) corresponding artifact? Same with artifacts--at least one vehicle-related function should exist, even if there are a number of vehicle subclasses with no more specific functions.

Reflecting the decision to under-axiomatize the ontology to allow users to craft their own data models with less restriction, the subclass restrictions seems to be an oversight and should be deleted to align with the other functions.

CCO offers lots of functions to express how an artifact is used, but it does not guide modelers in how to tie functions to artifacts. This is an important design decision with significant consequences for the content of a mid-level ontology. Was this design decision deliberate or organic?

I'm not sure what you mean here. CCO follows the BFO pattern, that material entities bear functions, and those are realized in processes, and they may be 'used-by' agents in those processes, and further the usage of these artifacts may produce certain cco:effects.

from commoncoreontologies.

gregfowlerphd avatar gregfowlerphd commented on September 22, 2024

@cameronmore: I don't want to speak for @swartik here, but I think what he means is:

  • Unlike his proposed definition of 'Life Support Artifact Function', the definitions for subclasses of Artifact Function don't mention subclasses of Material Artifact (and vice versa).
  • The subclasses of Artifact Function don't have associated axioms linking them to subclasses of Material Artifact (and vice versa).

from commoncoreontologies.

swartik avatar swartik commented on September 22, 2024

@cameronmore: What I'm really asking is why. Why those Artifact Function subclasses? Why such depth in some areas (Chemical Reaction Artifact Function) and not in others (Healing Artifact Function)? What motivated the persons who chose the subclasses and sometimes created deep hierarchies? What kind of mid-level ontology were they intending to create?

It's true, as @gregfowlerphd says, that I'd like to see Artifact Function subclasses linked to Material Artifact subclasses. I realize it's tricky to do this with axioms. Take Cooling Artifact Function. Given that you can cool water by putting it outside in a bucket on a winter day in Buffalo, I hesitate to recommend adding a subclass-of restriction like "Cooling Artifact Function inheres-in some Cooling System". And given that a refrigerator doesn't cool anything until the first time it's turned on, which may never happen, I hesitate to recommend adding subclass-of restriction "Cooling System bearer-of some Cooling Artifact Function".

These edge cases shouldn't drive the definition annotations. A Cooling System is intended to bear a Cooling Artifact Function. A Cooling Artifact Function usually inheres in a Cooling System. If the definition of Cooling Artifact Function was:

An Artifact Function, usually inhering in a Cooling System, that is realized in a process in which
the thermal energy of a system decreases.

then modelers would have additional guidance about how to use class Cooling Artifact Function. CCO becomes more self-contained.

Now let me tie all this together. Let's say, for the sake of argument, that you agree with me. Someone, perhaps I, could rewrite Artifact Function subclass definitions this way. Currently it couldn't always be done because of all the Artifact Function subclasses for which no Material Artifact subclass really corresponds. What then would be the proper direction? Add more subclasses of Material Artifact, or remove subclasses of Artifact Function?

from commoncoreontologies.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.