Questions about the necessity of ITEM_SINGLE
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: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111004/7588c5be/attachment.html>
Questions about the necessity of ITEM_SINGLE
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
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
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
