Kevin et al,

[This is a very long thread - I hope I have taken in enough of the comments to comment myself at this late stage.]

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?

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.

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?

Talking more about our use of LSIDs:

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.  

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:

1) Resolve the LSID using the standard DNS based mechanism - an LSID aware client.
2) Resolve the pixied version - a non LSID aware client.
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.

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 http://dx.doi.org/ - unlike the itself DOI ;) 

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!!!).

Hope this helps,

Roger







On 2 Dec 2007, at 20:28, Kevin Richards wrote:

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". 
 
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).
 
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).
 
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).
 
Kevin

>>> "Chuck Miller" <Chuck.Miller@mobot.org> 1/12/2007 6:18 a.m. >>>
How to turn LSIDs into a clickable link guaranteed to work forever?

Rich's vision:
http://<some proxy server>.org/?urn:lsid:zoobank.org:act:1234

This sounds to me like a question more about networking infrastructure,
than TDWG's charter about data exchange protocols and content standards.
I have always presumed that TDWG's standards would work using whatever
networking infrastructure was available to them - e.g. DNS, HTTP, local
provider servers, etc. 

But, then lsid.tdwg.org was created--a server. Servers are operational
infrastructure.  I don't think TDWG has (yet) a "forever" funding stream
to enable operational infrastructure - ongoing operation of server room,
system administrator, network connections.  But, something like
lsid.tdwg.org would serve a valuable purpose as Rich notes of enabling
LSIDs as a clickable link in publications or other online sources.

Is there an existing international body that could operate a forever
functioning LSID proxy (say like, proxy.lsid.org--which unfortunately is
already lost to Lindsay-Strathmore Irrigation District)?

Maybe we will be forced to accept that there is no "forever" on the
Internet and accept instead the "forseeable future".  I would think for
the forseeable future that GBIF would be a good place to put a new LSID
infrastructure like this since they are in the "operations center"
business already and TDWG is by charter not. So, maybe the proxy should
be lsid.gbif.org?

Chuck


-----Original Message-----
From: tdwg-guid-bounces@lists.tdwg.org
[mailto:tdwg-guid-bounces@lists.tdwg.org] On Behalf Of Richard Pyle
Sent: Friday, November 30, 2007 6:39 AM
To: 'Roger Hyam'; 'Roderic Page'
Cc: tdwg-guid@lists.tdwg.org
Subject: [tdwg-guid] Embedding LSID links within Publications


Thank you, Roger, for launching the next conversation I wanted to start
on
this list (not to interrupt the previous conversation....but this one is
actually more pressing for me right now):

> Would it be better to take the approach we have with LSIDs
> where we always cite a proxied version?
>
> What do other people do?

As many of you already know, I'm planning to publish the description of
five
new species of Chromis in Zootaxa on Jan 1 to:

- launch ZooBank
- Commemorate the 250th Anniversary of the start of Zoological
Nomenclature
- Create an "exemplar" cybertaxonomy publication

I was talking this up at Bratislava, and things are still on track.
Anyone
who wants to know more about the project, let me know and I'll send a
document describing it in more detail.

For now, I'll just provide a basic synopsis: This publication will
include
the first 5 zoological names proactively registered in ZooBank. As such,
there will be five ZooBank LSIDs, which I will want to include within
the
publication itself (published in both paper version to comply with ICZN
Code
rules; and as an online PDF version, which 99.9% of people will actually
read).  The plan is to have the PDF version marked up as much as
possible,
with taXMLit & TaxonX markup files, SDD files for the character data,
ZooBank LSIDs, Images deposited in MorphBank, links to GenBank records
for
Barcode sequences, links to Museum specimen databases, links to BHL for
literature cited, etc., etc.

So....this will be a document intended to show what could be possible
with
all this TDWG stuff we've all be working on for all these years -- i.e.,
how
cybertaxonomy could/should be done in the age of the internet.

Now, the PDF file itself will be rather simple -- a standard PDF file as
per
normal Zootaxa practice -- except in this document, there will be MANY
embedded links that allow point-and-click access to all sorts of online
resources -- each of which will in some way showcase TDWG and TDWG-like
standards.

A bunch of these links will be LSIDs (e.g., ZooBank LSIDs, plus maybe
others).  However, some of them may be other links (DOIs, URLs, etc.).
All
HTTP and other self-resolving links will be pretty straightforward, but
I'm
not sure yet how to embed links associated with the LSIDs.

Obviously, LSIDs are not, by themselves, completely self-resolving via
most
web browsers, so simply embedding the LSID as a link will not do the
average
user much good.  Thus, I'm now thinking of how I can make the LSIDs
"clickable" from the PDF, to allow the cicker/user to be directed to
something meangiful.  And that has caused me to think a lot about HTTP
proxies for LSIDs.

Thus, assuming I have a ZooBank LSID that is
urn:lsid:zoobank.org:act:1234,
how do I represent that as a "clickable" link?  One way to do this would
be
to embed the LSID within the TDWG HTTP proxy:

http://lsid.tdwg.org/?urn:lsid:zoobank.org:act:1234

However, what I'm shooting for is to have a document that can, as best
as
possible, withstand the test of time, such that 250 years from now, some
or
all of those embedded links will still work (I know, I know -- they
won't --
but humor me....) I'm a little neverous about simply assuming that the
TDWG
LSID resolver will still be around in 250 years.  Besides, 99.9% of
users
will look at the returned RDF and scratch their heads.

My gut feeling is that LSIDs have a better chance of surviving the
long-term
than URLs do.  And following this premise, the LSID
"urn:lsid:zoobank.org:act:1234" will only survive as long as the
authority
"zoobank.org" survives (in theory), so it seems to me a slightly more
appropriate solution would be to build a custom LSID resolver at
zoobank.org, and thereby format the clickable link as:

http://zoobank.org/?lsid=urn:lsid:zoobank.org:act:1234

Does this make sense to anyone?  Am I missing something fundamental
here?
Is there a better way to embed clickable links to LSIDs in a PDF
document?

I have a bunch of other questions to follow up with, but let's tackle
this
one first.

Many thanks!!

Aloha,
Rich

Richard L. Pyle, PhD
Database Coordinator for Natural Sciences
  and Associate Zoologist in Ichthyology
Department of Natural Sciences, Bishop Museum
1525 Bernice St., Honolulu, HI 96817
Ph: (808)848-4115, Fax: (808)847-8252
email: deepreef@bishopmuseum.org
http://hbs.bishopmuseum.org/staff/pylerichard.html



_______________________________________________
tdwg-guid mailing list
tdwg-guid@lists.tdwg.org
http://lists.tdwg.org/mailman/listinfo/tdwg-guid
_______________________________________________
tdwg-guid mailing list
tdwg-guid@lists.tdwg.org
http://lists.tdwg.org/mailman/listinfo/tdwg-guid