Blog

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: doi:10.1045/july2010-hammond

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

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

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

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

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

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.

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.