Today two new content types were added to dx.doi.org resolution for Crossref DOIs. These allow anyone to retrieve DOI bibliographic metadata as formatted bibliographic entries. To perform the formatting we’re using the citation style language processor, citeproc-js which supports a shed load of citation styles and locales.
In fact, all the styles and locales found in the CSL repositories, including many common styles such as bibtex, apa, ieee, harvard, vancouver and chicago are supported.
We’ve been asked a few times if it is possible to determine whether or not a particular domain name belongs to a Crossref member. To address this we’re launching another small service that performs something like a “reverse look-up” of URLs and domain names to DOIs and Crossref member status.
The service provides an API that will attempt to reverse look-up a URL to a DOI and return the membership status (member or non-member) of the root domain of the URL.
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.
Today I’m announcing a small web API that wraps a family name database here at Crossref R&D. The database, built from Crossref’s metadata, lists all unique family names that appear as contributors to articles, books, datasets and so on that are known to Crossref. As such the database likely accounts for the majority of family names represented in the scholarly record.
The web API comes with two services: a family name detector that will pick out potential family names from chunks of text and a family name autocompletion system.
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://0-dx.doi.org.lib.rivier.edu/10.1126/science.1157784”
curl -D - -L -H “Accept: text/turtle” “http://dx.
Announcements regarding Crossref system status or changes are posted in an Announcements forum on our support portal (http://support.crossref.org). We recommend that someone from your organization monitor this forum to stay informed about Crossref system status, schema changes, or other issues affecting deposits and queries. Subscribe to this forum via RSS feed (https://0-support-crossref-org.lib.rivier.edu/hc/en-us) or select the ‘Subscribe’ option in the forum to subscribe by email.
The TWG Discussion forum replaces the TWG mailing list and can be accessed by members of the Crossref community who log in to our support portal.
While working on an internal project, we developed “pdfstamp“, a command-line tool that allows one to easily apply linked images to PDFs. We thought some in our community might find it useful and have released it on github. Some more PDF-related tools will follow soon.
Just a quick heads-up to say that we’ve had a go at incorporating InChIs and ontology terms into our PDFs with XMP. There isn’t a lot of room in an XMP packet so we’ve had to be a bit particular about what we include.
InChIs: the bigger the molecule the longer the InChI, so we’ve standardized on the fixed-length InChIKey. This doesn’t mean anything on its own, so we’ve gone the Semantic Web route of including an InChI resolver HTTP URI.
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:
(Click image for full size graphic.)
I thought I could take this opportunity to demonstrate one evolution path from traditional record-based search to a more contemporary triple-based search. The aim is to show that these two modes of search do not have to be alternative approaches but can co-exist within a single workflow.
Let me first mention a couple of terms I’m using here: ‘graphs’ and ‘properties’. I’m using ‘property’ loosely to refer to the individual RDF statement (or triple) containing a property, i.