A Knowledge Graph Is a Collection of Claims
Knowledge graphs connect things and relationships for many uses, but every edge still needs meaning, evidence, and maintenance.
Search for a company and a system can show its products, founders, locations, and related organizations without treating the query as words that happen to occur together in a document. Google’s 2012 Knowledge Graph announcement made this approach visible to a broad public. It described real-world things and their relationships as a basis for search. (Google, “Introducing the Knowledge Graph,” 2012)
The name can sound as though the graph itself knows the world. What it actually contains are representations: identifiers for things, links between them, and often descriptions of where those statements came from. A product may be linked to a company, a component to a standard, or a clinical term to a classification. Software can traverse those links. A person still has to ask what each link means and whether it remains warranted.
The link does work
Imagine an engineering organization with records for a component, its supplier, test reports, projects, standards, and approved uses. A connected model can let a person begin at the component and inspect relevant evidence without knowing which database holds each record. It can also help an application ask which projects may be affected when a test is withdrawn or a standard changes.
That is more than keyword search. The system follows relationships that people have chosen to represent. A link saying a component was tested under a standard is different from a link saying it complies with that standard. A link saying a report mentions a component is weaker still. If the graph stores all three as an undifferentiated connection, it may produce a persuasive path to the wrong conclusion.
The engineer needs to name the relationship, its direction, and its conditions. They also need to know whether two records identify the same thing. A supplier’s catalogue entry may describe a family of products, while the project record names one serial-numbered instance. Connecting them may be useful; merging them would erase information the decision needs.
More connections raise the maintenance cost
A graph can support discovery, recommendation, analysis, and integration across applications. This is one reason knowledge engineering moved beyond the single expert system that answered one class of questions. Protégé-related tools and public resources such as biomedical classifications demonstrate the scale of maintained conceptual structures. (Musen, “The Protégé Project,” 2015)
Reuse also multiplies the consequences of a change. If a central concept is narrowed, search, reports, alerts, and AI answers may all change. The knowledge engineer must discover those dependencies, decide whether the update is correct, and tell the consuming systems what changed. A graph that grows without such work is not a living model. It is an expanding record of assumptions.
There is a human problem as well. A machine can process millions of links. A person cannot inspect a wall of nodes and lines and call it understanding. The graph needs useful views, filters, explanations, and routes back to evidence. We will return to that design problem later in the series; graphic design has been working on related questions much longer than graph databases have existed.
For now, the practical point is narrower. The graph is a means of making relationships operational. Each relationship remains a claim whose meaning and support can be challenged. The job of knowledge engineering includes building those links and making it possible to discover when one should be changed.
