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

[Bert Verhees]

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.

Bert


On 17-06-17 15:11, Thomas Beale wrote:



On 16/06/2017 21:13, Bert Verhees wrote:


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.


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.


- thomas


___
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?

[Thomas Beale]

On 16/06/2017 21:13, Bert Verhees wrote:


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.


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.


- thomas


___
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]

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

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

[Bert Verhees]

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.

But I come back to this tomorrow.

Bert

Op vr 16 jun. 2017 00:24 schreef Thomas Beale :

> 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?

[Thomas Beale]

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

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

[Bert Verhees]

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?


Op 15 jun. 2017 19:41 schreef "Pablo Pazos" :

> Hi Bert, when using ISO OIDs, UUIDs are not one arc OIDs since they have
> to start with a specific arc 1. or 2.
>
> http://www.oid-info.com/cgi-bin/display?tree=
>
> On Jun 15, 2017 4:33 AM, "Bert Verhees"  wrote:
>
>> 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.
>>
>> Bert
>>
>>
>>
>>
>> On 15-06-17 03:17, Heath Frankel wrote:
>>
>> Hi Thomas,
>>
>> 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.
>>
>>
>>
>> Regards
>>
>>
>>
>> Heath
>>
>>
>>
>> *From:* openEHR-technical [mailto:openehr-technical-boun
>> c...@lists.openehr.org ] *On
>> Behalf Of *Thomas Beale
>> *Sent:* Thursday, 15 June 2017 5:40 AM
>> *To:* Openehr-Technical 
>> 
>> *Subject:* AOM 1.4 - Archetype.uid a UUID or OID?
>>
>>
>>
>>
>>
>> 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?
>>
>> thanks
>>
>> - thomas
>>
>>
>>
>> --
>> 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 
>> 

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

[Pablo Pazos]

In 1.4 the description of Archetype.uid saying "OID..." is incorrect. It
should say "UID root with no extension".



On Jun 15, 2017 7:50 AM, "Thomas Beale"  wrote:

>
> On 15/06/2017 02:17, Heath Frankel wrote:
>
> Hi Thomas,
>
> 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.
>
>
> Right. I was skimming over that detail... I remember now the logic of this
> choice - we originally thought we should accommodate UUIDs (Guids) and
> OIDs, which does require a HIER_OBJECT_ID in the openEHR type system.
>
>
>
> 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.
>
>
>
> from the point of view of continuity, that is probably correct. However we
> wouldn't need to do that just in order to maintain XSD compatibility - we
> can maintain the XSD HIER_OBJECT_ID type in that field, in a version of the
> AOM2 XSD that aims to be compatible with the AOM1.4 XSD, while in a more
> efficient AOM2 XSD which we might write, it would just be a restricted
> string field, i.e. a UUID.
>
> I am more inclined to make the AOM2 specification, which is normative, as
> clean as it can be. And since it has other breaking changes, having this
> one as well is not problematic.
>
> I also think that the AOM1.4 spec is correct as it is, given what Heath
> says above. So really it comes down to how we treat XSDs and XML, not the
> normative models of archetypes.
>
> - thomas
>
>
>
>
>
> ___
> 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?

[Pablo Pazos]

Hi Bert, when using ISO OIDs, UUIDs are not one arc OIDs since they have to
start with a specific arc 1. or 2.

http://www.oid-info.com/cgi-bin/display?tree=

On Jun 15, 2017 4:33 AM, "Bert Verhees"  wrote:

> 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.
>
> Bert
>
>
>
>
> On 15-06-17 03:17, Heath Frankel wrote:
>
> Hi Thomas,
>
> 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.
>
>
>
> Regards
>
>
>
> Heath
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org ] *On
> Behalf Of *Thomas Beale
> *Sent:* Thursday, 15 June 2017 5:40 AM
> *To:* Openehr-Technical 
> 
> *Subject:* AOM 1.4 - Archetype.uid a UUID or OID?
>
>
>
>
>
> 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?
>
> thanks
>
> - thomas
>
>
>
> --
> 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 
> listopenEHR-technical@lists.openehr.orghttp://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
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org

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

[Bert Verhees]

On 15-06-17 12:49, Thomas Beale wrote:



On 15/06/2017 02:17, Heath Frankel wrote:


Hi Thomas,

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.




Right. I was skimming over that detail... I remember now the logic of 
this choice - we originally thought we should accommodate UUIDs 
(Guids) and OIDs, which does require a HIER_OBJECT_ID in the openEHR 
type system.


That is right, the loadValue function creates a UUID from the 
root-value  if it has that specific string-pattern. So the root of a 
HIER_OBJECT_ID can always be a UUID. Nifty construct. My mistake also, 
sorry for the trouble


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]

On 15/06/2017 02:17, Heath Frankel wrote:


Hi Thomas,

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.




Right. I was skimming over that detail... I remember now the logic of 
this choice - we originally thought we should accommodate UUIDs (Guids) 
and OIDs, which does require a HIER_OBJECT_ID in the openEHR type system.


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.





from the point of view of continuity, that is probably correct. However 
we wouldn't need to do that just in order to maintain XSD compatibility 
- we can maintain the XSD HIER_OBJECT_ID type in that field, in a 
version of the AOM2 XSD that aims to be compatible with the AOM1.4 XSD, 
while in a more efficient AOM2 XSD which we might write, it would just 
be a restricted string field, i.e. a UUID.


I am more inclined to make the AOM2 specification, which is normative, 
as clean as it can be. And since it has other breaking changes, having 
this one as well is not problematic.


I also think that the AOM1.4 spec is correct as it is, given what Heath 
says above. So really it comes down to how we treat XSDs and XML, not 
the normative models of archetypes.


- thomas


___
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]

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.


Bert




On 15-06-17 03:17, Heath Frankel wrote:


Hi Thomas,

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.


Regards

Heath

*From:*openEHR-technical 
[mailto:openehr-technical-boun...@lists.openehr.org] *On Behalf Of 
*Thomas Beale

*Sent:* Thursday, 15 June 2017 5:40 AM
*To:* Openehr-Technical 
*Subject:* AOM 1.4 - Archetype.uid a UUID or OID?

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?

thanks

- thomas

--
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



___
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?

[Heath Frankel]

Hi Thomas,
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.

Regards

Heath

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Thursday, 15 June 2017 5:40 AM
To: Openehr-Technical 
Subject: AOM 1.4 - Archetype.uid a UUID or OID?




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?

thanks

- thomas

--
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?

[Pablo Pazos]

Never saw an OID in any tool I tested and I tested most of the open tools.
I would say UUID is the industry standard here :)

On Wed, Jun 14, 2017 at 5:09 PM, Thomas Beale 
wrote:

>
> 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?
>
> thanks
>
> - thomas
>
> --
> 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
>



-- 
Ing. Pablo Pazos Gutiérrez
Cel:(00598) 99 043 145
Skype: cabolabs

http://www.cabolabs.com
pablo.pa...@cabolabs.com
Subscribe to our newsletter 
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org