Seeing the Model: Visual Ontology Modelling and Visualisation Tools

A model nobody can look at is a model nobody will check. Turtle is precise and unreadable in bulk; a domain expert will not review three thousand triples, and if you make them try, they will nod and sign off on something they did not understand. The tooling in this lesson exists to close that gap, and it splits into two jobs that are constantly confused: drawing a model so it can be built and reviewed, and visualising an ontology that already exists so it can be understood.

Visual Ontology Modelling and Visualisation Tools

Drawing to build: modelling notations

OntoUML is the most opinionated option, and the only one that carries semantics: because its stereotypes are the UFO distinctions you met earlier, an OntoUML diagram can be checked for ontological errors, not just drawn. If you have committed to UFO, draw in OntoUML and use its tooling to validate.

Graffoo is a diagram notation for OWL delivered as palettes for the free yEd editor. It is a favourite for documentation because the resulting diagrams are legible to people who have never seen an ontology, and it maps cleanly onto OWL constructs.

Chowlk takes the idea further: you draw the conceptualisation in diagrams.net using a UML-based notation, and the framework converts the diagram into OWL. That closes the loop that usually leaks, where the diagram and the ontology drift apart within a fortnight because the diagram is a picture rather than a source. It comes out of the Ontology Engineering Group at UPM and was presented at ESWC 2022.

Worked example · the Aberdeen-2 asset register

Where we left it: a typed, testable backlog. Now the domain experts get something they can actually review.

The equipment module, one module exactly as the lesson prescribes, drawn in Chowlk conventions in diagrams.net so the diagram compiles to OWL instead of drifting from it. In outline:

[Equipment] <--subClassOf-- [Pump] --hasPart--> [Impeller]
                             [Pump] --installedAt--> [Site]
[WorkOrder] --performedOn--> [Equipment]
[Pump] --ratedPowerKW--> xsd:decimal

Twenty minutes into the review, the platform’s senior engineer, who has never read a line of Turtle, points at the sheet: “Nothing stops a work order being performed on a site.” That is a real catch, the diagram doing its job. Just as important is knowing what the sheet is not showing. The Pump/Pipeline disjointness, the at-most-one-impeller-per-state discipline from lesson 6, and every cardinality live in annotations or nowhere: box-and-arrow notations declare vocabulary and its wiring, not quantified axioms. So the sign-off is minuted honestly: the expert approved the structure, and the axioms remain the CQ suite’s job to check. A diagram review supplements the tests; it never replaces them.

State of the register: a reviewable, compilable module diagram and one caught wiring error. Next: definitions, patterns and OntoClean, where the hierarchy itself goes under audit.

Drawing to understand: visualisation

VOWL is a visual notation for OWL with two implementations worth knowing: WebVOWL, a standalone web application, and a Protege plugin. It is genuinely useful for a mid-sized ontology and genuinely useless above a few hundred classes, where force-directed layout produces what practitioners politely call a hairball.

Inside Protege you have OntoGraf and OWLViz for quick structural views, which are fine for orientation and poor for communication. PoolParty and similar commercial platforms provide taxonomy-oriented visual editing aimed at non-technical curators, which is the real use case: the person maintaining a thesaurus should not be in a text editor. If your graph is in a property graph store, Neo4j Bloom and similar tools give you instance-level exploration, which is a different thing again: you are looking at data, not at the schema.

Matching the tool to the job
Job Tool Watch out for
Design a model with ontological rigour OntoUML with its plugin Requires commitment to UFO
Draw an OWL model for documentation Graffoo palettes in yEd The diagram is not the source. It will drift
Draw and generate OWL from the drawing Chowlk with diagrams.net Notation coverage is not the whole of OWL 2
Understand an ontology you were handed WebVOWL or the Protege plugins Unusable above a few hundred classes
Let curators maintain a taxonomy PoolParty and similar Commercial. Taxonomy-shaped, not axiom-shaped
Explore instance data Neo4j Bloom and graph explorers Shows data, not the model

What breaks · the review pack printed in greyscale

The register’s module diagrams go into the quarterly assurance pack, which is printed, in black and white, as assurance packs are. In the notation used, object properties and datatype properties are distinguished chiefly by colour, and in greyscale they collapse into the same grey arrow. On page 14, ratedPowerKW appears pointing at a box that the modeller had drawn as a value node, the exact entity-attribute-value antipattern lesson 17 warned against. On screen, in colour, a sharp reviewer might have caught the wrong arrow type; on paper, both arrows read identically, and the reviewer, who happens to be one of the roughly one in twelve men with red-green colour vision deficiency, would not have seen the difference on screen either. The diagram is approved, the antipattern ships, and the aggregation queries slow down a quarter later with a sign-off trail saying everything was reviewed. The lesson’s warning is not accessibility etiquette; it is an assurance failure mode. The fix costs nothing: encode distinctions redundantly in shape and label, print the pack in greyscale yourself before circulating it, and caption what every visual channel means.

Two honest warnings

First, colour carries meaning in both VOWL and Graffoo, which means information is lost when a diagram is printed in black and white, and for colleagues with different colour perception. If a diagram is going into a report or a bid, check that it still reads without colour, and label what the colours encode.

Second, automatic layout of a real ontology is almost always unreadable. The diagrams that persuade people are hand-arranged views of one module at a time, which is a strong practical argument for the modular approach two lessons ago. Draw the module, not the ontology.

Next we return to method with the material on definitions, design patterns and OntoClean.

Visual Ontology Modelling and Visualisation Tools in practice

Check yourself

A module diagram shows: a Pump box with a subclass arrow to Equipment, a hasPart arrow to Impeller, and an installedAt arrow to Site. Which statement is NOT asserted by that diagram?

  1. Pump is a subclass of Equipment.
  2. hasPart is used to relate pumps to impellers.
  3. Every pump has at least one impeller.
  4. installedAt is used to relate pumps to sites.
Show the answer, and why each wrong option is wrong

C is correct: the diagram does not say it. An arrow between class boxes declares vocabulary and wiring, that the property exists and connects these kinds of thing. Existence claims, “every pump has at least one”, are quantified axioms, and they live in an existential restriction or a minCount, which most notations render as small annotation text or omit entirely. The gap between what a diagram shows and what a reviewer believes it shows is exactly where lesson 6’s silent bombs hide.

A is asserted: the subclass arrow is the one construct virtually every notation renders faithfully. B and D are asserted at the level the diagram operates: the property connects those classes in the model’s intent (in Chowlk, they compile to property declarations with their usage). Believing the diagram also promised C is how “the expert approved it” becomes “nobody actually said every pump needs an impeller”, and the fixture with an impeller-less pump sails through review.

Further reading

Apply it to your work


Lesson Content
Previous Quiz
Back to Course
Next Quiz