On Tue, Apr 13, 2010 at 6:31 PM, Pierre-Antoine Champin <[email protected]> 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... cheers, Dan
