You are here
The graph engineering lifecycle
Design, configure, engineer, iterate and automate graph model production: the whole lifecycle, without writing bespoke ingest code for each project.
Consulting
We built Graph.Build because we kept doing the same engineering by hand. The people who wrote it still take on the work it came from, mostly when a team wants an ontologist alongside them for the first model rather than a tool and good luck.
What we are brought in for
Almost every engagement starts with a model somebody has already attempted. The rest follows from getting that right.
The part that needs the experts and repays the time. A model that describes the domain rather than the schema of whichever system got there first. Pragmatic, published, and something the people who own the domain can read.
output an OWL model you keep
Large organisations describe the same thing four different ways in four different databases. Reconciling those into one model is most of the work in most projects, and it is work we have done in enough industries to recognise the patterns.
typical scope 4 to 12 sources
There is a large and growing world of public data. Linking your domain to DBpedia, Wikidata, GeoNames and the rest enriches what you already hold, which shows up in annotation, search and anything you build on top.
sources public and licensed
Making unstructured documents findable by pulling concepts out of them and linking them to the graph. Known concepts and unknown ones, so the model grows from what the corpus actually contains.
related the Document Transformer
We have helped build some of the largest digital publishing platforms in the world. Tagging assets with real concepts rather than free-text keywords is what makes automatic linking, data-driven pages and useful search possible at all.
sectors publishing and media
Off-the-shelf content systems assume a page is the unit. When the unit is a concept, you need something else. We have built these before and will reuse what we have rather than starting from a blank repository.
approach reuse, then build
Where we have done it
The industries differ. The problem underneath them rarely does.
Pharmaceuticals, life sciences, finance, engineering, e-commerce, publishing and media. Enough regulated ones that provenance and audit are not new requirements to us.
since 2015
From small companies with one product to organisations where the data architecture team is larger than most companies. Engagements are scoped to match, and a first one is usually small on purpose.
shape alongside your team
A model, the mappings that fill it, and people on your side who can change both. If the engagement ends and nothing can be altered without us, it did not work.
ownership yours
No. Consulting and the platform are sold separately and a good number of engagements have been modelling work with no software in them at all. The reverse is also true: most people who license the platform never speak to us beyond support.
You do. It is an OWL or RDFS file and it is yours, along with the mappings. That matters more than it sounds: an ontology you cannot take with you is a dependency dressed as a deliverable.
With your team, and deliberately. The subject-matter experts are on your side and the point of the engagement is that they end up able to do this without us. We are usually a small number of people working alongside a larger number of yours.
With a domain someone has already tried to model once and a conversation about why it stalled. That is enough to say whether this is a week of modelling, a first project, or something you do not need us for. We would rather say the last one early.
Consulting enquiry
Tell us what you are trying to describe and what has stopped you so far. That is usually enough for a useful first answer.
Goes to the consulting team. Not added to any marketing list unless you ask.