Event data integration

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 IMS Global Caliper standard for the UDP to accept the data.

There are three major aspects to building an event data integration to the Unizin Data Platform:

1. Caliper sensor. Per the IMS Global standard, your LTI application will implement a Caliper sensor to emit Caliper-conformant events.

2. Caliper event design. Ensure that the design of your Caliper events supports the UDP’s event enrichment and processing capabilities.

3. UDP event data integration mechanics. Integrate your LTI application’s event data stream with the UDP Caliper endpoint.

Not a Caliper implementation guide

This article is not an implementation guide for a Caliper sensor. All LTI application developers should consult the IMS Global Caliper documentation when deciding how to implement the tool’s Caliper sensor and which data to produce.

Implement a Caliper sensor

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.

Caliper event design

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.

Make your event payloads consistent

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.

Make your identifiers predictable IRIs or URNs

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:

“edApp.id”: “http://unizin.instructure.com/”
“session.id”: “urn:umich:engin:leccap:session:T7Lzgsmtq0x2e1204jut6sop6”

Include LTI launch parameters in your payload

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.

"federatedSession": {
  "type": "LtiSession",
  "id": "urn:session-id-localized/lti/oauth_nonce/5a81e2eb557427.65333446",
  "messageParameters": {
    "custom_canvas_course_id": "12345",
    "custom_canvas_user_id": "98765",
    "lis_course_offering_sourcedid": "test_99999003",
    "lis_person_sourcedid": "11235813",
    "resource_link_id": "a1b2c3d4e5f6g7h8i9j10"
  },
  "user": "https://university.edu/#profile:smith"
}