Transformation Issues

Note:  Please add your contributions to this page labeled with your initials.

subClass Intersections

rdfs:subClassOf is represented as a single intersection in Spackman Transform, but the proposed specification uses implicit intersection.  

ML: Should this be owl:subClassOf? As I understood things, RDFS has difference semantics to the DL semantics of OWL

HS: To be honest, I've never heard of owl:subClassOf – can you point me at a reference?   (Note also that this transformation is currently to OWL 1.1)

ML: Ah, you are correct.  Syntactically it is still rdfs:subClassOf and the (OWL 1.1) spec claims the semantics are the same even though RDFS semantics (in general) are not OWL (OWL2-EL) semantics.

Conclusion: Use implicit intersection in the specification.

Relationship of Module identifier and owl ontology

Should every SNOMED module be represented as a separate ontology?  

RC: Yes! OWL facilitates ontology inclusion, we should use that. Maybe stronger: Each OWL ontology should not contain more than one SNOMED module, modules on which it depends must be included (using xmlns?). 

HS: The Spackman transform adds all descendants of Concept model attribute as owl:ObjectProperties to any module it processes.  If we want to change that to owl:imports we will probably want an attribute ontology that is separate from the rest of the SNOMED metadata.

ML: Modules do not contain complete fragments of an ontology.

It is possible for some of the defining relationships of a Concept to live in one module and some in another.

I would suggest an alternative question (but still not without technical complexities) as "Should every SNOMED Edition be represented as a separate ontology.

HS: It would seem that this should be the case, but (I suspect) you are asking whether the OWL imports mechansim should be used or whether every Edition is presented as a stand-alone module.  The risk of this is that one doesn't know what definitions came from core and which from the extensions.

Conclusion:  Yes, each SNOMED Edition should be represented as a separate ontology and included as required.

HS: Follow on question - does this fall within the scope of the Spackman OWL formalization project or should it be forwarded to the OWL representation working group?  My take is that we should probably document what needs to happen but declare it outside the scope of the existing work.  See: Modules and Ontologies as well

Non-defining Relationships 

How should non-defining relationships be represented?

RC: using annotation. Needs to be worked out, though. Do we mean part-of ?

HS: the characteristicTypeId in the relationship file can be one of "stated", "inferred, "qualifying" or "additional".  "Stated" and "Inferred" are classified as "Defining", so I assume that "qualifying" and "additional" are not.  In the international release, the Stated Relationships file has only one type - "stated".  The Relationships file, however, has two: "Inferred" and "Additional" – the "Additional" being attached to "part-of" relationships. 

So, we sort-of mean part-of, to the extent that part-of only appears in relationships that have an "additional" characteristicTypeId.  There is nothing in the model itself, however, that prevents part-of appearing in a "stated" relationship or, for that matter, finding-site from appearing as an "additional" relationship.  Unless there are formal rules that guarantee that neither of these cases can happen, we need to address them in this transformation.

HS: as an aside, how, exactly do new facts appear in the relationships file without ever being "stated"?  If we decide that we can only transform the stated relationships file and non-defining relationships can never be stated (???) then this issue may be moot.

ML: Non-defining relationships sit outside of the DL. At most they could be included as annotations. I think the answer here comes back to the question of scope - why are we producing an OWL representation, and therefore how much of what is in RF2 is useful to include in the OWL.

Re stated etc types, I think the problem is that these are not well named.  Stated really should be Stated - defining as both qualifying and additional are clearly qualifying - non-defining, and additional - non-defining, while inferred is inferred - defining.

HS: I have to keep reminding myself that our initial scope is pretty narrow – formalizing what is in the Spackman code and filling in some of the gaps.  The Spackman code is mute when it comes to non-defining relationships, which is why I asked the question.  It was built for the SNOMED International Core module and does not apply to the metadata module.  Mostly I'm wondering what the transform should produce if it were pointed at the metadata module...

PWI: A question was asked at the last meeting as to why Additional Relationships appear in the Inferred Table.  I believe this was done so as to avoid having them be presented to the classifier since we always pass in the stated relationships.  We are currently looking at returning Part Of relationships to being defining and this has a number of implications both for the formation of the OWL that is passed to the classifier, and for the formation of the distributed normal form.

Conclusion:  Non-defining relationships should be included as annotations.

HS: Does this fall within the scope of the Spackman OWL formalization, or should it be forwarded to the OWL representation working group?  

TA: Could the non-defining relationships be represented as necessary conditions (rdfs:subClassOf)?

Universal quantifier — what should the policy be on the allOf  relationship modifierId?

ML: Must not use. We don't have any agreement on whether or how to extend the expressive power of SNOMED in this direction.

HS: Is this documented? 

Conclusion: Universal quantifier is out of scope currently.  We do not expect to receive any from RF2.  No known documentation on this fact exists.

What do we do with Linkage concepts that are not Concept model attributes?

PWI: Does this mean what would you do - for example - if you came across an active relationship that was of type Link assertion?

Open

Conclusion:  These are not definitional concepts – they belong to the information model / instance space.  While they could be declared as ObjectProperties in the OWL, they cannot be incorporated into the actual concept definitions.  These are not currently emitted by the Spackman OWL transform and, as a consequence, I would argue that they fall outside the scope of the Spackman OWL formalization project.

Should we continue to ignore module id in relationships table?

Primitive concepts can be additively defined – modules can add rdfs:subClassOf assertions that do not contradict assertions in other modules.  The current rules, however, require that all definitions be present for a fully-defined concept.   The assertion:   C == intersection(X, Y) contradicts C == intersection (X, Y, Z) unless C is a subset of Z.  Another approach that has been suggested is that each module definition be considered a separate equivalence assertion – the above example would be interpreted as C == intersection(X, Y) and C == Z ... this would require some serious examination and documentation before it could be widely adopted.  We could also add additional rules to the relationships definition itself – asserting, for instance, that all active assertions in the stated relationships file for a given source must be made in the same module.

ML: I do not understand the question. ModuleId is significant for determining which rows in the FULL relationships table are relevant to a specific SNAPSHOT Version (based on the Edition module and & release date). Once you have a SNAPSHOT view of the Relationships table, the moduleId plays no part in the structure/definition of the concept.  Where this might differ is if there is a push to separate things along Edition lines (see comment above). However, given the rules about not modifying the INTERNATIONAL release, I would expect this to be driven by the moduleId of the Concept, not the Relationships.

Conclusion: Yes, we should continue to ignore module id.  All relationships having a typeId that is a descendant of Concept model attribute will be emitted as part of any transformation process.  Note that not all extensions include the SNOMED Model Component namespace – if this is not present, no relationships will be emitted. Note: we may want to consider an additional configuration attribute that states whether the extension is intended to include relationships or whether it is only description/definition changes.

Spackman Transform uses StatedRelationships.  The proposed specification allows stated or Relationships table.  Is this valid?

There has already been discussion on this elsewhere – (see comments here: Representation of SNOMED in OWL.v0.9)

Conclusion:  Issues caused by concepts being pulled in from other modules during classifications would suggest that only the stated form should be used.

HS - will document that transformation rules as only applying to stated relationships.

Header Information

There are a number of attributes that are hard-coded in the Spackman transformation. These attributes are specific to the SNOMED International Edition and do not apply to other transformations:

• module version (e.g. 20160131) – this could potentially be derived from one of the file names

• module version description (e.g. "International Release, Core Module, Release Date: 20160131")

• language to language code map ("900000000000509007": "en-us", "900000000000508004": "en-gb", ...)

• module label (e.g. "SNOMED Clinical Terms, International Release, GB and US English, Stated Relationships, ...")

• module copyright ("Copyright 2016 The International Health Terminology Standards Development Organisation (IHTSDO). All rights reserved....')

• never grouped identifiers (e.g. 123005000, 272741003, 127489000, 411116001)

• right id rules ("363701004": 127489000)

The never grouped list may get resolved in the role group 0 discussion, but we have to carry additional information in a configuration file for the time being.  It is my understanding that right identifiers are no longer used?

This information needs to be distributed with the RF2 release – it should not be part of the conversion tools.

Conclusion:  ???