This document argues that the RDF/XML syntax is either fruitless or harmful for Atom. It accepts the RDF model, and the RDF background of formal data modelling, to be beneficial.
[DannyAyers] What's changed is that Aaron pointed out that the last snapshot was already very close to RDF, which made the issue worth re-examining.
The following are arguments against Atom's syntax being valid RDF/XML, with or without an accompanying DTD.
Atom Doesn't Need RDF
Atom does not need RDF. RDF needs Atom. RDF needs Atom in much the same way that it needs every XML syntax: the data that are in XML are more accessible to RDF toolkits when that XML is in RDF/XML form. But tools to process Atom from a syndication point of view, syndication as we know it at the moment, do not need that. As long as the Atom specification is closely monitored by the RDF community for compatability with RDF, as long as it has a formal rigorously defined model, it does not need to be expressed in RDF/XML syntax.
[ShelleyPowers] By not using a valid RDF/XML format, we preclude using automated tools such as web bot from accessing this data. Remember that XML tools can directly access RDF/XML, but RDF/XML tools cannot directly access a non-valid RDF/XML feed. Which format, then, is the more exclusionary format? If the RDF/XML couldn't be accessed using XML tools, I could understand the push back. All I see now, is not technology, but politics.
RDF/XML excludes Topic Maps. RDF/XML excludes XFML. But preclusion of automated tools and exclusivity are not valid rebuttals of Atom not needing RDF, and the preclusion argument is moreover refuted by "Work a Little, Work a Lot" below. The argument from Atom not needing RDF is that Atom-specific applications gain no value from RDF/XML syntax. It's a YAGNI spin-off, and exclusion has nothing to do with it. It's what's valuable to Atom developers that counts.
"RDF/XML excludes Topic Maps. RDF/XML excludes XFML." Not so. Topic Maps can be expressed using RDF/XML, facetting can be expressed in RDF/XML which can then transformed into XFML (in fact it can be expressed more rigidly thanks to the OWL ontology).
[DannyAyers] RDF doesn't need Atom, it's doing fine by itself. RSS 1.0 can be used directly and RSS 2.0 can be used after transformation (this data isn't very clean, but that's another issue). Atom doesn't yet have any systematic way of handling material from other namespaces. It doesn't necessarily need RDF, but it needs something.
[HenriSivonen] Reiterating what I said in [DontUseXml] but with s/XML/RDF/: If Atom were an RDF-based format, everyone would have to consume it with RDF tools. Otherwise, interoperability would suffer. As long as most people see RDF only as a matter of buzzword-compliance and don't want to use RDF tools to consume the feeds, it is guaranteed that very quickly there'd be a bunch of RDF-looking incorrect feeds out there which would break interop with apps that actually tried to use RDF tools. Personally, I don't believe most people are interested in consuming an ordered list of entries that have a few name-value pairs attached to them by poking around a graph. Specifying RDF/XML and saying that you can consume it as regular XML if you want to, will break RDF compatibility anyway and make the regular XML way unnecessarily complex.
[DannyAyers] Not so. People that used RDF tools would get maximum benefit, but it certainly isn't necessary. This is very like the current situation with *any* XML (notably RSS) - you can use XML tools (and get the associated benefits) or you can just hack together a few regexps. As long as there are test feeds and a validator, interop shouldn't be affected with RDF or XML.
[KenMacLeod] Just to clarify, the only way non-RDF tool users are able to easily use RDF-based formats is if the serialization structure of the RDF is restricted for that format, as RSS 1.0 is. This is similar on the output side to, but less critical than, having a non-RDF format on the input side that needs to be transformed to be read as RDF. The benefit to the web at large is that non-RDF tools can easily read and create the format and that RDF tools do not need to pre-process to read the format (the much larger proportion than those RDF tools that have to write it).
Work a Little, Work a Lot
It has been said that AtomXML causes problems for RDF people. The XSLT transformation step is too much of a burden for them. But RDF is like XML in that it is a meta-language; applications are built on top of it. XML parsers don't understand Atom; you have to build aggregators and so forth to actually make use of Atom itself. Likewise, even if Atom were RDF/XML, RDF parsers would not understand it. There is an extra step already in that application semantics don't come for free with meta-language parsers. Adding another XSLT step is insignficant, since the argument from automation can no longer be made.
[AsbjornUlsberg] Can't an "official" XSLT stylesheet (and maybe even an online WebService) be offered for those who want to convert their Atom-feeds into RDF? This shouldn't be very difficult to create.
[ShelleyPowers] And have all producers deal with this? Do we find that XSLT to be readable, and easy to work with for most folks? How about web bot access for those people who don't transform the syntax -- that's data thats excluded from gathering. And I ask again -- does using RDF/XML preclude one from using XML tools?
[AsbjornUlsberg] If we offer a Web Service which they can POST an Atom feed to and get RDF in return, aren't that going to help? And if we offer an official XSLT stylesheet, developers making CMS's etc. can implement this XSLT into their system, easilly enabling users to give both Atom and RDF feeds. Heck, we can even provide "official" MovableType-templates as well. It's not much work for us, and it should benefit users greatly.
To your other question, I'm not sure. I can't think of a reason why it should, though I've not given the matter much thought.
[DannyAyers] re. "even if Atom were RDF/XML, RDF parsers would not understand it". Not so. Certain parts (e.g. title) could be specified in the schema in terms of other RDF vocabularies (atom:title subPropertyOf dc:title). Additionally the structural relationship between the components would be defined, allowing processing without any domain-specific understanding. RDF works because it can work with partial understanding, it isn't all or nothing. This is one of the major benefits of using RDF for any vocabulary.
RDF Programs Must Handle Non-XML/RDF
This is a corollary to 1), Atom Doesn't Need RDF, and is based on a suggestion by MarkPilgrim on the #echo IRC channel. There are many non-RDF data formats, e.g. RFC 822, CSV, HTML and SGML, etc. Some of these are formally defined enough to be useful as RDF applications, and some aren't. Some are semi-formal, and some guesswork needs to be applied to make them RDF-compatible. But from a syntax point of view, none of these formats are even XML, yet alone RDF/XML. Some work has been conducted on being able to parse arbitrary grammars as RDF, e.g. Sandro Hawke's blindfold BNF reader.
[DannyAyers] The only way I can see this as being relevant is that if RDF can handle the listed formats, then making Atom RDF compatible will bring the benefit of better interop with those formats.
It is not known, and nor is it possibly even quantitatively measurable, how much of the useful data to RDF programs will have come from first class RDF/XML sources and how much won't, but we can assume that a very rigid set of approaches and code implementations must be put in place to deal with the non-RDF/XML cases.
Given this, is it not reasonable to assume that if Atom were to not use RDF/XML, RDF programs should have the facility to deal with this?
[DannyAyers] I imagine the facilities of those RDF programs are likely to be the same whether Atom uses RDF/XML or not.