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.

Features

  • 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.

Principles

  • 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.

Design Choices

  • 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.

Governance

  • 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 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.

Future Features

  • 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.

Agenda

  • Do we need to broaden the concept of "prized numbers" (exclusions) to include patterns like 1234567890 or 3838385544?
Home
About PCA
Reference Data Services (RDS)
RDS Operations Support
Meetings and Conferences
ISO 15926
Special Interest Groups
Technical Advisory Board
Norwegian Continental Shelf Std
Projects
Search