Knowledge Graphs and Knowledge Representation

Knowledge representation is at the heart of symbolic AI, and Prolog’s fact-and-rule database is itself a knowledge representation system. A knowledge graph stores information as triples (subject, predicate, object) exactly the structure of a Prolog fact. This makes Prolog a natural language for building, querying, and reasoning over knowledge graphs. In this chapter we develop two complementary tools: kg_creator for building knowledge graphs from scratch and exporting them to standard formats, and kg_query for multi-hop reasoning and path finding over richly connected graph data.

A knowledge graph is a set of triples, each linking a subject to an object through a named predicate. In Prolog this is direct:

No translation layer is needed: Prolog’s fact base is a knowledge graph. The triple/3 predicate is our storage schema, and Prolog’s unification engine is our query processor. This is why Prolog is sometimes called the “language of knowledge graphs”: the representation and the reasoning machinery are one and the same.

We organize the code into modules so that the triple store is encapsulated and the exported predicates form a clean API. The convention :- dynamic triple/3. declares the predicate as modifiable at runtime, which is essential since knowledge graphs grow as we add information.

The kg_creator project provides a minimal but complete knowledge graph builder. It stores triples as dynamic Prolog facts, queries them with pattern matching, and exports the graph to two widely used formats: N-Triples RDF (for Semantic Web tools) and Neo4j Cypher CREATE statements (for graph databases).

Here is the file kg_creator/prolog/kg_builder.pl:

The add_triple/3 predicate uses a simple pattern: first check whether the triple already exists, and only assert it if it does not. This prevents duplicate entries and is safe to call repeatedly — the predicate always succeeds:

The if-then-else construct ( Condition -> Then ; Else ) is classic Prolog control flow. When triple(S, P, O) succeeds, the branch -> true simply succeeds without modification. When it fails — meaning the triple is new — the ; assert(triple(S, P, O)) branch fires, adding it to the dynamic database.

Because query_triples/3 delegates directly to triple/3, any combination of bound and unbound arguments works. This is unification at work:

Prolog’s built-in backtracking yields every matching fact — no explicit iteration required.

The export_rdf/1 and export_cypher/1 predicates demonstrate a common Prolog pattern: setup_call_cleanup/3 ensures the output file is always closed, even if an error occurs during writing. The forall/2 meta-predicate iterates over all triples, formatting each one:

The resulting output.nt contains N-Triples RDF:

And output.cypher contains Neo4j Cypher statements:

These exports make the Prolog knowledge graph interoperable with the wider world of graph databases and Semantic Web tools — a topic we explore further in the Semantic Web chapter.

Running the tests:

Or simply:

While kg_creator focuses on building and exporting knowledge graphs, the kg_query project focuses on reasoning over them — finding paths, checking connectivity, and discovering what is reachable from a given entity. This is where Prolog truly shines: recursive path finding with backtracking is trivial to express declaratively, yet would require significant effort in a general-purpose language.

The kg_query project uses a richer schema with typed entities and named relations. The file kg_query/prolog/kg_reason.pl implements the reasoning engine:

The core of the reasoning engine is path/3, which finds a chain of relations connecting two entities. It uses an accumulator to track visited nodes and prevent cycles:

The public path/3 delegates to an auxiliary path/4 that tracks visited nodes in a list. The \+ member(End, Visited) check prevents the path from revisiting nodes, which is essential in densely connected graphs where cycles are common. On each recursive step, a relation is followed from the current node to an intermediate node Mid, and Mid is added to the visited list before recursing.

The connected/2 predicate checks whether any path exists between two entities, in either direction:

The reachable/2 predicate finds all entities reachable from a given starting point, using bidirectional breadth-first search — it expands forward along outgoing edges and backward along incoming edges:

The BFS implementation uses a queue of nodes to visit, accumulating visited nodes to avoid revisiting. findall/3 collects all next-step neighbors at each level, which means each BFS “level” is expanded fully before moving to the next — breadth-first rather than depth-first.

The remaining predicates provide utility queries:

Note the cut (!) in path_length/3 — once a path is found, we commit to it rather than trying alternatives. This is appropriate when any shortest-or-longer path suffices, and the length of the first found path is returned. The all_paths/3 predicate, by contrast, uses findall/3 to collect every cycle-free path.

The kg_query project includes a rich sample dataset in kg_query/prolog/sample_data.pl with over 350 assertions spanning eight entity types:

The relations connect these entities in meaningful ways: people research fields, use languages, work at organizations, collaborate with each other, and author publications. Languages are implemented by tools, fields use concepts, organizations develop projects, and languages form dialect chains (e.g., clojure → lisp).

This richly connected graph enables interesting multi-hop queries. For example, can we trace a path from a person to a concept they have never directly referenced?

Mark works on AI, which uses NLP, which uses the transformer concept — a three-hop inference that no single fact expresses, but that emerges from the graph’s connectivity.

Running tests:

The test suite validates direct relations, multi-hop paths, cycle-free paths, bidirectional reachability, and path length constraints:

The export_rdf/1 and export_cypher/1 predicates in kg_creator bridge Prolog’s knowledge graph to the wider ecosystem of graph tools. N-Triples RDF is the simplest RDF serialization — each line is a triple formatted as <subject> <predicate> "object" .. This format can be loaded by any RDF-compliant tool: Apache Jena, RDF4J, or SWI-Prolog’s own semweb library (covered in the Semantic Web chapter).

Cypher is Neo4j’s query language, and the CREATE statements generated by export_cypher/1 can be pasted directly into a Neo4j browser session to reconstruct the graph in a production graph database.

For a production system, you would want to extend these exports with:

• URI namespacing for RDF (e.g., http://example.org/kg#john instead of bare john)
• Datatype and language tags for RDF literals
• Node labels and properties for Cypher (e.g., CREATE (john:Person {name: "John"}))
• Batch import using Cypher’s UNWIND for large graphs

The simple approach shown here illustrates the essential idea: Prolog’s triple store is a fully functional knowledge graph that can be projected into any standard format with a few lines of formatting code.

Local knowledge graphs are most powerful when connected to the global web of Linked Open Data (LOD). Public knowledge bases like DBpedia (which structures Wikipedia content as RDF) and Wikidata (Wikimedia’s structured database) act as massive, open-access triple stores. Both databases expose public SPARQL endpoints that can be queried remotely over HTTP.

SWI-Prolog’s library(semweb/sparql_client) allows us to query these endpoints directly and merge remote graph segments into our local database. This process is called graph enrichment.

A SPARQL client query returns results as a list of row terms representing variable bindings. For instance, we can fetch metadata about programming languages directly from DBpedia.

Here is a Prolog predicate that queries DBpedia for the developer of a given programming language, and automatically asserts the result as a new triple in our local knowledge graph:

By combining remote endpoints with local rules, you can dynamically fetch missing information at runtime. For example, if a user queries our local graph for the developer of Prolog, but that relation is missing, a Prolog rule can catch the failure, query DBpedia in the background, assert the new relation, and return the answer seamlessly:

This hybrid pattern uses Prolog’s backtracking and unification to build self-enriching knowledge engines, turning the entire web of Linked Open Data into an extension of your application’s local knowledge graph. Details on constructing advanced SPARQL queries and managing namespace conversions are covered in depth in the Semantic Web chapter.