LSID Resolution Service using DDDS/DNS
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
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/ 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" (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@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@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 Skype: rdmpage AIM: rodpage1962@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
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@lists.tdwg.org mailto:tdwg-content@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@bio.gla.ac.uk mailto:r.page@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 Skype: rdmpage AIM: rodpage1962@aim.com mailto:rodpage1962@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
Hi Julien,
On 18 Jun 2012, at 15:51, Julien Cigar 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.
DOI can do the same thing, or we can design URLs to act much the same way (e.g., by using consistent "slugs" across domains, such as Wikipedia topics or ISBNs).
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 metadata/data distinction is often messy. What is metadata and what is data? Is the metadata about the data, or about the LSID itself, etc.? Cue much metaphysical discussion (sigh)
- the versioning
To a first approximation nobody uses versions. I have never seen anyone use a version of a GenBank sequences, for example. In general people people want the latest version. One can also create versioned identifiers using other schemes if you really must.
- the resolution services/discovery services.. although there are a lot of "assuming that..." in the spec
They didn't happen...
- protocol independent
I think HTTP pretty much won that argument...
- other things ... ?
LSIDs do have some nice features, but if we step back we see that it's got zero traction outside our community. It's either URLs or DOIs (the later are gaining traction in the data citation world, and are obviously already established in academic publishing). There's a bunch of reasons LSIDs failed to take off, partly technical (they are too hard for most people to get working properly), partly social (pretty much no LSID serves content we can actually do something useful with).
I'm being a little flippant, but personally I think the last thing we'd want to do as a community is continue to flog a technology that has zero uptake outside biodiversity informatics. it was a nice idea, we tried it, didn't work out too well, let's move on...
Regards
Rod
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@lists.tdwg.org mailto:tdwg-content@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@bio.gla.ac.uk mailto:r.page@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 Skype: rdmpage AIM: rodpage1962@aim.com mailto:rodpage1962@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.
<jcigar.vcf>
--------------------------------------------------------- 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@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 Skype: rdmpage AIM: rodpage1962@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
The main advantages of LSIDs are pretty much what you have listed. The main ones being the separation of the Identifier itself and the resolution protocol and the encouragement to avoid "plain" urls that are so easily broken. This was obviously much more of an issue 8-10 years ago when we started discussing the use of GUIDs in biodiversity informatics. These days however, with the move towards restful architecture and web resource based mechanisms (eg avoiding urls like http://example.org/birds/moa.html, which doesn't make a very nice ID), I feel the approach for creating web resources and urls has improved and result in less broken urls anyway.
I think I agree with Rod here in that it is probably best to adopt the benefits of LSIDs but use HTTP URL/URIs.
Kevin
From: tdwg-content-bounces@lists.tdwg.org [mailto:tdwg-content-bounces@lists.tdwg.org] On Behalf Of Roderic Page Sent: Tuesday, 19 June 2012 3:39 a.m. To: Julien Cigar Cc: TDWG Content Mailing List Subject: Re: [tdwg-content] LSID Resolution Service using DDDS/DNS
Hi Julien,
On 18 Jun 2012, at 15:51, Julien Cigar 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.
DOI can do the same thing, or we can design URLs to act much the same way (e.g., by using consistent "slugs" across domains, such as Wikipedia topics or ISBNs).
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 metadata/data distinction is often messy. What is metadata and what is data? Is the metadata about the data, or about the LSID itself, etc.? Cue much metaphysical discussion (sigh)
- the versioning
To a first approximation nobody uses versions. I have never seen anyone use a version of a GenBank sequences, for example. In general people people want the latest version. One can also create versioned identifiers using other schemes if you really must.
- the resolution services/discovery services.. although there are a lot of "assuming that..." in the spec
They didn't happen...
- protocol independent
I think HTTP pretty much won that argument...
- other things ... ?
LSIDs do have some nice features, but if we step back we see that it's got zero traction outside our community. It's either URLs or DOIs (the later are gaining traction in the data citation world, and are obviously already established in academic publishing). There's a bunch of reasons LSIDs failed to take off, partly technical (they are too hard for most people to get working properly), partly social (pretty much no LSID serves content we can actually do something useful with).
I'm being a little flippant, but personally I think the last thing we'd want to do as a community is continue to flog a technology that has zero uptake outside biodiversity informatics. it was a nice idea, we tried it, didn't work out too well, let's move on...
Regards
Rod
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.orghttp://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@lists.tdwg.orgmailto:tdwg-content@lists.tdwg.org mailto:tdwg-content@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@bio.gla.ac.ukmailto:r.page@bio.gla.ac.uk mailto:r.page@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 Skype: rdmpage AIM: rodpage1962@aim.commailto:rodpage1962@aim.com mailto:rodpage1962@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.
<jcigar.vcf>
--------------------------------------------------------- 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@bio.gla.ac.ukmailto:r.page@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 Skype: rdmpage AIM: rodpage1962@aim.commailto:rodpage1962@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
________________________________ Please consider the environment before printing this email Warning: This electronic message together with any attachments is confidential. If you receive it in error: (i) you must not read, use, disclose, copy or retain it; (ii) please contact the sender immediately by reply email and then delete the emails. The views expressed in this email may not be those of Landcare Research New Zealand Limited. http://www.landcareresearch.co.nz
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 a standards sense. Jonathan
On Jun 18, 2012, at 8:04 AM, 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@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content
participants (4)
-
Jonathan Rees -
Julien Cigar -
Kevin Richards -
Roderic Page