Hi Mikael I've not seen the final specification, but in it's original draft, it was extremely limited in scope. For instance, the language would have made the grammar unsuitable for use in OpenEHR, though there was no technical reason for this. Apparently there's going to be a new draft shortly.
However even in it's revised form, the document will almost certainly only specify a syntax for building single concepts. It will not provide a syntax or a grammar that deals with conformance and binding, though one of these is surely needed. Grahame Mikael Nystr?m wrote: > Hi, > > Some days after 2008-12-09 IHTSDO probably release a draft of a > compositional grammar for SNOMED CT expressions which can be used for > terminology bindings to SNOMED CT. This draft can probably be a basis for > discussions of terminology bindings. > > Greetings, > Mikael > > > -----Original Message----- > From: openehr-technical-bounces at openehr.org > [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Heath Frankel > Sent: den 2 december 2008 10:27 > To: erisu at imt.liu.se; 'For openEHR technical discussions' > Subject: RE: text and description > > Erik, > I don't see the difference. The same approach can be used with different > query parameters and terminology identifiers. We just need to find a way to > uniquely identify local terminology ids, some sort of namespacing mechanism > such as a terminology source organisation UID should do the trick. This > would not be that much different to uniquely identifying templates which is > also under development. > > Heath > >> -----Original Message----- >> From: e.sundvall at gmail.com [mailto:e.sundvall at gmail.com] On Behalf Of >> Erik >> Sundvall >> Sent: Tuesday, 2 December 2008 7:03 PM >> To: For openEHR technical discussions >> Cc: Heath Frankel; hugh.grady at oceaninformatics.com >> Subject: Re: text and description >> >> Hi! >> >> I know that there are suggestions for defining terminology >> queries/subset-selections using URIs. We discussed this a bit in a >> conference paper that was selected for republication in BMC: >> "Integration of tools for binding archetypes to SNOMED CT" freely >> available at http://www.biomedcentral.com/1472-6947/8/S1/S7 >> >> This kind of URI-encoded queries with semantics have come and gone and >> seem to be coming again in openEHR discussions. Sometimes the URIs >> have contained semantics similar to what you describe below. Sometimes >> they have just contained ID's of queries that have their semantics >> hidden, sorry I mean stored/maintained, in some query server. See >> especially the appendix in the paper above for discussion and >> references. >> >> However, my recent question/suggestion did not have much to do with >> those URI-encoded terminology queries. >> >> Instead, I was asking about two specific use-cases: >> 1. directly pointing out single codes/concepts that already have URIs and >> 2. a way of creating "local" bindings using URIs as unique identifiers. >> >> Please re-read the previous post and feel free to ask more if I have >> not made the difference clear enough. >> >> Best regards, >> Erik Sundvall >> erisu at imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579 >> >> >> >> On Mon, Dec 1, 2008 at 22:28, Heath Frankel >> <heath.frankel at oceaninformatics.com> wrote: >>> Hi Erik, >>> As you know Ocean has been doing a lot of work making terminology and >>> openEHR Archetype work. Hugh Grady is the best to describe this but in >>> summary we are proposing the use of terminology URIs for bindings. >>> >>> Bindings can reference a whole terminology, a branch of a terminology >>> hierarchy or a complex query which extracts specific subset of a >>> terminology. >>> >>> To identify these there at least four identifiers; terminology ID, > subset >>> ID, query name and query version id. There are other parameters such as >>> language and terminology version. >>> >>> In simply cases where you just want to reference a terminology it might > look >>> something like the following >>> (NOTE: these are examples to illustrate the point and are certainly not > a >>> final proposal). >>> terminology:snomed-ct?language=en-GB >>> >>> or for a specific version of SNOMED >>> terminology:snomed-ct(2003)?language=en-GB >>> >>> For a hierarchy of a terminology it might look something like >>> terminology:snomed-ct(2003)/hierarchy?rootConcept=28374832 >>> >>> and for a pre-specified query >>> terminology:snomed-ct(2003)/query?name=AllBacteria >>> >>> There are also more specific URIs for terminology queries by using > subset >>> and query version identifiers (UIDs) mentioned above. >>> >>> I believe this work is ongoing and is being proposed through IHTSDO. I >>> suggest we wait for that work to conclude but I thought I would let you > know >>> that Erik's thinking is certainly the way things are being proposed. >>> >>> Heath >>> >>>> -----Original Message----- >>>> From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- >>>> bounces at openehr.org] On Behalf Of Erik Sundvall >>>> Sent: Monday, 1 December 2008 11:20 PM >>>> To: For openEHR technical discussions >>>> Subject: Re: text and description >>>> >>>> Hi! >>>> >>>> Would it be a good or bad idea to have URI:: as a valid terminology >>>> prefix in openEHR terminology bindings, with the intention to host... >>>> >>>> 1. "local" bindings that are not foreseen to be of public general use: >>>> > URI::http://www.cs.chalmers.se/~oloft/terminologies/odont-123/local-Mucos- >>>> txtur >>>> >>>> 2. Potentially universally interesting terminologies that already have >>>> official URIs but do not (yet?) have openEHR-defined prefix: >>>> URI::urn:miriam:obo.go:GO%3A0045202 >>>> >>>> I guess opening up for any URIs would lead to a risk of having double >>>> representations (URI+openEHR-prefix) for the same thing, like... >>>> URI::urn:UMLS/CID=C0037658 >>>> >>>> ...and the example URI::urn:miriam:obo.go:GO%3A0045202 is just one of >>>> several URI-ways to point out an entry in the gene ontology.. >>>> >>>> What are the other pitfalls and/or benefits? >>>> >>>> I guess there will probably never be only one ultimate updated >>>> registry fitting every purpose, not from openEHR, not from EuroRec not >>>> from anybody else. >>>> >>>> Best regards, >>>> Erik Sundvall >>>> erisu at imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579 >>>> >>>> P.s. Remember that URIs include both URLs and URNs >>>> >>>> On Mon, Dec 1, 2008 at 09:09, Gerard Freriks <gfrer at luna.nl> wrote: >>>>> Dear all, >>>>> The European Institute for Health Records has created a registry of >>> coding >>>>> systems. >>>>> In the (near) future they expect to be the place where coding systems >>> and >>>>> their meta-information are registered so an URL and unique > identifying >>>>> number will suffice. >>>>> Will this be the way to go? >>>>> Gerard >>>>> >>>>> >>>>> -- <private> -- >>>>> Gerard Freriks, MD >>>>> Huigsloterdijk 378 >>>>> 2158 LR Buitenkaag >>>>> The Netherlands >>>>> T: +31 252544896 >>>>> M: +31 620347088 >>>>> E: gfrer at luna.nl >>>>> >>>>> Those who would give up essential Liberty, to purchase a little >>> temporary >>>>> Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov >>> 1755 >>>>> >>>>> >>>>> >>>>> On 1, Dec, 2008, at 5:26 , Koray Atalag wrote: >>>>> >>>>> So custom/local terminologies can be handled this way and the >>> implementation >>>>> will be left to developers....BUT this may result in different >>>>> implementations which may render interoperability in the long run.... >>>>> >>>>> So I suggest a sub-section within ontology section where used >>> terminologies >>>>> are declared explicitly; i.e. "umls": 2008AA version of NLM UMLS >>> knowledge >>>>> sources. Perhaps an URI and other details can be specified (i.e. > WSDL). >>> I >>>>> think it is easier for the community to agree on such a naming >>> convention. >>>>> Custom local terminologies can be declared this way and you can > create >>>>> terminology names for use in term/constraint bindings.Perhaps > creating a >>>>> keyword (i.e. CustomTerminology) might be a good idea so that these >>> names do >>>>> not interfere with formal names. >>>>> >>>>> Cheers, >>>>> >>>>> >>>>> _______________________________________________ >>>>> openEHR-technical mailing list >>>>> openEHR-technical at openehr.org >>>>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >>>>> >>>>> >>>> _______________________________________________ >>>> openEHR-technical mailing list >>>> openEHR-technical at openehr.org >>>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >>> > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
