DRAFT FOR COMMENTS AND REVISION
To help scientists manage and share data sets, workflows, and workflow computation steps (i.e., actors) as well as semantic descriptions (i.e., metadata and ontology-based annotations) of each of these, we propose adding a new file-management middleware subsystem to Kepler.
The main goals of the file-management subsystem are listed below. We use the term "Kepler item" loosely below to refer to actors, workflows, and data sets, and "annotations" to refer to metadata (like EML) and semantic descriptions. The subsystem should provide the infrastructure for enabling scientists to:
The figure below outlines the architectural components of the subsystem. We treat annotations and Kepler items uniformly below. That is, the management subsystem does not have separate storage components for managing annotations and items. The subsystem assumes the use of Life-Sciences Identifiers (LSIDs) as logical identifiers for items and annotations. (QUESTION: and also for local "libraries" -- do these need to be stored in the EcoGrid, e.g.?). Thus, relevant files are assigned LSIDs and are accessed via LSIDs. We assume that an LSID will store the type of file (e.g., the type of annotation, or the type of Kepler item) associated with the ID.
Fig 1: A high-level architecture for file-management in Kepler.
The remote manager component provides the operations required to interact with the EcoGrid. It also may provide a local cache for better performance. The LSID manager creates and assigns unique identifiers for items and annotations. The logical/physical index manager provides operations to relate physical files to LSIDs, and to access physical files based on LSIDs. The directory/view manager provides operations to support the creation and retrieval of local, customized libraries.
The following are operations (these are very half-baked!) may be provided by the Kepler file-management subsystem:
Another feature that we may consider is support for change management. In particular, when a file within the subsystem is changed, a notification can be cached/stored of the change, for use by components within Kepler. (Isn't there already a change api in Kepler; and can we piggy-back on this?)
MOTIVATION FOR LSIDs
To link metadata and semantic annotations to actors and workflows that are utilized in Kepler, we need a consistent scheme for uniquely identifiying these components. Currently, MoML refers to the implementing Java class as the principal definition of the actor, but this does not allow for the specializations that might occur later that constrain and define the actors I/O signatures and functionality. For example, the 'Expression' actor can be specialized by providing a particular expression to be evaluated, and the I/O signature of this specialized actor can be far more constrained than the Expression actor is generally.
In SEEK, we wish to provide both a structural and a semantic description of the signature and behavior of the actors and services used in models. This will allow us to use these descriptions to construct more powerful search and browsing services and to help integrate and compose workflows.
The EcoGrid and Taxon communities within SEEK are adopting Life Science Identifiers (LSIDs) as the principal syntax for creating identifiers. These ientifiers are free of semantics relating to the identified object, which makes it far easier to maintain consistent identifiers for a set of changing objects. LSIDs are described more thoroughly in EcoGridIdentifiers.
Proposal: Use LSID identifiers for actors, services, and components
LSID Java Tutorial
This material is based upon work supported by the National Science Foundation under award 0225676. Any opinions, findings and conclusions or recomendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation (NSF).
Copyright 2004 Partnership for Biodiversity Informatics, University of New Mexico, The Regents of the University of California, and University of Kansas