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> &lt;<a href="mailto:ricardo at tdwg.org">ricardo at tdwg.org</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
&nbsp;&nbsp; Bob and all,<br><br>&nbsp;&nbsp; I wanted to discuss this characteristic of LSIDs that Bob brought up<br>in a recent post.<br><br>Bob Morris wrote:<br><br>&gt; &gt;From my understanding of the LSID spec, LSIDs do not rely on the DNS.
<br>&gt; Rather one particular mechanism for discovering resolution services<br>&gt; depends on the DNS, and nothing in the LSID specification requires the<br>&gt; use of that mechanism, convenient as it presently may be. Future
<br>&gt; resolution service discovery mechanisms can use the existing LSID as<br>&gt; they please provided only they meet the specification of a resolution<br>&gt; service discovery service.<br><br>&nbsp;&nbsp;&nbsp;&nbsp;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>&nbsp;&nbsp;&nbsp;&nbsp;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>&nbsp;&nbsp;&nbsp;&nbsp;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>&nbsp;&nbsp;&nbsp;&nbsp;If you read it again, the LSID spec acknowledges this situation in<br>the following paragraph:<br><br>&quot;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).&quot;<br><br>&nbsp;&nbsp;&nbsp;&nbsp;Does that property of LSID brings any implications for our group?<br><br>&nbsp;&nbsp;&nbsp;&nbsp;Cheers,<br><br>Ricardo
<br><br><br>&gt;<br>&gt; Also, LSIDs are required by the spec to be semantically opaque.<br>&gt; Though, this has some exceptions, and semantic opacity is narrowly<br>&gt; defined, I would say that except for resolution service discovery
<br>&gt; services---and such services that use DNS are narrowly constrained by<br>&gt; the spec---, those applications that ascribe meaning to parts of an<br>&gt; LSID are probably guilty of violating the spec and perhaps don't
<br>&gt; deserve that much sympathy.<br>&gt;<br>&gt; 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>&gt;<br>&gt; I hope that those who argue against LSIDs on either of the above two
<br>&gt; grounds will place in the wiki (or point me to where it already is)<br>&gt; how I am misreading the spec.If I am reading it correctly, I don't<br>&gt; understand how the arguments Rod puts forth here would lead to
<br>&gt; rejection of LSID whatever other disadvantages it may have compared to<br>&gt; alternatives.<br>&gt;<br>&gt; This is a familiar sounding point and maybe somebody answered me the<br>&gt; last time I whined about it, long ago in a mailing list far, far away.
<br>&gt; My apologies if so.<br>&gt;<br>&gt; Bob Morris<br></blockquote></div><br>


More information about the tdwg-tag mailing list