Hello Bjørn,
This is your first bp query, following the same notation I used in the initial response:
Which would correspond to the following Xquery code:
xquery version “3.0”;
declare namespace xsi=“http://www.w3.org/2001/XMLSchema-instance”;
declare default element namespace “http://schemas.openehr.org/v1”;
{
for $obs in composition//content[@xsi:type=‘OBSERVATION’]
for $protocol in $obs/protocol[@archetype_node_id=‘at0011’]
let $cuff := $protocol/items[@archetype_node_id=‘at0013’]/value/value
let $obs_data := $obs/data[@archetype_node_id=‘at0001’]
let $origin := $obs_data/origin/value
for $event in $obs_data/events[@archetype_node_id=‘at0006’]
let $eventTime := $event/time/value
for $data in $event/data[@archetype_node_id=‘at0003’]
for $systolicElement in $data/items[@archetype_node_id=‘at0004’]
let $systolic := $systolicElement/value/magnitude
for $diastolicElement in $data/items[@archetype_node_id=‘at0005’]
let $diastolic := $diastolicElement/value/magnitude
return
{
(element Origin {$origin/text()},
(element EventTime {$eventTime/text()}),
(element Systolic {$systolic/text()}),
(element Diastolic {$diastolic/text()}),
(element Cuff {$cuff/text()}))
}
}
Which gives the result the query is asking for. I am not sure I understand why you’re naming the first aql query for blood pressure as naive though. It looks like a reasonable query to me.
Your second query is the following:
Which corresponds to the following Xquery code:
xquery version “3.0”;
declare namespace xsi=“http://www.w3.org/2001/XMLSchema-instance”;
declare default element namespace “http://schemas.openehr.org/v1”;
{
for $obs in composition//content[@xsi:type=‘OBSERVATION’]
for $protocol in $obs/protocol[@archetype_node_id=‘at0011’]
let $cuff := $protocol/items[@archetype_node_id=‘at0013’]/value/value
let $obs_data := $obs/data[@archetype_node_id=‘at0001’]
let $origin := $obs_data/origin/value
(:THIS IS WHERE AQL_BP1 AND THIS FILE DIFFERS:)
for $event in $obs//*[@xsi:type=‘POINT_EVENT’]
let $eventTime := $event/time/value
for $data in $event/data[@archetype_node_id=‘at0003’]
for $systolicElement in $data/items[@archetype_node_id=‘at0004’]
let $systolic := $systolicElement/value/magnitude
for $diastolicElement in $data/items[@archetype_node_id=‘at0005’]
let $diastolic := $diastolicElement/value/magnitude
return
{
(element Origin {$origin/text()},
(element EventTime {$eventTime/text()}),
(element Systolic {$systolic/text()}),
(element Diastolic {$diastolic/text()}),
(element Cuff {$cuff/text()}))
}
}
The results for both query are the same, which is:
2017-05-02T20:00:00+02:00
2017-05-02T20:05:00+02:00
100
90
Adult thigh
2017-05-02T20:00:00+02:00
2017-05-02T20:10:00+02:00
101
91
Adult thigh
2017-05-02T20:15:00+02:00
2017-05-02T20:20:00+02:00
102
92
Large adult
I did not have time to write the data instance in OWL based on the xml you’ve provided, so I did not write SPARQL versions.
Your third example re Glasgow Comma Scale produces the correct results and you have a good point re displaying this to a clinician: it is almost certain that a clinician would have difficulty figuring the difference between the two rows which is at the rightmost column, but this is not about AQL semantics, it is about how to format query results.
Going back to the difference between your two queries for blood pressure. The results are the same because even though the structural constraints are different, given your data, and more importantly, the design of RM, the results would be the same. Think about it, there is nothing of importance sitting between the observation and event, so whether your query includes the event via a CONTAINS constraint in the FROM clause or via a direct parent/child path in the SELECT clause does not matter
Your use of POINT_EVENT raises the kind of issue I’m pointing at though, because that is not a structural constraint, it is a type constraint. So the interesting question is:
Should AQL implementations support polymorphic results?
That is, if I use EVENT in the FROM clause for a named node as in EVENT e should this resolve to both POINT_EVENT and INTERVAL_EVENT instances? What if the data has INTERVAL_EVENTS and the query, as you’ve done, is asking for POINT_EVENTs?
How about the interpretation of paths int the SELECT clause? Do we assume a logical or here? That is, if a composition does not contains one of the rows in the SELECT clause, should the results include a row with that column set to null, or should that row be excluded all together (if we assume logical AND) ?
Can you imagine what would happen if a large scale data extraction for decision support/population query analysis were run on two different implementations that interpret the SELECT clause children differently?
Currently, almost all vendors that I know if assume a logical OR, so any data instance that satisfies at least one condition/existence in the SELECT clause is included in the results, but this is just common sense of the implementers, there is nothing in the AQL specification about this.
How about the semantics of CONTAINS constraint in the FROM clause? Is it mandatory? can we have optional CONTAINS or any data that fails all CONTAINS constraints should be excluded?
What is the right way to extend AQL with functions that can be allowed to take variables as parameters? This is more of a syntax issue but it requires an underlying semantics to be defined nonetheless.
You can I could exchange examples an implementations till we turn blue but until we have an AQL spec that clarifies the points I’m trying to make above, we’re all blind man in a room, with an elephant in between us 
All the best
Seref
Ps: I’ve accepted the pull request and put the above queries there.