Between the first release of SNOMED CT in 2002 and 2018 both
Gloss |
---|
PreSpace | false |
---|
t | stated |
---|
GlosTerm | stated view |
---|
|
and
of
were distributed as
in the
Specref |
---|
PreSpace | false |
---|
RefType | file |
---|
t | stated relationship file |
---|
|
and the
.
Info |
---|
|
Glossary include |
---|
Gloss | defining relationship |
---|
Suffix | is |
---|
Def | inline |
---|
Example | true |
---|
Note | true |
---|
Prefix | A |
---|
|
|
As illustrated in
Caption reference |
---|
CapRefId | relationship-diagram |
---|
CapRefType | Figure |
---|
|
, each
Gloss |
---|
PreSpace | false |
---|
t | defining relationship |
---|
|
is represented by a row in the
Specref |
---|
RefType | file |
---|
t | relationship file |
---|
|
. The
being defined is referenced by the
, the
that represents the type of relationship (attribute) is referenced by the
and the
refers to the
that represents the value of that attribute.
The
Specref |
---|
RefType | file |
---|
t | relationship file |
---|
|
also has a
which allows two or more
Gloss |
---|
PreSpace | false |
---|
t | defining relationships |
---|
|
to be grouped together.
The
Specref |
---|
PreSpace | false |
---|
t | definitionStatusId |
---|
|
of the source concept, indicates whether the combination of
provide provides
of that concept.

Caption label |
---|
CapId | relationship-diagram |
---|
CapType | Figure |
---|
|
Diagrammatic representation of use of relationships to represent a concept definition |
Caption reference |
---|
CapRefId | relationship-table |
---|
CapRefType | Table |
---|
|
, shows the three rows in the
Specref |
---|
RefType | file |
---|
t | relationship file |
---|
|
that represent the definition of
Concept |
---|
t | 53442002 |Excision of stomach structure| |
---|
|
. As this is considered to be a
of
Concept |
---|
ShowParts | term |
---|
t | 53442002 |Excision of stomach structure| |
---|
|
the
Specref |
---|
PreSpace | false |
---|
t | definitionStatusId |
---|
|
of this concept is set to the value
Concept |
---|
t | 900000000000073002 |defined| |
---|
|
.
Caption label |
---|
CapId | relationship-table |
---|
CapType | Table |
---|
|
Example of stated view of |gastrectomy| represented by stated relationships |
Footnote Macro |
---|
Some columns omitted: id, effectiveTime, active, moduleId and modifierId. |
Footnote Macro |
---|
Id columns are shown with the term expanded for clarity. |
| sourceId | destinationId | relationship Group | typeId | characteristicTypesId |
Concept |
---|
t | 53442002 |Excision of stomach structure| |
---|
|
| | 0 | | Concept |
---|
t | 900000000000010007 |Stated relationship| |
---|
|
|
Concept |
---|
t | 53442002 |Excision of stomach structure| |
---|
|
| | 1 | Concept |
---|
t | 129304002 |Excision - action| |
---|
|
| Concept |
---|
t | 900000000000010007 |Stated relationship| |
---|
|
|
Concept |
---|
t | 53442002 |Excision of stomach structure| |
---|
|
| Concept |
---|
t | 405813007 |Procedure site - Direct| |
---|
|
| 1 | Concept |
---|
t | 69695003 |Stomach structure| |
---|
|
| Concept |
---|
t | 900000000000010007 |Stated relationship| |
---|
|
|
Limitations of Relationships for Representing Concept Definitions
Section 2.3.2 Necessary Conditions and Sufficient Definitions, illustrated the following three points, which are not supported by the current use of
to represent
:
- A concept may have more than one .
- Use of only supports representation of a single for each concept. If a concept is marked as sufficiently defined, all it relationships are considered to be part of its .
- A concept may have a that includes some assertions that are not
- Relationships are all assumed to be necessarily true.
- Some may not be part of a .
- Including these additional may cause some valid subtypes concepts (or expressions) to be omitted from the results of classification.
Section 2.3.3 Additional Logic Features, identifies other useful features that are supported by
tools but cannot be represented using only SNOMED CT.
Benefits of Relationships for Representing Concept Definitions
Relationships can be distributed in an easy to understand relational file structure. The
has been an established part of the standard set of SNOMED CT release files since the first release in 2002, with a revision in 2011-2012 to use
to enhance versioning capabilities. Relationships can be retrieved, displayed and processed using widely understood techniques such as
making it easy to join the relationships to the concepts to which they relate.
Future Use of Relationships for Representing Concept Definitions
Stated Relationships to be Deprecated
The
of
needs to be enhanced to allow more flexible and expressive use of description logic. The structure of the relationship file is not suitable for this and a decision has been made to adopt the
so that new DL features can be added over time. As a result, at the end of the current transition period (during 2019), update, the
Specref |
---|
t | stated relationship file |
---|
|
with be deprecated.
Information about the new representation for the
is included in section
2.3.4.2 Concept Definitions Represented in OWL.
Tip |
---|
|
This change only impacts people who use the current stated view. Proper use of the stated view requires access to and use of a Gloss |
---|
t | description logic classifier |
---|
| . Most DL classifiers require data to be provided in a OWL format, so these users typically transform from the Specref |
---|
t | stated relationship file |
---|
| to OWL prior to use. The new SNOMED CT OWL Toolkit makes it easy to prepare a full OWL file for classification from current and new distribution formats. Overall impact is expected to be low with significant benefits. |
Relationships Used for Inferred View Only
The current
Specref |
---|
RefType | file |
---|
t | relationship file |
---|
|
will continue to be released containing the inferred view. Due to limitations of the
Specref |
---|
RefType | file |
---|
t | relationship file |
---|
|
format, the inferred definitions will not contain the more sophisticated DL features. The
Specref |
---|
RefType | file |
---|
t | relationship file |
---|
|
:
- will only contain
- it will not distinguish between multiple
- it will whether each is part of any of the .
Nevertheless, the end result will still be a more complete and precise than the current content of this file. The reason for this is that the inferred relationships in the file will be be generated by processing the enhanced stated view. Details of the way the inferred relationship are generated from the stated view are document in 2.5. Generating Necessary Normal Form Relationships from the OWL Refsets.
Tip |
---|
|
The limitation of this format should not impact the vast majority of users of this file. The inferred relationship file will continue to support subsumption testing of precoordinated concepts. The inferred relationship file, however, will no longer support the testing of subsumption of postcoordinated expressions. Accurate tests for subsumption of postcoordinated expressions will be possible using a DL classifier with the stated OWL axioms. Optimizations such as the use of preclassified expression repositories can still be used to assist run time subsumption testing. Overall impact is expected to be low with significant benefits.
|