Vision

caArray

  -------------------------- --------------------------------------------
  Last Revised:              January 16, 2008

  Produced By:               NCICB Development Team

  Version:                   1.3
  -------------------------- --------------------------------------------

Document Approvals

The list contains the name for the core project team and any key
stakeholders who have an interest in the success of the project. An "S"
identifies persons responsible for approval from the Business and
Development. Sign off of the document would be required when a decision
is made not to take action for defined gaps.

  --- ---------------- ---------------- --- ---------------- ----------------
  S   Name             Role             S   Name             Role

  S   Anand Basu       NCICB            S   Juli Klemm,      Product Manager
                       Engineering          Ph.D.            
                       Manager                               

      Brent Gendleman  Development          Jerry Eads       NCICB
                       Project Manager                       Independent QA

      Eric Tavela      Development                           
                       Architect                             

      Don Swan         NCICB                                 
                       Application                           
                       Support                               
  --- ---------------- ---------------- --- ---------------- ----------------

Revision History

When you make a change to a document, you must add an entry to this
Revision History table and you must manually type the Last Revised Date
on the front cover.

  ------------ --------- ------------------------------------ ---------------
  Date         Version   Description                          Revised by

  03/12/2007   0.1       Initial Draft with a focus on        Brent Gendleman
                         Stakeholder descriptions and         
                         identification                       

  03/23/2007   0.2       Detailed the Problem Statement and   Brent Gendleman
                         Product Positioning                  

  04/06/2007   0.3       Updated from Internal Requirement    Brent Gendleman
                         Sessions                             

  04/11/2007   0.4       Updated through product positioning  Brent Gendleman

  4/15/2007    0.5       Updated Business Opportunity and     Juli Klemm
                         Product Positioning                  

  4/18/07      0.6       Filled in Needs                      Brent Gendleman

  5/3/07       0.7       Flushed out Features based on in     Brent Gendleman
                         person cancer center interviews and  
                         documentation they provided          

  5/8/07       0.8       Reviewed and updated needs and       Brent Gendleman
                         features per consultation with       
                         Product Manager                      

  5/9/07       0.9       Added proposed priority to the       Brent Gendleman
                         features                             

  6/19/07      1.0       Minor updates to replace "study"     Brent Gendleman
                         with "project"                       

  7/16/07      1.1       Minor update to Project Content      Brent Gendleman
                         model (showing 1:1 relationship      
                         between a project and exp design)    
                         and missing url and description of   
                         web genome                           

  8/3/07       1.2       Updated based on feedback from user  Brent Gendleman
                         community                            

  9/27/07      1.3       Updated based on additional feedback Brent Gendleman
                         from Dev, Product Manager and User   
                         Community. Experiment has replaced   
                         Project fully and description added  
                         for Glycan Assays                    
  ------------ --------- ------------------------------------ ---------------

Copyrights and Trademarks

© Copyright 2007 by CBIIT, caBIG^TM^. All rights reserved.

Table of Contents

[1. Introduction 1](#introduction)

[1.1. Purpose 1](#purpose)

[1.2. Scope 1](#scope)

[1.3. Definitions, Acronyms, and Abbreviations
1](#definitions-acronyms-and-abbreviations)

[1.4. References 2](#references)

[1.4.1. caArray sites of interest 2](#caarray-sites-of-interest)

[2. Positioning 2](#positioning)

[2.1. Business Opportunity 2](#business-opportunity)

[2.2. Problem Statement 4](#problem-statement)

[2.3. Product Position Statement 5](#product-position-statement)

[3. Stakeholder and User Descriptions
6](#stakeholder-and-user-descriptions)

[3.1. Market Demographics 6](#market-demographics)

[3.2. Stakeholder Summary 6](#stakeholder-summary)

[3.2.1. External Stakeholders 6](#external-stakeholders)

[3.2.2. Internal Stakeholders 7](#internal-stakeholders)

[3.3. User Environment 10](#user-environment)

[3.3.1. Institutional Structure of the Community
10](#institutional-structure-of-the-community)

[3.3.2. Experiment Lifecycle 12](#experiment-lifecycle)

[3.3.3. Array platforms 15](#array-platforms)

[3.3.4. Common Proprietary analysis tools
17](#common-proprietary-analysis-tools)

[3.3.5. Available caBIG analysis tools
17](#available-cabig-analysis-tools)

[3.4. Key Stakeholder or User Needs 18](#key-stakeholder-or-user-needs)

[3.5. Alternatives and Competition 22](#alternatives-and-competition)

[4. Product Overview 22](#product-overview)

[4.1. Product Perspective 23](#product-perspective)

[4.2. Assumptions and Dependencies 23](#assumptions-and-dependencies)

[4.2.1. Only terms from Managed Ontology systems will be available
23](#only-terms-from-managed-ontology-systems-will-be-available)

[4.3. Cost and Pricing 23](#cost-and-pricing)

[4.4. Licensing and Installation 23](#licensing-and-installation)

[5. Product Features 24](#product-features)

[5.1. Experiment Management 24](#experiment-management)

[5.1.1. Propose an Experiment 24](#propose-an-experiment)

[5.1.2. Review an Experiment 24](#review-an-experiment)

[5.1.3. Transfer Experiment Ownership
26](#transfer-experiment-ownership)

[5.1.4. Cascading Control of Experiment or Sample Visibility
26](#cascading-control-of-experiment-or-sample-visibility)

[5.1.5. Control Experiment or Sample Permissions
26](#control-experiment-or-sample-permissions)

[5.1.6. Provide an Legible and Accessible Experiment name and URL
26](#provide-an-legible-and-accessible-experiment-name-and-url)

[5.1.7. Support Multiple Types of Array Services
26](#support-multiple-types-of-array-services)

[5.1.8. Associate Publications to Experiments
27](#associate-publications-to-experiments)

[5.2. Array Annotation and Data Management
27](#array-annotation-and-data-management)

[5.2.1. Source and Sample Annotation 28](#source-and-sample-annotation)

[5.2.2. Annotate Experiments Interactively Using Web Forms
28](#annotate-experiments-interactively-using-web-forms)

[5.2.3. Import Array Annotations and Data
29](#import-array-annotations-and-data)

[5.2.4. Validate Data 31](#validate-data)

[5.2.5. Parse Data 31](#parse-data)

[5.2.6. Maintain Annotations and Array Data
31](#maintain-annotations-and-array-data)

[5.3. Array Design Management 32](#array-design-management)

[5.3.1. Pre-load Array Designs 32](#pre-load-array-designs)

[5.3.2. Import Array Design 32](#import-array-design)

[5.4. Extraction 32](#extraction)

[5.4.1. Export Experiment to Standard Formats
32](#export-experiment-to-standard-formats)

[5.4.2. Submit Experiment to GEO or ArrayExpress
33](#submit-experiment-to-geo-or-arrayexpress)

[5.4.3. Retrieve Complete Data Matrix as a comma or tag delimited file
33](#retrieve-complete-data-matrix-as-a-comma-or-tag-delimited-file)

[5.4.4. Retrieve Partial Data Matrix as a file
33](#retrieve-partial-data-matrix-as-a-file)

[5.4.5. Retrieve data in native (manufacturer) format
33](#retrieve-data-in-native-manufacturer-format)

[5.4.6. Retrieve annotations and array data through an API
33](#retrieve-annotations-and-array-data-through-an-api)

[5.5. System Administration 34](#system-administration)

[5.5.1. Add a User 34](#add-a-user)

[5.5.2. Edit a User 34](#edit-a-user)

[5.5.3. Delete user 34](#delete-user)

[5.5.4. Disable a User 34](#disable-a-user)

[5.5.5. Manage Collaboration Groups 34](#manage-collaboration-groups)

[5.5.6. Provide Configurable, System Generated Email
34](#provide-configurable-system-generated-email)

[5.5.7. Provide for Customization of Installations
35](#provide-for-customization-of-installations)

[5.6. Curate Annotation 35](#curate-annotation)

[5.6.1. Edit Ontological Values through a Single View
35](#edit-ontological-values-through-a-single-view)

[5.6.2. Edit Ontological Values during Annotation of a Experiment
35](#edit-ontological-values-during-annotation-of-a-experiment)

[5.6.3. Add Vocabulary Term 35](#add-vocabulary-term)

[5.6.4. Manage Terms Added by Users 35](#manage-terms-added-by-users)

[5.7. Navigation and Search 35](#navigation-and-search)

[5.7.1. Inventory of Summary Repository Statistics
36](#inventory-of-summary-repository-statistics)

[5.7.2. Search Public Data 36](#search-public-data)

[5.7.3. Search Restricted Data 36](#search-restricted-data)

[5.7.4. Search Categories and Result Actions
36](#search-categories-and-result-actions)

[5.7.5. Query Genes Across the Repository
37](#query-genes-across-the-repository)

[5.7.6. Actionable Search Results 37](#actionable-search-results)

[5.7.7. Provide Experiment Workspace 37](#provide-experiment-workspace)

[5.7.8. User-Directed Organization of Repository Information
37](#user-directed-organization-of-repository-information)

# Introduction

## Purpose

The purpose of this document is to collect, analyze, and define
high-level needs and features of the next generation of caArray. It
focuses on the capabilities needed by the stakeholders and the target
users, and why these needs exist. The details of how caArray fulfills
these needs are detailed in the use-case and supplementary
specifications.

## Scope

Successful software naturally evolves to meet the changing needs of its
user community and the "world" in which it exists. caArray has been
deployed and in use since January 31, 2005, and the team has determined
that several factors encourage us to review its first major revision
since its original inception.

The factors we have considered include:

-   Revisit the vision of caArray to ensure our evolved view of its
    raison d'etre is optimized going forward.

-   Revisit of the user community to understand changing needs and
    current growth potential

-   Review of other industry and competitive developments which should
    be considered for co-opting, collaboration, or capitulation.

-   Introspective review of the 1.x architecture and features to ensure
    the best elements are elevated and the lesser elements are retired
    or replaced.

-   Incorporate elements of caBIG-wide architecture that have matured
    since the creation of 1.x caArray (e.g., the Common Security Model).

-   Re/Produce supporting software assets that may have received
    insufficient attention or grown out of sync with the software over
    time to ensure 2.0 is clearly communicated to both internal and
    external stakeholders.

An additional benefit of this activity is it will put essential assets
in a form that our development team uses to schedule, prioritize, and
reference as the new generation moves toward implementation. In short,
all software applications require periodic consideration for major
revision to ensure efficient and pertinent evolution. caArray is no
exception. The team is enthusiastically anticipating driving the next
generation of caArray!

## Definitions, Acronyms, and Abbreviations

See caBIG Glossary: <https://cabig.nci.nih.gov/glossary> and NCI
Dictionary of terminologies:
<http://nciterms.nci.nih.gov/NCIBrowser/Dictionary.do>.

To support understanding of this document, the following terms are
defined here:

Project -- a collection of projects that support a specific scientific
goal

Experiment -- a set of annotation and array data that describe the
experimental design, the samples used and the array data produced.

Source -- the material -- typically tissue or cell lines - from which a
sample is taken

Sample -- the material used for extraction onto an array

Annotation -- the experiment metadata that describe the "what" and "how"
a experiment was executed

Array -- the raw data that is produced as a result of an experiment

## References

### caArray sites of interest

**NCICB Production Site**: <http://array.nci.nih.gov/> -- the public
instance of caArray

**Product Summary Site**: <https://cabig.nci.nih.gov/tools/caArray> -
the summary of caArray capabilities and direction

**Public Information Site**: <http://caarray.nci.nih.gov/> -- a public
web site that allows anyone to download the latest version, access
documentation, launch the portal and visit sites that provide analysis
of the data contained in caArray.

**caArray Work Group Site**:
<https://cabig.nci.nih.gov/workspaces/ICR/caArray-wg/> -- this public
web site provides access to the schedule, monthly meeting notes and
links to the listserv for the stakeholder community

**Microarray Gene Expression Data Society -** <http://mged.org/> The
providers and curators of microarray standards, software and models.

# Positioning

## Business Opportunity

The National Cancer Institute (NCI) has launched the caBIG™ (cancer
Biomedical Informatics Grid™) initiative to accelerate research
discoveries and improve patient outcomes by linking researchers,
physicians, and patients throughout the cancer community. caBIG™ serves
as the cornerstone of NCI's biomedical informatics efforts to transform
cancer research into a more collaborative, efficient, and effective
endeavor. In 2007, caBIG™ has moved from the pilot phase to the
enterprise and is looking to evolve its set of maturing assets. A
significant business opportunity exists in this evolution to make the
day to day lives of the researchers who produce and consume data at the
local level easier and in so doing, meet the needs of the global cancer
community.

As the scientific community begins to better understand cancer at the
molecular levels and personalized medicine is implemented in cancer
patient care, researchers and clinicians will require more rapid access
to---and easier methods to analyze---the multiple types of information
involved. However, in many cases the systems needed to help translate
the necessary data into better patient outcomes are either non-existent,
disconnected, or underperforming. To this end, the vision of caBIG™ is a
full cycle of integrated cancer research, extending from bench to
bedside, and back again. caArray a committed following, years of user
feedback and contribution on which to build from, sufficient resources,
and an expansive vision to support integrative cancer research.

Expression profiling is now a standard tool set with which to
interrogate biological systems. Parallel advances in computing and new
array technology provide an opportunity for collaboration and discovery
within the scientific community and across traditional boundaries to
reach clinicians and ultimately patients. The insistence on open source
development provides the community with the greatest opportunity to gain
access to the tools they desperately need to execute their respective
mission. caArray was initially developed with expression profiling in
mind, using the caBIG Compatibility Guidelines, as well as the
Microarray Gene Expression Data (MGED) society standards for microarray
data. Compatibility with these standards and guidelines was and remains
required. However, the ability to add new standards that are developing
is also necessary to facilitate data exchange and analysis across
domains. A number of analytical tools and services that connect to
caArray are already available - including geWorkbench and GenePattern -
that provide a variety of analysis, visualization and annotation
functions for microarray data.

The primary goal of caArray is to further translational cancer research
through acquisition, dissemination and aggregation of high quality array
data to support subsequent analysis. Initially envisioned to be the de
facto repository for cancer related expression data, other applications
-- primarily the Gene Expression Omnibus (GEO) -- has assumed the role.
However, the quality of the expression data and the ability to integrate
the use of array technology into clinical research remains at issue.
Further, the opportunity for caArray to evolve to handle other types of
array data will provide greater impetus for use among the Cancer Centers
and their collaborators which will ultimately benefit the cancer
community. Data from expression, SNP, methylation, and protein arrays
are anticipated for inclusion in caArray. Also under consideration are
the burgeoning platforms of RNAi and CHip-chip data. Tissue microarrays
represent another array-based technique that require a significantly
different business process in their creation but are being considered
for inclusion in the repository.

A significant challenge is to find common ground for the annotation,
upload and extraction of these array data platforms to support
meaningful analysis for cancer research. The need for logical and
expedient approaches to storing, querying, retrieving and reporting on
array--based data has increased over the last several years due to the
contribution of several factors:

-   a significant increase in array information (expression and others)
    available due to:

-   decreases in the cost to generate this data

-   improvements in the technology to generate this data

-   advances in the approaches to analyze this data

-   the need to increase the numbers of samples to enhance discovery and
    ensure validity of results once found;

-   and the need to ease the administration of the data and results by
    giving the community a single point of reference to perform the most
    essential tasks of array-based research.

The initial generation of caArray (1.0) and subsequent point releases
(currently 1.5) have provided the interface for annotating
scientifically significant meta-data along with the independent ability
to upload and download data through an applet or accessing the MAGE-OM
API over the grid service provided by caBIG. caArray will improve upon
this starting point by organizing the application around the natural
workflow between investigators and the array labs that serve them,
improve the user experience for storing and retrieving the data
produced, query the data through an easier to comprehend API, and bridge
the gap between the analysis tools in heavy use in the community today
and the data they need to consume. A simplified organizational structure
for basic experiment relationships that fundamentally represent
"annotation" versus the resulting array "data" is shown in Figure 1.
This is a definition we will use throughout this document and is an
overall theme of the application.

![](media/image2.wmf){width="4.895833333333333in"
height="3.8958333333333335in"}

Figure 1: Basic Organizational Structure

caArray will look to perform intra-platform, intra-experiment queries
for local adopters, via the NCICB instance and potentially across the
grid collectively to increase the availability of quality data.

caArray will be built to scale with an open architecture and supportive
documentation to allow for future enhancements, particularly with regard
to interfacing with additional analysis tools, the ability to query
across platforms, and poised to exploit web services and/or databases
from other components of caBIG when available and prudent. The desire to
create an extensible array system that is non-platform-specific and
potentially customizable is a theme that should influence the building
of caArray.

## Problem Statement

+---------------+------------------------------------------------------+
| **The problem | -   Platform vendors and custom crafters not         |
| of**          |     universally producing a single shareable format  |
|               |     for the annotation of array experiments and the  |
|               |     data that results;                               |
|               |                                                      |
|               | -   The lack of properly annotated high              |
|               |     dimensionality molecular data that can be        |
|               |     seamlessly integrated into the execution of      |
|               |     clinical research;                               |
|               |                                                      |
|               | -   The amount of annotation needed to support the   |
|               |     validation, retrieval and analysis of large sets |
|               |     of data;                                         |
|               |                                                      |
|               | -   Data repositories that meet the publishing       |
|               |     requirements of journals but not the scientific  |
|               |     needs of geographically disparate researchers    |
+---------------+------------------------------------------------------+
| **Affects**   | -   The cancer research community, the life science  |
|               |     community as a whole, clinicians and ultimately  |
|               |     their patients access to the highest quality     |
|               |     care                                             |
+---------------+------------------------------------------------------+
| **The impact  | -   A variety of incompatible tools and services     |
| of which is** |     disparately made available that limits the       |
|               |     ability to share and benefit from others in the  |
|               |     community who are generating otherwise useful    |
|               |     array data,                                      |
+---------------+------------------------------------------------------+
| **A           | -   One that permits the community to share and      |
| successful    |     analyze array data regardless of the platform    |
| solution      |     used to generate it, tied to meaningful sample   |
| would be**    |     annotations.                                     |
+---------------+------------------------------------------------------+

## Product Position Statement

+---------------+------------------------------------------------------+
| **For**       | -   The NCI and its affiliated institutions          |
+---------------+------------------------------------------------------+
| **Who**       | -   Need to annotate, store, and share array         |
|               |     annotation and data as part of cancer research   |
|               |     and clinical trials in a caBIG compliant manner  |
+---------------+------------------------------------------------------+
| **caArray**   | -   Is an open-source, user-driven, role-based, web  |
|               |     and programmatically accessible data management  |
|               |     system that guides the annotation and exchange   |
|               |     of array data through a federated model of local |
|               |     installations                                    |
+---------------+------------------------------------------------------+
| **That**      | -   provides browser-based and programmatic access   |
|               |     to the data stored locally;                      |
|               |                                                      |
|               | -   enables mechanisms for accessing all local       |
|               |     installation data over the caGrid;               |
|               |                                                      |
|               | -   provides interoperability with a wide set of     |
|               |     other data repositories available over the       |
|               |     caGrid;                                          |
|               |                                                      |
|               | -   supports silver compatibility with caBIG         |
|               |     guidelines;                                      |
|               |                                                      |
|               | -   promotes compatibility with the MIAME 1.1        |
|               |     guidelines and supports the import and export of |
|               |     MAGE-TAB                                         |
|               |                                                      |
|               | -   provides the data for caBIG analytical services  |
+---------------+------------------------------------------------------+
| **Unlike**    | -   Gene Expression Omnibus                          |
|               |                                                      |
|               | -   Array Express                                    |
|               |                                                      |
|               | -   Stanford Microarray Database                     |
|               |                                                      |
|               | -   And a variety of commercial proprietary and      |
|               |     open-source solutions from microarray vendors    |
|               |     and service providers                            |
+---------------+------------------------------------------------------+
| **Our         | -   is a completely open source (web application     |
| product**     |     server and database) and funded by the NCI to    |
|               |     continue its open-source evolution               |
|               |                                                      |
|               | -   supports the natural workflow of the community   |
|               |     across array approaches                          |
|               |                                                      |
|               | -   caGrid-Enabled                                   |
|               |                                                      |
|               | -   is caBIG compliant at a Silver Level             |
+---------------+------------------------------------------------------+

# Stakeholder and User Descriptions

## Market Demographics

The overall market for caArray is expansive. caBIG™ casts a wide net
across more than 50 Cancer Centers and a significant number of
collaborators world wide. While each Cancer Center isn't necessarily a
core facility for producing array data, it is readily apparent that the
interrogation and analysis of array data is among the techniques that
will drive discovery, trials and treatments and is therefore, a
necessary tool for each center and their external collaborators. Two
methods for accessing caArray have been established. The first is to use
the centralized portal and repository hosted by the NCICB. The second is
to download the application packaged with necessary external components
to install locally. Currently there are 550 NCICB caArray Portal Users
and roughly 6 known local installations across the community.

The market goes beyond the core set of users who will populate caArray
to those who want to interrogate the data they produce in unique ways to
support the translational model of discovery. This interrogation will
come through manipulation of a web-based dialogue with a Graphical User
Interface (GUI) or through accessing the data through a well-documented
Application Protocol Interface (API) at the central NCICB repository or
another other exposed data set across the grid.

## Stakeholder Summary

### External Stakeholders

These stakeholder types represent the breadth of the target audience
that lie outside the core development team for the caArray application.
At least one individual will be named as a representative for each
Stakeholder type, though there is no restriction on the number of
representatives or the ability for one individual to represent more than
one stakeholder. In addition, not all stakeholders are end-users of the
application.

Table 1. External Stakeholders

+------------+------------------+---------------------+---------------+
| Type       | Description      | Responsibilities    | R             |
|            |                  |                     | epresentative |
+============+==================+=====================+===============+
| NCICB      | A user or group  | Requirements        | Hanxin Lu     |
| Adopter    | of users who     | Specifier           | (NCI/DCB)     |
|            | have adopted the | (excluding          |               |
|            | NCICB version of | environment)        |               |
|            | caArray but who  |                     |               |
|            | haven't or don't | Contributes to      |               |
|            | plan to use      | feature             |               |
|            | local            | prioritization      |               |
|            | installations of |                     |               |
|            | caArray.         | Potential Alpha     |               |
|            |                  | Tester              |               |
|            |                  |                     |               |
|            |                  | Beta Tester         |               |
+------------+------------------+---------------------+---------------+
| Local      | A general term   | Requirements        | University of |
| Installer  | covering user    | Specifer (including | Pittsburgh    |
|            | groups who have  | environment)        |               |
|            | installed at     |                     | Georgetown    |
|            | least one        | Contributes to      | University    |
|            | version of       | feature             |               |
|            | caArray (1.3,    | prioritization      | Thomas        |
|            | 1.4, or 1.5)     |                     | Jefferson     |
|            |                  | Potential Alpha     |               |
|            |                  | Tester              | Wistar        |
|            |                  |                     |               |
|            |                  | Beta Tester         |               |
+------------+------------------+---------------------+---------------+
| Code       | Anyone who has   | Requirements        | Gerald        |
| C          | or plans to      | Specifier           | Fontenay      |
| ontributor | provide complete |                     | (LBNL)        |
|            | modules,         | API Reviewer        |               |
|            | enhancements or  |                     |               |
|            | fixes to any of  | Follower of         |               |
|            | the underlying   | practices and       |               |
|            | code of caArray  | procedures for code |               |
|            |                  | contribution        |               |
+------------+------------------+---------------------+---------------+
| caArray    | Anyone who has   | Requirements        | Subha         |
| Integrator | or plans to      | Specifier           | Madhavan      |
|            | access caArray's |                     | (NCICB)       |
|            | API to integrate | API Reviewer        |               |
|            | into their own   |                     | Aris Floratos |
|            | application      | API Alpha and/or    | (Columbia)    |
|            | either under the | Beta Tester         |               |
|            | caBIG umbrella   |                     |               |
|            | or outside of    |                     |               |
|            | it.              |                     |               |
+------------+------------------+---------------------+---------------+
| Desired    | An individual or | Requirements        | Cancer Center |
| Adopter    | group of users   | Specifier           | Community     |
|            | who is targeted  |                     | (e.g.,        |
|            | for adoption but | May contribute to   | Northwestern, |
|            | for many reasons | feature             | Dana Farber,  |
|            | has chosen not   | prioritization      | Washington    |
|            | to adopt caArray |                     | University)   |
|            | at the present   | Alpha/beta tester?  |               |
|            | time.            |                     |               |
+------------+------------------+---------------------+---------------+
| caGrid     | The underlying   | Expose and maintain | Avinash       |
| Team       | service oriented | service definitions | Shanbhag      |
|            | infrastructure   |                     |               |
|            | that supports    |                     |               |
|            | caBIG™           |                     |               |
+------------+------------------+---------------------+---------------+
| caCORE     | Cancer Common    | Validate Common     | Denise Warzel |
| Team       | Ontologic        | Data Elements       |               |
|            | Representation   | (caDSR)             |               |
|            | Environment;     |                     |               |
|            | open-source      | Validate Controlled |               |
|            | software that    | Vocabulary (EVS)    |               |
|            | helps to         |                     |               |
|            | streamline       | Validate UML        |               |
|            | informatics      | supporting a Model  |               |
|            | development      | Driven Approach     |               |
|            | throughout the   |                     |               |
|            | cancer community |                     |               |
+------------+------------------+---------------------+---------------+
| Satellite  | The IT team that | Contribute to       | James Li      |
| E          | supports local   | Environment         | (GTown), Carl |
| nvironment | installations of | Requirements        | Swanson (TJ)  |
| Team       | caArray for our  |                     |               |
|            | end user         | Support             |               |
|            | community        | Installations and   |               |
|            |                  | Updates             |               |
+------------+------------------+---------------------+---------------+

### Internal Stakeholders

These stakeholders are, at a minimum, focused on the evolution of
caArray. For the purposes of this document and the caArray project,
their perspective is squarely on caArray and its contribution to the
success of caBIG™'s collective stakeholders.

Table 2. Internal Stakeholders

+----------+--------------+---------------------+---------------------+
| Name     | Description  | Responsibilities    | Representative      |
+==========+==============+=====================+=====================+
| caBIG    | The          | Provide strategic   | -   Ken Buetow      |
| Program  | visionary    | input and validate  |                     |
| Leader   | across the   | the vision and      |                     |
|          | caBIG        | scope of caArray.   |                     |
|          | enterprise.  |                     |                     |
+----------+--------------+---------------------+---------------------+
| CBIIT    | Head of      | Provide input into  | -   Peter Covitz    |
| Chief    | operations   | the position of     |                     |
| Op       | for CBIIT.   | caArray in the      |                     |
| erations |              | broader scope of    |                     |
| Officer  |              | all CBIIT products. |                     |
+----------+--------------+---------------------+---------------------+
| caArray  | Ensuring     | Provide input into  | -   Juli Klemm      |
| Product  | over time    | the direction for   |                     |
| Manager  | that caArray | the evolution of    |                     |
|          | comfortably  | the software        |                     |
|          | meets the    | leading the CCB.    |                     |
|          | needs of all |                     |                     |
|          | stakeholders | Monitor             |                     |
|          | by           | development,        |                     |
|          | continually  | marketing and       |                     |
|          | monitoring   | outreach            |                     |
|          | and          |                     |                     |
|          | modifying    | Ensures that there  |                     |
|          | the elements | will be a market    |                     |
|          | of how it is | demand for the      |                     |
|          | marketed and | product's features  |                     |
|          | forecasting  |                     |                     |
|          | what caArray |                     |                     |
|          | needs to     |                     |                     |
|          | provide to   |                     |                     |
|          | be           |                     |                     |
|          | successful.  |                     |                     |
+----------+--------------+---------------------+---------------------+
| caArray  | Responsible  | Monitors the        | -   Anand Basu      |
| Eng      | for the      | project's progress  |                     |
| ineering | ultimate     | Ensures that the    |                     |
| Manager  | success of   | system will be      |                     |
|          | the          | maintainable        |                     |
|          | application  |                     |                     |
|          | both as an   | Monitors all facets |                     |
|          | independent  | of the project's    |                     |
|          | service and  | progress            |                     |
|          | under the    |                     |                     |
|          | umbrella of  | Approves resources  |                     |
|          | caBIG        | and funding         |                     |
+----------+--------------+---------------------+---------------------+
| caArray  | Provides     | Requirements        | -   George          |
| Ind      | independent  | Reviewer            |     Komatsoulis     |
| ependent | validation   |                     |                     |
| Quality  | and          | Manages Test Plans, |                     |
| A        | verification | Test Cases, and     |                     |
| ssurance | that         | provides Results    |                     |
| (IQA)    | expected     |                     |                     |
|          | functional   | Validates and       |                     |
|          | and          | Promotes Deliveries |                     |
|          | no           | across Tiers post   |                     |
|          | n-functional | Development         |                     |
|          | requirements |                     |                     |
|          | are met      |                     |                     |
+----------+--------------+---------------------+---------------------+
| NCICB    | Provides     | Contributes to      | -   Paul Duvall,    |
| Systems  | system       | Environment         |     Stelligent,     |
| Team     | resources    | Requirements        |     (SCM), Terrapin |
|          | for          |                     |     Systems Inc.,   |
|          | development, | Supports all        |     Don Swan (Help  |
|          | test, stage  | Environment Setup   |     Desk), Vanessa  |
|          | and          | and Maintenance     |     Caldwell (DBA), |
|          | production   |                     |     Sriram Kira(App |
|          |              | Provides Level 1    |     Support)        |
|          |              | Help Desk Support   |                     |
+----------+--------------+---------------------+---------------------+
| NCICB    | Provides     | Requirements        | -   Jill Hadfield   |
| Docum    | end-user and | Reviewer            |                     |
| entation | system       |                     |                     |
|          | d            | Creates User Help,  |                     |
|          | ocumentation | Instructions and    |                     |
|          |              | Installation Guides |                     |
+----------+--------------+---------------------+---------------------+
| caArray  | Responsible  | Elicits and         | -   5AM Solutions,  |
| Dev      | for the      | Documents           |     Inc.            |
| elopment | delivery of  | Requirements        |                     |
| Team     | the software |                     |                     |
|          | meeting the  | Analyzes and        |                     |
|          | r            | Designs the         |                     |
|          | equirements. | Software            |                     |
|          |              |                     |                     |
|          |              | Implements the      |                     |
|          |              | Software            |                     |
|          |              |                     |                     |
|          |              | Collaborates with   |                     |
|          |              | all stakeholders to |                     |
|          |              | support the         |                     |
|          |              | evolution of the    |                     |
|          |              | software            |                     |
|          |              |                     |                     |
|          |              | Supports CCB        |                     |
|          |              |                     |                     |
|          |              | Responds to Level 2 |                     |
|          |              | and 3 Support       |                     |
|          |              | Requests            |                     |
+----------+--------------+---------------------+---------------------+

Table 3 User Depictions

+----------+------------+----------------+-------------+-------------+
| Name     | D          | Re             | Stakeholder | Rep         |
|          | escription | sponsibilities |             | resentative |
+==========+============+================+=============+=============+
| P        | Designers  | Overall        | NCICB       | Monica      |
| rincipal | of         | execution and  | Adopter,    | Parenelli   |
| Inve     | e          | quality of the | Local       | (Pitt)      |
| stigator | xperiments | science        | Installer,  |             |
|          | that will  |                | Desired     |             |
|          | use array  |                | Adopter     |             |
|          | technology |                |             |             |
+----------+------------+----------------+-------------+-------------+
| Research | A support  | Data entry and | NCICB       | Robert      |
| S        | position   | submission of  | Adopter,    | Clifford    |
| cientist | in the     | projects for   | Local       |             |
|          | Principal  | their PI       | Installer,  |             |
|          | Inve       |                | Desired     |             |
|          | stigator's |                | Adopter     |             |
|          | department |                |             |             |
+----------+------------+----------------+-------------+-------------+
| Lab      | R          | Organizing and | NCICB       | Paola       |
| Admin    | esponsible | managing a     | Adopter,    | Fortina and |
| istrator | for        | lab's          | Local       | Jack        |
|          | co         | production,    | Installer,  | London,     |
|          | ordination | sample         | Desired     | Kathryn     |
|          | and often  | storage, and   | Adopter     | Scott (TJ,  |
|          | reporting  | meeting the    |             | Local       |
|          | of the     | needs of the   |             | installer)\ |
|          | lab's day  | lab's          |             | Habtom      |
|          | to day     | researchers    |             | Ressom      |
|          | work.      |                |             | (GWU, Local |
|          |            |                |             | Installer)  |
+----------+------------+----------------+-------------+-------------+
| Lab      | Performs   | Sample receipt | NCICB       | TBD         |
| S        | most of    | and storage    | Adopter,    |             |
| cientist | the lab's  |                | Local       |             |
|          | day to day | Management of  | Installer,  |             |
|          | scientific | experiment     | Desired     |             |
|          | work with  | runs           | Adopter     |             |
|          | regard to  |                |             |             |
|          | preparing  | Quality        |             |             |
|          | of         | Control        |             |             |
|          | samples,   |                |             |             |
|          | running    | Raw Data       |             |             |
|          | chips and  | Production     |             |             |
|          | checking   |                |             |             |
|          | quality.   |                |             |             |
+----------+------------+----------------+-------------+-------------+
| Biostat  | Performs   | Analysis of    | NCICB       | Robert      |
| istician | the        | Raw Data       | Adopter,    | Gentleman   |
|          | analysis   |                | Local       | (Fred       |
|          | of the     | Creation and   | Installer,  | Hutchinson) |
|          | data       | Management of  | Desired     |             |
|          | derived    | Algorithms and | Adopter     | Baris Suzek |
|          | from array | Scripts        |             | (Gtown)     |
|          | e          |                |             |             |
|          | xperiments | Reporting of   |             | Uma         |
|          |            | Results        |             | Chandran    |
|          |            |                |             | (UPitt)     |
|          |            |                |             |             |
|          |            |                |             | Louise      |
|          |            |                |             | Showe       |
|          |            |                |             | (Wistar)    |
|          |            |                |             |             |
|          |            |                |             | Abhijit     |
|          |            |                |             | Dasgupta    |
|          |            |                |             | (TJ)\       |
|          |            |                |             | Simon Lin   |
|          |            |                |             | (NWU)       |
+----------+------------+----------------+-------------+-------------+
| Curator  | Reviews    | Annotation     | NCICB       | TBD         |
|          | their own  | Quality        | Adopter,    |             |
|          | or their   | Control        | Local       |             |
|          | labs data  |                | Installer,  |             |
|          | entry and  |                | Desired     |             |
|          | may change |                | Adopter     |             |
|          | and        |                |             |             |
|          | contribute |                |             |             |
|          | data terms |                |             |             |
|          | to         |                |             |             |
|          | increase   |                |             |             |
|          | quality of |                |             |             |
|          | s          |                |             |             |
|          | ubmissions |                |             |             |
+----------+------------+----------------+-------------+-------------+
| A        | Views the  | No             | N/A -- all  | All         |
| nonymous | public     | responsibility | s           |             |
| User     | projects   |                | takeholders |             |
|          | on the     |                | will        |             |
|          | NCICB      |                | dictate     |             |
|          | instance   |                | what is and |             |
|          | of caArray |                | what isn't  |             |
|          |            |                | available   |             |
|          |            |                | to an       |             |
|          |            |                | anonymous   |             |
|          |            |                | user        |             |
+----------+------------+----------------+-------------+-------------+
| External | Progra     | Use API to     | caBIG       | Subha       |
| System   | mmatically | request and    | Integrator, | Madhavan -  |
|          | integrates | receive data   | TCGA,       | Cancer      |
|          | with or    |                | caBIO,      | Genome      |
|          | in         |                | caTissue,   | Atlas       |
|          | terrogates |                | Analysis    |             |
|          | the NCICB  |                | Tools       | Aris        |
|          | and/or a   |                |             | Floratos    |
|          | local      |                |             | (Columbia)  |
|          | instance   |                |             |             |
|          | of caArray |                |             | WorkBench,  |
|          |            |                |             | caBIO       |
|          |            |                |             |             |
|          |            |                |             | Michael     |
|          |            |                |             | Becich-     |
|          |            |                |             | (Pitt)      |
|          |            |                |             | Honest      |
|          |            |                |             | Broker,     |
|          |            |                |             | caTissue    |
+----------+------------+----------------+-------------+-------------+

## User Environment

In this section, we will cover vital elements that reflect the
environment of our user community -- the processes they have in place,
the equipment and materials they use to conduct their experiments and
the tools they commonly use to consume the data placed into caArray.

### Institutional Structure of the Community

The array community caArray serves has a variety of organizational
approaches to the set up of array based labs and the relationship to the
research scientists they serve. The investigation into those structures
has produced the following generic model that represents most of the
institutional pattern for how people work within the cancer community.
The model will be represented by the type of software roles we create,
the assignment of individuals to those role or roles, allowances for
collaboration within and across the institution those individuals are
associated with, and the granularity of permissions when exposing
experiments as public.

![](media/image3.wmf){width="4.052083333333333in"
height="5.385416666666667in"}

Figure 2. Institutional Organization and Generic Roles

At the top of the model is a general construct called "Groups" which
serves to group 1 or more institutions and the underlying research and
lab facilities that are associated to it. The most common types of
groups in the community are **consortiums**, which primarily come
together to share resources and expertise across institutions both
inside and outside caArray's cancer center focus. Examples of such
groups include [Cooperative
Groups](http://nciterms.nci.nih.gov/NCIBrowser/ConceptReport.jsp?dictionary=NCI_Thesaurus&code=C16008&bookmarktag=2),
which organize researchers, cancer centers and community doctors to
support clinical trial activities and are officially recognized through
grants; and the
[SPORE](http://nciterms.nci.nih.gov/NCIBrowser/GetRoleAndProperty.do?bookmarktag=1&conceptname=Specialized_Programs_of_Research_Excellence)
program, which are organized to promote interdisciplinary research and
speed the bi-directional exchange of information between basic and
clinical sciences.

caArray's first priority are Institutions that are a part of the Cancer
Center community -- currently numbering sixty-two (62). However, these
centers' array labs often support more than just cancer related
inquiries and caArray will be generic enough to support non-cancer
experiments.

In addition, all cancer centers are not organized in the same manner.
Many do have [Core
Facilities](http://nciterms.nci.nih.gov/NCIBrowser/ConceptReport.jsp?dictionary=NCI_Thesaurus&code=C15896&bookmarktag=2),
which provide a consolidated, shared resource of expertise that is
typically available to anyone inside the Institution and occasionally to
scientists outside the home institution if a research agreement is in
place between the respective institutions. Still others don't have any
one core facility, but rather several independent array facilities that
offer different threads of expertise -- such as genotyping, gene
expression or proteomics. Regardless, there are core sets of roles that
can be organized to support the array labs (project executors) and the
researchers (project submitters) who request their services which are
represented in Figure 2.

### Experiment Lifecycle

The typical lifecycle ranges anywhere from 3-6 months from the point a
experiment is initially discussed to the delivery of results by the lab
to the requesting investigator. To this day, the most common method for
the distribution of data back to the investigator is the creation of
DVDs (to accommodate the larger file size that CDs can't store).
Disconnection between the PI's and the Lab remains a consistent problem
though our anecdotal evidence from the end users suggests that the state
of collaboration is improving. In fact, some of the target institutions
are requiring a minimal set of information to be shared by the
investigator (vs. walking over to the lab and handing them samples to be
run). A generalized depiction of the work flow from start to finish is
described below in Figure 3.

![](media/image4.wmf){width="5.770833333333333in"
height="2.7152777777777777in"}

Figure 3. Overall Workflow

An additional item of importance is to allow for the establishment of
how much an experiment will cost and what charge code will be used --
for example, a purchase order or a grant number -- as historically,
payment has been an issue for doing work and it remains an issue
regarding analysis. Most of the labs we spoke with won't begin an
experiment without a known source of revenue to cover the costs.

#### Experiment Design Collaboration

Collaboration between the investigators and the statisticians is highly
desired by the statisticians at a minimum is becoming known to be the
beneficial to all. Figure 4 depicts the states of the "experiment" that
support the collaboration between the Principal Investigator, the Lab
Administrator and the Lab Scientists and Statisticians who will be
assigned to execute the experiment's experimental design. Using the
Overall Workflow (Figure 3) as a guide, these states represent the
activities of collaboration, approval and assignment.

![](media/image5.wmf){width="5.229166666666667in"
height="3.7604166666666665in"}

Figure 4. Experiment Submission States

#### Lab Workflow post-Acceptance

Acceptance indicates that the experiment is understood and assigned. The
first activity is to actually receive the samples so the planning for
the execution can begin. The samples may or may not come all at once and
depending on the volume of work the lab is performing, the lab
scientists may choose to start the experiment prior to receiving all the
samples.

There are a significant number of activities to be taken against each
sample in the experiment. They are described at a high-level below.

![](media/image6.wmf){width="6.495833333333334in"
height="3.0479166666666666in"}

Figure 5. High-level Lab Workflow

#### Lab Workflow post-production 

Once a experiment's data analysis has been completed, the priority
becomes publication. Typically, there is a 6-9 month period between when
the work is done and when a paper will be published, though longer time
frames are common. In order to support publication, there is often a
request for actual data to be made available to the journal considering
publication and very commonly (though not absolutely) once a paper is
published for the data to be publicly consumable.

As of this writing, there is no requirement across journals for making
data available that is MIAME compliant. The MGED Society has a long
history in the literature for making the case for MIAME and several
significant journals have accepted the suggestion -- with Nature being
the most influential -- but it isn't a fundamental requirement (see
<http://mged.org/Workgroups/MIAME/journals.html> for current journals
requiring MIAME). Much of the community has taken the step to submit the
hybridization data to GEO but the cancer community widely regards the
value of the data available to be limited due to the lack of detailed
sample annotation.

The goal for caArray will be to support making the data publicly
available as well as to allow for keeping data private.. The basic model
for promotion of experiments is shown in Figure 6 with the Principal
Investigator responsible for assigning the visibility of the experiment
as the "data owner". There are additional considerations to be explored
governing what portion of a experiment is actually available -- all of
it or just portions -- and the overall theme that when a experiment is
made available at the "public access" level, the ability to see, find
and download those experiments across the grid is also available. This
would allow for an anonymous user at the NCICB instance to search for
experiments of a certain type and find experiments at any of the local
installations.

![](media/image7.wmf){width="6.498611111111111in"
height="4.6402777777777775in"}

Figure 6 Graduated Degrees of Public Exposure

### Array platforms

The following Array platforms are expected to be supported over the life
of caArray. If an array platform is not supported, the expected release
will be stated as either "tbd" which indicates that it is not known or
"deferred" which indicates that a decision has been made for the release
in question. It is also understood that multiple versions of an array
design should be supported as well as the community is acutely aware of
the cost of the technology and will want to use the last of a particular
design even when a newer design is available. In addition, with the
method of investigations and the supporting technology moving faster
than the adoption, the support of additional manufacturers and
experiment types is expected to grow. Table 4 indicates the current set
of array methods, their description, providers, data produced known to
be in use in the cancer community and our anticipated release for
supporting them.

Table 4 Supported Array Types and Providers

  ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  Type               Description      Providers                                         Data Types                                                           Available   Expected
                                                                                                                                                             Content     Release
  ------------------ ---------------- ------------------------------------------------- -------------------------------------------------------------------- ----------- -----------
  SNP                A Single         Affymetrix                                        .dat, .cel, .chp, .exp, .rpt, .txt (design: .cdf)                    .cel, .chp, 2.0
                     Nucleotide                                                                                                                              .cdf parsed 
                     Poloymorphism is                                                                                                                                    
                     the most                                                                                                                                            
                     frequent type of                                                                                                                                    
                     variation in the                                                                                                                                    
                     genome. These                                                                                                                                       
                     studies look to                                                                                                                                     
                     scour a                                                                                                                                             
                     particular                                                                                                                                          
                     population's                                                                                                                                        
                     propensity for a                                                                                                                                    
                     given disease                                                                                                                                       
                     and potential                                                                                                                                       
                     therapy based on                                                                                                                                    
                     the SNP-linkage                                                                                                                                     
                     analysis                                                                                                                                            

                                      [Illumina](http://www.illumina.com/) (bead        .idat (image), .csv or .dat (bead manifest), .xml (content)          Csv parsed  2.0
                                      arrays)                                                                                                                            

                                      [Illumina Golden                                                                                                       Download    2.0
                                      Gate](http://www.illumina.com/pages.ilmn?ID=11)                                                                        Only        

                                      Agilent                                           .txt (design: .txt)                                                  Download    2.0
                                                                                                                                                             Only        

  aCGH               The ratio of the Agilent                                           .txt (design: .txt)                                                  Download    2.0
                     fluorescence                                                                                                                            Only        
                     intensity of the                                                                                                                                    
                     tumor to that of                                                                                                                                    
                     the reference                                                                                                                                       
                     DNA is                                                                                                                                              
                     calculated to                                                                                                                                       
                     measure the copy                                                                                                                                    
                     number changes                                                                                                                                      
                     for a particular                                                                                                                                    
                     location in the                                                                                                                                     
                     genome.                                                                                                                                             

                                      UCSF Spot                                         .gpr\                                                                .gpr, .gal  2.0
                                                                                        (design: .gal)                                                                   

  Gene Expression    Investigation    Affymetrix (including Exon)                       .dat, .cel, .chp, .exp, .rpt, .txt, (design: cdf)                    .cel, .chp, 2.0
                     focuses on what                                                                                                                         .cdf        
                     genes are                                                                                                                                           
                     expressed in a                                                                                                                                      
                     particular cell                                                                                                                                     
                     type of an                                                                                                                                          
                     organism, at a                                                                                                                                      
                     particular time,                                                                                                                                    
                     under particular                                                                                                                                    
                     condiditions                                                                                                                                        

                                      GenePix                                           .gpr (design: .gal)                                                  .gpr, .gal  2.0

                                      ImaGene                                           .txt, .csv                                                           Download    2.0
                                                                                                                                                             Only        

                                      Agilent                                           .shp, .xml                                                           Download    2.0
                                                                                                                                                             Only        

  Methylation        Attempts to      Illumina GoldenGate                                                                                                    Download    2.0
                     establish                                                                                                                               Only        
                     patterns of                                                                                                                                         
                     methylation                                                                                                                                         
                     genome-wide or                                                                                                                                      
                     within targeted                                                                                                                                     
                     promoters or CpG                                                                                                                                    
                     islands                                                                                                                                             

                                      Nimblegen                                         .tiff, gff version2.0 (design: .ndf)                                 Download    TBD
                                                                                                                                                             Only        

  microRNA           By measuring     Ambion+Invitrogen                                                                                                                  TBD
                     activity among                                                                                                                                      
                     the 217 genes                                                                                                                                       
                     encoding miRNA,                                                                                                                                     
                     patterns of gene                                                                                                                                    
                     activity that                                                                                                                                       
                     can distinguish                                                                                                                                     
                     types of cancers                                                                                                                                    
                     can be                                                                                                                                              
                     discerned.                                                                                                                                          

  Protein/antibody                    TBD                                               TBD                                                                  Deferred    Deferred

  Reverse phase                                                                                                                                                          Deferred
  protein lysate                                                                                                                                                         

  RNAi               RNA Interference Nimblegen                                                                                                                          Deferred
                     explores gene                                                                                                                                       
                     silencing                                                                                                                                           
                     affects                                                                                                                                             

  Chip-chip          Map regulatory   Nimblegen                                         Raw data, variety of GFF image files                                             TBD
                     protein binding                                                                                                                                     
                     sites genome                                                                                                                                        
                     wide for                                                                                                                                            
                     transcription                                                                                                                                       
                     factors,                                                                                                                                            
                     polymerases and                                                                                                                                     
                     histones, or                                                                                                                                        
                     target promoter                                                                                                                                     
                     regions                                                                                                                                             

  Glycan             characterizing   Custom - though it appears that the NCI through   Unknown -- but examples are available at:                                        TBD
                     and studying the SBIR/STTR and Biotech companies are attempting to <http://www.functionalglycomics.org/glycomics/publicdata/home.jsp>               
                     changes in       commercialize ([The Gel                                                                                                            
                     carbohydrate     Company,](http://www.gelcompany.com/index.html)                                                                                    
                     structures       [Gentel Biosciences](http://www.gentelbio.com/))                                                                                   
                     (glycans) on                                                                                                                                        
                     particular                                                                                                                                          
                     proteins                                                                                                                                            

  Tissue Microarray  A fundamentally  Custom                                            Small alpha/numeric values                                                       TBD
                     different                                                                                                                                           
                     approach, this                                                                                                                                      
                     method consists                                                                                                                                     
                     of paraffin                                                                                                                                         
                     blocks in which                                                                                                                                     
                     up to 1000                                                                                                                                          
                     separate tissue                                                                                                                                     
                     cores are                                                                                                                                           
                     assembled in                                                                                                                                        
                     array fashion to                                                                                                                                    
                     allow                                                                                                                                               
                     simultaneous                                                                                                                                        
                     histological                                                                                                                                        
                     analysis.                                                                                                                                           
  ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

### Common Proprietary analysis tools

Commercial standard analytical tools such as SAS and S+ are expected to
be a part of the statistician tool set.

### Available caBIG analysis tools

Several tools are currently able to analyze data stored in caArray from
local installations. These include:

**geWorkbench** -
<http://wiki.c2b2.columbia.edu/workbench/index.php/Home>

Developed at the Columbia University, NY is an extendible and flexible
desktop tool for microarray data analysis and visualization. The release
1.0 includes several data analysis and visualization functions,
including hierarchical clustering, self organizing maps, color mosaic
images and biological pathways.

**Gene Pattern** --
<http://www.broad.mit.edu/cancer/software/genepattern/>

GenePattern puts sophisticated computational methods into the hands of
the biomedical research community. A simple application interface gives
a broad audience access to a growing repository of analytic tools for
genomic data, while an API supports computational biologists.
GenePattern is a powerful analysis workflow tool developed to support
multidisciplinary genomic research programs and designed to encourage
rapid integration of new techniques. It is developed by the Broad
Institute.

**Bioconductor --** <http://www.bioconductor.org/>

Bioconductor is an open source and open development software project for
the analysis and comprehension of genomic data. The project was started
in the Fall of 2001. The Bioconductor core team is based primarily at
the Fred Hutchinson Cancer Research Center. Other members come from
various US and international institutions. Bioconductor is primarily
based on the R programming language but we do accept contributions in
any programming language.

**webGenome** -- <http://webgenome.nci.nih.gov/>

WebGenome is a web application for creating various types of graphical
plots of microarray-based data, especially aCGH data. The system can be
configured to read data from relational database systems or from
in-memory data structures from client applications

**VISDA -** <https://cabig.nci.nih.gov/tools/VISDA>

VISDA (VIsual Statistical Data Analyzer) is an analytical tool for
cluster modeling, visualization, and discovery.

## Key Stakeholder or User Needs

The following table describes high level needs elicited from the
stakeholder and user representatives above and prioritized by the
Product Manager with their assistance. These needs frame the context for
deriving features and a basic traceability should exist.

Table 5. Stakeholder and User Needs

  --------------------------------------------------------------------------------------------------------------
  Need              Priority       Concerns             Current         Proposed Solutions
                                                        Solution        
  ----------------- -------------- -------------------- --------------- ----------------------------------------
  Improve ability   **High**       Distinctions between Often           Provide an intuitive interface for
  to upload fully                  arrays don't lend    experiments are organizing the array data and annotation
  annotated array                  itself immediately   sent to NCICB   that resembles concepts that are
  data in bulk by                  to one common        for uploading.  commonly understood across arrays,
  any owner of an                  interface and        The process is  rather than an unfamiliar and
  experiment                       underlying           tedious for     intimidating model meant more for
                                   compliance           them as well    computers than human consumption.
                                   requirements (for    but the desire  
                                   importing, exporting is to get the   
                                   MAGE-ML) may be      data into       
                                   problematic                          

  Conveniently add  **High**       The ability to add   A new design is NCICB will provide new array types and
  new array types                  custom array types   loaded into the load the designs which can be
  and designs as                   and designs may be a database        downloadable by all local installations.
  the field                        significant effort.  through a       This could be a choice -- where NCICB
  progresses                       Commercially         backend         informs user of the existence or
                                   available designs    process.        automated by way of a check caArray
                                   seem more prudent.                   performs periodically. In addition,
                                   Need to determine                    local centers may be able to make public
                                   whether to                           a type and a design if they are first to
                                   distribute the                       use it.
                                   designs or indicate                  
                                   where and how to                     
                                   load them.                           

  Dramatically      **Critical**   The matrix of teams, While thorough, Automate wherever prudent and possible
  decrease the                     management and       manual,         that supports the quality and timeline
  turnaround time                  processes and lack   redundant       of delivery. Configuration and Testing
  for releases of                  of automation.       effort is       are the likely candidates for
  new features and                 Balancing the needs  employed        automation.
  bug fixes                        of functional        throughout the  
                                   testing and          process and is  
                                   scientific/quality   prone to        
                                   control              inadvertent     
                                                        error. Months   
                                                        go by between   
                                                        the release of  
                                                        candidates to   
                                                        their eventual  
                                                        promotion to    
                                                        production      

  Improve           **Critical**   Distinction might    Current process Register through the application web
  turnaround time                  need to be made for  is up to 72     portal and automate requests to NCICB
  on acquiring user                acquiring NCICB      hours; need to  
  accounts                         accounts versus      ensure that at  
                                   local accounts       NCICB all users 
                                                        are known       

  Secure            **Critical**   Applet signature has SSL has been    Determine if an applet is required and
  transactions and                 been problematic and introduced as   ensure extremely clear instructions on
  data exchange                    it has not been      an option for   how to install the certificate to allow
                                   tested outside of    general         for full coverage of the server and the
                                   NCICB                browsing in     applet
                                                        addition to the 
                                                        upload applet   
                                                        being made      
                                                        secure          

  Need for an       **Critical**   Needs to be          For caArray,    A simple, human understandable study
  accession code or                recognized as        long URL        identifier consisting of a concatenated
  URI to                           acceptable for being pointing to     description of the study
  unambiguously                    publicly available   Experiment      (studytype_platform_pilastname_number)
  identify an                      by MGED and                          
  experiment                       scientific journals                  

  caArray MUST be   **Critical**   Formats and other    Different tools Establish THE method for accessing
  able to easily                   constraints of the   are running     caArray data that removes the need for
  pass the data to                 analytical tools     different       re-implementation on the part of tools
  analytical tools                 need to be           methods and     that use it
  to get usable                    established up front even caArray    
  results out.                     and be careful       versions to     
                                   implemented.         access caArray  
                                   Backward             data            
                                   compatibility is                     
                                   also a concern                       

  A structure that  **Critical**   Users dislike adding Some solutions  Ensure MIAME compliance through the use
  supports                         the amount of data   such as         of an adaptive, intelligent, flexible
  MIAME-compliant                  necessary to ensure  maxdLoad from   tool that enforces data compliance,
  experimental                     MIAME compliance,    EBI offer a     makes uploading less error-prone, and
  annotations in a                 potential cause for  Java app that   provides the user with enough feedback
  user-firendly                    retrenchment of      forces the user to make the process painless BUT NOT
  manner                           experiments;         to input all    required.
                                   application that     MIAME fields.   
                                   forces user to input ArrayAnalyzer   
                                   MIAME is not         from Insightful 
                                   designed yet         does not allow  
                                                        analysis to     
                                                        continue until  
                                                        the user inputs 
                                                        all MIAME       
                                                        fields          

  Link array data   **Critical**   High variability in  Hand entry      Design an attribute set that is
  to clinical                      the quality,         without         suggested, but not required, for any
  sample Attributes                accessibility and    restriction     sample
                                   format of the data                   

  Balance the need  **Critical**   Need to be           Organization of Support data ownership by Principal
  for privacy of                   representative of    public versus   Investigator and have granular,
  experiment data                  diverse methods of   private         ever-expanding levels of public exposure
  with the need for                institutional        experiment by   
  expansive                        organization and     way of group    
  collaboration                    ensure that the PI's assignments     
                                   know what data is                    
                                   being exposed                        

  Support multiple  **Critical**   Determining how to   Various -- from Don't support the service variations or
  types of                         incorporate and      paper to home   do support it but make it a configurable
  experiments                      validate the data    grown LIMS      items that would allow for Core labs to
  including those                  they do have and                     set up service arrangements that would
  that have already                degree of difficulty                 roughly increase or decrease the amount
  done most of the                 vs. value of working                 of data to be entered.
  experiment                       to allow this "pick                  
  outside of the                   your service"                        
  Array lab and                    portion of the                       
  just bring the                   workflow                             
  lab chips to be                                                       
  analyzed                                                              

  Store ancillary   **Critical**   Increases the amount Upload of       These files can be stored without
  information such                 of data to be        individual      parsing so they are available for
  as images                        stored, not          files (i.e.,    downloading
                                   particularly         .dat)           
                                   valuable outside of                  
                                   completeness of the                  
                                   data produced by the                 
                                   experiments                          

  Be informed of    **Medium**     Workflow may not be  A balance       Genericize a workflow that can be
  state of the                     common across labs   between looking extended. Worth investigating whether
  experiment's                     or techniques. This  at a lab        the creation of an experiment should
  execution                        is a new feature     notebook and    begin with the type of experiment it is
                                   that should be       manually        which would drive the unique thread(s)
                                   validated.           inspecting a    of the otherwise generic workflow
                                                        series of web   
                                                        pages related   
                                                        to an           
                                                        experiment      

  Scientists        **Medium**     May need to support  No ability in   Allow for the experiment sample
  require a series                 multiple formats to  caArray -       structure to be downloaded (as
  of points in the                 make this effective  ranges from     placeholders for the deposition of array
  process where                    for importing into   printing out    data); allow for the extraction and
  array annotation                 other systems        data and        download of experiment structure and
  data can be                      (MAGE-ML,            re-entering it  annotation in the format of the user's
  downloaded at the                comma-delimited txt  into additional choice.
  current state.                   files)               software        
                                                        packages,       
                                                        placing data on 
                                                        ftp sites or    
                                                        burning cds     

  Store analysis    **Medium**     annotation of the    Desktops,       Enable the annotation of analysis
  results                          analysis factors     LAN's, FTP      parameters and offer the ability to
                                   used needs to be     sites and the   upload files on a per-parameter set
                                   provided             "other"         basis. Potentially set a size limit on a
                                                        category of     "exeperiment/project" based on the
                                                        current caArray platform and number of samples to
                                                        applet upload   control size and don't allow versioning
                                                                        of the data

  There is          **Medium**     Corrupt data can be  None            "Quarantine" data when it is submitted
  currently no way                 loaded into caArray,                 to caArray. A curator must review and
  to enforce the                   compromising the                     approve the data before it is persisted.
  integrity of data                overall integrity of                 
  in caArray                       the database                         

  Document Quality  **Medium**     Will need a UI to    Not done, by    Provide features for sorting, global
  Control measures                 support QC           hand in a lab   selections, all
  on a sample by                   annotations for      notebook, excel 
  sample basis to                  small and large                      
  support data                     numbers of samples                   
  analysis and                     in a given                           
  reuse                            experiment                           

  Store Data in the **Medium**     Applications are in  caBIG is the    When possible and practical, look to
  appropriate                      various stages of    attempt         access vs acquire data and harmonize the
  application that                 maturity with a high                 data elements at key touchpoints
  corresponds to                   degree of divergence                 
  the kind of data                                                      
  it is (e.g.,                                                          
  tissue data                                                           
  belongs in                                                            
  caTissue)                                                             

  Make Analysis     **Medium**     A little knowledge   μAD-B,          Increase the ability to organize and
  Accessible to a                  can be dangerous and commercial      format the data to be exposed to the
  larger portion of                cause less           products for    analysis tools and seek to transmit just
  the user                         productive           simple analysis the data necessary to increase speed.
  community                        discussions than a                   Potentially integrate less sophisticated
                                   show and tell                        analysis tools directly into caArray.
                                   performed by the                     
                                   biostatistician                      

  Ability to        **Medium**     A significant amount No solution     Quarantine data upon initial upload and
  maintain a high                  of compromised data  exists          inspect through curation before making
  quality data                     is submitted to                      it available
  repository at                    NCICB                                
  NCICB                                                                 

  Access Current    **Low**        Issues surrounding   No solution     Store the gene annotation ids from caBIO
  Gene Annotation                  versioning, storing  exists          
  and understand                   the gene annotation                  
  the difference                   in multiple places,                  
  between when the                 usability burdens on                 
  experiment's data                representing the                     
  was produced and                 distinct annotations                 
  the time it is                                                        
  being accessed                                                        
  --------------------------------------------------------------------------------------------------------------

## Alternatives and Competition

Since the initial deployment of caArray in January 2003, several
applications have extended their reach and capabilities serving a very
similar, if not the same audience. Tbale 7 outlines how caArray will be
positioned relative to its non-commercial competitors.

Table 6 Alternate Solutions

  ----------------------------------------------------------------------------------------------
  Alternative                            Why caArray              What can we benefit from that
                                                                  they do well
  -------------------------------------- ------------------------ ------------------------------
  Gene Expression Omnibus (GEO):         Initially, quality over  Easy interface to upload data
  <http://www.ncbi.nlm.nih.gov/geo/>     quantity. While the      leading to their current
                                         amount of data in GEO is status as the defacto
                                         unsurpassed, the ability repository for microarray
                                         to find quality data     data. Provides unique but
                                         (including the           short accession numbers for
                                         attribution needed to    each sample which is used to
                                         determine its value) is  prove data has been placed in
                                         difficult. Next, is the  a public repository for
                                         transparent access to    publication purposes.
                                         analysis tools and       
                                         retrieval of meaningful  
                                         results.                 

  ArrayExpress:                          caArray is open-source   Simple query interface against
  <http://www.ebi.ac.uk/arrayexpress/>   and caBIG-compliant.     a small number of concepts on
                                                                  the home page, RSS feeds,
                                                                  indications of how many
                                                                  experiments are available, can
                                                                  query against a gene name

  Stanford Microarray Database (SMD:     Not an open-development, Statistical analysis available
  <http://genome-www5.stanford.edu//>)   open source project, not directly in the systems;
                                         caBIG compliant          storage of gene lists, query
                                                                  by gene
  ----------------------------------------------------------------------------------------------

# Product Overview

caArray is associated with the Integrative Cancer Research Workspace
(ICR) that falls under the caBIG™ umbrella.

## Product Perspective

![](media/image8.wmf)

Conceptual positioning of caArray in integrative cancer research

## Assumptions and Dependencies

### Only terms from Managed Ontology systems will be available

Whenever a controlled vocabulary is appropriate for user-based entry,
the system will allow for the use of terms from the NCI Enterprise
Vocabulary Service. If terms are not found, then the data can be saved
but will be placed in the queue of the installation's curator for
submission to the EVS.

## Cost and Pricing

There is no cost to the user community in terms of purchasing a license
for caArray. However, there is a cost in terms of time and energy spent
in supporting the product and its evolution, the server(s) and
potentially the use of commercial tools such as Oracle to replace the
open source database of choice - MySQL.

## Licensing and Installation

Following the principles of caBIG of Federation, Open-Development,
Open-Access, and Open Source, the source code is available to view,
alter, and redistribute however a consumer chooses to do so. The license
agreement is available from the NCICB download center:
<http://ncicb.nci.nih.gov/download/caarraylicenseagreement.jsp>.

# Product Features

With priority set by the Product Manager, with input from all
stakeholders, the following features represent the functional aspects of
the caArray. All features are not created equal, particularly when
having to deal with constraints such as time, budget and level of
effort. Ranking requirements by their relative benefit to the end user
opens a dialogue with customers, analysts and members of the development
team. This feature set and the relative priority will be used to manage
scope and determining development priority.

Table 7. Feature Priority Attributes

  --------- -------------------------------------------------------------
  High      Essential features. Failure to implement means the system
            will not meet customer needs. All critical features must be
            implemented in the release or the schedule will slip.

  Medium    Features important to the effectiveness and efficiency of the
            system for most applications. The functionality cannot be
            easily provided in some other way. Lack of inclusion of a
            required feature may affect customer or user satisfaction,
            but release will not be delayed due to lack of any required
            feature.

  Low       Useful features that are anticipated to be used less
            frequently, or for which reasonably efficient workarounds can
            be achieved. No significant customer satisfaction impact can
            be expected if such an item is not included in a release.
  --------- -------------------------------------------------------------

## Experiment Management

**Overall Priority: Medium**

### Propose an Experiment 

**Priority:** Medium

To support the collaboration between a Principal Investigator and the
lab that serves them, the ability to propose an experiment that will
contain a set of required, suggested (e.g., strongly encouraged), and
truly optional annotation data that describes in sufficient detail the
experiment desired, the platform to be used and the samples to be sent.

#### Save as Draft

**Priority:** Medium

The ability to save the work entered during a given session by an
investigator as long as a minimum set of information has been entered
and is unique enough to be stored discreetly.

### Review an Experiment

**Priority:** Medium

Once an experiment has been submitted, the ability to take action and
communicate with the submitting investigator is expected. The action can
take three forms:

-   Accept a Experiment -- moves the experiment forward and includes the
    ability to establish a price and assign staff (scientists and
    biostatisticians)

-   Reject a Experiment -- an irrevocable action that places the
    experiment back in the queue of the submitter, who may then choose
    to hide the rejected experiment.

-   Return a Experiment for Revision -- sends the experiment back in the
    investigator's queue

#### Inform Experiment Submitter of Activity

**Priority:** Medium

In addition, the ability to enter, automatically transmit via email from
the application and retain experiment notes submitted should be easily
navigable from the experiment's "home page. If a researcher acts on
behalf of a Principal Investigator, both users will be informed.

#### Allow Principal Investigators or their designees to submit Experiments

**Priority:** Medium

Any user with a Principal Investigator role will be able to submit
experiments and become the logical "owner" of the experiment. The
Principal Investigator will also be able to associate users to their
research lab to allow other users to submit experiments on their behalf.

#### Restrict Experiment Submission based on Required Experiment Annotation

**Priority:** Medium

The ability to submit a proposed experiment must be restricted by
requiring the following set of information to be entered using an
interactive web form by a Principal Investigator or their designee:

The **Principal Investigator** and the contact information

A **Experiment Synopsis** that details the high level aspects of the
experiment that will drive succeeding data entry and/or upload options.
This will include the kind of experiment it is (genotyping, gene
expression, etc.) array platform of choice, the source of funding, the
species, organ/tissue type, organ region, cell type, disease or
condition being studied, the number of replicates, whether pooled
samples are being used, the type of samples being submitted (e.g., total
RNA), and the total number of samples expected.

The **Experimental Design** that will include the experiment type (time
series, pharmacogenomic, subclassification, etc.), the relevance of the
study, hypothesis, specific aim, experimental procedures and factors.

The **Sources** which will be a derived from the synopsis but with
additional characteristics that will correspond to the type of
experiment it is (e.g., human will require sex). Common properties would
be a name and description, strain, developmental stage, genetic
variation, genotype or mutation status, and age.

The **Samples**, which will also be derived from the synopsis but will
require a bio-source and additional characteristics such as a name and
description, the amount (volume or weight), and any treatment
information.

Additional information that covers extractions and array designs would
be made available (to support those investigators who will perform most
activity in their own lab and use the Core Facility to run the labeled
extracts or just do analysis) but not required.

#### Copy a Previous Experiment's Annotation

**Priority:** Low

The ability for an Investigator to select one of their experiments for
copying into a new experiment will be made available. The copy feature
will only apply to the annotation for the investigator, experiment
synopsis and experimental design.

### Transfer Experiment Ownership

**Priority:** Low

Experiments and the objects that make them up in caArray are owned by
individual users. To prevent a situation where a user is no longer
active, the current owner or a system administrator can transfer the
ownership to an active member.

### Cascading Control of Experiment or Sample Visibility

**Priority:** High

The ability to control the public visibility of an experiment must be
controlled by the Principal Investigator or their designee. The actions
can be taken against a experiment as a whole (with a cascading affect
down all experiment elements) or an individual or set of samples within
a experiment (with no cascading affect). Depending on the organization
of an Institution, the ability to set the visibility to all within the
institution, a self created group of collaborators, a known group (such
as a SPORE) or completely public (allowing for anonymous browsing)
should be available.

### Control Experiment or Sample Permissions

**Priority:** High

The ability to control the permissions at a experiment or sample level
is expected. Similar to the visibility feature -- which makes the
experiment or samples read-only, this feature will allow for read, write
and no permissions to be extended to labs, institutions, groups or the
public. Editing will not be allowed when making a experiment or samples
public at the highest level. Otherwise, all permissions are allowable.

### Provide an Legible and Accessible Experiment name and URL

**Priority:** High

Each experiment, as soon as it is saved as a draft, must have an
automated name and reflective URL associated to the experiment. A
potential pattern for name generation is as follows:

Principal Investigator Last Name-Autonumber which will be truncated to
the first 5 characters of each particular attribute.

An example would be: klemm- 89765. The name produced would be directly
represented in the URL. No matter the state of the experiment's
visibility, if a user has permission (unless it's public -- where
permission is unnecessary) the URL can be directly entered into a web
browser and the experiment pulled up. This is particularly useful when
trying to indicate where the data is and may suffice for publication if
the installation is outside of the firewall. The brevity and legibility
will also help to discern what the experiment is, while at the same
time, the auto-generation of the number helps offset concerns of hacking
the URL.

### Support Multiple Types of Array Services 

**Priority:** Medium

Across the community, there are three main kinds of services requested
and are categorized as complete, partial, or analysis services. The
challenge with the latter two is to ensure that the requisite
annotations are properly acquired and uploaded into caArray.

#### Complete Service

**Priority:** Medium

This service supports the complete set of activities from the receipt of
source material (samples) where the lab prepares the RNA, runs the
experiment and performs the data analysis

#### Partial Service

**Priority:** Medium

This service allows for the submission of labeled extracts to be run
through hybridization and data analysis

#### Analysis Service 

**Priority:** Medium

This service is invoked when the requesting researcher has already
performed all the effort to produce the raw data and just wants to have
the data analyzed.

### Associate Publications to Experiments

**Priority:** Medium

The ability to create, edit and delete publications, indicate their
state (published, in press, in preparation) and associate them to
specific experiments is desired. Additional publication types --
abstracts, talks and reference materials -- would also be available. The
standard format for citations would be followed with the ability to
create hyperlinks to the paper and open the experiment from a listing of
publications as well as open the publication from the experiment. In
addition, the ability to auto-populate citation information (volume,
page number, etc.) based on PubMed ID would be available.

## Array Annotation and Data Management

**Overall Priority:** High

These features describe the essential functions required to populate and
maintain array experiment annotation and data -- an essential and
primary purpose for the system. To support finding data of interest for
any user, the ability to annotate the data clearly and consistently is
required. Any descriptive experiment elements that support and/or
identify arrays are considered "annotations." "Arrays" are the data
produced by the experiment. Annotations, therefore, are used to describe
the following:

Project -- a set of experiments

Experiment

Person

Organization

Protocol

Array Design

Source

Sample

Details of these elements will be found in the Domain Model in the Use
Case Summary and the Data Model associated with the Software
Architecture Document.

### Source and Sample Annotation

**Priority:** High

#### Acquire Source Annotation from External Source

The general ability to acquire tissue annotation from an external source
is desired. Whether through navigation of caTissue directly in caArray
or The minimum set of annotation to support MIAME will be exposed so
that the data pulled in will conform to the standard and allow for
expedient searching of caArray as a portion of the data will be moved.
Non-caTissue repositories that contain the information could also be
used -- though their integration is not directly supported by caArray
through the user interface.

#### Allow for an Institutional Id to be entered

**Priority:** High

When annotating a source or sample, allow for an institutional id to be
entered to support relationships back to de-identified clinical data.
While a unique id is expected to be generated by caArray, this
additional id allows for the opportunity to connect to other
repositories of additional information that local users would have
access to -- directly or indirectly from caArray.

#### Allow for Clinical Annotation to be entered

**Priority:** High

Although there is a set minimum of information to be entered, the system
should support the addition of clinical annotation such as treatments
and outcome data to the desired degree on the part of the investigator.
In addition, the ability to do so programmatically is also desired,
though any editing of data consumed by caArray is uni-directional and
not expected to update the other system. This would include details such
as the removal of the stated amount of the sample from the source in the
institutional tissue bank.

#### Share Controls across Experiments

**Priority:** Medium

There are occasions where a control source or sample will be used for
multiple experiments. Therefore, the ability to "re-use" a control
should be available across experiments.

#### Generate Source and Sample Placeholders

**Priority:** Low

When a experiment is created, the users will have the option to enter
the number of sources and samples expected to be in the study and have
the system produce the requisite number of placeholders for data entry.
The characteristics of each will be predicated on the high level
experiment depictions (experiment type, species, tissue type) and will
annotate the name field of each source or sample and distinguishing one
from another by incrementing the number (e.g., source1, source2).

### Annotate Experiments Interactively Using Web Forms

**Priority:** High

The most common method for experiment annotation is expected to be
through a web-based series of forms. In addition to the experiment
definitions, the ability to manage the experiment's bio-source, samples,
extracts and array designs is expected. While the data characteristics
are dependent on the element in question, each significant element
should be enterable through a form.

#### Evaluate MIAME Compliance Per Form

**Priority:** Medium

When entering data in any form or reviewing imported or uploaded data
annotations, the system will provide an option to evaluate the
compliance of the data that has been entered. If the evaluation fails,
the indication of why will include:

-   The element(s) of the MIAME guidelines that produced the failure

-   A link to the full MIAME description

-   And Each instance of what is wrong

However, the system will not enforce the user to fix the error. Rather,
this is simply informational to help users understand what they need to
do in order to fairly state that experiment is supportive of MIAME
compliance. Further, there are some variations of MIAME which should be
adopted for particular experiment types: CGH and ChIP-on-chip. Finally,
Illumina has offered an extension to the MIAME guidelines which they
would like to see adopted -
<http://mged.org/Workgroups/MIAME/Illumina_MIAME.pdf>.

#### Evaluate MIAME Compliance Per Experiment

**Priority:** Medium

When viewing an experiment's initial view, the ability to see at a
glance what elements of the experiment are in compliance with the MIAME
guidelines is required. The summary should include:

-   Array Design Details

-   Experiment Details

-   Sample Detail

-   Hybridization Detail

-   Measurement Detail

A basic indication of whether it is valid or not should be exposed and a
link to the exact cause, a full description and each instance of error
should be provided.

#### Support Extension of MIAME as the guidelines evolve

**Priority:** High

The ability to seamlessly introduce new MIAME elements and wholesale
additions or concepts to the MIAME guidelines should be supported. As
the field expands and new technologies mature, the ability to add new
validation routines should be transparent.

### Import Array Annotations and Data

**Overall Priority:** High

Users will be able to submit array data by importing data files in
formats known to caArray. Annotations associated with this data will be
submitted though file-based methods or through a form-based graphical
user interface as described above. The submission process can either be
incremental (e.g., a file at a time) or a complete set of data.

#### Import existing array data on a sample by sample basis

**Priority:** High

The ability to select one or more pre-existing data files located on any
user's local hard-drive, local access network or locally available media
(e.g., a CD, DVD, or external hard drive) for system-specified array
designs needs be supported. The array data will correlate to a
pre-existing sample available in caArray. The array design plus the
version of the design needs to be selected in order for this to succeed.

#### Import existing array data across samples

**Priority:** High

The ability to select a **set** of one or more pre-existing files
located on any user's local hard-drive, local access network or locally
available media (e.g., a CD, DVD, or external hard drive) for
system-specified array designs needs be supported. The array data will
correlate to existing samples and the ability to choose which
pre-existing files go with each sample must be available. The array
design plus the version of the design needs to be selected in order for
this to succeed.

#### Import existing array data without existing samples

**Priority:** High

The ability to upload a set or a single array data file into a
experiment without pre-existing sample definitions needs to be
available. The system will automatically create sample definitions or
"placeholders" based on the names of the files, however, the source of
each sample may need to be manually entered and the sample array data
uploaded will need to be associated to the source.

#### Import existing annotations from files

**Priority:** High

Array annotation is available in a variety of independent files.
MAGE-TAB is one source of annotation that is gaining popularity. Support
for MAGE-TAB files is under consideration. In addition, other file
formats contain annotations, particularly from commercial vendors (e.g.,
Affymetrix's .chp file). The list of supported annotation files are
found in the Supplemental Requirements: Annotation Files.

#### Upload Supplemental and Private Documents

**Priority:** Medium

In addition to annotations and data, the ability to manage (e.g., add,
replace, delete) documents such as spreadsheets, images, and word
documents should be available. These documents would be attached at the
experiment level and could be made public or private (only available to
a lab, institution, group or collaborator). The initial assumption is
that they are private to the Lab and the PI.

#### Import array annotation and array data from other repositories

**Priority:** Low

The ability to select complete experiment annotation and data from other
repositories is desired. The initial target is the EBI's Array Express
whose data is considered of high quality.

#### Establish Integration with other repositories

**Priority:** Low

The ability to exchange data with other repositories, particularly EBI's
ArrayExpress, is desired. This would allow the automatic transmission of
data from one repository to another. An alternative, also deferred,
approach, would be to allow the searching of one repository's data from
another.

### Validate Data

**Priority:** High

The ability to validate the format and completeness (not the scientific
contents) of the array files being imported is required. The expected
formats vary per manufacturer (e.g., Affymetrix vs. Illumina) or
standard (e.g., MAGE-ML, MAGE-TAB). In order to validate, the user must
select the array design that the file corresponds to with the design and
the system should indicate if the file or set of files meet the
expectations of the platform and design.

### Parse Data

**Priority:** High

The ability to parse particular data files that contain values of
interest -- for example, expression levels on a per gene basis -- is
required to support granular searching of data and to serve out data in
a platform-independent format. Which file and what values are dependent
on the experiment type and manufacturer. The relationship between
manufacturer, data file and values will be described in the Software
Architecture Document.

### Maintain Annotations and Array Data

**Priority:** High

Maintenance is defined as the ability to edit, replace and delete
annotations or data as distinguished from Management, which explicitly
allows for the ability to create in addition to the actions of
maintenance.

#### Edit Annotations

**Priority:** High

For any annotation element in a experiment, the ability to edit those
annotations by the data owner or those associated with the data owner is
required. While the Principal Investigator is the ultimate data owner,
the elements of the execution workflow that are directed to distinct
roles will allow those assigned to the task to edit the annotations.

#### Restrict Experiment editing once a Paper has been published

**Priority:** Deferred

An experiment will become read only once a manuscript has been published
and associated with the experiment. Additions can be made, such as new
samples or uploading of additional supplemental files.

#### Replace Array Data

**Priority:** High

The ability to change array data by importing/uploading a new file in
place of an existing file is required. Versioning of the files, however,
is not expected or required.

#### Delete Annotations and Array Data

**Priority:** High

Any unassociated annotation can be deleted. This would allow for samples
not associated with array data, for example, to be removed, or to delete
array data files if uploaded in error.

#### Copy, Edit and Delete Experiment Annotations at a Glance

**Priority:** High

Entering source and particularly sample annotations are often time
consuming. To offset that cumbersome activity, the ability to enter one
and copy it as many times as desired should be supported. This should be
allowed to be done for any one significant entity -- source, sample,
extracts and arrays. In addition, any one of the entities could be
edited from the initial page and provide for more extensive editing in a
separate page if necessary. Finally, the ability to delete an entity
should be efficiently done directly on screen, rather than having to
drill down several layers to get to the element desired.

## Array Design Management

**Overall Priority: High**

### Pre-load Array Designs

**Priority:** High

At the time of any release, the ability to provide array designs
pre-loaded and annotated into the system is desired. The list of array
designs supported is maintained in the Supplementary Specifications:
Array Designs and will be visible within the application itself. A
validation that the array design doesn't already exist in a local
installation's library will need to be present in the upgrade script.

### Import Array Design

**Priority:** High

For any array design that isn't already available, the ability to add an
array design to the system is required. Once the design has been
uploaded, the ability to load data files corresponding to the design
will be available and allowed to be parsed.

## Extraction

**Overall Priority:** High

One of the critical values that caArray must bring to the community is
the ability to find and use the content of the repository to serve
multiple, meaningful functions.

### Export Experiment to Standard Formats

**Priority:** Medium

Export of experiment data to standard formats will be supported -
current candidates include MAGE-ML, MAGE-TAB, and additional standards
that become recognized in the community. The standards decided upon will
be explicitly added in the Supplementary Specification: Export Formats.

### Submit Experiment to GEO or ArrayExpress

**Priority:** Low

The ability to select a experiment and choose the repository for data
submission is required. When the experiment is intended for GEO, the
system needs to create an appropriate SOFT file for the user to upload
to GEO. Array Express can consume a MAGE-ML file so that ability to
produce a MAGE-ML File representing an entire experiment is also
expected.

### Retrieve Complete Data Matrix as a comma or tag delimited file

**Priority:** High

Essentially the desire is to acquire a spreadsheet of data from the
repository that represents the expression data for a experiment
(rows=reporter values; columns=samples). This would include references
to the raw file via a system-generated URL.

### Retrieve Partial Data Matrix as a file

**Priority:** High

There is occasion for the user community to only want to select a subset
of the data for a given experiment(s). Tied to the general Search
features, this specifically refers to the ability to:

-   select from a list of arrays (with a "select all" or "select some"
    option)

-   selecting the interesting quantitation type for each array; example
    -- signal, S/N, probeid

-   Searching for a sample of interest

In addition, the overall desire is to be able to review the subset of
data and make changes to the query that produces prior to downloading
the data matrix -- versus having to download the data in order to see
the result.

### Retrieve data in native (manufacturer) format

**Priority:** High

The ability to find and download all raw experiment data or a subset of
available array data is required. The search mechanism would allow for
common selection methods that support the selection of all items found
or the de-selection of particular items in the list and the choice of
data format to be downloaded by file extension.

### Retrieve annotations and array data through an API

**Priority:** High

A key feature of caArray is the ability to access data through a
caBIG-compliant application programming interface. The existing caArray
MAGE-OM API provides this capability but is highly complex and requires
users to have an intimate knowledge of the MAGE model. It is a
requirement that a less complex API be provided for access to data
within caArray. For the NCICB instance of caArray, this API must be
grid-enabled. The requirement for also maintaining a MAGE-OM API is TBD.

## System Administration

**Overall Priority:** High

### Add a User

**Priority:** High

The ability to add a unique user, assign a role or multiple roles, and
the institution they belong to should be made available to the System
Administrator. Common validation checks should be performed to thwart
potential duplicates being introduced.

### Edit a User

**Priority:** High

An individual user or a system administrator should be allowed to edit
their demographic characteristics. If a user changes Institutions and
still has active experiments, the System Administrator can decide if the
user can continue to have access to the local installation.

### Delete user

**Priority:** High

The System Administrator can delete users who have not been associated
with an experiment. The user is completely removed and will no longer
have any restricted access privileges.

### Disable a User

**Priority:** High

The System Administrator, Lab Administrator or Principal Investigator
can disable a user's privileges. They can reinstate the user's
privileges at a later time but when disabled, the user is no longer able
to neither view restricted portions of the site nor be assigned to
workflow tasks.

### Manage Collaboration Groups

**Priority:** High

Any registered user can create, edit, or delete groups outside or within
their home institution to allow for other registered users to
participate with experiments that are otherwise restricted to their lab,
institution, or group.

### Provide Configurable, System Generated Email

**Priority:** Low

Using a set of templates, allow for the customization of generic emails
at given points in the process. This would include a welcome message for
newly registered users, the experiment approval decisions, and
indications when a experiment has moved from additional state
progressions.

### Provide for Customization of Installations

**Priority:** Deferred

The ability to easily indicate the location of a particular caArray
installation by adding a text or graphic logo is desired. In addition,
the ability to add html pages into the framework of caArray to support
custom instructions and other information should be possible.

## Curate Annotation 

**Overall Priority:** Low

### Edit Ontological Values through a Single View

**Priority:** Low

The ability to view the lists of common terms and definitions, from
protocols to file types to array designs from a single page and be able
to edit or add to the values from a single view should be supported.
While the NCI's Enterprise Vocabulary System is the vocabulary authority
and will provide the categorical definition, the values or details of a
particular definition will be different from lab to lab. To curate the
data definitions, the ability to edit an entry performed by a user and
have the update cascade throughout the system is required.

### Edit Ontological Values during Annotation of a Experiment

**Priority:** Low

In addition to the single view held by a curator, the ability to select
controlled vocabulary terms and definitions should be supported. If a
user edits the details of a term, the ability to save it and have it
cascade throughout the local instance is required.

### Add Vocabulary Term

**Priority:** Low

The ability to add an entry to the vocabulary at any local instance
should be supported though the process for getting it accepted in EVS is
distinct. This feature will support timely execution of a experiment but
it should be an infrequent event where a new term is necessary. All new
terms will need to have a category, value and description, potentially
specific properties and database data.

### Manage Terms Added by Users

**Priority:** Low

Across the local installation, the ability to see any new terms that
have been entered should be available to support the acceptance,
rejection or re-assignment of those terms along with the ability to mark
the action taken. For new terms that fall outside of the EVS, the
ability to submit the terms to the EVS for approval should be supported.

## Navigation and Search

**Overall Priority:** High

### Inventory of Summary Repository Statistics

**Priority:** High

The ability to see from the home page of caArray, a dashboard-like
summary of overall statistics for any installation is required. This
would be broken out by a local installation and all installations
available on the Grid, allowing the user to switch between views. The
"home" institution will be shown first, with the ability to switch to
any installation that is available across the grid. This would support
quick navigation to experiments by experiment state, platforms,
experiment types, species and publications by choosing the numeric link
corresponding to the item of interest which would produce a list of
respective experiments. Graphical representation of summary data is also
desired. All data should be represented, though only public data can be
searched. This is the only place in the application that goes against
the principle of showing only what a given user has rights to see.

### Search Public Data

**Priority:** High

In addition to the inventory summary, any experiment data that has been
made public should have a finer-grained search capability. High level
searches for experiments, hardware, software, arrays, array designs,
sources, samples, and labeled extracts would be available on a per
installation basis, and have content appropriate values related to the
type of search to be executed. In addition, the search should lead the
user to results by only showing data attributes that will produce a
result as much as possible.

#### Anonymous Browsing

**Priority:** High

> The ability to search public data should be available without
> requiring the individual user or external application to have a
> registered account.

### Search Restricted Data

**Priority:** High

The same search mechanism that applies to public data will also apply to
experiment data that has restricted visibility Only the experiment data
that a user has access to will be made available, following the general
principal of show users what they have rights to, not what they don't.

### Search Categories and Result Actions

**Priority:** High

The ability to query the repository for data one has access to can occur
in the following manner:

-   Natural text search against a discrete set of commonly referenced
    annotation values. (NOTE: analogous the iTunes search.)

-   May also use appropriate ontology categories (where appropriate) to
    support searches by:

    -   Disease

    -   Tissue type

    -   Species

    -   Array design

    -   Investigator

    -   Submission date

    -   "Accession number" of a experiment

    -   Identifiers of sources, samples, array design, investigators,
        species

All search results should allow user to export associated data or other
actions corresponding to the search executed. For example, a search
against a disease type will produce a set of experiments referencing the
disease type. The ability to download all or some of the experiments
data should be available as well as independent inspection of any given
experiment selected.

### Query Genes Across the Repository

**Priority:** Low

Once the data is stored and annotated appropriately, the ability to
query a single gene across common tissues or treatments within one's own
experiment or against available experiments. The intent would be to
retrieve experiments or samples that contain arrays that contain
information about the gene or genes of interest given a particular
value.

### Actionable Search Results

**Priority:** High

For any search performed, the ability to perform actions in context of
the search should be available. These will range from links to more
information, downloading or exporting of the results, saving the result
or portions of the result to virtual experiments or other organizing
mechanisms.

### Provide Experiment Workspace

**Priority:** High

For those users involved in any aspect of the workflow of a experiment,
a workspace that shows all experiments they are associated with to be
immediately available (a two-click maximum. Whether they propose the
experiment as a Principal Investigator, or are assigned work by a Lab
Administrator, the experiment will be placed in their queue with the
state of the experiment exposed and the respective actions available.
Once a experiment is public, it is removed from their queue but still
available to the user. This feature is provided automatically based on
the role the user has and can not be altered by the user.

### User-Directed Organization of Repository Information

**Priority:** High

All registered users should have the ability to place information they
care to access frequently and easily into logical folders of their
choosing. For example, a folder can represent a category of its contents
(for example, "My Queries", "My Virtual Experiments"). Additionally,
folders can contain other folders (leading to a hierarchical
organization). It is assumed that putting something in a folder does not
physically copy the item, but instead simply refers to it. This will
permit inexpensive organization and also reduce fears of mistakenly
deleting something of value.

#### Default Organization

**Priority:** High

The default organization of 'folders" should support a experiment
workspace, virtual experiments, and independent organization of favorite
samples, queries and genes.

#### Manage Virtual Experiments

**Priority:** High

The ability to create, edit or delete a "virtual" experiment that will
allow for sources and samples to be pulled from real experiment data
should be supported. The population of the experiment will likely come
from search results, but may also be derived from actions taken on an
open experiment, where, for example, a particular sample is of interest
to the user. A limited set of actions available to a real experiment
will be available to the user -- primarily the ability to download the
data or send to the analysis tools.

#### Save Queries

**Priority:** Medium

The ability for any registered user who creates a query with at least
one attribute/parameter selected and/or entered to save the query for
future use. The query must be named and within a user's set of queries,
be unique.

#### Update Queries

**Priority:** Medium

Supports the ability to select a user's saved queries, change the
parameters and save it again for future use. There is no expectation of
versioning of queries though a user may choose to save a query with a
new name and the system should show when the query of interest was last
run.

#### Re-Run Queries and represent what's new

**Priority:** Low

The user would be able to choose to run a saved query and indicate that
the results of interest should be restricted to only those that have
appeared since the last time the query was run by the user (or not).

#### Share Queries

**Priority:** Deferred

The ability to expose a query to another user and/or set of users is
desired. Some of the queries may take significant time to
develop/curate, therefore this feature would help share the results of
that burden. It is TBD where there should be ownership of the query or
referential integrity.

#### Paginate Query Results

**Priority:** High

For result sets that span 25 or more items, the ability to show the
total number of results and paginate the results in 25 entity increments
should be supported. In addition, the ability to navigate to any one
page of results should be available.