Blog

So, why is it just so difficult to reference OpenURL? Apart from the standard itself (hardly intended for human consumption - see abstract page here and PDF and don’t even think to look at those links - they weren’t meant to be cited!), seems that the best reference is to the Wikipedia page. There is the OpenURL Registry page at http://0-alcme-oclc-org.libus.csd.mu.edu/openurl/servlet/OAIHandler?verb=ListSets but this is just a workshop. Not much there beyond the OpenURL registered items.

So, the big guns have decided that XRI is out. In a message from the TAG yesterday, variously noted as being “categorical” (Andy Powell, eFoundations) and a “proclamation” (Edd Dumbill, XML.com), the co-chairs (Tim Berners-Lee and Stuart Williams) had this to say: “We are not satisfied that XRIs provide functionality not readily available from http: URIs. Accordingly the TAG recommends against taking the XRI specifications forward, or supporting the use of XRIs as identifiers in other specifications.

Following on from yesterday’s post about making metadata available on our Web pages, I wanted to ask here about “metadata reuse policies”. Does anybody have a clue as to what might constitute a best practice in this area? I’m specifically interested in license terms, rather than how those terms would be encoded or carried. Increasingly we are finding more channels to distribute metadata (RSS, HTML, OAI-PMH, etc.) but don’t yet have any clear statement for our customers as to how they might reuse that data.

Well, we may not be the first but wanted anyway to report that Nature has now embedded metadata (HTML meta tags) into all its newly published pages including full text, abstracts and landing pages (all bar four titles which are currently being worked on). Metadata coverage extends back through the Nature archives (and depth of coverage varies depending on title). This conforms to the W3C’s Guideline 13.2 in the Web Content Accessibility Guidelines 1.0 which exhorts content publishers to “provide metadata to add semantic information to pages and sites”.

Metadata is provided in both DC and PRISM formats as well as in Google’s own bespoke metadata format. This generally follows the DCMI recommendation “Expressing Dublin Core metadata using HTML/XHTML meta and link elements, and the earlier RFC 2731 “Encoding Dublin Core Metadata in HTML”. (Note that schema name is normalized to lowercase.) Some notes:

• The DOI is included in the “dc.identifier” term in URI form which is the Crossref recommendation for citing DOI.
  • We could consider adding also “prism.doi” for disclosing the native DOI form. This requires the PRISM namespace declaration to be bumped to v2.0. We might consider synchronizing this change with our RSS feeds which are currently pegged at v1.2, although note that the RSS module mod_prism currently applies only to PRISM v1.2.
    • We could then also add in a “prism.url” term to link back (through the DOI proxy server) to the content site. The namespace issue listed above still holds.
      • The “citation_” terms are not anchored in any published namespace which does make this term set problematic in application reuse. It would be useful to be able to reference a namespace (e.g. “rel="schema.gs" href="..."“) for these terms and to cite them as e.g. “gs.citation_title“.
      The HTML metadata sets from an example landing page are presented below.

Further to my previous post “NIH Mandate and PMCIDs” we’ve been looking into linking to articles on publishers’ sites from PubMed Central (PMC). There are a couple of ways this happens currently (see details below) but these are complicated and will lead to broken links and more difficulty for PMC and publishers in managing the links. Crossref is going to be putting together a briefing note for its members on this soon.

The main issue we are raising with PMC, and that we will encourage publishers to raise too, is why doesn’t PMC just automatically link DOIs? Most of the articles in PMC have DOIs so this would require very little effort from PMC and no effort from publishers and would give readers a perisistent link to the publisher’s version of an article.

Following up the earlier post on OpenHandle, there are now a number of language examples which have been contributed to the project. The diagram below shows the OpenHandle service in schematic with various languages support. Briefly, OpenHandle aims to provide a web services interface to the Handle System to simplify access to the data stored for a given Handle. (Note that the diagram is an HTML imagemap and all elements are “clickable”.

The NIH Public Access Policy says “When citing their NIH-funded articles in NIH applications, proposals or progress reports, authors must include the PubMed Central reference number for each article” and the FAQ provides some examples of this: Examples: Varmus H, Klausner R, Zerhouni E, Acharya T, Daar A, Singer P. 2003. PUBLIC HEALTH: Grand Challenges in Global Health. Science 302(5644): 398-399. PMCID: 243493 Zerhouni, EA. (2003) A New Vision for the National Institutes of Health.

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.

Just announced on the handle-info and semantic-web mailing lists is the OpenHandle project on Google Code. This may be of some interest to the DOI community as it allows the handle record underpinning the DOI to be exposed in various common text-based serializations to make the data stored within the records more accessible to Web applications. Initial serializations include RDF/XML, RDF/N3, and JSON. We’d be very interested in receiving feedback on this project - either on this blog or over on the project wiki.

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.