All pages
Powered by GitBook
1 of 1

Loading...

Generating Necessary Normal Form Relationships from the OWL Refsets

The logic definitions are represented by the OWL axiom refset that is a replacement of the RF2 stated relationship file. As a result, the nature of the inferred relationship file in the distribution normal form (DNF) has changed, because the new DL features are not representable in the current relationships file. The inferred relationship file will maintain the same format and structure, but it is no longer equivalent to the stated form (containing all necessary and sufficient conditions). In fact, it is a collection of all the necessary conditions of precoordinated concepts and represents a subset of the full semantics.

Necessary Normal Form

The Necessary Normal Form (NNF) is a replacement for the Distribution Normal Form for inferred relationships. The NNF is a precalculated distribution form for practical purposes, for example, to support the continuity of existing implementations based on relational databases and queries by the expression constraint language.

The NNF consists of the full set of necessary relationships of precoordinated concepts after removal of redundant relationships within a given concept definition. Within the scope of a SNOMED CT terminology, necessary relationships are defined only for precoordinated concepts (aka OWL’s named classes). Let C be a precoordinated concept and D be either a precoordinated concept or a complex expression. If an axiom is in the form of SubClassOf(C D) or EquivalentClasses(C D), then all of the derivable and necessary relationships of D are necessary relationships of C.

The NNF does not include class disjointness, transitive properties, reflexive properties and sufficient conditions represented as General Concept Inclusions (GCIs) in the OWL axiom refset.

Inferred relationships for concrete values, e.g. decimal, integer, string, or dateTime, should be included in a separate relationship file.

Given two relationships, A and B, A with r = C and B with s = D, within the same role group, A is redundant if:

  • r is the same as or a supertype of s, and

  • C is the same as or a supertype of D

Note, “crossover relationships”, where r is a supertype of s, and C is instead a subtype of D do not result in a redundant relationship.

Stated relationships:

Inferred relationships before the removal of redundant relationships:

Inferred relationships after the reduction:

For , the relationship = is inherited from , which is a redundant relationship because is a subtype of . The relationship = is inherited from , which is a redundant relationship because is a subtype of .

Table 2.5-1: Example in OWL axiom refset and RF2 relationship file (NNF)

referencedComponentId
owlExpression
sourceId
destinationId
relationshipGroup
typeId

Stated relationships:

Inferred relationships before the removal of redundant relationship:

Inferred relationships after reduction:

For concept , the relationship = is inherited from , which is a redundant relationship to = because is a subtype of . Because is a subtype of and , the inherited relationships for are also redundant.

Table 2.5-2: Example in OWL axiom refset and RF2 relationship file (NNF)

referencedComponentId
owlExpression
sourceId
destinationId
relationshipGroup
typeId

Given attribute r, s and t with a property chain SubObjectPropertyOf(ObjectPropertyChain(t s) r), and two relationships A and B, A with r = C and B with u = D, within the same role group, A is redundant if:

  • Attribute u is the same as or a subtype of t, and

  • D has a relationship to C via attribute s

Note the following:

  • C does not need to subsume D

  • Attribute t does not need to be the same as or a subtype of r

  • Transitive properties are defined by a property chain in the form of

SubObjectPropertyOf(ObjectPropertyChain(r r) r) and thus it is a special case of the above.

Stated relationships of (the other model detail has been omitted):

Stated relationships of :

Inferred relationships before the removal of the redundant relationship:

Inferred relationships after the reduction:

For , the relationship = is inherited from . If rule 1 for class inclusion was applied, the relationships would not be considered redundant because is not a subconcept of . Since and property chain of " o " is a sub-property of , rule 2 actually compares the anonymous concepts for subsumption, i.e. = with = . Therefore, the inherited relationship is redundant and can be removed from the NNF. Their relationships and property chain can be demonstrated in the following diagram.

Table 2.5-3: Example in OWL axiom refset and RF2 relationship file (NNF)

referencedComponentId
owlExpression
sourceId
destinationId
relationshipGroup
typeId

This fairly complex process uses the stated form and the output of the reasoner to calculate the necessary normal form which is represented in the relationship RF2 file.

The most straightforward way to produce the necessary normal form would be to use the or the which is language agnostic.

  1. Read the Stated Form from RF2 files.

    1. The following files are required: Concept, OWL Ontology Reference Set, OWL Axiom Reference Set.

    2. If the edition has any active stated relationships then the Stated Relationship and MRCM Attribute Domain Reference Set files are also required.

Calculating the necessary normal form happens in two passes of the hierarchy.org.snomed.otf.owltoolkit.normalform

  1. Walk the class hierarchy in a top-down, breadth first, order.

    1. For each class visited gather the stated attributes of this class and each inferred parent.

    2. Compare the attributes and remove those which are found to be redundant because they are less specific in terms of depth in the hierarchy.

For fine level detail the best source of information is the Java class org.snomed.otf.owltoolkit.normalform.RelationshipNormalFormGenerator which performs the Necessary Normal Form calculation.

It is important to clearly indicate if an attribute is grouped or not because has impact to semantics and classification results. is represented by an integer in the field of relationshipGroup in the relationship file. In contrast, is represented by as an object property in the OWL axiom refset. After the stated relationship file is replaced by the OWL expression refset, role group numbers need to be generated for inferred relationships.

The following rules should be followed in the inferred relationship file to provide consistent representation aligned with the concept model diagram and the OWL axiom refset.

  1. All relationships should be assigned in role group 0;

  2. Attribute that is not grouped, not a value of or grouped=0 in MRCM, should be assigned in role group 0;

  3. Attribute that is grouped, value of or grouped=1 in MRCM, should be assigned a role group number that is not 0. Each in the OWL axiom should be presented by a unique role group number. Note, role group merging is not covered here.

is explicitly represented for self-grouped attributes where there is only a single attribute in a role group in an OWL axiom. However, these self-grouped attributes and values are not explicitly represented in the current relationship files. This representation has caused confusion if an attribute in role group 0 is grouped or not. The following example demonstrates the changes to assignment of role group number after the implementation of the complete OWL axiom refset.

An example for the current diagram representation for attribute in role group 0 in the stated relationship file and concept model diagram

sourceId
destinationId
relationshipGroup
typeId
referencedComponentId
owlExpression
sourceId
destinationId
relationshipGroup
typeId

284003005 72704001 272673000

0 1 1

116680003 116676008 363698007

12676007

EquivalentClasses(:12676007 ObjectIntersectionOf(:64572001 ObjectSomeValuesFrom(:609096000 ObjectIntersectionOf(ObjectSomeValuesFrom(:116676008 :72704001) ObjectSomeValuesFrom(:363698007 :62413002)))))

12676007 12676007 12676007 12676007

65966004 429353004 72704001 62413002

0 0 1 1

116680003 116680003 116676008 363698007

62413002

SubClassOf(:62413002 :299701004)

62413002

299701004

0

116680003

71388002 64033007

0 1

116680003 363704007

7246002

EquivalentClasses(:7246002 ObjectIntersectionOf(:71388002 ObjectSomeValuesFrom(:609096000 ObjectIntersectionOf(ObjectSomeValuesFrom(:260686004 :129314006) ObjectSomeValuesFrom(:405813007 :64033007)))))

7246002 7246002 7246002 7246002 7246002

118851004 362995002 430212007 129314006 64033007

0 0 0 1 1

116680003 116680003 116680003 260686004 405813007

405813007

SubObjectPropertyOf(:405813007 :363704007)

405813007

363704007

0

116680003

90704004 372687004

0 1

116680003 127489000

323739006

EquivalentClasses(:323739006 ObjectIntersectionOf(:763158003 ObjectSomeValuesFrom(:609096000 ObjectSomeValuesFrom(:762949000 :427483001))))

323739006 323739006

27658006 427483001

0 1

116680003 762949000

127489000

SubObjectPropertyOf(ObjectPropertyChain(:127489000 :738774007) :127489000))

N/A

N/A

N/A

N/A

427483001

SubClassOf(:427483001 ObjectIntersectionOf(:440327007 ObjectSomeValuesFrom(:738774007 :372687004)))

427483001 427483001 427483001

373298001 372687004 768681000

0 0 0

116680003 738774007 726542003

Use the OWL API to infer the class hierarchy
  1. Build the Ontology object using:

    1. Axioms from the OWL Axiom Reference Set, making a note of any Transitive property and Property Chain axioms.

    2. Axioms created by converting Stated Relationships to OWL Axioms using the MRCM Attribute Domain Reference Set for list of attributes which should not be grouped in the given domain.

  2. Use a reasoner to pre-compute the class hierarchy.

During this first pass build a hierarchy for property chains and transitive properties.
  • Walk the class hierarchy again in the same order reducing the attributes of each class further.

    1. Compare the attributes and remove those which are found to be redundant because they are less specific in terms of depth in one of the alternate hierarchies.

  • 0

    116680003

    90708001

    249578005

    0

    116680003

    90708001

    64033007

    1

    363698007

    125605004

    EquivalentClasses(:125605004 ObjectIntersectionOf(:64572001 ObjectSomeValuesFrom(:609096000 ObjectIntersectionOf(ObjectSomeValuesFrom(:116676008 :72704001) ObjectSomeValuesFrom(:363698007 :272673000)))))

    118851004

    EquivalentClasses(:118851004 ObjectIntersectionOf(:71388002 ObjectSomeValuesFrom(:609096000 ObjectSomeValuesFrom(:363704007 :64033007))))

    27658006

    EquivalentClasses(:27658006 ObjectIntersectionOf(:763158003 ObjectSomeValuesFrom(:609096000 ObjectSomeValuesFrom(:127489000 :372687004))))

    90708001

    64033007

    0

    363698007

    90708001

    EquivalentClasses(:90708001 ObjectIntersectionOf(:64572001 ObjectSomeValuesFrom(:609096000 ObjectSomeValuesFrom(:363698007 :64033007))))

    90708001

    734045002

    0

    116680003

    90708001

    Rules for Determining Redundant Relationships

    Rule 1 - Class and Role inclusions

    Example for Class inclusion

    Example for Role Inclusion

    Rule 2 - Property chains including transitive properties

    Example for property chain:

    Technical Implementation for Calculating the NNF

    High Level Process

    Classification

    Necessary Normal Form Calculation

    Assignment for Role Group Number

    | Fracture of radius|
    | Finding site|
    | Bone structure of radius and/or ulna|
    | Fracture of forearm|
    | Bone structure of radius|
    | Bone structure of radius and/or ulna|
    | Associated morphology|
    | Traumatic abnormality|
    | Injury of radius|
    | Fracture (morphologic abnormality)|
    | Traumatic abnormality|
    | Kidney biopsy|
    | Procedure site|
    | Kidney structure|
    | Procedure on kidney|
    | Procedure site - Direct|
    | Kidney structure|
    | Procedure site - Direct|
    | Procedure site|
    | Kidney structure|
    | Urinary system structure|
    | Retroperitoneal compartment structure|
    | Procedure site - Direct|
    | Product containing precisely amoxicillin (as amoxicillin sodium) 1 gram/1 vial powder for conventional release solution for injection (clinical drug)|
    | Amoxicillin sodium (substance)|
    | Product containing precisely amoxicillin (as amoxicillin sodium) 1 gram/1 vial powder for conventional release solution for injection (clinical drug)|
    | Has active ingredient|
    | Amoxicillin|
    | Product containing amoxicillin|
    | Amoxicillin sodium (substance)|
    | Amoxicillin (substance)|
    | Amoxicillin sodium|
    | Is modification of|
    | Amoxicillin|
    | Has active ingredient|
    | Is modification of|
    | Has active ingredient|
    | Has active ingredient|
    | Amoxicillin|
    | Has active ingredient|
    | Amoxicillin sodium|
    Snomed OWL Toolkit
    Classification Service REST API
    | Role group (attribute)|
    | Role group|
    | Role group|
    609096000 | Role group (attribute)|
    116680003 | Is a|
    | Role group (attribute)|
    | Role group (attribute)|
    | Role group (attribute)|
    609096000 | Role group (attribute)|
    Provide Feedback
    After the complete OWL axiom refset is implemented, [ | Role group|](http://snomed.info/id/609096000 "609096000 | Role group |") in the OWL axiom refset and concept model diagram should be represented as following.
    Representation of [ | Role group|](http://snomed.info/id/609096000 "609096000 | Role group |") in the NNF relationship file and concept model diagram

    125605004 125605004 125605004

    118851004 118851004

    27658006 27658006

    443820000