Open dcollien opened 6 years ago
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
Thank you very much for your reply Andrew.
On the first use case: e.g.
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
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:
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.
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.
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.
In the following use cases I cannot see how to interpret this spec, and wish to clarify my understanding: