XMP on Crossref

XMP in RSC PDFs

Crossref — Tue, 03 Aug 2010 00:00:00 +0000

Just a quick heads-up to say that we’ve had a go at incorporating InChIs and ontology terms into our PDFs with XMP. There isn’t a lot of room in an XMP packet so we’ve had to be a bit particular about what we include.

InChIs: the bigger the molecule the longer the InChI, so we’ve standardized on the fixed-length InChIKey. This doesn’t mean anything on its own, so we’ve gone the Semantic Web route of including an InChI resolver HTTP URI. Alternatively you can extract the InChIKeys with a regular expression.
Ontology terms: we’re using HTTP URIs again and pointing to either Open Biomedical Ontology URIs (biology, biomedicine; slashy) or RSC ontology terms (chemistry; hashy). Often the OBO URIs resolve to a specific web page, but for the moment the RSC URIs just point to a large OWL file. Slashy URIs are quite a bit more involved so we’ll have to see what the demand is like.

There’s only about 4K to play with, so it’s only ever going to be a best-of. More detailed article metadata has to go in either a sidecar file, as Tony has pointed out before, or ideally on the article landing page. The example files are here and I’ve posted something with a different slant on the RSC technical blog.

Add Crossref metadata to PDFs using XMP

Geoffrey Bilder — Wed, 09 Dec 2009 00:00:00 +0000

In order to encourage publishers and other content producers to embed metadata into their PDFs, we have released an experimental tool called “pdfmark”, This open source tool allows you to add XMP metadata to a PDF. What’s really cool, is that if you give the tool a Crossref DOI, it will lookup the metadata in Crossref and then apply said metadata to the PDF. More detail can be found on the pdfmark page on the Crossref Labs site. The usual weasels words and excuses about “experiments” apply.

XMP Primer

Tony Hammond — Wed, 10 Jun 2009 00:00:00 +0000

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.

XMP Library for Flash

Tony Hammond — Fri, 16 Jan 2009 00:00:00 +0000

Update about new XMP Library from Adobe Labs:

“The new Adobe XMP Library for ActionScript is now available for download on Adobe Labs. Adobe Extensible Metadata Platform (XMP) is a labeling technology that allows you to embed data about a file, known as metadata, into the file itself. XMP is an open technology based on RDF and RDF/XML. With this new library you can read existing XMP metadata from Flash based file formats via the Adobe Flash Player.“

Any volunteers?

Xmas XMP

Tony Hammond — Fri, 19 Dec 2008 00:00:00 +0000

Well, as I blogged on our web publishing blog Nascent we just went live with XMP labelling on Nature in yesterday’s double issue. We will be adding XMP to all new issues of Nature as well as rolling out across all our other titles in the next few weeks and months.

The screenshots below from Acrobat (File > Properties, CMD-D / CTL-D) show what the user might see both with (bottom-left) and without (top-right) semantic markup.

As to the actual contents of the metadata record, see this sample I posted to the semantic web list.

XMP Marches On

Tony Hammond — Mon, 20 Oct 2008 00:00:00 +0000

For those who may be interested in the progress of XMP, Adobe’s Gunar Penikis has just announced ¹ two new releases of XMP SDKs: XMP Toolkit 4.4 (with support for new file formats), and FileInfo SDK (for customizing CS4 UIs). More importantly, though, may be the new edition of the XMP spec - see here, which is bumped from a modest 112 page document to a 3-parter at 199 pages.

Looks to be quite a thorough spec bar one telling particular: there is no version number and no date! The previous version was likewise unnumbered though at least dated as “September 2005”. Btw, I’m not sure of there is any archive of XMP specs being maintained by Adobe. At least, I’m not aware of any page with that information. Perhaps we can refer to our earlier call to have XMP turned over to a standards organisation to formalize a public spec.

Update Aug 2022: the announcement blog post mentioned above was previously at blogs.adobe.com/gunar/2008/10/new_xmp_sdks_released.html but is no longer live. ↩︎

Hybrid

Tony Hammond — Wed, 17 Oct 2007 00:00:00 +0000

So, back on the old XMP tack. The simple vision from the XMP spec is that XMP packets are embedded in media files and transported along with them - and as such are relatively self-contained units, see Fig 1.

Fig. 1 - Media files with fully encapsulated descriptions.

But this is too simple. Some preliminary considerations lead us to to see why we might want to reference additional (i.e. external) sources of metadata from the original packet:

PDFs: PDFs are tightly structured and as such it can be difficult to write a new packet, or to update an existing packet. One solution proposed earlier is to embed a minimal packet which could then reference a more complete description in a standalone packet. (And in turn this standalone packet could reference additional sources of metadata.)
Images: While considerably simpler to write into web-delivery image formats (e.g. JPEG, GIF, PNG), it is the case that metadata pertinent to the image only is likely to be embedded. Also, of interest is the work from which the image is derived which is most likely to be presented externally to the image as a standalone document. (And in turn this standalone packet could reference additional sources of metadata.)

(Continues)

Thus the two cases - PDF documents and images - are not dissimilar. Fig. 2 shows a “wall-to-wall” XMP architecture whereby the standalone metadata documents for the work and for additional sources are expressed in XMP.

Fig. 2 - XMP “wall-to-wall” architecture.

Fig. 3 presents a variant on this theme whereby additional sources are presented as generic RDF/XML. (In the most general case only RDF need be assumed, the serialization being a matter of choice.)

Fig. 3 - XMP authority metadata with references to generic RDF/XML

And finally, Fig. 4 shows the most extreme case whereby XMP is used merely to “bootstrap” RDF descriptions for media objects. The XMP is used to embed a minimal description into the media file with references to a fuller work description and to additional sources which are presented as generic RDF/XML. That is, the metadata descriptions use generic RDF/XML exclusively and only resort to the idiomatic RDF/XML employed by XMP for embedding descriptions into binary structures.

Fig. 4 - XMP “bootstrap” only - metadata descriptions proper are generic RDF/XML.

If I were to choose I might opt for the scenario presented in Fig. 3, but the scenarios in both Figs. 2 and 4 leave room for thought. Such a hybrid solution may be a means to bridge two different concerns:

Generic RDF/XML for unconstrained descriptions.
- Idiomatic RDF/XML (aka XMP) for embedding the head of a metadata trail.
I’m not sure that I see the XMP spec loosening up any time soon to accommodate generic RDF/XML. Nor, likewise is XMP likely to be provided (or even tolerated) down the metadata trail. And the metadata is not going to be fully encapsulated within a media file. The media file will merely encapsulate the head of the metadata trail.

I Want My XMP

Tony Hammond — Sat, 13 Oct 2007 00:00:00 +0000

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:

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

Well, I don’t really believe that 1) is too difficult to overcome. A little focus and ingenuity should do the trick. I do, however, think 2) is just a crazy straitjacket that Adobe is forcing us all to wear but if we have to live with that then so be it. Better in Bedlam than without. (RSS 1.0 wasn’t so much better but allowed us to do some useful things. And that came from the RDF community itself.) We could argue this till the cows come home but I don’t see any chance of any change any time soon.

(Continues)

So, putting the RDF issue aside for the moment (as if RDF didn’t have problems of its own - XML, URI, etc.) let’s just look at the options for writing the stuff. (Btw, I’m not referencing any tools or toolkits. This is just in the round.) There are various means of publishing metadata in XMP:

 **Sidecar**
: XMP can be produced as standalone files - see [XMP Specification, (Sept. ’05)][3], p. 36. (These are called &#8220;sidecar&#8221; files if the file has the same name as the main document and is in the same directory.) The only things needed to produce these files are a text editor and a good grasp of the XMP serialization. A template will do for that. The main problem with a standalone file is that it does not travel with the media file and so risks being left behind.
Worth a note here. Not standalone as such but the [Mars][4] format (the draft XML formalization for PDF) discloses its metadata in an independent XMP file &#8220;metadata.xml&#8221; under the &#8220;META-INF/&#8221; directory. For distribution the whole directory structure is packaged up as a zip file and so the XMP is embedded in a &#8220;.mars&#8221; file, but accessed directly from the zip file or from the unpackaged directory the XMP can be manipulated just like any other XML document.
**Embedded**
: This is the normal means of distributing XMP - embedded within the media file. Some graphics formats are essentially linear (JPEG, PNG, GIF) and it is relatively straightforward to add in an XMP packet. Other formats (PDF, TIFF) have internal cross-referencing and are more difficult to deal with.
**Embedded + Sidecar**
: One possible method for dealing with the difficulty of writing XMP is to note that some media (especially PDFs) already have embedded XMP packets. As noted earlier, much if not all of the metadata in these XMP packets will be workflow-related and thus dispensible for final-form products where authority work-related metadata is desired. These packets may, or may not, be writeable and thus include additional padding whitespace. Even for read-only packets there is much (if not all) that can be discarded and also sometimes unnecesary bulk (e.g. default namespace declarations which are never used). _The bottom line is that any legacy XMP packet may typically be 2-3K in size and, just as in transplanting a cell nucleus, the XMP packet innards can be deftly substituted with a minimal XMP packet content, say 1K in size, which would be guaranteed to fit with suitable padding._ A packet that size would be sufficient to provide at minimum for a DOI and for a reference to additional metadata, e.g. a more complete standalone XMP packet. The two forms can coexist.
The third way option here allows embedding a minimal XMP packet into &#8220;difficult&#8221; packaging structures while pointing out to a fully-formed XMP packet. The &#8220;simple&#8221; packaging structures may both include a fully-formed XMP packet while also possibly referencing extended metadata sources as per my previous post [here][4].

Metadata - For the Record

Tony Hammond — Sat, 13 Oct 2007 00:00:00 +0000

Interesting post from Gunar Penikis of Adobe entitled “Permanent Metadata” Oct. ’04). ¹.

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. In fact, unique IDs are already created by Adobe applications and stored in the XMP - that is what the XMP Media Management properties are all about.”

An intriguing idea. Of course, Gunar’s (and Adobe’s) preoccupations with metadata revolve mainly around document workflow whereas, at least as things stand currently, scholarly publisher concerns are mainly with the dissemination of media in final form. Hence some differences in thinking:

Subject

As just noted Adobe are more interested in workflow than in work. Scholarly articles are rich in descriptive metadata about the work itself and have a well-developed ctation model. Academic interest is in the intellectual content rather than the vehicle used to carry and preserve that content - the file format.

Unique IDs

Workflow IDs are UUIDs which identify specific instances and expressions, but do not identify the abstract work. UUIDs provide a unique identifier but there is no central registry for such identifiers, hence they cannot be “looked up”. Crossref publishers should be concerned to associate closely the DOI for the underlying work with a given media file. That’s the identifier that this community is actively promoting.

Read/Write: Because of the focus on workflow, the XMP specification recommends that XMP packets be “writeable”, that is that they be marked as “writeable” and that they include padding whitespace which can accommodate updates without changing packet size. Publishers distributing final form documents are more likely to want to distribute “read-only” metadata which is authoritative and which describes the work, rather than the document format and workflow. Of course, this should not preclude additional sources of metadata which may be added “by reference” rather than “by value”. That is, a pointer to a web page (or service) may be sufficient to relate additional publisher terms and user annotations instead of embedding them directly in the file for various reasons: a) file integrity, b) limiting growth of file size, c) term authority, d) dynamic production (in forward time), and e) multiple sources.

Update Aug 2022: the blog post mentioned below was previously at blogs.adobe.com/gunar/2007/10/permanent_metadata.html but is no longer live. ↩︎

XMP-Ville

Tony Hammond — Tue, 25 Sep 2007 00:00:00 +0000

Been so busy looking into the technical details of XMP that I almost forgot to check out the current landcsape. Luckily I chanced on these articles by Ron Roszkiewicz for The Seybold Report (and apologies for lifting the title of this post from his last). The articles about XMP are well worth reading and chart the painful progress made to date:

The Brief Tortured Life of XMP (July ’05)
- [Thought Leaders Hammer out Metadata Standard] (April ’07)
  - [Metadata Persistence and “Save for Web…”] (July ’07)
  From the earlier characterization of XMP as “underachieving teenager” Roszkiewicz is cautiously optimistic that IDEAlliance’s XMP Open initiative (an initiative to advance XMP as an open industry specification) will help outreach and foster adoption of this fledgling technology.
  
  (Continues.)

There has been some activity here. Following on from an industry open day event last year:

 * [IDEAlliance XMP Open Day][5], New York, March ’06</ul>
there have been two metadata summits earlier this year co-sponsored by Adobe Systems and IDEAlliance:
* [Metadata Directions in Advertising and Branding][6], San Francisco, January ’07
* [Content Metadata Summit 1.1][7] New York, March ’07</ul>
Promising bestirrings. (And also with the recent public airing of the PRISM 2.0 draft with its support for XMP which was reviewed at the PRISM WG F2F last week for publication as a standard.) But generally the state of XMP-Ville at this time is rather sleepy. There’s not much by way of news on the [XMP Open][8] website. At least promise, if no promises.
Back to the articles. The really interesting thing of note (to me at any rate) in Roszkiewicz’s review of the last summit is the almost total absence of any mention of the Web. It is as if XMP users (both consumers and providers) would be content to play within the walled garden of the CS3 product portfolio. I don’t get that. The Web changes everything.
Although XMP maps its native data model to RDF (and RDF is an inherently open technology allowing arbitrary schemas to be mixed at will), XMP betrays its application roots by seeming to want to impose some kind of veto on the schemas to be used. Or rather, how they are to be used. It also seems to be all fussed up by centralized notions such as a cross-mapping schema registry. (As if that were part of its remit.)
As Roszkiewicz notes:
> _&#8220;The consortia [IDEAlliance and the stakeholders] will have ownership responsibility for name space registry, cross-map definition and support, standards group outreach and coordination, compliance certification and logo and the “XMP Open” brand.&#8221;_
And elsewhere:
> _&#8220;So while the standard for XMP might be defined, the data that will be fed into files is not, for want of an IDEAlliance-like standards management body to filter and rationalize the many [schema] into a few.&#8221;_
And then more worryingly, this:
> _&#8220;That schema should be managed by a government agency such as the Library of Congress which could manage the dictionaries and schema, certify them, register the namespace and provide a centralized location to distribute them.&#8221;_
Well, I don’t see what this matters to the core technology of XMP which is just a specification for the sneaking in of an XML document into arbitrary media files. And the use of RDF/XML would seem to be a further indication that XMP is to be independent of the schema used. The use of both RDF plus XML technologies should allow XMP to present itself as a framework or &#8220;platform&#8221; for metadata exchange and to get out of the way of what is actually carried by the XMP packets. App neutrality, if you will.
Again the notion of Web as just an alternate channel is apparent in the third of the articles where Roszkiewicz talks about the Device Central tool which allows a user of a CS3 product to &#8220;Save for Web or Devices&#8230;&#8221;. This article talks about the clumsy handling of metadata in such device saves, whereby the packet may be abbreviated - and metadata terms dropped - when printing to small footprint devices. Not a feature to be retained for too long, I would hope.
So, where are we currently with XMP? According to Roszkiewicz:
> _&#8220;As the developer of a suite of applications that relies on XMP as the vehicle for managing metadata, Adobe has too much invested in its development to allow any substantive changes by outsiders. So “open” primarily will mean open to suggestions, with an official channel in place to process them.&#8221;_
And as to that channel?
> _&#8220;As the principal conduit to Adobe for changes to XMP, IDEAlliance will act as a gateway and support organisation to the user community - a role for which it is well-suited. &#8230; As a sponsor-supported, not-for-profit organisation, IDEAlliance can serve as a credible buffer for Adobe to the user community and synchronize and standardize third-party development efforts.&#8221;_
And goes on:
> _&#8220;The principal unanswered questions at this point are: Will the stakeholders represent all of the key industries; will Adobe provide timely support for considering user input and updating the XMP Toolkit; and can Adobe, IDEAlliance and IDEAlliance workgroups manage all of the responsibilities that will fall upon them when the deal is struck. The hand-over doesn’t seem to have taken place yet, and we are still examining the scope and feasibility of the proposal.&#8221;_
It seems to me that Adobe is the party girl, IDEAlliance is the special guest, and Crossref publishers are the neighbourly gatecrashers who want to play with the toys. And not perhaps too nicely neither. I just hope that the toys aren’t taken away from us. They’re too much fun.
Ironic really that we’re on the outside of this since scholarly publishers have a very clearcut grasp of what to do with metadata and a ready application in terms of citation linking. XMP is worth it.

The Name’s The Thing

Tony Hammond — Thu, 20 Sep 2007 00:00:00 +0000

I’m always curious about names and where they come from and what they mean. Hence, my interest was aroused with the constant references to “XAP” in XMP. As the XMP Specification (Sept. 2005) says:

“NOTE: The string “XAP” or “xap” appears in some namespaces, keywords, and related names in this document and in stored XMP data. It reflects an early internal code name for XMP; the names have been preserved for compatibility purposes.”

Actually, it occurs in most of the core namespaces: XAP, rather than XMP.

(Continues.)

An earlier XMP Specification from 2001 (v. 1.5 - and see here for an earlier post of mine about XMP’s missing version numbers, and here about Adobe’s lack of archiving for XMP specifications) says almost the same thing:

“NOTE: Many namespaces, keywords, and related names in this document are prefaced with the string “XAP”, which was an early internal code name for XMP metadata. Because the Acrobat 5.0 product shipped using those names and keywords, they were retained for compatibility purposes.”

So, there’s no indication in either of these specifications as to what the original name signified.

But then I turned up this issue in the Adobe Developer Knowledgebase:

_“Known Issue: The metadate framework name was changed from XAP to XMP

Summary

XAP (Extensible Authoring Publishing) was an early internal code name for XMP (Extensible Metadata Platform).

Issue

Why are many namespaces, keywords, data structures, and related names in the documents and XMP toolkit code prefaced with the string “XAP” rather than “XMP”?

Solution

XAP (Extensible Authoring and Publishing) was an early internal code name for XMP (Extensible Metadata Platform) metadata. Because Acrobat 5.0 used those names, they were retained for compatibility purposes. XMP is the formal name used the framework specification.”_

Aha! Now it’s all clear. And now I’m also wondering if this original name still reflects Adobe’s thinking on the purpose of XMP that it be primarily an authoring utility rather than a workflow utility. That is, is Adobe’s XMP more geared to individual authors of Adobe’s Creative Suite products entering in metadata by hand as part of the authoring act, rather than as a batch entry process within an automated publishing workflow? The emphasis that Adobe put on Custom File Info panels for their CS products would seem to foster the view that Adobe see XMP as an interactive authoring device for adding metadata. But what about the publishers and their workflows? The SDK is a rather poor effort at garnering any widespread support of XMP within the publishing industry.

Marking up DOI

Tony Hammond — Tue, 11 Sep 2007 00:00:00 +0000

(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. Also added in a comment here which shows the example in RDF/XML for those who may prefer that over RDF/N3.)

So, as a preliminary to reviewing how a fuller metadata description of a Crossref resource may best be fitted into an XMP packet for embedding into a PDF, let’s just consider how a DOI can be embedded into XMP. And since it’s so much clearer to read let’s just conduct this analysis using RDF/N3. (Life is too short to be spent reading RDF/XML or C++ code. :~)

(And further to Chris Shillum’s comment [(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. Also added in a comment here which shows the example in RDF/XML for those who may prefer that over RDF/N3.)

(And further to Chris Shillum’s comment]2 on my earlier post Metadata in PDF: 2. Use Cases where he notes that Elsevier are looking to upgrade their markup of DOI in PDF to use XMP, I’m really hoping that Elsevier may have something to bring to the party and share with us. A consensus rendering of DOI within XMP is going to be of benefit to all.)

(Continues.)

Within an XMP packet our first idea might be to include the DOI using the Dublin Core (DC) schema element dc:identifier in minimalist fashion:

@prefix dc: <http://purl.org/dc/elements/1.1/> .
<> dc:identifier "10.1038/nrg2158" .

This simply says that the current document (denoted by the empty URI “<>“) has a string property “10.1038/nrg2158” which is of type identifier from the dc (or Dublin Core) schema which is identified by the URI http://purl.org/dc/elements/1.1/.

Now, since this is just a DOI and the wider public cannot be expected to know about DOIs, it would surely be better to present the DOI in URI form (doi:) as

@prefix dc: <http://purl.org/dc/elements/1.1/> .
<> dc:identifier "doi:10.1038/nrg2158" .

or, using a registered URI form (info:) as

@prefix dc: <http://purl.org/dc/elements/1.1/> .
<> dc:identifier "info:doi/10.1038/nrg2158" .

Aside: This shows up a limitation of XMP where the DC schema property value for dc:identifier is fixed as type Text. The natural way to express the above in RDF/N3 would be as:

@prefix dc: <http://purl.org/dc/elements/1.1/> .
<> dc:identifier <info:doi/10.1038/nrg2158> .

which says that the value is a URI (type URI in XMP terms), not a string (type Text in XMP terms). We either have to flout the XMP specification or else live with this restriction. We’ll opt for the latter for now.

But, the XMP Spec deprecates the use of dc:identifier since the context is not specific. (Note that that’s what was just discussed above. The limitation is built into XMP which builds on RDF but does not fully endorse the RDF world view.) Instead the XMP Spec recommends using xmp:Identifier since the context can be set using a qualified property as:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xmp: <http://ns.adobe.com/xap/1.0/> .
@prefix xmpidq: <http://ns.adobe.com/xmp/Identifier/qual/1.0/> .
<> xmp:Identifier [
a rdf:Bag;
rdf:_1 [
xmpidq:Scheme "DOI";
rdf:value "10.1038/nrg2158" ] ] .

This says the string “10.1038/nrg2158” belongs to the scheme “DOI”.

Here we have used the scheme “DOI” and, as noted above, for wider recognition it would be better to employ one of the URI forms, e.g.

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xmp: <http://ns.adobe.com/xap/1.0/> .
@prefix xmpidq: <http://ns.adobe.com/xmp/Identifier/qual/1.0/> .
<> xmp:Identifier [
a rdf:Bag;
rdf:_1 [
xmpidq:Scheme "URI";
rdf:value "doi:10.1038/nrg2158" ] ] .

This says the string “doi:10.1038/nrg2158”belongs to the scheme “URI”.

But this is the unregistered URI form (doi:), so should we be using instead the registered form (info:)? Well, turns out that this construct for xmp:Identifier is an rdf:Bag so we can include more than one term. How about using this construct then:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xmp: <http://ns.adobe.com/xap/1.0/> .
@prefix xmpidq: <http://ns.adobe.com/xmp/Identifier/qual/1.0/> .
<> xmp:Identifier [
a rdf:Bag;
rdf:_1 [
xmpidq:Scheme "URI";
rdf:value "info:doi/10.1038/nrg2158" ];
rdf:_2 [
xmpidq:Scheme "URI";
rdf:value "doi:10.1038/nrg2158" ] ] .

Now we’ve got both forms, which is fair enough since these are equivalent. In RDF terms we can make the statement that:

doi:10.1038/nrg2158 owl:sameAs info:doi10.1038/nrg2158 .

which asserts that the two URIs are equivalent and that they reference the same resource.

So, what if we want to include a native DOI without the URI garb? We can easily do that:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xmp: <http://ns.adobe.com/xap/1.0/> .
@prefix xmpidq: <http://ns.adobe.com/xmp/Identifier/qual/1.0/> .
<> xmp:Identifier [
a rdf:Bag;
rdf:_1 [
xmpidq:Scheme "URI";
rdf:value "info:doi/10.1038/nrg2158" ];
rdf:_2 [
xmpidq:Scheme "URI";
rdf:value "doi:10.1038/nrg2158" ];
rdf:_3 [
xmpidq:Scheme "DOI";
rdf:value "10.1038/nrg2158" ] ] .

OK, that takes care of the XMP direction to use xmp:Identifier, but, while deprecated by XMP, we note that back in the real world folks will be looking at the DC elements which is the schema with the greatest purchase. So, why not also add in a dc:identifier element such as would be used typically for DOI in citations. How about this:

@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xmp: <http://ns.adobe.com/xap/1.0/> .
@prefix xmpidq: <http://ns.adobe.com/xmp/Identifier/qual/1.0/> .
<> xmp:Identifier [
a rdf:Bag;
rdf:_1 [
xmpidq:Scheme "URI";
rdf:value "info:doi/10.1038/nrg2158" ];
rdf:_2 [
xmpidq:Scheme "URI";
rdf:value "doi:10.1038/nrg2158" ];
rdf:_3 [
xmpidq:Scheme "DOI";
rdf:value "10.1038/nrg2158" ] ];
dc:identifier "doi:10.1038/nrg2158" .

Right, so we’ve taken care of the identfiers. But maybe there’s something missing? There’s no link to the DOI proxy. For widest applicability we should not assume prior knowledge of the DOI system. Perhaps we could include this link using the property dc:relation? Seems feasible though would really like to get some feedback on this. Any ideas?

So here, then, is a fairly full and complete expression of DOI within the XMP packet.

@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xmp: <http://ns.adobe.com/xap/1.0/> .
@prefix xmpidq: <http://ns.adobe.com/xmp/Identifier/qual/1.0/> .
<> xmp:Identifier [
a rdf:Bag;
rdf:_1 [
xmpidq:Scheme "URI";
rdf:value "info:doi/10.1038/nrg2158" ];
rdf:_2 [
xmpidq:Scheme "URI";
rdf:value "doi:10.1038/nrg2158" ];
rdf:_3 [
xmpidq:Scheme "DOI";
rdf:value "10.1038/nrg2158" ] ];
dc:identifier "doi:10.1038/nrg2158";
dc:relation "http://dx.doi.org.pluma.sjfc.edu/10.1038/nrg2158" .

Ta-da!

(Of course, this is all premised on having freedom in writing out the XMP packet. If one is dependent on commercial applications to write out the packet then things may be different. Actually, they will be very different. They may not even be workable.)

Feedback would be very welcome.

W5M0MpCehiHzreSzNTczkc9d

Tony Hammond — Mon, 10 Sep 2007 00:00:00 +0000

What on earth can this string mean: ‘W5M0MpCehiHzreSzNTczkc9d’? This occurs in the XMP packet header:

Well from the XMP Specification (September 2005) which is available here (PDF) there is this text:

“The required id attribute must follow begin. For all packets defined by this version of the syntax, the value of id is the following string: W5M0MpCehiHzreSzNTczkc9d”

(See: 3 XMP Storage Model / XMP Packet Wrapper / Header / Attribute: id)

OK, so it’s no big deal to cut and paste that string, it’s just mighty curious why this cryptic key is needed in an open specification, especially since (contrary to what might be implied by the text) it doesn’t seem to vary with version. (Or hasn’t yet, at any rate - more below.)

Right, so now we get down to it. Just what is the version number of the current XMP Specification anyways? I couldn’t for the life of me find one. (Note that I am talking about the XMP Specification itself and not the XMP Toolkit which is versioned at 4.1.1.) I am assuming that I have the latest version, else I really don’t know where else to look. This link

http://www.adobe.com/products/xmp/

leads me to

http://www.adobe.com/devnet/xmp/

which leads me to

https://web.archive.org/web/20210811233806/https://www.adobe.com/devnet/xmp.html

which by the way is also the same version that ships with the SDK.

I do know that there was a Version 1.5 published in September 14, 2001. (You can see that this is a fairly slow changing technology - the published spec is from 2 years back, and an earlier - the earlier? - version is from 6 years back). Note that this version has a version number (1.5) but still uses the same XMP packer header ‘id’ attribute.

No good, by the way, peeking inside the XMP of the XMP Spec either. Here’s a dump (using the DumpMainXMP utility with the SDK):

% xmpd xmp_spec.xmp
 
 
// -----------------------------------
// Dumping main XMP for xmp_spec.xmp :
 
File info : format = " ", handler flags = 00000260
Packet info : offset = 0, length = 4051
 
Initial XMP from xmp_spec.xmp
Dumping XMPMeta object "" (0x0)
 
http://ns.adobe.com/pdf/1.3/ pdf: (0x80000000 : schema)
pdf:Producer = "Acrobat Distiller 7.0 (Windows)"
pdf:Copyright = "2005 Adobe Systems Inc."
pdf:Keywords = "XMP metadata schema XML RDF"
 
http://ns.adobe.com/xap/1.0/ xap: (0x80000000 : schema)
xap:CreateDate = "2005-09-23T15:19:07Z"
xap:ModifyDate = "2005-09-23T15:19:07Z"
xap:CreatorTool = "FrameMaker 7.1"
 
http://purl.org/dc/elements/1.1/ dc: (0x80000000 : schema)
dc:description (0x1E00 : isLangAlt isAlt isOrdered isArray)
[1] = "XMP metadata specification" (0x50 : hasLang hasQual)
? xml:lang = "x-default" (0x20 : isQual)
dc:creator (0x600 : isOrdered isArray)
[1] = "Adobe Developer Technologies"
dc:title (0x1E00 : isLangAlt isAlt isOrdered isArray)
[1] = "Extensible Metadata Platform (XMP) Specification" (0x50 : hasLang hasQual)
? xml:lang = "x-default" (0x20 : isQual)
dc:format = "application/pdf"
 
http://ns.adobe.com/pdfx/1.3/ pdfx: (0x80000000 : schema)
pdfx:Copyright = "2005 Adobe Systems Inc."
 
http://ns.adobe.com/xap/1.0/mm/ xapMM: (0x80000000 : schema)
xapMM:InstanceID = "uuid:99b91701-a78b-4652-84e5-6bccaeb7534e"
xapMM:DocumentID = "uuid:374ea24b-3931-4b83-944d-5b9daa42277e"

or in more readable form (courtesy of ‘cwm‘):

% xmp2n3q docs/XMP-Specification.pdf
#Processed by Id: cwm.py,v 1.164 2004/10/28 17:41:59 timbl Exp
# using base file:/Users/tony/Sources/Build/XMP-SDK/
 
# Notation3 generation by
# notation3.py,v 1.166 2004/10/28 17:41:59 timbl Exp
 
# Base was: file:/Users/tony/Sources/Build/XMP-SDK/
 
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix pdf: <http://ns.adobe.com/pdf/1.3/> .
@prefix pdfx: <http://ns.adobe.com/pdfx/1.3/> .
@prefix xmp: <http://ns.adobe.com/xap/1.0/> .
@prefix xmpMM: <http://ns.adobe.com/xap/1.0/mm/> .
 
<> pdf:Copyright "2005 Adobe Systems Inc.";
pdf:Keywords "XMP metadata schema XML RDF";
pdf:Producer "Acrobat Distiller 7.0 (Windows)";
pdfx:Copyright "2005 Adobe Systems Inc.";
xmp:CreateDate "2005-09-23T15:19:07Z";
xmp:CreatorTool "FrameMaker 7.1";
xmp:ModifyDate "2005-09-23T15:19:07Z";
xmpMM:DocumentID "uuid:374ea24b-3931-4b83-944d-5b9daa42277e";
xmpMM:InstanceID "uuid:99b91701-a78b-4652-84e5-6bccaeb7534e";
dc:creator [
a rdf:Seq;
rdf:_1 "Adobe Developer Technologies" ];
dc:description [
a rdf:Alt;
rdf:_1 "XMP metadata specification"@x-default ];
dc:format "application/pdf";
dc:title [
a rdf:Alt;
rdf:_1 "Extensible Metadata Platform (XMP) Specification"@x-default ] .
 
#ENDS

So, just what then is the version number of the XMP Specification which the id string ‘W5M0MpCehiHzreSzNTczkc9d’ is marking?

XMP - Some Other Gripes

Tony Hammond — Mon, 10 Sep 2007 00:00:00 +0000

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.

2. Unpublished schemas

Also there is nothing published - outside the XMP Spec itself - on the core schemas used by XMP. There’s nothing to be gleaned from the namespace URIs used. The Adobe namespaces, e.g.

https://web.archive.org/web/20070929102516/http://www.adobe.com/products/xmp/ (listed in XMP Spec)

https://web.archive.org/web/20070929102516/http://www.adobe.com/products/xmp/ (not listed in XMP Spec)

seem to all resolve to this page

http://www.adobe.com/products/xmp/.

So, that can leave us with undocumented terms (e.g. ‘xmpMM:Manifest‘ used by Adobe InDesign CS2 4.0.5) from documented schemas and also undocumented schemas (e.g. ‘pdfx‘).

3. UUID

Note also that many Adobe apps do not use the URN syntax for ‘uuid:‘. The XMP Spec also has this to say:

_“There is no formal standard for URIs that are based on an abstract UUID. The following proposal may be relevant:

https://datatracker.ietf.org/doc/rfc4122/;

(see: 3 XMP Storage Model / Serializing XMP / rdf:Description elements / rdf:about attribute)”

I guess the XMP Spec (Sept. ’05) had just been bedded down more or less when the URN namespace for ‘uuid:‘ was published as RFC 4122 in July ’05.

4. RDF/XML serialization

The biggie.

XMP schemas specify fixed property value types in RDF/XML, i.e. they specify a fixed profile of RDF/XML instead of generic RDF/XML. This has been commented on recently by myself on the semantic-web list, and also here by Bruce D’Arcus speaking about OpenDocument, and here by Mike Linksvayer speaking for CC.

This profiling of RDF/XML leads to real problems. For example, Adobe have defined a Dublin Core (DC) schema which lists the property value types that DC values can assume in an XMP serialization. Meantime, the PRISM 2.0 draft spec defines an incompatible mapping of DC terms to XMP property values. Since both schemas would make use of the same DC namespace (though PRISM haven’t actually specified a DC namespace for use with XMP but do use elsewhere the regular DC namespace) this isn’t going to work. I did supply some feedback on this to the PRISM WG but have heard nothing back from them. So, PRISM XMP looks uncertain at this time. Which, for us, must be a shame.