----- Original Message -----
From: "Thomas Beale" <thomas.be...@oceaninformatics.biz>
To: <openehr-technical at openehr.org>
Sent: Monday, November 14, 2005 6:15 PM
Subject: Re: Question about Ocean's Archetype Editor
> Mattias Forss wrote:
>
>> Hello,
>> I'm trying to figure out which reference model Ocean's achetype editor
>> follows. I have an example regarding the data type Quantity, see below.
>> There seems to be great differences depending on what reference model the
>> archetypes follow.
>
> I pretty sure that the reference model is the same in all cases. There is
> only one definition of DV_QUANTITY in the openEHR reference model, and as
> far as I know, only one assumed in archetypes.
Thank you for your answer Thomas,
I bet the reference model is the same, but do the Ocean archetype editor
fully conform to the reference model? Take a look at the ITEM_TREE class
definition for example. You will see that the correct attribute for the
physical representation of the tree will be either "representation" for
version 0.9 of the specifications or "root" for version 0.95+ of the
specifications. However, the Ocean archetype editor does not use neither of
these attributes, instead it uses "items" but maybe this is correct if the
editor conforms to an earlier version of the specifications than 0.9. Anyone
who knows about this?
> However, it may look different. There are two ways of representing
> constraints on Quantity in an archetype. One is to use the 'standard'
> method of creating C_COMPLEX_OBJECTs which mimic the sructure of the
> QUANTITY class; the other is to use an instance of C_QUANTITY, which is a
> custom replacement type which provides a better model of the possible
> constraint on QUANTITY (while still assuming the same underlying
> definition of QUANTITY).
This is interesting, but I'm getting slightly confused about the naming
here. Could you explain more and tell me the difference between QUANTITY,
C_QUANTITY and C_DV_QUANTITY. It is probably a lot easier to grasp for
someone like you.
I believe the C_QUANTITY corresponds to the CQuantity (inherits from
CDomainType) class in the java reference kernel, and the parser gives me
this object if the archetype looks like Q1. Nevertheless, I'm starting to
think that this isn't right and that the parser instead should give me the
CQuantity object if the archetype looks like Q2. What do you think? By the
way, should there exist a class called Quantity in the java kernel or maybe
it is sufficient with the CComplexObject (that mimics the structure of the
QUANTITY class)?
Q1:
QUANTITY matches {
magnitude matches {|<0.0|}
units matches {"cm/s2"}
}
Q2:
C_QUANTITY <
property = <"Acceleration">
list = <
["1"] = <
units = <"cm/s2">
magnitude = <|< 0.0|>
>
["2"] = <
units = <"ft/s2">
magnitude = <|>= 0.0|>
>
>
>
>
>> Background:
>> I'm trying to figure out how to get the property of a quantity but this
>> doesn't seem to be supported by the java kernel I'm using, so I'm asking
>> if anyone has a good idea on how to support this in other ways.
>
> the property attribute is defined only in the type C_QUANTITY. It provides
> a convenient way to capture the constraint that you want only length or
> pressure, without saying which unit. If only the property is set in the
> C_QUANTITY in the archetype, then when the kernel checks to see if an
> instance of DV_QUANTITY conforms to the C_QUANTITY in the archetype, it is
> up to the C_QUANTITY to carry out this check in sensible way, i.e. by
> determining what property the actual units measure.
I'm not getting this... as an example, do you mean that a C_QUANTITY with
its property set to "length" is supposed to check if "meters" or "inches" in
the DV_QUANTITY conforms to this C_QUANTITY? How is it supposed to do that,
it seems to me that the C_QUANTITY then must know what allowable units there
can be for the length property. Where are those units supposed to be stored
if only the property is set in the C_QUANTITY?
>> By the way, shouldn't the property attribute represent a CODED_TEXT
>> object that can be linked to a local or external terminology?
>
> this is true; we watered it down to make people in CEN and HL7 happy, but
> I no longer believe such compromises are sensible. We will probably change
> this to a CODED_TEXT.
Ok, I suppose you're referring to the Ocean archetype editor now?
Regards,
Mattias
>
> hope this helps
>
> - thomas beale
>
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org
