Building a Knowledge Graph: Databases, Standards, Tools, and Enterprise Platforms

In the previous article, we looked at why modern AI systems need more than documents, tables, and vector search. They need a way to understand entities, relationships, meaning, and context.

That is where knowledge graphs come into the picture. The usual next question is, what do we actually use to build one? The answer is not as simple as choosing a graph database.

A real enterprise knowledge graph may involve ontology standards, graph databases, validation rules, data mapping tools, visualisation applications, cloud services, security systems, and release processes.

Most organisations also do not use just one format or one graph model. They may use RDF for semantic modelling, a property graph for operational queries, JSON-LD in APIs, CSV for data imports, and Git for storing ontology files.

So before discussing the product we want to build, it is useful to understand the current technology landscape and where the gaps still exist.

Knowledge graph representation standards

There are several ways to represent graph data. Some are graph models, some are modelling languages, and others are only file formats.

They are often discussed as competing technologies, but in practice they are usually used together.

RDF

RDF, or Resource Description Framework, represents knowledge as statements.

Each statement contains three parts:

Here, Customer123 is the subject, placedOrder is the relationship, and Order456 is the object.

A large collection of these statements forms a graph.

RDF is commonly used when organisations want to represent information using shared identifiers and well-defined semantics. It is particularly common in linked data, research, publishing, life sciences, government data, and enterprise semantic systems.

RDF itself is the model. It can be stored or exchanged using several different formats.

RDFS and OWL

RDFS adds basic modelling concepts to RDF.

It lets us say that something is a class, that one class is a subclass of another, or that a property is expected to connect particular types of entities.

OWL goes further.

It can express richer rules such as equivalence, disjoint classes, cardinality restrictions, and more complex relationships between concepts.

Not every knowledge graph needs the full power of OWL. Sometimes a simple vocabulary is enough. In other cases, especially where reasoning or strict domain modelling is important, OWL becomes useful.

SHACL

SHACL is mainly used for validation.

For example, an organisation may define rules saying:

• Every customer must have an identifier.

• Every product must have a name.

• A birth date must be a date value.

• A relationship must point to a particular type of entity.

The graph can then be checked against those rules before data is published or released.

This is important because an ontology can describe what the domain means, while SHACL can check whether the actual data follows the expected structure.

SKOS

SKOS is commonly used for taxonomies, thesauri, controlled vocabularies, and classification systems.

It is useful for representing concepts such as broader terms, narrower terms, preferred labels, alternative labels, and multilingual terminology.

For many organisations, SKOS is a practical starting point because they already have product classifications, business glossaries, topic hierarchies, or domain vocabularies that need better management.

Turtle, JSON-LD, N-Triples, and RDF/XML

These are different ways of writing RDF data.

Turtle is compact and fairly easy for people to read. It is often used for ontologies and examples.

JSON-LD is useful when linked data needs to work with web APIs or applications already using JSON.

N-Triples stores one RDF statement per line. It is verbose, but simple to process and useful for bulk data movement.

RDF/XML represents RDF using XML. It is still supported by many established systems, though it is not usually the first choice for developers starting a new project.

These formats are not different kinds of knowledge graphs. They are different serialisations of the same underlying RDF model.

Property graph models

Property graphs use nodes, relationships, labels, and properties.

A customer may be represented as a node. An order may be another node. A PLACED relationship connects them.

Both nodes and relationships can contain properties.

This model is popular because it maps naturally to application development and graph traversal.

Property graphs are widely used for fraud detection (I will provide case studies later from my professional experience), identity resolution, recommendations, dependency analysis, network management, and connected operational data.

Apache TinkerPop and Gremlin provide a common programming model used by several property graph platforms.

GraphML and CSV

GraphML is an XML-based format for exchanging graph structures. It is commonly supported by graph-analysis and visualisation tools.

CSV is not really a graph format, but it remains one of the most common ways to load graph data.

An organisation may have one CSV file containing entities and another containing relationships. During import, the database or mapping tool decides which columns represent identifiers, labels, properties, source nodes, and destination nodes.

This may not sound sophisticated, but it reflects how enterprise data actually arrives in real time and also how we support historical data.

Enterprises usually use more than one format

RDF and property graphs are sometimes presented as two separate worlds.

That is not always how enterprises work.

An organisation may use RDF and OWL for its ontology, while storing high-volume application relationships in a property graph database.

It may use JSON-LD when exposing selected data through APIs and CSV when onboarding data from older systems.

It may receive external data in RDF/XML, transform it into another model, and publish only part of it to a graph database.

Graph and knowledge graph databases

Once the graph model is chosen, the next part of the landscape is the database.

There are many products, but they broadly fall into a few groups.

Property graph databases

Neo4j is probably the best-known property graph database. It uses the Cypher query language and has a large ecosystem around development, visualisation, analytics, and managed cloud deployment.

Memgraph also supports Cypher and focuses heavily on operational and real-time graph workloads.

JanusGraph is an open-source distributed graph database built around the Apache TinkerPop ecosystem. It is often deployed with separate storage and indexing technologies underneath it.

ArangoDB and OrientDB are multi-model databases. They support graph use cases while also handling document-oriented data.

TigerGraph focuses on large-scale graph processing and analytics.

Amazon Neptune supports property graphs through Gremlin and openCypher.

Azure Cosmos DB provides graph capabilities through its Gremlin API.

There are also several other TinkerPop-compatible platforms. They may share a traversal language, but their operational behaviour, indexing, security, deployment, and administration can still be quite different.

RDF and semantic graph databases

GraphDB is a semantic graph database built around RDF, SPARQL, reasoning, and related standards.

Apache Jena is an open-source Java framework for working with RDF. Fuseki provides its SPARQL server and graph-store capabilities.

Eclipse RDF4J is another open-source framework for storing, querying, processing, and validating RDF data.

Stardog combines graph storage with reasoning, virtualisation, modelling, and enterprise knowledge graph features.

AllegroGraph is a mature semantic graph platform with RDF, SPARQL, reasoning, and security capabilities.

Virtuoso combines RDF and SPARQL with broader multi-model database and application-server features.

MarkLogic is not only a graph database, but it supports RDF triples and SPARQL alongside XML, JSON, search, and document storage. This can be useful when semantic relationships need to exist next to large collections of enterprise content.

Ontotext provides GraphDB as well as broader semantic data and managed platform services.

These products overlap in many areas, but they are not interchangeable. Their reasoning support, scaling approach, security, tooling, deployment model, and licensing can differ considerably.

Cloud and managed graph services

Managed graph services remove some of the operational burden of installing and maintaining a database.

Amazon Neptune supports both RDF and property graph workloads, although the two models are still queried separately.

Neo4j Aura provides managed Neo4j services.

Microsoft provides graph capabilities through services such as Azure Cosmos DB and newer graph features across its analytics ecosystem.

Google Cloud has also been expanding its graph and semantic offerings through services around Spanner, enterprise knowledge graphs, analytics, and GraphRAG.

Many commercial graph vendors now provide their own managed cloud versions.

This makes deployment easier, but it does not solve every enterprise problem.

A managed database still does not automatically provide a common ontology workflow, release process, approval model, validation policy, or business-user experience across several graph systems.

Ontology and graph-management applications

The database is only one part of the picture.

Someone still has to design the model, manage vocabularies, map source data, explore the graph, review changes, validate releases, and decide who is allowed to see or change what.

That is where ontology and graph-management tools come in.

Ontology editors

Protégé is one of the most widely used ontology editors. It is free, open source, and particularly useful for detailed OWL modelling.

WebProtégé brings ontology editing into the browser and adds collaboration around shared projects.

VocBench is another browser-based platform. It supports ontologies, SKOS vocabularies, RDF datasets, multilingual terminology, roles, history, and publishing workflows.

These tools are strong for ontology and vocabulary work.

However, ontology editing is only one part of running an enterprise knowledge graph.

Database-specific tools

Most graph databases come with their own development or administration environment.

GraphDB has GraphDB Workbench.

Stardog has Stardog Studio.

Neo4j has Neo4j Browser for querying and development, and Neo4j Bloom for visual graph exploration.

These tools are usually very good at working with their own databases.

That is also their natural limitation.

When an organisation uses more than one graph platform, each database introduces another interface, another security model, another way of loading data, and another way of managing users and permissions.

Enterprise semantic platforms

TopBraid provides ontology, taxonomy, glossary, workflow, governance, and approval capabilities.

PoolParty combines taxonomy and ontology management with semantic enrichment, graph construction, mapping, and search.

metaphactory provides modelling, exploration, application development, and knowledge graph management capabilities.

These products cover a much broader part of the enterprise lifecycle than a basic ontology editor or database console.

They also prove that there is already a serious market for semantic governance and knowledge graph management.

The gap is not that these tools do not exist.

The issue is that they are usually centred on a particular platform, database family, or semantic technology stack.

Data preparation and visualisation tools

OntoRefine, now Ontotext Refine, is useful for cleaning tabular data and mapping it into RDF.

Other visualisation and modelling tools can work with GraphML, RDF, property graphs, or database-specific formats.

Data catalogues are also adding semantic features such as business glossaries, classifications, lineage, metadata relationships, and AI context.

These tools are useful, but they usually solve only one part of the lifecycle.

A visualisation tool does not necessarily manage ontology releases.

A data catalogue does not necessarily manage operational graph data.

An ontology editor does not necessarily manage database connections and ingestion pipelines.

A database workbench does not necessarily provide approval workflows for business users.

Where the gap actually is

It would be wrong to say that the knowledge graph market lacks tools. There are already many good tools.

The problem is fragmentation.

A typical organisation may use one tool for ontology editing and another for graph exploration. Each graph database may have its own administration console. Validation may be handled through scripts. Models may be stored in Git, shared drives, or exported files. Approvals may happen through tickets, email, or meetings. Identity and access rules may need to be configured separately in each product.

Business users may need a custom application because the database tools expose too much technical detail.

Release management may be a little more than someone exporting a file and loading it into another environment.

The opportunity is not another graph database

SolidState Graph should not try to replace Neo4j, GraphDB, Neptune, Stardog, MarkLogic, JanusGraph, Memgraph, TigerGraph, Jena, RDF4J, or the other databases already in use.

Those systems solve the storage and query problem.

The opportunity is to build a management layer over them.

A knowledge graph control plane could connect to the graph infrastructure an organisation already has and provide one consistent browser-based environment for managing it.

That includes product areas such as:

• Graph exploration

• Ontology and vocabulary management

• Data-source registration

• Mappings

• Validation

• Change comparison

• Releases

• Governance

• Approvals

• Audit history

• Role-based business views

• AI-assisted graph interaction

These are some browser-first product surfaces already identified for SolidState Graph: Explore, Ontology, Mappings, Validation, Releases, AI Views, Sources, and Governance.

The goal is not to pretend that every graph database works in the same way.

The platform should understand those differences and handle them through database adapters, format-aware workflows, capability checks, and controlled abstractions.

A small team may use it to browse a graph, edit an ontology, run validation, and publish a release.

A large enterprise may use it across several teams, databases, environments, identity providers, approval processes, and business domains.

That is the space SolidState Graph can occupy. Not another database. Not another ontology editor. Not another visualisation screen.

A practical operating layer for managing the full knowledge graph lifecycle across the systems an enterprise already uses.