Ah I see. Well, in that case we agree :) On Tue, Aug 21, 2018 at 5:30 PM, Birger Haarbrandt < birger.haarbra...@plri.de> wrote:
> Hi Seref, > > I'm sorry, I interpreted the following quote > > "anybody using this function could figure out that it was introduced by a > particular vendor" > > as a statement that the folder issue should be solved by particular > vendors by introducing their own functions. I'm just saying that dealing > with folders in AQL "somehow" should be part of the specification. However, > I did not express any preferences regarding the solution. > > As you seem to agree on this point: sorry for the misunderstanding! > > Best, > > Birger > > > > Am 21.08.2018 um 17:10 schrieb Seref Arikan: > > 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 > > > -- > > > > *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 >
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
