Knowledge graphs represent structured information about the world, capturing entities, their attributes, and relationships in a queryable format. From Google's Knowledge Graph to enterprise data catalogs, they power semantic search, question answering, and intelligent applications.
A knowledge graph is a graph database that stores factual information and relationships in a structured, machine-readable format. Unlike general-purpose graphs, knowledge graphs emphasize semantic meaning and often include:
Defines the structure and rules:
// Define entity types
CREATE (concept:Concept {name: 'Person', definition: 'A human being'})
CREATE (concept2:Concept {name: 'Company', definition: 'A business organization'})
// Define allowed relationships
CREATE (rel:RelationType {
name: 'WORKS_FOR',
domain: 'Person',
range: 'Company'
})Actual instances conforming to schema:
CREATE (alice:Person:Entity {
id: 'person_001',
name: 'Alice Johnson',
birthDate: date('1990-05-15'),
nationality: 'American'
})
CREATE (acme:Company:Entity {
id: 'company_001',
name: 'Acme Corporation',
founded: date('2000-01-01'),
industry: 'Technology'
})
CREATE (alice)-[:WORKS_FOR {
role: 'Engineer',
since: date('2020-01-01'),
confidence: 0.95
}]->(acme)Query interfaces, APIs, and applications that leverage the knowledge.
Identify entities and relationships in your domain:
Create a formal model:
// Entity hierarchy
CREATE (thing:Class {name: 'Thing'})
CREATE (person:Class {name: 'Person'})-[:SUBCLASS_OF]->(thing)
CREATE (employee:Class {name: 'Employee'})-[:SUBCLASS_OF]->(person)
// Properties
CREATE (nameProp:Property {
name: 'name',
domain: 'Thing',
range: 'String',
required: true
})
// Relationships
CREATE (worksFor:RelationType {
name: 'WORKS_FOR',
domain: 'Person',
range: 'Organization',
cardinality: 'many-to-one'
})Sources for knowledge graph data:
Extract entities from text using NLP:
import spacy
nlp = spacy.load("en_core_web_sm")
doc = nlp("Alice works at Acme Corporation in New York.")
for ent in doc.ents:
print(f"{ent.text} ({ent.label_})")
# Output:
# Alice (PERSON)
# Acme Corporation (ORG)
# New York (GPE)Match extracted entities to existing nodes:
// Find or create entity
MERGE (person:Person {name: $name})
ON CREATE SET
person.id = randomUUID(),
person.createdAt = timestamp(),
person.source = $source
ON MATCH SET
person.lastSeen = timestamp(),
person.mentionCount = person.mentionCount + 1
RETURN personIdentify relationships from text or structured sources:
// Pattern-based extraction
MATCH (alice:Person {name: 'Alice'}), (acme:Company {name: 'Acme'})
WHERE $text CONTAINS 'works at'
MERGE (alice)-[r:WORKS_FOR]->(acme)
ON CREATE SET r.extractedFrom = $source, r.confidence = 0.8
RETURN r// Time-based facts
CREATE (alice:Person {name: 'Alice'})
CREATE (acme:Company {name: 'Acme'})
CREATE (employment:Employment {
role: 'Engineer',
startDate: date('2020-01-01'),
endDate: date('2023-12-31')
})
CREATE (alice)-[:HAS_EMPLOYMENT]->(employment)
CREATE (employment)-[:AT_COMPANY]->(acme)
// Query: Where did Alice work in 2022?
MATCH (p:Person {name: 'Alice'})-[:HAS_EMPLOYMENT]->(e:Employment)
-[:AT_COMPANY]->(c:Company)
WHERE date('2022-01-01') >= e.startDate
AND date('2022-01-01') <= coalesce(e.endDate, date())
RETURN c.name// Track information sources
CREATE (fact:Fact {
statement: 'Alice works at Acme',
confidence: 0.95,
source: 'LinkedIn',
timestamp: timestamp(),
verificationStatus: 'verified'
})
CREATE (alice)-[:SUBJECT_OF]->(fact)
CREATE (acme)-[:OBJECT_OF]->(fact)CREATE (company:Company {id: 'company_001'})
CREATE (company)-[:HAS_NAME {language: 'en'}]->(:Name {value: 'Acme Corporation'})
CREATE (company)-[:HAS_NAME {language: 'es'}]->(:Name {value: 'Corporación Acme'})
CREATE (company)-[:HAS_NAME {language: 'zh'}]->(:Name {value: '顶点公司'})Add derived facts:
// Infer relationships
MATCH (person:Person)-[:WORKS_FOR]->(company:Company)
-[:LOCATED_IN]->(city:City)
WHERE NOT (person)-[:LIVES_NEAR]->(city)
CREATE (person)-[:LIVES_NEAR {inferred: true, confidence: 0.7}]->(city)// Transitive relationships
MATCH (a:Person)-[:MANAGES]->(b:Person)-[:MANAGES]->(c:Person)
WHERE NOT (a)-[:INDIRECTLY_MANAGES]->(c)
CREATE (a)-[:INDIRECTLY_MANAGES {hops: 2}]->(c)// Entity-aware search
MATCH (entity:Entity)
WHERE entity.name CONTAINS $query
OR any(alias IN entity.aliases WHERE alias CONTAINS $query)
OPTIONAL MATCH (entity)-[r]-(related:Entity)
RETURN entity, collect({rel: type(r), entity: related}) AS related
LIMIT 10// "Who founded Google?"
MATCH (company:Company {name: 'Google'})<-[:FOUNDED]-(founder:Person)
RETURN founder.name
// "What companies did Elon Musk found?"
MATCH (person:Person {name: 'Elon Musk'})-[:FOUNDED]->(company:Company)
RETURN collect(company.name) AS companies// Recommend companies similar to user's interests
MATCH (user:Person {id: $userId})-[:INTERESTED_IN]->(topic:Topic)
<-[:TAGGED_WITH]-(company:Company)
WHERE NOT (user)-[:KNOWS_ABOUT]->(company)
WITH company, count(topic) AS commonTopics
RETURN company.name, commonTopics
ORDER BY commonTopics DESC
LIMIT 5// Import from Wikidata API
CALL apoc.load.json('https://www.wikidata.org/wiki/Special:EntityData/Q95.json')
YIELD value
WITH value.entities.Q95 AS entity
MERGE (e:Entity {wikidataId: 'Q95'})
SET e.name = entity.labels.en.value,
e.description = entity.descriptions.en.value
RETURN e// Handle conflicting facts
MATCH (entity:Entity)-[:HAS_FACT]->(f:Fact)
WHERE f.property = 'birthDate'
WITH entity, f ORDER BY f.confidence DESC, f.timestamp DESC
WITH entity, collect(f) AS facts
SET entity.birthDate = facts[0].value,
entity.birthDateSource = facts[0].source
RETURN entityThis section reconciles the knowledge graph ENUM tokens of the Graph Database Standard simulator with the construction procedures discussed in §6.1 through §6.6. The simulator exposes six knowledge graph asset tokens — WIKIDATA, DBPEDIA, YAGO, CONCEPTNET, SCHEMA_ORG, and KG_ALIGNMENT — each representing a global knowledge asset of substantial significance1. Among the database engine ENUMs (NEO4J, NEPTUNE, DGRAPH, ARANGODB, JANUSGRAPH, TIGERGRAPH, MEMGRAPH, NEBULA_GRAPH), the distinction between RDF triple stores and property graph engines (LPG) is the principal decision variable for knowledge graph deployments2.
| ENUM Token | Scale (2025) | Schema | License | Standard |
|---|---|---|---|---|
WIKIDATA | 106 million items | RDF + item ID (Q/P) | CC0 | W3C_RDF3 |
DBPEDIA | 22 million entities | RDF + OWL 2 | CC BY-SA 3.0 | W3C_SPARQL4 |
YAGO | 6.7 million entities | RDF + temporal + spatial | CC BY 4.0 | OWL 25 |
CONCEPTNET | 34 million phrases | RDF + multilingual | CC BY-SA 4.0 | RDF 1.16 |
SCHEMA_ORG | 800+ types | RDFa, JSON-LD | CC BY-SA 3.0 | JSON-LD 1.17 |
KG_ALIGNMENT | Alignment algorithms | SBERT, TransE, RotatE | Varies | arXiv 2024 KG survey8 |
Knowledge graph construction rests on the conformant application of four axes of standards: RDF (Resource Description Framework) for the data model, OWL 2 (Web Ontology Language) for class hierarchies and reasoning, SPARQL 1.1 for query, and SHACL for constraint-based validation9. RDF represents knowledge as an unbounded graph of subject-predicate-object triples; OWL 2 enables formal entailment regimes including RL, EL, and QL profiles. SPARQL 1.1 was adopted as a W3C Recommendation in March 2013, and SHACL was promoted to Recommendation status in July 2017 to standardize shape-based validation of RDF graphs.
Knowledge graph embedding (KGE) projects entities and relations into a low-dimensional vector space, enabling link prediction, entity alignment, and triple classification8. Landmark methods include TransE (2013), DistMult (2015), ComplEx (2016), RotatE (2019), and SBERT-based variants (2019 onward). Each model encodes distinct assumptions about the algebraic structure of relations.
TransE models a relation as a translation in vector space, requiring h + r ≈ t for plausible triples. While elegant, it fails to faithfully represent 1-to-N, N-to-1, and N-to-N relations, motivating subsequent variants TransH, TransR, and TransD10. RotatE, in contrast, models relations as rotations in complex-valued space, capturing symmetric, antisymmetric, and compositional patterns within a single framework, and achieved state-of-the-art performance on the FB15k-237 and WN18RR benchmarks at the time of publication.
| Model | Year | Score Function | FB15k-237 MRR | Reference |
|---|---|---|---|---|
| TransE | 2013 | -‖h + r - t‖ | 0.294 | Bordes NeurIPS 201311 |
| DistMult | 2015 | <h, r, t> | 0.241 | Yang ICLR 2015 |
| ComplEx | 2016 | Re(<h, r, t̄>) | 0.247 | Trouillon ICML 2016 |
| ConvE | 2018 | 2D convolution | 0.325 | Dettmers AAAI 201812 |
| RotatE | 2019 | -‖h ∘ r - t‖ | 0.338 | Sun ICLR 201913 |
Knowledge graph alignment, the task of matching equivalent entities across heterogeneous knowledge graphs, has become increasingly important as enterprise data ecosystems integrate Wikidata, DBpedia, YAGO, and proprietary domain graphs. Recent approaches combining BERT and SBERT contextual embeddings with graph neural networks have substantially improved alignment quality. SHACL 1.1, adopted as a W3C Recommendation in 2017, standardizes constraint-based validation of the integrity of aligned graphs9.
In "RotatE: Knowledge Graph Embedding by Relational Rotation in Complex Space," Sun et al. demonstrate that rotation in complex-valued space provides a unified representation of symmetric, antisymmetric, and compositional relation patterns.
End-to-end knowledge graph construction pipelines combine information extraction, entity resolution, schema mapping, and validation. Open-source frameworks such as DeepDive, Snorkel, and DeepKE have lowered the entry barrier for domain-specific knowledge graph projects14. In industry settings, Google's Knowledge Vault project (Dong et al., 2014) pioneered probabilistic knowledge fusion at scale, integrating 1.6 billion facts from heterogeneous web sources with confidence scoring.
Quality assurance in knowledge graph pipelines typically involves four dimensions: completeness (coverage of required properties), consistency (absence of contradiction), accuracy (alignment with ground truth), and freshness (currency of data). SHACL provides a declarative mechanism for expressing many of these constraints, while domain-specific data validation can leverage probabilistic soft logic (PSL) or Markov logic networks (MLN). The W3C Data on the Web Best Practices (2017) provides additional guidance on provenance, licensing, and dataset versioning15.
WIA-Official/wia-standards-public/tree/main/graph-database — open standard initiative providing source code for simulator, spec, API, and ebook assets cited throughout this volume; serves as the canonical verification record for all primary-source citations made by the WIA standard committee in this chapter. Canonical ENUM tokens used in this volume include NEO4J, NEPTUNE, DGRAPH, ARANGODB, JANUSGRAPH, TIGERGRAPH, MEMGRAPH, NEBULA_GRAPH, CYPHER, GREMLIN, SPARQL, GQL, PAGERANK, LOUVAIN, NODE2VEC, GRAPHSAGE, ISO_GQL_2024, W3C_RDF, W3C_SPARQL, LDBC_SNB, WIKIDATA, DBPEDIA, YAGO, CONCEPTNET.