Re: [syndication] Re: [radio-userland] Payloads for RSS

["Dave Winer" <dave@userland.com>]

Mark, I'm going to respond on the Syndication list only.

We have a new concept that I haven't seen elsewhere, for lack of a better
term, we're calling it a "content router". I get a stream of items on my
desktop from a multitude of sources. I have an EDIT button on each one which
allows me to pick from an array of categories which in the UI are just
checkboxes. For example I routed the Payloads for RSS story to the RSS
channel and to the Grateful Dead channel (which I think of as an audio
weblog). The categories are entirely up to the user (author). Now here's the
really cool part, each category is an RSS file that can serve as input to
another user-author-content-router-guy. Here are all the RSS files I'm
maintaining, and I'm just one user-author.

http://www.ourfavoritesongs.com/users/dave@userland.com/rss/

I have only an idea of where this going, I think the network effect is going
to be pretty amazing. We have just a handful of people actively doing this
stuff now, but I love the feedback loops that get going. For example when
one of my guys routes something I routed back I know he read it (or at least
I believe he did). This is just one of the nice little deals.

These channels are not synthetic, like the ones that the scraper-aggregators
produce. There are human minds at work here. It's Two-Way at it's core, I'm
not an eyeball, the user-author is a contributor, not a passive participant.

Also, I'm not sure there really are any low bandwidth connections in this
system. I give my agent four hours every night to download stuff. So far
it's only used five minutes of the four hours.

It's a different paradigm. Really.

Dave



----- Original Message -----
From: "Mark Nottingham" <mnot@mnot.net>
To: <syndication@egroups.com>
Cc: <radio-userland@egroups.com>; <decentralization@egroups.com>
Sent: Thursday, January 11, 2001 10:58 PM
Subject: Re: [syndication] Re: [radio-userland] Payloads for RSS


>
> Interesting. Good addition, Dave - this is redefining what a channel
> is, which should make RSS better/stronger.
>
> Thinking aloud, channel discrimination might go three ways (not
> mutually exclusive):
>
> * Each channel is atomic; if you want a channel about the Baltimore
>   Orioles for medium bandwidth connections, you subscribe to
>   "Baltimore Orioles for medium bandwidth connections"
>
> * The user builds the channel. Instead of
>     http://www.example.com/channel.rss
>   the user might request
> http://www.example.com/channel.rss?interests=Orioles,Braves,Yankees
>   where the query args let the user build a dynamic channel according
>   to their interests; of course, the URI can be built by a friendly,
>   web-based (or not) UI.
>
> * The channel contains enough metadata to let the user make decisions
>   about what they want to see (RDF or whatever).
>
> All three should play nicely together; ideally, there'd be some
> information somewhere that would give the client hints about this
> (e.g., the first one would have a pointer to a listing of other
> available channels by the same provider, the second a pointer to the
> web interface for building channels, or a WSDL-ish description of a
> SOAP interface (?), and the third would hopefully be self-contained,
> except for pointers to full schemas for the metadata).
>
> The flip side of that would be a standard meta tag or well-known
> location that allows the easy location of a channel/channel directory
> for a particular site (think I've already seen discussion of this
> somewhere).
>
> RE: transport over email - SOAP/XP allows use of other transport
> bindings, there's been a lot of talk about a SMTP binding. Should be
> easy once that's there.
>
> Cheers,
>
>
> On Thu, Jan 11, 2001 at 10:33:58PM -0800, Jeff Barr wrote:
> > I also like the payload idea. I was just thinking that
> > it might be an interesting email format too, since
> > it would avoid the problem of overly large enclosures.
> >
> > I think the expectation here is that the client program
> > (the one reading the RSS) would either make some decisions
> > or ask the user to make decisions about how to proceed.
> > Dave has thoughtfully provided the type and size
> > information needed to make this possible.
> >
> > For example, it could have rules such as "Download all
> > movies each night", or "Play Sound Files Immediately",
> > or "Wait until late at night to download anything
> > bigger than 1 MB". Or, even more cleverly, "Download
> > any movies where the referenced document includes the
> > string 'George Bush'". That could be kind of cool.
> >
> > I would not expect the client to, by default, "deference
> > all of the pointers" and bring down everything.
> >
> > Note that this client could be a kind of Active Napster,
> > accumulating interesting chunks of out of band content
> > as references to them stream by.
> >
> > Classification seems nice in theory, but remember that
> > each additional piece of information that we add into
> > RSS will make the format more complicated and harder to
> > use, while also bloating the file. A great attribute
> > of RSS is that it is clean, simple, and very easy to
> > produce. I was talking to a VP at the Wall St. Journal
> > yesterday, and she told me that a lot of the value
> > that they add to their syndicated content is in the form
> > of tags for geographic location and stock tickers. They
> > employ editors who do this and nothing else. Most people
> > shipping out RSS are not going to have the wherewithal
> > to do this.
> >
> > Jeff;
> >
> > -----Original Message-----
> > From: David Davies [mailto:d.a.davies@bham.ac.uk]
> > Sent: Thursday, January 11, 2001 5:55 PM
> > To: radio-userland@egroups.com
> > Cc: decentralization@egroups.com; syndication@egroups.com
> > Subject: [syndication] Re: [radio-userland] Payloads for RSS
> >
> >
> > I think this is a truly inspired addition to RSS and will help us in our
use
> > of syndicated data no end. I can't wait to get going with it.
> >
> > One thought though. I can imagine a danger of super-bloat with the
enclosure
> > field in regular RSS channels. Suppose I subscribe to a hypothetical CNN
> > sports news channel and with this new enclosure element all its sports
> > stories come with a video clip of a sports game. Maybe I'm only
interested
> > in following one team let alone one sport yet when I wake up in the
morning
> > I find my personal aggregator (e.g. MyUserland on the Desktop) has
> > downloaded megabytes (tens, hundreds, more?) of videos of stuff I'm just
not
> > interested in. Wow, there goes my hard disk.
> >
> > What's the answer? More specific RSS channels?
> >
> > On the radio-UserLand list we talked a little about further refinement
of a
> > channel's data using a category or keyword element.
> >
> > This is a difficult area because of standardisation of keyword
> > classification systems. At one level (e.g. some professional areas)
there
> > are many standard classification systems in operation. In my own field
of
> > medicine we have an international keyword system making highly specific
data
> > syndication a lot easier. Granted, there is a lack of standardisation in
> > other areas though there are pointers such as Library of Congress or the
> > Dewey decimal system. There will always be other areas (personal weblogs
> > with automatic syndication are a good example) where no classification
> > system is ever going to emerge though maybe with these channels by
> > definition they're more focussed so you may not mind or even get lots of
> > unwanted enclosure elements.
> >
> > This isn't a criticism, I think enclosures are a major leap forward, for
me
> > and our application of RSS at least. Just trying to keep the discussion
> > moving forward.
> >
> > Cheers,
> >
> > David
> >
> >
> >
> >
> >
> >
> >
>
> --
> Mark Nottingham
> http://www.mnot.net/
>
>
>