openEHR artifact namespace identifiers
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
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 <http://www.openehr.org/releases/1.0.2/architecture/overview.pdf>, 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/20110408/d0679b1a/attachment.html>
openEHR artifact namespace identifiers
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: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110408/59018744/attachment.html>
openEHR artifact namespace identifiers
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
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
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
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
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: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110408/84948970/attachment.html>
openEHR artefact namespace identifiers
That we are very cautious about reference model version changes doesn't mean that any other organization does the same. Look at HL7 v2 & v3 for example ;) 2011/4/8 Thomas Beale : > On 07/04/2011 12:07, David Moner wrote: >> Dear Thomas, >> >> I agree with your general approach, but you miss two important things. >> >> 1. If openEHR spreads, you cannot expect that all implementations will >> be always up-to-date. That means that just upgrading the version >> number of the archetype will not be enough for a system to >> automatically differentiate the right version for the RM version they >> have implemented. If we just say "Ok, but since that information will >> be at the archetype header we don't need it at the identifier", we can >> also say the same for the concept, the RM class, the RM and the >> organisation. At the end, we will find that we don't need a semantic >> id, as Erik said, and that a UUID, OID or whatever is enough for >> identifying archetypes. > > I have no problem with a UUID or similar, but I don't think they are > that useful on their own, and they require more tooling support. If you > want to make inferences about what RM class, and what clinical concept > a given archetype is about, and you only have a UUID, you need to know > what / where to lookup. You also have to be able to have rules somewhere > to know when to assign a new UUID, when to treat two different UUIDs as > referring to archetypes that are actually revisions (i.e both compatible > with the same data), when to treat them as versions (not compatible with > the same data). We could potentially make the RM class name and concept > id just new fields in the description. The thing you lose (and maybe it > is worth losing) is that by creating a tuple of a particular subset of > meta-data items, viz: publishing organisation + RM issuer + RM class > name + archetype concept id + archetype version id, this happens to be > the unique key in archetype space (a new revision or new translation on > the other hand is obviously a new artefact, but it is not semantically a > new archetype). To achieve the equivalent with a UUID -based id system > means smarter software and either centralised id management (ISO oids) > or some distributed id system, possibly like DNS. At the moment we can > process the archetype id and directly know the relationship between two > archetypes. I think going down the UUID road will require more agreement > on tools and governance infrastructure. > >> >> 2. Archetypes are not only for openEHR. We must always have in mind >> that other reference models can be used with their own life-cycle that >> could be not so fine-grained as in openEHR. For example, we are now >> creating HL7 CDA R2 archetypes but during this year it is expected CDA >> R3 to be approved. How will we differentiate archetypes of R2 from >> archetypes of R3? Once again, R2 will still be used for many years and >> updating the version number isn't enough. > > I don't know what R3 looks like, but if it is a different reference > model, then the ids would be something like > > hl7-cda3-Entry.diagnosis.v1 > > If CDA r3 on the other hand is a clean extension / superset of CDAr2, > then the 'reference model' is really just 'cda', and there is no simple > relationship between particular archetypes and particular releases of > the CDA model. > > - thomas > > > ___ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
