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

[Mark Nottingham <mnot@mnot.net>]

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/