Atom and RDF

Issues of extensibility and language interop for the Atom Syndication
Format [1] have been bouncing around the Atom (IETF) group from day
one. Right now I think discussions may (again) be at a point where
input from the RDF/FOAF community could be helpful.

The Atom charter [2] says:
[[
The format must be able...
...to represent additional information in an user-extensible manner.
...
The Working Group will also take steps to ensure interoperability, by -
...describing how one migrates from the various RSS versions to the
Atom syndication feed format.
]]

<probably-biased-background>
There are various dialects in use, but generally RSS syndication
material comes under the umbrella of either RSS 1.0 or RSS 2.0 (the
version numbers are only of political significance).

RSS 1.0 [3] is defined as an RDF vocabulary, with a constrained subset
of RDF/XML as its exchange syntax (over HTTP), so there's clearly some
overlap with RDF efforts. RSS 1.0 extensions must follow the
constraints of RDF. So RDF is at least potentially a factor in Atom's
user-extensibility and must be a consideration when format migration
is under discussion.

RSS 2.0 [4] is defined as a 'simple' XML format. It hasn't got a
namespace itself, though any material in other XML namespaces can
appeared in the document and be called an extension. Most syndication
tools (for publishing and reading) support both formats. Most
syndication tools only support enough of the RDF model to be able to
extract the syndication-domain data (there are notable exceptions, and
of course virtually all RDF tools can consume & process RSS 1.0 out of
the box). Developers of syndication tools tend to have expertise with
regular expressions.

Aside from all else, there is (loosely) a polarization of opinion
among Atom WG members on how it should tackle extension and interop
issues, this being roughly parallel to that of RSS 1.0 vs. RSS 2.0.

One pole is probably most easily expressed by saying Atom should've
been defined as an RDF/OWL vocabulary and the exchange syntax made
compatible with RDF/XML.

The other pole is that Atom Core should be totally bolted down, and
extensions should simply be partitioned off using XML namespaces.
There would be no systematic approach to those extensions, anything
could go anywhere.

I would guess that group consensus generally leans towards the latter
pole. (Come to think of it, probably everyone agrees with the
bolted-down core part).
</probably-biased-background>

In [5] Robert Sayre describes an option for applying potentially
arbitrary properties to Atom entries in a uniform fashion, which may
be enough (given a bit of polish) to disambiguate extensions into
RDF-compatible statements. His suggestion hasn't brought immediate
condemnation from the core+namespace-only camp. Which is promising.

But how workable does this seem from the RDF point of view? To me it
looks like the kind of structural constraint suggested will go a long
way towards allowing extraction of viable RDF from fairly arbitrarily
extended Atom documents e.g. using XSLT -> RDF/XML. All the usual
suspects like FOAF and DC could be used to make richer Atom documents,
without compromising the core format. Does that sound about right? Or
wouldn't it work? Or is there a better approach to RDF-compatibility
that wouldn't worry the simple-XML camp?

Why does it matter? I think RDF potentially stands to gain quite a lot
from Atom, in the form of a relatively lightweight but versatile and
thoroughly spec'ed transport (and editing protocol) which is likely to
gain widespread deployment. Atom can gain potentially a lot from RDF,
up front for its intuitions into modelling on the Web and longer term
through compatibility with (and adoption by) RDF-based systems. Then
everyone gains when all these systems are joined together...

Cheers,
Danny.

[1] http://www.intertwingly.net/wiki/pie/FrontPage
[2] http://www.ietf.org/html.charters/atompub-charter.html
[3] http://purl.org/rss/1.0/spec
[4] http://blogs.law.harvard.edu/tech/rss
[5] http://www.imc.org/atom-syntax/mail-archive/msg10481.html

-- 

http://dannyayers.com

Received on Sunday, 10 October 2004 12:19:30 UTC