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 > >
