oship-dev team mailing list archive
-
oship-dev team
-
Mailing list archive
-
Message #00637
MLHIM was: Java Implementations was: [Fwd: Re: [Glade-users] Abusing Glade? :-)]
Hi All,
This email is probably far past due to be sent but better late than
never. :-)
For those that haven't noticed there have been a couple of emails
reference MLHIM but there hasn't really been a clear picture/plan of
what all of this means. I hope I can clear the fog a bit with this
email. I certainly welcome input and ideas from everyone; but be aware
that these things have been discussed with a number of people both
inside the OSHIP community and outside. Such as in other technical
communities like Python, Glade, MEDICAL (HIS), the WHO SDMX-HD, DataSUS
(Brasil), various academic centers, the 4CMBr group (Brasilian
municipalities), National Scientific Computing Center of Brasil and
others.
We created the Multi-Level Healthcare Information Modeling project as an
umbrella https://launchpad.net/mlhim
(a) The first movement was that we needed a copy of the openEHR
specifications in a format that could be easily translated to other
languages.
Step 1. Extract the openEHR documents from the proprietary Framemaker
files and publish them in open formats. (completed)
Step 2. Using the Lyx cross-platform Latex editor publish a new version
of the specifications under the MLHIM banner that are more readable than
the current openEHR specifications. (just beginning).
https://launchpad.net/mlhim-specs
(b) Since most of the tools being used by the openEHR Foundation are at
least partially proprietary; including the CKM which will become a
replicated component of a federated knowledge management system. It was
felt that we needed a pure open source replacement to manage the assets.
Since there is wide support for the Plone content management system
among open source, commercial and government agencies globally. We
chose to create a specialized version as a replacement for the CKM;
dubbed the Healthcare Knowledge Component Repository
https://launchpad.net/hkcr .
(c) During the MedInfo Connectathon planning it appeared that no one
really wanted to use ADL to exchange information and that XML using the
schemas found here
http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html
according to the wiki entries made as resources for the workshop. So, it
seems this is the preferred openEHR transport method inside a SOAP
package. http://www.w3.org/TR/soap12-part1/ Therefore our thought
process has turned a bit away from ADL towards XML where there are
better tools and resources available. We discovered that the GUI
designer GLADE 3.x http://glade.gnome.org/ generates XML from the
widgets contained in it's catalog and there can be custom catalogs
created and added. After confirming with the Glade users that our ideas
are quite feasible we have decided to embark on a project to use this
cross-platform tool to build a constraint definition designer
(archetypes and templates) that will create a XML file that will
represent constraints on the reference model. There are existing
Builders that can generate runtime code in a variety of languages from
these XML files. Languages such as; Python, Java, C++, C#, PHP and
others http://www.gtk.org/language-bindings.html
By storing the XML in HKCR as well as the associated runtime source code
in a secure and certified manner, these can be made available down
stream to any users on any platform for their applications based on the
reference model. The Constraint Definition Designer is here
https://launchpad.net/cdd
(d) We also have an agreement in principle to work with the MEDICAL
Hospital Information System to convert their clinical side to two level
modeling http://sourceforge.net/projects/medical/ it is built on top of
openERP and fully exercises their business intelligence capabilities.
(e) We are also working to add the SDMX-HD XML communications standard
to OSHIP so that OSHIP applications can be used in WHO and NGO based
environments in developing countries for indicator reporting. This will
open a huge market for consulting and knowledge transfer (teaching) If
you are interested in working on this XML monster let me know. We have
an open invitation to collaborate with the Medical Research Council in
South Africa on their Java library so that the two libraries are built
almost identical making them easier to maintain.
(f) Even though there are a couple of applications started that are
built on OSHIP the common thought is that to really round out MLHIM we
should have an implementation based on the Java reference implementation
as well. Something that we could get and running fairly quickly; but
that may give us freedom to expand it later if needed. That is why the
discussion around MyOODB. Not just because it's an object database but
because it also includes a web server and object publisher. I've heard
good things about db4o (Vanna) but what kind of publishing framework did
you use? Is it all available open source? Can we plug it all in as a
ready to go project? That would seem to be a great way to go.
Though there are a few more things coming they are embryonic at this
point. But the MLHIM idea is growing rapidly on a global basis and
offers opportunities for all.
Cheers,
Tim
On Mon, 2009-11-23 at 07:43 -0200, Roberto Siqueira wrote:
> Hi, folks:
> For an interesting object-oriented database (i.e. optimized for
> tree-like objects like our archetypes), please have a look at Apache's
> CouchDB: http://en.wikipedia.org/wiki/CouchDB &
> http://books.couchdb.org/relax/ . It stores JSON objects directly (I
> already proposed the JSON format as our "official" internal
> representation for the archetypes:
> https://lists.launchpad.net/oship-dev/msg00112.html) and there is
> already a Python interface for it:
> http://code.google.com/p/couchdb-python/ .
> Roberto.
>
> Tim Cook a écrit :
> > Sergio,
> >
> > Apologies,
> >
> > I missed this before. Likely due to moving in etc. and thinking it was
> > part of the Glade discussion.....anyway.
> >
> > This seems to be a pretty serious limitation of
> > http://jdoinstruments.sourceforge.net/help/userguide.htm
> >
> > "5. Collections of SCO objects are not supported: For example collection
> > of String, collection of Long, etc. are not supported,..."
> >
> > If you cannot store mixed collections then you cannot store a single
> > archetype much less an entire contribution. Maybe I'm misunderstanding
> > something?
> >
> > Also, what would be the plan for object publication over the web?
> >
> > Your points about MyOODB http://www.myoodb.org/documentation.html are
> > well taken. However, Thomas Hazel is no lightweight;
> > http://www.linkedin.com/in/thomashazel and this is how open source
> > works. Some starts a project. Other people get interested in using it
> > and chip in to help out. So we build on what he has developed and maybe
> > add to it a bit here and there molding it to our own needs along the
> > way. At least it is a complete framework.
> >
> > --Tim
> >
> >
> > On Sat, 2009-11-21 at 19:41 -0200, Sergio Freire wrote:
> >
> >> MyOODB seems to be a one-guy project for small applications. No
> >> documentation yet, it is kind of learning by examples and/or reading
> >> the source code.
> >> It seems to me that dbfo (another java oodb) seems more reliable. It
> >> has a company behind it, has some documentation and it seems that I
> >> don't need to modify my classes in order to use it. Although it is not
> >> embedded in an application server like zodb, it doesn´t seem hard to
> >> use. I will start experimenting with it.
> >>
> >> Sergio
> >>
> >> On Tue, Nov 17, 2009 at 7:19 AM, Tim Cook
> >> <timothywayne.cook@xxxxxxxxx> wrote:
> >> Hi All,
> >>
> >> I wanted to share the very encouraging response I received
> >> from the
> >> Glade list. Sergio, I hope your investigation of MyOODB is
> >> going as
> >> well.
> >>
> >> Cheers,
> >> Tim
> >>
> >>
> >> -------- Forwarded Message --------
> >> From: Tristan Van Berkom <tristan.van.berkom@xxxxxxxxx>
> >> Reply-to: tristan.van.berkom@xxxxxxxxx
> >> To: timothywayne.cook@xxxxxxxxx
> >> Cc: Glade Users <glade-users@xxxxxxxxxxxxxxxx>
> >> Subject: Re: [Glade-users] Abusing Glade? :-)
> >> Date: Tue, 17 Nov 2009 00:22:23 -0200
> >>
> >> On Mon, Nov 16, 2009 at 12:53 PM, Tim Cook
> >> <timothywayne.cook@xxxxxxxxx> wrote:
> >> > Hi All,
> >> >
> >> > For those that may have built their own widgets and added
> >> them to Glade
> >> > I'd like to ask a question.
> >> >
> >> > I want to use the Glade machinery to allow users to build
> >> what I call
> >> > constraint definitions against a well defined reference
> >> model. There
> >> > will only be about 30 or so widgets and most of them are
> >> simply
> >> > adaptations of existing widgets. Containers, trees, lists,
> >> text boxes,
> >> > etc. but of course all the properties/constraints are
> >> different
> >> > (actually simpler than in Glade).
> >> >
> >> > So I would like to hide/remove the existing Glade widgets
> >> and leave only
> >> > my two libraries visible. Then in the XML I will write the
> >> names of the
> >> > classes from the reference model as well as modify all the
> >> property
> >> > settings according to each class as needed.
> >> >
> >> > So why do this? Well, it gives me a great starting point
> >> for people
> >> > without knowledge of a complex system to be able to put
> >> components
> >> > together in a way that makes sense to them in their domain.
> >> Gives me a
> >> > generic XML output that I can use to build classes for a
> >> variety of
> >> > programming languages that can be executed against this
> >> reference model
> >> > in each of those languages.
> >> >
> >> > Here is a (non-sensical) modified XML file just showing how
> >> I envision
> >> > the object (class) names being changed to match the
> >> reference model. I
> >> > didn't bother with the property names but you can imaging
> >> that they will
> >> > be modified extensively as well.
> >> >
> >> > I would appreciate any thoughts/commets/feedback on this
> >> approach.
> >>
> >> Hi,
> >> First of all, everything you want to do should be quite
> >> simple and require
> >> no modifications to Glade, except hiding the existing
> >> catalogs.
> >>
> >> Glade installs usually with at least the GTK+ catalog - and
> >> while practically
> >> speaking, you dont need to display this catalog in the
> >> palette, you do need
> >> the GTK+ catalog to be installed to do useful things with GTK+
> >> derived objects.
> >>
> >> Basically, if you havent yet looked into the reference docs,
> >> the idea is that
> >> every catalog provides an adaptor class for any object that
> >> the catalog wants
> >> to introduce to the Glade runtime - so for instance, to
> >> leverage the code
> >> that does Drag/Resize in the GtkTable widget, you will want to
> >> derive from
> >> the GladeWidgetAdaptor that was subclassed for GtkTable.
> >>
> >> So I would suggest you start by creating your catalog with
> >> your GTK+ derived
> >> widgets and depend on the 'gtk+' catalog - when you are
> >> finished that part,
> >> which may only imply declaring the object types and
> >> disableing/hiding some
> >> properties, or could imply providing some of your own custom
> >> editing widgets
> >> (i.e. the property editor is subclassable and allows you to
> >> present
> >> the information
> >> differently than just flat properties, the class adaptor
> >> provides a mechanism
> >> to create an editor on behalf of the class)...
> >>
> >> Anyway that would be the juice of your work, hiding the
> >> installed GTK+ catalog
> >> from the palette could be a feature you maintain as a
> >> downstream hack/patch
> >> against Glade, or if its of any real use to others we could
> >> even develop some
> >> mechanism in Glade to hide widgets from catalog dependencies.
> >>
> >> Actually, you could even probably just remove the
> >> <glade-widget-class-ref> entries
> >> and <glade-widget-group> entries in the GTK+ catalog, which
> >> would result in the
> >> types getting properly introduced into the runtime, but no
> >> references
> >> to the widgets
> >> from the palette.
> >>
> >> Have fun :)
> >>
> >> Cheers,
> >> -Tristan
> >>
> >>
> >> --
> >> ***************************************************************
> >> Timothy Cook, MSc
> >>
> >> LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
> >> Skype ID == (upon request)
> >> Academic.Edu Profile: http://uff.academia.edu/TimothyCook
> >>
> >> You may get my Public GPG key from popular keyservers or
> >> from this link http://timothywayne.cook.googlepages.com/home
> >>
> >>
> >>
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~oship-dev
> > Post to : oship-dev@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~oship-dev
> > More help : https://help.launchpad.net/ListHelp
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~oship-dev
> Post to : oship-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~oship-dev
> More help : https://help.launchpad.net/ListHelp
--
***************************************************************
Timothy Cook, MSc
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
Skype ID == (upon request)
Academic.Edu Profile: http://uff.academia.edu/TimothyCook
You may get my Public GPG key from popular keyservers or
from this link http://timothywayne.cook.googlepages.com/home
Attachment:
signature.asc
Description: This is a digitally signed message part
References
