Re: FYI: Updated Index draft
This could all get rather complicated very quickly. My primary objective
is to address known use cases for ordered feeds (my netflix queue
feed[1] for example), most of which are structured as complete datasets
that are non-incremental in nature. I'm not convinced that I necessarily
want to try to solve all of the potential problem cases that could arise
with ordered feeds that span multiple a collection of historical feeds,
etc. Also, I am not wishing to duplicate what Microsoft has done with
their simple list extensions. So with that in mind, I still wish to try
and address the issues that have been raised so here's what I have so far:
[1] http://rss.netflix.com/QueueRSS?id=P5365369447081104293883231608616881
{domain}
{nonNegativeInteger}
I drop the feed level i:ranking element and introduce a new i:domain
element that identifies a "ranking domain" that this feed is a part of.
The i:rank element is used to specify the nonNegativeInteger rank for
the given {scheme} for the containing element. The {domain} attribute is
used to scope the i:rank to a specific ranking domain -- for instance,
the priority ranking is only relevant if the entry is contained in a
feed with a corresponding i:domain element.
The lack of a i:domain element indicates the "default ranking domain".
Any i:rank elements that do not specify a domain attribute are
considered to be part of the default ranking domain.
For instance, in the following example, only the first i:rank is
relevant within the given feed. Neither of the urn:bar i:rank elements
are relevant within this particular feed example.
tag:example.com,2005:/feed
urn:foo
tag:example.com,2005:/feed/1
1
2
tag:example.com,2005:/feed/2
2
1
Domain urn:foo ranking: tag:example.com,2005:/feed/1 then
tag:example.com,2005:/feed/2
Domain urn:bar ranking: rag:example.com,2005:/feed/2 then
tag:example.com,2005:/feed/1
The domain element serves multiple purposes.
1. It helps us to scope the relevance of an i:rank element within an
entry. For instance, if an entry with an i:rank in the urn:foo domain is
aggregated into a synthetic feed that either a) does not specify a
ranking domain or b) specifies a different ranking domain, consumers can
safely ignore the urn:foo i:rank.
2. It helps us to correlate ranks that span multiple feed documents. For
instance, two separate feed documents may specify the same ranking domain.
No-Rank Entries: no-rank entries are marked by the absence of an i:rank
element corresponding to a given scheme. For instance, in the following
example, entry "C" is a No-Rank Entry in the Index scheme, but is ranked
in the Priority Scheme.
A
1
10
B
2
50
C
20
Re: Eric's Question: "How does this help (eg) bbc.co.uk order their news
items in some sensible manner?"
By the description given, it sounds as if the BBC ranking is more a
ranking of relative importance than a ranking of natural order. That is,
Top Story A has a higher importance that Top Story B, etc. If that is
the case, a "priority" or "importance" ranking scheme can be used in
conjunction with the atom:updated element.
top-story-A
2005-12-12T12:00:00Z
90
top-story-B
2005-12-12T12:00:00Z
80
top-story-C
2005-12-11T12:00:00Z
90
top-story-D
2005-12-11T12:00:00Z
80
In this example, top-story-A is ranked as the highest priority entry on
Dec, 12, 2005 while top-story-C is ranked as the highest priority entry
on Dec, 11, 2005.
Re: Eric's Question: "What happens when entries "fall off the bottom"
... do their rankings expire?"
It will be entirely dependent on the scheme. In a priority ranking
scheme (measuring the relative importance of an entry), having an entry
"fall off the bottom" would have no effect on the overall
ordering/ranking of the feed. In a natural order ranking scheme (indexed
position), having an entry "fall off the bottom" would likely mean that
the entry is no longer a part of the ordered list or is no longer
relevant to the rankings.
Re: Thomas Broyer's suggestions:
>1. get rid of your i:rank, users will use any extension element
instead (no more
> registry and you can still define "standard" priority and index
extensions)
I considered this but a single extensible rank element fits most of the
simple use cases for this rather well. That said, allowing for specific
ranking elements would be helpful, so how about a bit of a compromise?
rankingCommonAttributes =
attribute i:scheme { IRI },
attribute i:domain { IRI }?
rankingConstruct =
rankingCommonAttributes
integerRank = element i:rank {
rankingConstruct (nonNegativeInteger)
}
With this approach, i:rank is defined as the standard nonNegativeInteger
ranking element. If I so desired, I could easily define new
rankingConstructs however, for instance:
importanceRank = element x:importance {
rankingConstruct ('critical' | 'high' | 'medium' | 'low' | 'info'|)
}
high
>2. get rid of your @order attribute: users should be able to choose in
which
Re: FYI: Updated Index draft
I had considered something along those lines, but it seemed to me to be a bit vague. I suspect it would produce adequate results in the majority of cases, but I'd prefer something that gave the content provider finer control. I like the idea of being able to say exactly where in a feed an item should be positioned. Then again I'm not a content provider so maybe that's not the sort of thing they're looking for. Eric Scheid wrote: thinking more ... I think the way to handle this is that the client application could weight the ranking with the age of the item, and thus a rank#1 item would appear near the top of the list, and then slowly drop away. You also get to know what the original ranking for an item is.
Re: Structured Publishing -- Joe Reger shows the way...
On 9/12/05, Bob Wyman <[EMAIL PROTECTED]> wrote: > I believe it doesn't make sense for us to add data-carrying elements > to Atom other than atom:content or atom:summary. Atom provides a definition > of a collection of entries and it provides the entry format. Frankly, it > should stop there. The data payload should be carried in the content > element. I believe the ability to include data outside the content is likely to be useful, and may even be essential in some republishing scenarios where additional metadata about the payload is required. But that's not to say the transport-only view of Atom doesn't offer big advantages in the Structured Blogging kind of scenario where the data can be neatly packaged, relatively opaquely to the rest of the entry data. (Atom as SOAP lite?) One aspect I am curious about - are you intending to use the Atom entry ID as an identifier within the content at all? Any issues there? Cheers, Danny. -- http://dannyayers.com
Re: FYI: Updated Index draft
On 21/9/05 9:35 PM, "James Holderness" <[EMAIL PROTECTED]> wrote: > Marking entries as having no rank sounds like a nice idea, but I don't think > it's feasible in the long run. thinking more ... I think the way to handle this is that the client application could weight the ranking with the age of the item, and thus a rank#1 item would appear near the top of the list, and then slowly drop away. You also get to know what the original ranking for an item is. e.
Re: FYI: Updated Index draft
Marking entries as having no rank sounds like a nice idea, but I don't think it's feasible in the long run. In order to erase ranking effectively from previous entries, the content provider needs to double their feed size potentially. And if a user misses out on a "rank update" they could end up with news items from the distant past sitting at the top of their ranking forever. Admittedly you already have the problem of losing items that have fallen off the bottom of a feed, but at least the feed remains readable. With a corrupted ranking system, the ranking effectively becomes useless. One possible solution may be the use of a rank-offset tag. Let's say you have three items A, B and C with A being the most important (rank 1) and C being the least important (rank 3). You start with a rank-offset of 0 and your feed looks like this: A:1 B:2 C:3 (rank-offset = 0) Now say you want to add a new item D that falls between A and B, but you still only want to include 4 items in your feed. You increment the rank-offset to 1 and reconstruct the feed with new ranks which now look like this: A:1 D:2 B:3 (rank-offset = 1) When the client receives that feed, it automatically subtracts the rank-offset from each item's rank value before adding them to its database. So internally its list of items now look like this: A:0 D:1 B:2 C:3 A's rank has been updated. D has been inserted. B and C remain unchanged. From the client's point of view the ranking numbers will start going negative almost immediately, but as long as you treat the lowest (signed) value as having the highest priority it shouldn't be a problem. And the rankings that actually appear in the feed are always nice small positive integers. The rank-offset will get large over time (and I don't see how it can be reset), but that's just one tag. Eric Scheid wrote: The only way out of this conundrum is that bbc.co.uk will have to update the original #1 and #2 stories and re-rank them as much lower. If they re-rank them as #46 and #47 then they will need to re-rank any previous entry at those ranks to lower positions, and similarly for any other entries with ranks which get pushed down. Eventually the entire history of the feed needs to be re-ranked. Unless entries can be marked as having no rank. Can they?
Re: FYI: Updated Index draft
On 21/9/05 1:05 PM, "James M Snell" <[EMAIL PROTECTED]> wrote: > The ranking is part of the entry metadata. If an entry falls off the > feed, there is no effect on the ranking metadata. With partial feed > retrieval, ordering could be performed over the entire set of entries. How does this help (eg) bbc.co.uk order their news items in some sensible manner? Today, they have a couple of important stories, they indicate those entries are rank #1, #2. Tomorrow, they have more news, but not more important than yesterday's big news. The day after they have a new big story, it should be rank #1. The #1 and #2 stories from two days ago have fallen off the bottom of the feed. The only way out of this conundrum is that bbc.co.uk will have to update the original #1 and #2 stories and re-rank them as much lower. If they re-rank them as #46 and #47 then they will need to re-rank any previous entry at those ranks to lower positions, and similarly for any other entries with ranks which get pushed down. Eventually the entire history of the feed needs to be re-ranked. Unless entries can be marked as having no rank. Can they? e.
