identifiers for geologic samples
Bob Morris
morris.bob at GMAIL.COM
Sun Jan 29 22:04:22 CET 2006
>>>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.
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
On 1/28/06, Roderic Page <r.page at bio.gla.ac.uk> wrote:
>
> On 28 Jan 2006, at 01:02, Richard Pyle wrote:
>
> > The more I think about it, the more I think this is the sort of system
> > that
> > would work well for our field. A centralized issuer (which could issue
> > blocks of thousands or millions of numbers at a time),
>
> The major problem I see with this is that a central registry may be a
> rate limiting step because it has to allocate blocks, it would also
> decide for format of the last part of the identifier (which the
> provider might not find desirable), and it may well lead to lots of
> wasted identifiers (e.g., it allocates 100,000 to me, but I use 3 off
> them).
>
> Would it not be better to devolve this? You can still have a central
> registry. For example, Handles and DOIs work by having a central
> registry for the prefix (e.g., "1018") and the provider is responsible
> for allocating the suffix locally.
>
>
> > I'm not sure how wise it would be to create a new syntax standard,
> > rather
> > than go with one of the ones we've discussed. But if (for example)
> > using
> > LSID, I personally think it would be preferable to establish a highly
> > generic form, such as:
> >
> > urn:lsid:gbif.org:BioGUID:12345
>
> Without wishing to preempt some of the things I'm going to present at
> the workshop, I'm going off LSIDs a little because of their reliance on
> the Internet DNS. Apart from the hassle of mucking with the DNS records
> to set them up (I suspect not every provider is going to find this easy
> to do), it assumes that the Internet its present form is going to be
> here forever, and it also embeds information in the identifier (e.g.,
> "gbif.org") that currently has meaning, but over time may loose
> meaning, or worse, be positively misleading (say if GBIF goes belly up
> and somebody else serves the data).
>
> Handles (including DOIs) and ARK have no information in the identifier
> (perhaps not strictly true for some DOIs, but that's by choice not
> design), and also in principle don't need the internet. In the future
> some other mode of information transport may come along, and they could
> still be used.
>
> While it might be hard to imagine the Internet and the DNS going away,
> if anybody has a 5 1/4" floppy lying around, they'll be aware of how
> hard it is to get information off it these days as 5 1/4" drives are
> scarce as hens teeth -- the only one in my department is in an old PC
> that is connected to the network. The digital library community seem
> particularly sensitive to these issues, which is perhaps why they use
> handles, DOIs, and ARK.
>
> Regards
>
> Rod
>
>
>
> ------------------------------------------------------------------------
> ----------------------------------------
> Professor Roderic D. M. Page
> Editor, Systematic Biology
> DEEB, IBLS
> Graham Kerr Building
> University of Glasgow
> Glasgow G12 8QP
> United Kingdom
>
> Phone: +44 141 330 4778
> Fax: +44 141 330 2792
> email: r.page at bio.gla.ac.uk
> web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html
> reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html
>
> Subscribe to Systematic Biology through the Society of Systematic
> Biologists Website: http://systematicbiology.org
> Search for taxon names at http://darwin.zoology.gla.ac.uk/~rpage/portal/
> Find out what we know about a species at http://ispecies.org
>
>
>
>
>
>
> ___________________________________________________________
> Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with
> voicemail http://uk.messenger.yahoo.com
>
------=_Part_18912_17886685.1138590262539
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
>>>From my understanding of the LSID spec, LSIDs do not rely on the DNS. <span style="font-style: italic;"><span style="font-style: italic;">Rather o</span>ne particular </span>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.
<br><br>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.
<br><br>cf Section 8 and Section 13.3 of <a href="http://www.omg.org/docs/dtc/04-05-01.pdf" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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
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.<br><br>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.
<br><span class="sg"><br>Bob Morris<br></span><br><br><div><span class="gmail_quote">On 1/28/06, <b class="gmail_sendername">Roderic Page</b> <<a href="mailto:r.page at bio.gla.ac.uk">r.page at bio.gla.ac.uk</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;">On 28 Jan 2006, at 01:02, Richard Pyle wrote:<br><br>> The more I think about it, the more I think this is the sort of system
<br>> that<br>> would work well for our field. A centralized issuer (which could issue<br>> blocks of thousands or millions of numbers at a time),<br><br>The major problem I see with this is that a central registry may be a
<br>rate limiting step because it has to allocate blocks, it would also<br>decide for format of the last part of the identifier (which the<br>provider might not find desirable), and it may well lead to lots of<br>wasted identifiers (
e.g., it allocates 100,000 to me, but I use 3 off<br>them).<br><br>Would it not be better to devolve this? You can still have a central<br>registry. For example, Handles and DOIs work by having a central<br>registry for the prefix (
e.g., "1018") and the provider is responsible<br>for allocating the suffix locally.<br><br><br>> I'm not sure how wise it would be to create a new syntax standard,<br>> rather<br>> than go with one of the ones we've discussed. But if (for example)
<br>> using<br>> LSID, I personally think it would be preferable to establish a highly<br>> generic form, such as:<br>><br>> urn:lsid:gbif.org:BioGUID:12345<br><br>Without wishing to preempt some of the things I'm going to present at
<br>the workshop, I'm going off LSIDs a little because of their reliance on<br>the Internet DNS. Apart from the hassle of mucking with the DNS records<br>to set them up (I suspect not every provider is going to find this easy
<br>to do), it assumes that the Internet its present form is going to be<br>here forever, and it also embeds information in the identifier (e.g.,<br>"<a href="http://gbif.org">gbif.org</a>") that currently has meaning, but over time may loose
<br>meaning, or worse, be positively misleading (say if GBIF goes belly up<br>and somebody else serves the data).<br><br>Handles (including DOIs) and ARK have no information in the identifier<br>(perhaps not strictly true for some DOIs, but that's by choice not
<br>design), and also in principle don't need the internet. In the future<br>some other mode of information transport may come along, and they could<br>still be used.<br><br>While it might be hard to imagine the Internet and the DNS going away,
<br>if anybody has a 5 1/4" floppy lying around, they'll be aware of how<br>hard it is to get information off it these days as 5 1/4" drives are<br>scarce as hens teeth -- the only one in my department is in an old PC
<br>that is connected to the network. The digital library community seem<br>particularly sensitive to these issues, which is perhaps why they use<br>handles, DOIs, and ARK.<br><br>Regards<br><br>Rod<br><br><br><br>------------------------------------------------------------------------
<br>----------------------------------------<br>Professor Roderic D. M. Page<br>Editor, Systematic Biology<br>DEEB, IBLS<br>Graham Kerr Building<br>University of Glasgow<br>Glasgow G12 8QP<br>United Kingdom<br><br>Phone: +44 141 330 4778
<br>Fax: +44 141 330 2792<br>email: <a href="mailto:r.page at bio.gla.ac.uk">r.page at bio.gla.ac.uk</a><br>web: <a href="http://taxonomy.zoology.gla.ac.uk/rod/rod.html">http://taxonomy.zoology.gla.ac.uk/rod/rod.html
</a><br>reprints: <a href="http://taxonomy.zoology.gla.ac.uk/rod/pubs.html">http://taxonomy.zoology.gla.ac.uk/rod/pubs.html</a><br><br>Subscribe to Systematic Biology through the Society of Systematic<br>Biologists Website:
<a href="http://systematicbiology.org">http://systematicbiology.org</a><br>Search for taxon names at <a href="http://darwin.zoology.gla.ac.uk/~rpage/portal/">http://darwin.zoology.gla.ac.uk/~rpage/portal/</a><br>Find out what we know about a species at
<a href="http://ispecies.org">http://ispecies.org</a><br><br><br><br><br><br><br>___________________________________________________________<br>Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail
<a href="http://uk.messenger.yahoo.com">http://uk.messenger.yahoo.com</a><br></blockquote></div><br>
More information about the tdwg-tag
mailing list