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

RE: [RSS-DEV] Merge threads - who, what, why

Expand Messages
  • Bradley P. Allen
    As others have noted, the container syntax in RDF was badly concieved, even more poorly explained, and is not necessary for the effective representation of
    Message 1 of 36 , Sep 23, 2002
    • 0 Attachment
      As others have noted, the container syntax in RDF was badly concieved,
      even more poorly explained, and is not necessary for the effective
      representation of syndication feeds. Representing sequences in logical
      languages has always been a bit of a kludge, and RDF is no different in
      this respect. It was a mistake for RSS1.0 to use this misfeature. Future
      attempts at RSS-in-RDF should eschew the use of RDF containers. But we
      should not throw the baby out with the bathwater and conclude that RDF
      is innappropriate for syndication feeds because of this mistake. In
      fact, I would make the opposite assertion: as RSS 1.0 has effectively
      demonstrated, there is no reason for using any notation other than RDF
      for this purpose, *assuming the appropriate use of RDF*. What does that
      mean? It means don't use rdf:Seq.

      Blank nodes exist in parsed RSS because of the use of rdf:Seq to
      enumerate items. Eliminate the use of rdf:Seq and there will be no blank
      nodes. Alternatively, ignore the blank nodes and the only thing you lose
      is the ordering, which, as previous threads have noted, is not much of a
      loss.

      Further, there is nothing about RDF that works counter to the
      requirement for impermanence. Simply parse the feed periodically and
      throw away the previously created triples. If you want to maintain a
      monotonically growing historical record of what was fed, what Phil is
      doing with timestamping is in the right direction.

      We carried out a similar experiment in February of this year using
      Meerkat feeds; because the metadata in those feeds at that time was
      somewhat impoverished, it's not very impressive, but a faceted metadata
      search interface running on top of an RDF query engine using RSS feed
      data can be viewed at
      http://w3.bpallen.com:8080/spout/search.html?customer=demo&model=meerkat
      demo

      To make this point with fresher data, I've also put up an example search
      interface generated off of the content in today's XMLHack feed at
      http://w2.bpallen.com/spout/search.html?model=xmlhack. This took all of
      2 minutes of form filling, works entirely off of an RDF technology
      foundation, and is an example of how RDF technologies can be easily used
      to build value-added RSS applications, *assuming the
      RSS/syndication/aggregration community does not walk from the
      achievement of RSS1.0.*

      Bradley P. Allen
      bpallen technologies LLC
      5155 West Rosecrans Avenue, Suite 1078
      Los Angeles, CA 90250 USA
      phone +1 310 491-3424
      fax +1 310 379-0231
      web www.bpallen.com


      -----Original Message-----
      From: Shelley Powers [mailto:shelleyp@...]
      Sent: Monday, September 23, 2002 7:17 AM
      To: rss-dev@yahoogroups.com
      Subject: [RSS-DEV] Merge threads - who, what, why


      There seems to be three separate threads running along the lines
      of "Who are we and what are we trying to accomplish", mixed in with
      proofs and justification of keeping RDF in the mix. How can the
      energy expended into these threads be coalesced into a determined
      course?

      I asked the question, here and elsewhere, who is your audience? This
      isn't marketing or make work. This is a genuine attempt to understand
      what this group hopes to accomplish other than working with cool
      technology for the sake of the technology. What is the business of
      this group?

      If RSS, past and current, is based on providing syndication and
      aggregation feeds, and nothing more, than I agree with those that say
      RDF adds nothing to the mix, and not because RDF adds complexity --
      the reason is because the business of RSS isn't necessarily
      compatible with the business of RDF.

      In the last few weeks, Phil Ringnalda has been working on a
      application to process RSS 1.0 files and combine this with FOAF to
      provide a sophisticated interface allowing us to find who has posted
      or commented on what topic. Yesterday he hit what is probably the
      core difference between the business of RSS and the business of RDF --
      the fact that tools generate labels for blank nodes, and that these
      labels will vary each time the same file is parsed. (See
      http://philringnalda.com/archives/002327.php). RDF/RSS (RSS 1.0) has
      blank nodes.

      RDF is a meta-language for describing items that exist in
      such a way that this data can be processed with the same set of tools
      and combined with a great deal of confidence that this mergence
      results in a valid pool of rich data. It is literally a markup
      version of the relational data model, and as such, is extremely
      useful and necessary to help with the chaos that XML created.
      However, there is an implied persistence to the items described with
      RDF, the same as there is with relational databases. Data may change
      and be removed, but there is no temporal self-destruct attached to
      the items.

      RSS, as the majority of those who view it (the users, not the tool
      developers) is a syndication feed -- nothing more than recently
      updated items that can be polled and aggregated. There is no implied
      persistence. In fact, the business of RSS is based on impermanence.

      This is a major difference in 'business' between the two concepts.
      >From a database perspective, you rarely use an RDBMS when a flat file
      of comma-delimited data is all you need.

      If this group wants to continue providing a specification that
      defines syndication feeds, then it needs to consider that RDF not
      only doesn't buy the group anything -- it can harm the tool
      developers that use the spec. (Not to mention that trying to use RDF
      inappropriately can actually negatively impact the acceptance of the
      RDF specification.)

      If, however, this group sees that what they're working on transcends
      throwaway syndication feeds, then it needs to formally define exactly
      what the business is _before_ trying to create a spec that implements
      it. Hence my questions: who is your audience and what are you trying
      to accomplish?

      Specific instances of technology isn't an answer to these questions.
      This isn't answered by, "Well, we'll just continue as is and use XSLT
      to handle any problems in the future". If you find yourself answering
      these questions by referencing technology, then either you're missing
      the point, and or (more likely) I'm doing a piss-poor job of
      explaining myself.

      What is the problem this group is trying to resolve? What is the
      benefit this group is trying to provide that no other technology or
      specification provides? Who is your audience? Not the tool
      developers -- people don't write tools for no reason. Who are the he
      consumers of the tools developed.

      What are you trying to accomplish?

      This understanding of the basic business goes beyond a name, though
      the name of 'RSS' is drastically adding to the problem by forcing a
      type of business on this group that this group really doesn't want,
      as well as adding an element of competition that is both unnecessary
      and harmful.

      Perhaps this group really isn't interesting in throwaway syndication
      feeds. Perhaps this group is interested in finding ways of describing
      publication units that may or may not be smaller or bigger than an
      individual web page. And a side benefit of this is that the data can
      be used for aggregation purposes. Or not. I don't know -- the group
      hasn't told me what the business is.

      If you continually have to justify the use of something over and over
      again, either you're wrong, or your audience is wrong. In either
      case, you need to re-focus your efforts, and either find a different
      audience, or stop beating a dead effort.

      I guess this was more than my 0.02 worth, wasn't it?

      Shelley




      To unsubscribe from this group, send an email to:
      rss-dev-unsubscribe@egroups.com



      Your use of Yahoo! Groups is subject to
      http://docs.yahoo.com/info/terms/
    • Jon Hanna
      Unfortunately illness kept me away from my machine for a few days, and is currently reducing my desire to correspond quite drastically. It is also likely to
      Message 36 of 36 , Sep 25, 2002
      • 0 Attachment
        Unfortunately illness kept me away from my machine for a few days, and is
        currently reducing my desire to correspond quite drastically. It is also
        likely to make my normally rambling style even worse.

        However Shelley's main question about the "business" of RSS is important and
        I'd like to have my 2c.

        It seems to me that there are three ways to define the purpose of a
        technology. One I will label "designed", one "adaptive", and the other
        "reductive".

        The designed way is to have a purpose decided by necessity or inspiration
        from which you design the technology. The technology then apparently springs
        from the forehead of the individual or group who create it fully-formed,
        since it is generally only after much work that the public is made aware of
        it.

        The adaptive way is to define a purpose by examining the uses to which it's
        predecessors are used.

        The reductive is similar to the adaptive, but more forcibly redefines the
        purpose by producing a technology that can no longer be used for some of the
        tasks it's predecessors were put to.

        The parthenogenesis of the designed way tends to produce "purer"
        technologies with limited application, the adaptive way tends to produce
        messy technologies with a wide range of applications, many of which it does
        not match very well. As annoying as the inelegance may often be the latter
        type tend to be the most useful. The reductive method tends to result in
        something between those two.

        Many technologies start with a designed version 1.0 (or 0.x when the
        author(s) choose to acknowledge that they don't consider it finished) and
        are then used for purposes outside of their initial use-case which feed into
        an adaptive definition of the purposes of later versions. To elide
        historical detail for the sake of brevity the Internet's designed goal is to
        be a military and academic communication network that can survive total
        destruction of many of it's nodes and the Web's designed goal is to provide
        a simple way to write up scientific papers which would include references to
        other such papers, hypertext being used to make those references more
        useful. The Internet and the Web both have current uses quite different to
        those, and many of their parts are used in manners further removed from
        their origins (e.g. the use of HTML in many Windows technologies doesn't
        even make use of the Web's distributed nature).

        I maintain that RSS is such a technology. It's designed purpose is the
        syndication of "news" items from individual websites to a portal website, to
        be more specific to the MyNetscape portal website. It was *not* designed to
        be of any particular use to bloggers, aggregators, or metadata providers,
        but it *does* serve them and others.

        Which makes answering Shelley's question a bit tricky. Casting the net wide
        there are real-world use cases now which include some cases quite close to
        the original intent, but also some that are quite disparate (e.g. using
        RSS - either in accordance with the spec, or else as a mere provider of
        vocabulary - to provide a table-of-contents to a collection of RDF documents
        describing a site or other system). As such the best answer I can think of
        for the purpose of RSS is:

        "To provide information about web resources that change often enough to make
        such information worth giving".

        Which is a thoroughly unsatisfactory answer really, but not a useless one,
        for it still has implications in our decisions if we intend RSS+ to remain
        useful to all or most of its current users.

        In particular it means that dropping features, including features that are
        by-products of design rather than deliberately built into the format, should
        only be done with extreme caution. With such a wide range of use-cases any
        feature could prove vital to someone. This includes RDF, inherent (as
        opposed to spec-defined) ordering, the ability to work as a "pure" XML
        format, and in fact everything that someone (including myself) has suggested
        dropping.

        The reductive method could be applied here. We could define the use-case of
        RSS as, for example, "syndication of blog items", which is pretty much the
        use case of RSS0.92+/RSS2.0 and design appropriately, dropping features such
        a case doesn't need.

        Dropping such a feature is likely to lead to a split as developers no longer
        served look elsewhere, indeed that is part of the reason for the
        RDFSS/RichSS split. Such a split may indeed be a good thing, but there are
        obviously disadvantages in the loss of momentum and critical mass that it
        would entail.

        In all I would avoid a reductive definition of RSS+'s purpose. If needed
        such reduction can be provided by APIs in only providing access to some of a
        feed's information without necessitating the same reduction in the format
        itself.

        This isn't conducive to simplicity, but it doesn't preclude it either, and
        everyone benefits from simplicity (that said I'd be prepared to sacrifice
        simplicity from an RDF perspective to gain simplicity from an XML
        perspective - as in using Collection).
      Your message has been successfully submitted and would be delivered to recipients shortly.