openEHR artifact namespace identifiers

[Heath Frankel]

Source file class in a program language have names and in the cases of COM
they have an ID such as a GUID.  The issue here is related to the later, not
the former.

 

More than happy with a GUID, in fact our knowledge resource repository does
exactly what David Moner proposed, it assigns a resource ID (GUID) and
maintains a version tree ID.

 

Really I don't see the difference between a GUID and OID, as you say
elsewhere, they are just strings.  It is just the process used to create the
string that differs and when we start introducing governance with publishing
organisations, having an OID root for the publishing organisation and an
extension for each artefact generated by a repository system aligns so
nicely with the OID approach I can't understand why we so easily blow this
option off.  

 

Once we have a reliable UID of some kind we can generate URIs.  The
alternative of generating a composite UID from meta data sounds complicated,
contentious, unreliable and frankly worse than the same kind of issues you
have with OIDs.

 

Heath 

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale
Sent: Friday, 29 April 2011 2:16 AM
To: openehr-technical at openehr.org
Subject: Re: openEHR artifact namespace identifiers

 

On 08/04/2011 01:49, Heath Frankel wrote: 

Thomas,

Your proposed changes to the archetype Identifiers and governance actually
aligns with the same management and inferencing requirements as OIDs, the
only benefit left is the readability, but even that is becoming hard to do
with the additional namespaces and delimiters.  In addition, having
meaningful IDs and deriving meaning from IDs is counter to what good
practice in terminology identifier management.


for atomic concepts a la SNOMED, meaningless identifiers make sense; for
complex artefacts like programming language source files - of which
archetypes are an example, they don't really - they just obscures meaning
from developers. Meaningless identifiers of the Guid variety make sense for
deployed versions of these artefacts - i.e. generated template OPTs,
assemblies etc. Where identification really matters is a) in data and b) in
deployed software artefacts that were generated from templates & archetypes.

The future may well be to do as David Moner (I think, or maybe Diego, can't
remember now) said - to create archetype meta-data attributes to carry the
pieces of the id, and generate the strings that we currently use as ids when
and as needed. Attaching Guids to source archetypes can also be done
obviously, but I think for source artefacts, Oids provide little gain and a
lot of pain. 

- thomas




 

 

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110429/e86f9e97/attachment.html>

openEHR artifact namespace identifiers

[Thomas Beale]

On 08/04/2011 01:49, Heath Frankel wrote:
>
> Thomas,
>
> Your proposed changes to the archetype Identifiers and governance 
> actually aligns with the same management and inferencing requirements 
> as OIDs, the only benefit left is the readability, but even that is 
> becoming hard to do with the additional namespaces and delimiters.  In 
> addition, having meaningful IDs and deriving meaning from IDs is 
> counter to what good practice in terminology identifier management.
>

for atomic concepts a la SNOMED, meaningless identifiers make sense; for 
complex artefacts like programming language source files - of which 
archetypes are an example, they don't really - they just obscures 
meaning from developers. Meaningless identifiers of the Guid variety 
make sense for deployed versions of these artefacts - i.e. generated 
template OPTs, assemblies etc. Where identification really matters is a) 
in data and b) in deployed software artefacts that were generated from 
templates & archetypes.

The future may well be to do as David Moner (I think, or maybe Diego, 
can't remember now) said - to create archetype meta-data attributes to 
carry the pieces of the id, and generate the strings that we currently 
use as ids when and as needed. Attaching Guids to source archetypes can 
also be done obviously, but I think for source artefacts, Oids provide 
little gain and a lot of pain.

- thomas

*
*
-- next part --
An HTML attachment was scrubbed...
URL: 

openEHR artifact namespace identifiers

[Heath Frankel]

Exactly, an OID can be used as an URI scheme.

 

Not sure how much simpler you can get then assigning a string of numbers and
dots to a system that issues an accession number and appends it the assigned
string, CKM already does the first two steps of this.Anyone that can
implement a openEHR -based health record service or an ADL parser should be
able to cope with this.

 

Anyway, I am happy with a URI as long as we leave open the scheme choice in
ADL/AOM and adopt a limited set of standard schemes for openEHR archetypes
rather than invent a new one.  However, it does mean a substantial change to
the AOM compared with using the existing UID attribute of type
HIER_OBJECT_ID.  A URI can always be constructed from this as is done with
EHR URIs.

 

Heath

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale
Sent: Friday, 8 April 2011 11:50 PM
To: openehr-technical at openehr.org
Subject: Re: openEHR artifact namespace identifiers

 

On 08/04/2011 14:28, pablo pazos wrote: 

Hi Heath,

Just analysing OIDs vs. URIs:


Usage:
OIDs are in use in health informatics and other areas.
URIs are in use everywhere in form of URLs

Procesing:
OIDs lack internal processing
URIs can be processed

Compatibility with actual identifiers:

Inside archetypes, each node can be identified by a path, so if we use URIs
to identify an archetype, just appending the path to the URI we get a valid
URI to identify a node inside the archetyp.


I go with URIs.


if you have a look at the Architecture
<http://www.openehr.org/releases/1.0.2/architecture/overview.pdf>  Overview
spec, this is documented in some detail (more is needed... next release ;-).
When Tony Shannon and I met a couple of years ago with Tim Berners-Lee, this
was almost the only thing he found significant - that we could point to any
knowledge model node or data instance node with a proper URI. Of course you
can stick an Oid inside a URI, but I am still very unconvinced about Oids. I
don't like making things complex when they can be simple.

- thomas beale

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110411/4f7f6d9f/attachment.html>

openEHR artifact namespace identifiers

[pablo pazos]

Yep, EHR URIs for global operations like referencing a knowledge artifact 
internal node or in AQL/EQL queries referencing a set of RM nodes are good 
enough for me.

I think our team will start working on querying and reporting in a couple of 
months when we have a more robust implementation of our openEHR-based tool 
(http://code.google.com/p/open-ehr-gen-framework/). Then we'll see if the URI 
approach is enough :D

-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos



Date: Fri, 8 Apr 2011 15:19:47 +0100
From: thomas.be...@oceaninformatics.com
To: openehr-technical at openehr.org
Subject: Re: openEHR artifact namespace identifiers



  



  
  
On 08/04/2011 14:28, pablo pazos wrote:

  
  Hi Heath,

  

  Just analysing OIDs vs. URIs:

  

  

  Usage:

  OIDs are in use in health informatics and other areas.

  URIs are in use everywhere in form of URLs

  

  Procesing:

  OIDs lack internal processing

  URIs can be processed

  

  Compatibility with actual identifiers:

  

  Inside archetypes, each node can be identified by a path, so if we
  use URIs to identify an archetype, just appending the path to the
  URI we get a valid URI to identify a node inside the archetyp.

  

  

  I go with URIs.




if you have a look at the Architecture
  Overview spec, this is documented in some detail (more is
needed... next release ;-). When Tony Shannon and I met a couple of
years ago with Tim Berners-Lee, this was almost the only thing he
found significant - that we could point to any knowledge model node
or data instance node with a proper URI. Of course you can stick an
Oid inside a URI, but I am still very unconvinced about Oids. I
don't like making things complex when they can be simple.



- thomas beale

  


___
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical 
  
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110409/caafc24e/attachment.html>

openEHR artifact namespace identifiers

[Diego Boscá]

Hello

I have been working some time in DCM/archetype metadata. Dublin Core
is suitable for that, however, there is an ISO norm (ISO 15699. Health
informatics. Clinical knowledge resources. Metadata ) which is an
extension of Dublin Core for Health informatics and it's even more
suitable. They have even defined 'archetype' as one of the valid
document types!. I would be interested in helping on metadata topic.
When do we start? ;)


2011/4/8 Erik Sundvall :
> Hi!
>
> While we are discussing metadata and identifiers... Shouldn't the
> metadata/description part of an archetype/template be based on Dublin
> Core ( http://en.wikipedia.org/wiki/Dublin_Core ) instead of an
> openEHR specific approach? That might make librarians, search engines
> and other existing artifact storage/searc software feel more at home
> :-) Using Dublin Core does not take away the requirement of having
> identifiers though, since something has to go into the Dublin Core
> identifier field. There are several levels of Dublin Core and the ones
> with good structural requirements on the values may be useful.
>
> The idea of using Dublin Core for archetype/template-like-artifacts I
> got from Tim Cook et.al. in MLHIM.
>
> Best regards,
> Erik Sundvall
> erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ ?Tel: +46-13-286733
>
> On Fri, Apr 8, 2011 at 10:57, Thomas Beale
>  wrote:
>> I will have a play around with some new meta-data additions to archetypes
>> and put them on this list in the next day or so. Let's then think about what
>> is needed in terms of different kinds of 'identifiers', both assigned and
>> generated.
>>
>> - thomas
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>

openEHR artifact namespace identifiers

[Thomas Beale]

On 08/04/2011 14:28, pablo pazos wrote:
> Hi Heath,
>
> Just analysing OIDs vs. URIs:
>
>
> Usage:
> OIDs are in use in health informatics and other areas.
> URIs are in use everywhere in form of URLs
>
> Procesing:
> OIDs lack internal processing
> URIs can be processed
>
> Compatibility with actual identifiers:
>
> Inside archetypes, each node can be identified by a path, so if we use 
> URIs to identify an archetype, just appending the path to the URI we 
> get a valid URI to identify a node inside the archetyp.
>
>
> I go with URIs.*
> *

if you have a look at the Architecture Overview spec 
, this 
is documented in some detail (more is needed... next release ;-). When 
Tony Shannon and I met a couple of years ago with Tim Berners-Lee, this 
was almost the only thing he found significant - that we could point to 
any knowledge model node or data instance node with a proper URI. Of 
course you can stick an Oid inside a URI, but I am still very 
unconvinced about Oids. I don't like making things complex when they can 
be simple.

- thomas beale
-- next part --
An HTML attachment was scrubbed...
URL: 

openEHR artifact namespace identifiers

[Ian McNicoll]

Hi Diego,

Very interesting. Is any of the documentation available without paying a
small fortune?

Ian

Dr Ian McNicoll
office +44 (0)1536 414994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com

Clinical analyst, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care  www.phcsg.org



On 8 April 2011 12:20, Diego Bosc?  wrote:

> Hello
>
> I have been working some time in DCM/archetype metadata. Dublin Core
> is suitable for that, however, there is an ISO norm (ISO 15699. Health
> informatics. Clinical knowledge resources. Metadata ) which is an
> extension of Dublin Core for Health informatics and it's even more
> suitable. They have even defined 'archetype' as one of the valid
> document types!. I would be interested in helping on metadata topic.
> When do we start? ;)
>
>
> 2011/4/8 Erik Sundvall :
> > Hi!
> >
> > While we are discussing metadata and identifiers... Shouldn't the
> > metadata/description part of an archetype/template be based on Dublin
> > Core ( http://en.wikipedia.org/wiki/Dublin_Core ) instead of an
> > openEHR specific approach? That might make librarians, search engines
> > and other existing artifact storage/searc software feel more at home
> > :-) Using Dublin Core does not take away the requirement of having
> > identifiers though, since something has to go into the Dublin Core
> > identifier field. There are several levels of Dublin Core and the ones
> > with good structural requirements on the values may be useful.
> >
> > The idea of using Dublin Core for archetype/template-like-artifacts I
> > got from Tim Cook et.al. in MLHIM.
> >
> > Best regards,
> > Erik Sundvall
> > erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
> >
> > On Fri, Apr 8, 2011 at 10:57, Thomas Beale
> >  wrote:
> >> I will have a play around with some new meta-data additions to
> archetypes
> >> and put them on this list in the next day or so. Let's then think about
> what
> >> is needed in terms of different kinds of 'identifiers', both assigned
> and
> >> generated.
> >>
> >> - thomas
> > ___
> > openEHR-technical mailing list
> > openEHR-technical at openehr.org
> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
> >
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
-- next part --
An HTML attachment was scrubbed...
URL: 

openEHR artifact namespace identifiers

[Erik Sundvall]

Hi!

While we are discussing metadata and identifiers... Shouldn't the
metadata/description part of an archetype/template be based on Dublin
Core ( http://en.wikipedia.org/wiki/Dublin_Core ) instead of an
openEHR specific approach? That might make librarians, search engines
and other existing artifact storage/searc software feel more at home
:-) Using Dublin Core does not take away the requirement of having
identifiers though, since something has to go into the Dublin Core
identifier field. There are several levels of Dublin Core and the ones
with good structural requirements on the values may be useful.

The idea of using Dublin Core for archetype/template-like-artifacts I
got from Tim Cook et.al. in MLHIM.

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733

On Fri, Apr 8, 2011 at 10:57, Thomas Beale
 wrote:
> I will have a play around with some new meta-data additions to archetypes
> and put them on this list in the next day or so. Let's then think about what
> is needed in terms of different kinds of 'identifiers', both assigned and
> generated.
>
> - thomas

openEHR artifact namespace identifiers

[pablo pazos]

Hi Heath,

Just analysing OIDs vs. URIs:


Usage:
OIDs are in use in health informatics and other areas.
URIs are in use everywhere in form of URLs

Procesing:
OIDs lack internal processing
URIs can be processed

Compatibility with actual identifiers:

Inside archetypes, each node can be identified by a path, so if we use URIs to 
identify an archetype, just appending the path to the URI we get a valid URI to 
identify a node inside the archetyp.


I go with URIs.

-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos



> From: heath.frankel at oceaninformatics.com
> To: openehr-technical at openehr.org
> Subject: RE: openEHR artifact namespace identifiers
> Date: Fri, 8 Apr 2011 10:10:09 +0930
> 
> Hi Erik,
> I was suggesting that we enforce OIDs, in fact my intent was similar to
> yours, to open up the choice of what is used and not enforce the specially
> designed ID scheme currently used that requires upgrading to support
> namespacing making it have the same issues as the standard UID schemes.
> 
> I like the suggestion of URIs, although I also agree with Tom's later
> comment that within openEHR implementations we should try to limit the
> options of the URI schemes used.  However, ADL and AOM shouldn't be
> restricted to this same set, to allow other implementation profiles for
> other reference models to make their own choices.
> 
> Heath
> 
> > -Original Message-
> > From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
> > bounces at openehr.org] On Behalf Of Erik Sundvall
> > Sent: Wednesday, 6 April 2011 9:04 PM
> > To: For openEHR technical discussions
> > Subject: Re: openEHR artefact namespace identifiers
> > 
> > Hi!
> > 
> > On Tue, Apr 5, 2011 at 17:51, Ian McNicoll
> >  wrote:
> > > artefact identification proposals
> > > at
> > http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/
> > am/knowledge_id_system.pdf
> > ...
> > > se.skl.epj::openEHR-EHR-EVALUATION.problem.v1
> > 
> > ...Then discussions regarding UUIDs, OIDs etc followed in several
> > messages
> > 
> > Is not the simplest thing to just use URIs [
> > http://en.wikipedia.org/wiki/Uniform_Resource_Identifier ], or even
> > better allowing non-latin characters by using IRIs [
> > http://tools.ietf.org/html/rfc3987 ]?
> > 
> > Then organizations can choose if they want to base IDs on
> > domain-names, UUIDs, OIDs or whatever that fits in a URI (which might
> > be a URN, see list at http://www.iana.org/assignments/urn-namespaces/
> > ). Some archetype authoring organizations may like names with
> > semantics, some may not, so why enforce any of the views.
> > 
> > Now since metadata is going to be well defined inside the file, the
> > need for semantics in identifiers or file names is gone so the main
> > thing left is that we want a _unique_ string. URIs are supposed to be
> > unique.
> > 
> > Some URI-examples:
> > urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
> > urn:oid:1.3.6.1.2.1.27
> > urn:lsid:chemacx.cambridgesoft.com:ACX:CAS967582:1
> > http://id.skl.se/openEHR/EHR-EVALUATION.problem.v1
> > http://schema.openehr.org/openEHR/EHR/EVALUATION/problem/v3
> > urn:nbn:se:liu:diva-38012
> > 
> > I see no point in enforcing usage of OIDs as suggested in some
> > responses.
> > 
> > The idea of not changing the ID if/when transferring responsibility of
> > an archetype between authorities sounds very reasonable if the content
> > is unchanged.
> > 
> > When I visited Brazil, I noticed that the MLHIM project's development
> > version was using UUIDs for the artifacts (CCDs) that correspond to
> > what is called archetypes in openEHR.
> > 
> > Best regards,
> > Erik Sundvall
> > erik.sundvall at liu.se http://www.imt.liu.se/~erisu/  Tel: +46-13-286733
> > 
> > ___
> > openEHR-technical mailing list
> > openEHR-technical at openehr.org
> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
  
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110408/abd75895/attachment.html>

openEHR artifact namespace identifiers

[Heath Frankel]

Thomas,

Your proposed changes to the archetype Identifiers and governance actually
aligns with the same management and inferencing requirements as OIDs, the
only benefit left is the readability, but even that is becoming hard to do
with the additional namespaces and delimiters.  In addition, having
meaningful IDs and deriving meaning from IDs is counter to what good
practice in terminology identifier management.

 

If we choose a GUID (or any other standard UID) for the archetype ID, then I
see no reason why the VersionedObjectId scheme cannot be used for managing
versions of the archetype as long as it is properly administered.

 

Heath

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale
Sent: Friday, 8 April 2011 1:11 AM
To: openehr-technical at openehr.org
Subject: Re: openEHR artifact namespace identifiers

 


Oids probably are the one kind of id I would not propose for archetypes; the
multi-axial id in current use + the proposed namespace id is equivalent to
an Oid, just with some more constrained rules on what is on the axes, and
readable values. The need for a highly managed id assignment system plus
loss of readability and inferencing capability seems like a backward step to
me. UUIDs seem a more obvious step. Note that UUIDs don't cope properly with
namespaces nor versions, and there are already id systems that assign a UUID
to the 'artefact' and a second UUID to the version, so that it can be
inferred if two concrete artefact instances are really just versions of the
same thing. Note that a UUID is massive overkill for a version id of
something! But this just shows that simple assignment of UUIDs or Oids is no
panacea

- thomas

On 06/04/2011 01:41, Heath Frankel wrote: 

 
 
 
 
Personally, I would like to propose the use of OIDs for controlled artefacts
as it is an ISO standard and already used in health informatics for
identifying such knowledge artefacts such as terminologies.  I know OIDs are
not liked due their length, unreadability and managed allocation, but to me
it is a natural fit for this kind of artefact ID.  Each publishing
organisation can get an OID and manage the items that they produce, this can
be done using a content management system automatically as is done by CKM.
And to be honest, the new namespaced ID scheme is likely to be longer and
requires management, and barely legible once we include the namespace and
additional delimiters.
 
 
 

 

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110408/13a45640/attachment.html>

openEHR artifact namespace identifiers

[Heath Frankel]

Hi Erik,
I was suggesting that we enforce OIDs, in fact my intent was similar to
yours, to open up the choice of what is used and not enforce the specially
designed ID scheme currently used that requires upgrading to support
namespacing making it have the same issues as the standard UID schemes.

I like the suggestion of URIs, although I also agree with Tom's later
comment that within openEHR implementations we should try to limit the
options of the URI schemes used.  However, ADL and AOM shouldn't be
restricted to this same set, to allow other implementation profiles for
other reference models to make their own choices.

Heath

> -Original Message-
> From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
> bounces at openehr.org] On Behalf Of Erik Sundvall
> Sent: Wednesday, 6 April 2011 9:04 PM
> To: For openEHR technical discussions
> Subject: Re: openEHR artefact namespace identifiers
> 
> Hi!
> 
> On Tue, Apr 5, 2011 at 17:51, Ian McNicoll
>  wrote:
> > artefact identification proposals
> > at
> http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/
> am/knowledge_id_system.pdf
> ...
> > se.skl.epj::openEHR-EHR-EVALUATION.problem.v1
> 
> ...Then discussions regarding UUIDs, OIDs etc followed in several
> messages
> 
> Is not the simplest thing to just use URIs [
> http://en.wikipedia.org/wiki/Uniform_Resource_Identifier ], or even
> better allowing non-latin characters by using IRIs [
> http://tools.ietf.org/html/rfc3987 ]?
> 
> Then organizations can choose if they want to base IDs on
> domain-names, UUIDs, OIDs or whatever that fits in a URI (which might
> be a URN, see list at http://www.iana.org/assignments/urn-namespaces/
> ). Some archetype authoring organizations may like names with
> semantics, some may not, so why enforce any of the views.
> 
> Now since metadata is going to be well defined inside the file, the
> need for semantics in identifiers or file names is gone so the main
> thing left is that we want a _unique_ string. URIs are supposed to be
> unique.
> 
> Some URI-examples:
> urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
> urn:oid:1.3.6.1.2.1.27
> urn:lsid:chemacx.cambridgesoft.com:ACX:CAS967582:1
> http://id.skl.se/openEHR/EHR-EVALUATION.problem.v1
> http://schema.openehr.org/openEHR/EHR/EVALUATION/problem/v3
> urn:nbn:se:liu:diva-38012
> 
> I see no point in enforcing usage of OIDs as suggested in some
> responses.
> 
> The idea of not changing the ID if/when transferring responsibility of
> an archetype between authorities sounds very reasonable if the content
> is unchanged.
> 
> When I visited Brazil, I noticed that the MLHIM project's development
> version was using UUIDs for the artifacts (CCDs) that correspond to
> what is called archetypes in openEHR.
> 
> Best regards,
> Erik Sundvall
> erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

openEHR artifact namespace identifiers

[Thomas Beale]

I will have a play around with some new meta-data additions to 
archetypes and put them on this list in the next day or so. Let's then 
think about what is needed in terms of different kinds of 'identifiers', 
both assigned and generated.

- thomas

On 08/04/2011 01:40, Heath Frankel wrote:
> Hi Erik,
> I was suggesting that we enforce OIDs, in fact my intent was similar to
> yours, to open up the choice of what is used and not enforce the specially
> designed ID scheme currently used that requires upgrading to support
> namespacing making it have the same issues as the standard UID schemes.
>
> I like the suggestion of URIs, although I also agree with Tom's later
> comment that within openEHR implementations we should try to limit the
> options of the URI schemes used.  However, ADL and AOM shouldn't be
> restricted to this same set, to allow other implementation profiles for
> other reference models to make their own choices.
>
> Heath
>
*

*
-- next part --
An HTML attachment was scrubbed...
URL: 

openEHR artifact namespace identifiers

[Thomas Beale]

Oids probably are the one kind of id I would not propose for archetypes; 
the multi-axial id in current use + the proposed namespace id is 
equivalent to an Oid, just with some more constrained rules on what is 
on the axes, and readable values. The need for a highly managed id 
assignment system plus loss of readability and inferencing capability 
seems like a backward step to me. UUIDs seem a more obvious step. Note 
that UUIDs don't cope properly with namespaces nor versions, and there 
are already id systems that assign a UUID to the 'artefact' and a second 
UUID to the version, so that it can be inferred if two concrete artefact 
instances are really just versions of the same thing. Note that a UUID 
is massive overkill for a version id of something! But this just shows 
that simple assignment of UUIDs or Oids is no panacea

- thomas

On 06/04/2011 01:41, Heath Frankel wrote:
>
>
>
> Personally, I would like to propose the use of OIDs for controlled artefacts
> as it is an ISO standard and already used in health informatics for
> identifying such knowledge artefacts such as terminologies.  I know OIDs are
> not liked due their length, unreadability and managed allocation, but to me
> it is a natural fit for this kind of artefact ID.  Each publishing
> organisation can get an OID and manage the items that they produce, this can
> be done using a content management system automatically as is done by CKM.
> And to be honest, the new namespaced ID scheme is likely to be longer and
> requires management, and barely legible once we include the namespace and
> additional delimiters.
>
>
>
*
*
-- next part --
An HTML attachment was scrubbed...
URL: 

openEHR artifact namespace identifiers

[Heath Frankel]

Hi Ian,

This sounds more sensible to me, I was always worried about the change in
identifier when it got escalated to a higher PO.  

 

I wonder if we can get a summary of the rest of the SNOMED namespacing
scheme so that we can see if it is usable in its entirety.

 

I have always been a supporter of the readable identifiers but I am now
starting to see their limitations in reality.  I think we should seriously
consider an existing standard unique identifier scheme (UUID/GUID or OID)
rather than trying to invent a new one.  I understand that there are issues
with using these existing schemes but I can't say that I am seeing that
namespaced archetype ID helps these issues, the only benefit is some
readability but this is countered by clashes in the wild and the governance
overhead to get it controlled.

 

The Archetype class has a UID attribute, I think we need to start using this
as an object identifier, after all an archetype is an object.  In the
artefact maintenance area, we can start using the ObjectVersionId scheme to
manage the PO (creating system) and revisions.  Alternatively we can use a
single OID to represent the PO with a root and the artefact ID as an
extension.

 

The issue with this suggested change is that we will have to work out how we
make this work with the existing archetype IDs used in data or transition
away from using existing archetype IDs.  In the short term I think we need
to concentrate on template identifiers as the problem is worse with many
more organisations producing templates that overlap and less being reused
between organisations.  Therefore, we can try a standard UID approach for
templates without the legacy and once we have this sorted we can look at
integrating back into archetypes.  

 

Personally, I would like to propose the use of OIDs for controlled artefacts
as it is an ISO standard and already used in health informatics for
identifying such knowledge artefacts such as terminologies.  I know OIDs are
not liked due their length, unreadability and managed allocation, but to me
it is a natural fit for this kind of artefact ID.  Each publishing
organisation can get an OID and manage the items that they produce, this can
be done using a content management system automatically as is done by CKM.
And to be honest, the new namespaced ID scheme is likely to be longer and
requires management, and barely legible once we include the namespace and
additional delimiters.

 

We can also have a fallback to GUID for organisations that don't have an OID
and a knowledge management system to maintain an OID.  This would be the
default when a new template is created in a template editor but can be
upgraded to an OID once submitted to a knowledge management system.

 

Regards

 

Heath 

 

From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Ian McNicoll
Sent: Wednesday, 6 April 2011 1:21 AM
To: For openEHR technical discussions
Subject: openEHR artefact namespace identifiers

 

Hi,

 

About a year ago Thomas published a draft of some detailed artefact
identification proposals at
http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/kn
owledge_id_system.pdf

 

to help with the rapidly approaching scenario of having to cope with
similarly named artefacts being published by different authorities. We are
starting to see this scenario emerging  in real-world projects and whilst
potential collisions can be managed informally for now, we will need a
formal mechanism before long.

 

I would like to raise one aspect which I think might need re-thought on the
basis of recent IHTSDO proposal for SNOMED covering the same ground.

 

In the pdf Thomas says

 

" When an archetype is moved from its original PO (e.g. a local health
authority, or a specialist peak

body) to a more central authoring domain (e.g. a national library,
openEHR.org) its namespace will be

changed to the new domain, as part of the review and handover process. The
archetype's semantic

definition may or may not change. In order for tools to know that an
archetype was not created new

locally, but was moved from another PO, an explicit reference statement can
be made in the archetype

in the description section of an archetype as follows:"

 

id_history = <"se.skl.epj::openEHR-EHR-EVALUATION.problem.v1"

 

The IHTSDO proposals cover  the same scenario i.e a SNOMED code originally
authored in one namespace subsequently being managed in a new namespace. A
good example might be a SNOMED term which is originally used t a national
level but is then adopted internationally. They suggest that the term keeps
its original authored namespace, and it is the namespace of the managing
entity that changes, arguing that this is much less disruptive to systems
that are using the term concerned.

 

I think we should consider adopting the same approach for openEHR
archetypes, as otherwise the formal identifier of an archetype will change
if a locally de