Science Environment for Ecological Knowledge
Ecoinformatics site parent site of Partnership for Biodiversity Informatics site parent site of SEEK - Home
Science Environment for Ecological Knowledge









 

 

 



Identifiers In Kepler

Difference between version 2 and version 1:

Line 3 was replaced by line 3
- EcoGrid needs to provide a consistent identification scheme for data objects and metadata records in the system, among other things. This identifier format should allow for the creation of globally unique identifiers, hopefully with a local part that is assigned at the participating service rather than centrally.
+ 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.
Lines 5-6 were replaced by line 5
- !!Proposed Identifier Formats
- In the past meetings we've discussed trying to standardize our identifier formats, but so far none of the systems (srb, metacat, etc) will accept identifers of the format we've discussed. In Edinburgh, our proposed ID format was:
+ 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.
Line 8 was replaced by line 7
- {{{urn:ecogrid://scope/localIdentifier}}}
+ 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 on
Removed line 10
- where scope is a symbolic name from the registry that can be used to look up the wsdl (and therefore endpoint) of the EcoGrid query service.
Line 12 was replaced by line 10
- However, we've also discussed using LSID's as the taxon group is doing, which take the form:
+ !! Proposal: Use LSID identifiers for actors, services, and components
Line 14 was replaced by lines 12-16
- {{{URN:LSID:authority:namespace:objectId:revision}}}
+ ! Potential components needing identification
+ * An actor or service overall
+ ** This would include annotations regarding the behavior of the actor
+ * A port from an actor or service
+ * Combinations of ports? Probably not, as they can be referred as compound objects
Removed line 16
- The revision is optional, and taxon and ecogrid have both agreed that it should NOT be used (and that any versioning information belongs in the metadata). The authority is a DNS name that resolves via DNS to a service that can be used to resolve the LSID to actual physical locations. 'Namespace' is analogous to our 'scope', and 'objectId' is analogous to our 'localIdentifier'. So, this is similar to our proposal above, but relies on DNS instead of our registry for the resolution service.
Line 22 was replaced by line 23
- [EcoGridCommunity]
+ [AnalysisAndModelingCommunity]

Back to Identifiers In Kepler, or to the Page History.