Category: XMP

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 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?

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 organization to formalize a public spec.

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)

Continue reading “Hybrid”

Now, assuming XMP is a good idea – and I think on balance it is (as blogged here 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.
2. 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)

Continue reading “I Want My XMP”

Interesting post here 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.

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

Continue reading “XMP-Ville”

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

Continue reading “The Name’s The Thing”