I am afraid I remain in the dark as to why we are talking about making AQL semantics specifically dependent on openEHR RM - I thought we already agreed to the opposite on this thread.
We already have the main RM, Demographics, and TP meta-models published and in use, in BMM, JSON-schema, and XSD formats. The class relations can just be looked up, as described in the above-referenced thread.
Not doing so makes an AQL engine fragile, whereas if the relations are looked up, the engine will work on any data. Not only that, but every addition we do to the RM will require tinkering with the AQL semantics spec, and with everyone’s AQL engines, to write in special rules for the relationships of each new change (example: the addition of EHR.folders). If anyone can explain why we wouldn’t want to do this generically, I would be very appreciative.
NB: I don’t mean to say that today’s implementations, which probably are hard-wired should immediately (or maybe ever) change - I’m just talking about how we specify the semantics of AQL. I really don’t see any reason why the very nice work @Seref has done would not be generic to any model - openEHR RM is not special in any way.
Generic rules will just be of the form:
if is_composition (C1, C2) then action_aaa if is_reachable (C1, C2) then action_aaa
action_aaa is some action to do in the query processor. Since that
is_composition() and other lookups can be very easily done against the meta-models we already have, I’m not sure why we would document anything else. It doesn’t matter whether
C1 happens to be
EHR or any other class.
Looking for enlightenment…