Re: AQL access of fields of potential subclasses or derived archetypes

2019-05-03 Thread Thomas Beale 

Hi Georg,

The generic way to do this is to do what archetype tools do. An 
archetype itself mentioned class and attribute names from a 'reference 
model', but it doesn't know anything about any particular model. SUch 
tools have to be told to load a representation of the model in order to 
validate an archetype against it (i.e. in addition to validating correct 
ADL structures etc). Today, every tool is doing this by loading the BMM 
schemas of the reference models. Probably the Archie project 
contains the easiest to use code that 
does this. (Note: the latest Marand ADL-designer, and LinkEHR, as well 
as the original ADL Workbench all use BMM files these days; but Archie 
is probably going to have the cleanest, most modern source code to work 
with).


The general picture is the same for AQL queries: figure out from some 
environment var, config setting or the RM names in the archetype ids in 
the queries which BMM to use to do the validation. Once you have that it 
is easy.


If you want to know more on Archie, ask here, the authors will no doubt 
respond.


- thomas

On 03/05/2019 12:09, Georg Fette wrote:

Hello,
I have a question the is a bit related to the discussion about the 
constraining of the ELEMENT type in the laboratory_analytes.
The current specification defines the field "ehr_status" of the class 
EHR with the type OBJECT_REF. In the AQL specification there is an 
example (chapter 3.7.2.3. NOT) that accesses this field with the 
assumption that the field is of type EHR_STATUS.
I have written a type checker for AQL queries, so I am now stumbling 
across queries that access fields of potential subclasses or derived 
archetypes.

Does/should the specification generally allow such a thing ?
Greetings
Georg


--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Project, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 
 | The Objective Stance 

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL access of fields of potential subclasses or derived archetypes

2019-05-03 Thread Seref Arikan 
Bah, meant "..(I think) it should not..."

On Fri, May 3, 2019 at 12:19 PM Seref Arikan <
serefari...@kurumsalteknoloji.com> wrote:

> As things stand, No, the spec does not allow such a thing (since it is
> unspecified at the moment) and also partially No, (I don't think) it should
> not allow such a thing auto-magically or try to be smart about it.
>
> As things stand, AQL has only access to information provided by the RM. I
> for one would be uncomfortable with Aql queries making assumptions about
> actual subtypes of abstract/parent types because validating those at the
> query level is impossible.
> It is semantically 'downcasting' the type and it should only be done in an
> explicit way when the authors of the queries explicitly declare the cast
> and take the risk.
>
> I'll take a look at the example you mentioned, but it does not sound right
> to me. My earlier response to Tom mentioning comparison operators also fall
> under this topic.
>
> All the best
> Seref
>
> On Fri, May 3, 2019 at 12:10 PM Georg Fette 
> wrote:
>
>> Hello,
>> I have a question the is a bit related to the discussion about the
>> constraining of the ELEMENT type in the laboratory_analytes.
>> The current specification defines the field "ehr_status" of the class
>> EHR with the type OBJECT_REF. In the AQL specification there is an
>> example (chapter 3.7.2.3. NOT) that accesses this field with the
>> assumption that the field is of type EHR_STATUS.
>> I have written a type checker for AQL queries, so I am now stumbling
>> across queries that access fields of potential subclasses or derived
>> archetypes.
>> Does/should the specification generally allow such a thing ?
>> Greetings
>> Georg
>>
>> --
>> -
>> Dipl.-Inf. Georg Fette  Raum: B001
>> Universität WürzburgTel.: +49-(0)931-31-85516
>> Am Hubland  Fax.: +49-(0)931-31-86732
>> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
>> -
>>
>>
>> ___
>> 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

Re: AQL access of fields of potential subclasses or derived archetypes

2019-05-03 Thread Seref Arikan 
As things stand, No, the spec does not allow such a thing (since it is
unspecified at the moment) and also partially No, (I don't think) it should
not allow such a thing auto-magically or try to be smart about it.

As things stand, AQL has only access to information provided by the RM. I
for one would be uncomfortable with Aql queries making assumptions about
actual subtypes of abstract/parent types because validating those at the
query level is impossible.
It is semantically 'downcasting' the type and it should only be done in an
explicit way when the authors of the queries explicitly declare the cast
and take the risk.

I'll take a look at the example you mentioned, but it does not sound right
to me. My earlier response to Tom mentioning comparison operators also fall
under this topic.

All the best
Seref

On Fri, May 3, 2019 at 12:10 PM Georg Fette 
wrote:

> Hello,
> I have a question the is a bit related to the discussion about the
> constraining of the ELEMENT type in the laboratory_analytes.
> The current specification defines the field "ehr_status" of the class
> EHR with the type OBJECT_REF. In the AQL specification there is an
> example (chapter 3.7.2.3. NOT) that accesses this field with the
> assumption that the field is of type EHR_STATUS.
> I have written a type checker for AQL queries, so I am now stumbling
> across queries that access fields of potential subclasses or derived
> archetypes.
> Does/should the specification generally allow such a thing ?
> Greetings
> Georg
>
> --
> -
> Dipl.-Inf. Georg Fette  Raum: B001
> Universität WürzburgTel.: +49-(0)931-31-85516
> Am Hubland  Fax.: +49-(0)931-31-86732
> 97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
> -
>
>
> ___
> 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

AQL access of fields of potential subclasses or derived archetypes

2019-05-03 Thread Georg Fette 

Hello,
I have a question the is a bit related to the discussion about the 
constraining of the ELEMENT type in the laboratory_analytes.
The current specification defines the field "ehr_status" of the class 
EHR with the type OBJECT_REF. In the AQL specification there is an 
example (chapter 3.7.2.3. NOT) that accesses this field with the 
assumption that the field is of type EHR_STATUS.
I have written a type checker for AQL queries, so I am now stumbling 
across queries that access fields of potential subclasses or derived 
archetypes.

Does/should the specification generally allow such a thing ?
Greetings
Georg

--
-
Dipl.-Inf. Georg Fette  Raum: B001
Universität WürzburgTel.: +49-(0)931-31-85516
Am Hubland  Fax.: +49-(0)931-31-86732
97074 Würzburg  mail: georg.fe...@uni-wuerzburg.de
-


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org