automatic demotion of lists in AQL ?

Technical (archive)
1

Hello,
Is it allowed to use an element that is allowed to appear multiple times within a path ?
For example in the query

SELECT a/items[at0001]/value
FROM EHR e
CONTAINS CLUSTER a[openEHR-EHR-CLUSTER.laboratory_test_analyte.v1]

the field items[at0001] may appear 0..* times. Thus the access to the value field is not properly defined from a type checking point of view.
Does the AQL specification allow such constructs and how is this situation interpreted ?
Greetings
Georg

2

Unless I am missing something, the fragment items[at0001] cannot appear more than once relative to any given archetype. Here, it is relative to ‘a’, i.e. openEHR-EHR-CLUSTER.laboratory_test_analyte.v1. Within the same archetype, you cannot have other items[xxx] such that the xxx are not unique, even if there are multiple ‘items’ attributes down the containment graph. From different archetypes you can, but there is no difficulty for the AQL processor to disambiguate these.

3

Yes that at codes are always effectively namespaced by their parent archetype.

Ian

4

Hi Thomas,
I do not want to use the path element "items[at0001]" multiple times. What I mean is that in the query

SELECT a/items[at0001]/value
FROM EHR e CONTAINS CLUSTER a[openEHR-EHR-CLUSTER.laboratory_test_analyte.v1]

the path "a/items[at0001]" denotes a list of ELEMENT (min: 0, max: *). Thus the access to the field "value" of this list seems odd. But from the specification it seems that if I want to receive all values of all values of all elements this query is the correct query to make what I want.
To access all path leafs of all elements of such a list is therefore implicitely done.
Greetings
Georg

5

Hello,
In order to better understand the semantics of AQL I try to rephrase the problem I have:
Imagine an archetype "openEHR-EHR-CLUSTER.example.v1" that allows the multiple existence of a specific contained field:

definition
CLUSTER[at0000] matches {
items cardinality matches {0..*; unordered} matches {
ELEMENT[at0001] occurrences matches {0..*} matches { value matches { DV_TEXT matches {*} } }
}
}

Is it allowed to constrain this archetype in the WHERE part by accessing the field within a path? :

SELECT e FROM EHR e CONSTAINS CLUSTER a[openEHR-EHR-CLUSTER.example.v1]
WHERE a/items[at0001]/value = 'test'

The problem I have with this query is that the path "a/items[at0001]" is a list, so it perhaps cannot be extended with "value", because a list does not have a field "value" but only the members of this list have this field.
An alternative to the query above would be to resolve the list in the FROM part by writing something like this:

SELECT e FROM EHR e CONSTAINS CLUSTER a[openEHR-EHR-CLUSTER.example.v1]
CONTAINS DV_TEXT b
WHERE b/value = 'test'

This would work in the above example, but would create further problems if there are further elements in parallel to ELEMENT[at0001] that as well contain DV_TEXTs and which would be matched as well by the alternative query.
Greetings
Georg

6

Have you seen a previous answer I gave to you re contains clause and nodes without arch nd ids? The one explaining why it is unlikely to work

a/items[at0001]/value/value should do the trick

7

Hi Seref,
Ok, thank you for the answer.
From that I and the other answers I would summarize that
"implicit iteration over lists in order to further process the elements"
is a paradigm that does actually exist in AQL.
Greetings
Georg

8

Hi Georg,
I’d say yes but do it reluctantly :slight_smile: you can think in terms of iteration but in my experience it leads to incorrect assumptions and can confuse you, especially regarding how result sets are created
I’d suggest thinking in terms of pattern matching rather than traversal but both are valid ways of interpreting Aql semantics

Cheers
S.