<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Dear Dusty,<div><br><div><div>On 27 Feb 2012, at 16:44, DLMcDonald wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">GBIF URIs are cheap - why not get a couple?!<br><br>
Along with museums randomly publishing their specimens a few times, others often (re)publish specimen data. <a href="http://data.gbif.org/occurrences/146112485/" target="_blank">http://data.gbif.org/occurrences/146112485/</a> and <a href="http://data.gbif.org/occurrences/210282234/" target="_blank">http://data.gbif.org/occurrences/210282234/</a> are both "copies" of <a href="http://arctos.database.museum/guid/UAM:Mamm:29830" target="_blank">http://arctos.database.museum/guid/UAM:Mamm:29830</a>,
which is the primary, current specimen data, for example. There's no
obvious link between the three records. The
NatureServe record was (apparently) taken from the literature, the other
was provided by the specimen owner but is cached at GBIF and very much
abridged to fit DWC. I think there are probably many more "reported
sightings" (from literature, checklists, "known" specimens at other
museums, etc.) than
specimen-backed data records in GBIF, especially for things like
insects, and I think most GBIF data are probably severely out of sync with the primary data, if such a thing exists. I
have no idea what any identifier could do about that - inspire false
confidence, perhaps.<br><br>I can't really think of a worse "authority" than GBIF, at least from a museum/specimen perspective.<br></blockquote><div><br></div><div>It's clear that GBIF has issues, especially with duplicate records. Tim Roberston has given a detailed explanation of the reasons GBIF struggles with this <a href="http://iphylo.blogspot.com/2012/02/how-many-specimens-does-gbif-really.html#comment-449811856">http://iphylo.blogspot.com/2012/02/how-many-specimens-does-gbif-really.html#comment-449811856</a>. From my experience, problems include (a) museums changing the metadata for specimens (e.g., changing a the collection code form 'Bird' to 'Birds') and (b) lack of internal identifiers that are invariant when the metadata changes. It's also clear that the same records are being aggregated several times, some via "primary" sources (e.g., the museum's DiGiR provider) and some via "secondary" sources. Much of the specimen-level digital infrastructure we have has no notion of identifiers, hence no easy way to avoid duplicates.</div><div><br></div><div>Yes GBIF is problematic, but the one big advantage from my point of view is I want to go to one place and get information on specimens. I don't want to have to discover where I get this information from, then figure out how to retrieve it. If I'm matching 100,000s of records I want one place to do this for me.</div><div><br></div><div>The analogy I often use is CrossRef, which has metadata for millions of scientific articles. If I want to locate the DOI for an article I don't have to figure out which publisher published the article and how I talk to their database, I simply ask CrossRef what the DOI is using a simple API. This is how the linked reference list at then end of a paper are generated. I want something similar for specimens.</div><br><blockquote type="cite">
<br>A small community of us have implemented a very successful URL "guid" model. If anyone has another specimen identifier that gets more
inter-system use, I don't know about it. It's also pretty handy, if far from perfect, for
finding things on the internet. (<a href="http://goo.gl/WRe6p" target="_blank">http://goo.gl/WRe6p</a> should find the specimen listed above, for example.)
We've worked closely with GenBank in developing this system, and even
in the case of things like authors not bothering to tell us about
publications we can use the GUID to automagically find
specimens/sequences in each other's systems. I think it's about as good
as URIs can get. And it's not very good. We're always a bad
administrative decision or two from doing something we'll regret, and we've learned most of whatever we know by getting it wrong the first time(s). I cringe every
time I see <a href="http://arctos.database.museum/SomeSupposedlyForeverURL">http://arctos.database.museum/SomeSupposedlyForeverURL</a> in a static medium (<a href="http://goo.gl/8szEv" target="_blank">http://goo.gl/8szEv</a>).<br>
<br>tl;dr: There is a strong need for something beyond URLs, but there are scary social problems to address.<br>
<br>-Dusty<br></blockquote><div><br></div><div>I guess this model is one reason David Schindel likes Darwin Core triplets. Being able to construct a URL from metadata is nice, but looking at the history of GBIF data lots of museums like to change this metadata, which makes the URLs fragile (or at least, potentially breaks attempts infer the URL from the metadata). Then there's the issue of global uniqueness of these codes.</div><div><br></div><div>The thing I find somewhat bemusing in all of this is that we are far from the first people to face these problems. The publishing industry has the same issues, and they ended up having centrally-managed identifiers (DOIs) that use redirection to hide the underlying URLs, so the individual publishers can muck about with the platforms they use to serve the data without breaking things for users. It seems to me that any system that links using URLs has to have a strategy for handling URLs changing (because it's pretty clear museums have virtually no ability to keep URLs from changing). If you accept that, then I think the way forward becomes pretty clear. GBIF is our CrossRef. </div><div><br></div><div>Regards</div><div><br></div><div>Rod</div><div><br></div><div><br></div><br><blockquote type="cite"><br><div class="gmail_quote">On Sun, Feb 26, 2012 at 8:41 PM, Paul Murray <span dir="ltr"><<a href="mailto:pmurray@anbg.gov.au" target="_blank">pmurray@anbg.gov.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The question is - who has the job of declaring what the "original URI" is for existing specimens that already have a history? And what should that URI be? Perhaps this is where GBIF-issued ids become important. Or perhaps we could ditch the idea of "original URI", and just track the "GBIF URI". It's the responsibility of anyone with a specimen that does not already have a GBIF URI to get one for it.<br>
</blockquote><div><br><br></div></div>
</blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">---------------------------------------------------------<br>Roderic Page<br>Professor of Taxonomy<br>Institute of Biodiversity, Animal Health and Comparative Medicine<br>College of Medical, Veterinary and Life Sciences<br>Graham Kerr Building<br>University of Glasgow<br>Glasgow G12 8QQ, UK<br><br>Email: <a href="mailto:r.page@bio.gla.ac.uk">r.page@bio.gla.ac.uk</a><br>Tel: +44 141 330 4778<br>Fax: +44 141 330 2792<br>AIM: <a href="mailto:rodpage1962@aim.com">rodpage1962@aim.com</a><br>Facebook: <a href="http://www.facebook.com/profile.php?id=1112517192">http://www.facebook.com/profile.php?id=1112517192</a><br>Twitter: <a href="http://twitter.com/rdmpage">http://twitter.com/rdmpage</a><br>Blog: <a href="http://iphylo.blogspot.com">http://iphylo.blogspot.com</a><br>Home page: <a href="http://taxonomy.zoology.gla.ac.uk/rod/rod.html">http://taxonomy.zoology.gla.ac.uk/rod/rod.html</a><br></span>
</div>
<br></div></body></html>