Standards on Crossref

Announcing changes to REST API rate limits

Martyn Rittman — Wed, 05 Nov 2025 00:00:00 +0000

Our REST API makes all of the metadata we hold publicly available. It receives the majority of our API traffic, with around 1 billion hits per month. It’s one of the key ways that we fulfil our mission to make research objects easy to find, cite, link, assess, and reuse. From 1 December 2025, we will be revising the rate limits for the public and polite pools of the REST API to ensure that we can maintain a stable and reliable system, and that metadata is freely available to everyone.

We haven’t changed the rate limits since the REST API was launched in 2013. In the past five years, the number of requests to the REST API has tripled and the number of metadata records has increased by a third, from 120 million to around 180 million. This means an increase in the resources needed to run it, and we’ve seen periods of instability where we haven’t been able to keep the API available for all users. We have decided that it is the right time to revisit rate limits to check that they’re in line with what our technology can provide and what our community needs. As a result, we will apply the following for the public and polite pools:

Public pool:

Request type	Rate limit	Concurrency limit
Single record	5	1
List of records (queries, filters, etc.)	1	1

Polite pool:

Request type	Rate limit	Concurrency limit
Single DOI record	10	3
List of records (queries, filters, etc.)	3	3

The rate limit is the number of total requests that can be made per second. The concurrency limit is how many requests can be running at the same time. This means that for longer-running requests you may need to wait for previous requests to finish before you can make a new one.

Here are some examples of single records requests:

The second case here will be directed to the polite pool because an email is included using the ‘mailto’ parameter. And here are examples of requests that return lists of records:

The second and third examples here will use the polite pool.

Our guiding principle in making these changes is to keep all of the metadata available to everyone, all of the time. These changes to rate limits won’t restrict current users from accessing the metadata they want to retrieve, but it will make it easier for us to maintain the system now and in the future.

Which use cases do we support?

Our metadata has a broad range of applications. If you’re someone who uses the REST API, we’re glad that you are part of our community! Our mission includes making it easier to find, reuse, and assess scholarly research outputs. By using metadata, you’re helping us to fulfil that goal.

The main uses of the REST API fit into several categories. The new rate limits will continue to support these, among many others:

I have some metadata, what is the DOI?
I have a DOI, what is its metadata?
I want all of the metadata, just give me everything.
Research on a specific topic or subset of metadata, often refreshing the results every few weeks or months.

Rate limits can encourage responsible usage. The majority of API users make requests at a low rate and will not need to make any changes, however a few send spikes of large numbers of requests in a short space of time, sometimes making it difficult for others to access the service. These can be smoothed out by lower rate limits. Complex requests that search across large numbers of items put more pressure on our systems than requests for a single content item, so we have decided to set different rate limits for different types of request.

Who will be affected?

We estimate that the changes might affect around 40 users per week across the public and polite pools, and this is only for some of their requests. In all of the cases we’ve seen, the rate of requests could be slowed down and users would still be able to get the same results. In other words, the aim of these changes is to make the load on the API more predictable, not to reduce the total number of requests or amount of metadata transferred. No changes are being made to the Metadata Plus service or other APIs, such as the XML API and OAI-PMH endpoint.

Do I need to change how I use the API?

If you’re reading this, thank you! It’s clear that you want to be a considerate user of our services. Almost all users can continue to use the REST API in exactly the same way, you won’t need to change anything. Here is some general advice that will help you make the most of the service and ensure that you won’t encounter issues.

Use a mailto parameter. This gives you access to the polite pool meaning higher rate limits and meaning we can get in touch with you if needed. We’ll only use your address to contact you about your API requests.
Check the HTTP response status for your requests. This is always good practice and can help you identify malformed requests and where you reach rate limits.
Cache results to avoid repeatedly making the same requests. Most records don’t change on a regular basis. How often you update the cache will depend on what you are interested in, but most metadata fields rarely change.
If you are making a very high volume of requests or have very complex analysis to carry out, consider downloading the public data file which is made available once a year and contains all of our metadata. You can update it with recent additions using the REST API.
If you are relying on our metadata in a production service, Metadata Plus can provide more stability, support, and access to monthly snapshots of our entire database.

We have more tips and tricks for the REST API in our documentation. If you have questions, please join the conversation on our Community Forum.

Can you help us to launch Distributed Usage Logging?

Kirsty Meddings — Mon, 02 Mar 2020 00:00:00 +0000

Update: Deadline extended to 23:59 (UTC) 13th March 2020.

Distributed Usage Logging (DUL) allows publishers to capture traditional usage activity related to their content that happens on sites other than their own so they can provide reports of “total usage”, for example to subscribing institutions, regardless of where that usage happens.

We are looking for a consultant to take the lead with DUL outreach, promoting the service and its benefits in order to solicit participation from publishers (receivers) and content-hosting platforms/scholarly collaboration networks (senders).

Crossref provides the infrastructure for DUL. The call for participation is being led by COUNTER and the selected consultant will be representing COUNTER, with additional support from Crossref

If you are interested in this opportunity, please download the request for information (RFI).

The RFI response deadline is 23:59 (UTC) 13 March 2020.

Redirecting redirection

Geoffrey Bilder — Tue, 24 Apr 2018 00:00:00 +0000

Crossref has decided to change the HTTP redirect code used by our DOIs from 303 back to the more commonly used 302. Our implementation of 303 redirects back in 2010 was based on recommended best practice for supporting linked data identifiers. Unfortunately, very few other parties have adopted this practice.

What’s more, because using a 303 redirect is still unusual, it tends to throw SEO tools into a tizzy- and we spend a lot of time fielding SEO questions from our members about our use of 303s.

TL;DR

At this point, we need to emphasise that we have never seen our use of 303s actually affect page rankings. But at the same time, use of 303 redirects has not had wider uptake. Maintaining this quixotic behaviour just isn’t worth the effort. We hope that, in the future, we can use other techniques (e.g. signposting & cite-as) to achieve some of the things that 303 was supposed to do.

Note that these changes will not affect users or machines using DOIs. The change should be entirely transparent.

Below we provide some background to our decision and after that we provide some detailed technical notes from Jonathan Rees and Henry Thompson who have been very kind in helping to provide Crossref technical guidance on how we can help DOIs best support linked open data and adhere to HTTP best practice.

Background

Back in 2010, Crossref, DataCite (and later, several other RAs) responded to concerns that DOIs were not “linked-data friendly.” There were three problems with DOIs at that time:

It was not clear that DOIs could be used and expressed as HTTP URIs.
There was no standard way to ask a DOI to return a machine-readable representation of the data.
It wasn’t always clear if the DOI resolved to “the thing” (e.g. an article) or “something about the thing” (e.g. a landing page).

On the advice of several people in the linked data community, we proposed some options for fixing this. And we finally settled on:

Recommending that Crossref DOIs be expressed and displayed as HTTP (now HTTPS) URIs. This made it clear that DOIs could be used with HTTP applications.
Enabling DOI registration agencies to support content negotiation. This allowed RAs to support providing machine-readable representations of the data associated with a DOI.
Changing the underlying redirect code from the normal 302 to 303. This was designed to clarify what, at the time, was true- that most DOIs resolved to a landing page, not the article itself.

By any practical measure, machine use of DOIs has exploded since we made these decisions back in 2010. Crossref’s APIs and content negotiation handle over 800 million requests for machine readable data a month. Our sibling organisation, DataCite, has also seen a huge growth in machine use of DOIs. Many applications, from bibliographic management tools, to authoring systems and CRIS systems, make use of machine actionable DOIs all the time. So clearly our work to promote DOIs as machine actionable identifiers is working, but we are certain that our current use of 303 redirects has nothing to do with this growth.

First of all, as we said, very few parties have actually subscribed to the notion of using 303s to help distinguish “the thing” from “something about the thing”.

Secondly, even if they did try to rely on 303s to make this distinction, they would quickly get confused because the DOI is so often just the first in a chain of redirects which do not implement the same semantic distinction. At this point we should be clear - Crossref thinks these kinds of long redirect chains are a bad idea for two main reasons:

They slow down resolution.
They increase the number of potential failure points between the DOI and the item it resolves to.

But we also cannot legislate them away. They exist. And in the real world you will find plenty of DOIs that do a 303 redirect to a system that, in turn, does a 302 redirect to a system that does a 301 redirect and…eventually ends up someplace returning a 200. You get the picture. How on earth is a machine supposed to interpret a 303->302->301->302 redirect chain?

Furthermore - nowadays, after following this chain of redirects, you will often find yourself on a “page” that is both a landing page and the article itself. Dynamic, one-page applications can simply morph the one into the other without the use of additional HTTP requests.

In other words, using 303s is not helping machines interpret what the DOI is pointing at. And yet, people seem to be making good use of machine actionable DOIs and they are not complaining much about it.

Personally, I’d might have just been happy to switch back to using 302s simply so that I could cut down on my conversations with SEO hacks. But that wouldn’t be a principled approach. In 2010 we spent a lot of time considering the initial switch to 303s- we needed to consult with the LOD community on a potential switch back to 302s. At the January 2018 PIDapalooza I had a chance to talk to Henry Thomson about the 302/303 dilemma we faced, and he along with Jonathan Rees very generously provided the following feedback.

Best practices for HTTP redirection by persistent identifier resolvers: 302 vs. 303

Jonathan Rees (MIT CSAIL, https://orcid.org/0000-0001-7694-8250)
Henry Thompson (University of Edinburgh, School of Informatics, https://orcid.org/0000-0001-5490-1347)

If one goes to the trouble to organize an identifier system, then the desire that such a system should last as long as possible leads one to aspirationally say it’s a persistent identifier (PID) system. The unwillingness of the major browser suppliers to implement new URI schemes for PIDs initially hindered their use on the Web and this in turn inhibited widespread adoption. More recently a number of PID approaches have enjoyed very rapid growth as a result of a compromise: these PIDs participate in the World Wide Web by defining simple conversion rules mapping identifiers to actionable (‘http:’ and/or ‘https:’) forms and providing resolution servers that redirect requests for such forms to the appropriate destination.This approach has been widely adopted and is very successful, because it is so useful. An identifier’s actionable form leads, via the HTTP protocol and one or more redirections, to a web page that bears on the ground identity of the associated entity – or perhaps even directly to the entity itself, if the system is one for document entities that are naturally provided as web pages. The nature of the retrieved web page varies from one system to the next.

A confusion arose, however, over claims in various technical specifications (URIs, HTTP, Web Architecture) that the normal case is for the protocol to yield a “representation” of the “resource” “identified” by the URI. None of these terms is adequately defined by the specifications, and initially the language was not taken as normative. Those deploying identifier systems took the HTTP “resource” to be the entity associated with an identifier, and understood the “resource” as being “identified” by the URI, but it was never clear what was, or wasn’t, a “representation” of a given entity/resource: a description of the resource, the resource itself, a version of the resource, instructions on how to find the resource, etc. Sixteen years ago, in an attempt to clarify the intent of this part of the theory of URIs, and to allow applications to usefully and uniformly exploit the idea that an HTTP 200 response must deliver a “representation” of the “resource”, Tim Berners-Lee asked the W3C Technical Architecture Group to consider what came to be known as the httpRange-14 issue. It’s now 13 years after the TAG gave advice which almost no one was happy with, and 5 years after work on issue httpRedirections-57 (which superseded httpRange-14) ground to a halt. There’s still no consensus on whether it’s OK to return landing pages with a 200 status in response to requests for pictures or publications, but the Web seems to be working nonetheless, and no one seems to be bothered much anymore.

The provision of HTTP-based resolution services has stimulated widespread support for the use of identifier systems with Web resolution, particularly in the scholarly journal publication context. Those setting up HTTP resolvers responsible for identifier systems must decide which HTTP response code should be used. The TAG’s advice sows doubt on the use of the 200 response code when the response would have been a landing page, and many resolvers avoid 200 regardless and use redirection for administrative purposes, for example

‘https://dx-doi-org.pluma.sjfc.edu/10.1109/5.771073’ to

‘http://ieeexplore.ieee.org/document/771073/?reload=true’ for the DOI

‘10.1109/5.771073’, or ‘https://identifiers.org/uniprot/A0A022YWF9’ to

‘http://www.uniprot.org/uniprot/A0A022YWF9’ for the Uniprot identifier

‘A0A022YWF9’.

So the response should be a redirection, but what kind, 301, 302, or 303? (Or 307, which is almost the same as 302.) A 301 redirect seems to say that the URI is not persistent (since its target is deemed “more persistent”). A 302 redirect seems to say that the response could have come via a 200, and so suffers the same fate as 200. That leaves 303, as hinted at in the TAG’s advice. This idea got some traction: Ten years ago a Semantic Web interest group promoted the TAG’s advice in a published note, and seven years ago one of us wrote a blog post giving the same advice for resolvers for PIDs in publishing.

However, not only is there neither consensus nor general utility around this strict understanding of the use of the various response codes – that is, that resolution to a landing page is inconsistent with a 200 (and a posteriori therefore with a 302) – but also the range of usage patterns for redirection of HTTP requests has grown and ramified over time as the Web has grown and become more complex. It’s on the face of it unlikely that a mere three response codes can capture all the resulting complexity or cover the space of outcomes (in terms of e.g. what ends up in the browser address bar or what search engines index a page under) that a page owner might like to signal.

We find in practice that some PID redirections are ending up (usually after further publisher-local redirects) at the “identified” document, some at landing pages, and some at one or the other depending on the requesting site, for example in the case of paywalled material.

In the absence of a rethinking of the whole 3xx space, it seems to us that only the 301 vs. 302 distinct ion (roughly, 301 = permanent = please fix the link, and 302 = temporary = don’t change the link) is well understood and more or less consistently treated, whereas for 303, web servers are not very consistent and both search engine and citation crawler behaviours are at best inconsistent and at worst downright unhelpful.

So, we believe it is in both users’ and publishers’ interests for resolvers of actionable-form PIDs to use 302 redirects, not 303.

If we want to help machines better understand the resource that a DOI points at, we have to explore using more nuanced mechanisms.

Just using 302 for the first redirect doesn’t do everything necessary to effectively support the emerging PID+redirection architecture. It’s at the end of the redirect chains that we need more: a standardised way to find the PID back at the start of the chain. The ‘cite-as’ proposal does exactly this, and we hope it’s quickly approved and widely adopted. Once that happens a proposal for augmenting browser (and API) behaviour to prefer, or at least offer, the ‘cite-as’ link for bookmarking and copying will be needed.

Linking DOIs using HTTPs: the background to our new guidelines

Geoffrey Bilder — Tue, 17 Jan 2017 00:00:00 +0000

Recently we announced that we were making some new recommendations in our DOI display guidelines. One of them was to use the secure HTTPS protocol to link Crossref DOIs, instead of the insecure HTTP.

Some people asked whether the move to HTTPS might affect their ability to measure referrals (i.e. where the people who visit your site come from).

TL;DR: Yes

Yes. If you do not move your DOI links to HTTPS, Crossref, its members and the members of other DOI registration agencies (e.g. DataCite, JLC, CNKI) will find it increasingly difficult to accurately measure referrals. You should link DOIs using HTTPS.

In fact, if you do not support HTTPS on your site now, it is likely that your ability to measure referrals is already impaired. If you do not already have a plan to move your site to HTTPS, you should develop one.

If you have already transitioned your site to HTTPS, you should follow the new guidelines and link DOIs via HTTPS as soon as possible. As it stands, you are not sending any referrer information when DOIs are clicked on and followed from your site. You should also make sure that the URLs you have registered with Crossref are HTTPS URLs, otherwise you will not get referrer information on your site when they are followed.

Read on if you want some grody details. We’ll try to keep it as non-technical as possible.

Two protocols, one web

To start with your web browser supports two closely related protocols, HTTP and HTTPS.

The first, HTTP, is the protocol that the web started out with. It is an unencrypted protocol and it is also easy to intercept and modify. It is also very easy and inexpensive to implement.

The second protocol, HTTPS, is a secure version of the first protocol. It is very difficult to intercept and modify. It has historically been more complex and expensive to implement.

Here you might say - “Great, but HTTPS has been around for a long time. We’ve used it for sensitive transactions like authentication and credit card transactions. Why do we want to use DOI links with HTTPS?” Why are you suggesting that we should even consider moving our entire site to HTTPS?

The pressure to move to HTTPS

The insecure HTTP protocol has become a major vector for a lot of security issues on the web. It allows user web pages to be intercepted and modified between the server and the browser. This flaw is being abused for everything from spying, to inserting unwanted advertisements into web pages, to distributing viruses, ransomware and botnets.

As such, there has been a steady drumbeat of industry encouragement to move to the more secure HTTPS protocol for all website functions.

We are not going to argue all the points here. Instead we will mention the major constituencies that are advocating for a move to HTTPS and provide you with some pointers. We apologise that these are all so US-centric, but a lot of the web’s global direction does seem to be presaged by US adoption trends.

Google

It is probably easiest to start with Google, since its practices tend to focus the attention of those managing websites.

Back in 2014 Google announced that they would slowly move toward including the use of HTTPS as a ranking signal. In 2015 they upped the ante by announcing that they would start indexing HTTPS versions of pages by default. It looks like in early 2017 they will really start to take the gloves off as they modify their Chrome browser to flag sites that do not use HTTPS as being insecure.

Every top website, evah

It looks like Google's plan is working too. Their 2016 transparency report shows that most top websites have already transitioned to HTTPS and that this translates to approximately 25% of all web traffic worldwide taking place using HTTPS. Indeed, over 50% of all web pages viewed by desktop users are delivered via HTTPS.

Government agencies

The USA’s Whitehouse issued [a directive instructing all Federal websites to adopt HTTPS]. As of December 2016 64% of federal websites have made the transition.

Libraries

Much of the pressure to move to HTTPS is coming from the library community who have a historical tradition of protecting patron privacy and resisting efforts to censor content. The third principle of the American Library Association's code of ethics reads:

We protect each library user’s right to privacy and confidentiality with respect to information sought or received and resources consulted, borrowed, acquired or transmitted.

Recently there has been a major push by the Electronic Frontier Foundation to get libraries to adopt a number of security and privacy practices, including the use of HTTPS by all library systems as well as those used by library vendors.

What are Crossref members doing about HTTPS?

How big an issue is this? How many of our members have moved to HTTPS? How many plan to? Well, we looked at the URLs that are registered with Crossref and we tested them with both protocols. Eventually we will write a blog post detailing our findings - but the highlights are:

Slightly fewer than half of the member domains tested only support HTTP.
Slightly fewer than half of the member domains tested support both HTTP and HTTPS.
About 370 of the member domains tested only support HTTPS.

The transition to HTTPS and the issue of DOI referrals

The HTTP referrer is a piece of information passed on by a browser that indicates the site from which the user navigated.

So, for example, if a user visiting site A clicks on a link which takes them to site B, site B will then record in its logs that a user visited them from site A. Obviously, this is important information for understanding where your web site traffic comes from.

The default rules for referrals are¹:

If you link between two sites with the same level of security, all referral information is retained.
When you follow a link from an insecure (HTTP) web site to a secure (HTTPS) site, referral data is passed on to the secure web site.
If you follow a link from a secure (HTTPS) web site to an insecure (HTTP) site, referral data is not passed on to the insecure web site.

So let's see what the situation would look like with normal links. If we had two sites, `A` & `B`, the following table maps the possible combinations of protocols that can be used to link from `A` to `B`. So, for example, row #2 reads:

A user browses site A using HTTP and clicks on a HTTPS link to publisher B who hosts their site using HTTPS.

The last column indicates if the referrer information is passed along by the browser. In the case of row #2, the answer is “yes”. The user has navigated from a less secure site to a more secure site.

User views site A using	Site A links to site B using	Browser reports referrer to site B
HTTP	HTTP	Yes
HTTP	HTTPS	Yes
HTTPS	HTTP	No
HTTPS	HTTPS	Yes

But this gets a little more complicated with DOIs. In this case publisher `A` links to publisher `B` through the DOI system. This means there are two parts to the link. The first `(A->doi.org)` results in a redirect (A->B). Again we use the last columns to indicate when referrer information is passed along to site B. Again, let’s look at row #2. It reads:

A user browses the site of member A using HTTP and clicks on a HTTP DOI link. The DOI system redirects the browser to member B using an HTTPS link registered with Crossref by member B. The middle column and the last column records whether Crossref and the publisher were able to see referrer information. The answer in both cases is “yes”. In the first case (A->DOI) because the link was from a less secure site (HTTP on A) to a more secure site (HTTPS at DOI). The second case because the link is between two sites at the same security level (HTTP).

	User views site A using	Site A links DOI using	Browser reports referrer to Crossref²	Crossref redirects to site B using³	Browser reports referrer to site B
1	HTTP	HTTP	Yes	HTTP	Yes
2	HTTP	HTTP	Yes	HTTPS	Yes
3	HTTP	HTTPS	Yes	HTTP	Yes
4	HTTP	HTTPS	Yes	HTTPS	Yes
5	HTTPS	HTTP	No	HTTP	No
6	HTTPS	HTTP	No	HTTPS	No
7	HTTPS	HTTPS	Yes	HTTP	No
8	HTTPS	HTTPS	Yes	HTTPS	Yes

So what does this mean?

Our old display guidelines recommended linking DOIs using HTTP. Rows #1, #2, #5, #6 represent the status quo.

About half of our members support HTTPS. A few support it exclusively and it seems, given the industry pressures mentioned above, those who support both protocols are likely doing so as a transition stage to HTTPS-only sites.

This means that the scenarios represented in row #5 & #6 are already happening. The referral information for any user viewing one of our member sites using HTTPS is being lost when they click on DOIs that use the HTTP protocol. Crossref doesn’t get the referral data and neither does the member whose DOI has been clicked on.

Of course this applies to non-member sites that link to DOIs as well. Wikipedia is the largest referrer of DOIs from outside the industry. In 2015 The Wikimedia Foundation made a highly publicised transition to HTTPS on all of their sites. This means that any of our members who are running HTTP sites have already lost the ability to see any referral information from Wikipedia on their own sites. However, Crossref worked closely with Wikimedia to ensure that, at the very least, Crossref was still able to record Wikimedia referral data on behalf of our members.

A solution

It is largely this work with Wikimedia that has helped us to understand just how important it is for Crossref to get ahead of the curve in helping our community to transition to HTTPS.

As long as our members are running a combination of HTTP and HTTPS sites, there is no way for our community to avoid some disruption in the flow of referral data. And we certainly would never entertain the notion of asking our members to keep using HTTP.The best we can do is recommend a practice that will help smooth the transition to HTTPS. That is what we are doing.Our new recommendation is to move to linking DOIs using HTTPS. This is represented in rows #3, #4, #7 and #8 in the table above.

This is a particularly important step for our members who have already moved to hosting their sites on HTTPS. As long as they are using HTTP DOIs on their site, they will be sending no referral traffic to Crossref, other Crossref members or other users of the DOI infrastructure. This is captured in scenarios #5 and #6.

If our linking guidelines are followed during the industry’s transition to HTTPS, then scenario #5 and #6 will eventually be replaced with scenario #7. It is still not perfect, but at least it means that, during the transition, publishers who are still running HTTP sites will be able to get some DOI referral data via Crossref. And of course, once our members have widely transitioned to HTTPS, everything will go back to normal and they will be able to see referral data on their own sites as well (i.e.they will have moved from the state represented in row #1 to state represented in row #8.)

In summary, please change your sites to use HTTPS to link DOIs. They should look like this:

https://doi-org.pluma.sjfc.edu/10.7554/eLife.20320

FAQ

Q: If I have moved my site to HTTPS, do I need to redeposit my URLs to that they use the HTTPS protocol instead?

A: Yes. If you want to be able to still collect referrer information on your site (scenario #8) as opposed to via Crossref (scenario #7).

Q: But can’t I avoid redepositing my URLs and get referrer data again if I simply redirect HTTP URLs to HTTPS on my own site?

A: No. The browser will strip referrer information if there is any HTTP step in the redirects. Even if the redirect is done on your own site.

Q: Can I avoid having to redeposit all my URLs? Can’t Crossref just update the protocol on our existing DOIs for us?

A: Contact support@crossref.org. We’ll see what we can do.

Q: What about all the old PDFs that are are there? They link to DOIs using HTTP.

A: That is true. But links followed from PDFs don’t send referrer information anyway.

Q: And what about my new PDFs? Should I start linking DOIs from them using HTTPS.

A: Probably. But not because of the DOI referrer problem. Simply because HTTPS is a more secure, private, and future-proof protocol.

Q: Don’t some countries block HTTPS?

A: Typically countries block specific sites and/or services. We do not know of any countries that have a blanket block on the HTTPS protocol.

Q: I use a link resolver that uses OpenURL + a cookie pusher to redirect my users to local resources. What do I need to do?

A: You need to change your cookie pusher script to enable the Secure attribute for cookies for HTTPS-linked DOIs.

Q: Can I use protocol-relative URLs (e.g. //doi.org/10.7554/eLife.20320)?

A: Protocol-relative URLs can be used in HTML HREFs to help ease the transition from HTTP to HTTPS, but use the full protocol in the text of the DOI link itself. So, for example, the following is fine:

https://doi-org.pluma.sjfc.edu/10.7554/eLife.20320

Q: I hear that HTTP and HTTPS versions of URI identifiers are considered to be different identifiers. Doesn’t this mean that by moving to HTTPS we are essentially doubling the number of DOI-based identifiers out there?

A: Yes. It isn’t a problem that is only being faced by DOIs. Basically all HTTP-URI based identifiers face the same issue. We will put in place appropriate same-as assertions in our metadata and HTTP headers to allow people to understand that the HTTP and HTTPS representations of the DOI point to the same thing.

On a personal note (@gbilder speaking- don’t blame @CrossrefOrg) - it breaks my brain that the official line is that the protocol difference means they are different identifiers. As a practical matter (a concept the W3C seems to be increasingly alienated from), it would be insane for anybody to follow this policy to the letter. You can probably be pretty safe swapping the protocols on DOIs and being sure you will get the same thing.

Q: I see that the Crossref site isn’t running on HTTPS. Are you just a bunch of hypocrites?

A: ~~Yes. The site will be moving to HTTPS-only very soon. Then we won’t be.~~ We do now.

References

These rules can be tweaked using meta referrer tags (https://www.w3.org/TR/referrer-policy/), but not in any way that both avoids the fundamental problems outlined here and that preserves the security/privacy characteristics that are the very reason to implement HTTPS in the first place.
To be pedantic- it actually passes referrer information to the DOI proxy (https://doi-org.pluma.sjfc.edu/), which in turn is reported to Crossref.
To continue with the pedantry- the DOI proxy does the redirect based on the URL member B has deposited with Crossref.

Taxonomies Meet-up at #FBM15

Ginny Hendricks — Fri, 25 Sep 2015 00:00:00 +0000

The Taxonomies Interest Group would like to invite Crossref members to an informal drop-in at the Frankfurt Book Fair:

4-5pm on Wednesday 14th October at the TEMIS booth H76

The group would like to discuss how different publishers use their taxonomies for content enrichment and to explore the role that the Crossref interest group can play in promoting industry collaboration and emerging standards. TEMIS have kindly offered to host the event at their booth and provide refreshments: Please come by from 4pm at Booth H76.

Graham McCann from IOP Publishing and Christian Kohl from De Gruyter will be coordinating the event. For background information on the work the group is doing, take a look at this webinar recording from March 2015.

DataCite supporting content negotiation

Geoffrey Bilder — Mon, 10 Oct 2011 00:00:00 +0000

In April In April for its DOIs. At the time I cheekily called-out DataCite to start supporting content negotiation as well.

Edward Zukowski (DataCite’s resident propellor-head) took up the challenge with gusto and, as of September 22nd DataCite has also been supporting content negotiation for its DOIs. This means that one million more DOIs are now linked-data friendly. Congratulations to Ed and the rest of the team at DataCite.

We hope this is a trend. Back in June Knowledge Exchange organized a seminar on Persistent Object Identifiers. One of the outcomes of the meeting was “Den Haag Manifesto” a document outlining five relatively simple steps that different persistent identifier systems could take in order to increase interoperability. Most of these steps involved adopting linked data principles including support for content negotiation. We look forward to hearing about other persistent identifiers adopting these principles over the next year.

Having said that, this time I will refrain from calling-out anybody specifically…

Content Negotiation for Crossref DOIs

Geoffrey Bilder — Tue, 19 Apr 2011 00:00:00 +0000

So does anybody remember the posting DOIs and Linked Data: Some Concrete Proposals?

Well, we went with option “D.”

From now on, DOIs, expressed as HTTP URIs, can be used with content-negotiation.

Let’s get straight to the point. If you have curl installed, you can start playing with content-negotiation and Crossref DOIs right away:

curl -D - -L -H   “Accept: application/rdf+xml” “http://dx.doi.org.pluma.sjfc.edu/10.1126/science.1157784”

curl -D - -L -H   “Accept: text/turtle” “http://dx.doi.org.pluma.sjfc.edu/10.1126/science.1157784”

curl -D - -L -H   “Accept: application/atom+xml” “http://dx.doi.org.pluma.sjfc.edu/10.1126/science.1157784”

Or if you are already using Crossref’s “unixref” format:

curl -D - -L -H “Accept: application/unixref+xml” “http://dx.doi.org.pluma.sjfc.edu/10.1126/science.1157784&#8221;

This will work with over 46 million Crossref DOIs as of today, but the beauty of the setup is that from now on, any DOI registration agency can enable content negotiation for their constituencies as well. DataCite- we’re looking at you 😉 .

It also means that, as registration agency members (Crossref publishers, for instance) start providing more complete and richer representations of their content, we can simply redirect content-negotiated requests directly to them.

We expect that that this development will round-out Crossref’s efforts to support standard APIs including OpenURL and OAI_PMH and we look forward to seeing DOIs increasingly used in linked data applications.

Finally, Crossref would just like to thank the IDF and CNRI for their hard work on this as well as Tony Hammond and Leigh Dodds for their valuable advice and persistent goading.

OpenSearch/SRU Integration Paper

Tony Hammond — Mon, 19 Jul 2010 00:00:00 +0000

Since I’ve already blogged about this a number of times before here, I thought I ought to include a link to a fuller writeup in this month’s D-Lib Magazine of our nature.com OpenSearch service which serves as a case study in OpenSearch and SRU integration:

doi:10.1045/july2010-hammond

Now What About XMP?

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

With PDF now passed over to ISO as keeper of the format (as blogged here on CrossTech), Kas Thomas (on CMS Watch’s TrendWatch) blogs here that Adobe should now do the right thing by XMP and look to hand that over too in order to establish it as a truly open standard. As he says:

“Let’s cut to the chase. If Adobe wants to demonstrate its commitment to openness, it should do for XMP what it has already done for PDF: Put it in the hands of a legitimate standards body. Right now it’s open in name only. “

And this:

“Adobe is pushing the XMP standard … at Adobe’s pace and in ways that benefit Adobe. (The parallels with PDF are numerous and obvious.) There are lingering technical issues waiting to be solved, however. Issues whose solutions shouldn’t have to be dependent on Adobe’s needs only.”

He’s absolutely bang on. With XMP on the threshold of finally shining through we really could do with Adobe cutting it loose. It’s time to leave home.

Word Add-in for Scholarly Authoring and Publishing

Crossref — Wed, 26 Mar 2008 00:00:00 +0000

Last week Pablo Fernicola sent me email announcing that Microsoft have finally released a beta of their Word plugin for marking-up manuscripts with the NLM DTD. I say “finally” because we’ve know this was on the way and have been pretty excited to see it. We once even hoped that MS might be able to show the plug-in at the ALPSP session on the NLM DTD, but we couldn’t quite manage it.

The plugin is targeted at production/editorial staff, but, of course, it will be interesting to see if any of this work can be pushed back to the author. I won’t hold my breath on the latter score, but it will be fun to watch.

One thing I would note is that the NLM DTD can also be used in the humanities and social sciences, so, frankly, I think they should market it more broadly.

Anyway- the plugin can be downloaded from the Microsoft site.

And Pablo has setup a blog where testers can discuss the add-in.

And there is also an entry for the project on the Microsoft Research site (an interesting place to peruse, if you have a moment).

Congatulations to Pablo and his team.

Object Reuse and Exchange

Chuck Koscher — Wed, 05 Mar 2008 00:00:00 +0000

On March 3rd the Open Archives Initiative held a roll out meeting of the first alpha release of the ORE specification (http://www.openarchives.org/ore/) . According to Herbert Van de Sompel a beta release is planned for late March / early April and a 1.0 release targeted for September. The presentations focused on the aggregation concepts behind ORE and described an ATOM based implementation. ORE is the second project from the OAI but unlike its sibling PMH it is not exclusively a repository technology. ORE provides machine readable manifests for related Web resources in any context. For instance, DOI landing pages (aka splash page) are human readable resources containing links to any number of resources related to the work identified by the DOI. An ORE instance for the DOI (called a Rem or resource map) would describe the same set of resources in a machine friendly format. A standardized form of redirection understood by the DOI proxy would yield the Rem instead of normal page e.g.

http://dx.doi.org.pluma.sjfc.edu/10.5555/abcd?type=rem which could be useful for crawlers.

A second roll out meeting is planned during the Sparc-08 workshops in early April.

STIX Fonts in Beta

Tony Hammond — Tue, 06 Nov 2007 00:00:00 +0000

Well, Howard already blogged on Nascent last week about the STIX fonts (Scientific and Technical Information Exchange) being launched and now freely available in beta. And today the STM Association also have blogged this milestone mark. So, just for the record, I’m noting here on CrossTech those links for easy retrieval. As Howard says:

“I recommend all publishers download the fonts from the STIX web site at www.stixfonts.org today.”

(And for those who want to see more of Howard, he can be found in interview here on the SIIA Executive FaceTime Webcast Series. 🙂

“Spinning Around”

Tony Hammond — Fri, 23 Feb 2007 00:00:00 +0000

There’s a great exposition of FRBR (the Functional Requirements for Bibliographic Records model “work -> expression -> manifestation -> item“) in this post from The FRBR Blog on De Revolutionibus as described in The Book Nobody Read: Chasing the Revolutions of Nicolaus Copernicus by Owen Gingerich. See post for the background and here (103 KB PNG) for a map of the FRBR relationships.

(Yes, and a twinkly star in the title too. ;~)

OpenDocument 1.1 is OASIS Standard

Tony Hammond — Thu, 15 Feb 2007 00:00:00 +0000

From the OASIS Press Release:

“Boston, MA, USA; 13 February 2007 — OASIS, the international standards consortium, today announced that its members have approved version 1.1 of the Open Document Format for Office Applications (OpenDocument) as an OASIS Standard, a status that signifies the highest level of ratification.”

Microsoft to Support OpenID

Crossref — Thu, 08 Feb 2007 00:00:00 +0000

Kim Cameron, Microsoft’s Identity Czar and member of the Identity Gang, comments on Microsoft’s announcement that they will support OpenID. Another sign that federated identity schemes are gaining traction and OpenID is likely to emerge as a standard the publishers are going to want to grapple with soon.

This follows Doc Searl’s comments on the notion of “Creator Relationship Management” where he speculates that the techniques being used in federated identity schemes and the Creative Commons can be combined to create a new “silo-free” value chain amongst creators, producers and distributors.

RSC launches semantic enrichment of journal articles

rkidd — Thu, 01 Feb 2007 00:00:00 +0000

The RSC has gone live today with the results of Project Prospect, introducing semantic enrichment of journal articles across all our titles. I’m pretty sure we’re the first primary research publisher to do anything of this scope.

We’re identifying chemical compounds and providing synonyms, InChIs (IUPAC’s Chemical Identifier), downloadable CML (Chemical Markup Language), SMILES strings and 2D images for these compounds. In terms of subject area we’re marking up terms from the IUPAC Gold Book, and also Open Biomedical Ontology terms from the Gene, Cell, and Sequence Ontologies. All this stuff is currently available from an enhanced HTML view, with the additional information and links to related articles accessed via highlights in the article and popups.

The mark-up tools have been developed together with UK academics based at the Unilever Centre of Molecular Informatics and the Computing Laboratory at Cambridge University.

At launch we have about 100 articles from our 2007 publications, with the enhanced views currently free-to-air. Feel free to take a look.

An Open PDF?

Tony Hammond — Mon, 29 Jan 2007 00:00:00 +0000

Adobe announces today the following:

“SAN JOSE, Calif. — Jan. 29, 2007 — Adobe Systems Incorporated (Nasdaq:ADBE) today announced that it intends to release the full Portable Document Format (PDF) 1.7 specification to AIIM, the Enterprise Content Management Association, for the purpose of publication by the International organisation for Standardization (ISO).”

The full press release is here.

(Via Oleg Tkachenko’s Blog.)

STIX and Stones

Crossref — Thu, 05 Oct 2006 00:00:00 +0000

The STIX Fonts project funded by six major publishers to develop a comprehensive font set for STM publishing has completed its development phase and is about to move into beta testing (planned to commence in late October). Participation is open to all publishers - so now is the time to get involved to ensure your needs are met by this significant activity.