# Projekt: Werkzeuge und Verfahren zur Standardisierung von OER-Metadaten im deutschsprachigen Raum

## Zum Zustandekommen des Projekts

Am 25. Juni fand in Marburg der Workshop „Interoperabilität bei der Digitalisierung in der Hochschullehre“ der KMK-AG „Digitalisierung im Hochschulbereich“ statt. Dort schlugen Vertreter\*innen aus NRW, Baden-Würtemberg und Rheinland-Pfalz vor, einen Fokus auf gemeinsame Standards für Metadaten zu legen. Dr. Stefan Drees, Vertreter des Landes Nordrhein-Westfalen, stellte eine baldige Finanzierung in Aussicht, um auf diesem Gebiet die Entwicklung zu unterstützen.

## Problemstellung

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 – 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 derzeit 67 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.

Bisher wird das Potential der Gruppe nicht optimal ausgeschöpft. Ein Hauptgrund ist, dass die Arbeitsweise der OER-Metadatengruppe verbesserungsfähig ist. Zwar sind Dokumente und Protokolle offen zugänglich, für interessierte potentielle Neueinsteiger\*innen ist es aber schwierig, einen Überblick über die geleisteten, gegenwärtigen und zukünftigen Arbeiten der Gruppe zu bekommen. So gibt es viele verschiedene Google-Drive-Dokumente – teilweise sehr umfangreich – und dazu Inhalte im Wiki, auf der Mailingliste und auf GitHub. Diese Arbeitsweise mag bei einer kleinen Anzahl aktiver Mitglieder ausgereicht haben, allerdings steht sie einer Integration weiterer Mitglieder im Weg.

In Anbetracht des steigenden Interesses am Thema und der wachsenden Anzahl von Menschen, die sich damit beschäftigen, muss also die Arbeitsweise der Gruppe angepasst werden. Nur so kann der Anspruch gewahrt bleiben, kontinuierlich eine zentrale Anlaufstelle für alle im deutschsprachigen Raum an OER-Metadatenstandards Interessierten zu bieten.

## Lösungsansätze

Die wichtigsten Desiderate zur Optimierung der Standardisierungsprozesse in der OER-Metadatengruppe sind die folgenden:

1. **Professionelle Erstellung und Publikation gemeinsamer Standards**
Für den Aufbau einer vernetzten, interoperablen Infrastruktur sind gemeinsame Standards in den deutschen Bundesländern und darüber hinaus ein wesentlicher Erfolgsfaktor. Damit diese Standards anerkannt sind, ist eine professionelle Publikationsumgebung und ein ebensolcher Erstellungsprozess unumgänglich. Dabei lässt sich von Standardisierungsgremien im Bereich Metadaten und/oder Web einiges lernen, z. B. vom World Wide Web Consortium (W3C) oder der Dublin Core Metadata Initiative (DCMI).

1. **Einstiegshürden potentieller Teilnehmer\*innen minimieren**
Mit Blick auf potentielle Teilnehmer\*innen an der Standardentwicklung soll ein schneller Überblick über die geleisteten, gegenwärtigen und zukünftigen Aktivitäten der Gruppe agegeben werden und ein einfacher Einstieg zur Beteiligung an der Standardentwicklung ermöglicht werden.

Dieses Projekt wird sich auf die erste Aufgabe fokussieren und damit aber auch einiges zur zweiten Aufgabe beitragen. Das Projekt flankierend müssen in der OER-Metadatengruppe aber weitere Dinge erledigt werden, z. B. das Gruppen-Wiki neu und übersichtlich zu strukturieren.

## Projektziel

**Zur professionellen Entwicklung von Metadatenstandards sind die Prozesse definiert und die nötigen Werkzeuge stehen zur Verfügung.**

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

Zum Ende des Projekts werden also die Werkzeuge bereitstehen und Prozesse definiert sein, die zur professionellen Entwicklung gemeinsamer Metadatenstandards ("Empfehlungen") nötig sind. Dabei werden sich Tools und Prozesse unterscheiden für

1. Standardisierung von Metadatenschemata
2. Standardisierung kontrollierter Vokabulare

## Arbeitspakete

### AP1: Evaluation, Auswahl und Anpassung von Spec-Präprozessoren

Geschätzter Arbeitsaufwand: 5 Tage

Bekannte Präprozessoren zur Publikation von Spezifikationen im Web via GitHub/GitLab Pages, wie z.B. [respec](https://github.com/w3c/respec) oder [bikeshed](https://github.com/tabatkins/bikeshed) werden evaluiert und an die Bedürfnisse der Gruppe angepasst.

Orientierung an https://github.com/reconciliation-api/specs (bzw. https://github.com/reconciliation-api/specs/commit/6b5985df4e37bd45bb50dd2dcda80b9c7014f561), das ReSpec mit dem `ajv` schema validator verwendet.

### AP2: Definition des Prozesses zur Spezifikation von Metadatenschemas

Geschätzter Arbeitsaufwand: 2 Tage

Bestandteile der fertigen Spezifikation eines Metadatenschemas sollen sein:

- ein HTML-Standard-Dokument mit allgemeinen Informationen und Dokumentation anhand eines annotierten Beispiels (siehe die [prototypische Umsetzung mit GitHub Pages Theme](https://dini-ag-kim.github.io/oer-metadata-schemas/service-card.html) und die Vorarbeit unter https://docs.google.com/document/d/15maQjLpDdrhQArKvAcmz11LpdB77L9JAC_9JOhV7l98/edit#heading=h.389kpof6h5n)
- Extra Pflege bei hypothes.is (Automatisierung von Updates möglich? Prüfung hypothes.is API) oder Integration in Schema-Generierung?
- ein Schema zur Validierung von Metadatensätzen (JSON Schema – wie im SkoHub-Editor oder Erweiterung durch Nutzung von ShEx/Shacl)
- ein Editor, der auf dem Schema basiert (Nutzung des skohub-editors)

Der Prozess, um zu diesem Ergebnis zu gelangen, muss definiert werden, vgl. das W3C-Prozessdokument (https://www.w3.org/2019/Process-20190301/) und den IETF-Prozess (https://www.ietf.org/standards/process/). Fragen dazu sind u. a.:

- Wer kann am Prozess teilnehmen? -> Die Gruppe ist offen für alle Interessierten.
- Wie wird entschieden, woran gearbeitet wird und in welchem Zeitraum?
- Welche Rollen gibt es?
- Welche Art von Treffen (physisch und virtuell) gibt es und wie häufig? (vgl. https://www.w3.org/2019/Process-20190301/#GeneralMeetings)
- Wie sind die Einladungsmodalitäten?
- Was findet auf der Mailingliste, was im Wiki, was auf GitHub statt?
- Wie werden Entscheidungen bei konkurrierenden Standardisierungsvorschlägen getroffen? Inwieweit gilt das Konsensprinzip? vgl. https://www.w3.org/2019/Process-20190301/#Votes
- Wie lange muss ein Spezifikationskandidat zum Kommentieren veröffentlicht sein, bevor die Spezifikation veröffentlicht wird?

### AP3: Definition des Prozesses zur Spezifikation von kontrollierten Vokabularen

Geschätzter Aufwand: 2 Tage

Bestandteile der fertigen Spezifikation eines kontrollierten Vokabulars sollen sein:

- Eine SKOS-Datei als Basis
- Eine HTML-Seite mit allgemeiner Beschreibung des Vokabulars und Anwendungsfällen sowie hierarchischer Darstellung und Filterfunktion
- Eine Web-API zum Lookup von Elementen des Vokabulars

Siehe die Fragen im vorherigen Abschnitt.

SkoHub Vocabs: http://blog.lobid.org/2019/09/27/presenting-skohub-vocabs.html

### AP4: Verfassen einer SKOS-Einführung

Geschätzter Aufwand: 4 Tage

Ein wesentlicher Aspekt zur erfolgreichen Standardisierung von OER-Metadaten ist die breite Nutzung der SKOS-Beschreibungssprache für kontrollierte Vokabulare (SKOS = Simple Knowledge Organization System). Da es dafür bisher – weder auf Englisch noch auf Deutsch – keine gute Einführung gibt, soll eine solche erstellt werden.

Angefangener Blogbeitrag: https://github.com/lobid/lobid.github.com/blob/skohub-ssg/_posts/2019-07-30-skohub-ssg.md

## Projektpartner "Open Culture Consulting"

Zur Umsetzung dieses Projekts wird die Sebastian Meyer & Felix Lohmeier GbR – Open Culture Consulting beauftragt. Das Unternehmen bringt die idealen Voraussetzungen für die Umsetzung dieses Projekts mit:

- Langjährige Erfahrungen in den Bereichen Metadaten, Normdaten und Standards
- Kenntnisse in der Informationsvermittlung und Prozessdokumentation
- Langfristiges Engagement im Bereich Openness (Open Source, Open Data)
- Commitment zu transparenten und offenen Prozessen und Einsatz entsprechender Werkzeuge

Sebastian Meyer ist studierter Informatiker und halbtags als Stabsstelle Digitale Bibliothek an der SLUB Dresden beschäftigt. Er ist Hauptentwickler von Kitodo.Presentation und der Referenzimplementierung des DFG-Viewers sowie seit 2011 Release Manager für die Kitodo Software Suite. Erfahrungen in der Standardisierung hat er unter anderem als Moderator der DINI AG KIM Gruppe Digitalisierungsmetadaten gesammelt.

Felix Lohmeier bringt Erfahrungen aus seinen früheren Tätigkeiten als Leiter der IT-Abteilungen an der SLUB Dresden und der SUB Hamburg mit ein. Erfahrungen in der Informationsvermittlung und Prozessdokumentation hat er als Gastdozent an der HAW Hamburg, HSH Hannover und HTW Chur sowie als Leiter des Referats Informationsservice an der SLUB Dresden gewonnen. Seit 2014 propagiert er Openness als Leitbild für Bibliotheken und ist dazu an Community-Initiativen wie Open Library Badge beteiligt.

Die beiden Gesellschafter von Open Culture Consulting werden die Arbeitspakete in enger Absprache mit dem hbz bearbeiten.

### Sonstiges / Ideen / Fragen

- Welche Domain für die Specs? github.io? dini.de? kim-forum.org
- Wiki entschlacken und übersichtlich machen: https://wiki.dnb.de/display/DINIAGKIM/OER-Metadaten-Gruppe
- Prozesse AP2 und AP3 auch visualisieren mit Flowcharts?
- Einführung SKOS AP4 wie lobid.org Dokumentation beispielorientiert, vielleicht sogar interaktiv (wie bei Coding-Lernplattformen)?
- Für AP2 und AP3 Berücksichtigung der bisherigen Erfahrungen durch Vorgespräche mit AG-Mitgliedern? Dann ggf. jeweils +1 Tag.
- eher frühzeitige Ankündigung und teilen von Entwürfen plus ein bis zwei Telefonkonferenzen
- Schema-Entwicklung mit validierenden und nicht-validierenden Testdateien, siehe https://git.io/Jenjj
- User Stories für Metadatenelemente und SKOS-Konzepte, um sicherzustellen, dass aus Nutzerperspektive entwickelt wird. Am besten in Rückkopplung mit tatsächlichen Endnutzer\*innen
- Sprache (Standard englisch, Prozessbeschreibung deutsch)?