[kepler-dev] Issues with LSIDs
sbowers at ucdavis.edu
Mon Jan 31 14:55:03 PST 2005
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
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).
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?
More information about the Kepler-dev