Abstract

The IMS OneRoster (OR) standard addresses the exchange of student data (primarily about people, courses, enrollments and grades) between different educational systems for the specific needs of K-12. The primary use-case is the exchange of data between a Student Information System (SIS) and Learning Management System (LMS). In OR 1.2, the service has been split into three core services:

• OneRoster Rostering Service 1EdTech OneRoster 1.2 Rostering Service Model Final Release 1.0 - to enable the exchange of information about the rostering of people in classes;
• OneRoster Gradebook Service 1EdTech OneRoster 1.2 Gradebook Services Final Release 1.0 - to enable the exchange of information about results which may be aligned as lineItems and categories which are collections of lineItems;
• OneRoster Resources Service - described in this document.

This OR 1.2 Resources Service provides the ability to manage the allocation of resources to classes, courses and users. It does NOT enable access to the resources themselves. A OneRoster resource is a description of a resource with sufficient information such that the resource itself could be obtained. In this document the data exchange is described in an implementation-independent format i.e. using a profile of the Unified Modeling Language (UML). The service description includes the definition of the data formats that are exchanged using a set of service operations.

Introduction

This Section is NOT NORMATIVE.

Scope and Context

This document is the OneRoster 1.2 Resources Service Model and as such it is used as the basis for the development of the following documents:

• OneRoster 1.2 Resources REST/JSON Binding IMS OneRoster 1.2 Resources REST/JSON Binding Final Release - the description of the REST/JSON binding, including the OpenAPI description, of the Information Model;
• OneRoster 1.2 Implementation Guide 1EdTech OneRoster 1.2 Implementation Guide Final Release 1.0 - the recommended best practices for implementing the set of OneRoster services;
• OneRoster 1.2 Conformance and Certification 1EdTech OneRoster 1.2 Conformance and Certification Final Release 1.0 - the conformance guidelines for achieving OneRoster Resources certification.

This information model defines the OneRoster Resources Abstract Application Programming Interface (a-API). This service model is described using the Unified Modeling Language (UML) based upon the 1EdTech Model Driven Specification approach and the associated modelling toolkit 1EdTech Binding Auto-generation Toolkit (I-BAT). This means that this specification is based upon the concepts of:

• Interoperability - the OneRoster Resources service focuses on the exchange of learning standards and competencies definitions. There are no definitions in the specification on how the data is managed within the end-systems;
• Service-oriented - the OneRoster Resources service specification defines the exchange of information in terms of the services being supplied by the collaboration of the systems.

Conventions

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, NOT RECOMMENDED, NOT REQUIRED, OPTIONAL, RECOMMENDED, REQUIRED, SHALL, SHALL NOT, SHOULD, and SHOULD NOT in this document $are to be interpreted as described in Key words for use in RFCs to Indicate Requirement Levels.

An implementation of this specification that fails to implement a MUST/REQUIRED/SHALL requirement or fails to abide by a MUST NOT/SHALL NOT prohibition is considered nonconformant. SHOULD/SHOULD NOT/RECOMMENDED statements constitute a best practice. Ignoring a best practice does not violate conformance but a decision to disregard such guidance should be carefully considered. MAY/OPTIONAL statements indicate that implementers are entirely free to choose whether or not to implement the option.

The Conformance and Certification Guide for this specification may introduce greater normative constraints than those defined here for specific service or implementation categories.

Changes in the Resources Service 1.2

The only changes made in this new version are:

• The Resource Management parts of the OneRoster specification have been separated out into their own Service Model and REST/JSON Binding documents;
• The endpoint 'getResourcesForUser()' has been added;
• The endpoints have been annotated as '/ims/oneroster/resources/v1p2' to replace the '/ims/oneroster/v1p1';
• The 'RoleEnum' vocabulary has been made extensible to enable easier profiling for internationalisation;
• Use of OAuth 1.0a message signing has been removed. The use of OAuth 2.0 Bearer Tokens (Client Credentials Grant) is required instead. The security architecture has been aligned to the 1EdTech Security Framework 1EdTech Security Framework 1.1 Final Release.

Nomenclature

API

Application Programming Interface

GUID

Globally Unique Identifier

HTTP

Hypertext Transfer Protocol

I-BAT

IMS Binding Autogeneration Toolkit

IETF

Internet Engineering Task Force

JSON

Java Script Object Notation

LIS

Learning Information Services

NCES

National Centre for Education Statistics

OAS

OpenAPI Specification

PII

Personally Identifiable Information

REST

Representational State Transfer

RFC

Request for Comments

TLS

Transport Layer Security

UML

Unified Modeling Language

URI

Uniform Resource Identifier

URL

Uniform Resource Locator

UTC

Coordinated Universal Time

YAML

Yet Another Markup Language

Use-cases

This Section is NOT NORMATIVE.

The set of use-cases addressed by the OR Resources Service are summarised in Table 2.1.

ID	Use-case Description
1	To enable a system to obtain information about the set of resources that should be used when taking a specific class. To provide the set of identifiers that are allocated to a class.
2	To enable a system to obtain information about the set of resources that should be used when taking a specific course. To provide the set of identifiers that are allocated to a course.
3	To enable a system to obtain information about the set of resources that should be made available to a specific user. To provide the set of identifiers that are allocated to a user.
[Table 2.1 - The list of use-cases enabled by this OneRoster service.]

Service Architecture and Specification Model

This Section is NOT NORMATIVE.

An Abstract Representation

It is important to remember that this document contains a description of the underlying service model in terms of the abstract Application Programming Interface (API). The manner in which this abstract representation is visualized is not intended to dictate the implementation form of the Service. The breakdown of the service into its interface classes is a convenient way to document the set of behaviors. The objective for producing these interfaces is to identify and define the messages that are exchanged between the end-systems to realize the system behaviors required of the service.

The internal organization of an implementation of the full abstract API is beyond the scope of this specification. The only constraint is that the external behavior of the abstract API complies with this specification. This means that a .NET, J2EE, etc. physical implementation of this abstract API does not have to represent the functionality using the same breakdown of operations/methods. This physical implementation is not subject to the conformance specification.

It is important to note that the UML representation of the interfaces is used to help develop and document the Service Model and various Bindings. It is not a requirement for a system to implement this interface as defined i.e. to use the same parameters, etc. Conformance against this specification will be confirmed by inspecting the appropriate binding of the information model and ensuring that the relevant information is present and that different sequences of activity result in the predicted and mandated behavior. It is essential that the behaviors described by each of the operations are fully supported and that the behaviors described by different sequences are also maintained.

Service Providers and Service Consumers

The basic architectural model for the OR Resources Service specification is shown in Figure 3.1. In this architecture the scope of the IMS OR Resources Service specification is shown as the dotted line. The scope of the interoperability is the data and behavioral models of the objects being exchanged.

Figure 3.1 - The OR Resources service architecture.

It is important to remember that the structure of the exchanged information has NO bearing on how the same information is contained within the 'consumer' and 'provider' OR Resources systems (the OR Resources repositories in the two end-systems). It is simply a representation of the data used to facilitate exchange between the end-systems. The only constraint on the end-system repositories is that they provide data persistence consistent with the required behavior.

Service Objects

The set of service objects that are exchanged between end-systems are:

• Resource - the container for the complete set of data for a Resource.

The set of service collection objects that are exchanged between end-systems are:

• ResourceSet - a set of Resources.

A class and/or a course and/or a user has a set of associated resources. A class, course and user MUST reference the set of associated resources. A UML class representation of this set of relationships is shown in Figure 3.2.

Figure 3.2 - The logical relationships between resources and classes, courses and users.

In general a resource will be associated with more than one class and/or course and/or user.

Synchronous and Asynchronous Services

The OR Resources Service is a synchronous service i.e. the consumer is blocked until the response from the provider is received. This means that a consumer can only have one outstanding request with a service provider. The corresponding sequence of actions is shown in Figure 3.3.

Figure 3.3 - The action sequence for the OR Resources synchronous service.

Figure 3.3 shows the action sequence from the prespective of the consumer but it must be noted that a Service Provider will be expected to support concurrent requests from many consumers.

OneRoster Rostering and Resources Choreography

Apart from the 'getAllResources()' call, the other calls require provision of a 'sourcedId' to identify either the resource itself or the associated class or course. Therefore, support for the Resources endpoints should also require support for the OR Rostering endpoints. The Class and Course classes contain the set of sourcedIds for the resources associated with the class or course retrospectively and so this is the entry point for obtaining the associated resource allocations.

The Behavior Model

The definition of the operations of the service. This focuses on the description of the behaviors supported by the service. The behaviors are grouped as interfaces;

Interface	Description
CoursesManagement	This enables the management of information about resources i.e. the allocation of resources to courses.
ClassesManagement	This enables the management of information about resources i.e. the allocation of resources to classes.
ResourcesManagement	This enables the management of information about resources.
UsersManagement	This enables the management of information about resources i.e. the allocation of resources to courses.

CoursesManagement Interface

This enables the management of information about resources i.e. the allocation of resources to courses.

Operation	Description
getResourcesForCourse	To read, get, the collection of resources associated to the specified course. This is the OneRoster description of the resources and not the actual resources. If the specified class cannot be identified within the service provider then a status code of 'unknownobject' must be reported.

"getResourcesForCourse" Operation

To read, get, the collection of resources associated to the specified course. This is the OneRoster description of the resources and not the actual resources. If the specified class cannot be identified within the service provider then a status code of 'unknownobject' must be reported.

Parameters

No parameters defined.

Return Parameters

Type	Description	Multiplicity	Confidentiality
ResourceSet	No Description	[1]	N/A

ClassesManagement Interface

This enables the management of information about resources i.e. the allocation of resources to classes.

Operation	Description
getResourcesForClass	To read, get, the collection of resources associated to the specified class. This is the OneRoster description of the resources and not the actual resources. If the specified class cannot be identified within the service provider then a status code of 'unknownobject' must be reported.

"getResourcesForClass" Operation

To read, get, the collection of resources associated to the specified class. This is the OneRoster description of the resources and not the actual resources. If the specified class cannot be identified within the service provider then a status code of 'unknownobject' must be reported.

Parameters

No parameters defined.

Return Parameters

Type	Description	Multiplicity	Confidentiality
ResourceSet	No Description	[1]	N/A

ResourcesManagement Interface

This enables the management of information about resources.

Operation	Description
getAllResources	To read, get, a collection of resources i.e. all resources. This is the OneRoster description of the resources and not the actual resources.
getResource	To read, get, a specific OneRoster resource description. If the specified class cannot be identified within the service provider then a status code of 'unknownobject' must be reported.

"getAllResources" Operation

To read, get, a collection of resources i.e. all resources. This is the OneRoster description of the resources and not the actual resources.

Parameters

No parameters defined.

Return Parameters

Type	Description	Multiplicity	Confidentiality
ResourceSet	No Description	[1]	N/A

"getResource" Operation

To read, get, a specific OneRoster resource description. If the specified class cannot be identified within the service provider then a status code of 'unknownobject' must be reported.

Parameters

No parameters defined.

Return Parameters

Type	Description	Multiplicity	Confidentiality
SingleResource	No Description	[1]	N/A

UsersManagement Interface

This enables the management of information about resources i.e. the allocation of resources to courses.

Operation	Description
getResourcesForUser	To read, get, the collection of resources available to the specified user. This is the OneRoster description of the resources and not the actual resources. If the specified user cannot be identified within the service provider then a status code of 'unknownobject' must be reported.

"getResourcesForUser" Operation

To read, get, the collection of resources available to the specified user. This is the OneRoster description of the resources and not the actual resources. If the specified user cannot be identified within the service provider then a status code of 'unknownobject' must be reported.

Parameters

No parameters defined.

Return Parameters

Type	Description	Multiplicity	Confidentiality
ResourceSet	No Description	[1]	N/A

The Data Model

Data Class Descriptions

Base Class

This is the base class which all of the first class objects in the Resource service inherit. It defines the instance's unique, interoperability identifier, the status of the instance data and the date the data was last changed. It all defines how the data model can be extended using the 'metadata' structure.

Attribute	Type	Description	Multiplicity	Privacy
sourcedId	GUID	All Objects MUST be identified by a Source Identifier. This is a GUID i.e. a unique system interoperability identifier for an object. This is the GUID that SYSTEMS will refer to when making API calls, or when needing to identify an object. It is RECOMMENDED that systems are able to map whichever local identifiers (e.g. database key fields) they use to the corresponding SourcedId. The sourcedId of an object is considered an addressable property of an entity and as such will not be treated as Personally Identifiable Information (PII) by certified products. Therefore, as a part of certification, vendors will be required to declare that they will notify customers via documentation or other formal and documented agreement that sourcedIds should never contain PII in general, but particularly users. This means that if a customer includes a student name in an enrollment.sourcedId, it will not fall to any certified product to protect the enrollment.sourcedId as PII, or even the userSourcedId field in the enrollment record.	[1]	N/A
status	BaseStatusEnum	All objects MUST BE either 'active' or 'tobedeleted'. Something which is flagged 'tobedeleted' is to be considered safe to delete. Systems can delete records that are flagged as such if they wish, but they are not under any compulsion to do so. NOTE: In v1.1 the enumeration value of 'inactive' was removed and so for backwards compatibility all such marked objects should be interpreted as 'tobedeleted'.	[1]	N/A
dateLastModified	DateTime	All objects MUST be annotated with the dateTime upon which they were last modified. This enables requesters to query for just the latest objects. DateTimes MUST be expressed in W3C profile of [ISO 8601] and MUST contain the UTC timezone.	[1]	N/A
metadata	Metadata	All objects CAN be extended using the Metadata class. This specification is silent on what implementers may consider to be appropriate extensions.	[0..1]	N/A

Metadata Class

This is the container for the data model extensions that may be assigned to the associated class of objects.

This class can be extended with additional properties.

Resource Class

A resource is a description of learning content that is related to a course and/or a class and/or a user. This identifies a resource that is used by a teacher, learner, etc. as part of the learning experience. A resource MUST be associated to a course and/or a class.

Attribute	Type	Description	Multiplicity	Privacy
title	NormalizedString	A human readable title/label for the resource.	[0..1]	N/A
roles	RoleEnumExt	The set of roles, types of users, who are expected to make use of the resource.	[0..*]	N/A
importance	ImportanceEnum	This is an indicator of the significance of the resource i.e. primary or secondary.	[0..1]	N/A
vendorResourceId	Identifier	This is a unique identifier for the resource allocated by the vendor.	[1]	N/A
vendorId	Identifier	Identifier for the vendor who created the resource. This will be assigned by 1EdTech as part of Conformance Certification.	[0..1]	N/A
applicationId	Identifier	Identifier for the application associated with the resource. The nature, and how this identifier is assigned is not defined by this specification.	[0..1]	N/A
sourcedId	GUID	All Objects MUST be identified by a Source Identifier. This is a GUID i.e. a unique system interoperability identifier for an object. This is the GUID that SYSTEMS will refer to when making API calls, or when needing to identify an object. It is RECOMMENDED that systems are able to map whichever local identifiers (e.g. database key fields) they use to the corresponding SourcedId. The sourcedId of an object is considered an addressable property of an entity and as such will not be treated as Personally Identifiable Information (PII) by certified products. Therefore, as a part of certification, vendors will be required to declare that they will notify customers via documentation or other formal and documented agreement that sourcedIds should never contain PII in general, but particularly users. This means that if a customer includes a student name in an enrollment.sourcedId, it will not fall to any certified product to protect the enrollment.sourcedId as PII, or even the userSourcedId field in the enrollment record.	[1]	N/A
status	BaseStatusEnum	All objects MUST BE either 'active' or 'tobedeleted'. Something which is flagged 'tobedeleted' is to be considered safe to delete. Systems can delete records that are flagged as such if they wish, but they are not under any compulsion to do so. NOTE: In v1.1 the enumeration value of 'inactive' was removed and so for backwards compatibility all such marked objects should be interpreted as 'tobedeleted'.	[1]	N/A
dateLastModified	DateTime	All objects MUST be annotated with the dateTime upon which they were last modified. This enables requesters to query for just the latest objects. DateTimes MUST be expressed in W3C profile of [ISO 8601] and MUST contain the UTC timezone.	[1]	N/A
metadata	Metadata	All objects CAN be extended using the Metadata class. This specification is silent on what implementers may consider to be appropriate extensions.	[0..1]	N/A

ResourceSet Class

The container for a collection of resource records. The order is not significant. This may be empty. The service provider may not have any resources or cannot identfiy any resources that fit the specified filter constraints.

Attribute	Type	Description	Multiplicity	Privacy
resources	Resource	The set of contained resource identfiers.	[0..*]	N/A

SingleResource Class

The container for a single resource. This may be empty i.e. the resource has no properties that obey any of the specified selection criteria.

Attribute	Type	Description	Multiplicity	Privacy
resource	Resource	The label for the contained resource.	[1]	N/A

imsx_CodeMinor Class

This is the container for the set of code minor status codes reported in the responses from the Service Provider.

Attribute	Type	Description	Multiplicity	Privacy
imsx_codeMinorField	imsx_CodeMinorField	Each reported code minor status code.	[1..*]	N/A

imsx_CodeMinorField Class

This is the container for a single code minor status code.

Attribute	Type	Description	Multiplicity	Privacy
imsx_codeMinorFieldName	NormalizedString	This should contain the identity of the system that has produced the code minor status code report. In most cases this will be the target service provider denoted as 'TargetEndSystem'.	[1]	N/A
imsx_codeMinorFieldValue	imsx_CodeMinorValueEnum	The code minor status code (this is a value from the corresponding enumerated vocabulary).	[1]	N/A

imsx_StatusInfo Class

This is the container for the status code and associated information returned within the HTTP messages received from the Service Provider. For the OneRoster Resources service this object will only be returned to provide information about a failed request i.e. it will NOT be in the payload for a successful request. See Appendix B for further information on the interpretation of the information contained within this class.

Attribute	Type	Description	Multiplicity	Privacy
imsx_codeMajor	imsx_CodeMajorEnum	The code major value (from the corresponding enumerated vocabulary). See Appendix B for further information on the interpretation of this set of codes. The permitted vocabulary for the values for the CodeMajor field.	[1]	N/A
imsx_severity	imsx_SeverityEnum	The severity value (from the corresponding enumerated vocabulary). See Appendix B for further information on the interpretation of this set of codes.	[1]	N/A
imsx_description	String	A human readable description supplied by the entity creating the status code information.	[0..1]	N/A
imsx_CodeMinor	imsx_CodeMinor	The set of reported code minor status codes. See Appendix B for further information on the interpretation of this set of codes.	[0..1]	N/A

Derived Class Descriptions

GUID Class

The data-type for establishing a Globally Unique Identifier (GUID). This is the data-type used for a 'sourcedId'. There is no predefined structure for the GUID.

Identifier Class

The data-type for a unique identifier (but not a GUID). The format/structure of such an identifier is undefined.

RoleExtString Class

The data-type that enables the 'RoleEnum' vocabulary to be extended.

Attribute	Type	Description	Multiplicity	Privacy
pattern	String	The regular expression to constrain the structure of the string that MUST be used when creating a new, proprietary, vocabulary term. The term must start with the substring 'ext:'.	[1]	N/A

Union Class Descriptions

RoleEnumExt Class

The data-type for the 'role' characteristic used to identify the type of user for whom the resources are targetted. This is an extensible enumerated vocabulary. Extending the vocabulary makes use of a naming convention.

Attribute	Type	Description	Multiplicity	Privacy
pattern	String	The regular expression to constrain the structure of the string that MUST be used when creating a new, proprietary, vocabulary term. The term must start with the substring 'ext:'.	[1]	N/A
administrator	String	Administrator in the organization (e.g. School).	[1]	N/A
aide	String	Someone who provides appropriate aide to the user but NOT also one of the other roles.	[1]	N/A
guardian	String	Guardian of the user and NOT the Mother or Father. May also be a Relative.	[1]	N/A
parent	String	Mother or father of the user.	[1]	N/A
proctor	String	Exam proctor. May be used for enrollment.	[1]	N/A
relative	String	A relative of the user and NOT the Mother or Father. May also be the Guardian.	[1]	N/A
student	String	A student at an organization (e.g. School).	[1]	N/A
teacher	String	A Teacher at an organization (e.g. School).	[1]	N/A

Enumerated Vocabulary Descriptions

Link Data Definitions

The set of descriptions for the link data definitions that are used to establish the intra- and inter- specification relationships;

Privacy Implications

All of the privacy implications contained within this Information Model are described in this Section. All of the corresponding concepts and methods for these privacy annotations are defined in the Privacy Framework.

Accessibility

denotes information about the accessibility personal needs and preferences of the user

Analytics

denotes information that will be used to support the creation of learning analytics

Container

denotes that the child attributes have privacy-sensitive information

Credentials

denotes access control information for the use e.g. password, private key, etc.

CredentialsIdRef

denotes reference to/use of an identifier to credentials information for the user

Demographics

denotes information about the demographics of the user e.g. ethnicity, gender, etc.

Extension

denotes that proprietary information can be included and so this MAY contain privacy-sensitive information

Financial

denotes that the information is of a financial nature e.g. bank account, financial aid status, etc.

Identifier

denotes a unique identifier that has been assigned, by some third party, to the user e.g. passport number, social security number, etc.

IdentifierRef

denotes reference to/use of a unique identifier that has been assigned, by some third party, to the user

Insurance/Assurance

denotes that the information is about the insurance life-assurance nature, e.g. type of insurance, etc.

Legal

denotes that the information is of a legal or judicial nature e.g. Will, prison record, etc.

Medical/Healthcare

denotes that the information is of a medical, or healthcare-related nature e.g. allergies, blood-type, mobility needs, etc.

N/A

denotes that there are NO PRIVACY IMPLICATIONS for this attribute (this is the default setting)

Other

denotes privacy sensitive information that is NOT covered by one of the other categories

Qualification/Certification

denotes that the information is about education qualifications, skill-set certifications, microcredentials, etc.

Personal

denotes personal information about the user e.g. name, address, etc.

SourcedId

denotes the interoperability unique identifier that has been assigned and MUST be present for the correct usage of the corresponding 1EdTech specification

SourcedIdRef

denotes reference to/use of the interoperability unique identifier, sourcedId, to link/point to an associated 1EdTech object

Confidentiality Level

All of the privacy classification of the exchanged payloads are described in this Section.

unrestricted

there are no privacy concerns (this is the default value).

normal

denotes that privacy sensitive data could be included and so all best practices to secure this data should be used.

restricted

denotes that some of the data is more sensitive than usual or that many attributes information that when used together create increased vulnerability for identification of the associated individual or group.

veryrestricted

denotes that the request could contain very sensitive privacy data. Depending on the capabilities of the Provider this very sensitive data may be obfuscated or may not even be present

Extending and Profiling the Service

This section is NOT NORMATIVE.

Proprietary extensions of the service are based upon two approaches:

• The extension of the data models being manipulated by the current set of operations;
• The inclusion of new operations to support new proprietary functionality.

It is NOT permitted to change the behavior of the current set of operations. Such changes MUST be supported by the creation of new operations.

Extending the Specification

Proprietary Operations

The definition of new operations should follow the same format as adopted herein. The new operations should be defined using a new interface type. Every operation must result in the return of a status code that describes the final state of the request on the target end system.

An example of creating such an extension is given in the accompanying Best Practices document 1EdTech OneRoster 1.2 Implementation Guide Final Release 1.0.

Proprietary Data Elements

It is recognized that implementers may wish to extend the specification. The preferred mechanism for doing this is for implementers to use an extension space within the OneRoster data model, and then set their parsers to read those extension attributes. Extensions are ONLY permitted using the 'metadata' attribute within the 'Base' class (see Sub-section 5.1.1 for more details).

Proprietary Vocabulary Terms

In this version the ability to extend some of the enumerated vocabularies has been added: currently, ONLY the 'RoleEnum' vocabulary MAY be extended. Each proprietary term must start with the characters 'ext:'.

Profiling the Specification

This Service can be profiled. In general, Profiling is used to:

• Refine which Interfaces are used and which operations are supported for each Interface;
• Refine the data models by increasing the constraints on the base definitions.

Valid Profiles must be restrictive i.e. optional features can be removed or constraints increased but new features must not be added. A Profile of this service is made by annotating the UML supplied with the documentation for the specification.

It is strongly recommended that a profile of this specification is undertaken either by, or with the close support, of 1EdTech. However, no matter who is responsible for creating the profile artefacts (documents, XSDs, etc.), it is strongly recommended that the 1EdTech specification tools are used. This will ensure that the artefacts are consistent with the base specifications and that useful support documentation is automatically produced e.g. creation of a document that summarises the differences between the base specification and the profile. Organizations wishing to produce a profile of this specification should contact the 1EdTech VP of Operations at: operations@1edtech.org.

Related resources

Data Model

Class	JSON Schema
ResourceSet	https://purl.imsglobal.org/spec/orresources/v1p2/schema/json/orresources_v1p2_resourceset-jsonschema1.json
SingleResource	https://purl.imsglobal.org/spec/orresources/v1p2/schema/json/orresources_v1p2_singleresource-jsonschema1.json
imsx_StatusInfo	https://purl.imsglobal.org/spec/orresources/v1p2/schema/json/orresources_v1p2_imsx_statusinfo-jsonschema1.json

Service Model

The service model is available as an OpenAPI document at the following URL:

• OneRoster Resources Service 1.2 OpenAPI 3.0 definition file (JSON)
• OneRoster Resources Service 1.2 OpenAPI 3.0 definition file (YAML)

Skill

The skill model is available as a JSON file at the following URL:

• OneRoster Resources Service 1.2 Skill