Maybe, though I don’t think [a clean mapping between Atom and RDF] 's official. And even it if is, it leaves out RSS. But even if it worked for RSS too, what about all the feed extensions that might be?

You could store the fully qualified entries, with the appropriate namespaces, and then define equivalencie using owl:equivalentClass. Then (I believe) a SPARQL query that extracted the rss:entry resources would also pick up the entries from Atom and the various RSS flavours. Although at that point you'd need a OWL-capable triplestore and library.

But, this part certainly caught my eye:

Our task is similarly to store high level information and preserve as much content as practical while moving it between programs. But we need to span a larger universe of data types and cannot expect to centrally define them all. Fortunately, we don't need to make programs preserve information that they don't understand.

(Also, I miss my Amiga.)

Sigh.

Isn’t there already a clean mapping between Atom and RDF?

Maybe, though I don't think it's official. And even it if is, it leaves out RSS. But even if it worked for RSS too, what about all the feed extensions that might be? I think RSS 1.0 had the right idea for extension modules in the RDF universe, but the world seems to be settling for XML.

I haven’t tried [Blogsieve], but it claims to allow filtering.

It does filter, but it does so destructively. (And that's not to mention the 7-8 step form I had to go through to start filtering. Definitely not a URL-line application.) But, with respect to their filtering and conversion, check out these feeds:

• http://del.icio.us/rss/deusx
• http://feeds.blogsieve.com/192/RSS0.91
• http://feeds.blogsieve.com/192/RSS1.0
• http://feeds.blogsieve.com/192/RSS2.0
• http://feeds.blogsieve.com/192/ATOM0.3

If you compare these to each other, you'll find information loss and even just plain corruption. The dc:subject elements encoding del.icio.us tags are gone, even in the RSS-1.0-to-RSS-1.0 transformation. And somehow, in the Atom version, they managed to jumble up titles and authors. Granted, my stuff doesn't do conversion yet, but I wouldn't want to do it like this.

I haven't tried it yet, but I'd have to guess that a podcast feed with iTunes and/or Yahoo! Media elements would get mangled in a very nasty way.

Well, a triplestore would be great if these feeds were RDF. But alas, with the exception of RSS 1.0, they’re XML. I could play with trying to make transformations from XML to RDF, but that’s getting back to a dangerously unlazy level of intelligence required to map unanticipated future feed extensions to RDF equivalents.

Isn't there already a clean mapping between Atom and RDF? There's a list of integration ideas here.

On a side note, while Googling for Atom/RDF notes, I came across blogseive, which claims to be:

...a free web-based tool that creates new feeds by filtering, merging and sorting existing feeds. The BlogSieve engine accepts virtually every (valid) feed format, processed results are then exported into any feed format you choose.

I haven't tried it, but it claims to allow filtering.

If you want feed processing tools that are useful for the general case, they have to be tolerant of things not understood. Rather than intrusively breaking apart and recasting feed data into a predetermined data structure, you’ve got to remain hands-off as much as possible.

It sounds to me like you're arguing for a triplestore and SPARQL. You'd stash everything in the triple store, and then your front end app just needs to be able to construct the appropriate query and process the results. More general and extensible than creating custom classes for filtering by specific fields, and I think if you were to ever write a general filter app where users can specify filter fields and values, you'd basically be reimplementing SPARQL.