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

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

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.

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

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.