Public comment period on the PRISM 2.0 draft ends Saturday (Sept. 15) ahead of next week’s WG meeting to review feedback and finalize the spec. (I put in some comments about XMP already.

( Update - 2007.09.15: Clean forgot to add in the rdf: namespace to the examples for xmp:Identifier in this post. I’ve now added in that namespace to the markup fragments listed.

You might have been wondering why I’ve been banging on about XMP here. Why the emphasis on one vendor technology on a blog focussed on an industry linking solution? Well, this post is an attempt to answer that. Four years ago we at Nature Publishing Group, along with a select few early adopters, started up our RSS news feeds.

Following on from the missing XMP Specification version number discussed in the previous post here below are listed some miscellaneous gripes I’ve got with XMP (on what otherwise is a very promising technology). I would be more than happy to be proved wrong on any of these points. 1. XMP version history and archive There doesn’t appear to be any XMP version history or archive hosted by Adobe as far as I can tell.

David Shorthouse and Rod Page have developed some great tools for linking references by tying together a number of services and using the Crossref OpenURL interface amongst other things.

Boy, was I ever so wrong! Contrary to what I said in yesterday’s post, the new PRISM 2.0 spec does support XMP value type mappings for its terms. See the table below which lists the PRISM basic vocabulary terms and the XMP value types.

Following on from yesterday’s post I just came across this very useful source of information on PDF/A: the PDF/A Conformance Center.

So, following up on my recent posts here on Metadata in PDFs (Strategies, Use Cases, Deployment), I finally came across PDF/A and PDF/X, two ISO standardized subsets of PDF. the former (ISO 19005-1:2005) for archiving and the latter (ISO 15929:2002, ISO 15930-1:2001, etc.) for prepress digital data exchange. Both formats share some common ground such as minimizing surprises between producer and consumer and keeping things open and predictable.

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

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.

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.