- From: Dan Brickley <danbri@danbri.org>
- Date: Tue, 13 Apr 2010 19:15:46 +0200
- 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... cheers, Dan
Received on Tuesday, 13 April 2010 17:16:19 UTC