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.
The discussion about RSS 1.0 and RSS 2.0 continue here :
Why using RDF instead of XML? [25 May 2006]
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.
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>[email protected]</email:To>
<email:From>[email protected]</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 |
John Tropea
May 24, 2006 — 9:14 pm
Fred,
I totally agree that we need to take action after reading from within the RSS Reader.
See an old post of mine:
http://libraryclips.blogsome.com/2005/05/26/connecting-my-blog-aggregator-and-bookmarks/
http://libraryclips.blogsome.com/2006/05/04/770/#comment-30614
Taka
May 24, 2006 — 10:03 pm
This is something that we’ve been designing into Awasu for a long time, making it something that actively monitors and responds to the information stream rather than just passively presenting it to the user.
Awasu already has a plugin that monitors a mailbox and generates a feed from it, using a mailto: link for each item so that clicking on them wil launch your email client. This almost gives the exact behaviour you described.
Even better, I am right this moment working on a new feature to extract *arbitrary* metadata from a feed (such as the your email module) and present it to the user, make it available to channel hooks, be searchable, etc. It’s going to be a *really* exciting addition to the next release 🙂
Fred
May 25, 2006 — 4:24 pm
Hi guys,
John: great, thanks for these links.
Taka: wow, thanks for passing by and telling me that something in that way already exist! I just read about your “channel hooks” and it is exactly what I had in mind.
I particularly like the example with the stock exchange:
If my understanding is right, the Awasu plugins are standalone applictions that create the feed content and the “channel hooks” are able to read and act accordingly to these “special” feed, right?
In that case, you format the feed in a “special” way, right? If so, how does it works?
It is a job for RDF vocabularies I think, doesn’t?
Thanks for this very interesting conversation that is starting!
Take care,
Salutations,
Fred
Taka
May 25, 2006 — 8:56 pm
Both plugin channels and channel hooks are small standalone scripts. They can be written in any language and can sometimes be as short as 10 lines of code.
For plugin channels, think CGI scripts on web server: somebody requests a URL and the web server launches the CGI to generate the HTML that will be returned. Similarly, when a plugin channel needs to be updated, Awasu launches a script which does what it needs to do (e.g. query a database or web service) and prints out a RSS, RDF or Atom feed to stdout. No special “formatting” is required, it’s all standard feed XML.
Channel hooks are akin to aspect-oriented programming. They are scripts that get launched when something *happens* on a channel e.g. it is updated or new content is received. The hook gets passed details of the event which it can analyze and respond to. For example, there is a channel hook that sends an email when new content is received and another one that shows the latest content for a channel in small window that floats on the desktop. One of our users wrote a channel hook to manage iTunes downloads; it gets invoked every time a podcast download completes. Again, nothing “special” is required, you simply register a hook for any channel (it doesn’t matter if it’s a plugin channel or a normal HTTP-based feed) and it will get invoked every time the events happen.
WRT to your original post, the really cool stuff will be in the next release. Awasu currently uses a generic metadata framework and as it parses a feed, it extracts the standard RSS/RDF/Atom elements and maps them to these metadata. The HTML page that is used to show feed content to the user is template-based and uses this metadata to build the page e.g. {%CHANNEL-METADATA% name} is used to insert the channel’s name, {%ITEM-METADATA% author/email} for a feed item author’s email address.
The next release will let you map arbitrary elements in the XML to Awasu metadata nodes. Using your email example, you might set up a mapping like this:
email:Subject => email/subject
email:From => email/from
Awasu will parse these XML elements and attach them as metadata to the feed item. You can then include them in the HTML templates like this:
Yo! An email from {%ITEM-METADATA% email/name%} is embedded in this feed item: {%ITEM-METADATA% email/title}
Taka
May 25, 2006 — 9:00 pm
Whoops, made a misteak with the node names in the metadata node mapping example :embarrassed: But you get the idea.
The point is that Awasu will be able to parse *arbitrary* XML and present it to the user, and use it elsewhere in the program e.g. search. It could be RDF, it could be something else, but regardless, Awasu doesn’t need to know anything about it.
Fred
May 29, 2006 — 9:36 am
Hi taka,
It is really great what you are doing with Awasu. I am glad that you took the time to explain to me (and my readers) what it is all about.
Are you expecting to extend the metadata framework with the next release? Because tell me if I am wrong, but I think that the metadata framework have been created from RSS feed elements only? I think it could be, in the future, interesting to extend it with other elements.
Otherwise, is there a way to extend the metadata framework by ourselfves, using pludings or channel or whatever, to meet our needs?
Thanks and keep up the great work!
Take care,
Salutations,
Fred
Taka
May 29, 2006 — 10:13 am
Yes, the metadata framework will be enhanced in the next release.
Right now, Awasu only recognizes standard feed elements such as Author, PubDate, Copyright, etc. The next release will allow you to extract arbitrary elements from the XML (using XPath) and save them as your own metadata (along with all the standard ones) with each feed item.
Taka
July 19, 2006 — 7:19 am
Just letting you know that a new version of Awasu has just been released that contains the metadata features I talked about above.
We included your embedded email example as one of the formats Awasu supports out-of-the-box and you can see it in action at the bottom of this page.
Fred
July 20, 2006 — 12:47 pm
Hi Taka!
Wow! It seems really, really great! You have done a real good job with that one. I’ll try to write something about that new feature as soon as I have some time to check it and write about it (I currently lack of time with Talk Digger and other contracts).
Salutations,
Fred