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 From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale Sent: Friday, 29 April 2011 2:16 AM To: openehr-technical at openehr.org Subject: Re: openEHR artifact namespace identifiers On 08/04/2011 01:49, Heath Frankel wrote: 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. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110429/e86f9e97/attachment.html>
