# Presentation: 036334

## caGrid Local Metadata caBIG F2FAugust 14, 2005

- Shannon Hastings (_[hastings@bmi.osu.edu](mailto:hastings@bmi.osu.edu)_)
- Scott Oster (_[oster@bmi.osu.edu](mailto:oster@bmi.osu.edu)_)
- Stephen Langella (_[langella@bmi.osu.edu](mailto:langella@bmi.osu.edu)_)
- Tahsin Kurc (_[kurc@bmi.osu.edu](mailto:kurc@bmi.osu.edu)_)
- Joel Saltz (_[saltz@bmi.osu.edu](mailto:saltz@bmi.osu.edu)_)
- Department of Biomedical Informatics
- Ohio State University

## Overview

- caBIG Service Overview
- Data Description Infrastructure
- From caDSR to GME
- Service Metadata
- Metadata Registration

## caBIG Services

- Overview
- caBIG presents an “Object-Oriented” view of data
- Data types are well-defined and registered in a repository
- Defined by XSD and ISO/IEC 11179
- Described by UML, and semantic Ontologies
- Formal harmonization and curation process
- Standardized metadata facilitates discovery
- Technologies
- Built upon Globus Toolkit 3.2.1
- Analytical Services built upon GT3 Core and can leverage analytical development toolkit.
- Data Services leverage OGSA-DAI 5.0
- Service Data registered to Index Services

## Data Description Infrastructure – Service Description

**Cancer Data Standards Repository (caDSR)**
- NCI has a broad initiative to standardize the metadata used for cancer research. These Common Data Elements (CDEs) are developed by various NCI-sponsored organizations, then centrally stored and managed the caDSR
**Enterprise Vocabulary Services (EVS)**
- EVS is set of services and resources that address the need for controlled vocabulary
**Thesaurus**: a biomedical thesaurus
**Metathesaurus**: based on NLM's Unified Medical Language System Metathesaurus supplemented with additional cancer-centric vocabulary
**Global Model Exchange (GME)**
- GME is a DNS-like data definition registry and exchange service that is responsible for storing and linking together data models in the form of XML schema.
**Globus Information Services**
- The Globus Information Services infrastructure provides a generic framework for aggregation of service data, a registry of Grid services, and a dynamic data-generating and indexing node, suitable for use in a hierarchy or federation of services

## Data Description Infrastructure – Overview

- Client and service APIs are object oriented, and operate over well-defined and curated data types
- Objects are defined in UML and converted into ISO/IEC 11179 Administered Components, which are in turn registered in the Cancer Data Standards Repository (caDSR)
- Object definitions draw from vocabulary registered in the Enterprise Vocabulary Services (EVS), and their relationships are thus semantically described
- XML serialization of objects adhere to XML schemas registered in the Global Model Exchange (GME)

##   Global Model Exchange (GME)

- DNS Like Architecture
- Hierarchical authority subordinate domain division
- Model resolution query messaging
- Local cache with TTL

## Global Model Exchange

- Schemas describing data types can be extracted programmatically and used during service composition time and can also be used at runtime for validation
- Extraction Tools:
- Graphical Extraction Tool used for creating analytical service interfaces via data types published in the GME
- Command Line Extraction Tool used for extracting schemas based on namespace and name which can be used and build/run time of the grid service

## UML to caDSR Mapping Review

- UML Class is mapped to an Object Class
- Attribute of a UML Class is mapped to a Property
- Combination of UML Class and Attribute is mapped to Data Element Concept
- Combination of UML Class, Attribute and it’s Datatype is mapped to Data Element (CDE)
- UML Class and it’s attribute are based on EVS concepts
- UML Model/Project is mapped to Classification Scheme
- Packages are mapped to classification scheme items

## From caDSR to GME

- In caDSR, each project (application) will have its own Classification Scheme (e.g. caCORE).  A Classification Scheme may define a subproject, which is represented as a Classification Scheme Item (CSI) (e.g. caBIO).  For this phase of caBIG is seems reasonable to assume that each CSI will have its own schema.
- Each XML schema will be published into the caGrid GME service. As the caDSR ensures semantic interoperability, the GME ensures programmatic data exchange (syntactic) interoperability.

## From caDSR to GME (cont)

- The recommendation for assigning schema namespaces for caBIG objects is shown below:
- For example
- gme://caTIES.caBIG/3.0/edu.upmc.opi.cabig.caties.document.domain

**<Classification Scheme>.<Context>/<Classification Scheme Version>/<Classification Scheme Item>**

## From caDSR to GME (cont)

- Internally, each Object will have an element/complex type defined using its name.  For example, if the caTIES model has an object Document, it would serialize to a document similar to that shown below.
- Although in this phase we will be using a single GME, GMEs can be federated.  Using this namespacing scheme, we would ultimately be able to federate authoritative schema storage on a per Classification Scheme basis (which basically means that each project could have its own GME)

- <Document xmlns=" gme://caTIES.caBIG/3.0/edu.upmc.opi.cabig.caties.document.domain">
- ...
- </Document>

## Standard Service Metadata Review

**Standard Service Metadata Review**

- Service Metadata (SDEs) are standardized as XML schemas stored in GME. (Common, Data Service, and Analytical Service)
- Common Metadata describes generic information about service providing Cancer Center
- Data Service Metadata describes the data exposed using terminology and objects from caDSR/EVS
- Analytical Service Metadata describes the supported operations and their inputs and outputs using terminology and objects from caDSR/EVS

*Common*
*Service*
*Metadata*

*Analytical*
*Service*
*Metadata*

*Data*
*Service*
*Metadata*

## Service Metadata Review