Transformation from OWL/SHACL to UML/OCL

[u/No_Bottle4038]

Hi everyone,

I am working on a transformation from OWL + SHACL models into UML + OCL, and I’d love to get some opinions from people in the semantic web community.

The motivation is that many companies already have their own knowledge graphs, and domain ontologies often already describe their domains quite well. So, instead of rebuilding everything from scratch for software development, why not reuse that knowledge to accelerate software production?

Ontologies are great for structuring and reasoning over data, but when it comes to application design and code generation, UML is often a closer representation of what software teams actually work with. The idea is therefore to automatically transform a KG/ontology into UML models and OCL constraints that can then be used by existing MDE and code generation tools (with and without LLMs). Note that we don't simply represent an ontology using a class diagrams, we automatically convert all logical constraints from such ontology as well.

I wrote a short blog post explaining the transformation rules if anyone is interested:
https://modeling-languages.com/owl2_shacl-uml_ocl/

We’ll also present the work at the KGMDSE workshop in October, co-located with ISWC.

The long-term vision is something like:

KG → UML/OCL → automatically generated software system

I’m curious about the semantic web community opinion about this. Does it sound useful in practice? Where do you see the biggest limitations?

Any feedback is welcome!

[u/Complete-Ebb-1035]

Do you have data to support this assertion: UML is often a closer representation of what software teams actually work with IMHE RDF, rendered as JSON-LD, is a near perfect fit with JavaScript development. Further, we easily transform RDF/JSON-LD to be a direct source for Python manipulation. IMHE UML is inconsistent with RDF and adds no value WRT structuring facts and reasoning.

[u/No_Bottle4038 → u/Complete-Ebb-1035]

That’s a fair comment. I’m not claiming UML is better than RDF, or that it should replace a KG. RDF/OWL are obviously much better suited for representing knowledge, interoperability, and reasoning.

What I meant is more that they are usually used for different purposes. RDF is fundamentally “a standard model for data interchange on the Web” (https://www.w3.org/RDF/), while UML is a “standard for visualizing, specifying, constructing, and documenting software systems” (About the Unified Modeling Language Specification Version 2.5.1).

So the transformation is not meant to manage the KG itself, but to reuse the knowledge already present in it to help generate software artifacts.

For example, many enterprise systems still rely on more traditional application architectures: databases, APIs, CRUD apps, generated code, etc. In that context, UML/OCL can be a useful intermediate representation because there is already a large ecosystem of tooling around it.

So the idea is more:

KG/ontology → UML/OCL → software generation

while the KG can still remain the semantic source of truth and continue supporting reasoning.

I completely agree that adding UML into a pipeline already centered around RDF/JSON-LD for data manipulation and inference would probably not bring much value. Where I think it becomes more interesting is when the goal is to generate a full software system for end users, communicate the structure to stakeholders, or integrate with existing model-driven engineering tooling and workflows.

[u/Successful-Farm5339]

Many thanks for sharing this work. It is good that you documented the rules in the blog post instead of reserving them for the workshop paper. The approach is helpful. My clients have the exact asset you mention. They hold a domain ontology that represents the domain accurately. However, their software teams will never inspect a Turtle file.

I anticipate two areas where this transformation will present challenges.

First, your inputs combine distinct semantics. SHACL operates under closed-world assumptions. Therefore, mapping shapes to OCL invariants resembles a syntactic shift. OWL axioms function as open-world inference licenses. In OWL, Person subClassOf hasParent some Person does not invalidate an instance lacking a parent. The reasoner deduces that an unnamed parent exists. The resulting OCL invariant will reject that same instance. The transformation silently converts inference licenses into integrity constraints. Do you limit the OWL input to a profile where this interpretation is safe? Or do you declare closed-world plus unique names for the entire pipeline?

Secondly, which graph do you translate? Is it the asserted axioms or the closure? We encountered this issue in our own CI. Running an OWL-RL reasoner before SHACL validation alters validation outcomes. Materialised inferences lack provenance. Once the closure is embedded in a downstream artifact, you cannot explain why a class has a specific attribute. In your pipeline, that downstream artifact consists of generated code. This makes the question more acute.

Both questions resurface after the initial generation run. This is because the ontology continues to evolve once the code is deployed. I have been addressing this coevolution problem. I maintain Open Ontologies (https://github.com/fabio-rovai/open-ontologies). It is a Rust MCP for validating and governing OWL/SHACL ontologies. One tool checks SHACL shapes against the OWL-RL closure. It revalidates incrementally when IRIs change. This is the machinery I would want upstream of a transformation like yours. Since your code generation path involves LLMs, an MCP validation gate before the generator could be a suitable fit.

I am happy to run your example ontologies through it if that is of interest. Good luck at KGMDSE we are presenting something at OM, same conference different workshop, happy to connect if you ping me!.

[u/No_Bottle4038 → u/Successful-Farm5339]

Thank you for the feedback!

Regarding the first challenge, the OWA/CWA difference is precisely why we do not consider the transformation fully lossless. In our experiments we enforce a CWA for the transformation pipeline. To reduce inconsistencies caused by this shift, we first materialize inferred triples using a reasoner before performing the transformation.

In the prototype we are developing, we also inform the user about rules that may become problematic under this interpretation and let them decide whether they should be enforced, relaxed, or ignored before generation.

For the second point, we currently translate the materialized closure. As you mentioned, this can create provenance issues downstream once the generated artifacts evolve independently. At the moment, we essentially assume that the input KG has already been validated enough to act as the source of truth. We also explicitly mention in the paper that the quality of the resulting UML/OCL model is directly tied to the quality of the input graph.

Your project is interesting as well! I can definitely see scenarios where something like that would fit nicely upstream of a transformation pipeline like ours.

And yes, happy to connect during the conference. I’ll ping you closer to KGMDSE/OM.

[u/newprince]

I'm not sure if the translation to UML is necessary. I tend to think that this approach by Palantir makes a lot of sense... capturing ontologies and serving them up as MCP resources/tools. https://youtu.be/bJsHKMUqCvg?is=HZgWE5zA5trKVnwn

Otherwise I would honestly go the other way, that is make VKGs out of the existing databases using RML for example. That would be much more lightweight

[u/No_Bottle4038 → u/newprince]

Thanks for sharing the video, I didn’t know about that MCP solution from Palantir. It definitely makes a lot of sense for a lot of KG-centric use cases.

To me, though, it feels more oriented toward interacting with and extracting insights from KGs through LLMs than toward generating software systems themselves.

Our approach is a bit different: the KG is used as an input to model the application, but the final system still relies on a more traditional software stack behind the scenes (database, APIs, UI, etc.). The goal is basically to reuse the knowledge already captured in the ontology/KG to accelerate the creation of those systems.

And yes, I agree with your last point: if you already have a well-structured operational database, then our approach probably brings little value. It makes more sense in situations where the ontology/KG is already the main structured representation of the domain.

Still, your comment makes me think it would be very interesting to run experiments comparing software development using our approach and using the ontology as input (with and without MCP)

[u/TheGratitudeBot → u/No_Bottle4038]

Thanks for such a wonderful reply! TheGratitudeBot has been reading millions of comments in the past few weeks, and you’ve just made the list of some of the most grateful redditors this week! Thanks for making Reddit a wonderful place to be :)

[u/Extra-Guava8]

https://shacl-play.sparna.fr/play/doc

[u/No_Bottle4038 → u/Extra-Guava8]

Thanks for sharing this, I didn’t know it yet.
There’s definitely some overlap in motivation. Our idea, though, is less documentation-oriented and more focused on software generation and communication with software teams/stakeholders. Still, I’ll take a deeper look at it for some inspiration : )