Random RSS/RDF FAQs

What concrete advantages does RSS 1.0 offer? Why use RDF for syndication?

What are the advantages of Atom over RSS 2.0? What problems does it solve?

What's the difference between XML-RPC and the new RESTful blogging API?

What concrete advantages does RSS 1.0 offer? Why use RDF for syndication? Isn't it just theoretical stuff?

The thing is news syndication is just one application. RSS 2.0 is fine if all you want to do is publish/read newslike information. But it's a classic stovepipe app - it isn't any good for doing anything else. On the other hand, RDF is a framework that allows you to describe any resources in a consistent fashion. RSS 1.0 is just one vocabulary of RDF.

Let's say you want to use RSS to deliver reviews of products, with ratings etc. In RSS 2.0 this could look something like :

<item>
    <guid>http://example.org</guid>
    <title>Mary Poppins</title>
    <rvw:rating>9</rvw:rating>
</item>

in RSS 1.0 :

<item about="http://example.org">
<title>Mary Poppins</title>
<rvw:rating>9</rvw:rating>
</item>

For a start, notice that there's isn't really any additional complexity.

But to do anything useful with this, an application will have to know how to interpret the <rvw:rating> element. The RSS 2.0 spec says *absolutely nothing* about how the element should be interpreted, so the entire definition for this will have to go in the extension module.

For RSS 1.0, the RDF/XML syntax above makes the statement "the resource at http://example.org is an instance of the class rss:item and it has a property called rvw:rating. The value of that property is the literal string "9". Although the syntax above is fairly similar, this information comes for free, because you're using the framework.

The module developer is given a head start, but more significantly this information can be used alongside other RDF data. You could say put it directly into an RDF store and then make the query "what properties has http://example.org?".

*Every* RSS 2.0 module will have to (re)define the basic relationships between the new elements and the core. The complexity goes way up immediately you try to do anything beyond the core.

The thing is the data from either version of RSS is easy enough to present in a human-readable form. The difference is that the RSS 1.0 version is also eminently machine-readable.

This kind of thing could be done with RSS 2.0, but every step along the way you're haven't to build something new - the same store and query tools used for this example query could be used for *any* other RDF. (e.g. see http://tap.stanford.edu/tap/ss.html) The RSS 2.0 store and query tools would only be of use for RSS 2.0.

It's really a big picture thing - the "killer app" for RDF isn't a single tool, it's a whole system of different apps and services that can use the same data - in the same way that the killer app for HTML is the web, the killer app for RDF is an improved web.

RDF is way past the theory stage, systems are being implemented all over the place. The data found in RSS 1.0 is compatible with these systems at a level far above that of XML syntax.

There is still theoretical work in progress though, particularly when it comes to reasoning with the data. But even there some apps have appeared, e.g.

http://onto.stanford.edu:8080/wino/index.jsp

Some RDF apps :
http://www.w3.org/2001/sw/Europe/reports/chosen_demos_rationale_report/hp-applications-survey.html

Dave Beckett's resource list :

http://www.ilrt.bristol.ac.uk/discovery/rdf/resources/

See also:

http://www.xml.com/pub/a/2003/07/30/practicalRDF.html

What is Dublin Core?

One of the big things about RDF is that the terms can all be mixed up (this is part of the extensibility) which makes it easy to use things from different namespaces. DC is one of the best known metadata vocabularies (amongst librarians!) and so rather than reinvent the wheel for certain terms, RSS 1.0 uses the DC definitions.

"The Dublin Core Metadata Initiative is an open forum engaged in the development of interoperable online metadata standards that support a broad range of purposes and business models."
http://dublincore.org/

They defined a bunch of terms that are largely related to publishing, the DC Element Set. For example :

    Element Name: Creator
    Label: Creator
    Definition: An entity primarily responsible for making the content of the resource.
    Comment: Examples of Creator include a person, an organization, or a service. Typically, the name of a Creator should be used to indicate the entity.

http://dublincore.org/documents/dces/

These terms can be used in various places such as the <meta... > element in HTML. But as well as the human-readable text description, they are also expressed in RDF schemas:

http://dublincore.org/schemas/rdfs/

This effectively "fixes" the meaning to a namespace. If you look at the schema entry for "creator" (I've pasted it below, it's pretty ugly ;-) you'll see it's an rdf:Property.

Similarly, the terms in RSS 1.0 are defined in a schema , so for example "channel" is defined as an rdf:Class (which basically says it's a resource that can be identified with a URI).

http://web.resource.org/rss/1.0/schema.rdf

So in an RSS 1.0 feed you'd have something like this :

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns="http://purl.org/rss/1.0/">

<channel rdf:about="http://example.org/">
<dc:creator>Sheryl Canter</dc:creator>
</channel>
...

The use of the namespace declaration
xmlns:dc="http://purl.org/dc/elements/1.1/"
and the prefix dc: effectively ties the term "creator" back to its standard definition.

The use of the RDF schemas to define the Class rss:channel and the Property dc:creator allows you to express the structural relationship unambiguously, even if you don't know the specific meaning of "channel" and "creator". As it happens in this case we do know their meanings ;-)

RSS 1.0 explicitly uses RDF/XML syntax, and the RSS 1.0 snippet above is stating that the instance of the rdf:Class rss:channel identified by http://example.org/ has the property dc:creator "Sheryl Canter".

(excerpt from DC schema)

<rdf:Property rdf:about="http://purl.org/dc/elements/1.1/creator">
    <rdfs:label xml:lang="en-US">Creator</rdfs:label>
    <rdfs:comment xml:lang="en-US">An entity primarily responsible for making the content of the resource.</rdfs:comment>
    <dc:description xml:lang="en-US">Examples of a Creator include a person, an organisation, or a service. Typically, the name of a Creator should be used to indicate the entity.</dc:description>
    <rdfs:isDefinedBy rdf:resource="http://purl.org/dc/elements/1.1/" />
    <dcterms:issued>1999-07-02</dcterms:issued>
    <dcterms:modified>2002-10-04</dcterms:modified>
    <dc:type rdf:resource="http://dublincore.org/usage/documents/principles/#element" />
    <dcterms:hasVersion rdf:resource="http://dublincore.org/usage/terms/history/#creator-004" />
</rdf:Property>>

Is OWL like Dublin Core?

The RDF stuff is layered - RDF provides some basic definitions, RDF Schema (RDFS) adds to this the means of creating vocabularies of which Dublin Core is an example. RDFS doesn't give you much more than the ability to say what terms are classes and which are properties. OWL is expressed in RDF, but is a layer on top which allows you to say more about your vocabulary, e.g.

<owl:Restriction>
<owl:onProperty rdf:resource="#hasParent" />
<owl:allValuesFrom rdf:resource="#Human" />
</owl:Restriction>

this says that every resource that has the property "hasParent" must be an instance of "human".

OWL allows a more sophisticated level of reasoning on the data. OWL is still pretty young, though it's based on DAML+OIL, which has been around a while.

What are the advantages of Atom over RSS 2.0? What problems does it solve?

The original motivation is pretty well described on the Wiki :
http://www.intertwingly.net/wiki/pie/Motivation
Essentially various minor technical bits and pieces, but critically moving on past the political obstacles associated with RSS.

What's interesting is that over the 7 weeks or so the project's been running, the emphasis has shifted a fair bit from the basic format (i.e. "RSS Next Generation") to the API. Having a good, standard way of communicating with blog/syndication tools has been a requirement from the start, so you could e.g. use the same tool to post a new blog entry to a Movable Type blog as a Blogger blog.

RSS systems usually use the Blogger API, which was originally just a quick hack, and the MetaWeblog API which isn't much better. Both of these use XML-RPC that goes direct from code to a programmatic kind of XML language, which is converted back into procedure calls at the other end. It's a bit of an outdated approach, web service techniques have moved on.

The thing is, if you have the syndication language well defined, then you can used this not only to publish the feeds, but also *create* the blog entries in the first place. Normally you'd use a http GET to retrieve the feed XML from a particular URI. To create a new entry of whatever, all you have to do is pass a chunk of the XML over http using a POST. The beauty of this is that the syndication system gets unified, (hopefully) making life a lot easier for developers.

btw, I'm blogging the project :
http://danja.typepad.com/fecho/

What's the difference between XML-RPC and the new RESTful blogging API?

With XML-RPC you use program calls sort of directly, so the remote service is like an extension of your local program. XML-RPC libraries take your method calls and wrap them up in a generic XML language, e.g.

<?xml version="1.0"?>
    <methodCall>
        <methodName>examples.getStateName</methodName>
            <params>
                    <param>
                        <value><i4>41</i4></value>
                    </param>
            </params>
       </methodCall>

and that's posted over the web to the service. It's essentially the same as pre-web network remote procedural calls, just wrapped in XML and tunnelled through http.

http://www.xmlrpc.com/spec

The REpresentational STate architectural approach makes more direct use of http. You'd create XML that's related to the data you're interested in and send that directly over http. e.g.

<?xml version="1.0"?>
        <p:Part xmlns:p="http://www.parts-depot.com" xmlns:xlink="http://www.w3.org/1999/xlink">
        <Part-ID>00345</Part-ID>
        <Name>Widget-A</Name>
        <Description>This part is used within the frap assembly</Description>
        <Specification xlink:href="http://www.parts-depot.com/parts/00345/specification"/>
        <UnitCost currency="USD">0.10</UnitCost>
        <Quantity>10</Quantity>
</p:Part>

Nice tutorial at :

http://www.xfront.com/REST-Web-Services.html

There's a difference in philosophy - the XML-RPC approach uses the web effectively as a low-level transport, the RESTful approach is using the web in the same way the web is used for html etc.