Types and social flow

Mapping to planes

• all activities can receive a 'whole class' data structure
• a groupingKey-mapped product
  • can be received by a team-based activity, in which case one of the groupingKeys must correspond to the groupingKey of the activity (this is enforced by the Graph Editor)
  • can be received by a Plane 1 activity, in which case all the students who match a certain groupingKey/Attribute pair will receive the corresponding activityData unit
• only individual activities can receive activityData mapped to individual students

Tracing

We need to trace the structure of activity data across activities and operators. The social structure of activity data cannot be determined by the activity, it gets a compatible structure in (as seen above), fed into each instance, and the output is purely determined by plane and groupingKey (for p2).

Operators are more complex, they always receive the entire activityData in, and have to specify

• which structure they accept (in addition to the type of dataUnits)
• which structure they produce

The three options are similar to the header of activityData:

• structure: 'all'
• structure: 'individual'
• structure: { groupingKey: 'something' }

Structurally, structure individual and structure with grouping key are similar. The difference is between grouped and ungrouped data units.

Theoretically we could distinguish between aggregating, disaggregating, and transforming operators, hard-coding that each type could only do one thing (ie. transforming would be mapped over however many dataUnits, whereas aggregating would go many->one, and disaggregating one->many (having to specify grouping key etc). However, this seems limiting...

Let's try for now...