Polishing node identifier (at-codes) use cases.
I have quite a few generated archetypes. Not clinically valid (or clinically validated at least) but they should be simple and varied enough to test. Or we could just try to generate a full cycle (I could open a CKM archetype, save it and give it back to you to test it). 2013/8/27 Thomas Beale thomas.beale at oceaninformatics.com Bert, I would be very happy to test some archetypes created with the LinkEHR editor in the ADL workbench, but I don't think any are publicly visible are they? We need some definitive problem reports to know what to fix. Or log an issue here http://www.openehr.org/issues/browse/AEPR. I am pretty sure we can fix problems in both tools if we know what they are. - thomas On 27/08/2013 19:44, Bert Verhees wrote: On 08/27/2013 07:20 PM, Diego Bosc? wrote: Do we need at-codes when we create siblings such as DV_TEXT and DV_CODED_TEXT? In which circumstance can a sibling occur of a DataValue? Certainly not in an ELEMENT. I either cannot imagine another circumstance. So why use a node-value? Write a nodeId if you want, it is not very interesting. The problem is another. It annoys me quite some time, this issue, not if you use a nodeId or not, or if your archetype-editor does or does not. ***I would say, make it optional, configurable But what is the case? The problem is that there are two main archetype editors. One creates nodeIds in DataValues, and the other does not. The designers have apparently a different opinion on this. Sometimes the editors crash/choke on the ADL construct the other delivers. And even when they do not choke, when you change one letter in an archetype, maybe in the ontology What happens? The editor quickly removes/adds the nodeIds on all DataValues. (one does this, the other does that) This makes it impossible to work with them both. Ity makes it hard it exchange archetypes with other people. -- It looks very much alike the Document-format battle we have on this world for years now, Word vs WordPerfect vs OpenOffice. Even ISO standards did not solve this. Why is that? What is behind this? Competition? -- Coming back to archetype editors? Why change other parts of an archetype if someone wants to save a very small change. I really gave up complaining about this, and I often use text-editors for writing archetypes. At least, they do what I want them to do. So hey, we are living in 2013, it should not be that way. Please think about the users, the customers, do what they want you to do, and make it configurable. All problems are solved then. Thanks Bert ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- [image: Ocean Informatics] http://www.oceaninformatics.com/ *Thomas Beale Chief Technology Officer* +44 7792 403 613 Specification Program, *open*EHRhttp://www.openehr.org/ Honorary Research Fellow, UCL http://www.chime.ucl.ac.uk/ Chartered IT Professional Fellow, BCS http://www.bcs.org.uk/ Health IT blog http://wolandscat.net/category/health-informatics/ [image: View Thomas Beale's profile on LinkedIn] http://uk.linkedin.com/in/thomasbeale ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130827/71601831/attachment-0001.html -- next part -- A non-text attachment was scrubbed... Name: btn_liprofile_blue_80x15.png Type: image/png Size: 511 bytes Desc: not available URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130827/71601831/attachment-0001.png -- next part -- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 4085 bytes Desc: not available URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130827/71601831/attachment-0001.jpg
Polishing node identifier (at-codes) use cases.
Hi Thomas, thanks for your attention.
I experienced the problems with the Ocean Archetype Editor and The LinkEhr
editor when used in the same work-environment, for example, which causes
archetypes to be opened in both editors.
It is not difficult to reproduce the errors and inconviences. The issue is
that both, Ocean and LinkEhr, do not recognize their responsibility and do
not see a need to change this.
One problem easy to reproduce, easy, a few steps.
- create an archetype in the LinkEhr editor, most simple, based on Element
with one DataValue. You will see it will have a nodeid on the DataValue.
- open it in the Ocean Editor, as I recall, this is not possible, first you
need to change a few things, forgot what exactly. Small things, but this
should not be. Ok, repair it in a text-editor, open it, and change one
letter in the ontology, and save it.
- The nodeids in the DataValue are removed without notifying the user. The
archetype has changed on other places then was the purpose of the user.
You can do this also the other way around and you will experience also
problems.
The solution is: a good behavior would be that an archetype editor would
conform to the archetype a user loads in it, changing it without
notification is very wrong.
Another solution also needed would be that nodeids on locations where these
are not enforced by the ADL-definition should be optional.
These problems exist for years now, everyone knows about them, If it was my
software, I would comfort my users and customers with friendly solutions.
regards
Bert
Op dinsdag 27 augustus 2013 schreef Thomas Beale (
thomas.beale at oceaninformatics.com):
Bert,
I would be very happy to test some archetypes created with the LinkEHR
editor in the ADL workbench, but I don't think any are publicly visible are
they? We need some definitive problem reports to know what to fix. Or log
an issue here http://www.openehr.org/issues/browse/AEPR.
I am pretty sure we can fix problems in both tools if we know what they
are.
- thomas
On 27/08/2013 19:44, Bert Verhees wrote:
On 08/27/2013 07:20 PM, Diego Bosc? wrote:
Do we need at-codes when
we create siblings such as DV_TEXT and DV_CODED_TEXT?
In which circumstance can a sibling occur of a DataValue? Certainly not in
an ELEMENT.
I either cannot imagine another circumstance.
So why use a node-value? Write a nodeId if you want, it is not very
interesting. The problem is another.
It annoys me quite some time, this issue, not if you use a nodeId or not,
or if your archetype-editor does or does not.
***I would say, make it optional, configurable
But what is the case?
The problem is that there are two main archetype editors.
One creates nodeIds in DataValues, and the other does not.
The designers have apparently a different opinion on this.
Sometimes the editors crash/choke on the ADL construct the other delivers.
And even when they do not choke, when you change one letter in an
archetype, maybe in the ontology
What happens? The editor quickly removes/adds the nodeIds on all
DataValues. (one does this, the other does that)
This makes it impossible to work with them both. Ity makes it hard it
exchange archetypes with other people.
--
It looks very much alike the Document-format battle we have on this world
for years now, Word vs WordPerfect vs OpenOffice. Even ISO standards did
not solve this.
Why is that?
What is behind this?
Competition?
--
Coming back to archetype editors?
Why change other parts of an archetype if someone wants to save a very
small change.
I really gave up complaining about this, and I often use text-editors for
writing archetypes. At least, they do what I want them to do.
So hey, we are living in 2013, it should not be that way.
Please think about the users, the customers, do what they want you to do,
and make it configurable. All problems are solved then.
Thanks
Bert
___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org javascript:_e({}, 'cvml',
'openEHR-technical at lists.openehr.org');
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
[image: Ocean Informatics] http://www.oceaninformatics.com/ *Thomas
Beale
Chief Technology Officer*
+44 7792 403 613 Specification Program, *open*EHRhttp://www.openehr.org/
Honorary Research Fellow, UCL http://www.chime.ucl.ac.uk/
Chartered IT Professional Fellow, BCS http://www.bcs.org.uk/
Health IT blog http://wolandscat.net/category/health-informatics/ [image:
View Thomas Beale's profile on LinkedIn]
http://uk.linkedin.com/in/thomasbeale
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130827/9d5a611f/attachment.html
-- next part --
A non-text attachment was scrubbed...
Name:
Polishing node identifier (at-codes) use cases.
Bert Verhees bert.verhees at rosa.nl wrote: The issue is that both, Ocean and LinkEhr, do not recognize their responsibility and do not see a need to change this. Hi Bert, Glad you've brought this up again, but the problem won't get fixed unless you report it. Can you report the problem at http://www.openehr.org/issues/browse/AEPR and attach an archetype that demonstrates it? These problems exist for years now, everyone knows about them, If it was my software, I would comfort my users and customers with friendly solutions. If I had a problem that I wanted fixed, I would report it in the problem tracker. We are very busy and working on other projects. If this problem is important to you, please report it and we may get around to it some day. Please make sure that you attach an example of an archetype that demonstrates the problem. Peter
Polishing node identifier (at-codes) use cases.
. - thomas ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/75c6767e/attachment.html
Polishing node identifier (at-codes) use cases.
On 08/28/2013 02:34 AM, Peter Gummer wrote: Bert Verhees bert.verhees at rosa.nl wrote: The issue is that both, Ocean and LinkEhr, do not recognize their responsibility and do not see a need to change this. Hi Bert, Glad you've brought this up again, Can you report the problem at http://www.openehr.org/issues/browse/AEPR and attach an archetype that demonstrates it? Dear Peter, First I have to start up a Windows computer, this means, digging up my notebook, clean my desk to have space to put my notebook on, and hope Windows will start on it, which is always a risk. Last time I remember my virusscanner was preventing Windows to start, I never tried again after that because my notebook also has Linux. Both the LinkEhr as the Ocean-editor only run on Windows. The LinkEhr editor should run on Linux too, but it is for a 32-bits JVM, and I cannot get it to run. The Ocean editor should also run on Mono, but simply does not. When I have succeeded both to run, than I must reproduce something. It will cost me a day or more. To whom can I send the bill? It is in the advantage of Ocean and LinkEhr to get this sorted out. The problems are easy to reproduce. I told you how to. Please make a copy of this and the previous email, and put it in Jira. It contains valuable information. Or leave it and do nothing with it, like this has been done for years now. The market maybe will correct you. Thanks again for your attention. Have a nice day. Bert but the problem won't get fixed unless you report it. Ah, PS: But don't put the blame on me for your software having problems. Thanks. These problems exist for years now, everyone knows about them, If it was my software, I would comfort my users and customers with friendly solutions. If I had a problem that I wanted fixed, I would report it in the problem tracker. We are very busy and working on other projects. If this problem is important to you, please report it and we may get around to it some day. Please make sure that you attach an example of an archetype that demonstrates the problem. Peter ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Polishing node identifier (at-codes) use cases.
Bert Verhees bert.verhees at rosa.nl wrote: Or leave it and do nothing with it, like this has been done for years now. The market maybe will correct you. Nothing has been done about it, Bert, because no one has ever logged it as an issue. If any one out there actually does care about this, then please log it at http://www.openehr.org/issues/browse/AEPR with an example archetype. Problems logged there do get fixed. Peter
Polishing node identifier (at-codes) use cases.
On 08/28/2013 08:27 AM, Peter Gummer wrote: Bert Verhees bert.verhees at rosa.nl wrote: Or leave it and do nothing with it, like this has been done for years now. The market maybe will correct you. Nothing has been done about it, Bert, because no one has ever logged it as an issue. If any one out there actually does care about this, then please log it at http://www.openehr.org/issues/browse/AEPR with an example archetype. Problems logged there do get fixed. Someday, when I am busy with it, I will do it. Could well be coming month. Or maybe I write my own archetype editor and thank Ocean and LinkEhr for giving me this business-opportunity, maybe even send a box of chocolates then. :) Bert
Polishing node identifier (at-codes) use cases.
On 08/28/2013 08:42 AM, Bert Verhees wrote: maybe even send a box of chocolates then. From Brussels, of course.
Polishing node identifier (at-codes) use cases.
Bert, all these tools are free, built and maintained by their originators at their own cost. So you might be sending yourself the chocolates... - thomas
Polishing node identifier (at-codes) use cases.
On 08/28/2013 08:54 AM, Thomas Beale wrote: Bert, all these tools are free, built and maintained by their originators at their own cost. So you might be sending yourself the chocolates... There ain't no such thing as a free lunch Bert
Polishing node identifier (at-codes) use cases.
2013/8/27 Thomas Beale thomas.beale at oceaninformatics.com What is so wrong about having at-codes in every class of the archetype with no ontology definition for that code? interesting question - so far (10 years!) we have always treated an at-code as something that is in the ontology. At the moment no tools at all would handle the assumption that only some codes had definitions; it would raise questions: how do you know which things need definitions and which don't? My guess is that there would need to be a special definition that is connected to the at-codes you want to have no definitions, which would complicate the archetype ontology section structure. - thomas I'll try to summarize the origin of the different views we have regarding this topic and maybe this can be also useful to see why this is not just a configuration problem of the tools. We can find the explanation of node identifiers in two places (I use the latest drafts, I think): - In AOM 1.5 specifications, page 47: Semantic identifier of this node, used to distinguish sibling nodes of the same type. [Previously called ?meaning?]. Each node_id must be defined in the archetype ontology as a term code. - In ADL 1.5 specifications, page 26: In cADL, an entity in brackets of the form [at] following a type name is used to identify an object node, i.e. a node constraint delimiting a set of instances of the type as defined by the reference model. and A Node identifier is required for any object node that is intended to be addressable elsewhere in the same archetype, in a specialised child archetype, or in the runtime data and which would otherwise be ambiguous due to sibling object nodes The definition in AOM is the one followed by the openEHR editor, i.e. a node identifier or at code is just a pointer to the ontology section and a mechanism to distinguish sibling nodes. Thus, wherever it is not needed, the tool does not introduce that code in order not to dirty the ontology section. The first part of the definition in ADL is the one followed in LinkEHR and, in our opinion, more correct formally. When you introduce an archetype constraint for a C_OBJECT you are in fact creating a definition of a type (a sub-type of the more generic type defined by the reference model class) that will be used to create a subset of instances. We have to distinguish this sub-type from the RM type, and since the class name cannot be changed, the only solution is to use the at as type identifier. In other words, our interpretation is that at codes are unique identifiers of each type defined in the archetype, that may be also used to link to the ontology section, but that is the optional part. In fact, the only exception to this would be when you create constraints using a path, because then you are just navigating through the RM but do not change the meaning of the intermediate classes. The logic of the tools and the validation checks of archetypes are built based on those interpretations. I agree with Bert in one thing: tools shouldn't change things without notifications, but in this case we face a methodological difference, not just a configuration one, and that's why it is not easy to be solved. David -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es http://www.linkedin.com/in/davidmoner Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia ? 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/a5af394a/attachment.html
Polishing node identifier (at-codes) use cases.
On 08/28/2013 08:55 AM, Bert Verhees wrote: On 08/28/2013 08:54 AM, Thomas Beale wrote: Bert, all these tools are free, built and maintained by their originators at their own cost. So you might be sending yourself the chocolates... There ain't no such thing as a free lunch Some of the originators are students, working for their academic purposes and forgetting their tools very quickly when the have a job. Some originators are part of an enterprise and building the tools to promote their enterprise. Some of the originators are working in a university and getting well paid for spending their time on building such a tool. Some of the originators are promoting a standard and using the tool as promotion. Some of the originators are selling their tools for good money. And I must say, I agree with them all, there is nothing wrong with that. Nothing at all. We all have to live, and everyone is doing it on his/her way. There is nothing dishonorably on working for your profit. They could be grateful accept the help I offered until now and profit from it, they can also do nothing with it. It is their choice. I fully respect that. But saying that the tool isn't better because I (me, as a person) refuse to walk through some time-consuming formalities, that is not right, is my opinion. I leave it all up to the originators to improve their tooling or leave it as it is. Once in a year, the subject comes up (thanks, Diego), and I write down this old annoyance. I will stop doing this when I am bald and gray. Maybe that is today, I just looked into the mirror. Again, have a nice day, you are good folks. Bert
Polishing node identifier (at-codes) use cases.
On 28/08/2013 08:13, David Moner wrote: I'll try to summarize the origin of the different views we have regarding this topic and maybe this can be also useful to see why this is not just a configuration problem of the tools. We can find the explanation of node identifiers in two places (I use the latest drafts, I think): - In AOM 1.5 specifications, page 47: Semantic identifier of this node, used to distinguish sibling nodes of the same type. [Previously called 'meaning']. Each node_id must be defined in the archetype ontology as a term code. - In ADL 1.5 specifications, page 26: In cADL, an entity in brackets of the form [at] following a type name is used to identify an object node, i.e. a node constraint delimiting a set of instances of the type as defined by the reference model. and A Node identifier is required for any object node that is intended to be addressable elsewhere in the same archetype, in a specialised child archetype, or in the runtime data and which would otherwise be ambiguous due to sibling object nodes The definition in AOM is the one followed by the openEHR editor, i.e. a node identifier or at code is just a pointer to the ontology section and a mechanism to distinguish sibling nodes. Thus, wherever it is not needed, the tool does not introduce that code in order not to dirty the ontology section. The first part of the definition in ADL is the one followed in LinkEHR and, in our opinion, more correct formally. *When you introduce an archetype constraint for a C_OBJECT you are in fact creating a definition of a type (a sub-type of the more generic type defined by the reference model class) that will be used to create a subset of instances*. We have to distinguish this sub-type from the RM type, and since the class name cannot be changed, the only solution is to use the at as type identifier. In other words, our interpretation is that at codes are unique identifiers of each type defined in the archetype, that may be also used to link to the ontology section, but that is the optional part. In fact, the only exception to this would be when you create constraints using a path, because then you are just navigating through the RM but do not change the meaning of the intermediate classes. Does LinkEHR actually do this? I.e. only some at-codes are found in the ontology? Your statement above (bolded) is right in theory (or at least that's the way I see it), but then the obvious question is: if I mutate the type (say) ENTRY to ENTRY[at0123], what does ENTRY[at0123] mean? In general we want to equate that with a meaning of some kind (like 'ENTRY' has a meaning). Remember, we could have done something like 'ENTRY[admission]' or 'ENTRY[bp_measurement]' but we don't do that because we want the meanings to be multi-lingual (one day the 'ENTRY' bit should be as well...). So we use term codes. So if we agree that 'mostly' we want those meanings defined, then the question is: which places doesn't it matter? I would say: places where it's obvious, like ELEMENT.value: DV_TEXT. My view has always been that we would avoid at-codes in locations where the meaning is obvious (principally for single-valued attributes, where the archetype meaning is the same as the RM meaning). The other reason for that is to limit the length of paths for Xpath processing. Unnecessary codes can double the length of some paths. If we go the other way, then we are saying: at-codes are 100% mandatory everywhere, but definitions for them are optional. Then we need some rules on when it is optional and when mandatory. What rules would you propose for that? Remembering that a clinical modeller absolutely relies on those rules for understanding the archetype? - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/52af4bf5/attachment-0001.html
Polishing node identifier (at-codes) use cases.
Bert Verhees bert.verhees at rosa.nl wrote: They could be grateful accept the help I offered until now and profit from it, they can also do nothing with it. It is their choice. I fully respect that. But saying that the tool isn't better because I (me, as a person) refuse to walk through some time-consuming formalities, that is not right, is my opinion. I leave it all up to the originators to improve their tooling or leave it as it is. Very happy to have the help, Bert. Without people like you reporting problems, we don't know about them. Look forward to getting that problem report when you get a chance. It should only take you a couple of minutes ? probably a lot quicker than writing all of these emails ;-) Peter
Polishing node identifier (at-codes) use cases.
2013/8/28 Thomas Beale thomas.beale at oceaninformatics.com
Does LinkEHR actually do this? I.e. only some at-codes are found in the
ontology? Your statement above (bolded) is right in theory (or at least
that's the way I see it), but then the obvious question is: if I mutate the
type (say) ENTRY to ENTRY[at0123], what does ENTRY[at0123] mean? In general
we want to equate that with a meaning of some kind (like 'ENTRY' has a
meaning). Remember, we could have done something like 'ENTRY[admission]' or
'ENTRY[bp_measurement]' but we don't do that because we want the meanings
to be multi-lingual (one day the 'ENTRY' bit should be as well...). So we
use term codes.
So if we agree that 'mostly' we want those meanings defined, then the
question is: which places doesn't it matter? I would say: places where it's
obvious, like ELEMENT.value: DV_TEXT. My view has always been that we would
avoid at-codes in locations where the meaning is obvious (principally for
single-valued attributes, where the archetype meaning is the same as the RM
meaning). The other reason for that is to limit the length of paths for
Xpath processing. Unnecessary codes can double the length of some paths.
No, currently all at codes are also found at the ontology in LinkEHR,
even if they are empty, to be compatible with the VATDF2 check, although
we would like to avoid it :-)
In my opinion we talk of two different levels of meaning. One is the
explicit meaning, where the definition of the node is defined through a
natural text or a terminology binding and that is, of course, the needed
for a complete semantic interoperability. The other is the implicit
meaning, when you create e.g. an OBSERVATION with occurrences {1..1} you
are creating An OBSERVATION that only happens once. That means something
(otherwise you wouldn't have defined that constraint), even if you cannot
give it a natural name or a terminology code. And if it means something, it
shall have an identifier.
If we go the other way, then we are saying: at-codes are 100% mandatory
everywhere, but definitions for them are optional. Then we need some rules
on when it is optional and when mandatory. What rules would you propose for
that? Remembering that a clinical modeller absolutely relies on those rules
for understanding the archetype?
I don't think a clinical modeller would have to mind about these aspects.
He/she creates an archetype node (internally, a unique at code is
created). He/she optionally gives it a name or defines a terminology
binding (internally the ontology structures are created). When the
archetype is used or processed, the systems will only use the information
they have available.
--
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner
Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/c3a581e6/attachment.html
Polishing node identifier (at-codes) use cases.
2013/8/28 Bert Verhees bert.verhees at rosa.nl: On 08/28/2013 08:55 AM, Bert Verhees wrote: On 08/28/2013 08:54 AM, Thomas Beale wrote: Bert, all these tools are free, built and maintained by their originators at their own cost. So you might be sending yourself the chocolates... There ain't no such thing as a free lunch Some of the originators are students, working for their academic purposes and forgetting their tools very quickly when the have a job. Some originators are part of an enterprise and building the tools to promote their enterprise. Some of the originators are working in a university and getting well paid for spending their time on building such a tool. Some of the originators are promoting a standard and using the tool as promotion. Some of the originators are selling their tools for good money. BTW, I don't know how much does a university researcher gets paid in the Netherlands, but I can assure you that is not that well paid in Spain ;D And I must say, I agree with them all, there is nothing wrong with that. Nothing at all. We all have to live, and everyone is doing it on his/her way. There is nothing dishonorably on working for your profit. They could be grateful accept the help I offered until now and profit from it, they can also do nothing with it. It is their choice. I fully respect that. But saying that the tool isn't better because I (me, as a person) refuse to walk through some time-consuming formalities, that is not right, is my opinion. I leave it all up to the originators to improve their tooling or leave it as it is. Once in a year, the subject comes up (thanks, Diego), and I write down this old annoyance. I will stop doing this when I am bald and gray. Maybe that is today, I just looked into the mirror. Again, have a nice day, you are good folks. Bert ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Polishing node identifier (at-codes) use cases.
On 08/28/2013 11:25 AM, Diego Bosc? wrote: BTW, I don't know how much does a university researcher gets paid in the Netherlands, but I can assure you that is not that well paid in Spain ;D It depends on your qualifications, but it must be enough so one can live from it. A dead researcher is of no good at all. :)
Polishing node identifier (at-codes) use cases.
On 08/28/2013 10:33 AM, Peter Gummer wrote: Look forward to getting that problem report when you get a chance. It should only take you a couple of minutes I think you are right. I do it, next chance as I happen to work with it. Bert
Polishing node identifier (at-codes) use cases.
On 28/08/2013 10:07, David Moner wrote:
No, currently all at codes are also found at the ontology in
LinkEHR, even if they are empty, to be compatible with the VATDF2
check, although we would like to avoid it :-)
In my opinion we talk of two different levels of meaning. One is the
explicit meaning, where the definition of the node is defined through
a natural text or a terminology binding and that is, of course, the
needed for a complete semantic interoperability. The other is the
implicit meaning, when you create e.g. an OBSERVATION with occurrences
{1..1} you are creating An OBSERVATION that only happens once. That
means something (otherwise you wouldn't have defined that constraint),
even if you cannot give it a natural name or a terminology code. And
if it means something, it shall have an identifier.
David, I am not totally clear on what you mean. OBSERVATION is a class
that always has an at-code on it anyway, because it is a high-level
class and needs its clinical meaning defined anyway. If you impose
{1..1} on it, you will do that via a SECTION or COMPOSITION slot.
If we go the other way, then we are saying: at-codes are 100%
mandatory everywhere, but definitions for them are optional. Then
we need some rules on when it is optional and when mandatory. What
rules would you propose for that? Remembering that a clinical
modeller absolutely relies on those rules for understanding the
archetype?
I don't think a clinical modeller would have to mind about these
aspects. He/she creates an archetype node (internally, a unique at
code is created). He/she optionally gives it a name or defines a
terminology binding (internally the ontology structures are created).
When the archetype is used or processed, the systems will only use the
information they have available.
Ok, but if tools have no rules, then we can end up with an archetype
like this:
OBSERVATION matches {
data matches {
HISTORY matches {
}
}
}
with no meaning on anything. What is to prevent that?
- thomas
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/6610f406/attachment-0001.html
Polishing node identifier (at-codes) use cases.
David, Can I summarise it for my understanding as: - AT codes are pointers to an 'ontology'. - AT codes can be considered symbols that represent a particular concept - The 'ontology' provides a name that will be used to display the name of a node (concept) in an archetype. - When a node is specialised the node name used will indicate a new concept (its meaning has changed) - When the archetype is specialised ideally the new concept in the specialisation is a subordinate concept. - When a Node is specialised the standard does not prescribe that the new concept is a sub-set of the previous one. - The question is: is each Node (and the concept it represents) unique or not. - The question is: is it obligatory that each node in the archetype carries a unique code of the form AT . My answers to both questions are: - Each archetype node is a unique concept that must have attached to it a unique identifier. - Archetype editors must support this. And I would like to add: - When specialising each specialised concept must be a subset of its previous one. Gerard Freriks +31 620347088 gfrer at luna.nl On 28 aug. 2013, at 09:13, David Moner damoca at gmail.com wrote: I'll try to summarize the origin of the different views we have regarding this topic and maybe this can be also useful to see why this is not just a configuration problem of the tools. We can find the explanation of node identifiers in two places (I use the latest drafts, I think): - In AOM 1.5 specifications, page 47: Semantic identifier of this node, used to distinguish sibling nodes of the same type. [Previously called ?meaning?]. Each node_id must be defined in the archetype ontology as a term code. - In ADL 1.5 specifications, page 26: In cADL, an entity in brackets of the form [at] following a type name is used to identify an object node, i.e. a node constraint delimiting a set of instances of the type as defined by the reference model. and A Node identifier is required for any object node that is intended to be addressable elsewhere in the same archetype, in a specialised child archetype, or in the runtime data and which would otherwise be ambiguous due to sibling object nodes The definition in AOM is the one followed by the openEHR editor, i.e. a node identifier or at code is just a pointer to the ontology section and a mechanism to distinguish sibling nodes. Thus, wherever it is not needed, the tool does not introduce that code in order not to dirty the ontology section. The first part of the definition in ADL is the one followed in LinkEHR and, in our opinion, more correct formally. When you introduce an archetype constraint for a C_OBJECT you are in fact creating a definition of a type (a sub-type of the more generic type defined by the reference model class) that will be used to create a subset of instances. We have to distinguish this sub-type from the RM type, and since the class name cannot be changed, the only solution is to use the at as type identifier. In other words, our interpretation is that at codes are unique identifiers of each type defined in the archetype, that may be also used to link to the ontology section, but that is the optional part. In fact, the only exception to this would be when you create constraints using a path, because then you are just navigating through the RM but do not change the meaning of the intermediate classes. The logic of the tools and the validation checks of archetypes are built based on those interpretations. I agree with Bert in one thing: tools shouldn't change things without notifications, but in this case we face a methodological difference, not just a configuration one, and that's why it is not easy to be solved. David -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/1595399d/attachment.html
openEHR-technical Digest, Vol 18, Issue 37
, that may be also used to link to the ontology section, but that is the optional part. In fact, the only exception to this would be when you create constraints using a path, because then you are just navigating through the RM but do not change the meaning of the intermediate classes. The logic of the tools and the validation checks of archetypes are built based on those interpretations. I agree with Bert in one thing: tools shouldn't change things without notifications, but in this case we face a methodological difference, not just a configuration one, and that's why it is not easy to be solved. David -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/1595399d/attachment-0001.html -- Subject: Digest Footer ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- End of openEHR-technical Digest, Vol 18, Issue 37 *
openEHR-technical Digest, Vol 18, Issue 37
as defined by the reference model. and A Node identifier is required for any object node that is intended to be addressable elsewhere in the same archetype, in a specialised child archetype, or in the runtime data and which would otherwise be ambiguous due to sibling object nodes The definition in AOM is the one followed by the openEHR editor, i.e. a node identifier or at code is just a pointer to the ontology section and a mechanism to distinguish sibling nodes. Thus, wherever it is not needed, the tool does not introduce that code in order not to dirty the ontology section. The first part of the definition in ADL is the one followed in LinkEHR and, in our opinion, more correct formally. When you introduce an archetype constraint for a C_OBJECT you are in fact creating a definition of a type (a sub-type of the more generic type defined by the reference model class) that will be used to create a subset of instances. We have to distinguish this sub-type from the RM type, and since the class name cannot be changed, the only solution is to use the at as type identifier. In other words, our interpretation is that at codes are unique identifiers of each type defined in the archetype, that may be also used to link to the ontology section, but that is the optional part. In fact, the only exception to this would be when you create constraints using a path, because then you are just navigating through the RM but do not change the meaning of the intermediate classes. The logic of the tools and the validation checks of archetypes are built based on those interpretations. I agree with Bert in one thing: tools shouldn't change things without notifications, but in this case we face a methodological difference, not just a configuration one, and that's why it is not easy to be solved. David -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/1595399d/attachment-0001.html -- Subject: Digest Footer ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- End of openEHR-technical Digest, Vol 18, Issue 37 * ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/34ab97de/attachment.html
Polishing node identifier (at-codes) use cases.
it is not easy to be solved. David ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/b1f51ef3/attachment-0001.html
Polishing node identifier (at-codes) use cases.
be also used to link to the ontology section, but that is the optional part. In fact, the only exception to this would be when you create constraints using a path, because then you are just navigating through the RM but do not change the meaning of the intermediate classes. The logic of the tools and the validation checks of archetypes are built based on those interpretations. I agree with Bert in one thing: tools shouldn't change things without notifications, but in this case we face a methodological difference, not just a configuration one, and that's why it is not easy to be solved. David ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/a2999dd1/attachment-0001.html
