Entwicklung eines Profils für OER-Metadaten mit JSON Schema & SkoHub

Adrian Pohl
Offene Infrastruktur, Hochschulbibliothekszentrum NRW (hbz)

KIM-Workshop, WWW, 4.5.2020

Diese Präsentation:
http://slides.lobid.org/kim-ws-2020/
Creative Commons License

Zur Person

Angestellt am hbz, arbeite vor allem an lobid und in letzter Zeit an SkoHub und OERSI (OER Search Index)

Moderator der OER-Metadatengruppe von KIM und Jointly

Fokus: Datenmodellierung, Web- und Metadatenstandards

Grüße an meine hbz-Kollegen (Pascal & Fabian) und an Felix Ostrowski (graphthinking GmbH). Danke für die tolle Zusammenarbeit!

Agenda

  1. Was ist ein Metadatenprofil?
  2. Ein LRMI-Profil für Hochschul-OER
  3. Entwicklungsprozess
  4. Fazit / Ausblick

Was ist ein Metadatenprofil?

Kontext

Vorschlag von Rachel Heery & Manjula Patel im Herbst 2000, seitdem zentrales Thema in der Dublin Core Metadata Initative (DCMI) und Verwendung in vielen anderen Kontexten

Auch "Profil", "Application Profile/Anwendungsprofil" oder "Community Profile" genannt

Aktuell Thema in der Dublin Core Application Profile Interest Group

Was macht ein Profil?

Gibt an welche existierenden Metadatenschemas (z.B. Dublin Core, schema.org) und welche Elemente und Typen daraus benutzt werden

Definiert Einschränkungen für die Nutzung des/der Schema(s)

z. B. Einschränkungen auf Felder (welche Felder, Pflichtfeld: ja/nein, Häufigkeit) oder Werte (Formatvorgaben, kontrollierte Vokabulare)

Quelle: Baker/Coyle (2019), Slide 4

Funktionen eines Profils

Dokumentation von Verabredungen einer Community

Zur Produktion von Daten

Für die Analyse und Validierung von Daten

Um Daten aus verschiedenen Quellen zu mischen/auszuwählen

Um Daten Dritter zu indexieren

Für Retrieval oder das Angebot verschiedener Ansichten

Quelle: Baker/Coyle (2019), Slide 3

Mögliche Ausformungen/Bestandteile

Menschenlesbare Dokumentation (z.B. tabellarisch in PDFs)

Beispiel-zentrierte menschenlesbare Dokumentation (siehe Dokumentationssession KIM WS 2017)

Schema für spezifische Serialisierung (z. B.: XML Schema, JSON Schema)

Spezifikation eines RDF-Graphen (z. B. ShEx)

Generische Spezifikation eines Profils mit tabellenbasiertem DC AP Core Vocabulary (in Entwicklung)

...

LRMI-Metadatenprofil für Hochschul-OER

Zu viele Akronyme?!

OER: Open Educational Resources, frei zugängliche und offen lizenzierte Lehr- und Lernmaterialien

LRMI: Learning Resource Metadata Initiative, ein Initiative zur Ergänzung von bildungsmaterialspezifischen Properties & Classes in schema.org

Wurde nicht gerade ein OER-Profil veröffentlicht?

Ja, mit LOM for Higher Education OER Repositories wurde bereits ein Profil inklusive XML Schema von der OER-Metadatengruppe veröffentlicht, das auf LOM (Learning Objects Metadata) basiert

LOM ist XML-basiert und eignet sich für einige Zwecke (z.B. OAI/PMH) gut, für das Web ist schema.org/LRMI besser

Warum ein LRMI-Profil?

Interesse an LRMI ist groß in der deutschsprachigen OER-Welt, allerdings gibt es keine leichte Anleitung, wie man es am besten nutzt

Aktuelles Projekt (von TIB Hannover und hbz) mit konkretem Bedarf an einem an Standards orientierten JSON Schema für OER-Metadaten: OERSI – OER Search Index

Der Entwicklungs-prozess

Idee zur Umsetzung

Zuerst JSON Schema & SkoHub-basiertes Referenz-Eingabeformular entwickeln

Danach: Spezifikation mit ReSpec schreiben (siehe dazu Sebastians Vortrag am morgigen Dienstag)

JSON Schema als zentrales Dokument

Das JSON Schema legt Felder, Wertetypen & referenzierte kontrollierte Vokabulare fest:
https://dini-ag-kim.github.io/lrmi-profile/draft/schemas/schema.json

Schema lässt sich im SkoHub Editor ausprobieren:
https://skohub.io/editor/

Kontrollierte Vokabulare als separate SKOS-Datei

Kontrollierte Vokabulare/Wertelisten werden separat als SKOS-Datei veröffentlicht und im Schema referenziert, so dass es im Editor eine Lookup-Funktion gibt

(Es gibt übrigens eine neue deutschsprachige Einführung zu SKOS – Simple Knowledge Organization System)

Property mit nicht-formatiertem String


{
  "properties": {
    "name": {
    "title": "Title",
    "type": "string"
    }
  }
}

Property mit formatiertem String (URI)


{
  "image": {
    "title": "Image",
    "type": "string",
    "format": "uri",
    "_display": {
	  "placeholder": "A link to an image of the resource"
    }
  }
}

Liste von möglichen Strings


{
  "type": {
    "title": "Type",
    "type": "string",
    "enum": [
      "AudioObject",
      "Book",
      "Course",
      "CreativeWork",
      "DataDownload",
      "ImageObject",
      "PresentationDigitalDocument",
      "SoftwareApplication",
      "VideoObject"
    ]
  }
}

Referenz auf SKOS-Vokabular


{
  "about":{
    "title":"Subject",
    "type":"array",
    "items":{
      "type":"object",
      "properties":{
        "inScheme":{
          "type":"object",
          "properties":{
            "id":{
              "type":"string",
              "enum":[
                "https://w3id.org/kim/hochschulfaechersystematik/scheme"
              ]
            }
          }
        }
      },
      "_widget":"SkohubLookup"
    }
  }
}

Wo kommen die vorgeschlagenen Werte her?

Kontrollierte Vokabulare müssen in SkoHub Vocabs veröffentlicht sein

Pflege als Turtle-Datei auf GitHub und Publikation als HTML/JSON-LD unter skohub.io (siehe hier für Details)

Hier: Nutzung einer im Kontext von "LOM for Higher Education OER Repositories" publizierten Klassifikation

Fazit / Ausblick

Vorteile

Entwicklung auf GitHub o.ä. mit den dort etablierten Prozessen

Referenz-Formular und Schema zur Validierung werden in einem Zuge entwickelt

Kontrollierte Vokabulare werden parallel mit SKOS entwickelt und sind unabhängig vom Schema nutzbar

Nachteile (?)

Fokussiert auf JSON und genau eine (von vielen möglichen) JSON-LD-Repräsentationen der Daten

Deshalb keine Validierungsmöglichkeit für anders strukturierte JSON-Daten und andere RDF-Serialisierungen

Menschenlesbare Version ist nicht von Beginn an verfügbar und muss separat geschrieben werden

Diskussion

Möglichkeiten der (zusätzlichen) Nutzung des DC Core Vocabulary for Profiles oder von ShEx?

Welche Form sollte die menschenlesbare Version haben?

Wer hat Interesse, das LRMI-Profil mit weiterzuentwickeln?

Weiterführende Informationen