Subject: The distinction between "time this entry was published" and "time this entry was added to this feed"

From: Martin Atkins <[email-masked]>
Date: Sun, 11 Jan 2009 18:50:41 -0800

The work on using Atom to encode activity streams has raised what seems 
to be a more general issue with Atom that I thought I'd bring up over 
here to see what insight this group can bring.

In the "normal" case of a feed of entries a user has published, 
"published" quiet sensibly represents both the time the entry was 
published and the time it appeared in the feed, by definition.

However, when the feed is of something else, these two times are no 
longer necessarily the same.

Consider for example the feed that YouTube publishes of a user's 
"Favorite Videos". In this feed, the entry-level atom:published tells us 
when the entry was added as a favorite, *not* when the entry (i.e. the 
video) was posted to YouTube by its author.

However, Digg's equivalent "Favorite Articles" feed (which is actually 
RSS 2.0, but let's pretend it's Atom for the sake of this discussion) 
has the published time set to the time the article was originally 
submitted to Digg, *not* when it was added as a favorite.

My question, then, is which of these approaches is correct. The Atom 
specification is (intentionally?) very vague about what this time 
represents, but it does refer to "the entry". It's open to 
interpretation whether "the entry" means "the actual atom:entry element 
in this feed" or "the item that this atom:entry element describes".

Do you think it would be vaulable to have an optional extra element that 
indicates when the entry appeared in the current feed/collection? (This 
would effectively make YouTube wrong and Digg right.)

(I'm told that Digg couldn't actually implement this element even if it 
was specified, because they don't retain a timestamp on their "favorite" 
relationships, but at least it would reduce the ambiguity about what 
atom:published represents.)

---

From: "Peter Keane" <[email-masked]>
Date: Sun, 11 Jan 2009 22:02:39 -0600

On Sun, Jan 11, 2009 at 8:50 PM, Martin Atkins <[email-masked]> wrote:
>
>
> The work on using Atom to encode activity streams has raised what seems to
> be a more general issue with Atom that I thought I'd bring up over here to
> see what insight this group can bring.
>
> In the "normal" case of a feed of entries a user has published, "published"
> quiet sensibly represents both the time the entry was published and the time
> it appeared in the feed, by definition.
>
> However, when the feed is of something else, these two times are no longer
> necessarily the same.
>
> Consider for example the feed that YouTube publishes of a user's "Favorite
> Videos". In this feed, the entry-level atom:published tells us when the
> entry was added as a favorite, *not* when the entry (i.e. the video) was
> posted to YouTube by its author.
>
> However, Digg's equivalent "Favorite Articles" feed (which is actually RSS
> 2.0, but let's pretend it's Atom for the sake of this discussion) has the
> published time set to the time the article was originally submitted to Digg,
> *not* when it was added as a favorite.

I might be thinking too much as a library geek, but it seems to me
that the YouTube approach is more correct.  The activity stream work
is raising good questions and I'd say you need a clear idea of the
abstract model of an activity and its consituent entities and actors.
This sort of thing can get pretty hairy (Google "FRBR" or CIDOC-CRM"
for real fun) if there is not a pretty good shared understanding of
what's what.  Unless I am mistaken, an activity stream is making
assertions about activities and to mix in metadata about the
underlying things (like when a video was originally posted) seems off.
 Of course, a linked-to Atom entry representing that media item
(specifically it's YouTube instance) probably would have the that
information.

FWIW, I am hoping this Activities stream will (like Atom itself) have
all kinds of applicability outside the social networking context in
which it is being created, so I hope the modeling is very solid.  To
me, a set of activity streams seems to offer lots more opportunity for
semantic mining than "linked data in RDF" since the human actors are
so much more visible.  (Which is why I find the act of making it a
favorite more pertinent than when it was posted, which I can find by
other means).

> represents, but it does refer to "the entry". It's open to interpretation
> whether "the entry" means "the actual atom:entry element in this feed" or
> "the item that this atom:entry element describes".
>
> (I'm told that Digg couldn't actually implement this element even if it was
> specified, because they don't retain a timestamp on their "favorite"

That's a significant omission on Digg's part, I think.

--peter keane

---

From: "James Holderness" <[email-masked]>
Date: Mon, 12 Jan 2009 22:39:29 -0000

> posted to YouTube by its author.

Without answering you directly, I'd like to comment on YouTube's feeds, 
because I think what I have to say is relevant to the way you might go about 
creating feeds for activity streams.

Imagine I know someone that has a knack for finding good videos on YouTube, 
so I subscribe to their favourites feed to keep up with all the cool stuff 
they've discovered. I also subscribe to the YouTube "Recently Featured" 
feed, for similar reasons. And finally I subscribe to a couple of individual 
feeds for users who are friends.

Now imagine one day that one of my friends produces a really good video. 
It's spotted by the person whose favourites I subscribe to, as well as being 
a featured feed. That means the entry is going to show up in three of my 
feeds. Identical content, linking to an identical page, repeated three 
times. How many times do you think I want to view that entry?

You might be thinking, that's exactly what the atom:id element is for - my 
feed reader should be able to detect that all three entries are the same 
since they should have the same id value. Only they don't have the same 
value. Each one has a different id, so I get to see the exact same entry 
repeated three times. Saying that this is annoying would be a huge 
understatement.

Where this is relevant to your question, is that if you change the published 
date from the original entry (as YouTube is doing - at least for their 
favourites feeds), you basically have to change the entry id, since you're 
now no longer dealing with the same entry. And that, as I've said, would be 
incredibly annoying.

If you think that's a worthwhile compromise for your needs, that's your 
choice to make. I'll just weep quietly in the corner.

Regards
James

---

From: Martin Atkins <[email-masked]>
Date: Mon, 12 Jan 2009 15:08:05 -0800

James Holderness wrote:
[snip]
> 
> You might be thinking, that's exactly what the atom:id element is for - 
> my feed reader should be able to detect that all three entries are the 
> same since they should have the same id value. Only they don't have the 
> same value. Each one has a different id, so I get to see the exact same 
> entry repeated three times. Saying that this is annoying would be a huge 
> understatement.
> 

I hadn't noticed this -- that the id varies between feeds -- but that's 
definitely interesting. My assumption until this point was that 
different feeds describing the same resource would have the same id.

> Where this is relevant to your question, is that if you change the 
> published date from the original entry (as YouTube is doing - at least 
> for their favourites feeds), you basically have to change the entry id, 
> since you're now no longer dealing with the same entry. And that, as 
> I've said, would be incredibly annoying.
> 

This raises a more fundamental question of what atom:id is the id for,

In my mental model, I've always thought of atom:id as being the id for 
the thing that the entry represents, not that concrete atom:entry XML 
element. Therefore I'd expect different atom:entry elements that exist 
in different feeds but that represent the same "thing" would have the 
same id.

My understanding of section 4.2.6 seems to agree:

    When an Atom Document is relocated, migrated, syndicated,
    republished, exported, or imported, the content of its atom:id
    element MUST NOT change.  Put another way, an atom:id element
    pertains to all instantiations of a particular Atom entry or feed;
    revisions retain the same content in their atom:id elements.  It is
    suggested that the atom:id element be stored along with the
    associated resource.

I would consider an entry appearing in the three feeds you described to 
be either "republished" or "syndicated" (I'm not really sure how these 
are different) and so you'd expect the id to remain the same across all 
of them.

Changing the id in order that the publication date can be re-used as a 
"date this was added to this collection" seems like a shaky workaround 
at best.

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 12 Jan 2009 17:43:48 -0800

This is getting metaphysical but do they represent the same thing? If Alice, Bob, Dick and Jane share a link to a favorite video should it be treated as identical with the same atom:id? What if they each put their own caption on the video? What if there are comments from their friends on each instance they have shared? These aren't hypothetical questions, I'm describing Facebook's implementation of sharing videos with friends.

--
THINGS TO DO IF I BECOME AN EVIL OVERLORD #139
If I'm sitting in my camp, hear a twig snap, start to investigate, then encounter a small woodland creature, I will send out some scouts anyway just to be on the safe side. (If they disappear into the foliage, I will not send out another patrol; I will break out the napalm.)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Atkins
Sent: Monday, January 12, 2009 3:08 PM
Cc: Atom Syntax
Subject: Re: The distinction between "time this entry was published" and "time this entry was added to this feed"

James Holderness wrote:
[snip]

---

From: Martin Atkins <[email-masked]>
Date: Mon, 12 Jan 2009 17:51:23 -0800

Dare Obasanjo wrote:
> This is getting metaphysical but do they represent the same thing?
 > If Alice, Bob, Dick and Jane share a link to a favorite video
 > should it be treated as identical with the same atom:id? What
> if they each put their own caption on the video? What if there
 > are comments from their friends on each instance they have
 > shared? These aren't hypothetical questions, I'm describing
 > Facebook's implementation of sharing videos with friends.
> 

While I'd concede that this is not a general solution, in Activity 
Streams land we currently have an object type that is called "bookmark" 
that is a reference to something else.

In this case, the thing it's "about" to goes into <link rel="related">, 
which is not ideal but seems to align with current practice.

The <link rel="alternate"> goes to a page representing the bookmark, if 
any, or it's just omitted completely if there is no such page.

The following URL is an example of something that might be an an 
appropriate <link rel="alternate"> for a "bookmark" object.
     http://ma.gnolia.com/people/Mart/bookmarks/cribonush

I suppose the general case is that when the user adds additional 
metadata their entry becomes a pointer to the original item rather than 
the item itself, so the id (and everything else, for that matter) is 
different in this case.

---

From: Antone Roundy <[email-masked]>
Date: Mon, 12 Jan 2009 22:03:08 -0600

> the item itself, so the id (and everything else, for that matter) is 

That makes sense to me.

As for the un-annotated case where essentially the same entry is showing 
up in multiple feeds, perhaps a reasonable approach to making it easy to 
recognize them as the same entry would be to give them all the same 
atom:id, and give them all an identical atom:source pointing to The One 
Feed To Rule Them All from YouTube, which perhaps would never really 
exist -- sort of a "dark matter" feed that just binds the other feeds 
together.

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Tue, 13 Jan 2009 14:06:59 +0100

* Martin Atkins <[email-masked]> [2009-01-13 03:00]:
> I suppose the general case is that when the user adds
> additional metadata their entry becomes a pointer to the
> original item rather than the item itself, so the id (and
> everything else, for that matter) is different in this case.

Exactly. And the mere act of bookmarking generates additional
metadata – specifically the time at which the item was
bookmarked.

Plus, if I follow the favourites of a user, and they star
something that was uploaded 3 years ago, I don’t want my feed
reader to show the item at the very bottom of my unread items
list. What matters to me is when the friend/user bookmarked it.

* James Holderness <[email-masked]> [2009-01-12 23:50]:
> How many times do you think I want to view that entry?

Depends. If I’ve seen the entry on the feeds of one of the people
I subscribe to directly, then I probably don’t care about its
instance in the general popular items feed. But I usually care to
be made aware of the fact that the people I subscribe to have
bookmarked it; so if I saw it on the popular items feed or the
feed of the friend who uploaded it, I would still want to see
that the stuff-spotting user I follow has also bookmarked it. If
the popular stuff feed has relevant annotations that the other
feeds have not, I might even still care to see that one too. In
general I care about all the content/annotations added uniquely
by each of the feed publishers.

I imagine you don’t care as much, though. Different people want
different things.

It would be nice if we had a link relation that makes a stronger
assertion than `related` does, about the linked resource being
the subject that the entry describes, with each being distinct
resources. That would let feed readers handle cases like this
tripple-publishing more intelligently, f.ex. summarise them all
in a single display unit.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Tue, 13 Jan 2009 16:42:45 +0100

* Aristotle Pagaltzis <[email-masked]> [2009-01-13 14:20]:
> It would be nice if we had a link relation that makes a
> stronger assertion than `related` does, about the linked
> resource being the subject that the entry describes, with each
> being distinct resources. That would let feed readers handle
> cases like this tripple-publishing more intelligently, f.ex.
> summarise them all in a single display unit.

Hey, actually, we do: RFC 4685.

Regards,

---

From: Martin Atkins <[email-masked]>
Date: Tue, 13 Jan 2009 09:55:55 -0800

> Hey, actually, we do: RFC 4685.

What are you referring to in RFC4685? (Atom Threading Extensions)

The "replies" link relation? I'm not sure that it means what we need for 
this use-case.

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Tue, 13 Jan 2009 19:17:04 +0100

* Martin Atkins <[email-masked]> [2009-01-13 19:05]:
> The "replies" link relation? I'm not sure that it means what we
> need for  this use-case.

No, the `in-reply-to` element. It doesn’t sound like the link
relation was I thinking of at first glance but the definitions
are congruent. Even my proposal for how it could be usefully
displayed is essentially that of a thread. It’s kind of
embarrassing that I didn’t notice immediately.

(Nearly no one supports 4685, of course. But then neither do they
support the hypothetical link relation.)

Regards,

---

From: Martin Atkins <[email-masked]>
Date: Tue, 13 Jan 2009 11:08:03 -0800

> support the hypothetical link relation.)

It seems strange to use in-reply-to to represent a pointer to something. 
To me, in-reply-to seems a specialized kind of pointer, not a general 
pointer.

However, I'm willing to be convinced if you can explain your reasoning! :)

---

From: "James Holderness" <[email-masked]>
Date: Tue, 13 Jan 2009 20:57:51 -0000

> list. What matters to me is when the friend/user bookmarked it.

That's a valid point, but it's only really a problem if your feed reader 
sorts by some form of date rather than something like time of arrival. I've 
never thought that was a good idea, for a number of reasons, but I accept 
that I may be in the minority in that regard.

> bookmarked it

The thing is, if the entries were all correctly identified with the same 
atom:id, your feed reader can do all sorts of useful things. It could 
display an annotation on the entry saying something like "also received in 
feeds X, Y and Z". Or if you read feeds individually rather than in a merged 
view, it might show the message in all three feeds, but automatically mark 
all three versions as read the minute you read any one of them. Or let the 
user choose whether to eliminate duplicates or not.

If the entries are not correctly identified, though, you've got zero 
options.

> If

Annotations are another issue altogether. If you're commenting on someone's 
video, that's an entry in it's own right that should be pointing back to the 
item you're annotating. But you don't take the entire content of the entry, 
throw a "cool video!" comment on the end of it, and then claim authorship of 
that content.

> in a single display unit.

As you mention later, the in-reply-to link would be appropriate for this 
sort of thing, but IMO only if the entry is the annotation itself, and not 
the original content. Definitely not a byte-for-byte copy of the original 
entry with a new date and author (what YouTube is doing). That's plagiarism. 
The fact that both feeds are generated by the same server doesn't make it 
any less wrong.

Regards
James

---

From: Martin Atkins <[email-masked]>
Date: Tue, 13 Jan 2009 13:08:29 -0800

James Holderness wrote:
> sorts by some form of date rather than something like time of arrival. 
> I've never thought that was a good idea, for a number of reasons, but I 
> accept that I may be in the minority in that regard.
> 

If I'm understanding you correctly, then in the common case of a polling 
aggregator the order is skewed unless polling is done very often.

Sorting by published time allows items from multiple feeds to be 
intermingled into a single list in the correct order.

---

From: Bill de hOra <[email-masked]>
Date: Tue, 13 Jan 2009 23:03:17 +0000

Antone Roundy wrote:
>> metadata their entry becomes a pointer to the original item rather 
>> than the item itself, so the id (and everything else, for that matter) 
>> is different in this case.
> 
> That makes sense to me.

Me too.

The atom:source element isn't designed to capture that idea, so we're 
looking at something along the lines of thr:in-reply-to or a new rel 
attribute.

Bill

---

From: Bill de hOra <[email-masked]>
Date: Tue, 13 Jan 2009 23:00:02 +0000

> published and the time it appeared in the feed, by definition.

We can't (and don't) specify it as the time it appears into a feed. It's 
the time the author published it, not the time it showed up in the feed 
(or downstream).

> longer necessarily the same.

That's true of all feeds. CDNs, caches, and aggregators break that idea 
it's the time it shows.

> video) was posted to YouTube by its author.

That's down to how Youtube models a "favorite".

If they create a new Entry for the favorite (you can tell by the IDs) it 
makes sense relative to their domain. Although that will be annoying for 
people following other people's favourites if people are tagging the 
same vid. If not, it's a data bug.

> submitted to Digg, *not* when it was added as a favorite.

That's down to how Digg models a "favorite".

Again this depends on the site's internal domain model. In their case, 
it looks like they don't exposed favorites as distinct entities.

> My question, then, is which of these approaches is correct. 

They both are.

> The Atom 

It's to do (imo) with whether a favorite is an identifiable object, as 
pointed out above. That is, it's about what the resource identifies as 
indicated in this case by atom:id, not the representation of the 
resource as indicated by the atom:feed's XML.

> would effectively make YouTube wrong and Digg right.)

It would be more helpful (again imo),

for Youtube: if when a favourite is modeled as an Entry in its own 
right, atom:link or other metadata was used to reference what was 
favourited (Atom's thread extension is good food for thought on that).

for Digg: if the favourite is modelled as an echo of the what was 
favourited, they used atom:source.

> atom:published represents.)

That's what I mean by this being specific to internal domain models. 
There's no correct way to represent a favourite atm.

Bill

---

From: Bill de hOra <[email-masked]>
Date: Tue, 13 Jan 2009 23:05:31 +0000

> support the hypothetical link relation.)

I've used threading for both comments and capturing private messaging. I 
agree it can work here, but a qualifier similar to rel would be better 
to cover off Martin's bookmark use case.

Bill

---

From: James M Snell <[email-masked]>
Date: Tue, 13 Jan 2009 19:07:49 -0800

As the author of 4685 I'm a bit biased but I'm not sure I see the need 
for the new rel attribute. in-reply-to would seem to cover the need well 
enough.

- James

Bill de hOra wrote:
>>> than the item itself, so the id (and everything else, for that 
>>> matter) is different in this case.
>>
>> That makes sense to me.
>
> Me too.
>

---

From: Peter Keane <[email-masked]>
Date: Tue, 13 Jan 2009 21:19:18 -0600

On Tue, Jan 13, 2009 at 5:05 PM, Bill de hOra <[email-masked]> wrote:
>> No, the `in-reply-to` element. It doesn't sound like the link
>> displayed is essentially that of a thread. It's kind of
>> embarrassing that I didn't notice immediately.
>>
> agree it can work here, but a qualifier similar to rel would be better to
> cover off Martin's bookmark use case.

It's the same issue that's come up again and again about expressing
hierarchy in Atom.  Proposed rel values include "detail"/"master",
"up"/"down", "parent"/"child", or using the threading extension (the
closest thing we have right now for hierarchy).  None of those fit
just exactly right for this use case, and I think a new rel value
(esp. for pointing from child to parent a la 'in-reply-to') would be
extremely useful.  I'd hope it could be somewhat generic, though (and
paired with a parent-to-children rel a la "replies" as well) so that
it might serve these other uses.  As Aristotle suggested, it simply
needs to be more specific/strong  than "related."

--peter keane

---

From: Martin Atkins <[email-masked]>
Date: Tue, 13 Jan 2009 20:04:59 -0800

> for the new rel attribute. in-reply-to would seem to cover the need well 

So, just to complete the thought, the proposal is to use in-reply-to to 
represent a bookmark? In other words, we'd be modelling a bookmark as a 
response to an entry.

Presumably this would look something like this:

   <entry>
     <author>
       <name>Mart</name>
     </author>
     <id>tag:ma.gnolia.com,2005:Ma.gnolia-slokowuyird</id>
     <published>2009-01-11T22:02:04-08:00</published>
     <updated>2009-01-11T22:02:04-08:00</updated>
     <thr:in-reply-to
         href="http://www.ietf.org/ietf/1id-guidelines.html"
         type="text/html"
     />

     <link
         href="http://ma.gnolia.com/people/Mart/bookmarks/slokowuyird"
         rel="alternate"
         type="text/html"
     />
     <title>
         I-D Guidelines: Guidelines to Authors of Internet-Drafts
     </title>
     <content type="html">[elided]</content>
     <category term="ietf" scheme="http://ma.gnolia.com/tags"/>
     <category term="web standards" scheme="http://ma.gnolia.com/tags"/>
   </entry>

How is a consumer intended to determine that the above is a "bookmark" 
(i.e. annotated pointer) rather than a reply in the traditional sense?

---

From: "James Holderness" <[email-masked]>
Date: Thu, 15 Jan 2009 10:26:47 -0000

> intermingled into a single list in the correct order.

Feed readers typically poll every hour. If I receive 20 new posts in that 
hour, I couldn't care less what exact order I read them in - I just want to 
know that those are the most recent 20 posts.

I know that for some people, some kind of date order (what you refer to as 
the "correct" order) is important. So if article A has a publish date, or 
update date, or whatever that is 10 minutes before article B, then it's 
vitally important that message A gets read before message B, or is it 
message B before message A? I just don't get why it's so important.

I bet if you asked, most users couldn't even tell you if they were ordering 
by published date or updated date. They just know that how they're doing it 
is correct; and vitally important. Right up until the time that it's 
inconvenient to have things sorted that way; and then it's the date that is 
wrong, not the ordering.

The thing is, if you know that the actual ordering doesn't matter, and it's 
more a matter of perception than anything else, it's not that difficult to 
come up with an algorithm that gives the perception of sorting by date 
without actually doing so.

Regards
James

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 15 Jan 2009 06:22:54 -0800

I'm confused. What about desktop feed readers that aren't running so can't poll every hour? How would they show sensible results after the user fires them up for the first time that week or month.

Anyway, this discussion seems moot because most feed reading apps today sort by published date today so it seems weird to be discussing breaking behavior expected by hundreds of deployed apps.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of James Holderness
Sent: Thursday, January 15, 2009 2:27 AM
To: Atom Syntax
Subject: Re: The distinction between "time this entry was published" and"time this entry was added to this feed"

Regards
James

---

From: James M Snell <[email-masked]>
Date: Thu, 15 Jan 2009 08:01:52 -0800

> Anyway, this discussion seems moot because most feed reading apps today sort by published date today so it seems weird to be discussing breaking behavior expected by hundreds of deployed apps.
... especially given that they're not likely to change no matter what is 
discussed here...

- James

---

From: "James Holderness" <[email-masked]>
Date: Thu, 15 Jan 2009 20:12:49 -0000

Dare Obasanjo wrote:
> I'm confused. What about desktop feed readers that aren't running so can't 
> poll every hour? How would they show sensible results after the user fires 
> them up for the first time that week or month.

That depends what you mean by sensible. It's certainly possible to 
approximate an ordering by published date without strictly enforcing that 
order across all entries.

> Anyway, this discussion seems moot because most feed reading apps today 
> sort by published date today so it seems weird to be discussing breaking 
> behavior expected by hundreds of deployed apps.

I wasn't suggesting that applications should change the way they do things. 
I'm merely curious why so many people seem to think that ordering by 
published date is the one and only "correct" way to sort feed entries.

Also, I'm curious what makes you think that most feed reading apps today do 
sort by published date. Based on past research, I was of the opinion that it 
was more like 25-30%. I'm assuming you have more recent research that has 
reached a different conclusion?

Regards
James

---

From: "James Holderness" <[email-masked]>
Date: Thu, 15 Jan 2009 20:12:49 -0000

Regards
James

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Fri, 16 Jan 2009 11:58:58 +0100 (CET)

> published date is the one and only "correct" way to sort feed entries.

I wonder the same.

I think being aware one can sort a feed based on various parameters is
quite important. I don't think RFC 4287 specifies it has to be ordered in
a certain way, RFC 5023 IIRC specifies that collection partial list ought
to be ordered by app:edited element but that's it.

One point that I believe is quite important to remember is that Atom,
though mainly used in a blog-type contexts, is much more generic than that
and we should remember it may well be used in all sorts of other contexts
where human are not involved or not by using a common feed reader.

- Sylvain

-- 
Sylvain Hellegouarch
http://www.defuze.org

---

From: Bill de hOra <[email-masked]>
Date: Sat, 17 Jan 2009 03:04:07 +0000

Peter Keane wrote:
> hierarchy in Atom.  

I don't know if hierarchy matters here (really). I am fairly sure the 
message I send to you looks different in my outbox to the one you see in 
your inbox. Are they the same/different messages? No idea.

Bill

---

From: Peter Keane <[email-masked]>
Date: Sat, 17 Jan 2009 10:29:11 -0600

> your inbox. Are they the same/different messages? No idea.

I suppose what I'd like to see is a link@rel that says "without which
I would have no meaning/reason to exist" and another that says "this
is related, by I can stand on my own".

The latter is (I think) adequately captured by link@rel="related",
while for expressing the former, we only have thr:in-reply-to.
Bookmarking certainly requires the former (i.e., the bookmark has no
meaning w/o the thing being bookmarked).

--peter

---

From: Eric Scheid <[email-masked]>
Date: Sun, 18 Jan 2009 11:40:09 +1100

> meaning w/o the thing being bookmarked).

link@rel="referent"

ref·er·ent (n) - the thing or idea that a symbol, word, or phrase denotes

e.

---

From: Peter Keane <[email-masked]>
Date: Sun, 18 Jan 2009 12:30:23 -0600

On Tue, Jan 13, 2009 at 9:07 PM, James M Snell <[email-masked]> wrote:
>
> As the author of 4685 I'm a bit biased but I'm not sure I see the need for
> the new rel attribute. in-reply-to would seem to cover the need well enough.
>

Just a thought in favor of in-reply-to:.  The "source" attribute could
be quite useful.  Per RFC 4685:

"""
   The "source" attribute MAY be used to specify the IRI [RFC3987] of an
   Atom Feed or Entry Document containing an atom:entry with an atom:id
   value equal to the value of the "ref" attribute.
"""

Seems to me that a client might be aware of a finite set of "sources":
YouTube, Digg, etc., and thus would be able to decide which
in-reply-to elements it would like to process.

--peter

>>>> metadata their entry becomes a pointer to the original item rather than the
>>>> item itself, so the id (and everything else, for that matter) is different
>>>> in this case.
>>>
>>> That makes sense to me.
>>
>> Me too.
>>

---

From: Eric Scheid <[email-masked]>
Date: Mon, 19 Jan 2009 09:15:30 +1100

> in-reply-to elements it would like to process.

however, any given atom:entry MAY have only ONE atom:source element.

e.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 20 Jan 2009 08:11:04 +0100

On Thu, Jan 15, 2009 at 08:12:49PM -0000,
 James Holderness <[email-masked]> wrote 
 a message of 25 lines which said:

> Also, I'm curious what makes you think that most feed reading apps
> today do sort by published date. Based on past research, I was of
> the opinion that it was more like 25-30%.

Until a few months ago, the program which produced the Atom feed for
my blog did *not* sort the entries (the order was random), relying on
the feed reader to do so.

All the local feed readers I tested sorted by published date, as well
as many of the big online feed readers. I found only two exceptions,
two online readers, Netvibes and the iGoogle gadget (not Google Reader,
which started to do the sorting one year ago).

It was quite inconvenient for the users and I received several bug
reports. They were forwarded to these organizations, which never
replied.

[In the end, I gave in and decided, in the name of the robustness
principle, to do the sorting myself.]

So, I would not call this "research" but "anecdotal evidence seems to
indicate that sorting by <published> is the norm, not sorting the
exception".

---

From: "James Holderness" <[email-masked]>
Date: Wed, 21 Jan 2009 00:19:57 -0000

> which started to do the sorting one year ago).

Interesting. I've tested Google Reader a lot more recently than a year ago 
and I was convinced that they were ordering entries as they appeared in the 
feed. Although, to be honest, I don't think the answer is necessarily as 
simple as that, and I would like to have researched this in more detail if 
I'd had the time.

For example, a feed reader might sort individual feeds differently to 
aggregated views (assuming they support such things). They may sort an 
initial set of entries in a subscription differently to how they order a new 
entry added to an existing subscription.

> reports. They were forwarded to these organizations, which never

Also interesting. Given that there's no requirement that feed readers sort 
entries by the published date, what made you think they'd want to work 
around a problem in your feed that you could easily fix yourself?

If you can try and imagine, for just a moment, that sorting by published 
date might not be the one and only correct way to order feed entries, you'll 
begin to realise how ridiculous your bug report must seem to someone that 
doesn't share your views.

> indicate that sorting by <published> is the norm, not sorting the

I'll accept for now that the most popular choice of ordering is uncertain. 
Without more concrete evidence, though, I would think it unwise for a feed 
publisher to rely on any particular sort order.

Regards
James