Bert picked up an anomaly in this PR that I think should probably be fixed. ARCHETYPE.uid is of type UUID in the AOM2 spec, but of type HIER_OBJECT_ID in the AOM1.4 spec (the latter type is the openEHR type for OIDs). However it appears that all ADL1.4 archetypes that have a uid have it as a Guid (i.e. UUID), and I assume the various tools do as well. We avoid Oids like the plague in openEHR, and I am not aware of them being used anywhere.
If we can verify that everything assumes a UUID for this field, then the spec is wrong, and we should update it from 1.4.2 to 1.4.3, i.e. treat this as an error correction.
Could tool makers check this issue and report here?
Your statement that the use of HIER_OBJECT_ID in the AOM1.4 spec is used for OIDs is incorrect. HIER_OBJECT_ID is a complex type with a value attribute of type UID, which may be either UUID, ISO_OID or INTERNET_ID.
The bigger issue is the HIER_OBJECT_ID is incompatible with UUID from a XML schema perspective as UUID is a simple type with a restricted string value while HIER_OBJECT_ID is a complex type with a child element value. The V1.4 AOM XML schema uses this HIER_OBJECT_ID type (as per the AOM specification) and since the OPT schema inherits this model, it also uses this type and all OPTs generated by CKM (and the template designer) populate the uid element with the template GUID specified in the OET file.
I suggest that the ADL 2 specification is that one that needs to change or there needs to be a specified mapping between the two.
AOM 1.4 Archetype.uid is HIER_OBJECT_ID, value have both root: UID and extension: String, more or less an II of HL7. But, he is right, UID can be UUID or OID.
AOM 2 Archetype.uid is UUID, besides tooling, hat makes AOM 1.4 spec incompatible with AOM v spec.
Also the description of AOM v1.4 is wrong for Archetype.uid: “OID identifier of this archetype.”, because it can be UUID or OID root, and also have an extension!
Lastly, the AOM 1.4 spec doesn’t say anything about the extension, so some archetypes might have c1315be0-203a-42e4-a6be-d5b0db05d27d::extension34232 or 2.1.123.342.235.456::extension342342 as uid.
I think we might need to do an amendment like AOM 1.5 saying that extension should be empty and the UID should be UUID for Archetype.uid.
About the schema, IMO that is a different topic since it is not related with the AOM spec. Still need to discuss good XML representations. On the other hand, we are focused on JSON right now for the REST API, so we might need to focus on JSON Schema more than XSD.
Although the OID and UUID as used in the archetypes are (in the most simple (one arc) OID-occurrence) technical interchangeable is their semantical meaning completely different. So what do we want to express here? Is it ever used in the way a OID is meant to be used? (to trace back the organization that is responsible for creating/maintaining the archetype and assign a purpose/meaning to the archetype)
The OID is a paper tiger, it suggests something, with structured meaning, but no organization I know has the overhead of maintaining useful use of OID's in archetypes implemented. That is why, also, they do not occur in CKM and no-one ever complained about that, for ten years. No software I know is interpreting the arcs of the OID in the uid-property of an archetype, it would run into trouble when it did. The tooling (including CKM) has no way to support administrative overhead.
That the use of OID in the uid-property of archetypes is not useful, is illustrated by replacing the OID by a UUID in ADL/AOM 2.0.x
When remaining to the OID in 1.4.x, we create an illusion, we suggest some structure in the uid-property which is not there. In fact opposite, we suggest that all archetypes are to be maintained by different organizations because they have a different uid and only one arc.
The problem I have is that the current situation with OID in the uid-property corrupts the administrative use. We write a UUID, we call it OID but we treat it as a UUID, because the practical use does not allow to see it as a meaningful structure.
Your statement that the use of HIER_OBJECT_ID in the AOM1.4 spec is used for OIDs is incorrect. HIER_OBJECT_ID is a complex type with a value attribute of type UID, which may be either UUID, ISO_OID or INTERNET_ID.
Seems that the story is not finished yet. Someone in a project I work made the joke to rename HIER_OBJECT_ID to ANY_KIND_OF_ID, because it can represent almost any type of id.
What is the official defined purpose of the Archetype.uid property?
Two machine identifiers are defined for archetypes. The ARCHETYPE.*uid* attribute defines a machine identifier equivalent to the human readable ARCHETYPE.*archetype_id*.*semantic_id* , i.e. ARCHETYPE_HRID up to its major version, and changes whenever the latter does. It is defined as optional but to be practically useful would need to be mandatory for all archetypes within a custodian organisation where this identifier was in use. It could in principle be synthesised at any time for a custodian that decided to implement it.
The ARCHETYPE.*build_uid* attribute is also optional, and if used, is intended to provide a unique identifier that corresponds to any change in version of the artefact. At a minimum, this means generating a new UUID for each change to:
ARCHETYPE.*archetype_id*.*release_version*;
ARCHETYPE.*archetype_id*.*build_count*;
ARCHETYPE.*description*.*lifecycle_state*.
For every change made to an archetype inside a controlled repository (for example, addition or update of meta-data fields), this field should be updated with a new UUID value, generated in the normal way.
First reaction, I need to reread your reply carefully. We also have an MD5 key as part of the archetype to detect changes. What does the build_uid add to this? I discovered that the template - editor uses the MD5 key for that purpose.
I believe that William Goossen is depending on OID’s in DCM, in which archetypes can play a role. But for his case, he can add a description-field, containing a OID. I think that would be better for him, because then he can trust that there is always a usable OID in the archetypes he refers to and not, like now in 99% of the archetypes is the case in the uid-property, a UUID. I think, best is when there is uniformity in the use of the standard, the HIER_OBJECT_ID, which can be anything, with every possible semantic meaning does not look right in a standard. As is in the definition, the uid serves as a machine-readable identifier equivalent to the archetype-id, which is human readable. For this purpose, it needs to be unique. But how hard is it for a computer to check if a ID is unique, when the computer must guess what kind of Id is used? I think the definition of the uid needs to be tighter. Now it is said in the specs: uid: HIER_OBJECT_ID: “OID identifier of this archetype.” This is definitely wrong, it can be anything, as long as it fits in HIER_OBJECT_ID, which is quite a lot, and my original question was to change the specs. And the best thing is to change it to its common practical use, which is UUID. Best regards Bert
Wouldn't it be a good idea to have the build_uid of type HIER_OBJECT_ID, and have it the same UUID as the uid-property and behind the UUID the double colon and then the buildnumber?
It would do right to the HIER_OBJECT_ID nature of being hierarchical in the way that it would represent a hierarchy of builds.
And it would make it machine-interpretable that it would be related to the uid-property, and it would make it machine-interpretable which build of the original uid it is.
As it is now, a machine cannot relate the build_uid to the original uid-property.
In this way, it also does not matter which type the root is, because the mechanism still works.
It’s not correct to say that HIER_OBJECT_ID can represent anything. It can represent ids that are made of a UID root (either a UUID or OID or domain name or reverse domain name) and a String extension. While the String part could be abused, it isn’t in properly built software. As can be seen in the model, there quite a few other identifier types as well.
You are right about the error you mention however, we need to fix the documentation for that.
UID can also be INTERNET_ID, and the “extension” and double colon are not required, so the HIER_OBJECT_ID cannot represent anything, but it is a lot. Of course it is a matter of taste, maybe there are good arguments to make the archetype.uid available for so many ID-types. Thanks, that helps me. Bert
I'm not saying it's the best design, and if we had our time again, we might do something simpler. All I am saying is we need to understand objectively what the model that is there says, so that developers and users know how to work with it.
How about the idea of using the same UUID ofr the build_uid- and uid-property, but then extended with a version number?
Giving a different UUID to the build_uid makes it impossible to a machine to relate the build_uid to the original archetype.uid.
It seems that the build_uid is quite useless how it is arranged now. It just indicates a new version, but not which version, and the which versions are older and what the original version was. There is external administration needed, I think this can be avoided.
Sorry if I miss the point. It might be explained somewhere.
