Re: data element type from the RM

[Seref Arikan]

Hi Georg,
Do not confuse the RM model aspects with a particular serialisation
format's aspects.

RM is technology agnostic, it contains a definition of types which can be
implemented via most mainstream (OO) programming languages.

Json or XML form of data is a 'serialisation' of an object, which is an
implementation of an RM type in a language you don't even have to know
about. The type field is a requirement of the serialisation format, so that
deserialising code can create the correct instance of the RM types for the
correct attributes.

The RM has no need of a type field, it is based on type definitions
already.  RM uses inheritance (and generics in combination with that) at
various locations in the types it defines and this is the reason the type
field in the serialised formalism is needed.

It is the same with any mainstream serialisation library that serialises
objects which come from a type system that supports inheritance. Nothing
specific to openEHR.

Keep this in mind:

RM Definitions -> Rm implementation(s) -> Data
serialisation/deserialisation -> (XML/JSON/bla)
The @type field is required at the last two levels.

Cheers
Seref


On Wed, Oct 9, 2019 at 10:27 AM Georg Fette 
wrote:

> Hello,
> Which is the field that stores the RM-model-type of data elements ? When
> I use the ocean instance generator the json contains a field called
> "@xsi:type", which contains this information. Where in the RM-model
> itself is this type-field defined ?
> 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: data element type from the RM

[Pieter Bos]

In a serialized RM instance there is always a field that lets you know what the 
class is, for example standardized as discussed before in xml, and as the field 
_type in json.

If you have this mapped as actual objects in memory in your system, those 
usually have something in place to determine which class an object is. There's 
no need to replace the standard mechanisms with something custom and 
non-standard.

In other words, yes you need to know the class of a given object, but it is 
mapped to the mechanism best suited for the used concepts and technology.

Regards,

Pieter Bos

Op 10 okt. 2019 12:19 schreef Georg Fette :
But if the class is contained within a template instance only within
some technical background information and it is not part of the
reference model, how can a query mechanism like AQL use this information
during query execution ?
How does an AQL query engine know that an archetype based on Composition
is a Composition when this link is given in the RM-part of the
serialized instance only within the archetype_id of the
archetype_details ? From that it could deduced by using the background
knowledge of the available archetype definitions that it is in fact a
Composition. It would be easier if this would be directly included in
the RM-part of a serialized Composition itself.
Or is the class type something one would assume as part of the RM ?
Greetings
Georg

--
-
Dipl.-Inf. Georg Fette  Raum: B009
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: data element type from the RM

[Diego Boscá]

I think short answer is that you need to be aware of the
templates/archetypes when executing the AQL. Each node in the archetype has
either an at code or a archetypeid in the archetype node id attribute,
that's how you link both.

El jue., 10 oct. 2019 a las 12:19, Georg Fette (<
georg.fe...@uni-wuerzburg.de>) escribió:

> But if the class is contained within a template instance only within
> some technical background information and it is not part of the
> reference model, how can a query mechanism like AQL use this information
> during query execution ?
> How does an AQL query engine know that an archetype based on Composition
> is a Composition when this link is given in the RM-part of the
> serialized instance only within the archetype_id of the
> archetype_details ? From that it could deduced by using the background
> knowledge of the available archetype definitions that it is in fact a
> Composition. It would be easier if this would be directly included in
> the RM-part of a serialized Composition itself.
> Or is the class type something one would assume as part of the RM ?
> Greetings
> Georg
>
> --
> -
> Dipl.-Inf. Georg Fette  Raum: B009
> 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
>


-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

La información contenida en este mensaje y/o archivo(s) adjunto(s), enviada
desde VERATECH FOR HEALTH, SL, es confidencial/privilegiada y está
destinada a ser leída sólo por la(s) persona(s) a la(s) que va dirigida. Le
recordamos que sus datos han sido incorporados en el sistema de tratamiento
de VERATECH FOR HEALTH, SL y que siempre y cuando se cumplan los requisitos
exigidos por la normativa, usted podrá ejercer sus derechos de acceso,
rectificación, limitación de tratamiento, supresión, portabilidad y
oposición/revocación, en los términos que establece la normativa vigente en
materia de protección de datos, dirigiendo su petición a Avda Puerto 237,
1º, pta 1 - 46011 Valencia o bien a través de correo electrónico
d...@veratech.es

Si usted lee este mensaje y no es el destinatario señalado, el empleado o
el agente responsable de entregar el mensaje al destinatario, o ha recibido
esta comunicación por error, le informamos que está totalmente prohibida, y
puede ser ilegal, cualquier divulgación, distribución o reproducción de
esta comunicación, y le rogamos que nos lo notifique inmediatamente y nos
devuelva el mensaje original a la dirección arriba mencionada. Gracias
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: data element type from the RM

[Georg Fette]

But if the class is contained within a template instance only within 
some technical background information and it is not part of the 
reference model, how can a query mechanism like AQL use this information 
during query execution ?
How does an AQL query engine know that an archetype based on Composition 
is a Composition when this link is given in the RM-part of the 
serialized instance only within the archetype_id of the 
archetype_details ? From that it could deduced by using the background 
knowledge of the available archetype definitions that it is in fact a 
Composition. It would be easier if this would be directly included in 
the RM-part of a serialized Composition itself.

Or is the class type something one would assume as part of the RM ?
Greetings
Georg

--
-
Dipl.-Inf. Georg Fette  Raum: B009
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

Re: data element type from the RM

[Pablo Pazos]

That is not a RM attribute, is the class. In XML the xsi:type is needed
because for generic types it is not possible to tell the internal structure
without specifying the type. That type is the class in the RM.

On Wed, Oct 9, 2019 at 6:27 AM Georg Fette 
wrote:

> Hello,
> Which is the field that stores the RM-model-type of data elements ? When
> I use the ocean instance generator the json contains a field called
> "@xsi:type", which contains this information. Where in the RM-model
> itself is this type-field defined ?
> 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
>


-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter 

http://www.cabolabs.com
https://cloudehrserver.com
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

data element type from the RM

[Georg Fette]

Hello,
Which is the field that stores the RM-model-type of data elements ? When 
I use the ocean instance generator the json contains a field called 
"@xsi:type", which contains this information. Where in the RM-model 
itself is this type-field defined ?

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