Page tree

What is Description Logic?

Description Logics (DLs) exist to enable a reduction in content maintenance costs with a concurrent increase in content quality. Processing power and reasoning algorithms have improved such that a more expressive DL is now practical to use in SNOMED CT. 

The principle benefit of more DL features is the ability to represent content in a more fully systematised and thus more machine processable way, to enable the following benefits:

  • increased efficiency, consistency, precision and quality of authoring through reduced manual effort to organise content

  • lower costs to author and maintain content through reduced manual effort

  • a more complete and consistent product that is, as a consequence, more usable (for implementers and end users) and attractive (to drive adoption and implementation)

  • reduction in the cost of assessing the impact of modelling change, because changes also become systematically describable (and transformable).

  • simplification of content modelling by removing workarounds

  • close interoperability with an international standard, OWL, allowing easier application of other standards and tools

  • explicitly specified logic profile for Description Logic features used in SNOMED CT

Transitive and Reflexive Properties

Attribute concepts now have the ability to declare DL property characteristics as Transitive or Reflexive.

Property characteristics are currently maintained via the Terminology Server Application Programming Interface (TS API). Changes can be made via service requests to the technical team.

Example concept JSON data structure showing a Transitive property characteristic
"effectiveTime": "20110131",
"moduleId": "900000000000012004",
"active": true,
"released": true,
"conceptId": "123005000",
"fsn": "Part of (attribute)",
"definitionStatus": "PRIMITIVE",
"preferredSynonym": "Is a",

"propertyCharacteristics": ["Transitive"],

"descriptions": [],
"relationships": [],
"isLeafStated": true,
"isLeafInferred": true

When saved via the TS API, the changes are written into the Owl Axiom Reference Set as shown in the following examples:






Property Chains

OWL DL Property Chains can now be used within the authoring platform to infer additional concept properties during classification.

These inferred attributes appear in classification results along with all other inferred relationships.

Property chains are currently maintained via the TS API. Changes can be made via service requests to the technical team.


This feature allows |Has active ingredient| to be linked with |Is modification of| such that a medicinal product that has an active ingredient which is the modification of another substance, could classify as a child of a product containing the less modified substance.

This behaviour is critical to controlling the effect of changes to the  |Substance (substance)| hierarchy on other hierarchies.


Axioms are a relatively new part of SNOMED CT concepts. Each Axiom is like another mini concept definition including definition status and a set of stated relationships. These are presented and maintained through the concept edit panel in the same way as the earlier version stated relationships, visually located below the existing stated relationships of the concept. Axioms have a named concept on the left and an expression on the right.

The relationships within each additional axiom follow MRCM rules just like the stated relationships. At least one is-a relationship is required in an Axiom. The concept editor panel supports creation, editing and removing of axiom relationships. There is no released or active state on axiom relationships - they can always be modified or deleted.

Each Axiom of a concept is necessarily true. The attributes from all Axioms are in the inferred form and are inherited by children through inference. The normal form process may reduce these attributes if a more specific attribute or group of attribute is present, in the same way that is does for attributes from the stated relationships. Attributes in an Axiom are inferred on the named concept and its descendants.


Concept A has Axiom A1 (stated relationships) and A2.
Concept B has Axiom B1 (stated relationships).
Concept A subsumes Concept B - Concept B gets the inferred attributes of Axiom A1 AND A2.

General Concept Inclusion Axioms

Non-attribute concepts have the ability to declare general class Axioms in addition to the stated relationships.

General Concept Inclusions (GCIs) with Axioms provide authors with greater flexibility in how concepts are defined, and provide classifiers with a greater ability to make appropriate inferences. 

For example, these features can be used to state that a subset of attributes is sufficient to define a concept, and therefore that this sufficient set can be used to classify other concepts as descendants in the hierarchy.

Each GCI is recorded as a separate Axiom expression within a separate member of the Owl Axiom Reference Set. A GCI has a definition status which is represented using a SubClassOf or EquivalentClasses axiom expression.

  • No labels