I found that offset was a stored value at openEHR RM 0.95 (back in 2005),
but then it became a computed method.
2012/1/15 Thomas Beale thomas.beale at oceaninformatics.com
Life would have been much easier if Event recorded 'offset' as a stored
value, and the 'time' was the property being
On 16/01/2012 06:12, David Moner wrote:
A possible problem I can envision is that this opens the door to the
creation of invalid archetypes without the possibility of validating
them at design time.
A quick and dirty example just to get the idea. In an archetype, the
HISTORY.origin is
Life would have been much easier if Event recorded 'offset' as a stored
value, and the 'time' was the property being computed. I argued
strenuously for that years ago, precisely to avoid the problem we are
talking about here, but lost the battle ;-)
A nicer approach could be as follows:
* we allow 'computed' attributes in the RM definition used by
archetype tools, which will allow archetypes to be very clear and
nice, e.g. in the case of 'offset'
* in the RM definition, we include a rule that defines the equivalence
of such
Or simply using an assertion on the first place?
2012/1/15 Thomas Beale thomas.beale at oceaninformatics.com:
A nicer approach could be as follows:
we allow 'computed' attributes in the RM definition used by archetype tools,
which will allow archetypes to be very clear and nice, e.g. in the
On 11/01/2012 02:38, Diego Bosc? wrote:
If you still say that properties can be restricted, then current
stable validated bmm files are incorrect, as they are currently
missing 90% of stored properties (all methods without parameters),
like all the ones in ITEM_TABLE.
We don't include them
On 15/01/2012 09:08, Diego Bosc? wrote:
Or simply using an assertion on the first place?
there is already an assertion in the RM. Where/how do you want to use it
in an archetype?
- thomas
On 15/01/2012 09:52, Diego Bosc? wrote:
I'm not sure if I have understood your question, but there isn't
already assertion support on the AOM?. just put an assertion of the
restricted and desired condition (in this case something like this:
|event.time - history[at].origin|=P10M)
I don't
On 11/01/2012 08:15, Heath Frankel wrote:
Further to my previous email, I believe the original intent of the
name attribute is a form caption of an element value, the approach of
adding a numeric suffix to provide a unique key is contrary to this
original intent.
this is correct. The
Further to my previous email, I believe the original intent of the name
attribute is a form caption of an element value, the approach of adding a
numeric suffix to provide a unique key is contrary to this original intent.
Btw, another example of multiple names values conflict with this unique
Heath Frankel wrote:
I believe this unique name rule should be reviewed and revoked. It is not
formally defined, as indicated in [
http://www.openehr.org/issues/browse/SPECPR-54 ] its only stated in the
architecture overview in the context of paths which assumes name is the
unique within
Sebastian Garde wrote:
A few other functional properties come to mind such as type in
PARTY_RELATIONSHIP ...
Re type: This is the same as the property name (because of the
type_validity invariant)
Yes, funny you should mention that, Sebastian, because I discovered yesterday
that this is a
If you still say that properties can be restricted, then current
stable validated bmm files are incorrect, as they are currently
missing 90% of stored properties (all methods without parameters),
like all the ones in ITEM_TABLE.
2012/1/10 Thomas Beale thomas.beale at oceaninformatics.com:
On
Oh, this is the first time I have heard that functions can be
constrained. However, AOM specifications say otherwise:
C_attribute: a node representing a constraint on an attribute
(i.e. UML ?relationship? or
?primitive attribute?) in an object type; (AOM specifications, page 12)
This
On 10/01/2012 08:40, Diego Bosc? wrote:
Oh, this is the first time I have heard that functions can be
constrained. However, AOM specifications say otherwise:
C_attribute: a node representing a constraint on an attribute
(i.e. UML ?relationship? or
?primitive attribute?) in an
Doesn't this create problems while using archetypes/templates as basis for
the generation of data instances?
I mean, a computed attribute (for example, the EVENT offset) gets its value
from already existing values or attributes of the instance class (in this
example, from the time and the
On 10/01/2012 09:52, Sebastian Garde wrote:
Thomas, Rong and I had a similar discussion many moons ago, and in the
end I think we agreed to disagree ;-)
A few other functional properties come to mind such as type in
PARTY_RELATIONSHIP and is_integral in DV_QUANTITY.
These are more or less
On 10/01/2012 14:32, David Moner wrote:
Doesn't this create problems while using archetypes/templates as basis
for the generation of data instances?
I mean, a computed attribute (for example, the EVENT offset) gets its
value from already existing values or attributes of the instance class
When I was trying to validate an archetype with the reference model
(openEHR-EHR-OBSERVATION.apgar), I found something strange on all
'event' archetypes.
The EVENT class has a function (method) that calculates the offset.
However, in that archetype the offset was restricted as if it was an
In ADL/AOM, constraints can be made on computed properties as well as
stored ones. If you look at the spec, EVENT.offset is computed as
time.diff(parent.origin). Making a constraint on EVENT.time, which is
the absolute time (which is what you want in the data) is annoying
because you want to
20 matches
Mail list logo
