The OWL axioms are in the scope for the OWL axiom refset if they are allowed in the SNOMED CT Logic Profile Specification. The following is a list of allowed OWL axioms .

• Class Axiom
  • SubclassOf
  • EquivalentClasses
  • DisjointClasses
• Object Property Axiom
• Data Property Axiom

The following axioms are in the scope of Logic Profile, however they are excluded from the OWL axiom refset:

...

The transformation from the OWL refset to OWL ontology should process 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 are excluded from the OWL refset to avoid duplication to the content that are represented by the RF 2 concept file.

• • 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 because the Concept file represents the same information. 138875005 |SNOMED CT Concept (SNOMED RT+CTV3)| is the only concept needs to be declared in the OWL axiom refset.
  • Property declarations should be included in the OWL axiom Refset to reduce the implementation burden for deriving such information at runtime.

Concept Defined by Axiom

The OWL Axiom Reference Set is designed to cover all logic definitions of SNOMED CT. A concept can be defined by one or more axioms in the same module or different modules. OWL Axioms are statements that indicate what is true in the domain. 

...

Each concept can only have one axiom during the period of transformation from the existing stated relationships file to the OWL axiom reference set. Therefore, there should be only one reference set member active axiom in the OWL axiom reference set for the union of relationships active all active relationships in conjunction for a concept at that snapshot across modules.

If a dependant 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,

...

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. 

...

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 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 609096000|Role group (attribute)| should still be represented by a circle rather than an object property. Figure 2.4.4-1 current

Current diagram representation for attribute in role group 0

For diagram of inferred relationships in the Necessary Normal Form, the circle should be used for self grouped attributes in the role group 0. Figure 2.4.4-2 diagram

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 modules under 900000000000445007|International Health Terminology Standards Development Organisation maintained module (core metadata concept)|.
However, SNOMED CT extensions can add new axioms for the concepts in the international release. A new axiom in the extension module can be represented by two approaches with different semantics.

...

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

Concept
ShowParts term t 116680003 |Is a|

 relationships must be a superset of transitive closure of the dependent modules in order to ensure the integrity of terminology. The exceptions should be discussed with the owner of the dependent module before making changes.

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 between attributes and concepts explained in the section 2.4.2. The NNF will still have the computed effectiveTime for each inferred relationship. The version of each 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. The same UUID should be used with a new effectiveTime. 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 new expression. This approach can simplify the tooling and authoring process and it is different approach to the history of changes to individual relationship.
However, an axiom must be inactivated in the following situations:

...