Query on cardinality of Atom entry : Activity

[John Panzer]

The new model draft spec (http://martin.atkins.me.uk/specs/activitystreams/refactored-atomactivity)  sez:

Any valid Atom entry as defined by section 4.1.2 of [RFC4287] is a representation of one or more activities as defined in Section 3.1.

and

Although there is not a one-to-one mapping between an Atom entry and an activity...

I'm trying to understand why this would be; is there a canonical use case for this?  (I saw an earlier discussion but did not understand the use case; it seemed to involve coalesced activities but I don't quite see how that is not just another summary activity with its own id.)

--
John Panzer / Google
jpa...@google.com / abstractioneer.org / @jpanzer

[Martin Atkins]

On 03/11/2010 01:27 PM, John Panzer wrote:
> The new model draft spec
> (http://martin.atkins.me.uk/specs/activitystreams/refactored-atomactivity)
> sez:
>
> Any valid Atom entry as defined by section 4.1.2 of [RFC4287]

> <#RFC4287> is a representation of one or more activities as defined
> in Section 3.1 <#Activity>.

>
>
> and
>
> Although there is not a one-to-one mapping between an Atom entry and
> an activity...
>
>
> I'm trying to understand why this would be; is there a canonical use
> case for this? (I saw an earlier discussion but did not understand the
> use case; it seemed to involve coalesced activities but I don't quite
> see how that is not just another summary activity with its own id.)
>

I was expecting a question like this, since I know this is one thing
that was really unclear in the previous spec, and this is why I made a
point of calling it out right at the start of the section about activity
entries.

This is another case where we make a concession in Activity Streams to
afford nicer presentation in non-activity-aware feed reader applications.

Specifically, publishers seem to want to publish this sequence of
activities:

* John posted a photo 1 minute ago.
* John posted a photo 1 minute ago.
* John posted a photo 1 minute ago.
* John posted a photo 1 minute ago.
* John posted a photo 1 minute ago.

as:

* John posted 5 photos 1 minute ago.

So allowing a single activity entry to actually represent 5 activities
affords the desired handling in non-activity readers while keeping the
activities distinct in activity-aware readers. (The assumption being
that activity-aware readers will do their own display-time summarization
if they want to and that may or may not match the summarization of the
original feed.)

[Will Norris]

I think it might make more sense to first explain a single activity entry, but worded carefully so as not to preclude combined entries.  Then have a small section after that which explains the optional combined form.

[John Panzer]

Let's imagine everyone is activity aware.  Isn't it still reasonable to imagine that A would like to send out a summary of the following activities:

* John posted a photo 1 minute ago.
* John posted a photo 1 minute ago.
* John posted a photo 1 minute ago.
* John posted a photo 1 minute ago.
* John posted a photo 1 minute ago.

...as exactly one coalesced activity:

* John posted 5 photos 1 minute ago.

Even if you assume that all downstream processors are going to do intelligent coalescing, which is dubious IMHO, you still may well not want to pay for the overhead of sending out all of the individual messages.

And of course the opposite is true on the generation side:  I imagine many clients would be far happier to upload their photos and then trigger a one-time "John posted 500 photos..." than to either send notifications one at a time or have the service trigger individual sends on their behalf.

So I think this is a useful and valuable even in the shiny future when the activities are buzzing around like busy bees.  

What would this mean for activities?  Well, it'd meant that a coalesced or summary activity is a first class activity, but one that is an alias for a collection of other activities.  In other words, it's a lot like a crosspost, but a crosspost that sums up a set of sources.  So what if you allowed crosspost:source multiple times?  Instead of

"A single Atom entry may contain zero or one crosspost:source elements."

you'd have one edit to crosspost:

"A single Atom entry may contain any number of crosspost:source elements."

...where N>1 source elements means "this entry is an aggregation or summary of the other activities".

If crosspost isn't right (because you're doing a derivative work, not a copy) then perhaps something similar would work.  Theoretically rev="collection" would be appropriate but I think people are trying to kill "rev".

On Thu, Mar 11, 2010 at 3:24 PM, Martin Atkins <ma...@degeneration.co.uk> wrote:

--
You received this message because you are subscribed to the Google Groups "Activity Streams" group.
To post to this group, send email to activity...@googlegroups.com.
To unsubscribe from this group, send email to activity-strea...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en.