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
graph.build is the only platform on which you can design, test and build a semantic layer that follows W3C Semantic Web standards and is graph vendor agnostic. The model is not locked to a warehouse, a metrics product, or a graph database vendor.
What people mean
Here are three examples. These, and many others, do not conform to the W3C Semantic Web standards. Those standards have been rigorously tested, they are widely adopted, and they are database vendor agnostic. graph.build fully supports them.
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 as OWL and RDFS. You test the model against real records here, so a mapping that does not conform is flagged before it runs. This is the design 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 let you design, test and build against W3C Semantic Web standards, and leave the store as a choice. Most products called a semantic layer do one of those jobs, and not against those standards. graph.build is built to do all of it.
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, in OWL, RDFS, RML and R2RML. Those are W3C standards, and they do not belong to a database vendor. 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, written to W3C Semantic Web standards so the model is not bound to one vendor. graph.build is the second kind: definitions you can design, test and 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: design, test and build, on W3C Semantic Web standards, without binding the model to one graph vendor. 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. If you are evaluating one that does all of it, the comparison to make is whether the model is OWL you can take with you and whether the mappings are RML you can read.
The ontology is OWL and RDFS. The graph is RDF. The mappings are RML and R2RML. Provenance uses W3C PROV. The Writers speak SPARQL, and also openCypher and Gremlin so the same model can land in a property graph store. Those are the standards that make the layer portable. A semantic layer that uses a private format is a layer you rebuild when the vendor changes.
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.