# Specifying and implementing AQL CONTAINS
**URL:** https://discourse.openehr.org/t/specifying-and-implementing-aql-contains/427
**Category:** AQL
**Tags:** aql
**Created:** [7 March 2020 11:35 UTC](https://discourse.openehr.org/t/specifying-and-implementing-aql-contains/427 "2020-03-07T11:35:49Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [7 March 2020 11:35 UTC](https://discourse.openehr.org/t/specifying-and-implementing-aql-contains/427/1 "2020-03-07T11:35:49Z")
In the interests of clarifying what became a far more contentious issue than I would have ever imagined, let me describe briefly why I thought we should retain AQL’s independence at the spec level from any particular model.
Let’s say we have two models, openEHR RM and Acme RM, a model of some company structures. To let an AQL processor know where the logical CONTAINment relations are, the processor needs some model information. It could interrogate a meta-model, but let’s say we don’t want to provide a whole meta-model (although, we already have it, implemented and in use…), so we provide a simple graph of CONTAINS relations, like so:
```auto
// openEHR RM CONTAINS relations
source target
--------- --------
EHR COMPOSITION
COMPOSITION SECTION
COMPOSITION OBSERVATION
COMPOSITION EVALUATION
COMPOSITION INSTRUCTION
COMPOSITION ACTION
SECTION CLUSTER
OBSERVATION CLUSTER
CLUSTER ELEMENT
etc
-------------------------
// ACME IM CONTAINS relations
source target
--------- --------
COMPANY ORG_UNIT
ORG_UNIT ORG_UNIT
ORG_UNIT ASSET
ORG_UNIT ITEM
ASSET ITEM
etc
------------------------
```
Now, for an AQL query to be checked, the above table just needs to be looked up for whatever the info model at hand is. Clearly, more simple info can be added, e.g. cardinality, ref type etc:
```auto
// openEHR RM CONTAINS relations
source target cardinality ref_type
--------- -------- ----------- --------
EHR COMPOSITION * IND
COMPOSITION SECTION * DIR
COMPOSITION OBSERVATION * DIR
etc
--------------------------
// ACME IM CONTAINS relations
source target cardinality ref_type
--------- -------- ----------- --------
COMPANY ORG_UNIT 1 IND
ORG_UNIT ORG_UNIT * IND
ORG_UNIT ASSET * DIR
etc
```
Now, in terms of implementation, let’s say AQL processor AQL-A runs over a certain RDBMS with a particular schema for openEHR RM, and another for Acme IM. Let’s say it converts AQL queries to SQL queries. It’s going to need to know what SQL to use to get a COMPOSITION for an EHR, i.e. to traverse the EHR indirect ref; same for the indirect refs in the ACME model.
Assuming a 3NF schema for the moment, it will need to know something like the following SQL for the AQL `EHR[id=$id] CONTAINS c`, where `c is a `COMPOSITION`:
```auto
SELECT id // assume we get the id, not the object
FROM Composition
WHERE ehr_id = $id
```
or similar. A super-efficient schema might be non-3NF, and the above could be quite different, but you get the idea. So the AQL back-end will need whole bunch of things like this (many of which could actually be inferred from the schema…).
AQL-B implementation or binding will have a whole lot of different mappings.
The AQL spec needs to know nothing of this, there just needs to be a way of converting each logical relation to its concrete queries. If we were using a graph DB, then it will be some kind of API calls.
So as far as I can see, in principle the ability to query Containment graph meta-model info is all that needs to be mentioned in the AQL spec. Being able to query a full meta-model would provide a bit more power, but might not be that useful.
The correct graph Containment table for openEHR and any other RM would of course in reality be generated from a true meta-model representation (assuming such was available), such as we have in BMM. I could write the generator in ADL workbench or in Archie in an hour or two. It could also be added to the code in the UML extractor. But it would also be easy to write by hand.
Doing something like the above seems simple and practical to me, and why I don’t see any argument to create a direct dependency from AQL to openEHR RM. I’m sorry if I made that point too forcefully on the other thread.
If someone does have an argument as to why this or an equivalent simple approach will not work, I’d be very happy to hear it.
---
### Author:  [@matijap](https://discourse.openehr.org/u/matijap)
#### Post date: [9 March 2020 05:47 UTC](https://discourse.openehr.org/t/specifying-and-implementing-aql-contains/427/2 "2020-03-09T05:47:23Z")
I agree and I don’t think this was ever controversial. Now, due to implementation details and the fact that we only implement CDR over openEHR RM, and no other RMs, we (ab)use this fact:
> [@thomas.beale](#):
>
> But it would also be easy to write by hand.
As a consequence, it is in our interest to give priority (and your and our limited time) to other pressing issues around AQL, than to make sure the specification is “clean”. (Actually, the specification should be general, but I see benefit in it containing non-formal parts (examples and explanations) that relate to openEHR RM and possibly Demographics RM.)
---
### Author:  [@bna](https://discourse.openehr.org/u/bna)
#### Post date: [28 March 2020 11:41 UTC](https://discourse.openehr.org/t/specifying-and-implementing-aql-contains/427/3 "2020-03-28T11:41:34Z")
> [@matijap](#):
>
> agree and I don’t think this was ever controversial.
This is true. The above is IMHO not problematic. It’s about the functional expectations to the result set given an AQL and a defined dataset.
I’ve tried to provide an example here [AQL - the simplest possible question? - #10 by bna](https://discourse.openehr.org/t/aql-the-simplest-possible-question/533/10)