Blog

(This post is just a repost of a comment to Geoff’s last entry made because it’s already rather long, because it contains one original thought - FRBR as OSI - and because, well, it didn’t really want to wait for moderation.) Hi Geoff: First off, there is no question but that Crossref was established to take on the reference linking challenge for scholarly literature. (Hell, it’s there, as you point out, in the organization name - PILA - as well as in the application name - Crossref.

Tony’s recent thread on making DOIs play nicely in a linked data world has raised an issue I’ve meant to discuss here for some time- a lot of the thread is predicated on the idea that Crossref DOIs are applied at the abstract “work” level. Indeed, that it what it currently says in our guidelines. Unfortunately, this is a case where theory, practice and documentation all diverge. When the Crossref linking system was developed it was focused primarily on facilitating persistent linking amongst journals and conference proceedings.

(Update - 2010.02.10: I just saw that I posted here on this same topic over a year ago. Oh well, I guess this is a perennial.) I am opening a new entry to pick up one point that John Erickson made in his last comment to the previous entry: “I am suggesting that one “baby step” might be to introduce (e.g.) RDFa coding standards for embedding the doi:D syntax.” Yea!

(Click image for full size graphic.) Following the JISC seminar last week on persistent identifiers (#jiscpid on Twitter) there was some discussion about DOI and its role within a Linked Data context. John Erickson has responded with a very thoughtful post DOIs, URIs and Cool Resolution, which ably summarizes how the current problem with DOI in that the way the DOI is is implemented by the handle HTTP proxy may not have kept pace with actual HTTP developments.

Was outraged (outraged, I tell you) that one of my favorite online comics, PhD, didn’t include DOIs in their recent bibliography of Christmas-related citations.. So I’ve compiled them below. We care about these things so that you don’t have to. Bet you will sleep better at night knowing this. Or perhaps not… A Christmas Reading List… with DOIs. Citation: Biggs, R, Douglas, A, Macfarlane, R, Dacie, J, Pitney, W, Merskey, C & O’Brien, J, 1952, ‘Christmas Disease’, BMJ, vol.

In order to encourage publishers and other content producers to embed metadata into their PDFs, we have released an experimental tool called “pdfmark”, This open source tool allows you to add XMP metadata to a PDF. What’s really cool, is that if you give the tool a Crossref DOI, it will lookup the metadata in Crossref and then apply said metadata to the PDF. More detail can be found on the pdfmark page on the Crossref Labs site.

Inspired by Google’s recent promotion of QR Codes, I thought it might be fun to experiment with encoding a Crossref DOI and a bit of metadata into one of the critters. I’ve put a short write-up of the experiment on the Crossref Labs site, which includes a demonstration of how you can generate a QR Code for any given Crossref DOI. Put them on postcards and send them to your friends for the holidays.

[See this link if you’re short on time: facets search client. Only tested on Firefox at this point. Caveat: At time of writing the Crossref Metadata Search was being very slow but was still functional. Previously it was just slow.] Following on from Geoff’s announcement last month of a prototype Crossref Metadata OpenSearch on labs.crossref.org, I wanted to show what typical OpenSearch responses might look like in a more mature implementation.

Following on from my recent post about our shiny new nature.com OpenSearch service we just put up a cheatsheet for users. I’m posting about this here as this may also be of interest especially to those exploring how SRU and OpenSearch intersect. The cheatsheet can be downloaded from our nature.com OpenSearch test page and is available in two forms: Cheatsheet (PDF, 65K) Cheatsheet (PNG, 141K) Naurally, all comments welcome.

We’re pleased to announce that a Crossref working group has released a set of best practice recommendations for scholarly publishers producing RSS feeds. Variations in practice amongst publisher feeds can be irritating for end-users, but they can be insurmountable for automated processes. RSS feeds are increasingly being consumed by knowledge discovery and data mining services. In these cases, variations in date formats, the practice of lumping all authors together in one <dc:creator> element, or generating invalid XML can render the RSS feed useless to the service accessing it.