|Click Image For Full-Size Version|
OneRoster® 1.1 solves a school’s need to securely and reliably exchange roster information, course materials and grades between systems. OneRoster supports the commonly used .csv mode for exchange and the latest real-time web services mode known as REST.
See a brief OneRoster Video.
Provision key roster related data including student, course and related enrollment information between various platforms such as a student information system (SIS) and a learning management system (LMS).
Flexible implementation options to align with an institution’s needs and capabilities, supporting simple spreadsheet-style (CSV) exchanges as well as system-to-system exchanges using REST API’s
Improves data exchange among multiple systems with roster and gradebook information, thus eliminating problems before they happen
Transmit scored results between applications, such as student scores from the LMS back to the SIS.
1EdTech has testing programs that enable products to be certified compliant with specific standards and features of the standards. For technology suppliers, participation in the 1EdTech certification process is the fastest and most cost-effective way to achieve product integrations. For institutions, ensuring that your educational technology tools are 1EdTech certified is the best way to establish a plug-and-play ecosystem, allowing your tools and content to work together seamlessly, giving you more choice, and reducing your total cost of ownership. 1EdTech members have access to expert support to implement the standards prior to completing conformance certification. Learn more to begin taking advantage of the benefits of certification.
Institutional & Training Resources
- Introduction to OneRoster 1.1
- OneRoster 1.1 Real-World Scenarios
- 1EdTech K-12 Playbook
- OneRoster Developer FAQ's
- 1EdTech OneRoster Roundtables
OneRoster 1.2 builds on the successes of version 1.1 while making improvements and introducing new functionality driven by the need of 1EdTech member institutions and suppliers. The Public Candidate Final specification documents are being made available now as they are finalized and released by the OneRoster Project Group. Active work continues finalizing some of the content in the implementation and best practices guide.
OneRoster 1.1 Documents
OneRoster 1.1 is the current final version of the specification
- OneRoster 1.1 Specification (CSV Tables)
- OneRoster 1.1 Specification (REST API)
- OneRoster 1.1 Best Practices and Implementation Guide
- OneRoster 1.1 Conformance Guide
Member Resources (Login Required)
Student Learning Data Model
- The 1EdTech Student Learning Data Model visualizes a digital ecosystem interconnected with real-time data. Log in with your 1EdTech member credentials to access specification-level Mapping and Discovery in the tool.
Earlier Versions of the Specification
OneRoster is a modern, easy to use data exchange for rostering, course setup and grade reporting. OneRoster should be a key element in your digital curriculum and automation strategy including Common Cartridge and support for cloud-based content with LTI-enabled Thin Common Cartridge.
Feedback on the specification is welcomed in our public forums.
Learning Information Services Background
The Learning Information Services (LIS) specification is the definition of how systems manage the exchange of information that describes people, groups, memberships, courses and outcomes within the context of learning. The LIS v2.x specification supersedes the 1EdTech GLC Enterprise Services v1.0 specification. The LIS specification is based on the aggregation of the Person Management, Group Management, Membership Management, Course Management, Outcomes Management and the Bulk Data Exchange Management Services specifications. The LIS v2.0 can be implemented using both a Web Services infrastructure (based upon a SOAP http transport mechanism) and the Lightweight Directory Access Protocol (LDAP). An implementation is not required to support each and every service. Neither is an implementation required to support each and every operation. Interoperability is best defined through the use of a Domain Profile. This specification includes such a profile for Higher Education. Interoperability is supported between systems that implement the same profile. The LIS documentation consists of:
- The LIS Specification - describes how the LIS is composed using its six component services;
- Information Models - these documents contain the normative description of the various service definitions, data structures, and their relationships. Each of the six services has its own Information Model;
- Binding documents - each of the Information models has an associated WSDL binding document. Some of the services also have a LDAP binding document;
- Best Practice & Implementation Guide - this is intended to provide vendors with an overall understanding of the 1EdTech GLC LIS Specification, the relationship of the specification with other 1EdTech GLC specifications, and a best practices guide derived from experiences of those using the specification. The guide also includes several actual examples that describe how vendors can make the best use of the 1EdTech LIS Specification;
- Core Profiles & Conformance Specification - a set of profiles of the LIS specification has been created. The Core Profiles identify the minimal subset of the functionality that must be supported by systems developed for deployment in HE. These Profiles (there is a Core plus several Additions) define the set of operations and data models that must be supported by the systems supporting the set of services within the LIS. Each profile contains its Conformance Specification against which compliant systems are tested;
- The Binding Files - one of the outputs of the LIS specification is the set of Web Services Description Language/XML Schema Definition (WSDL/XSD) binding files. Each service has its own set of WSDL/XSD files. It is these files that are used by code-generation tools to create the source code that handles the SOAP messages and XML data structures. Some small changes are required to the WSDL files to map the SOAP messages to the actual server-based implementation of the Web Service. Each of the services has a set of vocabulary files that contain the set of default vocabularies defined in the Information Model. The vocabulary files are instances of the 1EdTech GLC Vocabulary Data Exchange (VDEX) specification.
Feedback may be posted in the 1EdTech public forums.
1EdTech Learning Information Services Specification - Version 2.0.1 Final Specification (30 September 2013)
The Learning Information Services v2.0.1 corrects some minor errors in the v2.0 specification and updates the Core Profile definition. The specification document set contains information models, binding documents, best practice and implementation guidance, profile and conformance specification, and supporting files.
1EdTech Learning Information Services Overview
1EdTech Learning Information Services Specification
Learning Information Services Core Profile Adoption Overview
Learning Information Services Core Profile
Learning Information Services Best Practice and Implementation Guide
1EdTech Person Management Service Information Model
1EdTech Course Management Service Information Model
1EdTech Group Management Service Information Model
1EdTech Outcomes Management Service Information Model
1EdTech Membership Management Service Information Model
1EdTech Bulk Data Exchange Management Service Information Model
1EdTech Person Management Service WSDL/XSD Binding
1EdTech Course Management Service WSDL/XSD Binding
1EdTech Group Management Service WSDL/XSD Binding
1EdTech Outcomes Management Service WSDL/XSD Binding
1EdTech Membership Management Service WSDL/XSD Binding
1EdTech Bulk Data Exchange Management Service WSDL/XSD Binding
WSDLs/XSDs (combined into a single file):
The WSDL bindings are for a Synchronous SOAP implementation only. The WSDL files, expressed using WSDLv1.1, are combined WSDL/XSD files:
The XSDs for each data structure for use with the BDEMS:
The PMS vocabularies are:
- The type of formatted name vocabulary formatnmetypevocabularyv1p0.xml;
- The type of name vocabulary nametypevocabularyv1p0.xml;
- The type of name part-name vocabulary – partnamevocabularyv1p0.xml;
- The type of address vocabulary addresstypevocabularyv1p0.xml;
- The address part vocabulary addresspartvocabularyv1p0p2.xml;
- The type of contact information vocabulary contactinfotypevocabularyv1p0.xml;
- The type of demographics vocabulary demographicstypevocabulartv1p0p2.xml;
- The type of representations vocabulary representationtypevocabularyv1p0.xml;
- The demographics information vocabulary demographicsinfovocabulartv1p0.xml;
- The type of enterprise system role vocabulary epriserolestypevocabularyv1p0.xml;
- The type of institution role vocabulary institutionroletypevocabularyv1p0p2.xml;
- The type of system role vocabulary systemrolevocabularyv1p0.xml;
- The enrollment information vocabulary enrollmentinfovocabularyv1p0.xml;
- The type of agent vocabulary agenttypevocabularyv1p0.xml;
- The type of event date vocabulary eventdatevocabularyv1p0.xml;
- Extension data-types vocabulary extensionvocabularyv1p0p2.xml;
- Language codes languagecodesvocabularyv1p0p2.xml. The set of codes used to identifiy the language for a string (based upon RFC4646).
The CMS vocabularies are:
- Status values vocabulary statusvocabularyv1p0.xml. The permitted status codes;
- Extension data-types vocabulary extensionvocabularyv1p0.xml. The set of data-types for the extensions;
- Language codes languagecodesvocabularyv1p0p2.xml. The set of codes used to identify the language for a string (based upon RFC4646).
The OMS vocabularies are:
- Types of LineItem vocabulary lineitemtypevocabularyv1p0.xml;
- Status of Result vocabulary statusofresultvocabularyv1p0.xml;
- Replace Status Code vocabulary replacestatuscoesvocabularyv1p0.xml;
- Exension data-types vocabulary extensionvocabularyv1p0.xml;
- Language codes – languagecodesvocabularyv1p0p2.xml. The set of codes used to identifiy the langage for a string (based upon RFC4646).
The MMS vocabularies are:
- The set of role types that a Person can have for their Memberships vocabulary roletypevocabularyv1p0p2.xml;
- The set of sub-role types that a Person can have for their Memberships vocabulary subrolevocabularyv1p0p2.xml;
- Extension data-types vocabulary extensionvocabularyv1p0p2.xml;
- Language codes – languagecodesvocabularyv1p0p2.xml. The set of codes used to identify the language for a string (based upon RFC4646).
The BDEMS vocabularies are:
- Parameter types vocabulary parametertypevocabularyv1p0.xml;
- Filter types vocabulary filtertypevocabularyv1p0.xml;
- Filter types for filter objects vocabulary filtervalueobjectvocabularyv1p0.xml;
- Transaction failure status codes vocabulary transactionfailstatusvocabularyv1p0.xml;
- Announce failure reports vocabulary announcefailurereportvocabularyv1p0.xml.
Edu-API is the latest in the 1EdTech family of “academic enterprise” specifications. Driving off the comprehensive modeling of Learning Information Services (LIS) and leveraging the extensive history and experience of past efforts like OneRoster and LTI, Edu-API will allow for the standardized exchange of data between the transactional systems that manage higher education administration and teaching and learning. That means not only increased efficiency on campus, but the facilitation of the development of a new generation of smart, sustainable apps, personalized based on data about the student shared in a secure and responsible way.
Launched in Spring 2018, Edu-API is currently under design and development and welcomes members of the Higher Education institutional and supplier communities to participate as the specification makes its way through the 1EdTech lifecycle. More information can be found at https://imsglobal.org/edu-api