**caGrid Requirements Pertaining to Interoperability:**

**Implications for caBIG Compatibility Criteria and Reuse**

Robert R. Freimuth, Ph.D., Mayo Clinic

Scott Oster, M.S., Ohio State University

September 15, 2008

Version 0.1

**Table of Contents**

Introduction [3](#introduction)

Purpose [3](#purpose)

Background [3](#background)

Interoperability Requirements [4](#interoperability-requirements)

Applications with Silver Level APIs
[4](#applications-with-silver-level-apis)

Grid-Enabled Applications [5](#grid-enabled-applications)

Implications for Compatibility Criteria and Reuse
[7](#implications-for-compatibility-criteria-and-reuse)

Silver Level Criteria [7](#silver-level-criteria)

Gold Level Criteria [7](#gold-level-criteria)

Creation of Harmonized Domain Models
[7](#creation-of-harmonized-domain-models)

Recommendations [8](#recommendations)

Conclusions [10](#conclusions)

Appendix: Interoperability Use Cases
[11](#appendix-interoperability-use-cases)

# Introduction

## Purpose

This document summarizes the requirements related to interoperability
that are imposed by the caGrid infrastructure. Specifically, this
document describes how the way XML schemas are utilized on caGrid
relates to the caBIG™ Silver and Gold Level compatibility criteria, and
the impact it has on both UML model and common data element (CDE) reuse.

## Background

Interoperability is a key requirement for sharing data among
applications, and as a result caBIG places a special emphasis on
syntactic and semantic interoperability. The caBIG community developed
and published a document (\"caBIG Compatibility Guidelines\") that
provides basic definitions and compatibility guidelines in the areas
of 1) information models, 2) common data elements, 3)
vocabularies/terminologies and ontologies, and 4) programming and
messaging interfaces[^1]. That document also defines different levels of
syntactic and semantic interoperability in caBIG. In order of increasing
stringency and requirements, these levels are Bronze, Silver and Gold.
Each level builds on the previous level, so the requirements for Gold
level include all of the requirements specified for Silver level.

The Guidelines document forms the basis for the specific compatibility
criteria that are used to evaluate applications for caBIG compatibility.
The compatibility requirements for Bronze level applications are
relatively low and are intended to serve as a stepping stone for
applications to reach Silver Level. The criteria for Silver Level is
well established and, in general, emphasizes accurate semantic
annotation of data elements and complete documentation of application
programming interfaces (APIs)[^2]. The criteria for Gold Level are
currently being defined by a working group and are available in draft
form[^3]. At Gold level, applications are required to meet additional
standards for UML model harmonization, reuse of CDEs, and registration
of the application and metadata on caGrid.

During the creation of the Gold Level criteria it was observed that some
of the requirements for the harmonization and reuse of information
models and CDEs conflicted with how direct interoperability in the
caGrid infrastructure is achieved (i.e. programmatic integration without
translation), and specifically with how XML schemas are utilized. This
document describes the nature of those conflicts and discusses their
implications on the compatibility criteria.

# Interoperability Requirements

In order for two applications to exchange information they must be both
semantically and syntactically interoperable. The method by which
semantic interoperability is assured is common to all Silver and Gold
level applications, but the specification of syntax differs depending on
whether the application exposes a Silver level API or whether it is a
\"grid-enabled\" Silver or Gold level application that utilizes the
caGrid for information exchange.

## Applications with Silver Level APIs

> **[Semantic Requirements]{.underline}**: All Silver and Gold level
> applications register CDEs in the caDSR for each attribute in the UML
> model. Each CDE is semantically annotated using terms from controlled
> vocabularies that have been approved for use by the Vocabularies and
> Common Data Elements workspace. Therefore, CDEs provide semantic
> meaning to attributes in UML models.
>
> **[Syntactic Requirements]{.underline}**: The syntax for applications
> that expose Silver Level APIs is defined by the programming language
> used to create the API. Methods exposed by the API accept as
> parameters and return objects composed of individual CDEs.

Most applications that have been certified as being caBIG-compatible
expose a Silver level API. For two Silver level applications to
interoperate semantically they must use the same CDEs for input and
output, but since those objects are utilized independently from one
another the extent of interoperability between the applications is
determined only by how many CDEs they have in common. For applications
with Silver level APIs to interoperate directly syntactically, they must
use the exact same libraries; messaging systems must use the exact same
messages and technologies to exchange those messages. See Example 1.

![](media/image1.wmf){width="3.3318897637795275in"
height="2.6653543307086616in"}

Example 1: Interoperability between two applications that have Silver
level APIs. A query of Model 1 returns instances of A.foo, which can be
joined with instances of A.foo from Model 2 and passed to method
foozle().

[]{.mark}

## Grid-Enabled Applications

> **[Semantic Requirements]{.underline}**: The semantic requirements for
> grid-enabled applications are the same as those for applications that
> expose Silver level APIs.
>
> **[Syntactic Requirements]{.underline}**: The syntax for grid-enabled
> Silver level applications and for Gold level applications is defined
> by one or more XML schemas that are registered in the Global Model
> Exchange (GME). The schemas contain structural definitions of the XML
> representation of all of the classes, attributes, and associations in
> the UML model, and thereby define the syntax for data exchange for the
> application.

As for Silver level APIs, grid-enabled applications must use the same
CDEs to ensure semantic interoperability. The syntax requirements for
grid-enabled applications are much more stringent than they are for
Silver level APIs, however.

Grid-enabled applications (either Silver or Gold level) exchange
information using defined XML schemas, which allow applications written
in different programming languages to interoperate (provided they use
the same schema). These XML schemas include a complete description of
the UML model, including all classes, attributes, and associations.
*Therefore, grid-enabled applications must reuse entire models to
directly interoperate without translation; reusing individual CDEs or
even portions of highly-connected models is not sufficient*.

Specifically, when a given element of a model is reused then all
portions of the model that are referenced by (associated with) that
element must also be reused in their entirety (Example 2). Furthermore,
a portion of a model can only be reused in isolation as long as that
portion does not reference another portion that is not reused.
Therefore, the practice of creating fully connected models where all
associations are bidirectional ultimately results in a situation where
reusing any portion of the model requires reusing the entire model. On
the other hand, if subgraphs of the model were isolated from each other
through the use of unidirectional associations, then those portions
could be reused independently.

[]{.mark}

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

  ----------------- -------------------- ---------------------------------
  **Reuse           **UML Requirements   **Schema Requirements for Model
  scenario**        for Model 2**        2**

  Model 2 reuses    Model 2 must contain The schema for Model 2 must
  class A           A, B, and C          reference the Model 1 schema
                                         definitions for A, B, and C (i.e.
                                         it cannot redefine its own
                                         definition for A, B, or C).

  Model 2 reuses    Model 2 must contain The schema model 2 must reference
  class B           both B and C         the Model 1 schema definitions
                                         for B and C (i.e. it cannot
                                         redefine its own definitions for
                                         B or C).
  ----------------- -------------------- ---------------------------------

Example 2: Reuse of highly-connected grid-enabled models. The UML
diagram and accompanying table illustrates reuse scenarios if the owners
of another model (Model 2) wanted to reuse components from Model 1.

[]{.mark}

> Note: Partial interoperability is possible. For example, if two
> applications use the same CDE they are semantically interoperable but
> unless they also use the same XML schema they are not directly
> syntactically interoperable, as format transformation would be
> required. In this case it may be possible to transform the XML from
> one application to match the schema used by another, thereby achieving
> syntactic interoperability. Similarly, two applications that use the
> same XML schema are syntactically interoperable but unless they also
> use the same CDEs they are not guaranteed to be semantically
> interoperable. Semantic interoperability can be verified by examining
> a service's metadata and/or querying the caDSR and comparing the
> corresponding CDEs for each attribute in the UML model (XML schema).

In summary, grid-enabled applications must use *both* the same CDEs and
the same XML schema to directly interoperate on caGrid.

# Implications for Compatibility Criteria and Reuse

The requirement for grid-enabled applications to use the same XML schema
in order to directly interoperate has implications for the existing
Silver level review criteria, the Gold level criteria currently under
development, and the creation of harmonized domain (or \"backbone\")
models.

## Silver Level Criteria

The existing Silver level criteria is used to evaluate applications that
expose programming language (Silver level) APIs as well as applications
that have been grid-enabled, but this may not be appropriate.

For example, two different applications, each of which meet the criteria
for Silver level compatibility and expose Silver level APIs, can
interoperate both semantically and syntactically if they use the same
CDEs and programming language libraries, respectively. Grid-enabled
versions of those same applications, however, will likely *not* be able
to directly interoperate due to syntactic differences between the XML
schemas. In some cases, this situation may also apply to two versions of
the same application (see below).

## Gold Level Criteria

The Gold level criteria currently under development include strict
requirements in the areas of UML model and CDE reuse, specifically with
respect to harmonized domain (backbone) models and CDE standards. The
draft criteria also include requirements for applications to reuse
components of other, related models as appropriate. Given the
requirement for grid-enabled applications to use the same XML schema for
direct programmatic interoperability and the way existing models have
been constructed, these requirements will be very difficult if not
impossible to meet.

## Creation of Harmonized Domain Models

Since grid-enabled applications must use the same XML schema to directly
interoperate, any requirement for an application to harmonize to a
domain or backbone model will require the application to use that model
in its entirety. This will influence the scope and structure of those
harmonized models, and will require rules and processes to govern the
expansion and extension of those models. Furthermore, the impact of
versioning those models over time must be assessed, since changing the
model may result in the registration of a new XML schema and therefore
prevent interoperability between applications that use different
versions of the harmonized model.

# Recommendations

This section outlines some of the recommendations that should be pursued
to ensure the compatibility criteria remains internally consistent with
itself and aligns with the requirements and practical constraints of web
services (and the caGrid infrastructure in particular). This is not
intended to be an exhaustive list.

1.  Clearly distinguish between different types of interoperability in
    caBIG. Grid services can interoperate through direct exchange of
    information, but it is also possible to achieve interoperability
    between grid services using metadata and transformations.
    Non-grid-enabled applications can interoperate by using the same
    CDEs.

    a.  The caGrid infrastructure makes it possible to integrate data
        from two different data services using two different models and
        representations through the Federated Query Processor by
        leveraging shared CDEs (without requiring schema reuse), but
        that does not imply those two services can directly exchange
        data. That is, if the data representation is different (i.e.,
        different XML schemas), one would not be able to use the results
        obtained from a query to one service, directly as input to an
        operation provided by the other service.

        i.  This distinction is particularly pronounced in the area of
            workflows, where such data pipelining would require format
            transformation.

        ii. While the metadata available in caGrid could make such a
            transformation programmatically possible there is no
            currently available infrastructure to do this automatically,
            hence the strong preference for XML schema reuse wherever
            possible.

2.  Review the existing Silver level criteria to determine if it
    accurately enumerates the requirements for grid-enabled Silver level
    applications. A separate checklist for grid-enabled Silver level
    applications may be appropriate.

    a.  Grid-enabled Silver level applications might require modified
        criteria, or additional criteria similar to that being developed
        for Gold level applications.

3.  Review the draft Gold level criteria to ensure that the requirements
    are achievable given the current caGrid infrastructure requirements.

    a.  The criteria for UML model and CDE reuse may help to encourage
        developers to move towards harmonizing their models, but
        applications will not be able to directly interoperate unless
        they use the exact same UML model and XML schema.

    b.  The requirements for reuse of CDE standards will require the
        creation of both UML models and XML schemas.

    c.  The criteria for reuse of the backbone model will require
        developers seeking direct interoperability to reuse the backbone
        model in its entirety, if that model is fully connected with
        bidirectional associations. This could be partially mitigated if
        portions of the backbone model are isolated though the use of
        unidirectional associations, at the expense of navigability
        between classes in the model.

    d.  The criteria for UML model reuse (e.g., class/attribute names,
        partial vs. whole model reuse) may need to be modified.

4.  Determine methods to maximize reuse of CDE standards in grid-enabled
    applications.

    a.  This will require establishing and registering a UML model and
        XML schema for each standard, and should be done in conjunction
        with harmonized domain or backbone models.

5.  Review recommended UML modeling practices to ensure that they
    encourage reuse and interoperability among applications, given the
    technical requirements of web services and the caGrid
    infrastructure. This could result in a recommendation to create
    smaller, more modular models rather than a single large model.

    a.  Encourage developers to create several smaller models that are
        connected with unidirectional associations or inheritance to
        facilitate reuse of models, CDEs, and schemas.

        i.  Develop a list of modeling practices *prior to* the creation
            of the \"backbone model\" or harmonized domain-specific
            models.

            1.  These practices would help to define the rules for
                extending source models (expansion of the base classes
                by addition of attributes vs. extension; unidirectional
                associations to and inheritance from the source model
                vs. associations from the source model).

        ii. This approach would also mitigate the problem caused by
            circular references in UML models (e.g., when model A refers
            to model B and model B refers to model A).

6.  Explore scenarios for versioning components of grid-enabled
    applications (UML models and CDEs) and determine what technical and
    procedural needs exist for allowing models to evolve gracefully over
    time and still maintain a level of interoperability with other
    applications.

    a.  This is especially relevant for harmonized or backbone models,
        as modifications to those models will likely result in the
        creation of a new XML schema and therefore break
        interoperability with applications that use a previous version.

7.  Determine if the design of the current binding between the UML model
    and the XML schema should be modified to facilitate reuse and
    interoperability between applications.

    a.  The one-to-one correspondence between the XML schema and the UML
        model ensures that applications that use the same schema are
        both syntactically and semantically interoperable. Relaxing this
        constraint to allow multiple UML models to map to the same XML
        schema may help to increase interoperability but it may have
        other consequences.

# Conclusions

The maturation of the caBIG program, the development of Gold level
applications, and the prospect of widespread interoperability between
data and analytic services on caGrid are exciting, but they also poses
several challenges that require the careful definition of what
interoperability means in caBIG and how the compatibility guidelines are
implemented. This white paper attempts to outline the issues that have
been identified.

The recommendations specified in this white paper can be summarized as
follows:

-   There are multiple types of interoperability, which have different
    requirements and methods for information exchange, but these
    distinctions are not always recognized.

-   The same set of Silver level criteria is used to evaluate both
    grid-enabled and non-grid-enabled applications, although the
    interoperability requirements are clearly different for these two
    types of applications.

-   Some items in the draft Gold level criteria for UML model and CDE
    reuse may not be achievable given the current caGrid infrastructure
    requirements.

-   Some of the recommended UML modeling practices currently in use were
    developed to improve interoperability among Silver level,
    non-grid-enabled applications. However, some practices actually
    reduce or prevent interoperability among applications on caGrid.

-   Processes are needed to ensure interoperability is maintained as
    applications evolve over time. This is particularly relevant to the
    creation and harmonization of standard domain models.

-   The current design of the binding between the UML model and the XML
    schema has some advantages, but it also has limitations that may
    reduce interoperability.

It is important to note that most, if not all, of the issues can be
solved. For those solutions to be effective, however, an integrated view
of interoperability requirements (theoretical, practical, and technical)
across all four areas of interoperability is required.

# Appendix: Interoperability Use Cases

This section lists examples of common use case scenarios that either
have already been encountered or are anticipated in the future. As
discussed above, the answers to each of these questions depends on a
number of factors. Specifically, grid-enabled applications (either
silver or gold level) can interoperate and exchange data directly only
if they meet both the semantic and syntactic requirements (the same CDEs
and XML schemas are used, respectively). If they are only semantically
interoperable (i.e., they use the same CDEs but have different schemas)
then a syntactic transformation is necessary to enable information
exchange. The ability to reuse a schema will be influenced by the
structure and content of the UML model, including associations between
classes.

1.  Application 1 and Application 2 are both grid-enabled, silver level
    applications. They model the same piece of information differently.
    Will they be able to interoperate?

2.  Application 1 is a grid-enabled, silver level application. As part
    of the next release, the developers update the model based on
    suggestions from the silver level review team. Some of those updates
    resulted in changing UML names and/or semantic annotation. Will the
    new version be able to interoperate with the old version, and visa
    versa?

    a.  Note: This use case also covers the use case where an existing
        silver level application is updated to map to a reference model
        (domain, backbone, etc).

3.  Application 1 is a grid-enabled, silver level application. The
    developers update the model, which includes improving CDE reuse
    (from standards, from other models, and/or from the backbone model),
    and then release a gold level version. Will the two versions be able
    to interoperate?

4.  Applications 1, 2, and 3 are gold level applications that contain
    classes that are not currently in the backbone model (so the
    developers were free to model them as they saw fit). The maintainers
    of the backbone model decide to expand the backbone model to include
    some of the new classes/attributes from Applications 1, 2, and 3.
    The additions may use the same names and/or concept mappings of one
    or more of the applications, but in all cases at least one
    application must update their model to keep it harmonized with the
    new backbone model.

    a.  Note: This use case also covers the use case for updating gold
        level applications and maintaining backward-compatibility with
        previous versions.

5.  Application 1 was developed in English. It contains Gene.ensemblId
    and maps to CDE 12345. Application 2 was developed in Quux. It
    contains Foo.bar (where \"Foo\" is a translation of \"Gene\" and
    \"bar\" is a translation of \"Ensembl identifier\"), which also maps
    to CDE 12345.

    a.  Can the applications interoperate if:

        i.  they are both grid-enabled silver level applications

        ii. they are both gold level applications

        iii. one is a grid-enabled silver level application and the
             other is a gold level application

[^1]: https://cabig.nci.nih.gov/guidelines_documentation/compat_v3/

[^2]: http://gforge.nci.nih.gov/docman/?group_id=233

[^3]: http://gforge.nci.nih.gov/docman/index.php?group_id=472&selected_doc_group_id=3744&language_id=1