Comment on page
SIS data integration
A Student Information System (SIS) is an essential, enterprise system in the educational technology landscape. It is the system of record for a broad range of data that are pertinent to data science, research, and learning analytics. Consequently, SIS data is a required part of the overall UDP implementation.
This document describes high-level details of an SIS context data integration with the UDP. For an in-depth description of an SIS data integration’s nuts and bolts, please review our technical documentation on writing a UDP context data integration.
A UDP loading schema is the conceptual anchor of a context data integration with the UDP.
All institutions are expected to support the latest version of the SIS UDP loading schema. It is an essential part of a UDP instance and UDP implementation.
- Required. These entities are required from the SIS for any UDP implementation. The UDP cannot import and join LMS and other LTI tool data into the UDP without these entities from the SIS.
- Strongly recommended. These entities are almost always needed for research, data science, and learning analytics use cases. Consequently, Unizin strongly recommends that institutions include these entities in their SIS data integration.
- Recommendation. The need for these entities varies by institution. Institutions may add data for these entities over time as needed.
As a starting point, Unizin’s recommendation is that Academic institutions implementing the UDP should provide the “strongly recommended” entities in addition to the required entities.
We strongly recommend that you generate an SIS context dataset every night. Please note that the UDP currently only accepts full historical datasets. Consequently, Academic institutions will need to reproduce the history of SIS data they wish to be available in the UDP on a nightly basis.
The "role" of the Person in the Section and the "status" of that Person in their role are option set values. No other value can be used other than those of the option set. At present, the two values are required for a Course section enrollment record.
The Person entity in the UCDM can be used to model data for any kind of individual. Persons may have different relationships (to course sections, say) that are reflected by their "role" and "status."
The breadth and historical depth of SIS data sent by institutions varies. Our recommendation is that institutions send SIS data for at least 5 years of history or until the beginning of their use of their current LMS, whichever is longer. Generally speaking, longer historical time horizons are attractive for longitudinal analytics and research.
All institutions, regardless of their number of campuses, should populate the Campus entity. We strongly recommended that all multi-campus institutions populate this entity to include all of their campuses. Rolling up data and analytics by campus is often essential to reporting, for example. We also recommend that you properly model all Campus-based relationships (e.g., Academic organization, Course offering, Facility). Those relationships express the dimensions along which data can get rolled up by Campus.
Should “Person” data be unified or differentiated? If unified, how should data conflicts be resolved? Does the Home campus wins on a conflict? If unified, how should FERPA be handled for students who have differing values? What would be different about FERPA? The restrictions applied to the student? Do we would carry through the most aggressive protection?
A_t present_, we do nothing with the FERPA directory block value except capturing it from institutions. It does not change the way we present information in the context store. Nor is it excluded from the data that can be seen by users in the context store. Unizin does not publish the data anywhere. It's only stored in the context store. We capture the FERPA directory block variable mainly in case we do, in future uses of the data than just capturing it, need to use it to selectively present data.
Everywhere data can be unified across campuses, it should be unified across campuses. For example, a single set of values for Academic careers should be pursued. The goal is to let the relationships explain where the data comes from.
Composite identifiers can be useful to differentiate records from different campuses. This is acceptable and even routine for entities like Course offerings and Course sections, where the identifiers need to be unique across the whole system.
Composite identifiers will likely be required for certain entities, like Course offering and Course section, where there are common codes across campuses. Every record in a dataset must be unique along some grain of data. If you're aggregating data across multiple campuses, you may need to use campus-specific markers in the identifiers to make the datasets unique.