Subject: Article importance

From: "Johan H. Borg" <[email-masked]>
Date: Tue, 19 Oct 2004 19:28:13 +0200

Hi,

I'm new on the list, this may have been discussed earlier but I couldn't  
find anything about it easily.

This question may or may not be relevant to this forum, but hopefully to  
some of its subscribers..

One thing that annoys me with RSS and Atom is this:
There doesn't seem to be any way to indicate the relative importance of an  
article in a feed (?).

Background:
In e-mail there is the "Importance:" header, which in general isn't very  
usable since it's only used by a few senders, and those who use it tend to  
misuse it (like claiming that all their messages are important).

For Atom it makes a whole lot more sense: When I subscribe to a feed I may  
not be interested in every single entry. OK, I may have a different  
definition of importance than the editor, but in many cases the editor  
will be able to say that this is the main headline of the day.

Advantages:
 From a user interface perspective, knowing the relative importance of each  
entry in a feed can allow the receiving client to show a list of only the  
X most important items for each subscribed feed that day. This would be of  
great help not only on the desktop, but maybe in particular on a mobile  
device, where screen estate is of higher importance.

It would also make it possible to warn the end user about important events  
without disturbing them when only minor updates are available. I believe  
this could enhance the user experience significantly.

Implementation:
Add something like an atom:importance element. The value could be from 1  
to number of items in the feed, where 1 is the most important entry.  
Another way would be to let the author decide the value individually for  
each entry, from 1 to 10, where 10 is the most important. In either case  
it's easy for the client to compare the value against the average  
importance in the feed that day.

Comments?

Johan.

---

From: Robert Sayre <[email-masked]>
Date: Tue, 19 Oct 2004 13:42:31 -0400

Johan H. Borg wrote:
> There doesn't seem to be any way to indicate the relative importance of 
> an  article in a feed (?).
> 

> In e-mail there is the "Importance:" header, which in general isn't 
> very  usable since it's only used by a few senders, and those who use it 
> tend to  misuse it (like claiming that all their messages are important).
> 
> 
> Comments?

Hi Johan, thanks for the suggestion. This sounds like a good candidate 
for an extension element (that would be useful for both Atom and RSS).

The header for importance is usually "X-Priority", isn't it? For 
example, I generally turn off such alerts because I don't find them 
useful. Leaving these things for extensions lets the market decide.

Robert Sayre

---

From: Brian Skahan <[email-masked]>
Date: Tue, 19 Oct 2004 15:44:46 -0400

> useful. Leaving these things for extensions lets the market decide.

Sadly, I think this would just get misused, even as an extension.  I
think the better solution is for clients to learn what you think is
important.

-Brian

-- 
Brian Skahan
http://bskahan.etria.com

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 19 Oct 2004 17:23:23 -0400

Johan H. Borg wrote:
> There doesn't seem to be any way to indicate the relative
> importance of an article in a feed (?).
	If you dig into this thought a bit, I think you'll find some very
difficult questions to answer. For instance, what is the scope of any metric
of importance? What is it that you mean when you say "a feed"? Are you
speaking of the conceptual "feed" that is the series of all entries that
have been published since the "feed" was created and will be published to
the feed in the future? Or, are you referring to just those items that might
be in a particular instance of an Atom file? (i.e. a sliding window on the
head of the feed) If you are referring to an Atom file, then how would
importance be handled if the entries are individually copied into an
aggregate feed or distributed one at a time via a protocol such as "Atom
over XMPP?" Given that more and more people are using RFC3229+feed[1] when
publishing and retrieving Atom feeds, the idea of "Atom file" begins to make
less and less sense. How can a file specific concept be maintained if
different clients have different ideas of what constitutes the file?
	If you have a fixed scale of importance (perhaps 1 to 10), then what
do you do when you publish a new entry whose "importance" is greater than
all previously published entries yet you've already used the highest measure
for something in the past? Can the scale of importance be anything other
than open ended? Importance may tend to decay over time. Would you define
such a decay function? Sometimes, the importance of an old entry might be
considered to increase after it is published. If this happens, would you
have people republish items to adjust their importance metrics?
	It is best to think of Atom in terms of entries, not feeds. Remember
the slogan: "It's the Entries, Stupid!"...

		bob wyman

[1] http://bobwyman.pubsub.com/main/2004/09/implementations.html
http://bobwyman.pubsub.com/main/2004/09/using_rfc3229_w.html

---

From: Danny Ayers <[email-masked]>
Date: Tue, 19 Oct 2004 23:25:09 +0200

I'd go with Robert on this one - it's a good idea, appropriate for an
extension (probably not using X-Priority as such). Thing is that there
are also a lot of other potential value scales that could usefully be
delivered - if the app was a project manager you might have separate 
'urgency' and 'importance' measures.

A couple of other possibles I've been mulling over (for some
client-side stuff) are 'relevance' and 'proximity'. Relevance to a
particular topic could be used for filtering the cat photos out of
Planet Goldfish, for instance. Proximity I was thinking of in terms of
a kind of combined/generalised measure between two entities (entries,
people, events, whatever), again for filtering down info overload.

Cheers,
Danny.
-- 

http://dannyayers.com

---

From: Danny Ayers <[email-masked]>
Date: Wed, 20 Oct 2004 00:05:51 +0200

On Tue, 19 Oct 2004 17:23:23 -0400, Bob Wyman <[email-masked]> wrote:
 Importance may tend to decay over time. Would you define
> such a decay function? 

I believe the Knobot aggregator does just that:

http://wymiwyg.org/knobot

> the slogan: "It's the Entries, Stupid!"...

Yup. Probably the worst sounding but most useful slogan this century...

-- 

http://dannyayers.com

---

From: "Johan H. Borg" <[email-masked]>
Date: Thu, 21 Oct 2004 16:43:58 +0200

Hi again,

Thanks for great feedback everyone! I agree that this is likely a  
candidate for an extension.

> than open ended? Importance may tend to decay over time. Would you define

The end-user client could define such a function any way it wants to and  
it even depends on the use case. Sometimes you just want to know which are  
the most important entries received the last hour so you can display the  
breaking news from several sources combined. In this case importance falls  
to Normal after an hour, for other uses you may choose a different decay  
function.

> Sometimes, the importance of an old entry might be

They do today, sometimes just to fix a typo (you see this a lot in feeds  
 from online newspapers..). On the other hand, if the importance of an  
event increases, it would typically be because of new information, so a  
new entry makes sense.

Thanks,

Johan.

---

From: "Bob Wyman" <[email-masked]>
Date: Thu, 21 Oct 2004 12:10:09 -0400

Johan H. Borg wrote:
> The end-user client could define such a[n importance decay]
> function any way it wants to and  it even depends on the use case.
	What the client does won't impact the protocol or the data provided
by a publisher. What I'm concerned about is any proposal that would have
publishers regularly modify importance-metrics that might be part of an Atom
entry. If this was done, then most clients would probably decide that the
entry was "modified" and would display it as a new entry. The result would
be a user perception of an increase in duplicate entries (distinguished only
by importance-metrics) as well as the counter-intuitive result that if you
*lowered* the importance-metric for an item, it would tend to be treated by
many clients as "important" because it was recently modified.
	In the worst case, one might implement an importance-metric that
caused the importance-metrics of all items to be modified whenever any new
item was modified. Even worse would be something like a publisher-side
system that caused entries to be regularly republished with modified
time-dependent importance-metrics on some sort of schedule. The result could
be that *all* entries in a feed appear to be "modified" every time that feed
is fetched. The effect would be something like that which results from the
"spam-blogs" that currently update the dates of all their entries every time
the feed is fetched. This would not be good.
	My personal feeling is that if an importance-metric is provided, it
should only rank the current entry in terms of previously published entries
-- not entries published in the future. Thus, importance should be a metric
of "importance at the time of publishing." It should not change over time
unless a modification to some other element in the entry is changed and the
entry republished for some purpose other than modifying its importance.
	In any case, I think you will find it very difficult to produce
"cross-feed" importance measures that are meaningful. Thus,
importance-metrics are likely to be ignored by aggregate feed generators.
They should be considered, at best, blog-local metrics.

		bob wyman