A Knowledge Graph Is More Than Triples: Facts, Claims, Concepts, and Context

Knowledge graphs are often introduced through the familiar triple:

Subject ── Predicate ──> Object

For example:

Employee1 ── worksFor ──> Acme

The abstraction is powerful because it provides a uniform representation for heterogeneous information. Yet the simplicity of the triple can obscure an important distinction: a triple represents a statement, but a stored statement is not automatically equivalent to knowledge or fact.

In an enterprise knowledge graph, meaning also depends on the semantics of the predicate, the concepts represented by the subject and object, the source of the assertion, its temporal and organisational context, and the basis on which the organisation considers it trustworthy.

This suggests a broader view of a knowledge graph: not simply as a collection of triples, but as a system of reusable semantic structures instantiated as contextualised claims.

Predicates Carry Reusable Relationship Semantics

Consider a set of apparently simple relationships:

The subject identifies the employee and the object identifies the organisation. The predicate tells us what the connection means. Without worksFor, we would know that Employee1 and Acme are connected, but we would not know the semantics of that connection.

A predicate can therefore be viewed as a reusable binary relation:

A graph may contain billions of relationship instances while relying on a much smaller vocabulary of predicates. The individual triples contain instance-level knowledge, while predicates provide reusable relational semantics across those instances.

The predicate alone, however, is not always sufficient. Consider:

The predicate is identical, but the applicable semantics and constraints may differ. A useful conceptual abstraction is therefore:

Triple Template = Subject Concept + Predicate + Object Concept

For example:

This is not intended as a new RDF standard construct. It is an architectural abstraction over ideas already represented through ontology languages such as OWL and graph-constraint mechanisms such as SHACL. OWL provides formal semantics for classes and properties, while SHACL describes constraints that graph data is expected to satisfy. [6][7]

The individual triples are then instances of the recurring semantic structure.

Large Graphs Contain Repeated Structural Patterns

The observation that graphs contain repeated predicate structures also appears in database research.

Neumann and Moerkotte introduced Characteristic Sets for RDF cardinality estimation. A characteristic set describes the set of predicates associated with a subject:

[ CS(s)={p\mid \exists o:(s,p,o)\in G} ]

Two resources may therefore exhibit the same structural signature even though their actual values differ. [1]

For example, many employees may share a structure such as:

This is interesting because structural regularity itself becomes information about the graph. At one level we have individual triples. Above them we have predicates and typed relationship patterns. At another level we can identify recurring neighbourhood structures such as characteristic sets.

A very large knowledge graph may therefore contain billions of statements while exhibiting far fewer frequently occurring semantic and structural patterns.

This regularity is useful not only for modelling but also for indexing and query optimisation.

Subject, Predicate and Object Are Also Access Dimensions

A triple can be queried from different directions. Given:

we may ask:

RDF systems therefore commonly use indexes or related structures organised around different combinations of subject, predicate and object. Conceptually, these may include:

The exact physical implementation varies between databases. The broader principle is that subject, predicate and object are simultaneously semantic components and potential access paths into the graph.

Predicate-based organisation has also been studied explicitly. In vertical partitioning, triples are logically separated by predicate so that each predicate behaves like a two-column relation. Abadi et al. demonstrated this approach for scalable Semantic Web data management. [2]

Conceptually:

The predicate therefore becomes more than a relationship label. It can also become a natural grouping and optimisation boundary.

Statistics around predicates and recurring structures can then help a query optimiser estimate cardinality and selectivity. Characteristic Sets were proposed specifically to improve RDF cardinality estimation for queries involving multiple joins. [1]

This matters because query execution is often determined by where traversal starts. If one relationship has ten million instances while another highly selective relationship has only a few thousand, beginning with the smaller set may radically reduce intermediate results.

Shared Structure Can Also Support Compact Representation

Graph representation also exposes opportunities for reuse.

Consider:

Acme is a shared entity. Its description does not need to be conceptually embedded into every employment relationship. Multiple relationships converge on the same node.

The same applies to predicates. The complete textual identifier for worksFor need not necessarily be repeated physically for every occurrence.

A well-established example is HDT — Header, Dictionary, Triples. HDT separates RDF vocabulary into a dictionary and represents the graph structure using compact identifiers. The W3C submission explicitly describes the dictionary as a way to avoid repeated vocabulary strings and to enable compact representation of large RDF graphs. [3]

Conceptually:

The triples can then be represented using identifiers:

This gives us several forms of reuse. Entity reuse allows many relationships to reference the same node. Predicate reuse allows the same relationship vocabulary to be instantiated repeatedly. Semantic-template reuse allows common constraints and behaviour to be defined once for a relationship pattern and applied across many instances.

The first two can directly contribute to compact physical representation. The third is better described as semantic reuse rather than physical compression.

It is important not to overstate this point. Graph databases are not inherently smaller than relational databases; relational systems also use normalisation, identifiers and compression. Graph systems additionally maintain indexes, adjacency information and other structures. The more defensible observation is that graph representation makes repeated entities and relationships explicit, allowing storage engines to exploit that regularity.

A Triple Is Still Only an Assertion

Efficient storage and indexing do not establish truth.

Consider:

These statements appear contradictory, but several explanations are possible. They may have come from different systems, apply to different periods, or represent different concepts, such as a billing address and a residential address.

This illustrates the distinction between a statement and a claim.

A statement represents a relationship. A claim associates the statement with information about its assertion:

The knowledge graph can retain another claim from a different source without immediately deciding that one must be deleted.

This leads directly to the research area of hyper-relational knowledge graphs, where a basic triple is accompanied by qualifier pairs that restrict or refine its interpretation. Galkin et al., for example, model hyper-relational facts as triples augmented with an arbitrary number of qualifiers. [4]

Conceptually:

The relationship remains the core statement, but qualifiers provide additional context required to interpret it.

There is also increasing support for standards for representing statements about statements. The current RDF 1.2 work introduces triple terms, allowing an RDF triple itself to participate as a term in another statement. As of August 2026, RDF 1.2 Concepts is a W3C Candidate Recommendation rather than a final Recommendation. [5]

This formalises an important idea: sometimes the knowledge system must represent not only a relationship, but also information about the assertion of that relationship.

Context Includes More Than Provenance

Time is particularly important because knowledge is often valid only during a particular period.

Suppose:

was valid from January 2024 until June 2026. The system may also have learned that the employment ended only in August 2026.

These are two different temporal dimensions.

Valid time describes when the statement was true in the represented world. Transaction time describes when the information was recorded or known by the system.

Recent work on BiTemporal RDF applies precisely this distinction to RDF, combining valid time and transaction time to support historical representation and reconstruction. [8]

This matters in enterprise graphs because asking:

What was true on 1 June?

is different from asking:

What did the organisation believe was true on 1 June?

The second question requires historical knowledge about the knowledge base itself.

Context may additionally include provenance, jurisdiction, organisational scope, confidence, authority, evidence and version. A triple therefore often provides only the core proposition around which a richer knowledge assertion must be constructed.

From Statements to Trusted Knowledge

This also suggests that the terms statement, claim, fact and knowledge should not be treated as interchangeable.

A stored triple is a statement. Once its source and assertion are represented, it becomes a claim. Once temporal, provenance and other qualifiers are attached, it becomes a contextualised claim.

Calling something a fact introduces a stronger epistemic judgement: we are treating the claim as sufficiently supported for a particular purpose.

Enterprise systems rarely establish absolute truth. What they can do is establish why a claim should be trusted. That requires questions such as: Who asserted it? Which source produced it? When was it valid? Which ontology gives the predicate its intended meaning? What evidence supports it? Has it passed validation? Which version introduced it? Who approved it?

A more complete knowledge model therefore looks something like:

This model separates representation, semantics, assertion and trust. The triple solves the representation problem elegantly, but the other layers require additional structures.

Implications for Enterprise Knowledge Graph Management

Once these distinctions are recognised, managing a knowledge graph becomes more than managing nodes and edges.

An enterprise platform may need to manage concepts, predicates, recurring relationship patterns, graph instances, claims, provenance, contextual qualifiers, validation rules, policies, versions and approvals.

The layers are interdependent. A change to the meaning of a predicate can affect millions of instances. A change to a constraint may invalidate existing relationships. A source losing its authority may alter the status of trust of every claim derived from it.

This is also why the graph database and the Knowledge Graph management plane solve different problems.

The graph database is responsible for efficient storage, indexing, traversal and query execution. The management plane addresses the semantic and governance lifecycle around that graph: ontology management, validation, provenance, policies, collaboration, versioning, approval and release.

That distinction is central to the architectural role we are exploring with SolidState Graph.

Conclusion

The triple remains one of the most elegant abstractions for structured information:

But it is only the starting point.

Predicates provide reusable relationship semantics. Typed relationship patterns capture recurring semantic structures. Characteristic Sets reveal higher-order structural regularities. Predicate-oriented indexing, vertical partitioning and compact representations such as HDT demonstrate how those regularities can also support efficient computation and storage.

At the same time, hyper-relational models, RDF triple terms and temporal representations show why a plain triple is often insufficient for representing real-world knowledge. Claims require sources, qualifiers and context; trusted knowledge requires an explicit basis for interpretation and reliance.

A modern enterprise knowledge graph is therefore better understood as:

A system of reusable semantic structures instantiated as contextualised claims over shared entities, with explicit mechanisms for efficient access, interpretation, provenance and trust.

The graph database stores and indexes relationships. The broader knowledge system determines what those relationships mean, under what conditions they hold, where they came from, and when the enterprise should rely on them.

References

[1] Neumann, T., & Moerkotte, G. (2011). Characteristic Sets: Accurate Cardinality Estimation for RDF Queries with Multiple Joins. Proceedings of the 27th IEEE International Conference on Data Engineering (ICDE), pp. 984–994. DOI: 10.1109/ICDE.2011.5767868.

[2] Abadi, D. J., Marcus, A., Madden, S. R., & Hollenbach, K. (2007). Scalable Semantic Web Data Management Using Vertical Partitioning. Proceedings of VLDB 2007, pp. 411–422.

[3] Fernández, J. D., Martínez-Prieto, M. A., Gutierrez, C., & Polleres, A. (2011). Binary RDF Representation for Publication and Exchange (HDT). W3C Member Submission, 30 March 2011.

[4] Galkin, M., Trivedi, P., Maheshwari, G., Usbeck, R., & Lehmann, J. (2020). Message Passing for Hyper-Relational Knowledge Graphs. Proceedings of EMNLP 2020, pp. 7346–7359. DOI: 10.18653/v1/2020.emnlp-main.596.

[5] W3C RDF & SPARQL Working Group. (2026). RDF 1.2 Concepts and Abstract Data Model. W3C Candidate Recommendation Snapshot, 7 April 2026.

[6] W3C. (2017). Shapes Constraint Language (SHACL). W3C Recommendation, 20 July 2017.

[7] W3C OWL Working Group. (2012). OWL 2 Web Ontology Language Document Overview, Second Edition. W3C Recommendation, 11 December 2012.

[8] Tansel, A. U., Wu, D., & Wang, H.-T. (2025). Time Travel with the BiTemporal RDF Model. Mathematics, 13(13), 2109. DOI: 10.3390/math13132109.