Hi Anthanasios I think time has shown that this is probably an area of over engineering in openEHR. All archetypes are now ITEM_TREE and could be clusters.
If we think of these as providing constraint on an underlying cluster - ITEM_LIST is a cluster of ELEMENTs and ITEM_TABLE sets up a set of clusters to provide the Information structure of an addressable table. There is a place for ITEM_LIST and ITEM_TABLE but the other issue is these constraints might be brought to bear at any point in an information hierarchy. I have proposed in version 2 of the RM that we make these specialisations of CLUSTER as a constraint statement. That would ensure backward compatibility. Cheers, Sam On 16/06/2012 1:25 AM, Athanasios Anastasiou wrote: > Hello everyone > > I am sending this email to clarify the role of ITEM_STRUCTURE in > relation to other structures (such as HISTORY and EVENT) both from the > point of view of EHR semantics as well as the computational view. > > My "problem" in one line is that i can't understand if ITEM_STRUCTURE > are there to ensure that their content is interpreted properly > semantically or they really "do what they mean" (i.e. they represent > tables, lists, trees that have to be populated as such). > > A related question is also this one: > > Is it possible that a C_MULTIPLE_ATTRIBUTE constraint pointing to an > ITEM_LIST will have upper_unbounded=True? > > If yes, then ITEM_LIST would have to be dynamically expanding (and this > complicates things a little bit but...that's life)...If no, then the > contents of ITEM_LIST can be considered static (yay!) and you only need > to know that this is an ITEM_LIST for interpretation purposes (which of > course is KEY when you come across an ITEM_TREE) > > This will help me in two points: > a) Clarify the role of ITEM_STRUCTURE and use it properly in archetypes > and templates > b) Be able to assign widgets properly (and later read data off them) > when constructing a GUI. > > A few more notes are available at the end of this message > > All the best > Athanasios Anastasiou > > > > What i understand but would like to verify is that ITEM_STRUCTURE do > what they say they do, i.e an ITEM_LIST represents a dynamic list > (constrained by some C_MULTIPLE_ATTRIBUTE) and an ITEM_SINGLE > represents....just one entry (constrained by some C_SINGLE_ATTRIBUTE). > > But i am a little bit confused for two reasons: > > a) by what is meant by HISTORY<T>. > > HISTORY already implies "A list of events" with the type of the list > being (point or interval)EVENT<T> which could imply "A [single item or > table] of ITEM_STRUCTURE" OR "A [list,tree] of ITEM_STRUCTURE"....and > this is where it gets confusing. > > Does that mean that all of the following are valid? (with respect to > HISTORY<T>) > > *) a dynamic list of events containing dynamic lists of item structure > (the history.events can expand and so can the item structures held by > events) > > *N1) a dynamic list of events containing static lists of item structure > (events can expand, but each event is supposed to simply contain a list > of items that is actually fixed in size). > > (dynamic and static expanded for the following lines as well) > *) A list of trees > *) a list of tables > *) a list of single values (this is the most intuitive thing....For > example, a time series represented as a history of point events of > single_value...) > > > b) by the explanation given in the specs > With reference to (*N1) above: > The example that is given in the spec for ITEM_LIST is that of "parts of > an address". This is what leads me to believe that ITEM_LIST is not > supposed to be a dynamic list but just something THAT IS TO BE > INTERPRETED AS A LIST but from a computational point of view is just a > list. I really do hope this makes sense. (I have gone through section 6 > in "data_structures.pdf" and that again points to ITEM_STRUCTURE being > used for interpretation rather than "definition" :-/) > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > >
