It has previously been argued that the AUTHORED_RESOURCE.uid field, inherited into the ARCHETYPE class in AOM 1.4, and similar classes in AOM 2, should accommodate Oids and GUIDs.
However, Oids appear to be rarely used, and leaving this choice available complicates software unnecessarily.
If Oids are needed as ids, we should consider them as 'supplementary' ids attached in a dedicated meta-data field in the AUTHORED_RESOURCE class.
Yes but this is inherited from AUTHORED_RESOURCE which might refer to design-time artefacts, I think?
yes, this is correct. However, similar arguments could apply to LOCATABLE.uid...(although that is not at all what this PR is about).
@Diego, sorry, I don't see the connection between the archetype uid (this issue) and the oid of implementation guides or cda instances.
@Pablo as always, you could create an equivalent archetype from something that has an OID, and probably this is the best place to store it.
I agree with Thomas that having additional types of identifiers makes software (at least some) more complex. Parsing, identifying what type it is, generating, searching, etc.
I agree with Heath that storing an OID elsewhere in some metadata is not ideal if someone is really using this as a primary identifier.
This then can only be some kind of reference to additional external identifiers, while the UUID would be primary.
My personal opinion is that openEHR should be bold enough to say that it uses UUIDs, not OIDs.
UUIDs are proven, widely in use, and I think it is fair enough to favour them over OIDs nowadays.
Any other ids can be attached, be it OIDs, URIs / URNs.
The alternative is to allow all URIs/URNs and if you want to use a UUID, you use urn:uuid: as the prefix.
I am just not sure there is much value in allowing this + it may add confusion if and when to use/add/search with our without urn:uuid: