Clarification on more complex use cases for Groups and Actors

[dcollien]

In the following use cases I cannot see how to interpret this spec, and wish to clarify my understanding:

1. An Agent performs an action on behalf of a Group (capturing the Group as the Actor, but the Agent as the member acting on behalf of the Group to create this statement) - this is to be distinctly reported from an Agent performing an action (on behalf of just their self) within a Group context (which I expect to see as a Group in the Context of the statement)
2. An Agent or Group performs an action within a Group context, which is a sub-group of a larger Group context (nested Groups). e.g. A student may be a member of a group-of-three on an activity within a larger 15-person tutorial class, within a larger 90-person cohort. I wish to capture and filter xAPI data on any of these groupings.

[garemoko]

Hi,
On the first use case please can you give a couple of examples that illustrate the distinction between the two things?

In the second use case, it sounds like the person performing the action is the student and you want to aggregate data based on some groupings that the person is in. In that case, the actor in xAPI should probably be the student and the system using the data will need to know additional information about the student - specifically which group(s) they are in. The way we handle this in Watershed LRS reporting is that organization hierarchy data is imported from an HR system via CSV file and the person's id in that is matched up to the actor id in the xAPI information.

Andrew

[dcollien]

Thank you very much for your reply Andrew.

On the first use case:
e.g.

1. I'll call this a "Group Session". A student may be participating in a group discussion. In this setting their contributions are their own, and they are performing them in the context of a particular group setting. (In the system I am working in, the same core activities can be taken by different groups of people as a group session). In this situation I presume to add this Group as the context for that statement, as the Group context into which a contribution is being made (destination).
2. I'll call this "Group Work". A student may be working with others in a group setting, but only one member needs to act on behalf of the group. e.g. submitting a group proposal/contribution. In this situation I presume to have a different verb, e.g. capturing the essence of "contribute on behalf of a group", and now this could signal that the Group in the context is to instead be interpreted as the group context from which the contribution is originating (source).
3. A combination thereof: A student may be working together on a contribution which is submitted by one member of the group on behalf of that group, to be shared with a different group (or more concretely, one member of a small 3-person group performs an action on behalf of that small group, to share an artefact with their larger 15-person tutorial class group.). This gets confusing as now we have two groups to reference: the Group context from which the contribution was made (source) and the Group context to which the contribution is shared (destination).

In the second case your interpretation sounds right - it is groupings that person is in, within the context of that particular statement, and the statement can provide only the most specific group context, but additional data is required to be able to aggregate by more general groupings.
Importing the group hierarchy separately sounds like a good workaround (I'm glad Watershed LRS has that capability) - I was hoping that this hierarchy could be added to the data in the statement for ease of referencing, similarly to how Activity hierarchy is captured within the statement.

Cheers,
David

[garemoko]

Thanks for the extra detail. I don't have a definitive answer to this and I'd encourage you to try a few things out to see what ends up working. If possible, try to connect with others looking to track the same detail about group work so you can share an approach.

In general though, there are two parts of the xAPI statement that I imagine could be useful:

1. context.instructor In scenario 1, the actor is the student and the instructor is the group. In 2, the actor is the group and there is no instructor. In scenario 3 the actor is the smaller group and the instructor is the larger group. This may not be ideal because the groups being presented to are not really the instructor and in fact there may be a separate instructor that you want to record.

2. context.extensions with an extension defining various agents and groups associated with the experience. This extension could work in a similar way to the contextActivities property in that each property of the extension could contain an array of group objects representing those involved and related to the experience in different ways. Possible properties might include things like 'observers', 'audiences', 'targets', 'recipients' etc.

[dcollien]

Thank you Andrew.

I think I might opt for option 2. for the time being - that sounds like an extensible way forward until there's some more community consensus on these kinds of use cases.

The kinds of terminology are perhaps more aligned to distinguishing between "participants" and "contributors" as types of collaborator, in my use case.