Re: automatic demotion of lists in AQL ?

2019-05-06 Thread Seref Arikan
Hi Georg,
I’d say yes but do it reluctantly :) you can think in terms of iteration
but in my experience it leads to incorrect assumptions and can confuse you,
especially regarding how result sets are created
I’d suggest thinking in terms of pattern matching rather than traversal but
both are valid ways of interpreting Aql semantics

Cheers
S.

On Monday, May 6, 2019, Georg Fette  wrote:

> Hi Seref,
> Ok, thank you for the answer.
> From that I and the other answers I would summarize that
> "implicit iteration over lists in order to further process the elements"
> is a paradigm that does actually exist in AQL.
> Greetings
> Georg
>
> --
> -
> Dipl.-Inf. Georg Fette  Raum: B001
> Universität WürzburgTel.: +49-(0)931-31-85516
> Am Hubland  Fax.: +49-(0)931-31-86732
> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
> -
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: automatic demotion of lists in AQL ?

2019-05-06 Thread Georg Fette

Hi Seref,
Ok, thank you for the answer.
From that I and the other answers I would summarize that
"implicit iteration over lists in order to further process the elements"
is a paradigm that does actually exist in AQL.
Greetings
Georg

--
-
Dipl.-Inf. Georg Fette  Raum: B001
Universität WürzburgTel.: +49-(0)931-31-85516
Am Hubland  Fax.: +49-(0)931-31-86732
97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
-


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: automatic demotion of lists in AQL ?

2019-05-05 Thread Seref Arikan
Have you seen a previous answer I gave to you re contains clause and nodes
without arch nd ids? The one explaining why it is unlikely to work

a/items[at0001]/value/value should do the trick

On Sunday, May 5, 2019, Georg Fette  wrote:

> Hello,
> In order to better understand the semantics of AQL I try to rephrase the
> problem I have:
> Imagine an archetype "openEHR-EHR-CLUSTER.example.v1" that allows the
> multiple existence of a specific contained field:
>
> definition
> CLUSTER[at] matches {
> items cardinality matches {0..*; unordered} matches {
> ELEMENT[at0001] occurrences matches {0..*} matches { value
> matches { DV_TEXT matches {*} } }
> }
> }
>
> Is it allowed to constrain this archetype in the WHERE part by accessing
> the field within a path? :
>
> SELECT e FROM EHR e CONSTAINS CLUSTER a[openEHR-EHR-CLUSTER.example.v1]
> WHERE a/items[at0001]/value = 'test'
>
> The problem I have with this query is that the path "a/items[at0001]" is a
> list, so it perhaps cannot be extended with "value", because a list does
> not have a field "value" but only the members of this list have this field.
> An alternative to the query above would be to resolve the list in the FROM
> part by writing something like this:
>
> SELECT e FROM EHR e CONSTAINS CLUSTER a[openEHR-EHR-CLUSTER.example.v1]
> CONTAINS DV_TEXT b
> WHERE b/value = 'test'
>
> This would work in the above example, but would create further problems if
> there are further elements in parallel to ELEMENT[at0001] that as well
> contain DV_TEXTs and which would be matched as well by the alternative
> query.
> Greetings
> Georg
>
> --
> -
> Dipl.-Inf. Georg Fette  Raum: B001
> Universität WürzburgTel.: +49-(0)931-31-85516
> Am Hubland  Fax.: +49-(0)931-31-86732
> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
> -
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_
> lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: automatic demotion of lists in AQL ?

2019-05-05 Thread Georg Fette

Hello,
In order to better understand the semantics of AQL I try to rephrase the 
problem I have:
Imagine an archetype "openEHR-EHR-CLUSTER.example.v1" that allows the 
multiple existence of a specific contained field:


definition
    CLUSTER[at] matches {
        items cardinality matches {0..*; unordered} matches {
            ELEMENT[at0001] occurrences matches {0..*} matches { value 
matches { DV_TEXT matches {*} } }

        }
    }

Is it allowed to constrain this archetype in the WHERE part by accessing 
the field within a path? :


SELECT e FROM EHR e CONSTAINS CLUSTER a[openEHR-EHR-CLUSTER.example.v1]
WHERE a/items[at0001]/value = 'test'

The problem I have with this query is that the path "a/items[at0001]" is 
a list, so it perhaps cannot be extended with "value", because a list 
does not have a field "value" but only the members of this list have 
this field.
An alternative to the query above would be to resolve the list in the 
FROM part by writing something like this:


SELECT e FROM EHR e CONSTAINS CLUSTER a[openEHR-EHR-CLUSTER.example.v1]
CONTAINS DV_TEXT b
WHERE b/value = 'test'

This would work in the above example, but would create further problems 
if there are further elements in parallel to ELEMENT[at0001] that as 
well contain DV_TEXTs and which would be matched as well by the 
alternative query.

Greetings
Georg

--
-
Dipl.-Inf. Georg Fette  Raum: B001
Universität WürzburgTel.: +49-(0)931-31-85516
Am Hubland  Fax.: +49-(0)931-31-86732
97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
-


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: automatic demotion of lists in AQL ?

2019-05-02 Thread Georg Fette

Hi Thomas,
I do not want to use the path element "items[at0001]" multiple times. 
What I mean is that in the query


SELECT a/items[at0001]/value
FROM EHR e CONTAINS CLUSTER 
a[openEHR-EHR-CLUSTER.laboratory_test_analyte.v1]


the path "a/items[at0001]" denotes a list of ELEMENT (min: 0, max: *). 
Thus the access to the field "value" of this list seems odd. But from 
the specification it seems that if I want to receive all values of all 
values of all elements this query is the correct query to make what I want.
To access all path leafs of all elements of such a list is therefore 
implicitely done.

Greetings
Georg

--
-
Dipl.-Inf. Georg Fette  Raum: B009
Universität WürzburgTel.: +49-(0)931-31-85516
Am Hubland  Fax.: +49-(0)931-31-86732
97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
-


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: automatic demotion of lists in AQL ?

2019-05-02 Thread Ian McNicoll
Yes that at codes are always effectively namespaced by their parent
archetype.

Ian
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


Re: automatic demotion of lists in AQL ?

2019-05-02 Thread Thomas Beale
Unless I am missing something, the fragment items[at0001] cannot appear 
more than once /relative to any given archetype/. Here, it is relative 
to 'a', i.e. openEHR-EHR-CLUSTER.laboratory_test_analyte.v1. Within the 
same archetype, you cannot have other items[xxx] such that the xxx are 
not unique, even if there are multiple 'items' attributes down the 
containment graph. From different archetypes you can, but there is no 
difficulty for the AQL processor to disambiguate these.


On 26/04/2019 12:27, Georg Fette wrote:

Hello,
Is it allowed to use an element that is allowed to appear multiple 
times within a path ?

For example in the query

SELECT a/items[at0001]/value
    FROM EHR e
        CONTAINS CLUSTER 
a[openEHR-EHR-CLUSTER.laboratory_test_analyte.v1]


the field items[at0001] may appear 0..* times. Thus the access to the 
value field is not properly defined from a type checking point of view.
Does the AQL specification allow such constructs and how is this 
situation interpreted ?

Greetings
Georg


--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Project, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 
 | The Objective Stance 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org