date:20181129

Re: ADL specification question

2018-11-29 Thread Thomas Beale

Hi Georg,

the other answers are right, but for reference you may want to read the 
relevant part of the ADL specification (ADL2 version 
; 
ADL1.4 version 
). 
The main thing to understand is that 'cardinality' applies to container 
attributes, and that 'occurrences' defines how often an object node may 
appear in the data.

The ADL2 version gives the clearer explanation, and the main semantics 
of cardinality and occurrences have not changed from one to the other.

- thomas

On 29/11/2018 10:09, Georg Fette wrote:

Hi Diego,
The items inside the CLUSTER look like this:

CLUSTER[at0001] matches {
   items cardinality matches {2..*; ordered} matches {
 ELEMENT[at0002] matches {
   value matches {
 DV_COUNT matches {*}
   }
 }
 ELEMENT[at0003] matches {
   value matches {
 DV_TEXT matches {*}
   }
 }
   }
}

It could be that I not yet fully understand ADL, therefore I would need to 
verify/falsify some assumptions I make:

- Both elements (at0002, at0003) have an implicit cardinality of "1..1" ?
- The keyword "ordered" just indicates that the items inside an instance of the 
cluster at0001 have to maintain the order in which they were defined. The order does not 
affect an enforced order of the types of the elements inside the cluster ?
- What is true?:
* The cluster at0001 may include the elements at0002 and at0003 in any order an 
unlimited amounts of them as long as the cluster includes at least 2 of them. The 
specification inside of at0001 just gives the set of possible elements that may appear as 
items of at0001. E.g. "at0003, at0003, at0002, at0003, ..."
* The cluster at0001 has to include at least 2 elements in the order given in the 
at0001 definition and the order may be repeat an unlimited amount of times, e.g. 
"at0002, at0003, at0002, at0003, ..."

Greetings
Georg

>Hello Georg,
>
>What (and how many) objects you have inside the items attribute?
>Think the cardinality as the "vector" capacity, and inside you can put them
>in order (depending on their occurrences, they may even not appear at all)
>
>Regards
>
>El jue., 29 nov. 2018 10:31, Georg Fette http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org>>
>escribió:

Am 29.11.2018 um 10:30 schrieb Georg Fette:

Hello,
I have an archetype with a complex object derived of CLUSTER with
"items cardinality matches {2..*; ordered}"
and those two items are also defined inside the complex object.
I understand the semantics of this definition that both items always 
have to appear together inside the cluster but the package of those 
two items may appear any number of times.
Is it allowed for instances of this archetype to have an uneven 
number of items > 2 inside this cluster, because that would still 
suffice the restriction of having 2..* children. Or do the instances 
always have to have both elements as a package that are defined as 
items in this cluster.
As I am not the author of the archetype I do not completely 
understand how the definition has to be interpreted.

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

--
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: Two-level modelling diagram

2018-11-29 Thread Thomas Beale



On 28/11/2018 17:56, Pablo Pazos wrote:

Do we need the user in the middle?


we could, although I learned a long time ago to only include relevant 
elements, and the point of this diagram is just one thing: where the 
models of information are made, and how they relate to the built system.




Another point, I always thought that diagram lacks some management, 
for instance the developer is not who manages the IT aspects of the 
system running in production, makes deployments, updates, etc.


well then we are into the cycle of software management, I'm not trying 
to represent any of that, just to show in a relatively simple way how 
the models relate to the system.




And thinking about this, there are at least two main flows: one is 
design-development-use, and the other is maintenance-evolution. I 
think the second one might be even more important than the first one, 
where domain experts get feedback from the users, and the IT team gets 
feedback from users and domain experts, for instance to make changes 
or create more reports or add UI elements. IMO this second flow is 
what gives openEHR a lot of value.


also true - but I would make a second diagram to show UI / UX feedback 
loop and evolution.


You can try to make some variations, just use the draw.io source at 
Github 
.


- t


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

Re: ADL specification question

2018-11-29 Thread Diego Boscá

As Pieter said, default occurrences (if not stated) are 0..*
So if the attribute is ordered, this means that if the object appears, it
has to be in that specific order, in your case at0002, at0002...at0003,
at0003
Cardinality tells you how many of these are valid, so minimum 2.
Take into account that occurrences of 0..* means that a given object may
not appear, so in this case at0002, at0002 or at0003, at0003 are both valid

Regards

El jue., 29 nov. 2018 11:09, Georg Fette 
escribió:

> --
>
> Hi Diego,
> The items inside the CLUSTER look like this:
>
> CLUSTER[at0001] matches {
>   items cardinality matches {2..*; ordered} matches {
> ELEMENT[at0002] matches {
>   value matches {
> DV_COUNT matches {*}
>   }
> }
> ELEMENT[at0003] matches {
>   value matches {
> DV_TEXT matches {*}
>   }
> }
>   }
> }
>
> It could be that I not yet fully understand ADL, therefore I would need to 
> verify/falsify some assumptions I make:
>
> - Both elements (at0002, at0003) have an implicit cardinality of "1..1" ?
> - The keyword "ordered" just indicates that the items inside an instance of 
> the cluster at0001 have to maintain the order in which they were defined. The 
> order does not affect an enforced order of the types of the elements inside 
> the cluster ?
> - What is true?:
>   * The cluster at0001 may include the elements at0002 and at0003 in any 
> order an unlimited amounts of them as long as the cluster includes at least 2 
> of them. The specification inside of at0001 just gives the set of possible 
> elements that may appear as items of at0001. E.g. "at0003, at0003, at0002, 
> at0003, ..."
>   * The cluster at0001 has to include at least 2 elements in the order 
> given in the at0001 definition and the order may be repeat an unlimited 
> amount of times, e.g. "at0002, at0003, at0002, at0003, ..."
>
> Greetings
> Georg
>
> >Hello Georg,
> >
> >What (and how many) objects you have inside the items attribute?
> >Think the cardinality as the "vector" capacity, and inside you can put them
> >in order (depending on their occurrences, they may even not appear at all)
> >
> >Regards
> >
> >El jue., 29 nov. 2018 10:31, Georg Fette  >>
>
> >escribió:
>
>
> Am 29.11.2018 um 10:30 schrieb Georg Fette:
>
> Hello,
> I have an archetype with a complex object derived of CLUSTER with
> "items cardinality matches {2..*; ordered}"
> and those two items are also defined inside the complex object.
> I understand the semantics of this definition that both items always have
> to appear together inside the cluster but the package of those two items
> may appear any number of times.
> Is it allowed for instances of this archetype to have an uneven number of
> items > 2 inside this cluster, because that would still suffice the
> restriction of having 2..* children. Or do the instances always have to
> have both elements as a package that are defined as items in this cluster.
> As I am not the author of the archetype I do not completely understand how
> the definition has to be interpreted.
> 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: ADL specification question

2018-11-29 Thread Georg Fette




Hi Diego,
The items inside the CLUSTER look like this:

CLUSTER[at0001] matches {
  items cardinality matches {2..*; ordered} matches {
ELEMENT[at0002] matches {
  value matches {
DV_COUNT matches {*}
  }
}
ELEMENT[at0003] matches {
  value matches {
DV_TEXT matches {*}
  }
}
  }
}

It could be that I not yet fully understand ADL, therefore I would need to 
verify/falsify some assumptions I make:

- Both elements (at0002, at0003) have an implicit cardinality of "1..1" ?
- The keyword "ordered" just indicates that the items inside an instance of the 
cluster at0001 have to maintain the order in which they were defined. The order does not 
affect an enforced order of the types of the elements inside the cluster ?
- What is true?:
* The cluster at0001 may include the elements at0002 and at0003 in any order an 
unlimited amounts of them as long as the cluster includes at least 2 of them. The 
specification inside of at0001 just gives the set of possible elements that may appear as 
items of at0001. E.g. "at0003, at0003, at0002, at0003, ..."
* The cluster at0001 has to include at least 2 elements in the order given in the 
at0001 definition and the order may be repeat an unlimited amount of times, e.g. 
"at0002, at0003, at0002, at0003, ..."

Greetings
Georg


Hello Georg,

What (and how many) objects you have inside the items attribute?
Think the cardinality as the "vector" capacity, and inside you can put them
in order (depending on their occurrences, they may even not appear at all)

Regards

El jue., 29 nov. 2018 10:31, Georg Fette 
>

>escribió:


Am 29.11.2018 um 10:30 schrieb Georg Fette:

Hello,
I have an archetype with a complex object derived of CLUSTER with
"items cardinality matches {2..*; ordered}"
and those two items are also defined inside the complex object.
I understand the semantics of this definition that both items always 
have to appear together inside the cluster but the package of those 
two items may appear any number of times.
Is it allowed for instances of this archetype to have an uneven number 
of items > 2 inside this cluster, because that would still suffice the 
restriction of having 2..* children. Or do the instances always have 
to have both elements as a package that are defined as items in this 
cluster.
As I am not the author of the archetype I do not completely understand 
how the definition has to be interpreted.

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

Re: ADL specification question

2018-11-29 Thread Pieter Bos

The cardinality you mention only defines how many values the items attribute 
must have. In this case at least two.

Which values that are depends on the child elements/items and their occurrences 
attribute. If the occurrence of both of these  is 1 exactly, they must both 
appear. If they both are 0..*, it can be two or more of the first, two or more 
of the second, or at least one but possibly more of both. More options are 
possible. If occurrences is not defined, in this case I think it defaults to 
0..*.

Regards,

Pieter Bos

Op 29 nov. 2018 10:31 schreef Georg Fette :
Hello,
I have an archetype with a complex object derived of CLUSTER with
"items cardinality matches {2..*; ordered}"
and those two items are also defined inside the complex object.
I understand the semantics of this definition that both items always
have to appear together inside the cluster but the package of those two
items may appear any number of times.
Is it allowed for instances of this archetype to have an uneven number
of items > 2 inside this cluster, because that would still suffice the
restriction of having 2..* children. Or do the instances always have to
have both elements as a package that are defined as items in this cluster.
As I am not the author of the archetype I do not completely understand
how the definition has to be interpreted.
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: ADL specification question

2018-11-29 Thread Diego Boscá

Hello Georg,

What (and how many) objects you have inside the items attribute?
Think the cardinality as the "vector" capacity, and inside you can put them
in order (depending on their occurrences, they may even not appear at all)

Regards

El jue., 29 nov. 2018 10:31, Georg Fette 
escribió:

> Hello,
> I have an archetype with a complex object derived of CLUSTER with
> "items cardinality matches {2..*; ordered}"
> and those two items are also defined inside the complex object.
> I understand the semantics of this definition that both items always
> have to appear together inside the cluster but the package of those two
> items may appear any number of times.
> Is it allowed for instances of this archetype to have an uneven number
> of items > 2 inside this cluster, because that would still suffice the
> restriction of having 2..* children. Or do the instances always have to
> have both elements as a package that are defined as items in this cluster.
> As I am not the author of the archetype I do not completely understand
> how the definition has to be interpreted.
> 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

ADL specification question

2018-11-29 Thread Georg Fette


Hello,
I have an archetype with a complex object derived of CLUSTER with
"items cardinality matches {2..*; ordered}"
and those two items are also defined inside the complex object.
I understand the semantics of this definition that both items always 
have to appear together inside the cluster but the package of those two 
items may appear any number of times.
Is it allowed for instances of this archetype to have an uneven number 
of items > 2 inside this cluster, because that would still suffice the 
restriction of having 2..* children. Or do the instances always have to 
have both elements as a package that are defined as items in this cluster.
As I am not the author of the archetype I do not completely understand 
how the definition has to be interpreted.

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

Re: ADL specification question

Re: Two-level modelling diagram

Re: ADL specification question

Re: ADL specification question

Re: ADL specification question

Re: ADL specification question

ADL specification question

7 matches

Site Navigation

Mail list logo

Footer information