Design Decisions relating to representation of Descriptions

Additions, Changes and Deletions to Descriptions and Definitions

The following questions relate to the representation definitions and descriptions:

1. When an extension adds definition or description entries to a concept that is not owned by the the extension module, how should that information be represented in OWL?

   1. Should the concept include an rdfs:label (FSN)? (Proposed answer: Yes)

   2. Should the concept include any descriptions or definitions that are not part of the extension module? (Proposed answer: No)

2. When an extension changes a definition or description entry that is not owned by the extension model, how is that change represented?

   1. Add a row with a later effectiveTime, active=0, original moduleId + a new row w/ same row id, active?

      1. New row has same moduleId as original?

      2. New row has extension moduleId?

   2. Change existing row to active=0 then add a new row w/ same row id, active?  (same subchoices as above)

   3. Add a row with a later effectiveTime, active=0, extension moduleId + a new row w/ same row id, active, extension moduleId and changed text? (Proposed answer: Yes)
      Example:

      extension

3. Is it necessary to add a corresponding language refset entry whenever a definition or description is added or changed?

   1. Proposed answer: YES - definitions or descriptions that are not marked as preferred or acceptable for the extension moduleId in the language refset  will not be emitted in the OWL representation.
      
      
      

Description and Definition predicates

The current Spackman transformation generates the following predicates

http://snomed.info/field/term.en-us.preferred “txt”@en
http://snomed.info.field/term.en-us.synonym “txt”@en
http://snomed.info.field/TextDefinition.term “txt”@en

these predicates are not widely understood or recognized.  Furthermore, the specific language is embedded in the predicate itself meaning that there is no easy way to ask the question, "What are all of preferred names for concept C?".

Recommendation: Use SKOS (https://www.w3.org/TR/skos-reference/):

skos:prefName “txt”@en-us

skos:altName “txt”@en-us

skos:definition “txt”@en-us

Recommendation accepted in Wellington meeting – specification will be updated accordingly

Hi @Harold,
From your example, I gather your talking about representing these changes in RF2? I would say none of the options for 2 are correct.

2a - Extensions shouldn't be creating any entries on a module that isn't theirs. Definite No.
2b - This sounds like a violation of the RF2 append only history model. Absolute No.
2c - My only issue with this is that the inactivation seems unnecessary. It reads as though the extension retired the description (on 20170412) then reactivated it (on the 13th) an simultaneously changed the term.

I'd say just  create the new entry.

This would apply to any component - Extensions make whatever changes desired on their own module, while not violating the immutable rules for various fields.

(Note the specific example described above "Perinatal nose Hemorrhage" → "Perinatal bleeding inside nose" might be against some rule (I've seen conflicting documents, trying to find.. but it's fine as an example)

Also note, such edits is a contentious topic (see SNOMED International response to "Discussion paper - Allowance of Extensions to Modify Core Content"). Though all extensions are currently doing so...