Frederick Giasson’s Weblog

You can download 129 different web feed readers at download.com. Primary, they will all do the same thing: aggregating RSS and Atom feeds content. After they will differ in the way they will manage and present the information. That’s it.

In that case, what is the next step with Web Feed Readers… if any?

If I check the big picture, I can find out one recurrent user state: they sat in front of their web feed reader passively reading their uninterrupted incoming flow of feed content.

I am playing with this idea since I answered to a comment from Hussein on one of my old blog post talking about the security of the Gmail Atom feeds. There is what I wrote:

Google is supposed to have tested a RSS feed service for Gmail in their GoogleLabs in 2004. I can not confirm if the service is always available because I do not have any Gmail accounts and I can not sing-in for one. This service put new incoming messages of a Gmail account into a RSS feed. Then if you subscribe to that feed you will see your new Gmail messages directly into your web feed reader. What an excellent idea! However, I was surprised to found that they used SSL to create a secure channel between the feed and the feed reader.

Then I thought about all the things that we can aggregate in these days: blog content, incoming emails, UPS package delivery status, calendar events, etc, etc, etc. Then I realized: people have all that content in their face, but what can they do with it? Some web feed readers and other services now implement a “blog this item” feature. It lets the user instantly blog about that specific item. Great, users can act accordingly to aggregated content via their feed reader. Why not extending this behavior to everything else?

The email example

In a hypothetical world, I am receiving my incoming email in my web feed reader via a RSS feed service provided by my mail provider.

What is cool is that I will receive my news, my emails, my UPS delivery status, my calendar events, etc, at the same place.

So, I just received an email from Sophie. Instead of opening my email client to answer her (what would be really, really unproductive), my web feed reader detect that the incoming web feed item is an email and let me answer directly from its interface.

Wow, one single application to do all these things.

How it would works?

Technologies are already available to be able to do that. I will not re-open the RSS 1.0 vs. RSS 2.0 debate here but this example is just another one in favor of using RSS 1.0 instead of RSS 2.0.

Fred, you are telling us that RSS 1.0 is much powerful than RSS 2.0? Yes, all the power of RSS 1.0 resides in the fact that it supports modules. This capability is given by RDF and his ability to import external RDF schemas to extend his vocabulary. What is a module? A module gives the possibility to the content publisher to extend his file format’s vocabulary by importing external RDF schemas.

- RSS 1.0, RSS 2.0: make it simple not simpler

What web feed readers need is to know what particular feed item is (a sort of type). What we need is something to tell to the feed reader that this feed item is in fact an email, and not a normal feed item, and that there are its characteristics.

This is what RSS 1.0 modules are all about. This is a way to extend the information about an item in a web feed.

That way, I could tell to feed readers that this particular web feed item is not a normal one, it is an email, and there are its characteristics (sender email, receiver email, subject, body, attached files, etc, etc).

What is wonderful is that if the web feed reader cannot understand the content provided by the module, then he just doesn’t have to care about it and display the item as if it was a normal feed item. This is what is great with modules: you can act according to or just ignore them, it doesn’t change anything.

The email example with RSS 1.0 modules

Now, how it would works? Simple, we could create a RSS 1.0 module that would describe what is an email (a module is an ontology that describe classes (sender, receiver, etc.) and their properties (subject, from, to, etc.)

I will use the mailont ontology used in MailSMORE for my example.

Considering this module, a RSS 1.0 feed of a Gmail email feed would look like something like:

<rdf:RDF
xmlns:rdf=”http://www.w3.org/1999/02/22-rdf-syntax-ns#”
xmlns:dc=”http://purl.org/dc/elements/1.1/”
xmlns:email=”http://www.wam.umd.edu/~roark/mailont.rdf#”
xmlns=”http://purl.org/rss/1.0/”
>

<channel rdf:about=”http://gmail.com/?_fl=rss1.0″>
<title>GMail feed</title>
<link>http://gmail.com</link>
<description>GMail secure feed</description>
<items>
<rdf:Seq>
<rdf:li resource=”hhttp://gmail.com/getemail?r123″ />
</rdf:Seq>
</items>
</channel>

<item rdf:about=”http://gmail.com/getemail?r123″>
<title>Hello Bob! Tonight’s dinner!</title>
<link>http://gmail.com/getemail?r123</link>

<!– only used to describe the content provider, in that case it is GMail –>
<dc: publisher>Google</dc: publisher>
<dc:creator>GMail system</dc:creator>
<dc:rights>Copyright © 2006 Google</dc:rights>

<email:Message rdf:ID=”Current Message”>
<email: DateTime>10:05:03 25/10/2006</email: DateTime>
<email:Subject>Hello Fred! Tonight’s dinner!</email:Subject>
<email:To>fred@gmail.com</email:To>
<email:From>sophie@gmail.com</email:From>
<email:Cc></email:Cc>
<email:MessageId></email:MessageId>
<email:InReplyTo></email:InReplyTo>
<email:ArchiveUrl></email:ArchiveUrl>
<email:References></email:References>
<email:Body>Hello Fred! it was to let you know that it’s working for me for tonight’s dinner. Take care! Sincerely yours, Sophie xxx</email:Body>
</email:Message>

</item>

</rdf:RDF>

Now a Web Feed Reader could act upon this meta-information if he is able to understand it.

Giving this information, I could create a web feed reader that understand the “email” RSS 1.0 module (ontology) and act vis-à-vis its content. So my web feed reader would not only display static information to its users, but it would also let them act (reply to the email) accordingly to that information!

This simple schemas only shows how a RSS reader would act accordingly to the module he understand and not.

Technorati: Web | feed | rss | rss1.0 | rss2.0 | semantic | web | readers | atom |

I just came across a blog post by Doc Searl that link to a conversation about linking vs non-linking bloggers.

I was surprised to read this from Robert W. Anderson:

“What I should have said is that as a new blogger, linking is required to get into the conversation.”

My question would be: then how old bloggers can get into conversation without linking? The thing is that a link is the best metadata element we can use to link Web documents together. All the current technologies understand what a link is, and how to work and play with it.

It is sure that in the future (the Semantic Web, the Web of meaning) we will be able to link documents without “explicit links in document”. But for now, with the current technologies available, they are essential both for writer (to get into conversations) and readers (to know where the information came-from and go-to).

Links are definitely essential to beginner and expert bloggers to get into conversations.

By the way, I saw that weird argument a couple of times on the Blogsphere in the last weeks: “Strong web bloggers no longer link”. The argument here seems to mean: stop linking because the big ones stopped (you have to stop if you want to be one of these bigs). I have to confess that I don’t get it… Some A-list bloggers probably stopped to link to other people for some reasons. One of them could be because they think that they are so bright that they don’t need other people ideas to write something intelligent. For them I would cite Emerson: “Every man I meet is my superior in some way. In that, I lean of him”. Okay, I agree, most of them probably stopped to link to other people because they see themselves as columnists and not as bloggers(people that get into conversations evolving on the Web via their personal Web log) anymores.

Technorati: Link | a-list | bloggers | metadata | conversation | discussion | web | talkdigger |

“Make everything as simple as possible, but not simpler”. – Albert Einstein.

I love that quote of Albert Einstein. Few words that tell so much to designers. Make things simple to the user, make it such that he does not even know that he his using what you designed (okay, it is an utopia); but beware: do not make it simpler, do not compromise on the capabilities of what you are designing to make it simple (this is all the art of design).

This said, I am currently rewriting the Talk Digger RSS feeds generator for the next release planned in a week or two. While working on it, I found that I done the error: I make it simpler while whishing to make it simple.

Let me explain the situation. Some months ago, I choose to create the feeds in RSS 2.0 instead of RSS 1.0. But what is the problem then? RSS 2.0 should be much more evolved then RSS 1.0, isn’t? No, it is not. RSS 2.0 is about 2 years younger than RSS 1.0, but much simpler. Why do I say that the file format is much simpler? Because RSS 1.0 feeds are serialized in RDF and RSS 2.0 feeds are serialized in XML.

Where is the problem then? XML serialized files are much easier to read than RDF serialized ones; in fact, RDF files are only cluttered XML files, isn’t it? No, definitely not. It is sure that RDF/XML serialized files (because there exist other serialization format like N3 that will also serialize RDF files) are less intuitive to read for humans, but they are much more powerful to answer to some needs.

Personally I see RSS 2.0 as a lesser version of RSS 1.0. Why? Because applications that support RSS 2.0 are much simpler (a thing that we do not want) considering that it only have to handle XML files instead of full RDF ones.

Fred, you are telling us that RSS 1.0 is much powerful than RSS 2.0? Yes, all the power of RSS 1.0 resides in the fact that it supports modules. This capability is given by RDF and his ability to import external RDF schemas to extend his vocabulary. What is a module? A module gives the possibility to the content publisher to extend his file format’s vocabulary by importing external RDF schemas.

Okay, but what is the advantage of using these modules? I will explain it with an example using Talk Digger. I am currently thinking about creating a RDF schema that would model some semantic relations that Talk Digger will compute with the search engines’ returned results. Personally I want to make that information publicly available to anyone who would like to have access to it and do something with it. This said, I am also thinking to broadcast the information directly in the RSS feed: I want to create only one source of information that would broadcast everything. RSS 1.0 gives me that possibility (in fact, a RSS 1.0 web feed is a normal RDF/XML file using the RSS 1.0 schema). It is beautiful, I can make all the information I want available to any one, in a unique source. If a software that read the feed do not understand a part of the information I broadcast (in reality, he do not know the RDF schema I am using) he simply skip it and continue to read the source of information (the web feed) and do what he have to do with the information he understand. I can’t do that with RSS 2.0 because it is serialized in XML and not RDF. I could even add OWL elements in my feeds to model some relations between the knowledge represented in the web feeds. That way an application could be able to infer knowledge from it! An example of a popular module is the Dublin Core metadata initiative.

You are probably thinking: yeah Fred, but readers only have to support both formats, and publishers also only have to support both formats as well and everybody will be happy. Bad design thinking: do not forget that the goal is to make application. How do you think that I will explain the difference between RSS 1.0 and RSS 2.0 to my mother? How do you think that I will explain her which one to choose if she have the possibility to subscribe to more than one feed? Will she choose RSS 0.91, RSS 0.92, RSS 1.0, RSS 2.0, ATOM 0.9, or ATOM 1.0 (because some websites propose them all)? Sorry, but I do not want to.

One of the current problems

On of the problem are the way applications handle all these file formats and serializations. I will explain it with a problem I faced today while testing the new RSS feed of Talk Digger with Bloglines.

A thing I wanted was to use the Dublin Core element “Description” instead of the normal “<description></description>” tag of the RSS 1.0 specification. I first thought that it would scale much more because the Dublin Core RDF schema is widely use by many, many applications over the Internet. First I tested it using RSS Bandit. It worked like a charm. All the Dublin Code elements I added to my RSS feed were handled by it. Wow! Then a tested it with Bloglines: nothing. Bloglines just doesn’t handle that Dublin Core tag: deception.

Then I included this namespace into my RDF file: “xmlns:ct=”http://purl.org/rss/1.0/modules/content/””. Then I re-tested it: nothing. Wow, it should works, isn’t? Then I tested something else, I changed the alias “ct” for the namespace “content”: it worked. What a deception I had: Bloglines is not caring about the namespace local alias, in fact it seems that it parse the RSS 1.0 feeds (in fact a RDF file) with fixed strings. The system should know that “ct” is related to the namespace instead of “content” because they are just aliases that I use to define the namespace in my local file. It is a perfect example of bad implementation of specifications in softwares.

The problem here is that Bloglines is the most popular web feed reader out there. So I have to change the way I build my feeds to handle that fact, but I shouldn’t be supposed to (it is really frustrating). Will I have to change the way I build my feeds each time I discover that an application is not parsing and using them properly? I hope no, I shouldn’t be supposed to because I follow the specification to build them.

I hope they will check that problem with their parser and hire somebody to develop a robust system that will parse and handle the RDF specification, and not only parsing RSS 1.0 feeds as simple text files with some format… (Could I change that skill requirement “Familiarity with RSS and blogs” for “Strong understanding of RDF, RSS and blogs”, cited in that job proposition, to answer that responsibility “maintain and improve RSS crawling and parsing processes”.

I hope to be able to show you how RSS 1.0 could be extended, using a future version of Talk Digger, soon.

Technorati: Rss | rss1.0 | rss2.0 | atom | feed | Bloglines | talkdigger | simple | simpler | Einstein |