Page Status: under development
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:
FROM EHR e CONTAINS COMPOSITIONS c |
FROM EHR e CONTAINS COMPOSITION c CONTAINS SECTION s [openEHR-EHR-SECTION.adhoc_section.v1] |
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 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.
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... |
(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 |
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.
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> |