Exactly, an OID can be used as an URI scheme.
Not sure how much simpler you can get then assigning a string of numbers and dots to a system that issues an accession number and appends it the assigned string, CKM already does the first two steps of this. Anyone that can implement a openEHR -based health record service or an ADL parser should be able to cope with this. Anyway, I am happy with a URI as long as we leave open the scheme choice in ADL/AOM and adopt a limited set of standard schemes for openEHR archetypes rather than invent a new one. However, it does mean a substantial change to the AOM compared with using the existing UID attribute of type HIER_OBJECT_ID. A URI can always be constructed from this as is done with EHR URIs. Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale Sent: Friday, 8 April 2011 11:50 PM To: openehr-technical at openehr.org Subject: Re: openEHR artifact namespace identifiers On 08/04/2011 14:28, pablo pazos wrote: 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. if you have a look at the Architecture <http://www.openehr.org/releases/1.0.2/architecture/overview.pdf> Overview spec, this is documented in some detail (more is needed... next release ;-). When Tony Shannon and I met a couple of years ago with Tim Berners-Lee, this was almost the only thing he found significant - that we could point to any knowledge model node or data instance node with a proper URI. Of course you can stick an Oid inside a URI, but I am still very unconvinced about Oids. I don't like making things complex when they can be simple. - thomas beale -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110411/4f7f6d9f/attachment.html>
