Formal ontology is necessary for multi-project data sharing across contextual, departmental and company boundaries. Simple labeling doesn’t scale across multiple projects and the need to do data lifecycle management and keep historical records so that they’re shareable without constant mapping and remapping. Here’s why:

1) Labeled property graphs trace their origin back to ad-hoc graph analytics projects. In an ad-hoc project, you’re just focused on that project. Ad-hoc projects are typically inside a single department for a single use case. Ad-hoc project designers are entirely focused on that project. They’re not thinking about other projects that might benefit from that data.

2) Formal ontologies such as RDF/OWL (Resource Description Framework and Web Ontology Language) trace their origins back to the need for multi-dataset integration, interoperation, and boundary crossing . Web pioneer Tim Berners-Lee had a vision of a table with hundreds of different columns, all logically integrated. Imagine the power of such a table if you’re an investment firm doing all sorts of analysis and creating a historical record that everyone in the investment firm can rely on, time and again.

Why semantic graphs?

Of course graphs and logically interlinked subgraphs are a more scalable means of managing structured data than tabular databases are. And so Berners-Lee and the other pioneers of web semantics 25+ years ago decided on standards-based graphs, controlled vocabularies, thesauri, taxonomies, and ontologies.

Those pioneers weren’t working in a vacuum. They tapped into what librarians had been doing for decades to make text and even image search feasible across topics, across context, across libraries. They tapped into what technical writers had done to make documentation searchable.

The key insight the web semantics pioneers had was to use library formalisms created for content and knowledge sharing, and apply those to tabular data as well. Semantic graphs enabled this.

All of a sudden, companies who committed to the standards and formalism could tap into all their data, not just their tabular data. Web semantics evolved into where graph AI suites and GraphRAG are today.

Why ontologies?

In order to build logically integrated graphs and scale the management of the data they describe for multi-project, multi-department, multi-company sharing purposes, you’ve got to agree on a single approach across all those multiple company contexts–an approach without lock in. With the right, standards-based design, that approach can flex, using taxonomies (for example) that were conceived in one context with one set of vocabularies in other contexts, with the help of an ontology, a multi-dimensional model, or means of high-level abstraction.

Ideally, companies, particularly multinationals who rely on tiers and networks of suppliers, agree on a standards based approach (RDF) for expressing all content, knowledge and data. Then ideally, they express their vocabs, taxos and ontologies in that same form. The pharma industry is doing this exact thing right now, with what their Pistoia Alliance has called the FAIR (findable, accessible, interoperable and reusable) data, and more recently, FAIR squared, which makes datasets agent-ready and reusable by machines.

If you want to share the data broadly and reuse your data, you’ve got to create tiers of abstractions. That’s where ontologies come in, at higher levels of abstraction. Ontologies tie all the controlled vocabs, thesauri and taxonomies created at lower levels of abstraction together.

How ontologies bring multiple heterogeneous sources together into a unified whole

ECOLOPES, a European research project, set out to make cities more nature-friendly by helping architects and ecologists collaborate effectively. The obstacle was data. These two fields stored information in fundamentally incompatible ways — architects worked with building blueprints and 3D models; ecologists worked with species lists, habitat maps, and biological interaction data. The result was a tangle of mismatched formats, incomplete records, and siloed databases that made meaningful collaboration nearly impossible.

The solution

The team built a knowledge graph that pulled this scattered data into a unified, queryable system. The semantic backbone was an ontology — a formal definition of concepts and relationships across both domains — that gave the system a shared vocabulary.

Because it understood that an architect’s CAD object and an ecologist’s species record could refer to the same real-world thing, it could bridge the two worlds without forcing either side to abandon their existing tools or data formats.
Some data was physically consolidated into the central system; other data, like complex solar radiation models, stayed in its original database but remained fully accessible through the ontology layer — no migration required.

The new capability

Architects could query across ecological and architectural data simultaneously — asking, for instance, which tree species interact with a particular insect — and get immediate, reliable answers without needing ecological expertise themselves. When designers adjusted elements in their design software, the system returned instant visual feedback: green for choices that satisfied ecological constraints, red for those that didn’t.

Significance of the new capability

What made this work wasn’t just having an ontology — it was applying one at the point where two expert communities needed to share data that had never been designed to be compatible.

The ontology didn’t replace either field’s data; it sat above it, making the whole greater than the sum of its p/arts. The practical payoff was faster decisions, fewer errors from manual data translation, and designers who could explore ecological consequences of their choices in real time.

Ontologies provide the backbone

Formal ontologies — standards-based frameworks for defining concepts and their relationships — exist to solve a problem that simpler labeling systems can’t: sharing data reliably across projects, departments, and organizations over time. They trace back to the same insight that librarians and web pioneers shared: if you want diverse, heterogeneous data sources to work together without constant manual remapping, you need agreed-upon, standards-based abstractions sitting above the data itself.

The ECOLOPES project illustrates this in a concrete way — architects and ecologists had incompatible data that an ontology unified into a single queryable system, letting designers ask cross-disciplinary questions and get real-time answers, without either side abandoning their existing tools or formats.

Some explanations in this post appeared originally on Quora.

For more information:

Blumauer, Andreas, and Helmut Nagy. The Knowledge Graph Cookbook: Recipes that Work. Vienna: edition mono/monochrom, 2020.https://www.poolparty.biz/the-knowledge-graph-cookbook

Graphwise. “Driving Ecological Building Innovation Through Multi-Disciplinary Data Integration.” Case Study. August 27, 2025. https://graphwise.ai/success-story/vienna-university-of-technology-accelerating-ecological-building-innovation-with-multi-disciplinary-data-integration-and-iteration/.