I agree with Seref, So why not use conditions over the Folder.items instead of CONTAINS?
We might need a f.items INCLUDES c operator to resolve direct or indirect references (?) With indirect I mean via an OBJECT_REF, and direct via an object oriented link in the IM. That can be even used for CLUSTER.items or OBSERVATION.data.events, or any other collection. CONTAINS should be just for traversing the tree using ancestor-descendant relationships, including direct references. On Tue, Aug 21, 2018 at 9:37 AM, Seref Arikan < serefari...@kurumsalteknoloji.com> wrote: > @Bjorn and @Ian both: I don't think this is a good idea. This example > overloads the semantics of CONTAINS operator of AQL for a very specific > scenario: when the object reference is a reference to a composition and the > reference sits under folder F, which btw should not be a folder contained > in another folder. Based on the second Example from Bjorn, It looks like > CONTAINS also (silently?) resolves the reference of its parent's parent (f) > which is another overload of its very core definition. > > This is not standard AQL, even though AQL is probably the most variable > spec in openEHR in terms of its implementation across vendors. I know > different vendors come across different requirements at different times and > our individual solutions to those slowly make it into the standard so there > is always a window during which a feature is available from a vendor but > still not in the spec but this can be problematic at times. > > As I said in the past in numerous occasions: I think the robust way to > deal with these type of edge cases is to leave the core semantics of AQL > alone as much as possible and use extensions such as functions. Something > like > > SELECT resolve_folder_comps(f/items) as compositions_under_folder FROM EHR > e[$ehrId] CONTAINS FOLDER f[..] > > would encapsulate the specific case into resolve_folder_comp function's > definition and semantics. Anybody using this function could figure out that > it was introduced by a particular vendor, see its documentation, read its > limitations such as the root folder requirement for f etc etc. > > Pretty soon, we'll have a REST spec which the vendors will have > implemented, with API calls to run AQL queries. If those queries do not > work across REST deployments of Ocean, DIPS, Marand, Code24 etc how on > earth we can claim we have a unified way of retrieving data that works > consistently across systems? > > My suggestion above my be faulty and I'd be delighted to hear objections > and suggestions for alternatives but let's please try to not to lose the > big picture when working on AQL: it is going to be a huge value added of > openEHR in near future and its portability matters a lot. I tried to make > this point in a more subtle way in my previous messages but I seem to have > failed, hence: this rather blunt response I'm sending with good intentions > only. > > All the best > Seref > > > > > On Tue, Aug 21, 2018 at 12:44 PM, Ian McNicoll <i...@freshehr.com> wrote: > >> Thanks Bjorn >> >> That feels logical and the restriction to one layer of folders make >> sense. I appreciate that under the hood 'CONTAINS' is implemented >> differently but it feels natural to think in terms of logical containment. >> >> Ian >> Dr Ian McNicoll >> mobile +44 (0)775 209 7859 >> office +44 (0)1536 414994 >> skype: ianmcnicoll >> email: i...@freshehr.com >> twitter: @ianmcnicoll >> >> >> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org >> Director, freshEHR Clinical Informatics Ltd. >> Director, HANDIHealth CIC >> Hon. Senior Research Associate, CHIME, UCL >> >> >> On Tue, 21 Aug 2018 at 08:54, Bjørn Næss <b...@dips.no> wrote: >> >>> @ian – we have implemented the query you wrote: >>> >>> >>> >>> “select c from EHR e contains FOLDER f contains COMPOSITION c where >>> c…..” >>> >>> >>> >>> You might even write: >>> >>> >>> >>> “select c from EHR e contains FOLDER f contains FOLDER child_folder >>> contains COMPOSITION c where c…..” >>> >>> >>> >>> >>> >>> We made a restriction such that the COMPOSITION c MUST be referenced in >>> FOLDER f and not any sub-folder. This was needed to avoid circular >>> references and explosion in the result set. >>> >>> >>> >>> >>> >>> Vennlig hilsen >>> Bjørn Næss >>> Product owner >>> DIPS ASA >>> >>> Mobil +47 93 43 29 10 <+47%2093%2043%2029%2010> >>> >>> >>> >>> *From:* openEHR-technical <openehr-technical-boun...@lists.openehr.org> *On >>> Behalf Of *Ian McNicoll >>> *Sent:* mandag 20. august 2018 11:22 >>> *To:* For openEHR technical discussions <openehr-technical@lists.opene >>> hr.org> >>> *Subject:* Re: AQL on specific list of compositions >>> >>> >>> >>> Yup but AQL is so cool for this kind of thing :) >>> >>> I still want to do >>> >>> Select c FROM EHR Contains folder x contains composition c >>> >>> >>> >>> since logically folder x contains compositions. >>> >>> Ian >>> >>> >>> >>> Dr Ian McNicoll >>> mobile +44 (0)775 209 7859 >>> office +44 (0)1536 414994 >>> skype: ianmcnicoll >>> email: i...@freshehr.com >>> twitter: @ianmcnicoll >>> >>> >>> >>> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org >>> >>> Director, freshEHR Clinical Informatics Ltd. >>> Director, HANDIHealth CIC >>> Hon. Senior Research Associate, CHIME, UCL >>> >>> >>> >>> >>> >>> On Mon, 20 Aug 2018 at 10:14, Thomas Beale <thomas.be...@openehr.org> >>> wrote: >>> >>> Well if you have access to a Folder, you don't need to do an AQL query, >>> you can just retrieve the Folder structure and recurse through it, >>> picking up direct refs to VERSIONED_COMPOSITIONs. >>> >>> Creating Folders from the data on the other hand requires writing some >>> queries that look for admissions and discharges, matching them up, and >>> generating a Folder for each pair, named after the institution and/or >>> dates of the stay. A bit messy, but not hard to do, if one wants to >>> post hoc add Folders to 'old' EHRs that never had them. >>> >>> - thomas >>> >>> >>> On 20/08/2018 10:07, Ian McNicoll wrote: >>> > Thanks Thomas, >>> > >>> > What are your thoughts on the AQL example I foolishly guessed at :( >>> > and that Seref quite correctly rejected!! >>> > >>> > How would/should we do... >>> > >>> > Select all compositions referenced by Folder x. >>> >>> >>> _______________________________________________ >>> 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 >>> >> >> _______________________________________________ >> 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 > > -- *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-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
