Page Status: under development

Limitations of the current AQL FROM clause

The AQL FROM clause uses class expression and a set of containment criteria to specify the query data source in a hierarchical structure. This has two limitations:

It does not specify the underlying reference model class attributes at all. Due to this reason, the AQL query engine has to make some assumptions on the openEHR RM, i.e. it has dependencies on the underly archetype RM, which is not expected. For example, the FROM clause shown below does not indicate where the COMPOSITION is from. The query engine has to either know that it needs to search for the required COMPOSITION (c) from EHR.compositions.latest_trunk_version.data, or it needs to keep searching until it founds a property with type of COMPOSITION from the EHR object or the properties within the EHR object. The former approach leads the query engine has dependencies on the underlying RM. The latter approach is not efficient and it will be an issue if there are more than one class attributes with type of COMPOSITION.
```
FROM EHR e CONTAINS COMPOSITIONS c
```
It is no way to specify the path explicitly in the FROM clause.
Let's assume that we have a composition data instance with three adhoc sections.
This FROM clause means that all the three section instances are relevant to the query. There is no way to explicitly indicate that only section instance 1 (refer data instance shown above) is relevant.
```
FROM EHR e CONTAINS COMPOSITION c CONTAINS SECTION s [openEHR-EHR-SECTION.adhoc_section.v1]
```

Enhancement of AQL FROM clause

The enhancement includes two features: one is the openEHR RM attributes can be represented, and another feature is the path of the containments can be specified explicitly.

openEHR RM attributes representation

openEHR RM attributes are represented in the AQL FROM clause indicating the path of the containments. Although traditional attribute representation in Object Query Language uses dot notation, the openEHR RM attributes are represented using openEHR path-like style. In order to keep backward compatibility, attributes representation is optional.We use the following examples illustrate the syntax of this enhancement.

Syntax

A typical class attribute representation syntax is the class epxression identifier followed by a forward slash (\/) , which is followed by the attribute name. For example,

FROM EHR e/compositions                                   // e is the class expression identifier or viable, compositions is the attribute within openEHR EHR class.

When the attribute is not specified, it can be represented as a SINGLE forward slash with wild card key (/*), which indicates that all attributes within the current class are relevant, or it can be simply ignored. For example, these two FROM clauses are equivalent:

FROM EHR e/* CONTAINS...

FROM EHR e CONTAINS...

Path representation for the FROM clause containment.

(All syntax illustrations are using the data instance with three adhoc sections.)

Indicating a path instead of the keyword 'CONTAINS' in FROM clause gives explicit information on the location in which the relevant child object(s) should be identified. Like attributes representation, path representation starts with the parent class expression identifier, which is optional, followed by a path, which is followed by the child class expression. The path used in FROM clause has same semantic meaning of openEHR path.

For example, this FROM clause indicates only the adhoc section at the path of /content is relevant, i.e. adhoc section 1 is relevant.

FROM EHR e.compositions CONTAINS COMPOSITION c/content SECTION s[openEHR-EHR-SECTION.adhoc_section.v1]         // adhoc section 1 is relevant

If the path is double slash with wild card key (//*) indicates both the the required child classes within the parent class and the child classes within the child classes are relevant. For example, the FROM clause below indicates all adhoc sections within the composition content, or within the adhoc sections are relevant, i.e. adhoc section instance 1, 2 and 3 are relevant.

FROM EHR e.compositions CONTAINS COMPOSITION c//* SECTION s[openEHR-EHR-SECTION.adhoc_section.v1]              // adhoc section 1, 2, 3 are relevant

If the path has an attribute followed by a single slash with wild card key, it means all required child classes within the specified attribute are relevant. The FROM clause below indicates only adhoc section 2 and 3 are relevant.

FROM EHR e.compositions CONTAINS COMPOSITION c/content/* SECTION s[openEHR-EHR-SECTION.adhoc_section.v1]       // adhoc section 2, 3 are relevant

Summary

Using openEHR-path like syntax for representing class attribute or a path in AQL FROM clause makes it easy to explicitly indicate the location in which the required child classes (containment classes) should be identified relevant to the AQL statement.

Appendix

Data Instance

The data instance shown below is used for all the AQL FROM clause statements illustrated below.

<!--data instance-->
<data xsi:type='COMPOSITION'...>
  <content xsi:type='SECTION' archetype_node_id='openEHR-EHR-SECTION.adhoc_section.v1'>          <!--section instance 1-->
      <items xsi:type='SECTION' archetype_node_id='openEHR-EHR-SECTION.adhoc_section.v1'>        <!--section instance 2-->
          <items xsi:type='SECTION' archetype_node_id='openEHR-EHR-SECTION.adhoc_section.v1'>    <!--section instance 3-->
          </items>
      </items>
  </content>
</data>