Namespace for referencing "Likes" and "Tags"

[Diana]

Hello,

I was wondering what's the correct way of representing that a "parent"
activity has got "likes" and "tags" in Atom/AS. In the case of
comments or replies, a link is added to the parent activity, such as:

<link rel="replies" type="application/atom+xml" href="http://
www.example.org/mycommentsfeed.xml" thr:count="10"
thr:updated="2005-07-28T12:10:00Z" />

where the Atom Threading Extensions namespace is used to include the
replies count and date of last replies update.

In the case of Google Buzz I have seen that they are using their own
namespace for the referencing "likes" in the parent activity:

<link rel="http://schemas.google.com/buzz/2010#liked"
type="application/poco+xml" href="https://www.googleapis.com/buzz/v1/
activities/114514765867914874469/@self/
B:z13ohrwi4pyrfjcar04cdxxhfpfwufiakl40k/@liked?alt=atom"
buzz:count="1"/>


But I was wondering if there is not an existing namespace or
specification (like the atom threading extension) that can be used,
instead of having to mint my own.

Thanks in advance,
Diana.

[Rob Dolin]

Hmmm, in the case of the rel attribute for linked feeds of Likes and Tags, what about using:
* "http://activitystrea.ms/schema/1.0/like" for Like
(see: http://activitystrea.ms/schema/1.0/activity-schema-01.html#like)
* "http://activitystrea.ms/schema/1.0/tag" for Tag
(see: http://activitystrea.ms/schema/1.0/activity-schema-01.html#tag)

FWIW--
--Rob

Hello,

Thanks in advance,
Diana.

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

[Mike Macgirvin]

Friendika just uses as-schema:like activities and transmits/stores
them as if they were any other comment.

This works quite well, but I suppose the point you're getting at is
how do you quickly display "how many"?

Google's link extension has the ability to display a pre-tallied
total, but there don't appear to be any standard mechanisms for doing
this.

We just count them.

One has to evaluate them individually anyway - if you want to be able
to say "joe, mary, bob, and six other people liked this" (although I
suppose one could always delegate that to an XHR query).

Google's approach is fascinating though. Turning this into a poco
result set is an interesting solution to the problem of iterating the
identities - and also removes the need to use AS to propagate them. In
the primary feed one only needs to increment the count and it takes no
extra bandwidth until such time as there is a need to expand the set.

In the AS approach, each "like" is a hefty Atom/AS entry and these can
add up to a lot of bandwidth to convey a relatively small amount of
information.

It wouldn't take much to convince me that Google's approach is
technically superior. But if you want something that's more or less
standard and widely supported, AS wins - for better or worse.

[Mike Macgirvin]

It then occurred to me that using Atom thread with separate comment
feeds could be problematic for "like" activities, because they all
will count as "comments" - and this may not be the desired outcome.
(Friendika does not use separate comment feeds - the primary feed
contains full conversations with the original post, likes, replies,
etc.).

I would be interested to know how other implementers deal with this
situation. The feed consumer in this environment would effectively
have to ignore thr:count until they've parsed the comment feed to
separate total "likes" (and perhaps "tags", etc.) from total
"comments" - which sort of negates any advantages to having
thr:count.

[Will Norris]

yeah, it's a question of what data structure you're linking to.  Buzz lists the "likers" of the activity (represented using PoCo), not the "liking" activities.  This is the primary reason we went with our own rel value for the time being, figuring we could switch to a standard value if and when one were ever decided on.

-will

--

[Daniel Chapman]

This isn't too dissimilar to the retweet thread, where we are starting
to find situations where we may have to choose between a technically
more efficient method (i.e. Google's method) or a specification
perfect method (linked AS objects).

In this case though, it's not even clear cut as some services will
usually only need a summary, but others may need the full
information.

Perhaps we could add some new attributes, elements or a rel that can
be used to summarize things like reply, like and retweet counts? Or is
that getting out of scope for AS?

Both sides have strong use cases. We certainly don't want to weigh
down the feeds with every like and retweet if we aren't explicitly
using them. But nor do we want to force any processes to wait until
they have counted (after possibly retrieving via separate requests)
everything before they can continue.

Is there a good way we can meet both needs?

> > activity-strea...@googlegroups.com<activity-streams%2Bunsubscrib e...@googlegroups.com>
> > .