Blog

From Ray Denenberg’s post to the SRU Listserv yesterday: _“The new SRU web site is now up: http://www.loc.gov/sru/ It is completely reorganized and reflects the version 1.2 specifications. (It also includes version 1.1 specifications, but is oriented to version 1.2.) … There is an official 1.1 archive under the new site, https://web.archive.org/web/20080724063403/http://www.loc.gov/sru/sru1-1archive/. And note also, that the new spec incorporates both version 1.1 and 1.2 (anything specific to version 1.1 is annotated as such).

The first thing to note is that this demo (the Acrobat plugin) is an application. And that comes with its own baggage, i.e. this is a Windows only plugin and is targeted at Acrobat Reader 8. On a wider purview the application merely bridges an identifier embedded in the media file and the handle record filed against that identifier and delivers some relevant functionality. The data (or metadata) declared in the PDF and in the associated handle if rich enough and structured openly can also be used by other applications. I think this is a key point worth bearing in mind, that the demo besides showing off new functionalities is also demonstrating how data (or metadata) can be embedded at the respective endpoints (PDF, handle).

Some initial observations follow below.

So, assuming we know the form of the metadata we wish to add to our PDFs (or else to comply with if there is already a set of guidelines, or some industry initiative in effect) how can we realize this? And, on the flip side, how can we make it easier for consumers to extract metadata we have embedded in our PDFs.

Below are some considerations on deploying metadata in PDFs and consumer access.

Only just caught up with this but the PRISM 2.0 draft is now available (since July 12) for public comment. See this posted by Dianne Kennedy: _“Just a note to let you know that PRISM 2.0 has just been posted at www.prismstandard.org . This is the first major revision to PRISM. We have incorporated new elements to support online content and have expanded and revised our controlled vocabularies. In addition we have added a profile to support PRISM in an XMP environment.

Emboldened by my own researches, by the recent handle plugin announcement from CNRI (on which, more in a follow-on post), and by Alexander Griekspoor’s comment to my earlier post, I thought I’d write a more extensive piece about embedding metadata in PDF with a view to the following: Discover what other publishers are currently doing Stimulate discussions between content providers and/or consumers Lay groundwork for a Crossref best practice guidelines Why should Crossref be interested?

Well, this is likely to be a fairly brief post as I’m not aware of many use cases of metadata in PDFs from scholarly publishers. Certainly, I can say for Nature that we haven’t done much in this direction yet although are now beginning to look into this.

I’ll discuss a couple cases found in the wild but invite comment as to others’ practices. Let me start though with the CNRI handle plugin demo for Acrobat which I blogged here.

Just announced on the handle-info list is a new plugin from CNRI for Acrobat Reader - see here. The announcement says: _“It is intended to demonstrate the utility of embedding a identifying handle in a PDF document. … A set of demonstration documents, each with an embedded identifying handle, is packaged with the plug-in to show potential uses. To make productive use of this technology, a given industry or community of

Well, it all went very quiet for a while but glad to see that the URI Template Internet-Draft has just been republished: _“A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : URI Template Author(s) : J. Gregorio, et al. Filename : draft-gregorio-uritemplate-01.txt Pages : 9 Date : 2007-7-23 URI Templates are strings that can be transformed into URIs after embedded variables are substituted. This document defines the

<span >(<b>Update - 2007.07.28:</b> I meant to reference in this entry Pierre Lindenbaum’s post back in May <a href="http://plindenbaum.blogspot.com/2007/05/is-there-any-xmp-in-scientific-pdf-no.html">Is there any XMP in scientific pdf ? (No)</a>, which btw also references Roderic Page’s post on <a href="http://iphylo.blogspot.com/2007/05/xmp.html">XMP</a> but forgot to add in the links in my haste to scoot off. Well, truth is we still can’t answer Pierre in the affirmative but at least we can take the first steps towards rectifying this.)

<span >I’ve been revisiting Adobe’s <a href="http://www.adobe.com/products/xmp/">XMP</a> just recently. (I blogged <a href="/blog/xmp-capabilities-extended//">here</a> about the new <a href="http://www.adobe.com/devnet/xmp/">XMP Toolkit 4.1</a> back in March.)

<span >I wanted to share some of my early experiences. First off, after a couple of previous attempts which got pushed aside due to other projects, I managed to compile the libraries and the sample apps that ship with the C++ SDK under Xcode on the Mac. I also needed to compile <a href="https://libexpat.github.io/">Expat</a> first which doesn’t ship with the distribution.

<span >OK, so far, so good. What this basically leaves one with is a couple of XMP dump utilities (<i>DumpMainXMP</i> and <i>DumpScannedXMP</i>) and two others (<i>XMPCoreCoverage</i> and <i>XMPFilesCoverage</i>) which is a good start anyways for exploring. And turns out that our PDFs already have some workflow metadata in them. This is encouraging because the SDK allows apps to read and update existing XMP packets from files, though not to write new packets into files (as far as I understand).

<span >I thought I would take this opportunity anyway to:

1. <span >See what XMP metadata terms we might consider adding

• <span >Try and add these to existing XMP packets<span >Ugly details are presented below, but by updating the XMP packet metadata in one of our PDFs (<i>Nature 445, 37 (2007), C.J. Hogan</i>) we can teach Acrobat Reader to read - see the “before” (<a href="https://web.archive.org/web/20130815224916/http://nurture.nature.com/">PDF here</a>) and “after” (<a href="https://web.archive.org/web/20130815224916/http://nurture.nature.com/">PDF here</a>) screenshots in the figure.

  <span ><img src="/wp/blog/images/acrobats.png" alt="acrobats.png" width="583" height="466" />

  <span >Of course, this is really about much more than getting Adobe apps to read/write metadata. It’s about using XMP as a standard platform for embedding metadata in digital assets for <i>third-party apps</i> to read/write. If we can put ID3 tags into our podcasts then why not XMP packets into other media?</p>

With these words: _“There was quite some interest in Linked Data at this year’s World Wide Web Conference (WWW2007). Therefore, Richard Cyganiak, Tom Heath and I decided to write a tutorial about how to publish Linked Data on the Web, so that interested people can find all relevant information, best practices and references in a single place.”_ Chris Bizer announces this draft How to Publish Linked Data on the Web. It’s a bright and breezy tutorial and useful (to me, anyway) for disclosing a couple of links: