Several thoughts...

[James M Snell]

1. In a discussion with Monica W. and Will N. today we went through
some recent explorations the Schema.org folks have had around
Activities. One of the ideas that came up is the notion of an activity
result... A similar notion appears in the Tin Can / Scorm stuff [1]...
it's a concept that currently does not exist in the AS model but does
prove to be semantically useful.

[1] http://scorm.com/wp-content/assets/tincandocs/TinCanAPI.pdf

For instance, imagine the following:

{
"actor": {"displayName": "Joe"},
"verb": "flagged-as-inappropriate",
"object": {"objectType": "article", ... },
"target": {"objectType": "service", "displayName": "Admin Service"},
"result": {
"objectType": "abuse",
"displayName": "abuse report",
"reasons": ["http://example.org/InappropriateContent"] }
}

This tells us several things...
1. Joe reported an article as being in appropriate.
2. That report was sent to the "Admin Service"
3. The activity resulted in the creation on a new "abuse" object that
describes the report

I think the result is something that is fundamental to many activities
and providing a common extension property for result, I think, will
make it easier to more naturally express the correct semantics for
many types of activities.

Another example taken directly from the conversation with Monica and
Will earler today:

{
"actor": {"displayName": "Joe"},
"verb": "reviewed",
"object": {"objectType": "product", ... },
"target": {"objectType": "service", "displayName": "Review Service"},
"result": {
"objectType": "review",
"displayName": "Review",
"rating": 3.5
}


2. Another much more abstract notion that I've seen in a number of
areas (including scorm, tin can, and opensocial) is the notion that an
activity can occur within a given context, and that when communicating
about the activity, understanding the context within which the
activity occurred is important. For instance, if the activity occurred
within the context of a project or class. The Tin can documentation
introduces a "context" property to the Activity whose value is an
object that describes the context. What I'm wondering is if there
would be value in generalizing the concept as a common "context"
extension property. For instance,

{
"actor": {"displayName": "Joe"},
"verb": "completed",
"object": {"objectType": "http://.../Assignment", ... },
"context": {
"objectType": "http://.../Class",
"displayName": "My Training Course",
"id": "http://.../classes/123"
}

For certain verbs, there may be some fuzzy overlap between the
"context" and "target" but that should be ok.

3. One of the other things that popped up in the conversation today
was the notion that, currently, we do not have a common mechanism for
referencing what a particular object is about. That is, for instance,
say we have a "review" object... how do we indicate what is being
reviewed? Say we have an "abuse" object that describes a report that
some content is inappropriate... how do we identify the object that
was reported? It's simple to come up with type specific properties
that handle the job, but it would be better to come up with a generic
property that would work independently of object type.

Recently, I came up with the Links for Activity Streams mechanism and
suggested a new "about" link relation in a separate document.. in
theory, these can be combined and used for this purpose.. e.g.

{
"objectType": "review",
"rating": 3.5,
"$about": "http://.../uri/of/thing/being/reviewed"
}

But that is fairly limiting in terms of being able to provide
additional metadata... in the discussion today we discussed the idea
of having a new generic "about" extension property whose value is an
array of objects... just like we have with the "tags" and
"attachments" properties. The meaning would be, "here's a list of
things this object is about" ... for instance:

{
"objectType": "review",
"rating": 3.5,
"about": [{
"objectType": "product",
"id": "http://.../uri/of/thing/being/reviewed"}]
}


The combination of these three new extension fields, I think, would
sufficiently round out our model for a broad range of use cases. They
would be defined as additional extension fields within the Schema
document (Section 5) and would be entirely optional.

Thoughts?

- James

[Martin Atkins]

On 05/16/2012 05:14 PM, James M Snell wrote:
> 1. In a discussion with Monica W. and Will N. today we went through
> some recent explorations the Schema.org folks have had around
> Activities. One of the ideas that came up is the notion of an activity
> result... A similar notion appears in the Tin Can / Scorm stuff [1]...
> it's a concept that currently does not exist in the AS model but does
> prove to be semantically useful.
>
> [1] http://scorm.com/wp-content/assets/tincandocs/TinCanAPI.pdf
>
> For instance, imagine the following:
>
> {
> "actor": {"displayName": "Joe"},
> "verb": "flagged-as-inappropriate",
> "object": {"objectType": "article", ... },
> "target": {"objectType": "service", "displayName": "Admin Service"},
> "result": {
> "objectType": "abuse",
> "displayName": "abuse report",
> "reasons": ["http://example.org/InappropriateContent"] }
> }
>
> This tells us several things...
> 1. Joe reported an article as being in appropriate.
> 2. That report was sent to the "Admin Service"
> 3. The activity resulted in the creation on a new "abuse" object that
> describes the report

I think for this sort of thing in the past we've thought about it as the
article being a property of the abuse report, so:

{
"actor": {"displayName": "Joe"},
"verb": "flagged-as-inappropriate",
"object": {

"objectType": "abuse-report",
"inReplyTo": {
"objectType": "article",
....
},

},
"target": {"objectType": "service", "displayName": "Admin Service"},
}

This has the advantage that if a system takes the abuse report object
out of the context of this activity it still contains the thing it was
about. As you wrote it, the abuse report object makes no sense unless it
stays in the context of the activity.

I used inReplyTo here because it seems to be a reasonable fit if you
think of the abuse report as being a kind of response to the article,
but I don't feel too strongly about that; a new property would be fine too.

> Another example taken directly from the conversation with Monica and
> Will earler today:
>
> {
> "actor": {"displayName": "Joe"},
> "verb": "reviewed",
> "object": {"objectType": "product", ... },
> "target": {"objectType": "service", "displayName": "Review Service"},
> "result": {
> "objectType": "review",
> "displayName": "Review",
> "rating": 3.5
> }
>

I'd make the same argument here: the review object in your "result" is
only useful in the context of this activity, but if you rewrote it as
being a response to the product then it would stand alone as a useful
object in its own right.

I'm sure not all examples lend themselves well to inReplyTo, but these
two seem like a fine fit. Other object-level properties can be
introduced if inReplyTo is not a good fit in some case.

>
> 2. Another much more abstract notion that I've seen in a number of
> areas (including scorm, tin can, and opensocial) is the notion that an
> activity can occur within a given context, and that when communicating
> about the activity, understanding the context within which the
> activity occurred is important. For instance, if the activity occurred
> within the context of a project or class. The Tin can documentation
> introduces a "context" property to the Activity whose value is an
> object that describes the context. What I'm wondering is if there
> would be value in generalizing the concept as a common "context"
> extension property. For instance,
>
> {
> "actor": {"displayName": "Joe"},
> "verb": "completed",
> "object": {"objectType": "http://.../Assignment", ... },
> "context": {
> "objectType": "http://.../Class",
> "displayName": "My Training Course",
> "id": "http://.../classes/123"
> }
>
> For certain verbs, there may be some fuzzy overlap between the
> "context" and "target" but that should be ok.

This was actually an area we thought about back in the Atom Activity
Streams days, and concluded that the general "context" concept is really
just activity extension properties.

In your particular example here again I feel like I want to make the
class a property of the assignment for the same reasons as above.

But the more general examples we had in the early AtomActivity specs
were location were the activity occured and the mood the actor was in
when the activity occured, and I think these are pretty natural as
activity-level extension properties.

{
"actor": {...},
"verb": "post",
"object": {"title":"I HATE EVERYTHING!!!", ...},
"mood": {
"caption": "ANGRY!!!!",
"id": "some-uri-scheme:angry",
}
}

(precise serialization of mood here isn't the point, of course, just
that it's an activity extension property that is orthogonal to the verb.
Just as with object types, some extensions may be useful only for
certain verbs.)

I actually replied to this email point-by-point and I'm amused that in
my first attempt at rewriting your abuse report activity I unknowingly
revivented a property called "about", before I realized that I was
really just duplicating the meaning of "inReplyTo".

I like this serialization a lot more than having the "result" property
at the activity level, for the reasons I stated above. If people think
"about" is a better way to write it than "inReplyTo" for these cases
then I'm not going to fight that too hard, but I do think it would be
useful to have a standard property name to look for so that consumers
can have a reasonable default handling of that property that is agnostic
of whatever object type is in use.

[James M Snell]

The challenge with this example are the semantics of the
"flagged-as-inappropriate" verb with the "abuse-report" object type...
reading it as a sentence, this would end up as "Joe flagged the
abuse-report as unacceptable"

The proper verb to use here, then, would be "post", "create" or
"submit"... e.g.

   {
     "actor": {"displayName": "Joe"},
     "verb": "submit",

     "object": {
         "objectType": "abuse-report",
         "inReplyTo": {
             "objectType": "article",
             ....
         },

     },
     "target": {"objectType": "service", "displayName": "Admin Service"},
   }

Which gives us, "Joe submitted an abuse-report" ... which we can then
extend to say "in response to an article"

The question, then, becomes a choice between using (a) specific object
types with generic verbs, or (b) generic object types with specific
verbs. Which is ideal? I believe historically, this group has favored
the (a) over the (b). Fortunately, our model supports both, and
equally fortunate is the fact that our model supports both approaches.

Your point about "inReplyTo" is definitely valid. I'm wondering,
however, if there's any harm in allowing for both approaches?

I definitely can buy in to this approach in theory, but if you look at
the "context" property defined in tin can [2] as an example, you'll
see the object is essentially a wrapper for a grouping of
domain-specific extension properties as opposed to a distinctly
separate entity. In that sense, it is not unlike the existing
"location" and "mood" properties we already have... whose values are
objects with their own properties. The "context" value would just
provide a convenient container for grouping up the domain specific
contextual properties for the activity, just as "location" provides a
convenient container for grouping up the geotagging details.

(I certainly hope that makes sense)

[2] http://scorm.com/wp-content/assets/tincandocs/TinCanAPI.pdf

I had considered "inReplyTo" but decided not to bring it up so I could
see if anyone made the connection to. This begs the question tho:

Is saying, "This article is about Foo" always the same as saying "This
article is in response to Foo"

Keeping in mind that we also have the existing "tags" property in the
mix, perhaps I wanted to say that...

(A) "This article about Foo is in response to Foo2" ...

{
"objectType":"article",
"about":[{"id":"Foo"}],
"inReplyTo":[{"id":"Foo2"}]
}

or perhaps

(B) all we need to say is "This article is in response to Foo2, and tags Foo"

{
"objectType":"article",
"tags":[{"id":"Foo"}],
"inReplyTo":[{"id":"Foo2"}]
}

Up to this point, I've been using (B) because it works well enough.

- James

> I like this serialization a lot more than having the "result" property at
> the activity level, for the reasons I stated above. If people think "about"
> is a better way to write it than "inReplyTo" for these cases then I'm not
> going to fight that too hard, but I do think it would be useful to have a
> standard property name to look for so that consumers can have a reasonable
> default handling of that property that is agnostic of whatever object type
> is in use.
>

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

[Craig McClanahan]

On Wed, May 16, 2012 at 5:14 PM, James M Snell <jas...@gmail.com> wrote:

For instance, imagine the following:

 {
   "actor": {"displayName": "Joe"},
   "verb": "flagged-as-inappropriate",
   "object": {"objectType": "article", ... },
   "target": {"objectType": "service", "displayName": "Admin Service"},
   "result": {
     "objectType": "abuse",
     "displayName": "abuse report",
     "reasons": ["http://example.org/InappropriateContent"] }
 }

One of the things that always makes me do a double-take when looking at activity streams is the idea that a stream entry documenting something that has happened should really have a past tense verb.  I like to see that you used this tense in your example here and in several others.  Can we also, in the context of standardizing a reasonable verb list, consider it for everything?

Craig McClanahan

[Martin Atkins]

On 05/16/2012 06:14 PM, Craig McClanahan wrote:
>
> One of the things that always makes me do a double-take when looking at
> activity streams is the idea that a stream entry documenting something

> that *has* happened should really have a past tense verb. I like to see

> that you used this tense in your example here and in several others.
> Can we also, in the context of standardizing a reasonable verb list,
> consider it for everything?
>

Well, that's not always true. In the case where an activity is acting as
a notification of an action that's true, but we've also seen uses where
the publishing of the activity is the action itself. OStatus, for example.

With that said I don't really care which we use I'd prefer to see us be
consistent. Unless we're going to go back and change all of the older
ones to be past tense I think it's best to continue forward with present
tense.

[James M Snell]

Historically, the verbs we've defined as a group have always used the
present tense (as my kids always say, it was like that when I got
here, I swear!), which is why I've kept that pattern with the new
verbs I've suggested. Using the past-tense form, however, does make a
heck of a lot more sense semantically and I would not be opposed to
it.

[Rob Dolin]

IIRC, verbs are intended to be enums rather than strings intended for UI display.

It is up to ASms clients/consumers to determine the appropriate language, tense, gender, etc. to render verbs in their UI. This allows a single enum in the data structure.

While we could potentially change the verb tense, I agree with Martin that we should not make a breaking change to existing implementations.

FWIW--
--Rob

[James M Snell]

I should clarify: I would not be opposed to using the past-tense for
*new* verbs. Existing verbs should remain as is so we don't break
anyone.

[Evan Prodromou]

-1 on using past tense of new verbs for the following reasons:

1. Switching tense between verbs is confusing and arbitrary (why 'post' but 'frobbed'?)

-1 on using past tense for any verbs for the following reasons:

1. In use cases where the activity is prescriptive (like ActivityPub API), past tense is inaccurate
2. We have other ways of marking an activity's time (published & updated)
   

I believe on the current schema "won" is in past tense.

-Evan

[James M Snell]

On Tue, May 22, 2012 at 9:58 AM, Evan Prodromou
<evan.pr...@gmail.com> wrote:
>[snip]

> I believe on the current schema "won" is in past tense.
>

Aha! Good catch. I'd completely missed that one.

- James

> -Evan

>
> --
> You received this message because you are subscribed to the Google Groups
> "Activity Streams" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/activity-streams/-/uZdeO3f6E_QJ.

[Jack Repenning]

On May 16, 2012, at 6:14 PM, Craig McClanahan wrote:

One of the things that always makes me do a double-take when looking at activity streams is the idea that a stream entry documenting something thathas happened should really have a past tense verb.  I like to see that you used this tense in your example here and in several others.  Can we also, in the context of standardizing a reasonable verb list, consider it for everything?

I've had that reaction from time to time myself. But in at least one of my designs (am i heretical?), I'm using AS as imperatives, not declaratives: Entity1 sends a message that includes an AS-format body, Entity2 receives the message and obligingly performs the requested action.

I've been thinking of the Ruby on Rails "inflectors" ... "subscribe".past_tense == "subscribed" ...

Jack Repenning

"People assume that time is a strict progression of cause to effect, but actually from a non-linear, non-subjective viewpoint, it's more like a big ball of wibbly-wobbly, timey-wimey... stuff."
The Tenth Doctor, Doctor Who, in the episode "Blink"