Organizations increasingly use knowledge graphs to describe their world: concepts such as customers, products, locations, or regulations, and the relationships between them. These descriptions are often written as ontologies, either developed internally or reused from established domain standards and community vocabularies.
However, when it is time to build an information system, developers commonly create a separate model of the same domain: classes, attributes, relationships, and business rules. This duplicates modelling effort and creates an opportunity for the knowledge graph and the software implementation to drift apart.
We propose a bridge between these two worlds. Starting from an OWL 2 ontology and SHACL validation shapes, we generate a UML class diagram enriched with OCL constraints.
From semantic knowledge to software design
OWL 2 is a standard for representing domain knowledge. It can describe concepts and relationships, such as “an airport has an IATA code”. SHACL complements it with validation rules, for example “an airport code must consist of three uppercase letters”.
On the software side, UML class diagrams describe the structure of an application, while OCL expresses the rules that valid application data must follow. The basic structural connection is not new: ontology concepts can become UML classes, relations can become associations, and data properties can become attributes.
The difficult, and more interesting, part is what happens beyond this structure. Ontologies and SHACL shapes can also contain restrictions, validation conditions, and logical rules that do not fit in a plain UML class diagram. Our approach aims to preserve these rules too, by translating them into OCL constraints attached to the generated UML model.
How the transformation works
The approach is not a simple change of notation. Before generating the UML model, it follows a short transformation pipeline that prepares the ontology and makes the information needed for software design explicit.
First, a reasoner derives facts that logically follow from the ontology. Not every piece of knowledge needs to be explicitly written in an ontology; some of it can be inferred from the rules already present.
The pipeline then resolves duplicate individuals. An ontology may state that two identifiers refer to the same real-world entity, whereas a conventional software model generally expects one object for that entity.
The key step is the bottom-up transformation. Ontology rules can be nested: one expression may contain smaller expressions inside it. Rather than translating a complex rule all at once, we first translate its innermost pieces and then progressively build the larger expression around them.
Finally, we materialise anonymous classes when needed. Ontologies can express useful concepts without naming them; for example, “things that are connected to at least one object of a particular type.” Such a concept has no ready-made box in a UML diagram. The transformation creates an auxiliary UML class for it, providing a concrete place to represent the restriction and attach the relevant OCL constraint.
Why add auxiliary classes? A manually created UML diagram might hide such intermediate details. Our goal is different: preserve the meaning of the ontology systematically. This may produce a more detailed model, but it avoids silently losing important rules.
Keeping rules, not just boxes and arrows
Earlier ontology-to-UML approaches have often focused on structure alone. Our approach also translates rules: cardinalities, allowed values, value formats, logical conditions, and other restrictions that a plain UML diagram cannot express by itself.
We define systematic transformation rules for OWL 2 to UML and OCL, and for SHACL to OCL. For readers who want the detail, below are the complete systematic mapping tables (click on the icons to see them full screen)
As a small example, both airlines and airports can have an IATA code. However, airline codes and airport codes follow different formats. Our transformation produces the corresponding UML attributes and preserves the specific validation rules as OCL constraints.
Why does this matter?
The generated UML/OCL model is closer to what software teams and model-driven tools use in practice. It can help align domain experts and developers, validate designs, and support the generation of parts of an application.
It may also help in AI-supported development: rather than relying on a broad description of a domain, your favorite LLM can start from a more concrete model of the system and the rules it must enforce.
What comes next?
We tested the approach on the YAGO schema, where it successfully transformed hundreds of OWL 2 and SHACL constructs into UML/OCL artifacts. This is an encouraging proof of concept, but there is still work to do.
In particular, we want to investigate how the generated UML diagrams can be refined and simplified without losing relevant meaning. Some auxiliary classes are needed to preserve the semantics of complex or anonymous ontology expressions, but they can also make diagrams harder to read.
We also plan to evaluate the approach on more ontologies and SHACL collections, covering different domains, sizes, and modelling styles.
Ultimately, the goal is simple: knowledge graphs should not remain isolated knowledge assets. They should also help shape the software systems that depend on them.
Paper: Mauro Dalle Lucca Tosi, Fitash Ul Haq, and Jordi Cabot . Translating OWL 2 Ontologies and SHACL Shapes into UML/OCL Models. Accepted at the 4th Workshop on Knowledge Graphs and Model-driven Systems Engineering (KGMDSE), co-located with ISWC 2026, Bari, Italy (In Press)
The implementation and generated artefacts are available at github.com/maurodlt/owl2uml.
Recent Comments