This page is used to further the discussion on the following issues:

• What is a relationship group, how is a group to be interpreted? What is it not?

• Detrimental effects of inconsistent relationship grouping

• Sources of inconsistency in relationship grouping

• New guidance for relationship 

What is a relationship group, how is a group to be interpreted? What is it not?

In the DL representation of SNOMED CT, a relationship group is a class just as any other concept. Just as SNOMED CT concepts have an associated meaning, so can relationship-group classes have an associated meaning. E.g. in the Drug model a relationship group corresponds to a drug constituent. Some of the attributes (e.g. Has active ingredient) is related to the drug constituent/relationship group while other attributes (e.g. Has manufactured dose form) is related to the drug product as a whole, i.e. should be ungrouped. Currently, these attributes are all relationship group 0, i.e. self-grouped.

(370409000 |Amoxicillin + clavulanate potassium 125mg/31mg chewable tablet (product)|) 
<<< 
(392251008 |Product containing amoxicillin and clavulanate potassium in oral dosage form (medicinal product form)| :
        127489000 |Has active ingredient| = 372687004 |Amoxicillin (substance)|, 
        127489000 |Has active ingredient| = 395938000 |Clavulanate potassium (substance)|, 
        411116001 |Has manufactured dose form| = 66076007 |Conventional release chewable tablet (dose form)|)

DL only allows binary relationships so it is not possible to "group" roles directly. There are approximations suggested, e.g. by the W3C (https://www.w3.org/TR/swbp-n-aryRelations/), most commonly reifying the n-ary relationships into classes just as done with relationship groups. However, this is an approximation and this reification has consequences which has been addressed e.g. by applying self-grouping to all attributes not explicitly grouped. This however requires full consistency in application of relationship groups.

Detrimental effects of inconsistent relationship grouping

Relationship group cross overs (false positive IsAs)

As seen e.g. here: https://dailybuild.ihtsdotools.org/qa/ (Patterns 4 and 5)

However, examining e.g. the concept 10491005 | Herpes zoster with meningitis (disorder) |, which is on the list of cross overs in the pattern analysis tool above, the issue isn't really a cross-over. The root cause(s) seem to be the definitions of 240468001 | Neurological varicella (disorder) | and 406586005 | Herpes virus infection of the central nervous system (disorder) | with two relationship groups leading to false positive IsAs.

Another issue is how to manage primitive parent cross-overs since stated IsAs are not grouped.

"Relationship group zero supersets" (false negative IsAs)

When there is a concept with grouped attributes and there is another concept with a self-grouped superset of those attributes, there will not be an inferred IsA between the two, and this might be an error (but not always).

Example: 240337004 | Verotoxigenic Escherichia coli food poisoning (disorder) | is not a kind of 92826001 | Colitoxemia (disorder) | because 92826001 | Colitoxemia (disorder) | has a stated parent 71057007 | Infection caused by Escherichia coli (disorder) | which has a group where as 240337004 | Verotoxigenic Escherichia coli food poisoning (disorder) | has (erroneously) only self-grouped attributes which are a superset of those of 71057007 | Infection caused by Escherichia coli (disorder) |.

Sources of inconsistency in relationship grouping

Uncontrolled relationship group inheritance.

New guidance for relationship grouping

• Always explicit relationship grouping (or relationship non-grouping)

• Always fully explicit use of attributes, "Zero-based modelling"

• Proximal primitive IsA assignment to avoid erroneous relationship inheritance

Meeting 2019-01-23

Attendees: @Yongsheng Gao, @Former user (Deleted), @stefan.schulz (Unlicensed), @Daniel Karlsson

A number of parallel work items needs to happen:

• Updating of the policy as well as tooling (authoring, viewing, and browsing) to better reflect that relationship grouping has semantic implications

• Identify the meaning of the relationship group in different contexts, e.g. a strength-specified ingredient in the Clinical Drug model or a condition in the Clinical Finding model. This needs further elaboration as assigning the distinct meaning to a relationship group can be challenging when e.g. overloaded generic attributes have to be used. While changing the relationship group meaning in RF2 might be a too invasive move at this time, specification of the distinct meaning in the OWL transformation might be allowed, if such distinct meanings can be found.

• Relationship grouping in relation to general nesting needs to be further clarified