Platform / Studio
Where the model gets made
Studio is the no-code interface at the centre of the platform, and because the Transformers and Writers are wired into it, it is closer to an IDE for graph production than a modelling tool. Model, mappings, test runs and generated queries are all in one place, on your real data.
Input sample.json
Supplier
LegalName
DunsNumber
Part
Description
LeadTimeDays
IRI Config
http://graph.build/ontology/
supply-chain.ontology · v14
1Output Model
Test Model Results
rdf:type gbo:Supplier
hasLegalName Northgate Ltd
hasDuns 213847561
hasLeadTime 14 (integer)
8 triples · subject, predicate, object
download as n-quads
1 The source, parsed. sample.json is read into its fields. Drag one onto the canvas and the mapping exists. There is no ingest code to write for it.
2 Identity, not a row number. The line above the class name is the field the IRI is built from, so the same supplier resolves to the same node across every source that mentions it.
3 The predicate is the edge. Relationships are named on the connector rather than beside it, because the name is the relationship. That is what ends up in the triple.
4 Test before you write. Run the model against the sample and read the triples it produces, before anything is written to a database.
Visual modelling
One model, both formalisms, generated
Semantic and property graph models are built in the same editor, from the same source data. When the design is done you press Generate, and Studio produces the shape the target expects: an ontology in OWL and RDFS on the semantic path, node and edge definitions on the property graph path. Both are standard, both are readable, and both are yours.
Class hierarchy
gbo:Supplier owl:Class
gbo:hasLegalName xsd:string
gbo:hasDuns xsd:string
gbo:hasRiskTier xsd:string
gbo:Part owl:Class
gbo:hasSku xsd:string
gbo:hasLeadTime xsd:integer
gbo:Site owl:Class
gbo:hasCountry xsd:string
gbo:hasPart owl:ObjectProperty
gbo:madeAt owl:ObjectProperty
Labels & properties
:Supplier node label
legalName string
dunsNumber string
riskTier string
:Part node label
sku string
leadTimeDays integer
:Site node label
country string
HAS_PART relationship
MADE_AT relationship
mapping
Source fields become meaning
Drag a column onto an attribute and the mapping exists. Where the source needs work first, over a hundred built-in functions handle the reshaping, including parsing, lookups, concatenation, date and unit normalisation, and you can register your own for the cases that are only yours. Every mapping is a file that lives with the model and versions with it.
The consequence: a published ontology can inform the mapping or restrict it, so a mapping that does not conform is caught while somebody is making it. Records that fail during a run go to a dead letter queue, which is a list you can work through and reprocess rather than a number that went down.
n-triples
8 emitted, validated against supply-chain.ontology
all passed
unmapped: 0 · quarantined rows keep their reason
Ontology governance
One definition of Customer, and a record of every change to it
Governance here is not a permission matrix. It is the ontology and its history. You agree what a Supplier is, generate it, publish it, and every model built afterwards is either informed by that definition or restricted to it, so the second team to arrive cannot quietly invent a second Supplier.
version control
Every change is a commit
Studio is backed by git. Saving a model writes a revision, and the history pane lists them with who made the change and what the model looked like at that point. Commit a named checkpoint yourself when a version is worth marking, restore an earlier revision when a direction turns out to be wrong, or make a copy from one and explore without touching what everyone else is using. Roles stay deliberately simple, an admin manages the instance and its users and everyone else builds, because what protects the model is the history rather than the seat.
The consequence: “who changed the definition of Customer, and when” is a question with an answer, and going back to the version before they changed it is a click rather than a restore from backup.
Collaboration
One person edits. Everyone else has it open.
Studio is multi-user without being simultaneously multi-writer, which for a governed model is the right way round. One person holds edit control while the rest have the model open read-only, and control is handed over deliberately rather than raced for. Because the model is visual, the subject-matter experts who know what a Supplier actually is can follow it, and take the pen, without learning a query language.
Input
Class
Literal
one writer at a time · handover is explicit · every publish carries a version
Where it sits
Studio authors it. Transformers run it. Writers land it.
Three component types, two hand-offs, and both hand-offs are files you can read. Every one of them is a Docker container, deployed on-premise or in your own cloud.
Studio
Authors the model and the mapping files, validates them, publishes a version.
outputs · model + .map
v14
Transformers
Execute the mappings against SQL, APIs, Kafka and files. Resolve identity, quarantine what does not fit.
outputs · resolved records
batches + cdc
Writers
Emit your database's native load in insert or update mode, and keep it current through CDC.
outputs · your graph database
See Studio on your own model
Bring a source system and the thing you have been trying to model. A working session gets further than a demo.
- 45 minutes, your data, no installation
- You keep whatever we model
- No obligation to buy anything