You're on GraphDB (Graphwise, Formerly Ontotext): Keep Your RDF Knowledge Graph True
Already on Graphwise GraphDB (formerly Ontotext)? Data Workers brings your ontology and taxonomies in as governed context and keeps the graph's feeds true, with approvals.
Your enterprise's meaning lives in RDF. The ontology defines Product, Supplier, Plant, Regulation and how they relate. Taxonomies curated in PoolParty or Graphwise Graph Modeling give every product line or risk category a SKOS concept with labels and a place in the hierarchy. Instance data lands in GraphDB repositories as named graphs, through SPARQL Update, the Kafka Sink connector or a virtual repository. Reasoning fills in what the rules imply, SHACL shapes check the graph, and Talk to Your Graph and the GraphDB MCP server let people and agents ask questions. GraphDB holds the meaning. Data Workers keeps it true: Data Context Wizard brings your ontology and vocabularies in as context with provenance, joins them to lineage, quality and usage, and when a feed breaks or a definition drifts, Data Workers proposes and carries the fix with approvals and a receipt.
The graph is only as good as what feeds it. A product master code that splits or a renamed dbt column reaches the graph through the nightly load, and a Graph RAG agent answers from whatever landed. That seam between the warehouse and the graph is the job this guide covers.
Key takeaways
- •GraphDB keeps its job. Repositories, ontologies, reasoning, SHACL, Talk to Your Graph and your load jobs stay as they are. Data Workers works next to them from day one.
- •Your ontology and taxonomies become governed context. Data Context Wizard puts them next to warehouse lineage, quality, usage and a named owner on every fact.
- •Feeds are watched before the load. Upstream code changes, unmapped values and stale tables are caught in the warehouse and fixed before the RDF load runs.
- •Writes stay gated. Your team's assistant reads the graph through the GraphDB MCP server, side by side with Data Workers. Approved fixes land in dbt and your own load pipeline, with a blast radius, an approver and a rollback path.
- •Start with a pilot. One repository, read-only, with its feeds watched; then one fix class in one domain, on the ladder from L0 manual to L4 autonomous.
GraphDB holds the meaning. Data Workers keeps it true.
GraphDB is a strong home for standards-based meaning. Graphwise describes it as "an enterprise-grade semantic graph database that supports RDF and SPARQL". Version 11.5 (11.5.0 on August 19, 2026; 11.5.1 on September 23, 2026) adds a repository maintainer permission, multiple authorization sources and a unified Prometheus metrics endpoint. Its built-in MCP server runs on GraphDB's own HTTP port at /mcp, with repository listing, full-text and similarity search, IRI discovery, ontology schema extraction and a SPARQL query tool. Administrators can publish MCP prompts, pre-validated SPARQL templates the model fills in.
Outside the graph sits everything that decides whether it is right: the ERP, ingestion, dbt models, the orchestrator that runs the RDF load and the semantic layer. Data Workers covers that side with one context, one approval flow and one audit trail.
Here is an evening with Data Workers next to a product knowledge graph. This is an illustration, not a customer case.
| Time | System | What happens |
|---|---|---|
| 17:20 | SAP S/4HANA | The product team splits category code AUDIO into AUDIO-HOME and AUDIO-PRO in the product master |
| 18:00 | Fivetran | The sync lands the updated product records in Snowflake |
| 18:30 | dbt | dim_product builds; its not_null and relationships tests pass, because both new codes are present and valid in the ERP |
| 18:35 | Data Workers | It flags two category codes with no matching concept in the product taxonomy: 1,240 products would lose their category link at the next load |
| 18:40 | GraphDB | The taxonomist's assistant reads the concept scheme over the GraphDB MCP server with a SPARQL SELECT and hands it to Data Workers: concepts match on skos:notation, and AUDIO has no narrower concepts yet |
| 18:50 | Airflow | Data Workers opens an incident ahead of the 02:00 RDF load, with the cause, the 1,240 products and the Talk to Your Graph agent that answers from them |
| 19:20 | dbt | Data Workers proposes a diff that maps both new codes to the existing AUDIO concept until the taxonomy catches up, with its blast radius: one seed, two models, one load DAG, one repository |
| 19:25 | Graph Modeling | Data Workers routes a proposal to the taxonomy owner: add two narrower concepts under AUDIO, with the codes and product counts attached |
| 20:10 | Spellbook | The taxonomy owner reviews the diff and the impact and approves; dbt CI passes |
| 02:00 | Airflow + Kafka | The load publishes each product's named graph through the Kafka Sink connector with replace-graph; every product maps to a concept |
| 02:20 | GraphDB | Data Workers verifies the source table, the taxonomist's assistant confirms with a SPARQL count that no product lacks a category, and Data Workers writes the receipt |
| 09:00 | Talk to Your Graph | A category manager asks for audio sales by product line; the answer includes all 1,240 products |
Without that check, the load would have written 1,240 products whose category pointed at a code no concept knows, and the morning answer would have quietly left them out. GraphDB did exactly what it was asked to do. The fix was upstream, in systems the graph doesn't run, it went through an owner's approval first, and the taxonomy change stayed with the taxonomy owner.
| Job | What GraphDB does | What Data Workers does |
|---|---|---|
| The meaning | Stores the ontology, taxonomies and instance data as RDF and infers what the rules imply | Reads classes, properties and concept schemes as context and joins them to lineage, quality, usage and owners |
| The questions | Answers through SPARQL, GraphQL, similarity search and Talk to Your Graph | Makes sure the data and definitions behind those answers are correct and current |
| The feed | Accepts loads through SPARQL Update, templates, the Kafka Sink connector and virtualization | Watches the tables, codes and keys that feed the graph and catches breaks before the load |
| The break | Validates what it holds with SHACL | Detects the upstream change and traces it across SAP, Fivetran, dbt and Airflow to the graph |
| The fix | Runs the update your pipeline sends | Proposes the change with its blast radius, routes it to a named owner, lands it in dbt and the load pipeline |
| The proof | Holds the graph state after the load | Verifies with SPARQL after the reload and writes a receipt with the cause, diff, approver and rollback |
| The vocabulary | Holds the concept scheme the taxonomist curates | Keeps the warehouse codes, the semantic layer and the taxonomy in step, with conflicts routed to an owner |
Why doesn't GraphDB just do this itself?
Because GraphDB built a database for the hardest part of its job: holding standards-based meaning at scale, with reasoning and validation, for any domain. Changing SAP, Fivetran, dbt and Airflow, which belong to other vendors and your data team, is a different product with a different liability.
GraphDB's own design draws that line sensibly. Its MCP SPARQL tool executes SELECT, CONSTRUCT and DESCRIBE queries, so agents read. The MCP endpoints default to anonymous READ, and GraphDB's access control still applies at the repository level, so administrators decide what agents see. SHACL checks the data graph against its shapes, the right check for what the graph holds. None of that reaches back into the warehouse to fix a code before it arrives, and it shouldn't: a database that serves many teams and agents should stay predictable.
Data Workers is the product on the other side of that line. It knows what a change will touch across systems, routes it to the owner, applies it reversibly through the pipelines you already run, verifies the result in the graph and keeps the record.
Every tool owns a slice. Data Workers covers the whole lifecycle
GraphDB owns one slice of the data lifecycle, and owns it outright: holding the enterprise's meaning as RDF, and the reasoning, search and Graph RAG built on it. Each point tool adds another console, contract and handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail, and builds on the graph you already run.
| Stage | Data Workers | GraphDB | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 9.5 | GraphDB's home stage: ontologies, taxonomies and instance data as RDF, with reasoning over RDFS and OWL 2 RL/QL, served to agents through its MCP server. Data Workers brings that model in as context with provenance, next to lineage, quality and usage. |
| Analytics & Insights | 8 | 8.5 | GraphDB's other home stage: SPARQL, GraphQL, similarity search and Talk to Your Graph answer questions across linked data. Data Workers' Insights agent answers through governed metric definitions. |
| Data Quality | 8 | 5 | SHACL shapes and consistency rulesets check what is already in the graph. Data Workers checks the warehouse tables that feed it and repairs breaks before a load. |
| Observability & Incidents | 8.5 | 3 | A unified Prometheus endpoint and query logs report on the database itself. Data Workers detects a bad feed, traces it across systems, fixes it and verifies the graph after the reload. |
| Pipelines & Ingestion | 8.5 | 4.5 | The Kafka Sink connector, SPARQL templates and Ontop virtualization bring data in. Data Workers builds, reruns and backfills the pipelines behind those loads with approvals. |
| Schema & Migration | 8 | 3.5 | Ontologies evolve inside the graph by design. Data Workers detects upstream schema and code changes and assesses their impact on every model and mapping before they land. |
| Governance & Access | 8.5 | 6 | Strong over its own repositories: user roles, repository permissions, the new repository maintainer permission and multiple authorization sources in 11.5. Data Workers proposes and applies grants across your data platforms by policy. |
| Security & Privacy | 8 | 5.5 | Strong for its own estate: Local, LDAP and OAuth users, OpenID and Kerberos, TLS and a security audit trail. Data Workers flags sensitive column names in pull request review and proposes masking for the owner. |
| Cost / FinOps | 8 | 2 | Licensing covers GraphDB itself. Data Workers traces credits in the warehouse that feeds the graph to the dbt model behind them and drafts the fix for its owner. |
| MLOps & Models | 7.5 | 4 | Embedding models and similarity indexes power vector search over the graph. Data Workers keeps the data under your models healthy and connects to MLflow and W&B. |
How GraphDB and Data Workers work together
Your engineers and agents stay where they are: Claude Code or Cursor for SPARQL and dbt, Talk to Your Graph for business users. Spellbook Data Catalog (in preview) is where the data team looks: each proposed change, its blast radius, its approver and its rollback. Between them, Data Context Wizard keeps one governed context graph, the Data-Agents Swarm does the work with more than 20 specialist agents, the Autonomous Data-Conductor runs each fix end to end (detect, diagnose, fix, review, verify, remember), and per-domain guardrails hold approvals, receipts and rollback.
What Context Wizard does with your graph. It reads the ontology and the concept schemes your taxonomists curate, plus the codes each load maps to IRIs, and records them as context with provenance: where each fact came from, when and who owns it. It joins that to warehouse lineage, so a product's category in the graph traces back through dim_product and Fivetran to the SAP field, and serves one governed view to every agent through tools like explain_table and trace_cross_platform_lineage. When the taxonomy and your semantic layer disagree, the conflict goes to a named owner. Your context stays yours: Data Workers exports its context graph and audit chain in JSON-LD and as Open Knowledge Format bundles.
Setup over MCP today. GraphDB connects over its built-in MCP server today, alongside Data Workers' own agents in the same client. Those agents are MCP servers from the open-source repository: clone it and add start-agent.sh entries to your client config, as the client setup docs show. Point the client at GraphDB's /mcp endpoint (streamable HTTP; stdio-only clients use the MCP gateway fork Graphwise maintains) with a GraphDB user that holds read rights on the repositories in scope and nothing more.
// Example: .mcp.json for Claude Code (Cursor uses the same mcpServers shape)
{
"mcpServers": {
"graphdb": {
"type": "http",
"url": "https://<your-graphdb-host>/mcp",
"headers": {
"Authorization": "Basic <graph_reader credentials from your secret store>"
}
},
"dw-context-catalog": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-context-catalog"]
},
"dw-schema": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-schema"]
},
"dw-quality": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-quality"]
}
}
}List the tools in your client with its own command (for example /mcp in Claude Code). An engineer can then ask "which warehouse columns feed the product taxonomy links, and is anything unmapped tonight?" and get the concept scheme from GraphDB, lineage from trace_cross_platform_lineage, the latest run_quality_check results on dim_product and downstream reach from blast_radius_analysis, in one answer. If your graph team publishes MCP prompts, Data Workers' agents use the same validated templates your people do.
Where writes go. Fixes land where your team already reviews change: a dbt diff for the owner to merge, the load DAG, the RDF mapping or the Kafka Sink configuration. Your load pipeline runs the update after the owner approves, as it does today. Taxonomy and ontology changes go to their owner as proposals with evidence, made in Graph Modeling or your ontology editor. Writes to the graph stay on a known path, run by a known job.
One request, L0 to L4. The autonomy ladder is set per domain.
- •L0 manual. Data Workers is connected but not acting. Your engineer traces the feed by hand.
- •L1 observe. Data Workers watches the feeds, flags breaks before the load and explains the cause with lineage and owners.
- •L2 propose. Data Workers drafts the dbt diff or load-job change with its blast radius; the owner approves in Spellbook before anything runs.
- •L3 act reversibly. For proven change classes, such as rerunning a failed load for the affected named graphs, Data Workers applies the change, verifies the tables behind the named graphs and can roll it back.
- •L4 autonomous. For a scoped, trusted class like late feeds into one repository, Data Workers fixes and verifies on its own and posts the receipt.
For the safety model behind each step, read is it safe to let AI agents change production data, and for where data and credentials live, read where does our data go.
The same pattern holds for every source of meaning. See the hub, bring your own context, and the guides for teams on Stardog, Neo4j and Fabric IQ. For background, read ontology for enterprise data, semantic layer vs knowledge graph for LLM grounding and what is a context graph.
What changes for your team
Knowledge graph teams spend much of the week chasing unmapped codes, reconciling vocabularies with the warehouse and rebuilding named graphs after a bad load. With Data Workers next to GraphDB, those jobs run on autopilot at the level you set.
- •Incidents. An upstream change that would orphan instances from the taxonomy is caught, traced and fixed before the load.
- •Data quality. Every code the graph maps to a concept gets an accepted-values check against the concept scheme in the warehouse.
- •Cloud spend. Cleanups of staging tables built for retired RDF loads are proposed to the owner after a dependency check.
- •Access. A request to read a sensitive repository arrives as a time-boxed grant proposal for its owner, with the policy behind it.
- •Audits. Every change to a feed, mapping or definition carries an approver, a diff and a rollback path, so "where did this triple come from?" has an answer.
- •Migrations. When the warehouse under the graph moves, the feeds move in parity-checked waves while the graph keeps loading.
The graph team gets its week back for ontology design, new domains and Graph RAG work.
Keep GraphDB, or consolidate?
Keep GraphDB if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
For most teams, the ontology, taxonomies, reasoning rules, SHACL shapes and Talk to Your Graph agents belong in GraphDB, and standards-based RDF keeps that meaning portable. What teams consolidate is the tooling around the graph: a separate quality tool for the feeds, a homegrown script that compares triple counts after each load, a spreadsheet mapping warehouse codes to concept IRIs. Data Workers runs those jobs with one context, one approval flow and one audit trail. If you are weighing building this layer yourself on the GraphDB MCP server, read build it ourselves with Claude Code and MCP servers: the connection is the easy part; cross-system context, approvals and rollback are where the work is.
The case for your CFO
The outcome: the knowledge graph the company invested in gives answers people can act on. Product analytics, regulatory mapping and Graph RAG all rest on the data that feeds the graph, and Data Workers keeps it right every night.
The risk story is plain. Your team's assistant reads the graph through the GraphDB MCP server with a read-only user; Data Workers' agents never call it. Every change Data Workers proposes shows its blast radius, goes to a named approver, lands through your own pipelines, is verified after the reload and leaves a receipt: who approved it, what it touched and how to undo it. Autonomy is set per domain from L0 manual to L4 autonomous and can be dialled back at any time. There is zero migration.
Why now: agents and Talk to Your Graph read the graph directly, so a bad load reaches everyone who asks. The first win is one repository with its feeds watched, so the next upstream change is caught before the load instead of after the answer. What stays the same: your ontology, vocabularies, SPARQL, GraphDB license, repository permissions and review process. The path is a pilot (see pricing), and the pilot is credited in full against the first year. For the numbers, see the ROI of agentic data operations.
The sentence to repeat upstairs: "Our knowledge graph is only as good as what feeds it; Data Workers keeps the feed and the meaning right, and fixes it with an approval and a receipt."
Getting started
Start with a pilot. Pick one repository agents or analysts already rely on, such as the product graph, connect the GraphDB MCP server read-only next to Data Workers, and let Data Workers watch its feeds and taxonomy mappings before enabling the first fix class. The pilot path and plans are on the pricing page, and the pilot is credited in full against the first year.
FAQ
Does Data Workers write to our GraphDB repositories? Your team's assistant reads the graph through the GraphDB MCP server with a read-only user. Approved fixes land in dbt, the load DAG, the RDF mapping or the Kafka Sink configuration, and your pipeline runs the update after the owner approves in Spellbook.
GraphDB is now Graphwise. Does that change anything? No. Ontotext and Semantic Web Company joined forces as Graphwise in 2024; GraphDB continues as Graphwise GraphDB, documented at graphdb.ontotext.com (version 11.5). Data Workers connects to it the same way, over its MCP server.
Our taxonomies live in PoolParty. Can Data Workers use them? Yes. PoolParty is now part of the Graphwise Platform. When its SKOS vocabularies are published into GraphDB, your team's assistant hands the concept schemes to Data Workers, which checks warehouse codes against them and sends change proposals to the taxonomy owner, who makes the change in their own tool.
How does lineage reach from a triple back to the source? Context Wizard records which warehouse tables and columns feed each class, property and concept mapping, and trace_cross_platform_lineage follows that back through dbt and ingestion to the source field.
Does this replace Talk to Your Graph, reasoning or SHACL? No. They stay where your Graph RAG, inference and validation run; Data Workers keeps the data and definitions under them correct and current.
Is our context locked in once it's in Data Workers? No. Your ontology stays in GraphDB in open RDF, and Data Workers exports its own context graph and audit chain in JSON-LD and as Open Knowledge Format bundles.
Sources
- •Graphwise, GraphDB 11.5 documentation (overview; vendor Graphwise, formerly Ontotext), https://graphdb.ontotext.com/documentation/11.5/ (checked Oct 2, 2026)
- •Graphwise, GraphDB release notes (11.5.0 Aug 19, 2026; 11.5.1 Sept 23, 2026), https://graphdb.ontotext.com/documentation/11.5/release-notes.html (checked Oct 2, 2026)
- •Graphwise, Using GraphDB's LLM tools with external clients (MCP server, tools, security, MCP prompts), https://graphdb.ontotext.com/documentation/11.5/using-graphdb-llm-tools-with-external-clients.html (checked Oct 2, 2026)
- •Graphwise, Talk to Your Graph (labelled experimental in the 11.5 docs), https://graphdb.ontotext.com/documentation/11.5/talk-to-graph.html (checked Oct 2, 2026)
- •Graphwise, Kafka Sink Connector, https://graphdb.ontotext.com/documentation/11.5/kafka-sink-connector.html (checked Oct 2, 2026)
- •Graphwise, Updating data with SPARQL templates, https://graphdb.ontotext.com/documentation/11.5/updating-data.html (checked Oct 2, 2026)
- •Graphwise, SHACL validation, https://graphdb.ontotext.com/documentation/11.5/shacl-validation.html (checked Oct 2, 2026)
- •Graphwise, Accessing relational databases with data virtualization, https://graphdb.ontotext.com/documentation/11.5/virtualization.html (checked Oct 2, 2026)
- •Graphwise, GraphDB security, https://graphdb.ontotext.com/documentation/11.5/security.html (checked Oct 2, 2026)
- •Graphwise, GraphQL, https://graphdb.ontotext.com/documentation/11.5/graphql.html (checked Oct 2, 2026)
- •Graphwise, Graphwise GraphDB product page (editions, MCP support), https://graphwise.ai/components/graphdb/ (checked Oct 2, 2026)
- •Graphwise, Graph Modeling (taxonomy and ontology management, SKOS), https://graphwise.ai/components/graph-modeling/ (checked Oct 2, 2026)
- •Graphwise, About us (2024 merger of Semantic Web Company and Ontotext), https://graphwise.ai/about-us/ (checked Oct 2, 2026)
- •PoolParty, "PoolParty is now part of the Graphwise Platform", https://www.poolparty.biz/ (checked Oct 2, 2026)
- •Data Workers, Client setup (open-source docs), https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 2, 2026)
- •Data Workers open-source repository, agent tools and start-agent.sh, https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 2, 2026)