Subject: Priorities in Atom?

From: Graham <[email-masked]>
Date: Wed, 8 Dec 2004 04:04:03 +0000

I had a random idea the other day that priorities would be a really 
useful thing to have in Atom. Now I'm aware of how useless they are in 
email, but syndication is much less open to abuse. One of the things 
that bugs me about using a newsreader is that all items are the same 
size and the same emphasis, yet if you go somewhere like 
news.bbc.co.uk, someone's carefully planned out the relative sizes of 
each story. This would make newspaper-style view that some readers 
offer much more useful, and would also allow sites that present an 
overview of all feeds the ability to show the top story for each one 
rather than just the latest.

Emphasizing that the priority number is only valid relative to items in 
the same feed should stop most abuse. Anyone interested?

Graham

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 8 Dec 2004 04:35:48 -0500

Graham wrote: 
> priorities would be a really useful thing to have in Atom
	There are many useful values that could be associated with either a
feed or an entry. Rather then focusing on one of them I think we would be
best served by created methods to express classes of them in a predictable
way.
	For instance: 
	1. At PubSub, we would like to insert the "PubSub LinkRank" into
items that we publish. This would allow newsreaders to sort entries based on
the LinkRank of their sources. 
	2. It might be interesting to allow entries or feeds to carry the
current "value" of the feed as listed on the BlogShares.com exchange.
Newsreaders might find this useful for sorting/filtering, etc.
	3. I'd like to insert geo-tags of some sort.
	4. After doing classification of the content of an entry, we'd like
to insert the results into the entry. i.e. indicate which DMOZ
classification our classifier thinks the entry falls under.
	Etc.
	Most of these things could be quite nicely handled by a simple
"tag/value" structure. Something like:

	<prop name="LinkRank">333</prop>
	<prop name="BSValue">$33.03</prop>
	<prop name="classification">politics</prop>
	<prop name="priority">very_high</prop>

	Let's focus on the mechanism for communicating properties rather
then the specific properties that are to be communicated.

		bob wyman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Graham
Sent: Tuesday, December 07, 2004 11:04 PM
To: Atom WG
Subject: Priorities in Atom?

Graham

---

From: Danny Ayers <[email-masked]>
Date: Wed, 8 Dec 2004 11:46:58 +0100

>         <prop name="priority">very_high</prop>

They could be handled this way, but as it stands there isn't any way
of recognising the properties in an unambiguous fashion. I don't think
a centralized registry is the answer either. But if there was a simple
generalized interpretation of material from other namespaces, we can
remove ambiguity and use the XML more like, errm, XML:
e.g. 

<entry ...>
    <pubsub:LinkRank>333</pubsub:LinkRank>
...
</entry>

The spec could contain words to the effect that elements like this
SHOULD be interpreted as a named property of  the enclosing entry, the
value being the child text node. The use of namespaces will avoid
clashes, so this won't be interpreted as the same thing as
<google:PageRank>333</google:PageRank>.

> then the specific properties that are to be communicated.

Yes please. I'd favour something like Robert's PacePropertyDesign
(which would probably find it's way to consensus without the RDF
references).

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Graham <[email-masked]>
Date: Wed, 8 Dec 2004 15:13:29 +0000

Those all seem different and not in the same "class". The key 
difference is that an entry can have an unlimited number of different 
types of those things, whereas it can only have one priority. Currently 
any entry has an inherent relative priority of [average], whereas their 
blogrank or geourl is unknown.

Graham

---

From: Danny Ayers <[email-masked]>
Date: Wed, 8 Dec 2004 17:15:22 +0100

> blogrank or geourl is unknown.

It may well be a good idea to treat priority differently than other
properties, but it's not yet clear what is meant by the term. There's
really quite a lot being assumed - how does priority relate to urgency
and importance? Presumably this will be a publisher-set value, but on
some kind of linear scale? discrete or continuous? global or
site-local?

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Graham <[email-masked]>
Date: Wed, 8 Dec 2004 17:21:52 +0000

On 8 Dec 2004, at 4:15 pm, Danny Ayers wrote:

> and importance?

Importance might be a petter word for it, or prominence maybe. It 
wouldn't be used for QoS-type stuff that prioritizing implies. They'd 
purely be a hint for the UA, which currently has no choice but to 
display all entries the same way.

> Presumably this will be a publisher-set value, but on
> some kind of linear scale? discrete or continuous?

I'd imagine a scale of 1 to 10 (though no upper limit is really 
necessary), with 1 being the most important.

> global or site-local?

Site-local, otherwise it's open to abuse, and too difficult to define. 
The numbers would be purely relative to other entries from the same 
feed, as a standardized scale would be impossible to come up with. 
Composite feeds may have to strip them, or we could come up with a 
simple rule based on feed ids and headinentry.

Time to write a Pace.

Graham

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 8 Dec 2004 10:25:09 -0800

This seems like a very useful extension, but not part of the core. 
I'd say: write it up! I would certainly like to see priorities 
allowed in some of the feeds I read.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Antone Roundy <[email-masked]>
Date: Wed, 8 Dec 2004 12:05:57 -0700

> simple rule based on feed ids and headinentry.
Information like this that is valid only within the context of the feed 
brings up issues that we need to be careful to resolve correctly.  A 
few options and related issues:

1) Composite feeds strip this element out:
	a) loses information
	b) breaks signing of the entries (Could the aggregator sign the 
modified entry in a way that said "when I got it, I verified it's 
signature"--then, if you trust the aggregator, you accept that it was 
originally properly signed? ...what if an aggregator gets it from 
another aggregator which you DON'T trust?  The entry would need to 
carry info about the whole chain of aggregators who'd signed it to 
enable consumers to make their own trust decisions.)
	c) if this element gets defined in an extension, we'll need a 
must-understand mechanism to ensure that aggregators that don't know to 
strip it out don't pass it through

2) Composite feeds leave this in as-is, and it applies within the 
context of the feed whose head appears in the entry:
	a) we'd either need a way to add another element specifying the 
priority/importance/whatever of the entry within the composite feed, or 
composite feed publishers would not be able to add that editorial 
information

3) Composite feeds add something to this element to indicate that it 
applies to the feed whose head appears in the entry, and may add 
another element to specify the priority/importance/whatever of the 
entry within the composite feed:
	a) same as 1b above
	b) 1c =~ s/strip it out/alter it/

---

From: Robert Sayre <[email-masked]>
Date: Wed, 08 Dec 2004 14:13:32 -0500

> This seems like a very useful extension, but not part of the core.

+1

Robert Sayre