[kepler-dev] Issues with LSIDs

[Shawn Bowers]

My opinion is that we create, for the local case, an "almost" lsid 
version of an LSID. For example, to use and play with a new/revised 
actor, or a data set one could locally assign it one of these 
"temporary" lsids. And then only if someone wants to publish the 
resource, would we assign a "real" lsid to the item (where publishing is 
done automatically by the system).

The "temporary" lsids could use formats such as 
urn:lsid:localhost:keplerlocal:<id>, where the namespace is just our 
default namespace for local id's, and the id portion is automatically 
assigned.

There are probably a million other ways to gen up a local lsid format 
here.  Alternatively, we could just make up a completely new format for 
local ids ... with the caveat that they "become" real lsids when the 
item is published.

When an item is published, I would assume the dns and namespace would be 
assigned based on where the item is published to (the remote repository).

shawn


Rod Spears wrote:
> When creating LSIDs for the local cache will we be using a LSID 
> "authority" for that?
> 
> Meaning will we use our own LSID server?
>     If so, what do we do when running off line?
>     If not, how should the LSID be generated?
> 
> Whether we use the LSID server or not:
> 
>     * What will we use for the "name space" portion?
>     * What will we use for the "object id" portion?
> 
> 
> LSIDs are intended to live forever, I guess we won't be concerned about 
> that so much as long as they are unique?
> 
> Rod