Questions about the necessity of ITEM_SINGLE

[Heath Frankel]

Hi Sam,

The problem with this is that we currently use the RM inheritance to assist
in these structure constraints, i.e. an ITEM_LIST only contains a CLUSTER
containing only ELEMENTs.  However, if you think about it, the semantics of
CLUSTER and ITEM_TREE are equivalent.  It is only the level in the model
that is different.  The question is, would it be helpful to have other
ITEM_STRUCTURE subtypes within an ITEM_STRUCTURE, i.e. an ITEM_TREE
containing an ITEM_LIST or ITEM_TABLE.  This is certainly the case in
CEN13606 with the mandatory CLUSTER.structure_type attribute.

 

I think we need to go back and ask, why are we trying to simplify
ITEM_STRUCTURE?  Are we doing it to simplify the RM, archetypes or data?

 

For me the data is of interest and it is about 10 years since I first
questioned Thomas about the need for ITEM_STRUCTURE.  Not only does it
lengthen paths but it requires a whole level in data that is necessary and
requires mandatory structural only attribute values such as node_id and
name.

 

>From a domain model perspective I see the value of supporting additional
properties and methods on these sub-classes but in a persistence model they
add no value, we just need to know which domain class to materialise.  In
XML this can be done using the built-in schema type attribute and this
approach would support XML-class generator libraries, whereas using the CEN
13606 model defined attribute would require an additional adapter to
materialise the domain model class.  My point is, we probably need to
separate the RM representation from the persistence ITS.  Even with the
current RM, we could probably simplify the XML schema to collapse this level
of data, although we still need a way to represent the mandatory node_id and
name attributes of the ITEM_STRCTURE.  This would be easier if they were not
mandatory, but that is topic for another day.

 

However, if we want a RM change with migration path, the minimal change that
I can see is to make ITEM inherit from ITEM_STRUCTURE.  We could make the
ITEM_SINGLE, ITEM_TREE, ITEM_TABLE and ITEM_LIST sub type of CLUSTER but the
only true sub type of CLUSTER is ITEM_TREE.  In future we could merge
CLUSTER and ITEM_TREE and remove ITEM_SINGLE.

 

Regards

 

Heath

 

From: openehr-clinical-boun...@openehr.org
[mailto:openehr-clinical-bounces at openehr.org] On Behalf Of Sam Heard
Sent: Monday, 10 October 2011 1:40 PM
To: 'For openEHR clinical discussions'
Subject: RE: Questions about the necessity of ITEM_SINGLE

 

Hi

 

My (clinician?s thinking) idea was to have ITEM_STRUCTURE inherit from
Cluster (it is a fancy one anyway). This would make ITEM_TREE and
ITEM_SINGLE redundant allow ITEM_LIST to be used as a constraint on Cluster
to only allow ELEMENTS.

 

ITEM_TABLE could then have additional attributes .

 

Cheers, Sam

 

From: openehr-clinical-boun...@openehr.org
[mailto:openehr-clinical-bounces at openehr.org] On Behalf Of pablo pazos
Sent: Thursday, 6 October 2011 5:22 AM
To: openehr clinical
Subject: RE: Questions about the necessity of ITEM_SINGLE

 

Done: http://www.openehr.org/issues/browse/SPECPR-74

-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

  _  

Date: Tue, 4 Oct 2011 17:07:27 +0100
From: thomas.be...@oceaninformatics.com
To: openehr-clinical at openehr.org
Subject: Re: Questions about the necessity of ITEM_SINGLE

On 04/10/2011 16:18, pablo pazos wrote: 

Hi!

Your comments are very interesting, and I think we all converge to the same
point.

For the transition steps mentioned by Thomas, I think we could do quick
change with backwards compatibility, adding things without removing the
ITEM_STRUCTURE package.
We could do a fork also, and start to work in a new model without affecting
current tools, and join the specs, tools and archetypes at some point on the
future.


Now, how do we proceed? I don't know if there's a formal way to do a Change
Request to the RM. I don't want to leave this issue to die on the lists.


yep there is - post a problem report issue here
<http://www.openehr.org/issues/browse/SPECPR> .

- thomas


___ openEHR-clinical mailing
list openEHR-clinical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111011/b4e1bef9/attachment.html>

Questions about the necessity of ITEM_SINGLE

[Sam Heard]

Hi Eric,

The serialisation in XML Schema should provide the basis for transformation
I would have thought. If there is a standard transformation then we can
share data based on a previous reference model.

Is that sensible?

Cheers, Sam

> -Original Message-
> From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
> bounces at openehr.org] On Behalf Of Erik Sundvall
> Sent: Wednesday, 5 October 2011 6:58 PM
> To: For openEHR clinical discussions; For openEHR technical discussions
> Subject: Re: Questions about the necessity of ITEM_SINGLE
> 
> Hi!
> 
> Perhaps the following image with UML redesign useful as input for a
> 2.0 development fork:
> http://www.imt.liu.se/~erisu/2010/openEHR/RM-pencil.jpg
> The accompanying mail describing it is at
> http://www.openehr.org/mailarchives/openehr-technical/msg05285.html
> 
> I have right now submitted parts of that mail as a formal change
> request at:
> http://www.openehr.org/issues/browse/SPECPR-73
> Feel free to add all your own thoughts from this discussion to that
> issue.
> 
> The argument that there are systems with 1.X data is of course valid
> for refreshing 1.X one more time, but a 2.X version of the RM should
> not wait too long since we'd like to have as much as possible of
> future patient data to be in 2.X form.
> 
> Does anybody have an approximate number indicating how many patient
> records are now in 1.X systems? Do you believe those system owners
> with real patient data could be able to convert data to a 2.X based
> systems, I guess there aren't too many vendors involved...
> 
> Best regards,
> Erik Sundvall
> erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733
> 
> P.s. There was no way of specifying in jira that it could relate to a
> 2.0 release
> 
> On Tue, Oct 4, 2011 at 10:32, Thomas Beale
>  wrote:
> > On 03/10/2011 15:23, pablo pazos wrote:
> >
> > Hi everyone,
> >
> > I've been studying how to simplify the ITEM_STRUCTURE model to
> enhance the
> > persistence performance of our Open EHR-Gen project
> > (http://code.google.com/p/open-ehr-gen-framework).
> >
> > Now I'm reaching a point in which I doubt about the necessity of
> ITEM_SINGLE
> > in the RM (as a subclass of ITEM_STRUCTURE) and I want to expose some
> > arguments and hear your comments about it.
> >
> > Semantic argument: As I understand ITEM_SINGLE, the semantics of this
> class
> > are the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT, I
> mean
> > that: the semantics of ITEM_SINGLE is just a matter of cardinality
> (=1).
> >
> > Practical argument: in practice, an ITEM_SINGLE is like using an
> ELEMENT as
> > an ITEM_STRUCTURE. And if we have only TREEs, LISTs and TABLEs, the
> > interface of each class can be the same, like: getItems(),
> setItems(), the
> > ITEM_SINGLE breaks that with getItem() and setItem().
> >
> > if you have a look at the RM specification for ITEM_STRUCTURE (p13-),
> you
> > will see that the interfaces are quite different across all the
> classes -
> > the ITEM_TABLE type has table-specific accessor functions, and the
> LIST type
> > has an interface specific to a list. But... see below...
> >
> >
> > Evolution argument: If I have an archetype with an ITEM_SINGLE, but
> the
> > concept modeled with this archetype needs to change adding more nodes
> to the
> > archetype, I need to change the ITEM_SINGLE to another
> ITEM_STRUCTURE, but
> > if the archetype is modeled with an ITEM_TREE, I can add any nodes
> without
> > changing the ITEM_STRUCTURE type. I think this way is more simple to
> create
> > new archetypes with backwards compatibility.
> >
> >
> > What do you think?
> >
> > this seems to be the conclusion of people creating archetypes as
> well. It
> > has turned out over the years that archetype modellers are far less
> able to
> > stick to any particular data structure than one might have thought. I
> don't
> > think the statically declared RM type is the main issue in archetype
> > authoring - it is the archetype paths that really matter... but if
> neither
> > were to change over time, that certainly makes things easier. The two
> data
> > types we thought would be used quite often were ITEM_LIST and
> ITEM_TABLE. It
> > appears that these types have been used pretty rarely, although that
> might
> > just reflect which parts of medicine have been modelled.
> >
> > Sam and no doubt others have proposed simplifications to the
> ITEM_STRUCTURE
> > part of the model, and I woul

Questions about the necessity of ITEM_SINGLE

[Erik Sundvall]

Hi!

Perhaps the following image with UML redesign useful as input for a
2.0 development fork:
http://www.imt.liu.se/~erisu/2010/openEHR/RM-pencil.jpg
The accompanying mail describing it is at
http://www.openehr.org/mailarchives/openehr-technical/msg05285.html

I have right now submitted parts of that mail as a formal change request at:
http://www.openehr.org/issues/browse/SPECPR-73
Feel free to add all your own thoughts from this discussion to that issue.

The argument that there are systems with 1.X data is of course valid
for refreshing 1.X one more time, but a 2.X version of the RM should
not wait too long since we'd like to have as much as possible of
future patient data to be in 2.X form.

Does anybody have an approximate number indicating how many patient
records are now in 1.X systems? Do you believe those system owners
with real patient data could be able to convert data to a 2.X based
systems, I guess there aren't too many vendors involved...

Best regards,
Erik Sundvall
erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733

P.s. There was no way of specifying in jira that it could relate to a
2.0 release

On Tue, Oct 4, 2011 at 10:32, Thomas Beale
 wrote:
> On 03/10/2011 15:23, pablo pazos wrote:
>
> Hi everyone,
>
> I've been studying how to simplify the ITEM_STRUCTURE model to enhance the
> persistence performance of our Open EHR-Gen project
> (http://code.google.com/p/open-ehr-gen-framework).
>
> Now I'm reaching a point in which I doubt about the necessity of ITEM_SINGLE
> in the RM (as a subclass of ITEM_STRUCTURE) and I want to expose some
> arguments and hear your comments about it.
>
> Semantic argument: As I understand ITEM_SINGLE, the semantics of this class
> are the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT, I mean
> that: the semantics of ITEM_SINGLE is just a matter of cardinality (=1).
>
> Practical argument: in practice, an ITEM_SINGLE is like using an ELEMENT as
> an ITEM_STRUCTURE. And if we have only TREEs, LISTs and TABLEs, the
> interface of each class can be the same, like: getItems(), setItems(), the
> ITEM_SINGLE breaks that with getItem() and setItem().
>
> if you have a look at the RM specification for ITEM_STRUCTURE (p13-), you
> will see that the interfaces are quite different across all the classes -
> the ITEM_TABLE type has table-specific accessor functions, and the LIST type
> has an interface specific to a list. But... see below...
>
>
> Evolution argument: If I have an archetype with an ITEM_SINGLE, but the
> concept modeled with this archetype needs to change adding more nodes to the
> archetype, I need to change the ITEM_SINGLE to another ITEM_STRUCTURE, but
> if the archetype is modeled with an ITEM_TREE, I can add any nodes without
> changing the ITEM_STRUCTURE type. I think this way is more simple to create
> new archetypes with backwards compatibility.
>
>
> What do you think?
>
> this seems to be the conclusion of people creating archetypes as well. It
> has turned out over the years that archetype modellers are far less able to
> stick to any particular data structure than one might have thought. I don't
> think the statically declared RM type is the main issue in archetype
> authoring - it is the archetype paths that really matter... but if neither
> were to change over time, that certainly makes things easier. The two data
> types we thought would be used quite often were ITEM_LIST and ITEM_TABLE. It
> appears that these types have been used pretty rarely, although that might
> just reflect which parts of medicine have been modelled.
>
> Sam and no doubt others have proposed simplifications to the ITEM_STRUCTURE
> part of the model, and I would have no problem with simplifying it.
> However there are already openEHR operational systems in existence and a
> lot of tools and archetypes, so we can't simply make breaking changes to the
> release 1.x reference model - and - ITEM_STRUCTURE appears in a lot of
> places in the model. I have not made a proper analysis, but a general
> approach to simplifying things would probably involve adding an attribute to
> ITEM_STRUCTURE to indicate which kind of logical structure it was meant to
> be (as in the 13606 model ITEM.item_category attribute), and then always
> using an ITEM_TREE in archetypes. This would still enable the types
> ITEM_TABLE and ITEM_LIST to be implemented in software and to be able to
> 'adopt' the data of an ITEM_TREE containing the appropriate logical marker.
>
> Other more radical approaches will probably break the current RM and would
> need an alternative openEHR 2.x RM.
>
> - thomas
>
>
> ___
> openEHR-clinical mailing list
> openEHR-clinical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
>

Questions about the necessity of ITEM_SINGLE

[pablo pazos]

Hi!

Your comments are very interesting, and I think we all converge to the same 
point.

For the transition steps mentioned by Thomas, I think we could do quick change 
with backwards compatibility, adding things without removing the ITEM_STRUCTURE 
package.
We could do a fork also, and start to work in a new model without affecting 
current tools, and join the specs, tools and archetypes at some point on the 
future.


Now, how do we proceed? I don't know if there's a formal way to do a 
Change Request to the RM. I don't want to leave this issue to die on the
 lists.




-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos

  
-- next part --
An HTML attachment was scrubbed...
URL: 

Questions about the necessity of ITEM_SINGLE

[Heather Leslie]

I model using ITEM_TREE as default in every archetype, except where we might 
need a table structure. 

So I always aim to allow for maximal flexibility as the archetype evolves... 
and in almost every situation it does.

Heather

>-Original Message-
>From: openehr-clinical-bounces at openehr.org [mailto:openehr-clinical-
>bounces at openehr.org] On Behalf Of Rong Chen
>Sent: Tuesday, 4 October 2011 6:29 AM
>To: For openEHR clinical discussions
>Cc: openehr technical
>Subject: Re: Questions about the necessity of ITEM_SINGLE
>
>Hi Pablo,
>
>I agree with your analysis here especially the last one regarding evolution of
>archetypes.
>
>Regards,
>Rong
>
>On 3 October 2011 16:23, pablo pazos  wrote:
>> Hi everyone,
>>
>> I've been studying how to simplify the ITEM_STRUCTURE model to enhance
>> the persistence performance of our Open EHR-Gen project
>> (http://code.google.com/p/open-ehr-gen-framework).
>>
>> Now I'm reaching a point in which I doubt about the necessity of
>> ITEM_SINGLE in the RM (as a subclass of ITEM_STRUCTURE) and I want to
>> expose some arguments and hear your comments about it.
>>
>> Semantic argument: As I understand ITEM_SINGLE, the semantics of this
>> class are the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT,
>> I mean
>> that: the semantics of ITEM_SINGLE is just a matter of cardinality (=1).
>>
>> Practical argument: in practice, an ITEM_SINGLE is like using an
>> ELEMENT as an ITEM_STRUCTURE. And if we have only TREEs, LISTs and
>> TABLEs, the interface of each class can be the same, like: getItems(),
>> setItems(), the ITEM_SINGLE breaks that with getItem() and setItem().
>>
>> Evolution argument: If I have an archetype with an ITEM_SINGLE, but
>> the concept modeled with this archetype needs to change adding more
>> nodes to the archetype, I need to change the ITEM_SINGLE to another
>> ITEM_STRUCTURE, but if the archetype is modeled with an ITEM_TREE, I
>> can add any nodes without changing the ITEM_STRUCTURE type. I think
>> this way is more simple to create new archetypes with backwards
>compatibility.
>>
>>
>> What do you think?
>>
>> --
>> Kind regards,
>> Ing. Pablo Pazos Guti?rrez
>> LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
>> Blog: http://informatica-medica.blogspot.com/
>> Twitter: http://twitter.com/ppazos
>> ___
>> openEHR-clinical mailing list
>> openEHR-clinical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
>>
>
>___
>openEHR-clinical mailing list
>openEHR-clinical at openehr.org
>http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical

Questions about the necessity of ITEM_SINGLE

[David Moner]

I think Thomas has already mentioned that here there is a good possibility
of harmonization with EN13606. At the end it seems that we only need  single
ELEMENTs and a container with list or table semantics.

2011/10/4 Sebastian Garde 

> Yes - and if you want to go one further, ITEM_LIST is nothing more than
> a special case of ITEM_TREE as well.
> Modelling this explicitly hasn't been extremely useful I believe,
> especially if weighed against your evolution argument.
>
> Sebastian
>
> Am 04.10.2011 01:42, schrieb Heather Leslie:
> > I model using ITEM_TREE as default in every archetype, except where we
> might need a table structure.
> >
> > So I always aim to allow for maximal flexibility as the archetype
> evolves... and in almost every situation it does.
> >
> > Heather
> >
> >> -Original Message-
> >> From: openehr-clinical-bounces at openehr.org [mailto:openehr-clinical-
> >> bounces at openehr.org] On Behalf Of Rong Chen
> >> Sent: Tuesday, 4 October 2011 6:29 AM
> >> To: For openEHR clinical discussions
> >> Cc: openehr technical
> >> Subject: Re: Questions about the necessity of ITEM_SINGLE
> >>
> >> Hi Pablo,
> >>
> >> I agree with your analysis here especially the last one regarding
> evolution of
> >> archetypes.
> >>
> >> Regards,
> >> Rong
> >>
> >> On 3 October 2011 16:23, pablo pazos  wrote:
> >>> Hi everyone,
> >>>
> >>> I've been studying how to simplify the ITEM_STRUCTURE model to enhance
> >>> the persistence performance of our Open EHR-Gen project
> >>> (http://code.google.com/p/open-ehr-gen-framework).
> >>>
> >>> Now I'm reaching a point in which I doubt about the necessity of
> >>> ITEM_SINGLE in the RM (as a subclass of ITEM_STRUCTURE) and I want to
> >>> expose some arguments and hear your comments about it.
> >>>
> >>> Semantic argument: As I understand ITEM_SINGLE, the semantics of this
> >>> class are the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT,
> >>> I mean
> >>> that: the semantics of ITEM_SINGLE is just a matter of cardinality
> (=1).
> >>>
> >>> Practical argument: in practice, an ITEM_SINGLE is like using an
> >>> ELEMENT as an ITEM_STRUCTURE. And if we have only TREEs, LISTs and
> >>> TABLEs, the interface of each class can be the same, like: getItems(),
> >>> setItems(), the ITEM_SINGLE breaks that with getItem() and setItem().
> >>>
> >>> Evolution argument: If I have an archetype with an ITEM_SINGLE, but
> >>> the concept modeled with this archetype needs to change adding more
> >>> nodes to the archetype, I need to change the ITEM_SINGLE to another
> >>> ITEM_STRUCTURE, but if the archetype is modeled with an ITEM_TREE, I
> >>> can add any nodes without changing the ITEM_STRUCTURE type. I think
> >>> this way is more simple to create new archetypes with backwards
> >> compatibility.
> >>>
> >>> What do you think?
> >>>
> >>> --
> >>> Kind regards,
> >>> Ing. Pablo Pazos Guti?rrez
> >>> LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
> >>> Blog: http://informatica-medica.blogspot.com/
> >>> Twitter: http://twitter.com/ppazos
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>



-- 
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es

Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia ? 46022 (Espa?a)
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111004/4d18e261/attachment.html>

Questions about the necessity of ITEM_SINGLE

[Sebastian Garde]

Yes - and if you want to go one further, ITEM_LIST is nothing more than 
a special case of ITEM_TREE as well.
Modelling this explicitly hasn't been extremely useful I believe, 
especially if weighed against your evolution argument.

Sebastian

Am 04.10.2011 01:42, schrieb Heather Leslie:
> I model using ITEM_TREE as default in every archetype, except where we might 
> need a table structure.
>
> So I always aim to allow for maximal flexibility as the archetype evolves... 
> and in almost every situation it does.
>
> Heather
>
>> -Original Message-
>> From: openehr-clinical-bounces at openehr.org [mailto:openehr-clinical-
>> bounces at openehr.org] On Behalf Of Rong Chen
>> Sent: Tuesday, 4 October 2011 6:29 AM
>> To: For openEHR clinical discussions
>> Cc: openehr technical
>> Subject: Re: Questions about the necessity of ITEM_SINGLE
>>
>> Hi Pablo,
>>
>> I agree with your analysis here especially the last one regarding evolution 
>> of
>> archetypes.
>>
>> Regards,
>> Rong
>>
>> On 3 October 2011 16:23, pablo pazos  wrote:
>>> Hi everyone,
>>>
>>> I've been studying how to simplify the ITEM_STRUCTURE model to enhance
>>> the persistence performance of our Open EHR-Gen project
>>> (http://code.google.com/p/open-ehr-gen-framework).
>>>
>>> Now I'm reaching a point in which I doubt about the necessity of
>>> ITEM_SINGLE in the RM (as a subclass of ITEM_STRUCTURE) and I want to
>>> expose some arguments and hear your comments about it.
>>>
>>> Semantic argument: As I understand ITEM_SINGLE, the semantics of this
>>> class are the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT,
>>> I mean
>>> that: the semantics of ITEM_SINGLE is just a matter of cardinality (=1).
>>>
>>> Practical argument: in practice, an ITEM_SINGLE is like using an
>>> ELEMENT as an ITEM_STRUCTURE. And if we have only TREEs, LISTs and
>>> TABLEs, the interface of each class can be the same, like: getItems(),
>>> setItems(), the ITEM_SINGLE breaks that with getItem() and setItem().
>>>
>>> Evolution argument: If I have an archetype with an ITEM_SINGLE, but
>>> the concept modeled with this archetype needs to change adding more
>>> nodes to the archetype, I need to change the ITEM_SINGLE to another
>>> ITEM_STRUCTURE, but if the archetype is modeled with an ITEM_TREE, I
>>> can add any nodes without changing the ITEM_STRUCTURE type. I think
>>> this way is more simple to create new archetypes with backwards
>> compatibility.
>>>
>>> What do you think?
>>>
>>> --
>>> Kind regards,
>>> Ing. Pablo Pazos Guti?rrez
>>> LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
>>> Blog: http://informatica-medica.blogspot.com/
>>> Twitter: http://twitter.com/ppazos

Questions about the necessity of ITEM_SINGLE

[Rong Chen]

Hi Pablo,

I agree with your analysis here especially the last one regarding
evolution of archetypes.

Regards,
Rong

On 3 October 2011 16:23, pablo pazos  wrote:
> Hi everyone,
>
> I've been studying how to simplify the ITEM_STRUCTURE model to enhance the
> persistence performance of our Open EHR-Gen project
> (http://code.google.com/p/open-ehr-gen-framework).
>
> Now I'm reaching a point in which I doubt about the necessity of ITEM_SINGLE
> in the RM (as a subclass of ITEM_STRUCTURE) and I want to expose some
> arguments and hear your comments about it.
>
> Semantic argument: As I understand ITEM_SINGLE, the semantics of this class
> are the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT, I mean
> that: the semantics of ITEM_SINGLE is just a matter of cardinality (=1).
>
> Practical argument: in practice, an ITEM_SINGLE is like using an ELEMENT as
> an ITEM_STRUCTURE. And if we have only TREEs, LISTs and TABLEs, the
> interface of each class can be the same, like: getItems(), setItems(), the
> ITEM_SINGLE breaks that with getItem() and setItem().
>
> Evolution argument: If I have an archetype with an ITEM_SINGLE, but the
> concept modeled with this archetype needs to change adding more nodes to the
> archetype, I need to change the ITEM_SINGLE to another ITEM_STRUCTURE, but
> if the archetype is modeled with an ITEM_TREE, I can add any nodes without
> changing the ITEM_STRUCTURE type. I think this way is more simple to create
> new archetypes with backwards compatibility.
>
>
> What do you think?
>
> --
> Kind regards,
> Ing. Pablo Pazos Guti?rrez
> LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
> Blog: http://informatica-medica.blogspot.com/
> Twitter: http://twitter.com/ppazos
> ___
> openEHR-clinical mailing list
> openEHR-clinical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
>

Questions about the necessity of ITEM_SINGLE

[pablo pazos]

Hi everyone,

I've been studying how to simplify the ITEM_STRUCTURE model to enhance the 
persistence performance of our Open EHR-Gen project 
(http://code.google.com/p/open-ehr-gen-framework).

Now I'm reaching a point in which I doubt about the necessity of ITEM_SINGLE in 
the RM (as a subclass of ITEM_STRUCTURE) and I want to expose some arguments 
and hear your comments about it.

Semantic argument: As I understand ITEM_SINGLE, the semantics of this class are 
the same as an ITEM_LIST or ITEM_TREE with only one ELEMENT, I mean that: the 
semantics of ITEM_SINGLE is just a matter of cardinality (=1).

Practical argument: in practice, an ITEM_SINGLE is like using an ELEMENT as an 
ITEM_STRUCTURE. And if we have only TREEs, LISTs and TABLEs, the interface of 
each class can be the same, like: getItems(), setItems(), the ITEM_SINGLE 
breaks that with getItem() and setItem().

Evolution argument: If I have an archetype with an ITEM_SINGLE, but the concept 
modeled with this archetype needs to change adding more nodes to the archetype, 
I need to change the ITEM_SINGLE to another ITEM_STRUCTURE, but if the 
archetype is modeled with an ITEM_TREE, I can add any nodes without changing 
the ITEM_STRUCTURE type. I think this way is more simple to create new 
archetypes with backwards compatibility.


What do you think?

-- 
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos
-- next part --
An HTML attachment was scrubbed...
URL: