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.

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

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

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)

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.

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

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

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

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.

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.

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)

1) 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.

2) Resources have been re-arranged dedicating more horse-power to the OpenURL function.

3) 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

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/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 publisher 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.

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.

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

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.

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.

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 content type), but overall things are looking pretty good. :)