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.
Semantic layer
Most things called a semantic layer describe tables for a BI tool. graph.build is the only dedicated semantic layer platform that authors the ontology and builds the knowledge graph from your systems, then writes it to any of the supported graph databases. The model is not locked to a warehouse, a metrics product, or a graph database vendor.
The phrase, three ways
They share a name and almost no mechanism. Knowing which one someone is buying is the whole problem, because the three do not substitute for each other.
dbt, Cube, Looker, the warehouse vendor's own layer. A governed set of measures over tables, so two dashboards stop disagreeing about revenue. It is a good product for that job. It does not author an ontology, and it does not build a knowledge graph.
A place to define classes, properties and concept schemes. The vocabulary is real. The graph of your records is somebody else's project: a second tool, a second team, and a mapping that drifts the moment either side changes.
Modelling and load, built around one store. Excellent if you have already picked that vendor and intend to stay. The model takes on the shape the database makes easy, and moving it later is a rewrite.
Both jobs, one platform
A semantic layer that only defines meaning leaves the load to someone else. A pipeline that only moves data leaves the meaning in a slide deck. graph.build is built so neither can drift from the other.
01 · ontology
Entities, relationships, constraints and the vocabulary the business already uses, as RDF or as a labelled property graph, on one canvas. Versioned, reviewed, and published. This is the ontology-building half of a semantic layer: not a diagram that gets redrawn after the pipeline is finished, but the model the pipeline reads.
The consequence: “what is a customer” has one owner, and the graph cannot quietly invent a second answer.
gbo:Customer the type
legalName xsd:string
holdsAccount gbo:Account
registeredIn gbo:Jurisdiction
incorporatedOn xsd:date
published as OWL, or as a property graph schema, from the same model
02 · graph
SQL, REST APIs, Kafka and files are mapped onto that model as RML and R2RML, which are open W3C specifications. Each node exists because a row did. Change data capture keeps the graph in step. A Writer then loads it, over SPARQL, openCypher or Gremlin, into the database you already run. This is the graph-building half, and it is the half ontology platforms leave on the table.
The consequence: the semantic layer is not a description of the estate. It is the estate, typed, current, and queryable.
n-triples
11 emitted from one record, checked against customer.ontology
all passed
unmapped: 0 · a mapping that does not conform to the model is flagged before it runs
What each kind actually does
A dedicated semantic layer has to author the ontology, build the graph from sources, and leave the store as a choice. Most products called a semantic layer do one of those. graph.build is built to do all three.
a green dot is a yes · the last row is deliberate: a metrics layer is the right tool for measures, and this is not one
Platform-agnostic
A semantic layer bound to one warehouse, one metrics product or one graph database is a layer you will rebuild. graph.build keeps the ontology and the mappings in the platform. The database is an output. Switching vendor is a configuration change and a re-run, which also means you can benchmark two of them on your own model before committing to either.
one model · four targets
supply-chain.model · v14
Same model, four generated loads. Changing target is a configuration change and a re-run.
A semantic layer is the place the business writes down what its data means, so a dashboard, an analyst or an agent reads the same definition. In the warehouse world that usually means governed metrics over tables. In a knowledge graph it means an ontology plus the graph built from it. graph.build is the second kind: definitions you can govern, and a graph those definitions actually fill.
A metrics layer describes tables so two dashboards agree about a number. A graph-based semantic layer describes entities and the relationships between them, so a question that crosses systems, such as whether this customer is the account holder in billing, has an answer that is not a join you write each time. They are complementary. If you have a metrics layer, keep it. It will not author an ontology or materialize a knowledge graph, and this platform will not replace it.
An ontology is the vocabulary: the classes, the properties, the rules. A semantic layer that stops there still needs a second system to become a graph of your records. graph.build treats the ontology as the first half of the layer and the mapping and load as the second, so the picture on the canvas is the thing the Transformers run. The longer explanation of ontologies is the fundamentals guide.
The combination is rare, and that is the claim. Metrics layers do not author ontologies or build a knowledge graph. Ontology platforms do not run the load against your systems. Graph database tooling is built around one store. A dedicated platform that does both jobs and treats the database as a deployment decision is not a crowded category. If you are evaluating one that does, the comparison to make is whether the model is portable and whether the mappings are a file you can read.
No. You pick one, and you can change it. The Writers speak SPARQL, openCypher and Gremlin, which covers Amazon Neptune, Neo4j, Stardog, Memgraph, GraphDB, RDFox and the rest of the compatibility page. The model does not have to be rewritten when the store does.
Yes. The graph is queried in the database you already run, under the access control you already put there. Studio also publishes a read-only MCP server so an assistant can read the ontology itself: the classes, the properties and the relationships, before it asks a question. That is context, not a pile of chunks. The longer version is the Context for AI page.
Next
Forty-five minutes on your own domain. We will model that corner and show you the ontology and the graph as one artefact, writing into a store you choose.