I have seen a few references to Sebastien Paquet's The Algebra of Feeds post lately, and just saw it re-published as The Algebra of RSS Feeds on the Java Development Journal / Linux World (all recently noted by Seb).

Seb mentions several of the operators of Codd's relational algebra, and, it seems to me there are two general reasons why everyone isn't already operating on RSS as relational data: 1) it is distributed across many files, and 2) the hierarchic XML structue of RSS.

I am developing the iCite net prototype right now and exploring different cases for using XML vs an SQL relational database store. In either case, iCites need to pull together data from different sources and be able to operate on them as if they are all in the same data base.

XML is nice for transfering data between multiple sites. A lot of the source data I am working with is RSS and XHTML already, and those are also primary output formats for iCites. But, I still don't have a handle on XPath 2, XQuery, and XSLT as a means of relational operations the way I do with SQL.

For example, it is pretty obvious to me how to splice and dice two RSS feeds when I think about RSS items in tabular format (which I mentioned in my RTS = Really Tabular Syndication, my new syndication format post).

Anyway, my basic goal these days is along the lines Seb's post: being able to slice and dice information that appears as RSS. iCites link RSS feeds (and other information) together and give them the semblance of being a single data base.

The main issue I am dealing with now is what types of data structures and formats work best with the various combinations of uses between data interchange, data storage, and querying.

Also, the one other issue, that is key to relational algebra, is unique identifiers. So, in the iCite net, the iCites (with support from the iCNS name service) assign unique identifiers to information. This means, for example, that duplicates can be eliminated when combining two different feeds that each include a common feed. Like:

Feed A + B = Feed C and
Feed A + D = Feed E so
Feed E = Feed A + Feed B + Feed D (without duplicates)

Ultiamtely, what I think of as the real opportunity for aggregation is when common information (i.e., sharing the same unique identifier) is recognized. Then, rather than seeing the same information repeated in disconnected contexts, one can see an aggregate view of multiple contexts.