Entities, Relationships, and Properties in Knowledge Graphs

Entities, relationships, and properties are the three basic building blocks of a knowledge graph.

Entities represent the things in the graph. Relationships connect those things. Properties describe them with details such as names, dates, labels, confidence scores, source references, and evidence.

In AI systems, these building blocks help retrieval move beyond isolated text chunks. They let an application find a relevant entity, follow its connections, collect supporting evidence, and give an LLM structured context for answering questions.

Short Answer

In a knowledge graph, an entity is a node, a relationship is an edge, and a property is an attribute attached to a node or edge.

For example, Acme Corp and Northwind Analytics are entities. acquired is a relationship. acquisition_date, source_document, and confidence are properties.

Together, they turn raw facts into a connected structure that AI systems can search, traverse, explain, and use in GraphRAG.

Why These Building Blocks Matter

A document search system can retrieve text that seems relevant. A knowledge graph can also show how the retrieved information is connected.

That difference matters for AI applications that need to answer questions such as:

• Who is connected to this organization?
• Which documents support this claim?
• Which services depend on this component?
• Which customers are affected by this incident?
• Which entities appear together across multiple reports?

Entities, relationships, and properties make those questions possible.

What Is an Entity?

An entity is a distinct thing the graph knows about.

Entities can be concrete things such as people, companies, products, contracts, tickets, datasets, APIs, or locations. They can also be abstract concepts such as policies, risks, symptoms, topics, skills, or research methods.

In a graph, each entity is usually represented as a node.

Examples of Entities

Common entity examples include:

• Person: Sara Kim
• Organization: Acme Corp
• Product: Analytics Dashboard
• Document: Refund Policy PDF
• SupportTicket: Ticket-1042
• Service: Billing API
• Concept: Entity Resolution
• Location: London

The exact entity types depend on what the AI system needs to retrieve and reason about.

Entity Mentions vs Entities

An entity mention is a piece of text that refers to an entity. The entity is the real thing being referred to.

For example, a document might mention IBM, International Business Machines, and IBM Corp.. These may all refer to the same entity.

This distinction is important because AI extraction pipelines often detect mentions first. The system then needs entity resolution to decide which mentions belong to the same entity node.

What Is a Relationship?

A relationship is a connection between two entities.

Relationships are usually represented as edges. They are what make the graph a graph rather than a list of objects.

For example:

Sara Kim -- works_for -- Acme Corp
Acme Corp -- owns -- Billing API
Billing API -- depends_on -- Identity Service
Refund Policy PDF -- mentions -- Billing API

These edges let the system traverse from a person to an organization, from an organization to a service, and from a service to relevant documents.

Direction Matters

Many relationships are directional.

Acme Corp acquired Northwind Analytics does not mean the same thing as Northwind Analytics acquired Acme Corp.

Direction helps graph queries express meaning accurately. It also helps LLMs receive clearer context when graph results are turned into natural language.

Relationship Types Should Be Specific

Useful relationship types describe the connection clearly.

Examples:

• works_for
• owns
• depends_on
• mentions
• caused_by
• located_in
• supports
• contradicts

A vague relationship such as related_to can be useful as a fallback, but too many generic edges make the graph less helpful for reasoning.

What Is a Property?

A property is a detail attached to an entity or relationship.

Properties are not usually traversed like relationships. They describe, qualify, identify, or filter graph elements.

For example, an entity might have a name, type, canonical ID, description, aliases, source IDs, and timestamps.

Entity Properties

An entity may have properties such as:

• name
• canonical_id
• entity_type
• description
• aliases
• source_ids
• created_at
• updated_at
• confidence

These properties help search, deduplication, display, filtering, and provenance.

Relationship Properties

Relationships can also have properties.

For example:

Acme Corp -- acquired -- Northwind Analytics
  acquisition_date: 2024-05-12
  source_document: contract-88.pdf
  evidence_text: "Acme Corp completed its acquisition of Northwind Analytics..."
  confidence: 0.91

Relationship properties are especially useful when the connection has a time range, source, weight, confidence, or explanation.

When to Use a Property vs a Relationship

Use a property when the detail describes one entity or one edge.

Use a relationship when the detail connects two things and may need to be traversed.

For example, company_name could be a property on a document, but Document -- mentions -- Company is a relationship. The relationship is better if the AI system needs to find all documents that mention a company or traverse from the company to connected documents.

Why Properties Matter for AI

Properties help AI systems produce grounded and explainable answers.

For GraphRAG, useful properties include source references, source chunk IDs, evidence text, summaries, confidence values, and timestamps.

These fields help the application show where an answer came from and whether the supporting fact is current or reliable.

How These Parts Work in GraphRAG

In GraphRAG, a user query may first identify relevant entities.

Those entities act as entry points into the graph. The retrieval system can then follow relationships, collect neighboring entities, gather properties, and pull source chunks connected to those nodes or edges.

The LLM receives richer context than a flat chunk list because it can see connected facts and evidence.

Example GraphRAG Flow

A user asks: “Which services could be affected by the billing outage?”

The system might:

• identify billing outage as an event entity
• follow affects relationships to services
• follow depends_on relationships to downstream systems
• retrieve source incidents and runbooks
• pass connected evidence to the LLM

This is different from only searching for text chunks that mention “billing outage.”

Provenance Properties

Provenance properties explain where graph facts came from.

Useful provenance fields include:

• source_document_id
• source_chunk_id
• source_url
• extraction_time
• extraction_model
• evidence_text
• confidence

Without provenance, it is difficult to audit graph facts or explain AI answers.

Common Mistakes

• Treating every noun phrase as an entity.
• Using vague relationship types for everything.
• Putting traversable connections into text properties only.
• Forgetting relationship direction.
• Failing to store evidence and source IDs.
• Creating duplicate entities for the same real-world thing.
• Adding too many properties that never support retrieval or explanation.

Best Practices

• Choose entity types based on real questions the AI system must answer.
• Use relationship names that describe meaningful connections.
• Store provenance on important entities and relationships.
• Keep stable IDs for entity resolution.
• Use properties for filtering, evidence, and display.
• Use relationships for connections that need traversal.
• Test the graph with real GraphRAG retrieval examples.

Summary

Entities, relationships, and properties are the foundation of a knowledge graph.

Entities represent things. Relationships connect those things. Properties describe entities and relationships with details, evidence, timestamps, confidence, and identifiers.

In AI systems, these building blocks help retrieval understand not only what content is relevant, but how facts, documents, people, systems, and concepts are connected.