URI's for SNOMED CT Languages
Discussion about the form of URIs for SNOMED CT Languages
Comments
Thanks very much for your URI proposal Harold!
In principle, this sounds like a great idea ... but I have a few comments on the specific syntax proposed:
The 'fol' (Family of Languages) abbreviation is problematic, as the community associates the word 'language' with languages like English, Spanish, Danish, French and German etc. If we are going to use a field to separate the 'snomed.info' from the 'ecl'/'scg' part, then another suggestion is to use 'syntax' (noting that this also permits reference to the 'template syntax', which in itself is not a whole language (like the 'expression template language' or 'expression constraint template language' is).
http://snomed.info/syntax/{syntax name}
The abbreviation for Compositional Grammar used to refer to the specification document is 'scg' (i.e. snomed.org/scg). It would therefore be good to be consistent in the URI spec - i.e.
The URL for the Express Constraint Language specification is "snomed.org/ecl" .... so 'ecl' is an appropriate abbreviation:
Please do not use SQL as the abbreviation for SNOMED Query Language ... because this obviously means something else to many people. Perhaps instead:
The SNOMED CT Template Syntax is a syntax and not a language, so something like:
The SNOMED CT Expression Template Language:
The SNOMED CT Expression Constraint Template Language:
http://snomed.info/syntax/ctl
The SNOMED CT Query Template Language:
http://snomed.info/syntax/qtl
With respect to use cases - I think we have a use case for trying to define expressions, expression constraints and expression templates as URIs - as this seems to be the preferred mechanism for terminology bindings to FHIR resources. Do you have any suggestions on how this could be done (given the special characters included)?
Also, just to reiterate what we discuss in the meeting, once we have finished discussing this within the Languages Project Group, we will take this proposal to the Modelling Advisory Group for further action (and updates to the URL standard).
Kind regards,
Linda.
While I don't care deeply what category is used, 'syntax' seems particularly odd, given that the the word 'language' appears in "ecl" and "etl" – the only one that is a syntax is "sts". Is "language" completely banned as in the category slot, or could we use something like "lsg" (language, syntax grammar)?
Requirements
1) A shared and standard URI to identify the particular family of languages language (Compositional Grammar, Expression Constraint Language, etc.)
<expression language="URI">(expression)</expression>
Examples:
<expression language="http://snomed.info/fol/ecl">
<![CDATA[<< 77400008 | Appendicitis| ]]>
</expression>
{"expression":
{"language": "http://snomed.info/fol/ecl/version/1.0",
"_contents": "<< 77400008 |Appendicitis|"}
}
2) A mime type to identify referenced languages:
<import href="pointer to a resource" type="MIME" />
Example:
<import href="samples/appendicitis_sample" type="application/snomed-ecl"/>
In particular, we note that we do not have any requirement to be able to embed a CG or ECL expression directly within a URL. The closest that we would come to this might be where an expression would be included as a parameter:
http://example.org/server/valueset?expr=%3C%3C+77400008+%7CAppendicitis%7C
(given the fact that none of these languages are particularly URI friendly, I suspect that we'd always pass it as mime encoded data (another reason for the mime type)...)
Proposed URI's
The SNOMED CT URI specification defines the following patterns:
http://snomed.info/sct – the SNOMED CT code system (specifically intended for use with FHIR)
http://snomed.info/sct/{sctid}[/version/{timestamp} – editions and versions
http://snomed.info/id/{sctid} - SNOMED CT "Component" (any item identified by an SCTID such as Concept, Relationship, or Description)
http://snomed.info/id/{uuid} - SNOMED CT reference set
http://snomed.info/sct/{moduleid}/version/{time}/id/{sctid} – version relative component
http://snomed.info/sct/{moduleid}/version/{time}/id/{uuid} - version relative reference set
http://snomed.info/module/{sctid} - snomed ct module
http://snomed.info/module/{sctid}/time/{timestamp} - module at a particular point in time
http://snomed.info/field/{tablename}.{fieldname} - a field in an RF2 table
The pattern that appears consistently against all but (arguably) the first is:
http://snomed.info/{category}/{identifier}/(subcategory)/{identifier}/subsubcategory/{identifier}
I believe that we should remain consistent with this approach. We need to identify languages, so we should create a new category ("lpg", "fol", "scl", ...) and with a new set of identifiers. I would recommend:
http://snomed.info/fol/ecl – for expression constraint language
http://snomed.info/fol/cgl – compositional grammar
http://snomed.info/fol/sql — query language
etc.
And
http://snomed.info/fol/ecl/version/0.9 – for version 0.9 of the SCT expression constrant language
...