Subject: Some Draft Atom-related Specs for Activity Streams

From: Martin Atkins <[email-masked]>
Date: Thu, 01 Jan 2009 16:37:30 -0800

Hi folks,

A small group of which I'm a member has been working on a specification 
for describing activities as Atom entries. An "activity" for our 
purposes is an action a user has taken on a social website, such as 
posting a photo or marking it as a favorite.

The draft we have so far is here:
     http://martin.atkins.me.uk/specs/activitystreams/atomactivity

In the process of working this through, we discovered a number of other 
problems that we believe require Atom extensions to solve, so we've also 
got drafts of a number of peripheral specifications.

As Sam Ruby posted earlier in the month[1], one issue encountered was 
the lack of a standard way to publish media items such as photos and 
videos in Atom. While a couple of publishers (notably Google properties) 
use the elements from MediaRSS for this purpose, the few implementations 
I found were inconsistent. It was suggested that a more Atom-shaped 
media specification might be useful, so we drafted up this:
     http://martin.atkins.me.uk/specs/atommedia

We also have a small specification for describing the "service provider" 
that hosts a feed (for example, YouTube or Twitter). This is intended to 
be similar in design to atom:author.
     http://martin.atkins.me.uk/specs/activitystreams/provider

Finally, we have a small extension to Atom Threading Extensions to allow 
some metadata about the parent entry to be included in the child so that 
consumers can avoid fetching source feeds in certain cases. This is 
intended to be similar in principle to atom:source
     http://martin.atkins.me.uk/specs/activitystreams/commentmeta

I'm well aware that these drafts need plenty more editorial work, and 
may need more detail in certain spots, but since some folks are ready to 
start implementing based on these drafts I wanted to throw them out here 
to get a few more eyes on them, so that if there are any major problems 
with the technical direction we're taking we might fix them before there 
are too many implementations to change.

I would appreciate it if folks here would cast a critical eye over what 
we're proposing and let me know if you see fundamental flaws in our 
approach to any of these problems.

We will of course continue to refine these documents and hopefully we 
would be able to bring some or all of them over here and work on them 
with the wider Atom community.

Thanks,
Martin

-----------------------------------------

[1]http://www.imc.org/atom-syntax/mail-archive/msg20818.html

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 1 Jan 2009 22:54:49 -0500

Hi Martin,

Interesting stuff. Are you actually submitting these as Internet- 
Drafts? (please do, if not already...).

Cheers,

On 01/01/2009, at 7:37 PM, Martin Atkins wrote:

>
>
> Hi folks,
>
> A small group of which I'm a member has been working on a  
> specification for describing activities as Atom entries. An  
> "activity" for our purposes is an action a user has taken on a  
> social website, such as posting a photo or marking it as a favorite.
>
> In the process of working this through, we discovered a number of  
> other problems that we believe require Atom extensions to solve, so  
> we've also got drafts of a number of peripheral specifications.
>
> As Sam Ruby posted earlier in the month[1], one issue encountered  
> was the lack of a standard way to publish media items such as photos  
> and videos in Atom. While a couple of publishers (notably Google  
> properties) use the elements from MediaRSS for this purpose, the few  
> implementations I found were inconsistent. It was suggested that a  
> more Atom-shaped media specification might be useful, so we drafted  
> up this:
> We also have a small specification for describing the "service  
> provider" that hosts a feed (for example, YouTube or Twitter). This  
> is intended to be similar in design to atom:author.
> Finally, we have a small extension to Atom Threading Extensions to  
> allow some metadata about the parent entry to be included in the  
> child so that consumers can avoid fetching source feeds in certain  
> cases. This is intended to be similar in principle to atom:source
> I'm well aware that these drafts need plenty more editorial work,  
> and may need more detail in certain spots, but since some folks are  
> ready to start implementing based on these drafts I wanted to throw  
> them out here to get a few more eyes on them, so that if there are  
> any major problems with the technical direction we're taking we  
> might fix them before there are too many implementations to change.
>
> I would appreciate it if folks here would cast a critical eye over  
> what we're proposing and let me know if you see fundamental flaws in  
> our approach to any of these problems.
>
> We will of course continue to refine these documents and hopefully  
> we would be able to bring some or all of them over here and work on  
> them with the wider Atom community.
>
> Thanks,
> Martin
>

--
Mark Nottingham     http://www.mnot.net/

---

From: "James Holderness" <[email-masked]>
Date: Fri, 2 Jan 2009 22:23:09 -0000

Martin Atkins wrote:
> It was suggested that a more Atom-shaped media specification might be 
> useful, so we drafted up this:

At first glance that all seems fairly reasonable to me. The only thing that 
concerned me was the media:description element. Is there any reason why the 
atom:summary element wouldn't work just as well?

I'm trying to imagine how I would construct a feed if I were a photo service 
like say flickr. The title is obvious, the content I'd probably put an html 
img thumbnail along with a more detailed description if the author had 
provided one, and the summary would just be the aforementioned description. 
I can't see what I'd do with the media:description element other than 
duplicate the atom:summary.

Is there a specific use-case that I'm missing?

>     http://martin.atkins.me.uk/specs/activitystreams/provider

It's worth pointing out that some feed parsers might be confused by the use 
of existing atom:elements. For example they'll interpret your 
service:provider title as the title of the feed. I know Planet Venus used to 
have problems with that sort of thing, although it's possible it has since 
been fixed.

Also, it could be argued that you're redefining the meaning of the atom 
elements. In RFC4287, atom:title is defined as "a human-readable title for 
an entry or feed". That's not how you're using it at all. I'm not sure if 
that sort of thing matters.

Regards
James

---

From: Martin Atkins <[email-masked]>
Date: Fri, 02 Jan 2009 15:19:34 -0800

James Holderness wrote:
> At first glance that all seems fairly reasonable to me. The only thing 
> that concerned me was the media:description element. Is there any reason 
> why the atom:summary element wouldn't work just as well?
> 
> I'm trying to imagine how I would construct a feed if I were a photo 
> service like say flickr. The title is obvious, the content I'd probably 
> put an html img thumbnail along with a more detailed description if the 
> author had provided one, and the summary would just be the 
> aforementioned description. I can't see what I'd do with the 
> media:description element other than duplicate the atom:summary.
> 

One of the principles I've been following with this stuff is to avoid 
repurposing existing Atom elements that might be used by generic feed 
readers, because sites will not want to alter what they're sending to 
generic feed readers in order to support the new media bits.

However, if it turns out that most publishers aren't using atom:summary, 
that most aggregators don't do anything with it, or that publishers were 
using it to contain the media description anyway then I'd be happy to 
remove it. It wasn't really a feature I felt strongly about other than 
avoiding clashes with existing implementations.

>> provider" that hosts a feed (for example, YouTube or Twitter). This is 
>> intended to be similar in design to atom:author.
> It's worth pointing out that some feed parsers might be confused by the 
> use of existing atom:elements. For example they'll interpret your 
> service:provider title as the title of the feed. I know Planet Venus 
> used to have problems with that sort of thing, although it's possible it 
> has since been fixed.
> 

If this is true then that would certainly be a problem. I can see how 
this sort of thing happens, having inadvertently introduced a similar 
bug by using getElementsByTagNameNS instead of getting only child nodes. 
Wouldn't suprise me if other implementations do it too, though hopefully 
they'd be okay as long as the feed-level atom:title appears before 
atom:provider; otherwise I'd expect such implementations to also 
interpret the entry-level atom:title as the feed title.

I could add in a requirement that service:provider must appear after 
atom:title if that would avoid this bug.

> elements. In RFC4287, atom:title is defined as "a human-readable title 
> for an entry or feed". That's not how you're using it at all. I'm not 
> sure if that sort of thing matters.
> 

I'm also not sure if this sort of thing matters. For what it's worth, I 
did also consider using atom:name, the child of atom:author for this 
purpose, since we're really talking about the name of the provider 
rather than its title. The choice between title and name was arbitrary, 
to be honest.

However, I could rewrite it to use custom elements if folks think 
extending the reach of these Atom elements is wrong. I was motivated by 
trying to make service:provider similar to atom:author, but I guess 
really atom:name would have been more consistent than atom:title in that 
case.

---

From: "James Holderness" <[email-masked]>
Date: Sat, 3 Jan 2009 11:51:07 -0000

> generic feed readers in order to support the new media bits.

I have similar concerns, but different conclusions. From what I've seen of 
feeds in the wild, I get the impression that sites tend to take whatever 
data they have available, and shove it into whatever fields look more or 
less appropriate.

In the best case, you'll get an identical copy of the summary element. Worst 
case you'll get a copy of the content element which may be a huge HTML blob, 
complete with embedded image thumbnails and all sorts of unwanted metadata.

Either way you've created an element that's just a duplicate of existing 
data. Have a look at all the RSS feeds out there using itunes and yahoo 
media rss extensions. You tend to see the same content repeated a half dozen 
times in different fields. I'd prefer this spec didn't encourage more of 
that sort of thing.

IMHO you'd be better off encouraging sites to produce a good summary element 
rather than trying to invent a new element that does essentially the same 
thing. But that really is just MHO. I do see where you're coming from.

>> use of existing atom:elements.
>
> If this is true then that would certainly be a problem.

I wouldn't lose too much sleep over it. I ran some tests overnight on a 
couple of feed readers and most seem ok (I wasn't specifically testing your 
usage - just general forms of nested element reuse).

> atom:provider;

As a general rule that doesn't necessarily apply, but for the specific 
failure cases I've seen at the feed level, having the atom:title first would 
have avoided the problem.

> atom:title if that would avoid this bug.

I don't think it would harm, but IMO that sort of thing belongs in an 
interoperability appendix - not in the main body of the spec.

> purpose, since we're really talking about the name of the provider rather 
> than its title.

If I had to choose, I'd say atom:name was more appropriate. Your usage seems 
pretty close to the RFC4287 definition.

> extending the reach of these Atom elements is wrong.

I honestly don't know. I was kind of hoping that some IETF expert on the 
list would express an opinion once I'd raised the issue.

Regards
James

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 8 Jan 2009 08:37:03 -0800

Quick question, who are the members of this "small group" and what is the process for getting changes/updates to the spec?

--
THINGS TO DO IF I BECOME AN EVIL OVERLORD #110
I will not employ devious schemes that involve the hero's party getting into my inner sanctum before the trap is sprung

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Atkins
Sent: Thursday, January 01, 2009 4:38 PM
To: Atom Syntax
Subject: Some Draft Atom-related Specs for Activity Streams

Hi folks,

Thanks,
Martin

---

From: Martin Atkins <[email-masked]>
Date: Thu, 08 Jan 2009 10:24:18 -0800

> Quick question, who are the members of this "small group" and what is the process for getting changes/updates to the spec?

The small group is working in a Google Group:
     http://groups.google.com/group/activity-streams

As far as the process for changes, just let me know what you think needs 
changing either here or in that group; I'm be happy to receive feedback.

---

From: Bill de hOra <[email-masked]>
Date: Thu, 08 Jan 2009 18:59:37 +0000

James Holderness wrote:
> 
> Martin Atkins: 
>> I'm also not sure if this sort of thing matters. For what it's worth, 
>> I did also consider using atom:name, the child of atom:author for this 
>> rather than its title.
> If I had to choose, I'd say atom:name was more appropriate. Your usage 
> seems pretty close to the RFC4287 definition.
> 

This is from the atomactivity-00 spec:

[[[
<entry>
    <id>tag:photopanic.example.com,2008:activity01</id>
    <title>Geraldine posted a Photo on PhotoPanic</title>
    <published>2008-11-02T15:29:00Z</published>
    <link rel="alternate" type="text/html"
          href="/geraldine/activities/1" />
    <activity:verb>
       http://activitystrea.ms/schema/1.0/post
    </activity:verb>
    <activity:object>
       <id>tag:photopanic.example.com,2008:photo01</id>
       <title>My Cat</title>
       <published>2008-11-02T15:29:00Z</published>
       <link rel="alternate" type="text/html"
             href="/geraldine/photos/1" />
       <activity:object-type>
           tag:atomactivity.example.com,2008:photo
       </activity:object-type>
       <source>
           <title>Geraldine's Photos</title>
           <link rel="self" type="application/atom+xml"
                 href="/geraldine/photofeed.xml" />
           <link rel="alternate" type="text/html"
                 href="/geraldine/" />
       </source>
    </activity:object>
    <content type="html">
        &lt;p&gt;Geraldine posted a Photo on PhotoPanic&lt;/p&gt;
        &lt;img src="/geraldine/photo1.jpg"&gt;
    </content>
</entry>
]]]

I see the following duplication:

1: atom:id, activity:id
2: atom:title, activity:title
3: atom:published, activity:published
4: atom:link@rel=alternate, activity:link@rel=alternate
5: atom:souce, activity:source

1,2,4,5 I think are duplicates, 3 depends on what activity:published 
means.  But on reading through the spec, I see that "5.5. The 
activity:object Extension Element" is saying to use atom:* elements. So 
I think the example XML is buggy, and here's my attempt at a fix by 
throwing in xmlns and xml:base declarations:

[[[
<entry
     xmlns:atom="http://www.w3.org/2005/Atom"
     xmlns:activity="http://activitystrea.ms/spec/1.0/"
     xml:base="http://example.org/activities" >
    <id>tag:photopanic.example.com,2008:activity01</id>
    <title>Geraldine posted a Photo on PhotoPanic</title>
    <published>2008-11-02T15:29:00Z</published>
    <link rel="alternate"
     type="text/html"
     href="/geraldine/activities/1" />
    <activity:verb>
     http://activitystrea.ms/schema/1.0/post
    </activity:verb>
    <activity:object>
       <activity:object-type>
           tag:atomactivity.example.com,2008:photo
       </activity:object-type>
       <id>tag:photopanic.example.com,2008:photo01</atom:id>
       <title>My Cat</atom:title>
       <published>2008-11-02T15:29:00Z</atom:published>
       <link rel="alternate"
         type="text/html"
         href="/geraldine/photos/1" />
       <source>
           <title>Geraldine's Photos</title>
           <link rel="self"
             type="application/atom+xml"
             href="/geraldine/photofeed.xml" />
           <link rel="alternate"
             type="text/html"
             href="/geraldine/" />
       </source>
    </activity:object>
    <content type="html">
        &lt;p&gt;Geraldine posted a Photo on PhotoPanic&lt;/p&gt;
        &lt;img src="/geraldine/photo1.jpg"&gt;
    </content>
</entry>
]]]

It's clear to me this needs refactoring. As a strawman let me suggest:

[[[
<entry xmlns:atom="http://www.w3.org/2005/Atom"
     xmlns:activity="http://activitystrea.ms/spec/1.0/"
     xml:base="http://example.org/activities" >
    <id>tag:photopanic.example.com,2008:activity01</id>
    <title>Geraldine posted a Photo on PhotoPanic</title>
    <updated>2008-11-02T15:29:00Z</updated>
    <link rel="alternate"
     type="text/html"
     href="/geraldine/activities/1" />
    <link rel="alternate"
       type="text/html"
         href="/geraldine/photos/1" />
     <content type="html">
        &lt;p&gt;Geraldine posted a Photo on PhotoPanic&lt;/p&gt;
        &lt;img src="/geraldine/photo1.jpg"&gt;
    </content>
    <activity:when>2008-11-02T15:29:00Z<activity:when>
    <activity:type>
      tag:atomactivity.example.com,2008:photo
    </activity:type>
    <activity:verb>
      http://activitystrea.ms/schema/1.0/post
    </activity:verb>
</entry>
]]]

  - I don't think you need an activity-object if you use atom:entry, but 
I suspect it would be the top level element in a dedicated format)

  - I think you need activity:when to keep event times distinct from 
publishing/update times, so I added it.

  - I suspect activity:type could be a machine tag and therefor using 
atom:category with a scheme could be an option. This would allow a 
useful extension point.

  - If this was an IETF standards track, I would suggest an IANA 
registry for activity:verbs.

I think the of an activity entry format outside any one silo has legs 
and is a good idea, but I expect some objections and a need for hard 
graft to get it done. In no way do I think this is slam dunk as Sam 
suggests in his weblog [1]. Some reasons why:

  - How this aligns with the OpenSocial activity format needs to be 
squared up (and technically as well as you can get more bang for the 
byte with that format)
 
http://code.google.com/intl/fr/apis/opensocial/docs/0.7/reference/opensocial.Activity.html

- There is repetition of data - practically speaking there are a lot 
more activity events than blog posts, I'd guess easily one order of 
magnitude, probably two. Having a uniform means of serving them will 
result in more events, maybe getting us to three orders. I imagine we'll 
see claims the web will collapse under the weight.

- Having duplicate places to put data will easily confuse publishers, as 
will clients be confused by data acquisition from parent elements. This 
is just how things are with XML modelling.

- As a simple specification example, MUST requirements for foreign 
markup extensions as this draft needs are a problem (this is why AtomPub 
cannot mandate the "app:edited" element).

What I would do next:

  1 write down the anatomy of a well formed activity entry[2], and get 
buyin on that.

  2 re-examine commonality of its elements with Atom

  3 make a decision to re-use Atom format elements or embed an activity 
inside it. An example of the former approach is GData, an example of the 
latter is OpenSocial.

The latter is very important and is about technical and social tradeoffs 
- ime reusing Atom as a base in this way tends to make more sense as you 
have more and more formats and they start to look less and less like 
precious snowflakes and more like snow. By analogy, microformats all 
base off XHTML, but RDFa chooses to embed within XHTML [3].

Bill

[1] 
http://intertwingly.net/blog/2009/01/08/Atom-Media-Extensions-for-Activity-Streams

[2] imvho: involves describing where, what, when, who, why

[3] as a datapoint, the Atom WG did not reuse Dublin Core's elements, we 
chose to mint our own, mainly because they could not be redefined 
outside the spec (Atom's stability around versioning requires this).

---

From: Bill de hOra <[email-masked]>
Date: Thu, 08 Jan 2009 19:09:52 +0000

Bill de hOra wrote:

> [...]
[...]

Argh. Both should be xmlns="http://www.w3.org/2005/Atom"

Bill

---

From: Martin Atkins <[email-masked]>
Date: Thu, 08 Jan 2009 11:42:30 -0800

> throwing in xmlns and xml:base declarations:

Note that the top-level entry here represents the activity or action, 
while the content of activity:object (which is also an Atom Entry in all 
but name) represents the object of the activity.

Therefore these are in fact not duplicates. The entry-level atom:title 
is a human-readable description of the activity ("Geraldine posted ...") 
while the activity:object atom:title is the title of what Geraldine 
posted, which in this case is a photo with the title "My Cat".

>      http://activitystrea.ms/schema/1.0/post

This is very similar to the "implied activity" shorthand syntax 
described later in the spec, which is in fact what we expect most 
publishers to generate. The full-blown activity entries are intended to 
be posted by publishers such as FriendFeed and Plaxo whose entries 
represent actions rather than simply lists of objects.

You are correct that in this case there is ambiguity for a few elements:

* If the verb is something other than "post", atom:published becomes the 
activity time rather than the published time. The definition of the 
"post" verb means that for that verb the activity time and the 
publication time are always the same, since it was not published until 
it was posted.

* atom:author becomes the activity actor rather than the author of the 
object. Again, in the "post" case these are the same, but for other 
verbs they are not necessarily the same. Unfortunately existing practice 
constrains the solution here; for example, YouTube's "favorite" feeds 
have atom:author set to the user that owns the feed, not the user who 
authored the video. Therefore the spec currently says that the author 
belongs to the activity, not to the object.

I think I've addressed many of your points above, so I'll just respond 

> atom:category with a scheme could be an option. This would allow a 

I did actually already get feedback in favor of machine tags, but they 
made me wary for two reasons:
  * They are not yet widely known or adopted, as far as I can tell.
  * (and this point relates to the use of atom:category in general) many 
existing aggregators display to the user all categories regardless of 
scheme, and a design goal of this specification is for the new 
annotations to cause no visible difference in legacy software, so that 
there will be less resistance to adoption.

>  - If this was an IETF standards track, I would suggest an IANA registry 
> for activity:verbs.
> 

Do you intend the IANA registry to replace the use of URIs as the 
extension mechanism with simple keywords?

This is certainly something that could be considered.

> http://code.google.com/intl/fr/apis/opensocial/docs/0.7/reference/opensocial.Activity.html 

In discussions with OpenSocial folks we got the impression that they 
would consider using an Atom-based format for activities. I used their 
schema as one of my research sources for this specification.

Right now the main "inspiration" for this spec are the syndication-based 
activity aggregators such as FriendFeed, Plaxo, Movable Type Action 
Streams, etc, but I agree that it is important to align with OpenSocial too.

> see claims the web will collapse under the weight.

The "implied activity" shorthand is intended to address this. In the 
weblog case, one needs only to add a single element to each entry to 
mark it up as a weblog entry:
     <object-type xmlns="http://activitystrea.ms/spec/1.0/">
         http://activitystrea.ms/schema/1.0/blog-entry/
     </object-type>

though of course in practice many activity consumers are likely to 
present an un-annotated entry much like a weblog entry because that's 
what they do today.

The work for things such as photos and videos is slightly more since 
some providers would need to add thumbnail links and so forth, but it 
was a very strong requirement that existing feeds would require only 
minimal changes -- and, in most cases, only additions -- to hit the 
important use-cases for this spec.

> is just how things are with XML modelling.

The most important feedback I've taken from this is that the spec should 
be re-organised to emphasise the implied activity shorthand rather than 
starting with the full "activity entry" case, since I expect only 
activity aggregator services to publish the latter, and indeed the 
motivation for this separation is that these publishers already have 
feeds that represent activities rather than objects.

Thanks for the very detailed feedback. Six Apart is hosting a meet-up 
regarding activity streams publishing this afternoon[1] where we can 
take a look at the feedback we've recieved.

Cheers,
Martin

[1] http://upcoming.yahoo.com/event/1470821/
(Folks are welcome to come, though I realise this is late notice for 
those who are only just finding out about it now.)

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 8 Jan 2009 12:58:55 -0800

Thanks for opening up the archives for that group. I'll take a detailed look at the spec this weekend and send some feedback. 

--
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.)

---

From: Bill de hOra <[email-masked]>
Date: Fri, 09 Jan 2009 00:10:10 +0000

Martin Atkins wrote:
>> activity:object Extension Element" is saying to use atom:* elements. 
>> So I think the example XML is buggy, and here's my attempt at a fix by 

  - with that many elements there will be boilerplate data injected into 
one or the other. James has already mentioned this, and it is an age old 
problem with markup, one that predates XML and HTML. Given what I know 
about event formats in general and SN specific data like activities 
which I have to aggregate, I think you have too many tags, which leads 
me to...

  - ...volume. My rule of thumb is that each interesting thing that 
happens in a web system causes about 10 events and you should plan to 
scale accordingly. I believe social network activity to be like this. My 
guess is that verbosity of the proposal (which I don't normally care 
about) will be an adoption factor.

And even if you are right about non-duplication, then there are still 
two arguments to be had,

  - rename all the activity elements so people are not confused about 
the purpose of the elements (I don't necessarily agree with this 
approach, but it's real)

  - either remove atom:source from activity:object or type qualify 
atom:source as being the source of the action and lift it up. I have a 
doubt you need both elements, unless there is a use case where an 
intermediary like friendfeed needs atom:source for something else.

> belongs to the activity, not to the object.

In markup-land, these are called co-occurence constraints. I would try 
to avoid them if possible :)

> there will be less resistance to adoption.

Makes sense to me.

> extension mechanism with simple keywords?

No, just to act as social control as per the link registry. If these 
will be acting as switch-on-type controls in code rather than data to be 
rendered out, then I can't imagine verb proliferation being  beneficial 
(what will happen is that the problem Dave Winer has identified with 
photo media and which Dare Obsanjo has explained will get pushed around 
rather than solved - activity:verb reminds me of soap:action in that 
sense).

> Streams, etc, but I agree that it is important to align with OpenSocial 

I work on aggregation for mobile systems, and while its not a format 
issue, I suspect the amount of data being served to describe the 
activity is high enough to impact services that are not flat-rated. Do 
the spec backers want to send that much data down to a handset?

>> result in more events, maybe getting us to three orders. I imagine 
>> we'll see claims the web will collapse under the weight.
> 

Right, and this approach is closer to how MediaRSS acts wrt to RSS/Atom, 
which leaves the door open for broadly consistent profiling of feed data 
down the line.

> important use-cases for this spec.

I think this is more an abbreviated syntax than an implied activity and 
I'd strongly suggest you pick just one and spec it  - keeping client and 
server dev work to a minimum ups the chance of adoption. [Having an 
abbreviated syntax without question damaged RDF/XML].

>> - Having duplicate places to put data will easily confuse publishers, 
>> as will clients be confused by data acquisition from parent elements. 
>> This is just how things are with XML modelling.
> 

That and the fact that everyone who uses this spec will have to think 
about where to put the data instead of being able to guess right. Reduce 
that burden!

> take a look at the feedback we've recieved.

Good luck with it.

Bill

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 8 Jan 2009 23:42:10 -0800

Comments on each doc

1.)     http://martin.atkins.me.uk/specs/atommedia
 - This spec describes a bunch of elements but not how they are supposed to be used. I'm especially confused about atom:link with rel="preview". What is it a preview of? The example in the spec has a single preview (pic) and two enclosures (also pictures). How is that expected to be treated? I'd expect there to be a 1:1 mapping between enclosures and previews but there doesn't seem to be any such rule in the spec.

2.) http://martin.atkins.me.uk/specs/activitystreams/atomactivity
 - Verbs seem to be poorly defined and unnecessary. It seems they are either a way to categorize items in a feed (i.e. use atom:category) or a way to point to an end point where an action can be taken (i.e. use rel="verbname" the same way AtomPub has rel="edit".
 - The list of base object types is missing update types that are common on social networking sites such as relationships ('Dare is a friend of Rob', 'Dare is a fan of Metallica'), profile changes ('Dare is now married', 'Dare has updated his occupation to cubicle dweller') and even reviews ('Dare rates the Zombies application ** out of *****)

3.) http://martin.atkins.me.uk/specs/activitystreams/atomactivity
- As I mentioned above, I can't see why an extension element is needed for activity:verb instead of atom:category or link@rel="post|markfavorite"
- activity:object just seems super weird. It is effectively an atom:entry embedded inside the atom:entry. This seems like a significant amount of duplication of data and a recipe for lots of confusion by feed consumers and producers. Almost every element that is a child of the activity:object seems redundant to the same elements that are children of the parent atom:entry. There needs to be more explanation of this design so it can be properly understood. I can imagine some simple scenarios where the activity:object may seem to help but it breaks down really quickly
- activity:object-type should either be an attribute/element of activity:object or even better a machine readable atom:category.

These are just quick impressions based on my experiences in this space. I'll try to go over the specs in more detail later.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Atkins
Sent: Thursday, January 01, 2009 4:38 PM
To: Atom Syntax
Subject: Some Draft Atom-related Specs for Activity Streams

Hi folks,

Thanks,
Martin

---

From: Martin Atkins <[email-masked]>
Date: Sun, 11 Jan 2009 12:56:10 -0800

(In the interests of addressing the interested audiences, what I'm doing 
here is addressing Dare's comments about activity streams over on the 
activity streams mailing list, and the media extensions over here.)

My feedback to Dare about the activity stuff can be viewed here:
http://groups.google.com/group/activity-streams/msg/27d35bbb13281640

Dare Obasanjo wrote:
>  - This spec describes a bunch of elements but not how they are
> supposed to be used.  I'm especially confused about atom:link with
 > rel="preview". What is it a preview of? The example in the spec
 > has a single preview (pic) and two enclosures (also pictures).
 > How is that expected to be treated? I'd expect there to be a
> 1:1 mapping between enclosures and previews but there doesn't
 > seem to be any such rule in the spec.
> 

The text of the spec here is:

     The "preview" link relation indicates that the link is to a
     reduced-fidelity and/or reduced-content representation of the media
     object that is intended to allow the user to sample the content
     before retrieving a full representation.

 From your mention of multiple enclosures I think the confusion arises 
because AtomMedia specifically addresses only the use-case where an 
entry represents one specific media object -- that is, one photo, or one 
video, etc -- so all enclosures and all previews are of that same object.

Specifically, if there are multiple enclosures they are expected to be 
different representations of the same content.

So "the media object", as referred to in the description of 
rel="preview", means the single photo, video or other media object that 
this entry represents.

The spec then goes on to give some concrete examples:

     For example, if the media object is an image a thumbnail of the
     photograph can be linked using this relationship.

     If the media object is a video, the preview could be a thumbnail
     image of a representative frame from the video, or a clip showing a
     short segment of the full video.

Would clarifying the fact that a particular entry represents only one 
media object address your concern, or are the above quoted passages 
themselves unclear?

Thanks for the feedback.
-Martin

---

From: Martin Atkins <[email-masked]>
Date: Sun, 11 Jan 2009 20:28:27 -0800

Bill de hOra wrote:
>>> So I think the example XML is buggy, and here's my attempt at a fix 
>>> by throwing in xmlns and xml:base declarations:
>>
>> while the content of activity:object (which is also an Atom Entry in 
>> all but name) represents the object of the activity.
>>
>> is a human-readable description of the activity ("Geraldine posted 
>> ...") while the activity:object atom:title is the title of what 
>> Geraldine posted, which in this case is a photo with the title "My Cat".
> 

Activity aggregator services already use the entry-level title to encode 
  a human-readable activity description, and they do this for the 
benefit of non-activity-aware consumers, so the actual title of the 
object must be in a distinct element.

My intent with activity:object was to be able to re-use the Atom 
elements which are already understood rather than inventing new 
elements. I consider this to be similar in design to atom:source, which 
re-uses the existing Feed-level elements.

>  - rename all the activity elements so people are not confused about the 
> purpose of the elements (I don't necessarily agree with this approach, 
> but it's real)
> 

So you believe that re-using the Atom elements inside activity:object is 
confusing? If this is the case, then my design has indeed failed, since 
my intention was exactly the opposite... that activity:object/atom:title 
would be understood to mean "the title of the object" based on people's 
existing understanding of what atom:title means.

> intermediary like friendfeed needs atom:source for something else.

atom:source inside activity:object tells us where the aggregator (i.e. 
FriendFeed) found the object.

atom:source as a sibling of activity:object comes into play when the 
source feed already contains activity entries; FriendFeed is not 
synthesizing implied activities in this case.

The most readily-available example of such an instance is when I feed 
the output of Plaxo (another activity aggregator) into FriendFeed. In 
that case, there ought to be an atom:source sibling to activity:object 
that refers to the Plaxo feed, while the atom:source inside 
activity:object would be the source as far as *Plaxo* is concerned.

Without this distinction, the following activity published on Plaxo:
    "Martin posted a photo on Flickr"
would become the following when read into FriendFeed:
    "Martin posted a photo on Plaxo"
or worse,
    "Martin posted 'Martin posted a photo on Flickr' on Plaxo'"

Do you believe that this level of indirection is counter-intuitive?

>> * If the verb is something other than "post", atom:published becomes 
>> the activity time rather than the published time. The definition of 
>> the "post" verb means that for that verb the activity time and the 
>> verbs they are not necessarily the same. Unfortunately existing 
>> practice constrains the solution here; for example, YouTube's 
>> "favorite" feeds have atom:author set to the user that owns the feed, 
>> not the user who authored the video. Therefore the spec currently says 
>> that the author belongs to the activity, not to the object.
> 

As I'm sure you will have seen, I've started a separate thread about 
this, since I believe the problem is more general than AtomActivity.

> rather than solved - activity:verb reminds me of soap:action in that 

Okay, I understand. As currently defined, the ActivitySchema spec is 
effectively the registry and I suppose you need to go through me to get 
new verbs under http://activitystrea.ms/ added; once the spec is final, 
it would make sense to have a mechanism like an IANA registry to allow 
other specifications to extend the core set.

>> Right now the main "inspiration" for this spec are the 
>> syndication-based activity aggregators such as FriendFeed, Plaxo, 
>> Movable Type Action Streams, etc, but I agree that it is important to 
>> align with OpenSocial too.
> 

This is of course a concern; adding more data will always disadvantage 
those consumers that are not making use of that data.

If there is an activity-aware aggregator running on a mobile device it 
will presumably be interested in this extra data, but a generic 
aggregator will of course ignore it having already spent the data 
transfer on it.

As far as I can tell, the best way that the industry has found to deal 
with this problem thus far is to serve different content to constrained 
devices than to traditional computers, whether done by providing two 
parallel resources (m.sitename.com vs. www.sitename.com) or by using 
heuristics to determine whether a user-agent is resource-constrained and 
automatically delivering the constrained version.

On the other hand, it could be argued that AtomActivity would enable a 
mobile-based activity aggregator to use a single feed on FriendFeed in 
place of fetching a number of site feeds individually and mimicking the 
functionality of FriendFeed client-side, which would presumably be more 
efficient overall.

> abbreviated syntax without question damaged RDF/XML].

The two kinds of entry already exist in the wild, so I'm wary of 
excluding it from the spec. FriendFeed would be unable to use the 
implied activity shorthand without changing the content of their feeds 
as percieved by non-activity aggregators, and the reverse is true for 
sites such as YouTube and Flickr that currently publish what I refer to 
as "object entries".

>> The most important feedback I've taken from this is that the spec 
>> should be re-organised to emphasise the implied activity shorthand 
>> rather than starting with the full "activity entry" case, since I 
>> expect only activity aggregator services to publish the latter, and 
>> indeed the motivation for this separation is that these publishers 
>> already have feeds that represent activities rather than objects.
> 

It is my current belief that legacy software (both on the publisher and 
consumer side) requires at least some duplication in the "activity 
entry" case, but I will definitely take your feedback on board and see 
if it can be made clearer and less redundant.

Thanks,
Martin

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 11 Jan 2009 21:34:43 -0800

> Would clarifying the fact that a particular entry represents only one media object address your concern, or are the above quoted passages themselves unclear?

Making that constraint explicit up front would address the concern. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Atkins
Sent: Sunday, January 11, 2009 12:56 PM
To: Atom Syntax
Subject: Re: Some Draft Atom-related Specs for Activity Streams

Thanks for the feedback.
-Martin