LSID & resolution discovery service (was: identifiers for geologic samples)
Bob Morris
morris.bob at GMAIL.COM
Tue Jan 31 17:16:38 CET 2006
I've expanded my arguments a little at
http://wiki.gbif.org/guidwiki/wikka.php?wakka=LSID
--Bob
On 1/31/06, Ricardo Scachetti Pereira <ricardo at tdwg.org> wrote:
>
> 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
>
------=_Part_28037_18680079.1138745798911
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
I've expanded my arguments a little at <a href="http://wiki.gbif.org/guidwiki/wikka.php?wakka=LSID">http://wiki.gbif.org/guidwiki/wikka.php?wakka=LSID</a><br>--Bob<br><br><br><div><span class="gmail_quote">On 1/31/06, <b class="gmail_sendername">
Ricardo Scachetti Pereira</b> <<a href="mailto:ricardo at tdwg.org">ricardo at tdwg.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Bob and all,<br><br> I wanted to discuss this characteristic of LSIDs that Bob brought up<br>in a recent post.<br><br>Bob Morris wrote:<br><br>> >From my understanding of the LSID spec, LSIDs do not rely on the DNS.
<br>> Rather one particular mechanism for discovering resolution services<br>> depends on the DNS, and nothing in the LSID specification requires the<br>> use of that mechanism, convenient as it presently may be. Future
<br>> resolution service discovery mechanisms can use the existing LSID as<br>> they please provided only they meet the specification of a resolution<br>> service discovery service.<br><br> Now I'm intrigued. I was aware of the fact that the LSID spec left
<br>open the implementation of the resolution discovery service, but I<br>wasn't aware of the implications.<br><br> So, if there are more than one resolution discovery service in use<br>(say, the DNS-based one and some other proprietary ones) and if clients
<br>are not aware of them all (they can't, discovery mechanism is left open<br>by the spec), there may be situations in which a client can have a<br>perfectly valid LSID but cannot get to the identified object. In other<br>
words, although LSIDs are guaranteed to be globally unique, it does not<br>guaranteed that a client that possesses a LSID and no information about<br>it can retrieve data and metadata across different implementation of the
<br>resolution discovery service.<br><br> I'm surprised with this because all other technologies (ARK, Handle<br>System and DOI) are designed so resolutions is global as well. All the<br>other technologies consider resolution discovery as part of regular
<br>resolution.<br><br> If you read it again, the LSID spec acknowledges this situation in<br>the following paragraph:<br><br>"The LSID Resolution Discovery service has only one method that takes<br>any LSID and returns a list of LSID Resolution
<br>services that are responsible for the given LSID. The method may raise<br>an exception if it fails to find an appropriate LSID<br>Resolution service for the given LSID. This may occur particularly when<br>the authority identification field of the LSID is
<br>less standardized (which may occur for local services known only to a<br>limited number of clients)."<br><br> Does that property of LSID brings any implications for our group?<br><br> Cheers,<br><br>Ricardo
<br><br><br>><br>> Also, LSIDs are required by the spec to be semantically opaque.<br>> Though, this has some exceptions, and semantic opacity is narrowly<br>> defined, I would say that except for resolution service discovery
<br>> services---and such services that use DNS are narrowly constrained by<br>> the spec---, those applications that ascribe meaning to parts of an<br>> LSID are probably guilty of violating the spec and perhaps don't
<br>> deserve that much sympathy.<br>><br>> cf Section 8 and Section 13.3 of <a href="http://www.omg.org/docs/dtc/04-05-01.pdf">http://www.omg.org/docs/dtc/04-05-01.pdf</a><br>><br>> I hope that those who argue against LSIDs on either of the above two
<br>> grounds will place in the wiki (or point me to where it already is)<br>> how I am misreading the spec.If I am reading it correctly, I don't<br>> understand how the arguments Rod puts forth here would lead to
<br>> rejection of LSID whatever other disadvantages it may have compared to<br>> alternatives.<br>><br>> This is a familiar sounding point and maybe somebody answered me the<br>> last time I whined about it, long ago in a mailing list far, far away.
<br>> My apologies if so.<br>><br>> Bob Morris<br></blockquote></div><br>
More information about the tdwg-tag
mailing list