Default Aggregation Analysis (Roll up Algorithm)

Roll-up Algorithm

Aggregation Analysis allows to have a multi-level structure of activities where information is passed from children to parent nodes. Let's imagine we have the following tree:

Figure 1.: Example tree structure with one root (parent) and two children activities.

Let’s imagine that we want the following expression:

Root[‘result_math’] = Child1[‘result_Fourrier’] * 0,7 + Child2[‘result_derivatives’] * 0,3

Our meta-data model would be composed by following JSON:

[
 {
   "id": "Root",
   "weights": [
     {
       "name": "score",
       "op": "+",
       "children": [
         {
           "id": "Child1",
           "name": "coins",
           "multiplier": 0.7
         },
         {
           "id": "Child2",
           "name": "sweets",
           "multiplier": 0.3
         }
       ]
     }
   ]
 },
 {
   "id": "Child1",
   "parentId": "Root"
 },
 {
   "id": "Child2",
   "parentId": "Root"
 }
]

As we can see the “weights” attribute in the “Root” document describes a list of operations over a list of children.

This model does not allow the the concatenation of a sum and a multiplication on the same level of the tree because is not associative (the order matters). No associative expressions are supported due to the additional level of difficulty added to the algorithm that, in most cases, is not used for a real-life learning experience. It does not make much sense to want to know the result of summing two activities and multiplying them with the result of another activity for a teacher. The teacher wants simple sums, and at most multiplications of results from the learning experiences.

Now let’s imagine:

1. in Time = 1, we receive a trace with Target “Child1” (since this node has no children nor meta-information regarding operations we don’t execute the algorithm) and
2. in Time = 2, the trace is bubbled upwards (Target = “Root”, the parent). Since the “Root” node has an operation that must be performed (calculating Root[‘result_math’] = ...) we execute the algorithm.

The high-level flow of the algorithm that performs the aggregation is:

Let's imagine the trace has been bubbled to “Root”.

Every time a trace is received by a node (e.g. “Root”):

1. Does the node (“Root”) have metadata-information regarding operations with children? If yes...
2. Do the children from the operation actually exist for the current node? (e.g. “Child1” and “Child2”) If yes…
3. Retrieve the operation (e.g. Root[‘result_math’] = Child1[‘result_Fourrier’] * 0,7 + Child2[‘result_derivatives’] * 0,3)
4. Obtain the required values for each child from the operation:
   1. Obtain the current value of Child1[‘result_Fourrier’]. If not available, set default value to 0
   2. Obtain the current value of Child2[‘result_derivatives’]. If not available, set default value to 0
5. Evaluate the operation, in this case is a sum.
6. Persist the current value of the “Origin” node (the trace originally has been sent to “Child1” and bubbled to “Root”, which is when the algorithm has been triggered) so that is can be used the next time the algorithm is triggered in step 4.
7. Persist the final result for the current node (“Root”)

The following diagram displays the Multi-Level-Analysis (MLA).

Figure 2.: Multi-Level-Analysis diagram.

When the metadata-information regarding an aggregation analysis changes, a new event is triggered in the system to re-queue all the traces that have been sent to the analysis, so that the Real-Time analysis starts computing all the results again, but this time considering the changes.

In order to implement the Aggregation analysis and the Multi-Level-Analysis (tree of nodes per Activity) the Backend has been modified to add the following functionalities:

• Each activity can have a pointer pointing to a root activity.
• When a trace is sent to this activity, the Multi-Level Analysis (MLA) identifies that this activity is part of a structure by seeing the pointer to the root activity.
• MLA obtains, using the root activity identifier, the hierarchical structure that composes the activities, as well as the metadata (thresholds, max_attempts, etc) and performs the following calculations with this tree and the current trace:
  • For "completed" type traces:
    1. If you are the completed one: We compare, if there is score, the received score with the threshold score, and, independently of the success of the trace, we overwrite it with (score > threshold)
    2. If any other node is completed: We see if it is our direct child, and if so, we increase our progress and mark that the node has been completed. If all child nodes are completed, we generate a complete trace of ourselves, with the mean of the score.
  • For any trace received, we look for who our father is in that tree, and glue it together.
• Additionally MLA, by beaconing requirements, is able to:
  • Generate a temporal cluster (clustered by time) with the average score of each student per week, month and year.
  • Save a correct/incorrect answer counter
  • Generate the average progress of all the games you are playing
  • Generate an average time statistic comparable to that of a group with similar conditions.
• In addition it has been created:
  • ExternalID: allows to identify an element by means of an ID of an external system. Used in groups and users. It is a type map: {"beaconing: "123", "google": "pepito"}