[tdwg-content] LSID Resolution Service using DDDS/DNS
jcigar at ulb.ac.be
Wed Jun 20 10:23:32 CEST 2012
Thank you all for those clarifications, I'll not go further with LSID
and rather use the usual URLs.
On 06/19/2012 23:41, Jonathan A Rees wrote:
> Sadly nobody ever registered urn:lsid: with IETF, or even specified it
> well enough that it would be able to pass IETF NID review if
> submitted. LSIDs aren't URNs or URIs in any standards sense. Jonathan
> On Mon, Jun 18, 2012 at 10:51 AM, Julien Cigar<jcigar at ulb.ac.be> wrote:
>> Hi Roderic,
>> Thanks for your reply.
>> But I've almost the same feeling. The more I read about LSIDs, the more I
>> feel that there are no real huge benefits over URLs, .. although it looks
>> like different concept to me: I see more an URL as the location of the
>> resource, and the LSID the identifier of that resource.
>> It's frustrating because at first glances all the models and the "to be
>> compliant you must ..." rules that come with the spec seemed pretty
>> Some advantages I see compared to URLs:
>> - the separation of data and metadata (through the .getData / .getMetadata
>> methods and the WSDL files), .. although you could achieve more or less the
>> same by playing on the Accept header of the HTTP request
>> - the versioning
>> - the resolution services/discovery services.. although there are a lot of
>> "assuming that..." in the spec
>> - protocol independent
>> - other things ... ?
>> Best regards,
>> On 06/18/2012 15:15, Roderic Page wrote:
>>> Hi Julien,
>>> Firstly, let me say "run, run away now". Unless you need to support
>>> resolving existing LSIDs (e.g., Index Fungorum, IPNI) then I can see no
>>> reason to use LSIDs. The future landscape of identifiers is essentially URLs
>>> and DOIs. The difference between the two boils down to whether you want your
>>> identifiers to have a degree of management or not (you can add management to
>>> URLs but the DOI infrastructure for this seems more established).
>>> My understanding has been that querying the DNS for the SRV record is
>>> enough. This is what my LSID tester
>>> <http://darwin.zoology.gla.ac.uk/%7Erpage/lsid/tester/> does. Reading the
>>> LSID spec I get the sense that, had it been more widely adopted, there was a
>>> mechanism to resolve LSID authorities centrally at a server
>>> "lsidauthority.org<http://lsidauthority.org>" (option [a]). If this
>>> mechanism didn't exist, we would do a regular DNS lookup of the domain in
>>> the LSID we were trying to resolve (option [b]). Option (a) was never
>>> implemented, so it's option (b).
>>> That said,
>>> On 18 Jun 2012, at 13:04, Julien Cigar wrote:
>>>> I'm reading the LSID spec and there are some things that are some things
>>>> that are a little cloudy to me.
>>>> The spec says that the client should query the DNS for NAPTR records for
>>>> the domain name "lsid.urn.arpa", but it seems that the URN NID part "lsid"
>>>> has not been established at IANA (lsid.urn.arpa is unresolvable) ? Why ?
>>>> I wondered if it's enough to query the DNS of the "authority
>>>> identification" part of the LSID (domain name) for a _lsid._tcp SRV record
>>>> and assume that this entry is a valid resolution service for the given LSID
>>>> ? If not, what's the proper way to find a resolution service for, let's say,
>>>> "urn:lsid:blah.my.domain:foo:12345" ?
>>>> Thank you
>>>> Best regards,
>>>> No trees were killed in the creation of this message.
>>>> However, many electrons were terribly inconvenienced.
>>>> tdwg-content mailing list
>>>> tdwg-content at lists.tdwg.org<mailto:tdwg-content at lists.tdwg.org>
>>> Roderic Page
>>> Professor of Taxonomy
>>> Institute of Biodiversity, Animal Health and Comparative Medicine
>>> College of Medical, Veterinary and Life Sciences
>>> Graham Kerr Building
>>> University of Glasgow
>>> Glasgow G12 8QQ, UK
>>> Email: r.page at bio.gla.ac.uk<mailto:r.page at bio.gla.ac.uk>
>>> Tel: +44 141 330 4778
>>> Fax: +44 141 330 2792
>>> Skype: rdmpage
>>> AIM: rodpage1962 at aim.com<mailto:rodpage1962 at aim.com>
>>> Facebook: http://www.facebook.com/profile.php?id=1112517192
>>> Twitter: http://twitter.com/rdmpage
>>> Blog: http://iphylo.blogspot.com
>>> Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html
>> No trees were killed in the creation of this message.
>> However, many electrons were terribly inconvenienced.
>> tdwg-content mailing list
>> tdwg-content at lists.tdwg.org
No trees were killed in the creation of this message.
However, many electrons were terribly inconvenienced.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 292 bytes
Desc: not available
Url : http://lists.tdwg.org/pipermail/tdwg-content/attachments/20120620/59fd193d/attachment.vcf
More information about the tdwg-content