Skip to content
Vera Meister edited this page Jul 27, 2020 · 14 revisions

Datenaufbereitung für Modulkatalog@THB

Dokumentation

Entwicklung eines RDF-Datenschemas

Ausgangspunkt waren die Modulbeschreibungen im eigenen Studiengang: Bachelor Wirtschaftsinformatik am Fachbereich Wirtschaft der THB. In bisherigen Projekten zur Entwicklung von Wissensgraph-basierten Anwendungssystemen gab es gute Erfahrungen mit schema.org. Zudem hat sich in der schema.org-W3C-Community in den letzten Jahren eine aktive Gruppe mit Fokus auf den Bildungsbereich gebildet. Die Entwicklung des Schemas erfolgte in mehreren Schritten bzw. Iterationen:

  1. Identifikation geeigneter Klassen, Attribute und Relationen für die Daten einer Modulbeschreibung. Dafür wurde zunächst die tabellarische Struktur der Modulbeschreibungen im FB Wirtschaft der THB analysiert und Mapping-Kandidaten identifiziert. Dabei wurden fast ausnahmslos schema.org-Ressourcen genutzt. Für die Abbildung der didaktischen Elemente (Lernziele, Inhalte und Prüfungsformen) wurde die generische Relation about mit Referenz auf eine ItemList gewählt. Die Differenzierung sollte mithilfe des identifier-Attributs erfolgen. Eine ähnliche Vorgehensweise wurde für die methodischen Aspekte (Lehr-/Lernformen und Aufteilung der Workload) gewählt. Da es sich hier um quantifizierbare Attribute handelt, wurde die Relation additionalProperty in Verbindung mit PropertyValue und für die Differenzierung das name-Attribut gewählt. Für eine Reihe von Ordnungs-relevanten Attributen (Abschlussgrad, Zuordnung zum Curriculum, Notengewichtung, Modultyp) konnten keine geeigneten schema.org-Attribute identifiziert werden. Deshalb wurde eine Konstruktion über die Relation educationalAlignment in Verbindung mit AlignmentObject entwickelt und die Differenzierung über das Attribut alignmentType realisiert. Als proprietäre Schema-Elemente wurden nur zwei Unterklassen von Person eingerichtet: Lecturer und Author. schema.org verfügt über keinerlei Unterklassen der Klasse Person. Die Differenzierung in Lehrende und Autoren (von referenzierter Literatur) ist angemessen, da sie bis auf Basisdaten über unterschiedliche Relationen und Attribute verfügen.
  1. Visualisierung des initialen Schemas mit CMap-Tools. Dabei wurden alle schema.org-Ressourcen mit roter Farbe, die proprietären Elemente dagegen mit grüner Farbe gekennzeichnet. Die Klassenhierarchie wird über rdfs:subClassOf dargestellt. Für die Knoten wurden unterschiedliche Formen zur Darstellung des Typs verwendet: URI-Knoten sind abgerundete Rechtecke (wenn es sich um Basisklassen handelt, dann ist die Form mit einem Schatten hinterlegt), Literalknoten sind mit einfachen Rechtecken dargestellt und verweisen auf den jeweiligen Datentyp. Für die unter 1. genannten Differenzierungen für didaktische, methodische und Ordnungs-relevante Aspekte der Modulbeschreibung wurden grüne Pfeilmarken an die jeweiligen Attribute bzw. Klassen angehängt.
  1. Serialisierung im Turtle-Format mit dem rdfEditor (dotNetRDF). Auch wenn schema.org einen weniger formalen Ansatz verfolgt, wurden zur Definition der Klassenhierarchien sowie der Spezifikation von Klassen, Relationen und Attributen die W3C-Standardvokabulare rdf, rdfs, owl und skos genutzt. Für die proprietären Elemente wurde der Namensraum module eingeführt. Einige weitere Vokabulare werden nur für die Beschreibung des Schemas selbst verwendet: dc, dcterms und voaf. Zur Spezifikation numerischer Datentypen wird die W3C-Spezifikation xsd genutzt. Schließlich dient wd als Namensraum für Wikidata-Entitäten, die zur Identifikation von Organisationen genutzt werden. Das Schema-Dokument spezifiziert jedes einzelne Element, indem in zwei Sprachen (Deutsch und Englisch) eine Bezeichnung (schema:name) und eine Beschreibung (rdfs:comment) referenziert werden. Die Beschreibung orientiert sich an den Vorgaben von schema.org, gibt jedoch domänenspezifische Ergänzungen. Die Hierarchie wird über rdfs:subClassOf kodiert, während die Geltungs- und Wertebereiche für Relationen und Attribute über rdfs:domain und rdfs:range abgebildet werden. Die Klassifikation wird über owl:Class, owl:ObjectProperty und owl:DatatypeProperty realisiert.
  1. Refactoring des Schemas. Für das Refactoring kann es unterschiedliche Anlässe geben: a) Anforderungen aus der Anwendungsentwicklung, b) Anforderungen aus der weiteren Analyse der Quelldaten, c) neue Versionen des Basis-Vokabular schema.org. Alle drei Anlässe haben tatsächlich bereits zu Umarbeitungen des Schemas geführt. Aus der Diskussion mit Experten aber auch aus der eigenen Anwendungsentwicklung wurden formalere Anforderungen an die Differenzierung und Sortierung der didaktischen und methodischen Listenelemente deutlich. Deshalb wurden proprietäre Sub-Properties und teilweise auch andere Klassifikationen in diesem Bereich vorgenommen. Die Analyse von Modulbeschreibungen eines weiteren Fachbereichs (Informatik und Medien) offenbarte Defizite in der Abbildung Ordnungs-relevanter Aspekte, da im Gegensatz zum FBW hier viele Module nicht nur einem Studiengang, sondern mehreren zugeordnet sind. Die Abbildung über educationalAlignment wurde aufgelöst und stattdessen weitere proprietäre Sub-Properties zur generischen schema.org-Property additionalProperty eingeführt. Weitere Umarbeitungen waren im Hinblick auf erforderliche oder empfohlene Voraussetzungen notwendig. Der Bezug eines Moduls zu einem Studiengang wurde so auf eine höhere Ebene gehoben. Schließlich wurden einige neuere Klassen und Relationen bzw. Attribute aus schema.org ersatzweise oder ergänzend eingefügt. So wird z. B. die Anzahl der ECTS-Punkte je Modul nicht mehr über das etwas sperrige Attribut educationalCredentialAwarded, sondern über numberOfCredits angegeben. Der Bezug eines Studiengangs zu einer Studien- und Prüfungsordnung wird über die Relation subjectOf in Verbindung mit der neuen Klasse Legislation umgesetzt.

Weiter zu Aufsetzen der Datenbank

Clone this wiki locally