Hi Ian, I agree with the light-touch approach, I was also thinking about it. I have some thoughts for a solution:
Because a dataset has an archetypeID to indicate to which archetype-content it must be able to validate. The archetype-content should be digitally signed, this makes it safe to exchange datasets, because both parties can be sure they are using the same archetype content and not only the same archetypeID. This digitally signature should be a property of every dataset which is exchanged, so it should be a required property of the Locatable-class (if the archetypeID in this class is used). The validation-routines must be able to calculate the signature, so the parser-routines also needs modification. I don't know (cannot oversee) if this must be part of the ADL-grammar. The digitally signature should be added with the the archetype content itself, but it should not be a part of it. I think this is the easiest way to maintain the digital signatures. Than a central registry may not be necessary, because parties are able to check their archetypes against the digital signature, and see if the archetype has been changed since it is in possession of that party. Solved will be that when an error occurs, it will be able to proof who is responsible for using this erroneous situation. Possible it is enough to sign the definition-character-contents, excluding comments, trailing/leading spaces and new-lines. To do so, there will be only one end of line, that is after the closing curly brace of the definition. I don't know if the ontology section should be signed with the definition-section. Maybe it should be signed separately for each language. To make it easy for developers, they could during the developing process work with dummy-signatures, which need to be defined. The production-kernel, however, should never allow dummy signatures in datasets. It this is done, we can allow any archetypeID-structure, because it is not the archetypeID internally which should be leading, but the archetype-content. As Thomas wrote yesterday, the concept is not important, we must discuss if it still should be inside the archetype. But other things must sure be a part of the archetype (but not the archetype ID, that is up to the designer). These are the Reference Model (and version), and keywords. If we agree on the concept is important also, this should be a property of the archetype, but this needs discussion. I always used the concept to have a quick impression about what the archetype is about, but maybe I must change this habit. I don't think that the RM-class is needed in the archetype properties, because, that is where the definition starts with. ---- Doing all this we have advantages that no central registry is needed (light-touch?), that it is possible to construct an archetypeID in any way an organization prefers. Thanks for your attention, I hope it contributes to the thinking about a solution. Bert On 12/14/2012 10:06 AM, Ian McNicoll wrote: > I have just re-read Erik's PS in his email and I think we are > basically in agreement. I would prefer a to see a system where each > namespace is essentially self-governing with respect to unique > identification and versioning (which is an even bigger problem). If > they want to play in the wider community "The openEHR Knowledge > Federation" they have to abide by a stricter set of rules, and of > course, can be kicked out if they do not manage their identification > and versioning governance safely. > > We need to make this safe but we also need to keep it light-touch and > agile and avoid a cumbersome top-down mechanism > > Ian > > > > > On 14 December 2012 08:48, Ian McNicoll > <Ian.McNicoll at oceaninformatics.com> wrote: >> Hi Bert, >> >> Nice summary. >> >> I think we are all agreed on your first point, and that this now needs >> urgent attention. I have been speaking to THomas about how to add >> some sort of namespacing and more detailed versioning metadata to ADL >> 1.4 archetypes to let us address some of these type of issues in the >> openEHR CKM in advance of the formal ADL1.5 specifications. >> >> I think some form of namespacing whether uri, oid or SNOMED type >> identifier is essential. Ultimately whichever of these is adopted, the >> owner of the namespace is responsible for preventing identifier >> clashes within their namespace. It will always be possible for people >> to subvert the system by accident or design unless we add-in digital >> signing but that introduces its own burden of compliance, particularly >> in the authoring space where archetype creation and development needs >> to be very agile. >> >> Option 3 clearly has merits but I am anxious that trying to enforce a >> top-down registry for every potential developer will be hard and >> complex to maintain. One idea I have toyed with is the concept of an >> openEHR Knowledge Federation, Basically a very light touch registry of >> 'official' openEHR namespaces and maintained list of URLs to the >> actual repositories concerned. Essentially a sort of DNS. This would >> need a little bit of funding and governance. It would need clear rules >> of engagement and perhaps digital singing might be a requirement for >> Federation membership. However I would not make Federation membership >> compulsory. If people just want to tinker in the space they should be >> able to develop non-namespaced archetypes. >> >> In summary, I think option 3 is the gold-standard' and that we should >> probably aim for some sort of central namespace registry but I think >> it needs to be light touch, easily governable and not mandatory. It is >> up to consumers to decide if they trust non-Federation namespaced >> archetypes. >> >> >> Ian >> >> On 14 December 2012 07:49, Bert Verhees <bert.verhees at rosa.nl> wrote: >>> Let me summarize my emails from last weeks. >>> >>> In my opinion there are more choices to proceed: >>> >>> 1- The currently situation which has no namespace and no unique >>> archetypeIds. You can never trust an archetypeID. You always need to >>> validate a dataset, and if it does not validate against the archetype with >>> that Id in your system, the received dataset is useless. No >>> interoperability. For a message-standard this is fatal. There is quite some >>> urgency to repair this. >>> >>> Which brings us to the following solutions, maybe there are more solutions, >>> but these come to my mind. >>> >>> 2- Working with namespaces which brings the responsibily of the system >>> being well maintained and trustworthy to the namespace-owner. >>> >>> 3- Making it safe by design, so that even bad namespace-owners cannot break >>> the system. To do this, you need a central registry outside the eco-system, >>> and some way of digitally signing. >>> >>> Solution 2 can also work with digitally signing, which makes their >>> archetypes also trustworthy but without a central registration, there can >>> be a problem. >>> You will need the digitally signature to be in the dataset, to compare it >>> with the signature of the archetype which is in your system. >>> What do you do when it does not fit? Throw away the dataset and start a >>> discussion with the organization which sent it? And as long as this >>> discussion is not finish, hold up communications with that organization? >>> >>> This brings us to situation 3, which handels all occuring situations best. >>> >>> Regards >>> Bert Verhees. >>> _______________________________________________ >>> openEHR-clinical mailing list >>> openEHR-clinical at lists.openehr.org >>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >> >> >> -- >> Dr Ian McNicoll >> office +44 (0)1536 414 994 >> fax +44 (0)1536 516317 >> mobile +44 (0)775 209 7859 >> skype ianmcnicoll >> ian.mcnicoll at oceaninformatics.com >> >> Clinical Modelling Consultant, Ocean Informatics, UK >> Director openEHR Foundation www.openehr.org/knowledge >> Honorary Senior Research Associate, CHIME, UCL >> SCIMP Working Group, NHS Scotland >> BCS Primary Health Care www.phcsg.org > >
