Yep, EHR URIs for global operations like referencing a knowledge artifact internal node or in AQL/EQL queries referencing a set of RM nodes are good enough for me. I think our team will start working on querying and reporting in a couple of months when we have a more robust implementation of our openEHR-based tool (http://code.google.com/p/open-ehr-gen-framework/). Then we'll see if the URI approach is enough :D -- 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 Date: Fri, 8 Apr 2011 15:19:47 +0100 From: thomas.be...@oceaninformatics.com 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 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 _______________________________________________ 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/20110409/caafc24e/attachment.html>