IMS TECH TALK
Contributed by Dr. Colin Smythe, IMS Chief Architect
The Student Learning Data Model: A New Way of Working with the IMS Specifications
Having published edtech interoperability specifications for over 20 years, we’ve learned a few things. As is the standard (pun intended) by all specification development organizations, these specs are published as sets of HTML documents. In most cases, these documents are long, and it is difficult for a reader to find the information of specific interest. New tools are needed to simplify reading specification documentation, and so IMS has been developing such tools over the past 12 months. In November 2020, we announced the availability of the Student Learning Data Model or SLDM for short. The SLDM provides a new way to access, explore and visualize all of the information within the set of IMS specifications relevant to a student’s engagement and progress.
In many cases, an edtech system will make use of more than one IMS specification. An essential part of our development process is the integration between IMS spec, for example, LTI® links being a resource type in Common Cartridge®. The reference now has to be made to several specs. A reader needs to easily access, explore, and visualize information across several sets of documentation. As the number of published specifications increases (over 100 in our history), as the complexity of each specification increases (an unavoidable reality as a specification evolves), and as the integrations become more comprehensive, the availability and use of tools such as the SLDM is essential.
The SLDM provides three tiers of information. The first two tiers are available to any registered user of the IMS website. Access to the third tier is only available to users from IMS member organizations.
The first tier collects the information into an eight-cell honeycomb of:
- User and Organization
- Enrollment & Attendance
- Pathways to Competency
- Instructional Resources
- Assignment and Assessment
- Learning Activities
The second tier—accessed through the honeycomb—provides the list and details of the relevant data models from the IMS specifications. A user of the SLDM can now get all of the information on the data models in just two clicks, avoiding having to dive into the thousands of pages of specification documentation. The third tier—accessed either through the second-tier links or directly—gives even richer details for the data models and related information.
The SLDM is a curation of the relevant specification information. It is a focus or “lens” on the IMS specifications.
Applying the lens to the complete set of IMS specifications provides a way to bring the relevant information into one focus from the mass of spec material. And we plan to make other lenses. As part of realizing the SLDM, the IMS technical team created a new data dictionary or Common Data Model (CDM). We generated the CDM from the source models made in the IMS model-driven specification development process (I will reveal more about this process in later blogs), which guarantees consistency between the published IMS spec documentation and the Common Data Model. The information presented through the SLDM is drawn directly from the CDM.
The first release of the SLDM and CDM draws on data model definitions only. Many IMS specs like OneRoster®, REST API, and others include a service definition. A service definition describes how the data must be exchanged; the data model describes the syntax, semantics, and format of the data to be exchanged but not how the data is exchanged. Future releases of the CDM and SLDM will include the service definitions and the binding technology artifacts, e.g., OpenAPI files, etc. The long-term aim is to make tools such as the SLDM and CDM the primary way of working with IMS specifications.
Access to the SLDM and CDM is through the IMS website. We used GraphQL as the delivery technology when creating the CDM. A GraphQL server contains all of the Common Data Model and responds to queries from the IMS website. GraphQL provides a powerful combination for defining a flexible API with common semantics for the data being exchanged and stored. This is a great learning opportunity for us, so if in the future, IMS members request GraphQL based binding of an IMS specification, we can produce them from a strong understanding of its strengths and weaknesses.
So, what now?
Next, we need your feedback on what to improve and what new features we need to add. The early response has been encouraging, but we want more from you. Some of the specific feedback we need includes:
How can the user experience for the SLDM and Common Data Model be improved?
What type of synthesized information across the specifications is useful?
What type of information and visualization would be useful for our service-based specifications?
The SLDM is the first lens. What are other lenses of interest?
We look forward to hearing your feedback! Please email us at email@example.com.