Identifiers In Kepler

This is version 7. It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

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. In particular, the subsystem should provide the infrastructure for enabling scientists to:

• Search for all known items of interest, including actors, workflows,

• Easily organize actors, workflows, and data sets of interest using the

• Persist actors, workflows, and data sets in a network-accesible

• Retrieve new actors, workflows, and data sets from a network-accessible

• Track both revisions of actors, workflows, and data sets as well as new

• Store semantic annotations of actors, workflows, and data sets and

The figure below outlines the architectural components of the subsystem. The subsystem assumes the use of Life-Sciences Identifiers (LSIDs) as logical identifiers for actors, workflows, data sets, and annotations (and possibly for local "libraries"?). Thus, particular files (representing actors, workflows, data sets, or annotations) are assigned LSIDs and are accessed via LSIDs.

Fig 1: A high-level architecture for file-management in Kepler.

The main components provide operations over a local data store of files. The remote manager provides the operations required to interact with the EcoGrid. It also may provide a local cache for performance. The LSID manager is used to assign unique identifiers for items, e.g., serving as logical identifiers for actors, workflows, data sets, and semantic annotations. The logical/physical index manager provides operations to related physical files to LSIDs, and to access files based on LSIDs. The directory/view manager provides operations for local organizations of items into libraries.

The following are a set of possible supported operations (note that these are half-baked, if that):

• Retrieve(ID). Given an id, the subsystem returns the files

• LocalIDs(IDMetadata). Retrieve a list of local LSIDs, based on LSID

• RemoteIDs(IDMetadata). Retrieve a list of remote LSIDs, based on LSID

• Store(ItemHandle, IDMetadata). Construct an LSID with the given

• GetRemoteUpdates(). Retrieve a list of new or updated LSIDs from a remote

• Update(LSID). Update the given LSID item from a remote source. This

• Branch(LSID). Create a new version of an item. This creates and

• CommitToRemoteServer(LSID). Update this item in a remote server.

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

Potential components needing identification

• An actor or service overall
• This would enable annotations regarding the behavior of the actor overall
• Would need to attach these identifiers to Java implementations of actors, to specializations of actors, and to web service descriptions (e.g., WSDL), among other things
• A port from an actor or service
• This enables annotation of the actor signature, both before and after specialization
• Combinations of ports? Probably not, as they can be referred as compound objects

References