# Presentation: 677191

## Adoption of External Standards in caBIG

- Tahsin Kurc1Ted Liefeld2Patrick McConnell3
- 1Ohio State University2Broad Institute3Duke Comprehensive Cancer Center

## Agenda

- Introduction (Tahsin)
- MAGE (Ted)
- Overview, use cases, CDEs, challenges, solutions, open issues
- mzXML (Patrick)
- Overview, use cases, CDEs, challenges, solutions, open issues
- BioPAX (Tahsin)
- Overview, use cases, CDEs, challenges, solutions, open issues
- Recommendations (Tahsin)

## External Standards Workgroup

- Brian Davis
- Patrick McConnell
- Tahsin Kurc
- Xin Zheng
- Tommie Curtis
- Harold Solbrig

## Introduction

- An overarching goal of caBIG is to enable syntactic and semantic interoperability through community accepted/driven standards
- There are external communities and groups that have developed (are developing) data/information standards
- XML based, OWL based, Object based, Messaging standards (e.g., mzXML, BioPAX, MAGE, DICOM, HL7)
- It is desirable that caBIG leverage external standards
- To build on the previous efforts of standards bodies/groups in representing domain information
- To interface with legacy systems that have been adopted by vendors and other groups
- To enable external groups to leverage caBIG by providing syntactic and semantic interoperability between caBIG and external applications

## Introduction

- caBIG has adopted a set of artifacts to address overarching semantic and syntactic interoperability requirements that include
- UML models, concept annotation, CDEs stored in the caDSR, object-oriented APIs, XML messaging at the Grid level, etc.
- An Architecture/VCDE External Standards Workgroup was formed with the goal to examine
- Whether/how the current set of tools and processes in caBIG could be used to support adoption of community accepted/driven external data standards
- What issues had to be addressed
- What issues remain to be addressed

## Introduction 

- Looked at three different examples
- MAGE – a standard for MicroArray and Gene Expression data. It is a class of standards where both object model and XML DTD exist
- mzXML – a de-facto community standard for mass-spectrometry data. It is a class of standards where XML schema exists
- BioPAX – an evolving standard for representing biological pathway data. It is a class of standards where the standard is expressed using OWL/RDF
- A white paper was drafted
- Present the experience and problems faced in these example cases
- Develop an initial set of guidelines for adoption of external standards

## MAGE overview

- MAGE = Micro Array Gene Expression
- MIAME standard object model
**M**inimal **I**nformation **A**bout a **M**icroarray **E**xperiment
- Describes microarray experiments including
- Array design
- Experiment setup and execution
- Expression data
- Analysis Results
- MAGE-OM – UML Object model of MAGE
- MAGE-ML – XML representation of MAGE

## MAGE caBIG Use Cases

- caArray
- Used as basis for the DB design
- Used to define client/server communication in mage-om-api
- caBIG  clients
- GenePattern, DWD, caWorkbench all use caArray mage-om-api to retrieve data from caArray in MAGE Format
- caGRID Clients in the ICR DAST
- BioConductor, caWorkbench, and GenePattern have agreed to use MAGE for caGRID objects
- Expression data
- Analysis results

## MAGE Challenges

- Many ways to encode anything makes it hard to extract data without user input
- Even within a single repository (ArrayExpress)
- Especially true between repositories
- Extracting derived bioassay data from a full MAGE model required human intervention
- We need to develop use standards for passing data within caGRID to permit automated processing

## MAGE Challenges in caBIG

- MAGE model in VCDE  was initially flawed
- Automated load process missed several subclasses that had no attributes of their own
- MAGE CDE model is being reinstalled by caDSR team
- Due soon, but not available yet
- Reusing the model today isn’t yet possible
- Meetings scheduled between BioConductor, caWorkbench, GenePattern and caDSR to help learn how to reuse it once available

## MAGE Challenges

- Data transfer efficiency
- Microarray datasets can be large (10s-100s of MB)
- MAGE is space inefficient in storing the data
- Lots of XML tags bulks up the data further
- caGRID SOAP Parsers are inefficient in reading the data
- Attempt to load whole MAGE object into memory
- This requires very large memory machines (64 bit)                            to have sufficient memory for large datasets
- caGrid is addressing this: BulkDataTransfer project
- WS-transfer
- Enumeration
- GridFTP (or some other out-of-band transfer mechanism)

## mzXML overview

- mzXML encodes raw mass spectrometry data
- XML Schema created by Institute for Systems Biology (Sashimi)
- Used in many other projects – defacto standard for proteomics
- At least one other alternative: mzData (merging?)
- Raw mz/intensity data encoded in base64 binary
- mzXML also encodes some metadata
- Instrumentation
- Data processing
- Separation technique
- Spot description
- m/z scan values
- MALDI acquisition
- Data integrity

## mzXML raw data example

## mzXML use cases

- Used in the RProteomics project
- Not our native encoding (ScanFeatures, binary files)
- We provide converters: ScanFeatures, CSV, mzXML
- caBIG “standard” for proteomics mass spec data
- Exchange data between services/tools
- RProteomics, Q5, ProtLIMS, caBioconductor, CPAS (coming soon)
- Interface with legacy applications
- Open Proteomics Database
- PeptideAtlas
- The Global Proteome Machine (GPM)
- CPAS
- etc.

## mzXML CDE generation

## mzXML CDEs

## mzXML challenges and solutions

- Middle ground: impedance mismatch
- CDE generation caBIG best practices broken
- Empty classes
- Naming (plurals, atts w/ class name, abbreviations, semantics)
- Cardinality: maxOccurs=unbounded mapped to arrays
- Concordance to standard broken
- Naming: caps, “Type”, “Collection”
- Data types: xs:duration, etc.
- Structure: classes w/ single att, deriving from xs:string, id att
- Data size
- Experiments can generate GBs worth of XML (FTICR)
- Slow to parse, impossible to load into memory
- We implemented a streaming parser (SAX)
- We convert mzXML to binary files (2 per scan – mz/intensity)
- We don’t pass around real data much, we pass around pointers (ids)

## mzXML open issues

- It has not been submitted for consideration as a caBIG standard
- Empty classes
- Associations should be treated with the same “respect” as an attribute
- Data size
- No easy way to transfer the large data
- caGrid is addressing this: BulkDataTransfer project
- WS-transfer
- Enumeration
- GridFTP (or some other out-of-band transfer mechanism)
- caGrid identifiers framework could be leveraged

## BioPAX

- BioPAX (Biological Pathway Exchange) is a community effort to create a standard format for biological pathway data.
- Defined in OWL (Web Ontology Language)
- Several pathway databases and software systems use BioPAX as their data exchange format. These databases include BioCyc, Reactome, BioModels database, Cytoscape, Patika, and PathCase
- OWL is based on the RDF (Resource Definition Framework), which provides a data model for objects and relationships between objects.
- OWL extends RDF by incorporating additional vocabulary to describe classes, properties, relations between classes, cardinality, equality, etc.
- BioPAX does not have an object-model or XML schema.

## BioPAX

- Tools exist to create UML models from OWL
- An example set of steps to convert OWL to UML is provided at _[http://www.biopaxwiki.org/cgi-bin/moin.cgi/Converting_OWL_To_UML](http://www.biopaxwiki.org/cgi-bin/moin.cgi/Converting_OWL_To_UML)_
- The UML model may contain un-directional associations. Two or more associations may contain the same source and target classes
- Manual editing needed to ensure that the role names are different in each association
- Enumerated value domains can be manually added to the model
- Enumerated value domains were a problem in earlier versions of caCORE SDK
- Annotation and registration of enumerated value domains are supported by the Semantic Integration Workbench (SIW) and the UML loader.
- The caCORE SDK code generator cannot generate APIs and object classes from the model
- The class attributes and names may contain hyphens

## BioPAX – the cPATH approach

- This approach stemmed from the fact that an XML schema for the entire BioPAX ontology would require considerable effort
- Harmonize only a selected subset of elements that are likely to be queried
- Add a string type attribute that will hold the BioPAX document
- This is OK as far as the compatibility requirements are concerned
- It may not be an ideal solution: assumes the receiving party can decode the contents of the string attribute

## Recommended BioPAX UML Model

## Lessons Learned and Recommendations

## Lessons Learned

- Overall adoption process can be lengthy
- Some external tools exist, but output from external tools may not be fully compatible with caBIG tools
- Need to manually edit the model to harmonize with existing caBIG object models
- May require considerable effort to generate an XML schema, if the original representation does not have one
- Mismatches between the external standard representation and the caBIG object model
- Should be taken into consideration, especially if data will be exchanged between caBIG compliant systems and legacy systems
*A large mismatch between the external data standard and the caBIG harmonized object model may require implementation of complex transformation tools and services*

## General recommendations

- Two primary approaches
- Adopt/model the entire standard
- Allows for maximal use of the standard in terms of representation of information
- Facilitates better interoperability with legacy systems
- Adopt/model part of the standard
- Model important metadata as fully annotated CDEs
- Model standard as a single CDE (string/binary attribute)
- Easier to carry out adoption process
- Limited to modeled attributes/metadata for querying
- Complexity of translation services

## Primary Options

## Specific recommendations: XML Schema

- Map elements/attributes to CDEs
- Map embedded elements to associations
- Map sequence/choice to associations
- May need to map datatypes
- e.g. duration becomes String
- May need to map element/attribute names
- e.g. GeneType becomes Gene

## Workflow for mapping an XML Schema to an object model 

**Workflow for mapping an XML Schema to an object model**

## Specific recommendations: OWL

- You can attempt to model the entire standard
- There are some tools to help with this
- There will probably be a lot of manual curation of the model before loading
- Alternative (more viable approach) is to model part of the standard
- Model important metadata as CDEs
- Wrap entire OWL document into a single attribute in the model

## Specific recommendations: Object Models

- An existing object model is usually the easiest to bring into caBIG
- Manually curate the model before loading
- Use best practices outlines in the caCORE SDK programmers manual
- Evaluate changes which may impact interoperability with legacy systems

## Tooling/Architecture Recommendations

- One key area of enhancement is in the tooling for conversion of external standards to UML
- At the infrastructure level, enhancements to more natively support translation could be created
- A translation service framework could be developed to support translation between models

## Recommendations/Conclusions

- When adopting a standard, the team should acquire at least a basic understanding of the usefulness of the external standard and its intended use in caBIG
- A critical question in any effort to adopt an external standard is to ask is how the standard is to be used in caBIG
- examine the use cases, which are intended to be addressed by adopting the external standard
- there may be different artifacts and guidelines for each different type of external information standard (e.g., data exchange standard, vocabulary or ontology standard)