OneRoster(1.2与高级小组)
OneRoster是一项学校名册交换的国际标准(由1EdTech发布):它以统一格式描述学校的机构、学年、教学科目、班级、注册和用户。它用于把SIS、校园门户(ENT)或LMS接入其他工具,无需重复录入,也不必使用私有格式。
本页面向学校的信息系统负责部门(IT)。它介绍Omniscol在OneRoster方面提供和使用的内容、所要求的认证方式,以及每个交换方向的实际范围。
支持的版本
Omniscol支持 OneRoster 1.2 Rostering——即基础部分(Org、AcademicSession、Course、Class、Enrollment、User、Demographics)——以及 **OR-Groups(Advanced Groups Service)**层。后者是在1.2之上新增三个实体(Group、GroupMembership、GroupAssociation)的附加小组标准。
OR-Groups层是一项正在发布中的标准。它对1.2而言是严格的附加层:Group只以只读方式引用 1.2中的Class / User / Org / AcademicSession。OneRoster 1.3预告会让Class成为Group的一种特化——Omniscol的实现已经向这一方向靠拢。
Omniscol作为生产方(Omniscol → ENT / LMS)
作为生产方,Omniscol通过符合OneRoster的REST API以只读方式开放学校名册,供ENT或LMS读取。
- Rostering 1.2基础部分位于
/ims/oneroster/rostering/v1p2/…之下(例如/orgs、/schools、/academicSessions、/courses、/classes、/enrollments、/users、/teachers、/students、/demographics,每个都有对应的嵌套变体)。 - 小组层位于
/ims/oneroster/groups/v1p0/…之下(/groups、/groupMemberships、/groupAssociations及其嵌套变体)。 - 默认范围是当前学年;可通过参数指定其他学年,或涵盖所有学年。
数据反映的是Omniscol汇总后的排课结果(已发布的课表)。生产方有意设计为只读:不开放任何写入操作(PUT / DELETE)——远程系统不能在Omniscol中创建或删除实体。
生产方的认证
生产方的接口由 client_credentials 流程的OAuth2(机器对机器令牌,没有用户参与)保护,令牌由Omniscol的OAuth2服务器签发。它们不限于Premium账户:访问由OAuth2的 scope 控制,而不是由套餐控制。每个scope对应一项特定服务,对人口统计数据的访问在1.2内部单独隔离:
| 接口 | 接受的scope |
|---|---|
| Rostering 1.2(不含人口统计) | https://purl.imsglobal.org/spec/or/v1p2/scope/roster-core.readonly、https://purl.imsglobal.org/spec/or/v1p2/scope/roster.readonly |
Rostering 1.2 /demographics |
https://purl.imsglobal.org/spec/or/v1p2/scope/roster.readonly、https://purl.imsglobal.org/spec/or/v1p2/scope/roster-demographics.readonly |
| OR-Groups(全部) | https://purl.imsglobal.org/spec/or-groups/v1p0/scope/roster-group.readonly |
OR-Groups令牌无法访问Rostering基础部分,反之亦然。系统不公布任何写入scope。特权scope由Omniscol管理员在注册OAuth2客户端时授予;客户端不能自行授予。OAuth2客户端和令牌的管理请参见OAuth2 / OIDC(提供方)和Omniscol API。
学生范围由小组层提供
一项关键的设计选择:班级或小组的学生名单通过 OR-Groups(GroupMembership)提供,而不是仅靠1.2基础部分。只读取Rostering 1.2的使用方能获得目录(Courses、Classes)、教师到课程的注册关系以及用户名册,但得不到学生的归属关系。要知道谁在哪个班级或哪个小组,使用方必须实现OR-Groups层。这一选择反映了法国的模型:学生被注册到一个班级或小组,而不是逐科目注册。
生产方以REST方式提供服务。OneRoster CSV压缩包格式(每个集合一个文件的zip归档)则在导入一侧支持,供以文件而非API方式提供名册的提供方使用——参见下文的使用方部分。
Omniscol作为使用方(SIS → Omniscol)
作为使用方,Omniscol导入符合OneRoster的SIS名册,并在学校内完成对账。这一使用方配置属于与外部系统的同步:适用于 Premium 账户,并与Omniscol团队按项目确定(参见与外部系统同步)。
- 传输方式——可以是提供方的 REST API(配置基础地址,遵循OneRoster标准分页),并以
client_credentials流程的OAuth2向提供方的服务器认证;也可以是 CSV压缩包(zip归档)。 - 配置档——配置档指明要读取的范围:仅1.2基础部分、小组层,或面向中小学教育的法国映射。仅支持1.2、没有小组服务的提供方也能顺利导入。
- 受控应用——导入遵循与其他连接器相同的原则:Omniscol获取并对账数据,由管理员确认后应用到学校。远程系统从不直接向Omniscol推送数据。
- 幂等的重复导入——外部标识的对应关系会被保留,因此即使提供方更改了某个名称,重复导入也不会产生重复数据。
法国配置档(中小学教育)
面向中小学教育的法国配置档把法国的概念映射到OneRoster模型:division(实际意义上的班级)对应主要的组织类Group;小组对应教学类Group;教学小组组合对应跨班的Group;班内分组和对齐转化为小组之间的关联;教师对某门课程的指派则转化为教师注册。INE(全国学生标识号)或教职工标识等标识符放在用户的 userIds 中。
标识符与隐私
每个对外开放的实体都带有一个稳定的标识符 sourcedId。
- 结构性标识符(机构、学年、教学科目、班级、小组)稳定,在各次导出之间保持不变:使用方可以据此跨时间关联数据。
- 用户标识符经过匿名化:Omniscol从不把自己的实名标识放到传输中。传输中使用的令牌由账户专属的单向函数(HMAC)派生;注册和归属关系复用该令牌,但从不暴露原始标识。
状态
- 生产方——可用,且无需远程合作方即可演示(导出可独立完成)。Rostering 1.2和OR-Groups层均以只读方式提供,并采用OAuth2认证。
- 使用方——导入配置属于Premium同步的一部分。与SIS的实时同步能否上线,取决于提供方,必要时还取决于教育主管部门的时间安排:需按需逐个连接器确定。这不是可以立即使用的开箱即用同步。