This wiki has undergone a migration to Confluence found Here
Difference between revisions of "RIMBAA 201005 Minutes"
Jump to navigation
Jump to search
Rene spronk (talk | contribs) |
Rene spronk (talk | contribs) |
||
Line 10: | Line 10: | ||
**Create/update RIMBAA DMP, latest template at [http://www.hl7.org/participate/decisionmaking.cfm] | **Create/update RIMBAA DMP, latest template at [http://www.hl7.org/participate/decisionmaking.cfm] | ||
**Review/update RIMBAA mission&scope statement, currently [http://www.hl7.org/Special/committees/java/overview.cfm] | **Review/update RIMBAA mission&scope statement, currently [http://www.hl7.org/Special/committees/java/overview.cfm] | ||
− | ***Notably to see how we should/could add the S-column to the scope | + | ***Notably to see how we should/could add the S-column to the scope. From the minutes of the meeting in Amsterdam: ''Andrea: the current scope of RIMBAA is (officially) limited to the P* and O* columns of the technology matrix (i.e. the use of RIM based models within the application) - interoperability is out of scope. Rene: effectively S* column is within scope, but by focusing on those v3 implementations that use RIM based models internally (O and P), we're focusing on the most advanced, largest and complex implementations of v3. It'll be easier to learn the best practices from such implementations, than from implementations that solely want to use RIM-based models in the context of interoperability. Typically those applications use DOM/SAX/XPath and other classic XML techniques – there’s not a lot we could learn from them that’s not covered by the larger implementations as well. We could declare S* to be in scope, but with the added remark that it will not be the primary focus of RIMBAA.'' |
− | *Updates from the recent RIMBAA meeting in Amsterdam: | + | *Updates from the recent [[RIMBAA 201003 Minutes|RIMBAA meeting in Amsterdam]]: |
− | **Context Conduction ( | + | **Context Conduction (see [http://www.ringholm.de/persist/20100311_RIMBAA_Context_conduction.pptx]) |
− | **MIF meta model browser | + | **MIF meta model browser (see [http://www.ringholm.de/persist/MifModel.exe]) |
+ | *[[RIMBAA: SAIF vs RIMBAA|SAIF vs RIMBAA]] - update (Michael van der Zel). | ||
*Work on the deliverable(s) | *Work on the deliverable(s) | ||
+ | **[[ORM best practices]] , original aim was to finalize this during this WGM | ||
**Review code generation related RIMBAA issues | **Review code generation related RIMBAA issues | ||
**#[[Schema based code generation]] | **#[[Schema based code generation]] |
Revision as of 13:48, 22 March 2010
Agenda for the May 2010 WGM in Rio de Janeiro
Monday Q1 (09:00-10:30)
- Approval of agenda for the week (5 minutes)
- Administrative agenda items
- Announcements
- Upcoming RIMBAA meetings: September - Bologna, Italy; WGM in Cambridge in October, and November 4 - London UK.
- Approval of the minutes of the Out-of-cycle meeting on March 11 in Amsterdam (5 minutes)
- Review Draft agenda for the September meeting in Bologna and the Cambridge WGM.
- Create/update RIMBAA DMP, latest template at [1]
- Review/update RIMBAA mission&scope statement, currently [2]
- Notably to see how we should/could add the S-column to the scope. From the minutes of the meeting in Amsterdam: Andrea: the current scope of RIMBAA is (officially) limited to the P* and O* columns of the technology matrix (i.e. the use of RIM based models within the application) - interoperability is out of scope. Rene: effectively S* column is within scope, but by focusing on those v3 implementations that use RIM based models internally (O and P), we're focusing on the most advanced, largest and complex implementations of v3. It'll be easier to learn the best practices from such implementations, than from implementations that solely want to use RIM-based models in the context of interoperability. Typically those applications use DOM/SAX/XPath and other classic XML techniques – there’s not a lot we could learn from them that’s not covered by the larger implementations as well. We could declare S* to be in scope, but with the added remark that it will not be the primary focus of RIMBAA.
- Announcements
- Updates from the recent RIMBAA meeting in Amsterdam:
- SAIF vs RIMBAA - update (Michael van der Zel).
- Work on the deliverable(s)
- ORM best practices , original aim was to finalize this during this WGM
- Review code generation related RIMBAA issues
- Discuss Object nets and object trees
- Context Conduction in RIMBAA Applications
Tuesday Q6 (19:00-21:00)
- Product/Tooling demonstrations
- TBD
- Work on the deliverable(s)
- Grahame Grieve, to lead a discussion on RIM ITS implementation experiences
- See also: http://www.ringholm.de/persist/20100311_RIMBAA_RIM_ITS_overview.pptx (presented during the March out-of-cycle meeting held in Amsterdam)
- Presentations/discussion related to data type / RIMBAA issues:
- Grahame Grieve: Using R2 data types in your object model, and R1 data types on the wire. The differences will be explored - with Eclipse parser examples. Grahame: I convert between the forms in my parser and base all the other code off the proper object model R2 represents. You can also substitute R2 for R1 on the wire if you control both ends. It's a fairly simple change to do it minimally, all you need is a mapping schema that aliases BN to BL, CE and CV to CD (an up to date list is at RIM_ITS_Specification#Appendix_.231)
- Cecil Lynch: CD datatype implementation in a RIM based backend database used at MD Anderson Cancer Center.
- Some data type specific issues will be addressed, e.g. software implementation of GTS
- Grahame Grieve, to lead a discussion on RIM ITS implementation experiences
Wednesday Q4 (15:30-17:00)
- Product/Tooling demonstrations
- Cecil Lynch (Ontoreason LLC) on a RIMBAA implementation
- Experience at MD Anderson Cancer Center in building a RIM based backend and an application to transformed their "structured documents" from their EMR into CDA and the transform to the backend RIM model.
- It is based on an OWL ontology of the CDA model so that we can bind terminology to the CDA attributes using the inferencing from OWL. Expressing the v3 RIM in OWL. Cecil's company is fully based on OWL and RIM based artifacts and they have built the US CDC National Surveillance for Tuberculosis fully in OWL. That system has been in full production across the entire US since April of last year with no downtime and no errors.
- For OWL newbies: see the Pizza example in this tutorial PDF. That little exercise goes through all the aspects of OWL introducing them one at a time. Use an online OWl browser for the Pizza example OR: download the Protege software, and download the pizza.owl ontology tutorial.
- Cecil will also talk about the 'table per class or per hierarchy' discussion, he feels it is the is the wrong approach. You really need to think about relational theory and the cost of joins. I don't think the issue of performance is really debatable with so much literature addressing it from Codd and others. This is partly why triple stores tend to outperform relational equivalents.
- It is based on an OWL ontology of the CDA model so that we can bind terminology to the CDA attributes using the inferencing from OWL. Expressing the v3 RIM in OWL. Cecil's company is fully based on OWL and RIM based artifacts and they have built the US CDC National Surveillance for Tuberculosis fully in OWL. That system has been in full production across the entire US since April of last year with no downtime and no errors.
- Experience at MD Anderson Cancer Center in building a RIM based backend and an application to transformed their "structured documents" from their EMR into CDA and the transform to the backend RIM model.
- Work on the deliverable(s)