1. openMDR: Alternative Methods for Generating Semantically Annotated Grid Services Rakesh Dhaval Shannon Hastings

2. openMDR  ISO/IEC11179 compliant metadata repository  Adaptation of the UK cgMDR project  Agile knowledge management and evolution of knowledge over time  Enables smaller groups easily stand up local metadata registries and curate semantic metadata  openMDR + tools suite ->  Utilizes Light-Weight & Decentralized Data Model registries  New mechanisms for model annotation  Tools for caBIG required semantic metadata generation  Create and stand up semantically annotated grid services  Process for publishing metadata to caDSR

3. openMDR: Design  Makes use of the federated semantic metadata management platform provided by the UK CancerGrid’s cgMDR project, which provides a lightweight ISO 11179 standards compliant metadata repository.  Makes use of tools that enable semantic annotation from its own metadata repository, and can also resolve metadata and terminologies from remote resources  Provides choice to groups for managing semantic metadata and also give them the ability to create caGrid semantically annotated grid services  Provides for user groups that want to create a non authoritative metadata resource during development and do not want to use the NCI caDSR.

4. What are we trying to solve?  Give groups other choices for managing semantic metadata and still give them the ability to create caGrid semantically annotated grid services.  Currently caGrid tools can only use the caDSR, caCore, and SIW etc in order to create semantically annotated grid services.  User groups that don’t want for whatever reason to use the NCI caDSR or want to create a non authoritative or group authoritative metadata resource during development have no options.  Support for CTSA’s, Cooperative Groups, Regional Health Groups, Other domain.

5. Current caBIG Semantics Utilization Limitations  No support for “local” metadata or terminologies/ontologies.  Cannot (or not intended to) stand up a “local” caDSR.  The annotation tools(SIW) and caDSR cant annotate or store a model that is annotated by more that one metadata registry  No support to copy content from NCI caDSR to one’s local instance of caDSR  caGrid tools currently can only create grid data services that use models which have gone through the SIW – so NCI source of metadata approach is the ONLY current path.

6. Current NCI WorkFlow

7. Current caBIG Semantics Utilization Limitations  No support for “local” metadata or terminologies/ontologies.  Cannot (or not intended to) stand up a “local” caDSR.  The annotation tools(SIW) and caDSR cant annotate or store a model that is annotated by more that one metadata registry  No support to copy content from NCI caDSR to one’s local instance of caDSR  caGrid tools currently can only create grid data services that use models which have gone through the SIW – so NCI source of metadata approach is the ONLY current path.

8. Proposed WorkFlow  Federated semantic metadata management utilizing and enhancing UK CancerGrid cgMDR and adding components to fill the gaps to provide another possible workflow for creating cagrid services that can leverage this alternative process.

9. Where are We going with this?  Enable another path for creating semantically annotated grid services.

10. openMDR: Components

11. openMDR:mdrEAPlugin  A set of tools that can be used in commercial modeling tool such as Enterprise Architect, to enable the semantic annotation of federated semantics »Utilizes the MDRQuery service for locating and utilizing common data elements (CDE’s) from many semantic metadata sources for annotation of classes and attributes of the logical model »Tags are created that identify the service and CDE via local unique id to enable more information to be retrieved by a consumer of the model if desired »No need to leave the EA environment

12. openMDR:mdrCORE  Utilizing/enhancing the cancergrid cgMDR ISO11179 database.  Built on the eXist XML database.  Capable of storing, versioning, and maintaining semantic and representational metadata. »Metadata is annotated with conceptual information from a local or remote lexEVS system. »Web based front-end for creating and curating semantic metadata.

13. openMDR:mdrQuery  API and Grid Service for querying across many disparate semantic metadata repositories and using the information for data model annotation »caGrid grid service - capable of talking to caDSR, many lexEVS and many openMDR systems enabling federated query of common data elements and concepts. »Enhances and wraps the cgMDR mdrConnector in order to parse the received information into a common format. »caGrid service enables it to be deployed in any local or production grid environment and can be configured and modified to talk to many semantic metadata systems.

14. openMDR:mdrEAPlugin

15. openMDR:mdrEAPlugin

16. openMDR:mdrEAPlugin

17. openMDR:mdrDomainModelGenerator  A tool that can process an MDR Plugin annotated model and create service metadata which will enable the service to be a semantically annotated grid service which can be easily discovered »The metadata can be used to generate a data service using the Introduce Data Service Wizard which prior to this tool would only be able to utilize the caDSR, can now generate data services annotated with data models from almost anywhere.

18. The New Service Creation Workflow ① Draw logical model in EA. ② Annotate logical model in EA utilizing openMDR EA plug-in. ③ Export annotated XMI and ① Run through caCore SDK if you want to build a data service or have schema generated. ② Run through Domain Model Generator to generate grid service metadata for exposing the semantic annotations for the logical model being used. ④ Generate service with Introduce.

19. What have we done so far?  Refactor of cgMDR source to enable the following capabilities.  Pulled code out of exist source tree so that openMDR is not tied specifically to any version of eXist.  Broke project up into 3 sub projects and added a 4th.  mdrCore (iso 11179 database and web frontend to curate and browse)  mdrQuery (refactored mdrConnector in cgMDR with a caGrid grid service which provides this query functionality  mdrTools (currently an EA plugin which uses mdrQuery to provide model annotation.  mdrDomainModelGenerator (consumes XMI generated by openMDR EA plugin and generates a Domain Model file required for caGrid to create the grid data service.  Ivy based project build system consistent with caGrid project build and development processes.  Code in caGrid incubator project in the ESN.

20.  caCORE SDK requires UML logical (object) model and a corresponding data (table) model as input in the form of a XMI file + UML tags, dependencies, etc.  Process - tedious, time consuming, and unnecessary for new systems  XMI Mapper - generates a data model and all necessary data logical mappings required by caCORE SDK  Process:  Create an logical (model) in Enterprise Architect  Export the model as XMI  Run the XMI through the data model generator tool to generate a complete caCORE model  Run the complete model through the caCORE SDK Additional Tool: XMI Mapper

21.  This is a work in progress but we have a real community that is looking for a solution.  Getting ready for our Beta release.  The evolving wiki site can be found here: https://cagrid.org/display/MDR/Overview  Current Focus/Wishlist  Store/Retrieve/Export Models  User Management  Versioning of Objects stored  Export to caDSR for creating CDE’s and storing Models Where Are We Going With This?

22. Questions?