<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
A quick comment
about ubio.org's LSID resolution:&nbsp; I took a look at the complete RDF
source and noticed that the namespace declarations for "ubi:" and
"gla:" don't start with <a class="moz-txt-link-rfc2396E" href="http://">"http://"</a>.&nbsp;
I'm pretty sure that isn't kosher
RDF, although neither of the RDF validators complained about it
(doesn't give me much confidence in RDF validators).&nbsp; So much for being
overly optimistic about there being one source that worked completely.
:-)<br>
<br>
I should say that I'm not an advocate of LSIDs.&nbsp; I actually don't like
them at all.&nbsp; I simply investigated
them in this context as something that might work in a Linked Data
context.&nbsp; I should also say that I'm not necessarily an advocate of
Linked Data - I'm in the "wait and see" camp.&nbsp; I'd like to give it a
chance but I'm not betting the store on it.&nbsp; I AM an advocate of having
identifiers that are persistent and globally unique and it appears that
both Catalog of Life and IPNI (in my view) flunk the persistence test
if you just look at the URI (LSID with version) as a string (which you
SHOULD be
able to do) that can be an unchanging identifier.&nbsp; We desperately need
persistent and globally unique
identifiers for a lot of things.&nbsp; If they resolve to RDF/XML then
that's a bonus.&nbsp; We need an Emperor, clothing is somewhat optional.<br>
<br>
A few specific responses:<br>
<br>
Roderic Page wrote: <br>
<blockquote
 cite="mid:1B2A6026-103C-4120-A6A7-40A43284565D@bio.gla.ac.uk"
 type="cite">
  <pre wrap="">
These issues won't go away simply by replacing LSIDs with HTTP URIs.  
Some of the linked data sources go belly up fairly regularly (notably <a
 class="moz-txt-link-freetext" href="http://bio2rdf.org">http://bio2rdf.org</a> 
).
  </pre>
</blockquote>
The reason I see HTTP URIs [capable of producing either HTML or RDF/XML
through content negotiation] as something of greater value than LSIDs
is that people can at a minimum get a web page out of it.&nbsp; That's the
cake.&nbsp; If some people can also use them to get RDF for the Linked Data
dream, that's the icing.&nbsp; The fact that HTTP URI GUIDs fail to "work"
is similar to the fact that regular web URLs fail to work.&nbsp; That
doesn't stop people from using the web and it shouldn't stop well
designed (i.e. <a class="moz-txt-link-freetext" href="http://www.w3.org/TR/cooluris/">http://www.w3.org/TR/cooluris/</a> and
<a class="moz-txt-link-freetext" href="http://www.w3.org/Provider/Style/URI">http://www.w3.org/Provider/Style/URI</a>) URIs from being used as GUIDs. <br>
<blockquote
 cite="mid:1B2A6026-103C-4120-A6A7-40A43284565D@bio.gla.ac.uk"
 type="cite">
  <pre wrap="">
IPNI supports versioning of LSIDs, but the LSID without the version is  
also valid (it resolves to the latest version). I think this is a  
perfectly valid thing to do. Versioning matters to some, but not  
everyone cares about it, IPNI supports both views. If you want to cite  
a specific version, do so, if not, don't.
  </pre>
</blockquote>
OK, I guess as long as people can just leave the version off if they
want, they'll get unchanging strings for their identifiers and so I
guess that moves them into the "usable" column.&nbsp; But as far as I'm
concerned, putting the versions on adds to the confusion.&nbsp; If I can say
this without launching an unnecessary thread about the opacity of
GUIDs, nobody is supposed to be looking at any GUID itself to infer
meaning about the identified object.&nbsp; That "no-no" seems to be exactly
what Catalog of Life and IPNI seem to be suggesting that people do with
the LSID version numbers they are tacking on.&nbsp; Get rid of them.<br>
<blockquote
 cite="mid:1B2A6026-103C-4120-A6A7-40A43284565D@bio.gla.ac.uk"
 type="cite">
  <pre wrap="">
The data/metadata distinction is a complete red herring and has side- 
tracked more LSID conversations than I care to remember. The  
distinction stems from LSIDs originally being conceived as identifiers  
for large data objects (e.g., sequences, images, binary streams) that  
people want accurately versioned so that could reproduce digital  
experiments. In this scenario, metadata can change because it's not  
what mattered for this reproducibility. Some people think of data  
about  taxonomic names as "metadata", and then we're off on a wild  
goose chase about should LSIDs change when metadata changes. I  
wouldn't loose any sleep over this (see discussion of IPNI above).
  </pre>
</blockquote>
Agreed.&nbsp; The important thing is that the identifier for a certain
"thing" (however the "thing" is defined) should not change.&nbsp; I have
previously expressed the opinion that it won't really work to have any
URI (sensu Linked Data) point to "data" and that all URIs serving as
GUIDs should be considered to reference non-information resources
(which by definition have only "metadata").&nbsp; Under that scenario, all
resource properties are "metadata" and subject to change.&nbsp; The data vs.
metadata argument then becomes irrelevant.<br>
<blockquote
 cite="mid:1B2A6026-103C-4120-A6A7-40A43284565D@bio.gla.ac.uk"
 type="cite">
  <pre wrap="">
Regarding DOIs for books, these are uncommon, although there are moves  
to express ISBNs within the DOI framework, so there may be more of  
these. But for a DOI to exist someone has to claim ownership of a  
resource and register the DOI with CrossRef. For a lot of older  
literature there won't be a publisher around to do this, but that's  
where BHL comes in.
  </pre>
</blockquote>
Then PLEASE BHL, create simple, unchanging URIs [suitable for use in
the Linked Data world] to identify your resources.&nbsp; If you don't want
to provide RDF/XML, that's fine for now.&nbsp; You can wait and see if that
is necessary later.&nbsp; But at least create URIs that COULD be used for
Linked Data in the future and that are not long and loaded with "?" and
"&amp;" characters.&nbsp; I don't know how to do that because I'm not a
server dude.&nbsp; But it apparently isn't that hard to do with a mod
rewrite.&nbsp; I know there are at least three people (probably more) on
this list who do that routinely - Rod does it with his bioguid.info
site (i.e. "cool" URI <a class="moz-txt-link-freetext" href="http://bioguid.info/doi:10.1093/bib/bbn022">http://bioguid.info/doi:10.1093/bib/bbn022</a> gets
written into "ugly" URL
<a class="moz-txt-link-freetext" href="http://bioguid.info/openurl.php?id=doi:10.1093/bib/bbn022">http://bioguid.info/openurl.php?id=doi:10.1093/bib/bbn022</a> but nobody
cares as long as the "cool" URI doesn't change).&nbsp; <br>
<br>
My two cents worth...<br>
Steve<br>
<blockquote
 cite="mid:1B2A6026-103C-4120-A6A7-40A43284565D@bio.gla.ac.uk"
 type="cite">
  <pre wrap="">
In summary, we're in a mess, and I don't think this is really down to  
technology. It's a failure of our community to create the appropriate  
resources (e.g., centralised, curated resources of identifiers and  
associated metadata for names, publications, and specimens).

Regards

Rod



On 6 Jan 2011, at 05:32, Steve Baskauf wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Well, I have continued my quest for resolvable, RDF-producing GUIDs  
for
taxon/name-related stuff.  I have gotten a lot of good information  
from
reading Rod Page's BMC Bioinformatics paper
(<a class="moz-txt-link-freetext"
 href="http://dx.doi.org/10.1186/1471-2105-10-S14-S5">http://dx.doi.org/10.1186/1471-2105-10-S14-S5</a>) and from investigating
his <a class="moz-txt-link-freetext" href="http://bioguid.info/">http://bioguid.info/</a> site.

&gt;From the standpoint of the "sec./sensu" part of a TNU/taxon concept,
based on the recent discussion, it sounds like the DIO solution for
publications is a good direction to go IF resolution services  
producing
RDF comes into existence and IF it becomes possible to actually search
for the DIOs of more obscure publications.  I tried using Rod's site  
to
look up a journal article using the ISSN, volume, and page and the web
interface found the DOI and generated RDF just fine.  However, an
attempt to use the web to find the DIO of Gleason and Cronquist's  
Manual
of vascular plants of Northeastern United States and adjacent Canada
failed despite a half hour of effort (I found the UPC, the LOC call
number, and the ISBN, but no DOI).  Maybe there just isn't a DOI for  
it
but there should be a way for me to know that.  So DOIs for books and
old journal articles are not really ready for prime time.

&gt;From the standpoint of the "scientific name" part of a TNU/taxon
concept, I had better luck (sort of).  Rod's "Status of biodiversity
services" page (<a class="moz-txt-link-freetext"
 href="http://www.bioguid.info/status/">http://www.bioguid.info/status/</a>) was really cool.  I  
saw
resources I hadn't known about before.  I tried out several of the
services that claimed to issue LSIDs.

Catalog of Life's LSIDs didn't work with either the
<a class="moz-txt-link-freetext" href="http://www.bioguid.info/">http://www.bioguid.info/</a> or <a
 class="moz-txt-link-freetext" href="http://lsid.tdwg.org/">http://lsid.tdwg.org/</a> proxies with  
either a
web browser or  the OpenLink RDF browser.  I only got an empty RDF
element in response.

Index Fungorum was down.

IPNI seemed to work.  However, I was somewhat appalled to observe that
they seem to change the revision identifier any time that they change
any part of the metadata.  That renders the LSID useless as a  
permanent
GUID for the name and I believe is inconsistent with the design of  
LSIDs
where the revision is only supposed to change if the underlying data
itself (NOT metadata) changes.  (Catalog of Life says that they change
the revision identifier EACH YEAR for all of their records!  That's  
even
worse!)  If I'm remembering the TDWG LSID recommendations, it is not
even recommended to use the revision part of an LSID at all in the
biodiversity informatics context.

ubio.org's LSIDs seemed to work properly.

[sorry - didn't try zoobank since I was looking for plants]

I don't know which (if any) of the Web sites listed on Rod's status  
page
use generic HTTP URI guids (rather than LSIDs) to refer to taxon  
names.
I tried out the Global Names index that Pete was mentioning.  The URI
version of the UUIDs (e.g.
<a class="moz-txt-link-freetext"
 href="http://gni.globalnames.org/name_strings/3a70f04d-fd29-5570-ba91-52dae0c3d07f">http://gni.globalnames.org/name_strings/3a70f04d-fd29-5570-ba91-52dae0c3d07f</a>)
do resolve under content negotiation, but the only useful information
that the RDF representation seems to provide is the actual name string
that was used to generate the UUID.  Until some other useful linked
information is added to the RDF, there doesn't seem to be much  
advantage
in pointing a semantic client to the URI over just using a string
literal for the name.

So the bottom line is that of the LSID services for names that I've
tried so far, only ubio.org seems to have LSIDs for names that are
unchanging, can work as a proxied URI,  and that produce actual useful
RDF.  That's pretty disappointing given the apparently huge amount of
work that's been put into building these various systems.

Steve

-- 
Steven J. Baskauf, Ph.D., Senior Lecturer
Vanderbilt University Dept. of Biological Sciences

postal mail address:
VU Station B 351634
Nashville, TN  37235-1634,  U.S.A.

delivery address:
2125 Stevenson Center
1161 21st Ave., S.
Nashville, TN 37235

office: 2128 Stevenson Center
phone: (615) 343-4582,  fax: (615) 343-6707
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu">http://bioimages.vanderbilt.edu</a>

_______________________________________________
tdwg-content mailing list
<a class="moz-txt-link-abbreviated"
 href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a>
<a class="moz-txt-link-freetext"
 href="http://lists.tdwg.org/mailman/listinfo/tdwg-content">http://lists.tdwg.org/mailman/listinfo/tdwg-content</a>

    </pre>
  </blockquote>
  <pre wrap=""><!---->
---------------------------------------------------------
Roderic Page
Professor of Taxonomy
Institute of Biodiversity, Animal Health and Comparative Medicine
College of Medical, Veterinary and Life Sciences
Graham Kerr Building
University of Glasgow
Glasgow G12 8QQ, UK

Email: <a class="moz-txt-link-abbreviated"
 href="mailto:r.page@bio.gla.ac.uk">r.page@bio.gla.ac.uk</a>
Tel: +44 141 330 4778
Fax: +44 141 330 2792
AIM: <a class="moz-txt-link-abbreviated"
 href="mailto:rodpage1962@aim.com">rodpage1962@aim.com</a>
Facebook: <a class="moz-txt-link-freetext"
 href="http://www.facebook.com/profile.php?id=1112517192">http://www.facebook.com/profile.php?id=1112517192</a>
Twitter: <a class="moz-txt-link-freetext"
 href="http://twitter.com/rdmpage">http://twitter.com/rdmpage</a>
Blog: <a class="moz-txt-link-freetext" href="http://iphylo.blogspot.com">http://iphylo.blogspot.com</a>
Home page: <a class="moz-txt-link-freetext"
 href="http://taxonomy.zoology.gla.ac.uk/rod/rod.html">http://taxonomy.zoology.gla.ac.uk/rod/rod.html</a>







.

  </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">-- 
Steven J. Baskauf, Ph.D., Senior Lecturer
Vanderbilt University Dept. of Biological Sciences

postal mail address:
VU Station B 351634
Nashville, TN  37235-1634,  U.S.A.

delivery address:
2125 Stevenson Center
1161 21st Ave., S.
Nashville, TN 37235

office: 2128 Stevenson Center
phone: (615) 343-4582,  fax: (615) 343-6707
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu">http://bioimages.vanderbilt.edu</a>
</pre>
</body>
</html>