<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi Tim,<div><br><div><div>On 6 May 2014, at 15:10, Tim Robertson [GBIF] <<a href="mailto:trobertson@gbif.org">trobertson@gbif.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Hi all,</div><div><br></div><div>Supposing GBIF or some other body were interested in offering such a central service as proposed in this thread. Can we articulate what we envisage would be the process? </div><div><br></div><div> a) client has a specimen record they wish to stamp with an identifier</div></div></blockquote><div><br></div><div>A crucial first step is having data providers generate and maintain ids that are unique within their organisation. By maintain I mean they don’t change just because someone decides to use new software, or to rename "HERP” as “HERPS”, etc.</div><div><br></div><div>In the academic publishing world you will see all sorts of conventions for naming articles, e.g.</div><div><br></div><div>bms.2012.1078</div><div><br></div><div>S0025315407056196</div><div><br></div><div>16085914.2012.668850</div><div><br></div><div>0278-0372(2000)020[0603:DIMAWI]2.0.CO;2</div><div><br></div><div>that are designed to create identifiers unique within a publisher (some of these are obviously based on article metadata). These can then be migrated to DOis by prepending them with a DOI, e.g.</div><div><br></div><div><a href="http://dx.doi.org/10.5343/bms.2012.1078">http://dx.doi.org/10.5343/bms.2012.1078</a></div><div><br></div><div><a href="http://dx.doi.org/10.1651/0278-0372(2000)020[0603:DIMAWI]2.0.CO;2">http://dx.doi.org/10.1651/0278-0372(2000)020[0603:DIMAWI]2.0.CO;2</a> (yuck)</div><div><br></div><div><br></div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div> b) client requests DOI (or other format) from the issuing service and provides the minimum metadata in a DwC-esque profile, potentially with a preferred suffix </div></div></blockquote><div><br></div><div>Yes. Isn’t this pretty much what happens already, in the sense that data providers send GBIF data in an agreed format?</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div> c) service provides identifier, and client stores this along with their digital record</div></div></blockquote><div><br></div><div>Service provider mints DOI, which ideally is as simple as putting 10.xxx prefix in front of their locally unique identifier (if 10.xxx prefix is unique to that client), or adding additional string to make it globally unique.</div><div><br></div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div> d) from this point on, the DOI identifies the record</div></div></blockquote><div><br></div><div>Yes</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><br></div><div>If so, what would happen on resolution? Does the client provide the target URL during minting which will be the redirection target on resolution? Does the service have to monitor the availability and return the cached copy on outage?</div></div></blockquote><div><br></div><div>Yes, typically client provides the URL. Alternatively, client could delegate that to GBIF (“we can’t handle this right know, can GBIF please host HTML for occurrence”), in which case GBIF would add it’s own URL.</div><div><br></div><div>As Hilmar has said, CrossRef will penalise providers that fail to resolve. But just as importantly, they provide a support tool where you can report a DOI that doesn’t resolve. I think an obvious approach here is for GBIF to provide a fallback. One way to do this would be to have a resolver, e.g. <a href="http://doi.gbif.org">doi.gbif.org</a> that will, by default, go to client’s page, otherwise resolve to GBIF’s version of the HTML for a DOI.</div><div><br></div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><br></div><div>In such a model, effectively we would have a central specimen registration service where data owners push individual specimen records. Is that something we envisage the community would accept? Presumably the minimum metadata would include things like dwc:scientificName - would someone register a DOI pushing that for specimens of a new species before they have published on the name? </div></div></blockquote><div><br></div><div>Isn’t this pretty much GBIF’s current model? Data owners push data to GBIF, GBIF expects certain standard fields, and assigns an occurrence id. What changes is the id becomes a DOI.</div><div><br></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><br></div><div>This model will not in itself stop duplicate IDs. The scientists assembling datasets of specimens referenced in a paper might submit those references specimens for DOIs, while the original specimen curators might also submit the same records - thus the specimen is identified twice. Which piece of the infrastructure would capture that relationship?</div></div></blockquote><div><br></div><div>No, this is equivalent to me writing a paper, citing some articles, and saying I’d like to mint DOis for those articles! Either the DOis exist (in which case I or the publisher of my article can link to them) or the DOis don’t, in which case I get a “naked” citation string. Either way, authors of papers on’t get to mint DOIs for specimens .</div><div><br></div><div><div>One model is DOIs are minted for specimens in a collection (the “publisher” or “data owner"). For example, only the AMNH can apply for DOIs for it’s specimens. I guess this does raise some issues about how easy it is to identify who actually “owns” the specimen (i.e., is the primary source of data for that specimen). </div><div><br></div></div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><br></div><div>What seems most important to me when I think this through is that the identifier needs to be minted as early on as possible in the record life - before it is shared with others. Which leads us back to the question of whether we envisage people adopting a model where they effectively submit their record data in order to get an identifier. If not, at least if we got stable IDs on records in whatever form, we can manage the resolvability bit later, and identify duplicates.</div></div></blockquote><div><br></div><div>So, a first step is for providers submitting data to GBIF to have locally unique, stable identifiers. You’d think this would be an obvious and trivial thing, but I suspect it won’t be...</div><div><br></div><div>Regards</div><div><br></div><div>Rod</div><div><br></div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><br></div><div>It would be interesting to hear how others imagine such a service operating.</div><div><br></div><div>Thanks,</div><div>Tim</div><div><br></div><div><br></div><div> </div><div><br></div><br><div><div>On 06 May 2014, at 15:34, Hilmar Lapp <<a href="mailto:hlapp@nescent.org">hlapp@nescent.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Every registration agency has its own set of standard metadata which members register for every DOI, but the content-negotiation strategy does allow for a richer metadata response. By default it is the registration agency's resolver that responds with RDF (and thus only with the metadata it knows of), but members (the entities registering DOIs) can register their own content-negotiation resolver, which would allow them to return richer metadata. We have, for example, considered doing this for Dryad (<a href="http://datadryad.org/">http://datadryad.org</a>), but it hasn't risen to high-enough priority yet.<div>
<br></div><div>Hence, if GBIF were to register DOIs for specimens through DataCite (rather than being its own RA), then GBIF could still operate its own resolver for returning DwC metadata for RDF queries.</div><div><br></div>
<div><div class="gmail_extra">That doesn't mean there couldn't still be good arguments for GBIF serving as a RA.</div><div class="gmail_extra"><br></div><div class="gmail_extra"> -hilmar<br><br><div class="gmail_quote">
On Tue, May 6, 2014 at 5:53 AM, Roderic Page <span dir="ltr"><<a href="mailto:Roderic.Page@glasgow.ac.uk" target="_blank">Roderic.Page@glasgow.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Hi Steve,<div><br></div><div>My understanding is that the non-HTML content is decided at the level of registration agency. For a bibliographic DOI registered with CrossRef, the HTML redirect goes to whatever the publisher provides CrossRef (e.g., the article landing page), other content (including RDF) is served by CrossRef based on the metadata they hold for each article. Likewise, DataCite will serve metadata based on what they have. Hence, metadata from CrossRef and DatacIte look rather different.</div>
<div><br></div><div>So, this is something that would need to be worked out at the level of registration agency (see <a href="http://www.crossref.org/CrossTech/2010/03/dois_and_linked_data_some_conc.html" target="_blank">http://www.crossref.org/CrossTech/2010/03/dois_and_linked_data_some_conc.html</a> and <a href="http://crosstech.crossref.org/2011/04/content_negotiation_for_crossr.html" target="_blank">http://crosstech.crossref.org/2011/04/content_negotiation_for_crossr.html</a> for background).</div>
<div><br></div><div>Hence, if GBIF were to be a DOI registration agency they could serve Darwin Core RDF (and JSON and whoever else they want). This is a strong argument for GBIF doing this, rather than using DataCite (which serves very generic metadata).</div>
<div><br></div><div>Regards</div><div><br></div><div>Rod</div><div><div class="h5"><br><div><div>On 6 May 2014, at 01:42, Steve Baskauf <<a href="mailto:steve.baskauf@vanderbilt.edu" target="_blank">steve.baskauf@vanderbilt.edu</a>> wrote:</div>
<br><blockquote type="cite">
<div bgcolor="#ffffff" text="#000000">
I'm a big fan of not reinventing the wheel, and as such find the idea
of using DOIs appealing. I think they pretty much follow all of the
"rules" set out in the TDWG GUID Applicability Standard. They also
play nicely in the Linked Data universe in their HTTP URI form, i.e.
they redirect to HTML or RDF depending on the request header. <br>
<br>
But I have a question for someone who understands how DOIs work better
than I do. The HTML representation seems to arise by redirection to
whatever is the current web page for the resource. You can see this
by pasting this DOI for a specimen into a browser:
<a href="http://dx.doi.org/10.7299/X7VQ32SJ" target="_blank">http://dx.doi.org/10.7299/X7VQ32SJ</a> which redirects to
<a href="http://arctos.database.museum/guid/UAM:Ento:230092" target="_blank">http://arctos.database.museum/guid/UAM:Ento:230092</a> when HTML is
requested by a client. However, when the client requests RDF, one gets
redirected to a DataCite metadata page:
<a href="http://data.datacite.org/10.7299/X7VQ32SJ" target="_blank">http://data.datacite.org/10.7299/X7VQ32SJ</a> . Can the creator of the DOI
redirect to any desired URI for the RDF? <br>
<br>
The resulting RDF metadata doesn't have any of the kind useful
information about the specimen that you get on the web page but rather
looks like what you would expect for a publication (creator, publisher,
date, etc.):<br>
<br>
<span><<a href="http://linkeddata.informatik.hu-berlin.de/uridbg/index.php?url=http://dx.doi.org/10.7299/X7VQ32SJ&acceptheader=text%2Fturtle%3Bq%3D1%2Capplication%2Fx-turtle%3Bq%3D0.5&useragentheader=" target="_blank">http://dx.doi.org/10.7299/X7VQ32SJ</a>><br>
<<a href="http://linkeddata.informatik.hu-berlin.de/uridbg/index.php?url=http://purl.org/dc/terms/creator&acceptheader=text%2Fturtle%3Bq%3D1%2Capplication%2Fx-turtle%3Bq%3D0.5&useragentheader=" target="_blank">http://purl.org/dc/terms/creator</a>><br>
"Derek S. Sikes" ;<br>
<<a href="http://linkeddata.informatik.hu-berlin.de/uridbg/index.php?url=http://purl.org/dc/terms/date&acceptheader=text%2Fturtle%3Bq%3D1%2Capplication%2Fx-turtle%3Bq%3D0.5&useragentheader=" target="_blank">http://purl.org/dc/terms/date</a>><br>
"2004" ;<br>
<<a href="http://linkeddata.informatik.hu-berlin.de/uridbg/index.php?url=http://purl.org/dc/terms/identifier&acceptheader=text%2Fturtle%3Bq%3D1%2Capplication%2Fx-turtle%3Bq%3D0.5&useragentheader=" target="_blank">http://purl.org/dc/terms/identifier</a>><br>
"10.7299/X7VQ32SJ" ;<br>
<<a href="http://linkeddata.informatik.hu-berlin.de/uridbg/index.php?url=http://purl.org/dc/terms/publisher&acceptheader=text%2Fturtle%3Bq%3D1%2Capplication%2Fx-turtle%3Bq%3D0.5&useragentheader=" target="_blank">http://purl.org/dc/terms/publisher</a>><br>
"University of Alaska Museum" ;<br>
<<a href="http://linkeddata.informatik.hu-berlin.de/uridbg/index.php?url=http://purl.org/dc/terms/title&acceptheader=text%2Fturtle%3Bq%3D1%2Capplication%2Fx-turtle%3Bq%3D0.5&useragentheader=" target="_blank">http://purl.org/dc/terms/title</a>><br>
"UAM:Ento:230092 - Grylloblatta campodeiformis" ;<br>
<<a href="http://linkeddata.informatik.hu-berlin.de/uridbg/index.php?url=http://www.w3.org/2002/07/owl#sameAs&acceptheader=text%2Fturtle%3Bq%3D1%2Capplication%2Fx-turtle%3Bq%3D0.5&useragentheader=" target="_blank">http://www.w3.org/2002/07/owl#sameAs</a>><br>
"info:doi/10.7299/X7VQ32SJ" , "doi:10.7299/X7VQ32SJ" .<br>
<br>
Can one control what kinds of metadata are provided in "</span>DataCite's
metadata"? <span>Assuming that we get our act together and adopt
an RDF guide for Darwin Core, it would be nice for the RDF metadata to
look more like the description of a specimen and less like the
description of a book. But maybe that's just a function of where the
data provider choses to redirect RDF requests.<br>
<br>
Steve<br>
</span><br>
John Deck wrote:
<blockquote type="cite">
<div dir="ltr">
<div> +1 on DOIs, and on ARKS (see: <a href="https://wiki.ucop.edu/display/Curation/ARK" target="_blank">https://wiki.ucop.edu/display/Curation/ARK</a>
), and also i'll mention IGSN:'s (see <a href="http://www.geosamples.org/" target="_blank">http://www.geosamples.org/</a>) IGSN:
is rapidly gaining traction for geo-samples. I don't know of anyone
using them for bio-samples but they offer many features that we've been
asking for as well. What our community considers a sample (or
observation) is diverse enough that multiple ID systems are probably
inevitable and perhaps even warranted. </div>
<div><br>
</div>
<div>Whatever the ID system, the data providers (museums, field
researchers, labs, etc..) must adopt that identifier and use it
whenever linking to downstream sequence, image, and sub-sampling
repository agencies. This is great to say this in theory but difficult
to do in reality because the decision to adopt long term and stable
identifiers is often an institutional one, and the technology is still
new and argued about, in particular, on this fine list. Further, those
agencies that receive data associated with a GUID must honor that
source GUID when passing to consumers and other aggregators, who must
also have some level of confidence in the source GUIDs as well. Thus,
a primary issue that we're confronted with here is trust.</div>
<div><br>
</div>
<div>Having Hilmar's hackathon support several possible GUID schemes
(each with their own long term persistence strategy), and sponsored by
a well known global institution affiliated with biodiversity
informatics that could offer technical guidance to data providers, good
name branding, and the nuts and bolts expertise to demonstrate good
shepherding of source GUIDs through a data aggregation chain would be
ideal. I nominate GBIF :)</div>
<div><br>
</div>
<div>John Deck<br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Mon, May 5, 2014 at 1:09 PM, Roderic Page
<span dir="ltr"><<a href="mailto:r.page@bio.gla.ac.uk" target="_blank">r.page@bio.gla.ac.uk</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204,204,204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
<div>Hi Markus,
<div><br>
</div>
<div>I have three use cases that</div>
<div><br>
</div>
<div>1. Linking sequences in GenBank to voucher specimens. Lots of
voucher specimens are listed in GenBank but not linked to digital
records for those specimens. These links are useful in two directions,
one is to link GBIF to genomic data, the second is to enhance data in
both databases, see <a href="http://iphylo.blogspot.co.uk/2012/02/linking-gbif-and-genbank.html" target="_blank">http://iphylo.blogspot.co.uk/2012/02/linking-gbif-and-genbank.html</a>
(e.g., by adding missing georeferencing that is available in one
database but not the other).</div>
<div><br>
</div>
<div>2. Linking to specimens cited in the literature. I’ve done
some work on this in BioStor, see <a href="http://iphylo.blogspot.co.uk/2012/02/linking-gbif-and-biodiversity-heritage.html" target="_blank">http://iphylo.blogspot.co.uk/2012/02/linking-gbif-and-biodiversity-heritage.html</a>
One immediate benefit of this is that GBIF could display the
scientific literature associated with a specimen, so we get access to
the evidence supporting identification, georeferencing, etc. </div>
<div><br>
</div>
<div>3. Citation metrics for collections, see <a href="http://iphylo.blogspot.co.uk/2013/05/the-impact-of-museum-collections-one.html" target="_blank">http://iphylo.blogspot.co.uk/2013/05/the-impact-of-museum-collections-one.html</a>
and <a href="http://iphylo.blogspot.co.uk/2012/02/gbif-specimens-in-biostor-who-are-top.html" target="_blank">http://iphylo.blogspot.co.uk/2012/02/gbif-specimens-in-biostor-who-are-top.html</a>
Based on citation sod specimens in the literature, and in databases
such as GenBank (i.e., basically combining 1 + 2 above) we can
demonstrate the value of a collection.</div>
<div><br>
</div>
<div>All of these use cases depend on GBIF occurenceIds remaining
stable, I have often ranted on iPHylo when this doesn’t happen: <a href="http://iphylo.blogspot.co.uk/2012/07/dear-gbif-please-stop-changing.html" target="_blank">http://iphylo.blogspot.co.uk/2012/07/dear-gbif-please-stop-changing.html</a></div>
<div><br>
</div>
<div>Regards</div>
<div><br>
</div>
<div>Rod</div>
<div>
<div>
<div><br>
</div>
<div><br>
</div>
<div><br>
<div>
<div>On 5 May 2014, at 20:51, Markus Döring <<a href="mailto:mdoering@gbif.org" target="_blank">mdoering@gbif.org</a>>
wrote:</div>
<br>
<blockquote type="cite">
<div>Hi Rod,
<div><br>
</div>
<div>I agree GBIF has troubles to keep identifiers stable for
*some* records, but in general we do a much better job than the
original publishers in the first place. We try hard to keep GBIF ids
stable even if publishers change collection codes, registered datasets
twice or do other things to break a simple automated way of mapping
source records to existing GBIF ids. Also the stable identifier in GBIF
never has been the URL, but it is the local GBIF integer alone. The
GBIF services that consume those ids have changed over the years, but
its pretty trivial to adjust if you use the GBIF ids instead of the
URLs. If there is a clear need to have stable URLs instead I am sure we
can get that working easily.</div>
<div><br>
</div>
<div>The two real issues for GBIF are a) duplicates and b)
records with varying local identifiers of any sort (triplet,
occurrenceID or whatever else).</div>
<div><br>
</div>
<div>When it comes to the varying source identifiers I always
liked the idea of flagging those records and datasets as unstable, so
it is obvious to users. This is not a 100% safe, but most terrible
datasets change all of their ids and that is easily detectable.</div>
<div>Also with a service like that it would become more obvious
to publishers how important stable source ids are.</div>
<div><br>
</div>
<div>Before jumping on DOIs as the next big thing I would really
like to understand what needs the community has around specimen ids.</div>
<div>Gabi clearly has a very real use case, are there others we
know about?</div>
<div><br>
</div>
<div><br>
</div>
<div>Markus</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div>On 05 May 2014, at 21:05, Roderic Page <<a href="mailto:r.page@bio.gla.ac.uk" target="_blank">r.page@bio.gla.ac.uk</a>> wrote:</div>
<br>
<blockquote type="cite">
<div>Hi Hilmar,
<div><br>
</div>
<div>I’m not arguing that we shouldn’t build a resolver (I have
one that I use, Rich has mentioned he’s got one, Markus has one at
GBIF, etc.).</div>
<div><br>
</div>
<div>Nor do I think we should wait for institutional and social
commitment (because then we’d never get anything done).</div>
<div><br>
</div>
<div>But I do think it would be useful to think it through. For
example, it’s easy to create a URL for a specimen. Easy peasy. OK, how
do I discover that URL? How do I discover these for all specimens?
Sounds like I need a centralised discover service like you’e described.</div>
<div><br>
</div>
<div>How do I handle changes in those URLs? I built a specimen
code to GBIF resolver for BioStor so that I could link to specimens,
GBIF changed lots of those URLs, all my work was undone, boy does GBIF
suck sometimes. For example, if I map codes to URLs, I need to handle
cases when they change. </div>
<div><br>
</div>
<div>If URLs can change, is there a way to defend against that
(this is one reason for DOIs, or other methods of indirection, such as
PURLs). </div>
<div><br>
</div>
<div>If providers change, will the URLs change? Is there a way
to defend against that (again, DOIs handle this nicely by virtue of (a)
indirection, and (b) lack of branding).</div>
<div><br>
</div>
<div>How can I encourage people to use the specimen service?
What can I do to make them think it will persist? Can I convince
academic publishers to trust it enough to link to it in articles?
What’s the pitch to Pensoft, to Magnolai Press, to Springer and
Elsevier?</div>
<div><br>
</div>
<div>Is there some way to make the service itself become
trusted? For example if I look at a journal and see that it has DOIs
issued by CrossRef, I take that journal more seriously than if it’s
just got simple URLs. I know that papers in that journal will be linked
into the citation network, I also know that there is a backup plan if
the journal goes under (because you need that to have DOIs in
CrossRef). Likewise, I think Figshare got a big boost when it stared
minting DOIs (wow, a DOI, I know DOIs, you mean I can now cite stuff
I’ve uploaded there?). </div>
<div><br>
</div>
<div>How can museums and herbaria be persuaded to keep their
identifiers stable? What incentives can we provide (e.g., citation
metrics for collections)? What system would enable us to do this? What
about tracing funding (e.g., the NSF paid for these n papers, and they
cite these y specimens, from these z collections, so science paid for
by the NSF requires these collections to exist).</div>
<div><br>
</div>
<div>I guess I’m arguing that we should think all this through,
because a specimen code to specimen URL is a small piece of the puzzle.
Now, I’m desperately trying not to simply say what I think is
blindingly obvious here (put DOIs on specimens, add metadata to
specimen and specimen citation services, and we are done), but I think
if we sit back and look at where we want to be, this is exactly what we
need (or something functionally equivalent). Until we see the bigger
picture, we will be stuck in amateur hour.</div>
<div><br>
</div>
<div>Take a look at:</div>
<div><br>
</div>
<div><a href="http://search.crossref.org/" target="_blank">http://search.crossref.org</a></div>
<div><a href="http://www.crossref.org/fundref/" target="_blank">http://www.crossref.org/fundref/</a></div>
<div><a href="http://support.crossref.org/" target="_blank">http://support.crossref.org/</a></div>
<div><a href="https://prospect.crossref.org/splash/" target="_blank">https://prospect.crossref.org/splash/</a></div>
<div><br>
</div>
<div>Isn’t this the kind of stuff we’d like to do? If so, let’s
work out what’s needed and make it happen.</div>
<div><br>
</div>
<div>In short, I think we constantly solve an immediate problem
in the quickest way we know how, without thinking it through. I’d argue
that if we think about the bigger picture (what do we want to be able
to, what are the questions we want to be able to ask) then things
become clearer. This is independent of getting everyone’s agreement
(but it would help if we made their agreement seem a no brainer by
providing solutions to things that cause them pain).</div>
<div><br>
</div>
<div><br>
</div>
<div>Regards</div>
<div><br>
</div>
<div>Rod</div>
<div><br>
<div>
<div>On 5 May 2014, at 19:14, Hilmar Lapp <<a href="mailto:hlapp@nescent.org" target="_blank">hlapp@nescent.org</a>>
wrote:</div>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, May 5, 2014 at 1:29 PM,
Roderic Page <span dir="ltr"><<a href="mailto:r.page@bio.gla.ac.uk" target="_blank">r.page@bio.gla.ac.uk</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204,204,204);margin:0px 0px 0px 0.8ex;padding-left:1ex">Contrary
to Hilmar, there is more to this than simply a quick hackathon. Yes, a
service that takes metadata and returns one or more identifiers is a
good idea and easy to create (there will often be more than one because
museum codes are not unique). But who maintains this service? Who
maintains the identifiers? Who do I complain to if they break? How do
we ensure that they persist when, say, a museum closes down, moves its
collection, changes it’s web technology? Who provides the tools that
add value to the identifiers? (there’s no point having them if they are
not useful)<br>
</blockquote>
<div><br>
</div>
<div>Jonathan Rees pointed this out to me too off-list. Just
for the record, this isn't contrary but fully in line with what I was
saying (or trying to say). Yes, I didn't elaborate that part, assuming,
perhaps rather erroneously, that all this goes without saying, but I
did mention that one part of this becoming a real solution has to be an
institution with an in-scope cyberinfrastructure mandate that going
in would make a commitment to sustain the resolver, including working
with partners on the above slew of questions. The institution I gave
was iDigBio; perhaps for some reason that would not be a good choice,
but whether they are or not wasn't my point.</div>
<div><br>
</div>
<div>I will add one point to this, though. It seems to me
that by continuing to argue that we can't go ahead with building a
resolver that works (as far as technical requirements are concerned)
before we haven't first fully addressed the institutional and social
long-term sustainability commitment problem, we are and have been
making this one big hairy problem that we can't make any practical
pragmatic headway about, rather than breaking it down into parts, some
of which (namely the primarily technical ones) are actually fairly
straightforward to solve. As a result, to this day we don't have some
solution that even though it's not very sustainable yet, at least
proves to everyone how critical it is, and that the community can rally
behind. Perhaps that's naïve, but I do think that once there's a
solution the community rallies behind, ways to sustain it will be
found. </div>
<div><br>
</div>
<div> -hilmar</div>
</div>
-- <br>
<div dir="ltr">
<div>Hilmar Lapp -:- <a href="http://informatics.nescent.org/wiki" target="_blank">informatics.nescent.org/wiki</a>
-:- <a href="http://lappland.io/" target="_blank">lappland.io</a><br>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
tdwg-content mailing list<br>
<a href="mailto:tdwg-content@lists.tdwg.org" target="_blank">tdwg-content@lists.tdwg.org</a><br>
<a href="http://lists.tdwg.org/mailman/listinfo/tdwg-content" target="_blank">http://lists.tdwg.org/mailman/listinfo/tdwg-content</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
John Deck<br>
<a href="tel:%28541%29%20321-0689" value="+15413210689" target="_blank">(541) 321-0689</a><br>
</div>
</blockquote>
<br>
<pre cols="72">--
Steven J. Baskauf, Ph.D., Senior Lecturer
Vanderbilt University Dept. of Biological Sciences
postal mail address:
PMB 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: <a href="tel:%28615%29%20343-4582" value="+16153434582" target="_blank">(615) 343-4582</a>, fax: <a href="tel:%28615%29%20322-4942" value="+16153224942" target="_blank">(615) 322-4942</a>
If you fax, please phone or email so that I will know to look for it.
<a href="http://bioimages.vanderbilt.edu/" target="_blank">http://bioimages.vanderbilt.edu</a>
<a href="http://vanderbilt.edu/trees" target="_blank">http://vanderbilt.edu/trees</a>
</pre>
</div>
_______________________________________________<br>tdwg-content mailing list<br><a href="mailto:tdwg-content@lists.tdwg.org" target="_blank">tdwg-content@lists.tdwg.org</a><br><a href="http://lists.tdwg.org/mailman/listinfo/tdwg-content" target="_blank">http://lists.tdwg.org/mailman/listinfo/tdwg-content</a><br>
</blockquote></div><br></div></div></div><br>_______________________________________________<br>
tdwg-content mailing list<br>
<a href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a><br>
<a href="http://lists.tdwg.org/mailman/listinfo/tdwg-content" target="_blank">http://lists.tdwg.org/mailman/listinfo/tdwg-content</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>Hilmar Lapp -:- <a href="http://informatics.nescent.org/wiki" target="_blank">informatics.nescent.org/wiki</a> -:- <a href="http://lappland.io/" target="_blank">lappland.io</a><br>
</div><br></div>
</div></div></div>
_______________________________________________<br>tdwg-content mailing list<br><a href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a><br><a href="http://lists.tdwg.org/mailman/listinfo/tdwg-content">http://lists.tdwg.org/mailman/listinfo/tdwg-content</a><br></blockquote></div><div apple-content-edited="true"><br>
</div>
<br></div></blockquote></div><br><div><br></div><div><div>---------------------------------------------------------<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: <span class="Apple-tab-span" style="white-space: pre;"> </span><a href="mailto:r.page@bio.gla.ac.uk">r.page@bio.gla.ac.uk</a><br>Tel: <span class="Apple-tab-span" style="white-space: pre;"> </span>+44 141 330 4778<br>Fax: <span class="Apple-tab-span" style="white-space: pre;"> </span>+44 141 330 2792<br>Skype: <span class="Apple-tab-span" style="white-space: pre;"> </span>rdmpage<br>Facebook: <span class="Apple-tab-span" style="white-space: pre;"> </span>http://www.facebook.com/rdmpage<br>LinkedIn: <span class="Apple-tab-span" style="white-space: pre;"> </span>http://uk.linkedin.com/in/rdmpage<br>Twitter: <span class="Apple-tab-span" style="white-space: pre;"> </span>http://twitter.com/rdmpage<br>Blog: <span class="Apple-tab-span" style="white-space: pre;"> </span> http://en.wikipedia.org/wiki/Roderic_D._M._Page<br>Citations: <span class="Apple-tab-span" style="white-space: pre;"> </span>http://scholar.google.co.uk/citations?hl=en&user=4Z5WABAAAAAJ<br>ORCID: <span class="Apple-tab-span" style="white-space: pre;"> </span>http://orcid.org/0000-0002-7101-9767</div></div><div><br></div></div></body></html>