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

Who are we and what are we trying to accomplish anyway ?

Expand Messages
  • Seth Russell
    Maybe there are two kinds of design stratagies here. Maybe trying to combine them in one group will mean that what we would produce would be a bad
    Message 1 of 20 , Sep 20, 2002
      Maybe there are two kinds of design stratagies here. Maybe trying to
      combine them in one group will mean that what we would produce would be
      a bad compromise. I think the groups can be characterized as follows ....

      (1) One group (I count myself in this group) believes in RDF and it's
      ability to say just about anything in a manner where the meaning of the
      data is carried by the syntax of the data, it's vocabulary, and it's
      schema definitions. This group believes that RDF data will be
      interoperable between diverse applications, as long as those
      applications process the data according to the syntax and it's schema
      definitions. They believe that there will be a synergy at the end of
      the tunnel when data will match up without being contrived to match up.
      They use RDF tools designed to that belief ... and are developing more
      as they speak. But, perhaps somebody can say that better.

      (2) The other group of designers are comming in from the trenches of
      actually syndicating information. They believe that the only way to
      match up data is to contrive the matches. But perhaps somebody can
      characterize that group better than I can.

      It seems to me that a combined group will not be able to come up with a
      *winning* new format that goes beyond what RSS .9x, RSS 1.0 , and RSS
      2.0 already give us.

      Hey ... maybe group (1) should split off from group (2) .....

      Seth Russell

      In response to ------
      tappnel wrote:

      >I agree with Danny this should be asked before scope. I am of the
      >mind, the data needs to tests that prove a majority backward
      >compatability with existing aggregators and toolkits. Its been my
      >experience that most of them use liberal (sometimes in the ultra
      >sense) parsers and have little regard to "specification" compliance.
      >
    • Joseph Reagle
      That s an interesting idea, but while I m *very* interested in the (relative) simple syndication format; I d also like to see RDF succeed. However, I don t
      Message 2 of 20 , Sep 20, 2002
        That's an interesting idea, but while I'm *very* interested in the
        (relative) simple syndication format; I'd also like to see RDF succeed.
        However, I don't believe that the way we perpetuate/scale RDF is to get all
        developers/content creators in the world to learn RDF. For example, instead
        of forcing every XML geek to learn RDF; what if a devoted RDF advocate
        could map into the XML application. Yes, that requires some backwards
        engineering, and some semantics might get lost in translation, but the way
        these scenarios scale is very different! However, this supposes annotating
        schemas and other mechanisms not yet in existence.

        Regardless, even with what we have, a simpler syntax is like that spoon full
        of sugar "that helps the medicine go down, the medicine go down, the
        medicine, go down." <smile/>. Folks can come to this application and start
        using it *immediately*. And if they begin to worry about extending it and
        augmenting it, *then* they'll realize they need something more, and those
        capabilities will be there! A sugar coated trojan horse is better than
        clubbing someone over the head. It just means that if the RDF gurus also
        want want greater adoption, they need to make some concessions to those
        that are new or don't have any RDF tools they are using.

        On Friday 20 September 2002 02:55 pm, Seth Russell wrote:
        > (1) One group (I count myself in this group) believes in RDF and it's
        > ability to say just about anything in a manner where the meaning of the
        > data is carried by the syntax of the data, it's vocabulary, and it's
        > schema definitions. This group believes that RDF data will be
        > interoperable between diverse applications, as long as those
        > applications process the data according to the syntax and it's schema
        > definitions. They believe that there will be a synergy at the end of
        > the tunnel when data will match up without being contrived to match up.
        > They use RDF tools designed to that belief ... and are developing more
        > as they speak. But, perhaps somebody can say that better.
        >
        > (2) The other group of designers are comming in from the trenches of
        > actually syndicating information. They believe that the only way to
        > match up data is to contrive the matches. But perhaps somebody can
        > characterize that group better than I can.
        >
        > It seems to me that a combined group will not be able to come up with a
        > *winning* new format that goes beyond what RSS .9x, RSS 1.0 , and RSS
        > 2.0 already give us.
        >
        > Hey ... maybe group (1) should split off from group (2) .....
      • Dan Brickley
        As a strategy for getting RDF from a variety of homogenous, single-names XML formats, I think what you outline makes great sense. P3P, SOAP-Encoding, XLink,
        Message 3 of 20 , Sep 20, 2002
          As a strategy for getting RDF from a variety of homogenous,
          single-names XML formats, I think what you outline makes great sense. P3P,
          SOAP-Encoding, XLink, iCalendar's XML format, etc etc. I believe RSS's
          niche is different; that we should see an RSS feed from more or less each
          Website on the planet, and that the heterogeneity of the deployed Web will
          be reflected into these feeds. Jobs, movies, concerts, people; documents,
          images, classifications, sitemaps, ratings, promises... Descriptions of
          these things should enrich many of these RSS feeds. RSS is inherently
          pluralistic in a way that many standalone RSS apps isn't.

          As such I believe it'll prove much harder to architect a 'deploy vanilla
          XML and leave it to consumers to turn it into RDF' design. What advice can
          we offer to the creators of the namespaces that would be used to help
          describe the kinds of things I list?

          If we're serious about the 'RSS from every Web site' ambition (and I am)
          we have to find a way to share the cost of making it work, and share the
          cost of creating descriptive vocabularies that can be cheaply combined.
          Maybe I'm missing something, but from where I sit RDF is the only thing
          we've got right now that comes even close. Sure it has some syntactic
          overhead, and we need better docs, tutorials, tools to explain and lighten
          that burden. But unless we're dealing with standalone XML vocabularies
          that won't be heavily intermingled, I can't see a cheaper way forward.
          'RDFize it later' technology simply doesn't exist yet for the
          multi-namespace, pluralist case. I wish it did...

          Dan

          On Fri, 20 Sep 2002, Joseph Reagle wrote:

          >
          > That's an interesting idea, but while I'm *very* interested in the
          > (relative) simple syndication format; I'd also like to see RDF succeed.
          > However, I don't believe that the way we perpetuate/scale RDF is to get all
          > developers/content creators in the world to learn RDF. For example, instead
          > of forcing every XML geek to learn RDF; what if a devoted RDF advocate
          > could map into the XML application. Yes, that requires some backwards
          > engineering, and some semantics might get lost in translation, but the way
          > these scenarios scale is very different! However, this supposes annotating
          > schemas and other mechanisms not yet in existence.
          >
          > Regardless, even with what we have, a simpler syntax is like that spoon full
          > of sugar "that helps the medicine go down, the medicine go down, the
          > medicine, go down." <smile/>. Folks can come to this application and start
          > using it *immediately*. And if they begin to worry about extending it and
          > augmenting it, *then* they'll realize they need something more, and those
          > capabilities will be there! A sugar coated trojan horse is better than
          > clubbing someone over the head. It just means that if the RDF gurus also
          > want want greater adoption, they need to make some concessions to those
          > that are new or don't have any RDF tools they are using.
          >
          > On Friday 20 September 2002 02:55 pm, Seth Russell wrote:
          > > (1) One group (I count myself in this group) believes in RDF and it's
          > > ability to say just about anything in a manner where the meaning of the
          > > data is carried by the syntax of the data, it's vocabulary, and it's
          > > schema definitions. This group believes that RDF data will be
          > > interoperable between diverse applications, as long as those
          > > applications process the data according to the syntax and it's schema
          > > definitions. They believe that there will be a synergy at the end of
          > > the tunnel when data will match up without being contrived to match up.
          > > They use RDF tools designed to that belief ... and are developing more
          > > as they speak. But, perhaps somebody can say that better.
          > >
          > > (2) The other group of designers are comming in from the trenches of
          > > actually syndicating information. They believe that the only way to
          > > match up data is to contrive the matches. But perhaps somebody can
          > > characterize that group better than I can.
          > >
          > > It seems to me that a combined group will not be able to come up with a
          > > *winning* new format that goes beyond what RSS .9x, RSS 1.0 , and RSS
          > > 2.0 already give us.
          > >
          > > Hey ... maybe group (1) should split off from group (2) .....
          >


          --
          mailto:danbri@...
          http://www.w3.org/People/DanBri/
        • Dan Brickley
          Sorry, couple of confusing typos. Fixed inline; Re-sending.
          Message 4 of 20 , Sep 20, 2002
            Sorry, couple of confusing typos. Fixed inline; Re-sending.

            On Fri, 20 Sep 2002, Dan Brickley wrote:


            > As a strategy for getting RDF from a variety of homogenous,
            > single-namespace XML formats, I think what you outline makes great sense. P3P,
            > SOAP-Encoding, XLink, iCalendar's XML format, etc etc. I believe RSS's
            > niche is different; that we should see an RSS feed from more or less each
            > Web site on the planet, and that the heterogeneity of the deployed Web will
            > be reflected into these feeds. Jobs, movies, concerts, people; documents,
            > images, classifications, sitemaps, ratings, promises... Descriptions of
            > these things should enrich many of these RSS feeds. RSS is inherently
            > pluralistic in a way that many standalone XML apps isn't.
            >
            > As such I believe it'll prove much harder to architect a 'deploy vanilla
            > XML and leave it to consumers to turn it into RDF' design. What advice can
            > we offer to the creators of the namespaces that would be used to help
            > describe the kinds of things I list?
            >
            > If we're serious about the 'RSS from every Web site' ambition (and I am)
            > we have to find a way to share the cost of making it work, and share the
            > cost of creating descriptive vocabularies that can be cheaply combined.
            > Maybe I'm missing something, but from where I sit RDF is the only thing
            > we've got right now that comes even close. Sure it has some syntactic
            > overhead, and we need better docs, tutorials, tools to explain and lighten
            > that burden. But unless we're dealing with standalone XML vocabularies
            > that won't be heavily intermingled, I can't see a cheaper way forward.
            > 'RDFize it later' technology simply doesn't exist yet for the
            > multi-namespace, pluralist case. I wish it did...
            >
            > Dan
            >
            > On Fri, 20 Sep 2002, Joseph Reagle wrote:
            >
            > >
            > > That's an interesting idea, but while I'm *very* interested in the
            > > (relative) simple syndication format; I'd also like to see RDF succeed.
            > > However, I don't believe that the way we perpetuate/scale RDF is to get all
            > > developers/content creators in the world to learn RDF. For example, instead
            > > of forcing every XML geek to learn RDF; what if a devoted RDF advocate
            > > could map into the XML application. Yes, that requires some backwards
            > > engineering, and some semantics might get lost in translation, but the way
            > > these scenarios scale is very different! However, this supposes annotating
            > > schemas and other mechanisms not yet in existence.
            > >
            > > Regardless, even with what we have, a simpler syntax is like that spoon full
            > > of sugar "that helps the medicine go down, the medicine go down, the
            > > medicine, go down." <smile/>. Folks can come to this application and start
            > > using it *immediately*. And if they begin to worry about extending it and
            > > augmenting it, *then* they'll realize they need something more, and those
            > > capabilities will be there! A sugar coated trojan horse is better than
            > > clubbing someone over the head. It just means that if the RDF gurus also
            > > want want greater adoption, they need to make some concessions to those
            > > that are new or don't have any RDF tools they are using.
            > >
            > > On Friday 20 September 2002 02:55 pm, Seth Russell wrote:
            > > > (1) One group (I count myself in this group) believes in RDF and it's
            > > > ability to say just about anything in a manner where the meaning of the
            > > > data is carried by the syntax of the data, it's vocabulary, and it's
            > > > schema definitions. This group believes that RDF data will be
            > > > interoperable between diverse applications, as long as those
            > > > applications process the data according to the syntax and it's schema
            > > > definitions. They believe that there will be a synergy at the end of
            > > > the tunnel when data will match up without being contrived to match up.
            > > > They use RDF tools designed to that belief ... and are developing more
            > > > as they speak. But, perhaps somebody can say that better.
            > > >
            > > > (2) The other group of designers are comming in from the trenches of
            > > > actually syndicating information. They believe that the only way to
            > > > match up data is to contrive the matches. But perhaps somebody can
            > > > characterize that group better than I can.
            > > >
            > > > It seems to me that a combined group will not be able to come up with a
            > > > *winning* new format that goes beyond what RSS .9x, RSS 1.0 , and RSS
            > > > 2.0 already give us.
            > > >
            > > > Hey ... maybe group (1) should split off from group (2) .....
            > >
            >
            >
            >
          • Joseph Reagle
            ... You re confusing my two issues. My first paragraph was about the future of RDF, not RSS today. It d be nice to jack existing data into the SW. For RSS
            Message 5 of 20 , Sep 20, 2002
              On Friday 20 September 2002 03:49 pm, Dan Brickley wrote:
              > As such I believe it'll prove much harder to architect a 'deploy vanilla
              > XML and leave it to consumers to turn it into RDF' design. What advice
              > can we offer to the creators of the namespaces that would be used to help
              > describe the kinds of things I list?

              You're confusing my two issues. My first paragraph was about the future of
              RDF, not RSS today. It'd be nice to jack existing data into the SW. For RSS
              today, or SYM/RNR/something <grin/> tomorrow, I'm proposing, deploy the
              simple Shelley/Palmer (it's RDF, but doesn't scare newbiews) and when
              people want to start doing modules and extensions, then they'll actually
              have an incentive and reason to appreciate RDF.
            • Eric van der Vlist
              ... I think that we really need to define what we want to achieve before going back to the syntax. For instance, IMO (and at least for the way I am using RSS)
              Message 6 of 20 , Sep 20, 2002
                On Fri, 2002-09-20 at 21:58, Joseph Reagle wrote:

                > For RSS
                > today, or SYM/RNR/something <grin/> tomorrow, I'm proposing, deploy the
                > simple Shelley/Palmer (it's RDF, but doesn't scare newbiews) and when
                > people want to start doing modules and extensions, then they'll actually
                > have an incentive and reason to appreciate RDF.

                I think that we really need to define what we want to achieve before
                going back to the syntax.

                For instance, IMO (and at least for the way I am using RSS) it's
                important to decouple the items from the channels since they can live
                their own lives (a channel "includes" several items but an item can be
                included within several channels) and this is cleaner and easier to
                manipulate if we don't define contention relations between these notions
                and a good enough reason for me to keep a "table of content" (with or
                without RDF explicit containers) in the channels.

                But, of course, untill we've really defined what's a channel and what's
                an item and what the requirements are we can discuss during hours and
                hours without making any real progress.

                RSS 1.0 has been hard enough to specify because of this shortage of
                definitions to make me want to avoid doing the same mistake a second
                time :-) ...

                Also, I think that we must check, before breaking compatibility with RSS
                1.0, that the benefits outweight the costs and I am not sure to see this
                in the proposals I have read so far.

                Eric

                --
                Rendez-vous à Paris.
                http://www.technoforum.fr/integ2002/index.html
                ------------------------------------------------------------------------
                Eric van der Vlist http://xmlfr.org http://dyomedea.com
                (W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
                ------------------------------------------------------------------------
              • Dan Brickley
                ... The whole point of RSS 1.0 was to find a sweet spot where a simple-enough doc format could be specified that would work nicely both today *and* tommorrow.
                Message 7 of 20 , Sep 20, 2002
                  On Fri, 20 Sep 2002, Joseph Reagle wrote:

                  > On Friday 20 September 2002 03:49 pm, Dan Brickley wrote:
                  > > As such I believe it'll prove much harder to architect a 'deploy vanilla
                  > > XML and leave it to consumers to turn it into RDF' design. What advice
                  > > can we offer to the creators of the namespaces that would be used to help
                  > > describe the kinds of things I list?
                  >
                  > You're confusing my two issues. My first paragraph was about the future of
                  > RDF, not RSS today. It'd be nice to jack existing data into the SW. For RSS
                  > today, or SYM/RNR/something <grin/> tomorrow, I'm proposing, deploy the
                  > simple Shelley/Palmer (it's RDF, but doesn't scare newbiews) and when
                  > people want to start doing modules and extensions, then they'll actually
                  > have an incentive and reason to appreciate RDF.

                  The whole point of RSS 1.0 was to find a sweet spot where a simple-enough
                  doc format could be specified that would work nicely both today *and*
                  tommorrow. A format where simple feeds could be made by copy'n'paste from
                  a boilerplate example, and highly sophsticated feeds could be composed
                  from multiple indepdently developed RDF/XML namespaces.

                  I believe RSS 1.0.* with a few careful bugfixes and a *lot* more
                  tools/docs/etc is an adequate basis for both, and that the cost of
                  advocating (and then migrating away from) a slightly different RDF
                  serialization right now should steer our energies in other directions.

                  I guess what I'm hearing from you is that the RSS 1.0 project (in the
                  terms I describe it above) was in essence a failure, albeit a useful and
                  educational one. And that we should go back to the syntactic drawing
                  board. My view is that it's a good-enough compromise, that we can explore
                  alternate syntaxes etc in the future (I'm particularly interested in
                  XHTML-based syndication for the simple case), but that stabilising
                  tools/docs/etc around RSS 1.0 is a more productive goal than re-inventing
                  the base syntax.

                  Dan


                  --
                  mailto:danbri@...
                  http://www.w3.org/People/DanBri/
                • Dan Brickley
                  +1 (*1000 ;-) Well said.
                  Message 8 of 20 , Sep 20, 2002
                    +1 (*1000 ;-)

                    Well said.

                    On 20 Sep 2002, Eric van der Vlist wrote:

                    > On Fri, 2002-09-20 at 21:58, Joseph Reagle wrote:
                    >
                    > > For RSS
                    > > today, or SYM/RNR/something <grin/> tomorrow, I'm proposing, deploy the
                    > > simple Shelley/Palmer (it's RDF, but doesn't scare newbiews) and when
                    > > people want to start doing modules and extensions, then they'll actually
                    > > have an incentive and reason to appreciate RDF.
                    >
                    > I think that we really need to define what we want to achieve before
                    > going back to the syntax.
                    >
                    > For instance, IMO (and at least for the way I am using RSS) it's
                    > important to decouple the items from the channels since they can live
                    > their own lives (a channel "includes" several items but an item can be
                    > included within several channels) and this is cleaner and easier to
                    > manipulate if we don't define contention relations between these notions
                    > and a good enough reason for me to keep a "table of content" (with or
                    > without RDF explicit containers) in the channels.
                    >
                    > But, of course, untill we've really defined what's a channel and what's
                    > an item and what the requirements are we can discuss during hours and
                    > hours without making any real progress.
                    >
                    > RSS 1.0 has been hard enough to specify because of this shortage of
                    > definitions to make me want to avoid doing the same mistake a second
                    > time :-) ...
                    >
                    > Also, I think that we must check, before breaking compatibility with RSS
                    > 1.0, that the benefits outweight the costs and I am not sure to see this
                    > in the proposals I have read so far.
                    >
                    > Eric
                  • Joseph Reagle
                    ... I wouldn t call where we are today exactly sweet. I think there was a missed opportunity for it to be more appealing to those concerned with simple
                    Message 9 of 20 , Sep 20, 2002
                      On Friday 20 September 2002 04:11 pm, Dan Brickley wrote:
                      >The whole point of RSS 1.0 was to find a sweet spot where a simple-enough
                      >doc format could be specified that would work nicely both today *and*
                      >tommorrow.
                      > I guess what I'm hearing from you is that the RSS 1.0 project (in the
                      > terms I describe it above) was in essence a failure, albeit a useful and
                      > educational one.

                      I wouldn't call where we are today exactly sweet. I think there was a missed
                      opportunity for it to be more appealing to those concerned with simple
                      syndication: the well known rdf:Sequence sand-in-the-pants (which
                      ironically enough was there for backwards compatibility) and using RDF
                      syntax in the spec without even explaining what it meant.

                      If we went with a new name and easier syntax, on the compatibility front,
                      for those that are using RDF tools, well, it's just another RDF stream. On
                      the XML front, I'm not sure if it's a huge deal, one more variant, but if
                      we do the job well, it should be the last one folks will ever have to
                      bother with. <grin/>

                      > And that we should go back to the syntactic drawing
                      > board. My view is that it's a good-enough compromise, that we can explore
                      > alternate syntaxes etc in the future (I'm particularly interested in
                      > XHTML-based syndication for the simple case), but that stabilising
                      > tools/docs/etc around RSS 1.0 is a more productive goal than re-inventing
                      > the base syntax.

                      I appreciate this point of view, but the assumptions you make to reach it
                      are not the same as mine -- they're not that far off, but not completely
                      aligned. Regardless, if your view came to represent the concensus of the
                      WG, then I'd want them to be serious on that too: create a RSS 1.1 REC,
                      publish a NOTE with guidelines, etc.
                    • tappnel
                      ... I would be curious to know what it is you re looking for then. There seems to be an abundance of examples that 1.0 is not being used in favor of other
                      Message 10 of 20 , Sep 20, 2002
                        --- In rss-dev@y..., Eric van der Vlist <vdv@d...> wrote:
                        > Also, I think that we must check, before breaking compatibility with RSS
                        > 1.0, that the benefits outweight the costs and I am not sure to see this
                        > in the proposals I have read so far.

                        I would be curious to know what it is you're looking for then. There
                        seems to be an abundance of examples that 1.0 is not being used in
                        favor of other formats and the "tax" of the current RDF implementation
                        is a major impediment to its mainstream acceptance. The majority of
                        applications deployed use liberal parsers because so many feeds do not
                        comply with any specific format. Furthermore I am not optimistic that
                        more examples or documentation is going to convince developers any
                        time soon to go along. Many feeds continue to not even be well-formed
                        XML. Is it possible to make RDF simpler to understand then the rules
                        of XML well-formedness?

                        Eric & Dan: Please understand, I'm just trying to be devil's advocate
                        and play the voice of practicality having worked out on the
                        "battlefield" my whole career. Sounding negative is an unintentional
                        side effect. I want to give this stuff a chance to see this work, but
                        I have not seen any tangible data or examples that back your
                        assertions that RSS 1.0 is fine and just requires some careful bugfixes.

                        This reminds me of a recent thread over on the REST-DEV list where one
                        anti-extremist like myself pointed out that SOAP-style web services
                        are being adopted by developers because they are different, but not a
                        complete paradigm shift in their thinking as REST is. Some of the REST
                        advocates have chosen to compromise by lobbying to make SOAP et al
                        more "RESTful" and they are having some success. I would recommend you
                        consider a similar tact.

                        Its not the battle, but the war you want to win.

                        So, I would not go so far as to call RSS 1.0 a failure, but I would
                        certainly assert it needs significant retooling to address the
                        resounding feedback everyday Joe's like myself are offering.

                        <tim/>
                      • Bill Kearney
                        ... +1 ... +1 ... +1 (sadly so) ... I m not clear what you mean here. ... Right, this I completely agree with. Better to have RSS-1.0 more accurately
                        Message 11 of 20 , Sep 20, 2002
                          > The whole point of RSS 1.0 was to find a sweet spot where a simple-enough
                          > doc format could be specified that would work nicely both today *and*
                          > tommorrow. A format where simple feeds could be made by copy'n'paste from
                          > a boilerplate example, and highly sophsticated feeds could be composed
                          > from multiple indepdently developed RDF/XML namespaces.

                          +1

                          > I believe RSS 1.0.* with a few careful bugfixes and a *lot* more
                          > tools/docs/etc is an adequate basis for both, and that the cost of
                          > advocating (and then migrating away from) a slightly different RDF
                          > serialization right now should steer our energies in other directions.

                          +1

                          > I guess what I'm hearing from you is that the RSS 1.0 project (in the
                          > terms I describe it above) was in essence a failure, albeit a useful and
                          > educational one.

                          +1 (sadly so)

                          > And that we should go back to the syntactic drawing
                          > board.

                          I'm not clear what you mean here.

                          > My view is that it's a good-enough compromise, that we can explore
                          > alternate syntaxes etc in the future (I'm particularly interested in
                          > XHTML-based syndication for the simple case), but that stabilising
                          > tools/docs/etc around RSS 1.0 is a more productive goal than re-inventing
                          > the base syntax.

                          Right, this I completely agree with. Better to have RSS-1.0 more accurately
                          explained and keep the idea of using XHTML as an interesting, but separate,
                          concept. I don't fault the idea but suggest the reality of how content is now
                          produced makes that a seriously flawed concept.

                          -Bill Keanrey
                        • tappnel
                          ... simple-enough ... useful and ... a missed ... +1 ... front, ... stream. On ... but if ... +1 ... explore ... re-inventing ... reach it ... completely ...
                          Message 12 of 20 , Sep 20, 2002
                            --- In rss-dev@y..., Joseph Reagle <reagle@M...> wrote:
                            > On Friday 20 September 2002 04:11 pm, Dan Brickley wrote:
                            > >The whole point of RSS 1.0 was to find a sweet spot where a
                            simple-enough
                            > >doc format could be specified that would work nicely both today *and*
                            > >tommorrow.
                            > > I guess what I'm hearing from you is that the RSS 1.0 project (in the
                            > > terms I describe it above) was in essence a failure, albeit a
                            useful and
                            > > educational one.
                            >
                            > I wouldn't call where we are today exactly sweet. I think there was
                            a missed
                            > opportunity for it to be more appealing to those concerned with simple
                            > syndication: the well known rdf:Sequence sand-in-the-pants (which
                            > ironically enough was there for backwards compatibility) and using RDF
                            > syntax in the spec without even explaining what it meant.
                            >

                            +1

                            > If we went with a new name and easier syntax, on the compatibility
                            front,
                            > for those that are using RDF tools, well, it's just another RDF
                            stream. On
                            > the XML front, I'm not sure if it's a huge deal, one more variant,
                            but if
                            > we do the job well, it should be the last one folks will ever have to
                            > bother with. <grin/>
                            >

                            +1

                            > > And that we should go back to the syntactic drawing
                            > > board. My view is that it's a good-enough compromise, that we can
                            explore
                            > > alternate syntaxes etc in the future (I'm particularly interested in
                            > > XHTML-based syndication for the simple case), but that stabilising
                            > > tools/docs/etc around RSS 1.0 is a more productive goal than
                            re-inventing
                            > > the base syntax.
                            >
                            > I appreciate this point of view, but the assumptions you make to
                            reach it
                            > are not the same as mine -- they're not that far off, but not
                            completely
                            > aligned. Regardless, if your view came to represent the concensus of
                            the
                            > WG, then I'd want them to be serious on that too: create a RSS 1.1 REC,
                            > publish a NOTE with guidelines, etc.

                            I completely agree with Joe and would like to echo the same sentiment
                            as my stance in the matter.

                            <tim/>
                          • Eric van der Vlist
                            ... For those who don t want to use well formed XML, I have even proposed a text format equivalent to RSS 1.0 core :-) ...
                            Message 13 of 20 , Sep 20, 2002
                              On Fri, 2002-09-20 at 23:10, tappnel wrote:
                              > --- In rss-dev@y..., Eric van der Vlist <vdv@d...> wrote:
                              > > Also, I think that we must check, before breaking compatibility with RSS
                              > > 1.0, that the benefits outweight the costs and I am not sure to see this
                              > > in the proposals I have read so far.
                              >
                              > I would be curious to know what it is you're looking for then. There
                              > seems to be an abundance of examples that 1.0 is not being used in
                              > favor of other formats and the "tax" of the current RDF implementation
                              > is a major impediment to its mainstream acceptance. The majority of
                              > applications deployed use liberal parsers because so many feeds do not
                              > comply with any specific format. Furthermore I am not optimistic that
                              > more examples or documentation is going to convince developers any
                              > time soon to go along. Many feeds continue to not even be well-formed
                              > XML. Is it possible to make RDF simpler to understand then the rules
                              > of XML well-formedness?

                              For those who don't want to use well formed XML, I have even proposed a
                              text format equivalent to RSS 1.0 core :-) ...

                              http://4xt.org/downloads/rss/text-to-10.txt

                              Can it be much simpler than that?

                              > Eric & Dan: Please understand, I'm just trying to be devil's advocate
                              > and play the voice of practicality having worked out on the
                              > "battlefield" my whole career. Sounding negative is an unintentional
                              > side effect. I want to give this stuff a chance to see this work, but
                              > I have not seen any tangible data or examples that back your
                              > assertions that RSS 1.0 is fine and just requires some careful bugfixes.

                              I haven't seen either tangible data or examples that we need to
                              dramatically change the language!

                              > This reminds me of a recent thread over on the REST-DEV list where one
                              > anti-extremist like myself pointed out that SOAP-style web services
                              > are being adopted by developers because they are different, but not a
                              > complete paradigm shift in their thinking as REST is. Some of the REST
                              > advocates have chosen to compromise by lobbying to make SOAP et al
                              > more "RESTful" and they are having some success. I would recommend you
                              > consider a similar tact.
                              >
                              > Its not the battle, but the war you want to win.

                              I do not claim that RSS 1.0 should dominate the world ;-) ...

                              I would even say that RSS 2.0 might change the balance we need to
                              achieve between simplicity and extensibility since there is no need to
                              two competing formats which would have the exact same sets of
                              requirements.

                              > So, I would not go so far as to call RSS 1.0 a failure, but I would
                              > certainly assert it needs significant retooling to address the
                              > resounding feedback everyday Joe's like myself are offering.

                              I am afraid that the old guard might be getting tired and need new
                              members to carry on the tooling effort :-) ...

                              Eric

                              > <tim/>

                              --
                              Rendez-vous à Paris.
                              http://www.technoforum.fr/integ2002/index.html
                              ------------------------------------------------------------------------
                              Eric van der Vlist http://xmlfr.org http://dyomedea.com
                              (W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
                              ------------------------------------------------------------------------
                            • Ian Graham
                              ... Tappnel s commentary [1] reiterates this distinction, but also (IMO) makes the important but seemingly often glossed over point that the RDF formalism is
                              Message 14 of 20 , Sep 21, 2002
                                On Fri, 20 Sep 2002, Seth Russell wrote:

                                > Maybe there are two kinds of design stratagies here. Maybe trying to
                                > combine them in one group will mean that what we would produce would be
                                > a bad compromise. I think the groups can be characterized as follows ....
                                >
                                > (1) One group (I count myself in this group) believes in RDF and it's
                                > ability to say just about anything in a manner where the meaning of the
                                > data is carried by the syntax of the data, it's vocabulary, and it's
                                > schema definitions. This group believes that RDF data will be
                                > interoperable between diverse applications, as long as those
                                > applications process the data according to the syntax and it's schema
                                > definitions. They believe that there will be a synergy at the end of
                                > the tunnel when data will match up without being contrived to match up.
                                > They use RDF tools designed to that belief ... and are developing more
                                > as they speak. But, perhaps somebody can say that better.
                                >
                                >
                                > (2) The other group of designers are comming in from the trenches of
                                > actually syndicating information. They believe that the only way to
                                > match up data is to contrive the matches. But perhaps somebody can
                                > characterize that group better than I can.
                                >
                                > It seems to me that a combined group will not be able to come up with a
                                > *winning* new format that goes beyond what RSS .9x, RSS 1.0 , and RSS
                                > 2.0 already give us.
                                >
                                > Hey ... maybe group (1) should split off from group (2) .....

                                Tappnel's commentary [1] reiterates this distinction, but also (IMO) makes
                                the important but seemingly often glossed over point that the RDF
                                formalism is sufficiently tricky and complex that it trips up and inhibits
                                even very good programmers/developers.

                                Bill Kearney's comment [2] on how current feeds rarely use mod_content,
                                and how most that do implement this feature incorrectly, reiterates the
                                need for simplicity of meaning and implementation in the specficiation.

                                I too think that RDF has important value, but it adds complexity that can
                                also lead to problems, by increasing the risk of error in designing
                                feeds, and in reducing the pool of people who can practically work with
                                RSS.

                                IMO, the propogation of modules, namespaces, and complex rules for how
                                these can be mixed inevitably makes it harder and harder to get things
                                correct. And, once the RDF statements in a message buggered up, then the
                                benefits of using RDF are lost.

                                I think a three-pronged approach is best:

                                1) a pragmatic, simplified, limited functionality non-RDF approach
                                (or at least not heavily RDFfed) that is easy to understand by
                                competent (but not AI specilist) developers, and easy to implement
                                using non-RDF tools. In this case, a developer should NEVER
                                need to read RDF specs (or understand what 'reified' means ;-) )
                                2) a richer, more complex RDF-based syntax that can express all the
                                abstract concepts of the non-RDF approach, plus many others.
                                3) a formal transformation process for converting data conforming to
                                the first standard into RDF, and vice versa.

                                (1) provides for a consistent lowest-common-denominator playing field for
                                a large fraction of current users/developers, while (2) is an exciting
                                playing ground for new technologies and features, while (3) links the two
                                together.

                                [1] http://groups.yahoo.com/group/rss-dev/message/3897
                                [2] http://groups.yahoo.com/group/rss-dev/message/3959
                                --
                                Ian
                              • Seth Russell
                                ... Hmmm ... I m sure this is true, but alass why? A database of triples is almost the simplest concept in the world. These triples (subject, property,
                                Message 15 of 20 , Sep 21, 2002
                                  Ian Graham wrote:
                                     Hey ... maybe group (1) should split off from group (2) .....
                                      
                                  Tappnel's commentary [1] reiterates this distinction, but also (IMO) makes
                                  the important but seemingly often glossed over point that the RDF
                                  formalism is sufficiently tricky and complex that it trips up and inhibits
                                  even very good programmers/developers.
                                  Hmmm ... I'm sure this is true, but alass why?  A database of triples is almost the simplest concept in the world.  These triples (subject, property, object) are all the application sees from the parser.  
                                  I think a three-pronged approach is best:
                                  
                                  1) a pragmatic, simplified, limited functionality non-RDF approach 
                                     (or at least not heavily RDFfed) that is easy to understand by 
                                     competent (but not AI specilist) developers,  and easy to implement 
                                     using non-RDF tools.  In this case, a developer should NEVER 
                                     need to read RDF specs (or understand what 'reified' means ;-) ) 
                                  But what is the difference between that and Dave's RSS 2.0 ?   I know it's fashionable not to ack Dave on this list, but what is the use of duplicating his effort over here just because we don't like him ?  
                                  2) a richer, more complex RDF-based syntax that can express all the
                                     abstract concepts of the non-RDF approach, plus many others.
                                  Once we stop trying to compromise, this really just becomes RDF triples.  Syndication needs two new node types:  item and channel.  Of coure each of those kinds of nodes can be described with whatever properties the author wishes to use.  Applications just select off the properties of channels and items which they want to process and ignore the rest.   How could anything be simpler ?
                                  3) a formal transformation process for converting data conforming to 
                                     the first standard into RDF, and vice versa. 
                                  Agree.  This should be an easy piece.  

                                  Seth Russell

                                • Phil Ringnalda
                                  ... Going back a couple of years, Dan Libby said [1] However, to be *practical*, we must first create the tools for 1) validation, 2) processing, and 3)
                                  Message 16 of 20 , Sep 21, 2002
                                    Ian Graham wrote:
                                    > I too think that RDF has important value, but it adds complexity that can
                                    > also lead to problems, by increasing the risk of error in designing
                                    > feeds, and in reducing the pool of people who can practically work with
                                    > RSS.
                                    >
                                    > IMO, the propogation of modules, namespaces, and complex rules for how
                                    > these can be mixed inevitably makes it harder and harder to get things
                                    > correct. And, once the RDF statements in a message buggered up, then the
                                    > benefits of using RDF are lost.

                                    Going back a couple of years, Dan Libby said [1] "However, to be
                                    *practical*, we must first create the tools for 1) validation, 2)
                                    processing, and 3) generation, pretty much in that order. With proper
                                    validation tools, people can begin writing processors and generators, or
                                    even producing files by hand. Without them, it is like shooting in the
                                    dark. [...] Validation is extremely important -- important enough to be
                                    listed apart from "tools". Someone publishing a document *must* be able to
                                    validate that the document is correct before sending it, particularly when
                                    setting up an automated system. Validation further helps prevent the format
                                    from splitting, particularly in areas where the spec may be unclear. For
                                    XML, validation requires minimally a DTD, and optimally XML-Schema and/or
                                    further application level processing. For RDF, validation requires an
                                    RDF-Schema aware processor (I believe)."

                                    I really don't know how much I'm asking for, but are we close to the point
                                    where we can have a useful-to-amateurs validator, one that will not only
                                    check syntax but also somehow show the RDF statements in the way they would
                                    probably be interpreted, so that, for example, someone using the default
                                    MovableType template would see that they are claiming that the
                                    admin:generatorAgent for their feed is
                                    "http://www.theirsite.com/index.rdf#MovableType/2.21"? I'm trying my
                                    damndest to have my RDF say what I mean, but with only Leigh Dodds'
                                    validator [2] and the W3C RDF validator [3] I'm barely sure that I'm
                                    speaking in grammatically correct sentences, and I'm not at all clear on
                                    whether my sentences mean "Where is the bathroom?" or "Where is your
                                    mother's coccyx?"

                                    Phil Ringnalda


                                    [1] http://groups.yahoo.com/group/syndication/message/586
                                    [2] http://www.ldodds.com/rss_validator/1.0/validator.html
                                    [3] http://www.w3.org/RDF/Validator/
                                  • Ian Graham
                                    ... I believe the issue is that the triples add an extra abstraction layer that developers don t understand or want. They want to be doers, not thinkers, and
                                    Message 17 of 20 , Sep 21, 2002
                                      On Sat, 21 Sep 2002, Seth Russell wrote:

                                      > Ian Graham wrote:
                                      >
                                      > >> Hey ... maybe group (1) should split off from group (2) .....
                                      > >>
                                      > >>
                                      > >
                                      > >Tappnel's commentary [1] reiterates this distinction, but also (IMO) makes
                                      > >the important but seemingly often glossed over point that the RDF
                                      > >formalism is sufficiently tricky and complex that it trips up and inhibits
                                      > >even very good programmers/developers.
                                      > >
                                      > Hmmm ... I'm sure this is true, but alass why? A database of triples is
                                      > almost the simplest concept in the world. These triples (subject,
                                      > property, object) are all the application sees from the parser.

                                      I believe the issue is that the triples add an extra abstraction layer
                                      that developers don't understand or want. They want to be doers, not
                                      thinkers, and the RDF approach asks them to first think through the
                                      underlying subtlety of their data semantics before developing an
                                      application. For the scope of most RSS applications, this is seen to be
                                      unnecessary baggage.

                                      It's a bit like OO -- you really don't need OO (and all the OO design
                                      abstractions) for small applications, becuase the extra layer of
                                      abstraction gets in the way of getting the simple tasks done.

                                      > >I think a three-pronged approach is best:
                                      > >
                                      > >1) a pragmatic, simplified, limited functionality non-RDF approach
                                      > > (or at least not heavily RDFfed) that is easy to understand by
                                      > > competent (but not AI specilist) developers, and easy to implement
                                      > > using non-RDF tools. In this case, a developer should NEVER
                                      > > need to read RDF specs (or understand what 'reified' means ;-) )
                                      > >
                                      > But what is the difference between that and Dave's RSS 2.0 ? I know
                                      > it's fashionable not to ack Dave on this list, but what is the use of
                                      > duplicating his effort over here just because we don't like him ?

                                      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. This group, however, has never come to consensus on doing
                                      anything that follows model (1) -- which IMHO explains why this group
                                      continues to be fractured by this issue.

                                      > >2) a richer, more complex RDF-based syntax that can express all the
                                      > > abstract concepts of the non-RDF approach, plus many others.

                                      > Once we stop trying to compromise, this really just becomes RDF triples.
                                      > Syndication needs two new node types: item and channel. Of coure each
                                      > of those kinds of nodes can be described with whatever properties the
                                      > author wishes to use. Applications just select off the properties of
                                      > channels and items which they want to process and ignore the rest. How
                                      > could anything be simpler ?

                                      Well, yes -- to you and those comfortable with the technology and tooling.
                                      This is a bit of a stretch for someone writing RSS code using perl and a
                                      simple XML parser (if that) ;-) Better RDF tooling would help greatly...

                                      > >3) a formal transformation process for converting data conforming to
                                      > > the first standard into RDF, and vice versa.
                                      > >
                                      > Agree. This should be an easy piece.

                                      One would hope so.. however, the 'muckiness' of type (1) RSS may make it
                                      hard to transform this into type (2) -- much in the way it is hard to
                                      write an HTML parser that handles all the messiness of HTML...

                                      Ian
                                    • Ian Graham
                                      ... A very good point. I believe most pragmatic RSS developers (as opposed to the R&D developers who dominate this group) would be happy with a simple
                                      Message 18 of 20 , Sep 21, 2002
                                        On Sat, 21 Sep 2002, Phil Ringnalda wrote:

                                        > Ian Graham wrote:
                                        > > I too think that RDF has important value, but it adds complexity that can
                                        > > also lead to problems, by increasing the risk of error in designing
                                        > > feeds, and in reducing the pool of people who can practically work with
                                        > > RSS.
                                        > >
                                        > > IMO, the propogation of modules, namespaces, and complex rules for how
                                        > > these can be mixed inevitably makes it harder and harder to get things
                                        > > correct. And, once the RDF statements in a message buggered up, then the
                                        > > benefits of using RDF are lost.
                                        >
                                        > Going back a couple of years, Dan Libby said [1] "However, to be
                                        > *practical*, we must first create the tools for 1) validation, 2)
                                        > processing, and 3) generation, pretty much in that order. With proper
                                        > validation tools, people can begin writing processors and generators, or
                                        > even producing files by hand. Without them, it is like shooting in the
                                        > dark. [...] Validation is extremely important -- important enough to be
                                        > listed apart from "tools". Someone publishing a document *must* be able to
                                        > validate that the document is correct before sending it, particularly when
                                        > setting up an automated system. Validation further helps prevent the format
                                        > from splitting, particularly in areas where the spec may be unclear. For
                                        > XML, validation requires minimally a DTD, and optimally XML-Schema and/or
                                        > further application level processing. For RDF, validation requires an
                                        > RDF-Schema aware processor (I believe)."

                                        A very good point. I believe most 'pragmatic' RSS developers (as opposed
                                        to the 'R&D developers' who dominate this group) would be happy with a
                                        simple toolset adn API (perl, python, php, whatever) that lets them create
                                        outgoing or process incoming RSS without needing to understand any XML or
                                        RDF. The toolset should guarantee validity at the syntactic level. RSS
                                        feeds seem to still have lots of syntactic problems.

                                        Even for the R&D group, there seem to be too few good RDF tools, including
                                        validators and visualizers.

                                        > I really don't know how much I'm asking for, but are we close to the point
                                        > where we can have a useful-to-amateurs validator, one that will not only
                                        > check syntax but also somehow show the RDF statements in the way they would
                                        > probably be interpreted, so that, for example, someone using the default
                                        > MovableType template would see that they are claiming that the
                                        > admin:generatorAgent for their feed is
                                        > "http://www.theirsite.com/index.rdf#MovableType/2.21"? I'm trying my
                                        > damndest to have my RDF say what I mean, but with only Leigh Dodds'
                                        > validator [2] and the W3C RDF validator [3] I'm barely sure that I'm
                                        > speaking in grammatically correct sentences, and I'm not at all clear on
                                        > whether my sentences mean "Where is the bathroom?" or "Where is your
                                        > mother's coccyx?"

                                        A nice example, although it does open up the doors to way too many bad
                                        jokes ;-)

                                        Ian
                                      • Seth Russell
                                        ... 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
                                        Message 19 of 20 , Sep 21, 2002
                                          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.

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

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

                                          Seth Russell
                                          http://robustai.net/
                                        • 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 20 of 20 , Sep 21, 2002
                                            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.