I think it might be helpful to suggest that if this system is too<br>specialized and complicated to implement the vast majority of<br>collections will not adopt it. <br><br>If your goal is to make as much of this data available as possible
<br>to researchers then you need to devise a system that the typical<br>museum curator can understand and maintain using only<br>bright computer savvy undergraduates.<br><br>Respectfully,<br><br>Pete<br><br><div><span class="gmail_quote">
On 6/6/07, <b class="gmail_sendername">Dave Vieglais</b> <<a href="mailto:vieglais@ku.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">vieglais@ku.edu</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;">
Hi Bob,<br>it's pretty simple - DNS is used to resolve an ip address to which a<br>client may connect with a service to resolve the GUID. In the case<br>of LSIDs the suggested mechanism (and actually the only existing
<br>mechanism) is to use DNS SRV records to provide a level of<br>indirection that is meant to preserve the discovery of service ip<br>address independent of the normal issues with A records (although<br>much of the same functionality can be provided with judicious use of
<br>CNAME and A records). To state that LSID resolution is independent<br>of DNS is a bit misleading since the entire basis of LSIDs and their<br>functional utility beyond what can be provided by HTTP uris comes<br>down to their current use of DNS SRV records for service discovery.
<br><br>The only negative with LSIDs that I see is the fact that it is a<br>relatively unknown and so essentially un-implemented protocol. This<br>makes interoperability with the vast majority of existing<br>infrastructure more difficult than it needs to be without offering
<br>any advance in functionality. The use of LSID proxy services,<br>essentially turning LSIDs into URLs is an obvious and welcome<br>solution, but begs the question of what is really gained by the extra<br>step of using LSID URIs rather than HTTP URIs?
<br><br>Perhaps the real benefit is simply that they (LSIDs) look different,<br>which implies that they need to be handled differently than a typical<br>URL, and so people and services know immediately to ask a resolver to
<br>return bits (metadata or data) identified by the GUID. The problem<br>with this of course is that existing services and applications won't<br>know what to do with them since they are implemented to only<br>understand http (or perhaps a couple other schemes), and so need to
<br>be re-engineered to handle LSIDs unless the LSIDs are wrapped in HTTP<br>URLs... One could also argue that it is the context in which an<br>identifier appears that really indicates what is an identifier rather<br>than just a string - so in practice the visual appearance of a GUID
<br>shouldn't matter.<br><br>Perhaps an adequate solution is to use LSIDs and provide definitive<br>guidelines indicating how they can be embedded in URLs so that we do<br>not loose interoperability with the rest of the world? This is
<br>probably much like Ricardo's LSID proxy proposal. Except in my<br>opinion it should be extended further to be a general GUID resolver<br>to help resolve whatever form is used for GUIDs - then one could<br>embed a handle, LSID, HTTP URI, FTP URI, LDAP URI, or even, for the
<br>ancients of the internet, z39.50 URIs in a resolver proxy URL and get<br>something back. The problem of course is that the content that comes<br>back will be different for different protocols - but it would, I<br>suspect be possible to provide a generic form of metadata for the
<br>different protocols.<br><br>It would be pretty simple to add some provenance handling to such a<br>service so that if a particular web server, ftp server, or even LSID<br>system were moved, then the resolver service could lookup the new
<br>location information and appropriately service the request.<br><br>There should of course be multiple instances of such a resolver<br>service, and the provenance information should be shared and<br>replicated between them all.
<br><br>Dave V.<br><br>On Jun 6, 2007, at 15:13, Bob Morris wrote:<br><br>> I'm confused about what arguments in this thread are about the merits<br>> of HTTP (e.g. content negotiation) and what are about the merits of
<br>> DNS (e.g. resource and service location). The fact that most humans<br>> usually exploit these together is because most humans use web browsers<br>> for discovering resources doesn't have much to do with GUIDs. Even
<br>> LSID resolution itself is actually independent of anything to do with<br>> DNS, although all current resolvers are based on DNS services.<br>><br>> OK, I confess to not reading all the arguments in detail, but my
<br>> impression is that several of the opposite conclusions from the same<br>> facts may because one set of conclusions is about service discovery<br>> and one is about (meta)data provision. It won't surprise me if ANY
<br>> guid scheme is stronger about one of these than the other. This might<br>> be what Donald is arguing.<br>><br>> Bob<br>><br>> On 6/6/07, Dave Vieglais <<a href="mailto:vieglais@ku.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
vieglais@ku.edu
</a>> wrote:<br>>> This discussion has been very interesting reading, and though I agree<br>>> with Donald's comments, I find myself coming to a different<br>>> conclusion, leaning towards HTTP URIs as a preferable scheme. The
<br>>> reasons are simple - HTTP has been around for a long time, it is<br>>> widely implemented, and mechanisms for implementing robust services<br>>> with that protocol are pretty well sorted out - and really there is
<br>>> nothing to stop implementation of the same functionality exhibited by<br>>> LSIDs using HTTP. As Rod has pointed out, http is widely used for<br>>> referencing entities within a semantic web type of context, and it
<br>>> seems foolish to ignore the momentum in those technologies as they<br>>> provide a great deal of the desired functionality for<br>>> interoperability and interchange of our data. As a result my<br>
>> preference is towards the use of http, primarily because my intents<br>>> are to integrate data from a much broader community. In the end<br>>> though, it doesn't really matter which scheme is adopted by TDWG - we
<br>>> will build http resolvers regardless, since they will be necessary<br>>> for reasons of convenience in order to utilize LSIDs in all but<br>>> specific, custom built applications.<br>>><br>
>> However, regardless of the scheme used to implement the GUIDs used by
<br>>> this community, it is critical that the identifiers are persistent<br>>> and useful beyond the lives of whatever services are constructed to<br>>> resolve them. This implies some provenance information may need to
<br>>> be captured, and I would argue that the use of DNS alone for handling<br>>> server changes as utilized by LSIDs may be insufficient. The only<br>>> benefit provided by DNS in this context is that it is acting as a
<br>>> single source of authority for directing how to locate something (in<br>>> this case an ip address). What I suspect is really required is a<br>>> more robust, and richer mechanism for discovering and recording
<br>>> provenance. The ideal would be a large, replicated, and distributed<br>>> data store with a single service point which provided people and<br>>> systems with a one-stop shop for discovering provenance for a GUID.
<br>>> Then if an particular GUID could not be directly resolved, the global<br>>> provenance store could be consulted and the resulting information<br>>> providing a pointer (or perhaps a series of pointers) indicating how
<br>>> the guid can now be resolved.<br>>><br>>> By creating such provenance records and persisting them with as much<br>>> care as the data, it seems that a system with stability beyond the<br>>> vagaries of the internet could reasonably be constructed.
<br>>><br>>> regards,<br>>> Dave V.<br>>><br>>><br>>><br>>> On Jun 6, 2007, at 00:46, Donald Hobern wrote:<br>>><br>>> > Yesterday was a vacation here in Denmark - otherwise I'd have
<br>>> > responded a little earlier, but I'm glad to see all the comments<br>>> > from others. I thoroughly agree with Kevin, Jason, Rich and Anna.<br>>> > No one here believes that any particular solution is going to be
<br>>> > perfect. Our biggest need is consensus and the readiness to get<br>>> > going with a workable solution.<br>>> ><br>>> > I do recognise the strength of Rod's arguments. Indeed, if I were
<br>>> > building some system for integrating data using semantic web<br>>> > technologies, and my only concern was ensuring the efficiency of<br>>> > synchronous connections now, I am sure I would adopt HTTP URIs for
<br>>> > the purpose. However I remain convinced (as I've stated before)<br>>> > that the needs of this community do subtly shift the balance in<br>>> > another direction. We are interested in maintaining long-term
<br>>> > connections between our objects and have a perspective which goes<br>>> > back hundreds of years. This at least should give us pause over<br>>> > whether we want our specimens to be referenced using identifiers so
<br>>> > firmly tied to the Internet of today. More importantly, one of the<br>>> > key drivers right at the beginning of TDWG's consideration of GUIDs<br>>> > was that the community had plenty of experience of URL rot and
<br>>> > didn't want to rely on everyone maintaining stable virtual<br>>> > directories on their web servers to preserve the integrity of<br>>> > object identifiers.<br>>> ><br>>> > Both LSIDs and HTTP URIs could be made to work for us. Both are
<br>>> > totally reliant on good practice on the part of data owners.<br>>> > Personally I believe our chances of getting the community to<br>>> > consider, define and apply such practices are enhanced by the
<br>>> > identifier technology being something a little more different and<br>>> > distinct than just a "special URL".<br>>> ><br>>> > Thanks,<br>>> ><br>>> > Donald
<br>>> > ------------------------------------------------------------<br>>> > Donald Hobern (<a href="mailto:dhobern@gbif.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">dhobern@gbif.org
</a>)<br>>> > Deputy Director for Informatics<br>>> > Global Biodiversity Information Facility Secretariat
<br>>> > Universitetsparken 15, DK-2100 Copenhagen, Denmark<br>>> > Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480<br>>> > ------------------------------------------------------------
<br>>> ><br>>> ><br>>> > On Jun 6, 2007, at 12:51 AM, Kevin Richards wrote:<br>>> ><br>>> >> I agree with Jason. It is not the GUID that is the cause of all<br>>> >> the problems here - THERE IS NOTHING WRONG WITH LSIDS - we just
<br>>> >> need to move on and start using them in our own context (or any<br>>> >> other suitable GUID - LSIDs are only the recommended GUID, NOT the<br>>> >> only premissable GUID).<br>
>> >><br>>> >> If it all falls to pieces later on we could just do a search and<br>>> >> replace to change all our GUIDs to some other scheme (to quote<br>>> >> Bob, just serious).
<br>>> >><br>>> >> I agree, it is the RDF/metadata/ontologies that are the key to<br>>> >> getting things working well.<br>>> >><br>>> >> Kevin<br>>> >>
<br>>> >>>>> "Jason Best" <<a href="mailto:jbest@brit.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">jbest@brit.org</a>> 06/06/07 8:39 AM >>><br>
>> >> Rod,<br>>> >> I've only had a chance to quickly skim the documents you
<br>>> >> reference, but it seems to me that the alternatives to LSIDs don't<br>>> >> necessarily make the issues with which we are wrestling go away.<br>>> >> We still need to decide WHAT a URI references - is it the
<br>>> >> metadata, the physical object etc? URIs don't explicitly require<br>>> >> persistance, while LSIDs do so I see that as a positive for<br>>> >> adopting a standard GUID that is explicit in that regard. I think
<br>>> >> the TDWG effort to spec an HTTP proxy for LSIDs makes it clear<br>>> >> that the technical hurdles of implementing an LSID resolver (SVR<br>>> >> records, new protocol, client limitations etc) are a bit
<br>>> >> cumbersome, but I don't think the underlying concept is fatally<br>>> >> flawed. In reading these discussions, I'm starting to believe/<br>>> >> understand that RDF may hold the key, regardless of the GUID that
<br>>> >> is implemented. Now I have to go read up more on RDF to see if my<br>>> >> new-found belief has merit! ;)<br>>> >><br>>> >> Jason<br>>> >><br>>> >> ________________________________
<br>>> >><br>>> >> From: Roderic Page [mailto:<a href="mailto:r.page@bio.gla.ac.uk" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">r.page@bio.gla.ac.uk</a>]<br>>> >> Sent: Tuesday, June 05, 2007 2:10 PM
<br>>> >> To: Chuck Miller
<br>>> >> Cc: Bob Morris; Kevin Richards; <a href="mailto:tdwg-guid@lists.tdwg.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">tdwg-guid@lists.tdwg.org</a>;<br>>> >> <a href="mailto:WEITZMAN@si.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
WEITZMAN@si.edu</a>; Jason Best<br>>> >> Subject: Re: [tdwg-guid] First step in implementing LSIDs?
<br>>> [Scanned]<br>>> >><br>>> >><br>>> >> Maybe it's time to bite the bullet and consider the elephant in<br>>> >> the room -- LSIDs might not be what we want. Markus D�ring sent
<br>>> >> some nice references to the list in April, which I've repeated<br>>> >> below, there is also <a href="http://dx.doi.org/10.1109/MIS.2006.62" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://dx.doi.org/10.1109/MIS.2006.62</a> .
<br>>> >><br>>> >> I think the LSID debate is throwing up issues which have been<br>>> >> addressed elsewhere (e.g., identifiers for physical things versus<br>>> >> digital records), and some would argue have been solved to at
<br>>> >> least some people's satisfaction.<br>>> >><br>>> >> LSIDs got us thinking about RDF, which is great. But otherwise I<br>>> >> think they are making things more complicated than they need to
<br>>> >> be. I think this community is running a grave risk of committing<br>>> >> to a technology that nobody else takes that seriously (hell, even<br>>> >> the <a href="http://lsid.sourceforge.net/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://lsid.sourceforge.net/</a> web site is broken).<br>>> >><br>>> >> The references posted by Markus D�ring were:<br>>> >><br>>> >> (1) <a href="http://www.dfki.uni-kl.de/dfkidok/publications/TM/07/01/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://www.dfki.uni-kl.de/dfkidok/publications/TM/07/01/</a><br>>> >> tm-07-01.pdf<br>>> >> "Cool URIs for the Semantic Web" by Leo Sauermann DFKI GmbH,<br>>> >> Richard Cyganiak Freie Universit�t Berlin (D2R author), Max V�lkel
<br>>> >> FZI Karlsruhe<br>>> >> The authors of this document come from the semantic web community<br>>> >> and discuss what kind of URIs should be used for RDF resources.<br>>> >>
<br>>> >> (2) <a href="http://www.w3.org/2001/tag/doc/URNsAndRegistries-50" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.w3.org/2001/tag/doc/URNsAndRegistries-50</a><br>>> >> This one here is written by the W3C and addresses the questions
<br>>> >> "When should URNs or URIs with novel URI schemes be used to name<br>>> >> information resources for the Web?" The answers given are "Rarely<br>>> >> if ever" and "Probably not". Common arguments in favor of such
<br>>> >> novel naming schemas are examined, and their properties compared<br>>> >> with those of the existing http: URI scheme.<br>>> >><br>>> >><br>>> >> Regards
<br>>> >><br>>> >> Rod<br>>> >><br>>> >><br>>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>>> +++<br>>> >> +++++++++
<br>>> >> WARNING: This email and any attachments may be confidential and/or<br>>> >> privileged. They are intended for the addressee only and are not<br>>> >> to be read,<br>>> >> used, copied or disseminated by anyone receiving them in error.
<br>>> >> If you are<br>>> >> not the intended recipient, please notify the sender by return<br>>> >> email and<br>>> >> delete this message and any attachments.<br>>> >>
<br>>> >> The views expressed in this email are those of the sender and<br>>> do not<br>>> >> necessarily reflect the official views of Landcare Research.<br>>> >><br>>> >> Landcare Research
<br>>> >> <a href="http://www.landcareresearch.co.nz" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.landcareresearch.co.nz</a><br>>> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
<br>>> +++<br>>> >> +++++++++
<br>>> >><br>>> >><br>>> >> _______________________________________________<br>>> >> tdwg-guid mailing list<br>>> >> <a href="mailto:tdwg-guid@lists.tdwg.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
tdwg-guid@lists.tdwg.org
</a><br>>> >> <a href="http://lists.tdwg.org/mailman/listinfo/tdwg-guid" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lists.tdwg.org/mailman/listinfo/tdwg-guid</a><br>>> >>
<br>>> ><br>>> > _______________________________________________
<br>>> > tdwg-guid mailing list<br>>> > <a href="mailto:tdwg-guid@lists.tdwg.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">tdwg-guid@lists.tdwg.org</a><br>>> > <a href="http://lists.tdwg.org/mailman/listinfo/tdwg-guid" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://lists.tdwg.org/mailman/listinfo/tdwg-guid
</a><br>>><br>>> _______________________________________________<br>>> tdwg-guid mailing list<br>>> <a href="mailto:tdwg-guid@lists.tdwg.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
tdwg-guid@lists.tdwg.org</a><br>>> <a href="http://lists.tdwg.org/mailman/listinfo/tdwg-guid" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://lists.tdwg.org/mailman/listinfo/tdwg-guid</a><br>>><br><br>_______________________________________________<br>tdwg-guid mailing list<br><a href="mailto:tdwg-guid@lists.tdwg.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
tdwg-guid@lists.tdwg.org</a><br>
<a href="http://lists.tdwg.org/mailman/listinfo/tdwg-guid" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lists.tdwg.org/mailman/listinfo/tdwg-guid</a><br></blockquote></div><br><br clear="all">
<br>-- <br>---------------------------------------------------------------
<br>Pete DeVries<br>Department of Entomology<br>University of Wisconsin - Madison<br>445 Russell Laboratories<br>1630 Linden Drive<br>Madison, WI 53706<br>------------------------------------------------------------