Quick Opinion Poll: Flag as Inappropriate

[James M Snell]

Joe wants to flag an article as being inappropriate...

Three choices...

1. Use a verb with a generic object type..

{
"actor":{"displayName":"Joe"},
"verb":"report",
"object":{"objectType":"article",...}
}

2. Use a generic object with a specific object... e.g.,

{
"actor":{"displayName":"Joe"},
"verb":"post",
"object":{
"objectType":"report",
"inReplyTo":[{"objectType":"article",...}], ...}
}

3. Allow for both...

My vote is on #3... Allowing for both. I see valid use cases for either option.

That is, the following are two distinctly useful statements:

1. Joe flagged the article as inappropriate.
2. Joe posted an abuse report.

Allowing for both gives implementors the most flexibility to figure
out the best approach for their own scenarios.

- James

[Martin Atkins]

Abuse reports are often parameterized by extra details like the category
of abuse, so I'd probably end towards the second to encourage that
metadata to live inside the object rather than up at the activity level.

I'm not sure that there's really any practical difference between your
two example sentences above, so I'd prefer to keep it simple and just
use option 2.

[Jack Repenning]

On May 21, 2012, at 3:49 PM, Martin Atkins wrote:

>> 1. Joe flagged the article as inappropriate.
>> 2. Joe posted an abuse report.
>

> I'm not sure that there's really any practical difference between your two example sentences above, so I'd prefer to keep it simple and just use option 2.

The difference that jumped out at me was that, in the first case, Joe's flagging takes effect immediately (the article is removed) ... Joe#1 is, perhaps, an administrator. But in the second case, the "abuse report" feeds into some sort of arbitration system ... maybe human, maybe automated ... "takes at least three votes" or something like that. Joe#2 might be an ordinary user; Joe#1 might be in charge of reviewing such reports and taking action.

That said, though, I can't help thinking that "design is about making choices, not dumping them on the user." For my "two Joes" scenario, a single API, probably #1, plus a authn-backed action policy seems simpler to me.


Jack Repenning

But the men of the clique live together because they have the same kind of soul, and their narrowness is a narrowness of spiritual coherence and contentment, like that which exists in hell. A big society exists in order to form cliques. A big society is a society for the promotion of narrowness. It is a machinery for the purpose of guarding the solitary and sensitive individual from all experience of the bitter and bracing human compromises. It is, in the most literal sense of the words, a society for the prevention of Christian knowledge.
-- G. K. Chesterton, "Heretics"

[James M Snell]

Ok, thinking about it further, the verb and the object really are two
completely separate things. Consider the following flow:

1. Mary, John and Sally all read an offensive article and separately
report it to the moderator

{
"actor":{"displayName":"Mary"},

"verb": "post",
"object": {
"objectType":"report",

"replyTo": [{"objectType":"article","id":"http://.../123"}],
"reasons": [
"http://example.org/policy/inappropriateLanguage"
]
}
}

2. The moderator reviews the separate reports and determines that the
article does, in fact violate acceptable use policies, he also notices
that the article contains a copyright violation.

{
"actor":{"displayName":"Joe"},
"verb": "flag-as-inappropriate",
"object": {"objectType":"article","id":"http://.../123"},
"context": {
"objectType": "http://example.org/objects/policy",
"reasons": [
"http://example.org/policy/inappropriateLanguage",
"http://example.org/policy/copyrightViolation"
]
}
}

Note that these really are two distinct types of activities with two
entirely different (albeit related) contexts.

- James

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

[Laurent-Walter Goix]

Hello all,

we had such discussion within the OMA with other companies when trying
to address this issue through different proposals [1]. At the end we
chose to define a new object type "abuse" instead of a new verb. at
the end the group in OMA found the object type to be more flexible in
allowing a variety of actions (and reactions, including it in
inReplyTo for example) related to this concept, so it was introduced
in the spec. of course at this stage this was defined using OMA-
specific extension and should this be generalized by AS that'd be even
better to ensure a wider adoption and improve compatibility.

we're actually using the "target" property to identify the activity
(typically) to which this "abuse" report relates, and typically the
"post" verb for it: this to limit the number of additional verbs &
object types to be introduced in general for this feature kiss. in
general i have seen a number of threads over the last days (nights) on
this topic and am a bit confused about them. re-"about" i have the
feeling that the given example make it ambiguous, and actually either
mapped to "inReplyTo", or in other cases to the equivalent of "tags",
so i couldn't see a real need for this in the "base" schema. my
personal feeling is that the current version of the schema is already
very detailed in some areas (many verbs or detailed object types) and
may not include all possible cases, but rather a limited subset. then,
some area-specific (or use case-specific) extensions could be defined
using prefixes/namespaces easily (see e-learning etc)

back to the example below i can understand the "moderator" use case as
being differnt from the first-party action (abuse reporting) of users,
and maybe this could deserve more thinking, although it may not be
part of the "base" schema.

i am also quite confused by the "context" property but need to check
the tincan documentation first i guess.

walter

[1] http://member.openmobilealliance.org/ftp/Public_documents/CD/MobSocNet/2012/OMA-CD-MobSocNet-2012-0005-INP_Abuse_Reporting.zip

[James M Snell]

Walter,

On Wed, May 23, 2012 at 2:27 AM, Laurent-Walter Goix
<laurentwa...@gmail.com> wrote:
> Hello all,
>
> we had such discussion within the OMA with other companies when trying
> to address this issue through different proposals [1]. At the end we
> chose to define a new object type "abuse" instead of a new verb. at
> the end the group in OMA found the object type to be more flexible in
> allowing a variety of actions (and reactions, including it in
> inReplyTo for example) related to this concept, so it was introduced
> in the spec. of course at this stage this was defined using OMA-
> specific extension and should this be generalized by AS that'd be even
> better to ensure a wider adoption and improve compatibility.
>

Thank you for the detailed response. For the more general case of
indicating that a user has reported an object as being inappropriate,
I definitely agree with this approach. For the sake of keeping things
are generalized as possible, I am thinking about using a generic
"issue" objectType that can actually apply to more than just abuse
reporting. In addition to the normal properties for all objects, an
"issue" would have an additional property "types" whose value is an
array of absolute IRI's that specify the nature of the specific issue.
For example:

"object": {
"objectType": "issue",
"inReplyTo": [{"objectType":"article", "id":"http://.../123", ...},
"types": [
"http://example.org/codes/inappropriateMaterial",
"http://example.org/codes/copyrightViolation"
]
}

The structure meets the basic need and is generic enough that it can
be used and extended within completely different scenarios. Reading
through the material you referenced, it would appear to be that this
structure would meet the general requirements. Do you agree?

> we're actually using the "target" property to identify the activity
> (typically) to which this "abuse" report relates, and typically the
> "post" verb for it: this to limit the number of additional verbs &
> object types to be introduced in general for this feature kiss. in

I hadn't considered using the target in this way but it certainly
makes sense. I believe using the inReplyTo, however, would make the
issue report more self-contained and portable across multiple
scenarios. I imagine, for instance, that there will be scenarios in
which "issue" could be used with other verbs where "target" could mean
something else entirely... for instance:

{
"actor": {"displayName":"Manager", ...},
"verb": "assign",
"object": {"objectType":"issue", ... },
"target": {"displayName":"Employee", ...}

}


> general i have seen a number of threads over the last days (nights) on
> this topic and am a bit confused about them. re-"about" i have the
> feeling that the given example make it ambiguous, and actually either
> mapped to "inReplyTo", or in other cases to the equivalent of "tags",
> so i couldn't see a real need for this in the "base" schema. my
> personal feeling is that the current version of the schema is already
> very detailed in some areas (many verbs or detailed object types) and
> may not include all possible cases, but rather a limited subset. then,
> some area-specific (or use case-specific) extensions could be defined
> using prefixes/namespaces easily (see e-learning etc)

I've been running through a bunch of scenarios over the past few days
and in every case, the "inReplyTo" and "tags" properties can be used
to cover all of the cases where the proposed "about" property would be
used so, at least for now, I've decided to pull that back.

>
> back to the example below i can understand the "moderator" use case as
> being differnt from the first-party action (abuse reporting) of users,
> and maybe this could deserve more thinking, although it may not be
> part of the "base" schema.
>

After running through a variety of scenarios, I do believe they are
distinct and do deserve to be consider part of the core. Moderated
forums are widespread and admin/moderated directed actions such as
removing a particular thread of discussion or taking down a post that
violates copyright, etc really is a different kind of activity than an
ordinary user reporting potential abuse.

> i am also quite confused by the "context" property but need to check
> the tincan documentation first i guess.
>

From my perspective, the (perhaps misnamed) "context" property is all
about making it possible to explain *why* a particular activity
occurred. For example, if we consider "flag-as-inappropriate"...

{
"actor": {
"objectType": "person",

"displayName": "Joe"
},
"verb": "flag-as-inappropriate",
"object": {
"objectType": "article",

"displayName": "An article about stuff"
},
"context": {
"objectType": "issue",
"displayName": "Terms of Use Violation",
"url": "http://.../terms-of-use",
"types": [
"http://example.org/codes/inappropriateMaterial",
"http://example.org/codes/copyrightViolation"
]
}
}

What this Activity is saying is "Joe flagged the Article as
inappropriate *because of inappropriate content and a copyright
violation*"

- James

[Laurent-Walter Goix]

Hello james,

>
> Thank you for the detailed response. For the more general case of
> indicating that a user has reported an object as being inappropriate,
> I definitely agree with this approach. For the sake of keeping things
> are generalized as possible, I am thinking about using a generic
> "issue" objectType that can actually apply to more than just abuse
> reporting. In addition to the normal properties for all objects, an
> "issue" would have an additional property "types" whose value is an
> array of absolute IRI's that specify the nature of the specific issue.
> For example:
>
>     "object": {
>       "objectType": "issue",
>       "inReplyTo": [{"objectType":"article", "id":"http://.../123", ...},
>       "types": [
>         "http://example.org/codes/inappropriateMaterial",
>         "http://example.org/codes/copyrightViolation"
>       ]
>     }
>
> The structure meets the basic need and is generic enough that it can
> be used and extended within completely different scenarios. Reading
> through the material you referenced, it would appear to be that this
> structure would meet the general requirements. Do you agree?

The idea of types is interesting as it allows extensibility. do you
expect a minimum list of such types to be standardized to maximize
interop, eg at least for the "abuse reporting" use case based on the
most popular types of abuses/violations? this is something we wanted
to investigate in OMA but didn't have time so far. actually the
objective was to "mandate" somehow a "reason" for this abuse, that
could be a code/type and maybe a free text (some systems do support
this). code/types guarantee interop and programmable understanding on
the other hand and a short -default- list could be drawn possibly.

On the "issue" object type i can understand this to be very generic,
and maybe confusing by mixing a true abuse/violation/inappropriate
concept with bug tracking systems type of issues/tickets. issue is
indeed very generic and could lead to misunderstanding by developers
in choosing the best appropriate object type. what about using
"ticket" for these (and the assignment example you proposed below) and
keep "abuse" for the specific case.

>
> > we're actually using the "target" property to identify the activity
> > (typically) to which this "abuse" report relates, and typically the
> > "post" verb for it: this to limit the number of additional verbs &
> > object types to be introduced in general for this feature kiss. in
>
> I hadn't considered using the target in this way but it certainly
> makes sense. I believe using the inReplyTo, however, would make the
> issue report more self-contained and portable across multiple
> scenarios. I imagine, for instance, that there will be scenarios in
> which "issue" could be used with other verbs where "target" could mean
> something else entirely... for instance:
>
>   {
>     "actor": {"displayName":"Manager", ...},
>     "verb": "assign",
>     "object": {"objectType":"issue", ... },
>     "target": {"displayName":"Employee", ...}
>   }
>

mmm...inReplyTo instead of the target could fit for activities, but
our requirements are also to report abuse/inappropriate other types of
objects, say images, persons, applications, etc. so we found the
target more generic and appropriate for that need. what is your
feeling?

walter

[James M Snell]

On Thu, May 24, 2012 at 1:40 AM, Laurent-Walter Goix
<laurentwa...@gmail.com> wrote:
> Hello james,
[snip]

>
>
> The idea of types is interesting as it allows extensibility. do you
> expect a minimum list of such types to be standardized to maximize
> interop, eg at least for the "abuse reporting" use case based on the
> most popular types of abuses/violations? this is something we wanted
> to investigate in OMA but didn't have time so far. actually the
> objective was to "mandate" somehow a "reason" for this abuse, that
> could be a code/type and maybe a free text (some systems do support
> this). code/types guarantee interop and programmable understanding on
> the other hand and a short -default- list could be drawn possibly.
>

+1 .. I'm not sure what the best place to define that common set of
values would be, but it is definitely something that could and should
be done.

> On the "issue" object type i can understand this to be very generic,
> and maybe confusing by mixing a true abuse/violation/inappropriate
> concept with bug tracking systems type of issues/tickets. issue is
> indeed very generic and could lead to misunderstanding by developers
> in choosing the best appropriate object type. what about using
> "ticket" for these (and the assignment example you proposed below) and
> keep "abuse" for the specific case.
>

In general, I think the context in which the issue object is being
used, as well as the values provided for the "types" property is going
to provide sufficient differentiation to avoid the kind of ambiguity
you suggest. Semantically speaking, they really are both "issues" in a
general sense and differ only in the details of the problem.
Personally, I'm not too concerned about potentially
misinterpretations.

>>
>> > we're actually using the "target" property to identify the activity
>> > (typically) to which this "abuse" report relates, and typically the
>> > "post" verb for it: this to limit the number of additional verbs &
>> > object types to be introduced in general for this feature kiss. in
>>
>> I hadn't considered using the target in this way but it certainly
>> makes sense. I believe using the inReplyTo, however, would make the
>> issue report more self-contained and portable across multiple
>> scenarios. I imagine, for instance, that there will be scenarios in
>> which "issue" could be used with other verbs where "target" could mean
>> something else entirely... for instance:
>>
>>   {
>>     "actor": {"displayName":"Manager", ...},
>>     "verb": "assign",
>>     "object": {"objectType":"issue", ... },
>>     "target": {"displayName":"Employee", ...}
>>   }
>>
>
> mmm...inReplyTo instead of the target could fit for activities, but
> our requirements are also to report abuse/inappropriate other types of
> objects, say images, persons, applications, etc. so we found the
> target more generic and appropriate for that need. what is your
> feeling?
>

The value(s) provided for inReplyTo can be any object of any type. It
is not limited to just activities.

That is, it could just as easily be:

"inReplyTo": [{"objectType":"person","displayName":"James"}]

- James

> walter