Administration
| Project | Opaque | Unique | Permanent | Migratable | Resolvable | Federated | Secure | Optimized | Simple | Standard | Extensible | Policy Opaque | Verifiable | Deployment Model | *Notes * |
|---|
| caBIO |
| caDSR | ISO IRDI ? |
| caHUB | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | Unknown |
| caTissue | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | Unknown | Q4 2009 |
| LexEVS |
| LS Specimen Identifers |
| OpenMDR |
| Provenance |
| UK Cancer Grid |
Requirements
<CAGRID-IDS-010> Opaque: Meaning MUST NOT be explicitly associated with the string; though assignment MAY encode values into it.
<CAGRID-IDS-020> Unique: An identifier assignment scheme MUST enforce global uniqueness in a particular deployment/grid; and SHOULD enforce context independent universal uniqueness.
<CAGRID-IDS-030> Permanent: Once assigned, an identifier MUST forever exist (even if marked as deleted) and never be reassigned.
<CAGRID-IDS-040> Migratable: An identifier MUST be able to be moved from source to source without needing to change the identifier (e.g network information MUST NOT be encoded in the identifier).
<CAGRID-IDS-050> Resolvable: Given an identifier, there MUST be a consistent process/API for a client to be able to find its source, value, and additional metadata.
<CAGRID-IDS-060> Federated: The resolution process MUST be able to be distributed such that different groups of identifiers can be managed/resolved by different authorities.
<CAGRID-IDS-070> Secure: The management operations (create, update, etc) for identifiers MUST be able to be secured.
<CAGRID-IDS-080> Optimized: The mechanisms for creating, resolving, retrieving large numbers of identifiers MUST scale sub-linearly (e.g. batch operations may need to be supported).
<CAGRID-IDS-090> Simple: The client-side configuration and API MUST be simple, and not introduce additional prerequisites (e.g. a managed database).
<CAGRID-IDS-100> Standard: There MUST be a core required set of information associated with each identifier that provides a standard way to ascertain common information which MAY include:
- source
- creation/modification datetimes
- data type
<CAGRID-IDS-200> Extensible: The information associated with an identifier MUST be extensible such that new use cases can be supported via additional metadata.
<CAGRID-IDS-210> Policy Opaque: The infrastructure and identifier scheme SHOULD be as policy agnostic as possible (e.g. versioning, data persistency requirements, etc should not be assumed); such things MAY be enforced via metadata or profiles identified via metadata.
<CAGRID-IDS-220> Verifiable: There SHOULD be a way to verify the integrity of the data and metadata (e.g. MD5, PKI signing).
<CAGRID-IDS-230> The adopted identification scheme should be readily and automatically converted to a valid URI so that it plays nicely with the semantic web.
Requirements Questions:
- Is Verifiable a requirement, or can that just be a profile we support?
- Is there optimization Permanent allows us to make, or can we relax that requirement and leave that up to a profile?
Implementation Questions:
- How do we want to support the notion of profiles (just well-known QNames exposes as resource properties of the grid service)?
- Is there 1 grid service or 2 (naming authority and identifier authority) or more (if we want to separate out the "management" from "access" style operations)?
- e.g. Can we make it so a service/application can act as an identifier authority for a given prefix, but not expose any grid management operations, only the metadata/data access operations.
- This would be useful for co-locating/embedding identifier support in an application/service which has no intention in allowing any remote clients the ability to create new identifiers; ideally such a system would not have to support an operation like "createIdentifier" when it would never authorize anyone to use that
- e.g. Can we make it so a service/application can act as an identifier authority for a given prefix, but not expose any grid management operations, only the metadata/data access operations.
- Is it possible and is there utility in using the LSID spec and WSDL binding? If not, is there any other open source infrastructure or tooling we could leverage?
- nice comparison here: http://wiki.tdwg.org/twiki/bin/view/GUID/TechnologyComparison
- ibm article on LSID software they have: http://www.ibm.com/developerworks/webservices/library/os-lsid2/
- nice comparison here: http://wiki.tdwg.org/twiki/bin/view/GUID/TechnologyComparison