Part 3: Once Meaning Exists

Jeff Uren ★ 2026-07-06

This is the third article in a series about building a shared understanding of data, ontologies, and data architecture (UDA) in a large organisation that struggles with meaning.

The interesting thing about the UDA isn't the ontology, all told, that's actually only about 500 lines of plaintext turtle code which is used to compile the relationships and then more or less, discarded.

Once you've described the organisation well enough, an uncomfortable amount of software starts becoming derivable.

That's not out of us building dozens of separate systems, it's because they're all asking the same question:

"Given this understanding of the organisation... what can I build?"

Graph of Concepts

The simplest output is the ontology itself, not diagrams, but a living explorable and traversable graph of what's important to the organisation.

An application can browse the concepts, their relationships, domains, attributes, terms, enumerations.

Documentation at this point, is just a matter of exploring.

A Graph of Wellcome

Aside: I'll talk about this in a later article in more depth, because it's something really interesting. Then comes an even more interesting graph, because the ontology can connect to reality through the mappings.

A Grant, it's attributes, the datasets that contribute to it, the pipelines, lineage, and quality rules, and even the permissions.

Everything is discretely connected, so that it's no longer a graph of ideas, it's a complete graph of Wellcome as it exists.

Generated GraphQL

GraphQL more or less becomes stupidly obvious because the ontology knows the relationships, attributes, and even the underlying types.

Generating GraphQL becomes just a translation exercise, and we have built a graphql service which can read in annotated graphql declarations and automatically spin up a graphql service with resolvers that can read from the underlying data sources.

So instead of writing APIs, we just describe concepts, everything else is done for us. It doesn't even need AI to do it.

Generated REST APIs

The same applies to REST. Need an HTTP REST API to allow you to integrate Wellcome data into your new application or system? Need an aggregation endpoint, or a specific projection?

They're all describing different views over the same conceptual model.

Warehouse tables

One of my favourite examples, because people spend months designing warehouse tables.

We get dimension tables, fact tables, big report-style tables, slowly changing dimensions, conformed dimensions, star schemas, snowflakes.

The ontology already knows what entities exist, what relationships, and measures, so building a warehouse is just another projection. The warehouse is just an output of the UDA, and not the center of the universe.

Query Engines

This is where I think things become actually very exciting. Because instead of asking SQL questions we can ask semantic questions.

The query engine decides:

should satisfy the request, but it isn't querying tables, it's just materializing the concepts.

Integration Spine

This is probably the least obvious one, but one of the more important ones.

Organisations like to do a lot of point-to-point integrations, and they end up with a spaghetti of data flows.

Every migration of one of these systems is a project, and every replacement means rebuilding integrations.

The ontology changes that because applications don't integrate with Oracle, or Workday, or Salesforce. They integrate with organisational concepts. Behind the stable conceptual layer, mappings can change, systems can be replaced, fields renamed, schemas redesigned, but the interface does not move.

The ontology becomes an integration spin running through the middle of the organisation and not just another integration platform, it's fully semantic one with meaning baked in.

Change stops being terrifying and traumatic

Imagine replacing Oracle, Salesforce, or Workday. Normally one of the first questions you'd ask is:

What's this gonna break?

With semantic mappings we know exactly what these applications contribute, which concepts, attributes, projections, which APIs, warehouse tables, which applications.

Coupled with the integration spine, we can replace systems without fear of breaking everything, interrupting operations, or losing data. We can take more reasoned, and phased approaches to change, and we can even run multiple systems in parallel while we migrate, because the UDA knows how to combine the outputs of multiple systems into a single conceptual view.

So migration becomes substitution rather than archaeology, and the UDA unlocks the ability to take more reasoned, and phased approaches to change, allowing you to replace systems with less fear and much less trauma, cost, and stress.

Security

Permissions, also become semantic. So instead of granting access to data across multiple systems in different ways: 


- (Warehouse) finance.transactions.amount
- (Data Lake) s3://data-lake/finance/transactions.parquet
- (Oracle) Transactions API permissions
- (Tableau) Finance theme permissions

With each of these systems needing individual management of permissions in vastly different ways, creating a massive burden on IT and security teams. Instead we can grant access to individual concepts, addressable by a single unified identifier: 

urn:wellcome:uda:finance:AwardedAmount

or:

urn:wellcome:uda:finance:Payments

or:

urn:wellcome:uda:funding:FundedGrant

We can broker access through our own query engine, or the system can push and translate those permissions down the underlying systems through a central point, reducing overall complexity and risk.

Because these identifiers are mapped through the graph of the ontology, the physical implementation can move, but the permissions will always stay meaningful.

AI

People automatically assume that AI is the destination across all of this, but I don't really see that.

I think AI is simply just another consumer, yet another application that happens to ask questions in natural language.

It uses the exact same concepts, exactly the same query engine, same governance, and same permissions.

The ontology doesn't exist for AI, but AI benefits from it's existence because it already exists.

The surprising part

Looking at all these outputs individually makes them seem like separate things, separate projects, that will need product roadmaps, engineering teams, and maintenance burden.

The truth is, they're not. They're all just Projections, configurable and in some cases automatically deployable. They're just different views of the exact same understanding of the organisation.

That's is one the main things that I hope people take away from this, the UDA isn't trying to solve dozens of problems, it's trying to solve one problem well enough that dozens of solutions actually just naturally fall out of it.

In the final article we'll look at where all this ultimately leads, which isn't just another dashboard, it actually takes us to some really interesting places.

Part 5: Bringing It to People