Just one small problem - the built RM instance structure usually deviates in some way from the archetype structure, e.g. the archetype might have a single EVENT node that stands for any number of EVENTs; the data may have EVENTs at 0, 5min, 10min, ..... The same goes for most of the repeated structures in the reference model - the archetype may only have one or a few 'models' of what the data should look like, while the actual data may have many.
- thomas beale Seref Arikan wrote: > Hi Hugh, > I am not in my brightest state of my mind at the moment, so I may deny > that the following belongs to me when I wake up in the morning... > I think I can build a GUI automatically without instantiating a single > RM class at all. The reason is; the archetype gives you all the > information about the types you'd expect from input. The mappings from > constraints to GUI elements is mostly a one time job: coded text to > combo boxes, free text to text boxes, duration to some more > specialized widget, amount to a textbox with a combobox for unit > etc... (this is pretty much what Ocean's archetype editor seems to do, > but of course the classes in that source code are not as well > seperated as the java ref impl) > Whatever the value is given, the input from GUI can be validated via > AOM instances, right? I know the constrained RM type in AOM, I know > the constraints is must satisfy. So the moment I'd create the > instances would be after gui generation, data input, and validation > via AOM instances. At that time I have constraint fullfilling data > which can nicely be placed in a RIM instance. > For persistence, the archetype is still the deriving force, since to > create a structured set of RM instances, you need the AOM tree anyway, > because that's where the structure is, and since every node in AOM has > its path, a tree with (node, value.toString()) tuples is all I need > for simple persistence :) > So, with some extra coding, It seems possible to parse an archetype, > generate a gui, validate input and save data without using RIM > classes. I'm not saying that this is the right way to do it, it is > just that the role of the RM classes seem to begin "mostly" when you > start coding business logic. Again this is about the java ref. impl. > Other implementations may assign more behaviour to RM classes. The > feeling I get is, the whole thing is really archetype driven (and is > it not the point anyway?) > > Many thanks for the feedback, and I hope I did not confuse anyone... > > Kind regards > Seref > > > On Tue, Nov 25, 2008 at 10:20 PM, Hugh Leslie > <hugh.leslie at oceaninformatics.com > <mailto:hugh.leslie at oceaninformatics.com>> wrote: > > Hi Serif > > I would have thought that if you wanted to persist data and > retrieve it so that it conformed consistently with the archetype, > then you would have to invent some model of persistence which > would have at least some if not all of the characteristics of the > RM - so why not use the RM! You even said that you are parsing > the archetype and building instances of the RM datatypes in memory... > > Not sure how you would do it otherwise as the archetype is just a > model of constraint on the RM ie when we are building forms for > instance, the widgets conform to not just the archetype, but also > the underlying RM and are really archetype constrained versions of > RM instances but in a GUI model. ie. A quantity for systolic > blood pressure on the form is a quantity widget that conforms at > some level to the RM but is constrained by the archetype to mean > systolic with units mmHg and range 0 to 1000 etc. > > regards Hugh > > Seref Arikan wrote: >> Hi Tom, >> Thanks for the correction of the term. Yes I'm referring to >> runtime usage of archetypes. >> After taking a look at the RM class code in ref. impl. I guess it >> is safe to say that some RM classes seems to check for proper >> values, and that's a reason to create instances of them. I guess >> this is where syntactic checks about captured data are done. >> Also almost any business logic written against the reference >> object model would require interfaces of these classes, so their >> instances would be needed in any case you have data to process, >> so even if I could avoid them for a very simple case, I'd need >> them again for making any use of data in software. It takes some >> coding to see their use :) >> >> Thanks for the response. >> >> Kind regards >> Seref >> >> On Tue, Nov 25, 2008 at 5:43 PM, Thomas Beale >> <thomas.beale at oceaninformatics.com >> <mailto:thomas.beale at oceaninformatics.com>> wrote: >> >> >> Hi Seref, >> >> I think 'lifecycle' is not the term you want, since most >> people use that >> to mean 'authoring lifecycle' i.e. the authoring, review, >> approval >> history of an archetype. Here we are talking about the >> runtime usage of >> an archetype. If I understand correctly the question it is: >> can the >> runtime instantiation of the Java RM objects be avoided in >> some simple >> circumstances? It seems unlikely to me, because most of the >> RM classes >> have some routines that would be commonly used during data >> capture, e.g. >> have a look at the History package in the data structures >> part of the >> model - >> >> http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109157527311_729550_7234Report.html >> >> - thomas beale >> >> Seref Arikan wrote: >> > Hi, >> > The term lifecycle may not be appropriate for archetypes, and >> > suggestions for a better term are more than welcommed. >> > Assuming that we constrain our interest only to a set of >> information >> > encapsulated in a single archetype, would you provide the >> technical >> > lifecycle you can imagine, for an archetype? The scenario >> is very >> > simple: an archetype is loaded from disk, displayed on >> screen, and >> > after data is provided by user, data is saved on disk, >> later loaded >> > and edited, and saved again. That's it! >> > >> > To better explain the context of the question, please think >> about the >> > java reference implementation. I'll skip some minor steps >> and give my >> > own points, and I'd like to hear yours. >> > >> > 1) Archetype is created via a tool like Ocean's designer. >> > 2) It is loaded by the parser in the java ref. impl. >> > 3) It's in memory representation is parsed, and know we the >> > constraints on rim data types expressed in java language >> terms and >> > instances of these terms in memory. >> > 4) Assuming we are creating a gui only for an archetype, we >> can create >> > a form using the constraints on data types, and Ocean's >> tool has an >> > interface tab that does it. >> > 5) A user provides information using the generated form. >> > >> > 6) We can check the validity of the data entered using the >> in memory >> > representation of archetype, like dates, amounts being in >> allowed >> > interval, and simply warning user if any data is not valid. >> > >> > Things become interesting after this point. In the context >> of the java >> > reference impl. and immutable rm classes, we can now create rm >> > instances since we now have data, and we can persist them. >> If we were >> > think of the simplest use case of just storing information >> and loading >> > it back, would we need RM instances here? How about saving >> a custom >> > represention of user input like an xml file to disk, and >> reading back >> > for updates? As long as the link to original archetype is >> preserved, >> > updates can be checked for validity. >> > >> > In short, I'd be very happy to hear your description of the >> flow for a >> > very basic scenario "in the context of java ref. impl". >> Especially how >> > you'd use the RM classes (in immutable/mutable form) and when. >> > >> > Those of you who are active in development of archetype >> based systems >> > can provide very useful feedback for others to follow >> > >> > Kind regards >> > Seref >> > >> > Ps( the use of templates is deliberately excluded here, to >> keep things >> > within a smaller scope) >> > >> >> ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > openEHR-technical mailing list >> > openEHR-technical at openehr.org >> <mailto:openEHR-technical at openehr.org> >> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> > >> >> >> -- >> *Thomas Beale >> Chief Technology Officer, Ocean Informatics >> <http://www.oceaninformatics.com/>* >> >> Chair Architectural Review Board, /open/EHR Foundation >> <http://www.openehr.org/> >> Honorary Research Fellow, University College London >> <http://www.chime.ucl.ac.uk/> >> >> >> * >> * >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org >> <mailto:openEHR-technical at openehr.org> >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> >> ------------------------------------------------------------------------ >> _______________________________________________ openEHR-technical >> mailing list openEHR-technical at openehr.org >> <mailto:openEHR-technical at openehr.org> >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >> >> >> >> >> __________ Information from ESET NOD32 Antivirus, version of virus >> signature database 3639 (20081125) __________ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> > > -- > > ________________________________________________ > Dr Hugh Leslie MBBS, Dip. Obs. RACOG, FRACGP, FACHI > Clinical Director > Ocean Informatics Pty Ltd > M: +61 404 033 767 E: hugh.leslie at oceaninformatics.com > <mailto:hugh.leslie at oceaninformatics.com> W: > www.oceaninformatics.com <http://www.oceaninformatics.com> > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org <mailto:openEHR-technical at openehr.org> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > ------------------------------------------------------------------------ > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -- *Thomas Beale Chief Technology Officer, Ocean Informatics <http://www.oceaninformatics.com/>* Chair Architectural Review Board, /open/EHR Foundation <http://www.openehr.org/> Honorary Research Fellow, University College London <http://www.chime.ucl.ac.uk/> * *
