Over the last week, Planet RDF has seen more than a few posts and comments on the RDF/XML serialisation syntax, most of them looking into its (almost not enumerable) possible variations.
Danny Ayers has a great overview with reference to the expectations, not an unimportant point — as my boss always tells me: It’s all about controlling expectations.
All in all, I agree with most of the comments on the subject, even parts of the ones that don’t seem to agree with each other.
In short: RDF/XML is just a syntax (it’s the RDF model that counts), and while I generally find it acceptable, the variation is one aspect I hope I would have done different had I been involved. That would make it more accessible to XML tools such as XSLT, leading to easier ways of generating clean XML for other uses.
The subject of RDF/XML variation is as close to being a permathread as it can be, and I’ve participated before myself, mostly with regard to the R3X syntax subset. I’ve been doing a lot of XSLT as well, and three recommendations come to mind when considering a syntactic profile or subset of RDF/XML, to reduce the variation:
- Drop the attribute form
- Except for aesthetic reasons, it’s not necessary.
- Don’t use typed nodes
- While it may seem easier and smarter to write
<foaf:Person>...</foaf:Person>
than <rdf:Description><rdf:type rdf:resource="&foaf;Person"/>...</rdf:Description>
, it makes it much harder to deal with nodes that have multiple types (and using named entities can help a lot too).
- Sort and group
- ‘nuf said — don’t break statements about the same subject into different elements, keep them together and don’t nest at all.
That said, I don’t consider the deficiencies of RDF/XML to be serious enough to warrant a new XML syntax — after all, there are plenty of RDF/XML parsers out there by now, and the real challenges lies elsewhere (see: Crisis, LargeTripleStores, and Tagtriples + identity precision).