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. 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. > > >> >> >> 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
