Bob and all,
I wanted to discuss this characteristic of LSIDs that Bob brought up in a recent post.
Bob Morris wrote:
From my understanding of the LSID spec, LSIDs do not rely on the DNS.
Rather one particular mechanism for discovering resolution services depends on the DNS, and nothing in the LSID specification requires the use of that mechanism, convenient as it presently may be. Future resolution service discovery mechanisms can use the existing LSID as they please provided only they meet the specification of a resolution service discovery service.
Now I'm intrigued. I was aware of the fact that the LSID spec left open the implementation of the resolution discovery service, but I wasn't aware of the implications.
So, if there are more than one resolution discovery service in use (say, the DNS-based one and some other proprietary ones) and if clients are not aware of them all (they can't, discovery mechanism is left open by the spec), there may be situations in which a client can have a perfectly valid LSID but cannot get to the identified object. In other words, although LSIDs are guaranteed to be globally unique, it does not guaranteed that a client that possesses a LSID and no information about it can retrieve data and metadata across different implementation of the resolution discovery service.
I'm surprised with this because all other technologies (ARK, Handle System and DOI) are designed so resolutions is global as well. All the other technologies consider resolution discovery as part of regular resolution.
If you read it again, the LSID spec acknowledges this situation in the following paragraph:
"The LSID Resolution Discovery service has only one method that takes any LSID and returns a list of LSID Resolution services that are responsible for the given LSID. The method may raise an exception if it fails to find an appropriate LSID Resolution service for the given LSID. This may occur particularly when the authority identification field of the LSID is less standardized (which may occur for local services known only to a limited number of clients)."
Does that property of LSID brings any implications for our group?
Cheers,
Ricardo
Also, LSIDs are required by the spec to be semantically opaque. Though, this has some exceptions, and semantic opacity is narrowly defined, I would say that except for resolution service discovery services---and such services that use DNS are narrowly constrained by the spec---, those applications that ascribe meaning to parts of an LSID are probably guilty of violating the spec and perhaps don't deserve that much sympathy.
cf Section 8 and Section 13.3 of http://www.omg.org/docs/dtc/04-05-01.pdf
I hope that those who argue against LSIDs on either of the above two grounds will place in the wiki (or point me to where it already is) how I am misreading the spec.If I am reading it correctly, I don't understand how the arguments Rod puts forth here would lead to rejection of LSID whatever other disadvantages it may have compared to alternatives.
This is a familiar sounding point and maybe somebody answered me the last time I whined about it, long ago in a mailing list far, far away. My apologies if so.
Bob Morris