About

We wanted knowledge graphs to be accessible

Everyone who has built one agrees they are worth having and that getting one into production costs more than it should. We spent a long time working out which part of that cost was essential and which part was everybody rewriting the same code. The platform is what came out of the answer.

Book a demo Talk to us

the finding

The graph engineering lifecycle

Getting a knowledge graph from idea to production took about ten per cent thinking and ninety per cent engineering around the thinking. An ontologist and a subject-matter expert would agree a conceptual model. Then engineers, testers and devops would write a bespoke application to transform the source data into something the model could take, specific to that model and those sources. Then it would be tested, the model would need refining, as models always do, and the whole thing would be written again.

The consequence: the cost of a knowledge graph scaled with the number of times you changed your mind, which is a terrible property for something you are trying to get right.

gbo:Supplier/213847561 Northgate Ltd

gbo:Supplier/213847561 gbo:Supplier

gbo:Supplier/213847561 gbo:Part/HX-8841

gbo:Part/HX-8841 14 (integer)

n-triples 8 emitted, validated against supply-chain.ontology all passed
unmapped: 0 · quarantined rows keep their reason

No bespoke ingest code

Transformers are configured against the model rather than written against a schema, so refining the model does not mean rewriting an application. Changing your mind costs an afternoon.

The model is not the database

Definitions live in the platform and the database is an output. That keeps the modelling honest. You can shape the model around the domain rather than around what one vendor makes easy.

No-code, without a ceiling

The people who understand the domain are usually not the people who write the ingest. They should be able to build the model themselves, and the ones who do write code should not be locked out of it.

Registered in England & Wales

Data Lens Labs Ltd, incorporated February 2020 and trading as Graph.Build. Based in London.

Where we work

Remote-first across the UK, with delivery alongside your own teams. The platform runs in your infrastructure, so we rarely need to hold your data to help.

Consulting, when it helps

Some teams want the platform and nothing else. Others want an ontologist alongside them for the first model. Both are fine, and the second is not a prerequisite for the first.

Bring us the model you have been putting off

The interesting conversations start with a domain somebody has already tried to model once. Bring an OWL file, a database schema, or a whiteboard photograph.