Status: Entwurf. Kommentare, Ergänzungen, Kritik bitte in diesem Google-Dokument. |
Mit der Empfehlung einer Visitenkarte für OER-Services sollen Lerninhalte-Services besser auffindbar und nutzbar werden, bspw. innerhalb einer vernetzten Infrastruktur. Lerninhalte, insbesondere freie, sogenannte OER, sollen über die Grenzen von Organisationen und Ländern hinweg kooperativer erstellbar, nutzbar und verwaltbar werden.
Dieses Dokument empfiehlt die Implementierung elektronischer Visitenkarten an
Services, die eine Funktionalität zur Editierung, Verwaltung oder Nutzung von Lerninhalten bereitstellen, inklusive Services die zum Betrieb einer vernetzten Infrastruktur nötig sind.
Die Initiative für diese Harmonisierung entstand in Kooperationen von IT-Expert*innen im BMBF-Förderprogramm OERinfo. Dieses Video gibt in 4 Minuten einen Überblick zu von Expert*innen empfohlenen Infrastrukturentwicklungen:
Damit Quellen mit OER u.a. Inhalten von anderen Infrastrukturkomponenten gefunden und genutzt werden können, braucht es ein zentrales Adressbuch. Aus dem gleichen Grund sollten bei diesem Adressbuch auch Tools für Nutzer*innen (z.B. OER-Editoren) und Services für Softwaresysteme (z.B. Metadaten-Mapping) registriert werden.
Auf diesen registrierten Services, Tools und Quellen können dann lokale Funktionen von Lernplattformen oder Autorentools oder zentrale Funktionen oder Services, wie ein Suchservice oder ein Statistikservice aufbauen.
Wie eine OER-Quelle sich beim Adressbuch registrieren kann, um daraufhin von einem zentralen Statistikservice für eine zusammengefasste Deutschland-Statistik genutzt werden kann, zeigt ein Beispiel.
Eine Infrastruktur zum Austausch und zur Kooperation an Lerninhalten besteht aus verteilten Applikationen, in denen Nutzer*innen Contents nutzen oder mit denen sie Contents erstellen. Diese Applikationen greifen über das Netzwerk auf Contentquellen zu, die entweder nur die Metadaten oder auch die Contents selbst bereitstellen. Gleichzeitig können die Applikationen selbst auch Contentquelle im Netzwerk sein und jene Inhalte anbieten, welche Nutzer*innen in der Applikation erstellt oder hochgeladen haben. Zuletzt braucht ein Netzwerk noch einige unterstützende Services, die einerseits in für Applikationen hilfreiche Funktionalitäten für Nutzer*innen bereitstellen und andererseits Services, die den Betrieb des Netzwerkes, also nicht Nutzer*innen sondern Maschinen unterstützen. Nachfolgend einige Beispiele:
A) Applikationen | B) Content-Quellen | C) unterstützende (de)zentrale Services | |
für Lehrende, Lernende, Autor*innen | Lernplattform, Lern- u. Autorentool der eigenen Organisation Externe im Netzwerk nutzbare Autoren- und Lerntools, auch externe Lernplattformen, die ihr fremdes Kursformat abspielen Systeme zur Verwaltung eigener Inhalte, zum teilen, kooperieren, bspw. Cloudspeicher, OER-Repositorien (diese wären ggf. gleichzeitig “Contentquellen” s. Spalte B) | externe Lern- und Autorenplattformen, die OER bereitstellen Typische Contentquellen, wie Pixabay, Youtube, Wikimedia, Wikipedia. (OER-)Repositorien, -Referatorien (auch Sammelknoten) mit Funktionen zum Sammeln, Kuratieren und Veröffentlichen/Verbreiten von Lerninhalten und Kollektionen | OER-Such- und Vorschlags-Funktionen Lizenzhinweisgenerator OER-Veröffentlichung Lizenzierungs-Assistent (Lizenzeditor, Lizenzkompatibilitäts- Check, etc.) Suche von Mitwirkenden Kooperation, Workflows Qualitätssicherung, Voting, Kommentare |
für Redaktionen und Netzwerk- Verwaltung | |||
für Maschinen | Applikationen brauchen maschinenlesbare Schnittstellen für: Metadatenaustausch Export oder Abspielservice für ihre Contentformate ggf. für die Nutzung der Applikation als Service für andere Bildungseinrichtungen eine Visitenkarte für die Registrierung im Netzwerk | Applikationen brauchen maschinenlesbare Schnittstellen für: Metadatenaustausch Export oder Abspielservice für ihre Contentformate Registrierung beim zentralen Adressbuch- und Statistikservices | zentrale Regristrierung für Services, Applikationen und Contentquellen Metadatengeneratoren, KI-Bilderkennung, Audio, Video Metadaten-Mapping Metadaten- Sammelknoten und Verteiler |
Beispiele: LearningApps, ZUM-Wiki
Eine originäre Contentquelle sind Plattformen, auf denen Inhalte originär erstellt oder hochgeladen werden. Damit die Inhalte via Google auffindbar sind,
Um in einem organisations- und landesübergreifenden Contentnetzwerk eigene Inhalte anzubieten, sollte der Betreiber:
Die Umsetzung des Punktes a) und b) der hier empfohlenen Visitenkarte sowie die Registrierung beim vorläufigen zentralen Adressbuchservice sind die ersten Schritte, um eine Nutzung eigener Inhalte als Quelle zu verbessern.
Beispiel: ILIAS, OLAT, OPAL, StudIP
Eine Lernplattform ist ebenso eine mögliche originäre Contentquelle. Daher empfehlen wir die Punkte in Abschnitt 1.3.1.
Zusätzlich sind Lernplattformen i.d.R. in Bildungsorganisationen implementiert, wo zentral Contents gesammelt und bereitgestellt werden. Neben klassischen Bibliotheken sind dies auch zentrale Referatorien oder Repositorien, wo Lerninhalte gesammelt, ggf. kuratiert und für angeschlossene Applikationen bereitgestellt werden. Solche Repositorien bieten Schnittstellen oder Plugins an, um die Inhalte innerhalb der Lernplattform suchen und einbetten zu können.
Betreiber von Lernplattformen sollten daher prüfen, ob lokal Repositoren oder Referatorien verfügbar sind, die via Plugin eine Anbindung erlauben.
Sollte dies nicht der Fall sein, können Lernplattformen externe Inhalte über eigene Schnittstellen erschließen, d.h. direkt Contentquellen anbinden. Hier sollen zentrale Adressbücher künftig helfen, Quellen zu finden und standardisiert abzufragen.
Beispiel: ZOERR Baden-Württemberg, OER@RLP in Rheinland-Pfalz
Lokale Repositorien sollten über Schnittstellen oder Plugins mit Lernplattformen u.a. Applikationen, wo Nutzer Lerninhalte erstellen oder hochladen, verbunden sein. Idealerweise werden die entstehenden Inhalte mit dem Repositorium verwaltet, weil hier auf Inhalteverwaltung spezialisierte Funktionen zur Verfügung stehen. Ist dies nicht möglich oder sinnvoll, sollten zumindest die Metadaten der dezentral liegenden Inhalte zentral erschlossen werden, um sie gebündelt anderen Ländern oder Organisationen anbieten zu können.
Beispiel: OMEGA Rheinland-Pfalz
Bildungsserver erschließen Inhalte aus externen Quellen, ähnlich einer Bibliothek für Lerninhalte. Der eigenen Zielgruppe wird i.d.R. eine Portaloberfläche angeboten, wo die Inhalte such- und anzeigbar sind.
Externe Inhalte werden über Schnittstellen erschlossen, d.h. es werden entweder Contentquellen direkt angebunden oder es werden vorhandene Referatorien angebunden, die ihrerseits Inhalte aus Quellen erschließen. Hier sollen zentrale Adressbücher künftig helfen, Quellen und Referatorien zu finden und standardisiert zu erschließen.
Beispiel in DE gesucht
Fachgesellschaften oder Fachbibliotheken können Referatorien nutzen, um Inhalte zu erschließen. Der Use-Case ist dem von 1.3.4 sehr ähnlich, nur dass häufig fachspezifische Metadaten gewünscht sind. Referatorienbetreiber sollten auf die allgemeinen Metadatenstandards aufbauen und fachspezifisches modular ergänzen. Außerdem sollten sie Mappingservices anbieten oder vorhandene Mappingservices empfehlen, damit abfragende nicht fachspezifische Systeme die fachspezifischen Metadaten innerhalb der allgemeinen Metadatenfelder finden und nutzen können.
