Subject: [CODE4LIB] Assigning DOI for local content

From: Ranti Junus <[email-masked]>
Date: Tue, 17 Nov 2009 17:58:40 -0500

Hi All,

I was asked by somebody from a college @ my institution whether they
should go with assigning DOI for their journal articles:
http://llt.msu.edu/

I can see the advantage of this approach and my first thought is more
about whether they have resources in running their purl server, or
whether they would need to do it through crossref (or any other
agency.) Has anybody had any experience about this?

Moreover, are there other factors that one should consider (pros and
cons) about this? Or, looking at the structure of their content,
whether they ever need DOI? Any ideas and/or suggestions?

Any insights about this is much appreciated.

thanks,
ranti.

-- 
Bulk mail.  Postage paid.

---

From: Jonathan Rochkind <[email-masked]>
Date: Tue, 17 Nov 2009 18:19:57 -0500

So I have no actual experience with this.

But you have to pay for DOI's.  I've never done it, but I don't think 
you neccesarily have to run your own purl server -- CrossRef takes care 
of it.  Of course, if your documents are going to be moving all over the 
place, if you run your own purl server and register your purls with 
CrossRef, then when a document moves, you can update your local purl 
server; otherwise, you can update CrossRef, heh.

It certainly is useful to have DOIs, I agree.  I would suggest they 
should just contact cross-ref and get information on the cost, and what 
their responsibilities are, and then they'll be able to decide.  If the 
'structure of their content' is journal articles, then, sure DOI is 
pretty handy for people wanting to cite or link to those articles.

Jonathan

---

From: "Bucknell, Terry" <[email-masked]>
Date: Tue, 17 Nov 2009 23:44:06 +0000

You should be able to find all the information you need about CrossRef fees and rules at:

http://www.crossref.org/02publishers/20pub_fees.html

and

http://www.crossref.org/02publishers/59pub_rules.html

Information about the system of registering and maintaining DOIs is at:

http://www.crossref.org/help/

Note that as well as registering DOIs for the articles in LLT, LLT would be obliged to link to the articles cited by LLT articles (for cited articles that have DOIs too). Looking at the LLT site, it looks like they would have to change their 'abstract' pages to 'abstract plus cited refs', or change the way that their PDFs are created so that they include DOI links for cited references. (Without this the whole system would fail: publishers would expect traffic to come to them, but wouldn't have to send traffic elsewhere).

I'd agree that DOIs are in general a Good Thing (and for e-books / e-book chapters, and reference work entries as well as e-journal articles). The CrossRef fees are deliberately set so as not to exclude single-title publishers. Here's an example of a single-title, university-based e-journal in the UK that provides DOIs, so it must be a CrossRef member: http://www.bioscience.heacademy.ac.uk/journal/.

Terry Bucknell
Electronic Resources Manager
University of Liverpool

-----Original Message-----
From: Code for Libraries [mailto:[email-masked]] On Behalf Of Jonathan Rochkind
Sent: 17 November 2009 23:20
To: [email-masked]
Subject: Re: [CODE4LIB] Assigning DOI for local content

Jonathan

---

From: Jonathan Rochkind <[email-masked]>
Date: Tue, 17 Nov 2009 18:50:02 -0500

Bucknell, Terry wrote:
> Note that as well as registering DOIs for the articles in LLT, LLT would be obliged to link to the articles cited by LLT articles (for cited articles that have DOIs too).

Huh, I didn't know that. I understand the motivation, but investigating 
whether every cited article has a DOI and then making sure to include 
it... is non-trivial labor.

Jonathan

---

From: "Bucknell, Terry" <[email-masked]>
Date: Tue, 17 Nov 2009 23:58:24 +0000

They automate the process for obtaining DOIs for cited articles. See http://www.crossref.org/01company/16fastfacts.html:

"In a separate process, the publisher also submits the citations contained in each deposited article to the Reference Resolver, the front-end component of the MDDB that allows for the retrieval of DOIs. This way, the publisher can, as part of its electronic production process, add outbound links to any of an article’s citations that point to content already registered in the CrossRef system. The CrossRef website includes technical specifications for querying and a demo of the DOI look-up process. If you know the DOI for an article, that’s all you need to know in order to locate it persistently. If a publisher changes the location of an article, it need only update the URL for the article in one place with CrossRef."

Terry Bucknell

-----Original Message-----
From: Code for Libraries [mailto:[email-masked]] On Behalf Of Jonathan Rochkind
Sent: 17 November 2009 23:50
To: [email-masked]
Subject: Re: [CODE4LIB] Assigning DOI for local content

Jonathan

---

From: Jodi Schneider <[email-masked]>
Date: Tue, 17 Nov 2009 23:58:37 +0000

The first question is: what are they trying to accomplish by having DOIs?

Do they have a long-term plan for persistence of their content? Financial
plan?

If they're looking for persistent identifiers, I don't understand (a
priori), why DOI is better, as an identifier scheme, than any other
'persistent identifier scheme' (ARK [1], PURL, Handle, etc[2]). (Though I
really like CrossRef and the things they're doing.)

[1] http://www.cdlib.org/inside/diglib/ark/
[2] http://www.persistent-identifier.de/english/204-examples.php

-Jodi

On Tue, Nov 17, 2009 at 11:44 PM, Bucknell, Terry <
[email-masked]> wrote:

> Note that as well as registering DOIs for the articles in LLT, LLT would be
> obliged to link to the articles cited by LLT articles (for cited articles
> that have DOIs too). Looking at the LLT site, it looks like they would have
> to change their 'abstract' pages to 'abstract plus cited refs', or change
> the way that their PDFs are created so that they include DOI links for cited
> references. (Without this the whole system would fail: publishers would
> expect traffic to come to them, but wouldn't have to send traffic
> elsewhere).
>
> I'd agree that DOIs are in general a Good Thing (and for e-books / e-book
> chapters, and reference work entries as well as e-journal articles). The
> CrossRef fees are deliberately set so as not to exclude single-title
> publishers. Here's an example of a single-title, university-based e-journal
> in the UK that provides DOIs, so it must be a CrossRef member:
> http://www.bioscience.heacademy.ac.uk/journal/.
>
>
> Terry Bucknell

---

From: Jodi Schneider <[email-masked]>
Date: Wed, 18 Nov 2009 00:05:16 +0000

On Tue, Nov 17, 2009 at 11:50 PM, Jonathan Rochkind <[email-masked]>wrote:

> Bucknell, Terry wrote:
>
>> Note that as well as registering DOIs for the articles in LLT, LLT would
>> be obliged to link to the articles cited by LLT articles (for cited articles
>> that have DOIs too).
>>
>
> whether every cited article has a DOI and then making sure to include it...
> is non-trivial labor.
>

It does allow precise "cited by" measures:
http://www.crossref.org/citedby.html

This is where CrossRef's awesomeness comes in:
http://www.crossref.org/guestquery/#stqsearch

http://www.crossref.org/SimpleTextQuery/

as well as various experiments:
http://labs.crossref.org/
CrossRef does have certain free, lookup services which might be appropriate
for services like Umlaut, if you can sign a licensing agreement.

-Jodi

---

From: Eric Hellman <[email-masked]>
Date: Tue, 17 Nov 2009 22:13:59 -0500

The most important reason for a journal to submit its metadata to Crossref is to get citations in other journals to link to yours, and of course to get your citations linked to other journals.

The redirection system can be useful of course, but the link discovery system, and the fact that it's embedded in so many other publisher workflows, makes it invaluable.

Eric

>>> Any insights about this is much appreciated.

Eric Hellman
President, Gluejar, Inc.
41 Watchung Plaza, #132
Montclair, NJ 07042
USA

[email-masked] 
http://go-to-hellman.blogspot.com/

---

From: "Rees, John (NIH/NLM) [E]" <[email-masked]>
Date: Wed, 18 Nov 2009 09:05:12 -0500

And DOIs are just a managed implementation of Handles which the IDF created, so you could go the Handles route for free. But then you lose the CrossRef services, etc. if that is important to you.

John P. Rees, MA, MLIS
Curator, Archives and Modern Manuscripts
History of Medicine Division, MSC 3819
National Library of Medicine
8600 Rockville Pike
Bethesda, MD 20894

-----Original Message-----
From: Jodi Schneider [mailto:[email-masked]] 
Sent: Tuesday, November 17, 2009 6:59 PM
To: [email-masked]
Subject: Re: [CODE4LIB] Assigning DOI for local content

-Jodi

---

From: "Han, Yan" <[email-masked]>
Date: Wed, 18 Nov 2009 10:19:11 -0700

Currently DOI uses Handle (technology) with it social framework (i.e. administrative body to manage DOI). In technical sense, PURL is not going to last long. 
Crossref handles DOI registration in U.S. In Europe and Aisa, they have other organizations to handle it. DOI is also currently going through ISO standardization process. The other fact is that DOI has the biggest number of usage than other Persistent Identifiers. More info can be found at http://www.doi.org/faq.html 

Yan

-----Original Message-----
From: Code for Libraries [mailto:[email-masked]] On Behalf Of Jodi Schneider
Sent: Tuesday, November 17, 2009 4:59 PM
To: [email-masked]
Subject: Re: [CODE4LIB] Assigning DOI for local content

-Jodi

---

From: Ranti Junus <[email-masked]>
Date: Wed, 18 Nov 2009 13:08:15 -0500

Fascinating. I learned a lot from these discussions. Thank you all so much!

ranti.

-- 
Bulk mail.  Postage paid.

---

From: Stuart Lewis <[email-masked]>
Date: Thu, 19 Nov 2009 11:30:27 +1300

To me, one of the most important selling points of DOIs over any of those other systems, is that the DOIs are starting to have brand-recognition with users. Faculty generally know what a DOI is, what it does, and the importance of having one, whereas they don't know what a PURL or a handle is. (I say this coming from a DSpace background where we have to explain what handles are, and usually end up saying "they're like DOIs" to which the audience starts nodding).

Stuart Lewis
IT Innovations Analyst and Developer
Te Tumu Herenga The University of Auckland Library
Auckland Mail Centre, Private Bag 92019, Auckland 1142, New Zealand
Ph: 64 9 373-7599 x81928
http://www.library.auckland.ac.nz/

---

From: Ross Singer <[email-masked]>
Date: Wed, 18 Nov 2009 22:11:21 -0500

> Currently DOI uses Handle (technology) with it social framework (i.e. administrative body to manage DOI). In technical sense, PURL is not going to last long.

I'm not entirely sure what this is supposed to mean (re: purl), but
I'm pretty sure it's not true.

I'm also pretty sure there's little to no direct connection between
purl and doi despite a superficial similarity in scope.

-Ross.

---

From: Tom Keays <[email-masked]>
Date: Thu, 19 Nov 2009 09:22:35 -0500

> The first question is: what are they trying to accomplish by having DOIs?

DOIs are just a form of Handle, which is a persistent URL schema. I
don't think I need to explain what PURLs are designed to accomplish.

> really like CrossRef and the things they're doing.)

The advantage is that DOIs over other PURLs are used only for citation
purposes. As someone who works with a lot of students and faculty, I
have observed that DOIs are becoming familiar to them as a definitive
citation identifier. As more journals, publishing in an online
environment, stop using page numbers in their citations and turn
instead to article identifiers -- e.g., citations like this one:

Neylon C, Wu S (2009) Article-Level Metrics and the Evolution of
Scientific Impact. PLoS Biol 7(11): e1000242.
doi:10.1371/journal.pbio.1000242

then DOIs become the most consistently recognizable identifier for
constructing findable citations. So, you could use a PURL, but they
wouldn't be understood to mean the same thing.

Also, DOIs are not dependent on a single resolver -- i.e., you don't
have to send them through http://dx.doi.org/ although that's largely
been the case up to this point in time. PURLs tend to be
server-specific. We don't have to think too far back to recall an
instance when a PURL server failed, causing some temporary access
problems. Hopefully, DOIs are less vulnerable to this -- although this
certainly hasn't been tested.

And, responding to Jonathan, who said:
>investigating whether every cited article has a DOI and then making sure
>to include it... is non-trivial labor.

It certainly is if you have to go back and apply them to a backfile of
published articles. However, with the Code4Lib Journal, I've been
doing this all along in the articles I've edited. CrossRef has good
tools for finding this information and when that fails, I go to the
cited article itself. Some work, yes, but I figure that's part of my
job as an editor.

Tom

---

From: "Han, Yan" <[email-masked]>
Date: Thu, 19 Nov 2009 10:18:30 -0700

Please explain in more details, that will be more helpful. 
It has been a while. Back to 2007, I checked PURL's architecture, and it was straightly handling web addresses only. Of course, current HTTP protocol is not going to last forever, and there are other protocols in the Internet. The coverage of PURL is not enough. 
From PURL's website, it still says " PURLs (Persistent Uniform Resource Locators) are Web addresses that act as permanent identifiers in the face of a dynamic and changing Web infrastructure." I am not sure what "web addresses" means.  http://www.purl.org/docs/help.html#overview says " PURLs are Persistent Uniform Resource Locators (URLs). A URL is simply an address on the World Wide Web". We all know that "World Wide Web" is not "the Internet". What if info resource can be accessed through other Internet Protocols (FTP, VOIP, ....)?  This is the limitation of PURL. 
PURL is doing re-architecture, though I cannot find out more documentation.
The Handle system is " The Handle System is a general purpose distributed information system that provides efficient, extensible, and secure HDL identifier and resolution services for use on networks such as the Internet.". http://www.handle.net/index.html Notice the difference in definition. 

Yan

-----Original Message-----
From: Code for Libraries [mailto:[email-masked]] On Behalf Of Ross Singer
Sent: Wednesday, November 18, 2009 8:11 PM
To: [email-masked]
Subject: Re: [CODE4LIB] Assigning DOI for local content

-Ross.

---

From: Ross Singer <[email-masked]>
Date: Thu, 19 Nov 2009 12:51:19 -0500

Back in 2007, I had a different job, different email address and lived
in a different state.  Things change.  If people are sending emails to
[email-masked] to fix the library web services, they are going
to be sorely disappointed and should perhaps check
http://www.library.gatech.edu/about/staff.php for updates.

purl.org has been going through a massive architecture change for the
better part of a year now -- which has finally been completed.  It was
a slightly messy transition but they migrated from their homegrown
system to one designed by Zepheira.

I feel like predicting the demise of HTTP and worrying about a
services' ability to handle other protocols is unnecessary hand
wringing.

I still have a telephone (two, in fact).  Both my cell phone and VOIP
home phone are still able to communicate flawlessly with a POTS dial
phone.

My car still has an internal combustion engine based on petroleum.  It
still doesn't fly or even hover.  My wall outlets still accept a plug
made in the 1960s.

PURLs themselves are perfectly compatible with protocols other than HTTP:
http://purl.org/NET/rossfsinger/ftpexample

The caveat being that the initial access point is provided via HTTP.

But then again, so is http://hdl.handle.net/, which, in fact, the only
way currently in practice to dereference handles.

My point is, there's a lot of energy, resources and capital invested
in HTTP.  Even if it becomes completely obsolete, my guess I can still
type "http://purl.org/dc/terms" in spdy://google.com/ and find
something about what I'm looking for.

-Ross.

---

From: Eric Hellman <[email-masked]>
Date: Fri, 20 Nov 2009 14:23:22 -0500

Having incorporated the handle client software into my own stuff rather easily, I'm pretty sure that's not true.

Eric Hellman
President, Gluejar, Inc.
41 Watchung Plaza, #132
Montclair, NJ 07042
USA

[email-masked]

---

From: Ross Singer <[email-masked]>
Date: Fri, 20 Nov 2009 14:31:20 -0500

> Having incorporated the handle client software into my own stuff rather easily, I'm pretty sure that's not true.

Fair enough.  The technology is binding independent.

So you are using and sharing handles using some protocol other than HTTP?

I'm more interested in the sharing part of that question.  What is the
format of the handle identifier in this context?  What advantage does
it bring over HTTP?

-Ross.

---

From: Jodi Schneider <[email-masked]>
Date: Sat, 21 Nov 2009 15:44:38 +0000

I'm really interested to hear that DOIs are starting to have brand
recognition with (some) users. Thanks! -Jodi

---

From: Eric Hellman <[email-masked]>
Date: Mon, 23 Nov 2009 13:07:25 -0500

For example, if you don't want to rely on dx.doi.org as your gateway to the handle system for doi resolution, it would be quite easy for me to deploy my own gateway at dx.hellman.net. I might want to do this if a were an organization paranoid about security and didn't want to disclose to anybody what doi's my organization was resolving. Or, I might want to directly access metadata in the handle system that doesn't go through the http gateways, to provide a service other than resolution.

Does this answer your question, Ross?

Eric Hellman
President, Gluejar, Inc.
41 Watchung Plaza, #132
Montclair, NJ 07042
USA

[email-masked]

---

From: Roy Tennant <[email-masked]>
Date: Mon, 23 Nov 2009 10:32:03 -0800

But minting DOIs requires a Registration Agency which as far as I understand
it, requires $1,000 and approval from the International DOI Federation.[1]
Roy

[1] http://www.doi.org/handbook_2000/governance.html#7.2.2

On 11/23/09 11/23/09 € 10:07 AM, "Eric Hellman" <[email-masked]> wrote:

> For example, if you don't want to rely on dx.doi.org as your gateway to the
> handle system for doi resolution, it would be quite easy for me to deploy my
> own gateway at dx.hellman.net. I might want to do this if a were an
> organization paranoid about security and didn't want to disclose to anybody
> what doi's my organization was resolving. Or, I might want to directly access
> metadata in the handle system that doesn't go through the http gateways, to
> provide a service other than resolution.
>

---

From: Ross Singer <[email-masked]>
Date: Mon, 23 Nov 2009 13:32:16 -0500

> Does this answer your question, Ross?

Yes, sort of.  My question was not so much if you can resolve handles
via bindings other than HTTP (since that's one of the selling points
of handles) as it was "do people actually use this in the real world"?

Of course, it may be impossible to answer that question since, by your
example, such people may not actually be letting anybody know that
they're doing that (although you would probably be somebody with
insider knowledge on this topic).

Also, with your use cases, would these services be impossible if the
only binding was HTTP?  Presumably dx.hellman.net would need to
harvest its metadata from somewhere, which seems like it would leave a
footprint.  It also needs some mechanism to stay in sync with the
master index.  Your non-resolution service also seems to be looking
these things up in realtime.  Would a RESTful or SOAP API (*shudder*)
not accomplish the same goal?

Really, though, the binding argument here is less the issue here than
if you believe http URIs are valid identifiers or not since there's no
reason a URI couldn't be dereferenced via other bindings, either.

-Ross.

---

From: Jonathan Rochkind <[email-masked]>
Date: Mon, 23 Nov 2009 14:52:43 -0500

Ross Singer wrote:
> only binding was HTTP?  
Well, here's the trick about handles, as I understand it.  A handle, for 
instance, a DOI, is "10.1074/jbc.M004545200". 

While, for DOI handles, normally we resolve that using dx.doi.org, at 
http://dx.doi.org/10.1074/jbc.M004545200, that is not actually a 
requirement of the handle system. You can resolve it through any handle 
server, over HTTP or otherwise. Even if it's still over HTTP, it doesn't 
have to be at dx.doi.org, it can be via any handle resolver.

For instance, check this out, it works:

http://hdl.handle.net/10.1074/jbc.M004545200

Cause the DOI is really just a subset of Handles, any resolver 
participating in the handle network can resolve em.  In Eric's 
hypothetical use case, that could be a local enterprise handle resolver 
of some kind. (Although I'm not totally sure that would keep your usage 
data private; the documentation I've seen compares the handle network to 
DNS, it's a distributed system, I'm not sure in what cases handle 
resolution requests are sent 'upstream' by the handle resolver, and if 
actual individual lookups are revealed by that or not. But in any case, 
when Ross suggests -- "Presumably dx.hellman.net would need to harvest 
its metadata from somewhere, which seems like it would leave a 
footprint. It also needs some mechanism to stay in sync with the master 
index." -- my reading this suggests this is _built into_ the handle 
protocol, it's part of handle from the very start (again, the DNS 
analogy, with the emphasis on the distributed resolution aspect), you 
don't need to invent it yourself. The details of exactly how it works, I 
don't know enough to say.  )

Now, I'm somewhat new to this stuff too, I don't completely understand 
how it works.  Apparently hdl.handle.net can <strike>handle</strike> 
deal with any handle globally, while presumably dx.doi.org can only deal 
with the subset of handles that are also DOIs.  And apparently you can 
have a handle resolver that works over something other than HTTP too. 
(Although Ross argues, why would you want to? And I'm inclined to agree).

But appears that the handle system is quite a bit more fleshed out than 
a simple purl server, it's a distributed protocol-independent network.   
The protocol-independent part may or may not be useful, but it certainly 
seems like it could be, it doens't hurt to provide for it in advance. 
The distributed part seems pretty cool to me.

So if it's no harder to set up, maintain, and use a handle server than a 
Purl server (this is a big 'if', I'm not sure if that's the case), and 
handle can do everything purl can do and quite a bit more (I'm pretty 
sure that is the case)... why NOT use handle instead of purl? It seems 
like handle is a more fleshed out, robust, full-featured thing than purl.

Jonathan

> Presumably dx.hellman.net would need to

---

From: MJ Suhonos <[email-masked]>
Date: Mon, 23 Nov 2009 15:22:05 -0500

Hi all, couldn't resist jumping in on this one:

> But appears that the handle system is quite a bit more fleshed out than a simple purl server, it's a distributed protocol-independent network.   The protocol-independent part may or may not be useful, but it certainly seems like it could be, it doens't hurt to provide for it in advance. The distributed part seems pretty cool to me.
> 
> So if it's no harder to set up, maintain, and use a handle server than a Purl server (this is a big 'if', I'm not sure if that's the case), and handle can do everything purl can do and quite a bit more (I'm pretty sure that is the case)... why NOT use handle instead of purl? It seems like handle is a more fleshed out, robust, full-featured thing than purl.

I think it's also worth adding that handles (and DOIs) can also be used to create PURLs, eg. http://purl.org/handles/10.1074/jbc.M004545200 (which isn't a real link) -- in fact, there's no reason why you couldn't use a PURL server as a local handle resolver, aside from the fact that it wouldn't be participating in the handle network.  See, for example: <http://www.ukoln.ac.uk/distributed-systems/poi/>

One thing PURL has going for it is that it has defined meanings for HTTP response codes; these are similar to REST responses though I don't know if they're the same; the most recent documentation mentions that PURL servers are RESTful but I suspect this is part of the recent re-tooling of PURL.
<http://purl.oclc.org/docs/help.html#rest>

The only potential advantage of PURLs that I can see is the ability to do partial redirects, eg. http://purl.org/redirect/xxxxxx --> http://some.server/long.path/xxxxx -- though one could make the case that this might be useful for directing handle requests to the appropriate servers, eg.
http://purl.org/handles/10.123/xxxxxx --> http://handleserver1/xxxxxx and http://purl.org/handles/10.456/xxxxxx --> http://doiserver2/xxxxxx ...

Overall, I tend to agree that handles seem more flexible -- or at least, less tied to URL and HTTP -- than PURLs.  Not having to rely on a specific server for resolution is a fairly major bonus (think DNS-style round-robin resolver querying for handles; not possible with PURLs).

MJ

PS.  At the risk of reposting potentially old news:  <http://web.mit.edu/handle/www/purl-eval.html>

---

From: Ross Singer <[email-masked]>
Date: Mon, 23 Nov 2009 15:53:14 -0500

> instance, a DOI, is "10.1074/jbc.M004545200".

Well, actually, it could be:
10.1074/jbc.M004545200
doi:10.1074/jbc.M004545200
info:doi/10.1074/jbc.M004545200

etc.  But there's still got to be some mechanism to get from there to:
http://dx.doi.org/10.1074/jbc.M004545200
or
http://dx.hellman.net/10.1074/jbc.M004545200

I don't see why it's any different, fundamentally, than:
http://purl.hellman.net/?purl=http%3A%2F%2Fpurl.org%2FNET%2Fdoi%2F10.1074%2Fjbc.M004545200

besides being prettier.

Anyway, my argument wasn't that Purl was technologically more sound
that handles -- Purl services have a major single-point-of-failure
problem -- it's just that I don't buy the argument that handles are
somehow superior because they aren't limited to HTTP.

What I'm saying is that there plenty of valid reasons to value handles
more than purls (or any other indirection service), but independence
to HTTP isn't one of them.

-Ross.

> http://dx.doi.org/10.1074/jbc.M004545200, that is not actually a requirement
> of the handle system. You can resolve it through any handle server, over
> HTTP or otherwise. Even if it's still over HTTP, it doesn't have to be at
> dx.doi.org, it can be via any handle resolver.
>
> Cause the DOI is really just a subset of Handles, any resolver participating
> in the handle network can resolve em.  In Eric's hypothetical use case, that
> could be a local enterprise handle resolver of some kind. (Although I'm not
> totally sure that would keep your usage data private; the documentation I've
> seen compares the handle network to DNS, it's a distributed system, I'm not
> sure in what cases handle resolution requests are sent 'upstream' by the
> handle resolver, and if actual individual lookups are revealed by that or
> not. But in any case, when Ross suggests -- "Presumably dx.hellman.net would
> need to harvest its metadata from somewhere, which seems like it would leave
> a footprint. It also needs some mechanism to stay in sync with the master
> protocol, it's part of handle from the very start (again, the DNS analogy,
> with the emphasis on the distributed resolution aspect), you don't need to
> invent it yourself. The details of exactly how it works, I don't know enough
> to say.  )
>
> Now, I'm somewhat new to this stuff too, I don't completely understand how
> it works.  Apparently hdl.handle.net can <strike>handle</strike> deal with
> any handle globally, while presumably dx.doi.org can only deal with the
> subset of handles that are also DOIs.  And apparently you can have a handle
> resolver that works over something other than HTTP too. (Although Ross
> argues, why would you want to? And I'm inclined to agree).
>
> But appears that the handle system is quite a bit more fleshed out than a
> simple purl server, it's a distributed protocol-independent network.   The
> protocol-independent part may or may not be useful, but it certainly seems
> like it could be, it doens't hurt to provide for it in advance. The
> distributed part seems pretty cool to me.
>
> handle can do everything purl can do and quite a bit more (I'm pretty sure
> that is the case)... why NOT use handle instead of purl? It seems like
> handle is a more fleshed out, robust, full-featured thing than purl.
>
> Jonathan
>
>
>
>

---

From: Jonathan Rochkind <[email-masked]>
Date: Mon, 23 Nov 2009 16:03:01 -0500

The actual "handle" is "10.1074/jbc.M004545200 ".  If your software 
wants to get a "handle" to give it to any handle resolver of it's 
choice, it's going to have to parse the "doi:" or "info:" versions to 
get the handle out first.  The info version is a URI that has a DOI 
handle embedded in it.  The doi version is... um, I dunno, just a 
convention, I think, that has a DOI handle embedded in it.

Likewise, if your software had a URI, and was smart enough to know that 
the URI "http://dx.doi.org/10.1074/jbc.M004545200" actually had a handle 
embedded in it, it could strip the handle out, and then resolve it 
against some other handle server that participates in the handle 
network, like hdl.handle.net.  But that would be kind of going against 
the principle to treat URI's as opaque identifiers and not parse them 
for internal data.

But me, I end up going against that principle all the time in actual 
practice, actually for scenarios kind of analagous to, but less 
well-defined and spec'd than, getting the actual "handle" out of the URI 
and resolving it against some other service. For instance, getting an 
OCLCnum out of an http://worldcat.oclc.org/ URI, to resolve against my 
local catalog that knows something about OCLCnums, but doesn't know 
anything about http://worldcat.oclc.org URIs that happen to have an 
OCLCnum embedded in them. Or getting an ASIN out of a 
http://www.amazon.com/ URI, to resolve against Amazon's _own_ web 
services, which ironically know something about ASIN's but don't know 
anything about www.amazon.com URI's that have an ASIN embedded in them.  
Actually quite analagous to getting the actual handle out of an 
http://dx.doi.org or http://hdi.handle.net URI, in order to resolve 
against the resolver of choice.

Jonathan

---

From: Tom Keays <[email-masked]>
Date: Mon, 23 Nov 2009 17:07:26 -0500

Interesting stuff. I never really thought about it before that DOIs
can be served up by the Handle server. E.G.,

http://dx.doi.org/10.1074/jbc.M004545200 <=>
http://hdl.handle.net/10.1074/jbc.M004545200

But, even more surprising to me was realizing that Handles can be
resolved by the DOI server. Or presumably any DOI server.

http://hdl.handle.net/2027.42/46087 <=> http://dx.doi.org/2027.42/46087

I suppose I should have understood this point since the Handle service
does sort of obliquely say this.

http://www.handle.net/factsheet.html

Anyway, good to have it made explicit.

Tom

On Mon, Nov 23, 2009 at 4:03 PM, Jonathan Rochkind <[email-masked]> wrote:
> The actual "handle" is "10.1074/jbc.M004545200 ".  If your software wants to
> get a "handle" to give it to any handle resolver of it's choice, it's going
> to have to parse the "doi:" or "info:" versions to get the handle out first.
>  The info version is a URI that has a DOI handle embedded in it.  The doi
> version is... um, I dunno, just a convention, I think, that has a DOI handle
> embedded in it.
>
> Likewise, if your software had a URI, and was smart enough to know that the
> URI "http://dx.doi.org/10.1074/jbc.M004545200" actually had a handle
> embedded in it, it could strip the handle out, and then resolve it against
> some other handle server that participates in the handle network, like
> hdl.handle.net.  But that would be kind of going against the principle to
> treat URI's as opaque identifiers and not parse them for internal data.
>
> practice, actually for scenarios kind of analagous to, but less well-defined
> and spec'd than, getting the actual "handle" out of the URI and resolving it
> against some other service. For instance, getting an OCLCnum out of an
> http://worldcat.oclc.org/ URI, to resolve against my local catalog that
> knows something about OCLCnums, but doesn't know anything about
> http://worldcat.oclc.org URIs that happen to have an OCLCnum embedded in
> them. Or getting an ASIN out of a http://www.amazon.com/ URI, to resolve
> against Amazon's _own_ web services, which ironically know something about
> ASIN's but don't know anything about www.amazon.com URI's that have an ASIN
> embedded in them.  Actually quite analagous to getting the actual handle out
> of an http://dx.doi.org or http://hdi.handle.net URI, in order to resolve
>>> requirement
>>> participating
>>> analogy,
>>> how
>>> sure

---

From: "Ben O'Steen" <[email-masked]>
Date: Mon, 23 Nov 2009 22:23:17 +0000

What happens if the main doi resolver goes down? I'd be interested to see
how well a local resolver works when blocked from this upstream server. Are
there any other upstream servers?

Ben

On Nov 23, 2009 10:10 PM, "Tom Keays" <[email-masked]> wrote:

Tom

On Mon, Nov 23, 2009 at 4:03 PM, Jonathan Rochkind <[email-masked]> wrote:
> The actual "handle" ...

---

From: Jonathan Rochkind <[email-masked]>
Date: Mon, 23 Nov 2009 17:35:57 -0500

What do you mean by a local resolver?  If you're talking about a local 
handle resolver adhering to the handle spec... well, then it depends on 
the handle spec I guess, which I don't know. But since all the handle 
documetnation keeps saying "like DNS", then I'd imagine it has similar 
(or better) redundancy built into it as DNS does. But I don't know.

Poking around on handle.net, it looks like the handle infrastructure 
supports this,but you would have had to actually configure 'backup' 
handle resolvers -- similar to DNS in that if the DNS for your domain 
goes down, and you _haven't_ gotten someone else at another location to 
be a 'backup' resolver for you, and specified them as a nameserver in 
your DNS record... then you're out of luck. But the protocol supports 
that, and if you have done it (as most everyone does with DNS), you're 
good.

I have no idea if 'most everyone' does it with handle or not, but handle 
supports it. Note that if dx.doi.org goes down, you obviously won't be 
able to resolve at dx.doi.org -- but IF it works as I think (I'm still 
confused), AND dx.doi.org has distributed their handles to a backup 
resolver, then you'd still be able to resolve via hdl.handle.net, or via 
your own local handle resolver (which will in turn find the backup 
resolver).

http://www.handle.net/lhs.html

Jonathan

---

From: Jonathan Rochkind <[email-masked]>
Date: Mon, 23 Nov 2009 17:39:15 -0500

More info here too:

http://www.handle.net/introduction.html

This handle stuff is interesting, but I don't entirely understand it.

I guess if the Global Handle Service really went down, it would be 
similar to a root-level DNS server going down -- you'd be in trouble, 
somewhat mitigated by whatever data your local resolver had cached.

Of course, CNRI maintains several failover mirrors of the Global Handle 
Service for that reason. (Much as we'd hope all the root-level DNS 
servers are thorougly failover-ed).

Jonathan

---

From: Eric Hellman <[email-masked]>
Date: Wed, 25 Nov 2009 14:11:37 -0500

> of handles) as it was "do people actually use this in the real world"?

Well, the short answer to that question is "yes."

I think the discussion veered out of the zone of my understanding the point of it. The original question related to whether a journal should register Crossref doi's, and the short answer to that, as far as I'm concerned,  is an emphatic "yes".

Eric Hellman
President, Gluejar, Inc.
41 Watchung Plaza, #132
Montclair, NJ 07042
USA

[email-masked]