Post

Author

Password

URI Delete Entry?

Title

Content

<div>This may seem a strange request from an RDF fan who is on record
calling OPML bloody awful (or words to that effect). But I'd like
to humbly ask that anyone exposing RDF services on the web consider
also emitting the following : 
<ol>
 <li>Content supplied as RSS 2.0 and Atom</li>
 <li>Simple resource relations as OPML</li>
</ol>
Both of these should be made available through a simple HTTP
GET. This is looking towards what I've been calling 
<a href="http://danny.ayers.name/?s=out+of+eden&submit=Search+Archives">Out
of Eden</a> 
(warning: that's a search on the old site data, things are
still in transition). Make SemWeb data available for viewing
through RSS readers and the like. Give the innocents a bit of
knowledge. Hey, they've got the coolest UIs, they deserve some
Earthly Delights. (But don't make the mistake of equating innocence
with stupidity, that leads to 
<a href="http://houseofwarwick.com/entries/00000002.html">bad</a> 
<a href="http://www.cadenhead.org/workbench/news/2881/letter-dave-winers-attorney">Karma</a>).
There are a lot of intelligent and capable developers out there
working on the web around syndication technologies, using RSS 2.0
and OPML not for any technical reasons (they would have more sense)
but because they are de facto standards. There are applications
using this stuff which are considerably more visible than the
Semantic Web apps out there. But like pretty much any interesting
software system, the benefits of Semantic Web technologies need to
be seen to be believed.
I'm prompted to post this now after seeing 
<a href="http://www.grazr.com/">Grazr</a> (spotted by 
<a href="http://darwinianweb.com/archive/2006/308.html">Adam</a>),
which is a neat little Javascript data browser, not unlike the
column-based filesystem browser on the Mac. I'm sure given a bit of
effort the same kind of thing could be built to operate directly on
RDF sources. But it'll be a lot easier to serialise out (maybe
through SPARQL+XSLT) to formats that existing widgets and tools
understand.
RSS 2.0 
is lousy, in particular with the broken-as-designed
content escaping frozen in the spec. OPML 
is bloody awful, 
<strike>in particular</strike> in pretty much every respect. But
data is easy to output in these quasi-XML formats, just don't
expect to be able to read it predictably. This isn't really an
issue for most display purposes, and RSS and OPML tools tend to be
liberal about what they consume (of necessity because of the poor
specs). It doesn't really matter exactly how you flatten RDF down
to these formats, though some expressions are obvious - e.g. if
there's a dc:title and dc:description, wrap them up as title and
descriptionin a no-namespace RSS item. Where URIs are
dereferenceable, property relationships can be squashed down to a
tree of links in OPML.
Ok, so this in part is trying to appeal to people who wouldn't
otherwise give RDF a second glance. I personally think RSS 2.0 has
been legacy since long before RFC 4287 came along. OPML is a
badly-drawn toy format that's riding on the back of RSS. So why
aren't I suggesting more capable formats (microformats, direct RDF
serializations...)?
Because the simple-is-good message has been louder than
good-is-good. There are a lot of tools around that already support
RSS 2.0 and OPML. These formats, shored up with HTML and HTTP, are
more than adequate (assuming liberal interpretation) for fairly
sophisticated display purposes, as is being demonstrated all over
the place. For anything else there are serious issues, RSS 2.0 and
OPML are non-starters when it comes to shifting data around.
Why aren't I suggesting more capable formats? Because I don't
need to. The web's natural selection will see RSS 2.0 and OPML fade
as developers choose formats that can support the functionality
they want, without being arbitrarily crippled by bad specs. But
right now there's a great opportunity to make existing apps
(aggregators, OPML browsers) that much more useful by providing
them with more interesting data. So what if you-know-who decides to
patent/lock down OPML? Ten minutes work swapping to a different
serialization syntax.
Five or so years ago it was really cool what you could do with
XML-RPC, and its existence got quite a lot of people to think about
web services. It was a blind alley in itself (it did lead to SOAP,
but I'd argue that SOAP's place of utility isn't really the open
web). Whether or not progress would have been faster without it is
another question. But many of the early adopters of XML-RPC were
the first to drop it when better alternatives became apparent (such
as RESTful XML doc/literal). So I'm suggesting the best way to get
past rubbish like OPML is to acknowledge people are doing good
things with it, and engage with their tools in their terms. They 
will be curious about what's on the other end of the wire,
and if the intuitions surrounding Web as Platform and Web of Data
are correct, the SemWeb comes faster.
In the meantime, RDF-heads get some cool UIs at low cost.@en
</div>