Identifiers In Kepler

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

In order to link various types of annotations to actors, services, and I/O ports in models that are utilized in Kepler, we need a consistent scheme for identifiying unique actors and services and their 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 include annotations regarding the behavior of the actor
• 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
• Combinations of ports? Probably not, as they can be referred as compound objects

References