Comments inline On Tue, Oct 9, 2018 at 11:05 PM Pablo Pazos <pablo.pa...@cabolabs.com> wrote:
> Hi Seref, see below :) > > On Tue, Oct 9, 2018 at 5:19 AM Seref Arikan < > serefari...@kurumsalteknoloji.com> wrote: > >> Hi Pablo, see inline please >> >> On Mon, Oct 8, 2018 at 8:29 PM Pablo Pazos <pablo.pa...@cabolabs.com> >> wrote: >> >>> Recently we discussed other problematic cases, like having criteria over >>> a structured datatype like: >>> >>> WHERE xxxx/data[at0001]/items[at0004]/value/magnitude >= 140 AND >>> xxxx/data[at0001]/items[at0004]/value/units >>> = "mmHg" >>> >>> Internally that should be interpreted as "magnitude" and "units" should >>> be attributes of the same DV_QUANTITY instance, but do all AQL >>> implementations actually do that? >>> >> >> Who knows? :) the syntax is correct though, so what they do internally >> does not matter, the WHERE clause is clearly introducing two constraints on >> the same DV_QUANTITY instance. >> > > That should be defined by the spec to avoid inconsistent implementations. > Sorry, I misunderstood what you wrote earlier. My response 'who knows?' is not valid. The semantics is clear, mag and units are attributes of the same instance. it is the aql semantics. > > On the other hand, paths might not reference the same data instance, > consider multiple occurrences of the ELEMENT in > xxxx/data[at0001]/items[at0004], > the only way to be sure that references the same data instance is by doing > something like xxxx/data[at0001]/items[at0004][0]/value/... or > xxxx/data[at0001]/items[at0004][1]/value/... > without the index, paths references a list of objects. > Very short answer: No. similar to attributes being attributes of same DV_QUANTITY instance, paths are relative paths from a single 'match', i.e. an actual object that fits the criteria defined by the FROM clause . There may be multiple matches but the where clause would not apply criteria 1 to match one and criteria 2 to match two. You can see the same semantics used by XQuery and Sparql as well. Obligatory moaning for the millionth time: All of this confusion stems from lack of a formal model defining AQL semantics. I used tree pattern queries in my research so I can use those to explain aql, but as it stands the standard we have does not have this so users will keep getting confused. > > > >> >> >>> >>> >>> But maybe that kind of query should be written as: >>> >>> WHERE dv/magnitude >= 140 AND dv/units = "mmHg" >>> >>> In that case, dv should be defined in the FROM, and all >>> variables/aliases should point to the same data instance. >>> >> >> this is also valid AQL but you may have two problems here: >> >> 1) AQL implementations may not support the full AQL semantics. That is, >> even though EHR e[..] CONTAINS DV_QUANTITY dv is legal AQL a particular >> back end may not support it. >> > > I was thinking about EHR CONTAINS OBSERVATION CONTAINS .... CONTAINS > DV_QUANTITY dv, not directly referencing a DV from the EHR, but as you > said, it is valid. > > The CONTAINS also has to handle the multiple occurrences of contained > items on attributes that are collections. > > >> In your example snippet, the FROM statement (which we don't see) should >> have an xxxx. Now to use the dv alias as you've suggested, that FROM >> claused would have to become: xxxx/data[at0001]/items[at0004]/value as dv >> and this is the case a back end may not support, or all back ends may not >> support because a common thinking among vendors is users would select more >> meaningful/high-level nodes (mostly entries or clusters under them) and >> access data via SELECT or apply criteria in WHERE clauses using relative >> paths. >> >> 2) if you'd like to apply two criteria to xxxx, then you have to declare >> xxxx in FROM clause and do WHERE xxx/path1/value <criteria> AND >> xxx/path2/value <criteria> So you have to define xxxx here, if you do what >> I described above, you only have DV_QUANTITY leaf node and you cannot >> introduce constraints to other nodes relative to xxxx. So you have pros and >> cons or 'high level nodes giveth and taketh away'... >> >> Another option, which should actually be legal given the current AQL >> grammar may be to move all constraints on xxx to the immediate predicate of >> xxxx but this should be used only when there is no ambiguity. As in: >> >> FROM ..... CONTAINS xxxx[data/items/value/magnitude >= 140 AND >> data/items/value/units = 'mmHg'] >> > > wow, that is nice :) > > > >> >> This would neatly move the joint criteria up but I would be uncomfortable >> with this because you cannot specify archetype node ids for data[]/items[] >> anymore and this would likely trigger a cartesian explosion in result sets. >> Then you'd have Ian complaining about duplicate results ;) >> >> All the best >> Seref >> >> >>> On Mon, Oct 8, 2018 at 3:06 PM Georg Fette <georg.fe...@uni-wuerzburg.de> >>> wrote: >>> >>>> Hello, >>>> I have another question concerning the semantics of AQL queries: >>>> In the documentation there are queries of the form >>>> SELECT a/data[at0001]/items[at0004]/value >>>> FROM EHR e CONTAINS COMPOSITION a[openEHR-EHR-COMPOSITION.encounter.v1] >>>> WHERE b/data[at0001]/items[at0004]/value/value >= 140 >>>> What ensures that the identified path in the SELECT section references >>>> the same data instances that are contrained with the same identified >>>> path in the WHERE section ? It could be argued that there is only one >>>> "data[at0001]" in "b" and only one "items[at0004]" in "a/data[at0001]" >>>> and so on. But is this already the full explanation for the expression >>>> to be unambiguous ? The aliases used in queries (e.g. "a") ensures that >>>> a reference to an alias definitely means the same instance. Looking at >>>> queries like the one above let assume that aliases are only syntactic >>>> sugar and are not functionally needed. Is this correct ? >>>> Greetings >>>> Georg >>>> >>>> -- >>>> --------------------------------------------------------------------- >>>> Dipl.-Inf. Georg Fette Raum: B001 >>>> Universität Würzburg Tel.: +49-(0)931-31-85516 >>>> Am Hubland Fax.: +49-(0)931-31-86732 >>>> 97074 Würzburg mail: georg.fe...@uni-wuerzburg.de >>>> --------------------------------------------------------------------- >>>> >>>> >>>> _______________________________________________ >>>> openEHR-implementers mailing list >>>> openEHR-implementers@lists.openehr.org >>>> >>>> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org >>>> >>> >>> >>> -- >>> *Ing. Pablo Pazos Gutiérrez* >>> pablo.pa...@cabolabs.com >>> +598 99 043 145 >>> skype: cabolabs >>> Subscribe to our newsletter <http://eepurl.com/b_w_tj> >>> <https://cabolabs.com/> >>> http://www.cabolabs.com >>> https://cloudehrserver.com >>> >>> _______________________________________________ >>> openEHR-implementers mailing list >>> openEHR-implementers@lists.openehr.org >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org >>> >> _______________________________________________ >> openEHR-implementers mailing list >> openEHR-implementers@lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org >> > > > -- > *Ing. Pablo Pazos Gutiérrez* > pablo.pa...@cabolabs.com > +598 99 043 145 > skype: cabolabs > Subscribe to our newsletter <http://eepurl.com/b_w_tj> > <https://cabolabs.com/> > http://www.cabolabs.com > https://cloudehrserver.com > > _______________________________________________ > openEHR-implementers mailing list > openEHR-implementers@lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org >
_______________________________________________ openEHR-implementers mailing list openEHR-implementers@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
