this relates to the question of how SNOMED represents Ref set ids. In SCT concept space, all 'concept' ids are unique for the whole planet, with special bits being used to distinguish concepts and ref sets within national or other 'extensions' (i.e. outside the international release). So the question for the industry overall is: do we go to the SNOMED way of doing things (requires all other terminologies to be representable in SNOMED CT form) or do we have some more technologically neutral form? The URNs examples below raise the question: what is the internationally agreed namespacing scheme to use? WHat are the rules for establishing new URNs?
I don't know what the answers are at this stage, because it requires some sort of global / standards agreement, and that does not yet exist. - thomas On 21/02/2011 02:28, Andrew Patterson wrote: > I'm confused as to whether the intention here was really URI, URL or > URN? > > My understanding was that the use of DV_URI for term binding in archetypes was > more in the vein of global identification of resources (more URN) > rather than actually telling the software how to get to the resource > (ala URL). > > So I imagined that each EHR implementation would need to somehow > have a lookup table from terminology resources -> actual terminology > resource access mechanism. I mean, you can't actually use the > terminology reference as an actual URL and do a GET on it? What is > the return value? In the absence of an agreed terminology service > layer definition within openEHR I can't see how that could possibly work. > > So that is why I thought that they would be more along the lines of > > ["ac0001"] =<[urn:fdc:nehta.gov.au:2010:ctppconcepts]> > > or (in URL format, but clearly not an actual web location) > > ["ac0001"] =<[http://nehta.gov.au/cttpconcepts]> > > So to answer Pablo's question >> So, how can a machine know the difference or >> equivalency of both URIs? (URIs are universal, but >> not a unique way to identify a terminology or a subset). > They are equivalent if the canonical form of the URI is equivalent. > If the archetype is published globally, then the URI needs to > globally unique and every implementation that wants to deal > with the archetype will need to have a mechanism for turning > the globally unique URI into an real actual terminology set. > > I don't think implementations are meant to be looking inside the > URI to try to extract parameters, subsets etc. If they are then > we are at least one entire specification short of implementing > archetypes.. > > Andrew > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -- Ocean Informatics *Thomas Beale Chief Technology Officer, Ocean Informatics <http://www.oceaninformatics.com/>* Chair Architectural Review Board, /open/EHR Foundation <http://www.openehr.org/> Honorary Research Fellow, University College London <http://www.chime.ucl.ac.uk/> Chartered IT Professional Fellow, BCS, British Computer Society <http://www.bcs.org.uk/> Health IT blog <http://www.wolandscat.net/> * * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110221/ae6f6d1a/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110221/ae6f6d1a/attachment.jpg>
