GitLab-based Curriculum Management with Semantic Web Technologies

A decentralized approach to managing university module curricula using RDF, OWL, and SHACL — validated and published automatically through GitLab CI/CD pipelines.

Architecture overview showing the decentralized module repositories, central ontology, and the GitLab CI/CD validation pipeline

Initial situation

Universities manage complex curricula comprising hundreds of modules, each with prerequisites, study direction assignments, credit points, and ownership information. Traditionally, this data is maintained in spreadsheets or centralized relational databases. Both approaches suffer from similar limitations: schema changes require coordinated migrations, a single administrator becomes a bottleneck, and there is no built-in mechanism for automated consistency checks across the entire curriculum. As curricula evolve — new modules are added, prerequisites change, study directions are reorganized — maintaining data quality becomes increasingly difficult.

Problem statement / Project goal

The goal of this project is to design and implement a curriculum management system where each module owner (typically a professor) maintains their own data independently, while the system automatically ensures consistency and quality across the entire curriculum. The key challenge is reconciling decentralized data ownership with centralized validation: how can individual module descriptions be kept simple and self-contained, yet still be checked against the full curriculum for missing prerequisites, invalid references, or constraint violations?

Curriculum Visualization

Interactive curriculum visualization showing modules arranged by semester with prerequisite arrows and color-coded subject groups

The system automatically generates an interactive visualization of the entire curriculum. Modules are arranged by semester, color-coded by subject group, and connected by prerequisite arrows — making it easy to explore dependencies at a glance.

Module Editor

Web-based Module Editor interface showing form fields for module properties like name, ECTS credits, and language

A web-based editor allows professors to create and modify their module descriptions without needing to understand RDF syntax. The editor generates valid Turtle files and commits them directly to GitLab via the API.

Query Explorer

SPARQL Query Explorer interface showing a curriculum query with results table listing modules, groups, and study directions

A built-in SPARQL Query Explorer lets users run custom queries against the entire curriculum dataset. Pre-defined queries cover common use cases, and results can be exported as CSV for further analysis.

Solution developed and its benefits

The system is built entirely on open W3C Semantic Web standards. Each module is stored as a Turtle file (RDF) in its own Git repository. A central OWL ontology defines the curriculum schema, and SHACL shapes specify validation rules. When any module is updated, a GitLab CI/CD pipeline automatically performs the following steps:

  • Discovers and clones all module repositories tagged with a specific GitLab topic.
  • Validates each module individually against strict SHACL shapes (Phase 1).
  • Aggregates all module data with the central ontology and taxonomy.
  • Runs OWL 2 RL reasoning to infer transitive prerequisites and other derived facts.
  • Validates the complete inferred graph against semantic SHACL shapes (Phase 2).
  • Generates an interactive HTML validation report.
  • Publishes a Module Editor, SPARQL query interface, and curriculum visualization on GitLab Pages.

This architecture provides several key advantages over traditional approaches. Schema evolution requires no migrations — adding a new property to the ontology does not invalidate existing module data. Decentralized ownership means no single administrator bottleneck; each professor manages their own repository. Git provides a complete audit trail of every change. The OWL reasoner automatically derives implicit knowledge, such as the full chain of prerequisites for any module. And because everything runs on GitLab infrastructure already available at the university, no additional servers or databases need to be maintained.

The two-phase validation approach is particularly noteworthy: Phase 1 catches structural errors in individual modules (missing fields, wrong data types) before aggregation, while Phase 2 detects cross-module issues (dangling prerequisite references, unused taxonomy entries) that only become visible when looking at the full curriculum graph.

Key terms

  • RDFResource Description Framework — a W3C standard for representing knowledge as subject-predicate-object triples in a graph structure
  • TurtleA compact, human-readable syntax for writing RDF data, used as the file format for module descriptions
  • OWLWeb Ontology Language — defines the curriculum schema with formal semantics, enabling automatic reasoning over the data
  • OWL ReasoningAutomatic derivation of implicit facts (e.g., transitive prerequisite chains) from explicitly stated data and ontology axioms
  • SHACLShapes Constraint Language — declarative validation rules that check data quality and consistency across the curriculum
  • SPARQLQuery language for RDF graphs, used to generate reports and power the curriculum visualization
  • Knowledge GraphThe combined curriculum data forms a knowledge graph where modules, prerequisites, and study directions are interconnected
  • GitLab CI/CDContinuous Integration pipeline that automates aggregation, inference, validation, and publication on every commit

Team