Re: [RSS-DEV] Who are we and what are we trying to accomplish anyway ?
- On Sat, 21 Sep 2002, Seth Russell wrote:
> Ian Graham wrote:If the triples were that simple, then everyone would be happy to use
> >I believe the issue is that the triples add an extra abstraction layer
> >that developers don't understand or want.
> Bolder dash! Programmers never had any problem with name_value pairs
> ... they loved and embraced them .. right? Well RDF is just name_value
> pairs *about things*. Programmers never had any problem with relational
> databases ... they loved and embraced them .... right? Well RDF is just
> a relational database with a fixed and simplified column structure ...
> i.e. just three columns. If you look at RDF as data and forget about
> all the abstract semantics, it actually is a much simpler solution to
> the problem of saying anything about anything. It's much simpler than
> contriving customized structures every time we want to say something new.
But people don't seem to be entirely happy (otherwise this continuing
discussion wouldn't be happening). I suspect this is because the
simplicity of raw triples gets lost in the complexity of the XML notation,
and in the complexity of the RDF semantics (the RDF specs are long for
I think RDF is very cool -- and I think it is an important and useful
technology. But I don't think you need the power of RDF for all use
cases of RSS.
It's true developers love relational databases. But then, if you're only
working with a few simple resources and only simple indexing requirements,
then I bet you dimes for dollars that most developers would just dump the
stuff into a filesytem, and use index files and hashtables.....
> >Well, I think some of Dave's ideas are poorly designed, but otherwise thisThis is quite true, and things like Relax and trex are good examples of
> >is precisely the model (and rationale) he is following. OTOH, I am not in
> >favor of specifications designed by fiat, as opposed to by some sort of WG
> Well sometimes a single person can design a better structure ... where
> a committee will end up with an aberration of compromises trying to
> attain everybody's conflicting goals. I believe that RSS 1.0 is just
> such a aberration. But the 2.0 spec preserves compatibility with
> thousands of .9x feeds, yet allows for just the additional properties
> to be added which people are screaming for. It seems to me that the
> RSS 2.0 spec just reflects where the market is and where it wants to
> go. It's simple, uncontrived, and preserves the momentum of RSS. It
> is truly going to be difficult for a committee to come up with a
> better spec.
this. I'm not so convinced of all Dave's notions, however, although I do
admit that RSS 2.0 is a reasonable way forward along the 0.9x branch.
In these other cases, however, the contribution became an open standard,
with a great deal of community contribution / involvement / consensus. Why
that didn't happen with RSS is unclear to me. Perhaps it was because there
never was a true originator of RSS to lead things forward, or perhaps it's
because those going forward had two visions for where it should go. Or
perhaps it's both of these, and more.
> >One would hope so.. however, the 'muckiness' of type (1) RSS may make itMy muckiness referred to the need to add special handling to take care of
> >hard to transform this into type (2)
> Not at all. In fact we can transform any kind of items streaming in
> channel documents into RDF nodes and arrows streaming in whatever
> media. Emails, Usenet posts, XHTML marked up web pages, arbitrary XML,
> RSS .9x, RSS 2.0, RSS 1.0 etc .... all can be included. I bid 2000
> lines of code (or less) and a simple RDF description for each new kind
> of format.
badly formed XML .... experience in other work I've done (albeit with
HTML) suggests to me that reliable information scraping from badly formed
input can get messy, and that up to 20% of the code needs to be customized
for each 'scraped' page/feed. If you've found that scraping into RDF is
relatively easy and reliable, then I think that's fantastic (and would;ve
made my life a whole lot easier, if I'd had such tools a few years back