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?

[cameronmore]

@swartik this is an interesting issue. My own personal take:

As an artifact with a history, the ontologies developed more in some areas than others. There are terms which we all think are too specific for a mid level ontology (looking at you cco:Flywheel), but they're there, and I personally hope that domain ontologies take over some specific terms for which they may be the better and more authoritative curator.

Regarding the perhaps functional relationship between functions and artifacts, I personally think that the way the terms are defined now allows the ontologies to follow the construction and experimentation of real world artifacts, not the other way around. Every infomercial seems to invent a new artifact which solves an old problem in some unique way. Now, the latest vegetable mincer can bear the same 'Food Slicing Artifact Function' as the other five mincers on the market, while being its own unique artifact (defined, perhaps, in terms of how it performs that function). Functions are realized through the manifestations, effects. Freezers, fridges, laboratory storage fridges, mini-coolers, ice-machinies, ice houses, air conditioners, etc., all share the same or highly similar functions, and I think the current taxonomy handles such variation well by not more directly linking them.

If functions had normative statements in them, references to specific artifacts, then I can imagine users getting discourages when asserting that a cooling function inheres in something that's not a cooling system.

On the other hand, you may say that the functions could be linked up to generic classes, rather than a specific cooling artifact, but just to the generic set of artifacts that cool. This is a good strategy, but I am concerned that it would still bake in too much rigidity into the models and subtract from some flexibility.

Of course, the saying goes 'bend, don't break,' and I can't say whether this flexibility is a universal benefit or if there are steps we can take to shore up the artifact hierarchy or the function hierarchy. I can't speculate much without seeing more domains and their choices re function and artifact.

[swartik]

@cameronmore I wish I could offer wisdom; I tend to think about artifact/function classes one at a time, on an as-needed basis.

I think we've taken this discussion as far as is useful in the issues. I'll close it.