tag:blogger.com,1999:blog-356350393899715266.post2116160255305901083..comments2016-07-28T11:31:05.707-07:00Comments on BiSciCol: Making it 'EZ' to GUIDNico Cellinesehttp://www.blogger.com/profile/05502820618366076308noreply@blogger.comBlogger12125tag:blogger.com,1999:blog-356350393899715266.post-17694261366661210822013-04-30T08:21:55.391-07:002013-04-30T08:21:55.391-07:00I can see that you are putting a lot of efforts in...I can see that you are putting a lot of efforts into your blog. Some really helpful information in there. Nice to see your site. Thanks!<br /><a href="http://www.dhitconsulting.com/ez-connector/" rel="nofollow">Ez Connector Fishbowl</a>Andrew Krishthttp://www.blogger.com/profile/07440750284056901292noreply@blogger.comtag:blogger.com,1999:blog-356350393899715266.post-36271115676948336902012-12-13T08:43:14.638-08:002012-12-13T08:43:14.638-08:00Great to hear that! As for next steps, BiSciCol i...Great to hear that! As for next steps, BiSciCol is now working in conjunction with the California Digital Library (CDL) on tools the community can use for assigning identifiers to data elements within datasets. These persistent identifiers will be used to track physical objects (specimens, samples), events (collecting events, identification events) or digital information (photographs, sequences). We&#39;re actively working on this now and will be demonstrating these tools next June (at iEvoBio). John Deckhttp://www.blogger.com/profile/03050568439150665411noreply@blogger.comtag:blogger.com,1999:blog-356350393899715266.post-82355600154778448292012-12-12T20:53:45.309-08:002012-12-12T20:53:45.309-08:00Canadensys now assigns DOIs to its datasets served...Canadensys now assigns DOIs to its datasets served from its IPT. See http://www.canadensys.net/2012/link-love-dois-for-darwin-core-archives. What do you recommend for next steps?David Shorthousehttp://www.blogger.com/profile/07902186433894266822noreply@blogger.comtag:blogger.com,1999:blog-356350393899715266.post-80704890185897948252012-10-17T00:05:42.269-07:002012-10-17T00:05:42.269-07:00Referring to &quot;It frustrates me that cost is t...Referring to &quot;It frustrates me that cost is the issue which consistent comes up when discussing DOIs. ... DOIs imply permanence and citability,..&quot;, I&#39;d like to build a little on my earlier comments (thanks to Rob for posting them).<br /><br />There is no magic bullet for persistence, which is a sweaty, onerous service undertaking. It is true that the fees for DOIs have gone down; in particular, the per-DOI fee has been eliminated, but the owner of the DOI is completely responsible for actual persistence, which implies staffing, training, reviewing broken link reports, and applying fixes. The burden of maintaining 80 million CrossRef DOIs -- which set the current high standard for DOI quality -- is distributed across over 4000 publishers and societies, many of them well-funded. I believe we&#39;re talking about approximately 300 million specimen ids alone, with the maintenance burden spread across 200 (? wild guess) financially struggling museums. DataCite, the source of data DOIs, has fewer than 20 members, mostly from the traditionally underfunded library community. There is a vast disparity in wealth and projected DOI registration numbers between DataCite and CrossRef.<br /><br />I also mentioned that the concept of what a DOI implies is changing. The CDL (California Digital Library, which runs EZID) is a member of DataCite, which is working hard to uphold the quality of DataCite DOIs. DataCite requires that to get a DataCite DOI, you need to provide five elements of &#39;data-as-publication&#39;-type metadata (Author, Title, Publisher, Publication Year, target URL, resource type) as well as a landing page for each &#39;dataset&#39;. They are also contemplating requiring a CC0 license for all _metadata_. We have EZID customers who are challenged to provide this for 100,000 ordinary datasets. How would this play out with Natural History Collections data? Some of our customers have been surprised that the bar to obtain DOIs was so high, and that their DOIs would break if they didn&#39;t maintain the target URLs themselves. But quality isn&#39;t cheap.<br /><br />Keeping maintenance costs down is important, and the suffix-passthrough feature of our n2t.net resolver will make it possible (by December) by default to manage all 10,000 separately identifiable granules of a complex dataset with only one top-level registration. This will work with ARKs (and DOIs, but we don&#39;t say so since no one thinks to resolve them there).<br /><br /> &quot;Regarding pass-though, this is nice, but could be done with DOIs (at the cost of minting a new DOI for each path), or perhaps the original data provider could have a service that supports suffixes for a DOI (i.e., strings appended to the DOI that might indicate parts of the thing being referred to).&quot;<br /><br />Minting and maintaining a new DOI for each path presents a big maintenance burden. Unfortunately, there is no general way to pass strings along on the end of DOIs due to the way the Handle system works (which is how DOIs are resolved). There is a special &quot;template&quot; syntax that can be established for a subset of your DOIs by working with the Handle system folks to accomplish something similar, but I don&#39;t know if anyone uses it for DOIs. With the current infrastructure, all the granules would require separate registration and maintenance.<br /><br />ARKs also come with maintenance costs, but people can obtain them more easily than DOIs, and they tend to do so early in the life cycles of their data &quot;products&quot;. When selected, mature, publication-like products roll out of their research, that&#39;s when folks want to obtain DOIs.John Kunzehttp://www.blogger.com/profile/08199798878082886648noreply@blogger.comtag:blogger.com,1999:blog-356350393899715266.post-4719232276792113152012-10-15T15:45:46.125-07:002012-10-15T15:45:46.125-07:00This reply is from John Kunze at the California Di...This reply is from John Kunze at the California Digital Library. I am posting on his behalf. <br />___________________________________________________________<br /><br />There are lots of place to jump in, but first I&#39;d like to clear up some confusion about ARKs and DOIs.<br /><br />Global vs local resolution of ARKs is a choice. Unlike other schemes, ARK decouples syntax from resolution mechanism. It is thus a feature that you may choose to mint, maintain, and resolve them without belonging to a membership organization or paying fees. OTOH, a global resolver designed for ARKs and other kinds of ids is n2t.net (Name-to-Thing). While the EZID service uses n2t.net, the National Library of France and the Internet Archive have not sought out global resolution with n2t.net.<br /><br />The majority of the world&#39;s DOIs up until now have a perceived level of quality that is due to the well-funded and well-organized community that CrossRef has created. Not suprisingly, there is no magic bullet to keeping ids persistent -- CrossRef puts a lot of effort into policing broken ids by reminding and chastizing wayward publishers. Newer DOI registration agencies, such as<br /><br /> + DataCite (DOIs for research datasets -- where EZID gets DOIs) and<br /> + EIDR (DOIs for film and television inventory, including porn)<br /><br />are now trying to build their own communities. They have different kinds of content from CrossRef and will be responsible for maintaining their own persistence. With no policing, for example, one would expect DOIs to break at a rate similar to ordinary URLs. The director of strategic initiatives at CrossRef, Geoffrey Bilder, says the important base functionality for persistence is not that they be DOIs, but that they be &quot;persistable&quot; (that is, redirectable). He also expects the perception of DOI quality to change rapidly and he is exhorting CrossRef members to start saying &quot;CrossRef DOI&quot; instead of just &quot;DOI&quot;. DataCite also wishes to maintain high quality DOIs and is putting together link validation mechanisms to try to enforce this.rpghttp://www.blogger.com/profile/06710479641642737338noreply@blogger.comtag:blogger.com,1999:blog-356350393899715266.post-82539419293196812902012-10-15T07:42:13.718-07:002012-10-15T07:42:13.718-07:00Nico and Rob articulated well where we&#39;re comi...Nico and Rob articulated well where we&#39;re coming from. Just a couple points from my perspective. Given the need to not only track specimen derivatives, but processes acting on specimens/samples, the number of identifiers we envision is way way past 450 million or even 1 billion.<br /><br />Great points about the necessity for global resolution. However, i still think there is a use for ARKs, because of the importance of being able to assign identifiers in the field--- so many times spreadsheets leave the field and goes in 2 or more directions at once, leaving us later to rely on heuristics or long lookup tables of identifiers to match things up later. ARKs are useful for delivering pre-minted identifiers to the field when one doesn&#39;t know the exact number of id&#39;s required (e.g. for collecting events). Later, in the lab/museum, one can assign a DOI to the actual specimen or to the dataset. <br /><br />To that end, assigning ARKs to processes and DOIs to physical material could be developed as a common practice.<br /><br /><br /><br /> <br /><br />John Deckhttp://www.blogger.com/profile/03050568439150665411noreply@blogger.comtag:blogger.com,1999:blog-356350393899715266.post-78440199907643908132012-10-13T12:05:21.556-07:002012-10-13T12:05:21.556-07:00One thing that the California Digital Library has ...One thing that the California Digital Library has done that is very smart is to offer both DOIs and ARKs under their EZID approach. This doesn&#39;t solve the debate, above, but it recognizes that there are alternate approaches with alternate values. I believe that John Kunze (and I will forward this debate on to them) would probably argue that ARKs are good for early in digital data life cycles when there is value in being able to quickly create and destroy guids, when things are still fluid. When _publishing_, using DOIs makes more sense --- so DOIs on the physical material is absolutely the way to go, I think. And for finished digital products, I think DOIs are smart too. I am inclined to seeing BiSciCol build a service where there are still choices between ARKs and DOIs, but hopefully not tie these to cost models. I don&#39;t want to speak for anyone at CDL or CrossRef, but I think we can work this out in a way where absolutely everyone wins --- and I don&#39;t say that lightly, rpghttp://www.blogger.com/profile/06710479641642737338noreply@blogger.comtag:blogger.com,1999:blog-356350393899715266.post-56426065892697151592012-10-13T11:20:09.186-07:002012-10-13T11:20:09.186-07:00Nico, costs can change, indeed DOI costs have drop...Nico, costs can change, indeed DOI costs have dropped a lot since registration agencies like DataCite have come along. We regard the Internet as essentially free, but clearly lots of money is being spent to make it work. Perhaps we may reach a point where identifiers like DOIs are consider part of the infrastructure and hence essentially &quot;free&quot;. I can imagine national science funders deciding that so much publicly funded data is identified by DOIs that they need to fund its continued existence.<br /><br />It frustrates me that cost is the issue which consistent comes up when discussing DOIs. Obviously it&#39;s a consideration, but surely the primary consideration is what do we want to achieve? We want persistent, resolvable identifiers that support useful services, and that people will trust and use. None of that is &quot;free&quot;, indeed, that DOIs cost money is one reason they are trusted (given that it costs money for a publisher to get DOIs from CrossRef I have more faith that the content of a journal using DOIs won&#39;t simply disappear than a journal that simply uses URLs).<br /><br />The outcome of discussions driven by cost invariably end up choosing the &quot;cheap&quot; solution, at the expense of actually solving the problem. A big reason the community previously settled on LSIDs was because the were cheap, and look where that got us. DOIs imply permanence and citability, ARKs have no such implications - sure, these properties can be asserted but that doesn&#39;t make it so. Is it not time for our field to step up to the plate and act like our digital resources matter? If we were really serious about this stuff, wouldn&#39;t we simply get on with using DOIs, and doing everything we can to encourage their widespread use and citation?Roderic D. M. Pagehttp://www.blogger.com/profile/00269598293846172649noreply@blogger.comtag:blogger.com,1999:blog-356350393899715266.post-67663897573900088722012-10-13T10:42:45.777-07:002012-10-13T10:42:45.777-07:00Indeed Rod! But everything can get potentially cit...Indeed Rod! But everything can get potentially cited. Datasets, specimens, their images, tissues, in fact all of their derivatives and metadata. It really depends on individual&#39;s interests or research focus. So, we are talking about millions, and perhaps eventually billions(?) of DOIs at what cost? I think the issue of &#39;how many DOIs&#39; we would eventually need came up several times in our discussion with CDL and it seemed to us that ARK provided a workable compromise. It&#39;s a low-hanging fruit right now, but I do understand your valid points. Nico Cellinesehttp://www.blogger.com/profile/05502820618366076308noreply@blogger.comtag:blogger.com,1999:blog-356350393899715266.post-67709403825007690632012-10-13T10:10:13.631-07:002012-10-13T10:10:13.631-07:00Quick comment on granularity and pass-through. For...Quick comment on granularity and pass-through. For me the granularity that matters is what gets cited - if it gets cited it gets a DOI. Specimens get cited, so they should get DOIs (i.e., first-class identifiers). Let&#39;s keep things simple - if you cite a paper, a data set, a specimen, you cite the DOI.<br /><br />Regarding pass-though, this is nice, but could be done with DOIs (at the cost of minting a new DOI for each path), or perhaps the original data provider could have a service that supports suffixes for a DOI (i.e., strings appended to the DOI that might indicate parts of the thing being referred to).<br /><br />Whatever additional features ARK might have, my sense is that the traction DOIs have (e.g., CrossRef, DataCite, Dryad, Figshare) presents an opportunity to make the case for GUIDs, and that multiplying technologies dilutes that message.Roderic D. M. Pagehttp://www.blogger.com/profile/00269598293846172649noreply@blogger.comtag:blogger.com,1999:blog-356350393899715266.post-22591460043385098092012-10-13T09:37:48.421-07:002012-10-13T09:37:48.421-07:00Rod says: &quot;Regarding DOIs and ARKs, without ...Rod says: &quot;Regarding DOIs and ARKs, without wishing to focus on details I&#39;d much rather you go for DOIs as the default identifier. People &quot;get&quot; DOIs, plus there is a well known global resolver for them (http://dx.doi.org). ARKs don&#39;t have this infrastructure... My concern here is that ARKs are reminescent of LSIDs in that there&#39;s little obligation that make them actually work (they can be minted without any commitment to resolution). Once that happens, you are screwed. This, and the lack of a global ARK resolver is, for me, a deal breaker.&quot;<br /><br />Response: Rod, thanks for the great response. I am in nearly completely in agreement re: DOIs versus ARKs. Its the simplicity, persistence and globalness of the resolver that really works. I think most people just want to pop DOIs into their URL bar and resolve to the primary object. John Kunze makes the good point, however, that ARKs might have their uses. Because you can mix and match DOIs and ARKs, one possibility is to assign DOIs to datasets and ARKs to individual records - ARKs are built to be more granular and have these pass-through functions. Both are supported long term by the California Digital Library. There is some concern that assigning DOIs to 450 million data points might be problematic, given that there are only 60 million DOIs out there right now. Maybe we are wailing and nashing teeth for no reason. <br /><br />As for Point 3, man, we are totally with you. We have thought about this A TON and have had conversations with some aggregators about just this idea. Assign GUIDs at the aggregator, and then hand these back to the Museum to take over. In fact, this is a service aggregators could provide. There are some among the BiSciCol contingent who very seriously believe that collections managers and curators will be very reluctant to add fields to their databases unless they understand what the value proposition is for having guids. I think you touch on this as well, and I really like these use cases. Maybe one thing we can do is develop a huge set of those use cases and have them be realllly clear to the collections community. We have a set of use cases we&#39;ve been putting together as well. <br /><br />One thing we have been doing on the BiSciCol end is disambiguating _tracking_, which involves having guids on physical specimens and then developing the means to link up the physical specimens and their downstream derivatives (metadata records, images, sequences) and _discovery_, where linkages were broken in the past, and you want to find them again. For example, if two different specimens in two different museum collections came from the same collecting event, can you reassociate them post-hoc and then re-establish this inferred relationship. We definitely see strong use cases on both fronts. <br /><br />Rod says: &quot;My concern is that unless GUIDs give immediate, tangible benefits people will ask (quite rightly) why they went through all the hassle of adopting them. And I suspect the big benefits will come from getting these GUIDs used by GBIF and GenBank in the first place, then cited in the primary literature.&quot;<br /><br />Response: I TOTALLY AGREE. We have been advocating with GBIF, VertNet, iDigBio the value of persistent, well understood and globally resolvable guids such as DOIs. I also think there is great value in early adopters showing how we - as a community - can be pushing along new and obvious, needed frontiers. Our approach is --- lets get EZIDs (DOIs) onto specimens and records working at the source and the aggregator, and apply principle #4 (aggregators need to honor well-curated GUIDs from providers). We also really do see the value of _helping_ people do this guid assignment task - building simple services and actually putting some face-time into getting adoption happening at sources and aggregators. It might not be that people don&#39;t want to, it is more likely it is a matter of activation energy, and finding ways to overcome that barrier. rpghttp://www.blogger.com/profile/06710479641642737338noreply@blogger.comtag:blogger.com,1999:blog-356350393899715266.post-55319195675630255782012-10-13T01:06:41.466-07:002012-10-13T01:06:41.466-07:00This sounds very encouraging. As always, a few com...This sounds very encouraging. As always, a few comments.<br /><br />Regarding DOIs and ARKs, without wishing to focus on details I&#39;d much rather you go for DOIs as the default identifier. People &quot;get&quot; DOIs, plus there is a well known global resolver for them (<a href="http://dx.doi.org" rel="nofollow">http://dx.doi.org</a>). ARKs don&#39;t have this infrastructure, and the ARKs I can find in the wild aren&#39;t recognised by <a href="http://n2t.net" rel="nofollow">http://n2t.net</a>. The Gallica archive makes extensive use of them (<a href="http://gallica.bnf.fr/ark:/12148/cb34349289k/date" rel="nofollow">http://gallica.bnf.fr/ark:/12148/cb34349289k/date</a>, for example, yet <a href="http://n2t.net" rel="nofollow">http://n2t.net</a> pleads ignorance about these identifiers. Nor does it know anything about Internet Archive ARKs such as ark:/13960/t00z7hg8f. My concern here is that ARKs are reminescent of LSIDs in that there&#39;s little obligation that make them actually work (they can be minted without any commitment to resolution). Once that happens, you are screwed. This, and the lack of a global ARK resolver is, for me, a deal breaker. <br /><br />I like the emphasis on identifying the specimen, not the metadata. This is equivalent to CrossRef insisting that DOIs identify articles, and not the metadata, nor any particular physical representation of them. Had CrossRef chosen another approach (e.g., having separate identifiers for print and electronic versions it would have been a mess).<br /><br />Regarding point 3 (&quot;GUIDs must be assigned as close to the source as possible&quot;) this assumes everyone has the resources to do this. One thing I like about identifiers that lack domain names (e.g., DOIs, Handles, ARKs) is that enable an alternative approach, namely a body with more resources could assign and manage a namespace on another&#39;s behalf, until such time as the primary provider is ready to take over that namespace. Translation - someone like GBIF could mint identifiers for the contents of a museum&#39;s collection (using a unique namespace for that museum), then hand over running those identifiers to museum at a later date. From the user&#39;s perspective nothing happens, the identifier is unchanged.<br /><br />Lastly, GUIDs are like fax machines, having just one user makes no sense. With DOIs for literature, their utility becomes almost immediately apparent once publishers start using them in their lists of literature cited. I suspect part of the problem for collections is there&#39;s been no compelling display of the possible benefits of having GUIDs. For me the immediate use cases are:<br /><br />Persistent identification of records in GBIF so that GBIF avoids the occassionally massive duplication of records I&#39;ve discussed elsewhere (<a href="http://iphylo.blogspot.co.uk/2012/02/how-many-specimens-does-gbif-really.html" rel="nofollow">How many specimens does GBIF really have?</a>.<br /><br />Reuse of GUIDs by GBIF makes it trivial to transmit corrections back to providers (GBIF needs to do something better than emails for this).<br /><br />Collections could track citations in the literature (and GenBank) to their holdings. This task requires matching museum specimen codes to newly minted GUIDs, but would be doable (if tedious). I&#39;ve done a little work on this using GBIF occurrence ids as a proxy for specimen GUIDs, but became frustrated by <a href="http://iphylo.blogspot.co.uk/2012/07/dear-gbif-please-stop-changing.html" rel="nofollow">their lack of stability</a>.<br /><br /><br />My concern is that unless GUIDs give immediate, tangible benefits people will ask (quite rightly) why they went through all the hassle of adopting them. And I suspect the big benefits will come from getting these GUIDs used by GBIF and GenBank in the first place, then cited in the primary literature.Roderic D. M. Pagehttp://www.blogger.com/profile/00269598293846172649noreply@blogger.com
http://biscicol.blogspot.com/feeds/2116160255305901083/comments/default
biscicol.blogspot.com
crawl=CC-MAIN-2017-17
42389
application/http; msgtype=response
sha1:D3T25V3EW75EMQVM7QCYVGGT47PBW5NT
<urn:uuid:688143ac-bca6-437a-b800-c6311d7fb1eb>
2017-04-23T17:43:05Z
172.217.8.1
sha1:SLB7GWOINAQFVTSUX4JLPWXCUQSWJ62W
<urn:uuid:d8f36d31-10de-4c17-831e-c2109ff150b6>
http://biscicol.blogspot.com/feeds/2116160255305901083/comments/default
response
<urn:uuid:c18f8030-60a3-4f71-b682-42aa48eb08f2>
robots: classic
hostname: ip-10-145-167-34.ec2.internal
software: Nutch 1.6 (CC)/CC WarcExport 1.0
isPartOf: CC-MAIN-2017-17
operator: CommonCrawl Admin
description: Wide crawl of the web for April 2017
publisher: CommonCrawl
format: WARC File Format 1.0
conformsTo: http://bibnum.bnf.fr/WARC/WARC_ISO_28500_version1_latestdraft.pdf