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:

• Annotation Axiom - Descriptions can be represented as annotation assertions. They are excluded from the OWL refset to avoid duplication to the RF2 description file.

The transformation from the OWL 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.

• • rdfs:label - if present, it is RF2 fully specified name
  • skos:prefLabel - if present, it is RF2 preferred term
  • skos:altLabel - if present, it is RF2 acceptable synonym
  • skos:definition - if present, it is RF2 definition
    
    
• Declaration

• • Declarations for the built-in entities, e.g. owl:Thing, owl:Nothing, are excluded from the OWL refset because they are implicitly presented in every OWL 2 ontology.
  • Class declarations are excluded from the OWL refset to avoid duplication to the content that are represented by the RF2 concept file. Note, Class declaration 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.

Concept Defined by 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
t OWL Functional Syntax GlosTerm OWL Functional Syntax

 in the owlExpression field. Each concept is represented by a concept ID in the referencedComponentId in the refset. The association between axiom and concept should follow the following rules:

• 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 SubClassOf(C D) where concept C is NOT a precoordinated concept and D is a precoordinated concept, this is a General Concept Inclusion (GCI) axiom. Because concept C is a sufficient but not necessary condition for concept D, the concept ID of D should be the referencedComponentId for this axiom.
• 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 concepts, the concept ID of C should be the referencedComponentId for this axiom.

The definition status of a concept is 

Concept
ShowParts term t 900000000000073002|Sufficiently defined concept definition status|

 if the concept has one EquivalentClasses axiom no matter other associated axioms are SubClassOf or EquivalentClasses.

Representation of |is a| Relationships

Concept
ShowParts term t 116680003 |Is a (attribute)|

 relationships in SNOMED CT are represented by different axioms, SubClassOf, SubObjectPeroperty, SubDataPropery, or EquivalentClasses in the OWL axiom refset. 

• SubClassOf represents the 

  Concept
  ShowParts term t 116680003 |Is a (attribute)|

   relationship between concepts in SNOMED CT. 

• SubObjectProperty or SubDataProperty represents the 

  Concept
  ShowParts term t 116680003 |Is a (attribute)|

   relationship between attributes in SNOMED CT.

• 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
ShowParts term t 116680003 |Is a|

 relationships between SNOMED CT attributes and concepts in the OWL refset.

• 410662002 |Concept model attribute| should be represented as a class in the OWL refset and Ontology.
• 762705008|Concept model object attribute (attribute)| and its subconcepts should be represented as object property in the OWL refset and Ontology. The 

  Concept
  ShowParts term t 116680003 |Is a|

   relationships among them should be represented as SubObjectProperty();
• 762706009|Concept model data attribute (attribute)| and its subconcepts should be represented as data property in the OWL refset and Ontology. The relationship among them should be represented as SubDataProperty();

For inferred relationships in the Necessary Normal Form (NNF), SubClassOf, SubObjectProperty and SubDataProperty in the OWL refset should be represented as

Concept
ShowParts term t 116680003 |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 

Concept
ShowParts term t 116680003 |Is a|

 relationships should always be included in the inferred relationship file because they cannot be derived from the OWL axiom refset.

Attribute

SNOMED CT is based on concept and attribute is also concept. However, a property cannot be a subproperty of a class in OWL because class and property are disjoint.
Descendants of 

Concept
t 410662002|Concept model attribute (attribute)|

should be represented as either ObjectProperties or DataProperties in the OWL axiom refset. The rest SNOMED CT attributes including 

Concept
t 410662002|Concept model attribute (attribute)|

 should be represented as Classes in the OWL axiom refset.

Role Group

Role group must be explicitly stated and represented by the attribute 

Concept
t 609096000|Role group (attribute)|

 in the OWL refset. Furthermore, role group should allow having only one attribute and value as "self-grouped". These are key differences to the numeric number representation of role group in the RF2 relationship file.
For diagram of stated relationships in the OWL axiom refset, the attribute

Concept
t 609096000|Role group (attribute)|

 should still be represented by a circle rather than an object property.

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.

Diagram 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 extensions must not modify the OWL refset entries from the dependent modules, such as 900000000000445007|International Health Terminology Standards Development Organization maintained module (core metadata concept)|.
SNOMED CT extensions can add new axioms for 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.

• Axiom overriding - a new axiom with inclusion of the axiom from the international release as part of the axiom. The 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 - a new axiom without inclusion of the axiom from the international release as part of the axiom. The new axiom has a new UUID and effectiveTime in the extension. This approach provides multiple axioms for an concept in the extension module.

No matter which approach is taken, the transitive closure of the inferred

Concept
ShowParts term t 116680003 |Is a|

 relationships should be a superset of transitive closure of the dependent modules in order to ensure the comparability and interoperability of data captured using different SNOMED CT editions. 

Versioning for Axioms

The versioning is at the axiom level for a concept in the OWL refset. It means that there is only one effectiveTime for an axiom that might 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 files.

Any changes to the NNF should have a history of changes in the OWL refset. This will ensure that all entries in the NNF can be derived from the OWL refset except relationships 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 to make direct modification to a published axiom without inactivation by the owner of the module. The same UUID should be used with 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:

1. Concept as referenced component is inactivated.
2. Axiom needs to be inactivated without any replacement.
3. Any inactive concept or attribute in an axiom will not been replaced by active component.

Special notes on axioms during the transitional period from stated relationship file to the OWL refset

There should be only one active axiom in the reference set for all active relationships in conjunction for a concept at that snapshot across modules, during the period of transformation from the existing stated relationships file to the OWL axiom reference set. Therefore, this is the axiom overriding approach and should only be used for the transformation once. Then, these axioms should be reviewed and many of them could be more suitable for multiple axioms.   

If a dependent module (e.g. an extension) adds relationships to that concept, this will result in a new version of the axiom is added to the OWL reference set with the addition. This new version must be created if any of the relationships from the viewpoint of the module's dependencies changes, regardless of whether that change is on the module in question or not. For example,

Results in two versions of a single OWL reference set entry