Artifact Function subclass justifications

[swartik]

Issue #251 made me wonder about the many descendants of class Artifact Function and the rationale for including all of them in CCO. I'm not saying they're unnecessary classes, just questioning whether they should be in a mid-level ontology. Consider:

• Only two descendants of Artifact Function, Payload Capacity and Sensor Modality Function, have inheres-in subclass restrictions.
• I haven't examined most of the class definition annotations closely, but the ones I've seen seldom explicitly mention the class of artifact used in the function.

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?

[cameronmore]

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.

[gregfowlerphd]

@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).

[swartik]

@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?