- RDS/WIP Introduction
- RDS/WIP Sample Queries
- RDS/WIP Staging Diagrams
- RDS/WIP 1.0 Plan
- RDS/WIP 1.0 Testing
- RDS/WIP 1.0 Process
- RDS/WIP 1.0 Inventory
- RDS/WIP 2.0 Plan
- RDS/WIP ID Generator
- RDS/WIP Domain Proposal
- RDS/WIP Requirements Table
- RDS/WIP Use Case: Discrete Editing
- RDS/WIP Use Case: CSV Upload
- RDS/WIP 1.0 General Use Cases
- RDS/WIP 2.0 General Use Cases
- RDS/WIP ISO 15926 Template Definitions
- RDS/WIP OWL/RDF Definition
- RDS/WIP OWL/RDF Project Plan
- RDS/WIP Forums
- RDS/WIP Use Case: Bulk Upload
RDS/WIP Identifier Generator
There has long been a need for an identifier generator in this project, and so we now have one with a user interface here.
- Allocates identifiers in a given name space (you supply the base URI ending in #).
- All identifiers are stored in their name space in a single triplestore.
- All identifiers have the form RNNNNNNNNNN where NNNNNNNNNN are digits and R is literal.
- NNNNNNNNNN will never start with a zero.
- NNNNNNNNNN will never contain a sequence NNN of three of the same digits.
- NNNNNNNNNN will never contain any digit more than three times.
- NNNNNNNNNN is allocated with a strong random number generator (PRNG seeded from an RNG).
- The date of the allocation is recorded.
- Allows explicit binding to other URIs for reconciliation.
- There is intentionally no support for allocating "sequences" of identifiers.
- There is intentionally no support for allocating "bulk" identifiers.
- Uses HTTP CGI GET for operations and XML for results.
- No one can choose their identifier.
- No one can inadvertently create implicit knowledge by "owning" a block of identifiers - knowledge should be explicit, reservation blocks denied.
- No one can create "de facto" maps by allocating sequences that relate to other existing identifiers (again, to avoid creating implicit knowledge).
- Identifiers are of the same length (at least until "slots" become too sparse to find quickly, which will likely happen when its about 80% full).
- Prized numbers (like 1000000000 or 9999999999) will be never be allocated.
- While <base-uri>RNNNNNNNNNN is already recorded, it will go back and try another number - so it can never acquire duplicates (synchronization protects against race conditions).
- Supports machine interfacing.
- Identifiers exist in two stages: created and fixated.
- In the "created" stage, only the owner can add bindings, or release the identifier.
- In the "fixated" stage, no-one can release the identifier and any authenticated party can add bindings.
- There's no way to "unfixate" an identifier - it is permanently published.
- There is no "search" for existing identifiers - this service is not intended to be an index of definitions - users are intended to utilize the base URI endpoint for that sort of task.
- Any abuse of the system (ie. trying to circumvent the principles) should result in suspension of the service for the offending user and revocation of the abusing allocations.
Usage Policy for RDS/WIP
Since this was intended for the RDS/WIP, but has broader applicability (really for managing IDs of that fixed form in any namespace), then we need to come up with some policies for the RDS/WIP usage of this service:
- The URI of the service - https://secure.ids-adi.org/registry
- The protocol - CGI for now.
- Authentication - LDAP on server - user must be in rdswip_registry group.
- The base URIs to allocate identifiers against appear on the RdsWipDomains page.
- In the "created" state, the identifier will only be visible to the grant list (by default, just the creator).
- There will be three separate log trails: per user, per identifier and for the whole registry.
- Log items for identifiers in the "created" state will only be visible to the creator.
- Comments may be able to be added to identifiers (only by the grant list).
- Comments may be able to be added to base URIs.
- Do we need to broaden the concept of "prized numbers" (exclusions) to include patterns like 1234567890 or 3838385544?