Zum Ende der Metadaten springen
Zum Anfang der Metadaten
Icon

Status: Entwurf. Kommentare, Ergänzungen, Kritik bitte in diesem Google-Dokument.


1 Einleitung

 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

  1. Services, die als Quellen Lerninhalte anbieten,
  2. 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:

 


2 Zentrales Adressbuch

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.

3 Arten von Services in einem Contentnetzwerk

 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
in denen man OER nutzen, erstellen kann

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

 

Use Cases und Umsetzungsempfehlungen

4.1 Eine Contentquelle will seine Auffindbarkeit verbessern

 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,

  • müssen die Plattformbetreiber entsprechende Schnittstellen für Suchmaschinen anbieten (was Gegenstand einer anderen Harmonisierungsempfehlung sein wird)

Um in einem organisations- und landesübergreifenden Contentnetzwerk eigene Inhalte anzubieten, sollte der Betreiber:

  1. die in diesem Dokument empfohlene Visitenkarte implementieren
  2. die Metadaten der eigenen Inhalte über Schnittstellen anbieten, die ein harvesten ermöglichen (OAI-PMH, Resourcesync, Sitemaps)
  3. falls die Inhalte ein spezielles, nicht von anderen Systemen abspielbares Format haben, sollte der Anbieter einen Abspiel- oder auch Renderingservice anbieten.
  4. falls die Inhalte von Usern anderer Applikationen im Netzwerk mit der eigenen Applikation editierbar sein sollen, sollte die eigene Applikation als ##LTI-Tool angeboten werden

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.

4.2 Eine Lernplattform will eigene Inhalte als Quelle bereitstellen und externe Inhalte für eigene User nutzbar machen

 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.

4.3 Ein OER-Landes-Repository will die Inhalte aller LMS u.a. Plattformen des Landes erschließen

 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.

4.4 Ein Bildungsserver eines Bundeslandes will Inhalte für seine Bildungsorganisationen erschließen und für eigene Zielgruppen bereitstellen

 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.

4.5 Ein Referatory (Fachgesellschaft / Fachbibliothek) mit betreuendem Redaktionsteam erschließt thematisch Inhalte und stellt sie im Netzwerk zur Verfügung (Metadatensammelknoten)

 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.


  • Keine Stichwörter