Loading ...
Sorry, an error occurred while loading the content.

Re: [RSS-DEV] Who are we and what are we trying to accomplish anyway ?

Expand Messages
  • Ian Graham
    ... If the triples were that simple, then everyone would be happy to use them :-/ But people don t seem to be entirely happy (otherwise this continuing
    Message 1 of 20 , Sep 21, 2002
    • 0 Attachment
      On Sat, 21 Sep 2002, Seth Russell wrote:

      > Ian Graham wrote:
      >
      > >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.

      If the triples were that simple, then everyone would be happy to use
      them :-/

      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
      good reason!).

      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 this
      > >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
      > >consensus.
      > >

      > 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 is quite true, and things like Relax and trex are good examples of
      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 it
      > >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.

      My muckiness referred to the need to add special handling to take care of
      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
      ;-) )

      Ian
    Your message has been successfully submitted and would be delivered to recipients shortly.