I agree with Seref’s intention of keeping it clean and clear and most importantly of course consistent. In this particular case, I think the REFERS idea is worth pursuing…to me this sounds pretty fundamental and should be supported without the need for defining an extension/function (in whatever way)
Regards, Sebastian G. Von: openEHR-technical <[email protected]> Im Auftrag von Seref Arikan Gesendet: Dienstag, 21. August 2018 17:43 An: For openEHR technical discussions <[email protected]> Betreff: Re: AQL on specific list of compositions 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> www.plri.de<http://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 <[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]> twitter: @ianmcnicoll [https://docs.google.com/uc?export=download&id=0BzLo3mNUvbAjUmNWaFZYZlZ5djg&revid=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ] Co-Chair, openEHR Foundation [email protected]<mailto:[email protected]> 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 <[email protected]<mailto:[email protected]>> 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<tel:+47%2093%2043%2029%2010> From: openEHR-technical <[email protected]<mailto:[email protected]>> On Behalf Of Ian McNicoll Sent: mandag 20. august 2018 11:22 To: For openEHR technical discussions <[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]> twitter: @ianmcnicoll [https://docs.google.com/uc?export=download&id=0BzLo3mNUvbAjUmNWaFZYZlZ5djg&revid=0BzLo3mNUvbAjRzZKc0JpUXl2SkRtMDJ0bkdUcUQxM2dqSVdrPQ] Co-Chair, openEHR Foundation [email protected]<mailto:[email protected]> Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On Mon, 20 Aug 2018 at 10:14, Thomas Beale <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list [email protected]<mailto:[email protected]> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list [email protected]<mailto:[email protected]> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list [email protected]<mailto:[email protected]> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list [email protected]<mailto:[email protected]> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Sebastian Iancu mob: +31625588176 | email: [email protected]<mailto:[email protected]> Code24 B.V. Comeniusstraat 2d, 1817MS Alkmaar, The Netherlands www.code24.nl<http://www.code24.nl> _______________________________________________ openEHR-technical mailing list [email protected]<mailto:[email protected]> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
