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 frequently constrained in archetypes as well. At the very least my thinking is that it is counter-intuitive to constrain them directly. Also, for the Java validator that is also used in CKM, we had to introduce a special hard-coded check for "commonly constrained functional properties" such as the three mentioned here. Re "offset": I wonder if offset could be expressed as an attribute with an invariant for its validity. In fact, looking at the specs, there already is an invariant "Offset_validity": inv: offset <> Void and offset = time - parent.origin Now I wonder what the point of this invariant is when offset is a function that is already defined to be "time - parent.origin"? Re "type": This is the same as the property "name" (because of the type_validity invariant) Sebastian On 10.01.2012 09: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 object type;" (AOM specifications, page 12) > This excludes clearly the 'stored properties'. > > > > 2012/1/9 Thomas Beale<thomas.beale at oceaninformatics.com>: >> 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 constraint on relative time, not absolute time. It >> would mean creating constraints in the rules section with an equivalent >> expression, i.e. >> >> .../some/path/to/event[5 min]/time - .../some/path/to/event[5 >> min]/parent/origin<= PT5m >> >> - thomas >> >> On 09/01/2012 11:41, Diego Bosc? wrote: >>> 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 >>> attribute. >>> What is the sense for this? Shouldn't this restriction be expressed as >>> an assertion over the different attributes? (that is, a restriction >>> that must be checked at runtime as it is a result from a method). >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical at openehr.org >>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >>> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -- Ocean Informatics Dr Sebastian Garde Senior Developer Ocean Informatics /Dr. sc. hum., Dipl.-Inform. Med, FACHI/ Skype: gardeseb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120110/2fd63c03/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: oceanlogo.png Type: image/png Size: 5677 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120110/2fd63c03/attachment.png>
