- From: Dan Whaley <dwhaley@hypothes.is>
- Date: Sat, 7 May 2016 12:41:58 -0700
- To: Randall Leeds <randall@bleeds.info>
- Cc: Robert Sanderson <azaroth42@gmail.com>, Web Annotation <public-annotation@w3.org>
- Message-ID: <CAF-V5fg48ea=fMgHzN1ZxJe3HKz6id_h+j7nwniAhG9Rd+M4Ng@mail.gmail.com>
On Sat, May 7, 2016 at 11:55 AM, Randall Leeds <randall@bleeds.info> wrote: > > > On Sat, May 7, 2016, 11:07 Dan Whaley <dwhaley@hypothes.is> wrote: > >> On Fri, May 6, 2016 at 12:02 PM, Robert Sanderson <azaroth42@gmail.com> >> wrote: >> >>> >>> All, >>> >>> On the call today we briefly discussed the use of other identifiers for >>> annotations, such as DOIs. >>> >>> While there's no problem assigning a DOI to an Annotation, assuming that >>> CrossRef or some other registration agency is willing to manage the >>> potential drastic increase in registrations, there are some questions it >>> brings up for the working group. >>> >> >> While I think the number of DOIs would certainly increase (if scholarly >> annotation takes off) I imagine that DOIs would only be issued on request, >> not 1:1 for all annotations created. >> > > Why not mint a DOI for every annotation? You already give it a unique > identifier and derive a URL that contains it. > You're right to zero in on this issue as the crux. One obvious reason we wouldn't want to issue a CrossRef DOI for every annotation is that they cost money. Even at a few pennies apiece for the cheapest types at volume, I'm pretty sure we don't want to be paying another service for the right to create identifiers for every annotation we publish. An alternative would be for H. to become a registration agency itself-- as Bill suggested. I'm not sure what the implications of that are, including costs (are there still per-DOI costs that an RA shares with the mothership?) but perhaps it's worth exploring. > > >> >>> >>> * Is the DOI the canonical identifier for the Annotation? >>> >> >> So I may be off base here, but I think there are perhaps two different >> senses of the word "canonical" at play here. >> >> From an annotation systems perspective, it seems unlikely that the DOI is >> ever going to be canonical in the sense that it becomes the *primary >> identifier* replacing the one we minted originally. We'll want to use a >> consistent identifier for all our annotations internally, not different >> ones depending on whether a DOI was issued. (What if someone captured the >> URL of the annotation *prior* to the DOI issuance? We can't ourselves fail >> to resolve the "old" address of the annotation.) I assume there may even >> be performance issues underlying this. This is perhaps more true of >> annotation systems than regular publications because annotations would be >> born without DOIs and presumably get them later, and I'm not imagining that >> would change. Otherwise we'd be issuing DOIs for every trivial annotation >> from inception, and that indeed would be massive. >> > > All of this paragraph seems to be conclusions based on the earlier > assumption that annotations are "born without DOIs". > > >> Even assuming a DOI has been issued for an annotation, if someone else >> comes along and wants to tweet out the same annotation, and exposes our >> share dialog to get the link, are they going to care whether there is a >> DOI, and if there is one, is that the one that they necessarily want to >> use? (I'm presuming if a DOI was issued, we'd show both the original style, >> and also the DOI side by side) The tweeter doesn't really care about >> permanence, and they'd probably just opt for the link style they're >> familiar with (in our case, hyp.is/<TOKEN>). That one will also be more >> performant since it doesn't have to go through a resolver first. >> > > The hyp.is service is a resolver, it just resolves your tokens rather > than DOIs. > > The differences with DOIs are that your redirect would not be branded and, > as is the function of A DOI, not dependant upon your continued ownership > and operation of the hyp.is or hypothes.is domains. > > Why assume someone tweeting would prefer one or the other and doesn't care > about permanence? > >>
Received on Saturday, 7 May 2016 19:42:28 UTC