Post
Author
Password
URI
Delete Entry?
Title
Content
<p class="entry-content"><div><p>An entertaining post from <a href="http://darwinianweb.com/archive/2006/327.html">Adam Green</a>. It's time I was in bed, so I'll only respond to one point:</p> <blockquote>Surely anyone who can code for RDF could import or export RSS and OPML.</blockquote> <p>To a certain extent this is true. But there are aspects that cause problems. Firstly, RSS (in the "simple" dialects) is a content delivery format. RDF (in short) is a data model. Though it is possible to represent human-readable content within that model, and possible to represent data in a human-readable form through formats like RSS, they are fundamentally different beasts.</p> <p>OPML might be seen as having a data model, but beyond vague notions of labelling and containership it's undefined. What it means is largely determined by application behaviour, not by any kind of specification. That behaviour is usually show-child nodes; link to HTML page; read and display feeds. <em>[PS. On second thoughts this is more like an operational semantics. In this sense OPML is more like a programming language - except that the concerns: data; view; behaviour; are all mixed up, and...largely unspecified]</em> <br></br></p> <p>Let me try putting it another way. Shouldn't Java systems be able to import and export RSS and OPML? I don't mean create/read feeds, I mean express their actual source code as RSS, and read OPML and carry out programming operations based on it. Source code is only text after all. Are Java programmers religiously opposed to OPML? <br></br></p> <p>Java is a programming language; it has an operational semantics. Tools that understand the semantics (compilers) can do useful things with the stuff. Similarly RDF is a data language, it has a declarative semantics, tools that understand the semantics (stores, reasoners) can do useful things with the stuff. RSS and OPML, like HTML are primarily markup languages for human-readable content. But again, tools that understand them (browsers, aggregators, outliners) can do useful things with them.</p> <p>It is possible to express machine-readable data in HTML because of the lack of ambiguity and the existence of extensibility in the spec (metadata profiles provide an interpretation model). This isn't really the case with OPML and RSS, too many uncertainties.</p> <p>There's another little point that slightly undermines some of Adam's arguments. Some Semantic Web developers have done work to support RSS and OPML. Off the top of my head there's Redland/Raptor's support for RSS 2.0, I'm sure I've seen more than one XSLT between OPML and OCS, the Chumpalogica aggregator (the one behind Planet RDF, no less) uses Mark Pilgrim's feed parser - which supports pretty much every kind of RSS under the sun.</p> <p>I've been arguing recently that it'd be good to use existing feed readers and OPML viewers as user interfaces, because there aren't many end-user oriented interfaces for SemWeb stuff. But that isn't to say there hasn't been a lot happening recently, exploiting things like Ajax and JSON for creating SemWeb UIs based on regular browsers.</p> <p>I reckon the number one reason most Semantic Web developers aren't interested in OPML and RSS is because they don't really offer them anything they need, or at least could achieve by building on firmer foundations like XHTML and Atom. It's not everyone's cup of tea, but there's already a general-purpose serialization format - RDF/XML. <br></br></p>@en </div></p>
Tags
Date