Requirements:

___________________

A Kepler instance always has a unique namespace.

Ship Kepler with a list of valid authorities for providing unique namespaces.

During installation of a Kepler instance

IF a network connection is available

and an authority can be reached

and a namespace can be assigned

record authority and assigned namespace in the installation directory (not the cache directory)

call this file InstanceAuthNamespace { file contents example:    kepler-project.org:3271   }

refer to an LSID generated using this kind of Authorized Namespace as a Verified LSID (VLSID)

ELSE 

create a version 4 UUID and save it to disk as the existing namespace using "uuid" as the authority

call this file InstanceAuthNamespace { file contents example:   uuid:7e1d1daf-4890-4e84-bcf4-e9192254461a  }

refer to an LSID generated using this kind of Unauthorized Namespace as a Probabilistic LSID (PLSID)

Kepler may only create LSIDs using the authority and namespace that is saved in the InstanceAuthNamespace file.

(in future releases this file would be signed by the authority and could not be changed by the user without invalidating it)

LSID history will be maintained

The idea here is that if you have an object that does not match the InstanceAuthNamespace  

and you resave that object (with or without changing it) then the original LSID is recorded in the object metadata

For example:  the InstanceAuthNamespace of an existing Kepler installation is kepler-project.org:983

the user opens the "Display" actor that was shipped with Kepler as urn:lsid:kepler-project.org:1:1:1

and saves it back to the library as "Display 2", 

the lsid for this new object is set as urn:lsid:kepler-project.org:983:1:1 

(assuming this is the first object and first revision created with this InstanceAuthNamespace)

also saved in the metadata for this object is the previous LSID ( urn:lsid:kepler-project.org:1:1:1 )

call this type of LSID a Referral LSID (RLSID)

In this way objects may have 1 LSID and an ordered list of RLSIDs (ordered from newest to oldest)

LSIDs may only be "deleted" and "created" never "updated".

This implies that there will be no functionality developed to go back and retroactively update any objects that have been generated (or even uploaded) using PLSIDs.  If objects are assigned PLSIDs then those are their LSIDs.  If a user wishes to assign a VLSID to an object that has been labeled with a PLSID then they must save it as a new object (which would mean there is now an RLSID list that contains the original PLSID).

______________________

Note:

In this system, object revisions now become a function of both the LSID revision number and the RLSID list.

These requirements are being driven by 

the need to 

always have a unique identifier for objects within Kepler, 

(regardless of save state or successful communication with a server over an internet connection)

the desire to

minimize complexity associated with ID collision handling

maintain provenance of Kepler objects

use as much existing code as possible