**Integrative Cancer Research (ICR) Face-to-Face Meeting #4**

Natcher Center, Bethesda, Maryland

September 17--18, 2007

**Table of Contents**

[Executive Summary 2](#executive-summary)

[Dr. Ken Buetow---Opening Remarks 3](#dr.-ken-buetowopening-remarks)

[Mouse Models of Human Cancer Consortium (MMHCC)
3](#mouse-models-of-human-cancer-consortium-mmhcc)

[Biomarkers to Translation: Bioinformatics as the Currency of
Research---Inter-SPORE Prostate Biomarkers Study
4](#biomarkers-to-translation-bioinformatics-as-the-currency-of-researchinter-spore-prostate-biomarkers-study)

[Role of Bioinformatics in Translational Research
5](#role-of-bioinformatics-in-translational-research)

[Integrative Cancer Biology Program (ICBP)
5](#integrative-cancer-biology-program-icbp)

[Cancer Genetic Markers of Susceptibility (CGEMS)
6](#cancer-genetic-markers-of-susceptibility-cgems)

[Tools for Genomics Projects in Office of Cancer Genomics (OCG)
6](#tools-for-genomics-projects-in-office-of-cancer-genomics-ocg)

[Tumor Microenvironment Network (TMEN)
7](#tumor-microenvironment-network-tmen)

[caBIG Tools for Translational Research
7](#cabig-tools-for-translational-research)

[Empowering Translational Research
8](#empowering-translational-research)

[caTissue Suite and ca-Bench-to-Bedside (caB2B)
8](#catissue-suite-and-ca-bench-to-bedside-cab2b)

[NCI Proteomics Repository: NCI CPAS
9](#nci-proteomics-repository-nci-cpas)

[Open Discussion 9](#open-discussion)

[The Jackson Laboratory EY1 Adopter Project
11](#the-jackson-laboratory-ey1-adopter-project)

[Columbia University EY1 Adopter Project
12](#columbia-university-ey1-adopter-project)

[Washington University EY1 Adopter Project
12](#washington-university-ey1-adopter-project)

[Network Inference and Analysis Using SEBINI-CABIN
12](#network-inference-and-analysis-using-sebini-cabin)

[Washington University Workflows 13](#washington-university-workflows)

[University of Pittsburgh Medical Center Use Cases
14](#university-of-pittsburgh-medical-center-use-cases)

[ICR Workflow Working Group 17](#icr-workflow-working-group)

[Working Group Activities 17](#working-group-activities)

[Implementation Considerations 18](#implementation-considerations)

[Panel Discussion on Use Cases for Workflow Tools
19](#panel-discussion-on-use-cases-for-workflow-tools)

[Exercise---Collecting Use Cases and Specific Requirements with "Voting"
for prioritization
22](#exercisecollecting-use-cases-and-specific-requirements-with-voting-for-prioritization)

[ICR Bulk Data Transfer---High Throughput Data WG
24](#icr-bulk-data-transferhigh-throughput-data-wg)

[ICR Analytical Services Best Practices WG
26](#icr-analytical-services-best-practices-wg)

[Compatibility Guidelines v3.0 WG 29](#compatibility-guidelines-v3.0-wg)

**Integrative Cancer Research (ICR) Face-to-Face Meeting #4**

Natcher Center, Bethesda, Maryland

September 17--18, 2007

# Executive Summary

Day One focused on information exchange between the Cancer Biomedical
Informatics Grid (caBIG™) ICR Workspace (WS) and various National Cancer
Institute (NCI) programs. An ongoing intention is to identify high-value
touch points between ICR and NCI bioinformatics initiatives that provide
opportunities to mutually leverage resources toward translational
medicine objectives. The desired outcome is ongoing communication and
strategic assessment of collaborative opportunities.

Sessions included---

-   Reports and discussion related to particular NCI bioinformatics
    programs.

-   Facilitated discussion on translational research resources; topics
    of particular interest included data sharing and annotations.

-   Reports and discussion related to ICR Enterprise Adoption programs,
    including the resources used, and the scientific and/or clinical
    value of the data that will be exposed and shared.

Day Two consisted of working meetings covering technical topics that
affect the ICR WS and caBIG™ as a whole. During the Enterprise Year 1
(EY1) program year, three ICR Working Groups are addressing these
issues.

The goal of the ICR Workflow WG is to implement one or more caBIG™
workflows that fulfill the requirements of a given user community. The
Workflow Sessions consisted of---

-   Presentations of institutional use cases, including core labs and
    clinical research environments

-   Presentation of ICR WG findings on authoring tools

-   Presentation on grid implementation considerations

-   Facilitated discussion on anticipated workflow needs and desired
    features of authoring tools.

Based on information gathered at the Workflow sessions, the ICR WG
will---

-   Work with the grid team to implement tools and workflows that
    fulfill end-user feature requirements

-   Maintain evaluation of use cases and targeted user bases

-   Identify, vet, and recommend appropriate authoring tools.

The goal of the ICR High-Throughput (HTP) Data WG is to identify
mechanisms for efficient, use-case dependent data transfer. The HTP Data
Session discussion focused on test cases for gridFTP and End Point
Reference methodologies. Outcomes were recommendations for test cases
and benchmarking.

The goal of the ICR Analytical Services Best Practices (ASBP) WG is to
reduce the time and cost of deploying an analytical service on the grid;
this includes optimizing development practices and resolving breaking
issues that may be identified in the course of this activity.

The ASBP WG presented results and recommendations related to parameter
reuse, model reuse, and the role of caBIG™ development tools (e.g.,
caCORE, Introduce, Loader) in the Analytical Service development
process. Outcomes were recommendations for modified processes and
relevant test cases.

# Dr. Ken Buetow---Opening Remarks

The mission of caBIG™ is to create a "virtual web" of interconnected
data, individuals, and organizations that will redefine how cancer
research is conducted, patient care is provided, and individuals outside
the traditional research community interact with the biomedical research
enterprise.

The components of caBIG™ include information technology (IT) components
for creating the grid infrastructure itself: interoperable databases and
software tools for working with research data such as that derived from
microarray experiments; and supporting infrastructure, services, and
developer toolkits such as the caCORE Software Development Kit (SDK).
The vision for the caBIG™ grid also includes the ability interact with
other grids such as the National Heart, Lung, and Blood Institute
(NHLBI) grid (CardioVascular Research Grid \[CVRG\]).

A current activity for the program focuses on packaging selected caBIG™
tools into "Product Suites" consisting of bundles of the more mature
tools. These include suites for clinical trials management, basic life
sciences research, and security and data sharing. Activities also
include developing a support infrastructure for potential user
institutions that include knowledge centers, program offices, licensed
support contractors, and the enterprise adopter program.

The ICR workspace has played a key role in the program's efforts to
develop products that address real-world issues faced by the basic and
clinical research community. The charge to the ICR is to continue
building out the tool suite needed by the NCI community by inventorying
NCI assets; determining opportunities for improved or new tools; and
developing strategies for deploying caBIG™ resources and determining
new, high-priority efforts.

Presentation:
<https://gforge.nci.nih.gov/frs/download.php/2400/ICR-2007_KB.PPT>

# Mouse Models of Human Cancer Consortium (MMHCC)

Cheryl Marks

The immediate program goal is to develop a plan to integrate mouse
genomics and genetic resources into caBIG™. Over the longer term, the
goal is to develop informatics support for systems genetics.

Representative research projects include integrating 1) pre-clinical
testing of therapeutic agents and imaging modalities across
institutions, 2) cross-species approaches to systems genetics
(human/rodent initially), and 3) discovery of human and mouse biomarkers
for early detection, response to therapy, recurrence, and metastasis.

The projects capture a wide array of data ranging from molecular (e.g.,
microarray-based gene expression profiling, magnetic resonance imaging
\[MRI\]) to animal care conditions (e.g., diet). Data analysis usage
includes tasks such as those typically applied to microarray-based
assays, along with network analyses of expression arrays and
protein-protein interactions maps. Key data integration activities
include expression and comparative genomic hybridization (CGH)
comparisons comparable to those performed for humans, along with the
effects of experimental therapies and early interventions on the
outcomes of human trials.

Other challenges affecting the program that also influence IT needs
include intellectual property issues, such as the use of proprietary
agents, and "cultural" issues, such as different vocabularies and
concepts among basic, clinical, and epidemiological researchers.

Possible collaborations with caBIG™ include developing 1) a pre-clinical
testing informatics infrastructure, 2) tools to compare experimental
therapeutic outcomes with clinical and prevention trials, and 3) an
integrated systems genetics infrastructure enabling population
scientists and epidemiologists to share discoveries with model organism
geneticists.

Presentation:
<https://gforge.nci.nih.gov/frs/download.php/2402/Marks-Xlational_presentation_collaborator_template.PPT>

# Biomarkers to Translation: Bioinformatics as the Currency of Research---Inter-SPORE Prostate Biomarkers Study

Bruce Trock

A basic observation is that despite extensive, published literature on
biomarkers and prostate cancer, there is currently only one marker that
is routinely used in clinical practice (Prostate Specific Antigen
\[PSA\]). A general goal of the project is to address known or assumed
reasons for this and as appropriate, develop IT systems to address the
goal.

A specific research goal is to develop a pilot study using a
well-annotated, scalable, virtual tissue/data repository to support
future discovery efforts. The study is currently envisioned as enrolling
at least 700 individuals with prostate cancer from 11 institutions,
obtaining biospecimens from each using rigorous collection and storage
protocols, employing/developing a system for collecting annotations on
the samples and tracking distribution, tracking the progress of the
patients over time, and then analyzing samples from subsets of patients
based on response for putative biomarkers. The IT system should be able
to facilitate the interpretation of the data from the assays to be used
for biomarker elucidation.

In addition to the IT infrastructure and tools that would be needed,
there are also data sharing and intellectual property issues given that
the study's design employs "usual care" and is not a clinical trial. The
primary issue is to develop the appropriate consent protocol. An
additional issue is the agreement across centers on the types of
information needed for annotation with corresponding common data
elements identified and agreed upon.

Over the longer term, caBIG™ tools have been identified that have
functionality that matches that needed for the project. These include
caTissue, cancer Text Information Extraction System (caTIES),
caIntegrator, caArray, Distance-Weighted Discrimination (DWD), and
caBIG™ Function Express (caFE). Future development of these (or other
systems) might include more extensive data models to handle additional
data/information types and a better understanding of the types of extra
data/information needed for informative publications.

Presentation:
<https://gforge.nci.nih.gov/frs/download.php/2403/Trock.ppt>

# Role of Bioinformatics in Translational Research

Jorge Gomez

Translational trials differ from tradition, clinical trials. The latter
are meant to provide reliable evidence regarding a clinical outcome
while the former provide more mechanistic insights for answering why (or
why not) a defined end-point was reached. The population-level design of
translational trials is also capable of elucidating responders or
non-responders. No matter what the outcome in response, typically,
information for subsequent studies or basic research is gained.

Translational studies recognize variability among individuals and
tumors. They also have at least three confounders including: 1) the
correctness of the disease/treatment model employed, 2) the validity of
the target/biomarker selected, and 3) the effect of the therapy. The I
SPY TRIAL is an example of the design of a translational study and the
types of data and information obtained and used.

Bioinformatics provides tools for reengineering the process of
conducting translational trials. In the context of caBIG™, this includes
integrating data across multiple assay platforms, tracking specimens to
results, and monitoring the quality of samples and assays. In addition,
bioinformatics allows all investigators access to all data and
information along with a common set of tools such as caArray for
analyses.

Presentation:
<https://gforge.nci.nih.gov/frs/download.php/2404/Jorge_Gomez.ppt>

# Integrative Cancer Biology Program (ICBP)

Jennifer Couch (NCI) & Brian Joughin (MIT)

The Integrative Cancer Biology Program (ICBP) is an NCI-supported
consortium designed to develop a systems approach to cancer biology and
treatment. It is built on three conceptual pillars---biology, modeling,
and education.

The MIT group is applying this approach to the regulatory networks
involved in cancer initiation and progression with three subprojects
modeling mitogenesis, DNA repair, and cellular migration.

The mitogenesis project attempts to model mitogenesis from extracellular
clues to intracellular signals to cellular responses. The project
employs two classes of modeling: mechanistic (e.g., ordinary
differential equations) and descriptive/correlative (e.g., Principal
Component Analysis \[PCA\]/Partial Least-Squares Regression \[PLSR\]
dimensionality reduction). The intent it to validate/develop the models
using a variety of data types derived from a variety of assay systems
(e.g., FACS, genomic microarrays). The project currently uses the MATLAB
Workflow Environment along with a semantic mediawiki for cross-project
integration.

The needs of the project include those associated with model sharing
(e.g., not all investigators use the same modeling environment), model
documentation (e.g., assumptions that were used to develop a model), and
model/model and model/data integration (e.g., expanding models along
different axes).

Presentation:
<https://gforge.nci.nih.gov/frs/download.php/2405/ICBP.ICR.F2F.PPT>

# Cancer Genetic Markers of Susceptibility (CGEMS)

Stephen Chanock & Kevin Jacobs

The Cancer Genetic Markers of Susceptibility (CGEMS) is an NCI program
with the goals of discovering and characterizing markers for prevention,
early intervention, and potential drug targets. The first two diseases
under study are prostate and breast cancer. The underlying trial
component of the project is based on a case-control design using a
number of ongoing studies such as the Prostate Lung, Colorectal, and
Ovarian (PLCO) Cancer Screening Trial and the Nurses' Health Study.

The strategy at the molecular level was to identify putative loci and
alleles altering susceptibility through a three-step process ultimately
leading to the mapping of 10 to 50 loci.

The IT component of the project includes a data portal for publishing
results and data and an analytical tool (Graphics Language Utility
\[GLU\]) for managing single nucleotide polymorphism (SNP) data sets and
identifying associations between SNP markers and quantitative or
qualitative phenotypes. Both the data through the portal and GLU tool
are publicly available.

The current needs of the portal include 1) covering new disease types
(e.g., pancreatic cancer) and correspondingly enhanced user experience;
2) data visualization functionality typically associated with
genotyping; and 3) dynamic, user-driven model building.

Presentation:
<https://gforge.nci.nih.gov/frs/download.php/2406/CGEMS_caBIG_presentation.ppt>

# Tools for Genomics Projects in Office of Cancer Genomics (OCG)

Daniela Gerhard

The Cancer Genome Atlas (TCGA)

The Cancer Genome Atlas (TCGA) is a joint project of the NCI and the
National Human Genome Research Institute (NHGRI). The current objective
is to test the feasibility of a systemic approach to identifying genetic
alterations in cancer and making the data available to the research
community. The program also employs the existing sequencing
infrastructure of NHGRI for the resequencing of candidate alleles
identified in the initial analyses.

The current pilot employs three tumor types (glioblastoma multifore,
squamout cell lung carcinoma, and cystadenocarcinoma of the ovary). The
pilot also identifies and evaluates patient matched controls.

Data capture from participating laboratories and subsequent processing
is coordinated through Data Coordinating Centers. The data and
information is then made publicly available through the portal with a
security protocol where access must be requested and approved. Biology
drives the analyses with a defined set of priorities and the system
allows the integration of the data with other biological information,
including clinical response(s) and the identification of new pathways.

The OCG also has the program Therapeutically Applicable Research
Generating Effective Treatments (TARGET). The program is aimed at
improving treatment of pediatric cancers. The key to the project is
integrating genomic and transcriptomic data with disease expertise. As
with CGEMS, NCICB is a partner is the project.

Presentation:
<https://gforge.nci.nih.gov/frs/download.php/2408/Xlationa_caBIG_TCGA_DSG.PPT>

# Tumor Microenvironment Network (TMEN)

Suresh Mohla & Sumanta Goswami

The Tumor Microenvironment Network (TMEN) is a collaborative effort
among interdisciplinary research programs. The purpose of the network is
to delineate mechanisms of host-tumor interactions with a focus on
understanding the role of stroma in the neoplastic process. Individual
research projects typically are mechanistic studies into the biology of
tumor-microenvironment interactions using human cancer tissues or animal
models. Specific areas also include characterizing the role inflammatory
and immune cells play in the pathogenesis of cancer and identifying
tumor and normal stromal stem cells.

Informatics needs include tracking and sharing information about common
reagents, cell lines, animals, protocols, and similar research oriented
materials. Bioinformatics needs include managing diverse data types
(e.g., images), the storage and analysis of large scale data sets, and
modeling and simulations of host-tumor interactions.

Presentation:
<https://gforge.nci.nih.gov/frs/download.php/2409/TMEN_Slides_caBIG_091707_Final.PPT>

# caBIG Tools for Translational Research

Juli Klemm

The primary mission of the ICR is to---

-   Develop and integrate tools to store, link, and analyze diverse data
    resources in order to enable translational and integrative research

-   Engage and grow an adopter community that implements these solutions

-   Foster a collaborative culture to collect, integrate, share, and
    consume data.

ICR also supports the bench-to-bedside continuum for improved diagnostic
and prognostic tools and therapies. As noted by Dr. Buetow, the future
of the ICR WS is to provide a third dimension integrating solutions for
research and medicine.

The challenges for the ICR WS are---

-   The technologies for understanding the molecular bases of cancer are
    diverse.

-   The technologies are constantly evolving.

-   The data must be integrated and analyzed with associated clinical
    and pathological annotations.

-   Analysis and presentation needs vary from study to study.

The current collection of ICR-related tools include---

-   caArray

-   geWorkbench

-   caTRIP

-   caMOD

-   Many more noted on the caBIG tools page.

Presentation:
[[https://gforge.nci.nih.gov/frs/download.php/2410/Tools_overview_Juli.ppt]{.underline}](https://gforge.nci.nih.gov/frs/download.php/2410/Tools_overview_Juli.ppt)

# Empowering Translational Research

Subha Madhavan

Four themes that have emerged relevant to the IT needs of translational
research include 1) the deluge of data, 2) data representation, 3) data
integration and analysis, and 4) patient privacy and human subject
research.

In terms of the data deluge, The Cancer Genome Atlas (TCGA) project is
typical. To address the volume of data, the project employs both
specific tools and defined processes.

In terms of data representation, a current model that is both "simple"
and appropriate for downstream uses for the TCGA project is MicroArray
Gene Expression Tabular (MAGE-TAB). Other models that would allow making
data available through caBIG™ application programming interfaces (API)
include the Biospecimen Core Resource (BCR) and Clinical Genomics Object
Models.

In terms of data integration and analysis, caIntegrator has been
successfully employed for a variety of projects with a variety of
modifications (e.g., CGEMS).

In terms of patient privacy, TCGA balances the importance of sharing
clinical data and requirements to protect individuals donating tissue
and data. The approach employs well-defined processes and policies and
associated IT solutions.

Presentation:
[[https://gforge.nci.nih.gov/frs/download.php/2411/Tools_for_translational_research_Subha_v3.ppt]{.underline}](https://gforge.nci.nih.gov/frs/download.php/2411/Tools_for_translational_research_Subha_v3.ppt)

# caTissue Suite and ca-Bench-to-Bedside (caB2B)

Rakesh Nagarajan

Clinical and translational research suggests an iterative process
starting with hypothesis generation leading to the identification of
putative new targets for rationally designed therapies that then become
a new hypothesis for testing. From an IT/bioinformatics perspective, the
process needs tools for data integration, analysis, and visualization.

The types of data that are envisioned range from clinical information
(inpatient or outpatient originating from clinical trials or routine
treatment) to genomics. caBIG™ includes a collection of tools covering
these data types and associated analyses.

caB2B is designed to integrate data analysis and visualization. The
goals are to 1) develop a grid client that leverages grid services, 2)
allow searches for biospecimens and associated microarray data sets, 3)
co-analyze microarray data set and clinicopathological information, 4)
capture steps using a caGrid workflow engine, and 5) examine the results
with a rich set of visualization tools. Future versions are envisioned
to contain functionality for other data source and experimental
modalities.

Presentation:
[[https://gforge.nci.nih.gov/frs/download.php/2412/ICR_F2F_Sept_2007_Day1_Nagarajan.ppt]{.underline}](https://gforge.nci.nih.gov/frs/download.php/2412/ICR_F2F_Sept_2007_Day1_Nagarajan.ppt)

# NCI Proteomics Repository: NCI CPAS

Liming Yang

The Mouse Proteomic Technology Initiative aims at developing and
standardizing technologies for identifying proteins and peptides in
complex mixtures, providing reference sets, and distributing data
through caBIG™. The Center for Biomedical Informatics and Information
Technology (CBIIT) uses the Computational Portal Analysis System (CPAS)
that was developed at the Fred Hutchinson Cancer Research Center and the
peptide sequence database (MS2).

Enhancements to the NCI CPAS include 1) caBIG compatibility, 2) improved
querying capabilities (including a BioMart interface), and 3) an
experiment annotation and loading tool.

Future plans include continuing to work with the NCI clinical proteomics
initiative, bringing more CPAS objects to the caBIG API, and improving
data analysis capabilities.

Presentation:
[[https://gforge.nci.nih.gov/frs/download.php/2413/Proteomics_for_ICR.ppt]{.underline}](https://gforge.nci.nih.gov/frs/download.php/2413/Proteomics_for_ICR.ppt)

# Open Discussion

Moderator: Juli Klemm

These sessions included presentations on caBIG™ translational tools,
followed by a facilitated discussion; the latter was focused on
identifying desired features of caBIG™ tooling, and strategies for
lowering technical and procedural barriers to caBIG™ adoption by the
cancer research community.

Juli Klemm opened the discussion by noting that a major theme from the
morning session was the need for sharing experimental data along with
the associated metadata.

Mark Adams noted that Subha's presentation stated that TCGA has
developed policies and procedures for sharing clinical data that match
the available technology. Using that approach as a working example
should make it easier for other groups to develop and institute
appropriate procedures for their data.

*Audience*: In terms of "metadata," how much annotation is covered by
MAGE?

*Moderator*: The MAGE-OM is very extensive. MAGE-TAB, while more
manageable, still has the flexibility for adding additional or new types
of information.

*Audience*: One should remember the importance of fully articulating
requirements for new annotations and the implications for the front-end
on the data store.

*Moderator*: There is also a need to make both raw data and
"pre-computed" information from that data available for others to
perform meta-analyses.

*Audience*: Some investigators may look upon data sharing in the context
of a "Return on Investment" where they ask themselves whether their
"investment" (e.g., time) in making data available for sharing has a
reward for them.

*Audience*: So far, "forcing" people to share data as part of the caBIG™
program has not been an issue. Also, when people do question sharing,
peer pressure has had a major impact on dealing with hesitancy.

*Audience*: (Response to previous remark) caBIG™ relied on contracts as
a funding mechanism, and the majority of NCI extramural funding is
through investigator-initiated (e.g., R01, P01, etc.) grants. There is
not yet any mechanism for or consensus on forcing these recipients to
share data, and any effort would likely be met with resistance.

There was general discussion revolving around the need to develop
incentives for sharing data. It was noted (anecdotally) that there have
been no examples within the caBIG™ community of shared (microarray) data
being mined and used for original publications by other than the
investigator(s) creating the data.

*Audience*: Any incentives would most likely involve an educational
component along with providing financial support for installation of the
tools at centers (referred to Juli's third bullet point on her first
slide in the discussion deck).

*Audience*: Promoting the sharing of data would also require usable and
useful tools for analyzing the data or bringing it into an
investigator's workflow.

*Audience*: There is not an abundance of services available for end
users who might want to make use of shared data. The R01
(investigator-initiated) process could be used to support the
development of new tools (services) as long as all parties recognized
that any award was contingent on demonstrated good engineering
practices. It is even conceivable that some investigators might propose
funding for making existing tools (presumably not within the caBIG™
collection) caGRID compatible.

*Audience*: The tools within caBIG™ were often developed based on the
specific needs of individual projects. Have any gap analyses in terms of
general use been performed?

*Audience*: It might be wise to consider interactions or integration
with relevant commercial software (and presumably proprietary data
stores).

*Audience*: Identifying more general use cases might be a strategy for
extending caBIG™ tools like caIntegrator.

*Audience*: There is essentially no evidence of shared data being
inappropriately used. In contrast, there was a general sense that the
sharing of data would have the consequence of promoting collaboration by
virtue of allowing some level of access to prepublication or unpublished
results.

*Audience*: Data "quality" is also important in terms of sharing---many
experiments are preliminary in nature, first attempts at a new
technology, etc., and might not produce the highest quality results.

*Audience*: Generic use cases might also identify the usefulness of
"configurable" software or solutions.

*Additional items mentioned in audience feedback:*

-   Pathways---overlay expression and other genomic abnormality data on
    pathways

-   Tools to enable meta-analysis across datasets/institutions

-   Significant demand for annotations

-   User interface for federated metadata queries

-   Enable raw data availability

-   For consortial programs---establish rules of engagement---think data
    sharing at program inception

-   caBIG™ should help define "minimal data elements" that need to
    accompany any biomedical dataset from studies

-   Investigator education is critical at various cancer centers

-   Barrier to entry---extensive support networks to train and hand-hold
    users/principal investigators

-   Create a list of all projects---alphabet soup---already there in the
    form of caBIG™ tools landing page

-   Need to create more specific examples of real-life projects using
    caBIG™ tools

-   Publish policies and procedures for data access committees to
    encourage data sharing of protected datasets (clinical, genotype,
    etc.)

-   Other funding mechanisms need to be established to address gaps in
    translational tools. Example: write in language of caBIG™
    compatibility in R01 informatics grants

-   caBIG™ competence or core centers have to be created

-   R01 + center-based initiatives to increase adoption

-   Challenge: serve the need of today and yet design for the future. It
    is a fine balance.

-   Generic use cases---configurable solutions.

# The Jackson Laboratory EY1 Adopter Project

Grace Stafford

The goals of the project are to---

-   Use caBIG™ tools for the storage and analysis of microarray-based
    gene expression profiling

-   Make legacy microarray data available through a grid node.

Presentation:
<https://gforge.nci.nih.gov/frs/download.php/2414/JAX-ICR_tools_adoption_ICR_F2F_2007.ppt>

# Columbia University EY1 Adopter Project

Aris Floratos

The scientific goals of the study are to identify and characterize
oncogene, tumor suppressor, and signaling aberrations in breast cancer.
The IT goals of the project are to combine caBIG™ tools into a single
workflow to---

-   Migrate existing tissue banking information into caTissue

-   Employ caArray for the storage of microarray

-   Use caIntegrator for the management of research data and analyses

-   Use geWorkbench as an analysis platform.

Presentation:
<https://gforge.nci.nih.gov/frs/download.php/2415/Columbia_ICR_F2F-Sept2007.ppt>

# Washington University EY1 Adopter Project

Mukesh Sharma

The scientific goals of the study are to support two existing research
groups (the Acute Myelogenous Leukemia Group and the Neuro-Oncology
Research Group). The IT objectives include---

-   Centralized repository for microarray data

-   Biospecimen repository

-   Tools to analyze and visualize microarray data in the context of
    biospecimen information.

The caBIG™ tools to be used are---

-   caArray

-   caTissue Core/Suite

-   Analytical services for analyzing expression data, copy number, and
    loss of heterozygosity

-   caB2B.

The resources that are developed will be made available to the caBIG™
community.

Presentation:
<https://gforge.nci.nih.gov/frs/download.php/2416/WashU_ICR_F2F_slide.ppt>

# Network Inference and Analysis Using SEBINI-CABIN

Ronald Taylor and Mudita Singhal

Software Environment for Biological Network Inference--Collective
Analysis of Biological Interaction Networks (SEBINI-CABIN) is a set of
tools for inferring and analyzing networks that primarily employs a
correlational algorithm. It can be employed in identifying
transcriptional regulatory network, protein-protein information, and
interspecies and intraspecies communication in a microbial community.
The correlational approach is termed Mutual Information. The algorithm
does not assume relationships are linear.

SEBINI has the following characteristics:

-   Is a suite of programs operating on a central, relational database

-   Employs a web-based user interface that uses Java servlets

-   Contains a collection of inference algorithms

-   Includes an API to allow the addition of other methods.

CABIN has the following characteristics:

-   Is an exploratory visual analytic tool for enabling the process of
    multiple evidence fusion of interaction networks

-   Offers a plug-in for Cytoscape.

Presentation:
<https://gforge.nci.nih.gov/frs/download.php/2417/sept_17_07_NCI_caBIG_ICR_SEBINI_CABIN_talk.ppt>

# Washington University Workflows

Hrishikesh Deshmukh

The following HTP technologies are used at Washington University:

-   SNP

-   Copy Number Analysis

-   Affy and Nimblegen platforms.

The following is an example of a workflow to study Loss of
Heterozygosity (LOH):

CEL Files (Affy)

↓

Genotyping algorithm

↓

LOH segmentation tool

↓

Find overlapping segments between samples

↓

Prioritize segments with LOH

Workflows can be---

-   Linear (dChip)

-   Parallel (dChip and CNAT)

-   Iterative (SVM)

-   Conditional (aCGH, that is, if copy number = Hi, hten ID genes in
    the regions) This is computational, not experimental

[Q&A:]{.underline}

Q: How do you get all the genes into a pathway map? Do you ever find
that you'll want to put information into a tool and cannot?

Q: Do you start with a generalizable model to use for analysis?

A: Usually, we can start with either data or a model.

Q: How granularly do you capture the data? For data types that have to
be strongly typed, you would have to be pretty granular? If the service
has many steps, then you have to be careful with inputs and outputs.

A: The granularity is within a service in the examples shown here, but
in other services, you'd want to exit and be sure to get the "right"
data type.

Q: How did you define your workflow: Was it taken from Bioinformaticians
or researchers, etc.?

A: Users have a continuum of use cases and statically define the
workflow. Later, they may want to tweak the workflow. An expert will
often need to change the workflow and parameters, etc. and would
eventually move to the "hardened" tool.

Q: How embedded are the workflows? Could you swap out one?

A: Strongly typed and semantically described. Once you select an input,
the tool can put it in. Consequently, you can computationally determine
what to use.

Q: Do you save all the results/workflow?

Q: Do you have to store intermediate results?

A: Yes.

*Comment:* One may want to save intermediate results because available
caGrid services may change day to day.

Presentation:
[[https://gforge.nci.nih.gov/frs/download.php/2418/ICR_Adoption_F2F_Workflows_WashU.ppt]{.underline}](https://gforge.nci.nih.gov/frs/download.php/2418/ICR_Adoption_F2F_Workflows_WashU.ppt)

# University of Pittsburgh Medical Center Use Cases

Uma Chandron

The University of Pittsburgh Medical Center's UPMC) clinical genomics
core labs have objectives for finding solutions to managing data and
analytical service workflows, within a single core lab, within a number
of core labs (internal to UPMC) and also with external collaborators.
This includes many samples, including prostate and breast.

Highlights:

-   Have a new architecture model (CARDIFF) at UPMC that leverages
    caBIG™

-   Have used caArray to upload prostate data

-   Implemented caTISSUE for prostate

-   Would like to use caArray and caTISSUE system wide, if appropriate

-   Reported that tissue goes to Pathology, Inventory, Genomics,
    Proteomics Workflows

-   Interested in caArray repository in Clinical Genomics Repository.

-   Received mandate from the Chancellor of Health Sciences to store,
    annotate, share, and analyze microarray data.

Typical Workflow for specimen:

De-identify specimen (Tissue, RNA, cell pellet)

↓

Accession with new ID

↓

Annotate with project info, IRB, charge acct, etc.

↓

Sample processed

↓

Data generated; analysis by researcher and/or core lab

Data management:

-   Need a searchable database

-   Want to annotate as much as possible (clinical, histology, outcomes,
    protocol, reagents, etc.)

-   Want to share high-quality data within the institution and
    externally

-   Report that output of UPMC Clinical Genomics Facility was 400 chips
    in 2006.

Would like to do pilot study in Core Genotyping Facility (CGF) (with
caArray) and then expand to other core labs (University wide) if
appropriate

What is available?

-   Commercial Laboratory Information Management System (LIMS) did not
    suit UPMC's needs.

-   Large Repositories (e.g., Geo, took a long time \[2.5 months for
    post doctoral researcher to load data\])

Experience with caArray 1.4:

-   Could install, but never really used it because of user interface
    issues and some workflow issues that needed to be addressed, E.g.,
    the way projects and experiments are managed.

-   Will wait for caArray 2.0 and test for usability at UPMC.

Currently at UPMC:

-   Homegrown Access database is used.

-   No data management, only storage is possible.

-   Mostly Affy products are used, but need data management of Illumina
    and Agilent.

-   Suites by Affy (GCOS) are not sufficient for needs.

-   LIMS needs have been separated from the Repository.

Use cases for UPMC (now mostly done in a spreadsheet):

-   Annotate RNA samples processed with multiple protocols and assayed
    on multiple platforms. Many people are involved in generation and
    analysis.

-   Share experimental annotations.

-   For prostate data: Submitted data to GEO, but had to store
    annotations separately and had to send *internal*, clinical
    annotations to researchers who downloaded the "numerical/micro array
    "data from GEO.

How to Leverage caTISSUE and CaArray together:

-   Mostly for repositories but also for analysis

-   Used by 50 individuals; end users are diverse with simple and
    complex uses

-   Biggest roadblock: end users simply opening data files to get
    started

-   Majority of requests are fairly simple

-   A few methods used over and over: visualization, SAM, t test
    permutations, pathway analysis, GO annotation: Researchers want
    quick "at a glance" view

-   For more complex analyses, users want more sophisticated tools and
    integration of proteomic and genomic data/information.

-   Bioinformatics portal (GeneGo, Pathway tools, etc).

-   Commercial software: User interfaces are pretty good, but
    statistical methods are non-transparent, so there is little trust in
    the methods.

-   If caArray could format data for other tools, that would be great.

Q&A:

Q: What do you mean by "annotation"---controlled vocabulary or free
text---and how much flexibility do you need (e.g., for adding new
terms)?

A: Annotations are mostly from controlled vocabularies, but there is
also some need for free text. A system would need flexibility to extend
controlled terms.

*Audience Comment*: There may be a need for more complex use than is
reflected in the requests you are receiving.

Q: Do you see people using the user interface for annotation or do a lot
of people use MAGE-TAB?

A: MAGE-TAB is probably sufficient for us, but others have a need for a
user interface.

Q: Annotation will come from caTISSUE?

A: Yes, caArray will be able to pull in caTISSUE annotation
(eventually).

*Comment*: There might be other annotation that you need to do within
caArray that is simply not appropriate to expect to come from caTISSUE.

*Comment*: You may want annotation in workflows: not just experimental
data but also annotation within the workflows.

Presentation:
[[https://gforge.nci.nih.gov/frs/download.php/2419/Chandran_ICR_9_18_07.ppt]{.underline}](https://gforge.nci.nih.gov/frs/download.php/2419/Chandran_ICR_9_18_07.ppt)

# ICR Workflow Working Group

## Working Group Activities

***[Kiran Keshav]{.smallcaps}***

Current work group goals:

-   A tool for executing grid analytical and data service(s) to
    accomplish a pre-defined task (workflow)

-   Authoring and submission of workflows should be easy

-   Identification of specific use cases on which to base
    prototyping/development.

General considerations for a workflow authoring tool:

-   Current bottlenecks for end users?

-   Who is authoring?

-   What tools are they using, graphical?

-   What workflow features are supported?

Specific considerations for a workflow authoring tool:

-   Provide data type compatibility in the outputs to inputs between
    services.

-   Permit workflows in series or parallel (see the earlier presentation
    by Hrishikesh Deshmukh).

-   Must have semantic and syntactic compatibility (in lieu of
    transformation service).

-   Should not, at this stage, have to invoke a transformation service.

-   Be aware that even a "simple" workflow in Business Process Execution
    Language (BPEL) is not that "easy." Tools exist, but question is
    "what is easy to use" as a tool/feature?

-   After review of 15 tools, decided on Feature list.

-   Do not require an Author to code in order to create a workflow.

-   Provide a graphical user interface (GUI) that is smart enough to
    know if you can pipe services to each other.

-   Only minimal annotation should be needed?

Q&A:

Q: Do you propose to annotate components or the workflow?

A: Both.

Q: But the latter might be a BPEL doc?

A: And might also be graphical representation of it.

Q: Who is the targeted user?

A: Someone who has done SOME work in Bioinformatics.

Q: BPEL is standard. Should we use it?

A: How about Simple conceptual unified. Flow Language (Scufl)? But
caBIG™ is about standards, so we leaning toward BPEL.

*Comment*: Need to make determining data type compatibility easier.

Q: What about situations where the workflow engine sends off a request
and then waits?

A: As long as the feature set is available in BPEL, then we should
concentrate on use cases instead of more granular coding issues.

Q: What is the boundary between what the grid does and what the client
does?

A: The caGrid team wants to know specific workflow use cases so that it
can worry about the boundary.

Q: Authoring and using WF---is that the same tool?

Q: Is there are "Scheduler?"

A: Think so, but we're not interested in implementation details as much
as use cases.

*Comment*: Start thinking about workflows upfront and not after: is this
compatibility that needs to be considered in XC WSs?

Q: How do we address the issue of communicating with groups up front to
ensure that, as an example, data types can be exchanged?

*Comment*: There are two points where syntactics can go wrong: schema
generation (serialization) and in annotating the model (with data type
differences).

Next Steps:

-   Review potential scientific workflows to identify items of interest

-   Determine what potential services are available now

-   Investigate Taverna.

Presentation:
[[https://gforge.nci.nih.gov/frs/download.php/2421/20070917_icr_f2f_workflow.ppt]{.underline}](https://gforge.nci.nih.gov/frs/download.php/2421/20070917_icr_f2f_workflow.ppt)

**Action Items**

  ----------------- ------------------------------------ ----------------
  **Assigned To**   **Description**                      **Due Date**

  Mark Adams and    Collect and publish Requirements and Sept 28
  Curt Lockshin     Use cases to ICR WS listserv         

  Brian Davis       Take question to XC WSs: Is there a  At Oct 4 VCDE WS
                    need for an "Interoperability        meeting
                    review"?                             
  ----------------- ------------------------------------ ----------------

## Implementation Considerations

Patrick McConnell

Roles of different working groups:

-   ICR Role: Define scientific use cases

-   caGrid Team Role: Implement workflow solution to ICR scientific
    needs

Implementation considerations for a workflow authoring tool by the
caGrid team:

-   Language: (BPEL, Scuffle, Taverna)---BPEL currently supported by
    caGrid

-   Authoring tool (drag and drop, language-oriented)

-   Workflow Features

    -   Looping and parallelism are required.

    -   Some/most jobs will not be completed in a timely fashion,
        raising question of how to indicate that fact to the user.

-   Expensive Jobs

    -   Straight text editor (using XML) would be simple and
        inexpensive.

    -   A drag-and-drop GUI would be complicated and expensive.

-   Auditing (e.g., provenance, intermediate results)

-   Data types

    -   Stringing services together

    -   Common Data Element (CDE)/model reuse

    -   Translations may be needed with question of how to implement in
        GUI

-   Security

-   caGrid Service Types

-   caGrid Components

-   Workflow Sharing.

Presentation:
[[https://gforge.nci.nih.gov/frs/download.php/2422/20070918_icr_f2f_workflow_cagrid.ppt]{.underline}](https://gforge.nci.nih.gov/frs/download.php/2422/20070918_icr_f2f_workflow_cagrid.ppt)

## Panel Discussion on Use Cases for Workflow Tools

Mark Adams

The goal of the session is to collect suggestions from the attendees for
a list of use cases, prioritized in terms of interest, for use in
designing a workflow authoring tool/analytical pipeline.

Considerations:

-   Sharing workflows

-   Storage of workflows

-   Workflows of Workflows (e.g., stringing two smaller workflows
    together).

Example use cases:

-   Comparison of a new methodology to an old methodology.

-   SNP analysis.

-   Integration of microarrays and pathology images (as in caTRIP)

-   How to plug someone else's algorithm into your favorite methodology

-   "I want to record the steps that I followed in writing this paper
    because I want to do it over and over for future work"

-   "Every time I find a new SNP, I want to do x, y, and z; this is an
    operational process"

-   "I have already collected the data and want to leave it so that
    someone else can tweak it, and verify or refute the data"

-   How to determine, as a paper writer, which workflow version was used
    when a prior paper was written (in addition to knowing what was
    done)

*Comment:* Context is important. The core facility might want to share
but not necessarily between (for example) Duke and Pitt. Examples of
items that might have little utility for immediate sharing across
institutions include RNA sample information, cluster results, etc.
However, in the case of publications, users might want to provide a
pipeline so others can reproduce the analysis.

*Comment*: BPEL generates lots and lots of code, and it is very complex.
The question is: Does the ICR community really need those complex
features?" Scufl was developed in order to work without those
complexities.

*Comment:* Elucidating use cases will help determine which will be more
useful for community's purposes: SCUFL or BPEL.

*Comment*: The community needs to worry less about BPEL versus Scufl,
and more about whether or not to do certain things, such as looping.

*Comment*: It is given that user interaction with the workflow will be
asynchronous, but whether or not the calls in the workflow are
asynchronous will be the more important issue.

*Comment*: Asynchronous: should a workflow engine make calls or should
the user makes call?

Q: What is the priority for access to services outside of caBIG™? (e.g.,
non-grid services)

A: Taverna can take a Web Services Description Language (WSDL) file
(although not well described).

Q. Would looping over data sets (e.g., to vary parameters) be expected?
Is it practical?

Q. Would looping over different data sets be expected?

A. It's possible that it could be done by a workflow engine but it might
not be something we should do.

Q: How comfortable do people feel actually authoring/writing
scripts/programming at this level for these workflows?

A: Since this is not an end-user representative group, those who do
author need to see whether their end user (perhaps a scientist) can use
and manage what they are authoring.

Q: What level of comfort would people have doing the workflow now and is
this the appropriate audience to come up with use cases: put on user
hats.

A: Three levels of users: experts, those of the level of data
analysts/bioinformaticians, and less experienced end users.

*Comment*: We are more interested in "analytical pipeline" use cases for
caBIG™.

*Comment*: An approach would be to capture workflows by the steps that
are actually done---this would not affect the end user because it is a
very back-end activity.

*Comment*: In a LIMS, one could create XML files and then define
workflow, and so visualize the whole workflow.

Q: Is the theory of a workflow public? Should the components of a
workflow be considered intellectual property?

A: As new cases are entered, your report gets refreshed (would most
likely be manual).

Q: For a use case that might involve the discovery of a gene, do we
provide grid-based access to genome browsers and all the features they
provide?

A: No.

*Comment*: A number of non-grid academic services are used, in addition
to a smaller number of commercial services.

Q: Does every service have to be a grid service?

A: This will show up a gap analysis too.---what are we missing, and
whether we need to consider non-grid services.

*Comment*: A lot of sequences have been generated from tumor
analyses---one might want to identify how frequent a particular mutation
occurs. Typically, one can create a University of California Santa Cruz
(UCSC) genome browser track and then plot those data (if using those
data in a subsequent step is the most important part). This would
suggest grid-based access to the UCSC gene browser.

Q: Is it heterogeneous?

A: Yes.

*Comment*: Another common use case would be obtaining a set of SNPs for
analysis. This would involve using an external analytic service (or
tool). Creating a USCS track with final visualization in the USCS genome
browser would be standard. In this case, the visualization has
interactive features.

*Comment*: Workflow should include an interactive step (e.g., if there
is a conditional, and a human needs to make a decision).

*Comment*: As a requirement, workflows should also be applicable to
proteomics or a genomics---proteomics mix. A use case associated with
this requirement would be looking at expression data: An example would
be to find proteins associated with subset of interest in a gene list.

Q. Would use cases also require covering issues such as provenance:
intermediate results, whether and where they should be stored, who
should have access to them, or how long they should live? How critical
is it to have intermediate results?

A. Last year, server versus client side storage was discussed.
GenePattern has temporary server-side storage, but storage on the client
side is probably more appropriate. GenePattern does allow zip file to be
exported.

Q. Will dynamic discovery of services be of interest only to
computational scientists?

Q: When should workflow be published and what type of security should be
used? Should that be applied before or after publication? Should the
user decide?

A. Maybe just have to e-mail those around if private.

Q. What level of annotation will be needed for a workflow? An example
use case would be the publication of a paper that uses several different
workflows.

A. In this case, annotations might be versions of each component needed,
author, and contacts for tissue samples.

Q. Would a user always want to get intermediate results?

Q: Should we be able to choose who has access to intermediate results?

A: Whoever has access to the workflow should have access to intermediate
results but sometimes intermediate data is too sensitive---and we will
not want such open access to intermediate results.

Q. Should we make the distinction between authoring and publishing? When
authoring, should we not have to worry about moving terabytes of data?

# Exercise---Collecting Use Cases and Specific Requirements with "Voting" for prioritization

+---------+------------------------------------------------------------+
| **      | **[Use Case]{.smallcaps}**                                 |
| [Votes] |                                                            |
| {.small |                                                            |
| caps}** |                                                            |
+=========+============================================================+
| [1      | The author of a paper wants to record steps for            |
| 0]{.sma | publication/sharing.                                       |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | The core lab/facility wants to do same steps repeatedly    |
| 6]{.sma | internally.                                                |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | Core lab wants to share externally.                        |
| 1]{.sma |                                                            |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | User starts workflow, leaves it to run and dynamically     |
| 1]{.sma | pulls toward completion.                                   |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | When using LIMS, record steps as a workflow in XML file.   |
| 0]{.sma |                                                            |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | Looping over data sets.                                    |
| 1]{.sma |                                                            |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | Looping over services (to compare services).               |
| 4]{.sma |                                                            |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | Dynamic discovery (search) of services.                    |
| 1]{.sma |                                                            |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | Browsing discovery of services (to find distinctive        |
| 5]{.sma | functionality).                                            |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | User defines security for access to workflows.             |
| 5]{.sma |                                                            |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | User incorporates grid and non-grid data services into     |
| 9]{.sma | workflow.                                                  |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | Workflow interruption for user decision point (genes to    |
| 3]{.sma | proteins).                                                 |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | Need for non-caGrid components in workflow (e.g., UCSC     |
| 8]{.sma | genome browser).                                           |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [\-\-   | Annotations                                                |
| -]{.sma |                                                            |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | > *Annotation of version of component.*                    |
| 4]{.sma |                                                            |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | > *Annotation of version of parameters (input and          |
| 3]{.sma | > output).*                                                |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | > *Annotation of version of workflow.*                     |
| 0]{.sma |                                                            |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | > *Annotation of version of hardware.*                     |
| 0]{.sma |                                                            |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [\-\-   | Visualization tools                                        |
| -]{.sma |                                                            |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | > *Final step.*                                            |
| 0]{.sma |                                                            |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | > *Intermediate step.*                                     |
| 0]{.sma |                                                            |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | > *Types.*                                                 |
| 0]{.sma |                                                            |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [\-\-   | Provenance                                                 |
| -]{.sma |                                                            |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | > *Who authored the workflow.*                             |
| 5]{.sma |                                                            |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | > *What version(s) of component(s) were used.*             |
| 1]{.sma |                                                            |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | > *Where are intermediate data stored (server, client,     |
| 3]{.sma | > other).*                                                 |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | > *Who has access*                                         |
| 0]{.sma |                                                            |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+
| [       | > *When accessed*                                          |
| 0]{.sma |                                                            |
| llcaps} |                                                            |
+---------+------------------------------------------------------------+

  --------------------------------------------------------------------------------------
  **[Votes]{.smallcaps}**   **[Requirements]{.smallcaps}**
  ------------------------- ------------------------------------------------------------
  [\-\--]{.smallcaps}       Authoring Tool

  [6]{.smallcaps}           Drag-and-drop

  [1]{.smallcaps}           Different modes

  [0]{.smallcaps}           Visualization tools

  [\-\--]{.smallcaps}       Workflow Features

  [4]{.smallcaps}           Linear

  [3]{.smallcaps}           Parallel

  [6]{.smallcaps}           Iterative

  [3]{.smallcaps}           Conditional

  [1]{.smallcaps}           Fault tolerance

  [\-\--]{.smallcaps}       Provenance

  [5]{.smallcaps}           Workflow description

  [1]{.smallcaps}           Services used

  [2]{.smallcaps}           Intermediate results (storage)

  [0]{.smallcaps}           Annotations

  [1]{.smallcaps}           Data source

  [6]{.smallcaps}           Asynchronous submission of workflows

  [\-\--]{.smallcaps}       Security

  [7]{.smallcaps}           Intermediate results

  [0]{.smallcaps}           Intermediate "builds"

  [1]{.smallcaps}           General considerations (e.g., ownership)

  [0]{.smallcaps}           Non-GRID services

  [\-\--]{.smallcaps}       GRID-services type

  [8]{.smallcaps}           Bulk data

  [0]{.smallcaps}           Resources

  [1]{.smallcaps}           Data

  [\-\--]{.smallcaps}       Data types

  [5]{.smallcaps}           Semantic

  [1]{.smallcaps}           Syntactic

  [\-\--]{.smallcaps}       caGRID Components

  [4]{.smallcaps}           Service discovery

  [2]{.smallcaps}           TeraGrid

  [2]{.smallcaps}           Federated query

                            
  --------------------------------------------------------------------------------------

Action Items

  -----------------------------------------------------------------------
  **Assigned To** **Description**                          **Due Date**
  --------------- ---------------------------------------- --------------
  Mark Adams and  Collate and type up the results of Post  
  Curt Lockshin   its (Prioritized Requirements and Use    
                  Cases)                                   

  Curt Lockshin   Distribute list of Requirements and Use  
                  Cases to ICR WS                          

  Curt Lockshin   Share Requirements and Use Cases with    
  and Patrick     caGrid team                              
  McConnell                                                
  -----------------------------------------------------------------------

# ICR Bulk Data Transfer---High Throughput Data WG

Martin Morgan

The goal of the ICR HTP Data WG is to identify mechanisms for efficient,
use-case dependent data transfer.

Background

The HTP Data WG started by collecting scenarios/use cases to get idea of
types of data used and what was done with that data. HTP data transfer
should be handled behind the scenes (not seen by the user).

Examples:

-   caIntegrator/CGEMs---returns very few but very large objects

-   caTRIP---distributed query to return a very large number of small
    objects

-   MAGE-ML

-   RProteomics

-   SNP/Biomarker.

Data input/output issues:

-   User interaction-responsiveness (show something immediately to user)

-   Large data transfer between services (not to user, but to two
    services)

-   Many small objects versus several large objects.

Progress

-   Possibilities with caGrid

-   End Point References (EPR)

    -   Contains methods for iterating over a set

    -   Allows manageable data chunks

    -   Allows overlapping parallelized operations

-   Bulk data transfer

    -   Provides efficient (but out of band) data transfer.

Bulk data transfer by Grid FTP

-   Returns an EPR

-   EPR contains methods for retrieving files via FTP

-   Subsequent calls to the EPR move data from sources to destination

-   Data movement uses efficient GridFTP implementation

-   Data is in globus container

-   Efficiency gains are achieved because XML is not used (out of band)
    (e.g., but not quite semantically correct)

-   Example for Imaging WS (IVI Middleware project using for some of
    their huge Image data)

*Issue 1:* Semantics and security end point references

-   EPR is strongly typed, but methods inside EPR are *not* semantically
    typed (service discovery would be difficult)

-   Security could be short circuited because of this (FTP between two
    cases)

Comment: Maybe the way to do this is to make grid FTP more part of the
Grid and less accessible to the user, but this still needs to be
formalized.

*Issue 2*: Standardized APIs for common EPR "choreography" (e.g., two
cooperating services).

-   A solution is to embed in caGrid

-   Do not need to describe all this for users

-   Do not need multiple ways to do it

-   Do need to establish how it is done and explicit rules that *must*
    to be followed.

Q: Can this approach be abstracted?

A: Yes, it can and should be abstracted.

*Issue 3:* Specification of large data objects

-   Grid FTP is out of band: It does not need to conform to XSD.

-   Some formats are very well defined, (e.g., jpeg) without being
    strongly typed in caBIG™ (because they are NOT in XML).

Q: How does one decide what uses Grid FTP and what does not?

A: In some situations, the transport should be transparent at both ends
with one service replying to a service request with XML. The grid would
take that reply, bundle the data, and transport it efficiently via
GridFTP, and present it to the second service in the original XML.
Applications might be written that use GridFTP to communicate between
different components (e.g., distributed databases and processing). In
this case, data need not be exposed and hence could follow any
convention.

*Comment*: VCDE would like a proposal.

*Issue 4:* Need for additional grid-level infrastructure

-   No high-level GridFTP client/server implementation

Q: Are EPRs normal caBIG™ objects or do we need to make new guidelines
for them?

Q: For Grid FTP, will metadata about the service be needed?

A: Grid FTP will be able to supply some of the necessary metadata.

Presentation:
[[https://gforge.nci.nih.gov/frs/download.php/2424/20070918_ICR_F2F_WG_HTPD.ppt]{.underline}](https://gforge.nci.nih.gov/frs/download.php/2424/20070918_ICR_F2F_WG_HTPD.ppt)

Action Items

  -----------------------------------------------------------------------
  **Assigned To** **Description**                         **Due Date**
  --------------- --------------------------------------- ---------------
  Martin Morgan   Have small group present strawman       
                  proposal to VCDE (and Arch?) presenting 
                  the criteria for what can use GridFTP   
                  and what cannot                         

  Martin Morgan   Have small group present strawman       
                  proposal to VCDE (and Arch ) for how    
                  EPR would be rendered as object with    
                  metadata                                

  Brian Davis     Provide time to Martin on VCDE WS call  
                  for proposals to be discussed in VCDE   
                  WS                                      
  -----------------------------------------------------------------------

# ICR Analytical Services Best Practices WG

Ted Liefeld

The goal of the ICR Analytical Services Best Practices WG is to reduce
the time and cost of deploying an analytical service on the grid; this
includes optimizing development practices and resolving breaking issues
that may be identified in the course of this activity. A fundamental
observation is that it took three person-weeks to put GenePattern
modules on caGrid (longer for a new module).

Q: How long should it take?

A: We are aiming at putting modules on grid in less than 1 day: Given
the number of modules, that would be the only way to get these numerous
services up.

General Observations:

-   Data services have long lifetimes (measured in years) and are fewer
    in number than analytic services, which have shorter lifetimes.

-   Analytical services change often---parameters are added and removed,
    and algorithms are updated.

-   There are many analytic services (400 in GP, geW, and BioC).

-   Class registration in caBIG™ was designed for Data Services;
    Analytical Services change so fast that it does not make sense to
    put work into a heavyweight process to register.

-   Time spent on modeling: two to three person-weeks per service.

-   Analytical parameters now: \~ 1 week effort to register.

*Issue 1:* MAGE model reuse

-   caB2B tried to take data from caArray and put it in GenePattern, but
    was unsuccessful.

-   Parts of the MAGE model (property sets) that caused mismatched
    schemas were a little different.

-   The problem occurred because of the way reuse was done (with EA,
    hand edited to get into Introduce). This introduced errors and
    omissions.

-   It is recommended that XML schemas (not just Models) should be
    shared/reused to facilitate syntactic interoperability.

Q: How do we accomplish MAGE model reuse?

A: It can probably be done through the GME.

A: The next version of tools will be able to be able to provide
substantial help with this (caGrid 2.0).

Q: At the level of Schema and objects?

A: At the schema level into Introduce.

Q: How does sharing of schema and objects happen (when pruning down
data)?

A: It is not the best practice to do this?

*Issue 2:* Re-annotation /Re-registration of Models:

-   We recommend eliminating redundant re-annotation of shared models.

-   An example is the log transform with MAGE.

-   Avoid including the UML model.

Q. How do we address re-annotation and re-registration?

A. By creating an analytic service and documenting everything although
documentation is in many places.

*Comment:* An example is the log transform and the use of MAGE. EA is
finicky, the UML interfaces are not used in SIW, and EA does a poor job
of XML schema generation.

*Comment:* A proposed *new* process could be *only* adding *new*
classes. For this, one could acquire XML Schemas for reused models and
load schemas into Introduce. The new step would then be to register the
combined model with Service loader and send the service a metadata file.
Service loader is a new tool that will help us with this new process.

Q: Is the use of "Service Loader" truly needed?

A: To put up a caGrid service---no; to register service metadata---yes.

*Comment*: This ties the new model to the reused model. One could/might
use discover.

*Comment*: The Service Loader process is defined but still undergoing
testing.

*Comment*: The group wants to test the new service registration process
(to see if the process works) but there is still an issue. Using MAGE is
a problem with caCORE Tools and the generation of schema from MAGE: This
is a problem with SDK. The reason it went undetected is because the
caCORE system is not created so there is no an XML schema to load into
Introduce.

Q: Is this bug in caCORE SDK going to be fixed in 2008?

Q: Shall we drop MAGE now and use STAT-ML?

A. Not a semantically rich model; however, it is familiar to the ASBP
developers.

Q: Is there anything else that can be used?

A. We could have used another schema generator. Maybe we should do a
comparison of generators.

Q: What model should be used? What is the workflow?

Q. How about the CGEMS service?

Q: Is the goal to attach semantics to the parameters or what?

A. The use case is to turn the caGrid rep into a parameter information
class.

Q: Where do the parameter data lie? In the object model or in the
service metadata model?

*Comment:* To lessen the burden, do it one time (e.g., use case is for
updating).

*Comment*: Parameters modeling of semantics might be useless (use BLAST
as use case).

*Comment*: Maybe someone should go through a parameter model and see if
it is useful to users (e.g., for reuse, understanding of model, and
service).

*Comment*: Maybe this will come up in Silver level review.

*Comment*: We want to externalize the parameters; that is the best way
to do it (internal and caBIG™ development).

*Comment*: We should still annotate with vocabulary but use a
lightweight process to keep the burden low on developers.

*Comment*: It should probably be part of service metadata (because it
defines the interface) but only if in metadata class.

*Comment*: Maybe the distinction is making the UML model but not needing
to "register" it in caDSR as part of Data/UML model but instead put in a
service metamodel describing the service.

Q: Does the parameter model have to be specific for a service or can we
use a "generic" model for all parameters?

Presentation:
[[https://gforge.nci.nih.gov/frs/download.php/2425/ASBP_20070918_ICR_F2F_WG.ppt]{.underline}](https://gforge.nci.nih.gov/frs/download.php/2425/ASBP_20070918_ICR_F2F_WG.ppt)

Action Items

  --------------- --------------------------------------- ---------------
  **Assigned To** **Description**                         **Due Date**

  Brian           Arrange for Ted and Baris to present at October 4
                  VCDE WS on October 4                    

  Ted and Baris   Present strawman proposal to VCDE 1)    October 4
                  where ASBP is now, 2) Parameters: where 
                  does this information live and how is   
                  it registered (in service data through  
                  Introduce, and/or in Metadata in caDSR  
                  about input and output).                

  Ted and ASBP    Evaluate CGEMS service for Test         
  group           Analytic Service experiment: Ted and    
                  ASBP group.                             

  Ted             Provide proposed parameter model (used  
                  in GenePattern) to Aris and Martin (for 
                  geWorkbench and Bioconductor).          

  Aris and Martin Test proposed parameter model on        
                  geWorkbench and BioConductor to see     
                  whether it "works."                     
  --------------- --------------------------------------- ---------------

# Compatibility Guidelines v3.0 WG

Patrick McConnell

Silver API

-   Has well-described APIs

-   Has Tools, client interfaces, messaging interfaces

-   IS analytical or data oriented

-   Requires interfaces to be defined in UML

-   Exposes the connectivity of data elements.

Q: Regarding the query API, is its purpose to allow you to navigate the
model and is that expected for each data service?

A: Basically, yes.

Gold API

-   Is oriented toward grid and grid services

-   Has caGrid index service

-   Standardizes query interface

-   Has messaging APIs

-   Has well-described service level metadata

-   Includes security protocols, authentication

-   May need some retooling to taking messaging from silver to gold.

Vocabularies

Q: Why do we need a Concept ID and resolving services?

A: With a federated terminology space, concepts can appear in multiple
caGrid nodes as vocabulary services. Users will need to be able to point
to the concept they mean (e.g., over multiple instances and perhaps
versions) in the NCI thesaurus deployed at multiple caGrid nodes.

*Comment:* caBIG™ should make note of other federal initiatives that
impinge on these Vocabulary guidelines and make sure we are aligned. We
might want to acknowledge other guidelines and rules for this in v3
guidelines.

*Comment:* It would be important to distinguish different aspects of
vocabularies such as repository, content, and appropriateness of use.

Presentation:
<https://gforge.nci.nih.gov/frs/download.php/2426/20080918_icr_f2f_gold_compat.ppt>

Action Items

  ------------------------------------------------------------------------
  **Assigned   **Description**                               **Due Date**
  To**                                                       
  ------------ --------------------------------------------- -------------
  Brian        Make sure any federal initiatives on          Sept 30, 2007
               Vocabulary federation are researched while we 
               are writing up the guidelines                 

  ------------------------------------------------------------------------