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

Re: Merge threads - who, what, why

Expand Messages
  • Shelley Powers
    ... bit. ... was ... email ... run ... I didn t notice the quote ...run your mouth when I was here last time, not until Mark Pilgrim decided to join this
    Message 1 of 36 , Sep 23, 2002
    • 0 Attachment
      --- In rss-dev@y..., Seth Russell <seth@r...> wrote:
      > Shelley Powers wrote:
      >
      > >How does FOAF aid aggregation? The author is included with each
      bit.
      > >Why do we need extraneous material such as college, and who the
      > >author knows -- which is FOAF's business purpose.
      > >
      > For eaxmple I wanted to know who *you* were ... only thing I had
      was
      > your posts to this list ... so i found "burningbird.net" in your
      email
      > address and hence [1] .... then i did a lot of reading over there.
      > Still don't really know who your are and what you are into, what
      > projects you are working on, who you know, and why you came here to
      run
      > your mouth. But if there were a foaf button on the feed from this
      > channel, well I just click on that and i'm totally into your stuff.
      >
      > [1] http://burningbird.net/burningbird.rdf
      >
      > Seth Russell
      > http://radio.weblogs.com/0113759/



      I didn't notice the quote "...run your mouth" when I was here last
      time, not until Mark Pilgrim decided to join this little party.

      So, people that come here to question, pursue, query, whatver --
      unless they don't agree, they get things like "...run your mouth"?

      This group will never, ever get respect if this is how it handles
      pressure, or push back.

      I wanted to make a point today. And I think I made it.

      As for FOAF -- FOAF is friend-of-a-friend. It wasn't meant for
      identification or for web of trust. It was a test of a technology and
      a concept. I have absolutely no use for a FOAF file at my site. You
      want to know about me, trying clicking the little hypertext link that
      says "About Burningbird". I know it doesn't have an orange xml
      picture attached to it, but such is life.

      "Run your mouth". Unbelievable.

      Shelley



      Shelley


      >
      >
      >
      >
      >
      >
      >
      > >
      > >Syndication/aggregation -- been around since Microsoft and Active
      > >channels and CDF. Excerpting content and providing either pushed
      or
      > >polled updates of new material. Aggregation is specifically
      polling
      > >new material from several sources into one place for consumption.
      > >
      > >If you all see it as something else, what? And this still begs the
      > >question: does this working group see itself focusing primarily on
      > >syndication/aggregation?
      > >
      > >
      > >
      > >>>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.
      > >>>
      > >>>
      > >>There is certainly a difference, but I don't think it's quite
      that
      > >>
      > >>
      > >clear
      > >
      > >
      > >>cut. bnodes are attached to URIs, whereas 'loose' chunks of xml
      > >>
      > >>
      > >don't have
      > >
      > >
      > >>much grounding apart from their tree, and all have to be
      represented
      > >>in-memory somehow.
      > >>The problem Phil Ringnalda discusses looks to me like very much
      > >>
      > >>
      > >like a
      > >
      > >
      > >>specific implementation issue, rather than a general problem.
      > >>
      > >>
      > >>
      > >
      > >No way, Danny. Phil hit the business problem right on the head.
      RSS
      > >files are nothing more than throwaway files with the 15 most
      recent
      > >updated items. The items repeat until newer ones are pushed off.
      > >These items are scraped by tools that then throw this information
      > >into pages for people to look at and click a link if they want to
      > >read more. Can't get more uncomplicated than that.
      > >
      > >This is so time dependent, it's not even funny, and the whole
      concept
      > >of blank nodes implies single processing.
      > >
      > >
      > >
      > >>>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,
      > >>>
      > >>>
      > >>It literally isn't.
      > >>See the RDF M&S and Codd's model :
      > >> http://www.acm.org/classics/nov95/s1p3.html
      > >>
      > >>
      > >>
      > >
      > >Of course it's not the same mathematical model. Danny, I've been
      > >working with databases for 20 bloody years. The concepts are the
      > >same -- to provide a single model that allows interoperability of
      > >tools and data, and also to provide rules to ensure that the data
      is
      > >valid.
      > >
      > >If these concepts differ, show me how -- don't show two different
      > >models.
      > >
      > >
      > >
      > >>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.
      > >>>
      > >>>
      > >>I agree that the time aspect is very important in this context,
      > >>
      > >>
      > >which is why
      > >
      > >
      > >>I asked whether time properties should be mandatory a few posts
      > >>
      > >>
      > >back. I
      > >
      > >
      > >>think we can also agree that feed-type information doesn't have
      the
      > >>
      > >>
      > >same
      > >
      > >
      > >>kind of permanence as most other web data, but it may be illusory
      > >>
      > >>
      > >to take
      > >
      > >
      > >>this too far - after all, even if a headline is only an hour old
      it
      > >>
      > >>
      > >still
      > >
      > >
      > >>has to have been persisted somewhere.
      > >>
      > >>
      > >>
      > >
      > >Why?
      > >
      > >
      > >
      > >>>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.
      > >>>
      > >>>
      > >>How is that relevant?
      > >>
      > >>
      > >>
      > >
      > >Sorry, this was actually a typo. What this should have said was
      using
      > >RDF for syndication/aggregation is similar to using an RDBMS, when
      a
      > >temporary flat file with comma-delimited data is all you need.
      > >
      > >Now, if you see that the business needs of syndication and
      > >aggregation needs this persistence, define them. Explain them.
      > >
      > >
      > >
      > >
      > >>>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.)
      > >>>
      > >>>
      > >>I strongly disagree with the first point - RDF buys a *lot*. As a
      > >>
      > >>
      > >little
      > >
      > >
      > >>example, how about a syndication feed that includes foaf-type
      data.
      > >>
      > >>
      > >Trying
      > >
      > >
      > >>to augment feeds without something like RDF will get very messy,
      > >>
      > >>
      > >very
      > >
      > >
      > >>quickly.
      > >>
      > >>
      > >
      > >RDF buys nothing if the business hasn't the need for either the
      > >persistence or the complexity. I'm a huge fan of RDF, but I'm not
      a
      > >good friend of the spec if I insist on its use where not
      appropriate.
      > >And I can't tell, because I don't know what this group wants to
      > >accomplish? An alternative syndication feed format? Doesn't work.
      > >Something more? Than what.
      > >
      > >
      > >
      > >>You're right about the potential damage though.
      > >>
      > >>
      > >>
      > >>>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?
      > >>>
      > >>>
      > >>I think it transcends *existing* syndication feeds, throwaway or
      > >>
      > >>
      > >not. But I
      > >
      > >
      > >>think the core 'business' as you put it is still syndication. Ok,
      > >>
      > >>
      > >the
      > >
      > >
      > >>audience is people that want to generate, aggregate or read feeds.
      > >>
      > >>
      > >>
      > >
      > >Then why would there ever need to be a persistence to it?
      > >
      > >
      > >
      > >>>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 is a specification we're talking about, so it is impossible
      to
      > >>
      > >>
      > >define
      > >
      > >
      > >>all the uses it could be put to. But it is possible to say that
      > >>
      > >>
      > >we're
      > >
      > >
      > >>talking about transmitting and processing data of a 'news-like'
      > >>
      > >>
      > >nature.
      > >
      > >
      > >>Being able to process/aggregate this data in a versatile fashion,
      > >>
      > >>
      > >as well as
      > >
      > >
      > >>combine it with data of other kinds (like foaf) are the
      advantages
      > >>
      > >>
      > >of RDF.
      > >
      > >
      > >
      > >Why combine it with FOAF? Because this was the meme of the minute
      > >this weekend?
      > >
      > >
      > >
      > >>Again I'm not sure about the question - consider HTTP for a
      moment,
      > >>
      > >>
      > >now ask
      > >
      > >
      > >>of it "Who is your audience? Not the tool developers...".
      > >>
      > >>
      > >>
      > >
      > >Not the tool developers. The tool developers created tools that
      > >procecessed the HTML for the true end users -- the people who read
      > >the web pages.
      > >
      > >This is no different then an application one builds for an
      insurance
      > >company. Who is the XML for in this case? Or the C++? Or the
      > >database. The developers use the technology to build the
      application
      > >to meet the business of the 'users' -- the end consumers.
      > >
      > >
      > >
      > >>>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.
      > >>>
      > >>>
      > >>I think the matter of interest is syndication feeds, and their
      > >>
      > >>
      > >processing.
      > >
      > >
      > >>This includes the techniques of current throwaway feeds,
      > >>
      > >>
      > >aggregration and
      > >
      > >
      > >>viewing. Defining the publication units is one of the
      requirements.
      > >>
      > >>
      > >>
      > >>>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.
      > >>>
      > >>>
      > >>Perhaps one of the reasons the justification is repeated over and
      > >>
      > >>
      > >over is to
      > >
      > >
      > >>counter statements like :
      > >>"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..."
      > >>
      > >>
      > >>
      > >
      > >RDF doesn't fit throwaway syndication feeds. And I still am not
      > >reading a true justification for the use of RDF. Because it might
      > >help with combining with FOAF? Why? Because RDF/RSS provides
      > >information nothing else does? Sorry, Dublin does a damn good job
      of
      > >this if you're talking about information about a published item.
      > >
      > >If you're saying that we need a specification that defines
      > >publication units smaller than that defined by Dublin, and that
      > >persists beyond the lifespan of RSS, because there is, currently,
      no
      > >RDF vocabularly that can be included with something such as a
      weblog
      > >posting, which can multiply occur in a page, then we're talking
      > >something different than "syndication/aggregation". Aren't we?
      > >
      > >I am probably a bigger _believer_ in RDF than many people in this
      > >group. But using it just to use it for some possible future good --

      > >no, this isn't working any longer.
      > >
      > >Shelley
      > >
      > >
      > >
      > >To unsubscribe from this group, send an email to:
      > >rss-dev-unsubscribe@e...
      > >
      > >
      > >
      > >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.