# RFC CR-000024 - Revert "meaning" to String - ARB deadline 23 july 2004

**Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156)
**Created:** 2004-07-09 22:36 UTC
**Views:** 4
**Replies:** 7
**URL:** https://discourse.openehr.org/t/rfc-cr-000024-revert-meaning-to-string-arb-deadline-23-july-2004/14466

---

## Post #1 by @thomas.beale

Dear all,

here is another important CR to consider in the next few weeks\.

CR\-000024 \- Revert "meaning" to String\. See <http://www.openehr.org/repositories/spec/latest/publishing/CM/CRs/CR-000024.txt>\. This CR is about the meaning attribute defined on the class LOCATABLE \(see Common Model, Archetype package, at <http://www.openehr.org/repositories/spec/latest/publishing/architecture/reference_model/common/im/REV_HIST.html>\)\. This attribute is one of the most important in the whole reference model \- it is effectively the node id of every node in an archetype, and it is what gets imprinted into data, so that the latter can be reconnected with its archetypes\. It also has a second purpose: it is coded in the archetype, giving it a normalised meaning in multiple languages, e\.g "systolic pressure", whereas as the node name might have been set by the user to "sys BP" or whatever\. Currently, the attribute is of type DV\_TEXT, meaning it could be a DV\_CODED\_TEXT as well \(see the data types reference model for these types \- <http://www.openehr.org/repositories/spec/latest/publishing/architecture/reference_model/data_types/im/REV_HIST.html>\)\. Given that every single node in data will contain this item, it has been proposed by Sam, and now more recently by the DSTC that it should be reverted to just a String expressing the code \(it must be an "at" code, of the kind you see in the archetypes\), because to use a DV\_CODED\_TEXT means there is a DV\_CODED\_TEXT object, a CODE\_PHRASE object, with the latter containing 2 Strings\. The DSTC have shown that in the XML of the data, this causes quite a bit of bloat\. Sam Heard has always contended that we should just used the code as a String; the pracical consequence of this is that you must have archetypes present to interpret the node id\. Dipak Kalra has always contended that it should be present as the full coded term, so that the normalised meaning is available in the data \(well, in one language at least\), without referring to the archetype\.

It is also important to realise that the expression of the 'meaning' attribute as a simple string such as 'at0001', 'at0045\.1' etc \(codes derived from the archetypes\) provides an easy way to support path based querying in XML data, using Xpath\. A path of the form \.\.\./events\[@id=at0014\]/\.\.\. can find the node marked with  the arhceytpe node id \(= meaning\) 'at0014'; a concatenation of such patterns enables nodes to found anywhere in large trees of XML data\.

It has also been argued that the name of the attribute \- 'meaning' should be changed to e\.g\. 'node\_id', or even just 'id' \- whcih would not harm the comprehension of archetypes, and would be more obvious in data\.

reactions?

\- thomas beale

---

## Post #2 by @Vincent_McCauley

Hi Thomas,

1\. I think node\_id rather than "meaning" for the name of this data would be
clearer\.

2\. A compromise suggestion to address Dipak's issue \(which I think is
important\) as well as reduce XML bloat:
Change the datatype to just a string but introduce a new section at the
start of the XML "package" which has a list of name/value pairs of form:
<archetype references>
  <archetypeID> "atnnnn" <\\archetypeID>
  <archetypeName> "An archetype formal name" <\\archetypeName>
</archetype references>

one pair for each archetype referenced in the following XML "package"\.

This would also be helpful for software to pre\-locate all required
archetypes \(e\.g\. when XML is initially received\)
prior to further processing the XML\.

Regards
Vince

Dr Vincent McCauley
McCauley Software Pty Ltd

---

## Post #3 by @thomas.beale

Vincent McCauley wrote:

> Hi Thomas,
>
> 1\. I think node\_id rather than "meaning" for the name of this data would be
> clearer\.
>

I suspect we will make this change \- most people prefer it

> 2\. A compromise suggestion to address Dipak's issue \(which I think is
> important\) as well as reduce XML bloat:
> Change the datatype to just a string but introduce a new section at the
> start of the XML "package" which has a list of name/value pairs of form:
> <archetype references>
>  <archetypeID> "atnnnn" <\\archetypeID>
>  <archetypeName> "An archetype formal name" <\\archetypeName>
> </archetype references>
>
> one pair for each archetype referenced in the following XML "package"\.
>
> This would also be helpful for software to pre\-locate all required
> archetypes \(e\.g\. when XML is initially received\)
> prior to further processing the XML\.
>

this is a good idea \- we have previously had notions similar to this\. What you are suggesting is effectively including a slice of the archetype's ontology section either at the top of each Composition and/or at the top of each generated Extract, derived from the total ontology as follows:
\- only use the language of the locale \(translations can be gotten from the archetype\)
\- only include those codes/meanings of nodes actually used in the data \(remember that at runtime, a user might choose to ditch optional nodes, e\.g\. BP protocol etc\.

does this correctly express your suggestion Vince?

\- thomas

---

## Post #4 by @thomas.beale

Dear all,

due to changes in the openEHR website repositories area, the URLs I gave out previous should be replaced by the following ones:

Text of the CR\-00024: http://www.openehr.org/repositories/spec-0.9_D/latest/publishing/CM/CRs/CR-000024.txt

Common Model: http://www.openehr.org/repositories/spec-0.9_D/latest/publishing/architecture/reference_model/common/im/REV_HIST.html

Data types reference model \- http://www.openehr.org/repositories/spec-0.9_D/latest/publishing/architecture/reference_model/data_types/im/REV_HIST.html

Apologies for any inconvenience \- unfortunately there will be a few broken links on openEHR for a couple of days\.

\- thomas beale

---

## Post #5 by @christian.heller

> >1\. I think node\_id rather than "meaning" for the name of this data would
> > be clearer\.
>
> I suspect we will make this change \- most people prefer it

I propose to delete all "name", "meaning", "id" or similar fields from
all archetypes\. The only way an archetype should be identifiable is
through its file name, which should be unique and in English\.
This also permits to use a URL for archetype identification\.

Philosophical Background:
\- a knowledge model \(concept\) knows about its parts
\- the parts are identified by the whole over a unique name
\- a part model itself does not know what name it carries in a possible
surrounding "whole" concept that it is part of

Example:
\- the concept of a person can be used as part by different whole
concepts like an address\-, EHR\- or other administrative applications
\- these whole concepts can give a person very different names/ IDs
\- it is impossible to guess all possible uses of the person concept
\- therefore it does not make sense to store all possible names within
a concept \(knowledge template/ archetype\)

In short, the file name suffices to identify archetypes\.
Whole \(compound\) concepts use additional names to identify their parts\.

Christian

---

## Post #6 by @thomas.beale

Christian Heller wrote:

>>> 1\. I think node\_id rather than "meaning" for the name of this data would
>>> be clearer\.
>>>     
>>
>> I suspect we will make this change \- most people prefer it
>>   
> I propose to delete all "name", "meaning", "id" or similar fields from
> all archetypes\. The only way an archetype should be identifiable is
> through its file name, which should be unique and in English\.
> This also permits to use a URL for archetype identification\.
>

Christian, you may have misunderstood \- the 'meaning' fields in an archetype are the node\-level ids \- which also double as codes, whose meaning is given in the lower part of the archetype\. See for example http://www.openehr.org/repositories/archetype/latest/adl/archetypes/openehr/ehr/entry/observation/openehr-ehr-observation.apgar_result.draft.adl.html \- those codes in magenta in the main part of the archetype are 'meaning' values; the name of this field is what we are proposing to rename 'node\_id'\. It appears on every archetype node, not just the root\. Note that these ids are local to the archetype \- to reference them from the outside, you need to include the id of the archetype itself, e\.g\. 'openehr\-ehr\-OBSERVATION\.apgar\_result\.v1::\[at0004\]"\.

\- thomas

---

## Post #7 by @christian.heller

> Christian, you may have misunderstood \- the 'meaning' fields in an
> archetype are the node\-level ids \- which also double as codes, whose
> meaning is given in the lower part of the archetype\. See for example
> http://www.openehr.org/repositories/archetype/latest/adl/archetypes/openehr
> /ehr/entry/observation/openehr\-ehr\-observation\.apgar\_result\.draft\.adl\.html \-
> those codes in magenta in the main part of the archetype are 'meaning'
> values; the name of this field is what we are proposing to rename

You mean for example "at0000" at "OBSERVATION" is a meaning/id? O\.k\.
In this case it seems you follow a different design than I thought\.
Are "OBSERVATION", "HISTORY" and smaller nodes archetypes for you?
In my understanding of a world made of hierarchical models they would be\.
If they are knowledge models \(archetypes\) themselves, I would put each
of them into their own file\. Instead of using local ids, one could then
reference archetypes over their file name\.

While the template models \(archetypes\) should exist in separate files
from which a running system can get instantiated, there is also a need
for a serialized form of knowledge, like the observation example you
have given, or for storing a complete EHR\. In this case the file names
would be lost; one model would contain complete part models, not only
the reference to them\.

> 'node\_id'\. It appears on every archetype node, not just the root\. Note
> that these ids are local to the archetype \- to reference them from the
> outside, you need to include the id of the archetype itself, e\.g\.
> 'openehr\-ehr\-OBSERVATION\.apgar\_result\.v1::\[at0004\]"\.

Christian

---

## Post #8 by @thomas.beale

Christian Heller wrote:

>> Christian, you may have misunderstood \- the 'meaning' fields in an
>> archetype are the node\-level ids \- which also double as codes, whose
>> meaning is given in the lower part of the archetype\. See for example
>> http://www.openehr.org/repositories/archetype/latest/adl/archetypes/openehr
>> /ehr/entry/observation/openehr\-ehr\-observation\.apgar\_result\.draft\.adl\.html \-
>> those codes in magenta in the main part of the archetype are 'meaning'
>> values; the name of this field is what we are proposing to rename
>>   
> You mean for example "at0000" at "OBSERVATION" is a meaning/id? O\.k\.
> In this case it seems you follow a different design than I thought\.
> Are "OBSERVATION", "HISTORY" and smaller nodes archetypes for you?
> In my understanding of a world made of hierarchical models they would be\.
> If they are knowledge models \(archetypes\) themselves, I would put each
> of them into their own file\. Instead of using local ids, one could then
> reference archetypes over their file name\.
>

in general, it is useful for one archetype to provide structure for a number of nodes \- the 'micro\-structure' of a business object if you like\. If the object in question is an instance of the Observation class in the openEHR EHR information model then a typical archetype provides a model not just of the Observation node itself, but of all the pieces inside\. The best way to see this apart from ADL examples, is to use the ADL workbench \(get it from http://www.openehr.org/repositories/implem-dev/latest/publishing/tools/windows/index.html) on the example archetypes \(get them from http://www.openehr.org/repositories/archetype/archetype-latest.tgz). You get a folding explorer view of an archetype, and you can see quite easily why it makes sense for the one archetype to provide the model of Observation all the way down to Element objects\.

But\.\.\.there is nothing to stop you having an archetype for an Observation which stops at History, and then invokes another archetype for the History you want\. This is what archetype slots are for\. An example of archetype slots can be found in various archetypes in the archive \- e\.g\. the Section archetypes, but also a medication order archetype\.

The process of using separate archetypes for smaller and smaller pieces can indeed continue to the point where there is a separate archetype for each node in a data hierarchy, but our work so far shows that in general, this isn't particularly useful \- we tend to re\-use larger lumps than single nodes\. \(But again \- someone might prove that wrong\)\.

\- thomas

---


**Canonical:** https://discourse.openehr.org/t/rfc-cr-000024-revert-meaning-to-string-arb-deadline-23-july-2004/14466
**Original content:** https://discourse.openehr.org/t/rfc-cr-000024-revert-meaning-to-string-arb-deadline-23-july-2004/14466