2009 on Crossref

A Christmas Reading List… with DOIs

Geoffrey Bilder — Sun, 13 Dec 2009 00:00:00 +0000

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. 2, no. 4799, pp. 1378-1382.

Crossref DOI: http://dx.doi.org.pluma.sjfc.edu/10.1136/bmj.2.4799.1378

Title: More Than a Labor of Love: Gender Roles and Christmas Gift Shopping

Citation: Fischer, E & Arnold, S, 1990, ‘More Than a Labor of Love: Gender Roles and Christmas Gift Shopping’, Journal of Consumer Research, vol. 17, no. 3, p. 333.

Crossref DOI: http://dx.doi.org.pluma.sjfc.edu/10.1086/208561

Title: Looking at Christmas trees in the nucleolus

Citation: Scheer, U, Xia, B, Merkert, H & Weisenberger, D, 1997, ‘Looking at Christmas trees in the nucleolus’, Chromosoma, vol. 105, no. 7-8, pp. 470-480.

Crossref DOI: http://dx.doi.org.pluma.sjfc.edu/10.1007/s004120050209

Title: The Vela glitch of Christmas 1988

Citation: McCulloch, P, Hamilton, P, McConnell, D & King, E, 1990, ‘The Vela glitch of Christmas 1988’, Nature, vol. 346, no. 6287, pp. 822-824.

Crossref DOI: http://dx.doi.org.pluma.sjfc.edu/10.1038/346822a0

Title: Cardiac Mortality Is Higher Around Christmas and New Year’s Than at Any Other Time: The Holidays as a Risk Factor for Death

Citation: Phillips, D, 2004, ‘Cardiac Mortality Is Higher Around Christmas and New Year’s Than at Any Other Time: The Holidays as a Risk Factor for Death’, Circulation, vol. 110, no. 25, pp. 3781-3788.

Crossref DOI: http://dx.doi.org.pluma.sjfc.edu/10.1161/01.CIR.0000151424.02045.F7

Title: Red Crabs in Rain Forest, Christmas Island: Biotic Resistance to Invasion by an Exotic Snail

Citation: Lake, P & O’Dowd, D, 1991, ‘Red Crabs in Rain Forest, Christmas Island: Biotic Resistance to Invasion by an Exotic Snail’, Oikos, vol. 62, no. 1, p. 25.

Crossref DOI: http://dx.doi.org.pluma.sjfc.edu/10.2307/3545442

Title: The Carvedilol Hibernation Reversible Ischaemia Trial, Marker of Success (CHRISTMAS) study Methodology of a randomised, placebo controlled, multicentre study of carvedilol in hibernation and heart failure

Citation: Pennell, D, 2000, ‘The Carvedilol Hibernation Reversible Ischaemia Trial, Marker of Success (CHRISTMAS) study Methodology of a randomised, placebo controlled, multicentre study of carvedilol in hibernation and heart failure’, International Journal of Cardiology, vol. 72, no. 3, pp. 265-274.

Crossref DOI: http://dx.doi.org.pluma.sjfc.edu/10.1016/S0167-5273(99)00198-9

Add Crossref metadata to PDFs using XMP

Geoffrey Bilder — Wed, 09 Dec 2009 00:00:00 +0000

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. The usual weasels words and excuses about “experiments” apply.

QR Codes and DOIs

Geoffrey Bilder — Tue, 08 Dec 2009 00:00:00 +0000

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. Tattoo them on your pets. The possibilities are endless.

got SEARCH if you want it!

Tony Hammond — Tue, 24 Nov 2009 00:00:00 +0000

[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.

I have taken the liberty of modelling these on the response formats that we are already providing in our nature.com OpenSearch service which in turn are based on the draft syndication formats that I blogged here earlier.

I am therefore returning ATOM, JSON, JSONP and RSS responses from these four OpenSearch URL templates:

http://nurture.nature.com.pluma.sjfc.edu/cgi-bin/opensearch?db=crossref&out=atom&q={searchTerms}
- http://nurture.nature.com.pluma.sjfc.edu/cgi-bin/opensearch?db=crossref&out=json&q={searchTerms}
  - http://nurture.nature.com.pluma.sjfc.edu/cgi-bin/opensearch?db=crossref&out=jsonp&q={searchTerms}
    - http://nurture.nature.com.pluma.sjfc.edu/cgi-bin/opensearch?db=crossref&out=rss&q={searchTerms}
    as this OpenSearch description file details. Note that the URL templates include no indexing or pagination parameters as the Crossref prototype does not currently support these features.
    
    An example query (‘apple’) returning an ATOM feed from a Crossref Metadata OpenSearch would be the following:
    - http://nurture.nature.com.pluma.sjfc.edu/cgi-bin/opensearch?db=crossref&out=atom&q=apple
    And the same query returning a JSON version of that ATOM feed would look as follows:
    - http://nurture.nature.com.pluma.sjfc.edu/cgi-bin/opensearch?db=crossref&out=json&q=apple
    By the way, this is just for demonstration purposes and there are still issues to be resolved including character encoding.
    
    This interface uses the existing Crossref OpenSearch response format and parses the COinS objects embedded in that response to provide a more standard OpenSearch syndication result set format. The prototype implemenatation also has some bugs which I needed to work around. (I will forward on details of these.) And there is also a more fundamental issue of response time from the experimental search server.
    
    But still this should give some idea of what a Crossref Metadata OpenSearch service could look like.
    
    To show this all in action I’ve worked up one of my demo OpenSearch clients for nature.com OpenSearch which displays a facetted search response for a Crossref search. For good measure this includes also an OpenSearch interface for PubMed and the search client allows for simple selection between three journals databases: nature.com, Crossref and PubMed.
    
    Of course, with a reasonably uniform set of search result formats such as presented here it then becomes a simple exercise to reuse these search responses in additional search clients.
    
    As can be anticipated it would be very straightforward to carry this over into a single metasearch service which could run across these multiple databases.

A Cheatsheet for nature.com OpenSearch

Tony Hammond — Thu, 22 Oct 2009 00:00:00 +0000

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.

Recommendations on RSS Feeds for Scholarly Publishers

Geoffrey Bilder — Mon, 19 Oct 2009 00:00:00 +0000

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.

The recommendations intended to facilitate good practice in the production and provision of TOC RSS Feeds. The guidelines include general recommendations for good practice, specific recommendations on the use of RSS Modules and an example RSS TOC feed. Ultimately, we expect that industry wide adoption of these best practices will help drive more traffic to publisher web sites. Note that most of these recommendation can also be applied to non-TOC RSS feeds such as thematic feeds, automated search result feeds, etc.

Crossref Labs

Geoffrey Bilder — Tue, 13 Oct 2009 00:00:00 +0000

The other day Noel O’Boyle wrote to tell me that he had updated the Ubiquity plug-in that we had developed in order to to make it work with the latest version of Firefox. The problem was, I had *also* updated the Ubiquity plug-in, but I hadn’t really indicated to anybody how they could find updates to the plug-in. /me=embarrassed. So it seemed time to provide a home for some of the prototypes and experiments that we’ve been developing at Crossref. To that end, we have created a Crossref Labs site. Here you can find links to various tools and services that either make it easier to use Crossref services (e.g. Blog/Ubiquity plugins and OpenSearch Description files) or that serve to illustrate a concept that has been of interest to our members (InChI lookup, TOI-DOIs). Oh, yeah- and when we update these experiments, you should be able to find the updates on their respective pages. Sorry about that Noel… Finally, I will quote from the Crossref Labs home page:

“Most of the experiments linked to here are running on R&D equipment in a non-production environment. They may disappear without warning and/or perform erratically. If one of them isn’t working for some reason, come back later and try again.” Have fun.

nature.com OpenSearch: A Structured Search Service

Tony Hammond — Mon, 05 Oct 2009 00:00:00 +0000

(Click panels in figure to read related posts.)

Following up on my earlier posts here about the structured search technologies OpenSearch and SRU, I wanted to reference three recent posts on our web publishing blog Nascent which discuss our new nature.com OpenSearch service:

1. Service: Describes the new nature.com OpenSearch service which provides a structured resource discovery facility for content hosted on nature.com.
2. Clients: Points to a small gallery of demo web clients for nature.com OpenSearch which all use the text-based JSON interface.
3. Widgets: Introduces the new nature.com search desktop widgets which interface with the nature.com OpenSearch service via an RSS feed. (See also the screencast posted to YouTube.)

We hope that this new search service will prove to be useful and may also provide a model for other implementations.

Please join us for the 2009 Crossref Technical Meeting.

Anna Tolwinska — Tue, 08 Sep 2009 00:00:00 +0000

Crossref Technical Meeting*

The Charles Hotel, Cambridge, MA

Monday, November 9th, 2009

2:00 pm - 5:00 pm

Please register today!

We also encourage you to register for our 10th Anniversary Celebration Dinner, which will take place Monday, November 9th, 2009 at 6:30 pm following the Crossref Technical Meeting at the Museum of Science in Boston, MA. Transportation from the Charles Hotel to the Museum of Science will be provided. Our 2009 Annual Meeting will take place on Tuesday, November 10th at 9:00 am in the Charles Hotel in Cambridge, MA and we urge you to register soon (if you haven’t already done so)

as space is limited. You may register for both events here.

*Please note that this year’s Technical Meeting will be on Monday afternoon.

PRC Report and “iPub” revisited

Geoffrey Bilder — Mon, 07 Sep 2009 00:00:00 +0000

OK, so this has nothing to do with any Crossref projects- but there is an interesting new PRC report out by Mark Ware in which he explores how SMEs (small/medium-sized enterprises) make use of scholarly articles and whether the scholarly publishing industry is doing anything to make their lives easier. This is a topic that is close to my heart. For the past few years I’ve been saying (most recently at SSP09) that I think scholarly publishers are much too quick to dismiss the possibility of creating an iTunes-like service for scholarly publications (aka “iPub”). The report certainly seems to indicate that there is an important audience that would benefit from such a service (SMEs) and even goes so far as to cite my occasional rants on the subject. The summary of my iPub argument has been that:

A very large percentage of the web visits that hit publishers web sites come from sources that are unrecognised. That is, they don’t come from a subscribing institution and they don’t seem to come from a registered user or anybody who has visited the site previously. For many publishers the level of such unrecognised visitors can amount to over 90% of all the traffic that hits their sites. Most industries would look at this percentage and work hard to figure out how to monetize some of it. Our industry seems to treat it like “noise”, reasoning that only people in recognised academic and professional institutions are going to desire or understand the content on scholarly journal sites.
Evidence from the NSF shows that significantly more than 50% of US students who graduate with an S&E degree end up employed outside of directly S&E related fields. This represents a large percentage of potential consumers of scholarly and professional publications who are not part of a recognised academic or professional institution. SMEs anybody?
These potential consumers are faced with a bewildering variety of sources for their content. They have to deal with multiple publisher sites with different interfaces and different PPV checkout procedures. And they have to navigate all this without the aid of library finding tools or the professional researcher’s understanding the scholarly journal environment. It is no wonder that they give up hope once they land on our abstract pages and face the gauntlet of another PPV checkout system.

It seems to me that the industry could provide a single interface and PPV shopping cart interface targeted at allowing people who work outside of traditional subscribing institutions to easily purchase individual article downloads from scholarly publishers. The system would be modelled at least in part by Apple’s iTunes, a system that has been lauded (and denounced) for revolutionising the way in which consumers buy music online. The chief virtues of the iTunes system are often cited as being:

It contains a critical mass of content
It provides a simple and consistent user interface
It has a simple and inexpensive pricing model
It disaggregated content (per song purchases)
It interfaced transparently with the iPod.

A scholarly publishing “iPub” system could seek to emulate many of these strengths but not all. Clearly such a system could not impose uniform pricing or dictate pricing, as that would be anti-competitive. The PRC report makes this same point.

Some, including the PRC report, also claim that the publishing industry has no equivalent of the “iPod” and that this would be a weakness of the system. I don’t agree with this- I think that the “iPod” in this case is currently called “paper.” In the future we will almost certainly migrate to some iPod/Kindle-like device, but as far as fulfilling most of the iPod’s functionality (portable rendering of the content) right now, I suspect paper fits the bill.

Finally, there is a another oft-expressed concern that such a system might confuse channels for existing audiences and that librarians in particular would be very hostile to such a system. The truth is, I don’t know how librarians would react to such a system. The few I’ve mentioned it to certainly seemed amenable to the idea. Maybe this is where the PRC should do some follow-up research?

In any case, it seems to me that there is potentially much to be gained by simply providing an easy PPV experience where users don’t have to register with multiple sites and cope with multiple shopping cart applications. Publishers can’t seriously think that they gain competitive advantage through their shopping carts? If not, then why not standardise on a uniform interface that is easily purchased from? Perhaps it doesn’t have to look like iTunes but can instead look like PayPal (PayPub?). Providing a simple mechanism like this might enable the industry to meet the needs of important and often overlooked audiences. I keep wondering if CCC could help publishers do something here?

Crossref is hiring an R&D Developer in Oxford

Geoffrey Bilder — Thu, 20 Aug 2009 00:00:00 +0000

We are looking to hire an R&D Developer in our Oxford offices. We are look for somebody who:

Is passionate about creating tools for online scholarly communication.
Relishes working with metadata.
Has experience delivering web-based applications using agile methodologies.
Wants to learn new skills and work with a variety of programming languages.
Enjoys working with a small, geographically dispersed team.
Groks mixed-content model XML.
Groks RDF.
Groks REST.
Has explored MapReduce-based database systems.
Is expert in one or more popular development language (Java, C, C++, C#).
Is expert in one or more popular scripting language (Ruby, Python, Javascript).
Has deployed and maintained Linux/BSD-based systems.
Understands relational databases (MySQL, Postgres, Oracle).
Tests first.

If you are interested, please see the full job description. If you are not interested, but know somebody who might be, please let them know about this great opportunity.

Strategic Reading

Geoffrey Bilder — Fri, 14 Aug 2009 00:00:00 +0000

Allen Renear and Carole Palmer have just published an article titled “Strategic Reading, Ontologies, and the Future of Scientific Publishing” in the current issue of Science (http://dx.doi.org.pluma.sjfc.edu/10.1126/science.1157784). I’m particularly happy to see this paper published because I actually got to witness the genesis of these ideas in my living room back in 2006. Since then, Allen and Carole’s ideas have profoundly influenced my thinking on the application of technology to scholarly communication.

Those who have seen me speak at conferences recently will have heard me do an awful lot of ranting about the how publishers and librarians need to help researchers practice the time-honored art of “reading avoidance” (or as Renear and Palmer politely put it- “strategic reading”). I even managed to squeeze this rant into a recent interview I did with Wiley-Blackwell.

The essence of my argument has been that our industries need not be bamboozled by the technical jargon and messianic hand-waving that typically accompany discussions of new technology trends like “web 2.0”, “text-mining”, “the semantic web”, “micro-blogging”, etc. This is because there is a fairly simple way for us to understand the relative import (or lack thereof) of new technologies to scholarly communication and that is to ask the following question:

“Can the application of this technology in the realm of scholarly communication help researchers to read less?”

If the answer is “yes”, then you’d better pay very close attention to it.

In fact, I’d go so far as to say the history of scholarly publishing can be characterized by the successful adoption of conventions and tools that help researchers read strategically.

Now I have something to cite when I rant.

Anyway, congratulations to Allen & Carole.

OpenSearch Formats for Review

Tony Hammond — Thu, 23 Jul 2009 00:00:00 +0000

In an earlier post I talked about using the PAM (PRISM Aggregator Message) schema for an SRU result set. I have also noted in another post that a Search Web Service could support both SRU and OpenSearch interfaces. This does then beg the question of what a corresponding OpenSearch result set might look like for such a record.

Based on the OpenSearch spec and also on a new Atom extension for SRU, I have contrived to show how a PAM record might be returned in a coomon OpenSearch format. Below I offer some mocked-up examples for each of the following formats for review purposes:

RSS 1.0
- ATOM
  - JSON
  Just click the relevant figure for a text rendering of each result format for the following phrase search:
  
  cql.keywords adj “solar eclipse”
  
  In this example we imagine that two records have been requested. (The example formats also include navigational links as per the OpenSearch spec examples.)
  
  Note that the JSON example closely follows the ATOM schema with a couple of main deviations:
  - Repeated elements are gathered together in an array (e.g. “entry”, “dc:creator”)
    - Attributes are broken out alongside their parent elements (e.g. “rel”, “href”)
    It would be interesting to hear what readers think of these examples - especially the JSON format.
```
<td>
<a href="http://nurture.nature.com.pluma.sjfc.edu/opensearch/demo/solar2-atom.txt"><img alt="solar2-atom.jpg" border="0" width="159" height="309" src="/wp/blog/images/solar2-atom.jpg" /></a>
</td>
<td>
<a href="http://nurture.nature.com.pluma.sjfc.edu/opensearch/demo/solar2-json.txt"><img alt="solar2-json.jpg" border="0" width="159" height="309" src="/wp/blog/images/solar2-json.jpg" /></a>
</td>
```
```
<th>
ATOM
</th>
<th>
JSON
</th>
```
    RSS 1.0
    
    (Click image to get text format.)


RSS 1.0

OASIS Drafts of SRU 2.0 and CQL 2.0

Tony Hammond — Wed, 22 Jul 2009 00:00:00 +0000

As posted here on the SRU Implementors list, the OASIS Search Web Services Technical Committee has announced the release of drafts of SRU and CQL version 2.0:

sru-2-0-draft.doc
- cql-2-0-draft.doc
The Committee is soliciting feedback on these two documents. Comments should be posted to the SRU list by August 13.

Crossref OpenURL resolver

Chuck Koscher — Tue, 07 Jul 2009 00:00:00 +0000

A new version of our OpenURL resolver was deployed July 2 which should handle higher traffic (e.g. we have re-enable the LibX plug-in ) Unfortunately there were a few hick ups with the new version which I believe are now corrected (a character encoding bug and a XML structure translation problem).

Sorry for any inconvenience.

XMP Primer

Tony Hammond — Wed, 10 Jun 2009 00:00:00 +0000

There’s a new XMP Primer (PDF) by Ron Roskiewicz (ed. Dianne Kennedy) available from XMP-Open. This is copyrighted 2008 but I only just saw this now. This is a 43 page document which provides a very gentle introduction to metadata and labelling of media and then introduces XMP into the content lifecycle and talks to the business case for using XMP. The primer covers the following areas:

Introduction to Metadata
- Introduction to XMP
  - XMP and the Content Lifecycle
    - XMP in Action; Use Cases
      - Additional XMP Resources
      One small gripe would be that this seems to have been prepared for US letter-sized pages and although is printable on A4 there is the slightest of clippings on the right-hand margin with no real loss of information but it does confer a sense of “incompleteness”. Really there can be little excuse these days for this parochialism. Also, for a document talking up the benefits of using XMP, it’s decidedly odd that it doesn’t make use of XMP itself - or rather there is a default XMP packet in the PDF with no real useful properties such as title, author, or date. Could have been a nice little object lesson in using XMP.

Aligning OpenSearch and SRU

Tony Hammond — Fri, 05 Jun 2009 00:00:00 +0000

[Update - 2009.06.07: As pointed out by Todd Carpenter of NISO (see comments below) the phrase “SRU by contrast is an initiative to update Z39.50 for the Web” is inaccurate. I should have said “By contrast SRU is an initiative recognized by ZING (Z39.50 International Next Generation) to bring Z39.50 functionality into the mainstream Web“.]

[Update - 2009.06.08: Bizarrely I find in mentioning query languages below that I omitted to mention SQL. I don’t know what that means. Probably just that there’s no Web-based API. And that again it’s tied to a particular technology - RDBMS.]

(Click image to enlarge.)

There are two well-known public search APIs for generic Web-based search: OpenSearch and SRU. (Note that the key term here is “generic”, so neither Solr/Lucene nor XQuery really qualify for that slot. Also, I am concentrating here on “classic” query languages rather than on semantic query languages such as SPARQL.)

OpenSearch was created by Amazon’s A9.com and is a cheap and cheerful means to interface to a search service by declaring a template URL and returning a structured XML format. It therefore allows for structured result sets while placing no constraints on the query string. As outlined in my earlier post Search Web Service, there is support for search operation control parameters (pagination, encoding, etc.), but no inroads are made into the query string itself which is regarded as opaque.

SRU by contrast is an initiative to update Z39.50 for the Web and is firmly focussed on structured queries and responses. Specifically a query can be expressed in the high-level query language CQL which is independent of any underlying implementation. Result records are returned using any declared W3C XML Schema format and are transported within a defined XML wrapper format for SRU. (Note that the SRU 2.0 draft provides support for arbitrary result formats based on media type.)

One can summarize the respective OpenSearch and SRU functionalities as in this table:

<th width="33%" align="center">
OpenSearch
</th>
<th width="33%" align="center">
SRU
</th>

<td align="center">
no
</td>
<td align="center">
yes
</td>

<td align="center">
yes
</td>
<td align="center">
yes
</td>

<td align="center">
yes
</td>
<td align="center">
yes
</td>

<td align="center">
no
</td>
<td align="center">
yes
</td>

Structure
query
results
control
diagnostics

What I wanted to discuss here was the OpenSearch and SRU interfaces to a Search Web Service such as outlined in my previous post. The diagram at top of this post shows query forms for OpenSearch and SRU and associated result types. The Search Web Service is taken to be exposing an SRU interface. It might be simplest to walk through each of the cases.

(Continues below.)

Case 1: OpenSearch (Native Client)

As noted, OpenSearch uses a URL template (declared in an OpenSearch description document) where recognized parameters are mapped to implementation-specific parameters. The bolded parameter “query” in the figure indicates an OpenSearch parameter “searchTerms” which has been mapped to the Search Web Service parameter “query“,

As also noted, SRU 2.0 offers support for alternate result formats (other than SRU XML) by allowing a media type (aka mime type) to be passed in an “http:accept” parameter. There is, however, no OpenSearch parameter corresponding to a format selector, so this must be hard coded directly into the URL template with a value of “application/rss+xml” - the standard media type for an RSS feed which is the common result format for OpenSearch.

(In the diagram I have noted in parentheses that RSS in its RSS 1.0 form is RDF. And that format is a strong candidate for semantic interoperability. An alternate format would be Atom, which could be similarly selected with a value of “application/atom+xml”, but it is difficult to see at this time what advantage Atom confers. It does not conform to the RDF data model but may find better support in code libraries and applications.)

The third parameter shown for Case 1, is “queryType” which is another new SRU 2.0 parameter. I had noted earlier that an OpenSearch query string could be passed directly through to the Search Web Service and its associated CQL parser. It tuns out that this needs to be analyzed further. (And many thanks to Jonathan Rochkind for useful discussions on this.)

I had naively assumed that an OpenSearch query string would either be packed as a CQL string or would be a simple text string which could be interpreted as CQL. The latter interpretation (text string) turns out to be true only for a single bare word or for a quoted string - both of which are recognized CQL query strings (i.e. a single search term which has a default index and relationship to that index). It fails, however, for the more general case of unquoted strings. See table below for these cases.

<th width="50%">
Query string
</th>

<td align="left">
this
</td>

<td align="left">
&#8220;this is a query&#8221;
</td>

<td align="left">
this is a query
</td>

Query type
A. bare word
B. quoted string
C. unquoted string

Case C would fail a CQL parser. So we need to signal to the Search Web Service that this is not a CQL string. And that’s where the “queryType” parameter comes in. If it’s set to “cql” then the query string is to be parsed as CQL, otherwise it must be handled in an alternate fashion. (As of now there is no value set for this parameter that I am aware of so I am using the terms “plain” and “cql” to differentiate.)

How this should be handled by a CQL aware application is not immediately obvious. My first thought was to allow the application to silently quote such a string but that would change the semantics. It would be better to split the string into separate search clauses for each word and to join the search cluases by a default boolean operator, e.g. “AND“, so that case C in the table might be interpreted by the application as:

``[Update - 2009.06.07: As pointed out by Todd Carpenter of NISO (see comments below) the phrase “SRU by contrast is an initiative to update Z39.50 for the Web” is inaccurate. I should have said “By contrast SRU is an initiative recognized by ZING (Z39.50 International Next Generation) to bring Z39.50 functionality into the mainstream Web“.]

(Click image to enlarge.)

One can summarize the respective OpenSearch and SRU functionalities as in this table:

<th width="33%" align="center">
OpenSearch
</th>
<th width="33%" align="center">
SRU
</th>

<td align="center">
no
</td>
<td align="center">
yes
</td>

<td align="center">
yes
</td>
<td align="center">
yes
</td>

<td align="center">
yes
</td>
<td align="center">
yes
</td>

<td align="center">
no
</td>
<td align="center">
yes
</td>

Structure
query
results
control
diagnostics

(Continues below.)

Case 1: OpenSearch (Native Client)

<th width="50%">
Query string
</th>

<td align="left">
this
</td>

<td align="left">
&#8220;this is a query&#8221;
</td>

<td align="left">
this is a query
</td>

Query type
A. bare word
B. quoted string
C. unquoted string

Now, of course, we must not expect that a typical OpenSearch implementation would be aware of CQL (or any of the SRU technologies). Instead we can simply indicate in the URL template that the “queryType” is non-CQL, by hard coding “queryType=plain”. The actual URL template which is declared in the OpenSearch description would thus be something like the following (with whitespace added for clarity):

<!-- 1. queryType="plain" -->
<Url type="application/rss+xml"
     template="http://www.example/search?
     query={searchTerms}
     &queryType=plain
     &http:accept=application/rss+xml
     "
/>

This URL template uses one OpenSearch parameter(“searchTerms”) and that is mapped to the SRU parameter “query”. The SRU 2.0 parameters “queryType” and “http:accept” are wired in. This means that a Search Web Service would be aware of the query, would know that it was not CQL (so might invoke a handler), and would be know that a result set in RSS was required.

Case 2: OpenSearch (CQL-Aware Client)

The above case, works for a general OpenSearch client but now is problematic for a CQL-aware client. With the “queryType” set at “plain” there is no opportunity to indicate that a generic CQL string might be passed instead. We certainly wouldn’t want a non-CQL handler to operate on a valid CQL string. We need to vary the SRU 2.0 parameters and within the scope of OpenSearch this can only be done by recognizing the parameters as OpenSearch extensions. Basically, an extension is nothing more than a separately namespaced element or attribute. Recommendation is that the XML namespace would resolve to a specification document detailing the intention and format of the extension.

The URL template for a CQL-aware OpenSearch description could make use of the “queryType” and “http:accept” parameters as OpenSearch extensions (marked in bold italics in the figure) using a declaration like this:

<!-- 2. queryType="cql" -->
<Url type="application/xml"
     xmlns:sru="http://opensearch.example/sru-extension"
     template="http://www.example/search?
     query={searchTerms}
     &queryType={sru:queryType?}
     &http:accept={sru:httpAccept?}
     "
/>

Note here that both parameters have been specified as being optional. Also the namespace here is pointed at a fictional OpenSearch extension document. (It doesn’t need to point to such a document - could be anything - but it is recommended that there be a specification.)

I’m not aware of any such OpenSearch extension document for SRU currently existing but would be prepared to contribute to drafting such a document. It seems to me that it would be would be very useful for general OpenSearch/SRU compatibility and probably should detail all the SRU 2.0 parameters for “searchRetrieve”. In fact, that document could be the SRU spec itself, once that was established at a fixed URL. (Whether there should be a specific OpenSearch extension document depends on whether it would be useful to provide OpenSearch implementation details.)

Case 3: SRU (Native Client)

This is easy. We’re on home ground now. The query type is by default CQL, and the result format is SRU XML. The only thing that might be specified is “recordSchema” to require a schema for the result records, if there are alternate schemas supported by the Search Web Service. A default for the result records is anyway supplied.

Case 4: SRU (Media-Typed Client)

Again, we’re on familiar ground. For a media-savvy SRU interface we would need to use the SRU 2.0 parameter “http:accept”. This could be used to override the default SRU XML with an alternate format, e.g. RSS.

And that’s about it for this review of aligning the OpenSearch and SRU interfaces. It seems that using URL templates and OpenSearch extensions as indicated should allow for an easy OpenSearch interface onto an SRU-based Search Web Service. At a minimum we just need a permanent URL for the SRU 2.0 spec (when finalized). Alternately a separate OpenSearch extension document could be drafted and registered. That would allow for details specific to OpenSearch to be provided, as well as bringing SRU closer into the OpenSearch realm. And such a document could be created now and updated with the URL for the SRU 2.0 spec as it progresses from draft to final.

Search Web Service

Tony Hammond — Sat, 30 May 2009 00:00:00 +0000

(Click image to enlarge graphic.)

While the OASIS Search Web Services TC is currently working towards reconciling SRU and OpenSearch, I thought it would be useful to share here a simple graphic outlining how a search web service for structured search might be architected.

Basically there are two views of this search web service (described in separate XML description files and discoverable through autodiscovery links added to HTML pages):

OpenSearch
- SRU (Search and Retrieve by URL)
One can see at a glance that there’s more happening down in the SRU layer. The SRU layer implements a heavyweight, robust service which provides a detailed listing of search indexes and index relations in the description document (‘SRU Explain’), is searchable using a standard query grammar - CQL (‘Contextual Query Language’), responds with result sets inside a standard XML wrapper and expressed as an XML record set (e.g. PAM) that is validatable using W3C XML Schema, and makes available a full roster of diagnostics.

By contrast the OpenSearch layer provides a lightweight view onto the search web service in which a simple opaque query string is sent to the server and a simple XML result set returned (usually RSS or Atom). Again a description document is made available (‘OpenSearch Description’) but this is much more coarse grained than the SRU description - e.g. it does not specify query components such as indexes or relations.

In practice, both views can be provided for by the same search web service. While OpenSearch does not specify any structured query it can make use of a CQL packaged query. That is, a single parameter value for the OpenSearch ‘query’ parameter can be unpacked by a CQL parser to yield a complex search query. The search query does not need to be splattered all over the URL querystring which is already using its parameter set to provide control information for the search (e.g. pagination, encoding and the like).

And how would this relate to existing platform-hosted search services? Well, such services are usually bound to the host platform and are not intended to support remote applications. A search web service, on the other hand, would be ideally suited to offering direct support for running structured searches on platform-hosted content using off-platform apps.

Structured Search Using PRISM Elements

Tony Hammond — Sat, 30 May 2009 00:00:00 +0000

We just registered in the SRU (Search and Retrieve by URL) search registry the following components:

Context Sets

PRISM Context Set version 2.0
- PRISM Context Set version 2.1
Schemas
- PRISM Aggregator Message Record Schema Version 2.0
  - PRISM Aggregator Message Record Schema Version 2.1

This means that an SRU (Search and Retrieve by URL) search engine that supported one of the PRISM context sets registered above could accept CQL (Contextual Query Language) queries such as the following:

prism.doi = “10.1038/nature05398”
- prism.publicationName = “Nature” and prism.volume = “444” and prism.number = “7119” and prism.startingPage = “E9”
  - dc.identifier = “doi:10.1038/nature05398”
    - dc.creator = “Jones-Smith” and prism.publicationName = “Nature” and prism.publicationDate > “2006-01-01”
      - dc.title any “fractal pollock” and prism.publicationName = “Nature” sortBy prism.publicationDate/sort.descending
        
        “fractal anlysis” and prism.publicationDate within “2005-01-01 2008-12-31” sortBy dc.creator/sort.ascending

(Note that the quotes are only needed above for the DOI strings which contain a “/” character. Otherwise they are optional in the above examples.)

Any query such as one of the above (here #1) could be sent to the server on a querystring like so:

?version=1.1&operation=searchRetrieve&query=prism.doi=%2210.1038/nature05398%22

and if the server were also equipped to respond with PAM (PRISM Aggregator Message) format for result records, a response might look like this:

PAM was discussed here earlier.

Such a structured response would provide the metadata elements for applications to build various interfaces into the original article:

We think that these PRISM components (context sets and schemas) will be useful for structured search of scholarly publications.

OAI-ORE: Workshop Slides

Tony Hammond — Tue, 26 May 2009 00:00:00 +0000

An Overview of the OAI Object Reuse and Exchange Interoperability Framework

View more Microsoft Word documents from hvdsomp.

This is a very slick presentation by Herbert Van de Sompel on OAI-ORE which he’s due to give today for a workshop at the INFORUM 2009 15th Conference on Prrofessional Information Resources in Prague. It’s on the long side at 167 slides but even if you just flip though or sample it selectively you’ll be bound to come away with something.

Describing aggregations of resources is a subject that really has to be of interest to Crossref publishers.

PRISM Aggregator Message

Tony Hammond — Fri, 08 May 2009 00:00:00 +0000

The new OAI-PMH interface to Nature.com sports one particular novelty which may well be of interest here: it makes use of the PRISM Aggregator Message. (For an announcement of this service see the post on our web publishing blog Nascent.)

As a protocol for the harvesting of metadata records within a digital repository, OAI-PMH records may be expressed in a variety of different metadata formats. For reasons of interoperability a base metadata format (‘Dublin Core’) is mandated for all OAI-PMH implementations. The expectation is that this base format would be augmented by community-specific vocabularies.

Our natural inclination was to mirror the article descriptions which we already circulate in our RSS feeds and within our HTML pages (as META tags) and PDF files (as XMP packets). In these cases we have used open data models (e.g. RDF) with simple properties cherry-picked from the DC and PRISM namespaces. But OAI-PMH has a special ‘gotcha’ in this regard: any metadata format must allow for W3C XML Schema validation. That is, the properties need to be constrained by an XSD data model. Enter PRISM Aggregator Message (PAM).

(Continues)

For the longest time I must confess I did not ‘get’ what PAM was about. PRISM was clearly a metadata vocabulary and yet with PAM there was all this wrangling with content, which as an academic publisher we frankly had no interest in as we already had our own journal article DTD and for interop we were beginning to look at NLM DTD. And then it dawned on me (albeit slowly) that the PAM DTD is the equivalent to NLM DTD but for trade magazine publishing, where there might not be such a strong practice of XML. And since the release of PRISM 2.0 (February 2008) there was now also an W3C XML Schema defined for PAM. (Note that the latest revision of PRISM 2.1 is about to be published, although the changes there do not have any bearing on this implementation.)

So, PAM defines PRISM elements to be used with XML content markup. Examining further reveals that within a PAM message there are one or more articles with metadata packaged into a head section, and content (if present) in a body section.

Section 4.3 in the PAM 2.0 specification lists the allowable head elements by logical grouping, 11 in all: key elements, title, creative origin, publication, publication date, additional article ID, positional, topic, length, related content, rights & usage. Note that not all PRISM elements are supported; in fact only 43 of the 57 PRISM 2.0 elements are supported. Among the missing are ‘prism:endingPage‘. Also only 7 of the 15 DC elements are supported. Nevertheless we found that the bulk of the article descriptions could easily be accommodated within the PAM format. And because this is W3C XML Schema constrained there is an element ordering prescribed, and hence there is an interleaving of DC and PRISM elements.

The Nature.com OAI-PMH service has two access points:

User interface:: http://www.nature.com.pluma.sjfc.edu/oai
Service endpoint:: http://www.nature.com.pluma.sjfc.edu/oai/request

So, to work an example, if we want to get the record for doi:10.1038/nature01234 (which has an OAI-PMH identifier of oai:nature.com:10.1038/nature01234) we could use this call to get the description in PAM format:

http://www.nature.com.pluma.sjfc.edu/oai/request?verb=GetRecord&identifier=10.1038/nature01234&metadataPrefix=pam

(Note that as a convenience for the user we also allow a DOI to be used directly in place of the full OAI-PMH identifier as there is a one-to-one correspondence between the two within our repository. Simplifies cut and paste operations.)

This returns the following properties (shown in document order and by PAM logical grouping):

With PAM we are thus able to replicate in OAI-PMH the same journal article descriptions that we are currently disseminating through other service/content channels.

Crossref’s OpenURL query interface

Chuck Koscher — Wed, 06 May 2009 00:00:00 +0000

Over the past two weeks we’ve focused on our OpenURL query interface with the goal being to improve its reliability. I’d like to mention some things we’ve done.

We now require an OpenURL account to use this interface (see the registration page) . This account is still free, there are no fixed usage limits, and the terms of use have been greatly simplified.
Resources have been re-arranged dedicating more horse-power to the OpenURL function.
The OpenURL function is now in our advanced monitoring function which means some lucky staff member will be getting phone calls at 3AM (me included!).

I should note that #1 has already reduced inappropriate usage. This also is not the end of planned changes. Crossref has undertaken a major rewrite of parts of our system and this will include the OpenURL interface.

Chuck

OCLC defines requirements for a “Cooperative Identities Hub”

Geoffrey Bilder — Fri, 01 May 2009 00:00:00 +0000

OCLC has published a report (PDF) identifying some requirements for what they call a “Cooperative Identities Hub”. A quick glance through it seems to show that the use cases focus on what we are calling the “Knowledge Discovery” use cases. As I mentioned in my interview with Martin Fenner, there is also a category of “authentication” use cases that I think needs to be addressed by a contributor identifier system. Still, this is a good report that highlights many of the complexities that an identifier system needs to address.

What do people want from an author identifier?

Geoffrey Bilder — Mon, 27 Apr 2009 00:00:00 +0000

Martin Fenner continues his interest in the subject of author identifiers. He recently posted an online poll asking people some specific questions about how they would like to see an author identifier implemented.^*

The results of the poll are in and, though the sample was very small, the results are interesting. The responses are both gratifying -there seems to be a general belief that Crossref has a roll to play here- and perplexing -most think the identifier needs to identify other “contributors” to the scholarly communications process- yet there seems to be a preference for the moniker “digital author identifier”. This latter preference is certainly a surprise to us as we had been focusing our efforts on identifying analog authors. The only “digital authors” I know of are this one at at MIT and possibly this one at Aberystwyth University. 😉

Anyway, There are some additional reactions to Martin’s poll on FriendFeed.

Finally, I should have blogged about this earlier, but the March issue of Science included a summary of the initiatives and discussions surrounding the creation of an industry “author identifier” in an article titled “Are You Ready to Become a Number” (http://dx.doi.org.pluma.sjfc.edu/10.1126/science.323.5922.1662).

In pointing people at this, I feel like I must make a clarification to the article. In short, I don’t think any of our members would “force” anybody to use an author identifier whether it came from Crossref or from anybody else. Though it is likely that in the interview I used the terms “carrot” and “stick”, in truth publisher’s would, instead of “a stick”, at most wield a Nerf bat. Having said that, the essential point remains- even if most major publishers strongly encouraged all of their authors to use the system, it would take several years before the system had a critical mass of data.

^*Note that I deliberately didn’t point CrossTech readers at this poll as it was being conducted because I thought doing so might introduce a Crossref bias.

Introductory Signals

Geoffrey Bilder — Mon, 23 Mar 2009 00:00:00 +0000

So while doing some background reading today I realized that legal citations already widely support a form of “citation typing” in the form of “Introductory Signals“. The 10 introductory signals break down as follows…

In support of an argument:

1) [no signal]. (NB that, apparently, this is increasingly deprecated.)

2) accord;

3) see;

4) see also;

5) cf.;

For Comparisons:

6) compare … with …;

For contradiction:

7) but see;

8) but cf.;

For background:

9) see generally;

And for examples:

10) e.g.

Clever lawyers.

Citation Typing Ontology

Geoffrey Bilder — Fri, 20 Mar 2009 00:00:00 +0000

I was happy to read David Shotton’s recent Learned Publishing article, Semantic Publishing: The Coming Revolution in scientific journal publishing, and see that he and his team have drafted a Citation Typing Ontology.^*

Anybody who has seen me speak at conferences knows that I often like to proselytize about the concept of the “typed link”, a notion that hypertext pioneer, Randy Trigg, discussed extensively in his 1983 Ph.D. thesis.. Basically, Trigg points out something that should be fairly obvious- a citation (i.e. “a link”) is not always a “vote” in favor of the thing being cited.
In fact, there are all sorts of reasons that an author might want to cite something. They might be elaborating on the item cited, they might be critiquing the item cited, they might even be trying to refute the item cited (For an exhaustive and entertaining survey of the use and abuse of citations in the humanities, Anthony Grafton‘s, The Footnote: A Curious History, is a rich source of examples)
Unfortunately, the naive assumption that a citation is tantamount to a vote of confidence has become inshrined in everything from the way in which we measure scholarly reputation, to the way in which we fund universities and the way in which search engines rank their results. The distorting affect of this assumption is profound. If nothing else, it leads to a perverse situation in which people will often discuss books, articles, and blog postings that they disagree with without actually citing the relevant content, just so that they can avoid inadvertently conferring “wuffie” on the item being discussed. This can’t be right.
Having said that, there has been a half-hearted attempt to introduce a gross level of link typology with the introduction of the “nofollow” link attribute- an initiative started by Google in order to try to address the increasing problem of “Spamdexing”. But this is a pretty ham-fisted form of link typing- particularly in the way it is implemented by the Wikipedia where Crossref DOI links to formally published scholarly literature have a “nofollow” attribute attached to them but, inexplicably, items with a PMID are not so hobbled (view the HTML source of this page, for example). Essentially, this means that, the Wikipedia is a black-hole of reputation. That is, it absorbs reputation (through links too the Wikipedia), but it doesn’t let reputation back out again. Hell, I feel dirty for even linking to it here ;-).
Anyway, scholarly publishers should certainly read Shotton’s article because it is full of good, and practical ideas about what can can be done with today’s technology in order to help us move beyond the “digital incunabula” that the industry is currently churning out. The sample semantic article that Shotton’s team created is inspirational and I particularly encourage people to look at the source file for the ontology-enhanced bibliography which reveals just how much more useful metadata can be associated with the humble citation.
And now I wonder whether CiteULike, Connotea, 2Collab or Zotero will consider adding support for the CItation Typing Ontology into their respective services?
* Disclosure:
a) I am on the editorial board of Learned Publishing
b) Crossref has consulted with David Shotton on the subject of semantically enhancing journal articles

Researcher Identification Primer

Geoffrey Bilder — Wed, 11 Mar 2009 00:00:00 +0000

Discussions around “contributor Ids” (aka “Author ID, Researcher ID, etc.) seem to be becoming quite popular. In the interview that I pointed to in my last post, I mentioned that Crossref has been talking with a group of researchers who were very interested in creating some sort of authenticated contributor ID as a mechanism for controlling who gets trusted access to sensitive genome-wide aggregate genotype data.

Well, I’m delighted to say that said group of researchers(at the GEN2PHEN project) have created a “Researcher Identification Primer” website in which they outline the many use-cases and issues around creating a mechanism for unambiguously identifying and/or authenticating researchers. This looks like a great resource and I expect it will serve as a useful focus for further discussion around the issue.

An interview about “Author IDs”

Geoffrey Bilder — Thu, 19 Feb 2009 00:00:00 +0000

Over the past few months there seems to have been a sharp upturn in general interest around implementing an “author identifier” system for the scholarly community. This, in turn, has meant that more people have been getting in touch with us about our nascent “Contributor ID” project. The other day, after seeing my comments in the above thread, Martin Fenner asked if he could interview me about the issue of author identifiers for his blog on Nature Networks, Gobbledygook. I agreed and he posted the interview the other day.

I warn you ahead of time, I did ramble on a bit and the interview is long. There is a lot of stuff at the beginning about the DOI and it might seem off-topic, but I do think that there is a lot that we can learn from our DOI experiences which would apply to any author identifier. Just be thankful I didn’t start talking about the privacy issues that will inevitably arise from any author identifier system. If I had, the interview would have probably gone on for another six pages ;-).

Anyway, as most of our membership knows, we have a pilot project underway to explore what it would take to launch a “Crossref Contributor ID” system. We still haven’t concluded whether it makes sense for us to do it, but one thing is clear from the recent discussions we’ve had and that is that, if we don’t do it, somebody else almost certainly will.

Real PRISM in the RSS Wilds

Tony Hammond — Thu, 19 Feb 2009 00:00:00 +0000

Alf Eaton just posted a real nice analysis of ticTOCs RSS feeds. Good to see that almost half of the feeds (46%) are now in RDF and that fully a third (34%) are using PRISM metadata to disclose bibliographic fields.

The one downside from a Crossref point of view is that these feeds are still using the old PRISM version (1.2) and not the new version (2.0) which was released a year ago and blogged here. That version supports the elements prism:doi for the bare DOI, as well as prism:url for the DOI proxy server URL.

There are still some improvements to be made in serving up these feeds (as Alf’s analysis shows for record type), but overall things are looking pretty good. 🙂

DOIs in an iPhone application

Geoffrey Bilder — Thu, 12 Feb 2009 00:00:00 +0000

Very cool to see Alexander Griekspoor releasing an iPhone version of his award-winning Papers application. A while ago Alex intigrated DOI metadata lookup into the Mac version of papers and now I can get a silly thrill from seeing Crossref DOIs integrated in an iPhone app. Alex has just posted a preview video of the iPhone application and it includes a cameo appearance by a DOI. Yay.

CURIE Syntax 1.0

Tony Hammond — Mon, 19 Jan 2009 00:00:00 +0000

The W3C has recently (Jan. 16) released CURIE Syntax 1.0 as a Candidate Recommendation and is inviting implementations.

(Note that I made a fuller post here on CURIEs and erroneously confused the Editor’s Draft (Oct. 23, ’08) as being a Candidate Recommendation. Well, at least it’s got there now.)

Standard InChI Defined

Tony Hammond — Sat, 17 Jan 2009 00:00:00 +0000

IUPAC has just released the final version (1.02) of its InChI software, which generates Standard InChIs and Standard InChIKeys. (InChI is the IUPAC International Chemical Identifier.)

The Standard InChI “removes options for properties such as tautomerism and stereoconfiguration”, so that a molecule will always generate the same stable identifier - a unique InChI - which facilitates “interoperability/compatibility between large databases/web searching and information exchange”. Note also that any “shortcomings in Standard InChI may be addressed using non-Standard InChI (currently obtainable using InChI version 1.02beta)”.

On a practical level this means that the 27-character length InChIKeys (a hashed form of the InChI), with the following generic form

AAAAAAAAAAAAAA-BBBBBBBBFV-P

can now be readily and reliably generated and will start to be used in search indexing and linking applications.

XMP Library for Flash

Tony Hammond — Fri, 16 Jan 2009 00:00:00 +0000

Update about new XMP Library from Adobe Labs:

“The new Adobe XMP Library for ActionScript is now available for download on Adobe Labs. Adobe Extensible Metadata Platform (XMP) is a labeling technology that allows you to embed data about a file, known as metadata, into the file itself. XMP is an open technology based on RDF and RDF/XML. With this new library you can read existing XMP metadata from Flash based file formats via the Adobe Flash Player.“

Any volunteers?

Poorboy Metadata Hack

Tony Hammond — Tue, 06 Jan 2009 00:00:00 +0000

I was playing around recently and ran across this little metadata hack. At first, I thought somebody was doing something new. But no, nothing so forward apparently. (Heh! 🙂

I was attempting to grab the response headers from an HTTP request on an article page and was using by default the Perl LWP library. For some reason I was getting metadata elements being spewed out as response headers - at least from some of the sites I tested. With some further investigation I tracked this back to LWP itself which parses HTML headers and generates HTTP pseudo-headers using an X-Meta- style header. (This can be viewed either as a feature of LWP or a bug as this article bemoans.)

What this means anyway is that I can issue a simple call like this to get the HTML metadata - shown here for doi:10.1087/095315108X288947:

``I was playing around recently and ran across this little metadata hack. At first, I thought somebody was doing something new. But no, nothing so forward apparently. (Heh! 🙂

What this means anyway is that I can issue a simple call like this to get the HTML metadata - shown here for doi:10.1087/095315108X288947:

This shows a simple (read lazy) means of accessing metadata added as <meta> tags in HTML headers, such as those we added for Nature. (Of course, machine readable metadata is best added using RDFa as noted earlier, but does not preclude also adding in <meta> tags which are also usable with HTML as well as XHTML.)

(Btw, wouldn’t it be fun if Crossref had a random DOI facility? That would be real handy for testing as well as giving users a feel for what real-life DOIs look like and what lies at the other end of them.)