Hi Diego,
Very interesting. Is any of the documentation available without paying a small fortune?
Ian
Dr Ian McNicoll
office +44 (0)1536 414994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com
Clinical analyst, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org
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.
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 
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
Thomas,
Your proposed changes to the archetype Identifiers and governance actually aligns with the same management and inferencing requirements as OIDs, the only benefit left is the readability, but even that is becoming hard to do with the additional namespaces and delimiters. In addition, having meaningful IDs and deriving meaning from IDs is counter to what good practice in terminology identifier management.
for atomic concepts a la SNOMED, meaningless identifiers make sense; for complex artefacts like programming language source files - of which archetypes are an example, they don’t really - they just obscures meaning from developers. Meaningless identifiers of the Guid variety make sense for deployed versions of these artefacts - i.e. generated template OPTs, assemblies etc. Where identification really matters is a) in data and b) in deployed software artefacts that were generated from templates & archetypes.
The future may well be to do as David Moner (I think, or maybe Diego, can’t remember now) said - to create archetype meta-data attributes to carry the pieces of the id, and generate the strings that we currently use as ids when and as needed. Attaching Guids to source archetypes can also be done obviously, but I think for source artefacts, Oids provide little gain and a lot of pain.
Source file class in a program language have names and in the cases of COM they have an ID such as a GUID. The issue here is related to the later, not the former.
More than happy with a GUID, in fact our knowledge resource repository does exactly what David Moner proposed, it assigns a resource ID (GUID) and maintains a version tree ID.
Really I don’t see the difference between a GUID and OID, as you say elsewhere, they are just strings. It is just the process used to create the string that differs and when we start introducing governance with publishing organisations, having an OID root for the publishing organisation and an extension for each artefact generated by a repository system aligns so nicely with the OID approach I can’t understand why we so easily blow this option off.
Once we have a reliable UID of some kind we can generate URIs. The alternative of generating a composite UID from meta data sounds complicated, contentious, unreliable and frankly worse than the same kind of issues you have with OIDs.
Heath