All the permitted variations in RDF/XML make working with it using XML tools difficult, at best. Most of the time assumptions are made about the structure of the RDF/XML document. These are based on particular RDF/XML implementations. However, there is no standard spec that says what this simplified structure should be. The next generation of RDF specs should correct this and create a subset of RDF/XML for working with XML tools.
A good place to start is with the document Leo Sauermann has started. I like the design, but feel the rules could be improved, based on my experience.
The design of SimpleRdfXml, as proposed by Leo, is:
1. be compatible with RDF/XML
2. but only a subset
3. restrict to simplicity
The rules I try to follow when serializing RDF/XML for use with XSLT are:
1. No nested elements (references to resources must be done via rdf:resource or rdf:nodeID).
2. No property attributes.
3. All blank nodes identified by rdf:nodeID.
4. Only full URIs, no relative URIs.
5. No type node elements, always as rdf:type element.
6. The same rdf:about maybe repeated on multiple nodes.
7. Never use rdf:ID.
8. Always use rdf:li when possible.
9. Always use rdf:parseType="Collection" when possible.
10. All rdf:XMLLiterals written as rdf:parseType="Literal".
11. Never use rdf:parseType="Resource".
12. White-space is preserved within literal tags.
By standardizing on these (or another RDF/XML subset), interoperability between XML and RDF tools becomes possible. This allows existing shops to reuse their current XML skills to work with RDF, easing their transition.
Monday, March 1, 2010
Subscribe to:
Post Comments (Atom)
It would be nice if XML/RDF2 could be both easy to use with XSLT and easily read- and writable for humans. Since Turtle seems to work quite well for humans my question is: how hard would an XML-ified version of Turtle (like: Turtle with square brackets) be to work with on the XSLT side?
ReplyDeleteThe general opinion at the RDF Next Step Workshop was that no new RDF format in XML should be attempted. However, if you follow the rules above (or a similar set) the result is not too far from what you suggest.
ReplyDeletenice list of rules....if possible, I would suggest writing couple of lines for each rule to kind of explain the need. Some of them are obvious but some are not.
ReplyDeleteHello! Discovering this long after, but still. I've tried out various forms of normalized RDF/XML, and some other formats. None of them really met my needs though, so I threw out the compatibility requirement and created Grit:
ReplyDeletehttp://code.google.com/p/oort/wiki/Grit
(There's an XSLT implementation of it at: http://purl.org/oort/impl/xslt/grit/rdfxml-grit.xslt (also linked from the page).)
I've comfortably used it for e.g. vocabulary documentation (see e.g.: http://code.google.com/p/oort/source/browse/impl/xslt/vocab/grit_to_xhtml.xslt ).
(I don't expect it to become standardized though, due to the general opinion you mention (and current web technology trends are more oriented around e.g. JSON and dynamic languages). Still, at least for stuff like document generation I hope it can be useful to others!)