On this page:

Knowledge graphs

"Knowledge graph" is a term people use confidently and define differently. This page gives it a working definition, sets it against the alternatives, and describes how one actually gets built, because the building is where most of the effort goes, and it is rarely what people expect.

When reading this chapter we assume you know about Linked data.

What a knowledge graph is

A knowledge graph stores facts as a network of connected nodes and edges. Nodes are things: a product, a person, a building. Edges are relationships between them: made by, located in, broader than. Both nodes and edges have types, drawn from a shared vocabulary rather than invented per system.

That last clause carries the weight. A diagram of boxes and arrows is a graph. It becomes a knowledge graph when the boxes and arrows mean something that another system can also read.

In practice, and certainly at Triply, "knowledge graph" and "linked data dataset" describe the same thing from two angles. Knowledge graph emphasises the connected, meaningful nature of the data. Dataset emphasises it as a unit you can manage: with an owner, an access level, services and metadata.

Why connecting is the point

The argument for a knowledge graph is an argument about networks. The value of a network grows faster than the number of things in it, because what grows is the number of possible connections. Adding a dataset to a graph that already holds ten does not add one dataset's worth of value; it adds every question that can now be asked across the eleven.

That is the theory. In practice, organisations report a fairly consistent set of gains:

  • Lower cost of exchanging data, because the data carries its own meaning
  • Lower cost of integrating data, because merging is loading rather than mapping
  • Faster adaptation when requirements change, since there is no schema to migrate
  • Better visibility of data quality, because the model states what was expected
  • Questions that cross silos, which were previously projects in their own right
  • A workable foundation for machine learning, which needs context to be useful
  • Less vendor lock-in, since the formats and query language are open standards

Knowledge graph versus the alternatives

No approach wins everywhere. The question is which mismatch you can live with.

Approach Suits Struggles with
Relational database Stable schemas, transactional workloads Evolving schemas, uneven data, cross-source integration
Document store Semi-structured data, nested objects Traversing relationships, querying across documents
Spreadsheet Small datasets, human editing, quick analysis Scale, consistency, machine-to-machine exchange
Knowledge graph Connected data, evolving models, integration across sources High-volume transactional writes, plain tabular reporting

The bottom-right cell means that, if your workload is thousands of small writes per second, a knowledge graph is the wrong tool.

How a knowledge graph gets built

Knowledge graph construction has a shape, and it is not "load the data and see what happens". Triply's method runs in nine steps:

graph TD s1["1. Location and naming"] --> s2["2. Metadata"] s2 --> s3["3. Example records"] s3 --> s4["4. Ontology design patterns"] s4 --> s5["5. Vocabulary"] s5 --> s6["6. Feedback"] s6 --> s7["7. Implementation"] s7 --> s8["8. Data quality report"] s8 --> s9["9. Sustainability"] s6 -.-> s4
  1. Location and naming — where the data will live and how its IRIs are formed. Decided first, because everything else refers to it.
  2. Metadata — what this dataset is, who owns it, under what licence.
  3. Example records — a handful of real records, not a specification. They surface the exceptions that a specification hides.
  4. Ontology design patterns — recognising which modelling problems you have, and which are already solved.
  5. Vocabulary — choosing the terms. Reuse before you invent.
  6. Feedback — domain experts read the model back. This step loops; it is normal to return to step 4.
  7. Implementation — the repeatable process of extracting, transforming, and loading sources into triples.
  8. Data quality report — the model made testable, so quality is measured rather than asserted.
  9. Sustainability — who maintains this, on what schedule, when the project ends.

Note where the effort sits. Six of the nine steps happen before any data is converted, and the last one happens long after. Treating knowledge graph construction as an import job is the most common way it goes wrong.

Where this appears in Triply products

  • TriplyDB stores knowledge graphs as datasets, with services on top for querying and searching. See TriplyDB.
  • Flows are an approach to step 7 — the repeatable conversion from sources to triples. See Flows.
  • Validation is step 8, expressed as SHACL constraints. See SHACL.
  • Triply's public-sector work — cadastral, statistical, cultural heritage and archival knowledge graphs — follows this method.

Where to next