Axioms are statements or propositions which are regarded as being established, accepted, or self-evidently true in the domain. The OWL axioms are in the scope for the OWL axiom refset if they are allowed in the SNOMED CT Logic Profile Specification. Annotation axioms and Class declarations are generally excluded from the OWL axiom refset to avoid duplication to the RF2 files:
The transformation from the OWL expression refset to OWL ontology document should process the description file and language refset when descriptions are included. They should be represented by the following annotation properties for a given language refset.
However, property declarations should be included in the OWL refset to reduce the implementation burden for deriving such information at runtime. The property declarations include all attributes for SNOMED CT concept modeling. These attribute concepts must be excluded from the Class declarations.
The OWL Axiom Reference Set is designed to cover all logic definitions in SNOMED CT. A concept can be defined by one or more axioms in the same module or different modules. Each axiom is represented by a string in OWL Functional Syntax in the owlExpression field. Each concept is represented by a concept ID in the referencedComponentId in the refset. The following rules should be followed when assigning the referencedComponentId for an axiom:
The definition status of a concept is |Sufficiently defined by necessary conditions definition status| if the concept has at least one EquivalentClasses axiom, irrespective of whether other SubClassOf or EquivalentClasses axioms exist.
Representation of |is a| Relationships
116680003 |Is a (attribute)| relationships in SNOMED CT are represented by different axioms, SubClassOf, SubObjectProperty, SubDataPropery, or EquivalentClasses in the OWL axiom refset.
Class and property are all uniquely identified by an IRI in OWL 2 Ontology. It is not allowed to represent |Is a| relationships between SNOMED CT attributes and concepts in the OWL refset.
For inferred relationships in the Necessary Normal Form (NNF), SubClassOf, SubObjectProperty and SubDataProperty in the OWL axiom refset should be represented as
|Is a| relationships. The explanation for the Necessary Normal Form and the rules for calculating the NNF can be found in section 2.5. Generating Necessary Normal Form Relationships from the OWL Refsets.
The following additional two |Is a| relationships should always be included in the inferred relationship file because they cannot be derived from the OWL axiom refset.
Table 2.4-1: Additional inferred |Is a| relationships in the NNF file
SNOMED CT is based on concepts, with attributes also being represented as concepts. However, a property cannot be a subproperty of a class in OWL because class and property are disjoint.
Descendants of 410662002 |Concept model attribute (attribute)| should be represented as either ObjectProperties or DataProperties in the OWL axiom refset. The other SNOMED CT attributes including 410662002 |Concept model attribute| should be represented as Classes in the OWL axiom refset.
Role groups must be explicitly stated and represented by the concept 609096000 |Role group (attribute)| as an object property in the OWL axiom refset. In the diagram of stated relationships in the OWL axiom refset, the attribute 609096000 |Role group (attribute)| should still be represented by a circle rather than an object property. The role group should not be omitted for self-group attributes where there is only a single attribute in a role group.
An example for diagram representation of an OWL axiom
The editing of entries in the OWL refsets can only be performed by the owner of that module. The extensions must not modify the OWL refset entries from the dependent modules, such as |International Health Terminology Standards Development Organization maintained module|. No changes are permitted to the content of the International Edition, except for the addition of new versions of this content in a module owned by the extension producer.
SNOMED CT extensions can add new axioms to the concepts in the international release to support extension content, such as adding an extension concept as an additional parent to a concept in the international release. Each axiom in an extension must have a new UUID, moduleId and effectiveTime from the extension. An international concept may have multiple axioms - one or more axiom from the international edition and zero or more axiom from extension. An axiom addition in an extension can be presented by two alternative forms with the same classification result.
It is possible that substantive improvements or corrections to the International Edition can be made through axiom overriding in an extension, if they cannot be achieved by the Axiom addition approach.
This approach is different to the Axiom addition. The extension takes over the ownership of an axiom from the International Edition and overrides the axiom.
Whichever the approach is taken by extensions, either Axiom addition or Axiom overriding, it must follow the General Authoring Principles for extensions. Any modifications resulting in changes to the classification of international content must be accompanied by a disclaimer notifying users of the differences between the extension edition and the International Edition. These changes should be forwarded to SNOMED International in a timely fashion to improve the quality of the International Edition for all users. Please note that modifications of this kind pose a risk to the comparability and interoperability of data captured using different SNOMED CT editions.
The versioning is at the axiom level for a concept in the OWL axiom refset. This means that there is only one effectiveTime for each version of an axiom, which may have multiple relationships. The changes to any relationships in the current editing tool will trigger an "update" of the most recent version of the relevant axiom. Versioning at the axiom level (where each axiom may represent multiple relationships) is different to the versioning each individual relationship in the relationship file.
Any changes to the NNF should have a corresponding history of changes in the OWL axiom refset. This will ensure that all entries in the NNF can be derived from the OWL refset except for those relationships listed in the table 2.4-1. The NNF will still have the computed effectiveTime for each inferred relationship. The version of each inferred relationship can be derived from the OWL refset, but it is not true in reverse.
It is permitted to make modifications to a published axiom without inactivation by the owner of the module, by creating a new version of the axiom with the same UUID and a new effectiveTime. Since any modification to an axiom could potentially alter its meaning, it is not necessary to inactivate an axiom and create a new axiom. It is also not necessary to reinstate an inactivated axiom in the previous release when the same axiom is created as a new expression. This approach can simplify the tooling and authoring process and it is a different approach to the history of changes to individual relationship.
However, an axiom must be inactivated in the following situations:
Special notes on axioms during the transitional period from stated relationship file to the OWL refset
During the transitional period, there should be only one active axiom in the OWL axiom reference set for each concept. This axiom will represent the set of all active relationships (from the existing stated relationship file) for which the given concept is the source concept. This axiom overriding approach should only be used for the transition once. After the transition period, these axioms will be reviewed, and where appropriate will be split into multiple axioms as described in the Axiom addition approach.
If a dependent module (e.g. an extension module) adds defining relationships to a concept, then this will result in a new version of the axiom (which has the new relationship included) being added to the OWL axiom reference set. A new version of the axiom must be created if any of the concept's defining relationships change, regardless of whether or not that change is in the given module. For example (moduleId, sourceId, destinationId, typeId and referencedComponentId are represented by letters for easier readability):
Results in two versions of a single OWL reference set entry