Knowledge Graphs: Model Entities, Relationships and Evidence

Think in statements rather than keyword lists

A graph becomes useful when it can express a precise statement. An article has an author. A company publishes a website. A guide explains a concept. Each statement connects identifiable things through a relationship with a particular meaning. A list of related keywords lacks that structure. It may help an editor brainstorm, but it does not specify whether two names refer to the same thing, one created the other or they simply appear together in a paragraph.

The W3C RDF concepts specification describes a graph through subject, predicate and object triples. You do not need to build an RDF database to understand that pattern. In an illustrative publishing graph, the subject is an article, the predicate is authorship and the object is a person. Another statement gives that person a name. These are separate assertions, which lets the same author connect to many articles without treating every byline as a newly invented person.

Give entities identifiers that survive wording changes

A stable identifier separates identity from display text. A person may change their preferred public name, and a company may rebrand, without every historical relationship needing to become a different entity. On a website, an identifier can use a controlled URL with a fragment that refers to the entity. Choose it deliberately and keep it stable. A page address and an entity identifier can be related, but they serve different descriptive purposes and should not be confused casually.

An illustrative author profile might describe a person identified by a persistent profile fragment. Articles can reference that identifier while displaying the person's current name. If the profile route moves, plan how references and historical addresses will remain coherent. Do not generate a new identifier each time a page renders. The practical identity questions are covered in entity SEO. The graph's job is to express those decisions consistently, rather than decide who the person is based on whichever spelling appears most often.

Choose relationships that answer useful questions

Start with the questions the graph should help answer. Who wrote this article? Which organisation publishes it? What is its subject? Which profile describes the author? Those questions lead to a manageable model. Adding every possible property usually increases maintenance cost faster than usefulness. A field that nobody can verify or keep current is a liability, even when its presence makes the graph look sophisticated. Omit unknown facts rather than filling them with plausible guesses.

Use established vocabularies when their meanings fit. Schema.org Organization includes organisational relationships, while other types describe people and creative works. Read a property's definition before selecting it by name alone. A publisher is not necessarily an owner, and a sponsor is not necessarily an author. If the standard relationship does not describe the fact accurately, simplify the model or provide a clear visible explanation. Do not force an ambiguous business arrangement into an incorrect property merely to complete an example.

Test the model by asking what each edge allows a reader to conclude. If an article is about a product, that does not mean the publisher created the product or endorses every use of it. If a person works for an organisation, that does not mean the organisation approved every statement they wrote. These simple counterexamples expose relationships that have been given too broad a meaning.

Distinguish identity from association

The statement that two references describe the same entity is stronger than the statement that two entities are related. A business profile and its official website may identify the same organisation. A company and its founder are associated but remain separate entities. A product and the company selling it are also different. Merging them can create absurd implications, such as attributing a person's qualifications to a company or treating every product mention as a statement about the publisher.

Use the sameAs definition only for unambiguous identity references. In an illustrative graph, the organisation links to its own verified profile, while the founder connects through an appropriate founder relationship. A news report about a company can serve as evidence for an event without becoming the same thing as the company. Organisation schema and Person schema provide practical guidance for the two records most content publishers need to keep distinct.

Attach confidence to evidence, not graph decoration

A graph can express a false statement perfectly. Syntax validation proves that a record follows a format; it does not establish that a person holds a qualification or a company owns a product. Maintain evidence alongside important assertions in your editorial system. For a simple site, that may be a source URL and verification note attached to a field. More complex systems may need explicit provenance records describing where a statement came from and when it was checked.

When evidence changes, update the relevant assertion rather than rebuilding unrelated parts of the graph. An illustrative author may leave an employer but remain the author of an old article. Current employment and historical authorship are different facts with different lifetimes. Preserve that distinction. Source corroboration explains how to judge supporting material. The graph should make a fact easier to connect and maintain, while the evidence remains responsible for whether that fact deserves to be published at all.

Keep your graph distinct from a platform graph

A website's JSON-LD describes the publisher's chosen representation. A search engine's knowledge system is maintained independently and may reconcile many sources using processes the publisher cannot inspect fully. Publishing an identifier or relationship does not force the platform to accept it. Likewise, a valid graph does not guarantee a knowledge panel, rich result or citation. Describe your implementation as structured information on your site, without presenting it as a successful update to someone else's database.

This distinction matters when measuring work. Count corrections you can verify: duplicated author identities removed, publisher references aligned or outdated relationships fixed. If a platform's presentation changes, record the observation separately and avoid attributing it to one graph edit without supporting evidence. AEO experiments provides a more careful approach to causal claims. A graph can be valuable for your own content system even when no external interface visibly acknowledges it.

Keep the graph small enough to remain true

Review the model when the publishing operation changes, not only when the JSON stops parsing. New contributors, acquisitions and product renames can change real relationships. Give each important field an owner and avoid allowing multiple templates to create incompatible copies of the same entity. A shared record is easier to maintain than separate blocks of manually edited facts scattered across articles.

Do not confuse this entity model with a plan for future articles. A topical map assigns reader needs to content, while a knowledge graph describes entities and relationships. The two can inform one another, but they solve different problems. Keep the graph focused on precise statements that your public content can support. A modest model with stable identifiers and accurate edges is more useful than a dense network whose apparent completeness hides uncertainty about what its connections actually mean.

Sources and further reading

• W3C RDF conceptsRDF graphs comprise subject, predicate and object triples with identifiers.
• Schema.org OrganizationDefines organisations and organisational relationships.
• Schema.org sameAssameAs identifies an unambiguous reference to the same entity.