Ian Davis shows how even the smallest RDF graph has multiple XML serializations. He missed some variations: (i) rdf:RDF is optional, and (ii) rdf:type has special-case treatment in the grammar (iii) XML base can interact with URIs.

<foaf:homepage rdf:resource="~eve"/>

Simple RDF graph describing Eve

This variety should not be suprising. A good question to ask here, is how much we’d gain from dropping the more esoteric syntactic variations. Imagine for example a syntactic profile of RDF/XML in which rdf:RDF was never needed, rdf:type and literals were never represented as attributes, node elements always (or never!) carried a type, and rdf:nodeID was only used when absolutely (how to define this?) necessary. I still suspect that there would be plenty of variation, because the fundamental practice wouldn’t change. We’d be representing unordered graph data over an ordered tree.

My take: custom syntactic profiles, ones designed for some particular community and purpose have a role. We can define them as RDF/XML subsets (in Relax-NG, Schematron or prose), or as non-RDF XML formats, transformable with GRDDL. Either approach makes life somewhat easier for those working with XML tools, at some cost to those in an RDF environment. But we should also stop looking over our shoulder at XML. RDF/XML is painful for XML developers because they find themselves lacking familiar tools when working with RDF.

This is not because of the particular charm of those tools, but because they exist. If the RDF programming environment were anywhere near as rich with tools as XML’s, this would not be such an issue. Developers are pragmatic, and will use what is available. If RDF tools feel less mature than XML tools, developers will naturally complain if their data formats force them to use only RDF tools. SPARQL is an important thing here, one that might be accompanied by lightweight API standardisation and other steps to lessen the pain of those moving on from pure-XML toolsets.

I’d much rather see folk work on RDF tools and APIs (how about a SPARQL engine in .js or PHP?) than this endless navelgazing on RDF’s XML syntax. This is not to downplay the excellent work that’s already out there (Redland, Jena, etc.), just to note that we’ve still some catching up to do with the XML world. We don’t yet have API portability between tools, beyond that offered by the (still draft) SPARQL spec. It’s that sort of thing that inspires confidence in developers, and that will give them the sense that maybe (just maybe…) they could work with a non-XML toolset. Given a choice between worrying about the flexibility of the RDF/XML syntax versus helping test and document SPARQL support in some RDF toolkit, I know how I’d rather be spending my time…

Published by danbri

Click here to type

Join the Conversation


  1. Some random comments:

    The one issue I have with syntactic profiles is controlling the serialisation, which can be fiddly (otherwise it’s a fine choice).

    My suspicion is that when people are talking about issues with rdf/xml, they are specifically talking about xslt and rdf/xml. People like xslt (with good reason) and want to use it for everything. It’s probably worth
    capturing some of the discussion about transforming rdf in the ESW wiki (http://lists.w3.org/Archives/Public/semantic-web/2005Sep/0048.html ), which might help them out.

    I could summarise that as: sparql will help a great deal.

    One final random thought (and personal bugbear): if rdf/xml had a way to write properties without qnames, eg:

    Then you could have and rdf/xml normal form which:

    1. Used only the rdf namespace.
    2. Had a (useful) xml schema.
    3. Only varied in order.

    Much like trix et al. I don’t want to write it, but if people want that kind of thing…

  2. Swallow my example, will you?

    <dc:title … > -%gt;
    <rdf:predicate rdf:property=”&dc;title” …>

Leave a comment