Page History
...
- Annotation Axiom - Descriptions can be represented as annotation assertions. They are excluded from the OWL axiom refset to avoid duplication to the RF2 description file.
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.
...
- Declarations for the built-in entities, e.g. owl:Thing, owl:Nothing, are excluded from the OWL refset refsets because they are implicitly presented in every OWL 2 ontology.
- Class and property declarations are excluded from the OWL axiom refset to avoid duplication to the content that are is represented by the RF2 concept file. Note, Class declaration and property declarations should be included in cases where an entity type cannot be derived from the existing axiom.
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.
...
Referenced component for an Axiom
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
Gloss | ||||
---|---|---|---|---|
|
- If an axiom is in the form of SubClassOf(C D) or EquivalentClasses(C D) where concept C is a precoordinated concept, the concept ID of C should be the referencedComponentId for this axiom.
- If an axiom is in the form of SubPropertyOf(r s) or EquivalentProperties(r s) where attribute r is a precoordinated concept, the concept ID of r should be the referencedComponentId for this axiom.
- If an axiom is in the form of SubClassOf(C D) where concept C is NOT a precoordinated concept and D is a precoordinated concept, this . This is a General Concept Inclusion (GCI) axiom. Because concept C is a sufficient but not necessary condition for concept D, the ID of concept D should be the referencedComponentId for this axiom. Note, if C is a precoordinated concept, this SubclassOf axiom is NOT a GCI axiom and the concept ID of D D should not be assigned as the referencedComponentId.
- If an axiom is in the form of SubObjectPropertyOf(u t) where attribute u is NOT a precoordinated concept and attribute t is a precoordinated concept. The concept ID of t should be the referencedComponentId for this axiom. e.g. SubObjectPropertyOf(ObjectPropertyChain(:r :s) :t)
- If an axiom is in the form of SubClassOf(C D) or EquivalentClasses(C D) where both C and D are NOT precoordinated concepts, this is a GCI axiom and the referencedComponentId should be 733929006 |General concept inclusion axiom (metadata)|.
- If an axiom is in the form of DisjointClasses(C D) where both C and D are precoordinated conceptsprecoordinated concepts, the concept ID of C should be the referencedComponentId for this axiom. Then the axiom DisjointClasses(D C) is redundant.
- The disjointness in more than two Classes can be represented as DisjointClasses(C D E …) where all classes are precoordinated concepts. The concept
should be the referencedComponentId for this axiom.Concept t 787776007 |Disjoint classes axiom (OWL metadata concept)|
The definition status of a concept is
Concept | ||||
---|---|---|---|---|
|
Representation of |is a| Relationships
relationships in SNOMED CT are represented by different axioms, SubClassOf, SubObjectPeropertySubObjectProperty, SubDataPropery, or EquivalentClasses in the OWL axiom refset. Concept ShowParts term t 116680003 |Is a (attribute)|
- SubClassOf represents the
relationship between concepts in SNOMED CT. SubObjectPropertyConcept ShowParts term t 116680003 |Is a (attribute)|
- SubObjectPropertyOf or SubDataProperty SubDataPropertyOf represents the
relationship between attributes in SNOMED CTCT for concept model object attributes and concept model data attributes respectively.Concept ShowParts term t 116680003 |Is a (attribute)|
- EquivalentClasses means that two concepts are subclass of each other in description logics , e.g. SubClassOf(C D) and SubClassOf(D C). EquivalentClasses are usually used to represent the equivalence between a precoorrdinated concept(a named class) and an expression such as ObjectIntersectionOf() that has one part of a precoordinated superconcept and the other part is an expression that usually refines the superconcept, e.g. ObjectSomeValuesFrom() or intersection of expressions.
Class and property are all uniquely identified by an IRI in OWL 2 Ontology. It is not allowed to represent
Concept | ||||
---|---|---|---|---|
|
shouldConcept t 410662002 |Concept model attribute|
should be represented as a class in the OWL axiom refset and SNOMED Ontology.
attribute (Concept t 762705008 |Concept model object
)attribute
and|
and its subconcepts should be represented as an object property in the OWL axiom refset and SNOMED Ontology. The
relationships among them should be represented as SubObjectProperty();Concept ShowParts term t 116680003 |Is a|
attribute (Concept t 762706009 |Concept model data
)attribute
and|
and its subconcepts should be represented as a data property in the OWL axiom refset and SNOMED Ontology. The relationship among them should be represented as SubDataProperty();
The metamodeling capacities of OWL 2 allow the punning for Classes and Properties. Both attribute concepts,
Concept | ||
---|---|---|
|
Concept | ||
---|---|---|
|
Concept | ||
---|---|---|
|
Concept | ||
---|---|---|
|
- SubClassOf(:762706009 :410662002)
- SubClassOf(:762705008 :410662002)
For inferred relationships in the Necessary Normal Form (NNF), SubClassOf, SubObjectProperty and SubDataProperty in the OWL axiom refset should be represented as
Concept | ||||
---|---|---|---|---|
|
The following additional two
Concept | ||||
---|---|---|---|---|
|
...
SourceId
...
TypeId
...
Concept | ||
---|---|---|
|
...
Concept | ||
---|---|---|
|
...
Concept | ||
---|---|---|
|
...
Concept | ||
---|---|---|
|
...
Concept | ||
---|---|---|
|
...
Concept | ||
---|---|---|
|
Attribute
...
Representation of concrete domains
DataHasValue class expression should be used for a
Concept | ||
---|---|---|
|
Concept | ||
---|---|---|
|
DataHasValue(:1142135004 "50"^^xsd:decimal)
Unfortunately, the xsd:boolean data type is out of the scope for the OWL 2 EL profile (https://www.w3.org/TR/owl2-profiles/#Entities). In order to have a consistent representation and clear semantics, the boolean values should be represented by the concept
Concept | ||
---|---|---|
|
Concept | ||
---|---|---|
|
Concept | ||
---|---|---|
|
Note, trailing zeros are optional for the decimal data type in SNOMED CT. If the fractional part is zero, the period and following zero(es) can be omitted. For example, 2 is equivalent to 2.0. In particular, trailing zeros are prohibited for medicinal products in SNOMED CT because of clinical safety concerns. This 'trailing zero' policy should be applied in the same subject area of SNOMED CT for consistent classifications because the ELK reasoner has an incomplete implementation of concrete domains. However, it is possible that other subject areas, e.g. clinical findings, could allow for trailing zeros if it is desirable.
Attributes
SNOMED CT is based on concepts, with attributes also being represented as concepts. However, attributes need to be represented as properties in the OWL axiom refset. The following rules should be followed.
- The attribute
should be represented as a Class in the OWL axiom refset.Concept t 410662002 |Concept model attribute| - The attribute
andConcept t 762705008 |Concept model object attribute (attribute)|
should be represented as Classes and Properties as noted above.Concept t 762706009 |Concept model data attribute (attribute)| - All descendants of
Concept t 762705008 |Concept model object
...
should be represented asattribute (attribute)|
...
- ObjectProperties
...
- .
- All descendants of
Concept t
...
should be represented as762706009 |Concept model data attribute (attribute)|
...
- DataProperties.
- All the rest attributes in SNOMED CT should be represented as Classes.
Role Group
Role group groups must be explicitly stated and represented by the attribute concept
Concept | ||
---|---|---|
|
For axiom refset. In the diagram of stated relationships in the OWL axiom refset, the attribute attribute
Concept | ||
---|---|---|
|
Current diagram representation for attribute in role group 0
For diagram of relationships in logical model, the circle should be used for 'self-grouped' attribute(s) in the role group 0.
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 axiomDiagram representation of logical model
Modules and Axioms
The editing of entries in the OWL refsets can only be performed by the owner of that module. In general, the The extensions must not modify the OWL refset entries from the dependent modules, such as
Concept | ||||
---|---|---|---|---|
|
|
- Axiom addition
SNOMED CT extensions can add new axioms for to the concepts in the international release by following the General Authoring Principles for extensions. A new axiom in the extension module can be represented by two approaches with different semantics.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.
- Axiom inclusion
Axiom overriding - - a new axiom with inclusion of the axiom from the international release as part of the extension axiom.
The - For example, an extension concept D can be added as a superconcept by adding a new axiom
has the same UUID from the international release with a new effectiveTime and module id in the extension. This approach should be avoided because it overrides the axiom from the dependent module.Multiple axioms - in the extension.
SubClassOf(A C) is an axiom released in the international release.
SubClassOf(A ObjectIntersectionOf(C D)) is a new axiom in the extension. - Axiom without inclusion - a new axiom without inclusion of the axiom from the international release as part of the extension axiom. For example,
SubClassOf(A C) is an axiom released in the international release.
SubClassOf(A D) is a new axiom in the extension.
- in the extension.
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.
- Axiom overriding - a . The new axiom has the same UUID from the international release, but a new UUID and effectiveTime in effectiveTime, module id and OWL expression from the extension. This approach provides multiple axioms for an concept in the extension module.
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 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 No matter which approach is taken, the transitive closure of the inferred
Concept | ||||
---|---|---|---|---|
|
Versioning for Axioms
The versioning is at the axiom level for a concept in the OWL axiom refset. It This means that there is only one effectiveTime for each version of an axiom that might , which may have multiple relationships. The changes to any relationships in the current editing tool will trigger an "update" of axiom with the latest effectiveTime. They are different to the versioning at individual relationship level in relationship filesthe most recent version of the relevant axiom. The versioning at the axiom level, where each axiom may represent multiple relationships, is different from the versioning of 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 allowed permitted to make direct modification modifications to a published axiom without inactivation by the owner of the module. The same UUID should be used with , 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 the individual relationship.
However, an axiom must be inactivated in the following situations:
- Concept The concept used as the referenced component is inactivated or changed.
- Axiom needs to be inactivated without any replacement.
- Any inactive concept or attribute referenced in an the axiom will not been be replaced by an active component.
Special notes on axioms during the transitional period from the stated relationship file to the OWL axiom refset
There During the transitional period, there should be only one active axiom in the OWL axiom reference set for all active relationships in conjunction for a concept at that snapshot across modules, during the period of transformation each concept. This axiom will represent the set of all active attributes (from the existing stated relationships relationship file to the OWL axiom reference set. Therefore, this is the ) for which the given concept is the source concept. This axiom overriding approach and should only be used for the transformation transition once. ThenAfter the transition period, these axioms should will be reviewed and many of them could be more suitable for multiple axioms. , 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 that a concept, then this will result in a new version of the axiom is (which has the new relationship included) being added to the OWL axiom reference set with the addition. This A new version of the axiom must be created if any of the relationships from the viewpoint of the moduleconcept's dependencies changesdefining relationships change, regardless of whether or not that change is on in the given module in question or not. For example (moduleId, sourceId, destinationId, typeId and referencedComponentId are represented by letters for easier readability):
id | effectiveTime | active | moduleId | sourceId | destinationId | typeId |
111111 | 20190731 | 1 | A | |||
ID | Module | Version | Role | Source | Target | |
111 | A | 1 | Ra | X | W | Ra |
222222222A | 20190731 | 1 | RbA | X | Y | Rb |
333333333B | 20191031 | 21 | RzB | X | Z | Rz |
Results in two versions of a single OWL reference set entry
UUID | Version | Module | Axiom | effectiveTime | active | moduleId | referencedComponentId | owlExpression | |
9c1951e8-bbaa-434b-b9d7-82b460e221de | 20190731 | 11 | A | X | EquivalentClasses(:X ObjectIntersectionOf( | ||||
9c1951e8-bbaa-434b-b9d7-82b460e221de | 20191031 | 1 | 2BB | X | EquivalentClasses(:X ObjectIntersectionOf( |
...