Entities and the Knowledge Graph: How Search Engines Understand Things, Not Strings

Strings vs. things is the founding distinction of semantic search. A string is the sequence of characters a user types; a thing is the real-world concept it refers to. The word "apple" is a string, while the fruit, the company, and the city are three different entities that happen to share one. The query "[apple]" is ambiguous precisely because a single string maps to several things, and engines classify its interpretations as dominant, common, and minor before ranking anything.

Because concepts rather than words are the unit of storage, entities have no language of their own: meaning is universal across documents and locales. To manage that, query annotators assign each entity a canonical representation independent of language, so "Paris" resolves to one identifier, /m/05qtj, whichever language the query arrived in. Two documents can use entirely different vocabularies and still be recognized as writing about the same thing.

The doctrine states it as a writing rule: an undefined entity is an uncovered entity, and stuffing names without definitions contributes nothing to coverage. What completes the definition is the Entity-Attribute-Value structure: the entity, its properties, and the specific data attached to each property. A smartphone, for example, carries attributes such as operating system, battery capacity, and release year, each with its own literal values; until those values are stated, the definition is incomplete.

Definitions also work relationally. Entities must be connected through explicit relationships rather than mere co-mention: a predicate, usually a verb, explains how one entity relates to another and carries the contextual signal that keeps senses apart. Structured this way, facts become machine-readable units that search systems can match, lift, and cite.

A Knowledge Graph is described as "a collection of data stored as nodes and edges in a graph structure." Queries are annotated with the entities they contain, matched against that structure, and increasingly answered from it directly, which is why a knowledge panel is a strong sign that an engine has resolved an entity to a node.

Triples scale beyond pairs: the graph also models higher-order relationships, and queries themselves are augmented into entity-attribute-context triples before retrieval. Accuracy matters at graph level too. A site whose statements are consistently accurate earns a form of knowledge-based trust, because its content aligns with, and can even improve, the engine's own knowledge base. That is the difference between being cited and being doubted.

Every guess the engine makes on a publisher's behalf is billed as computation. Content that is semantically precise about entities and their attributes is cheaper to process, because extraction replaces interpretation. Confidence also compounds at site level: a source that clearly defines the entities in its domain raises the engine's confidence about what it covers, and that confidence means the site is considered across more queries without re-earning each one from scratch.

One detail is easy to miss: embedding models are good at meaning and bad at identifiers. Exact values, model numbers, quantities, and dates are handled poorly by vector similarity, so those literals must be written into the text for lexical extraction. The definition that states its values survives; the one that leaves them implicit gets skipped.

Writing for machine understanding is mostly a formatting discipline, and four habits carry most of it:

• Write liftable claims: phrase statements as subject-predicate-object so each one can be lifted on its own and cited verbatim.
• Complete the attributes: cover an entity through its full set of attributes and values, not only its most obvious one.
• Choose predicates deliberately: the verb carries the contextual signal, so a mismatched verb can scramble which sense of the entity is understood.
• Keep naming consistent: refer to the same entity the same way across the page, so its mentions resolve to one node instead of several.