[tdwg-content] LSID Resolution Service using DDDS/DNS

[Julien Cigar]

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,
Julien

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/~rpage/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,
>
> Regards
>
> Rod
>
> On 18 Jun 2012, at 13:04, Julien Cigar wrote:
>
>> Hello,
>>
>> 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,
>> Julien
>>
>> -- 
>> No trees were killed in the creation of this message.
>> However, many electrons were terribly inconvenienced.
>>
>> <jcigar.vcf>_______________________________________________
>> tdwg-content mailing list
>> tdwg-content at lists.tdwg.org <mailto:tdwg-content at lists.tdwg.org>
>> http://lists.tdwg.org/mailman/listinfo/tdwg-content
>
> ---------------------------------------------------------
> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: jcigar.vcf
Type: text/x-vcard
Size: 292 bytes
Desc: not available
Url : http://lists.tdwg.org/pipermail/tdwg-content/attachments/20120618/1420c8ad/attachment.vcf