What do you think about the following logic related to AQL?
The following AQLs will be intepreted as logical equals for the AQL engine. The first AQL 1.0 is a short hand query for the full AQL defined as AQL 1.3.
AQL 1.0
select o from OBSERVATION o[openEHR-EHR-OBSERVATION.lab_test-result.v1]
AQL 1.1
select o from COMPOSITION c
CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.lab_test-result.v1]
AQL 1.2
select o from EHR e
CONTAINS COMPOSITION c
CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.lab_test-result.v1]
AQL 1.3
select o from EHR e
CONTAINS VERSIONED_COMPOSITION vo
CONTAINS VERSION v[latest_version]
CONTAINS COMPOSITION c
CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.lab_test-result.v1]
The question is if you agree that the given AQL’s will produce identical results. The given AQLs are, in our opinion, equal. They are different syntactic variants of the same maximal AQL given in AQL 1.3.
Take a look at the original page for more details about the example, and also some more advanced examples covering the same kind of queires.
We came up with this when discussing the expected outcome from some AQL’s like example 1.0. And it got clear for us that we had to write the AQL out to the complete form to agree on what the expected result should be.
So again: Do you agree that AQL 1.0,1.1, 1.2 and 1.3 are identical on the logical level? If yes - is the same true also for 2.0, 2.1, 2.2 and 2.3?
They look functionally equivalent (or at least quite close) to me.
But I have few small questions:
one is about not using “EHR e”, is that allowed? will that assume there is an EHR somewhere in the context? or is it implying all EHR available on system?
in the AQL there is nothing like VERSIONED_COMPOSITION, but just VERSIONED_OBJECT, is that all correct?
syntactically, not having EHR is OK. We have a dedicated… “festival” going on regarding the definition of FROM, as you know
The syntax of AQL currently requires that you have a single root in the FROM clause, as in FROM X…
Again syntactically, that X can be any RM type with/without attribute constraints. Whether or not it is allowed, that’s what needs to go into AQL specification. Same for VERSIONED_COMPOSITION, currently it is unspecified as far as I know.