OneRoster (1.2 e gruppi avanzati)

OneRoster è uno standard internazionale di scambio di anagrafiche scolastiche (pubblicato da 1EdTech): descrive, in un formato comune, gli istituti, gli anni scolastici, i corsi, le classi, le iscrizioni e gli utenti di una scuola. Serve a collegare un SIS, un ambiente digitale di apprendimento o un LMS a un altro strumento senza reinserimento né formato proprietario.

Questa pagina si rivolge alla direzione dei sistemi informativi (l'IT) dell'istituto. Descrive ciò che Omniscol espone e consuma in OneRoster, l'autenticazione prevista e il perimetro reale di ciascun senso di scambio.

Versioni supportate

Omniscol supporta OneRoster 1.2 Rostering — la base (Org, AcademicSession, Course, Class, Enrollment, User, Demographics) — nonché il livello OR-Groups (Advanced Groups Service), lo standard di gruppi additivo che aggiunge tre entità (Group, GroupMembership, GroupAssociation) al di sopra della 1.2.

Il livello OR-Groups è uno standard in corso di pubblicazione. È strettamente additivo sulla 1.2: un Group si limita a fare riferimento alle entità Class / User / Org / AcademicSession della 1.2, in sola lettura. La versione 1.3 di OneRoster è annunciata per rendere Class una specializzazione di Group — orientamento verso cui l'implementazione di Omniscol converge già.

Omniscol produttore (Omniscol → ambiente digitale / LMS)

Come produttore, Omniscol espone l'anagrafica dell'istituto in sola lettura, tramite un'API REST conforme a OneRoster, affinché un ambiente digitale di apprendimento o un LMS la legga.

  • La base Rostering 1.2 è servita sotto /ims/oneroster/rostering/v1p2/… (ad esempio /orgs, /schools, /academicSessions, /courses, /classes, /enrollments, /users, /teachers, /students, /demographics, ciascuno con le sue varianti annidate).
  • Il livello gruppi è servito sotto /ims/oneroster/groups/v1p0/… (/groups, /groupMemberships, /groupAssociations e le loro varianti annidate).
  • Il perimetro è l'anno scolastico corrente per impostazione predefinita; un parametro consente di puntare a un altro anno o di coprire tutti gli anni.

I dati riflettono la pianificazione consolidata di Omniscol (orari attivi / pubblicati). Il produttore è in sola lettura per scelta: nessuna scrittura (PUT / DELETE) è esposta — un sistema remoto non guida la creazione o l'eliminazione di entità in Omniscol.

Autenticazione del produttore

Gli endpoint del produttore sono protetti da OAuth2 con flusso client_credentials (token da macchina a macchina, senza utente), emesso dal server OAuth2 di Omniscol. Non sono riservati agli account Premium: l'accesso è controllato dagli scope OAuth2, non dal piano. Ogni scope è specifico di un servizio e l'accesso ai dati demografici è compartimentato all'interno della 1.2:

Endpoint Scope accettati
Rostering 1.2 (esclusa la demografia) 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 (tutti) https://purl.imsglobal.org/spec/or-groups/v1p0/scope/roster-group.readonly

Un token OR-Groups non dà accesso alla base Rostering, e viceversa. Nessuno scope di scrittura è dichiarato. Gli scope privilegiati sono attribuiti dall'amministrazione Omniscol al momento della registrazione del client OAuth2; un client non può autoattribuirseli. La gestione dei client OAuth2 e dei token è descritta su OAuth2 / OIDC (provider) e API Omniscol.

Il perimetro degli studenti è portato dal livello gruppi

Scelta strutturante: l'elenco degli studenti di una classe o di un gruppo è esposto tramite OR-Groups (GroupMembership), non dalla sola base 1.2. Un consumatore che legge unicamente la Rostering 1.2 ottiene il catalogo (Courses, Classes), le iscrizioni professore → corso e l'anagrafica degli utenti, ma non l'appartenenza degli studenti. Per sapere chi è in quale classe o quale gruppo, il consumatore deve implementare il livello OR-Groups. Questa scelta riflette il modello francese: uno studente è iscritto in una classe o in un gruppo, non materia per materia.

Il produttore si espone in REST. Il formato bundle CSV OneRoster (archivio zip con un file per collezione), invece, è supportato lato importazione, per i fornitori che consegnano la loro anagrafica per file anziché per API — si veda la sezione consumatore di seguito.

Omniscol consumatore (SIS → Omniscol)

Importazione di un'anagrafica OneRoster (SIS → Omniscol): Omniscol può importare l'anagrafica di un SIS conforme a OneRoster — istituto, anni, corsi, classi, gruppi, utenti e dati demografici — tramite l'API REST del fornitore o un bundle CSV, e poi riconciliarla nell'istituto. Questa configurazione di consumo fa parte della sincronizzazione con sistemi esterni, disponibile sui conti Premium e concordata su progetto con il team Omniscol.

Come consumatore, Omniscol importa l'anagrafica di un SIS conforme a OneRoster e la riconcilia nell'istituto. Questa configurazione di consumo fa parte della sincronizzazione con sistemi esterni: è disponibile sui conti Premium e si concorda su progetto con il team Omniscol (si veda Sincronizzazione con sistemi esterni).

  • Trasporto — o l'API REST del fornitore (l'indirizzo di base è configurato, si segue la paginazione standard OneRoster), con autenticazione OAuth2 in flusso client_credentials verso il server del fornitore; oppure un bundle CSV (archivio zip).
  • Profilo — un profilo di configurazione indica l'ampiezza da leggere: sola base 1.2, livello gruppi o mappatura francese per l'istruzione scolastica. Un fornitore puramente 1.2, senza servizio di gruppi, si importa correttamente.
  • Applicazione controllata — l'importazione segue lo stesso principio degli altri connettori: Omniscol recupera e poi riconcilia i dati, e un amministratore convalida la loro applicazione all'istituto. Il sistema remoto non spinge mai direttamente in Omniscol.
  • Reimportazioni idempotenti — le corrispondenze di identificativi esterni sono conservate, cosicché una reimportazione non crea duplicati anche quando il fornitore rinomina un'etichetta.

Profilo francese (istruzione scolastica)

Il profilo francese per l'istruzione scolastica mette in corrispondenza le nozioni francesi con il modello OneRoster: una divisione (la classe in senso effettivo) diventa un Group di tipo organizzativo principale; un gruppo diventa un Group di erogazione didattica; un gruppo di gruppi un Group trasversale; le partizioni e gli allineamenti diventano associazioni di gruppi; un'assegnazione di un professore a un corso diventa un'iscrizione professore. Gli identificativi come l'INE o l'identificativo agente sono portati nei userIds dell'utente.

Identificativi e riservatezza

Ogni entità esposta porta un identificativo stabile, il sourcedId.

  • Gli identificativi strutturali (istituto, anno, corso, classe, gruppo) sono stabili e immutabili da un'esportazione all'altra: un consumatore può farvi affidamento per correlare i dati nel tempo.
  • L'identificativo dell'utente è anonimizzato: Omniscol non mette mai il proprio identificativo nominativo sul filo. Il token messo sul filo è derivato da una funzione a senso unico (HMAC) propria dell'account; le iscrizioni e le appartenenze riutilizzano questo token senza mai esporre l'identificativo di origine.

Stato

  • Produttore — disponibile e dimostrabile senza partner remoto (l'esportazione è autosufficiente). Rostering 1.2 e il livello OR-Groups sono serviti in sola lettura, con autenticazione OAuth2.
  • Consumatore — la configurazione di importazione fa parte della sincronizzazione Premium. La messa in servizio di una sincronizzazione in tempo reale con un SIS dipende dal fornitore e, se del caso, dai calendari ministeriali: si concorda su richiesta, connettore per connettore. Non si tratta di una sincronizzazione chiavi in mano immediata.

See also