Issue 1: Representing collections: Albums, Playlists, Groups
Monica Keller
objects. The representation of this collections is not particularly
interesting without listing the contents. For ex: A music playlist
titled "Happy Songs" does not not really engage the reader. However
providing information such as the list of songs and even better the
authors of those songs is much more engaging as the reader can
quickly
detect if the publisher of the activity has similar musical taste.
The current approach is to only include in the activity entry the
most
granular level. In the example above this would be the single song
being
added to the playlist, and expecting the consumer of the activity to
coalesce.
This is less efficient. The consumer should be able to request the
feed
aggregated by parent object in this case the Playlist.
Solutions discussed so far:
- Add multiple activity:object entries in atom:entry --> The problem
with
this approach is that while this would allow us to list each song in
the
playlist, there is no place for the attributes of the Playlist itself
inside the atom:entry. It would have to go inside each
activity:object
with the atom:source. Note that the entry does also have source but
this
is reserved to convey the origin of the activity (via)
- Only add one entry for the collection object then have a link to get
the
contents of this collection object --> The problem with this approach
is
performance and having to make multiple requests. However it is quite
extensible letting the hierarchy expand n levels.
- Use Microsoft's $expand concept which allows the consumer to request
the
child feed inline. See http://msdn.microsoft.com/en-us/library/dd541218.aspx
--> This approach is semi compatible with the one
above. MSFT also has the option of providing a count which we should
consider. For example, a photo album has 100 pictures but we are only
providing the thumbnails of 10 pics in the album.
Martin Atkins
> - Only add one entry for the collection object then have a link to get
> the
> contents of this collection object --> The problem with this approach
> is
> performance and having to make multiple requests. However it is quite
> extensible letting the hierarchy expand n levels.
I think having the top-level object of the activity be a photo album
doesn't quite fit the model used by existing applications, where "create
an album" and "add a photo to an album" are two distinct activities that
could in fact happen years apart.
> - Use Microsoft's $expand concept which allows the consumer to request
> the
> child feed inline. See
http://msdn.microsoft.com/en-us/library/dd541218.aspx
> --> This approach is semi compatible with the one
> above. MSFT also has the option of providing a count which we should
> consider. For example, a photo album has 100 pictures but we are only
> providing the thumbnails of 10 pics in the album.
>
Unfortunately this is a protocol-level feature rather than a
syntax-level feature, and we're currently exploring only syntax.
However, we should make a note of this for when we later inevitably
start working on standard protocols for efficiently exchanging activities.
>
> - Add multiple activity:object entries in atom:entry --> The problem
> with
> this approach is that while this would allow us to list each song in
> the
> playlist, there is no place for the attributes of the Playlist itself
> inside the atom:entry. It would have to go inside each
> activity:object
> with the atom:source. Note that the entry does also have source but
> this
> is reserved to convey the origin of the activity (via)
>
I think this approach is the best fit, with some adjustments.
First though I'd like to note that multiple activity:object elements in
an activity isn't defined to have any special meaning to an activity
processor, which is supposed to process it as a sequence of separate
activities. The multi-object syntax is there for the benefit of
non-activity feed readers.[1]
However, you're right that presently there isn't a good way to provide
the photo album as a pivot for an activity-aware aggregator to do
clustering.
Let's assume for the moment that the syntax spec includes
activity:target (the "indirect object") as an optional element in
activity entries. That then allows us to model my posting of several
photos into a photo gallery as follows:
<entry>
<title>Martin added three photos to an album</title>
<activity:verb>
http://activitystrea.ms/schema/1.0/post/
</activity:verb>
<activity:object>
<title>Coit Tower</title>
<activity:object-type>
http://activitystrea.ms/schema/photo/
</activity:object-type>
...
</activity:object>
<activity:object>
<title>Sealions</title>
<activity:object-type>
http://activitystrea.ms/schema/photo/
</activity:object-type>
...
</activity:object>
<activity:object>
<title>Windmill in Golden Gate Park</title>
<activity:object-type>
http://activitystrea.ms/schema/photo/
</activity:object-type>
...
</activity:object>
<activity:target>
<title>My trip to San Francisco</title>
<activity:object-type>
http://activitystrea.ms/schema/photo-album/
</activity:object-type>
...
</activity:target>
...
</entry>
This depends on a few things we don't have today:
* The activity:target element
* A photo-album object type
* A definition of how to interpret activity:target when used with the
"post" verb. (It is to be interpreted as the thing into which the object
was posted.)
This must still be manually clustered by a processor in the same way as
the previous atom:source approach, but the photo gallery appears only
once rather than in every entry, which is far less wasteful.
------------------------------------------
[1] Why is this distinction important? Consider the following three
activity sentences:
* Martin posted 5 photos on MySpace
* Martin posted 2 photos on Flickr
* Martin posted 1 photo on MySpace
An activity aggregator may choose to present this as a single activity
"Martin posted 8 photos", or it might choose to bundle the second
MySpace activity with the first and collapse down to two. In both cases,
the object bundling in the source feeds is ignored.
Monica Keller
Right now basically we dont have enough pointers to objects.
Ex: "Monica rated the restaurant Feast from the East giving it a 4 out
of 5 stars on MySpace Local"
Where "Feast from the East" can be the target and the review can be
the object and MySpace Local is our entry source
We may even need to consider more than one target for the case when a
user tags several people in a photo or note :)
Ok but going back to the adding photos or songs example, if we add
<activity:target> at the entry level, then <atom:source> at the
<activity:object> level becomes obsolete. I think we would need to
document very clearly when an object has a source
This is what we currently have
<activity:object xmlns:activity="http://activitystrea.ms/schema/1.0/">
<activity:object-type>http://activitystrea.ms/schema/1.0/Photo</
activity:object-type>
<id>tag:myspace.com,2009:/activity/279470469/PhotoAdd/
279470469/109231460</id>
<title></title>
<link rel="alternate" type="text/html" href="http://
viewmorepics.myspace.com/index.cfm?
fuseaction=viewImage&friendID=30740513&albumID=1794489&imageID=54341375" /
>
<link rel="preview" type="image/jpeg" href="http://c2.ac-
images.myspacecdn.com/images02/31/
s_da638cc1d2e64b33a679629cfa5bbab5.jpg" />
<source>
<title>New Inspirational Posters</title>
<link rel="alternate" type="text/html" href="http://
viewmorepics.myspace.com/index.cfm?
fuseaction=user.viewPicture&friendID=30740513&albumId=1794489" /
>
</source>
</activity:object>
New way :
<activity:object xmlns:activity="http://activitystrea.ms/schema/1.0/">
<activity:object-type>http://activitystrea.ms/schema/1.0/Photo</
activity:object-type>
<id>tag:myspace.com,2009:/activity/279470469/Photo/
279470469/109231460</id>
<title></title>
<link rel="alternate" type="text/html" href="http://
viewmorepics.myspace.com/index.cfm?
fuseaction=viewImage&friendID=30740513&albumID=1794489&imageID=54341375" /
>
<link rel="preview" type="image/jpeg" href="http://c2.ac-
images.myspacecdn.com/images02/31/
s_da638cc1d2e64b33a679629cfa5bbab5.jpg" />
</activity:object>
<activity:target>
<id>tag:myspace.com,2009:/activity/279470469/Album/279470469</id>
<activity:object-type>http://activitystrea.ms/schema/1.0/PhotoAlbum</
activity:object-type>
<title>New Inspirational Posters</title>
<link rel="alternate" type="text/html" href="http://
viewmorepics.myspace.com/index.cfm?
fuseaction=user.viewPicture&friendID=30740513&albumId=1794489" /
>
</activity:target>
As we can see activity:target has the same definition as
activity:object so couldn't we just use activity:object for the photo
album and add a new role property ... consider it
We could even infer role from verb + object types of the elements,
especially if we define a base collection object type which photo
album, playlist, etc would derive from
On Apr 5, 11:35 pm, Martin Atkins <m...@degeneration.co.uk> wrote:
> Monica Keller wrote:
>
> > - Only add one entry for the collection object then have a link to get
> > the
> > contents of this collection object --> The problem with this approach
> > is
> > performance and having to make multiple requests. However it is quite
> > extensible letting the hierarchy expand n levels.
>
> I think having the top-level object of the activity be a photo album
> doesn't quite fit the model used by existing applications, where "create
> an album" and "add a photo to an album" are two distinct activities that
> could in fact happen years apart.
>
> > - Use Microsoft's $expand concept which allows the consumer to request
> > the
Martin Atkins
> Adding the target element would help for other scenarios as well.
> Right now basically we dont have enough pointers to objects.
> Ex: "Monica rated the restaurant Feast from the East giving it a 4 out
> of 5 stars on MySpace Local"
>
> Where "Feast from the East" can be the target and the review can be
> the object and MySpace Local is our entry source
>
We should perhaps start a separat thread for this, but I was going to
propose modelling reviews as a funny sort of reply. In other words,
there'd be an object type called "review" and it would be marked as
being inReplyTo the object it's reviewing.
"MySpace Local" in that sentence seems to be in the same position as
"Flickr" in the sentence "Martin posted 5 photos on Flickr", so I think
what you have there is a "service provider" rather than a source.
However, I don't really know enough about MySpace Local to say what the
best representation of it is.
So in your example:
* The verb is "post"
* The object is the review
* The review is of type "review"
* The review has an in-reply-to element pointing at the object it's a
review of.
* We invent a simple schema for representing review scores and so forth,
probably based on the data model defined for hReview in the Microformats
community.
> We may even need to consider more than one target for the case when a
> user tags several people in a photo or note :)
That seems sensible, though it would need to be carefully defined.
> Ok but going back to the adding photos or songs example, if we add
> <activity:target> at the entry level, then <atom:source> at the
> <activity:object> level becomes obsolete. I think we would need to
> document very clearly when an object has a source
Indeed. In the case where the verb is "post" it is implied that the
object(s) in the entry are now contained within the object provided as a
target.
You could in theory still include atom:source to indicate the *primary*
place where something lives, but it's not necessary. It will still be
useful for situations where items are borrowed from one feed and
republished in another.
Can you post an example of this? I'm not sure I understand what you're
proposing here.
Monica Keller
proposing here.
pretty much the same as an activity:object
We can just add a new property "object-role" and set it to Target or
Parent
<activity:object>
<activity:object-type>
http://activitystrea.ms/schema/photo-album/
</activity:object-type>
activity:object-role>
</activity:object>
<activity:object>
<title>Coit Tower</title>
<activity:object-type>
http://activitystrea.ms/schema/photo/
</activity:object-type>
...
</activity:object>
<activity:object>
<title>Sealions</title>
<activity:object-type>
http://activitystrea.ms/schema/photo/
</activity:object-type>
...
object. Or maybe some properties which allow us to note its a
collection of n items. I think this is pretty valuable as users will
engage based on details like this.
thanks
Martin Atkins
>>> Can you post an example of this? I'm not sure I understand what you're
> proposing here.
>
> Sure. So instead of redefining what an activity:target is which is
> pretty much the same as an activity:object
>
> We can just add a new property "object-role" and set it to Target or
> Parent
>
> <activity:object>
> <title>My trip to San Francisco</title>
> <activity:object-type>
> http://activitystrea.ms/schema/photo-album/
> </activity:object-type>
> <activity:object-role>http://activitystrea.ms/schema/target</
> activity:object-role>
> ...
> </activity:object>
Hmm.
I'm not sure about this, since object-role seems to be re-inventing the
concept of element names... if something has a different meaning then it
ought to have a different element name. The fact that object and target
have the same content model doesn't necessarily mean that it must have
the same element name. For example, in HTML we don't have <inline-style
type="bold"> and <inline-style type="italic">.
(Though regrettably, as a side-note, the XML format for RFCs that we're
using for the specs does have <spanx type="emphasis">, which is
incredibly tedious to set, which is why I'm often lazy about it.)