<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Kevin et al,<div><br class="webkit-block-placeholder"></div><div>[This is a very long thread - I hope I have taken in enough of the comments to comment myself at this late stage.]<br><div><br class="webkit-block-placeholder"></div><div>I don't think it is idealistic to make the assumption of the existence of a community to maintain services associated with our efforts. We make an implicit assumption that there will be enough of a community around to keep the power on and food on the table so why not make other assumptions about community supported services? If the community goes there will be no one who needs the services perhaps?</div><div><br></div><div>It should be borne in mind though that there is no guarantee of "forever" from anyone. Take a look at an institutional library. How many books in there could be retrieved on interlibrary loan if the library didn't keep them? The reason for having an institutional copy is that it not only gives instant access but guarantees access, in perpetuity, to "business critical" resources even if everyone else throws away their copy. Bottom line is that if you need continued access to data "forever" you have to keep your own copy or pay some one to keep a copy for you. Stuff that isn't important you can leave more to chance.</div><div><br></div><div>Discussions about perpetuity should be refactored into discussions about licensing i.e. What can I do with *your* data to ensure the continued integrity of *my* data should your GUID not resolve in the future?</div><div><br class="webkit-block-placeholder"></div><div>Talking more about our use of LSIDs:</div><div><br></div><div>The continued existence of the proxy is not the most important thing. In the recommend RDF metadata the plain LSID is represented and the http://<someproxy>/<mylsid> version is given along with an owl:sameAs assertion. This means they represent the SAME thing. If the proxy version is changed to a new, better one in the future both proxied (I want to say pixied) versions will be linked to the same LSID with an equality i.e. this is the SAME thing. </div><div><br class="webkit-block-placeholder"></div><div>If the object is cached somewhere then they will be equated to being the same based on the LSID even if they were retrieved using different proxies or even from data off an old disk found in the library - provided the LSID is always cited. If a client comes across such a version and wants to resolve it the following actions can be taken:</div><div><br class="webkit-block-placeholder"></div><div>1) Resolve the LSID using the standard DNS based mechanism - an LSID aware client.</div><div>2) Resolve the pixied version - a non LSID aware client.</div><div>3) Look up either or both or the identifiers in the most efficient indexing service or cache available. The LSID is a well designed unique string so it is effectively a really good key word.</div><div><br class="webkit-block-placeholder"></div><div>If I have understood correctly this appears to be how DOIs are quoted in PDFs i.e. with a proxy that may not live forever <a href="http://dx.doi.org/">http://dx.doi.org/</a> - unlike the itself DOI ;) </div><div><br></div><div>In fact all that I have written there is GUID technology independent. You would only have to drop point 1 and we could be using UUIDs (I am not proposing this!!!).</div><div><br class="webkit-block-placeholder"></div><div>Hope this helps,</div><div><br class="webkit-block-placeholder"></div><div>Roger</div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><br><div><div>On 2 Dec 2007, at 20:28, Kevin Richards wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="MARGIN: 4px 4px 1px; FONT: 10pt Tahoma"> <div>I think this is the idea of "communities". I.e. nothing is guaranteed to be forever. It relies on us as a community to keep it going indefinitely. So yes on the safe side, we could say "in the forseeable future", but on the idealistic side we would say "indefinitely". </div> <div> </div> <div>So I would reccommend staying with tdwg.org, as this ties the "domain" to a global community / an ideal / an aspiration, rather than to a commercial / funding based organisation (which could, even more readily, be terminated).</div> <div> </div> <div>Any "infrastrutcture" will need to be housed somewhere and, I guess, this will be up to the members of our community to chip in and provide the services required at the time (as GBIF have done recently).</div> <div> </div> <div>This probably all sounds a bit "idealistic", but I think ideals last longer than organisations, and longer than any specific technology for that matter (LSIDs, DNS, Internet, etc).</div> <div> </div> <div>Kevin<br><br>>>> "Chuck Miller" <<a href="mailto:Chuck.Miller@mobot.org">Chuck.Miller@mobot.org</a>> 1/12/2007 6:18 a.m. >>><br></div> <div style="COLOR: #000000">How to turn LSIDs into a clickable link guaranteed to work forever?<br><br>Rich's vision:<br><a href="http://<some">http://<some</a> proxy server>.org/?<a href="urn:lsid:zoobank.org:act:1234">urn:lsid:zoobank.org:act:1234</a><br><br>This sounds to me like a question more about networking infrastructure,<br>than TDWG's charter about data exchange protocols and content standards.<br>I have always presumed that TDWG's standards would work using whatever<br>networking infrastructure was available to them - e.g. DNS, HTTP, local<br>provider servers, etc. <br><br>But, then lsid.tdwg.org was created--a server. Servers are operational<br>infrastructure. I don't think TDWG has (yet) a "forever" funding stream<br>to enable operational infrastructure - ongoing operation of server room,<br>system administrator, network connections. But, something like<br>lsid.tdwg.org would serve a valuable purpose as Rich notes of enabling<br>LSIDs as a clickable link in publications or other online sources.<br><br>Is there an existing international body that could operate a forever<br>functioning LSID proxy (say like, proxy.lsid.org--which unfortunately is<br>already lost to Lindsay-Strathmore Irrigation District)?<br><br>Maybe we will be forced to accept that there is no "forever" on the<br>Internet and accept instead the "forseeable future". I would think for<br>the forseeable future that GBIF would be a good place to put a new LSID<br>infrastructure like this since they are in the "operations center"<br>business already and TDWG is by charter not. So, maybe the proxy should<br>be lsid.gbif.org?<br><br>Chuck<br><br><br>-----Original Message-----<br>From: <a href="mailto:tdwg-guid-bounces@lists.tdwg.org">tdwg-guid-bounces@lists.tdwg.org</a><br>[<a href="mailto:tdwg-guid-bounces@lists.tdwg.org]">mailto:tdwg-guid-bounces@lists.tdwg.org]</a> On Behalf Of Richard Pyle<br>Sent: Friday, November 30, 2007 6:39 AM<br>To: 'Roger Hyam'; 'Roderic Page'<br>Cc: <a href="mailto:tdwg-guid@lists.tdwg.org">tdwg-guid@lists.tdwg.org</a><br>Subject: [tdwg-guid] Embedding LSID links within Publications<br><br><br>Thank you, Roger, for launching the next conversation I wanted to start<br>on<br>this list (not to interrupt the previous conversation....but this one is<br>actually more pressing for me right now): <br><br>> Would it be better to take the approach we have with LSIDs <br>> where we always cite a proxied version?<br>> <br>> What do other people do?<br><br>As many of you already know, I'm planning to publish the description of<br>five<br>new species of Chromis in Zootaxa on Jan 1 to:<br><br>- launch ZooBank<br>- Commemorate the 250th Anniversary of the start of Zoological<br>Nomenclature<br>- Create an "exemplar" cybertaxonomy publication<br><br>I was talking this up at Bratislava, and things are still on track.<br>Anyone<br>who wants to know more about the project, let me know and I'll send a<br>document describing it in more detail.<br><br>For now, I'll just provide a basic synopsis: This publication will<br>include<br>the first 5 zoological names proactively registered in ZooBank. As such,<br>there will be five ZooBank LSIDs, which I will want to include within<br>the<br>publication itself (published in both paper version to comply with ICZN<br>Code<br>rules; and as an online PDF version, which 99.9% of people will actually<br>read). The plan is to have the PDF version marked up as much as<br>possible,<br>with taXMLit & TaxonX markup files, SDD files for the character data,<br>ZooBank LSIDs, Images deposited in MorphBank, links to GenBank records<br>for<br>Barcode sequences, links to Museum specimen databases, links to BHL for<br>literature cited, etc., etc.<br><br>So....this will be a document intended to show what could be possible<br>with<br>all this TDWG stuff we've all be working on for all these years -- i.e.,<br>how<br>cybertaxonomy could/should be done in the age of the internet.<br><br>Now, the PDF file itself will be rather simple -- a standard PDF file as<br>per<br>normal Zootaxa practice -- except in this document, there will be MANY<br>embedded links that allow point-and-click access to all sorts of online<br>resources -- each of which will in some way showcase TDWG and TDWG-like<br>standards.<br><br>A bunch of these links will be LSIDs (e.g., ZooBank LSIDs, plus maybe<br>others). However, some of them may be other links (DOIs, URLs, etc.).<br>All<br>HTTP and other self-resolving links will be pretty straightforward, but<br>I'm<br>not sure yet how to embed links associated with the LSIDs.<br><br>Obviously, LSIDs are not, by themselves, completely self-resolving via<br>most<br>web browsers, so simply embedding the LSID as a link will not do the<br>average<br>user much good. Thus, I'm now thinking of how I can make the LSIDs<br>"clickable" from the PDF, to allow the cicker/user to be directed to<br>something meangiful. And that has caused me to think a lot about HTTP<br>proxies for LSIDs.<br><br>Thus, assuming I have a ZooBank LSID that is<br><a href="urn:lsid:zoobank.org:act:1234">urn:lsid:zoobank.org:act:1234</a>,<br>how do I represent that as a "clickable" link? One way to do this would<br>be<br>to embed the LSID within the TDWG HTTP proxy:<br><br><a href="http://lsid.tdwg.org/?urn:lsid:zoobank.org:act:1234">http://lsid.tdwg.org/?urn:lsid:zoobank.org:act:1234</a><br><br>However, what I'm shooting for is to have a document that can, as best<br>as<br>possible, withstand the test of time, such that 250 years from now, some<br>or<br>all of those embedded links will still work (I know, I know -- they<br>won't --<br>but humor me....) I'm a little neverous about simply assuming that the<br>TDWG<br>LSID resolver will still be around in 250 years. Besides, 99.9% of<br>users<br>will look at the returned RDF and scratch their heads.<br><br>My gut feeling is that LSIDs have a better chance of surviving the<br>long-term<br>than URLs do. And following this premise, the LSID<br>"<a href="urn:lsid:zoobank.org:act:1234">urn:lsid:zoobank.org:act:1234</a>" will only survive as long as the<br>authority<br>"zoobank.org" survives (in theory), so it seems to me a slightly more<br>appropriate solution would be to build a custom LSID resolver at<br>zoobank.org, and thereby format the clickable link as:<br><br><a href="http://zoobank.org/?lsid=urn:lsid:zoobank.org:act:1234">http://zoobank.org/?lsid=urn:lsid:zoobank.org:act:1234</a><br><br>Does this make sense to anyone? Am I missing something fundamental<br>here?<br>Is there a better way to embed clickable links to LSIDs in a PDF<br>document?<br><br>I have a bunch of other questions to follow up with, but let's tackle<br>this<br>one first.<br><br>Many thanks!!<br><br>Aloha,<br>Rich<br><br>Richard L. Pyle, PhD<br>Database Coordinator for Natural Sciences<br> and Associate Zoologist in Ichthyology<br>Department of Natural Sciences, Bishop Museum<br>1525 Bernice St., Honolulu, HI 96817<br>Ph: (808)848-4115, Fax: (808)847-8252<br>email: <a href="mailto:deepreef@bishopmuseum.org">deepreef@bishopmuseum.org</a><br><a href="http://hbs.bishopmuseum.org/staff/pylerichard.html">http://hbs.bishopmuseum.org/staff/pylerichard.html</a><br><br><br><br>_______________________________________________<br>tdwg-guid mailing list<br><a href="mailto:tdwg-guid@lists.tdwg.org">tdwg-guid@lists.tdwg.org</a><br><a href="http://lists.tdwg.org/mailman/listinfo/tdwg-guid">http://lists.tdwg.org/mailman/listinfo/tdwg-guid</a><br>_______________________________________________<br>tdwg-guid mailing list<br>tdwg-guid@lists.tdwg.org<br><a href="http://lists.tdwg.org/mailman/listinfo/tdwg-guid">http://lists.tdwg.org/mailman/listinfo/tdwg-guid</a><br></div></div></blockquote></div><br></div></div></body></html>