Dear Richard,

Quick comments on the metadata the LSID serves:

1. The dates in the TaxonName:publication section are a bit of a mess (one date lacks a year, and "11/26/1998 12:00:00 AM" is not an ISO standard date, it is also open to ambiguity given that the US writes month/day/year whereas Europeans write day/month/year). I think YYYY-MM-DD is the way to go to avoid major headaches. I've blogged about the mess DiGIR providers have created by not using ISO standard dates.

2. There's no journal name or ISSN so we don't know where this was published. I guess one could get this via the parent citation resource, but if you have all the other metadata included in the RDF, why not the journal?

3. The article in question has a DOI, hence it would be nice to link to that (doi:10.1007/BF02725185). I know you're working towards this, but without an external GUID for the publication I think nomenclators will be of limited use. Merely reproducing bibliographic metadata is ultimately an exercise in pain, given that most metadata contains errors or omissions, and the poor user has to dela with this when they try and track down the reference (or, more interestingly, try and link the literature together).

Regards

Rod

On 29 Nov 2007, at 18:04, Richard Pyle wrote:

Thanks Rod,

The two LSIDs in your links are truncated due to line wrap in my original message. They should be:

urn:lsid:zoobank.org:act:20889795-7EC7-42F3-A4C3-D1D97704A609

urn:lsid:bishopmuseum.org:tnu:20889795-7EC7-42F3-A4C3-D1D97704A609

Both have essentially identical WSDL data -- though it might be cached still from yesterday.

WSDL looks mostly the same as IPNI:

http://zoobank.bishopmuseum.org/authority/?lsid=urn:lsid:zoobank.org: act:208 89795-7EC7-42F3-A4C3-D1D97704A609

http://nsdb.bishopmuseum.org/authority/?lsid=urn:lsid: bishopmuseum.org:tnu:2 0889795-7EC7-42F3-A4C3-D1D97704A609

No doubt both of these will be truncated/line-wrapped as well....

Sally: might be DNS, but the DNS record hasn't changed for the ZooBank service since it was originally created, and I know it was working through the TDWG resolver back before/during Bratislava.

Lee: I've been pestering Kevin about other issues I ran into setting up the new nsdb LSID resolver, but I figured that the problem was with the TDWG resolver service, since Rod's tester seems to work fine on both (or am I missing something about your tester, Rod?) But now that I see that the nsdb LSIDs resolve through the TDWG site fine, I'm beginning to suspect the problem is with IIS on the ZooBank server. The Code really is identical (if anything, it should be broken on the nsdb version, not the zoobank version).

Hmmm....

Many thanks for all the feedback so far!

Aloha, Rich

---

From: Roderic Page [mailto:r.page@bio.gla.ac.uk] Sent: Wednesday, November 28, 2007 10:57 PM To: Richard Pyle Cc: tdwg-guid@lists.tdwg.org Subject: Re: [tdwg-guid] TDWG LSID Resolver broken?

Rich,

The authority WSDL looks to be empty. I can't get either LSIDs to work now with my tester. If you look at

http://nsdb.bishopmuseum.org/authority/?lsid=urn:lsid: bishopmuseum.org:tnu:2 0889795-7EC7-42F3-A4C3-D

or

http://zoobank.bishopmuseum.org/authority/?lsid=urn:lsid:zoobank.org: act:208 89795-7EC7-42F3-A4C3-D1D977

you'll see a pretty empty WSDL file. Compare this to, say, IPNI's:

http://www.ipni.org/authority/authority?lsid=urn:lsid:ipni.org:names: 2001272 8-1:1.1

I suspect there's a problem with Zoobank's code, and it might have taken a while to appear as my tester caches the WSDLs for 24 hours.

Regards

Rod

On 28 Nov 2007, at 23:27, Richard Pyle wrote:

VERY strange!

This LSID does not work:

http://lsid.tdwg.org/urn:lsid:zoobank.org:act:20889795-7EC7-42F3-A4C3- D1D977 04A609

But this one does:

http://lsid.tdwg.org/urn:lsid:bishopmuseum.org:tnu:20889795-7EC7-42F3- A4C3-D 1D97704A609

Even though these are the exact same record from the exact

same database, and the latter resolver was created from the exact same source code as the former.

Both seem to work fine on Rod's tester page, except the

latter has one failure (5a), while in the former it is just a warning.

Go figure....

Rich

________________________________

From: Paul Kirk [mailto:p.kirk@cabi.org]
Sent: Wednesday, November 28, 2007 11:57 AM
To: Richard Pyle
Subject: RE: [tdwg-guid] TDWG LSID Resolver broken?

Hi Rich,

works OK for IF LSIDs

http://lsid.tdwg.org/urn:lsid:indexfungorum.org:names:296755

http://lsid.tdwg.org/urn:lsid:indexfungorum.org:names:296755

Cheers,

Paul

________________________________

From: tdwg-guid-bounces@lists.tdwg.org on behalf of Richard

Pyle Sent: Wed 28/11/2007 21:52 To: tdwg-guid@lists.tdwg.org Subject: [tdwg-guid] TDWG LSID Resolver broken?

Hi All,

I'm testing the ZooBank LSID resolver, and I can't seem to

get any of my LSIDs to work with the TDWG LSID resolver (http://lsid.tdwg.org/) They used to work a couple months ago, but now they don't.

For example:

urn:lsid:zoobank.org:act:20889795-7EC7-42F3-A4C3-D1D97704A609

This works fine on Rod's Tester site:

http://linnaeus.zoology.gla.ac.uk/~rpage/lsid/tester/

Any ideas???

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

P Think Green - don't print this email unless you really

need to

---

• The information contained in this e-mail and any files

transmitted with it is confidential and is for the exclusive use of the intended recipient. If you are not the intended recipient please note that any distribution, copying or use of this communication or the information in it is prohibited.

Whilst CAB International trading as CABI takes steps to

prevent the transmission of viruses via e-mail, we cannot guarantee that any e-mail or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions.

If you have received this communication in error, please

notify us by e-mail at cabi@cabi.org or by telephone on +44 (0)1491 829199 and then delete the e-mail and any copies of it.

CABI is an International Organization recognised by the UK
Government under Statutory Instrument 1982 No. 1071.

---

---

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



----------------------------------------

Professor Roderic D. M. Page Editor, Systematic Biology DEEB, IBLS Graham Kerr Building University of Glasgow Glasgow G12 8QP United Kingdom

Phone: +44 141 330 4778 Fax: +44 141 330 2792 email: r.page@bio.gla.ac.uk web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html iChat: aim://rodpage1962 reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html

Subscribe to Systematic Biology through the Society of Systematic Biologists Website: http://systematicbiology.org Search for taxon names: http://darwin.zoology.gla.ac.uk/~rpage/portal/ Find out what we know about a species: http://ispecies.org Rod's rants on phyloinformatics: http://iphylo.blogspot.com Rod's rants on ants: http://semant.blogspot.com

------------------------------------------------------------------------ ---------------------------------------- Professor Roderic D. M. Page Editor, Systematic Biology DEEB, IBLS Graham Kerr Building University of Glasgow Glasgow G12 8QP United Kingdom

Phone: +44 141 330 4778 Fax: +44 141 330 2792 email: r.page@bio.gla.ac.uk web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html iChat: aim://rodpage1962 reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html

Subscribe to Systematic Biology through the Society of Systematic Biologists Website: http://systematicbiology.org Search for taxon names: http://darwin.zoology.gla.ac.uk/~rpage/portal/ Find out what we know about a species: http://ispecies.org Rod's rants on phyloinformatics: http://iphylo.blogspot.com Rod's rants on ants: http://semant.blogspot.com

Dear Chuck,

On 29 Nov 2007, at 18:54, Chuck Miller wrote:

Rod,

Although DOIs are really great and should be added by those who can, I think we have not choice but to accept the bibliographic data that exists and get on with collecting it, messy or not.

I'm not arguing against having bibliographic metadata -- I'm arguing for GUIDs, and that if they exist we should use them. There are a lot of DOIs out there, as well as Handles (DSpace repositories) and SICIs (served by JSTOR). If we link names to these we greatly increase the value of our resources.

I don't know that I agree with your hypothesis: "...without an external GUID for the publication I think nomenclators will be of limited use. Merely reproducing bibliographic metadata is ultimately an exercise in pain, given that most metadata contains errors or omissions..."

Is it true that *most* bibliographic metadata contains errors or omissions, or would it be true to say that *some* or *more than we'd like* metadata contain errors? And is it true that errors or omissions make nomenclators "of limited use"? I would agree that errors/omissions would surely limit use in some way, but I don't know that the magnitude of it rises to the level of declaring nomenclators "of limited use". Maybe it's just a semantic difference.

I rather overstated things perhaps -- obviously, nomenclators are very useful -- but based on my experience in finding existing DOIs for taxonomic literature, or harvesting large databases such as the AMNH's DSpace collection of publications, the number of times I encounter errors or ambiguities is enough to drive me nuts.

So, rather than letting my frustration get the better of me, what I should have said is that nomenclators can be even more useful if they use GUIDs for literature.

What I would very much NOT to see happen is nomenclators pump out LSID metadata that simply recycles bibliographic metadata. If this is all we do then we miss the point of LSIDs and RDF, namely integration. GUIDs, particularly universally used GUIDs make integration possible -- lots of metadata tags don't get us to this goal. Shared GUIDs do.

I think we have to accept that bibliographic metadata with errors or omissions is better than *no* bibliographic metadata and a nomenclator with some errors is better than *no* nomenclator. And, we need to continue to appeal for the *addition* of DOIs and such by those who can add them.

Agreed. I'm in the middle of working on several tools to help deal with this, such as a tool to match journal names (early version here http://bioguid.info/journal.php ), an OpenURL resolver to find GUIDs from metadata (early version here http://bioguid.info/openurl.php), and reference parsing tools (web version here http://bioguid.info/references/ , there is also a CGI interface being used by David Shorthouse's Ajax tools). These are all pretty crude, and I'm hoping to overhaul the OpenURL tool before the end of the year.

My sense is that, at least in the short term, our community needs to assign GUIDs for much of the existing taxonomic literature. These GUIDs need to be easy to assign to references, and easily discoverable. I don't think this is too difficult to do. We don't need to wait for DOIs to get this stuff off the ground.

Regards

Rod

Chuck

-----Original Message----- From: tdwg-guid-bounces@lists.tdwg.org [mailto:tdwg-guid-bounces@lists.tdwg.org] On Behalf Of Roderic Page Sent: Thursday, November 29, 2007 12:26 PM To: Richard Pyle Cc: tdwg-guid@lists.tdwg.org Subject: Re: [tdwg-guid] TDWG LSID Resolver broken?

Dear Richard,

Quick comments on the metadata the LSID serves:

1. The dates in the TaxonName:publication section are a bit of a mess

(one date lacks a year, and "11/26/1998 12:00:00 AM" is not an ISO standard date, it is also open to ambiguity given that the US writes month/day/year whereas Europeans write day/month/year). I think YYYY-MM-DD is the way to go to avoid major headaches. I've blogged about the mess DiGIR providers have created by not using ISO standard dates.

2. There's no journal name or ISSN so we don't know where this was

published. I guess one could get this via the parent citation resource,

but if you have all the other metadata included in the RDF, why not the

journal?

3. The article in question has a DOI, hence it would be nice to link to

that (doi:10.1007/BF02725185). I know you're working towards this, but without an external GUID for the publication I think nomenclators will be of limited use. Merely reproducing bibliographic metadata is ultimately an exercise in pain, given that most metadata contains errors or omissions, and the poor user has to dela with this when they try and track down the reference (or, more interestingly, try and link the literature together).

Regards

Rod

On 29 Nov 2007, at 18:04, Richard Pyle wrote:

...

Thanks Rod,

The two LSIDs in your links are truncated due to line wrap in my original message. They should be:

urn:lsid:zoobank.org:act:20889795-7EC7-42F3-A4C3-D1D97704A609

urn:lsid:bishopmuseum.org:tnu:20889795-7EC7-42F3-A4C3-D1D97704A609

Both have essentially identical WSDL data -- though it might be cached

...

still from yesterday.

WSDL looks mostly the same as IPNI:

http://zoobank.bishopmuseum.org/authority/?lsid=urn:lsid:zoobank.org: act:208 89795-7EC7-42F3-A4C3-D1D97704A609

http://nsdb.bishopmuseum.org/authority/?lsid=urn:lsid: bishopmuseum.org:tnu:2 0889795-7EC7-42F3-A4C3-D1D97704A609

No doubt both of these will be truncated/line-wrapped as well....

Sally: might be DNS, but the DNS record hasn't changed for the

ZooBank

...

service since it was originally created, and I know it was working through the TDWG resolver back before/during Bratislava.

Lee: I've been pestering Kevin about other issues I ran into setting

...

up the new nsdb LSID resolver, but I figured that the problem was with the TDWG resolver service, since Rod's tester seems to work fine on both (or am

...

I missing something about your tester, Rod?) But now that I see that the nsdb LSIDs resolve through the TDWG site fine, I'm beginning to suspect the problem is with IIS on the ZooBank server. The Code really is identical (if anything, it should be broken on the nsdb version, not the zoobank version).

Hmmm....

Many thanks for all the feedback so far!

Aloha, Rich

---

From: Roderic Page [mailto:r.page@bio.gla.ac.uk] Sent: Wednesday, November 28, 2007 10:57 PM To: Richard Pyle Cc: tdwg-guid@lists.tdwg.org Subject: Re: [tdwg-guid] TDWG LSID Resolver broken?

Rich,

The authority WSDL looks to be empty. I can't get either LSIDs

to

...

work now with my tester. If you look at

http://nsdb.bishopmuseum.org/authority/?lsid=urn:lsid: bishopmuseum.org:tnu:2 0889795-7EC7-42F3-A4C3-D

or

http://zoobank.bishopmuseum.org/authority/?lsid=urn:lsid:zoobank.org: act:208 89795-7EC7-42F3-A4C3-D1D977

you'll see a pretty empty WSDL file. Compare this to, say,

IPNI's:

...

http://www.ipni.org/authority/authority?lsid=urn:lsid:ipni.org:names: 2001272 8-1:1.1

I suspect there's a problem with Zoobank's code, and it might

have

...

taken a while to appear as my tester caches the WSDLs for 24 hours.

Regards

Rod

On 28 Nov 2007, at 23:27, Richard Pyle wrote:

VERY strange!

This LSID does not work:

http://lsid.tdwg.org/urn:lsid:zoobank.org:act:20889795-7EC7-42F3-A4C3-

...

D1D977 04A609

But this one does:

http://lsid.tdwg.org/urn:lsid:bishopmuseum.org:tnu:20889795-7EC7-42F3-

...

A4C3-D 1D97704A609

Even though these are the exact same record from the

exact

...

same database, and the latter resolver was created from the exact same source code as the former.

Both seem to work fine on Rod's tester page, except the

latter has one failure (5a), while in the former it is just a warning.

Go figure....

Rich

________________________________

From: Paul Kirk [mailto:p.kirk@cabi.org]
Sent: Wednesday, November 28, 2007 11:57 AM
To: Richard Pyle
Subject: RE: [tdwg-guid] TDWG LSID Resolver broken?

Hi Rich,

works OK for IF LSIDs

http://lsid.tdwg.org/urn:lsid:indexfungorum.org:names:296755

...

http://lsid.tdwg.org/urn:lsid:indexfungorum.org:names:296755

Cheers,

Paul

________________________________

From: tdwg-guid-bounces@lists.tdwg.org on behalf of

Richard

...

Pyle Sent: Wed 28/11/2007 21:52 To: tdwg-guid@lists.tdwg.org Subject: [tdwg-guid] TDWG LSID Resolver broken?

Hi All,

I'm testing the ZooBank LSID resolver, and I can't seem

to

...

get any of my LSIDs to work with the TDWG LSID resolver (http://lsid.tdwg.org/) They used to work a couple months ago, but now they don't.

For example:

urn:lsid:zoobank.org:act:20889795-7EC7-42F3-A4C3-D1D97704A609

This works fine on Rod's Tester site:

http://linnaeus.zoology.gla.ac.uk/~rpage/lsid/tester/

Any ideas???

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

P Think Green - don't print this email unless you really

need to

---

...

• The information contained in this e-mail and any files

transmitted with it is confidential and is for the exclusive use of

the

...

intended recipient. If you are not the intended recipient please

note

...

that any distribution, copying or use of this communication or

the

...

information in it is prohibited.

Whilst CAB International trading as CABI takes steps to

prevent the transmission of viruses via e-mail, we cannot guarantee

that

...

any e-mail or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions.

If you have received this communication in error, please

notify us by e-mail at cabi@cabi.org or by telephone on +44

(0)1491

...

829199 and then delete the e-mail and any copies of it.

CABI is an International Organization recognised by the

UK

...

Government under Statutory Instrument 1982 No. 1071.

---

...

---

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



----------------------------------------

Professor Roderic D. M. Page Editor, Systematic Biology DEEB, IBLS Graham Kerr Building University of Glasgow Glasgow G12 8QP United Kingdom

Phone: +44 141 330 4778 Fax: +44 141 330 2792 email: r.page@bio.gla.ac.uk web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html iChat: aim://rodpage1962 reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html

Subscribe to Systematic Biology through the Society of

Systematic

...

Biologists Website: http://systematicbiology.org Search for taxon names: http://darwin.zoology.gla.ac.uk/~rpage/portal/ Find out what we know about a species: http://ispecies.org Rod's rants on phyloinformatics: http://iphylo.blogspot.com Rod's rants on ants: http://semant.blogspot.com

---

---

Professor Roderic D. M. Page Editor, Systematic Biology DEEB, IBLS Graham Kerr Building University of Glasgow Glasgow G12 8QP United Kingdom

Phone: +44 141 330 4778 Fax: +44 141 330 2792 email: r.page@bio.gla.ac.uk web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html iChat: aim://rodpage1962 reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html

Subscribe to Systematic Biology through the Society of Systematic Biologists Website: http://systematicbiology.org Search for taxon names: http://darwin.zoology.gla.ac.uk/~rpage/portal/ Find out what we know about a species: http://ispecies.org Rod's rants on phyloinformatics: http://iphylo.blogspot.com Rod's rants on ants: http://semant.blogspot.com

---

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

------------------------------------------------------------------------ ---------------------------------------- Professor Roderic D. M. Page Editor, Systematic Biology DEEB, IBLS Graham Kerr Building University of Glasgow Glasgow G12 8QP United Kingdom

Phone: +44 141 330 4778 Fax: +44 141 330 2792 email: r.page@bio.gla.ac.uk web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html iChat: aim://rodpage1962 reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html

Subscribe to Systematic Biology through the Society of Systematic Biologists Website: http://systematicbiology.org Search for taxon names: http://darwin.zoology.gla.ac.uk/~rpage/portal/ Find out what we know about a species: http://ispecies.org Rod's rants on phyloinformatics: http://iphylo.blogspot.com Rod's rants on ants: http://semant.blogspot.com

Dear Rich,

That's a question for Kevin Richards, mostly. I guess a more general question is: how do we / should we automaticlly recurse up the "parentCitation" chain? My thinking is "yes", but I'm not completely sure how to represent that (nested?). I suppose I could flatten it out in the "parentCitationString" (which I only just now realized I havn't done yet -- must have been on a "todo" list that disappeared). But I wonder if there shouldn't be a more structured way of doing this for refs with n-number of parents/grandparents/etc.

From my perspective, if there is a GUID for the reference then I don't particularly care what the parent is (I can get that by querying the GUID for the reference).

If, however, there's no GUID then I would want all the relevant metadata to hand to be able to try and find one, I don't want to have to go up citation tree to get the journal name, I just want to take the bibliographic metadata in the RDF for the name and search for the GUID (e.g., using an OpenURL resolver).

...

3. The article in question has a DOI, hence it would be nice

to link to that (doi:10.1007/BF02725185). I know you're working towards this, but without an external GUID for the publication I think nomenclators will be of limited use.

Agreed -- and yes, I am headed that way -- just limited to 24hrs/day right now -- only 22hrs/day, when you subtract sleep.... :-)

You get to sleep -- luxury! ;-)

Anyway, many thanks....

Also: something I thought you would comment on, and what I've been meaning to ask this list: How to deal with HTML tags within data values? Note that the title: "<i>Belonoperca pylei</i>, a new species of seabass (Teleostei: Serranidae: Epinephelinae: Diploprionini) from the Cook Islands with comments on relationships among diploprionins"

I markup the original data field with "...<i>...</i>..." tags to denote italics, but I'm not sure what to do with those tags when piping out metadata in RDF. I could strip them easily enough --- but should I?

Personally I would strip out any formatting, especially from a field that will be interpreted by other software. Furthermore, what would you do if the metadata gets served in another format, such as n3, or JSON, etc.?

Regards

Rod

Thoughts/comments welcome....

Aloha, Rich

------------------------------------------------------------------------ ---------------------------------------- Professor Roderic D. M. Page Editor, Systematic Biology DEEB, IBLS Graham Kerr Building University of Glasgow Glasgow G12 8QP United Kingdom

Phone: +44 141 330 4778 Fax: +44 141 330 2792 email: r.page@bio.gla.ac.uk web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html iChat: aim://rodpage1962 reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html

Subscribe to Systematic Biology through the Society of Systematic Biologists Website: http://systematicbiology.org Search for taxon names: http://darwin.zoology.gla.ac.uk/~rpage/portal/ Find out what we know about a species: http://ispecies.org Rod's rants on phyloinformatics: http://iphylo.blogspot.com Rod's rants on ants: http://semant.blogspot.com

Dear Rich,

I'm not quit sure I understand "flattened". If you are asking whether the entire citation should be written as one string, e.g.

Baldwin, C. C. and W. L. Smith (1998). Belonoperca pylei , a new species of seabass (Teleostei: Serranidae: Epinephelinae: Diploprionini) from the cook islands with comments on relationships among diploprionins. Ichthyological Research 45(4):325-339.

such as would be included in a Dublin Core tag dcterms:bibliographicCitation then I think this would be a BAD THING. By all means have this as an additional element, but keep the individual bibliographic elements (volume, issue, pagination, etc) separate. This greatly simplifies the task of anybody trying to find the reference, or assign a GUID.

If by flat you mean that the journal information is a link to another LSID for the journal, rather than containing a string for the journal name, to me it seems needlessly complex not to include the journal name in the RDF that has the rest of the bibliographic information (that is, as well as any link to the journal). The ISSN is already included, which applies to the journal not the article, so if the idea was to cleanly separate articles from containing journals, then the model has already failed to do that.

Lastly, I'm sure I missed the discussion, but I don't see why the RDF at http://rs.tdwg.org/ontology/voc/PublicationCitation has it's own vocabulary, rather than using existing vocabularies such as Dublin Core (see http://dublincore.org/documents/dc-citation-guidelines/) and PRISM. Another aspect of integration is sharing vocabulary as well as GUIDs.

Compare

http://nsdb.bishopmuseum.org/authority/metadata/? lsid=urn:lsid:bishopmuseum.org:tnu:20889795-7EC7-42F3-A4C3-D1D97704A609

with

http://www.connotea.org/rss/uri/876ae25827e2e94426845b277686efca

Wonder which one is more likely to be integrated into other databases...?

Regards

Rod

On 29 Nov 2007, at 20:45, Richard Pyle wrote:

Hi Rod,

...

If, however, there's no GUID then I would want all the relevant metadata to hand to be able to try and find one, I don't want to have to go up citation tree to get the journal name, I just want to take the bibliographic metadata in the RDF for the name and search for the GUID (e.g., using an OpenURL resolver).

Right -- and I agree. But my question was whether the citation tree should merely be "flattened" ("collapsed"?) into a single text string that is instered into "parentCitationString", or should there be some sort of nested structure to accommodate each level in the tree. My gut feeling -- at least for now (and for simplicity), is to collapse it into a single text value.

...

You get to sleep -- luxury! ;-)

:-)

Actually, I have to confess: I had 11 hours of sleep last night. After a marathon week, I often just collapse on the sofa when I get home, and don't open my eyes again until the next morning.

...

Personally I would strip out any formatting, especially from a field that will be interpreted by other software. Furthermore, what would you do if the metadata gets served in another format, such as n3, or JSON, etc.?

I tend to agree -- but I wanted to get a sense for what others were doing.

Aloha, Rich

---------------------------------------- Professor Roderic D. M. Page Editor, Systematic Biology DEEB, IBLS Graham Kerr Building University of Glasgow Glasgow G12 8QP United Kingdom

Phone: +44 141 330 4778 Fax: +44 141 330 2792 email: r.page@bio.gla.ac.uk web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html iChat: aim://rodpage1962 reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html

Subscribe to Systematic Biology through the Society of Systematic Biologists Website: http://systematicbiology.org Search for taxon names: http://darwin.zoology.gla.ac.uk/~rpage/portal/ Find out what we know about a species: http://ispecies.org Rod's rants on phyloinformatics: http://iphylo.blogspot.com Rod's rants on ants: http://semant.blogspot.com

Dear Rich,

Pyle, R.L. 2002. Pomacanthidae. pp. 3266-3286. In: Carpenter, K.E. and V.E. Niem (Eds.) Living marine resources of the western central Pacific. Volume 5. Bony fishes part 3 (Menidae to Pomacentridae). Food and Agriculture Organization of the United Nations (FAO), Rome. i-iv+2791-3379.

...there are at least three "levels" of publication:

1. Pyle, R.L. 2002. Pomacanthidae. pp. 3266-3286.

2. Carpenter, K.E. and V.E. Niem (Eds.) Living marine resources of the

western central Pacific. Volume 5. Bony fishes part 3 (Menidae to Pomacentridae). Food and Agriculture Organization of the United Nations (FAO), Rome. i-iv+2791-3379.

3. Carpenter, K.E. and V.E. Niem (Eds.) FAO species identification

guide for fishery purposes: Living marine resources of the western central Pacific. Vols. 1-6. Food and Agriculture Organization of the United Nations (FAO), Rome. xl+4218 pp.

Granted, some might argue that number 3 is not really a separate citable "unit", but given that it is a single page number series, I would argue that it is.

So...if we wanted to cite specifically Pyle 2002, the parentCitationString might simply be the contents of of #2 above; or it might have two nested parents (a parent, and agrand parent).

As I said before, I'm leaning towards the simpler solution.

Isn't this over engineering things a little? Don't you just need a GUID for the chapter (1), and a GUID for the book (2)? For the latter we have an ISBN (9251043879), so there's already a GUID for that. I don't think we gain much from (3). Furthermore, if we use the ISBN as the GUID we know the items are linked because they share the same publisher code.

As for the ZooBank LSID resolver -- at this point in time conformance trumps optimization (so we can all get off our collective arses and serve content) -- so I'm just woking with what's up there now. If I'm resolving LSIDs, and I'm doing so because of TDWG standards, then I ought to conform to existing TDWG standards on vocabularies -- right or wrong. What we need to do is update the TDWG standards on this (which the St. Lousi meeting was attempting to accomplish), so we can conform *and* optimize!

The TDWG standard should need to be expanded to handle other kinds of GUIDs, notably Handles, which are being widely used in Digital Repositories.

Regards

Rod

Aloha, Rich

---------------------------------------- Professor Roderic D. M. Page Editor, Systematic Biology DEEB, IBLS Graham Kerr Building University of Glasgow Glasgow G12 8QP United Kingdom

Phone: +44 141 330 4778 Fax: +44 141 330 2792 email: r.page@bio.gla.ac.uk web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html iChat: aim://rodpage1962 reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html

Subscribe to Systematic Biology through the Society of Systematic Biologists Website: http://systematicbiology.org Search for taxon names: http://darwin.zoology.gla.ac.uk/~rpage/portal/ Find out what we know about a species: http://ispecies.org Rod's rants on phyloinformatics: http://iphylo.blogspot.com Rod's rants on ants: http://semant.blogspot.com

Dear Roger,

On 30 Nov 2007, at 09:48, Roger Hyam wrote:

Sorry I have come into this thread late. It looks really exciting stuff.

The one thing I pick up on at the end was Rod offering to come up with a policy for handling Handles in the RDF returned by LSIDs ;)

:-O

I had previously presumed DOI and Handles could be treated as URIs and therefore just used as rdf resources like this:

<dc:identifier rdf:resource="doi:10.1007/BF02725185" />

or in our current example

<tdwg:parentPublication rdf:resource="doi:10.1007/BF02725185" />

My off-the-cuff comment was inspired by seeing a tag <doi> in the ontology. If you have DOIs, why not Handles, or any other GUID? Personally I would just use dc:identifier

Now if we can't treat DOI/Handle as URIs I guess we could treat them as strings and just use the dc identifier (possibly the worst case scenario - this could be an ISBN, local catalogue code or anything).

dc:identifierdoi:10.1007/BF02725185</dc:identifier>

I'm leaning towards this (or a standard representation, see below) because if there are multiple DOI resolvers (and there are a couple out there) and people use different ones, we need to decide whether the identifier is the same. My feeling is that RDF populated by links to URIs, while being Semantic Web savvy, will actually break because many of these URIs will be fragile, or there may be multiple URIs that point to the same thing. I think we may be heading for an unholy mess of URIs, especially as we have lots of distributed databases serving related information.

Put another way, if I aggregate a bunch of RDF from multiple sources and want to find anything related to a paper, it would be much easier to find things that refer to the same DOI in the same way.

I presume support for DOI/Handle would have to be added to any semantic web clients to understand any of these.

Would it be better to take the approach we have with LSIDs where we always cite a proxied version?

What if the proxy goes away?

Is there an expectation that the proxied version will serve RDF?

What do other people do?

Connotea uses the INFO URI scheme, which is also used by OpenURL. It's a bit ugly, but at least is standardised. In this example the DOI would be

info:doi/10.1007/BF02725185

This scheme also supports Handles and SICIs, as well and GenBank sequences, and a few other identifiers (see http://info-uri.info/ registry/OAIHandler?verb=ListRecords&metadataPrefix=oai_dc).

We could add a global property so that any object could have one or hasHandle value.

Any solution other than making Handles behave like regular URIs means non-compliance with W3C recommendations and the need for specialist client software I think.

What do you think? Any ideas?

There seem to be at least two ways to approach this problem:

1. Write identifiers as strings in a canonical form likely to be shared by other databases, and leave it to client software to know how to handle them

2. Have a global proxy server for all classes of identifiers that we might have, and have this return RDF (and do 303 redirects, or whatever the Semantic Web community settle on). This was the motivation behind my experiments with http://bioguid.info .

Hope this makes sense...

Regards

Rod

Roger

On 30 Nov 2007, at 08:10, Roderic Page wrote:

...

Dear Rich,

...

Pyle, R.L. 2002. Pomacanthidae. pp. 3266-3286. In: Carpenter, K.E. and V.E. Niem (Eds.) Living marine resources of the western central Pacific. Volume 5. Bony fishes part 3 (Menidae to Pomacentridae). Food and Agriculture Organization of the United Nations (FAO), Rome. i-iv+2791-3379.

...there are at least three "levels" of publication:

1. Pyle, R.L. 2002. Pomacanthidae. pp. 3266-3286.

2. Carpenter, K.E. and V.E. Niem (Eds.) Living marine resources

of the western central Pacific. Volume 5. Bony fishes part 3 (Menidae to Pomacentridae). Food and Agriculture Organization of the United Nations (FAO), Rome. i-iv+2791-3379.

3. Carpenter, K.E. and V.E. Niem (Eds.) FAO species

identification guide for fishery purposes: Living marine resources of the western central Pacific. Vols. 1-6. Food and Agriculture Organization of the United Nations (FAO), Rome. xl+4218 pp.

Granted, some might argue that number 3 is not really a separate citable "unit", but given that it is a single page number series, I would argue that it is.

So...if we wanted to cite specifically Pyle 2002, the parentCitationString might simply be the contents of of #2 above; or it might have two nested parents (a parent, and agrand parent).

As I said before, I'm leaning towards the simpler solution.

Isn't this over engineering things a little? Don't you just need a GUID for the chapter (1), and a GUID for the book (2)? For the latter we have an ISBN (9251043879), so there's already a GUID for that. I don't think we gain much from (3). Furthermore, if we use the ISBN as the GUID we know the items are linked because they share the same publisher code.

...

As for the ZooBank LSID resolver -- at this point in time conformance trumps optimization (so we can all get off our collective arses and serve content) -- so I'm just woking with what's up there now. If I'm resolving LSIDs, and I'm doing so because of TDWG standards, then I ought to conform to existing TDWG standards on vocabularies -- right or wrong. What we need to do is update the TDWG standards on this (which the St. Lousi meeting was attempting to accomplish), so we can conform *and* optimize!

The TDWG standard should need to be expanded to handle other kinds of GUIDs, notably Handles, which are being widely used in Digital Repositories.

Regards

Rod

...

Aloha, Rich

---

Professor Roderic D. M. Page Editor, Systematic Biology DEEB, IBLS Graham Kerr Building University of Glasgow Glasgow G12 8QP United Kingdom

Phone: +44 141 330 4778 Fax: +44 141 330 2792 email: r.page@bio.gla.ac.uk web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html iChat: aim://rodpage1962 reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html

Subscribe to Systematic Biology through the Society of Systematic Biologists Website: http://systematicbiology.org Search for taxon names: http://darwin.zoology.gla.ac.uk/~rpage/ portal/ Find out what we know about a species: http://ispecies.org Rod's rants on phyloinformatics: http://iphylo.blogspot.com Rod's rants on ants: http://semant.blogspot.com

---

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

---------------------------------------- Professor Roderic D. M. Page Editor, Systematic Biology DEEB, IBLS Graham Kerr Building University of Glasgow Glasgow G12 8QP United Kingdom

Phone: +44 141 330 4778 Fax: +44 141 330 2792 email: r.page@bio.gla.ac.uk web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html iChat: aim://rodpage1962 reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html

Subscribe to Systematic Biology through the Society of Systematic Biologists Website: http://systematicbiology.org Search for taxon names: http://darwin.zoology.gla.ac.uk/~rpage/portal/ Find out what we know about a species: http://ispecies.org Rod's rants on phyloinformatics: http://iphylo.blogspot.com Rod's rants on ants: http://semant.blogspot.com

Oh, and why is

<tdwg:parentPublication rdf:resource="doi:10.1007/BF02725185" />

the parent? Am I missing something? The citation in question IS the publication, so it gets the DOI, not it's parent.

Is the bibliography trying to have a tree, e.g.: page -> article -> journal

If it is, then *gack*. The potential for confusion is pretty large -- is Richard's metadata about the journal article or a page in the article, and how would I know?

I tried to investigate this further but the Wiki http://wiki.tdwg.org/ twiki/bin/view/TAG/OntDiscussPublicationCitationPublicationCitation is down.

Regards

Rod

Now if we can't treat DOI/Handle as URIs I guess we could treat them as strings and just use the dc identifier (possibly the worst case scenario - this could be an ISBN, local catalogue code or anything).

dc:identifierdoi:10.1007/BF02725185</dc:identifier>

I presume support for DOI/Handle would have to be added to any semantic web clients to understand any of these.

Would it be better to take the approach we have with LSIDs where we always cite a proxied version?

What do other people do?

We could add a global property so that any object could have one or hasHandle value.

Any solution other than making Handles behave like regular URIs means non-compliance with W3C recommendations and the need for specialist client software I think.

What do you think? Any ideas?

Roger

On 30 Nov 2007, at 08:10, Roderic Page wrote:

...

Dear Rich,

...

Pyle, R.L. 2002. Pomacanthidae. pp. 3266-3286. In: Carpenter, K.E. and V.E. Niem (Eds.) Living marine resources of the western central Pacific. Volume 5. Bony fishes part 3 (Menidae to Pomacentridae). Food and Agriculture Organization of the United Nations (FAO), Rome. i-iv+2791-3379.

...there are at least three "levels" of publication:

1. Pyle, R.L. 2002. Pomacanthidae. pp. 3266-3286.

2. Carpenter, K.E. and V.E. Niem (Eds.) Living marine resources

of the western central Pacific. Volume 5. Bony fishes part 3 (Menidae to Pomacentridae). Food and Agriculture Organization of the United Nations (FAO), Rome. i-iv+2791-3379.

3. Carpenter, K.E. and V.E. Niem (Eds.) FAO species

identification guide for fishery purposes: Living marine resources of the western central Pacific. Vols. 1-6. Food and Agriculture Organization of the United Nations (FAO), Rome. xl+4218 pp.

Granted, some might argue that number 3 is not really a separate citable "unit", but given that it is a single page number series, I would argue that it is.

So...if we wanted to cite specifically Pyle 2002, the parentCitationString might simply be the contents of of #2 above; or it might have two nested parents (a parent, and agrand parent).

As I said before, I'm leaning towards the simpler solution.

Isn't this over engineering things a little? Don't you just need a GUID for the chapter (1), and a GUID for the book (2)? For the latter we have an ISBN (9251043879), so there's already a GUID for that. I don't think we gain much from (3). Furthermore, if we use the ISBN as the GUID we know the items are linked because they share the same publisher code.

...

As for the ZooBank LSID resolver -- at this point in time conformance trumps optimization (so we can all get off our collective arses and serve content) -- so I'm just woking with what's up there now. If I'm resolving LSIDs, and I'm doing so because of TDWG standards, then I ought to conform to existing TDWG standards on vocabularies -- right or wrong. What we need to do is update the TDWG standards on this (which the St. Lousi meeting was attempting to accomplish), so we can conform *and* optimize!

The TDWG standard should need to be expanded to handle other kinds of GUIDs, notably Handles, which are being widely used in Digital Repositories.

Regards

Rod

...

Aloha, Rich

---

Professor Roderic D. M. Page Editor, Systematic Biology DEEB, IBLS Graham Kerr Building University of Glasgow Glasgow G12 8QP United Kingdom

Phone: +44 141 330 4778 Fax: +44 141 330 2792 email: r.page@bio.gla.ac.uk web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html iChat: aim://rodpage1962 reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html

Subscribe to Systematic Biology through the Society of Systematic Biologists Website: http://systematicbiology.org Search for taxon names: http://darwin.zoology.gla.ac.uk/~rpage/ portal/ Find out what we know about a species: http://ispecies.org Rod's rants on phyloinformatics: http://iphylo.blogspot.com Rod's rants on ants: http://semant.blogspot.com

---

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

---------------------------------------- Professor Roderic D. M. Page Editor, Systematic Biology DEEB, IBLS Graham Kerr Building University of Glasgow Glasgow G12 8QP United Kingdom

Phone: +44 141 330 4778 Fax: +44 141 330 2792 email: r.page@bio.gla.ac.uk web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html iChat: aim://rodpage1962 reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html

Subscribe to Systematic Biology through the Society of Systematic Biologists Website: http://systematicbiology.org Search for taxon names: http://darwin.zoology.gla.ac.uk/~rpage/portal/ Find out what we know about a species: http://ispecies.org Rod's rants on phyloinformatics: http://iphylo.blogspot.com Rod's rants on ants: http://semant.blogspot.com

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

Hi Ricardo,

Thanks for chiming in!

That's one way, yes. But recommendations 34 and 35 on section 10.1 and 10.2 of the LSID Applicability Statement describe a more standard way of representing LSIDs as clickable links. In short, the document recommends that you use the LSID in its pure form as the link text and the proxy version as the link URL. Below are the link to the document and the text of recommendation #34:

Yes, this is exactly what I had planned to do for the five ZooBank LSIDs, as per the guidelines (sorry I wasn't more explicit about this). I was mostly concerned with how to establish the proxy itself -- i.e., whether to use the TDWG Proxy or build one on the same domain as the authority part of the LSID (which seems to me a more stable alternative, given that authority & domain are more likely live or die together -- thereby effectively having one opportunity to fail, instead of two -- or perhaps more correctly, 1.2 opportunites to fail, instead of two, given that it's possible for a proxy to break without the LSID resolver breaking, and vice versa). I also planned to include the little LSID icon with a link to an explanation of LSIDs, as per recommendations.

However, your comment leads me to another set of questions I wanted to ask this group, which I'll pose in a separate email.

No problem. You can use any HTTP proxy you want. The key is that the LSID must remain associated with your fine objects forever regardless of whether the proxy (or HTTP) will be around or not.

Agreed -- and this is part of my response to Chuck (which, again, I'll send under a seprate email).

If you want to set up your own LSID HTTP proxy, let me know, I can help

you.

Yes! Thank you! I'll be in touch with you on this in a couple weeks.

That's another problem that I think is related to Greg Riccardi's requirements for LSID citation text and links, and that is still open. Maybe we should address that issue in another thread...

No problem -- as long as we come up with an answer in the next two weeks that will stand as the right answer for the next 250 years, then I'll be happy!

:-)

I would just advise you to code your proxy so that question marks (?) and equal signs (=) are not needed. The parameter name "lsid" is also redundant, so it could be omitted. In other words, you should code your proxy to resolve LSIDs using URLs as in the example below:

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

That can be accomplished by some tricks on your resolver script and web server.

This is one of the things I'll need your help with (keeping in mind that I'm not a real web developer -- I only pretend to be one so I can pay the mortgage).

Many thanks again for your input, and offer to help on developing the proxy.

Rich

Dear Rich,

There are several issues here.

Personally I think we need to look way beyond the lifetime of LSIDs and HTTP. One reason digital library types like DOIs and Handles is that they serve as GUIDs independently of any protocol. They are printed in journal articles as bare identifiers, in the same way as ISSNs or ISBNs. Hence tying the LSID to a HTTP resolver strikes me as the quickest way to build in obsolescence.

I suspect that a betting person would put money on the paper version of your article outlasting any digital representation you create...

One approach is to do something like COinS (ContextObjects in Spans, http://ocoins.info/ ). This embeds citation metadata in HTML pages using OpenURL. However, it doesn't specify the OpenURL resolver. The user supplies this, for examples, there is a Firefox extension that rewrites COinS as clickable links (http://www.openly.com/ openurlref/ ). Here's an example of a COinS:

<span class="Z3988" title="ctx_ver=Z39.88-2004&amp;rft_val_fmt=info% 3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&amp;rft.issn=1045-4438"></span>

The OpenURL syntax is horrible, but I hope you get the idea. Hence, what if the LSID was embedded like this:

<span class="lsid" title="urn:lsid:zoobank.org:act:1A66BAE9-9B37-4C73- A560-BF63D0345F04"></span>

This avoids the need to specify a resolver (at the cost of needing a tool to make the links clickable). However, it may help ensure long term survival of the identifier.

I think the focus on PDFs is misplaced. This is a binary format that may well be unintelligible in 10-20 years time. XML makes more sense. If the PDF has clickable URLs that work today, that's fine as a demo, but long term this stuff all needs to move to XML.

Lastly, why not simply do something like this in the text of the paper.

Chromis xus sp nov urn:lsid:zoobank.org:act:1A66BAE9-9B37-4C73-A560-BF63D0345F04

---text goes here---

I suspect you will need to show the identifier for people to grasp what is going on. Yes, ultimately the GUIDs will disappear, but it seems that at this stage you want to show them off. You might regret UUIDs now ;-)

Regards

Rod

On 30 Nov 2007, at 22:07, Richard Pyle wrote:

Ricardo's email prompted me to launch into the next round of questions concerning the implementation of LSIDs in real-world taxonomy. His comment was this:

...

In short, the document recommends that you use the LSID in its pure form as the link text and the proxy version as the link URL.

I have long believed that GUIDs (and especially LSIDs) were meant for use by computers, not humans. As such, I am generally opposed to the idea of printing or displaying LSIDs in a way intended for humans to read them. They should be hidden, behind the scenes, enebling the cross-links.

In the case of the five new species of Chromis, I think it's appropriate to display the ID's in the human-readable parts of the document, because these are technically the ZooBank Registration IDs for the nomencatural acts.

However, here is where the first question comes in. As I've described previously, my strategy with ZooBank is to assign UUIDs to the records, and then use the UUIDs as the "ObjectID" part of the LSID, such as:

urn:lsid:zoobank.org:act:20889795-7EC7-42F3-A4C3-D1D97704A609

The idea behind using UUIDs is to "hedge my bets" agaisnt the possible demise of the LSID standard. In this sense, the LSID syntaxt is really just a wrapper representing a resolution protocol for the "real" GUID, which in this case is the UUID.

So....if I am to print/display the "ZooBank Registration ID", what should it be? The full LSID (which is placing a bet that LSIDs will still be recognizable/resolvable 250 years from now); or just the UUID (which is the "true" GUID for the ZooBank record, independent of the mechanism used to resolve it)?

Let's assume, based on the other thread discussion, that I will be wrapping the LSID within an HTTP proxy to make it clickable for the URL part of the hyperlink. The question is, what do I show the human reader? Options are:

<a href="http://zoobank.org/urn:lsid:zoobank.org:act: 20889795-7EC7-42F3-A4C3-D1 D97704A609">20889795-7EC7-42F3-A4C3-D1D97704A609</a>

OR:

<a href="http://zoobank.org/urn:lsid:zoobank.org:act: 20889795-7EC7-42F3-A4C3-D1 D97704A609">urn:lsid:zoobank.org:act:20889795-7EC7-42F3-A4C3- D1D97704A609</a

...

<a href="http://lsids.sourceforge.net/"><img

src="http://zoobank.bishopmuseum.org/images/lsidlogo.jpg"></a>

...the main difference being whether the human sees the "ZooBank Registration ID" (UUID), or sees the "ZooBank LSID" (=ZooBank RegistrationID wrapped in LSID syntax)?

I'm torn on this -- part of me wants to keep it to just the UUID (which makes the publication look slightly less stupid 250 years from now, in the event that LSIDs do not last more than a few years); but the other part of me wants to trumpet the notion of LSIDs to support the general TDWG cause, and hence set an example of representing ZooBank Ids as LSIDs, rather than stripped-down UUIDs.

Thoughts?

This also sets me up for the next related question:

Though I can see the justification for displaying, in human readable form, an LSID/UUID that serves as a "ZooBank Registration ID" within the context of the actual pblication that "creates" the identified nomenclatural act....I'm not expecially inclined to sprinkle such cumbersome LSIDs in human-readible form throughout the entire document.

For example, consider this sentence from the Introduction of the Chromis MS:

"The pomacentrid genus Chromis Cuvier 1814 (type species Sparus chromis Linnaeus 1758) is the largest genus of the family, with 86 valid species."

One way to mark this up would be as follows:

"The pomacentrid genus <i><a href="http://zoobank.org/ urn:lsid:zoobank.org:act:B8F9F80D-5798-4342-810D-D8 274164F8F1">Chromis</a></i> Cuvier 1814 (type species <i><a href="http://zoobank.org/urn:lsid:zoobank.org:act: 1A66BAE9-9B37-4C73-A560-BF 63D0345F04">Sparus</a></i> <i><a href="http://zoobank.org/urn:lsid:zoobank.org:act: 8F966156-68DE-4147-953D-74 E1B3724F5F">chromis</a></i> Linnaeus 1758) is the largest genus of the family, with 86 valid species."

This would appear to the user exactly the same as the above quote, except the three taxon names would be clickable links to the repsective ZooBank records.

The alternative would be to do something like this:

"The pomacentrid genus <i>Chromis</i> [<a href="http://zoobank.org/ urn:lsid:zoobank.org:act:B8F9F80D-5798-4342-810D-D8 274164F8F1">ZooBank: B8F9F80D-5798-4342-810D-D8274164F8F1</a>] Cuvier 1814 (type species <i>Sparus</i> [<a href="http://zoobank.org/urn:lsid:zoobank.org:act: 1A66BAE9-9B37-4C73-A560-BF 63D0345F04">ZooBank: 1A66BAE9-9B37-4C73-A560-BF63D0345F04</a>] <i>chromis</i> [<a href="http://zoobank.org/urn:lsid:zoobank.org:act: 8F966156-68DE-4147-953D-74 E1B3724F5F">ZooBank: 8F966156-68DE-4147-953D-74E1B3724F5F</a>] Linnaeus 1758) is the largest genus of the family, with 86 valid species."

To the human reader, this would appear as follows:

"The pomacentrid genus Chromis [ZooBank: B8F9F80D-5798-4342-810D-D8274164F8F1] Cuvier 1814 (type species Sparus [ZooBank: 1A66BAE9-9B37-4C73-A560-BF63D0345F04] chromis [ZooBank: 8F966156-68DE-4147-953D-74E1B3724F5F] Linnaeus 1758) is the largest genus of the family, with 86 valid species."

Kinda klunky, if you ask me -- even moreso if the full LSID syntax is included -- and more klunky still if I add the little "LSID" icon logos to each one.

My preference would be to go with the first option, and simply make the text of the names the clickable part, and have the UUID/LSID hidden from the user (but still visible to the computer) via the embedded HTTP proxy link.

But if I go that route this leads to another problem:

Because ICZN still requires paper-based publication for the new names to be available, there will also be a paper version published concurrently (standatd Zootaxa practice). If the GUIDs are not visible to the human in the PDF, they will not be visible at all in the paper copy.

So....I'm now considering adding an extra section to the published version of the article (both paper and PDF), that comes after the "Literature Cited" section, and represents a series of "end notes", indexed from the text via superscript numbers, that display in human readible form the complete URL of the link.

For example, something along the lines of the following:

"The pomacentrid genus <i>Chromis </i> ^{<a href="http://zoobank.org/ urn:lsid:zoobank.org:act:B8F9F80D-5798-4342-810D-D8 274164F8F1">1</a>} Cuvier 1814 (type species <i>Sparus</i> ^{<a href="http://zoobank.org/urn:lsid:zoobank.org:act: 1A66BAE9-9B37-4C73-A560-BF 63D0345F04">2</a>} <i>chromis</i> ^{<a href="http://zoobank.org/urn:lsid:zoobank.org:act: 8F966156-68DE-4147-953D-74 E1B3724F5F">chromis</a>} Linnaeus 1758) is the largest genus of the family, with 86 valid species."

Which would appear to the user simply as:

"The pomacentrid genus Chromis^1 Cuvier 1814 (type species Sparus^2 chromis^3 Linnaeus 1758) is the largest genus of the family, with 86 valid species."

(where "^" indicates superscripted character)

The "1", "2" and "3" would be the clickale links to the online resources, but at the end of the article there would ba a section called "Linked Resources" or something, along the lines of the following:

Linked Resources:

http://zoobank.org/urn:lsid:zoobank.org:act:B8F9F80D-5798-4342-810D- D8274164 F8F1 2. http://zoobank.org/urn:lsid:zoobank.org:act:1A66BAE9-9B37-4C73-A560- BF63D034 5F04 3. http://zoobank.org/urn:lsid:zoobank.org:act: 8F966156-68DE-4147-953D-74E1B372 4F5F

That way, the reader of the paper copy of the publication could, if they wanted to, manually type the various links into a browser.

This seems like the best compromise solution to me; but there is one problem:

If the superscript "1", "2", "3" etc are the clicable links, that makes for a very small tarket. People not so dexterous with the mouse control might be annoyed trying to click on the tiny little number. So I'm thinking maybe a little Icon similar to the LSID icon (http://zoobank.bishopmuseum.org/images/lsidlogo.jpg), except numbered. That would make for an easier mouse target to click on, and also would distinguish it from other superscript numbers (footnotes, etc.). Alternatively, I could simply make the superscript hyperlinked text be: "Link: 1", "Link: 2" and so on.

Well... That's probably enough for now. I still want to respond to Chuck's email, but I have to get to a meeting now.

Aloha, Rich

P.S. Later today I'll create a web version of this, so make it a bit more intelligible.

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

I am very much in favor of putting readable IDs into the paper version. Yes, for long term considerations, but also for short term considerations. I believe anything that is not there will not exist for the taxonomists and be considered only unintelligible techie stuff. And therefore certainly not worth thinking about in the context of their own work.

With respect to how to handle the presentation I think taking a look at how Genbank/EMBL sequence accessions are handled may be helpful. Not every occurrence of "Chromis" in the text needs the ID associated (it may have a hidden hyperlink though), but at one point it needs to be clarified. In molecular phylogenetics it is common to do this a single time in a table in material and methods. However, in the discussion an additional accession number may just be cited in brackets.

In short: allow any normal publishing practice, consider it as a special form of reference (like doi or ISBN) and observe the normal publishing practices of citing, especially avoid redundancies. Rich, I think you are too much thinking about general rules how to always handle it - but publishing practice for good reasons does almost the opposite (once and never again...).

Gregor

But Rich, the prose you refer to are the ... 'this is a really neat fish, just look at the video' discussion rather than the techie ICZN stuff ... Aus bus sp. nov ... LSID, Latin daignosis, holotype etc ... which, at the risk of being stoned (having rocks thrown at me ... ;-) ... I mean) as an heretic, could perhaps be usefully lost in an appendix, and thus disposed would not interrupt the flow.

Paul

-----Original Message----- From: tdwg-guid-bounces@lists.tdwg.org [mailto:tdwg-guid-bounces@lists.tdwg.org] On Behalf Of Richard Pyle Sent: 01 December 2007 00:48 To: 'Gregor Hagedorn'; tdwg-guid@lists.tdwg.org Subject: RE: [tdwg-guid] Embedding LSID links within Publications

Thanks, Gregor -- this is very helpful, and I pretty much agree.

In short: allow any normal publishing practice, consider it as a special form of reference (like doi or ISBN) and observe the normal publishing practices of citing, especially avoid redundancies. Rich, I

think you are too much thinking about general rules how to always handle it - but publishing practice for good reasons does almost the opposite (once and never again...).

Fair enough....and I'm sure I am over-thinking this. However, I still see problems with your proposed approached, in that I do not want big, cumbersome LSIDs (even once) interrupting the flow of prose.

I think I still favor the idea of a superscript indicator that can be easily ignored, easily clicked, and easily used to refer to a printed (not hidden) set of hyperlinks following the "Literature Cited" section. I think this strikes a resonable compromise/balance between how things are done in the publishing world, and how *I* think things *should* be done in the publishing world....

:-)

Rich

_______________________________________________ tdwg-guid mailing list tdwg-guid@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-guid ************************************************************************ The information contained in this e-mail and any files transmitted with it is confidential and is for the exclusive use of the intended recipient. If you are not the intended recipient please note that any distribution, copying or use of this communication or the information in it is prohibited.

Whilst CAB International trading as CABI takes steps to prevent the transmission of viruses via e-mail, we cannot guarantee that any e-mail or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions.

If you have received this communication in error, please notify us by e-mail at cabi@cabi.org or by telephone on +44 (0)1491 829199 and then delete the e-mail and any copies of it.

CABI is an International Organization recognised by the UK Government under Statutory Instrument 1982 No. 1071.

**************************************************************************

Hi Rich

I think, there are two issues. There are two versions of the publications, the underlying xml and the pdf/hard copy.

1. What we need is an xml version of the document which includes all the lsids, etc. For a name, that would look like

tax:name <tax:xid source="HNS" identifier="141015"/> tax:xmldata dc:GenusFormica</dc:Genus> dc:Speciesrubra</dc:Species> </tax:xmldata>rubra</tax:name> tax:statusnov. spec.</tax:status>

Replace HNS with LSID, or ZooBank, etc.

This needs to be the original document.

2. Then you need an XSLT which transforms it into whathever style and layout you want, such as pdf, or what journal style it has to be.

3. Whether you want to expose the lsid, make it clickable is then up to you, and need be discussed on an individual base. In most cases it would be enough to be able to click on a name and get back the data the LSID resolver delivers - which is what you have to decide at Zoobank. This allows also displaying documents in various ways, such as generic html with links, the original pdf, xml, etc.

If we are serious about access to the content of publications, we need focus on the xml version rather then pdf.

Donat

-----Original Message----- From: tdwg-guid-bounces@lists.tdwg.org [mailto:tdwg-guid-bounces@lists.tdwg.org] On Behalf Of Richard Pyle Sent: Monday, December 03, 2007 9:52 AM To: 'Paul Kirk'; 'Gregor Hagedorn'; tdwg-guid@lists.tdwg.org Subject: RE: [tdwg-guid] Embedding LSID links within Publications

Let's distinguish between the two separate places where there may be LSIDs in the document:

1) Underneath the header for each of the five new species described in the article.

2) Embedded within clicakble links scattered through the introduction, discussion, etc. (what I call "prose"), which are not themselves registered nomenclatural acts; but are simply "links of convenince" to allow someone reading the PDF to simply click on a highlighted word or symbol and be redirected (presumably through a web browser) to some sort of online resource (image, video, SDD document, whatever...)

As for #1, I believe that the LSID should be displayed to the human reader in full, and probably should *also* be a clickable link directly to the ZooBank record for that LSID. Displaying the full LSID here is appropriate, because the publication itself represents the Code-governed creation event behind that LSID. It also does not interrupt the "flow", because there is no "flow" to the header of a new species account.

As for #2, there is "flow" here, because people are reading a normal paragraph or text. Offsetting a clickable word in blue or underlined or with some sort of Mouseover highlighting does not interrupt the flow -- but inserting an LSID in parentheses within the text does interrupt the flow of reading.

So....in this context, my current preferred way of displaying it in the formatted PDF is:

1) Show the LSID for the 5 new species names, as part of header for the new species treatment (just like listing a holotype, etc.) The only question here is whether I show only the UUID, or do I show the UUID "wrapped" within the LSID syntax. In order to help promote LSIDs (in keeping with the TDWG/GBIF agenda at the moment), I'm leaning towards displaying the complete LSID; but perhaps mentioning in the methods that the ZooBank Registration ID is the UUID, but they are shown formatted with complete LSID resolving syntax.

2) Do not show the LSID for other clickable links within the "prose" of the document, but embed those LSIDs in the (hidden) link URL. I'm still not sure whether the word/name itself will be the clickable "thing", or whether I'll add some sort of standard symbol analagous to a footnote number that the user would click.

3) Display full URLs in an "Appendix" sort of section, at the end of the rest of the article, so they can be seen via the paper-printed version.

Does this make sense? Or am I stoned...? :-)

Rich

-----Original Message----- From: Paul Kirk [mailto:p.kirk@cabi.org] Sent: Sunday, December 02, 2007 10:39 PM To: Richard Pyle; Gregor Hagedorn; tdwg-guid@lists.tdwg.org Subject: RE: [tdwg-guid] Embedding LSID links within Publications

But Rich, the prose you refer to are the ... 'this is a really neat fish, just look at the video' discussion rather than the techie ICZN stuff ... Aus bus sp. nov ... LSID, Latin daignosis, holotype etc ... which, at the risk of being stoned (having rocks thrown at me ... ;-) ... I mean) as an heretic, could perhaps be usefully lost in an appendix, and thus disposed would not interrupt the flow.

Paul

-----Original Message----- From: tdwg-guid-bounces@lists.tdwg.org [mailto:tdwg-guid-bounces@lists.tdwg.org] On Behalf Of Richard Pyle Sent: 01 December 2007 00:48 To: 'Gregor Hagedorn'; tdwg-guid@lists.tdwg.org Subject: RE: [tdwg-guid] Embedding LSID links within Publications

Thanks, Gregor -- this is very helpful, and I pretty much agree.

...

In short: allow any normal publishing practice, consider it as a special form of reference (like doi or ISBN) and observe the normal publishing practices of citing, especially avoid

redundancies. Rich, I

...

think you are too much thinking about general rules how to always handle it - but publishing practice for good reasons does

almost the

...

opposite (once and never again...).

Fair enough....and I'm sure I am over-thinking this. However, I still see problems with your proposed approached, in that I do not want big, cumbersome LSIDs (even once) interrupting the flow of prose.

I think I still favor the idea of a superscript indicator that can be easily ignored, easily clicked, and easily used to refer to a printed (not hidden) set of hyperlinks following the "Literature Cited" section. I think this strikes a resonable compromise/balance between how things are done in the publishing world, and how *I* think things *should* be done in the publishing world....

:-)

Rich

---

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

---

---

The information contained in this e-mail and any files transmitted with it is confidential and is for the exclusive use of the intended recipient. If you are not the intended recipient please note that any distribution, copying or use of this communication or the information in it is prohibited.

Whilst CAB International trading as CABI takes steps to prevent the transmission of viruses via e-mail, we cannot guarantee that any e-mail or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions.

If you have received this communication in error, please notify us by e-mail at cabi@cabi.org or by telephone on +44 (0)1491 829199 and then delete the e-mail and any copies of it.

CABI is an International Organization recognised by the UK Government under Statutory Instrument 1982 No. 1071.

---

---

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

Dear all,

The usage of LSIDs and especially citing would be much easier if the usage of metadata would have been more precisely defined. Now, the recommendations allow the TDWGOntology as well as other 'well known vocabularies' = chaos.

We should at least decide on a small set of _obligatory_ metadata elements, for example some dublin core fields? For new taxon names the citation of LSIDs would be much easier, because this metadata could then be placed somewhere in the references section such as Pyle, R, 2007: TaxonXY, ...some other metadata..., TheLSID

best regards, Robert

2007/12/3, Richard Pyle deepreef@bishopmuseum.org:

Let's distinguish between the two separate places where there may be LSIDs in the document:

1. Underneath the header for each of the five new species described in the

article.

2. Embedded within clicakble links scattered through the introduction,

discussion, etc. (what I call "prose"), which are not themselves registered nomenclatural acts; but are simply "links of convenince" to allow someone reading the PDF to simply click on a highlighted word or symbol and be redirected (presumably through a web browser) to some sort of online resource (image, video, SDD document, whatever...)

As for #1, I believe that the LSID should be displayed to the human reader in full, and probably should *also* be a clickable link directly to the ZooBank record for that LSID. Displaying the full LSID here is appropriate, because the publication itself represents the Code-governed creation event behind that LSID. It also does not interrupt the "flow", because there is no "flow" to the header of a new species account.

As for #2, there is "flow" here, because people are reading a normal paragraph or text. Offsetting a clickable word in blue or underlined or with some sort of Mouseover highlighting does not interrupt the flow -- but inserting an LSID in parentheses within the text does interrupt the flow of reading.

So....in this context, my current preferred way of displaying it in the formatted PDF is:

1. Show the LSID for the 5 new species names, as part of header for the

new species treatment (just like listing a holotype, etc.) The only question here is whether I show only the UUID, or do I show the UUID "wrapped" within the LSID syntax. In order to help promote LSIDs (in keeping with the TDWG/GBIF agenda at the moment), I'm leaning towards displaying the complete LSID; but perhaps mentioning in the methods that the ZooBank Registration ID is the UUID, but they are shown formatted with complete LSID resolving syntax.

2. Do not show the LSID for other clickable links within the "prose" of

the document, but embed those LSIDs in the (hidden) link URL. I'm still not sure whether the word/name itself will be the clickable "thing", or whether I'll add some sort of standard symbol analagous to a footnote number that the user would click.

3. Display full URLs in an "Appendix" sort of section, at the end of the

rest of the article, so they can be seen via the paper-printed version.

Does this make sense? Or am I stoned...? :-)

Rich

...

-----Original Message----- From: Paul Kirk [mailto:p.kirk@cabi.org] Sent: Sunday, December 02, 2007 10:39 PM To: Richard Pyle; Gregor Hagedorn; tdwg-guid@lists.tdwg.org Subject: RE: [tdwg-guid] Embedding LSID links within Publications

But Rich, the prose you refer to are the ... 'this is a really neat fish, just look at the video' discussion rather than the techie ICZN stuff ... Aus bus sp. nov ... LSID, Latin daignosis, holotype etc ... which, at the risk of being stoned (having rocks thrown at me ... ;-) ... I mean) as an heretic, could perhaps be usefully lost in an appendix, and thus disposed would not interrupt the flow.

Paul

-----Original Message----- From: tdwg-guid-bounces@lists.tdwg.org [mailto:tdwg-guid-bounces@lists.tdwg.org] On Behalf Of Richard Pyle Sent: 01 December 2007 00:48 To: 'Gregor Hagedorn'; tdwg-guid@lists.tdwg.org Subject: RE: [tdwg-guid] Embedding LSID links within Publications

Thanks, Gregor -- this is very helpful, and I pretty much agree.

...

In short: allow any normal publishing practice, consider it as a special form of reference (like doi or ISBN) and observe the normal publishing practices of citing, especially avoid

redundancies. Rich, I

...

think you are too much thinking about general rules how to always handle it - but publishing practice for good reasons does

almost the

...

opposite (once and never again...).

Fair enough....and I'm sure I am over-thinking this. However, I still see problems with your proposed approached, in that I do not want big, cumbersome LSIDs (even once) interrupting the flow of prose.

I think I still favor the idea of a superscript indicator that can be easily ignored, easily clicked, and easily used to refer to a printed (not hidden) set of hyperlinks following the "Literature Cited" section. I think this strikes a resonable compromise/balance between how things are done in the publishing world, and how *I* think things *should* be done in the publishing world....

:-)

Rich

---

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

---

---

The information contained in this e-mail and any files transmitted with it is confidential and is for the exclusive use of the intended recipient. If you are not the intended recipient please note that any distribution, copying or use of this communication or the information in it is prohibited.

Whilst CAB International trading as CABI takes steps to prevent the transmission of viruses via e-mail, we cannot guarantee that any e-mail or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions.

If you have received this communication in error, please notify us by e-mail at cabi@cabi.org or by telephone on +44 (0)1491 829199 and then delete the e-mail and any copies of it.

CABI is an International Organization recognised by the UK Government under Statutory Instrument 1982 No. 1071.

---

---

---

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

Many thanks, Robert! (And thanks also for sending the PDFs).

Besides the email addresses, the external links (to publications and datasets) are DOIs, and within the PDF itself, are represented as clickable links via the HTTP proxy http://dx.doi.org/ -- essentially exactly how I would plan to embed clickable links to LSIDs.

Many thanks again!

Aloha, Rich

_____

From: tdwg-guid-bounces@lists.tdwg.org [mailto:tdwg-guid-bounces@lists.tdwg.org] On Behalf Of Robert Huber Sent: Monday, December 03, 2007 12:06 AM To: tdwg-guid@lists.tdwg.org Subject: Re: [tdwg-guid] Embedding LSID links within Publications

Dear all,

Maybe this could also help in this discussion: here is an example how data sets are cited in an existing publication: http://dx.doi.org/10.1016/j.palaeo.2007.03.030 http://dx.doi.org/10.1016/j.palaeo.2007.03.030

best regards, Robert

2007/12/3, Robert Huber rhuber@wdc-mare.org:

Dear all,

The usage of LSIDs and especially citing would be much easier if the usage of metadata would have been more precisely defined. Now, the recommendations allow the TDWGOntology as well as other 'well known vocabularies' = chaos.

We should at least decide on a small set of _obligatory_ metadata elements, for example some dublin core fields? For new taxon names the citation of LSIDs would be much easier, because this metadata could then be placed somewhere in the references section such as Pyle, R, 2007: TaxonXY, ...some other metadata..., TheLSID

best regards, Robert

2007/12/3, Richard Pyle < mailto:deepreef@bishopmuseum.org deepreef@bishopmuseum.org>:

Let's distinguish between the two separate places where there may be LSIDs in the document:

1) Underneath the header for each of the five new species described in the article.

2) Embedded within clicakble links scattered through the introduction, discussion, etc. (what I call "prose"), which are not themselves registered nomenclatural acts; but are simply "links of convenince" to allow someone reading the PDF to simply click on a highlighted word or symbol and be redirected (presumably through a web browser) to some sort of online resource (image, video, SDD document, whatever...)

As for #1, I believe that the LSID should be displayed to the human reader in full, and probably should *also* be a clickable link directly to the ZooBank record for that LSID. Displaying the full LSID here is appropriate, because the publication itself represents the Code-governed creation event behind that LSID. It also does not interrupt the "flow", because there is no

"flow" to the header of a new species account.

As for #2, there is "flow" here, because people are reading a normal paragraph or text. Offsetting a clickable word in blue or underlined or with

some sort of Mouseover highlighting does not interrupt the flow -- but inserting an LSID in parentheses within the text does interrupt the flow of reading.

So....in this context, my current preferred way of displaying it in the formatted PDF is:

1) Show the LSID for the 5 new species names, as part of header for the new species treatment (just like listing a holotype, etc.) The only question here is whether I show only the UUID, or do I show the UUID "wrapped" within

the LSID syntax. In order to help promote LSIDs (in keeping with the TDWG/GBIF agenda at the moment), I'm leaning towards displaying the complete LSID; but perhaps mentioning in the methods that the ZooBank Registration ID

is the UUID, but they are shown formatted with complete LSID resolving syntax.

2) Do not show the LSID for other clickable links within the "prose" of the document, but embed those LSIDs in the (hidden) link URL. I'm still not sure

whether the word/name itself will be the clickable "thing", or whether I'll add some sort of standard symbol analagous to a footnote number that the user would click.

3) Display full URLs in an "Appendix" sort of section, at the end of the rest of the article, so they can be seen via the paper-printed version.

Does this make sense? Or am I stoned...? :-)

Rich

-----Original Message----- From: Paul Kirk [mailto: p.kirk@cabi.org mailto:p.kirk@cabi.org ] Sent: Sunday, December 02, 2007 10:39 PM To: Richard Pyle; Gregor Hagedorn; tdwg-guid@lists.tdwg.org Subject: RE: [tdwg-guid] Embedding LSID links within Publications

But Rich, the prose you refer to are the ... 'this is a really neat fish, just look at the video' discussion rather than the techie ICZN stuff ... Aus bus sp. nov ... LSID, Latin daignosis, holotype etc ... which, at the risk of being stoned (having rocks thrown at me ... ;-) ... I mean) as an heretic, could perhaps be usefully lost in an appendix, and thus disposed would not interrupt the flow.

Paul

-----Original Message----- From: tdwg-guid-bounces@lists.tdwg.org

mailto:tdwg-guid-bounces@lists.tdwg.org

[mailto: mailto:tdwg-guid-bounces@lists.tdwg.org

tdwg-guid-bounces@lists.tdwg.org] On Behalf Of Richard Pyle

Sent: 01 December 2007 00:48 To: 'Gregor Hagedorn'; tdwg-guid@lists.tdwg.org Subject: RE: [tdwg-guid] Embedding LSID links within Publications

Thanks, Gregor -- this is very helpful, and I pretty much agree.

...

In short: allow any normal publishing practice, consider it as a special form of reference (like doi or ISBN) and observe the normal publishing practices of citing, especially avoid

redundancies. Rich, I

...

think you are too much thinking about general rules how to always handle it - but publishing practice for good reasons does

almost the

...

opposite (once and never again...).

Fair enough....and I'm sure I am over-thinking this. However, I still see problems with your proposed approached, in that I do not want big, cumbersome LSIDs (even once) interrupting the flow of prose.

I think I still favor the idea of a superscript indicator that can be easily ignored, easily clicked, and easily used to refer to a printed (not hidden) set of hyperlinks following the "Literature Cited" section. I think this strikes a resonable compromise/balance between how things are done in the publishing world, and how *I* think things *should* be done in the publishing world....

:-)

Rich

---

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

---

---

The information contained in this e-mail and any files transmitted with it is confidential and is for the exclusive use of the intended recipient. If you are not the intended recipient please note that any distribution, copying or use of this communication or the information in it is prohibited.

Whilst CAB International trading as CABI takes steps to prevent the transmission of viruses via e-mail, we cannot guarantee that any e-mail or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions.

If you have received this communication in error, please notify us by e-mail at cabi@cabi.org or by telephone on +44 (0)1491 829199 and then delete the e-mail and any copies of it.

CABI is an International Organization recognised by the UK Government under Statutory Instrument 1982 No. 1071.

---

---

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

Hey, Lindsay and Strathmore apparently aren't on board with the whole climate change thing. In a couple more years they will be regularly flooded and won't need an Irrigation District nor, hence, a URI for one.

But I agree with what you said. Bob

On Nov 30, 2007 12:18 PM, Chuck Miller Chuck.Miller@mobot.org wrote:

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

...

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)?

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

How much does it cost to run an LSID resolver, including anything from human resources to hardware? If this is high, and TDWG can't generate on an annually base this amount, then this needs be considered, not just the idealistic aspects.

Donat

_____

From: tdwg-guid-bounces@lists.tdwg.org [mailto:tdwg-guid-bounces@lists.tdwg.org] On Behalf Of Donald Hobern Sent: Sunday, December 02, 2007 10:26 PM To: Kevin Richards Cc: Chuck Miller; tdwg-guid@lists.tdwg.org Subject: Re: [tdwg-guid] Permanent LSID Proxy

For what it's worth, I agree with Kevin on this. The TDWG domain has been hosted by different organisations at different times and it seems a natural place for such a resolver.

Donald

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" mailto:Chuck.Miller@mobot.org 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:// http://%3Csome <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] mailto:tdwg-guid-bounces@lists.tdwg.org%5D 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

_____

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

I think this is a great idea, and we'd be willing to host one of the replicas at NCEAS if so desired. This is the same approach we've been pursuing for replicating our data between several nodes on the KNB (e.g., between NCEAS and LTER). I think insitutional diversity and redundancy are key to long-term persistence.

Matt

Dave Vieglais wrote:

Why not use something like round robin DNS as a load balancing mechanism? Then we can just use the same DNS entry for many identically implemented resolvers around the world. If one organization goes kaput, the others take on the load automatically, providing the domain remains registered.

Dave V.

On Dec 3, 2007 1:47 AM, Donat Agosti <agosti@amnh.org mailto:agosti@amnh.org> wrote:

How much does it cost to run an LSID resolver, including anything
from human resources to hardware? If this is high, and TDWG can't
generate on an annually base this amount, then this needs be
considered, not just the idealistic aspects.



Donat





------------------------------------------------------------------------

*From:* tdwg-guid-bounces@lists.tdwg.org
<mailto:tdwg-guid-bounces@lists.tdwg.org>
[mailto:tdwg-guid-bounces@lists.tdwg.org
<mailto:tdwg-guid-bounces@lists.tdwg.org>] *On Behalf Of *Donald Hobern
*Sent:* Sunday, December 02, 2007 10:26 PM
*To:* Kevin Richards
*Cc:* Chuck Miller; tdwg-guid@lists.tdwg.org
<mailto:tdwg-guid@lists.tdwg.org>

*Subject:* Re: [tdwg-guid] Permanent LSID Proxy



For what it's worth, I agree with Kevin on this.  The TDWG domain
has been hosted by different organisations at different times and it
seems a natural place for such a resolver.

Donald

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 <http://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>
<mailto: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 <http://%3Csome> 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 <http://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 <http://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 <http://lsid.gbif.org>?

Chuck


-----Original Message-----
From: tdwg-guid-bounces@lists.tdwg.org
<mailto:tdwg-guid-bounces@lists.tdwg.org>
[mailto:tdwg-guid-bounces@lists.tdwg.org]
<mailto:tdwg-guid-bounces@lists.tdwg.org%5D> On Behalf Of Richard Pyle
Sent: Friday, November 30, 2007 6:39 AM
To: 'Roger Hyam'; 'Roderic Page'
Cc: tdwg-guid@lists.tdwg.org <mailto: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 <http://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 <http://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 <mailto:deepreef@bishopmuseum.org>
http://hbs.bishopmuseum.org/staff/pylerichard.html



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





------------------------------------------------------------------------




_______________________________________________

tdwg-guid mailing list


tdwg-guid@lists.tdwg.org <mailto:tdwg-guid@lists.tdwg.org>


http://lists.tdwg.org/mailman/listinfo/tdwg-guid




_______________________________________________
tdwg-guid mailing list
tdwg-guid@lists.tdwg.org <mailto: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

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