Event data integration
Last updated
Last updated
All learning tools create experiences in which learning unfolds. The UDP is designed to accept teaching and learning behaviors that unfold, in real time, in learning tools as behavior data.
Determining exactly which behavior data is useful to communicate to the UDP will depend on the type of teaching and learning experiences supported by the LTI app and its pedagogy. Whatever those experiences and behavior might be, an LTI app will need to express them in the for the UDP to accept the data.
There are three major aspects to building an event data integration to the Unizin Data Platform:
Caliper sensor. Per the IMS Global standard, your LTI application will implement a Caliper sensor to emit Caliper-conformant events.
Caliper event design. Ensure that the design of your Caliper events supports the UDP’s event enrichment and processing capabilities.
UDP event data integration mechanics. Integrate your LTI application’s event data stream with the UDP Caliper endpoint.
This document does not cover the implementation of a Caliper sensor that conforms with the IMS Global Caliper standard. Please use IMS Global’s documentation.
The IMS Global Caliper standard provides flexibility for the design of a Caliper event. It also leaves certain parts of the implementation, such as the definition of identifiers, open to the learning tool.
Unizin recommends that, in addition to conforming with Caliper, you consider following these guidelines when defining your event payload. By following these guidelines, you enable the UDP Caliper endpoint and the UDP Event pipeline to process events in a consistent fashion, such that behavior data can be associated and used in conjunction with context data.
In practice, the UDP endpoint examines the attributes in event payloads to determine if they qualify beyond standard processing. The UDP endpoint then routes an event to the types of processing for which it qualifies. Our processing types are categorized into two main tiers.
To enable event processing for behavior from your learning tool, the UDP endpoint will require that your Caliper events have a consistent shape, so that attributes are in the same nodes of the JSON object. We strongly urge you to:
Provide an immutable edApp value (so we know how to read the rest of your event payload)
Use the same event shape (JSON object structure) across all events
Document your event payload shapes and attribute patterns
Share your documentation with Unizin. This enables us to write event processing based on your event attribute data.
We suggest that you define the identifiers included in your event payloads as Internationalized Resource Identifiers, or IRIs (RFC 3987). The UDP Caliper endpoint can parse each event that flows into a UDP, extract its identifiers, and then further parse the identifiers. The purpose of extracting the identifiers in an event is to associate it with a corpus of institutional data using the UDP Keymap. A known, predictable string pattern will allow the UDP to strip the relevant piece(s) of the id that can cross-reference to existing data in the relational store.
Alternatively, if your identifiers are not normally IRIs, we suggest constructing them as URNs, which are useful for showing the object’s location in the app’s internal hierarchy.
For example:
If your tool is launched via LTI, Unizin recommends including the LTI launch parameters passed to your tool via an event’s federatedSession object. Of particular interest are the LTI parameters representing the LMS course ID and the LMS user ID corresponding to the event. These values are typically useful for modeling your event data with object data.
In the example below, the LMS course and user IDs are passed via messageParameters (this is arbitrary) and identified with the attributes lis_course_offering_sourcedid and lis_person_sourcedid, respectively.