Also necessary conditions not included in the core set of sufficiently defining conditions
In preparation for the forthcoming call of the MAG later this week, I (Guillermo) am attaching four small OWL files demonstrating a potential alternative for dealing with the topic of this page.
File: role_demo.owl shows that using Protege and standard OWL I can define a concept as being equivalent to an expression and also as being subclass of another.
Since the upper level content of the product hierarchy is to be fully defined, the high level therapeutic groupers need to be fully defined also. In this example, "product containing atenolol in oral dose form" becomes a subtype of "product containing atenolol" after classification, even if it has a subclass axiom in addition to its equivalentTo axiom. This way of modeling in OWL would not be possible to transport directly to RF2 since the concept only has one set of defining conditions and definition status.
File: role_demo_flat.owl shows what happens when instead both axioms in the previos examples are flattened into a single axiom, joining the sufficiently defining conditions with also necessary conditions. This is a step the PERL owl script does. As a consequence, this antipattern contaminates SNOMED CT meanings, while avoiding it makes SNOMED CT less usable for some use cases that require clinically relevant groupers based on also necessary conditions (aggregation, decision support, etc.)
After amalgamating both axioms into a single one, "product containing atenolol in oral dose form" is no longer an inferred subtype of "product containing atenolol". This is a significant problem that is more visible now because we are trying to have near 100% fully defined concepts in products. If instead of the axiom we just add a stated ISA to the grouper we would maintain the current hierarchy entanglement.
Files role_demo_core and role_demo_extension.owl are to be used together. The first represents the core, the second an extension/module that imports the core, adds a subclass axiom with the also necessary condition without affecting the fully defined core concept used as an example: "product containing atenolol in oral dose form" becomes a subtype of "product containing atenolol" after classification, even if it has a subclass axiom in the extension in addition to its equivalentTo axiom in the core. This way of modeling in OWL (an extension importing the core owl file) is expected to become the standard some day. The equivalent in RF2 would be a module depending on the core, but without joining the axioms originating in the core and the extension as the PERL script currently does. Restrictions asserted in a module should be represented on their own axiom when transformed to OWL. This keeps the core more reusable, and enable different use cases to realize their needs without preventing others to do so.
Obviously appropriate guidance would be needed. However, so far, at least at the NRC level, terminology maintenance organizations use a very small set of software packages (represented in the MAG) or don't classify, and the cost/benefit equation might be reasonable.
Finally, the concrete use case that we are trying to establish a direction for has the following alternatives:
a) Keep the high level product groupers in the core, as intermediate primitive concepts and accept that the hierarchy cannot be fully defined.
b) Fully define the product groupers as having an active ingredient substance grouper. This would further contaminate substances with therapeutic groupers, which are intended to be removed during that hiearchy redesign.
c) Inactivate the product groupers that could not be fully defined. This might impair usability (e.g. retrieving all descendants of antibiotic, or contrast media, etc.)
d) have a way to represent also necessary conditions outside the default condition set, particularly for sufficiently defined concepts.
d1) using characteristicType (this option has many side effects and still requires changing the way RF2 is converted into OWL, modifying tooling. As an advantage, it could be modeled in the core. On the other hand, extensions could just contain also necessary conditions for a specific use case, in the same way as the example OWL files. So it ends up being an hybrid. It would still work.
d2) use extensions to add also necessary conditions to core concepts, for use cases that are not contemplated at the core level, without affecting core meanings and interoperability.
