There are two ways of modelling extensions in Atom/RDF. Generic Extensions, described here, work out of the box, and support any Extension Element you may find. The disadvantage is that they are verbose and clumsy. I’ll describe Pluggable Extensions in another post.

Generic extension support

Modelling Atom extensions in RDF is tricky. One of the unwritten principles in Atom’s design, was to avoid adding core elements that weren’t essential. At one point when the Atom standard was being developed, we had 4 different date elements. It was decided that less is more, and we cut it down to one (and a half). One of the consequencies of this policy is that it is important for software to treat extensions as first class citizens.

One aproach to making extensions first-class in Atom/RDF is to make them round-trippable; to ensure that no data-loss occurs to a property, just because it is an extension. This is great, but as extensions can contain arbitrary XML, and attributes on their top-level element, doing the obvious, and preserving the extension as a lump of XML Literal in an ex:extension property, makes the data pretty opaque to RDF processors such as SPARQL.

Another aproach (that I tried in an earlier version of Atom/RDF), is to follow the distinction of Section 6.4.1 Simple Extension Elements vs. 6.4.2 Structured Extension Elements.

The distinction between Simple Extensions and Structured Extensions was pretty much invented for use in RDF models (I know this, cause I was the one who proposed it). The idea is, that the vast majority of extensions out there are simple text properties of an Entry (or Feed, or Person), so the class of Simple Extensions makes it easier for software to implement some generic support for extensions. In RDF, Simple Extensions could be implemented by simply storing the value as an RDF property, where the property was the concatenated namespace, and local name of the Extension Element.

...at least that was the idea. Unfortunately, there are too few constraints for it to really work, people weren’t interested in fixing it, and the whole of Section 6 sticks out like a sore thumb. Oops.

The problems are basically:

• The section doesn’t give any justification for proposing two (or three) different classes of extension, so it is hard to understand what is going on. Why should an extension proposer care what class their extension is, and does it matter if their extension flips between being simple and structured depending on how it is used. [It is like trying to understand COM without reading the first chapter of Don Box’s book first.]
• The notion of determining whether an extension is simple or structured based on whether it has any attributes or mixed content, is fragile. What an attribute is, for the purpose of this distinction, is poorly defined. Does xml:base count as an attribute, what about namespace declarations. (Not that this holds any weight now, but the intention was “no” and “no”.)
• Simple Extensions aren’t language sensitive, but are they xml:base sensitive. (The intention was “no”, the whole point of them is that they are uber-easy to implement name/value pairs).
• The property name isn’t actually a URI, it is a namespace/localname pair; so if you wanted to represent it as a property in RDF, you’d have to also preserve where to split the URI so that it would be round-trippable.

The solution was a compromise. Store the extension as a BNode, with a bunch of properties. Store the complete XML as an XML Literal in atomrdf:extensionXML, but also store some other properties to make processing easier for the majority of cases:

• Store the atomrdf:contentBase as a URI. This ensures that it is available, for both Structured Extensions, and Simple Extensions that don’t work in the spirit of the Simple Extensions.
• Store the atomrdf:contentLang. This should only be needed for Structured Extensions, because the spec specifically says that Simple Extensions aren’t language-sensitive, but we might as well model it in both cases just in case.
• Store the atomrdf:propertyNS and the atomrdf:propertyName as two properties. This is duplication of atomrdf:extensionXML, but it makes it a lot, lot, easier to select an extension to process using RDF APIs or SPARQL.
• If the content of the extension isn’t mixed-content, then store the text content as atomrdf:extensionText. This basically fufils the promise of Simple Extensions, without the sillyness of treating extensions with attributes differently — and you can still use atomrdf:extensionXML in all cases.

Check out the Extension class in the Atom/RDF vocabulary for more information.