Re: [Zope3-Users] Next Step to Bug Resolution???
Hi Tim Betreff: Re: [Zope-dev] [Zope3-Users] Next Step to Bug Resolution??? Hi Dan, On Sat, 2009-01-17 at 01:28 +0300, Dan Korostelev wrote: Hi Tim. Unfortunately I didn't follow the discussion lately, so may be the problem is no more, but... There has been a tremendous amount of help from folks like you. However there is still not a solution. I have been asked several times for a 15 minute overview. This is tough given the complexity but allow me to ask the question at a more basic level. I believe it is similar to the way I asked it last year, but here goes. I'm not going to address Field or Object here, just explain the basics. class DataStructure(Persistence): abstract class What is Persistence? Where does is come from? class ItemStructure(DataStructure): abstract class class ItemList(ItemStructure): u Logical list data structure, where each item has a value and can be referred to by a name and a positional index in the list. The list may be empty. items = List( value_type=Object(schema=IElement), title=_(uitems), description=_(uPhysical representation of the list.), required=False ) I hope you don't instanciate any of this classes and use them for store something. Do you? Regards Roger Ineichen ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Next Step to Bug Resolution???
On Sun, 2009-01-18 at 15:18 +0100, Roger Ineichen wrote: class DataStructure(Persistence): abstract class What is Persistence? Where does is come from? Sorry, I was just typing in a hurry. In reality it inherits from an openEHR class called Locatable but that gets into another whole thing about writing queries one time that run on every openEHR application. I hope you don't instanciate any of this classes and use them for store something. Do you? [my next 15 minutes] No! These classes are part of a reference model where clinical experts can use tools to build and govern maximal data sets for clinical concepts. The tools only give them the options to use classes developed in the reference model. These are called archetypes and are represented in a language called the Archetype Definition Language (A CEN/ISO standard). They are version controlled and every compliant system will have them. To describe how they work in an application let's use just one attribute of blood pressure; 'position'. So position would be an ItemList that is composed of Elements that are of type Text. In the Archetype, position can be one of: Standing Sitting Lying Reclining A specific application may only want to use Standing, Sitting, Lying. So a GUI in one location (triage?) may only want to allow the option of Sitting. But say in the ER GUI they may want to also Standing and Lying or a cardiologist may want to record Reclining (as well as the +/-angle). Of course there is lots more to BP than this. So at the application level the archetype can be constrained to allow only certain options and at the GUI level the template can be used to further constrain the options for ease AND accuracy of data entry. But now everywhere that instance of that BP goes it can be validated against the archetype and the reference model. It really isn't unlike writing Python code that runs on multiple platforms. The exception here is that openEHR is also programming language independent. OSHIP (the app I'm working on) is the Python implementation of the openEHR specifications. It will be a framework for building interoperable healthcare applications basically by writing only the templates. This work is based on more than 20 years of research and development (and other language implementations). More info at: http://www.openehr.org/shared-resources/getting_started/openehr_primer.html Cheers, Tim attachment: oe_trick.png signature.asc Description: This is a digitally signed message part ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Next Step to Bug Resolution???
Hi Dan, Thanks for taking a look. On Thu, 2008-12-18 at 20:06 +0300, Dan Korostelev wrote: Hi, Tim. I builded out your application and took a quick look at the error. It looks like you're mis-using the zope.schema.Field class and its interface. It should be only used in schema definition, while you are using Field instances as attributes for other objects. For example, you are defining the ObjectId as a field, but are using its instances as objects. That's not a valid use. Okay. I can accept that it might be a mis-use. I extracted the problematic code to separate file and changed the IField to Interface and Field to ``object`` (though you'll want to use Persistent, i guess) for ObjectId and ObjectRef and it works okay. :-) This is actually what I did at first. You may want to refer to the UML http://www.openehr.org/svn/specification/TAGS/Release-1.0.1/publishing/architecture/computable/UML/uml_start_view.html (This is the rm.support.identification package we are looking at) Since ObjectId is an abstract class so inheriting from object seems reasonable. However, most of the other id classes inherit from ObjectId and when they are used as attributes to other classes they need to have the meta data expected by zope.schema. Otherwise you get errors like keyword required not found (or something similar). This is true throughout the model. So my solution (and CERTAINLY there may be a better one) was to use the Field class (it is just a Python class - right?) as the base class for all of the base classes in the model. As I said before I may have miss-diagnosed the problem and may fix may break other things? Or, it might be that I don't fully understand your code and application architecture, so I would like to hear more about it. It looks quite over-engeneered to me. I fully understand why you might think that. IF you'll bear with me... healthcare information is very complex (certainly the complex domain I've run into in 32 years of dealing with information systems) and the knowledge domain is constantly changing. I have a short point paper here http://timothywayne.cook.googlepages.com/context-lies.pdf that gives a 30,000' view of the issues of semantic interoperability and computability of healthcare information. and a good introduction to the domain issues are here: http://www.openehr.org/shared-resources/getting_started/openehr_primer.html This model has more than 20 years of constantly improving RD on this subject. The key goal have always been to be abstract enough so that it can be implemented in any OO language on any platform in any type of healthcare setting and all stored patient information is guaranteed to be computable (decision support, etc) as well as maintain it's semantic integrity over the course of time irregardless of the changes in the science. So in essence you can go back to any point in time and not only know what the blood pressure of the patient was, but also what was known about blood pressure at that time. This model has been implemented in Eiffel, Java, C# and VB. The applications (both commercial and open source) have demonstrated these capabilities. Certainly the model isn't perfect but there is a completely open change management system in place that deals with any changes due to new ares or new science. In order for this Python implementation to remain as true as possible to the model as well as exercise the value in the ZCA; this is the path I have taken. Thanks for your help. Cheers, Tim -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ** attachment: oe_trick.png signature.asc Description: This is a digitally signed message part ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
