On 08/12/2012 11:29, Bert Verhees wrote: > Hi Thomas, > > Using namespaces is a better idea then the current situation, I agree > with that, but it is not the perfect solution, as I explained several > times why.
I looked back through the thread - maybe I am just not seeing your explanation - but anyway, is it because you think there can be URI clashes? We are only talking about having a controlled id space within a namespace where the latter is based on internet domain - this is a pretty good guarantee that the organisation has been identified. So then it is just a question of managing the multi-axial id within that space, which should be easy (although we don't do it properly today). > > >> 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. > > That is not my problem. You can put as much properties as you think is > useful in an archetype. You can name the filename as you want (we, in > our ecosystem, don't use files to store archetypes) I'm not clear why you are talking about file names - they are not important in any tools using archetypes, to my knowledge. CKM doesn't use files at all. > > My problem is that the OpenEHR datasets depend on archetypes and they > express this dependency by the property Archetype-ID in the > Locatable-class. yes, that's the current spec. As I said elsewhere, there is a proposal (for some years now) to improve this, and to enable the use of the full multi-axial id (generated) and also Uids or Oids or whatever. So I don't think that in the future, there will be any problem. You will of course have difficulty to see what the archetypes are when inspecting data, so that's the downside. > If errors (like clashes) occur in this relationship, even if there is > no error but you have reasons to doubt, the datasets become unusable. > > The part I want to change is: to have in the specs to give the > Locatable a unique relationship to its connected archetype, and > resolving this by a UID (UUID, GUID, whatever) to identify the > archetype seems evident. > > In XML the namespaces are in URL's, they do not need to have a concept > in this URL. see above. But using a concept is also not a problem - it's just an id. The only problem is managing the assignment of ids, which doesn't occur today, but should. We had originally thought of doing this in a Snomed namespace, but now I am less sure that that is the right approach. > >> 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 becomes less restrictive that is true, because there are more > authorities, you can always find an authority which does not deny you > a specific concept-name. > Because, you can go to another which allows you that conceptname, or > even organize your own namespace. > And in that way the ID's (in spite of being meaningful) can still > remain unique, worldwide. > > But it is cumbersome. But as I said, it is better then the current. > > That is how the worldwide web started, I remember you could buy books > with URL's in it, like a phonebook. And people (also I) were busy > typing URL's from that book. I still have such a book as curiosity: > The Internet Yellow Pages (Google in hardcopy) there may be some confusion here. I am not advocating URLs. A domain name is not the same as a URL. > > But now, nobody ever remember URL's or reads them. It is all done by > machines, and the URL's often aren't anymore readable. Even > domainnames could not prevent them from becoming unreadable. I think we must be talking about different things; what kind of organisation domain names have become non-meaningful? > > With archetypes the same will happen. People are going to search for > archetypes, conceptnames will become a very important search argument. well they won't search in general with the short concept name, they will use keywords and ontology-based search terms which will enable the search. CKM and other tools already do this. So the 'blood_pressure_measurement' string is of limited importance in searching. It's main importance is for enabling direct quick understanding of what an archetype is about in tools and in data, and in education. > Because this is, you should never allow a technical reason (like there > is now) to deny conceptnames to people. Like in the worldwide web, the > concept should not be in the URL, but somewhere else. well actually concept names are part of well-design URLs all the time. That's the whole idea actually of a well designed reliable URL, to be based on a reliable concept, not a system directory or location. For example, the URL http://www.openehr.org/releases/1.0.2/architecture/overview.pdf is reliable because it has nothing to do with physical location - it's based purely on the concept 'releases/1.0.2', the concept of the 'architecure' part of the specs, and the concept of what the target document is about. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20121213/cdbae22d/attachment.html>
