Feed on
Posts
Comments

Time to deprecate RDF/XML?

Jan 7th, 2005 by Phil Dawes

It seems to me that the thing holding back widespread RDF adoption isn’t RDF itself, but rather RDF/XML.

Personally I think RDF/XML fails as a human oriented syntax - it’s just too complicated for the layman to bother with.

What’s more, promoting RDF/XML as the default serialisation of RDF positions RDF as a direct competitor to vanilla XML for data interchange. History is showing that this is a competition rdf/xml cannot win, and generates lots of heat and bad publicity.

Before I go on, I ought to clarify that I don’t necessarily think that RDF/XML is a bad implementation of an human-oriented XML profile of RDF, but rather that (in retrospect) the idea itself is bad. Any attempt to do this is doomed to failure.

The problem is that there is a fundamental mismatch between the RDF model (graphs/triples), and the XML model (ordered tree of elements with attributes). This mismatch makes RDF/XML painfully hard to write by hand, requiring an indepth understanding of both the rdf model and of the complicated serialization syntax nuances required to make graphs fit into a tree model.

Vanilla XML on the other hand looks like the model it represents, and that makes it simpler for people to write by hand.

So, What to do?

I’m sort of proposing the following:
(but could probably be easily persuaded otherwise by good arguments)

  • Deprecate RDF/XML as the default serialisation of RDF. Make it clear that it is tricky to write by hand (i.e. by putting this note in the W3C literature), and that if people want human-oriented xml interchange, they should use xml.
  • Develop tools to make it easy to specify a mapping between an xml dialect and RDF triples. For important web xml protocols (atom, rss2) specify some default xml to rdf triple mappings.
  • Promote turtle/n3 as the default human-oriented syntax
  • Reposition RDF as an information integration and knowledge management technology. It really excels at this, more so than any competing technologies (IMHO).
  • Promote one of the other triple-based xml serialisations for embedding rdf directly in XML documents. (e.g. trix or rxr)

N.B. I don’t expect RDF/XML to disappear anytime soon, and that’s good since it is the most widely implemented serialization of RDF in libraries, making it ideal for RDF interchange between applications.
It’s just that I think promoting it to humans is a lost cause, and my concern is that RDF/XML could bring the whole RDF stack down with it.

Does anybody agree?

Posted in Semantic Web | Comments

Viewing 5 Comments

    • ^
    • v
    • ^
    • v
    i do agree - i just doubt trix/rxr/n3/turtle will get widespread adoption (one can hope though) - trix and rxr mainly because of the 'overly' verbose syntax (yes i thought of entities here) and n3/turtle because it's simply new and people prefer to reuse their existing knowledge (even when they *should* be willing to learn new things, like in this case). one would need to prove that the use of rdf/xml is generally more harmful than your proposed way, and get acceptance for it (the harder part).

    for xml to triples - what about a new transformation reference with xslt in the background? something along < ?rdf-transformation type="text/xsl" href="http://example.org/stylesheet"?>

    regards, Michael
    • ^
    • v
    Hi Micheal,

    Thanks for the comments - I agree that trix/rxr aren't likely to become success stories in the XML world. I was really thinking of the times when some application/agent wants to interchange some RDF within an XML document.
    RDF/XML is a lot harder to parse than trix/rxr, and I suppose that's the appeal for me. Although thinking about it, that's not a good argument to replace rdf/xml as the defacto xml choice for machines talking to each other, since there's only a small number (few 10s) of implementations anyway.


    I'm not keen on using XSLT for xml to triples. The primary reason is because XSLT is complicated, and I'm assuming you'd be using the XSLT to tranform XML into RDF/XML to import it.

    Also, I suspect that it'll be easier to transform xml directly into triples given the right toys. This is a hunch though.

    The bottom line is one of numbers - there are a small number of RDF implementations, and there are a small number of important web based xml dialects. There are in contrast so many xml users out there that I think it would be much easier to supply transforms, than to try and convince XML people to use a complex RDF serialisation format in its place. (Esp when it doesnt off them much value, as is the case at present).

    Cheers,

    Phil
    • ^
    • v
    there are plenty of possible xml serializations of rdf that don't bite, the problem with the current is that it has numerous ways of representing graphed data, all of them in ways difficult to understand in xml, if there was just one way somewhat difficult to understand in xml it would probably have succeeded by now, because there are other xml formats that are difficult to understand that succeed [or at least succeed within their problem domains more securely than rdf xml has succeeded in its] so the trick is not to get rid of all serialization, but to instead agree on one of these simpler formats and stick to that one.
    • ^
    • v
    Agreed. See my blog and More on XML and RDF in particular for more thoughts.
close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus