the ontological problem here is that when dealing with time, you always
want to constrain at design time in terms of relative amounts, usually
offsets, durations etc. But at runtime, the time data are absolute
times, that you cannot know at the outset.
This would not be a problem if we had made offset a data element, but
then the time-point of an EVENT would need to be calculated by adding
the offset to the origin, and even worse, setting it in the first place
would have to be done by a subtraction.
Prbabaly the right way to get around this is to allow constraints of the
form:
(/path/to/EVENT/time - /path/to/HISTORY/origin) matches {PT5M}
and so on. We are just rewriting the expressions language, so we can
finally solve this any many other more complex constraints, with a
single language, which will be common to GDL, Task Planning and so on.
- thomas
On 26/06/2018 09:21, David Moner wrote:
Hi Pablo,
An old discussion about the offset and constraints over methods:
https://www.mail-archive.com/[email protected]/msg09386.html
And an even older one (from 2012!):
https://www.mail-archive.com/[email protected]/msg06557.html
It seems that we have never found a full agreement between those who
agree with constraining the value returned by methods, and those who
think that it is not a recommendable approach.
BTW, I just checked that in LinkEHR we cannot constraint offset or any
other method, since our main source for the RM is the XML Schema and
it doesn't define them.
--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog
<http://wolandsothercat.net/> | The Objective Stance
<https://theobjectivestance.net/>
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
