Handle on Crossref

DOI resolution and deposit outage on 17 March 2026

Dominika Tkaczyk — Mon, 30 Mar 2026 00:00:00 +0000

On 17 March 2026, we experienced an outage that affected DOI resolution for Crossref DOIs and the deposit of metadata records by Crossref members. In this summary, we outline what happened, the impact on our community, and the steps we are taking to strengthen our systems and processes as a result.

Starting around 06:30 UTC, a surge of traffic to the Handle System, governed by the DOI Foundation and operated by CNRI, caused instability across several handle servers. As a result, users couldn’t resolve Crossref DOIs. Because the Crossref system relies on the Handle System to register new DOIs and update resolution information for existing ones, metadata deposits by Crossref members were also failing.

Although the handle service was restored by 09:30 UTC, the Crossref system held onto stale authentication sessions and did not automatically recover. Once we restarted the affected servers, deposit processing returned to normal around 10:18 UTC. We later reprocessed the failed submissions to ensure that members did not need to take any action.

While incidents like this are disruptive for our community, several aspects of our response worked well. Our support and technology teams reacted quickly, and we were able to restore the deposit workflow promptly. We were also able to reach CNRI through established communication channels, and they responded out of hours to begin mitigation.

The incident also highlighted areas where we can improve our processes and resilience. In addition to the changes made by CNRI (more backend handle servers and tighter rate limiting), Crossref is taking the following actions:

Knowledge sharing and documentation: Crossref, like all Registration Agencies, relies on the Handle System. We are reviewing the technical documentation describing how the Crossref system integrates with the Handle System, and we will continue working with CNRI to stay informed as the handle infrastructure evolves.
Improving handle session management: We are reviewing how our system manages handle sessions to explore how recovery could occur automatically after connection disruptions.
Submission rerun process improvements: We will review, clarify, and document the workflow for identifying and rerunning affected member submissions after disruptions to deposit processing.

Reliable DOI resolution and deposit processing are central to the research ecosystem. We’re committed to continuously improving the resilience of our systems and we will continue to learn from incidents like this one to strengthen them further.

If you have any questions, we are always happy to hear from you.

You can stay informed about the status of our services by subscribing to updates at status.crossref.org

January 2015 DOI Outage: Followup Report

Geoffrey Bilder — Tue, 17 Mar 2015 00:00:00 +0000

Background

On January 20th, 2015 the main DOI HTTP proxy at doi.org experienced a partial, rolling global outage. The system was never completely down, but for at least part of the subsequent 48 hours, up to 50% of DOI resolution traffic was effectively broken. This was true for almost all DOI registration agencies, including Crossref, DataCite and mEDRA.

At the time we kept people updated on what we knew via Twitter, mailing lists and our technical blog at CrossTech. We also promised that, once we’d done a thorough investigation, we’d report back. Well, we haven’t finished investigating all implications of the outage. There are both substantial technical and governance issues to investigate. But last week we provided a preliminary report to the Crossref board on the basic technical issues, and we thought we’d share that publicly now.

The Gory Details

First, the outage of January 20th was not caused by a software or hardware failure, but was instead due to an administrative error at the Corporation for National Research Initiatives (CNRI). The domain name “doi.org” is managed by CNRI on behalf of the International DOI Foundation (IDF). The domain name was not on “auto-renew” and CNRI staff simply forgot to manually renew the domain. Once the domain name was renewed, it took about 48 hours for the fix to propagate through the DNS system and for the DOI resolution service to return to normal. Working with CNRI we analysed traffic through the Handle HTTP proxy and here’s the graph:

The above graph shows traffic over a 24 hour period on each day from January 12, 2015 through February 10th, 2015. The heavy blue line for January 20th and the heavy red line for January 21st show how referrals declined as the doi.org domain was first deleted, and then added back to DNS.

It could have been much worse. The domain registrar (GoDaddy) at least had a “renewal grace and registry redemption period” which meant that even though CNRI forgot to pay its bill to renew the domain, the domain was simply “parked” and could easily be renewed by them. This is the standard setting for GoDaddy. Cheaper domain registrars might not include this kind of protection by default. Had there been no grace period, then it would have been possible for somebody other than CNRI to quickly buy the domain name as soon as it expired. There are many automated processes which search for and register recently expired domain names. Had this happened, at the very least it would have been expensive for CNRI to buy the domain back. The interruption to DOI resolutions during this period would have also been almost complete.

So we got off relatively easy. The domain name is now on auto-renew. The outage was not as bad as it could have been. It was addressed quickly and we can be reasonably confident that the same administrative error will not happen again. Crossref even managed to garner some public praise for the way in which we handled the outage. It is tempting to heave a sigh of relief and move on.

We also know that everybody involved at CNRI, the IDF and Crossref have felt truly dreadful about what happened. So it is also tempting to not re-open old wounds.

But it would be a mistake if we did not examine a fundamental strategic issue that this partial outage has raised: How can Crossref claim that its DOIs are ‘persistent’ if Crossref does not control some of the key infrastructure on which it depends? What can we do to address these dependencies?

What do we mean by “persistent?”

@kaythaney tweets on definition of “persistent”

To start with, we should probably explore what we mean by ‘persistent’. We use the word “persistent” or “persistence” about 470 times on the Crossref web site. The word “persistent” appears central to our image of ourselves and of the services that we provide. We describe our core, mandatory service as the “Crossref Persistent Citation Infrastructure.”

The primary sense of the word “persistent” in the New Oxford American Dictionary is:

Continuing firmly or obstinately in a course of action in spite of difficulty or opposition.

We play on this sense of the word as a synonym for “stubborn” when we half-jokingly say that, “Crossref DOIs are as persistent as Crossref staff.” Underlying this joke is a truth, which is that persistence is primarily a social issue, not a technical issue.

Yet presumably we once chose to use the word “persistent” instead of “perpetual” or “permanent” for other reasons. “Persistence” implies longevity, without committing to “forever.” Scholarly publishers, perhaps more than most industries, understand the long term. After all, the scholarly record dates back to at least 1665 and we know that the scholarly community values even our oldest journal backfiles. By using the word “persistent” as opposed to the more emphatic “permanent” we are essentially acknowledging that we, as an industry, understand the complexity and expense of stewarding the content for even a few hundred years to say nothing of “forever.” Only the chronologically naïve would recklessly coin terms like “permalink” for standard HTTP links which have a documented half-life of well under a decade.

So “persistent” implies longevity- without committing to forever- but this still begs questions. What time span is long enough to qualify as “persistent?” What, in particular, do we mean by “persistent” when we talk about Crossref’s “Persistent Citation Infrastructure?” or of Crossref DOIs being “persistent identifiers?”

What do we mean by “persistent identifiers?”

]5 @violetailik tweets on outage and implication for term “persistent identifier”

First, we often make the mistake of talking about “persistent identifiers” as if there is some technical magic that makes them continue working when things like HTTP URIs break. The very term “persistent identifier” encourages this kind of magical thinking and, ideally, we would instead talk about “persist-able” identifiers. That is, those that have some form of indirection built into them. There are many technologies that do this- Handles, DOIs, Purls, ARKs and every URL shortener in existence. Each of them simply introduces a pointer mapping between an identifier and location where a resource or content resides. This mapping can be updated when the content moves, thus preserving the link. Of course, just because an identifier is persist-able doesn’t mean it is persistent. If Purls or DOIs are not updated when content moves, then they are no more persistent than normal URLs.

Andrew Treloar points out that when we talk about “persistent identifiers,” we tend to conflate several things:

The persistence of the identifier- that is the token or string itself.
The persistence of the thing being pointed at by the identifier. For example, the content.
The persistence of the mapping of the identifier to the thing being identified.
The persistence of the resolver that allows one to follow the mapping of the identifier to the thing being identified.
The persistence of a mechanism for updating the mapping of the identifier to the thing being identified.

If any of the above fails, then “persistence” fails. This is probably why we tend to conflate them in the first place.

Each of these aspects of “persistence” is worthy of much closer scrutiny, however, in the most recent case of the January outage of “doi.org,” the problem specifically occurred with item “D”- the persistence of the resolver. When CNRI failed to renew the domain name for “doi.org” on time, the DOI resolver was rendered unavailable to a large percentage of people over a period of about 48 hours as global DNS servers first removed, and then added back the “doi.org” domain.

Turtles all the way down*

The initial public reaction to the outage was, almost unanimous in one respect- people assumed that the problem originated with Crossref.

@iainh_z tweets to Crossref enquiring about failed DOI resoluton

@LibSkrat tweets at Crossref about DOI outage

This is both surprising and unsurprising. It is surprising because we have fairly recent data indicating that lots of people recognise the DOI brand, but not the Crossref brand. Chances are, that this relatively superficial “brand” awareness does not correlate with understanding how the system works or how it relates to persistence. It is likely plenty of people clicked on DOIs at the time of the outage and, when they didn’t work, simply shrugged or cursed under their breath. They were aware of the term ‘DOI’ but not of the promise of “persistence”. Hence, they did not take to twitter to complain about it, and if they did, they probably wouldn’t have known who to complain to or even how to complain to them (neither CNRI or the IDF has a Twitter account).

But the focus on Crossref is also unsurprising. Crossref is by far the largest and most visible DOI Registration Agency. Many otherwise knowledgeable people in the industry simply don’t know that there are even other RAs.

They also generally didn’t know of the strategic dependencies that exist in the Crossref system. By “strategic dependencies” we are not talking about the vendors, equipment and services that virtually every online enterprise depends on. These kinds of services are largely fungible. Their failures may be inconvenient and even dramatic, but they are rarely existential.

Instead we are talking about dependencies that underpin Crossref’s ability to deliver on its mission. Dependencies that not only affect Crossref’s operations, but also its ability to self-govern and meet the needs of its membership. In this case there are three major dependencies: Two of which are specific to Crossref and other DOI registration agencies and one which is shared by virtually all online enterprises today. The organisations are: The International DOI Foundation (IDF), Corporation for National Research Initiatives (CNRI) and the Internet Corporation for Assigned Names and Numbers (ICANN).

Dependency of RAs on IDF, CNRI and ICANN. Turtles all the way down.

Each of these agencies has technology, governance and policy impacts on Crossref and the other DOI registration agencies, but here we will focus on the technological dependencies.

At the top of the diagram are a subset of the various DOI Registration Agencies. Each RA uses the DOI for a particular constituency (e.g. scholarly publishers) and application (e.g. citation). Sometimes these constituencies/applications overlap (as with mEDRA, Crossref and DataCite), but sometimes they are orthogonal to the other RAs, as is the case with EIDR. All, however, are members of the IDF.

The IDF sets technical policies and development agendas for the DOI infrastructure. This includes recommendations about how RAs should display and link DOIs. Of course all of these decisions have an impact on the RAs. However, the IDF provides little technical infrastructure of its own as it has no full-time staff. Instead it outsources the operation of the system to CNRI, this includes the management of the doi.org domain which the IDF owns.

The actual DOI infrastructure is hosted on a platform called the Handle System which was developed by and is currently run by CNRI. The Handle System is part of a quite complex and sophisticated platform for managing digital objects that was originally developed for DARPA. A subset of the Handle system is designated for use by DOIs and is identified by the “10” prefix (e.g. 10.5555/12345678). The Handle system itself is not based on HTTP (the web protocol). Indeed, one of the much touted features of the Handle System is that it isn’t based on any specific resolution technology. This was seen as a great virtue in the late 1990s when the DOI system was developed and the internet had just witnessed an explosion of seemingly transient, competing protocols (e.g. Gopher, WAIS, Archie, HyperWave/Hyper-G, HTTP, etc.). But what looked like a wild-west of protocols quickly settled into an HTTP hegemony. In practice, virtually all DOI interactions with the Handle system are via HTTP and so, in order to interact with the web, the Handle System employs a “Handle proxy” which translates back and forth between HTTP, and the native Handle system. This all may sound complicated, and the backend of the Handle system is really very sophisticated, but it turns out that the DOI really uses only a fraction of the Handle system’s features. In fact, the vast majority of DOI interactions merely use the Handle system as a giant lookup table which allows one to translate an identifier into a web location. For example, it will take a DOI Handle like this:

10.5555/12345678

and redirect it to (as of this writing) the following URL:

http://psychoceramics.labs.crossref.org.pluma.sjfc.edu/10.5555-12345678.html

This whole transformation is normally never seen by a user. It is handled transparently by the web browser, which does the lookup and redirection in the background using HTTP and talking to the Handle Proxy. In the late 1990s, even doing this simple translation quickly, at scale with a robust distributed infrastructure, was not easy. These days however we see dozens if not hundreds of “URL Shorteners” doing exactly the same thing at far greater scale than the Handle System.

It may seem a shame that more of the Handle Systems features are not used, but the truth is the much touted platform independence of the Handle System rapidly became more of a liability and impediment to persistence than an aid. To be blunt, if in X years a new technology comes out that supersedes the web, what do we think the societal priority is going to be?

To provide a robust and transparent transition from the squillions of existing HTTP URI identifiers that the entire world depends on?
To provide a robust and transparent transition from the tiny subset of Handle-based identifiers that are used by about a hundred million specialist resources?

Quite simply, the more the Handle/DOI systems diverge from common web protocols and practice, then the more we will jeopardise the longevity of our so-called persistent identifiers.

So, in the end, DOI registration agencies really only use the Handle system for translating web addresses. All of the other services and features one might associate with DOIs (reference resolution, metadata lookup, content negotiation, OAI-PMH, REST APIs, Crossmark, CrossCheck, TDM Services, FundRef etc) are all provided at the RA level.

But this address resolution is still critical. And it is exactly what failed for many users on January 20th 2015. And to be clear, it wasn’t the robust and scaleable Handle System that failed. It wasn’t the Handle Proxy that failed. And it certainly wasn’t any RA-controlled technology that failed. These systems were all up and running. What happened was that the standard handle proxy that the IDF recommends RAs use, “dx.doi.org”, was effectively rendered invisible to wide portions the internet because the “doi.org” domain was not renewed. This underscores two important points.

The first is that it doesn’t much matter what precisely caused the outage. In this case it was an administrative error. But the effect would have been similar if the Handle proxies had failed of if the Handle system itself had somehow collapsed. In the end, Crossref and all DOI registration agencies are existentially dependent on the Handle system running and being accessible.

The second is that the entire chain of dependencies from the RAs down through CNRI are also dependent on the DNS system which, in turn, is governed by ICANN. We should really not be making too much of the purported technology independence of the DOI and Handle systems. To be fair, this limitation is inherent to all persistent identifier schemes that aim to work with the web. It really is “turtles all the way down.”

What didn’t fail on January 19th/20th and why?

You may have noticed a lot of hedging in our description of the outage of January 19th/20th. For one thing, we use the term “rolling outage.” Access to the Handle Proxy via “dx.doi.org” was never completely unavailable during the period. As we’ve explained, this is because the error was discovered very quickly and the domain was renewed hours after it expired. The nature of DNS propagation meant that even as some DNS servers were deleting the “doi.org” entry, others were adding it back to their tables. In some ways this was really confusing because it meant it was difficult to predict where the system was working and where it wasn’t. Ultimately it all stabilised after the standard 48-hour DNS propagation cycle.

But there were also some Handle-based services that simply were not affected at all by the outage. During the outage, a few people asked us if there was an alternative way to resolve DOIs. The answer was “yes,” there were several. It turns out that “doi.org” is not the only DNS name that points to the Handle Proxy. People could easily substitute “dx.doi.org” with “dx.crossref.org” or “dx.medra.org” or “hdl.handle.net” and “resolve” any DOI. Many of Crossref’s internal services use these internal names and so the services continued to work. This is partly why we only discovered the “doi.org” was down from people reporting it on Twitter.

And, of course, there were other services that were not affected by the outage. Crossmark, the REST API, and Crossref Metadata Search all continued to work during the outage.

Protecting ourselves

So what can we do to reduce our dependencies and/or the risks intrinsic to those dependencies?

Obviously, the simplest way to have avoided the outage would have been to ensure that the “doi.org” domain was set to automatically renew. That’s been done. Is there anything else we should do? A few ideas have been floated that might allow us to provide even more resilience. They range greatly in complexity and involvement.

Provide well-publicised public status dashboards that show what systems are up and which clearly map dependencies so that people could, for instance, see that the doi.org server was not visible to systems that depended on it. Of course, if such a dashboard had been hosted at doi.org, nobody would have been able to connect to it. Stoopid turtles.
Encourage DOI RAs to have the members point to Handle proxies using domain names under the RA’s control. Simply put, if Crossref members had been using “dx.crossref.org” instead of “dx.doi.org”, then Crossref DOIs would have continued to work throughout the outage of “doi.org”. The same with mEDRA, and the other RAs. This way each RA would have control over another critical piece of their infrastructure. It would also mean that if any single RA made a similar domain name renewal mistake, the impact would be isolated to a particular constituency. Finally, using RA-specific domains for resolving DOIs might also make it clear that different DOIs are managed by different RAs and might have different services associated with them. Perhaps Crossref would spend less time supporting non-Crossref DOIs?
Provide a parallel, backup resolution technology that could be pointed to in the event of a catastrophic Handle System failure. For example we could run a parallel system based on PURLs, ARKs or another persist-able identifier infrastructure.
Explore working with ICANN to get the handle resolvers moved under the special “.arpa” top level domain (TLD). This TLD (RFC 3172) is reserved for services that are considered to be “critical to the operation of the internet.” This is an option that was first discussed at a meeting of persistent identifier providers in 2011.

These are all tactical approaches to addressing the specific technical problem of the Handle System becoming unavailable, but they do not address deeper issues relating to our strategic dependence on several third parties. Even though the IDF and CNRI provide us with pretty simple and limited functionality, that functionality is critical to our operations and our claim to be providing persistent identifiers. Yet these technologies are not in our direct control. We had to scramble to get hold of people to fix the problem. For a while, we were not able to tell our users or members what was happening because we did not know ourselves.

The irony is that Crossref was held to account, and we were in the firing line the entire time. Again, this was almost unavoidable. In addition to being the largest DOI RA, we are also the only RA that has any significant social media presence and support resources. Still, it meant that we were the public face of the outage while the IDF and CNRI remained in the background.

And this is partly why our board has encouraged us to investigate another option:

Explore what it would take to remove Crossref dependencies on the IDF and CNRI.

Crossref is just part of a chain of dependencies the goes from our members down through the IDF, CNRI and, ultimately, ICANN. Our claim to providing a persistent identifier structure depends entirely on the IDF and CNRI. Here we have explored some of the technical dependencies. But there are also complex governance and policy implications of these dependencies. Each organisation has membership rules, guidelines and governance structures which can impact Crossref members. Indeed, the IDF and CNRI are themselves members of groups (ISO and DONA, respectively) which might ultimately have policy or governance impact for DOI registration agencies. We will need to understand the strategic implications of these non technical dependencies as well.

Note that the Crossref board has merely asked us to “explore” what it would take to remove dependencies. They have not asked us to actually take any action. Crossref has been massively supportive of the IDF and CNRI, and they have been massively supportive of us. Still, over the years we have all grown and our respective circumstances have changed. It is important that occasionally we question what we might have once considered to be axioms. As we discussed above, we use the term “persistent” which, in turn, is a synonym for “stubborn.” At the very least we need to document the inter-dependencies that we have so that we can understand just how stubborn we can reasonably expect our identifiers to be.

The outage of January 20th was a humbling experience. But in a way we were lucky: Forgetting to renew the domain name was a silly and prosaic way to partially bring down a persistent identifier infrastructure, but it was also relatively easy to fix. Inevitably, there was a little snark and some pointed barbs directed at us during the outage, but we were truly overwhelmed by the support and constructive criticism we received as well. We have also been left with a clear message that, in order for this good-will to continue, we need to follow-up with a public, detailed and candid analysis of our infrastructure and its dependencies. Consider this to be the first section of a multi-part report.

@kevingashley tweets asking for followup analysis

@WilliamKilbride tweets asking for followup and lessons learned

Image Credits

Turtle image CC-BY “Unrecognised MJ” from the Noun Project

Problems with dx.doi.org on January 20th 2015- what we know.

Geoffrey Bilder — Wed, 21 Jan 2015 00:00:00 +0000

Hell’s teeth.

So today (January 20th, 2015) the DOI HTTP resolver at dx.doi.org started to fail intermittently around the world. The doi.org domain is managed by CNRI on behalf of the International DOI Foundation. This means that the problem affected all DOI registration agencies including Crossref, DataCite, mEDRA etc. This also means that more popularly known end-user services like FigShare and Zenodo were affected. The problem has been fixed, but the fix will take some time to propagate throughout the DNS system. You can monitor the progress here:

https://www.whatsmydns.net/#A/doi.org

Now for the embarrassing stuff…

At first lots of people were speculating that the problem had to do with somebody forgetting to renew the dx.doi.org domain name. Our information from CNRI was that the problem had to do with a mistaken change to a DNS record and that the domain name wasn’t the issue. We corrected people who were reporting that domain name renewal as the cause, but eventually we learned that it was actually true. We have had it confirmed that the problem originated with CNRI manually renewing the domain name at the last minute. Ugh. CNRI will issue a statement soon. We’ll link to it as soon as they do. UPDATE (Jan 21st): CNRI has sent Crossref a statement. They do not have it on their site yet, so we have can included it below.

In the mean time, if you are having trouble resolving DOIs, a neat trick to know is that you can do so using the Handle system directly. For example:

http://hdl.handle.net/10.5555/12345678

Crossref will, of course, also analyse what occurred, and issue a public report as well. Obviously, this report will include an analysis of how the outage effected DOI referrals to our members.

The amazingly cool thing is that everybody online has been very supportive and has helped us to diagnose the problem. Some have even said that the event underscores a point we often make about so-called “persistent-identifiers”- which is that they are not magic technology; the “persistence” is the result of a social contract. We like to say that Crossref DOIs are as persistent as Crossref staff. Well, to that phrase we have to add “and IDF staff” and “CNRI staff” and “ICANN staff”. It is turtles all the way down.

We don’t want to dismiss this event as an inevitable consequence of interdependent systems.And we don’t want to pass the buck. We need to learn something practical from this. How can we guard against this type of problem in the future? Again, people following this issue on Twitter have already been helping with suggestions and ideas. Can we crowd-source the monitoring of persistent identifier SLAs? Could we leverage Wikipedia, Wikidata or something similar to monitor critical identifiers and other infrastructure like purls, DOIs, handles, PMIDs, perma.cc, etc? Should we be looking at designating special exceptions to the normal rules governing DNS names? Do we need to distribute the risk more? Or is it enough cough to simply ensure that somebody, somewhere in the dependency chain had enabled DNS protection and auto-renewal for critical infrastructure DNS names?

Truly, we are humbled. For all the redundancy built into our systems (multiple servers, multiple hosting sites, Raid drives, redundant power), we were undone by a simple administrative task. Crossref, IDF and CNRI- we all feel a bit crap. But we’ll get back. We’ll fix things. And we’ll let you know how we do it.

We will update this space as we know more. We will also keep people updated on twitter on @CrossrefNews. And we will report back in detail as soon as we can.

CNRI Statement

"The doi.org domain name was inadvertently allowed to expire for a brief period this morning (Jan 20). It was reinstated shortly after 9am this morning as soon as the relevant CNRI employee learned of it. A reminder email sent earlier this month to renew the registration was apparently missed. We sincerely apologize for any difficulties this may have caused. The domain name has since been placed on automatic renewal, which should prevent any repeat of this event."

Yer Basic One-Liner

Tony Hammond — Tue, 14 Oct 2008 00:00:00 +0000

Here’s your basic one-line handle client (all of it) for the browser:

OpenHandle.Util().getHandleData("10.1038/nature05826", function(data) { alert(OpenHandle.Util().helloWorld(data)); });

Can’t see how to make that much shorter (bar tossing spaces). But here’s one attempt (shorter though now it’s not strictly a one-liner):

var u = OpenHandle.Util();
u.getHandleData("10.1038/nature05826", function(_) { alert(u.helloWorld(_)); });

Here I’ve used two utility convenience methods from the OpenHandle client library:

OpenHandle.Util().getHandleData(handle, callback, [server])
OpenHandle.Util().helloWorld(JSON)

You will though need to include a couple of libraries: openhandle.js and jquery.js. (Note that the getHandleData() method supplied in the openhandle.js library uses jQuery. Feel free to overwrite that.) A complete working document can thus be implemented as:

<html>
<head>
<script type="text/javascript" src="http://jqueryjs.googlecode.com/files/jquery-1.2.6.js"></script>
<script type="text/javascript" src="http://openhandle.googlecode.com/files/openhandle-0.2.3.js"></script>
<script type="text/javascript">
jQuery().ready(function() { /* action when body content is loaded */
var u = OpenHandle.Util(); u.getHandleData("10.1038/nature05826", function(_) { alert(u.helloWorld(_)); });
});
</script>
</head>
<body>
Boo!
</body>
</html>

Let me know if this doesn’t work for you. I’ve tried to test this and seems to function OK but sure as the sun rises I ain’t no JS ninja.

Of course, we normally want to do more than just dump the values. So, given that it’s pretty straightforward to grab and to manipulate a handle’s data values over the Web, how can we put this into practice?

Let’s consider a couple of Crossref use cases.

(Disclaimer: These examples are not intended as being in any way a replacement for the existing Crossref services but merely show how those services could be implemented on the client side. These illustrations will be useful for new bespoke services accessing other data elements that may be registered with the DOI.)

Single Resolution

Here is how one could implement the regular URL redirect service from the client:

var handle = "10.1038/nature05826";
var callback = function(json) {
 var hv = new OpenHandle.Handle(json).getValuesByType(‘URL')[0];
 var url = new OpenHandle.HandleValue(hv).getData();
 // alert("Redirecting to " + url);
 window.location = url;
};
OpenHandle.Util().getHandleData(handle, callback);

The getValuesByType(‘URL')[0] call returns the first handle value of type ‘URL’. The next line just parses this value as a handle value object and gets the data field, i.e. the URL itself.

Note here that this client can show the URL that the user will be redirected to. With normal DOI resolution the resolution takes place on the proxy server (dx.doi.org) and the URL is not available to the user - until they are so redirected. In fact, the user may never get to see the URL stored in the handle value if this is the head of a redirect chain.

To recap, Crossref DOIs are not resolved by the user to URLs - rather, they invoke a service on the server which returns a content page.

Multiple Resolution

Let’s now take a look at a case of Crossref multiple resolution. This code uses the getValues() method to return all values:

var handle = "10.1130/B25510.1";
var callback = function(json) {
 var s = "";
 var hv = (new OpenHandle.Handle(json)).getValues();
 for (var i = 0; i < hv.length; i++) {
 var v = new OpenHandle.HandleValue(hv[i]);
 s += v.getType() + ": " + v.getData();
 }
 alert(s);
};
OpenHandle.Util().getHandleData(handle, callback);

which yields

700050: 200508231619480000
HS_ADMIN: [object Object]
URL.0: http://www.gsajournals.org/gsaonline/?request=get-abstract&doi=10%2E1130%2FB25510%2E1
URL.1: http://bulletin.geoscienceworld.org/cgi/doi/10.1130/B25510.1
CR-LR: <MR><LI label="GeoScienceWorld" resource="URL.1" /><LI label="Geological Society of America" resource="URL.0" />

Oops! Too much information. This includes types such as ‘700050’ and ‘HS_ADMIN’ which are used by the Crossref application, and not intended for the end user. Maybe we should just limit it to the URL types with getValuesByType('URL'):

getValuesByType(‘URL'):

var handle = "10.1130/B25510.1";
var callback = function(json) {
 var s = "";
 var hv = (new OpenHandle.Handle(json)).getValuesByType(‘URL');
 for (var i = 0; i < hv.length; i++) {
 var v = new OpenHandle.HandleValue(hv[i]);
 s += v.getType() + ": " + v.getData();
 }
 alert(s);
};
OpenHandle.Util().getHandleData(handle, callback);

which yields

URL.0: http://www.gsajournals.org/gsaonline/?request=get-abstract&doi=10%2E1130%2FB25510%2E1
URL.1: http://bulletin.geoscienceworld.org/cgi/doi/10.1130/B25510.1

_(By the way, the previous example shows the unregulated state of handle types. We have everything but the kitchen sink in this one example:

simple types, both well-known (‘URL’) and opaque (‘700050’)
- compound, or namespaced, types with various hierarchy delimiters: dot (‘URL.0’, ‘URL.1’), underscore (‘HS_ADMIN’), and hyphen (‘CR-LR’)
Well, they’re all in there now so we gotta deal with that, but generally one would probably have preferred well-known types and where namespaces are used the usual dot notation as this is a) familiar to programmers, and b) supported by the handle client library code. The underscore is used in the handle RFCs for system types so that can be viewed as a sort of inline namespacing. Seems to be no obvious excuse for hyphens though.)

Back to the example we can see that the first URL goes to a Crossref service which we can dispense with since this example is to be run client side. That leaves us with the two actual URL targets. But how to differentiate those for a user choice? That’s where that other type ‘CR-LR’ comes in which provides an XML fragment that relates label to type. There are obviously many ways to support resource labelling - this is just the method used by Crossref.

Let’s parse out the XML fragment for labels and resources and save those in an object keyed on resource:

var labels = {};
var hv_ = (new OpenHandle.Handle(json)).getValuesByType(‘CR-LR')[0];
var v = new OpenHandle.HandleValue(hv_);
var xml = v.getData();
var li = xml.match(/<li [^\>]* \/>/ig);
for (var i = 0; i < li.length; i++) {
 var a = li[i].match(/label=\"([^\"]+)\"
resource=\"([^\"]+)\"/i);
 labels[a[2]] = a[1];
}

Now we’ll also need to build a similar object for the URLs:

var urls = {};
var hv = (new OpenHandle.Handle(json)).getValuesByType(‘URL');
for (var i = 0; i < hv.length; i++) {
 var v = new OpenHandle.HandleValue(hv[i]);
 urls[v.getType()] = v.getData();
}

And now with both these objects we can build a set of labelled links as:

var s = "";
for (item in labels) {
 s += "<a href=\"" + urls[item] + "\">" + labels[item] + "</a>";
}
alert(s);

to yield

<a href="http://bulletin.geoscienceworld.org/cgi/doi/10.1130/B25510.1">GeoScienceWorld</a>
<a href="http://www.gsajournals.org/gsaonline/?request=get-abstract&doi=10%2E1130%2FB25510%2E1"gt;Geological Society of America</a>

How to build a page with those labelled links is now a simple exercise. (The actual Crossref service for doi:10.1130/B25510.1 returns a page with labelled links, logos, and metadata pulled from the Crossref database.)

Next Steps

The aim of this work has been to show that getting access to handle data values and manipulating those values in the browser can be fairly straightforward. How additional values get to be added to DOIs (or other handles) and what those values refer to is another matter, but services to access such values do not need to be centralized. User-generated services are also a possibility.

OpenHandle JavaScript API

Tony Hammond — Wed, 08 Oct 2008 00:00:00 +0000

(Click figure for PDF.)

I just posted updated versions of the OpenHandle JavaScript Client Library (v0.2.2) and Utilities (v0.2.2) to the project site. Mainly this post is just by way of saying that there’s now a “cheat sheet” for the API (see figure above, click for PDF) which will give some idea of scope. The JavaScript API attempts to reflect the Java Client Library API for Handle data structures, and has in excess of 100 methods. A change log is available.

The new API supports:

Single namespace
- Introspection
  - Unit testing, see here
  Why is this of interest to Crossref? Well, if DOIs are ever to begin take advantage of their innate Multiple Resolution capabiities there needs to be nimbler means of accessing the data items stored with a DOI. A JavaScript API would allow the data to be manipulated in the browser down by the user and so enable bespoke services. That, at least, is the idea.

Handle Clients #1, #2, #3

Tony Hammond — Wed, 01 Oct 2008 00:00:00 +0000

Three alternate clients for viewing a Handle (or DOI): #1 (sky - text), #2 (black - tuples), #3 (white - cards) - the image above is clickable. When Handle clients become JavaScript-able, one really can have it one’s own way. (The JavaScript library is here, the demo service interface here - the code for setting up a new service interface can be got from the OpenHandle project.)

Noted: As of February 2023, most of the links in this blog are not longer available.

The Last Mile

Tony Hammond — Wed, 01 Oct 2008 00:00:00 +0000

The figure above (click to enlarge) is probably self-explanatory but a few words may be in order.

With no end-to-end delivery of data from the Handle System to the user’s application (browser or reader), getting data out of the Handle System has traditionally meant using the Web (ie. HTTP) as a courier - in effect, this is the “last mile” for Handle data. Typically an upstream (Handle) client provides services to the user. The most well known of these services is the URL redirect service which underpins the Crossref reference linking service. Another hosted service is the web form which displays data stored in the Handle records in a simple HTML table for user browsing. See panel a) in the figure above.

By contrast, the OpenHandle proposal aims to move data in the Handle record in structured form (JSON or XML) over the Web for downstream processing - either in the user’s browser or on the desktop. See panel b). Advantages are that the Handle data and data structures are moved closer to the user and the services provided are capable of being better targeted and made more relevant. Data mobility as a whole is much improved. The data are accessible using standard Web description and scripting languages. One might almost say (to paraphrase the well-known Java slogan “write once, run anywhere“) that this is a case of “read once, write anywhere”.

Look Ma, No Plugins!

Tony Hammond — Mon, 22 Sep 2008 00:00:00 +0000

var f = function (OpenHandleJson) { var h = new OpenHandle(OpenHandleJson); var hv = h.getHandleValues(); for (var i = 0; i < hv.length; i++) { var v = new HandleValue(hv[i]); if (v.hasType(‘URL’)) { print(v.getData()); } else if (v.hasType(‘HS_ADMIN’)) { var a = new AdminRecord(v.getData()); print(a.getAdminPermissionString()) } } }

"And that, gentlemen, is how we do that." - Apollo 13

Following on from my earlier Client Handle Demo post, this entry is just to mention the availability of a port of (part of) the Handle client library (in Java) to JavaScript: openhandle-0.1.1.js which is being maintained on the OpenHandle site. The JavaScript module contains methods for three classes: OpenHandle, HandleValue and AdminRecord.

What does all that mean? It means that Handles and their constituent values and value fields can be accessed directly within **any Web browser (using an OpenHandle service) which allows a dynamic Handle client to be generated and presented within a user context. No plugins required. The port mirrors the class methods in the standard Java client library for Handle.

As a demo of this JavaScript module in action, see this Inspector app for a card index view of Handle (and by implication DOI) records.

Client Handle Demo

Tony Hammond — Tue, 01 Jul 2008 00:00:00 +0000

This test form shows handle value data being processed by JavaScript in the browser using an OpenHandle service. This is different from the handle proxy server which processes the handle data on the server - the data here is processed by the client.

Enter a handle and the standard OpenHandle “Hello World” document is printed. Other processing could equally be applied to the handle values. (Note that the form may not work in web-based feed readers.)

Dark Side of the DOI

Tony Hammond — Thu, 29 May 2008 00:00:00 +0000

(Click to enlarge.)

For infotainment only (and because it’s a pretty printing). Glimpse into the dark world of DOI. Here, the handle contents for doi:10.1038/nature06930 exposed as a standard OpenHandle ‘Hello World’ document. Browser image courtesy of Processing.js and Firefox 3 RC1.

OpenHandle: Languages Support

Tony Hammond — Mon, 21 Apr 2008 00:00:00 +0000

Following up the earlier post on OpenHandle, there are now a number of language examples which have been contributed to the project. The diagram below shows the OpenHandle service in schematic with various languages support. Briefly, OpenHandle aims to provide a web services interface to the Handle System to simplify access to the data stored for a given Handle.

(Note that the diagram is an HTML imagemap and all elements are “clickable”.)

Note: this diagram is no longer available online as of 2023. We show the code here for reference.

<map name="GraffleExport">
<area shape=poly coords="302,133,273,117,244,133,266,149,261,157,274,150,302,133" href="http://code.google.com/p/openhandle/wiki/OpenHandleCodeLisp"> <area shape=poly coords="359,93,330,77,302,93,324,109,318,117,332,110,359,93" href="http://code.google.com/p/openhandle/wiki/OpenHandleCodeFSharp"> <area shape=poly coords="186,93,157,77,129,93,151,109,145,117,159,110,186,93" href="http://code.google.com/p/openhandle/wiki/OpenHandleCodeAppleScript"> <area shape=poly coords="244,93,215,77,186,93,208,109,203,117,217,110,244,93" href="http://code.google.com/p/openhandle/wiki/OpenHandleCodeCSharp"> <area shape=poly coords="244,174,215,157,186,174,208,189,203,197,217,190,244,174" href="http://code.google.com/p/openhandle/wiki/OpenHandleCodePython"> <area shape=poly coords="244,133,215,117,186,133,208,149,203,157,217,150,244,133" href="http://code.google.com/p/openhandle/wiki/OpenHandleCodeJavaScript"> <area shape=poly coords="186,174,157,157,129,174,151,189,145,197,159,190,186,174" href="http://code.google.com/p/openhandle/wiki/OpenHandleCodePhp"> <area shape=poly coords="302,93,273,77,244,93,266,109,261,117,274,110,302,93" href="http://code.google.com/p/openhandle/wiki/OpenHandleCodeErlang"> <area shape=poly coords="359,133,330,117,302,133,324,149,318,157,332,150,359,133" href="http://code.google.com/p/openhandle/wiki/OpenHandleCodePerl"> <area shape=poly coords="302,174,273,157,244,174,266,189,261,197,274,190,302,174" href="http://code.google.com/p/openhandle/wiki/OpenHandleCodeRuby"> <area shape=poly coords="359,174,330,157,302,174,324,189,318,197,332,190,359,174" href="http://code.google.com/p/openhandle/wiki/OpenHandleCodeSmalltalk"> <area shape=poly coords="186,133,157,117,129,133,151,149,145,157,159,150,186,133" href="http://code.google.com/p/openhandle/wiki/OpenHandleCodeJava"> <area shape=poly coords="255,237,255,260,266,260,244,272,222,260,233,260,233,237,222,237,244,225,266,237,255,237" href="http://www.ietf.org/rfc/rfc2616.txt"> <area shape=poly coords="174,527,174,495,196,491,217,495,217,527,196,531,174,527" href="http://hdl.handle.net/"> <area shape=poly coords="270,527,270,495,292,491,314,495,314,527,292,531,270,527" href="http://hdl.handle.net/"> <area shape=poly coords="152,268,210,268,210,300,152,304,152,268" href="http://nascent.nature.com.pluma.sjfc.edu/openhandle/handle?id=10100/nature&#038;mimetype=text/plain&#038;format=rdf"> <area shape=poly coords="201,307,258,307,258,339,201,343,201,307" href="http://nascent.nature.com.pluma.sjfc.edu/openhandle/handle?id=10100/nature&#038;mimetype=text/plain&#038;format=n3"> <area shape=poly coords="267,297,325,297,325,329,267,333,267,297" href="http://nascent.nature.com.pluma.sjfc.edu/openhandle/handle?id=10100/nature&#038;mimetype=text/plain&#038;format=json"> <area shape=poly coords="255,426,255,450,266,450,244,461,222,450,233,450,233,426,222,426,244,414,266,426,255,426" href="http://www.ietf.org/rfc/rfc3651.txt"> <area shape=poly coords="262,355,262,388,226,388,226,355,262,355" href="http://nascent.nature.com.pluma.sjfc.edu/openhandle/handle?id=10100/nature&#038;mimetype=text/plain&#038;format=rdf"> <area shape=poly coords="277,223,292,208,320,208,344,220,330,235,301,235,277,223" href="http://nascent.nature.com.pluma.sjfc.edu/openhandle/handle?id=10.1000/1&#038;mimetype=text/plain&#038;format=json"> <area shape=poly coords="148,244,162,229,191,229,215,241,201,256,172,256,148,244" href="http://nascent.nature.com.pluma.sjfc.edu/openhandle/handle?id=10100/nature&#038;mimetype=text/plain&#038;format=json"> <area shape=poly coords="222,507,222,475,244,471,266,475,266,507,244,511,222,507" href="http://hdl.handle.net/"> <area shape=poly coords="49,215,89,102,191,62,305,79,401,143,393,282,315,350,198,363,105,317,49,215,120,481,140,501,178,501,199,474,186,442,152,436,122,447,120,481,49,215,57,569,79,571,89,547,71,534,53,548,57,569,49,215,57,569" href="http://code.google.com/p/openhandle/">
</map>

OpenHandle: Google Code Project

Tony Hammond — Fri, 07 Mar 2008 00:00:00 +0000

Just announced on the handle-info and semantic-web mailing lists is the OpenHandle project on Google Code. This may be of some interest to the DOI community as it allows the handle record underpinning the DOI to be exposed in various common text-based serializations to make the data stored within the records more accessible to Web applications. Initial serializations include RDF/XML, RDF/N3, and JSON.

We’d be very interested in receiving feedback on this project - either on this blog or over on the project wiki.