← Zurück zu Liora
AgentLiora

Skill · Version 1.0.0

Lernwerkzeuge verbinden

Verbindet Lernplattformen, Prüfungswerkzeuge und Teilnehmerlisten über gemeinsame Standards, damit Daten konsistent ausgetauscht werden können.

learning-interoperability

Entdecke, wie der Skill hilft

Wann ist der Skill hilfreich?

Dieser Skill unterstützt die Verbindung einer Lernplattform mit externen Lernwerkzeugen, Fragenbanken oder Teilnehmerverwaltung. Er prüft zuerst die tatsächlich unterstützten Versionen von LTI, QTI oder OneRoster.

Wobei hilft er dir?

  • Ordnet Nutzer, Kurse, Einschreibungen und Noten zwischen Systemen zu, ohne Identitäten oder Organisationen zu vermischen.
  • Prüft sichere Werkzeugstarts und meldet beim Import von Aufgaben ausdrücklich nicht unterstützte Fragetypen.
  • Plant die Synchronisierung von Teilnehmerlisten und Noten so, dass Unterbrechungen und doppelte Ereignisse korrekte Lernverläufe erhalten.

Das könntest du fragen

Prüfe, ob unser LMS ein externes Lernwerkzeug per LTI starten und Noten empfangen kann. Nenne unterstützte Versionen, erforderliche Rechte und Tests für doppelte Notenmeldungen. Wiederhole ein Bewertungsereignis nach einer Kurslistenänderung. Prüfe Lernenden- und Kurszuordnung; eine neuere Note darf nicht durch alte Daten ersetzt werden.

Ausführliche Dokumentation

Hier findest du die ursprüngliche Anleitung, Beispiele und Prüfschritte des Skills in ihrer Originalsprache.

Details…Weniger anzeigen

Learning interoperability

When to use

When an LMS exchanges launches, assessment content, grades or rosters with another product. Identify the exact standard and vendor implementation before designing the integration; supporting one LTI service does not imply support for QTI or roster synchronization.

Workflow

  1. Inspect both installed products, versions, plugins, configuration and available API metadata. Build a compatibility table listing the exact LTI, QTI or OneRoster version/profile, optional services, transport, authentication, requested scopes and implemented subsets on each side. Resolve gaps using the relevant 1EdTech specification and vendor documentation for those releases; do not infer compatibility from a product logo.
  2. Define stable, tenant-scoped mappings for users, organizations, courses/classes, enrolments, activities and grade items. Record the source of truth for each field. A remote user ID or email is not permission to link to a local account or another organization's learner; require the established account-linking and course-authorization flow.
  3. For an LTI integration, verify the chosen version's registration and launch contract. Where the profile uses OIDC and JWTs, validate issuer, audience/client, deployment, signature against trusted keys, expiry, nonce and state, and bind the launch context to the intended organization and course. Keep role claims scoped to that launch context. Use only approved endpoints and granted service scopes; check grade-service and roster-service capabilities independently of basic launch success.
  4. For QTI import/export, inspect supported item types, response processing, scoring, metadata, media and accessibility support at the exact version. Validate packages before import, restrict archive paths and external resource fetching, and preserve original item identifiers/version mappings. Return explicit unsupported-item diagnostics rather than dropping questions or changing their scoring silently. Compare a round trip against representative source items, including accommodations and partial credit when applicable.
  5. For roster exchange, establish the supported OneRoster version and CSV or REST profile, stable source identifiers, pagination, term boundaries and delta/deletion semantics. Decide whether an absent record means unchanged, inactive or removed; do not treat an incomplete page or failed export as a full roster replacement. Apply enrolment changes through the LMS's access policy without erasing attempts or certificates.
  6. Make grade and roster writes idempotent and reconcile against authoritative records. Handle duplicates, revoked access, rate limits and delayed results. After a timeout with an unknown write outcome, inspect the remote state using the operation's stable identity before retrying. Keep a bounded recovery queue with visible failures instead of repeatedly applying uncertain updates.

Evidence and verification

Deliver the compatibility table, permission/scopes map, field ownership map and a minimal integration proof against the specified versions. Test a valid launch plus wrong issuer/deployment and replay rejection; unsupported QTI content; a paginated roster interrupted midway; duplicate grade delivery; and a learner whose enrolment was revoked before a delayed event arrived.

Separate schema validation, a passing vendor sandbox test, production verification and formal certification. A successful sample launch or import is not evidence of complete standards conformance. Claim certification only when a verifiable certification record covers the exact product, version and profile.

Boundaries

  • Do not request broad roster or grade-write scopes just because an integration key allows them.
  • Do not change production registrations, enrolments or grades without authorization for that operation. Local implementation and test fixtures do not imply permission to enroll real learners.
  • Do not assume LTI, QTI, OneRoster, SCORM and xAPI are interchangeable. Use the actual requested contract and state unsupported requirements clearly.

Primary reference

Select and verify the exact versioned specification from the standards index:

Enthaltene Dateien 1

  • SKILL.md