AOM 1.4 - Archetype.uid a UUID or OID?

Pablo Pazos pablo.pazos at cabolabs.com
Thu Jun 15 13:40:50 EDT 2017


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" <bert.verhees at rosa.nl> 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-
> bounces at lists.openehr.org <openehr-technical-bounces at lists.openehr.org>] *On
> Behalf Of *Thomas Beale
> *Sent:* Thursday, 15 June 2017 5:40 AM
> *To:* Openehr-Technical <openehr-technical at lists.openehr.org>
> <openehr-technical at lists.openehr.org>
> *Subject:* AOM 1.4 - Archetype.uid a UUID or OID?
>
>
>
>
>
> Bert picked up an anomaly in this PR
> <https://openehr.atlassian.net/browse/SPECPR-219> 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 <http://www.arssemantica.com>
> Consultant, ABD Team, Intermountain Healthcare
> <https://intermountainhealthcare.org/>
> Management Board, Specifications Program Lead, openEHR Foundation
> <http://www.openehr.org>
> Chartered IT Professional Fellow, BCS, British Computer Society
> <http://www.bcs.org/category/6044>
> Health IT blog <http://wolandscat.net/> | Culture blog
> <http://wolandsothercat.net/>
>
>
> _______________________________________________
> openEHR-technical mailing listopenEHR-technical at lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20170615/fcbde18e/attachment-0002.html>


More information about the openEHR-technical mailing list