Subject-Predicate-Object Triples Explained

The Three Parts

Subject

The subject is the entity that the triple makes a statement about. In most knowledge graphs, subjects are entities: things that have identity and properties. "PostgreSQL," "authentication service," "Sarah Chen," "us-east-1 region." Subjects are typically stored as unique identifiers (a URI, a name, or a database ID) that distinguish them from other entities. The same subject appears across many triples, building up a rich description of that entity from multiple individual facts.

Predicate

The predicate describes the type of relationship between the subject and the object. It is the verb of the triple. "uses," "depends on," "is maintained by," "is located in," "was created on." Predicates should be specific enough to be meaningful but general enough to be reusable. "uses" is better than "utilizes for data storage" because it composes with any subject-object pair. But "relates to" is too vague to support useful traversal because it does not distinguish meaningful relationships from coincidental ones.

Predicate design is one of the most important decisions in knowledge graph construction. Too few predicates (everything is "relates to") produces a graph where traversal cannot distinguish between different types of connections. Too many predicates (unique wording for every relationship) produces a graph where similar relationships cannot be traversed together. A vocabulary of 15 to 30 well-chosen predicates covers most domains effectively.

Object

The object is what the subject is related to. Objects can be entities (another node in the graph) or literal values (strings, numbers, dates). When the object is an entity, the triple creates a connection between two nodes that can be traversed in either direction. When the object is a literal value, the triple attaches a property to the subject. "PostgreSQL" "version is" "15.4" uses a literal object to store a property. "PostgreSQL" "is used by" "order service" uses an entity object to create a traversable connection.

How Triples Compose

The power of triples comes from composition. Individual triples are simple facts. Combined, they form a rich, interconnected network that captures complex knowledge. Consider these triples:

From seven simple triples, you can now answer questions that none of the individual triples directly address. "What infrastructure does the payments team maintain?" Traverse from payments_team through maintained_by (reverse) to order_service, then through uses and depends_on to PostgreSQL and Redis. "Is there a single point of failure in us-east-1?" Both PostgreSQL and Redis are hosted there, and the order service depends on both, so yes. These answers emerge from the composition of triples, not from any single statement.

Triples compose without schema changes. Adding a new fact about the order service (like "order_service exposes /api/orders") is just another triple. Adding a new entity type (like a monitoring service) is just triples that reference it. No columns to add, no tables to alter, no schema migrations. This flexibility is why knowledge graphs handle evolving domains well.

Direction and Symmetry

Triples have direction: they go from subject to object through the predicate. "order_service uses PostgreSQL" is not the same as "PostgreSQL uses order_service." The direction encodes meaning, and getting it right matters for traversal. When you query "what does the order service use," you traverse outward from order_service through "uses" edges. When you query "what uses PostgreSQL," you traverse inward to PostgreSQL through "uses" edges.

Some relationships are symmetric: "A collaborates_with B" implies "B collaborates_with A." Others are asymmetric: "A depends_on B" does not imply "B depends_on A." Graph databases handle both, but you need to be deliberate about which relationships should be traversable in both directions and which should not. In practice, most queries traverse in the natural direction of the predicate, but being able to reverse traversal ("what depends on this service") is one of the most valuable capabilities of a knowledge graph.

Reification: Metadata About Triples

Sometimes you need to make statements about statements. "Sarah said that the order service uses PostgreSQL" is a statement about the triple (order_service, uses, PostgreSQL). "As of January 2026, the order service uses PostgreSQL" attaches temporal scope to the triple. This process of making triples about triples is called reification.

In practice, reification is implemented by giving each triple an identifier and then creating new triples with that identifier as the subject. The triple (order_service, uses, PostgreSQL) gets ID t1, and then you add (t1, stated_by, Sarah), (t1, valid_from, "2026-01-15"), (t1, confidence, 0.92). This lets you track provenance, temporal validity, and confidence for every fact in the graph.

Adaptive Recall uses reification extensively. Every entity relationship carries metadata about when it was established, what memory it was extracted from, how confident the system is in the relationship, and how recently it was corroborated. This metadata feeds into the spreading activation scoring during retrieval, so well-supported relationships contribute more to retrieval ranking than uncertain ones.

Storage Formats

Triples can be stored in several formats depending on your infrastructure. The simplest is a relational table with three columns (subject, predicate, object) plus metadata columns. This works in any database and handles millions of triples with proper indexing (index all three columns individually plus composite indexes on common query patterns). Graph databases like Neo4j store triples natively as nodes and edges, which optimizes traversal performance. RDF stores (like Apache Jena or Blazegraph) implement the W3C RDF standard and support SPARQL queries. For most AI applications, either a relational triple table or a property graph database provides the right balance of simplicity and performance.