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 <mailto: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 <mailto:birger.haarbra...@plri.de>
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 <i...@freshehr.com
<mailto: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 <mailto:i...@freshehr.com>
twitter: @ianmcnicoll
Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
<mailto: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
<mailto: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 <tel:+47%2093%2043%2029%2010>
*From:*openEHR-technical
<openehr-technical-boun...@lists.openehr.org
<mailto: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.openehr.org
<mailto:openehr-technical@lists.openehr.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 <mailto:i...@freshehr.com>
twitter: @ianmcnicoll
Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
<mailto: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
<mailto: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
<mailto:openEHR-technical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/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
<mailto:openEHR-technical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/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
<mailto:openEHR-technical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/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
<mailto:openEHR-technical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/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
--
Sebastian Iancu
mob: +31625588176 | email: sebast...@code24.nl
Code24 B.V.
Comeniusstraat 2d, 1817MS Alkmaar, The Netherlands
www.code24.nl
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
