Back to Knowledge Base

metaphactory — the knowledge-graph application layer

📖 6 min read

What metaphactory is

metaphactory is a commercial enterprise knowledge graph platform built by metaphacts GmbH, a German software company that Digital Science acquired on 23 January 2023; metaphacts continues to operate as a Digital Science company. Digital Science's announcement describes metaphacts as "a knowledge graph and decision intelligence software company" whose platform "supports collaborative knowledge modeling and knowledge generation and enables on-demand citizen access to consumable, contextual and actionable knowledge."

The distinction that matters most when you place metaphactory on your mental map: it is not a graph database. It is the application and knowledge-engineering layer that sits on top of one. metaphactory speaks SPARQL to a triplestore you bring, and spends its own effort on the things a triplestore deliberately does not do — modeling ontologies, authoring instance data, searching, visualizing, and letting people assemble apps over the graph without writing a front end.

The platform is described academically in "metaphactory: A platform for knowledge graph management" (Semantic Web Journal), which is the best source if you want the design rationale rather than the marketing.

Architecture and the standards it stands on

metaphactory is an unusually orthodox W3C-stack product. It builds on:

  • RDF — the data model (triples, not property graphs).
  • OWL and RDFS — ontology and schema definition.
  • SHACL — shapes, constraints and validation. In metaphactory, SHACL does double duty: it validates data and drives the generated authoring forms.
  • SPARQL 1.1 — the query language, and also the platform's integration seam.
  • SKOS — vocabulary and taxonomy management.
  • DCAT / Dublin Core — data-catalog description.

The load-bearing architectural choice is that metaphactory acts as a vendor-independent proxy over any SPARQL 1.1-compliant repository. It does not ship its own storage engine, so the same deployment can sit on top of Ontotext GraphDB, Stardog, Blazegraph, Amazon Neptune, or SAP HANA Cloud's Knowledge Graph Engine. Swapping the store underneath is a configuration concern, not a rewrite. Deployment is container-based (Docker Compose templates), with an AWS Marketplace listing that pairs it with Amazon Neptune.

The practical consequence for an engineer: your portability lives at the SPARQL boundary. Anything you express in RDF/SHACL/SPARQL travels with you; anything you express in metaphactory's proprietary app-configuration layer does not.

What it actually gives you

Semantic knowledge modeling. A visual ontology editor aimed at domain experts rather than only knowledge engineers — plus vocabulary/taxonomy management (SKOS), versioning, governance workflows, and Git integration for the models themselves. Recent releases add AI-assisted semantic modeling, where an LLM proposes model structure that a human curates.

Knowledge authoring. SHACL-driven semantic forms, so the shape of the ontology generates the shape of the data-entry UI. Constraint-checking is not a separate validation pass bolted on later — it is the same SHACL that defined the form.

Search and discovery. Faceted semantic search, autocomplete, relevance ranking, and graph pathfinding (how is A connected to B?), over both structured graph data and linked unstructured content.

Visualization. Graph, table, chart, timeline and map components that are bound to SPARQL queries and update as the query does. These are embeddable, which is what makes the next item possible.

Low-code application building. The headline capability: a templating/widget system that lets you compose search interfaces, dashboards, and data-entry apps over the graph declaratively, without building a bespoke front end. This — not storage, not reasoning — is metaphactory's real product.

Neuro-symbolic / LLM features. The current positioning leans hard on grounding LLMs in the graph rather than replacing it: a conversational natural-language interface, NL2SPARQL (natural language translated into SPARQL over your ontology), RAG over unstructured content, and agents whose answers are constrained by the semantic model. The pitch is that the ontology is what makes the LLM's answers checkable — the graph supplies verifiable structure, the model supplies the interface.

Where it gets used

The strongest vertical is pharma and life sciences — R&D knowledge discovery, where an entity resolved across assays, targets, compounds and literature is worth real money, and where FAIR-data obligations already push teams toward RDF. Ontotext publishes a joint case study of a global pharma company using metaphactory on top of GraphDB for exactly this. Engineering and manufacturing (part/product/config graphs) is the other named industry, and cultural-heritage and research-data deployments are common in the public literature, partly because metaphactory powers the well-known Wikidata-based demo instances.

Licensing is commercial — subscription, with usage-based options through AWS Marketplace. Treat the platform as closed-source: while metaphacts has historically published open components and the company is an active contributor to the semantic-web ecosystem, the product you deploy is a licensed one, and you should verify the current edition/licensing terms with metaphacts directly rather than trusting a summary like this one.

How it compares

The single most useful framing is layer, not features:

ProductWhat it primarily is
Ontotext GraphDBRDF triplestore with strong inference/reasoning
StardogKnowledge-graph database + virtualization/data-fabric layer
Amazon NeptuneManaged graph database (RDF and property graphs)
TopBraid EDGData governance suite built on semantic tech
metaphactoryKnowledge-engineering + application layer over any SPARQL store

So metaphactory is complementary to GraphDB, Stardog and Neptune, not a substitute — GraphDB is even a common pairing beneath it. Against Stardog the comparison is genuinely competitive at the edges, because Stardog also reaches upward into modeling and end-user tooling; the difference is that Stardog owns its storage and virtualization engine, while metaphactory deliberately does not own any storage at all. Against TopBraid EDG the overlap is real but the intent differs: EDG's center of gravity is governance and stewardship of data assets, metaphactory's is building consumable, user-facing knowledge applications.

Why an AI engineer should care

metaphactory is a clean, production-grade example of the neuro-symbolic pattern that keeps resurfacing in serious RAG work: an LLM is a superb interface and a mediocre source of truth, so you put a typed, constrained, curated graph underneath it and use the model to translate intent (NL2SPARQL) rather than to remember facts. The SHACL-drives-the-form idea is worth stealing on its own — one schema that simultaneously validates data, generates the UI, and constrains what an agent is allowed to assert is exactly the kind of grounding that makes an LLM's output auditable.

Sources