mlhim-owners team mailing list archive

[Tim Cook <timothywayne.cook@xxxxxxxxx>]

Hi Didonet,

Thank you for your insightful comments.  

Some of us were originally looking at UML for formal modeling but the
EMF seems to be a much better way to go.  

I have uploaded the XML Schemas (first drafts).  Is it possible for a
member of your team to turn this set of schemas into a model that we can
begin using?  The process seems to take a bit of familiarity with
Eclipse as well as a lot of assumptions that the user is a Java
developer.  

I'm sure if someone could get us started we'd be; "off to the races."

Thanks,
Tim



On Mon, 2011-02-07 at 16:05 -0200, Marcos Didonet Del Fabro wrote:
> Hello,
> 
> I've been working with EMF and related tools for a while, and I agree
> that using it is a very good deal, for different reasons:
> 
> - as already mentioned, the EMF API generates simple editors in Java.
> These editors can be customized relatively easily.
> - EMF also has a reflective API. This API enables using generic
> tree-based editors, for every Ecore metamodel.
> - it gets MHLIM closer to the Java community, and also to the modeling
> community. The Eclipse Modeling Project (EMP) has several components
> that use/contribute/interoperate with EMF, such as:
>    - xText: for parsing textual files and creating Ecore metamodels.
> This component could be used, for instance, for parsing ADLs.
>    - ATL: tool for transforming one model into another, conforming to
> different Ecore metamodels (archetype interoperability?).
>    - EMF Compare : comparison of Ecore metamodels
>    - UML editor
>    - etc.
> 
> Regards,
> 
> Marcos.
> 
> On Thu, Feb 3, 2011 at 6:57 PM, Tim Cook <timothywayne.cook@xxxxxxxxx>
> wrote:
>         Hi Luciana and All,
>         
>         On Thu, 2011-02-03 at 16:15 -0200, Luciana Tricai Cavalini
>         wrote:
>         > Hello Tim and the MLHIM community,
>         >
>         > Em 29/01/2011 16:25, Tim Cook escreveu:
>         > > > Hi Everyone,
>         > > >
>         > > > There have been several discussions in the past
>         re:modelling tools.
>         > > >
>         > > > Within the collaboration community of MLHIM there is a
>         good deal of use
>         > > > from the EMF tools.  These tools can provide us with
>         Java code
>         > > > generation, XSD Generation and UML generation.  I
>         believe we can get
>         > > > some productivity from using the Eclipse Modelling
>         Framework (EMF).
>         >
>         > I understand that this approach will bring us closer to the
>         Java
>         > developers' community, right? That's highly desirable, since
>         that
>         > enables them to build Java-and-MLHIM-based applications.
>         
>         It should enable a Java reference implementation to be
>         generated.
>         
>         I have created a branch at:
>         https://code.launchpad.net/~mlhim-specs-dev/mlhim-specs/mlhim-emf
>         
>         with these workspace entries for eclipse:
>         org.mlhim.schemas - contains the XML Schemas for MLHIM 2.0-dev
>         (current
>         working version)
>         
>         org.mlhim.rm - is an empty EMF project that I intended to
>         begin.
>         
>         However, we have a number of people with much more experience
>         than I
>         with EMF. So my thought is that someone (or several) will have
>         a spare
>         few minutes to import the schemas and begin the modelling
>         process in
>         EMF.   Just let us know via the MLHIM Owners mailing list what
>         your
>         Launchpad name (id) is and one of the managers will give you
>         write
>         access to the repository.
>         
>         > OK, so I want to make a statement: I think it is highly
>         desirable
>         > for the MLHIM Project (at least the part that I coordinate,
>         inside
>         > INCT-MACC) to move to MLHIM 2.x right now.
>         > For instance: with Tim's support, two days ago I was able to
>         migrate a
>         > simple openEHR archetype from the ADL to the XMind format
>         and it was fun
>         > and made much more sense for an epidemiologist with a bare
>         shallow
>         > understanding of the RM. And then today I started teaching
>         that for my
>         > undergrad granters and MSc students and it was a success. It
>         raised a
>         > lot of questions and some of them became "rebels" because
>         they don't
>         > understand why the RM is so complex, "because with Google
>         Forms we make
>         > forms so fast", but then I had a moment to connect to the
>         first
>         > theoretical half of the course and then they had that
>         "aaaaaw" moment.
>         > That's *excatly* what we need IMO. The specs only need to be
>         developed
>         > once, so do the RM implementations in each language. So,
>         still IMO, the
>         > tools need to be comprehensive enough to enable common
>         mortals to start
>         > modelling the knowledge on CCDs soon, and the same for
>         application
>         > developers (aka OSHIP users): the more "plugable" to any
>         development
>         > platform the implementations are, the better, because that
>         will take the
>         > application platforms out of the way from the RM
>         implementation to the
>         > application development.
>         
>         As far as tooling is concerned; this is the status.
>         
>         1) The Constraint Definition Designer (CDD) is the XMind mind
>         mapping
>         tool along with the CCD-2.0-dev template.
>         
>         XMind - http://www.xmind.net/downloads/
>         
>         Get the Concept Constraint Definition (CCD) template using
>         BZR:
>         bzr branch lp:cdd
>         
>         There is also a manual in the repository.  There isn't much to
>         it yet.
>         Do we have a volunteer to help work on this manual and
>         describe
>         installing XMind, the template, using the template, etc. ?
>          Luciana has
>         agreed to edit the notes in the CCD template.  This can be
>         used to
>         prompt sections of the manual as well. So that person can work
>         with
>         Luciana on creating a good manual.
>         
>         2) Healthcare Knowledge Component Repository (HKCR)
>         HKCR is a key component in the MLHIM family now.  This is
>         where users
>         will share their mindmaps and they will eventually be
>         converted to XML
>         Schemas that describe the concept based on the reference
>         model.  There
>         is a great deal of work to do on this project.  But there is a
>         development plan and it revolves around a specific application
>         based on
>         the Plone content management system.  This is a very popular
>         and very
>         robust platform.  After the initial elements are completed and
>         we have a
>         few CCDs to show off I believe that this will be a major
>         attraction for
>         developers.  They will actually be able to build a healthcare
>         application support business around this platform. If you are
>         interested
>         in working on this project please join the HKCR dev team
>         https://launchpad.net/~hkcr-dev
>         
>         As we move away from OSHIP 1.x to OSHIP 2 (based on MLHIM 2
>         w/CCDs)  I
>         want to move the Python development to OSHIPpy
>         (https://launchpad.net/oshippy ) and convert the Launchpad
>         OSHIP site to
>         an Umbrella for development projects.  We already have sites
>         and some
>         code for other languages (Java, Ruby, Lua, etc.)
>         https://launchpad.net/mlhim  This will give us consistency
>         across the
>         various platforms and allow each group to work independently
>         but also
>         collaborate where needed.
>         
>         There are a lot of documents to cleanup and correct.  We use
>         the LyX
>         document processor to create the source and then export to PDF
>         for
>         publication.  If anyone has an interest and a little time in
>         developing
>         a better template for all of our documents that would be
>         highly
>         appreciated.
>         
>         LyX  -  http://www.lyx.org
>         It is a very powerful documentation tool.  I hope someone can
>         help us
>         use it better.  :)  http://wiki.lyx.org/
>         
>         Anyone wanting to contribute on any level in any aspect.
>          Please let us
>         know and we can get you started. Also feel free to forward
>         this to
>         anyone you know that has an interest in open source/open
>         content,
>         knowledge modelling or tool/application development in
>         healthcare
>         
>         Thanks,
>         Tim
>         
>         
>         
>         
>         
>         
>         
>         --
>         ***************************************************************
>         Timothy Cook, MSc
>         Project Lead - Multi-Level Healthcare Information Modeling
>         http://www.mlhim.org
>         
>         LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
>         Skype ID == timothy.cook
>         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
>         
> 
> 
> 

-- 
***************************************************************
Timothy Cook, MSc
Project Lead - Multi-Level Healthcare Information Modeling
http://www.mlhim.org 

LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook 
Skype ID == timothy.cook
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