Polishing node identifier (at-codes) use cases.

[Bert Verhees]

OK

Bert

On 09/27/2013 05:20 PM, Thomas Beale wrote:
>
> Bert,
>
> can you raise an issue on SPECPR 
>  - that's the issue 
> tracker that we use to feed specification work. If you just paste most 
> of this post in as the description that will be enough to get back to 
> this when more people can get involved (which will be fairly soon).
>
> thanks
>
> - thomas
>
> On 26/09/2013 11:21, Bert Verhees wrote:
>>

 In my system it is not useful to preload archetypes, because, 
 archetypes are only parsed once in my system.
 That is when they are saved in the system. They are parsed in order 
 to create a RNG/Schematron definition.
>>>
>>> ok, so the downstream form of an archetype you are using is a 
>>> Schematron schema - so that's the thing that needs to be stored.
>>
>> OK, I misunderstood that part of the discussion, having a form of 
>> XML-schema is a representation of an archetype, which can be for 
>> specific purposes like validation more efficient then the 
>> archetype-object, depending on the technical architecture of the kernel.
>>
>> It seems that we agree on that.
>>
>>>

 That is used to validate the data, and if new data are entered, 
 then they will be checked against that RNG/Schematron definition, 
 not against the parsed archetype.
 The schema is loaded in microseconds and the validation takes one 
 second.

 After the data are validated, they are stored in an XML-database, 
 and they will never be validated again. They are ready for 
 XPath-queries and XQueries, and all kind of complicated handling 
 without even looking at an archetype.
>>>
>>> right - that sounds like all other archetype-based systems I know of.
>>>

 So the refusal to specify a "archetype_id" in the specs is, in my 
 architecture, bad for performance, because it forces extra 
 archetype-parsing, so I have that property without the consensus 
 with the specs, and I do not see it as a waste. I make sure that 
 when I have to export data to an OpenEHR system, I will put the 
 archetype_id in the archetype_node_id property.
>>>
>>> but the specs already specify archetype_details, which contains the 
>>> archetype id. And you can detect that easily in a schematron schema 
>>> I guess.  So you can easily figure out that you are on one of those 
>>> nodes. Is the real problem simply that the syntax of what is in 
>>> archetype_node_id on one of those nodes - an archetype_id rather 
>>> than an at-code - causes some problem in your processing? I am not 
>>> clear on what though... are you trying to use the at-code texts at 
>>> runtime? Are they also in the Schematron schema?
>>
>> We are not talking about the OpenEHR reference model, but about 
>> archetyped data-handling.
>>
>> I have two arguments, the first one is most simple to explain, so I 
>> start with that.
>> --
>> 1)
>> *A golden rule in design is that attribute-names should indicate what 
>> they are there for.*
>>
>> We are not writing obfuscated code, but readable code, because the 
>> cold war is finished, and we do not need to confuse the Russians 
>> anymore, so we can safely honor this rule.
>>
>> This means, an attribute (in the ADL common notation) which contains 
>> the archetypeNodeID should be called archetype_node_id and an 
>> attribute containing an archetypeId should be called archetype_id and 
>> it is confusing to use the attribute archetype_node_id to store both, 
>> and even, which makes it worse, without indication about what is in it.
>> --
>> 2)
>> The second argument is a more technical issue and a bit difficult to 
>> explain, but I try with an example:
>>
>> Imagine you have extracted an XML-path in your datastorage which says
>> ../details[@archetype_node_id="at0001"]/items[@archetype_node_id="at0003"]/.
>>  
>>
>>
>> Say, your client software wants to build a GUI, and uses the 
>> ontology-information to create the GUI-control-indicators and 
>> help-information. I think this is possible to do that that way. It 
>> makes dynamic GUI-building possible.
>> This example-path above is easy to find and will not cause any 
>> complicated handling.
>>
>> But in the current situation, the path can look like:
>> ../details[@archetype_node_id="at0001"]/items[@archetype_node_id="openEHR-EHR-ITEM_LIST.address.v1"]/.
>>  
>>
>>
>> First Step: Now the GUI software wants to have a container-control 
>> which contains the items, and it looks in the ontology of the 
>> containing data-set-archetype to find the archetype_node_id: 
>> "openEHR-EHR-ITEM_LIST.address.v1"
>>
>> It does not find it, because it is not there.
>>
>> Second Step: Now you suggest that the software should look if there 
>> is an archetypeDetails attribute, to see if there is another 
>> archetype to be used for ontology search. This is one step extra the 
>> software needs to do.
>>

Polishing node identifier (at-codes) use cases.

[Thomas Beale]

Bert,

can you raise an issue on SPECPR 
 - that's the issue tracker 
that we use to feed specification work. If you just paste most of this 
post in as the description that will be enough to get back to this when 
more people can get involved (which will be fairly soon).

thanks

- thomas

On 26/09/2013 11:21, Bert Verhees wrote:
>
>>>
>>> In my system it is not useful to preload archetypes, because, 
>>> archetypes are only parsed once in my system.
>>> That is when they are saved in the system. They are parsed in order 
>>> to create a RNG/Schematron definition.
>>
>> ok, so the downstream form of an archetype you are using is a 
>> Schematron schema - so that's the thing that needs to be stored.
>
> OK, I misunderstood that part of the discussion, having a form of 
> XML-schema is a representation of an archetype, which can be for 
> specific purposes like validation more efficient then the 
> archetype-object, depending on the technical architecture of the kernel.
>
> It seems that we agree on that.
>
>>
>>>
>>> That is used to validate the data, and if new data are entered, then 
>>> they will be checked against that RNG/Schematron definition, not 
>>> against the parsed archetype.
>>> The schema is loaded in microseconds and the validation takes one 
>>> second.
>>>
>>> After the data are validated, they are stored in an XML-database, 
>>> and they will never be validated again. They are ready for 
>>> XPath-queries and XQueries, and all kind of complicated handling 
>>> without even looking at an archetype.
>>
>> right - that sounds like all other archetype-based systems I know of.
>>
>>>
>>> So the refusal to specify a "archetype_id" in the specs is, in my 
>>> architecture, bad for performance, because it forces extra 
>>> archetype-parsing, so I have that property without  the consensus 
>>> with the specs, and I do not see it as a waste. I make sure that 
>>> when I have to export data to an OpenEHR system, I will put the 
>>> archetype_id in the archetype_node_id property.
>>
>> but the specs already specify archetype_details, which contains the 
>> archetype id. And you can detect that easily in a schematron schema I 
>> guess.  So you can easily figure out that you are on one of those 
>> nodes. Is the real problem simply that the syntax of what is in 
>> archetype_node_id on one of those nodes - an archetype_id rather than 
>> an at-code - causes some problem in your processing? I am not clear 
>> on what though... are you trying to use the at-code texts at runtime? 
>> Are they also in the Schematron schema?
>
> We are not talking about the OpenEHR reference model, but about 
> archetyped data-handling.
>
> I have two arguments, the first one is most simple to explain, so I 
> start with that.
> --
> 1)
> *A golden rule in design is that attribute-names should indicate what 
> they are there for.*
>
> We are not writing obfuscated code, but readable code, because the 
> cold war is finished, and we do not need to confuse the Russians 
> anymore, so we can safely honor this rule.
>
> This means, an attribute (in the ADL common notation) which contains 
> the archetypeNodeID should be called archetype_node_id and an 
> attribute containing an archetypeId should be called archetype_id and 
> it is confusing to use the attribute archetype_node_id to store both, 
> and even, which makes it worse, without indication about what is in it.
> --
> 2)
> The second argument is a more technical issue and a bit difficult to 
> explain, but I try with an example:
>
> Imagine you have extracted an XML-path in your datastorage which says
> ../details[@archetype_node_id="at0001"]/items[@archetype_node_id="at0003"]/.
>  
>
>
> Say, your client software wants to build a GUI, and uses the 
> ontology-information to create the GUI-control-indicators and 
> help-information. I think this is possible to do that that way. It 
> makes dynamic GUI-building possible.
> This example-path above is easy to find and will not cause any 
> complicated handling.
>
> But in the current situation, the path can look like:
> ../details[@archetype_node_id="at0001"]/items[@archetype_node_id="openEHR-EHR-ITEM_LIST.address.v1"]/.
>  
>
>
> First Step: Now the GUI software wants to have a container-control 
> which contains the items, and it looks in the ontology of the 
> containing data-set-archetype to find the archetype_node_id: 
> "openEHR-EHR-ITEM_LIST.address.v1"
>
> It does not find it, because it is not there.
>
> Second Step: Now you suggest that the software should look if there is 
> an archetypeDetails attribute, to see if there is another archetype to 
> be used for ontology search. This is one step extra the software needs 
> to do.
>
> Should it do this at every archetypeNodeId, or only if search did not 
> give a result? That is a statistical question, which workaround will 
> be applied more and cost more o

Polishing node identifier (at-codes) use cases.

[Bert Verhees]

>>
>> In my system it is not useful to preload archetypes, because, 
>> archetypes are only parsed once in my system.
>> That is when they are saved in the system. They are parsed in order 
>> to create a RNG/Schematron definition.
>
> ok, so the downstream form of an archetype you are using is a 
> Schematron schema - so that's the thing that needs to be stored.

OK, I misunderstood that part of the discussion, having a form of 
XML-schema is a representation of an archetype, which can be for 
specific purposes like validation more efficient then the 
archetype-object, depending on the technical architecture of the kernel.

It seems that we agree on that.

>
>>
>> That is used to validate the data, and if new data are entered, then 
>> they will be checked against that RNG/Schematron definition, not 
>> against the parsed archetype.
>> The schema is loaded in microseconds and the validation takes one 
>> second.
>>
>> After the data are validated, they are stored in an XML-database, and 
>> they will never be validated again. They are ready for XPath-queries 
>> and XQueries, and all kind of complicated handling without even 
>> looking at an archetype.
>
> right - that sounds like all other archetype-based systems I know of.
>
>>
>> So the refusal to specify a "archetype_id" in the specs is, in my 
>> architecture, bad for performance, because it forces extra 
>> archetype-parsing, so I have that property without  the consensus 
>> with the specs, and I do not see it as a waste. I make sure that when 
>> I have to export data to an OpenEHR system, I will put the 
>> archetype_id in the archetype_node_id property.
>
> but the specs already specify archetype_details, which contains the 
> archetype id. And you can detect that easily in a schematron schema I 
> guess.  So you can easily figure out that you are on one of those 
> nodes. Is the real problem simply that the syntax of what is in 
> archetype_node_id on one of those nodes - an archetype_id rather than 
> an at-code - causes some problem in your processing? I am not clear on 
> what though... are you trying to use the at-code texts at runtime? Are 
> they also in the Schematron schema?

We are not talking about the OpenEHR reference model, but about 
archetyped data-handling.

I have two arguments, the first one is most simple to explain, so I 
start with that.
--
1)
*A golden rule in design is that attribute-names should indicate what 
they are there for.*

We are not writing obfuscated code, but readable code, because the cold 
war is finished, and we do not need to confuse the Russians anymore, so 
we can safely honor this rule.

This means, an attribute (in the ADL common notation) which contains the 
archetypeNodeID should be called archetype_node_id and an attribute 
containing an archetypeId should be called archetype_id and it is 
confusing to use the attribute archetype_node_id to store both, and 
even, which makes it worse, without indication about what is in it.
--
2)
The second argument is a more technical issue and a bit difficult to 
explain, but I try with an example:

Imagine you have extracted an XML-path in your datastorage which says
../details[@archetype_node_id="at0001"]/items[@archetype_node_id="at0003"]/.

Say, your client software wants to build a GUI, and uses the 
ontology-information to create the GUI-control-indicators and 
help-information. I think this is possible to do that that way. It makes 
dynamic GUI-building possible.
This example-path above is easy to find and will not cause any 
complicated handling.

But in the current situation, the path can look like:
../details[@archetype_node_id="at0001"]/items[@archetype_node_id="openEHR-EHR-ITEM_LIST.address.v1"]/.

First Step: Now the GUI software wants to have a container-control which 
contains the items, and it looks in the ontology of the containing 
data-set-archetype to find the archetype_node_id: 
"openEHR-EHR-ITEM_LIST.address.v1"

It does not find it, because it is not there.

Second Step: Now you suggest that the software should look if there is 
an archetypeDetails attribute, to see if there is another archetype to 
be used for ontology search. This is one step extra the software needs 
to do.

Should it do this at every archetypeNodeId, or only if search did not 
give a result? That is a statistical question, which workaround will be 
applied more and cost more on the long term. Maybe some tricks may help, 
and we get tricky software.

Third Step: Then, the archetype_node_id in that archetype to search for 
is invisible for the software, because, it is not in the path. So, this 
step is a more complicated, the software needs to know which 
archetype_node_id belongs to the root of that archetype, and then it can 
find in the ontology section what the description is.

This all could be so much easier, and efficient when the extracted path 
looked like:
../details[@archetype_node_id="at0001

Polishing node identifier (at-codes) use cases.

[Thomas Beale]

On 25/09/2013 23:20, Bert Verhees wrote:
> Op 25-9-2013 22:47, Thomas Beale schreef:
>> On 25/09/2013 00:53, Bert Verhees wrote:
>>>
 sure - if you have a separate property to store the archetype id, 
 it is empty in 95% of all object instances, and also you need a 
 class invariant to prevent it being filled at the same time as the 
 archetype_node_id (at-code) property.
>>>
>>> I must disagree, it is very common in archetypes, I think it is in 
>>> 90% of the archetypes that the root of a definition also has a node_id. 
>>
>> It's 100% ;-)
>>
>> But what i meant was that in any instance structure, say a 
>> Composition, most of the nodes in the data tree will have an at-code 
>> in archetype_node_id, only a few - the archetype root points - will 
>> have archetype ids.
>>
>> The at-node corresponding to the root point is just the at code 
>> (or a specialised version of that). Putting that in the data is not 
>> much use.
>
> People could use it for some ontology-message. I don't understand why 
> it is there when it is not allowed to use, or when it is not possible 
> to retrieve the connected information. Again this is some small thing 
> in the specs which has no purpose while people could expect it. This 
> is caused in chain reaction by the other, I think, ambiguous spec. 
> Because the other spec makes it impossible to query the atcode from 
> the definition of an archetype.
>
> I must say that this is not very nice defined.
>
> -- skip skip 
> --
>
>> but the Xpath engine doesn't need to do this. It just processes the 
>> query paths it finds in the queries. It doesn't need to know what 
>> archetypes were used to structure it.
>
> Not quite so, XPath can have properties as path-arguments, and it must 
> possible to query for certain objects with a specific archetype_id and 
> another specific node_id. Since the root of the definition is allowed 
> to have an node_id, one can expect people use it, so there can be a 
> need to query them.
>
> As I said before, as a builder/designer of a two level modeling 
> system, you cannot predict which archetypes people use. And you must 
> be sure that the archetypes they use, can be used safely, which is not 
> always the case in the current specs, because there may be possible 
> information which cannot be reached at query-time.
>
>>
>> -- skip skip 
>> --
>>
>>
>> My suspicion from what you are saying is that you are not doing a 
>> pre-load of operational templates into your back-end system. If you 
>> had that, the query service can work very optimally.
>
> It depends if it is wished to have archetypes pre-loaded. If you run a 
> kernel as a public service, and there are hundreds of archetypes 
> operational, then it will cost a lot of memory to pre-load them all.
> The parsing an archetype should not be done more then once in its 
> lifetime, it is expensive and unnecessary computing, especially when 
> the archetypes are large. Saving them preloaded is a real memory-eater.

exactly - that's why you should pre-load them - I don't mean cache them 
in memory - I mean compile the them once, compile the templates, 
generate the operational templates, and store all of these in a local 
database or location in a post-parsed form, typically an XML or other 
object (e.g. JSON) object serialisation. If your system encounters a new 
archetype, that needs to be compiled and saved in the same way as well.

>
> In my system it is not useful to preload archetypes, because, 
> archetypes are only parsed once in my system.
> That is when they are saved in the system. They are parsed in order to 
> create a RNG/Schematron definition.

ok, so the downstream form of an archetype you are using is a Schematron 
schema - so that's the thing that needs to be stored.

>
> That is used to validate the data, and if new data are entered, then 
> they will be checked against that RNG/Schematron definition, not 
> against the parsed archetype.
> The schema is loaded in microseconds and the validation takes one second.
>
> After the data are validated, they are stored in an XML-database, and 
> they will never be validated again. They are ready for XPath-queries 
> and XQueries, and all kind of complicated handling without even 
> looking at an archetype.

right - that sounds like all other archetype-based systems I know of.

>
> So the refusal to specify a "archetype_id" in the specs is, in my 
> architecture, bad for performance, because it forces extra 
> archetype-parsing, so I have that property without  the consensus with 
> the specs, and I do not see it as a waste. I make sure that when I 
> have to export data to an OpenEHR system, I will put the archetype_id 
> in the archetype_node_id property.

but the specs already specify archetype_details, which contains the 
archetype id. And you can detect that e

Polishing node identifier (at-codes) use cases.

[Bert Verhees]

Op 25-9-2013 22:47, Thomas Beale schreef:
> On 25/09/2013 00:53, Bert Verhees wrote:
>>
>>> sure - if you have a separate property to store the archetype id, it 
>>> is empty in 95% of all object instances, and also you need a class 
>>> invariant to prevent it being filled at the same time as the 
>>> archetype_node_id (at-code) property.
>>
>> I must disagree, it is very common in archetypes, I think it is in 
>> 90% of the archetypes that the root of a definition also has a node_id. 
>
> It's 100% ;-)
>
> But what i meant was that in any instance structure, say a 
> Composition, most of the nodes in the data tree will have an at-code 
> in archetype_node_id, only a few - the archetype root points - will 
> have archetype ids.
>
> The at-node corresponding to the root point is just the at code 
> (or a specialised version of that). Putting that in the data is not 
> much use.

People could use it for some ontology-message. I don't understand why it 
is there when it is not allowed to use, or when it is not possible to 
retrieve the connected information. Again this is some small thing in 
the specs which has no purpose while people could expect it. This is 
caused in chain reaction by the other, I think, ambiguous spec. Because 
the other spec makes it impossible to query the atcode from the 
definition of an archetype.

I must say that this is not very nice defined.

-- skip skip 
--

> but the Xpath engine doesn't need to do this. It just processes the 
> query paths it finds in the queries. It doesn't need to know what 
> archetypes were used to structure it.

Not quite so, XPath can have properties as path-arguments, and it must 
possible to query for certain objects with a specific archetype_id and 
another specific node_id. Since the root of the definition is allowed to 
have an node_id, one can expect people use it, so there can be a need to 
query them.

As I said before, as a builder/designer of a two level modeling system, 
you cannot predict which archetypes people use. And you must be sure 
that the archetypes they use, can be used safely, which is not always 
the case in the current specs, because there may be possible information 
which cannot be reached at query-time.

>
> -- skip skip 
> --
>
>
> My suspicion from what you are saying is that you are not doing a 
> pre-load of operational templates into your back-end system. If you 
> had that, the query service can work very optimally.

It depends if it is wished to have archetypes pre-loaded. If you run a 
kernel as a public service, and there are hundreds of archetypes 
operational, then it will cost a lot of memory to pre-load them all.
The parsing an archetype should not be done more then once in its 
lifetime, it is expensive and unnecessary computing, especially when the 
archetypes are large. Saving them preloaded is a real memory-eater.

In my system it is not useful to preload archetypes, because, archetypes 
are only parsed once in my system.
That is when they are saved in the system. They are parsed in order to 
create a RNG/Schematron definition.

That is used to validate the data, and if new data are entered, then 
they will be checked against that RNG/Schematron definition, not against 
the parsed archetype.
The schema is loaded in microseconds and the validation takes one second.

After the data are validated, they are stored in an XML-database, and 
they will never be validated again. They are ready for XPath-queries and 
XQueries, and all kind of complicated handling without even looking at 
an archetype.

So the refusal to specify a "archetype_id" in the specs is, in my 
architecture, bad for performance, because it forces extra 
archetype-parsing, so I have that property without  the consensus with 
the specs, and I do not see it as a waste. I make sure that when I have 
to export data to an OpenEHR system, I will put the archetype_id in the 
archetype_node_id property.

Thanks for the discussion, sorry that we could not find an agreement.

regards
Bert
-- next part --
An HTML attachment was scrubbed...
URL: 

Polishing node identifier (at-codes) use cases.

[Thomas Beale]

On 23/09/2013 11:57, Diego Bosc? wrote:
> How does this 'unknown' value relate to the discussions we already had 
> regarding the need of having all at codes present in the ontology?

it's a fake node id value I use in the ADL workbench compiler, just to 
guarantee the non-void non-empty requirement. Like I said earlier, I 
would rather make the field optional, but mandatory if there are siblings.

- thomas

Polishing node identifier (at-codes) use cases.

[Thomas Beale]

On 25/09/2013 00:53, Bert Verhees wrote:
>
>> sure - if you have a separate property to store the archetype id, it 
>> is empty in 95% of all object instances, and also you need a class 
>> invariant to prevent it being filled at the same time as the 
>> archetype_node_id (at-code) property.
>
> I must disagree, it is very common in archetypes, I think it is in 90% 
> of the archetypes that the root of a definition also has a node_id. 

It's 100% ;-)

But what i meant was that in any instance structure, say a Composition, 
most of the nodes in the data tree will have an at-code in 
archetype_node_id, only a few - the archetype root points - will have 
archetype ids.

The at-node corresponding to the root point is just the at code (or 
a specialised version of that). Putting that in the data is not much use.

> So in that case both can occur simultaneously. But in the path only 
> the archetype_id will occur, and it is easier for a programmer to find 
> which one is the archetype_id if it is in a separate property.

well there is already a property - archteype_details - for that purpose. 
Originally we did think of putting the at codes in 
archetype_node_id, and putting the archetype id in the archetype_details 
property, which is a separate object. (Somee) developers found it was 
too annoying to use like that, so we changed to the current way of using 
the properties.

>
> And anyway, I don't think a seldom used property is a waste. It is 
> only bits and bytes, and there is hardly any code involved having this 
> property. But as I showed in example, not having this property can 
> make many thousands of lines code-execution necessary. That is a waste.
>
> We, system-builders, and special system-designers like you, do not 
> decide which archetypes are going to be used.
> There are archetypes of megabytes, they exist. I don't think it is 
> wise to have them, but it is that modeling is not always focused on 
> performance, but more on academical medical ideas.
> We, builders of two level modeling systems, we must be able to live 
> with this kind of academic exercises.
>
> But those archetypes cost one second ore more, just parsing on a 
> medium speed computer.
> You don't want to do this unnecessary, you don't want to parse that 
> kind of archetypes at every data-entry. It breaks your system.

well you wouldn't be parsing archetypes at data entry - they have to be 
pre-parsed, validated, and used to generate Operational Templates (OPTs) 
which are the final XML structures stored in the server.

>
> Because there is no sure way of analyzing a string and find out if it 
> is an archetype_node_id or an archetype_id in slotted situations 
> besides parsing and analyzing the archetype, this will make the 
> situation of having one property for two different values inefficient, 
> and in some situations dramatic inefficient.

as I said in he previous post, you can just check if archetype_details 
!= null

>>>
>>
>> If you are referring to what the data instance structure looks like, 
>> yes if the reference model says it is inline (i.e. included by value) 
>> then that's what it is. The corresponding archetype structure 
>> technically could be made of multiple archetypes, connected by slots, 
>> or by one large archetype acting as a template.
>
> The idea of what I was saying, I think I can express it more clear 
> now, is that there are two ways of embedding a slotted dataset (based 
> on an archetype which fits in the slot) in the containing dataset 
> (based on the archetype which has the slot, so to say, the containing 
> archetype)
>
> One way is to add a reference to the container-dataset, which points 
> to the slotted dataset.
> The other way is to add the slotted dataset materialized in the 
> container-dataset.
> (The expression "materialized" is from oracle)
>
> The first one is not described in the specs, so to say, there is no 
> spec which indicates how to reference the datasets.
> In theory the specs expect the second situation. The paths in AQL or 
> templates are defined if the slotted datasets are materialized inside 
> the containing dataset.
> This is also the most simple way to do this.

correct

>
> This causes, however, a problem.
>
> Imagine you have a dataset and you want to express a path to a 
> leaf-value.
> You must know in that case if there are slotted datasets in it, 
> because the path will follow other syntax rules in case of slots.
>
> So in a PERSON without slots a contact would look like this
>
> [person-archetype]/contacts[at0003]/items[at0004].
>
> In a PERSON with slots it would look like this.
> [person-archetype]/contacts[at0003]/[contact_archetypeId]/items[at0004].
>
> So if you have a large dataset and you want to express ADL-paths to 
> leaf-nodes, you need to know if there are slots.
> There is one way to find out. Parse the according archetype and find 
> out if there are slots.

well the more obvious way to find out is to parse

Polishing node identifier (at-codes) use cases.

[Bert Verhees]

Op 24-9-2013 19:54, Thomas Beale schreef:
> On 24/09/2013 00:10, Bert Verhees wrote:
>>
>>>
>>> For that reason I believe specifications should very carefully 
>>> specify things. I'll give a very simple example. The openEHR 
>>> specifications routinely specify which properties of a class are 
>>> mandatory, optional, and which String fields have to be non-empty. 
>>> Even those simple things help save time.
>>
>> What time do you save? Allowing developers to write sloppy code 
>> because they don't need to check for a null-value?
>> Do you think that professional programmers are not able to apply 
>> basic programming rules, to check for a null value when retrieving 
>> data from a database or external source?
>>
>> I don't know which quality of software-development you expected in 
>> the OpenEHR community when writing this spec, but it does not seem 
>> that you had much confidence in developers, at that time.
>
> it's not developers like you or many of the other careful, thoughtful 
> and professional people on these lists. But there are huge numbers of 
> developers out there whose main job is implementing something else, 
> but who have to quickly 'put something together' for this or that 
> project, typically in a department of health, hospital or other 
> provider site. These people have to write code in a rushed way, and 
> will inevitably solve things as fast as possible without deep 
> contemplation. And yet - those pieces of software routinely end up in 
> real health data processing environments. So the aim of the specs is 
> to reduce errors by this kind of development.
>
> Like I said, particular choices in the specs to achieve that might be 
> wrong, and the community here needs to help improve that.

So we can stop this discussion right here. I respect that you wanted to 
express your opinion on my message, but there is no need for me to 
comment on this. We agree that shit happens all the time, but apart from 
that that you will support a change of spec regarding the empty string 
representing a null value issue.

But we have the other issue of having one property to store two 
different things without indication what is stored. You call having a 
property which is not often used a waste.

>>
>> A waste of a data-property?
>>
>> I do not understand what you are trying to say.  Do you mean that 
>> there are occasions in which a specific property is useless?
>> Because it is not used? Then I must say that OpenEHR has a lot of 
>> waste, because there are many properties which are not used all the time.
>> :)
>
> sure - if you have a separate property to store the archetype id, it 
> is empty in 95% of all object instances, and also you need a class 
> invariant to prevent it being filled at the same time as the 
> archetype_node_id (at-code) property.

I must disagree, it is very common in archetypes, I think it is in 90% 
of the archetypes that the root of a definition also has a node_id. So 
in that case both can occur simultaneously. But in the path only the 
archetype_id will occur, and it is easier for a programmer to find which 
one is the archetype_id if it is in a separate property.

And anyway, I don't think a seldom used property is a waste. It is only 
bits and bytes, and there is hardly any code involved having this 
property. But as I showed in example, not having this property can make 
many thousands of lines code-execution necessary. That is a waste.

We, system-builders, and special system-designers like you, do not 
decide which archetypes are going to be used.
There are archetypes of megabytes, they exist. I don't think it is wise 
to have them, but it is that modeling is not always focused on 
performance, but more on academical medical ideas.
We, builders of two level modeling systems, we must be able to live with 
this kind of academic exercises.

But those archetypes cost one second ore more, just parsing on a medium 
speed computer.
You don't want to do this unnecessary, you don't want to parse that kind 
of archetypes at every data-entry. It breaks your system.

Because there is no sure way of analyzing a string and find out if it is 
an archetype_node_id or an archetype_id in slotted situations besides 
parsing and analyzing the archetype, this will make the situation of 
having one property for two different values inefficient, and in some 
situations dramatic inefficient.
>> One way is:
>> Having different instances, connected via a not in the specs defined 
>> connection indicating that one instance should be placed inside the 
>> property of another instance.
>> Talking about errors, here is a situation in which the specs fail to 
>> indicate how the connection must be made, and it is left to implementors.
>>
>> Seeing that the spec fail to specify this (and the specs want to 
>> protect us against simple programming-errors), we must conclude that 
>> the specs want us to really implement archetype-slotted instances to 
>> be a materialized part of the contai

Polishing node identifier (at-codes) use cases.

[Thomas Beale]

On 24/09/2013 00:10, Bert Verhees wrote:
>
>>
>> For that reason I believe specifications should very carefully 
>> specify things. I'll give a very simple example. The openEHR 
>> specifications routinely specify which properties of a class are 
>> mandatory, optional, and which String fields have to be non-empty. 
>> Even those simple things help save time.
>
> What time do you save? Allowing developers to write sloppy code 
> because they don't need to check for a null-value?
> Do you think that professional programmers are not able to apply basic 
> programming rules, to check for a null value when retrieving data from 
> a database or external source?
>
> I don't know which quality of software-development you expected in the 
> OpenEHR community when writing this spec, but it does not seem that 
> you had much confidence in developers, at that time.

it's not developers like you or many of the other careful, thoughtful 
and professional people on these lists. But there are huge numbers of 
developers out there whose main job is implementing something else, but 
who have to quickly 'put something together' for this or that project, 
typically in a department of health, hospital or other provider site. 
These people have to write code in a rushed way, and will inevitably 
solve things as fast as possible without deep contemplation. And yet - 
those pieces of software routinely end up in real health data processing 
environments. So the aim of the specs is to reduce errors by this kind 
of development.

Like I said, particular choices in the specs to achieve that might be 
wrong, and the community here needs to help improve that.

>
>>
>> Now, the actual openEHR specs of course have some errors, and wrong 
>> decisions. The original specs that most people use today (but are 
>> about to be revised) probably have some wrong decisions made by me, 
>> as a best guess at the time of the best way to limit ambiguity.
>>
>> So what is really needed is for the communities around each 
>> development technology to build up common reference software 
>> components that become the one true way (for today) of doing X in 
>> Java, or Y in Python. If developers start saying 'X is a strange 
>> decision', and upon analysis, there is a better way to do X with no 
>> impact on data, quality, performance etc, we should do it. That's how 
>> we should progress.
>>
>> But I don't believe in 'leave it to the programmers' because I don't 
>> believe in 'programming', I only believe in 'design', carried out at 
>> different levels of granularity.
>
> It is inefficient to have an empty string instead of a null value, it 
> is a waste of processor-time. Now, programmers must check for the 
> contents of a string, if it is empty then it must be considered null.

I agree that's usually true. However sometimes there are reasons to 
never want a null field, which guarantees that software will always deal 
with the value safely rather than crashing unexpectedly. Occasionally it 
makes sense to do the same with Lists - ensure there is one, even if 
occasionally empty.

> Checking for a null-string (which does not exist in memory) is much 
> more efficient. No String calculations needed, no object creation, etc.
> It is basic code-optimization, never instantiate a variable if you 
> want it to be null. Your specs force software to be unnecessary 
> inefficient.

like I said, in this case, it might make sense to change the spec.

>
> You are taking responsibility for errors bad or unexperienced 
> programmers could eventually make.
> It shows disdain for most developers. Ivory tower we call that in the 
> Netherlands.

you have to realise that specification authors (should) try to minimise 
ambiguity and therefore possible errors for all users of a standard. The 
unfortunate reality is that everyone programs these days, and many 
people (who might be surgeons or senior administrators!) do part-time 
programming, but probably not very well. That's the world today...


>
>> Well we thought about that a long time ago, and the view was that 
>> then you will have two fields in every LOCATABLE, one of which 
>> (hopefully) is null/void in each actual instance. This could easily 
>> lead to errors, and wastes a data property.
>
> I don't see any errors for having different properties for different 
> things.
> I see errors in having different things in the same property.
>
> A waste of a data-property?
>
> I do not understand what you are trying to say.  Do you mean that 
> there are occasions in which a specific property is useless?
> Because it is not used? Then I must say that OpenEHR has a lot of 
> waste, because there are many properties which are not used all the time.
> :)

sure - if you have a separate property to store the archetype id, it is 
empty in 95% of all object instances, and also you need a class 
invariant to prevent it being filled at the same time as the 
archetype_node_id (at-code) property.

If it's a single property,

Polishing node identifier (at-codes) use cases.

[Bert Verhees]

Op 23-9-2013 14:21, Thomas Beale schreef:
> On 23/09/2013 11:47, Bert Verhees wrote:
>> On 09/23/2013 10:38 AM, Thomas Beale wrote:
>>> On 20/09/2013 20:40, Bert Verhees wrote:
 Op 20-9-2013 17:01, Thomas Beale schreef:
> it's simpler than you think - we made that property mandatory so 
> that programmers would never get a null exception.
 Must have been along time ago, nowerdays, programmers have no 
 problem handling a null property.
>>>
>>> actually, that's not quite true. It's probably the primary reason 
>>> for exceptions in object-oriented software - method call on a void 
>>> object. But I get what you are saying, and for this String field, 
>>> being null would not pose a great problem. So we could change the 
>>> spec to do that.
>>
>> Yes, it is very easy to catch a null-exception and then do something 
>> with that information. Anyway, IMHO, specs should not solve technical 
>> problems, and they mostly don't do that. I believe this is also 
>> defined in UML.
>>
>> Technical problems are for implementers to solve.
>
> Hi Bert,
>
> I don't happen to believe in that philosophy. Here's why: if you leave 
> too much open, for implementers to constantly decide, then the 1,000 
> people (let's say) who download your specification will solve .. [ 
> skip, skip, skip ] ..problems. That's 333 x 10 = another 3,330 
> hours gone.

Sorry for skipping this, but I don't think this is relevant in the 
discussion.

There is really something good in the UML-philosophy which says not to 
interfere in implementing, but keep specifications clean of 
implementation-issues.
In this discussion are two things which illustrate that very well.

Specifications thought of some time ago have tried to solve 
possible-implementation-errors by interfering in software-development.
You are demonstrating that this UML-philosophy is good. I will explain this.

First, we can say about the specs that they are most of the text 
designed with this UML-philosophy in mind: no database-platform defined, 
no database structure defined, no programming language, no platform 
defined, everything in the OpenEHR-specs is open in a way that honors 
this UML-philosophy, which I think is good.

But there are a few exceptions in the OpenEHR-design:
One is having a small issue in the design explained in this argument:  
"we made that property mandatory so that programmers would never get a 
null exception. ".
The other is having one single property in the design for different 
things, to avoid errors, as you explain below (I disagree).

And then you bring in some arbitrary calculations as argument, I already 
skipped them.
> That's 5,330 hours, or over 2 person years. It clearly makes sense to 
> spend 10, 2 .. [skip, skip, skip] .. at ambiguity is the enemy 
> of good software and interoperability, and of efficiency in development.
>
> For that reason I believe specifications should very carefully specify 
> things. I'll give a very simple example. The openEHR specifications 
> routinely specify which properties of a class are mandatory, optional, 
> and which String fields have to be non-empty. Even those simple things 
> help save time.

What time do you save? Allowing developers to write sloppy code because 
they don't need to check for a null-value?
Do you think that professional programmers are not able to apply basic 
programming rules, to check for a null value when retrieving data from a 
database or external source?

I don't know which quality of software-development you expected in the 
OpenEHR community when writing this spec, but it does not seem that you 
had much confidence in developers, at that time.

>
> Now, the actual openEHR specs of course have some errors, and wrong 
> decisions. The original specs that most people use today (but are 
> about to be revised) probably have some wrong decisions made by me, as 
> a best guess at the time of the best way to limit ambiguity.
>
> So what is really needed is for the communities around each 
> development technology to build up common reference software 
> components that become the one true way (for today) of doing X in 
> Java, or Y in Python. If developers start saying 'X is a strange 
> decision', and upon analysis, there is a better way to do X with no 
> impact on data, quality, performance etc, we should do it. That's how 
> we should progress.
>
> But I don't believe in 'leave it to the programmers' because I don't 
> believe in 'programming', I only believe in 'design', carried out at 
> different levels of granularity.

It is inefficient to have an empty string instead of a null value, it is 
a waste of processor-time. Now, programmers must check for the contents 
of a string, if it is empty then it must be considered null.
Checking for a null-string (which does not exist in memory) is much more 
efficient. No String calculations needed, no object creation, etc.
It is basic code-optimization, never instantiate a variable if you want 
it 

Polishing node identifier (at-codes) use cases.

[Thomas Beale]

On 23/09/2013 11:47, Bert Verhees wrote:
> On 09/23/2013 10:38 AM, Thomas Beale wrote:
>> On 20/09/2013 20:40, Bert Verhees wrote:
>>> Op 20-9-2013 17:01, Thomas Beale schreef:
 it's simpler than you think - we made that property mandatory so 
 that programmers would never get a null exception.
>>> Must have been along time ago, nowerdays, programmers have no 
>>> problem handling a null property.
>>
>> actually, that's not quite true. It's probably the primary reason for 
>> exceptions in object-oriented software - method call on a void 
>> object. But I get what you are saying, and for this String field, 
>> being null would not pose a great problem. So we could change the 
>> spec to do that.
>
> Yes, it is very easy to catch a null-exception and then do something 
> with that information. Anyway, IMHO, specs should not solve technical 
> problems, and they mostly don't do that. I believe this is also 
> defined in UML.
>
> Technical problems are for implementers to solve.

Hi Bert,

I don't happen to believe in that philosophy. Here's why: if you leave 
too much open, for implementers to constantly decide, then the 1,000 
people (let's say) who download your specification will solve those 
problems individually. Some may talk on lists, but essentially (knowing 
developers as I do) they will mostly solve it on their own. Let's say 
each of those people takes average 2 hours to decide and test a solution 
for a given problem. That's 2,000 hours gone. Many of these solutions 
will be different, and many will have bugs or even be wrong. Let's say 
30% are buggy / wrong. Let's say there is 10 hours average remedial time 
to fix each of these problems. That's 333 x 10 = another 3,330 hours gone.

That's 5,330 hours, or over 2 person years. It clearly makes sense to 
spend 10, 20 or even 50 hours centrally to find a definitive answer once 
and publish that, rather than waste 2.5 person years at the periphery, 
creating low-grade chaos!

In addition, some let's say 1% of the original - that's 10 
implementations - have not only bugs, but bugs that cause patient harm 
or economic damage (e.g. wrong query results, downtime etc). Who knows 
what the cost of that will be.

Worse than all of this is the fact that many of the 1,000 solutions to 
the problem will be different, perhaps 100 flavours. That means we have 
100 flavours of solution to just that one tiny issue in the original 
specifications. On its own, that's a virtual guarantee that those 
solutions will not work interoperably without some small adjustment or 
remediation. The correction is probably small. However, if there are 100 
similar decisions / issues in the specifications we are talking about a 
combinatorial explosion of millions of variants of what should be the 
same software component (or at least the same one within each 
programming language / technology), and that is a huge interoperability 
problem.

My belief is that ambiguity is the enemy of good software and 
interoperability, and of efficiency in development.

For that reason I believe specifications should very carefully specify 
things. I'll give a very simple example. The openEHR specifications 
routinely specify which properties of a class are mandatory, optional, 
and which String fields have to be non-empty. Even those simple things 
help save time.

Now, the actual openEHR specs of course have some errors, and wrong 
decisions. The original specs that most people use today (but are about 
to be revised) probably have some wrong decisions made by me, as a best 
guess at the time of the best way to limit ambiguity.

So what is really needed is for the communities around each development 
technology to build up common reference software components that become 
the one true way (for today) of doing X in Java, or Y in Python. If 
developers start saying 'X is a strange decision', and upon analysis, 
there is a better way to do X with no impact on data, quality, 
performance etc, we should do it. That's how we should progress.

But I don't believe in 'leave it to the programmers' because I don't 
believe in 'programming', I only believe in 'design', carried out at 
different levels of granularity.

>
> That is why this is a strange decision.
>
>>
>>>
>>> I wonder what the idea behind stuffing the archetype_id in the 
>>> archetype_node_id property is?
>>> Here you make it harder for programmers because the archetype_id has 
>>> another syntax in archetype-paths then the archetype_node_id has, 
>>> and anyway, lots of other functions, and a programmer has to check 
>>> the string-layout to find out if it is an archetype_id or an 
>>> archetype_node_id. It also blocks the possibility to store the 
>>> "at"-code for the root, and check the ontology for its contents.
>>
>> the idea is that there is only one field to look at to find archetype 
>> identifying information in data. It is either an archetype_id (string 
>> form) or an at-code, or (for systems that support it) it's em

Polishing node identifier (at-codes) use cases.

[Diego Boscá]

How does this 'unknown' value relate to the discussions we already had
regarding the need of having all at codes present in the ontology?


2013/9/23 Thomas Beale 

> On 20/09/2013 20:40, Bert Verhees wrote:
>
>> Op 20-9-2013 17:01, Thomas Beale schreef:
>>
>>> it's simpler than you think - we made that property mandatory so that
>>> programmers would never get a null exception.
>>>
>> Must have been along time ago, nowerdays, programmers have no problem
>> handling a null property.
>>
>
> actually, that's not quite true. It's probably the primary reason for
> exceptions in object-oriented software - method call on a void object. But
> I get what you are saying, and for this String field, being null would not
> pose a great problem. So we could change the spec to do that.
>
>
>
>> I wonder what the idea behind stuffing the archetype_id in the
>> archetype_node_id property is?
>> Here you make it harder for programmers because the archetype_id has
>> another syntax in archetype-paths then the archetype_node_id has, and
>> anyway, lots of other functions, and a programmer has to check the
>> string-layout to find out if it is an archetype_id or an archetype_node_id.
>> It also blocks the possibility to store the "at"-code for the root, and
>> check the ontology for its contents.
>>
>
> the idea is that there is only one field to look at to find archetype
> identifying information in data. It is either an archetype_id (string form)
> or an at-code, or (for systems that support it) it's empty / 'unknown'
> (which could be replaced by null/void). With the archetype id, you can
> always look up the archetype and find out the root code (at, or a
> matching pattern like at.1 or at.1.1). But if you can't look up the
> archetype, you are lost, and that's what the archetype_id is for.
>
> - thomas
>
>
>
> __**_
> openEHR-technical mailing list
> openEHR-technical at lists.**openehr.org lists.openehr.org>
> http://lists.openehr.org/**mailman/listinfo/openehr-**
> technical_lists.openehr.org
>
-- next part --
An HTML attachment was scrubbed...
URL: 

Polishing node identifier (at-codes) use cases.

[Bert Verhees]

Now the same message but the last sentence in better English :)
(sorry for that)

On 09/23/2013 10:38 AM, Thomas Beale wrote:
> On 20/09/2013 20:40, Bert Verhees wrote:
>> Op 20-9-2013 17:01, Thomas Beale schreef:
>>> it's simpler than you think - we made that property mandatory so 
>>> that programmers would never get a null exception.
>> Must have been along time ago, nowerdays, programmers have no problem 
>> handling a null property.
>
> actually, that's not quite true. It's probably the primary reason for 
> exceptions in object-oriented software - method call on a void object. 
> But I get what you are saying, and for this String field, being null 
> would not pose a great problem. So we could change the spec to do that.

Yes, it is very easy to catch a null-exception and then do something 
with that information. Anyway, IMHO, specs should not solve technical 
problems, and they mostly don't do that. I believe this is also defined 
in UML.

Technical problems are for implementers to solve.

That is why this is a strange decision.

>
>>
>> I wonder what the idea behind stuffing the archetype_id in the 
>> archetype_node_id property is?
>> Here you make it harder for programmers because the archetype_id has 
>> another syntax in archetype-paths then the archetype_node_id has, and 
>> anyway, lots of other functions, and a programmer has to check the 
>> string-layout to find out if it is an archetype_id or an 
>> archetype_node_id. It also blocks the possibility to store the 
>> "at"-code for the root, and check the ontology for its contents.
>
> the idea is that there is only one field to look at to find archetype 
> identifying information in data. It is either an archetype_id (string 
> form) or an at-code, or (for systems that support it) it's empty / 
> 'unknown' (which could be replaced by null/void). With the archetype 
> id, you can always look up the archetype and find out the root code 
> (at, or a matching pattern like at.1 or at.1.1). But if 
> you can't look up the archetype, you are lost, and that's what the 
> archetype_id is for.

The point is, the archetype_id is stored in the property 
archetype_node_id, Pablo implemented it like that in XML, and he found 
in the specs it should be that way. I think this is an unneeded 
complication of the specs. Better was to assign a special property for 
the archetype_id, besides the archetype_node_id.

He found this spec in common.pdf, section 3.1.2 where is stated:
"The archetype_node_id is the standardised semantic code for a node and 
comes
from the corresponding node in the archetype used to create the data. 
The only exception is at archetype
root points in data, where archetype_node_id carries the archetype 
identifier in string form rather
than an interior node id from an archetype."

This makes it difficult to implement, because, an implementer has to 
test if the archetype_node_id contains an at-code or an archetype_id. 
This can lead to ambiguities, for example if XML contains the 
archetype-slots and the connected instances are embedded, which is legal 
and can really speed up XPath-queries. These possible ambiguities can 
occur because it is not really hard defined what an at-code looks at.

Bert


>
> - 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: 

Polishing node identifier (at-codes) use cases.

[Bert Verhees]

On 09/23/2013 10:38 AM, Thomas Beale wrote:
> On 20/09/2013 20:40, Bert Verhees wrote:
>> Op 20-9-2013 17:01, Thomas Beale schreef:
>>> it's simpler than you think - we made that property mandatory so 
>>> that programmers would never get a null exception.
>> Must have been along time ago, nowerdays, programmers have no problem 
>> handling a null property.
>
> actually, that's not quite true. It's probably the primary reason for 
> exceptions in object-oriented software - method call on a void object. 
> But I get what you are saying, and for this String field, being null 
> would not pose a great problem. So we could change the spec to do that.

Yes, it is very easy to catch a null-exception and then do something 
with that information. Anyway, IMHO, specs should not solve technical 
problems, and they mostly don't do that. I believe this is also defined 
in UML.

Technical problems are for implementers to solve.

That is why this is a strange decision.

>
>>
>> I wonder what the idea behind stuffing the archetype_id in the 
>> archetype_node_id property is?
>> Here you make it harder for programmers because the archetype_id has 
>> another syntax in archetype-paths then the archetype_node_id has, and 
>> anyway, lots of other functions, and a programmer has to check the 
>> string-layout to find out if it is an archetype_id or an 
>> archetype_node_id. It also blocks the possibility to store the 
>> "at"-code for the root, and check the ontology for its contents.
>
> the idea is that there is only one field to look at to find archetype 
> identifying information in data. It is either an archetype_id (string 
> form) or an at-code, or (for systems that support it) it's empty / 
> 'unknown' (which could be replaced by null/void). With the archetype 
> id, you can always look up the archetype and find out the root code 
> (at, or a matching pattern like at.1 or at.1.1). But if 
> you can't look up the archetype, you are lost, and that's what the 
> archetype_id is for.

The point is, the archetype_id is stored in the property 
archetype_node_id, Pablo implemented it like that in XML, and he found 
in the specs it should be that way. I think this is an unneeded 
complication of the specs. Better was to assign a special property for 
the archetype_id, besides the archetype_node_id.

He found this spec in common.pdf, section 3.1.2 where is stated:
"The archetype_node_id is the standardised semantic code for a node and 
comes
from the corresponding node in the archetype used to create the data. 
The only exception is at archetype
root points in data, where archetype_node_id carries the archetype 
identifier in string form rather
than an interior node id from an archetype."

This makes it difficult to implement, because, an implementer has to 
test if the archetype_node_id contains an at-code or an archetype_id. 
This can lead to ambiguities, for example if XML contains the 
archetype-slots and the connected instances are embedded, which is legal 
and can really speed up XPath-queries. This possibility ambiguities is 
special the possible because it is not really hard defined what an 
at-code looks at.

Bert


>
> - 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: 

Polishing node identifier (at-codes) use cases.

[Thomas Beale]

On 20/09/2013 20:40, Bert Verhees wrote:
> Op 20-9-2013 17:01, Thomas Beale schreef:
>> it's simpler than you think - we made that property mandatory so that 
>> programmers would never get a null exception.
> Must have been along time ago, nowerdays, programmers have no problem 
> handling a null property.

actually, that's not quite true. It's probably the primary reason for 
exceptions in object-oriented software - method call on a void object. 
But I get what you are saying, and for this String field, being null 
would not pose a great problem. So we could change the spec to do that.

>
> I wonder what the idea behind stuffing the archetype_id in the 
> archetype_node_id property is?
> Here you make it harder for programmers because the archetype_id has 
> another syntax in archetype-paths then the archetype_node_id has, and 
> anyway, lots of other functions, and a programmer has to check the 
> string-layout to find out if it is an archetype_id or an 
> archetype_node_id. It also blocks the possibility to store the 
> "at"-code for the root, and check the ontology for its contents.

the idea is that there is only one field to look at to find archetype 
identifying information in data. It is either an archetype_id (string 
form) or an at-code, or (for systems that support it) it's empty / 
'unknown' (which could be replaced by null/void). With the archetype id, 
you can always look up the archetype and find out the root code (at, 
or a matching pattern like at.1 or at.1.1). But if you can't 
look up the archetype, you are lost, and that's what the archetype_id is 
for.

- thomas

Polishing node identifier (at-codes) use cases.

[Peter Gummer]

Thomas Beale  wrote:

> On 20/09/2013 12:01, Diego Bosc? wrote:
>> ...
>> There is even an invariant defined as "Archetype_node_id_valid: 
>> archetype_node_id /= Void and then not archetype_node_id.is_empty"
>> How does this work in your current implementations when sometimes the at 
>> code is not present?
> 
> it's simpler than you think - we made that property mandatory so that 
> programmers would never get a null exception. If it doesn't contain an 
> at-code or an archetype id, it can be empty (but not null), or (what the ADL 
> workbench currently does) - it can contain a dummy id like 'unknown' that the 
> software can easily spot and strip out.


I think it has to be the dummy id. According to the invariant, it can't be 
empty.

Peter

Polishing node identifier (at-codes) use cases.

[Bert Verhees]

Op 20-9-2013 17:01, Thomas Beale schreef:
> it's simpler than you think - we made that property mandatory so that 
> programmers would never get a null exception.
Must have been along time ago, nowerdays, programmers have no problem 
handling a null property.

I wonder what the idea behind stuffing the archetype_id in the 
archetype_node_id property is?
Here you make it harder for programmers because the archetype_id has 
another syntax in archetype-paths then the archetype_node_id has, and 
anyway, lots of other functions, and a programmer has to check the 
string-layout to find out if it is an archetype_id or an 
archetype_node_id. It also blocks the possibility to store the "at"-code 
for the root, and check the ontology for its contents.

Bert

Polishing node identifier (at-codes) use cases.

[Thomas Beale]

On 20/09/2013 12:01, Diego Bosc? wrote:
> By the way, I just found out that archetype_node_id from locatable 
> class from the reference model (common_im document, page 22) is 
> obligatory (!!!).
>
> The meaning of the attribute is as follows:
> "Design-time archetype id of this node taken from its generating 
> archetype; used to build archetype paths. Always in the form of an 
> ?at? code, e.g. ?at0005?. This value enables a "standardised" name for 
> this node to be generated, by referring to the generating archetype 
> local ontology. At an archetype root point, the value of this 
> attribute is always the stringified form of the archetype_id found in 
> the archetype_details object."
> If you have to put the at code and the archetype does not have it, 
> what do you put there? What should expect the systems?
>
>
> There is even an invariant defined as "Archetype_node_id_valid: 
> archetype_node_id /= Void and then not archetype_node_id.is_empty"
> How does this work in your current implementations when sometimes the 
> at code is not present?

it's simpler than you think - we made that property mandatory so that 
programmers would never get a null exception. If it doesn't contain an 
at-code or an archetype id, it can be empty (but not null), or (what the 
ADL workbench currently does) - it can contain a dummy id like 'unknown' 
that the software can easily spot and strip out.

I'm not against making it an optional property if developers would 
prefer that.

- thomas

Polishing node identifier (at-codes) use cases.

[Diego Boscá]

By the way, I just found out that archetype_node_id from locatable class
from the reference model (common_im document, page 22) is obligatory (!!!).

The meaning of the attribute is as follows:
"Design-time archetype id of this node taken from its generating archetype;
used to build archetype paths. Always in the form of an ?at? code, e.g.
?at0005?. This value enables a "standardised" name for this node to be
generated, by referring to the generating archetype local ontology. At an
archetype root point, the value of this attribute is always the stringified
form of the archetype_id found in the archetype_details object."
If you have to put the at code and the archetype does not have it, what
do you put there? What should expect the systems?


There is even an invariant defined as "Archetype_node_id_valid:
archetype_node_id /= Void and then not archetype_node_id.is_empty"
How does this work in your current implementations when sometimes the
at code is not present?


2013/9/2 Thomas Beale 

>  On 02/09/2013 08:49, David Moner wrote:
>
>
>
>
> 2013/9/2 Thomas Beale 
>>
>>
>>  Well, LinkEHR is a real implementation in use by several organizations,
>> and we think these identifiers are needed both technically and
>> methodologically, so we will continue our way of doing thing :-)
>>
>>
>>  To be clear, I didn't mean modelling tools, I meant production EHR
>> systems that use the resulting models.
>>
>
>  Of course, me too:
> http://www.eurorec.org/news_events/newsArchive.cfm?newsID=239
>
>
> Yep, I know about that (the more systems the better!). But I would be
> interested to know what the clinical models look like - are they posted
> anywhere? And what is the clinical modelling process? I would think after a
> few years of it, there would be some ideas on which nodes need to be
> defined and which don't? I'm just trying to get some evidence here, so we
> can better understand the right set of rules to use in the formalism and
> its tooling.
>
> - 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: 

Polishing node identifier (at-codes) use cases.

[David Moner]

2013/9/2 Thomas Beale 

>  On 02/09/2013 08:49, David Moner wrote:
>
>
>
>
> 2013/9/2 Thomas Beale 
>>
>>
>>  Well, LinkEHR is a real implementation in use by several organizations,
>> and we think these identifiers are needed both technically and
>> methodologically, so we will continue our way of doing thing :-)
>>
>>
>>  To be clear, I didn't mean modelling tools, I meant production EHR
>> systems that use the resulting models.
>>
>
>  Of course, me too:
> http://www.eurorec.org/news_events/newsArchive.cfm?newsID=239
>
>
> Yep, I know about that (the more systems the better!). But I would be
> interested to know what the clinical models look like - are they posted
> anywhere? And what is the clinical modelling process? I would think after a
> few years of it, there would be some ideas on which nodes need to be
> defined and which don't? I'm just trying to get some evidence here, so we
> can better understand the right set of rules to use in the formalism and
> its tooling.
>
>

I have uploaded some archetypes to
http://www.en13606.org/resources/files/cat_view/67-sample-archetypes

They correspond to the ISO EN 13606 archetypes of the Patient Summary
document of the Fuenlabrada Hospital. They are only in Spanish. They are
mainly based on openEHR archetypes from the CKM, but also enriched with
some information from NEHTA specifications and from the Spanish law for
clinical documentation.

[image: Im?genes integradas 1]



-- 
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: 

-- next part --
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 93093 bytes
Desc: not available
URL: 

Polishing node identifier (at-codes) use cases.

[Peter Gummer]

pablo pazos  wrote:

> I would like to see both Archetype Editors to support this profile: to open 
> an archetype with the default behaviour of the specs (not having a nodeID for 
> every node) on LinkEHR Ed. and work ok, and open a profiled archetype in 
> Ocean AE and also work ok.
> 
> Is that tough to do?


Never having seen a LinkEHR archetype myself, I can't say for sure how tough it 
would be to open one in the Ocean AE successfully and then make sure that the 
at-codes are preserved in the ADL and XML output, Pablo. I would guess that it 
would take a couple of days at least ? and then it would have to be tested to 
make sure that the enhancement didn't break any other functionality. I don't 
have a couple of days right now to spend on something that has no business case 
behind it.

But a good first step towards making such a business case would be if someone 
who needs this enhancement could find a few minutes to raise the issue on Jira 
? with an example :-)

Peter
-- next part --
An HTML attachment was scrubbed...
URL: 

Polishing node identifier (at-codes) use cases.

[David Moner]

2013/9/2 Thomas Beale 
>
>
>  Well, LinkEHR is a real implementation in use by several organizations,
> and we think these identifiers are needed both technically and
> methodologically, so we will continue our way of doing thing :-)
>
>
> To be clear, I didn't mean modelling tools, I meant production EHR systems
> that use the resulting models.
>

Of course, me too:
http://www.eurorec.org/news_events/newsArchive.cfm?newsID=239



> I'm still not really clear on the rules that LinkEHR uses to decide when
> at-codes are not defined in the archetype ontology section.
>
>
The rules are:
- Every archetype node always has an explicit unique identifier. We use the
at codes to do so, to minimize the impact with current ADL.
- The archetype authors decide, during the definition and review process,
which nodes need or have a description or terminology binding due to
clinical reasons.



-- 
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: 

Polishing node identifier (at-codes) use cases.

[pablo pazos]

Hi David, IMO LInkEHR rules are a profile of the rules in the specs, that 
shouldn't make incompatible archetypes between tooling.
I would like to see both Archetype Editors to support this profile: to open an 
archetype with the default behaviour of the specs (not having a nodeID for 
every node) on LinkEHR Ed. and work ok, and open a profiled archetype in Ocean 
AE and also work ok.
Is that tough to do?
As a developer / investigator / trainer, I really don't care about the 
decisions made but each software provider, I just need stuff to work :-)
E.g. I wish one day on an openEHR workshop I can give the option of choosing 
the Archetype Editor to work with. Right now I only have one option that I know 
works with archetypes on the CKM, the Ocean one. And some time ago I tried 
LinkEHR Ed. and it was nice. I wish I can work with that today.

-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com

From: dam...@gmail.com
Date: Mon, 2 Sep 2013 09:49:06 +0200
Subject: Re: Polishing node identifier (at-codes) use cases.
To: openehr-technical at lists.openehr.org




2013/9/2 Thomas Beale 





Well, LinkEHR is a real implementation in use by
  several organizations, and we think these identifiers are
  needed both technically and methodologically, so we will
  continue our way of doing thing :-)
  

  



To be clear, I didn't mean modelling tools, I meant production EHR
systems that use the resulting models.

Of course, me too: 
http://www.eurorec.org/news_events/newsArchive.cfm?newsID=239 








I'm still not really clear on the rules that LinkEHR uses to decide
when at-codes are not defined in the archetype ontology section.




The rules are:- Every archetype node always has an explicit unique identifier. 
We use the at codes to do so, to minimize the impact with current ADL.

- The archetype authors decide, during the definition and review process, which 
nodes need or have a description or terminology binding due to clinical reasons.

-- 


David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.eshttp://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)


___
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/20130902/53db8a17/attachment.html>

Polishing node identifier (at-codes) use cases.

[Thomas Beale]

On 02/09/2013 08:49, David Moner wrote:
>
>
>
> 2013/9/2 Thomas Beale  >
>
>>
>> Well, LinkEHR is a real implementation in use by several
>> organizations, and we think these identifiers are needed both
>> technically and methodologically, so we will continue our way of
>> doing thing :-)
>
> To be clear, I didn't mean modelling tools, I meant production EHR
> systems that use the resulting models.
>
>
> Of course, me too: 
> http://www.eurorec.org/news_events/newsArchive.cfm?newsID=239

Yep, I know about that (the more systems the better!). But I would be 
interested to know what the clinical models look like - are they posted 
anywhere? And what is the clinical modelling process? I would think 
after a few years of it, there would be some ideas on which nodes need 
to be defined and which don't? I'm just trying to get some evidence 
here, so we can better understand the right set of rules to use in the 
formalism and its tooling.

- thomas



-- next part --
An HTML attachment was scrubbed...
URL: 

Polishing node identifier (at-codes) use cases.

[David Moner]

2013/8/30 Thomas Beale 

>
> You are probably right. I think for the moment I would like to get ADL/AOM
> 1.5 completed (more or less) with the current assumptions, at least until
> we can obtain some more evidence (particularly from vendor companies with
> actual production implementations) and modellers whose archetypes are
> deployed for real, that would show that we need to change the current
> status quo. Call me conservative, but I don't like changing things without
> real world justification!
>
>
Well, LinkEHR is a real implementation in use by several organizations, and
we think these identifiers are needed both technically and
methodologically, so we will continue our way of doing thing :-)


-- 
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: 

Polishing node identifier (at-codes) use cases.

[Thomas Beale]

On 02/09/2013 07:19, David Moner wrote:
>
>
>
> 2013/8/30 Thomas Beale  >
>
>
> You are probably right. I think for the moment I would like to get
> ADL/AOM 1.5 completed (more or less) with the current assumptions,
> at least until we can obtain some more evidence (particularly from
> vendor companies with actual production implementations) and
> modellers whose archetypes are deployed for real, that would show
> that we need to change the current status quo. Call me
> conservative, but I don't like changing things without real world
> justification!
>
>
> Well, LinkEHR is a real implementation in use by several 
> organizations, and we think these identifiers are needed both 
> technically and methodologically, so we will continue our way of doing 
> thing :-)

To be clear, I didn't mean modelling tools, I meant production EHR 
systems that use the resulting models.

I'm still not really clear on the rules that LinkEHR uses to decide when 
at-codes are not defined in the archetype ontology section.

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 

Polishing node identifier (at-codes) use cases.

[Thomas Beale]

On 30/08/2013 22:02, pablo pazos wrote:
> Wow, that's nice. Thanks Thomas.
> I'll propose the change to the Java Ref Impl project on GitHub (the 
> one I'm using).

You can see the code in C_COMPLEX_OBJECT 
,
 
but most of the pathing logic is supplied by an independent set of OG_XX 
classes (OG = object graph). So the OG_OBJECT_NODE 

 
class has most of the logic.

If you can be bothered, you can get the source and build just to the 
point where you can browse with the Eiffel tool, that will allow you to 
see the code properly. It's all Apache 2 license, take what you want ;-) 
See here  for instructions.

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 

Polishing node identifier (at-codes) use cases.

[pablo pazos]

Wow, that's nice. Thanks Thomas.I'll propose the change to the Java Ref Impl 
project on GitHub (the one I'm using).

-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com

Date: Fri, 30 Aug 2013 15:58:17 +0100
From: thomas.be...@oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: Re: Polishing node identifier (at-codes) use cases.


  

  
  
On 30/08/2013 14:23, pablo pazos wrote:



  
  Hi all,



Maybe this is OT but is related. I remembered a problem I
  had some time ago working with algorithms that traverses the
  archetype structure.



For CObjects without nodeID, the path of the CObject is
  equal to the path of it's parent CAttribute, so when I want to
  get the node with that path using Archetype.node(path), only
  one of those nodes will be returned.
  



the usual thing to do here is to provide two (well actually 4,
including the 'has' ones) functions:



c_attribute_at_path (a_path: String): C_ATTRIBUTE

pre-condition

has_attribute_path (a_path)



c_object_at_path (a_path: String): C_OBJECT

pre-condition

has_object_path (a_path)



in the ADL workbench, we actually pre-compute this in the parse
phase, but that isn't necessary of course.



- 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/20130830/4e023c51/attachment.html>

Polishing node identifier (at-codes) use cases.

[Thomas Beale]

You are probably right. I think for the moment I would like to get 
ADL/AOM 1.5 completed (more or less) with the current assumptions, at 
least until we can obtain some more evidence (particularly from vendor 
companies with actual production implementations) and modellers whose 
archetypes are deployed for real, that would show that we need to change 
the current status quo. Call me conservative, but I don't like changing 
things without real world justification!

If anyone thinks they can invent better rules for node identification in 
the meantime, please feel free to post them. It may be that we can make 
ADL/AOM work in a way that accommodates different 'modes' of operation.

- thomas

On 30/08/2013 07:27, David Moner wrote:
>
>
>
> 2013/8/29 Thomas Beale  >
>
>
> well the idea here has always been, and remains justified today:
>
>   * an archetype-local definition in words for the meaning of the
> node is needed, because this says _exactly_ what the designers
> intended
>   * those meanings are given by domain experts, and (with some
> review, QA process) will be as good as any linguistic
> definition in any ontology or terminology (probably better,
> because they are specific to the case at hand)
>   * if we are lucky enough to find some code that matches, or
> approximately describes the same thing in an ontology and/or
> SNOMED CT / LOINC etc, then we can add those bindings
>
> If we were only allowed to define nodes for which matching codes
> can be found in OBO, SNOMED or other supposedly reliable places,
> then we would have no chance of building anything but the most
> meagre archetypes, and no ability to build semantically enabled
> health information systems.
>
> I don't know of any facts that would contradict this long-standing
> position today...
>
>
> I'm not contradicting those positions, which I agree, I'm just saying 
> that this is a very subjective topic, dependant on the context of use, 
> the availability of some resources (e.g terminological codes) and many 
> other factors. So, we can all do our best but it will be very 
> difficult to have rules that guide which nodes of the archetype have 
> to be identified just based on a structural matter (the rules you 
> asked for).
>
> -

-- next part --
An HTML attachment was scrubbed...
URL: 

Polishing node identifier (at-codes) use cases.

[Thomas Beale]

On 30/08/2013 14:23, pablo pazos wrote:
> Hi all,
>
> Maybe this is OT but is related. I remembered a problem I had some 
> time ago working with algorithms that traverses the archetype structure.
>
> For CObjects without nodeID, the path of the CObject is equal to the 
> path of it's parent CAttribute, so when I want to get the node with 
> that path using Archetype.node(path), only one of those nodes will be 
> returned.

the usual thing to do here is to provide two (well actually 4, including 
the 'has' ones) functions:

c_attribute_at_path (a_path: String): C_ATTRIBUTE
 pre-condition
 has_attribute_path (a_path)

c_object_at_path (a_path: String): C_OBJECT
 pre-condition
 has_object_path (a_path)

in the ADL workbench, we actually pre-compute this in the parse phase, 
but that isn't necessary of course.

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 

Polishing node identifier (at-codes) use cases.

[pablo pazos]

Hi all,
Maybe this is OT but is related. I remembered a problem I had some time ago 
working with algorithms that traverses the archetype structure.
For CObjects without nodeID, the path of the CObject is equal to the path of 
it's parent CAttribute, so when I want to get the node with that path using 
Archetype.node(path), only one of those nodes will be returned.
Of course there are workarounds, like checking the type of the returned node, 
and if a CAttribute is returned but I want the CObject, I just get the 
node.children()[0]. But that only can be implemented if you know that the path 
you're using is a path to a CObject, so it depends on the context of your 
algorithm to expect CObject or CAttribute for a path you have (i.e. if you 
previously visit a CAttribute and you algorithm traverses from root to leaves, 
you'll expect next nodes to be CObjects).
>From a developer point of view, having unique paths would solve a lot of 
>workarounds and ugly code. So having a nodeID for each CObject node is 
>something I would encourage on tooling. I really don't care of having more 
>terms in the ontology :)

-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com

From: dam...@gmail.com
Date: Fri, 30 Aug 2013 08:27:39 +0200
Subject: Re: Polishing node identifier (at-codes) use cases.
To: openehr-technical at lists.openehr.org




2013/8/29 Thomas Beale 



  

  
  


well the idea here has always been, and remains justified today:


  an archetype-local definition in words for the meaning of the
node is needed, because this says _exactly_ what the designers
intended
  those meanings are given by domain experts, and (with some
review, QA process) will be as good as any linguistic definition
in any ontology or terminology (probably better, because they
are specific to the case at hand)

  
  if we are lucky enough to find some code that matches, or
approximately describes the same thing in an ontology and/or
SNOMED CT / LOINC etc, then we can add those bindings

If we were only allowed to define nodes for which matching codes
  can be found in OBO, SNOMED or other supposedly reliable places,
  then we would have no chance of building anything but the most
  meagre archetypes, and no ability to build semantically enabled
  health information systems.



I don't know of any facts that would contradict this
  long-standing position today...





I'm not contradicting those positions, which I agree, I'm just saying that this 
is a very subjective topic, dependant on the context of use, the availability 
of some resources (e.g terminological codes) and many other factors. So, we can 
all do our best but it will be very difficult to have rules that guide which 
nodes of the archetype have to be identified just based on a structural matter 
(the rules you asked for).



-- 
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)




___
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/20130830/64b43b25/attachment.html>

Polishing node identifier (at-codes) use cases.

[David Moner]

2013/8/29 Thomas Beale 

>
> well the idea here has always been, and remains justified today:
>
>- an archetype-local definition in words for the meaning of the node
>is needed, because this says _exactly_ what the designers intended
>- those meanings are given by domain experts, and (with some review,
>QA process) will be as good as any linguistic definition in any ontology or
>terminology (probably better, because they are specific to the case at 
> hand)
> - if we are lucky enough to find some code that matches, or
>approximately describes the same thing in an ontology and/or SNOMED CT /
>LOINC etc, then we can add those bindings
>
> If we were only allowed to define nodes for which matching codes can be
> found in OBO, SNOMED or other supposedly reliable places, then we would
> have no chance of building anything but the most meagre archetypes, and no
> ability to build semantically enabled health information systems.
>
> I don't know of any facts that would contradict this long-standing
> position today...
>
>
I'm not contradicting those positions, which I agree, I'm just saying that
this is a very subjective topic, dependant on the context of use, the
availability of some resources (e.g terminological codes) and many other
factors. So, we can all do our best but it will be very difficult to have
rules that guide which nodes of the archetype have to be identified just
based on a structural matter (the rules you asked for).

-- 
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: 

Polishing node identifier (at-codes) use cases.

[Thomas Beale]

On 29/08/2013 08:30, David Moner wrote:
>
>
> 2013/8/28 Gerard Freriks mailto:gfrer at luna.nl>>
>
> 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.
>
>
> I will stop at this point because I think it is the kernel of the 
> discussion. Which should be the idea?
> - The ontology "must" provide a name or meaning for each at node 
> in an archetype? This is how thing are supposed to work in current 
> specifications
> - The ontology "can" provide a name or meaning for each at node in 
> an archetype? This is how we think it should be, the ontology provides 
> a semantic description only when it is needed or it is possible.

My view (to date, which I am happy to revise if a better theory comes 
into view) has been:
- the ontology section provides a name or meaning for any node whose 
clinical/domain meaning is otherwise not understandable.

That is, it's not needed for:

  * single valued-attributes, one alternative,
  o e.g. ENTRY.protocol in most archetypes is just one constraint
tree, so it just means 'protocol' for whatever kind of Entry it
is, e.g. BP measurement
  * arguably single-valued attributes with multiple alternatives of
different RM types
  o e.g. ELEMENT[at011|cigarettes smoked|].value matches DV_COUNT or
DV_QUANTITY (grams).

The meanings of the above kinds of nodes are comprehensible.

Now, another requirement may be that a unique path can be stated for 
every possible alternative in an archetype. This would force the second 
case above to require codes anyway (which is the current rule).

My question is not which node codes don't need definitions, but which 
nodes don't need codes? And secondarily, are there any nodes that need 
codes that don't need meanings? I struggle to find any example of the 
latter (but I haven't looked that hard).

>
> And what is providing a meaning or semantic description?
> - A terminology binding? Of course, we will rely on terminologies and 
> ontologies for a complete semantic interoperability.
> - A natural language description? Well, here is where no automatic 
> rules can exist to check if a description such as "Systolic blood 
> pressure" or "This is a PQ type node" or "The sky is blue" or " " are 
> correct or have a sense, only a human validation check can work here.

well the idea here has always been, and remains justified today:

  * an archetype-local definition in words for the meaning of the node
is needed, because this says _exactly_ what the designers intended
  * those meanings are given by domain experts, and (with some review,
QA process) will be as good as any linguistic definition in any
ontology or terminology (probably better, because they are specific
to the case at hand)
  * if we are lucky enough to find some code that matches, or
approximately describes the same thing in an ontology and/or SNOMED
CT / LOINC etc, then we can add those bindings

If we were only allowed to define nodes for which matching codes can be 
found in OBO, SNOMED or other supposedly reliable places, then we would 
have no chance of building anything but the most meagre archetypes, and 
no ability to build semantically enabled health information systems.

I don't know of any facts that would contradict this long-standing 
position today...

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 

Polishing node identifier (at-codes) use cases.

[Thomas Beale]

On 29/08/2013 08:12, David Moner wrote:
>
>
> I know that the openEHR archetype editor only allows introducing 
> OBSERVATIONs and the other clinical classes through a slot at the 
> COMPOSITION and SECTION, and probably that is a good methodological 
> approach or good practice to improve archetype governance, but 
> technically it is not the only possibility. You can create an 
> archetype from the top COMPOSITION to the leaf data values in one 
> single archetype.

yeps, that's certainly true, and it could easily make sense in some 
situations.

> And in any case, it is just an example, we can use MY_CLASS_NAME or 
> whatever to avoid thinking this is a problem about how things work at 
> the openEHR reference model.
>
>>
>> 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?
>
>
> To be exact, in our approach all those classes should have an at 
> code, even if it is not described at the ontology section. But in any 
> case, current at rules does not force to put a description with a 
> sense either, except for the root node because it corresponds to the 
> same concept as the archetype identifier when you create the 
> archetype. It is more a duty of the clinical validation team to check 
> those kind of things, not something that can be automatically 
> validated by rules. Look at the following brand new archetype created 
> with the openEHR editor, just choosing an OBSERVATION root:
>
> definition
> OBSERVATION[at] matches {-- Test example
> data matches {
> HISTORY[at0001] matches {-- Event Series
> events cardinality matches {1..*; unordered} matches {
> EVENT[at0002] occurrences matches {0..1} matches {-- Any event
> data matches {
> ITEM_TREE[at0003] matches {*}
> }
> }
> }
> }
> }
> }
>
> ontology
> term_definitions = <
> ["es"] = <
> items = <
> ["at"] = <
> text = <"Test example">
> description = <"unknown">
> >
> ["at0001"] = <
> text = <"Event Series">
> description = <"@ internal @">
> >
> ["at0002"] = <
> text = <"Any event">
> description = <"*">
> >
> ["at0003"] = <
> text = <"Tree">
> description = <"@ internal @">
> >
> >
> >
> >
>
>
> The only "meaning" there is the "Test example" name of the 
> OBSERVATION, because it corresponds to the archetype name. But all the 
> others have no meaning and no existing rules are checking that (having 
> "Event series", "Any event" and "Tree" is the same as not saying 
> anything). So, again, those ontological descriptions will be always 
> checked by the authors, not by the tools.

well, ok, but that's just like saying that a half-made movie isn't 
watchable. Intermediate development states of any semantic object can 
clearly have meaningless placeholders for some period of time, while the 
designer does his/her thinking.

>
> By the way, following the specifications, even that example archetype 
> created with the openEHR editor is not perfect. Both the at0001 and 
> the at0003 codes should not be needed according to the rules, since 
> they are members of single value attributes without sibling nodes...

yes, I agree with that. I forget why that tool does that, but in any 
case, don't take it as a design guide...

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 

Polishing node identifier (at-codes) use cases.

[Gerard Freriks]

Why bring in religion?

I want to understand and ask questions.
And in the meantime I have an opinion based on my 'GBV'. (see below)

> Can you please give reasons for your statements that archetype nodes must be 
> unique concepts and must be uniquely identified? 
> 

Reasons for my statement?
- Each node in an archetype has a meaning
- Without an implicit or explicit meaning the archetype node indicates chaos, 
meaninglessness, nothingness.
- Meaning is attached to the given name of the node or code attached to that 
node
- In the case of specialisations of archetypes several things can happen, one 
of those is renaming the node, changing the meaning
- This changing the name and meaning of the archetype node needs to be 
reflected in a new unique code

So far I have not explained the scope, the jurisdiction, the namespace, of the 
unique codes I'm alluding to.
At the minimum it must be uniquely defined inside the archetype, and in the 
case of a code from an external coding system, it must be unique in that 
namespace.

> I have never been given a scientific reason why every node in an archetype 
> should be uniquely coded or have unique meaning outside the archetype itself. 
> I have never found a use case that makes this necessary but would be 
> interested if anyone can show me one.
> 


It all depends on scope of the archetype. Is it used in an 'open world' or 
'closed world' situation?
When used in a 'closed system' ( two or more actors that have an agreement of 
that what is exchanged, IHE with one profile) there is almost no need for 
external codes attached to archetypes. The explicit or implicit agreement is 
sufficient. Whatever the name in the archetype node, when the agreement says, 
the node name means 'Black', but we take to mean 'White' then there is no 
single problem.
In 'Closed world systems' the highest level of semantic interoperability is 
Level2a/2b at the best. It is the world of messaging with ad-hoc agreements, as 
we know it.

When the archetype is used in an 'open world' system, then we need to be very 
precise and explicit. Any party that interprets the data using the archetype as 
source, where it must find the meaning, needs to be informed fully. No single 
human intervention, human interpretation, must be needed to process fully and 
safely the data exchanged.
Local agreements between actors how to interpret the archetype node name do not 
exist, the archetype itself is the full agreement.
In 'Open world' systems the highest level of semantic interoperability is level 
3.
In this 'open world' situation there are other rules than in the 'closed world' 
situation.


Finally.
Do not create a  dichotomic world where things are either science or religion.
There are many shades.
And in order to surprise you:
Do not underestimate something that I call in Dutch: 'het gezonde boeren 
verstand'. (GBV)
Translated: the common sense of the farmer.
Many obvious things that happen in life, happen because they happen.
I do not have to prove, that water flows, that fire burns, that winds exits, 
for you and me to accept this is true,
with or without a science, with or without any belief system, with or without 
any dogma.

I try to base my own opinions on my 'GBV'.

Gerard Freriks
+31 620347088
gfrer at luna.nl

On 29 aug. 2013, at 00:13, Hugh Leslie  
wrote:

> Hi Gerard, 
> 
> This is science, not religion. Can you please give reasons for your 
> statements that archetype nodes must be unique concepts and must be uniquely 
> identified? 
> 
> In openEHR and 13606, the archetype is the unique concept which means that 
> nodes quite rightly can have unique meaning in the context of the archetype. 
> This is like human language where the same word can have different meanings 
> depending on the context used.
> 
> I have never been given a scientific reason why every node in an archetype 
> should be uniquely coded or have unique meaning outside the archetype itself. 
> I have never found a use case that makes this necessary but would be 
> interested if anyone can show me one. 
> 
> Regards Hugh
> 
> 

-- next part --
An HTML attachment was scrubbed...
URL: 

Polishing node identifier (at-codes) use cases.

[David Moner]

2013/8/28 Gerard Freriks 

> 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.
>
>
I will stop at this point because I think it is the kernel of the
discussion. Which should be the idea?
- The ontology "must" provide a name or meaning for each at node in an
archetype? This is how thing are supposed to work in current specifications
- The ontology "can" provide a name or meaning for each at node in an
archetype? This is how we think it should be, the ontology provides a
semantic description only when it is needed or it is possible.

And what is providing a meaning or semantic description?
- A terminology binding? Of course, we will rely on terminologies and
ontologies for a complete semantic interoperability.
- A natural language description? Well, here is where no automatic rules
can exist to check if a description such as "Systolic blood pressure" or
"This is a PQ type node" or "The sky is blue" or " " are correct or have a
sense, only a human validation check can work here.

-- 
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: 

Polishing node identifier (at-codes) use cases.

[David Moner]

2013/8/28 Thomas Beale 

>  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.
>
>
>

I know that the openEHR archetype editor only allows introducing
OBSERVATIONs and the other clinical classes through a slot at the
COMPOSITION and SECTION, and probably that is a good methodological
approach or good practice to improve archetype governance, but technically
it is not the only possibility. You can create an archetype from the top
COMPOSITION to the leaf data values in one single archetype. And in any
case, it is just an example, we can use MY_CLASS_NAME or whatever to avoid
thinking this is a problem about how things work at the openEHR reference
model.


>
>  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?
>
>
To be exact, in our approach all those classes should have an at code,
even if it is not described at the ontology section. But in any case,
current at rules does not force to put a description with a sense
either, except for the root node because it corresponds to the same concept
as the archetype identifier when you create the archetype. It is more a
duty of the clinical validation team to check those kind of things, not
something that can be automatically validated by rules. Look at the
following brand new archetype created with the openEHR editor, just
choosing an OBSERVATION root:

definition
OBSERVATION[at] matches { -- Test example
data matches {
 HISTORY[at0001] matches { -- Event Series
events cardinality matches {1..*; unordered} matches {
 EVENT[at0002] occurrences matches {0..1} matches { -- Any event
data matches {
 ITEM_TREE[at0003] matches {*}
}
}
 }
}
}
}

ontology
term_definitions = <
["es"] = <
items = <
 ["at"] = <
text = <"Test example">
description = <"unknown">
 >
["at0001"] = <
text = <"Event Series">
 description = <"@ internal @">
>
["at0002"] = <
 text = <"Any event">
description = <"*">
>
 ["at0003"] = <
text = <"Tree">
description = <"@ internal @">
 >
>
>
>


The only "meaning" there is the "Test example" name of the OBSERVATION,
because it corresponds to the archetype name. But all the others have no
meaning and no existing rules are checking that (having "Event series",
"Any event" and "Tree" is the same as not saying anything). So, again,
those ontological descriptions will be always checked by the authors, not
by the tools.

By the way, following the specifications, even that example archetype
created with the openEHR editor is not perfect. Both the at0001 and the
at0003 codes should not be needed according to the rules, since they are
members of single value attributes without sibling nodes...



-- 
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: 

Polishing node identifier (at-codes) use cases.

[Bert Verhees]

On 08/29/2013 08:33 AM, Thomas Beale wrote:
> On 29/08/2013 01:06, Diego Bosc? wrote:
>> don't forget the organization responsible for that archetype ;D
>>
>
> For those who may not realise, Diego is referring (I assume) to the 
> ADL 1.5 namespaced archetype identifiers, which would give paths of 
> the form:
>
> namespace::ARCHETYPE_ID/path[at0002]/to[at0003]/happiness
>
> where the namespace corresponds to the issuing organisation.

I must have missed this announcement, sorry, good that there is a 
solution now.

Bert

Polishing node identifier (at-codes) use cases.

[Bert Verhees]

On 08/29/2013 02:06 AM, Diego Bosc? wrote:
> don't forget the organization responsible for that archetype ;D

True, that is also an old and not yet finished discussion, 
name-collissions in archetypeIds. At this moment there is no solution 
for this in EN13606 and OpenEHR.

Thanks for reminding.

Bert

Polishing node identifier (at-codes) use cases.

[Thomas Beale]

On 29/08/2013 07:39, Bert Verhees wrote:
> On 08/29/2013 08:33 AM, Thomas Beale wrote:
>> On 29/08/2013 01:06, Diego Bosc? wrote:
>>> don't forget the organization responsible for that archetype ;D
>>>
>>
>> For those who may not realise, Diego is referring (I assume) to the 
>> ADL 1.5 namespaced archetype identifiers, which would give paths of 
>> the form:
>>
>> namespace::ARCHETYPE_ID/path[at0002]/to[at0003]/happiness
>>
>> where the namespace corresponds to the issuing organisation.

see wiki page here 

 
and the draft spec here 
.

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 

Polishing node identifier (at-codes) use cases.

[Thomas Beale]

On 29/08/2013 01:06, Diego Bosc? wrote:
> don't forget the organization responsible for that archetype ;D
>

For those who may not realise, Diego is referring (I assume) to the ADL 
1.5 namespaced archetype identifiers, which would give paths of the form:

namespace::ARCHETYPE_ID/path[at0002]/to[at0003]/happiness

where the namespace corresponds to the issuing organisation.

- thomas

Polishing node identifier (at-codes) use cases.

[Diego Boscá]

don't forget the organization responsible for that archetype ;D


2013/8/29 pablo pazos 

> Just use archetypeID+nodeID, then you have a unique concept id for each
> node.
>
>
> --
> Kind regards,
> Eng. Pablo Pazos Guti?rrez
> http://cabolabs.com <http://cabolabs.com/es/home><http://twitter.com/ppazos>
>
> --
> From: hugh.leslie at oceaninformatics.com
> To: openehr-technical at lists.openehr.org; gfrer at luna.nl
> Date: Thu, 29 Aug 2013 00:13:29 +0200
>
> Subject: Re: Polishing node identifier (at-codes) use cases.
>
> Hi Gerard,
>
> This is science, not religion. Can you please give reasons for your
> statements that archetype nodes must be unique concepts and must be
> uniquely identified?
>
> In openEHR and 13606, the archetype is the unique concept which means that
> nodes quite rightly can have unique meaning in the context of the
> archetype. This is like human language where the same word can have
> different meanings depending on the context used.
>
> I have never been given a scientific reason why every node in an archetype
> should be uniquely coded or have unique meaning outside the archetype
> itself. I have never found a use case that makes this necessary but would
> be interested if anyone can show me one.
>
> Regards Hugh
>
>
>
> ----- Original message -
>  *From:*Gerard Freriks  *Date:*28 August 2013 1:26:14 PM *
> Subject:*Re: Polishing node identifier (at-codes) use cases. *To:*For
> openEHR technical discussions 
>
> 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  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 typ

Polishing node identifier (at-codes) use cases.

[Hugh Leslie]

Hi Gerard,

This is science, not religion. Can you please give reasons for your 
statements that archetype nodes must be unique concepts and must be 
uniquely identified?

In openEHR and 13606, the archetype is the unique concept which means that 
nodes quite rightly can have unique meaning in the context of the 
archetype. This is like human language where the same word can have 
different meanings depending on the context used.

I have never been given a scientific reason why every node in an archetype 
should be uniquely coded or have unique meaning outside the archetype 
itself. I have never found a use case that makes this necessary but would 
be interested if anyone can show me one.

Regards Hugh



--- Original message ---
From: Gerard Freriks 
Date: 28 August 2013 1:26:14 PM
Subject: Re: Polishing node identifier (at-codes) use cases.
To: For openEHR technical discussions 

> 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  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 
>

Polishing node identifier (at-codes) use cases.

[pablo pazos]

Yep, that should be necessary in case of archetypeID collisions. Maybe in the 
future we have an archetypeID server (like a DNS protocol) to query for 
archetypeID to globally check for uniqueness.

-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com

From: yamp...@gmail.com
Date: Thu, 29 Aug 2013 02:06:54 +0200
Subject: Re: Polishing node identifier (at-codes) use cases.
To: openehr-technical at lists.openehr.org

don't forget the organization responsible for that archetype ;D


2013/8/29 pablo pazos 





Just use archetypeID+nodeID, then you have a unique concept id for each node.

-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com



From: hugh.les...@oceaninformatics.com
To: openehr-technical at lists.openehr.org; gfrer at luna.nl


Date: Thu, 29 Aug 2013 00:13:29 +0200
Subject: Re: Polishing node identifier (at-codes) use cases.



Hi Gerard, 



This is science, not religion. Can you please give reasons for your
statements that archetype nodes must be unique concepts and must be
uniquely identified? 



In openEHR and 13606, the archetype is the unique concept which means that
nodes quite rightly can have unique meaning in the context of the
archetype. This is like human language where the same word can have
different meanings depending on the context used.



I have never been given a scientific reason why every node in an archetype
should be uniquely coded or have unique meaning outside the archetype
itself. I have never found a use case that makes this necessary but would
be interested if anyone can show me one. 



Regards Hugh






- Original message -


From:Gerard Freriks 
Date:28 August 2013 1:26:14 PM
Subject:Re: Polishing node identifier (at-codes)
use cases.
To:For openEHR technical discussions





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  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 o

Polishing node identifier (at-codes) use cases.

[pablo pazos]

Just use archetypeID+nodeID, then you have a unique concept id for each node.

-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com

From: hugh.les...@oceaninformatics.com
To: openehr-technical at lists.openehr.org; gfrer at luna.nl
Date: Thu, 29 Aug 2013 00:13:29 +0200
Subject: Re: Polishing node identifier (at-codes) use cases.



Hi Gerard, 



This is science, not religion. Can you please give reasons for your
statements that archetype nodes must be unique concepts and must be
uniquely identified? 



In openEHR and 13606, the archetype is the unique concept which means that
nodes quite rightly can have unique meaning in the context of the
archetype. This is like human language where the same word can have
different meanings depending on the context used.



I have never been given a scientific reason why every node in an archetype
should be uniquely coded or have unique meaning outside the archetype
itself. I have never found a use case that makes this necessary but would
be interested if anyone can show me one. 



Regards Hugh






- Original message -


From:Gerard Freriks 
Date:28 August 2013 1:26:14 PM
Subject:Re: Polishing node identifier (at-codes)
use cases.
To:For openEHR technical discussions





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
620347088gfrer at luna.nl


On 28 aug. 2013, at 09: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.
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 configur

Polishing node identifier (at-codes) use cases.

[Peter Gummer]

Bert Verhees  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.

[Peter Gummer]

Bert Verhees  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.

[Gerard Freriks]

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  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: 

Polishing node identifier (at-codes) use cases.

[Bert Verhees]

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.

[Bert Verhees]

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.

[Thomas Beale]

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: 

Polishing node identifier (at-codes) use cases.

[Diego Boscá]

2013/8/28 Bert Verhees :
> 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.

[David Moner]

2013/8/28 Thomas Beale 

>
>
> 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: 

Polishing node identifier (at-codes) use cases.

[Peter Gummer]

Bert Verhees  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 Beale]

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: 

Polishing node identifier (at-codes) use cases.

[Bert Verhees]

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.

[David Moner]

2013/8/27 Thomas Beale 

>
>
>> 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: 

Polishing node identifier (at-codes) use cases.

[Bert Verhees]

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.

[Bert Verhees]

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 Verhees]

On 08/28/2013 08:27 AM, Peter Gummer wrote:
> Bert Verhees  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.

[Bert Verhees]

On 08/28/2013 02:34 AM, Peter Gummer wrote:
> Bert Verhees  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.

[Thomas Beale]

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.

[pablo pazos]

Hi all, very interesting discussion.
> Another use case is when valid children types are part of the same
> class hierarchy (no need for specialization). Do we need at-codes when
> we create siblings such as DV_TEXT and DV_CODED_TEXT?

according to the current rules (see my previous post), yes. I would 
actually still rather avoid this, and am still thinking about it...
Thinking about this case, shouldn't be a better design approach to define 
DV_TEXT at the base archetype, and the DV_CODED_TEXT alternative (with further 
constraints) in a specialized archetype?
So the issue of the codes dissapear and anyone can choose to use the very 
generic archetype or the specialized one.
This is good from an Object Oriented design approach, but right now the 
specializations defined on the CKM are very specific concepts, not just a way 
to simplify modeling and reuse of artifacts (as it is in the case I 
mentioned).I mean, the specialized archetype is not a more specific concept, is 
just the same concept with just "a little" more detail. E.g. if we take 
"Healthcare service request" and "Imaging examinaton request", the specialized 
archetype I would create sits right in the middle of those concepts, in fact is 
closer to the more generic one.
In short, I don't know if this should be defined at the model level or at the 
modeling proess level.

BTW, I aggree with Bert in that we need interoperable archetype design tools. 
Back in 2009 we needed to choose an editor, and we tested LiU, Ocean and 
LinkEHR, and we couldn't load an archetype created by one tool into another 
tool :-/ Maybe now this has improve.
-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com

> Date: Tue, 27 Aug 2013 20:47:11 +0100
> From: thomas.beale at oceaninformatics.com
> To: openehr-technical at lists.openehr.org
> Subject: Re: Polishing node identifier (at-codes) use cases.
> 
> On 27/08/2013 18:20, Diego Bosc? wrote:
> > The problem with this rules come with the (explicit or implicit)
> > specialization of single attributes. take this example:
> >
> >   ELEMENT[at0009] occurrences matches {0..1} matches {  -- Position
> >  value existence matches {0..1} 
> > matches {
> >  DV_TEXT occurrences
> > matches {0..1} matches {*}
> >  }
> >  }
> >
> > What happens if a DV_TEXT is added on the specialization? Does it need
> > at code? Do we consider the rule to be applied to the archetype +
> > parent or only to the archetypes? Do we need to add an at-code also to
> > the parent?
> 
> If it were added in a specialisation with no code, it would be assumed 
> to be a redefinition of an existing DV_TEXT constraint, assuming there 
> was one. If added with a code, the post flattening validation (phase 3) 
> in the current ADL workbench would need to detect this. Right now it 
> doesn't have checks in that phase for this. I'll have to run this 
> example through the compiler to see what it does.
> 
> > This would need either a rewriting of the rule to state the issue with
> > flat archetypes or a potential problem if an at-code is not specified.
> 
> good point; the rules should specify that they apply to flattened 
> archetypes, which means that ids are required even if each 
> specialisation child introduces only one alternative. I'll fix this in 
> the spec.
> 
> >
> > Another use case is when valid children types are part of the same
> > class hierarchy (no need for specialization). Do we need at-codes when
> > we create siblings such as DV_TEXT and DV_CODED_TEXT?
> 
> according to the current rules (see my previous post), yes. I would 
> actually still rather avoid this, and am still thinking about it...
> 
> > If we have several different data types, such as DV_BOOLEAN,
> > DV_QUANTITY, and DV_TEXT and then we want to add a DV_CODED_TEXT,
> > which one of the data types gets an at-code? all? only the text ones?
> > none?
> 
> according to the previous rules, none. But DV_CODED_TEXT would be 
> treated as a preferential constraint over DV_TEXT due to the RM 
> inheritance relationship. It would be up to apps and tools to make use 
> of that.
> 
> >
> > Again, rewording/clarification is needed or problems may occur.
> 
> yes - I doubt that we are at the final version of the wording on this - 
> but have a look at the new version and see what you think.
> 
> >
> > 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 

Polishing node identifier (at-codes) use cases.

[Bert Verhees]

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 .
>
> 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  'openEHR-technical at lists.openehr.org');>
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
>
> --
>   [image: Ocean Informatics]   *Thomas
> Beale
> Chief Technology Officer*
> +44 7792 403 613   Specification Program, *open*EHR
> Honorary Research Fellow, UCL 
> Chartered IT Professional Fellow, BCS 
> Health IT blog    [image:
> View Thomas Beale's profile on LinkedIn]
> 
>
-- next part --
An HTML attachment was scrubbed...
URL: 

Polishing node identifier (at-codes) use cases.

[Diego Boscá]

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 

>
> 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 .
>
> 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]   *Thomas
> Beale
> Chief Technology Officer*
> +44 7792 403 613   Specification Program, *open*EHR
> Honorary Research Fellow, UCL 
> Chartered IT Professional Fellow, BCS 
> Health IT blog    [image:
> View Thomas Beale's profile on LinkedIn]
> 
>
> ___
> 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: 

-- next part --
A non-text attachment was scrubbed...
Name: btn_liprofile_blue_80x15.png
Type: image/png
Size: 511 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: ocean_full_small.jpg
Type: image/jpeg
Size: 4085 bytes
Desc: not available
URL: 

Polishing node identifier (at-codes) use cases.

[Thomas Beale]

On 27/08/2013 21:27, Diego Bosc? wrote:
> I don't think archetype ontology would be more complicated at all.
> There are currently archetypes with different set of properties in
> each at code and tools can handle it well (if I remember correctly,
> NEHTA archetypes have extra properties). I'm pretty sure tools are
> currently robust enough to deal with missing at codes at the ontology.
> It's even very easy to check if an at-code is on the ontology (if I
> recall correctly from java implementation...)
>

well I think Nehta archetypes may have some hacks - they wouldn't 
conform to ADL 1.5 and I am not even sure if their internal archetypes 
conform to ADL 1.4. IN any case, the things they want (annotations 
mainly) are done differently in ADL 1.5.

It's certainly easy to check for codes that are not in the ontology - 
and current the tools all do check, and generate lots of errors:

VONSD, VATDF1, VATDF2, VATCD, VETDF, WETDF, VATCD, VACDF1, VACDF2; see 
meanings here 
.

I'm not saying it's not an idea worth thinking about, but the current 
specifications and tools all work on the opposite premise.

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 

Polishing node identifier (at-codes) use cases.

[Diego Boscá]

I don't think archetype ontology would be more complicated at all.
There are currently archetypes with different set of properties in
each at code and tools can handle it well (if I remember correctly,
NEHTA archetypes have extra properties). I'm pretty sure tools are
currently robust enough to deal with missing at codes at the ontology.
It's even very easy to check if an at-code is on the ontology (if I
recall correctly from java implementation...)

2013/8/27 Thomas Beale :
> On 27/08/2013 18:20, Diego Bosc? wrote:
>>
>> The problem with this rules come with the (explicit or implicit)
>> specialization of single attributes. take this example:
>>
>>   ELEMENT[at0009] occurrences matches {0..1} matches {  -- Position
>>  value existence matches {0..1}
>> matches {
>>  DV_TEXT occurrences
>> matches {0..1} matches {*}
>>  }
>>  }
>>
>> What happens if a DV_TEXT is added on the specialization? Does it need
>> at code? Do we consider the rule to be applied to the archetype +
>> parent or only to the archetypes? Do we need to add an at-code also to
>> the parent?
>
>
> If it were added in a specialisation with no code, it would be assumed to be
> a redefinition of an existing DV_TEXT constraint, assuming there was one. If
> added with a code, the post flattening validation (phase 3) in the current
> ADL workbench would need to detect this. Right now it doesn't have checks in
> that phase for this. I'll have to run this example through the compiler to
> see what it does.
>
>
>> This would need either a rewriting of the rule to state the issue with
>> flat archetypes or a potential problem if an at-code is not specified.
>
>
> good point; the rules should specify that they apply to flattened
> archetypes, which means that ids are required even if each specialisation
> child introduces only one alternative. I'll fix this in the spec.
>
>
>>
>> Another use case is when valid children types are part of the same
>> class hierarchy (no need for specialization). Do we need at-codes when
>> we create siblings such as DV_TEXT and DV_CODED_TEXT?
>
>
> according to the current rules (see my previous post), yes. I would actually
> still rather avoid this, and am still thinking about it...
>
>
>> If we have several different data types, such as DV_BOOLEAN,
>> DV_QUANTITY, and DV_TEXT and then we want to add a DV_CODED_TEXT,
>> which one of the data types gets an at-code? all? only the text ones?
>> none?
>
>
> according to the previous rules, none. But DV_CODED_TEXT would be treated as
> a preferential constraint over DV_TEXT due to the RM inheritance
> relationship. It would be up to apps and tools to make use of that.
>
>
>>
>> Again, rewording/clarification is needed or problems may occur.
>
>
> yes - I doubt that we are at the final version of the wording on this - but
> have a look at the new version and see what you think.
>
>
>>
>> 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
>
>
> ___
> 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.

[Thomas Beale]

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 .

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 
>
>


-- 
Ocean Informatics *Thomas Beale
Chief Technology Officer*
+44 7792 403 613Specification Program, /open/EHR 

Honorary Research Fellow, UCL 
Chartered IT Professional Fellow, BCS 
Health IT blog  
View Thomas Beale's profile on LinkedIn 



-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: ocean_full_small.jpg
Type: image/jpeg
Size: 4085 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: btn_liprofile_blue_80x15.png
Type: image/png
Size: 511 bytes
Desc: not available
URL: 

Polishing node identifier (at-codes) use cases.

[Diego Boscá]

Good to know. I think the only remaining issue could be the one to
confirm if a specialized object should always have at-code.

And regarding use_node, I would also add that you have to be careful
not to create an internal reference from a sibling (and if you do then
you MUST put an at-code)

2013/8/27 Thomas Beale :
> On 27/08/2013 18:20, Diego Bosc? wrote:
>
> Thinking a little about node identifiers I have thought some
> problematic use cases.
> First, this is the current 'rule' in the wiki
> (http://www.openehr.org/wiki/pages/viewpage.action?pageId=196633) for
> when node identifiers are really needed. I copy the relevant part for
> ease the discussion:
>
>
> this wiki page is (I hate to say...) out of date - the current rules are:
>
>
> ADL takes a minimalist approach and does not require node identifiers where
> sibling object nodes
> can be otherwise distinguished. Node identifiers are mandatory in the
> following cases:
>
> for an attribute defined as multiply-valued in the underlying information
> model (i.e. a container type such as a List, Set etc), all immediate
> child object nodes. This applies even if a particular archetype only
> specifies one child object of the attribute;
> for single-valued attributes with more than one child, all immediate child
> object nodes;
> with the exception of use_node constraints where the node identifier can be
> inferred from that of the target node.
>
> I think this probably deals with the cases you point out below. I'll now go
> and update that wiki page :(
>
> - thomas
>
>
> ___
> 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.

[Diego Boscá]

Well, I would say that "free or coded text" is quite common in
healthcare, but even if you argue that this exact example has no real
clinical validity in openEHR it is still an issue that could happen in
any other standard (I would say that CDA for example with his data
types and all his inheritances will suffer this problem for sure)

You can see that in these years even at-code rules have changed quite
a bit (just see current wording and compare with previous ones).
Specialization is a BIG part of archetypes and the more we use it the
more new problems we find. If you want we can wait until archetype
systems are in use to detect these kind of issues. Ignoring problems
won't make them disappear.

As we have discussed before, we want to add the functionality to turn
off the node autocompleting. But again having all nodes with at-code
is perfectly fine according to the specifications, and given the
issues we encounter with specializations I would say that is always be
better safe than sorry.


2013/8/27 Bert Verhees :
> 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

Polishing node identifier (at-codes) use cases.

[Thomas Beale]

On 27/08/2013 18:20, Diego Bosc? wrote:
> The problem with this rules come with the (explicit or implicit)
> specialization of single attributes. take this example:
>
>   ELEMENT[at0009] occurrences matches {0..1} matches {  -- Position
>  value existence matches {0..1} 
> matches {
>  DV_TEXT occurrences
> matches {0..1} matches {*}
>  }
>  }
>
> What happens if a DV_TEXT is added on the specialization? Does it need
> at code? Do we consider the rule to be applied to the archetype +
> parent or only to the archetypes? Do we need to add an at-code also to
> the parent?

If it were added in a specialisation with no code, it would be assumed 
to be a redefinition of an existing DV_TEXT constraint, assuming there 
was one. If added with a code, the post flattening validation (phase 3) 
in the current ADL workbench would need to detect this. Right now it 
doesn't have checks in that phase for this. I'll have to run this 
example through the compiler to see what it does.

> This would need either a rewriting of the rule to state the issue with
> flat archetypes or a potential problem if an at-code is not specified.

good point; the rules should specify that they apply to flattened 
archetypes, which means that ids are required even if each 
specialisation child introduces only one alternative. I'll fix this in 
the spec.

>
> Another use case is when valid children types are part of the same
> class hierarchy (no need for specialization). Do we need at-codes when
> we create siblings such as DV_TEXT and DV_CODED_TEXT?

according to the current rules (see my previous post), yes. I would 
actually still rather avoid this, and am still thinking about it...

> If we have several different data types, such as DV_BOOLEAN,
> DV_QUANTITY, and DV_TEXT and then we want to add a DV_CODED_TEXT,
> which one of the data types gets an at-code? all? only the text ones?
> none?

according to the previous rules, none. But DV_CODED_TEXT would be 
treated as a preferential constraint over DV_TEXT due to the RM 
inheritance relationship. It would be up to apps and tools to make use 
of that.

>
> Again, rewording/clarification is needed or problems may occur.

yes - I doubt that we are at the final version of the wording on this - 
but have a look at the new version and see what you think.

>
> 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

Polishing node identifier (at-codes) use cases.

[Bert Verhees]

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

Polishing node identifier (at-codes) use cases.

[Thomas Beale]

On 27/08/2013 18:20, Diego Bosc? wrote:
> Thinking a little about node identifiers I have thought some
> problematic use cases.
> First, this is the current 'rule' in the wiki
> (http://www.openehr.org/wiki/pages/viewpage.action?pageId=196633) for
> when node identifiers are really needed. I copy the relevant part for
> ease the discussion:

this wiki page is (I hate to say...) out of date - the current rules are:

ADL takes a minimalist approach and does not require node identifiers 
where sibling object nodes
can be otherwise distinguished. Node identifiers are mandatory in the 
following cases:

  * for an attribute defined as multiply-valued in the underlying
information model (i.e. a container type such as a List, Set
etc), all immediate child object nodes. This applies even if a
particular archetype only specifies one child object of the attribute;
  * for single-valued attributes with more than one child, all immediate
child object nodes;
  * with the exception of use_node constraints where the node identifier
can be inferred from that of the target node.

I think this probably deals with the cases you point out below. I'll now 
go and update that wiki page :(

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 

Polishing node identifier (at-codes) use cases.

[Diego Boscá]

Thinking a little about node identifiers I have thought some
problematic use cases.
First, this is the current 'rule' in the wiki
(http://www.openehr.org/wiki/pages/viewpage.action?pageId=196633) for
when node identifiers are really needed. I copy the relevant part for
ease the discussion:

-
ADL takes a minimalist approach and does not require node identifiers
where sibling object nodes can be otherwise distinguished.
Node identifiers are mandatory in the following cases:
* all immediate child object nodes of an attribute defined as
multiply-valued in the underlying information model (i.e. a container
   type such as a List, Set etc.). This applies even if a
particular archetype only specifies one child object of the attribute;
* all immediate child object nodes of single-valued attributes that
are of the same reference model type, i.e. of the form of the
   example shown in section 5.3.2;
* with the exception of use_node constraints where the node identifier
can be inferred from that of the target node.

In all other cases node identifiers are optional.
-


Summarizing: Attributes defined as multiply-valued (I will use the
term 'multiple attributes'/'single attributes' to simplify) must have
always an at-code, but single attributes only if the type is used more
than once.

The problem with this rules come with the (explicit or implicit)
specialization of single attributes. take this example:

 ELEMENT[at0009] occurrences matches {0..1} matches {  -- Position
value existence matches {0..1} matches {
DV_TEXT occurrences
matches {0..1} matches {*}
}
}

What happens if a DV_TEXT is added on the specialization? Does it need
at code? Do we consider the rule to be applied to the archetype +
parent or only to the archetypes? Do we need to add an at-code also to
the parent?
This would need either a rewriting of the rule to state the issue with
flat archetypes or a potential problem if an at-code is not specified.

Another use case is when valid children types are part of the same
class hierarchy (no need for specialization). Do we need at-codes when
we create siblings such as DV_TEXT and DV_CODED_TEXT?
If we have several different data types, such as DV_BOOLEAN,
DV_QUANTITY, and DV_TEXT and then we want to add a DV_CODED_TEXT,
which one of the data types gets an at-code? all? only the text ones?
none?

Again, rewording/clarification is needed or problems may occur.

What is so wrong about having at-codes in every class of the archetype
with no ontology definition for that code?

Regards