Leading knowledge graph tools for enterprise AI include Neo4j, Stardog, Amazon Neptune, Ontotext GraphDB, and Atlan’s Enterprise Data Graph. The right choice depends on whether your use case requires graph traversal, ontology-based semantic reasoning, or governed context delivery to AI agents. Most tools marketed as knowledge graph platforms are actually graph databases — only a few add true OWL-based reasoning.
Knowledge graph tool types: a quick breakdown
Permalink to “Knowledge graph tool types: a quick breakdown”A knowledge graph tool manages entities, relationships, and semantic meaning across a domain. The category spans three distinct types: property graph databases (like Neo4j and Amazon Neptune) that store nodes and edges with traversal performance as the primary goal; semantic triple stores (like Stardog and Ontotext GraphDB) that add OWL-based ontology reasoning and SPARQL query support; and governed metadata knowledge graphs (like Atlan’s Enterprise Data Graph) that focus on delivering structured, governed context to AI agents.
| Quick facts | Detail |
|---|---|
| Query languages | Cypher (Neo4j), SPARQL (Stardog, GraphDB, Neptune RDF), GSQL (TigerGraph), Gremlin (Neptune, Cosmos DB) |
| Semantic reasoning | OWL 2 support: Stardog, Ontotext GraphDB, Franz AllegroGraph only |
| Gartner stat | 85% of Fortune 500 use some form of knowledge graph (Gartner, 2024) |
| AI retrieval impact | Semantic enrichment improves retrieval precision 30-40% (Gartner, 2024) |
| Open-source options | Neo4j Community, Ontotext GraphDB Free, Wikidata, DBpedia |
| Enterprise governance | Only Stardog and Atlan include policy enforcement in the KG layer |
How knowledge graph tools differ from graph databases
Permalink to “How knowledge graph tools differ from graph databases”The terms are used interchangeably in vendor marketing, but they describe different things.
A graph database is a storage engine. It stores nodes (entities) and edges (relationships) with properties, and executes traversal queries efficiently. Neo4j, TigerGraph, and Azure Cosmos DB for Apache Gremlin are graph databases. They are excellent at answering questions like “what are all the customers connected to this account within three hops?” They are not designed to answer “what does this metric mean according to the business’s approved definition, and which data lineage path validates it?”
A knowledge graph tool adds a semantic layer on top of graph storage. That layer includes formal ontologies (typically expressed in W3C OWL or RDFS), a reasoning engine that infers implicit relationships from declared rules, and query support via SPARQL, the W3C standard for RDF-based graphs. According to the W3C OWL 2 specification (w3.org/TR/owl2-overview/), OWL enables description logic reasoning, which means a system can infer that if “Customer” is a subclass of “DataSubject” and GDPR applies to “DataSubjects,” then GDPR applies to all Customers, without that rule being explicitly stated for every entity.
Aidan Hogan et al., in the ACM Computing Surveys paper “Knowledge Graphs” (2021), identify three essential components of a knowledge graph: entities, relationships, and semantic descriptions. Most graph databases cover the first two. The third is the one AI agents require for correct reasoning, and it is precisely what most “knowledge graph tools” on the market omit.
For enterprise AI, this distinction is not academic. An AI agent querying a graph database can traverse relationships at speed. An AI agent querying a semantic knowledge graph can reason about what those relationships mean, enforce constraint violations, and answer questions the business actually asks. Enterprises building AI that needs to be right, not just fast, need tools that address the semantic layer, and the choice of tooling is where AI agent accuracy and project success or failure begins.
The three layers every enterprise knowledge graph stack needs
Permalink to “The three layers every enterprise knowledge graph stack needs”Before comparing specific tools, it helps to understand what layer each tool addresses. Enterprise teams that conflate these layers end up with capability gaps that surface as AI reasoning failures.
Layer 1: Storage and traversal. Graph databases belong here. Neo4j, TigerGraph, Amazon Neptune (property graph mode), and Azure Cosmos DB for Gremlin store entities and relationships and execute traversal queries efficiently. They are infrastructure. They answer “what is connected to what.” For a broader view of how these layers compose, see AI agent stack.
Layer 2: Semantic reasoning. Triple stores with OWL support belong here. Stardog, Ontotext GraphDB, and Franz AllegroGraph store RDF triples, enforce ontology schemas, infer implicit relationships using description logic, and expose SPARQL endpoints. They answer “what does this connection mean, and what can I infer from it?”
Layer 3: Governed context delivery. This layer is newer and often absent from both the tools market and the SERP. It is the layer that takes semantic knowledge and makes it governable, versioned, access-controlled, and consumable by AI agents via a protocol like MCP. Atlan’s Enterprise Data Graph operates here, combining lineage, business glossary terms, policies, and ownership into a metadata layer for AI served to AI agents through governed channels.
Most tools cover one layer. Some cover two. Enterprise AI needs all three wired together. Teams that pick a single tool and assume it covers all layers end up with traversal power but no semantic grounding, or semantic depth with no governance rail for AI consumption. This is one of the key reasons why AI agents fail in production.
What to look for when evaluating knowledge graph tools
Permalink to “What to look for when evaluating knowledge graph tools”For enterprise AI use cases, evaluate tools across six dimensions:
Query language: Cypher (Neo4j) is developer-friendly but not a W3C standard. SPARQL is the standard for RDF-based KGs and is required for interoperability with W3C ontologies and linked data sources. GSQL (TigerGraph) is proprietary but powerful for analytics traversal.
Ontology and reasoning support: OWL 2 description logic reasoning is the gold standard for semantic inference. SHACL (Shapes Constraint Language) adds validation rules. RDFS adds class hierarchy inference. If your use case requires constraint enforcement and inference, confirm OWL 2 support before evaluating further. See also: what is ontology in AI.
Integration surface: Does the tool expose a REST API? Does it have a native MCP server or support context delivery to AI agents? Does it integrate with your data catalog for AI, lineage system, or governance platform?
Scalability model: Managed cloud (Neptune, Stardog Cloud) reduces operational overhead. Self-hosted open-source (Neo4j Community, GraphDB Free) requires platform investment. Enterprise SaaS (Atlan, Stardog Enterprise) includes support and governance features but carries higher cost.
Governance features: Access control at the graph level, audit logging, versioning of ontology changes, and policy enforcement are non-negotiable for regulated industries and AI governance.
Pricing model: Neo4j has a free Community edition and commercial Enterprise tier. Ontotext GraphDB has a free standard edition and commercial enterprise edition. Amazon Neptune is consumption-based on AWS. Stardog, AllegroGraph, and Atlan are commercial with custom enterprise pricing.
The AI Context Stack
Before choosing knowledge graph tools, understand the full architecture. This brief maps the four layers every enterprise AI agent stack needs — and where graph tooling fits.
Read the BriefKnowledge graph tools compared: 9 platforms reviewed
Permalink to “Knowledge graph tools compared: 9 platforms reviewed”| Tool | Type | Query language | OWL reasoning | Best for |
|---|---|---|---|---|
| Neo4j | Property graph database | Cypher | No | Developer teams; graph traversal |
| Amazon Neptune | Managed graph service | Gremlin, SPARQL | RDFS only | AWS-native teams |
| Stardog | Semantic KG platform | SPARQL + virtual graphs | Full OWL 2 | Regulated enterprise |
| Ontotext GraphDB | Semantic triple store | SPARQL | OWL 2 | Semantic web; open-source users |
| Franz AllegroGraph | Semantic triple store | SPARQL | OWL | Financial / healthcare |
| TigerGraph | Property graph database | GSQL | No | Large-scale analytics |
| Azure Cosmos DB | Multi-model database | Gremlin | No | Azure-native teams |
| Wikidata | Public knowledge graph | SPARQL | Limited | Research; public open data |
| Atlan Enterprise Data Graph | Governed metadata KG | MCP server | N/A — governance-native | Enterprise AI governance |
1. Neo4j
Permalink to “1. Neo4j”Neo4j is the most widely adopted graph database and a common foundation for knowledge graph applications. It uses the property graph model with nodes, relationships, and properties, queried via the Cypher language. Neo4j does not natively support OWL reasoning or SPARQL, which means the semantic layer must be built on top of the database rather than being native to it. Teams use Neo4j for KG applications by defining their own schema conventions and using plugins like neosemantics (n10s) to layer RDF/SPARQL support. The Neo4j Knowledge Graph construction toolkit is popular among developers. For enterprises needing native semantic reasoning, Neo4j alone is insufficient.
Best for: Developer teams building KG applications with strong graph traversal needs; well-documented ecosystem.
Limitation: No native OWL reasoning; semantic layer is DIY; SPARQL support requires additional tooling.
Pricing: Community edition (open-source, Apache 2.0); Enterprise (commercial, custom pricing).
2. Amazon Neptune
Permalink to “2. Amazon Neptune”Amazon Neptune is a managed graph database service supporting both the property graph model (via Gremlin and openCypher) and RDF graphs (via SPARQL). For teams on AWS, Neptune removes the operational burden of running graph infrastructure. The RDF mode supports basic RDFS inference but not full OWL 2 description logic. Neptune integrates well with other AWS services (S3, Glue, SageMaker) and is a reasonable choice for teams that need both graph traversal and some RDF capability without leaving the AWS ecosystem. It is not a full semantic knowledge graph platform.
Best for: AWS-native enterprises needing managed graph infrastructure with RDF/SPARQL support.
Limitation: RDFS inference only; not full OWL 2; governance and ontology management are external concerns.
Pricing: AWS consumption-based (per I/O request, per GB storage).
3. Stardog
Permalink to “3. Stardog”Stardog is the closest to a “true” enterprise knowledge graph platform in this list. It combines an RDF triple store, full OWL 2 description logic reasoning, SPARQL query support, data virtualization (querying external sources as if they were part of the graph), and policy enforcement. Stardog’s reasoning engine can infer relationships that are not explicitly stored, which is essential for ontology-intensive applications in healthcare, financial services, and regulatory compliance. It also includes data masking and access control at the graph level. According to Stardog’s platform documentation, it supports virtual graphs over SQL databases, REST APIs, and cloud data warehouses, making it a genuine integration hub for semantic data.
Best for: Enterprise KG with OWL 2 reasoning; regulatory and compliance use cases; data virtualization.
Limitation: Commercial-only; steeper learning curve than property graph tools; smaller community than Neo4j.
Pricing: Commercial enterprise licensing (custom; Stardog Cloud also available as managed option).
4. Franz AllegroGraph
Permalink to “4. Franz AllegroGraph”Franz AllegroGraph is an enterprise RDF triple store and graph database with semantic reasoning (OWL) and GeoSPARQL support for geospatial knowledge graphs. It has been in production in defense, intelligence, and life sciences for over a decade. AllegroGraph supports federated SPARQL queries, temporal reasoning, and social network analysis on top of its RDF foundation. It is less visible in mainstream enterprise data teams but has deep capabilities for highly specific ontology-driven use cases.
Best for: Complex ontology-heavy deployments; geospatial knowledge graphs; long-standing government and life sciences implementations.
Limitation: Smaller ecosystem than Neo4j or Neptune; less cloud-native; pricing model is commercial-first.
Pricing: Commercial enterprise licensing (free version available for small datasets).
5. Ontotext GraphDB
Permalink to “5. Ontotext GraphDB”Ontotext GraphDB is an enterprise RDF semantic graph database built on top of the Sesame/Eclipse RDF4J framework. It supports OWL 2 RL and QL profiles, SPARQL 1.1, and SHACL validation. GraphDB is widely used in life sciences, publishing, media, and cultural heritage — any domain where linked data and ontology-driven classification are first-class requirements. Ontotext has published extensively on knowledge graph construction for AI, and GraphDB integrates with tools like OpenRefine for data transformation and with vector databases for hybrid semantic and embedding retrieval.
Best for: Ontology-driven knowledge graphs in life sciences, pharma, publishing; W3C-compliant semantic data infrastructure.
Limitation: OWL 2 RL/QL profiles only (not full EL or DL); less adoption in general enterprise data teams.
Pricing: Free (standard edition); GraphDB Enterprise (commercial, custom pricing).
6. Microsoft Azure Cosmos DB for Apache Gremlin
Permalink to “6. Microsoft Azure Cosmos DB for Apache Gremlin”Azure Cosmos DB for Apache Gremlin is a property graph database hosted in Azure. It stores vertices and edges and supports the Gremlin traversal language. It is not a knowledge graph tool in the semantic reasoning sense. It has no OWL support, no SPARQL, and no ontology layer. Teams use it for entity graphs in Azure-native applications where the priority is low-latency traversal and global distribution, not semantic inference. If your team is considering this for knowledge graph use, understand that you are getting a graph storage layer and will need to build the semantic layer externally.
Best for: Azure-native entity graphs; low-latency graph traversal at scale within the Microsoft ecosystem.
Limitation: Not a knowledge graph tool; no semantic reasoning; Gremlin is not a W3C standard.
Pricing: Azure consumption-based (RU/s and storage).
7. TigerGraph
Permalink to “7. TigerGraph”TigerGraph is a distributed graph analytics platform designed for high-volume graph traversal, pattern matching, and graph machine learning. It uses GSQL, a proprietary query language optimized for deep-link analytics. TigerGraph is strong for fraud detection, recommendation engines, and supply chain analysis, where the question is “what pattern of relationships matches a known risk signature?” It is not a semantic knowledge graph tool. There is no OWL, no SPARQL, and no ontology reasoning. It is a graph analytics engine, and an excellent one, but it addresses Layer 1 of the enterprise KG stack.
Best for: Large-scale graph analytics; fraud detection; real-time recommendation; deep traversal queries.
Limitation: Analytics-first, not semantics-first; no OWL/SPARQL; not suited for ontology-driven AI context delivery.
Pricing: TigerGraph Cloud (consumption-based); TigerGraph Enterprise (self-hosted, commercial).
8. Wikidata and DBpedia
Permalink to “8. Wikidata and DBpedia”Wikidata is the W3C-compliant, machine-readable linked knowledge graph maintained by the Wikimedia Foundation. DBpedia is a structured version of Wikipedia’s infoboxes, exposed as RDF with a SPARQL endpoint. Both are valuable as public reference knowledge graphs for bootstrapping domain ontologies, enriching entity graphs, and testing SPARQL queries against real-world data. They are not enterprise tools. Their data governance is community-managed, their schemas evolve without notice, and they contain public data only. Production AI agents operating on proprietary business context cannot rely on public KGs as their primary knowledge layer.
Best for: Bootstrapping ontologies; enriching internal entity graphs with public knowledge; research and prototyping.
Limitation: Not enterprise tools; public governance; no SLA; not suitable for proprietary production AI context.
Pricing: Free (public SPARQL endpoints).
9. Atlan Enterprise Data Graph
Permalink to “9. Atlan Enterprise Data Graph”Atlan’s Enterprise Data Graph is a governed metadata knowledge graph purpose-built for enterprise AI context delivery. It is distinct from all other tools in this list: it does not compete with Neo4j for general-purpose graph applications, nor with Stardog for ontology-heavy triple store use cases. It is built for the third layer of the enterprise KG stack, governed context delivery, at the point where metadata must become a reliable, versioned, auditable substrate for AI agents.
The Enterprise Data Graph connects data assets (tables, dashboards, APIs, ML models), lineage relationships, business glossary terms, data quality for AI signals, policies, and ownership information into a unified graph. The Business Glossary functions as the semantic layer, linking approved business terms to physical data assets. The active ontology graph evolves as systems and business context change, and Atlan supports ontology import and mapping so enterprises can operationalize external standards (like FIBO for financial services) inside the AI agent governance layer.
The Semantic View Generator exposes governed metrics via MCP to AI agents. The MCP Server provides a governed, access-controlled interface so AI agents receive only the context they are authorized to consume, in a form they can reason over.
This is not a general-purpose knowledge graph. It is the governed context layer that sits above your data warehouse, data lakehouse, and existing graph infrastructure, and makes that context AI-consumable. As Joe DosSantos, VP of Enterprise Data & Analytics at Workday, describes it: “All of the work that we did to get to a shared language at Workday can be leveraged by AI via Atlan’s MCP server.”
Best for: AI governance; governed AI context delivery; connecting lineage, business glossary, and policies for AI agent consumption; enterprises on Snowflake, Databricks, dbt, or BigQuery stacks.
Limitation: Not a general-purpose triple store or graph analytics engine; requires existing data infrastructure to govern.
Pricing: Enterprise SaaS (custom; contact Atlan for pricing).
How do I choose between Neo4j, Stardog, and Atlan for enterprise AI?
Permalink to “How do I choose between Neo4j, Stardog, and Atlan for enterprise AI?”The three tools address three different layers of the enterprise knowledge graph stack. Choosing one does not exclude the others — and for many enterprises, the right answer is a combination.
Start with Neo4j if your primary need is graph traversal performance and you have engineering bandwidth to build the semantic layer yourself. Neo4j’s developer ecosystem is the largest of any graph tool, and the neosemantics plugin provides a path toward RDF/SPARQL without migrating your existing data model.
Start with Stardog (or Ontotext GraphDB) if your use case requires formal ontology reasoning, SPARQL compliance, and data virtualization across multiple source systems. For regulated industries (healthcare, financial services, pharma) where OWL-based inference and constraint enforcement are requirements, Stardog is the most capable option. For context on how ontology fits into AI architecture, see ontology-first AI architecture.
Start with Atlan if your primary question is “how do AI agents get governed, accurate business context from across our data estate?” Atlan does not replace your graph database or semantic reasoner; it governs the context layer above them and delivers that context to AI agents via MCP. For enterprises on Snowflake, Databricks, or dbt, Atlan integrates with your existing metadata knowledge graph infrastructure rather than replacing it. See why this is the layer that matters most: why AI agents need an enterprise context layer.
For comprehensive enterprise AI infrastructure, the stack looks like: graph storage (Neo4j or Neptune) + semantic reasoner (Stardog or GraphDB) + governed context delivery (Atlan). The context graph vs knowledge graph distinction is worth understanding before committing to any single-tool architecture.
CIO's Guide to Context Graphs
Building a knowledge graph program is a leadership decision, not just a tooling one. This guide covers governance, ROI, and architecture decisions for enterprise teams.
Get the CIO's GuideDoes my AI agent need a knowledge graph or a vector database?
Permalink to “Does my AI agent need a knowledge graph or a vector database?”Both, for different reasons, and they serve complementary functions in an enterprise AI agent stack.
Vector databases (Pinecone, Weaviate, pgvector) store embeddings for similarity-based retrieval. They answer “what chunks of text are semantically similar to this query?” They are fast and effective for retrieval-augmented generation but do not enforce semantic constraints, track entity relationships, or apply business rules.
Knowledge graph tools store structured entity-relationship data with semantic meaning. They answer “what is the approved business definition of this metric, what lineage path validates it, and which policies restrict who can see it?” They are slower for unstructured retrieval but essential for structured reasoning and constraint enforcement.
According to Gartner (2024), semantic enrichment improves AI retrieval precision by 30-40% compared to unstructured vector search alone. The combination, using a knowledge graph for semantic grounding and a vector store vs graph database approach, outperforms either approach alone for enterprise AI use cases where factual accuracy and policy compliance are non-negotiable.
Real stories from real customers: knowledge graphs powering enterprise AI
Permalink to “Real stories from real customers: knowledge graphs powering enterprise AI”"We're excited to build the future of AI governance with Atlan. All of the work that we did to get to a shared language at Workday can be leveraged by AI via Atlan's MCP server…as part of Atlan's AI Labs, we're co-building the semantic layer that AI needs with new constructs, like context products."
— Joe DosSantos, VP of Enterprise Data & Analytics, Workday
"Atlan is much more than a catalog of catalogs. It's more of a context operating system…Atlan enabled us to easily activate metadata for everything from discovery in the marketplace to AI governance to data quality to an MCP server delivering context to AI models."
— Sridher Arumugham, Chief Data & Analytics Officer, DigiKey
See Context Agents Live
Watch how enterprise data teams are delivering governed knowledge graph context to AI agents — live demonstrations from production deployments.
Watch Live DemosWhy the knowledge graph layer separates AI projects that ship from those that stall
Permalink to “Why the knowledge graph layer separates AI projects that ship from those that stall”The most common mistake in enterprise AI infrastructure is treating knowledge graphs, semantic layers, and unified context layer as three names for the same thing — or as three competing options where you pick one.
They are three distinct layers. A property graph database like Neo4j is Layer 1: fast traversal, flexible schema, excellent developer ergonomics. A semantic reasoner like Stardog or Ontotext GraphDB is Layer 2: ontology-based inference, SPARQL compliance, constraint enforcement. A governed context delivery layer like Atlan’s Enterprise Data Graph is Layer 3: the point where semantic knowledge becomes auditable, access-controlled, and AI-consumable at enterprise scale.
Enterprises that pick only a graph database end up with a traversal engine and no semantic grounding. Their AI agents can navigate relationships quickly but cannot answer “what does this metric mean?” or “is this data subject to GDPR?” Enterprises that invest in a semantic reasoner but skip the governance layer get inference power that is invisible to their AI agents because there is no governed protocol for delivering it. This is part of why AI agent hallucination remains a persistent problem in production. The enterprises that wire all three layers together are the ones building AI that answers questions the business actually asks.
The context layer for enterprise AI is what closes this gap. It is not a replacement for your knowledge graph stack; it is the governance substrate that makes your knowledge graph AI-ready. The evidence from Workday and DigiKey points in the same direction: the teams delivering AI in production are not choosing between tools. They are wiring the stack.
FAQs about knowledge graph tools
Permalink to “FAQs about knowledge graph tools”-
What is the best knowledge graph tool for enterprise AI?
The best knowledge graph tool depends on your use case. For ontology-based semantic reasoning, Stardog or Ontotext GraphDB are purpose-built. For scalable graph traversal, Neo4j or Amazon Neptune fit well. For governed AI context delivery combining lineage, policies, and business terms, Atlan’s Enterprise Data Graph is purpose-built for that layer. Most enterprise AI stacks need tools from more than one of these categories. -
Is Neo4j a knowledge graph tool?
Neo4j is a property graph database commonly used to build knowledge graph applications, but it is not a knowledge graph tool by itself. It stores nodes and relationships but does not natively enforce ontology schemas or OWL-based semantic reasoning. Many teams build knowledge graphs on top of Neo4j by adding their own semantic layer using the neosemantics (n10s) plugin. For a deeper comparison, see combining knowledge graphs with LLMs. -
What is the difference between a graph database and a knowledge graph tool?
A graph database stores nodes and edges with properties and is optimized for traversal queries. A knowledge graph tool adds a semantic layer through ontologies (OWL, RDFS), supports SPARQL queries, and enforces type constraints via a reasoning engine. Knowledge graph tools can use graph databases as their storage layer, but they add ontology-based inference on top that graph databases do not provide natively. -
Does Atlan have a knowledge graph?
Atlan’s Enterprise Data Graph is a governed metadata knowledge graph that connects data assets, lineage, business glossary terms, policies, and ownership relationships. It is specifically designed as a context-aware AI agents substrate for enterprise AI, not a general-purpose knowledge graph. It differs from tools like Neo4j or Stardog in that it is built for AI governance and governed context delivery, not general triple store or graph analytics use cases. -
What knowledge graph tools support SPARQL?
Knowledge graph tools that support SPARQL include Stardog, Ontotext GraphDB, Franz AllegroGraph, and Amazon Neptune (for RDF graphs). SPARQL is the W3C standard query language for RDF-based knowledge graphs. Property graph databases like Neo4j use Cypher instead of SPARQL, which is a different query paradigm and does not support OWL semantic reasoning. -
How much do knowledge graph tools cost?
Pricing varies widely. Neo4j Community and Ontotext GraphDB Free are open-source with no licensing cost. Amazon Neptune and TigerGraph Cloud use consumption-based pricing. Stardog, Franz AllegroGraph, and Atlan are enterprise commercial platforms with custom pricing based on deployment size, data volume, and support tier. For budget planning, expect open-source tools to carry significant infrastructure and engineering costs even without licensing fees. See also: AI data infrastructure readiness. -
Can I use a knowledge graph tool with my existing data catalog?
Yes, and for enterprise AI this is the recommended approach. A knowledge graph tool and a data catalog serve different functions. Data catalogs (Alation, Collibra, DataHub) focus on metadata discovery and governance workflows. Knowledge graph tools add semantic reasoning and graph traversal. Atlan bridges these functions by combining a governed metadata catalog with an Enterprise Data Graph that can be queried by AI agents, serving as both catalog and context layer for AI agents.
Sources
Permalink to “Sources”- W3C OWL 2 Web Ontology Language Overview. W3C. https://www.w3.org/TR/owl2-overview/
- W3C SPARQL 1.1 Query Language. W3C. https://www.w3.org/TR/sparql11-query/
- W3C RDF 1.1 Concepts and Abstract Syntax. W3C. https://www.w3.org/TR/rdf11-concepts/
- Hogan, A. et al. “Knowledge Graphs.” ACM Computing Surveys, 2021. https://dl.acm.org/doi/10.1145/3447772
- Pan, J.Z. et al. “Unifying Large Language Models and Knowledge Graphs: A Roadmap.” IEEE TKDE, 2024. https://arxiv.org/abs/2306.08302
- Gartner. “Graph Technologies Are Becoming Essential for Data and AI Strategy.” 2024. https://www.gartner.com/en/documents/graph-technologies-data-ai-strategy
- Gartner. “Market Guide for Knowledge Graph Technology.” 2024. https://www.gartner.com/en/documents/market-guide-knowledge-graph-technology
- Neo4j Knowledge Graph Documentation. Neo4j. https://neo4j.com/developer/graph-database/
- Stardog Enterprise Knowledge Graph Platform. Stardog. https://www.stardog.com/platform/
- Ontotext GraphDB Product Overview. Ontotext. https://www.ontotext.com/products/graphdb/
- Amazon Neptune Developer Guide. AWS. https://docs.aws.amazon.com/neptune/latest/userguide/intro.html
