Was gehört zu welchem Video? Datenmodelle und Wissensgraphen

Ein Video bekommt einen neuen Vorspann. Bild und Ton sehen gut aus, aber plötzlich springen alle Suchtreffer an die falsche Stelle. Das Transkript gehört noch zur alten Fassung. Ein Dateiname und ein Textfeld reichen offenbar nicht aus, um die Beziehung zuverlässig festzuhalten.

Datenbanken und semantische Wissensmodellierung beschäftigen sich mit unterschiedlichen Seiten derselben Aufgabe: Informationen strukturiert verwalten und ihre Bedeutung nachvollziehbar beschreiben. Unsere Beispielmediathek benötigt beides, sobald aus Dateien ein durchsuchbarer Bestand mit Themen, Personen und automatisch erzeugten Ergebnissen wird.

Das Medienobjekt ist mehr als seine Datei

Eine Lehrveranstaltung kann als Originalaufnahme, komprimiertes Video und separate Audiospur vorliegen. Hinzu kommen Untertitel und Vorschaubilder. Würde jede Datei als unabhängiges Video behandelt, gingen diese Zusammenhänge verloren.

Ein möglicher relationaler Entwurf trennt deshalb Werk, Medienversion und abgeleitete Ergebnisse. Eine neue Schnittfassung ist eine neue Medienversion; eine kleinere Wiedergabedatei kann dagegen dieselbe inhaltliche Version repräsentieren. Die genaue Unterscheidung muss zum Projekt passen.

Datensatz	Beispielinhalt	Wichtige Beziehung
Video	Titel, Beschreibung, Eigentümer	Fachliche Identität
Medienversion	Dauer, Originaldatei, Erstellungszeit	Gehört zu einem Video
Wiedergabevariante	Auflösung, Codec, Dateiverweis	Gehört zu einer Medienversion
Transkriptversion	Sprache, Verfahren, Prüfstatus	Bezieht sich auf eine Medienversion
Textsegment	Anfang, Ende, Text	Gehört zu einer Transkriptversion

Das ist ein Beispielmodell, keine universelle Tabellenstruktur. Sein Zweck ist, fachlich wichtige Unterschiede ausdrücklich zu machen. Die Medienverarbeitung in Teil 7 liefert die entsprechenden Dateien und Zeitbezüge.

Datenregeln gehören auch in die Datenbank

Primärschlüssel identifizieren Datensätze. Fremdschlüssel sichern Beziehungen zwischen Tabellen. Eindeutigkeitsbedingungen verhindern unzulässige Duplikate; weitere Constraints begrenzen zulässige Werte. Solche Regeln schützen die Datenhaltung auch dann, wenn mehrere Anwendungsteile auf sie zugreifen. PostgreSQL-Dokumentation: Constraints

Für unsere Mediathek sollte etwa ein Segment nicht auf eine unbekannte Transkriptversion verweisen. Innerhalb eines Segments müsste der Endzeitpunkt nach dem Anfang liegen. Eine Prüfung gegen die Gesamtdauer des Videos erfordert zusätzlich einen geeigneten Abgleich mit dem zugehörigen Datensatz; ein einfacher zeilenlokaler Vergleich löst das nicht vollständig.

Personennamen würden wir separat speichern und über Zuordnungen mit Videos verbinden. Dadurch muss eine korrigierte Schreibweise nicht an jeder Fundstelle geändert werden. Gleichzeitig können mehrere Personen an einem Video beteiligt sein, ohne dass dafür neue Spalten wie person_2 und person_3 nötig werden.

Zusammengehörige Änderungen gemeinsam behandeln

Transaktionen bündeln Änderungen. Für parallele Zugriffe ist außerdem wichtig, welche Änderungen anderer Transaktionen sichtbar sind. Unterschiedliche Isolationsstufen erlauben unterschiedliche Effekte; starke Isolation kann Konflikte erkennen und einen erneuten Versuch notwendig machen. Die Anwendung muss diese Fälle berücksichtigen. PostgreSQL-Dokumentation: Transaction Isolation

Im Beispiel könnte das Freigeben einer Transkriptversion zusammen mit dem Wechsel des aktiven Versionsverweises erfolgen. So entsteht kein Zwischenzustand, in dem die Anwendung eine noch unvollständige Fassung als aktuell behandelt. Der externe Suchindex wird damit allerdings nicht automatisch Teil derselben Datenbanktransaktion. Seine Aktualisierung braucht einen eigenen nachvollziehbaren Ablauf, wie in Teil 2 zur verteilten Plattform beschrieben.

Von Tabellen zu ausdrücklich beschriebenen Aussagen

RDF stellt Wissen als Tripel aus Subjekt, Prädikat und Objekt dar. Eine Aussage könnte lauten: „Video 42 behandelt Information Retrieval.“ Eine weitere verbindet dieses Thema mit einem übergeordneten Fachgebiet. Ressourcen lassen sich durch eindeutige Kennungen bezeichnen; ein Graph besteht aus einer Menge solcher Aussagen. W3C, 2014: RDF 1.1 Concepts and Abstract Syntax

Für das Beispiel lassen sich die Beziehungen vereinfacht so lesen:

Video 42       — behandelt       → Information Retrieval
Video 42       — vorgetragen von → Person 7
Vorlesung      — Unterklasse von → Lehrveranstaltung

Eine Ontologie beschreibt Klassen, Beziehungen und zusätzliche formale Bedingungen. OWL erlaubt unter anderem, aus einer Klassenzugehörigkeit und einer Unterklassenbeziehung weitere Zugehörigkeiten abzuleiten. Dabei gilt eine offene Weltannahme: Fehlendes Wissen wird nicht automatisch als falsche Aussage behandelt. Dass kein zweiter Vortragender gespeichert ist, beweist also nicht, dass es keinen gibt. W3C, 2012: OWL 2 Web Ontology Language Primer

SPARQL ermöglicht Abfragen über RDF-Daten. Welche Zusammenhänge eine Abfrage findet, hängt von den vorhandenen Aussagen, dem Abfragemuster und gegebenenfalls aktivierten Schlussfolgerungsverfahren ab. Ein Wissensgraph beantwortet Fragen nicht unabhängig von seiner Modellierung. W3C, 2013: SPARQL 1.1 Overview

Automatische Aussagen brauchen Herkunft

Für unsere Mediathek wäre eine automatisch erkannte Themenzuordnung zunächst ein Vorschlag. Gespeichert würden Quelle, Verfahren, Modellversion und Prüfstatus. Eine redaktionell bestätigte Zuordnung könnte dann anders behandelt werden als eine ungeprüfte Vermutung.

Diese Herkunft hilft bei Korrekturen: Wird ein Transkript ersetzt, lässt sich feststellen, welche Themenzuordnungen daraus abgeleitet wurden. Ob dafür bereits ein eigener Graphspeicher nötig ist, sollte der tatsächliche Abfragebedarf entscheiden. Ein klares relationales Modell kann für den ersten Stand genügen.

Die Textanalyse in Teil 5 erzeugt solche Vorschläge. Teil 8 zur Visualisierung zeigt, wie ihre Beziehungen und ihr Prüfstatus sichtbar gemacht werden können.