On 07/12/2012 21:50, Bert Verhees wrote: > On 12/07/2012 06:01 PM, Thomas Beale wrote: >> The openEHR.org repository is not dictating anything to anyone, it's >> just providing a set of self-consistent archetypes that should be >> useful. Most of those archetypes will be from national programmes >> over time. Anyone can take part in the modelling. It seems to me to >> be a pretty free ecosystem. > > Hi Thomas, my problem is that archetypeID-clashes will occur if > archetypes with the same ID's but different from content exist. This > is because the Locatable is connected with an archetypeID according to > the specs, and which is easy to lose its uniqueness, because it has > obvious terms. > > The problem is in my opinion, and recognized by others, that this is > restrictive. > This problem is easy to resolve by giving them unique ID's.
which is what we expect to do with namespacing, based on reverse internet domains. Using reverse internet domain names means we don't have to invent a system for assigning the namespace ids, all we need to do is solve the technical problem of including namespace ids in the overall id. In the future, we should have 'identifying properties' that make up the multiaxial id, i.e. instead of the string openEHR-EHR-OBSERVATION.bp_measurement.v1 being a single property in the AOM ARCHETYPE class, it would be broken into pieces, and then this kind of id can be generated functionally. Other variants, including with the full version id can also be generated e.g. openEHR-EHR-OBSERVATION.bp_measurement.v1.3.16 (and in the future both of these will have namespaces). The only true 'id' field in that case will be the UID field. I think in the ADL representation of an archetype we would still use the multi-axial id at the top, because it is very convenient, but in XML and dADL, JSON, etc it would appear in pieces. And of course in AOM. Then it is just a question of tools using the different kind of ids - either the generated form, or the UID - to manage the archetypes. For example, CKM should use UIDs to track archetypes so that even the RM class could be changed (maybe someone decided it should be an ACTION instead of an OBSERVATION). And so on. We are not there yet, but those are the proposals I would have, and I have based most of the thinking on what others have said about improving the way the ids work (for example, the UPV guys have been asking for a long time to make the multi-part ids generated, and they are right, we are just slow in making it happen ;-) But I will get out a new version of the ADL 1.5 draft that includes these changes. Anyone is welcome to come up with a better idea in terms of namespacing of course - we just want something that works well. The only thing I see as really difficult to justify is getting embroiled in Oids. If we think Oids that are managed by other orgs need to be attached to openEHR artefacts, no problem, but we don't want to make it so that tools like CKM (or any equivalent) rely on Oids to work - that will just paralyse them. > > If the same archetypeID's are easy possible, than this will be > restrictive, because if an archetype is inside the eco-system, it is > difficult to write another archetype on the same concept. > It even can happen in a large eco-system (like a regional > health-eco-system which is in the Netherlands very common) that > someone writes an archetype, with an already existing ID. So the > current situation is restrictive and worse, it can easily come to > erroneous situations. assuming we have namespacing, I don't think it is restrictive, it is just a problem that the assignment of new ids, and the ability to search existing ids is not yet an online service. I would propose that it is a simple separate service that just performs those functions, and needs to exist for each domain (i.e. archetype namespace, e.g. nl.nictiz or whatever). > > It is also very hard to extend an ecosystem because, there can be more > archetypes active in the extension-area, which have the same ID. > So this is restrictive too. I believe this is a similar situation as > Koray Atalag experienced. > > The concept and other content-parameters can be properties of an > archetype, it is not necessary to put them in the archetypeID. > Compare with the WWW, every URL (ID) is unique, but title, keywords, > other parameters are properties of the document, which have nothing to > do with the URL (ID) of the document. This URL (ID) is nowadays more > and more a meaningless database-entity, sometimes even build from > different parts, all also with meaningless URL's (ID's). > So on the WWW it is possible to have more documents with the same > concept, and still clashes are not possible. As long as you know the > URL (ID) you can find your document. > Google, the largest database in the world, works this way. yep, see above > > Some time ago, I had a thread on this list, (or the technical list) > about the filename which is the same as the archetypeID. You said, > that this is not necessary, the filename can be anything. The ID is > what is inside the archetype. that's correct - I don't know of any tool that makes any assumptions about file names or directories for some years now. The AWB for example fast-parses the archetypes no matter where they are or what they are called and figures out the ids and inheritance structure. I don't believe any other tools make any assumptions about filename or directory. > This is already an improvement (although I don't know one > archetype-editor which supports another filename then the ID). I think you will find that although the editor tools by default save the archetype in a file that is the same as its multi-axial id, this is not needed. You should be able to create a file called 'blue_cheese.adl' and the AE will read and save to that. > The next improvement should be that a Locatable should be able to > point to an unique ID, and that ID, cannot be according to the specs > of the archetypeID, which says that the concept and other things > should be part of the ID and causes obvious terms to be used. some of this is already in the last two proposal docs here <http://www.openehr.org/svn/specification/TRUNK/publishing/roadmap.html> (note these are not all up to date, so ignore the bits that are obviously wrong). But I don't think meaningful multi-axial ids are a problem- like I said before, an id is just a string of characters. If it is made into a mnemonic, it is 100x more useful to software developers. It is only in perfect systems that the underlying nature of ids doesn't matter. > > Regarding to interoperability, I think querying will never be possible > in a same way. That is an utopia. (The better is the enemy of the good > (is a Dutch saying)) > Having content fixed to the archetypeID, because of interoperability > is about the same as forcing products to have the same > database-structure. Then you can exchange SQL (instead of AQL). > I don't think that is wise to aim that goal, because it will never > happen. actually it's already happening in production in at least 3 countries. We don't make any assumption at all about the physical structure of the DB, about SQL converted form of AQL, or even that the converted form of AQL will include SQL at all - in some modern databases, SQL is gone. Physical database structures are way of strangling interoperability actually, because you need total freedom to choose what you want and also change it, to manage local requirements of scalability and performance. Delinking this from AQL is absolutely fundamental to success, and particular, of enabling a decision support industry to flourish. As i say, this is already routine today, so if you are having problems with AQL, we should discuss it - they have already been solved in other implementations. > > And on the other hand, if you have all archetypes with a unique ID, > you can safely inter-operate, because, then you are sure, it is the > same archetype to which the Locatable points. Ithink this is a different problem. I would expect to support the use of both UIDs and/or multi-axial ids in data, depending on the scope of sharing and so on. Converting between multi-axial and UID form will be easy in the future. In some systems, it might be the case that only UIDs are used, but that implies that noone ever needs to look at the data itself, or at EHR Extracts, or to visualise data at some debugging level. I have never seen any system like that ever. So in summary, I believe that what is needed is a service for helpinng to assign, check, compare ids etc, as well as namespacing, and UIDs, and interconvertability between these. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20121208/6a7008d1/attachment.html>
