Lessons from building a knowledge graph platform

I created the first iteration of what is now Ontaura around 2012. It started as a product for managing field data such as inspection videos, reports and associated metadata, based largely on my experience in the Oil & Gas industry.

Its generic structure was based around people, objects, locations and events (we called it POLE). It worked well for its intended purpose, but over time some limitations became clear. The taxonomy was too rigid and the way relationships were defined was not flexible enough.

That first version taught me an important lesson: every assumption you hard-code into a generic platform eventually becomes a constraint when somebody wants to represent something you did not anticipate.

A team at IBM later approached Fusion242 and asked whether we could add time-series capabilities and connect the software to their database platform. Rather than simply adding those capabilities to the existing product, I decided to use the opportunity to refactor it as a platform.

The first rule was simple: we need to support anything.

If a customer wants to add something to the platform, they should be able to add it, define its metadata and describe how it relates to other things.

That led to a graph built around a small number of primitives:

• a hierarchical taxonomy defining types of things.

• entities representing instances of those types.

• relationships describing how entities are connected.

• attributes holding values against entities.

The important part was what I decided not to put into the graph.

Time-series data, for example, is better handled by systems designed specifically for it. The graph does not need to contain millions of telemetry values; it needs to know which entity those values belong to and how to retrieve them.

The same applies to documents. The graph does not need to store the file itself. It needs to know what the document is, where it is stored and what people, assets, locations or events it relates to.

Business logic also sits outside the graph. If I want to check all data-producing assets to see which ones have stopped sending data, that is useful operational logic, but it should not become part of the graph engine itself. The graph provides the entities, relationships and context; other services process them.

This separation has turned out to be one of the most important architectural decisions in Ontaura. It means the graph remains generic while specialist capabilities can evolve independently.

Generic does not mean devoid of domain expertise. For example, Ontaura has considerable functionality around time-series data, commissioning, file management, reporting and automation. It also provides a scripting layer so project-specific logic can be added without becoming part of the core platform.

One small example came from a healthcare project where we needed to plot blood pressure readings over time. Rather than add a “blood pressure chart” to Ontaura, we added a generic scatter-chart capability that could be driven from a script. The healthcare implementation used it for blood pressure, but the underlying capability could then be reused elsewhere.

That has become another useful rule: when a customer requirement exposes a missing capability, try to add the generic capability rather than the customer's specific implementation.

After more than a decade of building the platform this way, I think the boundaries around a knowledge graph matter just as much as the graph itself.

Keeping the core focused on taxonomy, entities, attributes and relationships has allowed Ontaura to expand across different operational domains without accumulating large amounts of domain-specific logic in the core platform.

We are now using this approach with implementations containing hundreds of thousands of entities, terabytes of time-series data and hundreds of different companies represented within a common taxonomy.

The knowledge graph gives us the structure and context. Everything else can evolve around it. It can also create a semantic representation of an operation that works particularly well with AI.