Das Open Linked Data Projekt OD.FMI der Fakultät

Über einen SPARQL Endpunkt können Interessenten lesend auf die aktuellen Stundenplandaten zugreifen. Diese Datenbasis od.fmi ist die Primärquelle der Stundenplandaten an der Fakultät. Dort werden schrittweise weitere Daten integriert, die für das operative Geschäft auf Fakultätsebene relevant sind. Sie haben damit in der Regel nichts zu tun, können aber diese Daten in eigenen Applikationen ebenfalls verwenden. Bitte nehmen Sie bei Interesse Kontakt mit mir auf.

Diese Entwicklungen waren ein komplexer Showcase für das Ontowiki-Projekt am BIS-Lehrstuhl.

Workflow

Die im RDF Store od.fmi.uni-leipzig.de vorgehaltene Datenbasis orientiert sich grundsätzllich am aktuellen, operativen Zustand der Lehrplanungsdaten der Fakultät. Änderungen werden sowohl in den semesterspezifischen als auch den semesterübergreifenden RDF-Graphen (studium, rooms, personal) aktuell gehalten, Querverbindungen zwischen verschiedenen Graphen orientieren sich immer am operativen Zustand.

Um auch Zustandsbeschreibungen vergangener Semester verfügbar zu machen, werden diese zusammen mit den damals gültigen Querverbindungen in semesterübergreifenden Daten archiviert. Dies geschieht nach Ablauf des jeweiligen Semesters als Schnappschuss über eine entsprechende SPARQL-Anfrage. Die dabei erzeugte Turtle-Datei wird im od.fmi-Archiv gespeichert.

Im RDF Store od.fmi.uni-leipzig.de (und damit über den SPARQL-Endpunkt abfragbar) werden nur die semesterspezifischen Daten des vergangenen, aktuellen und kommenden Semesters vorgehalten. Die anderen semesterspezifischen Daten werden nach Fristablauf im Store gelöscht und stehen danach nur noch in der archivierten Form zur Verfügung.

Struktur der Datenquelle

Die URL der einzelnen Ontologien lautet http://od.fmi.uni-leipzig.de/<name>/

Die Datenquelle besteht aus mehreren Wissensbasen, und zwar

Das Projekt folgt einer iterativen Entwicklungsmethodik. In die aktuellen Datenstrukturen werden nur Korrekturen eingearbeitet, die den Betrieb beeinträchtigen. Grundlegendere Strukturänderungen werden ausschließlich im Vorfeld der LV-Planung für das nächste Semester umgesetzt und für die Daten der neuen Lehrplanung wirksam.

Änderungen der Struktur der Datenquelle

Probleme

Änderungen

Änderungen zum Sommersemester 2020

Änderungen zum Wintersemester 2019/20

Änderungen zum Wintersemester 2019/20

Änderungen zum Sommersemester 2019

Änderungen zum Sommersemester 2018

Änderungen zum Wintersemester 2015/16

Änderungen zum Sommersemester 2015

Änderungen zum Wintersemester 2014/15

Änderungen zum Sommersemester 2014

Änderungen zum Wintersemester 2013/14

Änderungen zum Sommersemester 2013

Änderungen zum Wintersemester 2012/13

Änderungen zum Sommersemester 2012

Auflistung der Struktur im Detail

Globale Eigenschaften einer LV-Wissensbasis

od:Kurs – Gruppierungseinheit zwischen den Ebenen Unit und LV (Almaweb-Systematik, ab S12)

od:Module

od:ModuleGroup

foaf:Person – Mitarbeiter

org:organizationalUnit – Struktureinheiten (auf verschiedenen Ebenen) siehe Groups.ttl

od:RegularEvent
Oberklasse zu verschiedenen Event-Arten, der folgenden Struktur:
wöchentlicher Termin mit Literalen dayOfWeek, beginsAt und endsAt sowie hasRegularity mit Range od:TimeConstraint (A-Woche, Blockveranstaltungen usw., default: weekly), die auf Nummern der entsprechenden Kalenderwochen abgebildet werden. Siehe auch od:Semester

od:Extern rdfs:subClassOf od:regularEvent – weitere Termine, die für die Raumplanung zu berücksichtigen sind

od:LV rdfs:subClassOf od:regularEvent

rdfs:subClassOf od:LV

od:Room

od:Studiengang – von uns verantwortete Studiengänge

od:StudiengangSemester – Aggregat aus Studiengang und Semester für Stundenplaneinteilung

od:TimeConstraint – Klassifikation nicht wöchentlicher Termine

od:TimeSlotLA – Lehramt-Zeitfenster laut zentraler Übersicht

od:Unit – semesterübergreifende Gruppierungseinheit für zusammenhängende Lehrveranstaltungen (LV-Verantwortungsbereich) in “studium”

od:recommendedFor kann aus od:Module und od:toStudiengangSemester inferiert werden, wenn es Module gibt. Das ist aber für Veranstaltungen der Mathematik nicht unbedingt gegeben. Deshalb sind beide im Zuge einer Qualitätssicherung von Zeit zu Zeit abzugleichen.

Anbindung an Almaweb

Die Modellierung der Prüfungsordnungen von Almaweb kennt eine Baumstruktur (wohl eher ein DAG) – im Weiteren Almaweb-DAG -, deren Blättern die einzelnen Module sind, die im jeweiligen Studiengang zur Wahl stehen. Module können in mehreren Studiengängen eingehängt sein, um die bisherige Vervielfachung von Modulnummern für einen Modul in verschiedenen Studiengängen zu vermeiden. Jedem Modul ist eine Reihe von Kursen zugeordnet, die wiederum Lehrveranstaltungen enthalten.

Die Modul-Kurs-Zuordnung bildet semesterübergreifende Zusammenhänge ab und ist – so weit dies geht – auf od-Seite in eine eigene Wissensbasis Kurse ausgelagert, in der diese semesterübergreifenden Zusammenhänge auf Unit-Kurs-Ebene dargestellt sind, da unsere Planungseinheit nicht Modul, sondern Unit (als planungstechnische Zusammenfassung mehrerer LV, die auf mehrere Module verteilt sind) ist. Unit-Kurs-Zusammenhänge, die sich nicht (oder noch nicht) so darstellen lassen, sind in der Wissensbasis des jeweiligen Semesters zu finden wie auch alle Kurs-LV-Beziehungen.

aw:Kurs

aw:GradeSystem – Graduierungssystem aus Almaweb (was das auch immer ist)

aw:LVCategory – Kategorie einer LV aus Almaweb (was das auch immer ist)

aw:LVType – Typ einer LV aus Almaweb (was das auch immer ist)

aw:Modul

aw:ServingUnit – Resource-URI in die Almaweb-Wissensbasis

aw:Tag