Werkzeuge und Verfahren zur Standardisierung von OER-Metadaten. https://dini-ag-kim.github.io/oer-stoeberspecs/
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Adrian 09b92dd784
Fix formatting
5 months ago
ReSpec Fix typos 10 months ago
README.md Fix formatting 5 months ago

README.md

OER-StöberSpecs

Werkzeuge und Verfahren zur Standardisierung von OER-Metadaten

Ausgestattet mit Fördermitteln von Bund und Ländern beschäftigen sich immer mehr Akteure und Projekte mit dem Aufbau von Infrastrukturen zur Erstellung, Publikation und zum Teilen von 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, seit neuestem auch in der im Aufbau befindlichen KMK-Arbeitsgruppe OER-Repositorien. 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.

Die Mailingliste der OER-Metadatengruppe hat Mitglieder überwiegend aus Deutschland aber auch aus Österreich und der Schweiz. Innerhalb der Arbeitsgruppe gibt es kontinuierlichen Austausch zu den Entwicklungen im Bereich OER-Metadaten, diverse Konzepte wurden erstellt und prototypisch in der Praxis angewendet, ein fortgeschrittener Entwurf für die strukturierte Beschreibung von OER-Diensten (Repositorien, Referatorien, Autorenwerkzeugen etc.) liegt vor.

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.

Werkzeuge

Im Hinblick auf die Werkzeuge werden vorzugsweise existierende Tools benutzt, die gegebenenfalls an die spezifischen Bedingungen angepasst werden.

Spezifikationen, Standards, Empfehlungen

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 entweder als eine einzige Datei oder jeder Abschnitt in einer eigenen Datei gepflegt werden (siehe die untenstehenden Beispiele). ReSpec bereitet diese Dokumente automatisch für die Web-Publikation auf, in dem 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 kann entweder eine bestehende Spezifikation als Vorlage kopiert oder das Blanko-Dokument verwendet werden.

Versionierung

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. Zur niedrigschwelligen Kommentierung empfiehlt es sich, den Annotationsdienst hypothes.is einzubinden.

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.

Beispiele

Vokabulare, Ontologien

Auch Vokabulare und Ontologien 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 der Ontologie mit weitergehenden Möglichkeiten wie einer Suchfunktion (siehe Beispiele).

Einführung in SKOS

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)

Beispiele

Kommunikation

Zur Kommunikation wird neben gelegentlichen Präsenztreffen und Videokonferenzen vor allem eine Mailingliste verwendet. Diese ist öffentlich und kann 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 Annotationsmöglichkeiten versehen werden. Empfohlen wird neben der Verwendung der regulären GitHub-Werkzeuge wie Issues auch die Einbindung des niedrigschwelligen Dienstes hypothes.is.

Organisation der Arbeitsprozesse

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.

Maintainer

Um die Pflege der Standards, Spezifikationen, Empfehlungen und Vokabulare auf GitHub zu ermöglichen, benötigt jedes Dokument mindestens einen sogenannten Maintainer. 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 entscheidet letztlich auch über den Zeitpunkt der Publikation einer neuen Version des betreffenden Dokuments, führt die entsprechenden strukturellen Änderungen im GitHub-Repository durch und verantwortet die Endredaktion.

Änderungsvorschläge in Pull Requests & Annotationen

Um die Arbeit des oder der Maintainer 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 den oder die Maintainer übernommen werden. Als niedrigschwelligere Variante können Vorschläge auch – wie oben erwähnt – am Entwurf mit Hilfe des Annotationsdiensts hypothes.is ergänzt werden. Diese können dort diskutiert und zu gegebenem Zeitpunkt vom Maintainer in einen Pull Request überführt werden.

Wichtig ist, dass Pull Requests 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 Mail an eine/n Maintainer geschickt werden, der diese dann jedoch wiederum als Pull Request auf GitHub dokumentieren sollte.

Wiki

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).