6 thoughts on “The Second Wave”

  1. Tony —
    I’m having a difficult time fathoming the depth of the possibilities for XMP. In particular, I can’t place it in any consistent context or get an accurate description of what it is/does. The Adobe site isn’t much help — it talks about how XMP is great inside Adobe applications, but it seems that you have wider expectations and desires.
    In short, I guess: I don’t have an answer to the question “Why should I care about XMP?”

  2. Tony – thanks for all the practical info on XMP. I take your point that CrossRef hasn’t provided any guidelines in this area (“I don’t recall seeing any guidelines from CrossRef as to how machine readable metadata (even markup for the DOI itself) may be embedded within HTML pages, rather than on HTML pages for human readers.”)
    I think there could be huge value in having standards on embedding machine readable metadata in HTML. This could vastly improve search engine indexing, for one.
    So – we’ll think about what CrossRef should do about this – any thoughts from our member publishers about this?

  3. Peter:
    I had hoped that my post was a credible attempt to address the question of “Why XMP?”. Maybe I missed something.
    According to the XMP spec XMP provides for three things: a data model, a storage model, and schemas. The major technology contribution is the second – the storage model. To define a means for embedding XML packets within arbitrary binary and teext file formats is a key step forward. This means that metadata lodged in media files is done so in an “open” fashion and free of all the restrictions and impediments that other mechansims bring along: TIFF, EXIF, IPTC Headers, ICC Profiles, Photoshop, etc. XMP allows for a single means of emnedding metadata irrespective of file format and which can be manipulated with standard web-based tools (XML editors, and the like).
    The fact that XMP uses RDF/XML (more later) is also a major plus. RDF is an open data model which allows multiple data sources to be merged. The same cannot be said of generic namespaced XML. Different XML documents conform to differnet schemas and can not readily be merged. Because XML is more packaging and syntax than data model. (Unless you appeal to the Infoset which is a pretty low level and murky affair.) RDF/XML, on the other hand, uses XML as a carrier for data conforming to a model. An RDF parser can read RDF from multiple sources and multiple formats (XML, N3, RSS, JSON, SPARQL, etc) and abstract the data and fit it to the RDF data model. However, XMP defines only a subset of RDF proper and does not recognize some of the later constructs. It’s still RDF though.
    That’s good. But, where XMP realy screws up is the schemas which provide fossilized views of metadata schemas mapped to the RDF data model. Let’s consider the Dublin Core schema which XMP has stamped it’s imprint on. (Bit of a shame for those who would like to more meningfully describe objects with DC in XMP.) As a very simple example let’s consider the property “dc:identifier”. I may have an identifier which is a URI but I cannot express that within XMP’s definition of rthe DC schema. There it must forever be a string. I know what I want to do. I know what is right. But XMP won’t allow me to express this. Hard to see why really. Doesn’t impact on the XMP data model, nor the XMP storage model. It might impact on the XMP Toolkit (but who really cares about that) or on certain applications that make use of XMP. I don’t see why it should impact on XMP itself. Toolkit and apps are adjuncts.
    So, what do we have? We have a bastardized version of RDF (represented in RDF/XML) which can be fitted into arbitrary file formats. OK, so I think there’s still a lot of mileage in that. And as I tried to make clear, I would see that as being not dissimlar from the case of RSS 1.0 which itself is a bastardized version of RDF (represented in RSS). Still might useful despite the handicaps.
    Seems to me there are a number of options:

    • Ignore XMP – it’s not perfect
    • Change XMP – hard to see in short term
    • Flout XMP – ignore the schema restrictions
    • Embrace XMP – use it for what it can do

    We had some similar issues with RSS 1.0 (e.g. RSS 1.0 proscribes repeated prroperties which we chose to ignore for our dc:creator fields). At the end of the day, the issue is one of prgamatics. To me it seems very useful.

  4. Ah, now this is the key point I think I was missing:

    To define a means for embedding XML packets within arbitrary binary and text file formats is a key step forward. This means that metadata lodged in media files is done so in an “open” fashion and free of all the restrictions and impediments that other mechanisms bring along…

    Inclusion of metadata into arbitrary files is a big deal. I redoubled my efforts and finally found the XMP Specification (XMPSpecification.pdf, 948K), so I’ll take a deeper look. I knew about embedding XMP into JPEG2000 (which is easy given its file format’s run-length encoding and provision for arbitrary content ‘boxes’), but seeing how they work with PNGs, JPEGs, and other file formats should be instructive.
    Thanks for the additional discussion points!

  5. Hi Ed:
    Just to be clear, I’ve been talking about Adobe’s XMP (Extensible Metadata Platform), not XMPP (Extensible Messaging and Presence Protocol). The description technology not the messaging protocol of which I remain cheerfully ignorant.
    CrossRef interest should be in the embedding of DOIs into arbitrary media files which can then be propagated beyond the origin content platform and propelled out into the wider world with a keen sense of their own identity. Like nametagging a schoolchild’s items of clothing. If there’s additional metadata added to provide context then so much the better, but otherwise the DOI as a digital identity will suffice. That provides the “phone home” hook.

Comments are closed.