Various items.. just fyi really...

21 views
Skip to first unread message

James M Snell

unread,
Jun 7, 2012, 4:07:39 PM6/7/12
to activity...@googlegroups.com
Just wanted to give a heads up that I'm working through some basic
generic extensions to an activity and wanted to solicit some feedback.
These are not intended for the core schema at this time, but I at
least wanted to document the thoughts and see what people think...

1. Activity onset and completion date ... we currently have properties
for indicating when the activity statement was published and updated,
but nothing that defines when the activity began and completed. I'm
thinking simple "startTime" and "endTime" properties... e.g.

{
"actor": {...},
"verb": "...",
"object": {...},
"startTime": "2012-12-12T12:12:12Z",
"endTime": "2012-12-13T12:12:12Z"
}

2. Activity Priority ... this is a simple thing really, indicating the
relative priority of the activity statement. Is it something the
publishing things really needs to be paid attention to or not. What
I'm thinking is a simple non-negative decimal value between 0.0 and
1.0. Value 0.0 or null indicates a "default" priority.. no different
than not assigning any priority statement. All other values indicate
increasing priority as the value increases.

{
"actor": {...},
"verb": "...",
"object": {...},
"priority": 0.5
}

3. Actionable Items ... this one is a bit of a rabbit hole really, but
for now, the idea is to keep it simple. In our implementation, we have
the need to be able to indicate that an activity statement represents
an "actionable" item. That is, the consumer of the statement is
expected to DO something in response to the activity. What exactly
needs to be done in response is handled separately, generally through
the use of an OpenSocial Embedded Experience, but the idea is to at
least have a flag included in the activity statement that says "Yes,
this is an actionable item"..

{
"actor": {...},
"verb": "...",
"object": {...},
"actionable": true
}

If you look at the latest version of the Base Schema document, I have
included a new "task" object type.. which defines an "activity that
has yet to happen" that can also potentially be used for this but
there's lots of work to do to flesh this out. For now, the boolean
flag works as a stop gap.

Thoughts?

- James

Evan Prodromou

unread,
Jun 7, 2012, 4:36:14 PM6/7/12
to activity...@googlegroups.com
Replies in-line. By the way, these are pretty distinct; I'd recommend using different threads for each.


On Thursday, June 7, 2012 4:07:39 PM UTC-4, James M Snell wrote:
 
1. Activity onset and completion date ... we currently have properties
for indicating when the activity statement was published and updated,
but nothing that defines when the activity began and completed. I'm
thinking simple "startTime" and "endTime" properties... e.g.

  {
    "actor": {...},
    "verb": "...",
    "object": {...},
    "startTime": "2012-12-12T12:12:12Z",
    "endTime": "2012-12-13T12:12:12Z"
  }

This seems like a fine distinction; for most of the types of activities we support with AS, it's hard to see the difference.

I guess there are some implementations where there's an explicit publication process, but I think for a lot of us published === the time the activity happened (or finished).

2. Activity Priority ... this is a simple thing really, indicating the
relative priority of the activity statement. Is it something the
publishing things really needs to be paid attention to or not. What
I'm thinking is a simple non-negative decimal value between 0.0 and
1.0. Value 0.0 or null indicates a "default" priority.. no different
than not assigning any priority statement. All other values indicate
increasing priority as the value increases.

  {
    "actor": {...},
    "verb": "...",
    "object": {...},
    "priority": 0.5
  }

This is a tricky one; some systems like SMTP email use three priorities, "high", "medium" (or "normal"), and "low". See http://tools.ietf.org/html/rfc4021#section-2.1.52

Big problem with this kind of header is that they get ignored.
 
3. Actionable Items ... this one is a bit of a rabbit hole really

Yikes. This seems like a rabbit hole, indeed. Would a good example here be an event invitation? The expected response being an RSVP? Or a poll/question?

-Evan
 

James M Snell

unread,
Jun 7, 2012, 5:04:39 PM6/7/12
to activity...@googlegroups.com
On Thu, Jun 7, 2012 at 1:36 PM, Evan Prodromou <evan.pr...@gmail.com> wrote:
> Replies in-line. By the way, these are pretty distinct; I'd recommend using
> different threads for each.
>

If discussion for any particular item grows significantly I will split them up.

>
> On Thursday, June 7, 2012 4:07:39 PM UTC-4, James M Snell wrote:
>
>>
>> 1. Activity onset and completion date ... we currently have properties
>> for indicating when the activity statement was published and updated,
>> but nothing that defines when the activity began and completed. I'm
>> thinking simple "startTime" and "endTime" properties... e.g.
>>
>>   {
>>     "actor": {...},
>>     "verb": "...",
>>     "object": {...},
>>     "startTime": "2012-12-12T12:12:12Z",
>>     "endTime": "2012-12-13T12:12:12Z"
>>   }
>
>
> This seems like a fine distinction; for most of the types of activities we
> support with AS, it's hard to see the difference.
>
> I guess there are some implementations where there's an explicit publication
> process, but I think for a lot of us published === the time the activity
> happened (or finished).
>

This largely depends on the activity. For instance, saying that "James
is at the store", does not tell me how much time I spent at the store.
Or saying "Sally played the game" does not say how long she was
playing. The intent is to be able to model long running activities as
opposed to point-in-time activities. The case certainly is not
applicable to all cases.

>> 2. Activity Priority ... this is a simple thing really, indicating the
>> relative priority of the activity statement. Is it something the
>> publishing things really needs to be paid attention to or not. What
>> I'm thinking is a simple non-negative decimal value between 0.0 and
>> 1.0. Value 0.0 or null indicates a "default" priority.. no different
>> than not assigning any priority statement. All other values indicate
>> increasing priority as the value increases.
>>
>>   {
>>     "actor": {...},
>>     "verb": "...",
>>     "object": {...},
>>     "priority": 0.5
>>   }
>
>
> This is a tricky one; some systems like SMTP email use three priorities,
> "high", "medium" (or "normal"), and "low". See
> http://tools.ietf.org/html/rfc4021#section-2.1.52
>
> Big problem with this kind of header is that they get ignored.

Indeed. One alternative approach is to view this a "stickiness" or
"importance" rather than "priority"... in which case, it becomes a
kind of sort key for the collection. An item with "priority":1.0 would
stick to the top of the list more than an item with "priority":0.5,
and so forth.

The main reason for modeling this as a range of values is that it
allows implementors to establish meaningful brackets on their own,
without trying to artificially fit into some arbitrary definition of
"low", "medium" and "high".

>
>>
>> 3. Actionable Items ... this one is a bit of a rabbit hole really
>
>
> Yikes. This seems like a rabbit hole, indeed. Would a good example here be
> an event invitation? The expected response being an RSVP? Or a
> poll/question?
>

Yes. those are great examples. Others include activities that
represents steps in a workflow.. for instance "Joe posted an expense
report" where the next actions expected are for Joe's manager to
approve it or reject it. How the specific expected action is carried
out is not important here, at a minimum all we need to capture is that
an action is required.

This particular property is fairly specific to our use cases but,
because of the potential for things getting WAY too complex very
quickly, I wanted to surface the case for discussion.

> -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/-/LjQenWiO6OwJ.
> 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.
Reply all
Reply to author
Forward
0 new messages