Re: AOM 1.4 - Archetype.uid a UUID or OID?

[Bert Verhees]

On 16-06-17 21:12, Thomas Beale wrote:



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.




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.




You are right about the error you mention however, we need to fix the 
documentation for that.



Thanks, that helps me.

Bert

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AOM 1.4 - Archetype.uid a UUID or OID?

[Thomas Beale]

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.


- thomas


On 16/06/2017 10:05, Bert Verhees wrote:
I have a few thoughts, although the question has become less urgent to 
me, because I can use the HIER_OBJECT_ID to store a UUID. Which is a 
bit funny, but it is correct following the OpenEHR specs, so I can 
convince others that it is right.



On 16-06-17 01:36, Heath Frankel wrote:


No one uses OIDs and this is not the problem.



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.


The issue is AOM 1.4 uses the complex type HIER_OBJECT_ID which has a 
value attribute of type UID while AOM 2.0 uses simple type of 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."

http://www.openehr.org/releases/AM/Release-2.0.6/docs/AOM1.4/AOM1.4.html#_archetype_class

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


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AOM 1.4 - Archetype.uid a UUID or OID?

[Bert Verhees]

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.


Bert

On 16-06-17 00:23, Thomas Beale wrote:


from here 
:


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.


- thomas

On 15/06/2017 23:09, Bert Verhees wrote:
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?





___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AOM 1.4 - Archetype.uid a UUID or OID?

[Bert Verhees]

I have a few thoughts, although the question has become less urgent to 
me, because I can use the HIER_OBJECT_ID to store a UUID. Which is a bit 
funny, but it is correct following the OpenEHR specs, so I can convince 
others that it is right.



On 16-06-17 01:36, Heath Frankel wrote:


No one uses OIDs and this is not the problem.



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.


The issue is AOM 1.4 uses the complex type HIER_OBJECT_ID which has a 
value attribute of type UID while AOM 2.0 uses simple type of 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."

http://www.openehr.org/releases/AM/Release-2.0.6/docs/AOM1.4/AOM1.4.html#_archetype_class

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
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org