Constraints on class methods
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 ;-)
Constraints on class methods
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 computed attributes to static attributes - i.e. an expression * when generating performing the flattening operation, and generating the Operational Template, we replace constraints on computed attributes with the relevant equivalent expressions - thomas On 11/01/2012 06:53, Rong Chen wrote: Hi all, I also think constraining functions, i.e. computed attributes, in the reference model classes can be counter-intuitive and probably unnecessarily complex. In clinical modelling space, a function is supposedly less obvious to modeler than an ordinary RM class attribute. Since the result of the function is derived from several member attributes and the algorithm is documented in the RM specs, it's reasonable to assume that a constraint expressed on derived values is less understood than that on an attribute. If a derived value is so commonly used and indeed necessary in archetyping, why not make it an attribute in the first place. In the engineering space, constraints on static attributes seem to be more straight-forward to work with. Default data instance can be safely generated by the combined definitions of archetypes/templates. Upon saving the data instance, the invariants, or rules in the latest specs, would be used against the instance for final validation. Now considering how to handle the constraints on functions, they can't really be used for instance generation since they are dependent on other attributes. So they would probably only be used in the final validation just as rules/invariants. So indeed, why not implement these function constraints as invariants/rules to start with? In summary, I would vote for only allowing constraints on ordinary, static attributes. Use invariants or rules to achieve same effects as constraints on functions. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120115/e0ea501a/attachment.html
Constraints on class methods
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 case of 'offset' in the RM definition, we include a rule that defines the equivalence of such computed attributes to static attributes - i.e. an expression when generating performing the flattening operation, and generating the Operational Template, we replace constraints on computed attributes with the relevant equivalent expressions - thomas On 11/01/2012 06:53, Rong Chen wrote: Hi all, I also think constraining functions, i.e. computed attributes, in the reference model classes can be counter-intuitive and probably unnecessarily complex. In clinical modelling space, a function is supposedly less obvious to modeler than an ordinary RM class attribute. Since the result of the function is derived from several member attributes and the algorithm is documented in the RM specs, it's reasonable to assume that a constraint expressed on derived values is less understood than that on an attribute. If a derived value is so commonly used and indeed necessary in archetyping, why not make it an attribute in the first place. In the engineering space, constraints on static attributes seem to be more straight-forward to work with. Default data instance can be safely generated by the combined definitions of archetypes/templates. Upon saving the data instance, the invariants, or rules in the latest specs, would be used against the instance for final validation. Now considering how to handle the constraints on functions, they can't really be used for instance generation since they are dependent on other attributes. So they would probably only be used in the final validation just as rules/invariants. So indeed, why not implement these function constraints as invariants/rules to start with? In summary, I would vote for only allowing constraints on ordinary, static attributes. Use invariants or rules to achieve same effects as constraints on functions. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Constraints on class methods
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 because noone has ever wanted to constrain them, so currently it would serve no purpose, but obviously we could include them. - thomas
How to use C_DURATION pattern constraint
On 11/01/2012 11:09, Leonardo Moretti wrote:
Hi all,
maybe this is a silly question, but I didn't find a point in the specs
where this is clearly explained:
The following notation on ADL:
ELEMENT[at0009] occurrences matches {0..1} matches {-- Pattern
value matches {
DV_DURATION matches {
value matches {PYM}
}
}
}
constraints the data to have a DV_DURATION element with both year and
month specified (both part are mandatory) or with year and/or month
specified (both part are optional)!?
Leonardo,
where does this constrain come from? It says that the duration has to
have a Year and/or a Month. I.e. P5Y, P2M, P5Y2M are all allowed
according to this constraint. See pg 70 of the current ADL 1.5
specification
http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/adl1.5.pdf.
- thomas
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120115/fdcfcdb5/attachment.html
Constraints on class methods
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
Constraints on class methods
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 really see the big issue about defining things like this Technically there isn't. It's about clarity for modellers. The above makes perfect sense to us technical people, but now we can't have a simple constraint on Event.offset, which clinical people can understand, it means we have to have some more complex UI interface in the modelling tool, so that the constraint is comprehensible to normal mortals. That;s why I am more interested in a simpler constraint (based on a computed property) and putting the expression further back in the tool structure. But that's just my view; I am interested to hear other opinions - if everyone is against computed attributes then we need to find a clean solution for this. - thomas
