Re: "Top 10" and other lists should be entries, not feeds.

[Danny Ayers]

On 8/31/05, Danny Ayers <[EMAIL PROTECTED]> wrote:

Correction:

> I doubt there's much difference in terms of effort needed to support
> either the per-entry or in-entry approaches. Capabilities of the
> client might make a lot of difference though 

=>

> I doubt there's much difference in terms of effort needed for a publisher to 
> support
> either the per-entry or in-entry approaches. Capabilities of the
> client might make a lot of difference though 

Also what I didn't ask was - as these approaches are already supported
by the Atom format, what's the point of dispute, the aim of this
discussion?

Cheers,
Danny.

-- 

http://dannyayers.com

Re: "Top 10" and other lists should be entries, not feeds.

[Danny Ayers]

On 8/30/05, Bob Wyman <[EMAIL PROTECTED]> wrote:

> No. I'm saying that if Netflix switches over to Atom, what they
> should do is insert the Queue information, as a list, into a single entry
> within the feed.

Correct me if I'm wrong, but doesn't Atom already support this, along
with pretty much every other approach?

Entries in an individual feed document are unordered. The client can
derive a well-defined order from the dates (or have something
considerably less controlled going per doc changes). That's for date
order.

But the client could sort entries according to some other derived
order - e.g. alphabetically by title or content or by size.

Or by value of the x:priority element on each entry, with perhaps a
later entry flagged 2 replacing the current
entry with an element with that value.

Or by interpretation of something like:


...
http://www.w3.org/1999/xhtml"; ...>
   
   Number One
   Number Two
...
   

...


( - is that the kind of thing you had in mind, Bob?)

Another alternative would be:


...
whatever
...




...


i.e. having the list order provided in a single entry, but through
extensions rather than in the content. There's a load of other
alternatives to - adding "next" and "previous" URI links, labelled
with whatever axis the sort order is over.

I doubt there's much difference in terms of effort needed to support
either the per-entry or in-entry approaches. Capabilities of the
client might make a lot of difference though - expressing the order in
XHTML might be more client-friendly than using something like RDF/XML
or any other hard-to-view format.

With the aggregator code I've been playing with recently the list
approach might be marginally easier to support, as it could be XSLT'd
across to an rdf:List. Sorting on an x:sortPosition kind of element
could be trickier as that would need to be considered in combination
with the date, but then again joins may be more flexible.
  
Cheers,
Danny.

-- 

http://dannyayers.com

Re: "Top 10" and other lists should be entries, not feeds.

[Dan Brickley]

Peter Saint-Andre wrote:


Walter Underwood wrote:

--On August 30, 2005 1:49:57 AM -0400 Bob Wyman <[EMAIL PROTECTED]> 
wrote:



I’m sorry, but I can’t go on without complaining. Microsoft has 
proposed
extensions which turn RSS V2.0 feeds into lists and we’ve got folk 
who are
proposing much the same for Atom (i.e. stateful, incremental or 
partitioned
feeds)… I think they are wrong. Feeds aren’t lists and Lists 
aren’t feeds.




The Atom spec says:

This specification assigns no significance to the order of atom:entry
elements within the feed.

One could read that to mean that feeds are fundamentally unordered or 
that

Atom doesn't say what the order means.



Is not logical order, if any, determined by the datetime of the 
published (or updated) element?


Often it makes sense for the order to come from properties of the things
described by the items/entries, rather than publication dates. Examples:
movie listings, job listings, photos by image creation rather than upload
time, etc. Generally, feeds that aren't blog content but are views into some
database, ie. the same kinds of feed that are most likely to use 
data-centric

markup extensions.

Atom allows such orderings to be exposed, without requiring that a
machine-friendly justification be given. Seems about right to me.

cheers,

Dan

Re: "Top 10" and other lists should be entries, not feeds.

[Eric Scheid]

On 31/8/05 7:50 AM, "Peter Saint-Andre" <[EMAIL PROTECTED]> wrote:

> Is not logical order, if any, determined by the datetime of the
> published (or updated) element?

No. I've seen a few things online where they publish chapter 3 first,
followed by chapter 8, and then go back and fill in the blanks. And then
update chapter 2.

Sometimes there are good reasons for this, strangely enough.

Leaving aside completely the idea of publishing a chunk, followed by more
chunks, and *then* re-arranging them into some semblance of logical order
once they know what content they have.

e.

Re: "Top 10" and other lists should be entries, not feeds.

[Eric Scheid]

On 31/8/05 6:01 AM, "Mark Nottingham" <[EMAIL PROTECTED]> wrote:

> It sounds like you've got use cases for Atom that other use cases
> (e.g., lists) make difficult to work with. Banning those other use
> cases makes things easier for you, but I don't think it's good for
> Atom overall.

those other use cases are also a good example of some feeds which shouldn't
be devoured by robots.

e.

Re: "Top 10" and other lists should be entries, not feeds.

[James M Snell]

Or.. perhaps 1

http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-index-01.txt

- James

Henry Story wrote:



It's late here, but since I have been called...

Clearly the order of the entries could not be deduced from the tags  
themselves.

One would need to have an extra tag in there such as this  tag


   
  tag:first-in-list
  1
  The Graphes of Wrath
  1 July 2005
  ...
   
   ...

to specify the order of the entry. I think at the time I was talking  
in the context

of that being proposed.

Again it is late, but I think my idea of having a entry always stay  
at the same position
was that I was thinking that from one week to another one could just  
change the content

of the entry


   
  tag:first-in-list
  1
  Of Mice and Men
  8 July 2005
  ...
   


So that one could still think of a feed as a sequence of changes to  
resources. One
would then, I thought, not need to republish the whole list of  
entries, just
those that changed from week to week. As a result there was I  
thought, no need for

a  tag.

But the problem with that suggestion was that it could not cope well  
with mistaken
feed updates. So that if I mistakenly entered "Of Mice and Men" but I  
meant to
enter "The Restaurant at the End of the Universe" then adding the  
following entry



   
  tag:first-in-list
  1
  The Restaurant at the end of the Universe
  8 July 2005
  ...
   



would tend to indicate that the change was insignificant, whereas a  
change
of date would tend to indicate that the there was a new entry in  
first position.


Some proposed that one should distinguish therefore between the  
update time of the

entry and the update time of the object of the entry...

Henry

Re: "Top 10" and other lists should be entries, not feeds.

[Henry Story]

It's late here, but since I have been called...

Clearly the order of the entries could not be deduced from the tags  
themselves.

One would need to have an extra tag in there such as this  tag


   
  tag:first-in-list
  1
  The Graphes of Wrath
  1 July 2005
  ...
   
   ...

to specify the order of the entry. I think at the time I was talking  
in the context

of that being proposed.

Again it is late, but I think my idea of having a entry always stay  
at the same position
was that I was thinking that from one week to another one could just  
change the content

of the entry


   
  tag:first-in-list
  1
  Of Mice and Men
  8 July 2005
  ...
   


So that one could still think of a feed as a sequence of changes to  
resources. One
would then, I thought, not need to republish the whole list of  
entries, just
those that changed from week to week. As a result there was I  
thought, no need for

a  tag.

But the problem with that suggestion was that it could not cope well  
with mistaken
feed updates. So that if I mistakenly entered "Of Mice and Men" but I  
meant to
enter "The Restaurant at the End of the Universe" then adding the  
following entry



   
  tag:first-in-list
  1
  The Restaurant at the end of the Universe
  8 July 2005
  ...
   



would tend to indicate that the change was insignificant, whereas a  
change
of date would tend to indicate that the there was a new entry in  
first position.


Some proposed that one should distinguish therefore between the  
update time of the

entry and the update time of the object of the entry...

Henry


On 30 Aug 2005, at 23:35, Thomas Broyer wrote:

Bob Wyman wrote:



I’m sorry, but I can’t go on without complaining. Microsoft has  
proposed extensions which turn RSS V2.0 feeds into lists and we’ve  
got folk who are proposing much the same for Atom (i.e. stateful,  
incremental or partitioned feeds)… I think they are wrong. Feeds  
aren’t lists and Lists aren’t feeds. It seems to me that if you  
want a “Top 10” list, then you should simply create an entry that  
provides your Top 10. Then, insert that entry in your feed so that  
the rest of us can read it. If you update the list, then just  
replace the entry in your feed. If you create a new list (Top 34?)  
then insert that in the feed along with the “Top10” list.




Henry Story also proposed atom:id to be "order-related":
http://www.w3.org/2005/Atom";>
...

tag:first-in-list
Some entry
...


tag:second-in-list
Another entry
...



and a bit later:
http://www.w3.org/2005/Atom";>
...

tag:first-in-list
Another entry
...


tag:second-in-list
Yet another entry
...



Note how tag:first-in-list entry now represents "Another entry"  
while it were previously "Some entry", and tag:second-in-list now  
is "Yet another entry" while it were "Another entry".


--
Thomas Broyer

Re: "Top 10" and other lists should be entries, not feeds.

[A. Pagaltzis]

* Thomas Broyer <[EMAIL PROTECTED]> [2005-08-30 23:40]:
> Henry Story also proposed atom:id to be "order-related":

Indeed, and together with an extension for expiring entries, the
Netflix use case should be pretty well covered.

Regards,
-- 
Aristotle Pagaltzis // 

Re: "Top 10" and other lists should be entries, not feeds.

[Graham]

On 30 Aug 2005, at 11:19 pm, Mark Nottingham wrote:

I'd say an ordered list *can be* an entry that gets updated  
regularly. There's absolutely no reason that Netflix can't have one  
DVD-per-entry, and it's not a hack.


Well it depends. The basic paradigm for a feed is as a newswire of  
recently posted or updated entries, which works pretty well. For the  
netflix queue to work, you have to take a step beyond that and view  
the feed file as a document and not just an envelope. It's not  
necessarily a hack, but it's a totally different paradigm.


Graham

Re: "Top 10" and other lists should be entries, not feeds.

[Tim Bray]

On Aug 30, 2005, at 3:08 PM, Walter Underwood wrote:


That is one kind of order. Other kinds are relevance to a search term
(A9 OpenSearch), editorial importance (BBC News feeds), or datetime of
original publication (nearly all blog feeds, not the same as last  
update).


Well put.  It's obvious that there exist feeds that have ordering  
requirements that are orthogonal to atom:updated.


It's plausible, but not obvious, that the first two kinds of order  
Walter enumerates are instances of a class which we might label  
"importance" or "priority".  It's also plausible, but even less  
obvious, that there are going to be lots of places where non-updated  
order matters in a way that has to do with "importance", to the  
extent that a generally-implemented extension will be useful.  It's  
also plausible, but not obvious, that there's no usefully- 
generalizable notion of "importance", that the semantics of this  
stuff are really application-specific, and that interested parties  
should go and do their own NetFlix or A9 or BBC extensions.  Or just  
cram your Netflix queue in a single entry.


Fortunately, the format spec, with its "assigns no significance"  
language, doesn't get in the way of people who want to work on this  
problem.  I can see two generalized approaches; the first is a  
singleton attribute of child of  that says "in this feed,  
 order reflects importance".  The second is such an  
attribute that says "in this feed, an ordering by the following  
namespaced-element child of  reflects importance".  I  
prefer the first.  I haven't looked at the Microsoft proposal.


Clearly, the WG lacks consensus, at least in the short term. -Tim

Re: "Top 10" and other lists should be entries, not feeds.

[Mark Nottingham]

I'd say an ordered list *can be* an entry that gets updated  
regularly. There's absolutely no reason that Netflix can't have one  
DVD-per-entry, and it's not a hack.



On 30/08/2005, at 2:04 PM, Graham wrote:

But conceptually Bob is absolutely correct. An ordered list is just  
an entry that gets updated regularly. There's absolutely no reason  
for Netflix to create an individual entry for each DVD. It's a hack  
that makes it look better in most aggregators. Nothing more.



--
Mark Nottingham http://www.mnot.net/

Re: "Top 10" and other lists should be entries, not feeds.

[Walter Underwood]

--On August 30, 2005 3:50:45 PM -0600 Peter Saint-Andre <[EMAIL PROTECTED]> 
wrote:
>> One could read that to mean that feeds are fundamentally unordered or that
>> Atom doesn't say what the order means.
> 
> Is not logical order, if any, determined by the datetime of the published
> (or updated) element?

That is one kind of order. Other kinds are relevance to a search term
(A9 OpenSearch), editorial importance (BBC News feeds), or datetime of
original publication (nearly all blog feeds, not the same as last update).

wunder
--
Walter Underwood
Principal Software Architect, Verity

Re: "Top 10" and other lists should be entries, not feeds.

[Walter Underwood]

--On August 30, 2005 3:50:45 PM -0600 Peter Saint-Andre <[EMAIL PROTECTED]> 
wrote:
>> Otherwise, it is not possible to go from Atom to RSS 1.0.
> 
> I assume you mean from RSS 1.0 to Atom. :-)

No. You can go from a Bag to List by ignoring the order. RSS 1.0 is a
List, so you would need to invent an order to put unordered items in it.

wunder
--
Walter Underwood
Principal Software Architect, Verity

Re: "Top 10" and other lists should be entries, not feeds.

[Peter Saint-Andre]

Walter Underwood wrote:

--On August 30, 2005 1:49:57 AM -0400 Bob Wyman <[EMAIL PROTECTED]> wrote:



I’m sorry, but I can’t go on without complaining.  Microsoft has proposed
extensions which turn RSS V2.0 feeds into lists and we’ve got folk who are
proposing much the same for Atom (i.e. stateful, incremental or partitioned
feeds)… I think they are wrong. Feeds aren’t lists and Lists aren’t feeds.



The Atom spec says:

   This specification assigns no significance to the order of atom:entry
   elements within the feed.

One could read that to mean that feeds are fundamentally unordered or that
Atom doesn't say what the order means.


Is not logical order, if any, determined by the datetime of the 
published (or updated) element?



Other RSS formats are ordered, either implicitly or explicity (RSS 1.0).
For interoperatility, lots of software is going to treat Atom as ordered.
Otherwise, it is not possible to go from Atom to RSS 1.0.


I assume you mean from RSS 1.0 to Atom. :-)

Peter

--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml


smime.p7s
Description: S/MIME Cryptographic Signature

Re: "Top 10" and other lists should be entries, not feeds.

[Walter Underwood]

--On August 30, 2005 1:49:57 AM -0400 Bob Wyman <[EMAIL PROTECTED]> wrote:

> I’m sorry, but I can’t go on without complaining.  Microsoft has proposed
> extensions which turn RSS V2.0 feeds into lists and we’ve got folk who are
> proposing much the same for Atom (i.e. stateful, incremental or partitioned
> feeds)… I think they are wrong. Feeds aren’t lists and Lists aren’t feeds.

The Atom spec says:

   This specification assigns no significance to the order of atom:entry
   elements within the feed.

One could read that to mean that feeds are fundamentally unordered or that
Atom doesn't say what the order means.

Other RSS formats are ordered, either implicitly or explicity (RSS 1.0).
For interoperatility, lots of software is going to treat Atom as ordered.
Otherwise, it is not possible to go from Atom to RSS 1.0.

> What is a search engine or a matching engine supposed to return as a resul
>  if it find a match for a user query in an entry that comes from a list-feed?

Maybe the list feed should have a noindex flag.

> Should it return the entire feed or should it return just the entry/item
> that contained the stuff in the users’ query?

I'd return the entry. It is all about the entries. If the list position is
semantically important to the entry, then include a link from the entry to
the list. "This is movie 312 in wunder's queue."

wunder
--
Walter Underwood
Principal Software Architect, Verity

Re: "Top 10" and other lists should be entries, not feeds.

[Thomas Broyer]

Bob Wyman wrote:


I’m sorry, but I can’t go on without complaining. Microsoft has 
proposed extensions which turn RSS V2.0 feeds into lists and we’ve got 
folk who are proposing much the same for Atom (i.e. stateful, 
incremental or partitioned feeds)… I think they are wrong. Feeds 
aren’t lists and Lists aren’t feeds. It seems to me that if you want a 
“Top 10” list, then you should simply create an entry that provides 
your Top 10. Then, insert that entry in your feed so that the rest of 
us can read it. If you update the list, then just replace the entry in 
your feed. If you create a new list (Top 34?) then insert that in the 
feed along with the “Top10” list.



Henry Story also proposed atom:id to be "order-related":
http://www.w3.org/2005/Atom";>
...

tag:first-in-list
Some entry
...


tag:second-in-list
Another entry
...



and a bit later:
http://www.w3.org/2005/Atom";>
...

tag:first-in-list
Another entry
...


tag:second-in-list
Yet another entry
...



Note how tag:first-in-list entry now represents "Another entry" while it 
were previously "Some entry", and tag:second-in-list now is "Yet another 
entry" while it were "Another entry".


--
Thomas Broyer

RE: "Top 10" and other lists should be entries, not feeds.

[Bob Wyman]

Mark Nottingham wrote:
>Are you saying that when/if Netflix switches over to Atom, they
> shouldn't use it for the Queue?
No. I'm saying that if Netflix switches over to Atom, what they
should do is insert the Queue information, as a list, into a single entry
within the feed. 
This will not only preserve the nature of Atom feeds as "feeds" but
also allow NetFlix a number of new and potentially interesting opportunities
for providing data to customers. Most important among these will be the
ability to include multiple lists in the feed (i.e. in addition to the
Queue, they could also include their "Top 10" list as well as a set of
"recommendations" based on user experience. They might even include a list
of "10 most recent transactions on your account") Each list would be a
distinct entry. To make life easier on aggregators, each entry "type" should
probably use the same atom:id across "versions." This allows the aggregators
to discard earlier, now out of date entries.
NetFlix would also be able to intermix information such as the
"Queue List" with non-list entries. For instance, they might have a "Message
from NetFlix" that they want to include in the feed or, they might include a
series of movie reviews that were carefully selected for the specific user.
Basically, by using entries for lists instead of converting the
entire feed into a list, NetFlix is able to offer a much richer and much
more satisfying experience to their users.
The ability of Atom to carry both lists and non-lists as entries
means that Atom is able to offer a much more flexible and powerful mechanism
to NetFlix than can be had from the less-capable RSS V2.0 solution. I think
that if I were NetFlix, I would want to have the opportunity to experiment
with and find ways to exploit this powerful capability. The richer the
opportunity for communications between NetFlix and their customers, the
greater the opportunity they have to generate revenues.
The alternative to using entries rather than feeds would be creating
multiple feeds per user. That strikes me as a solution which is ugly on its
face and unquestionably increases the complexity of the system for both
NetFlix and its customers. The "list-in-entry" solution is much more elegant
and much more powerful.

bob wyman

Re: "Top 10" and other lists should be entries, not feeds.

[Graham]

On 30 Aug 2005, at 9:01 pm, Mark Nottingham wrote:

It sounds like you've got use cases for Atom that other use cases  
(e.g., lists) make difficult to work with. Banning those other use  
cases makes things easier for you, but I don't think it's good for  
Atom overall.


But conceptually Bob is absolutely correct. An ordered list is just  
an entry that gets updated regularly. There's absolutely no reason  
for Netflix to create an individual entry for each DVD. It's a hack  
that makes it look better in most aggregators. Nothing more.


It would be good if Atom were flexible enough to cope where there  
isn't a 1:1 mapping between publications and items of information, by  
subdividing entries into chapters or something, but as Mark Pilgrim  
said somewhere, Atom deals with none of the interesting problems with  
syndication (Atom = RSS3).


Graham

Re: "Top 10" and other lists should be entries, not feeds.

[James M Snell]

Mark Nottingham wrote:



Sorry, Bob I disagree. I tried to introduce a rigid concept of what a  
feed is much earlier, and people pushed back; as a result, Atom  
doesn't have a firm definition of the nature of a feed. As a result,  
we can't go and say what it can't be at a later date.


Besides which, I think the use cases for Atom-as-list are powerful,  
and just beginning to be seen. E.g., Netflix allows you to subscribe  
to your Queue:

  http://www.netflix.com/RSSFeeds

Are you saying that when/if Netflix switches over to Atom, they  
shouldn't use it for the Queue?


It sounds like you've got use cases for Atom that other use cases  
(e.g., lists) make difficult to work with. Banning those other use  
cases makes things easier for you, but I don't think it's good for  
Atom overall.



+1 on every point.

- James

Re: "Top 10" and other lists should be entries, not feeds.

[Mark Nottingham]

Sorry, Bob I disagree. I tried to introduce a rigid concept of what a  
feed is much earlier, and people pushed back; as a result, Atom  
doesn't have a firm definition of the nature of a feed. As a result,  
we can't go and say what it can't be at a later date.


Besides which, I think the use cases for Atom-as-list are powerful,  
and just beginning to be seen. E.g., Netflix allows you to subscribe  
to your Queue:

  http://www.netflix.com/RSSFeeds

Are you saying that when/if Netflix switches over to Atom, they  
shouldn't use it for the Queue?


It sounds like you've got use cases for Atom that other use cases  
(e.g., lists) make difficult to work with. Banning those other use  
cases makes things easier for you, but I don't think it's good for  
Atom overall.


Cheers,


On 29/08/2005, at 10:49 PM, Bob Wyman wrote:


I’m sorry, but I can’t go on without complaining.  Microsoft has  
proposed extensions which turn RSS V2.0 feeds into lists and we’ve  
got folk who are proposing much the same for Atom (i.e. stateful,  
incremental or partitioned feeds)… I think they are wrong. Feeds  
aren’t lists and Lists aren’t feeds. It seems to me that if you  
want a “Top 10” list, then you should simply create an entry that  
provides your Top 10. Then, insert that entry in your feed so that  
the rest of us can read it. If you update the list, then just  
replace the entry in your feed. If you create a new list (Top 34?)  
then insert that in the feed along with the “Top10” list.


What is the problem? Why don’t folk see that lists are the stuff of  
entries – not feeds? Remember, “It’s about the entries, Stupid…”


I think the reason we’ve got this pull to turn feeds into Lists is  
simply because we don’t have a commonly accepted “list” schema. So,  
the idea is to repurpose what we’ve got. Folk are too scared or  
tired to try to get a new thing defined and through the process, so  
they figure that they will just overload the definition of  
something that already exists. I think that’s wrong. If we want  
“Lists” then we should define lists and not muck about with Atom.  
If everyone is too tired to do the job properly and define a real  
list as a well defined schema for something that can be the payload  
of a content element, then why not just use OPML as the list format?




What is a search engine or a matching engine supposed to return as  
a result if it find a match for a user query in an entry that comes  
from a list-feed? Should it return the entire feed or should it  
return just the entry/item that contained the stuff in the users’  
query? What should an aggregating intermediary like PubSub do when  
it finds a match in an element of a list-feed? Is there some way to  
return an entire feed without building a feed of feeds? Given that  
no existing aggregator supports feeds as entries, how can an  
intermediary aggregator/filter return something the client will  
understand?


You might say that the search/matching engine should only present  
the matching entry in its results. But, if you do that what happens  
is that you lose the important semantic data that comes from  
knowing the position the matched entry had in the original list- 
feed. There is no way to preserve that order-dependence information  
without private extensions at present.


I’m sorry but I simply can’t see that it makes sense to encourage  
folk to break important rules of Atom by redefining feeds to be  
lists. If we want “lists” we should define what they look like and  
put them in entries. Keep your hands off the feeds. Feeds aren’t  
lists – they are feeds.




bob wyman










--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems



--
Mark Nottingham http://www.mnot.net/

Re: "Top 10" and other lists should be entries, not feeds.

[Henry Story]

Mhh. Good point too.

For some reason though, this is starting to make me think that a feed  
is an entry again...


Henry

On 30 Aug 2005, at 13:23, Graham wrote:


How would this apply to the most problematic example of a list  
feed, the BBC news headline page:


http://newsrss.bbc.co.uk//rss/newsonline_uk_edition/front_page/rss.xml

Which has the top stories first (amongst other structure) and is a  
hell of a lot more usable in news readers that preserve order.


Graham

Re: "Top 10" and other lists should be entries, not feeds.

[Graham]

How would this apply to the most problematic example of a list feed,  
the BBC news headline page:


http://newsrss.bbc.co.uk//rss/newsonline_uk_edition/front_page/rss.xml

Which has the top stories first (amongst other structure) and is a  
hell of a lot more usable in news readers that preserve order.


Graham

Re: "Top 10" and other lists should be entries, not feeds.

[Henry Story]

+1 I completely agree with Bob again.

Though my preference of course would be to put RDF in the content.
RDF has structures for ordered lists. It probably has vocabularies  
for songs.
It has vocabulary to specify the author of a work, etc... And with  
foaf you
could also specify which of the artists was your friend. In short you  
can

mix the different RDF vocabularies out there in well understood ways.

For those of you new to RDF but au fait with Java, I have just  
written up a blog

that should help explain exactly why RDF is so powerful:

http://blogs.sun.com/roller/page/bblfish? 
entry=java_annotations_the_semantic_web


In short: RDF can be mapped directly onto Java Beans. Just as Beans  
can be plugged
together, so RDF markup can be plugged together. Welcome to the world  
of OO xml.


Henry Story

On 30 Aug 2005, at 07:49, Bob Wyman wrote:
I’m sorry, but I can’t go on without complaining.  Microsoft has  
proposed extensions which turn RSS V2.0 feeds into lists and we’ve  
got folk who are proposing much the same for Atom (i.e. stateful,  
incremental or partitioned feeds)… I think they are wrong. Feeds  
aren’t lists and Lists aren’t feeds. It seems to me that if you  
want a “Top 10” list, then you should simply create an entry that  
provides your Top 10. Then, insert that entry in your feed so that  
the rest of us can read it. If you update the list, then just  
replace the entry in your feed. If you create a new list (Top 34?)  
then insert that in the feed along with the “Top10” list.


What is the problem? Why don’t folk see that lists are the stuff of  
entries – not feeds? Remember, “It’s about the entries, Stupid…”


I think the reason we’ve got this pull to turn feeds into Lists is  
simply because we don’t have a commonly accepted “list” schema. So,  
the idea is to repurpose what we’ve got. Folk are too scared or  
tired to try to get a new thing defined and through the process, so  
they figure that they will just overload the definition of  
something that already exists. I think that’s wrong. If we want  
“Lists” then we should define lists and not muck about with Atom.  
If everyone is too tired to do the job properly and define a real  
list as a well defined schema for something that can be the payload  
of a content element, then why not just use OPML as the list format?




What is a search engine or a matching engine supposed to return as  
a result if it find a match for a user query in an entry that comes  
from a list-feed? Should it return the entire feed or should it  
return just the entry/item that contained the stuff in the users’  
query? What should an aggregating intermediary like PubSub do when  
it finds a match in an element of a list-feed? Is there some way to  
return an entire feed without building a feed of feeds? Given that  
no existing aggregator supports feeds as entries, how can an  
intermediary aggregator/filter return something the client will  
understand?


You might say that the search/matching engine should only present  
the matching entry in its results. But, if you do that what happens  
is that you lose the important semantic data that comes from  
knowing the position the matched entry had in the original list- 
feed. There is no way to preserve that order-dependence information  
without private extensions at present.


I’m sorry but I simply can’t see that it makes sense to encourage  
folk to break important rules of Atom by redefining feeds to be  
lists. If we want “lists” we should define what they look like and  
put them in entries. Keep your hands off the feeds. Feeds aren’t  
lists – they are feeds.




bob wyman

"Top 10" and other lists should be entries, not feeds.

[Bob Wyman]

I’m sorry, but I can’t
go on without complaining.  Microsoft has proposed extensions which turn
RSS V2.0 feeds into lists and we’ve got folk who are proposing much the
same for Atom (i.e. stateful, incremental or partitioned feeds)… I think
they are wrong. Feeds aren’t lists and Lists aren’t feeds. It seems
to me that if you want a “Top 10” list, then you should simply
create an entry that provides your Top 10. Then, insert that entry in your feed
so that the rest of us can read it. If you update the list, then just replace
the entry in your feed. If you create a new list (Top 34?) then insert that in
the feed along with the “Top10” list. 

What is the problem? Why don’t
folk see that lists are the stuff of entries – not feeds? Remember, “It’s
about the entries, Stupid…”

I think the reason we’ve got
this pull to turn feeds into Lists is simply because we don’t have a
commonly accepted “list” schema. So, the idea is to repurpose what
we’ve got. Folk are too scared or tired to try to get a new thing defined
and through the process, so they figure that they will just overload the
definition of something that already exists. I think that’s wrong. If we want
“Lists” then we should define lists and not muck about with Atom.
If everyone is too tired to do the job properly and define a real list as a
well defined schema for something that can be the payload of a content element,
then why not just use OPML as the list format?

 

What is a search engine or a
matching engine supposed to return as a result if it find a match for a user
query in an entry that comes from a list-feed? Should it return the entire feed
or should it return just the entry/item that contained the stuff in the users’
query? What should an aggregating intermediary like PubSub do when it finds a
match in an element of a list-feed? Is there some way to return an entire feed
without building a feed of feeds? Given that no existing aggregator supports
feeds as entries, how can an intermediary aggregator/filter return something the
client will understand? 

You might say that the
search/matching engine should only present the matching entry in its results.
But, if you do that what happens is that you lose the important semantic data
that comes from knowing the position the matched entry had in the original
list-feed. There is no way to preserve that order-dependence information without
private extensions at present.

I’m sorry but I simply can’t
see that it makes sense to encourage folk to break important rules of Atom by
redefining feeds to be lists. If we want “lists” we should define
what they look like and put them in entries. Keep your hands off the feeds.
Feeds aren’t lists – they are feeds.

 

    bob
wyman