Blog

Now, assuming XMP is a good idea - and I think on balance it is (as blogged earlier), why are we not seeing any metadata published in scholarly media files? The only drawbacks that occur to me are:

1. Hard to write - it’s too damn difficult, no tools support, etc.

   • Hard to model - rigid, “simple” XMP data model, both complicates and constrains the RDF data model

(Continues)

Interesting post from Gunar Penikis of Adobe entitled “Permanent Metadata” Oct. ’04). 1. He talks about the the issues of embedding metadata in media and comes up with this: “It may be the case that metadata in the file evolves to become a “cache of convenience” with the authoritative information living on a web service. The web service model is designed to provide the authentication and permissions needed. The link between the two provided by unique IDs.

Last week, my colleague Ian Mulvany posted on Nascent an entry about NSF’s recent call for proposals on DataNet (aka “A Sustainable Digital Data Preservation and Access Network”). Peter Brantley, of DLF, has set up a public group DataNet on Nature Network where all are welcome to join in the discussion on what NSF effectively are viewing as the challenge of dealing with “big data”. As Ian notes in a mail to me:

(Click image to enlarge.) Following up on previous posts on OTMI (the proposal from NPG for scholarly publishers to syndicate their full text to drive text-mining applications), Fabien Campagne from Cornell, a long-time OTMI supporter, has created an OTMI-driven search engine (based on his Twease work). This may be the first publicly accessible OTMI-based service. It currently only contains NPG content from the OTMI archive online - some 2 years worth of Nature and four other titles.

Just noticed that there is now (as of last month) a blog for Mars (“Mars: Comments on PDF, Acrobat, XML, and the Mars file format”). See this from the initial post: “The Mars Project at Adobe is aimed at creating an XML representation for PDF documents. We use a component-based model for representing different aspects of the document and we use the Universal Container Format (a Zip-based packaging format) to hold the pieces.

This This was just sent out to the DC-GENERAL mailing list about the new DCMI Community for Scholarly Communications. As Julie Allinson says: “The aim of the group is to provide a central place for individuals and organisations to exchange information, knowledge and general discussion on issues relating to using Dublin Core for describing items of ‘scholarly communications’, be they research papers, conference presentations, images, data objects. With digital repositories of scholarly materials increasingly being established across the world, this group would like to offer a home for exploring the metadata issues faced.

Was reminded to blog about this after reading Lorcan’s post on the Names Project being run by JISC. From the blurb: _“The project is going to scope the requirements of UK institutional and subject repositories for a service that will reliably and uniquely identify names of individuals and institutions. It will then go on to develop a prototype service which will test the various processes involved. This will include determining the data format, setting up an appropriate database, mapping data from different sources, populating the database with records and testing the use of the data.

The InChI (International Chemical Identifier from IUPAC) has been blogged earlier here. RSC have especially taken this on board in their Project Prospect and now routinely syndicate InChI identifiers in their RSS feeds as blogged here. As reported variously last month (see here for one such review) IUPAC have now released a new (1.02beta) version of their software which allows hashed versions (fixed length 25-character) of the InChI, so-called InChIKey’s, to be generated which are much more search engine friendly.

Oh dear. Yesterday’s post “Using ISO URNs” was way off the mark. I don’t know. I thought that walk after lunch had cleared my mind. But apparently not. I guess I was fixing on eyeballing the result in RDF/N3 rather than the logic to arrive at that result.

(Continues.)

(Update - 2007.10.02: Just realized that there were some serious flaws in the post below regarding publication and form of namespace URIs which I’ve now addressed in a subsequent post here.)

By way of experimenting with a use case for ISO URNs, below is a listing of the document metadata for an arbitrary PDF. (You can judge for yourselves whether the metadata disclosed here is sufficient to describe the document.) Here, the metadata is taken from the information dictionary and from the document metadata stream (XMP packet).

The metadata is expressed in RDF/N3. That may not be a surprise for the XMP packet which is serialized in RDF/XML, as it’s just a hop, skip and a jump to render it as RDF/N3 with properties taken from schema whose namespaces are identified by URI. What may be more unusual is to see the document information dictionary metadata (the “normal” metadata in a PDF) rendered as RDF/N3 since the information dictionary is not nodelled on RDF, not expressed in XML, and not namespaced. Here, in addition to the trusty HTTP URI scheme, I’ve made use of two particular URI schemes: “iso:” URN namespaces, and “data:” URIs.

(Continues.)