Imbaud Pierre wrote:
I have to add access to some XMP data to an existing python
application.
XMP is built on RDF,
I'm just looking at the XMP Spec from the Adobe SDK. First impressions
only, as I don't have time to read the whole thing in detail.
This spec doesn't inspire me with confidence as to its accuracy and
consistency. I think I've already seen some obscure conditions where
developers will be unable to unambiguously interpret the spec. Compared
to MPEG-7 however, at least it's not 700 pages long!
The spec does state that property values can be structured, which is
one of the best reasons to start using RDF for storing metadata.
However I think actual use of these would be minimal in "typical" XML
applicaations. At worst it's a simple data typing exercise of a
two-valued tuple for "dimensions", rather than separate height and
width properties. These are no problem to process.
In particular, the XMP data model is a single-rooted tree, i.e. there
is an external model of "a resource" (i.e. one image file) and an XMP
document only addresses a single "resource" at a time.
A major restriction in XMP is that it has no concept of shared
resources between properties (and it can't, as there's no rdf:ID or
rdf:about allowed). This is always hard to process, but it's also very
valuable for doing metadata. Imagine a series of wildlife images that
all refer to a particular safari, national park and species. We might
be able to share a species reference between images easily enough by
referring to a well-known public vocabulary, but it would also be
useful (and concise) to be able to define one "expedition" in a subject
property on one image, then share that same resource to others. As it
is, we'd have to duplicate the full definition. Even in XMP's "separate
document for each image resource" model we still might wish to do
something similar, such as both photographer and director being the
same person. When you start having 20MB+ of metadata per video
resource (been there, done that!) then this sort of duplication is a
huge problem. Not just because of the data volume, but because we need
to identify that referenced resources are identical, not merely havingg
the same in their property values (i.e. I'm the same John Smith, not
just two people with the same name).
There is no visible documentation of vocabularies, inetrnal or
external. Some pre-defined schemas are given that define property sets,
but there's nothing on the values of these, or how to describe that
values are being taken from a particular external vocabulary (you can
do this with RDF, but they don't describe it). This isn't widely seen
as important, except by people who've already been through large media
annotation projects.
It's RDF-like, not just XML. However it's also a subset of RDF - in
particular rdf:about isn't supported, which removes many of the graph
structure constructs that make RDF such a pain to process with the
basic XML tools. Read their explicit not on which RDF features aren't
supported -- they're enough to make XMP easily processable with XSLT.
The notes on embedding of XMP in XML and XML in XMP are both simplistic
and ugly.
I still don't see much _point_ in XMP. I could achieve all this much
with two cups of coffee, RDF and Dublin Core and a whiteboard pen.
Publishing metadata is good, publishing new _ways_ of publishing
metadata is very bad!
Overall, it could be far better, it could be better without being more
complicated, and it's at least 5 years behind industry best practice
for fields like museums and libraries. It's also a field that's still
so alien to media and creative industries that the poor description and
support of XMP will cause them to invent many bad architectures and
data models for a few years to come.
