Content Negotiation for CrossRef DOIs

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/10.1126/science.1157784″ 

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

curl -D – -L -H   “Accept: application/atom+xml” “http://dx.doi.org/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/10.1126/science.1157784″ 

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.

9 thoughts on “Content Negotiation for CrossRef DOIs”

  2. Fergus Gallagher

    Is the unixref option suitable for production use. I also notice it doesn’t have a “pid”, unlike the current version.
    How about a JSONP variant that can be called from the browser?

  3. Jonathan Rochkind

    This is potentially great.
    If DataCite DID participate in this system… would the responses to DataCite-registered DOIs from content-negotiated requests to dx.doi.org return data in the same formats using the same vocabularies?
    Your CrossRef examples return atom+xml using PRISM and DC (used in particular ways — you have to know that dc:isPartOf is going to be the ISSN). The rdf+xml example seems to use DC and OWL, again used in particular ways. And the turtle example, despite being RDF, uses yet differnet vocabularies, it looks like DCterms and PRISM again, again used in particular ways.
    So if I’m writing software to use this, and I want my software to work regardless of whether the DOI came from CrossRef or DataCite…. my software not only needs to know it’s getting atom+xml or rdf+xml or turtle back, it needs to be written to know what vocabularies are going to be used inside these wrapper formats, and in particular the semantic choices of how the vocabularies are used (like using dc:isPartOf for an ISSN, again a convention not really obvious from dc:isPartOf on it’s own).
    Is there or will there be DOI documentation on vocabulary choices that can be consulted by those writing clients, and that those providing metadata (whether CrossRef or DataCite or someone else) will adhere to? Otherwise…. this is only marginally better than the previous status quo of every registration agency providing their own metadata lookup (or not) using their own custom semantics.

  4. Tom Pollard

    Thanks to Geoffrey and colleagues for this very positive development. I’m pleased to say that DataCite will be working towards the same content-negotiation solution as CrossRef.

  7. Geoffrey Bilder

    First- apologies to all above who sent in comments. Apparently, our MT comment system went berserk and flagged everything as spam. Was wondering why everything was so quiet…
    So give me a bit of time and I will try to address the various questions that have come up.

  8. Karl Ward

    @Ed Summers:
    Responses now contain a Vary header.
    @Fergus Gallagher:
    We will return JSON conversions of rdf+xml for the content type “application/rdf+json”. Not what you’re asking for, but I thought I’d mention it anyway.

Comments are closed.