New Account Helpful Tips
  CORE - caDSR
  Common Meta Data Registries Iteration 1 Scope
 Browse Space
Added by Denis Avdic, last edited by CHARLES GRIFFIN on Sep 24, 2008  (view change)

Labels

 
Contents
Author:  Denis Avdic
Email:
avdicd@mail.nih.gov
Team:
MDR
Contract:
27XS083
Client:
National Cancer Institute Center for Bioinformatics
National Institutes of Heath
US Department of Health and Human Services

Purpose and Focus of Document

The purpose of this document is to collect, analyze, and define high-level needs and features of the Metadata Registries Exchange architecture. This document focuses on the investigation into functionality required by the product stakeholders and target users in order to create an effective collaboration and exchange tool.

Vision and Dependencies

Vision Statement

The goal of first iteration is to identify requirements/use cases for a metadata registry interface layer using the operations of JAXR as a starting point. After analysis, a decision will be made regarding whether to use JAXR specification in the interface layer or build a custom solution if no other standards based options are available.

Stakeholder, Technical and User Descriptions

Stakeholder Summary

Customer Name
Role
Interest/Need
Denise Warzel
NCI CBIIIT Core Product Line Manager/ MDR Product Manager  
Dave Hau
Associate Director of Core Infrastructure Engineering  
NCICB Staff/Contractor Name
Role
Responsibilities
Charles Griffin
Project Manager
 
Denis Avdic
Technical Architect
 

Technical Environment

This product uses the following technical components which have been derived from the current NCICB Technology Stack.

  • Client Interface
    • Mozilla v. 2.0.0.1 and above
    • IE Browser 7.0
  • Application Server
    • Jboss 4.0.5
  • Database Server
    • Oracle 10g 
  • Operating System (Warehouse APIs)
    • Linux
    • Windows 32 bit

Current Solution to Meeting Needs

Currently there are no common interfaces defined among metadata registries. Each registry can be queried and utilized only by the tools written specifically for it, based on the custom interface available. Likewise, the only way to exchange data between registries is to export all data in bulk from a particular registry, transform it and then import to the target registry.

Proposed Solutions to Meeting Needs

The first order of business would be to convert the JAXR APIs into a set of discrete use cases describing the lifecycle and query operations. As JAXR is a thoroughly vetted Java specification, it presents us a good starting point to create a set of use cases to fuel our continuing investigation and design.

Next, consulting the cancerGrid UK and the caGrid teams, we propose to identify common use cases among all registries. This would cover all query and lifecycle management actions necessary to register data and retrieve existing registration information. 

Following would be an investigation of federated query interchange among registries will be made, using the ISO 11179 standard as the starting point. A successful identification of all use cases and determining the business processes governing sharing of data between registries would enable closer cooperation between registries and greater harmonization across domains.

Finally, based on all identified use cases and consultation with the stakeholders, the cancerGrid team and the caGrid team a decision will be made whether the JAXR implementation describes a complete set, a partial set, or an inadequate set of interfaces necessary for registry operation and inter-registry exchange.  This decision will guide the future development of metadata registries.

Product Dependencies

This release is dependent on the JAXR specification and implementation.  Additional influences come from the existing use cases governing submission and registration of metadata to both the caDSR and the cancerGrid produced caDSR 'Lite'.

Summary of Key Stakeholder or User Needs

The following subsections provide a description of key requirements to address the solution as perceived by the stakeholders and users.

Stakeholder and User Requirements

Functional Requirements

None

Non-Functional Requirements

  • Identify lifecycle and query operations specified by JAXR.
  • Identify and validate exchange use cases with cancerGrid UK team.
  • Determine intersection between JAXR operations and exchange use cases.
  • Identify common lifecycle and query operations.
  • Research the 'federated query' model.

In-Scope Requirements and Enhancements

In-Scope Functional Requirements (Enhancements or New Features)

Each new enhancement, modification or new feature is described in detail below.

(Proposed)

None

In-Scope Functional Bug Fixes

None

In-Scope Non-Functional Requirements

This section describes in detail all the non-software related requirements which must be met for this release but do not add functionality. These requirements are included in the scope and project plan due to level of effort or relative importance to the overall success of delivery of the release.

(Proposed)

Identify lifecycle and query operations specified by JAXR.

Examine the APIs specified by JAXR and formalize them in use cases.

Identify and validate exchange use cases with cancerGrid UK team.

Through cooperation with the cancerGrid UK team, determine how registry-to-registry data exchange should proceed.

Determine intersection between JAXR operations and exchange use cases.

Create a map between the JAXR use cases and exchange use cases established in the previous requirements.

Identify common lifecycle and query operations.

In cooperation with the cancerGrid UK and caGrid teams determine which of the use cases established, as described in previous requirements, are necessary for registry operations.

Research the 'federated query' model.

Federated queries entail searching other 11179 registries through grid services to find items and use them from where they are.  For example, a CDE registered in caDSR might be comprised of an object class registered in caDSR and a VD registered in UK MDR, without having a copy of the VD in caDSR.

In-Scope General Support Activities

None

Out of Scope Requirements and Enhancements

Out of Scope Functional Requirements (Enhancements or New Features)

Items that are out of scope were evaluated as part of the initial scoping activities for this release, and subsequently not included in the final approved scope. These items are also documented in the cumulative backlog of requirements found on the product GForge site.

None

Out of Scope Functional Bug Fixes if Applicable

None

Out of Scope Non-Functional Requirements

None

Out of Scope General Support Activities

None

Document History and Project Information

Document Version:
Click the Info tab. View the Recent Changes or click the link to view the page history.
Last Modified:
Refer to the first line displayed in the document window.
Project GForge site:
[caCORE:Project GForge site link]
Most current version:
Unless the display includes a notice that you are viewing a previous version, you are viewing the most current version of this Scope Document for the release indicated in the title.
Revision history:
Click the Info tab. In the Recent Changes area, click the link to view the page history.
Review history:
Click the Info tab. In the Recent Changes area, note the developer who made each change and the date and time. Refer to the Key People Directory for their roles. Click the link to view any page or to view the page history, and then click the link for a page. When the page opens, view the comments and changes made in that version.
Related documents:
[caCORE:Name and URL of each related document]
NCICB Management
Role Responsibilities
Denise Warzel
caDSR Product Manager and caCORE Product Line Manager Oversees development of the product: features, functions, definition of stakeholders, priorities within the scope, timeframe for release
Dave Hau
caDSR Engineering Manager
Oversees caDSR software engineering practices, conducts design reviews, guides technical development of the product

Comments  (Hide Comments)

At the 30k foot level, I think sometihng missing is an adopter project for federated metadata registries, one that needs to discover the registry within an application wtih a UI, and then be able to select and use content from any 11179 registries it finds.  Possible choices are of courese our own curation tools, but a better choice would be a rea caBIG application, perhpas on ethat is attempting to allow the apps end users to create new data elements, such as caTissue or caIntegrator might be good candidates...but essentially, we need that extra leg in this project to ensure that it will meet customer needs.  Afterall, cancerGrid caDSR-lite isn't really teh end users, its a collaborator, another registry or provider of services.  Make sense?

Posted by Denise Warzel at Jun 09, 2008 18:29

You are absolutely correct. We will work on identifying the likeliest candidate out of existing caBIG applications who will benefit the most by an improved metadata registry and bring them into the conversation.

Posted by Denis Avdic at Jun 10, 2008 09:47

I also agree with getting an initial adopter, it will definitely help shape the use cases and eventually build something usable out of the box.   I think we should identify some initial use cases that we can present to potential adopters to get feedback in lieu of coming to them with an open slate.   One suggestion is that we do a short Elaboration iteration focused on building these initial use cases with input from the caGrid and UK Cancer Grid folks and then quickly do another Elaboration iteration in which we present these use cases to potential adopters to get feedback/new requirements and use cases.  What do you think?

Posted by CHARLES GRIFFIN at Jun 10, 2008 10:42

Following up on Denise's point, I agree it would be good to differentiate between registry clients and registry providers.  Curation Tool, caTissue and caIntegrator would be using the "client" piece of the registry API (e.g. JAXR client).  caDSR and UK Cancer Grid would be using the "provider" piece of the registry API (e.g. JAXR provider, which is potentially just a facade around the existing registry interface of each registry).  From a requirements perspective, it may also be helpful to differentiate between client requirements (what functionalities do Curation Tool, caTissue and caIntegrator need to perform on multiple registries; what's the best way we can abstract these out so the client can be agnostic as to whether it's accessing a single registry or multiple registries), and provider requirements (what functionalities would caDSR and UK Cancer Grid like to expose to registry clients).

Posted by David Hau at Jun 10, 2008 13:31

Right, I agree, creating client side and server side requirements is the way to go.  Denis and I can document the Jax-R use cases as a starting point (server and client side).   We can then add/modify/delete them during a review.  We can then use them meet with the other stake holders for another round of review and modifications to the use cases.  Denise, how did you want to go about choosing the caBIG key stakeholders for the client perspective?

Posted by CHARLES GRIFFIN at Jun 11, 2008 14:36

Our current scope states the following:

"The goal of first iteration is to identify requirements/use cases for a metadata registry interface layer using the operations of JAXR as a starting point. After analysis, a decision will be made regarding whether to use JAXR specification in the interface layer or build a custom solution if no other standards based options are available."

However, based on a number of conversations after the scope was approved, it seems that there is an expansion to the scope for the current iteration.

In addition to the metadata registry interface layer, there is a parallel task for developing a generic registry interface/service definition in cooperation with COPPA and other stakeholders such as Terminology services and caGrid. This would allow for creating a unified registry service signature which could be used by any registry serving a particular repository (metadata, patient, organization).

This is my current understanding of the expansion of the scope.

Please use the comment system to respond with corrections/additions and I'll update the scope document to reflect the additional tasks.

Posted by Denis Avdic at Jul 17, 2008 16:04

Hi,

If by 'expansion' you mean in terms of the incusion of additional stakeholder use cases for analysis, yes that is true, we added COPPA.  But strategically, we need to be aligned with domain projects, this is a fundamental adjustment to CORE product managemetn strategy that will hold for all projects going forward.  if by expanded scope you mean somethign else, please clarify.

To my way of thinking, "use cases for a metadata registry interface layer" and "generic registry interface defintion" are exactly the same ... for COPPA Person and Organization registries, Terminology Registries, Service and XML Schema registries - all are metadata registries.  But, we need to ensure we have looked adequately at a broader set of requirements before designing a solution, and that teams undergoing similar efforts are harmonized and workign on the same thigns instead of independently doing similar things but maybe slightely differently.  this starts to put our thought aournd sMDRs into the mainstream to get feedback on from our peers in app develoment.  which, again, to my way of thinking, should make analyzing the problem space easier to see patterns/requiremetns emerge - as contrasted to  looking at only a few very technical types of metadata registries. 

Let me know if this helps.

Posted by Denise Warzel at Jul 17, 2008 16:25

CONTACT US PRIVACY NOTICE DISCLAIMER ACCESSIBILITY APPLICATION SUPPORT
National Cancer Institute Department of Health and Human Services National Institutes of Health USA.gov