What Belongs to Which Video? Data Models and Knowledge Graphs

A video gets a new introduction. Picture and sound look good, but suddenly every search result jumps to the wrong point. The transcript still belongs to the old version. A filename and a text field clearly are not enough to record the relationship reliably.

Databases and semantic knowledge modeling address different sides of the same task: managing information in a structured way and describing its meaning clearly. Our example media library needs both once files become a searchable collection with topics, people and automatically generated results.

The media object is more than its file

A class may exist as an original recording, a compressed video and a separate audio track. There may also be subtitles and preview images. Treating every file as an independent video would lose these relationships.

One possible relational design therefore separates the work, media versions and derived results. A new edit is a new media version; a smaller playback file, by contrast, can represent the same content version. The precise distinction must fit the project.

This is an example model, not a universal table structure. Its purpose is to make important domain distinctions explicit. Media processing in Part 7 supplies the corresponding files and timing references.

Data rules belong in the database too

Primary keys identify records. Foreign keys enforce relationships between tables. Uniqueness constraints prevent invalid duplicates; further constraints limit permissible values. These rules protect stored data even when several parts of an application access it. PostgreSQL documentation: Constraints

In our library, a segment should not reference an unknown transcript version, for example. Within a segment, the end time must be later than the start. Checking against the video’s total duration additionally requires an appropriate comparison with the associated record; a simple comparison within one row does not fully solve this.

We would store people’s names separately and link them to videos through associations. A corrected spelling would then not have to be changed at every occurrence. Multiple people can also be associated with a video without requiring new columns such as person_2 and person_3.

Handle related changes together

Transactions group changes together. For concurrent access, it also matters which changes from other transactions are visible. Different isolation levels permit different effects; strong isolation can detect conflicts and require a retry. The application must account for these cases. PostgreSQL documentation: Transaction Isolation

In our example, releasing a transcript version could happen together with switching the active version reference. This avoids an intermediate state in which the application treats an incomplete version as current. The external search index does not automatically become part of the same database transaction, however. Updating it requires its own traceable workflow, as described in Part 2 on the distributed platform.

From tables to explicitly described statements

RDF represents knowledge as triples of subject, predicate and object. A statement might say: “Video 42 covers information retrieval.” Another connects this topic to a broader discipline. Resources can be named using unique identifiers; a graph consists of a set of such statements. W3C, 2014: RDF 1.1 Concepts and Abstract Syntax

For our example, the relationships can be read in simplified form:

Video 42       — covers       → Information Retrieval
Video 42       — presented by → Person 7
Lecture        — subclass of  → Class

An ontology describes classes, relationships and additional formal conditions. OWL allows further class memberships to be inferred from an existing membership and a subclass relationship, among other things. It uses an open-world assumption: missing knowledge is not automatically treated as a false statement. The absence of a stored second presenter therefore does not prove that none exists. W3C, 2012: OWL 2 Web Ontology Language Primer

SPARQL supports queries over RDF data. Which relationships a query finds depends on the available statements, the query pattern and any enabled inference mechanisms. A knowledge graph does not answer questions independently of its modeling. W3C, 2013: SPARQL 1.1 Overview

Automatic statements need provenance

For our library, an automatically detected topic assignment would initially be a suggestion. Its source, method, model version and review status would be stored. An editorially confirmed assignment could then be treated differently from an unchecked assumption.

This provenance helps with corrections: if a transcript is replaced, it becomes possible to identify which topic assignments were derived from it. Whether a dedicated graph store is already necessary should depend on actual query requirements. A clear relational model can be sufficient for the first version.

Text analysis in Part 5 produces these suggestions. Part 8 on visualization shows how their relationships and review status can be made visible.