Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/jbarrasa/goingmeta/llms.txt

Use this file to discover all available pages before exploring further.

A knowledge graph is a structured representation of real-world entities and the relationships between them, stored in a way that makes both the data and its meaning queryable. Unlike a relational database, which organises data into tables with fixed schemas, a knowledge graph places relationships on equal footing with entities — a relationship is not just a foreign-key join but a first-class object with its own identity, direction, type, and properties. Neo4j’s native property graph model is purpose-built for this kind of interconnected data, and it underpins every session of Going Meta.

​
The Property Graph Model

Neo4j stores data as a labelled property graph with four core primitives:

Nodes

Represent entities — people, organisations, concepts, documents, events. A node can have one or more labels (e.g. Person, Article, Concept) and a map of properties (key-value pairs).

Relationships

Connect two nodes and are always directed (from a start node to an end node). Every relationship has a type (e.g. KNOWS, refers_to, broader) and can also carry properties.

Properties

Key-value attributes on both nodes and relationships. Values can be strings, numbers, booleans, dates, or arrays. Properties store the descriptive data about an entity or connection.

Labels & Types

Labels classify nodes into categories; relationship types classify connections. Both are used for pattern matching in Cypher queries and index creation.

​
Creating a Simple Knowledge Graph with Cypher

Cypher is Neo4j’s declarative query language. It uses an ASCII-art syntax where nodes are written as () and relationships as -->. The following example creates a minimal knowledge graph of articles and their conceptual topics — the same pattern used in Going Meta Session 2. 
// Create some article nodes
CREATE (a1:Article {
  uri: "https://dev.to/example/article-1",
  title: "Getting started with Neo4j",
  datetime: datetime("2022-01-15T10:00:00")
})

CREATE (a2:Article {
  uri: "https://dev.to/example/article-2",
  title: "SPARQL queries on Wikidata",
  datetime: datetime("2022-02-10T14:30:00")
})

// Create concept nodes
CREATE (c1:Concept {uri: "https://en.wikipedia.org/wiki/Neo4j", prefLabel: "Neo4j"})
CREATE (c2:Concept {uri: "https://en.wikipedia.org/wiki/SPARQL",  prefLabel: "SPARQL"})
CREATE (c3:Concept {uri: "https://en.wikipedia.org/wiki/Knowledge_graph", prefLabel: "Knowledge graph"})

// Connect articles to concepts
MERGE (a1)-[:refers_to]->(c1)
MERGE (a1)-[:refers_to]->(c3)
MERGE (a2)-[:refers_to]->(c2)
MERGE (a2)-[:refers_to]->(c3)

// Connect concepts hierarchically
MERGE (c1)-[:broader]->(c3)
MERGE (c2)-[:broader]->(c3)
Once this data is in Neo4j, you can traverse it naturally with Cypher pattern matching: 
// Find all articles that refer to concepts broader than "Knowledge graph"
MATCH (a:Article)-[:refers_to]->(c:Concept)-[:broader*1..]->(parent:Concept)
WHERE parent.prefLabel = "Knowledge graph"
RETURN a.title AS article, c.prefLabel AS concept
ORDER BY article;
The [:broader*1..] syntax means “follow one or more broader relationships”. This kind of variable-length path query is trivial in Cypher but requires recursive CTEs or CONNECT BY clauses in SQL — a concrete illustration of why graph databases suit hierarchical and network data.

​
Knowledge Graphs vs. Relational Databases

DimensionRelational DatabaseKnowledge Graph (Neo4j)
Data modelTables, rows, columnsNodes, relationships, properties
SchemaFixed, pre-definedFlexible, schema-optional
RelationshipsForeign-key joins (expensive at scale)First-class traversals (O(1) per hop)
SemanticsImplicit in column namesExplicit in labels, types, ontologies
Query languageSQLCypher (also SPARQL via n10s)
Multi-hop queriesComplex nested joinsNatural variable-length paths
The performance advantage of graphs becomes significant when queries involve many hops — finding friends-of-friends, traversing class hierarchies, or following citation chains. These patterns appear constantly in Going Meta sessions.

​
How Going Meta Builds Knowledge Graphs

The series demonstrates multiple strategies for populating a knowledge graph, each suited to different data sources:
Session 2 starts by loading articles from a CSV file into Neo4j, then enriching them with concept nodes imported from a SKOS taxonomy:
LOAD CSV WITH HEADERS
FROM 'https://raw.githubusercontent.com/jbarrasa/goingmeta/main/session02/resources/devto-articles.csv'
AS row
CREATE (a:Article { uri: row.uri })
SET a.title = row.title,
    a.body  = row.body,
    a.datetime = datetime(row.date);
The power of a knowledge graph over a plain vector store is that you can ask structural questions: “Which articles reference the same concept hierarchy?”, “What is the shortest path between two entities?”, or “Which entities have no outgoing relationships?” — questions that pure embedding search cannot answer.

​
The Role of Knowledge Graphs in GenAI

A knowledge graph acts as a structured, curated memory for an LLM application. Rather than retrieving semantically similar text chunks (pure vector RAG), a GraphRAG system can:
  • Follow explicit relationship paths to find precise facts
  • Use ontology class hierarchies to broaden or narrow queries
  • Combine structured Cypher traversals with vector similarity in a single query
  • Provide the LLM with a concise, factually grounded context window
This is the core insight that drives the entire second half of Going Meta — and it is explored in depth in the GraphRAG concepts page.

Build docs developers (and LLMs) love

Get started for freeTalk to us