Exercise 1 - Build an Ontology for Danish Public Transport

Build an Ontology for the Danish Public Transport System

Design a knowledge graph vocabulary for Rejseplanen's journey planning system

a Classes given are:

🚇

TransportService

Metro STog RegionalTrain Bus Ferry

📍

Location

Station BusStop Platform Terminal

🎫

FareZone

Zone1 Zone2 Zone3 Zone4

🏢

Operator

DSB MetroService Movia Arriva

👤

Passenger

Adult Child Senior Student

♿

AccessibilityFeature

Elevator Ramp TactilePaving AudioAnnouncement

📝 Note: These classes form the core vocabulary. TransportService has an intermediate hierarchy: Metro, STog, RegionalTrain → RailService; Bus → RoadService; Ferry → WaterService.

b Identify at least 5 relations (besides subClassOf) between entities

Define properties that connect instances of different classes. Consider: What stops where? What operates what? What is located in what zone?

→

c Identify possible constraints on the entities and relations

Think about rules that must hold in the transport domain. What cannot happen? What must always be true?

d Define the cardinality of each relation (1:1, 1:N, N:1, or N:M)

💡 Cardinality Guide:
1:1 — One-to-one (e.g., each line has exactly one terminus)
1:N — One-to-many (e.g., one operator runs many lines)
N:1 — Many-to-one (e.g., many stations belong to one zone)
N:M — Many-to-many (e.g., many lines stop at many stations)

↑ You've already specified cardinalities in task (b). Make sure each relation has the correct cardinality selected!

✓

Solutions

Relations Between Entities

Relation	Domain → Range	Description	Cardinality
`stopsAt`	TransportService → Location	A transport line stops at one or more locations	N:M
`operatedBy`	TransportService → Operator	A transport service is operated by a company	N:1
`inZone`	Location → FareZone	A location is situated in a fare zone	N:1
`hasFeature`	Location → AccessibilityFeature	A location has accessibility features	N:M
`connectsTo`	Location → Location	Direct connection between two locations	N:M
`boardsAt`	Passenger → Location	A passenger boards at a location	N:M
`uses`	Passenger → TransportService	A passenger uses a transport service	N:M
`adjacentTo`	FareZone → FareZone	Two fare zones are adjacent for pricing	N:M

Constraints

A Station must be located in exactly one FareZone (not zero, not multiple).
Every TransportService must be operated by at least one Operator.
Metro and STog lines can only stop at Stations (not BusStops).
A Bus line can stop at both Stations and BusStops.
Every Location must have GPS coordinates (latitude and longitude).
A Passenger of type Child must be accompanied by an Adult (for certain ticket types).
An Elevator (AccessibilityFeature) can only be associated with a Station or Terminal.
Two Locations can only have a connectsTo relation if at least one TransportService stops at both.
Zone numbers must be positive integers (Zone 1, Zone 2, etc.).
A TransportService cannot be both a RailService and a RoadService (disjoint classes).

💡 Note: These constraints would be expressed in SHACL (Shapes Constraint Language) or OWL restrictions in a real ontology implementation.