Spec has no negative actions like 'unfollow', 'unlike', 'leave', 'delete'?

[Todd Barnard]

Just saw this semi-snarky tweet go by;

"Just realized that #activitystreams has no negative actions like
'unfollow', 'unlike', 'leave', 'delete'."

http://twitter.com/exavolt/status/16175274100


A quick look at the spec makes me think there is some validity to the
statement.

Is it true?

[Chris Messina]

It is true, and has been discussed many times.

Negative actions may someday be supported, but we haven't catalogued
many examples-in-the-wild where they're being published today.
ActivityStreams as a format can take any verb in any namespace, we
just haven't added negative verbs to our namespace.

Furthermore, ActivityStreams is not really designed as a sync protocol
(see FeedSync instead). Therefore, just because a negative action
appears in a stream doesn't tell you if there should be any
consequence for it showing up. In other words, just because, say, a
"deleted a photo" activity came in doesn't mean that a cached copy of
the photo should be deleted (it's just not specified yet).

Lastly, negative actions may not all have corrolaries. Like, you can't
really "unpost" something! Bottom line: we need more research and more
implementations before we can support features that are not fully
understood.

Chris

Sent from my iPhone 2G

> --
> You received this message because you are subscribed to the Google
> Groups "Activity Streams" group.
> To post to this group, send email to activity-
> str...@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
> .
>

[Steven Livingstone-Perez]

"Unlike" is maybe one I think is needed.... or rather "dislike" (as unlike
seems to indicate you liked it and changed your mind - perhaps useful in
clothing outlets tho' ).

I often dislike items on Facebook (yesterday I actually wrote "I wish I
could dislike this" picture) for example but a comment is often over the
top.

/steven
http://livz.org

Chris

To post to this group, send email to activity...@googlegroups.com.

[James Walker]

I (still) think there is value in having unfollow, unlike, leave
(group). Again, we're utilizing them in OStatus as notifications (via
salmon, which IIRC makes feedsync difficult).

Consider that one vote still in the ring for adding them.

.j

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

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

--
James Walker :: http://walkah.net/ :: http://james.status.net/

[Todd Barnard]

"ActivityStreams is not really designed as a sync protocol...we need

more research and more implementations before we can support features

that are not fully understood..."

Sorry if I am reiterating a subject, my fault for not paying enough
attention. Most important is that the (potential) issue is known.
Completely OK if it hasn't been addressed yet, and I am not nagging or
asking for immediate action.

For what its worth, unfollow, unlike, leave, etc. are human behaviors,
and quantifying them for machine understanding ( and the resulting
machine action! ) is part of the grand scheme of things.



T

On Jun 15, 9:07 am, Chris Messina <chris.mess...@gmail.com> wrote:
> It is true, and has been discussed many times.
>
> Negative actions may someday be supported, but we haven't catalogued  
> many examples-in-the-wild where they're being published today.  
> ActivityStreams as a format can take any verb in any namespace, we  
> just haven't added negative verbs to our namespace.
>
> Furthermore, ActivityStreams is not really designed as a sync protocol  
> (see FeedSync instead). Therefore, just because a negative action  
> appears in a stream doesn't tell you if there should be any  
> consequence for it showing up. In other words, just because, say, a  
> "deleted a photo" activity came in doesn't mean that a cached copy of  
> the photo should be deleted (it's just not specified yet).
>
> Lastly, negative actions may not all have corrolaries. Like, you can't  
> really "unpost" something! Bottom line: we need more research and more  
> implementations before we can support features that are not fully  
> understood.
>
> Chris
>
> Sent from my iPhone 2G
>

[Peter H. Reiser]

Hi  Chris (and activtiystrea.ms community)- 

I getting pretty disappointed that negative actions are "just" discussed but no  real progress has been made. 

I think  that the AS standard is 99% focused on the public feed  use case   and it is completely ignoring the  huge potential of "Intranet/Enterprise 2.0" use cases. 

Furthermore social activities  are not just based on positive events -  in an (social) system you have positive and negative activities. 

I strongly suggest  to include the main negative verbs like unlike, leave, unfollow, unfavorite, rate and (potentially) delete into to the standard AS verbs

(or at least define  a standard name space  for such verbs)

As you might know we have already implemented all the negative  verbs in our Community Equity implementation but we had to use our own name space.

But we want to able  consume any activity streams from any sites (including negative verbs) and don't wont to modify our parser each time we consume a new feed with own name spaces. 

see some more feedback inline below.

Regards

Peter

On Jun 15, 2010, at 4:07 PM, Chris Messina wrote:

It is true, and has been discussed many times.

Negative actions may someday be supported, but we haven't catalogued many examples-in-the-wild where they're being published today. ActivityStreams as a format can take any verb in any namespace, we just haven't added negative verbs to our namespace.

There are well documented examples in the AS wiki today. .. 

Adding an own namespace makes the standard more complex to adopt (e.g need to write specific parser rules per feed) 

Furthermore, ActivityStreams is not really designed as a sync protocol (see FeedSync instead). Therefore, just because a negative action appears in a stream doesn't tell you if there should be any consequence for it showing up. In other words, just because, say, a "deleted a photo" activity came in doesn't mean that a cached copy of the photo should be deleted (it's just not specified yet).

Its not about syncing - its about capturing all the social activities. 

Lastly, negative actions may not all have corrolaries. Like, you can't really "unpost" something! Bottom line: we need more research and more implementations before we can support features that are not fully understood.

Why  do negative actions need a correlation to a positive action ?  It as usually an expression of an opinion and does not need to match with a positive term. 

PS: Ohh - and the hot topic in Social media today is sentiment analysis .. hmm  what if we just have positive sentiments .. hmm would be nice .. but pretty unrealistic :)

Chris

Sent from my iPhone 2G

On Jun 15, 2010, at 6:14 AM, Todd Barnard <roni...@gmail.com> wrote:

Just saw this semi-snarky tweet go by;

"Just realized that #activitystreams  has no negative actions like

'unfollow', 'unlike', 'leave', 'delete'."

http://twitter.com/exavolt/status/16175274100

A quick look at the spec makes me think there is some validity to the

statement.

Is it true?

--

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.

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

[James Walker]

What Peter said.

--

[Laurent Eschenauer]

Furthermore, ActivityStreams is not really designed as a sync protocol (see FeedSync instead). Therefore, just because a negative action appears in a stream doesn't tell you if there should be any consequence for it showing up. In other words, just because, say, a "deleted a photo" activity came in doesn't mean that a cached copy of the photo should be deleted (it's just not specified yet).

I second that. If the purpose of negative actions is simply to trigger a business logic similar to 'delete the related item', then it should not be done at the data model level. Instead, that should be handled by the distribution protocol. In onesocialweb, we handle the delete/undo cases by using the <retract/> flow of the PubSub pattern. I'm sure that a similar flow could be brought in PuSH.

Now, if you are talking about the need for users to express and share with other users an action with a negative flavor, then indeed it should be expressed in the data model. I don't see much use cases besides 'dislike'. Are you refering to the later cases ? What other use cases do you see ?

And in that case, you still need a way to 'negate a negative action' :-)

Laurent

Lastly, negative actions may not all have corrolaries. Like, you can't really "unpost" something! Bottom line: we need more research and more implementations before we can support features that are not fully understood.

Chris

Sent from my iPhone 2G

On Jun 15, 2010, at 6:14 AM, Todd Barnard <roni...@gmail.com> wrote:

Just saw this semi-snarky tweet go by;

"Just realized that #activitystreams  has no negative actions like
'unfollow', 'unlike', 'leave', 'delete'."

http://twitter.com/exavolt/status/16175274100


A quick look at the spec makes me think there is some validity to the
statement.

Is it true?

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

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

[Angel Robert Marquez]

This brings to memory an incident. When I worked at ATAR* as a tester the system in place was before you input a bug into the database it needed to be redlined/proofed by a designated redliner. The standards and format for writing the bugs were readily available and the database was open for research for duplicates, format reference etc...I found myself taking my bugs to all the redliners and than settling on one individual in particular. After I had a firm grasp on all the bug severities etc.. I decided to, as a tester, go back out into the wild and test my skills with the other redliners I didn't go back to after their acceptance test I had given them. This is the point to my story...A day arrives where the redliner who I trusted comes up to me and says let me see the last 4 bugs you wrote to be redlined before you input them into the system. Looking into the garbage their they were. I show him and he says come with me. He pulls up a spreadsheet that has been secretly tracking all the testers and each redliner has been grading their perfomance. 

Let me tell you. The negative marks were falsified. The redliner who showed me the window into the real world  confirmed it and referenced the standards we were ordered to abide by. BUT as I gazed at the names and grouped cronies and nepotist along with the freaks, the positive comments were as much bullshit as the negative ones. 

If the astream prevents monopolized marketing blitz's. which it probably won't, by removing a way of thinking great. I like the thought of 1 browser and sabotage prevention from the keep away mentality. Not sure if using the same keep away tactic is the fix though. BUT very interesting. One can't help but ponder...  

[Adina Levin]

With regard to Enterprise 2.0 use cases, I think the opportunity is to
write up the use cases and propose sample vocabulary for discussion. I
don't think the ActivityStrea.ms group is ignoring anything, instead
the group is responding to the use cases before it, which have mostly
come from personal-use applications in the past.

[Angel Robert Marquez]

Well, it seems obvious to not bake your beliefs into the scheme. It's a simple preference, yes or no. Do you eat meat yes or no, do you believe in go god, yes or no. your reasoning on why is a front end marketing problem. the point is the people providing the interface should be able to access unbiased data. 

I understand the use cases being addressed; but, it seems like it's 1, 2, ,3 done. Seems to scripted to be addressing all the options equally. 

I would just like to look at pure data before I hear if anyone liked it or how they 'felt'. Feelings can be interpreted/mis interpreted to easily. 

Like I said I'm on the sidelines. I'm not going to the challenge the spec to no avail.   

[Angel Robert Marquez]

Also, I think it's pretty obvious if a person wins a debate it doesn't necessarily make them right. BUT it does reveal a ratio to gauge what's right from wrong. 

It would be nice to take a bucket to the ocean of data and not have to filter out the...you know. Please tell me I'm not the only one that notices these simple little things.

I just think 'like' allows the 'I like war because it makes me money' idea.    

[Tom Brown]

roger ebert and gene siskel used the thumbs down for rating movies and it seemed people found some value in that.  years ago, ebert said that the worst thing that ever happened to the movie industry was the weekly top 10 in sales.  the movie industry could promote pure garbage and, of course, the garbage would show up in the top 10 list.  they realized they could continue to produce garbage because people would be tricked by the survivorship bias present in the list.  other better films would lose out.  the thumbs down from siskel and ebert was a check against this.  survivorship bias is generally a huge blindspot of popular social web software today.

cheers,

tom 

[mary hodder]

As Tom notes, you can get a power law around top 10 (or whatever) lists.. regardless of the metric. It can happen around thumbs up or down as well..

the fact that people see the "liked" items in some presentation makes them aware of it.. so they may want to like it because their friends did on FB (or their wanna be friends who have already liked it and means they'll be seen as "associated" with when people look at who liked it).

Like / not like should be decoupled from presentation and associations and lists and the resulting power law type concerns.

The first issue.. how to rate things, is messy.

As Adina mentioned earlier and in her post here:

http://www.alevin.com/?p=2050

likes are undefined and hard to figure out. That's true of stars as well.. unless you define and structure them. Stars are far messier than binary likes/unlike

A like could be because you liked your waitress but the food sucked. Or it could be because the movie touched you .. but it was really terrible. It was so bad, you "liked" (loved) it so you said you liked it on facebook.  Etc.  

The second issue, how to present the results for popularity or interestingness or whatever, would likely be improved by using more than one gesture (the like) where a system  would filter it against other gestures (recency, frequency, other things like whether the liker was a friend or someone with whom you had similar tastes, etc).

I don't know that a format can really control for the powerlaw question.. I would suggest that you make like/unlike.. and let people who make systems stumble into a solution (or not) that routes around power laws.  It took Digg a long time (we all knew it was a power law system that was also very gamable from day 1) to have the mass audience realize it was flawed.. but Activity Streams cannot solve for that kind of short sightedness.  

You can only solve for the simpler gesture of whether someone likes something.. no matter why or what silly reason they have for "liking" something.

mary

[Eric]

Hi, very interesting discussion.

Regarding negative actions such as "unfriend, unfollow, unlike", these
mechanisms are already in place via REST. In order to "friend,
follow, and like", a REST POST is made. Likewise, a REST DELETE
should be used to "unfriend, unfollow, and unlike." In other words,
negative verbs within ActivityStreams should not be used to replace
the REST mechanisms that are already in place.

Note that this does not relate to an action such as "dislike," which
is the same as "like" except it is expressing discontent. Unlike
"unfriend, unfollow, and unlike," which are undoing previously
performed actions, "dislike" would be expressed via a POST. A DELETE
would be used to "un-dislike".

Thoughts?
- Eric W.

On Jun 15, 3:21 pm, James Walker <wal...@walkah.net> wrote:
> What Peter said.
>

[Peter Ferne]

On 28 Jun 2010, at 16:30, Eric wrote:

> Regarding negative actions such as "unfriend, unfollow, unlike", these
> mechanisms are already in place via REST. In order to "friend,
> follow, and like", a REST POST is made. Likewise, a REST DELETE
> should be used to "unfriend, unfollow, and unlike." In other words,
> negative verbs within ActivityStreams should not be used to replace
> the REST mechanisms that are already in place.
>
> Note that this does not relate to an action such as "dislike," which
> is the same as "like" except it is expressing discontent. Unlike
> "unfriend, unfollow, and unlike," which are undoing previously
> performed actions, "dislike" would be expressed via a POST. A DELETE
> would be used to "un-dislike".
>
> Thoughts?

Makes a great deal of sense to me, except that it rather confuses the notion of a 'verb'. You are basically treating the verbs as nouns above, aren't you?
--
petef

[Jon Lebkowsky]

I think that's fair. "To like," "to unlike," or "to dislike" - all verbs. However the description of an action to express "like" or "unlike" could be expressed as a noun, as "a like" or "a dislike."  I think both usages are fairly common in our discussions.

~ Jon 

--
Jon Lebkowsky
+1 512.762-6547
website: http://weblogsky.com

twitter: http://twitter.com/jonl
facebook: http://facebook.com/jonlebkowsky
linkedin: http://linkedin.com/jonlebkowsky

[Martin Atkins]

I think what you're describing here is the activity itself. The thing
that you might delete to revoke a like is the activity describing the
fact that you liked it in the first place.

I think deleting the activity where you said you liked something and
publishing an activity that says that you "un-liked" something are two
different things, though; in the former case, you're revoking that
activity and I think the expectation would be that it would be as if
you'd never "liked" it in the first place. In the latter case, you're
explicitly publishing that you liked something and then later "un-liked" it.

[Peter Ferne]

On 28 Jun 2010, at 18:27, Martin Atkins wrote:

> I think deleting the activity where you said you liked something and publishing an activity that says that you "un-liked" something are two different things, though; in the former case, you're revoking that activity and I think the expectation would be that it would be as if you'd never "liked" it in the first place. In the latter case, you're explicitly publishing that you liked something and then later "un-liked" it.

Aha. A subtle and possibly important distinction. I imagine (although some evidence would be useful) that the former case would cover most popular scenarios.
--
petef

[Chris Messina]

Martin has it right. To expand somewhat:

* every user on a social site has a series of collections that store the artifacts of their activities. These include photos, videos, friends, and other gestures such as "Likes". 

* REST applies perfectly well to these collections — so you can GET, PUT, POST, DELETE, and UPDATE the entities in these collections.

* however, the ActivityStreams format is designed as a kind of "receipt" for the interactions that people have with the entities in these collections, and therefore represents data along a timeline, rather than against a mutable store of discrete objects (for example, I could conceivably "like" the same object dozens of times a day, but there would still only be one representation of that object in my personal "Likes" store). 

Therefore, you could conceivably delete the activity wherein you liked some object, but that wouldn't necessarily remove the liked item from your collection of likes. 

It would be more like destroying the receipt for the TV you just bought: destroying the receipt doesn't cause the TV to be destroyed, it only destroys the timebound record of your purchase (i.e. when you POST the TV in your store of purchased objects).

This is why ActivityStreams isn't positioned as a sync format — it's really a meta format for what's happening to objects on the web.

Chris

--
Chris Messina
Open Web Advocate, Google

Personal: http://factoryjoe.com
Follow me on Buzz: http://buzz.google.com/chrismessina
...or Twitter: http://twitter.com/chrismessina

This email is:   [ ] shareable    [X] ask first   [ ] private

[John Panzer]

You're absolutely right about a pure REST interface not needing this.

However, there are at least two cases where these would be useful, probably many others:

1. In a feed of activities (syndication, search, timeline, etc.) which for example show history.  You need to find some way to represent the "un-X" within the schema of the data, even if you also update things via DELETE.

2. In my own project, Salmon, the content is covered by a public key signature.  But the HTTP method line is not (there are many good reasons for this; the margin of this email is too small to detail them).  Given this, the data also needs to specify unambiguously that the action is an "un-X", in order for the signature to be at all useful.

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

[Martin Atkins]

On 06/28/2010 12:59 PM, John Panzer wrote:
> You're absolutely right about a pure REST interface not needing this.
>
> However, there are at least two cases where these would be useful,
> probably many others:
>
> 1. In a feed of activities (syndication, search, timeline, etc.) which
> for example show history. You need to find some way to represent the
> "un-X" within the schema of the data, even if you also update things via
> DELETE.
> 2. In my own project, Salmon, the content is covered by a public key
> signature. But the HTTP method line is not (there are many good reasons
> for this; the margin of this email is too small to detail them). Given
> this, the data also needs to specify unambiguously that the action is an
> "un-X", in order for the signature to be at all useful.
>

John.

It seems like the feed-ish equivalent of the DELETE verb is a tombstone.
If you apply the magic signatures thing to an deleted-entry element as
sepecified in Atom tombstones do you thing that would afford this use-case?

(To be clear, I mean that you would tombstone the Atom entry that
contains the activity you want to "revoke", in which case I would expect
a tombstones-aware consumer to delete whatever artifacts it created from
the entry in question.)

[John Panzer]

Yes, absolutely. Actually Atom Tombstones are referenced in the
Salmon spec as the standard solution for this, so if that works &
there's a similar solution for JSON you're done.

If the JSON format mandated support for an is_deleted flag from the
start, it could probably avoid needing to mint a new entity type :).

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