Hi Sebastian, Sure, that is another way of dealing with the requirement of resolving object references. Every time we discuss new features like these for AQL, we're basically looking at a choice between small language with libraries vs large language with richer native semantics. (e.g.: Java is former and C# is latter)
My inclination is usually towards small language option or at least keeping functionality in libraries and later promoting them to language syntax if they become features used frequently. The REFERS option presents no semantic ambiguity so it is not subject to my previous criticism. On Tue, Aug 21, 2018 at 4:25 PM, Sebastian Iancu <sebast...@code24.nl> wrote: > Hi Seref, Thomas, > > > On the last SEC meeting, another proposed idea (besides the one from > Seref) was to use REFERS or REFERRED BY instead of CONTAINS - but it we did > not explored further on. Could this still be considered in these > discussions? > > > Sebastian I. > > On 8/21/2018 5:10 PM, Seref Arikan wrote: > > You're missing my point. To express it in your terms: this is not about > excluding Folders from AQL spec, I said nothing of that sort or implied it > anyway. AQL does not include or exclude individual RM types, it addresses > all of RM and it is either consistent or not consistent across all of RM, > period. > > Contains statement works over folders but folders do not contain > compositions, they contain references to compositions (and to other things > if necessary) by design. Contains not returning compositions 'referenced' > under folders is not excluding folders from aql: on the contrary, it is AQL > working as intended on an RM type. > > > What is suggested here would make it inconsistent due to special cases. > I'm suggesting a way to preserve consistency and providing the > functionality that is requested. That is a win-win. There may be better > ways of doing it, but overloading the contains operator is not one of them > due to reasons I explained. > > All the best > Seref > > > > > On Tue, Aug 21, 2018 at 3:52 PM, Birger Haarbrandt < > birger.haarbra...@plri.de> wrote: > >> Hi Seref, >> >> while I understand your argument regarding overloading of definitions >> (and I agree with your reasoning), I see a clear need to not treat folders >> as second class citizens in openEHR. Not including Folders in the official >> AQL spec and leaving this to vendor-dependent functions will not be helpful >> to allow portability. Especially, as the use of folders (especially when it >> can contain data in an ITEM_STRUCTURE) is becoming a common pattern to >> represent episodes of care. >> >> Cheers, >> >> -- >> >> >> >> *Birger Haarbrandt, M. Sc. Peter L. Reichertz Institut for Medical >> Informatics (PLRI) Technical University Braunschweig and Hannover Medical >> School Software Architect HiGHmed Project * >> Tel: +49 176 640 94 640, Fax: +49 531/391-9502 >> birger.haarbra...@plri.de >> www.plri.de >> >> >> >> >> Am 21.08.2018 um 14:37 schrieb Seref Arikan: >> >> @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 >> listopenEHR-technical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> >> >> > > > _______________________________________________ > openEHR-technical mailing > listopenEHR-technical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > -- > Sebastian Iancu > mob: +31625588176 | email: sebast...@code24.nl > Code24 B.V. > Comeniusstraat 2d, 1817MS Alkmaar, The Netherlandswww.code24.nl > > > _______________________________________________ > 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
