[openEHR SEC] CONTAINS in AQL

Hi all,

I’m reading through the AQL specs, on this section http://openehr.org/releases/QUERY/latest/docs/AQL/AQL.html#_containment it is mentioned that CONTAINS is from parent to child.

Most examples there show COMPOSITION CONTAINS ENTRY. In a case that there is a SECTION in the middle, should AQL be always COMPOSITION CONTAINS SECTION CONTAINS ENTRY?

Before reading this specific point I was thinking that CONTAINS allowed to look anywhere on the COMPOSITION tree, semantically looking for “child or descendant”, instead of just “child”.

If we have only direct “child” references, having a small tree of SECTIONs can make queries more complex, like COMPOSITION CONTAINS SECTION CONTAINS SECTION CONTAINS SECTION CONTAINS ENTRY …

Would it be useful to have that kind of “child or descendant” containment operator added to AQL?

What do others think?

Hi Pablo,

The contains statement is intended to pick up any descendent and this is how it is implemented by marand ocean and Ethercis.

This works down to cluster level and I suspect to element if we had any element archetypes.

Hi Pablo,

CONTAINS is like the '//' operator in Xpath - it's matches the thing on the right hand side, anywhere under the object on the left hand side.

So doing COMPOSITION CONTAINS OBSERVATION and similar things is normal.

The AQL documentation may need to be fixed.

- thomas

Yes - this is the way DIPS openEHR server works as well.

For Composition we match any descendant . Any structure which matches will be valid no matter how deep the location is.

For Folder we have another case. There we only match the first level . This must be treated differently since we for Folder navigate through object references.

Vennlig hilsen

Bjørn Næss

Produktansvarlig

DIPS ASA

-------- Opprinnelig melding --------

Perfect!

I think the spec needs to clarify this. The only place that the relationship involved in CONTAINS is mentioned seems to be here:

“Since archetypes are in hierarchical structure, AQL has a containment constraint which specifies the hierarchical relationships between parent and child data items.”

And only mentions parent-child, that can be interpreted as direct child. It would be good to add the semantics of CONTAINS explicitly as parent to child-or-descendant.

“descendant” is not mentioned in the current spec.

PR time! Pablo, can you raise a PR for this change?

thanks

  • thomas

Done!