Hi Heath, Just analysing OIDs vs. URIs:
Usage: OIDs are in use in health informatics and other areas. URIs are in use everywhere in form of URLs Procesing: OIDs lack internal processing URIs can be processed Compatibility with actual identifiers: Inside archetypes, each node can be identified by a path, so if we use URIs to identify an archetype, just appending the path to the URI we get a valid URI to identify a node inside the archetyp. I go with URIs. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos > From: heath.frankel at oceaninformatics.com > To: openehr-technical at openehr.org > Subject: RE: openEHR artifact namespace identifiers > Date: Fri, 8 Apr 2011 10:10:09 +0930 > > Hi Erik, > I was suggesting that we enforce OIDs, in fact my intent was similar to > yours, to open up the choice of what is used and not enforce the specially > designed ID scheme currently used that requires upgrading to support > namespacing making it have the same issues as the standard UID schemes. > > I like the suggestion of URIs, although I also agree with Tom's later > comment that within openEHR implementations we should try to limit the > options of the URI schemes used. However, ADL and AOM shouldn't be > restricted to this same set, to allow other implementation profiles for > other reference models to make their own choices. > > Heath > > > -----Original Message----- > > From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- > > bounces at openehr.org] On Behalf Of Erik Sundvall > > Sent: Wednesday, 6 April 2011 9:04 PM > > To: For openEHR technical discussions > > Subject: Re: openEHR artefact namespace identifiers > > > > Hi! > > > > On Tue, Apr 5, 2011 at 17:51, Ian McNicoll > > <Ian.McNicoll at oceaninformatics.com> wrote: > > > artefact identification proposals > > > at > > http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/ > > am/knowledge_id_system.pdf > > ... > > > se.skl.epj::openEHR-EHR-EVALUATION.problem.v1 > > > > ...Then discussions regarding UUIDs, OIDs etc followed in several > > messages.... > > > > Is not the simplest thing to just use URIs [ > > http://en.wikipedia.org/wiki/Uniform_Resource_Identifier ], or even > > better allowing non-latin characters by using IRIs [ > > http://tools.ietf.org/html/rfc3987 ]? > > > > Then organizations can choose if they want to base IDs on > > domain-names, UUIDs, OIDs or whatever that fits in a URI (which might > > be a URN, see list at http://www.iana.org/assignments/urn-namespaces/ > > ). Some archetype authoring organizations may like names with > > semantics, some may not, so why enforce any of the views. > > > > Now since metadata is going to be well defined inside the file, the > > need for semantics in identifiers or file names is gone so the main > > thing left is that we want a _unique_ string. URIs are supposed to be > > unique. > > > > Some URI-examples: > > urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 > > urn:oid:1.3.6.1.2.1.27 > > urn:lsid:chemacx.cambridgesoft.com:ACX:CAS967582:1 > > http://id.skl.se/openEHR/EHR-EVALUATION.problem.v1 > > http://schema.openehr.org/openEHR/EHR/EVALUATION/problem/v3 > > urn:nbn:se:liu:diva-38012 > > > > I see no point in enforcing usage of OIDs as suggested in some > > responses. > > > > The idea of not changing the ID if/when transferring responsibility of > > an archetype between authorities sounds very reasonable if the content > > is unchanged. > > > > When I visited Brazil, I noticed that the MLHIM project's development > > version was using UUIDs for the artifacts (CCDs) that correspond to > > what is called archetypes in openEHR. > > > > Best regards, > > Erik Sundvall > > erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 > > > > _______________________________________________ > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110408/abd75895/attachment.html>
