W3C home > Mailing lists > Public > public-lod@w3.org > April 2010

Re: XMP RDF extractors?

From: Dan Brickley <danbri@danbri.org>
Date: Tue, 13 Apr 2010 19:15:46 +0200
Message-ID: <o2jeb19f3361004131015sd6cf7db9ma6210ac9132202c2@mail.gmail.com>
To: Pierre-Antoine Champin <swlists-040405@champin.net>
Cc: Leigh Dodds <leigh.dodds@talis.com>, Linking Open Data <public-lod@w3.org>
On Tue, Apr 13, 2010 at 6:31 PM, Pierre-Antoine Champin
<swlists-040405@champin.net> wrote:
> Even more tangent, but when I read in detail the XMP spec last year (in
> relation to the Media Annotation WG), I came to two conclusions:
> - XMP specifies RDF at the level of the XML serialization, which is
> *ugly* (emphasis on *ugly*). Furthermore, it makes it unsafe to use
> standard RDF/XML serializers, as those may not enforce those syntactic
> constraints.
> - XMP interprets RDF/XML in a non-standard way, considering the two
> following tags as non equivalent
>  <ns1:bar    xmlns="http://example.com/foo">...
>  <ns2:foobar xmlns="http://example.com/">...
> (which is again, a syntax-only perspective). So it is not safe to use
> standard RDF/XML parsers, as they will produce a model which may be
> inconsistent with other XMP parsers.
> So you can neither use standard serializers nor standard parsers to
> handle XMP's RDF safely, so as far as I'm concerned, XMP is not really
> RDF -- and Dan's problems to extract it strengthen this opinion of mine...
> That being said, the risks of inconsistency are minimal, especially for
> parsing. So I guess there is some value in "pretending" XMP is RDF ;)
> and using an RDF parser to extract it...

I think we can and should be generous to Adobe here; there were
supportive of RDF since the late '90s - eg. Walter Chang's work on UML
and RDF http://www.w3.org/TR/NOTE-rdf-uml/ - and commiting to
something that is embedded within files that will mostly *never* be
re-generated (PDFs, JPEGs etc in the wild) makes for naturally
conservative design. There are probably many kinds of improvement they
could make, but being back-compatible with the large bulk of deployed
XMP must be a major concern. Pushing out revisions to tools on the
scale of Photoshop etc isn't easy, especially when the new stuff will
also have to read/write properly in older deployed tools for unknown
years to come.

That said I think we would do well to look around more actively at
what's out there via XMP, and see how it hangs together when
re-aggregated into a common SPARQL environment. In particular XMP
pre-dates SKOS, and I imagine many of the environments where XMP
matters would benefit from the kinds of integration SKOS can bring. So
I'd love to see some exploration of that...


Received on Tuesday, 13 April 2010 17:16:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:16:05 UTC