Ausgestattet mit Fördermitteln von Bund und Ländern beschäftigen sich immer mehr Akteure und Projekte im Schul- und Hochschulbereich mit dem Aufbau von Infrastrukturen zur Erstellung, Publikation und zum Teilen von Bildungsmaterialien, insbesondere Open Educational Resources (OER). Innerhalb einer solchen Infrastruktur spielen Metadaten – strukturierte Beschreibungen, die Informationen über bestimmte Merkmale der beschriebenen Dinge erfassen – eine zentrale Rolle.
Dementsprechend stellt sich derzeit in verschiedenen Kontexten die Frage, wie OER mit Metadaten versehen werden sollten. Damit keine Parallelarbeiten stattfinden und vor allen damit die Anwendungen möglichst qualitative und homogene Metadaten aufweisen – etwa zum Zwecke der Zusammenführung und des Aufbaus übergreifender Recherchedienste – ist eine gemeinsame, fortdauernde, nachhaltige Entwicklung und Pflege von Metadatenstandards geboten.
Als ein überinstitutioneller, institutions- und projektunabhängiger Rahmen für Diskussion sowie Entwicklung und Pflege zukunftsfähiger Metadatenstandards im deutschsprachigen Raum hatte sich bereits 2013 – initiiert durch das hbz NRW – eine OER-Metadatengruppe innerhalb des Kompetenzzentrums Interoperable Metadaten (KIM) der Deutschen Initiative für Netzwerkinformation (DINI) gebildet. 2017 fusionierte diese Gruppe mit der OER-Metadatengruppe von Jointly. Anfang 2021 entstand aus der OER-Metadatengruppe heraus die Curricula-Gruppe, deren Fokus auf der interoperablen strukturierten Beschreibung von Curricula im Bildungsbereich liegt.
Die Mailinglisten der OER-Metadatengruppe und der Curricula-Gruppe haben Mitglieder überwiegend aus Deutschland, aber auch aus Österreich und der Schweiz. Innerhalb der Arbeitsgruppen gibt es kontinuierlichen Austausch zu den Entwicklungen im Bereich OER-Metadaten und Curricula, monatliche Treffen finden statt. Verschiedene Spezifikationen wurden bereits publiziert, andere finden sich in Arbeit.
In Anbetracht des steigenden Interesses am Thema und der wachsenden Anzahl von Menschen, die sich damit beschäftigen, soll die Arbeitsweise der Gruppe möglichst öffentlich, transparent und partizipativ gestaltet werden. Nur so kann der Anspruch gewahrt bleiben, kontinuierlich eine zentrale Anlaufstelle für alle im deutschsprachigen Raum an OER-Metadatenstandards Interessierten zu bieten.
Im Hinblick auf die Werkzeuge werden vorzugsweise existierende Tools benutzt, die gegebenenfalls an die spezifischen Bedingungen angepasst wurden.
Dokumente mit offiziellem Charakter wie Spezifikationen, technische Standards und Empfehlungen werden als HTML/Markdown-Dokument verfasst und mit Hilfe eines speziellen DINI-Profils des ReSpec-Präprozessors des W3C im Web publiziert. Die Quelldaten des Dokuments werden dabei auf GitHub abgelegt, wo sie automatisch versioniert und mit einer nachvollziehbaren Änderungshistorie versehen werden. Zur Publikation kann zudem GitHub Pages verwendet werden, das lediglich in den Einstellungen des GitHub-Repositories aktiviert werden muss.
Durch die Verwendung von ReSpec können die Dokumente mit einer Mischung aus HTML und Markdown gepflegt werden. ReSpec bereitet die Dokumente automatisch für die Web-Publikation auf, indem es etwa Inhaltsverzeichnisse erstellt, Querverweise einfügt, bibliografische Referenzen nachweist und Abkürzungen auflöst. Dazu müssen lediglich einige wenige Angaben zur Konfiguration von ReSpec gemacht werden sowie ein paar Konventionen in der Strukturierung und dem Markup eingehalten werden. Für neue Spezifikationen sollte am besten eine bereits publizierte Spezifikation als Vorlage verwendet werden.
Für jede Spezifikation, Standard oder Empfehlung sollte ein eigenes GitHub-Repository angelegt werden. In diesem sollte sich in einem Verzeichnis draft die aktuelle Entwurfsfassung des Dokuments befinden, die kommentiert werden kann.
Jede publizierte Version des Dokuments sollte in einem eigenen Verzeichnis abgelegt werden, das nach der jeweiligen Versionsbezeichnung benannt ist. Es empfiehlt sich, die Versionen etwa nach ihrem Veröffentlichungsdatum zu benennen (z. B. 20200131).
Ein symbolischer Link latest sollte zudem immer auf die neueste publizierte Fassung verweisen. Er dient als Referenz für Verweise auf die Spezifikation, wenn dabei nicht eine konkrete Version, sondern die jeweils gültige Fassung gemeint ist.
- Allgemeines Metadatenprofil für Bildungsressourcen (AMB)
- LOM for Higher Education OER Repositories
- Blanko-Vorlage für neue Spezifikationen
Auch kontrollierte Vokabulare – von einfachen Wertelisten bis zu mehrstufigen Klassifikationen – werden auf GitHub in einem eigenen Repository abgelegt und dort versioniert und gepflegt. Als Format sollte das Simple Knowledge Organization System (SKOS) verwendet werden, wobei die Kodierung idealerweise in Turtle-Syntax erfolgen sollte. Die Publikation erfolgt anschließend mit SkoHub-Vocabs, einer grafischen Präsentation des Vokabulars mit weitergehenden Möglichkeiten wie einer Suchfunktion (siehe Beispiele).
Die folgende Einführung enthält auch ein Tutorial zur Erstellung und Veröffentlichung eines SKOS-Vokabulars.
- Einführung in SKOS für den Bereich Open Educational Resources (OER)
- SKOS-Version der Destatis-Systematik der Fächergruppen, Studienbereiche und Studienfächer
- Hochschulcampus Ressourcentypen (HCRT), eine Werteliste für Typen von Lernressourcen
Zur Kommunikation wird neben gelegentlichen Präsenztreffen und monatlichen Videokonferenzen vor allem die Mailingliste der jeweiligen Gruppe verwendet. Die Listen sind öffentlich und können so von jeder/m Interessierten abonniert werden.
Die Arbeit an konkreten Spezifikationen und Standards erfolgt zusätzlich über die direkte Kommentierung der jeweiligen Entwurfsfassung (siehe oben). Diese sollte daher immer im Web publiziert werden und mit Möglichkeiten der Kommentierung versehen werden. Dazu werden die regulären GitHub-Werkzeuge wie Issues verwendet. Kommentare in den Treffen, per Mailingliste oder Forum sollen auch berücksichtigt werden.
Vorlage für den hier beschriebenen Prozess ist der Workflow des W3C, der jedoch aufgrund der überschaubareren Strukturen der OER-Metadatengruppe der DINI AG KIM deutlich vereinfacht wurde.
Um die Pflege der Standards, Spezifikationen, Empfehlungen und Vokabulare auf GitHub zu ermöglichen, benötigt jedes Dokument mindestens eine*n sogenannten Maintainer*in. Diese Person oder Personengruppe verfügt über die notwendigen Berechtigungen, Änderungen am jeweiligen GitHub-Repository vorzunehmen. Außerdem obliegt ihr die Verantwortung, den Arbeitsprozess zu moderieren, d. h. etwa Fristen für die Kommentierung eines Entwurfs festzulegen, notwendige Abstimmungen durchzuführen oder bei Bedarf zusätzliche Kommunikationsmittel einzubeziehen (siehe oben).
Der oder die Maintainer*innen entscheiden letztlich auch über den Zeitpunkt der Publikation einer neuen Version des betreffenden Dokuments, führen die entsprechenden strukturellen Änderungen im GitHub-Repository durch und verantworten die Endredaktion.
Um die Arbeit der Maintainer*innen so einfach wie möglich zu gestalten, sollten Änderungsvorschläge nach Möglichkeit immer in Form eines Pull Requests auf GitHub eingereicht werden. Auf diese Weise kann der Änderungsvorschlag öffentlich kommentiert, ggf. weiter verbessert und schließlich auf Knopfdruck durch die Maintainer*innen übernommen werden.
Wichtig ist, dass Pull Requests bei ReSpec immer nur Änderungen an der Entwurfsfassung im Verzeichnis draft beinhalten, da einmal publizierte Versionen nicht mehr substantiell geändert werden sollten. Ausnahmen stellen hier nur einfache Rechtschreibfehler oder ähnliches dar, die natürlich korrigiert werden dürfen.
Alternativ können Änderungsvorschläge natürlich auch auf herkömmlichem Weg etwa per Mailingliste an die Maintainer*innen geschickt werden, die diese dann jedoch wiederum als Pull Request auf GitHub dokumentieren sollten.
Für die Publikation einer neuen Version eines mit ReSpec publizierten Dokuments sind durch die Maintainer*innen folgende Schritte zu beachten:
- Einen neuen Ordner anlegen und die Inhalte des Draft-Ordners da reinkopieren (als eigener Commit, um die folgenden kleinen Änderungen gegenüber dem Drat dokumentiert zu haben)
- Den symbolischen Link aktualisieren (Linux:
ln -sfn yyyymmdd latest, Windows: etwas kniffelig, Google hilft). - In der neuen Version ein paar Änderungen vornehmen:
- In der ReSpec-Konfig ganz am Anfang das Release-Datum aktualisieren.
- In der ReSpec-Konfig ganz am Anfang den Status von "unofficial" auf "base" ändern.
- In der ReSpec-Konfig unter "otherLinks" den Link zur neuen Version ergänzen und die Auskommentierung entfernen.
- Falls die Spec auch vollständige Beispiele enthält, sollten die natürlich auch auf das Schema ihrer jeweiligen Version verweisen. Da müssen die Links in @schemaLocation also ggf. auch noch von "/draft/" auf das jeweilige Release geändert werden.
- Wenn ansonsten darauf geachtet wird, dass in der Spec nur relative Links verwendet werden, muss nichts weiter angepasst werden. Eventuell noch die neue Version in der README.md ergänzen, falls irgendjemand über die GitHub-Pages-Startseite kommt.
- Sobald die Publikation der neuen Version vollständig abgeschlossen ist, wird ein Git Tag für die Version vergeben sowie auf GitHub ein Release für diese Version angelegt (Beispiel).
Bei der Aktualisierung eines bestehenden SKOS-Vokabulars sind folgende Dinge zu beachten:
- Bereits publizierte URIs dürfen nicht gelöscht oder geändert werden.
- Veraltete SKOS-Konzepte werden als solche mit
owl:deprecated truemarkiert und – so vorhanden – mitdct:isReplacedByauf das Nachfolge-Konzept verlinkt.skos:broader- oderskos:narrower-Relationen der veralteten Konzepte sollen aber unangetastet bleiben. - Neue Versionen werden mit einem Git tag versehen und als GitHub Releases veröffentlicht.
Für jedes GitHub-Repository kann in den Einstellungen ein einfaches Wiki aktiviert werden. Dieses kann verwendet werden, um mit der Arbeit am jeweiligen Dokument in Verbindung stehende Dokumente zentral und öffentlich abzulegen (z. B. Protokolle von Videokonferenzen).