Skip to main content

​
Overview

Knowledge graphs provide a structured representation of entities and the relationships between them. While the Knowledge Base stores unstructured text for semantic retrieval, knowledge graphs organize information as nodes (entities) and edges (relationships), enabling precise traversal, reasoning, and complex question answering that text search alone cannot achieve.

​
Why Knowledge Graphs?

​
Core Concepts

​
Entities

Entities are the nodes in a knowledge graph. Each entity has a type, a unique identifier, and a set of properties. 
{
  "id": "entity_auth_service",
  "type": "Service",
  "properties": {
    "name": "Authentication Service",
    "team": "Platform Security",
    "language": "Python",
    "created_date": "2024-03-15"
  }
}

​
Relationships

Relationships are the directed edges that connect entities. Each relationship has a type, a source entity, a target entity, and optional properties. 
{
  "type": "DEPENDS_ON",
  "source": "entity_auth_service",
  "target": "entity_postgres_db",
  "properties": {
    "dependency_type": "runtime",
    "since": "2024-03-15"
  }
}

​
Ontology

An ontology defines the schema of a knowledge graph: what entity types exist, what relationship types are allowed, and what properties each can have. Nadoo AI supports RDF/OWL ontologies for formal schema definition. Learn more about ontology management

​
Architecture

​
Graph Stores

Nadoo AI supports three graph store backends, selectable based on your infrastructure and scale requirements.

​
Neo4j

A native graph database optimized for traversal-heavy workloads.
  • Best for: Complex graph queries with deep traversals (5+ hops)
  • Query language: Cypher (native) + SPARQL (via adapter)
  • Scale: Billions of nodes and relationships
  • Deployment: Self-hosted or Neo4j AuraDB
{
  "graph_store": {
    "provider": "neo4j",
    "uri": "bolt://localhost:7687",
    "username": "neo4j",
    "password": "your-password"
  }
}

​
PostgreSQL

Uses PostgreSQL with graph query extensions. Shares the same database instance as the rest of the platform.
  • Best for: Smaller graphs where operational simplicity is a priority
  • Query language: SPARQL (via query translation)
  • Scale: Millions of nodes and relationships
  • Deployment: Uses the existing platform PostgreSQL instance
{
  "graph_store": {
    "provider": "postgresql",
    "connection": "default"
  }
}

​
Apache Jena

A Java-based RDF framework with full SPARQL 1.1 support and OWL reasoning.
  • Best for: Deployments that require standards-compliant RDF/OWL reasoning
  • Query language: SPARQL 1.1 (native)
  • Scale: Hundreds of millions of triples
  • Deployment: Self-hosted TDB2 or Fuseki server
{
  "graph_store": {
    "provider": "jena",
    "endpoint": "http://localhost:3030/dataset"
  }
}

​
Entity Extraction from Documents

Knowledge graphs can be populated automatically by extracting entities and relationships from your uploaded documents.

​
Extraction Pipeline

1

Named Entity Recognition

An NLP model identifies entities in the document text: people, organizations, services, products, locations, dates, and custom entity types defined in your ontology.
2

Relationship Extraction

A second model (or the same LLM in a single pass) identifies relationships between detected entities. For example, from “The Platform Security team built the Authentication Service in March 2024”, the system extracts:
  • Entity: Platform Security (Team)
  • Entity: Authentication Service (Service)
  • Relationship: Platform Security —BUILT—> Authentication Service
  • Property: date: 2024-03
3

Ontology Validation

Extracted entities and relationships are validated against the knowledge graph’s ontology. Invalid types or relationships are flagged for manual review.
4

Graph Insertion

Validated entities and relationships are inserted into the graph store. Duplicate entities are merged using configurable identity resolution rules.

​
Configuration

{
  "entity_extraction": {
    "enabled": true,
    "model": "gpt-4o",
    "entity_types": ["Person", "Team", "Service", "Product", "Technology"],
    "relationship_types": ["BUILT", "MANAGES", "DEPENDS_ON", "USES", "MEMBER_OF"],
    "auto_validate": true
  }
}

​
Querying Knowledge Graphs

​
SPARQL

The primary query language for Nadoo AI knowledge graphs. SPARQL provides powerful pattern matching, filtering, and aggregation over graph data. 
SELECT ?service ?team WHERE {
  ?service a :Service .
  ?team a :Team .
  ?team :BUILT ?service .
  ?service :language "Python" .
}
Learn more about SPARQL queries

​
Natural Language Queries

For AI agent workflows, the knowledge graph can be queried using natural language. The platform translates the user’s question into a SPARQL query, executes it, and returns the results. 
User: "Which services does the Platform Security team manage?"

Generated SPARQL:
SELECT ?service WHERE {
  :PlatformSecurity :MANAGES ?service .
  ?service a :Service .
}

Result: Authentication Service, Key Management Service, SSO Gateway

​
Integration with Workflows

Add a Knowledge Graph Query node to your workflow to incorporate graph-based reasoning: This pattern uses the knowledge graph for structured lookups and the knowledge base for contextual retrieval, combining both in the AI agent’s prompt.

​
Next Steps

SPARQL Queries

Write and execute SPARQL queries against your knowledge graph

Ontology Management

Define entity types, relationships, and validation rules

Knowledge Base

Unstructured document retrieval with RAG

Contextual Retrieval

Advanced retrieval strategies that complement graph-based reasoning