[RFC] Change in activty:object semantics

[Simon Wistow]

Martin and I have been going back and forth on this over the last couple
of days and we've failed to convince each other either way so either my
idea is *really* stupid or it should be thrown open for discussion (so
that you can tell me it's really stupid).

Currently the spec say that you may refer to another object so that you
can do something like

<entry>
<title>Simon favourited a post</title>
<link href="http://delicious.com/simon/6464646">
<activitystream:verb>favourited</activitystream:verb>
<activitystream:object-type>favourite</activitystream:object-type>
<activitystream:object>
<title>A post</title>
<link href="http://example.com/post.html</link>
<description>blah blah blah</description>
<activitystream:verb>posted</activitystream:verb>
<activitystream:object-type>post</activitystream:object-type>
</activitystream:object>
</entry>

or

<entry>
<title>Simon befriended Martin</title>
<link href="http://social.example.com/simon/d34dbeef">
<activitystream:verb>friended</activitystream:verb>
<activitystream:object>
<title>Martin Atkins</title>
<link href="http://apparently.me.uk</link>
<activitystream:object-type>person</activitystream:object-type>
</activitystream:object>
</entry>

But this has somewhat bugged me for a few reasons:

* Atom already has elements meant to represent a Person. What we're
essentially doing is making activitystream:object a subclass of
atom:entry and then overloading the semantics so that it can be a person

* Whilst in AtomPub world (such as the Google GData API) atom:entry
basically means "an object" in feed world entry generally means "content
(that should probably be displayed as an event that happened)". An
atom:entry MUST have a title and either content or a link neither of
which will necessarily map to a person.

* It's going to make parsing slightly harder, especially lazy parsing -
although I realise that on the grand scale of things that's the *least*
of our worries.

My suggestion is to make atom:object a container that can contain an
atom:entry, an atom:post, and atom:link or, infact, anything so that say
Martin writes a post which is represented as

<feed>
<entry>
<title>I wish Simon would shut up</title>
<content>Simon's being kind of an ass</content>
<link href="http://mart.example.com/simon_ass.html" />
<activitystream:verb>posted</activitystream:verb>
<activitystream:object-type>post</activitystream:object-type>
</entry>
</feed>

And I want to refer to it then I can either do

<feed>
<entry>
<title>Martin called me an ass</title>
<content>Which is fair enough</content>
<link href="http://simon.example.com/am_ass.html" />
<activitystream:verb>posted</activitystream:verb>
<activitystream:object-type>post</activitystream:object-type>
<activitystream:object>
<activitystream:object-type>post</activitystream:object-type>
<entry>
<title>I wish Simon would shut up</title>
<content>Simon's being kind of an ass</content>
<link href="http://mart.example.com/simon_ass.html" />
<activitystream:verb>posted</activitystream:verb>
<activitystream:object-type>post</activitystream:object-type>
</entry>
</activitystream:object>
</entry>
</feed>

or I can do it without including the whole post

<feed>
<entry>
<title>Martin called me an ass</title>
<content>Which is fair enough</content>
<link href="http://simon.example.com/am_ass.html" />
<activitystream:verb>posted</activitystream:verb>
<activitystream:object-type>post</activitystream:object-type>
<activitystream:object>
<activitystream:object-type>post</activitystream:object-type>
<link href="http://mart.example.com/simon_ass.html" />
</activitystream:object>
</entry>
</feed>

then later Martin could do

<feed>
<entry>
<title>Mart defriended Simon</title>
<content>Because he's being kind of an ass</content>
<activitystream:verb>defriended</activitystream:verb>
<activitystream:object-type>post</activitystream:object-type>
<link href="http://mart.example.com/simon_defriend.html" />
<activitystream:object>
<activitystream:object-type>person</activitystream:object-type>
<person>
<name>Simon Wistow</name>
<email>swi...@example.com</email>
<url>http://simon.example.com/profile</url>
</person>
</activitystream:object>
</entry>
</feed>

The ugly thing about that is, in the first inline example of me
referencing your post, where and how many

<activitystream:object-type>post</activitystream:object-type>

elements to put in.

[Martin Atkins]

Simon Wistow wrote:
>
> <entry>
> <title>Simon favourited a post</title>
> <link href="http://delicious.com/simon/6464646">
> <activitystream:verb>favourited</activitystream:verb>
> <activitystream:object-type>favourite</activitystream:object-type>
> <activitystream:object>
> <title>A post</title>
> <link href="http://example.com/post.html</link>
> <description>blah blah blah</description>
> <activitystream:verb>posted</activitystream:verb>
> <activitystream:object-type>post</activitystream:object-type>
> </activitystream:object>
> </entry>
>

Note that this example should actually be:

<entry>
<title>Simon favourited a post</title>
<link href="http://delicious.com/simon/6464646">
<activitystream:verb>favourited</activitystream:verb>

<activitystream:object>
<title>A post</title>
<link href="http://example.com/post.html</link>
<description>blah blah blah</description>

<activitystream:object-type>blog-entry</activitystream:object-type>
</activitystream:object>
</entry>

No verb in activity:object and no object-type in the activity entry.

I there something in the spec that makes this unclear?

[David Recordon]

While you've given your view on why this is better, what has the
argument against it been?

--David

[Simon Wistow]

On Tue, Jan 13, 2009 at 11:15:18AM -0800, Martin Atkins said:
> I there something in the spec that makes this unclear?

Nope - mea culpa.

[Simon Wistow]

On Tue, Jan 13, 2009 at 11:16:58AM -0800, David Recordon said:
>
> While you've given your view on why this is better, what has the
> argument against it been?

I think the arguments against it (and Martin, please jump in and correct
me here) are

* It's verbose (admittedly this is minor, we are using XML after all)

* It's unecessary (it's the CS nerd in me doing a bit of
overengineering)

* It strays from AtomPub (and hence from the spirit of the Atom spec)
semantics of having every object be an entry

* It complicates the semantics of the implicit object of Martin's spec

http://martin.atkins.me.uk/specs/activitystreams/atomactivity#impliedpost

[David Recordon]

I personally think it becomes a bit simpler (not in terms of number of
options, but conceptually) to say that the atom:object contains either
a link, entry, or person (via author) and it thus describes the object
of the activity. It isn't creating more tags, grows if the Atom spec
ever changes how these elements work and makes implementors think more
about the sort of information that they should be including in their
feeds. It also allows us to include multiple links, entries, or
people when aggregators are publishing feeds for activities such as
David tagged Simon and Mart in a photo. Simon's proposal would
theoretically allow two atom:author and one atom:entry elements to
represent all of these things.

--David

[Martin Atkins]

David Recordon wrote:
> I personally think it becomes a bit simpler (not in terms of number of
> options, but conceptually) to say that the atom:object contains either
> a link, entry, or person (via author) and it thus describes the object
> of the activity. It isn't creating more tags, grows if the Atom spec
> ever changes how these elements work and makes implementors think more
> about the sort of information that they should be including in their
> feeds. It also allows us to include multiple links, entries, or
> people when aggregators are publishing feeds for activities such as
> David tagged Simon and Mart in a photo. Simon's proposal would
> theoretically allow two atom:author and one atom:entry elements to
> represent all of these things.
>

Personally, if we decided we wanted to be able to collapse an activity
on multiple objects into a single entry I'd just allow multiple
activity:object elements in an activity and define it such that the verb
was done to all of them.

However, I believe we agreed that it was better to let the aggregators
do this because they've (potentially) got visibility of multiple feeds
and can collapse related activities across two feeds into a single item.

[David Recordon]

Beyond the aggregation argument, being able to represent anything
ranging from just a link to a full entry seems like a good thing. All
of a sudden this means that Flickr thumbnails could be included in the
action of "Mart favorited the photo 'Violets in San Francisco'."

[Martin Atkins]

The above seems like a reasonable representation of why I disagree with
this.

What I was planning to do was instead address (in a separate spec) the
general case of how to make a list of people as an Atom feed -- for
example, if I want to make an feed of my contact list as Google's
Contacts API does -- and use that as the representation of a person in
AtomActivity.

Since you can't use atom:author at the top level in an Atom feed, it
seems strange to me to use as an object. Everything we can describe
inside object should, in my opinion, be usable at the top level to make
non-activity lists of things as well. (i.e. what I refer to as "Object
Feeds")

While I doubt activity aggregators are consuming the GData Contacts API
to find "Added a contact" events today, as far as I'm aware there's
nothing technical blocking them from doing this. It is also currently
the only example I'm aware of that represents contact lists in Atom.

[Martin Atkins]

David Recordon wrote:
> Beyond the aggregation argument, being able to represent anything
> ranging from just a link to a full entry seems like a good thing. All
> of a sudden this means that Flickr thumbnails could be included in the
> action of "Mart favorited the photo 'Violets in San Francisco'."
>

While the spec should really be clearer on this, you can already have an
activity:object that consists only of a link:

<activity:object>
<link href="..." />
</activity:object>

There is no requirement that activity:object must be an "entire" entry.
It is intended to be similar to atom:source. atom:source includes a
subset of the elements that are children of the target feed, and
likewise activity:object includes a subset of the elements that are
children of the referenced entry.

The above is valid, though I would argue not particularly useful since
it doesn't give you a name or a type of the item. Ideally we'd want at
least a title, and probably also an object-type.

[David Recordon]

What I meant was that it could then become an entire atom:entry. From a spec perspective, I like the idea of saying that activity:object must contain one of atom:link, atom:entry, or atom:author. Maybe we need to write up these two methods better to be able to discuss pros and cons?

--David

[Bill de hOra]

Simon Wistow wrote:
> On Tue, Jan 13, 2009 at 11:16:58AM -0800, David Recordon said:
>> While you've given your view on why this is better, what has the
>> argument against it been?
>
> I think the arguments against it (and Martin, please jump in and correct
> me here) are
>
> * It's verbose (admittedly this is minor, we are using XML after all)

Not really - it's very verbose, even for XML. There will be a lot more
events than blog posts.

I think the fact you have an abbreviated form indicates a design
problem. It will make client code harder to write and it will up the
number of broken real-world activity feeds by giving people options.
Most of the examples I've seen here and are malformed and I think this
is down to verbosity - if the spec proponents can't be bothered to write
it out properly, users are unlikely to.

Suggestion: to extend Atom gracefully, define an activity construct the
way atom has defined Date and Person constructs.

And nearly a week on after my initial feedback, I still think you need
to decide whether this data extends Atom as per GData or is carried by
it as per OpenSocial. The current syntax is a halfway house.

Bill

[Martin Atkins]

Bill de hOra wrote:
>
> I think the fact you have an abbreviated form indicates a design
> problem. It will make client code harder to write and it will up the
> number of broken real-world activity feeds by giving people options.
> Most of the examples I've seen here and are malformed and I think this
> is down to verbosity - if the spec proponents can't be bothered to write
> it out properly, users are unlikely to.
>

The "abbreviated form" (which I call the "implied activity shorthand")
is motivated by examples of feeds in the wild. It is not merely a way to
reduce the number of bytes in a feed.

> Suggestion: to extend Atom gracefully, define an activity construct
> the way atom has defined Date and Person constructs.

I don't follow what this would look like in practice. Can you give an
example?

[Bill de hOra]

Martin Atkins wrote:
> Bill de hOra wrote:
>> I think the fact you have an abbreviated form indicates a design
>> problem. It will make client code harder to write and it will up the
>> number of broken real-world activity feeds by giving people options.
>> Most of the examples I've seen here and are malformed and I think this
>> is down to verbosity - if the spec proponents can't be bothered to write
>> it out properly, users are unlikely to.
>>
>
> The "abbreviated form" (which I call the "implied activity shorthand")
> is motivated by examples of feeds in the wild. It is not merely a way to
> reduce the number of bytes in a feed.

Nonetheless, the argument that there are two formats and so more ways to
have the data messed up in practice stands.

Bill