What Early AI Needed Names to Mean
Relations need semantics; shared ontologies permit limited explicit commitments.

A diagram contains three boxes: pump, equipment, and building. Lines connect them. It looks reasonable until somebody asks what the lines mean.
A pump is a kind of equipment. A particular pump may be installed in a building. Those are different relationships. If software treats both lines as “is a kind of,” the building can end up classified as equipment. If every line merely means “related,” the diagram says too little to support the questions people actually ask.
Early AI made this problem urgent. Once a program was expected to use relationships rather than merely display them, a line needed a meaning precise enough to act on.
A network that could be followed
M. Ross Quillian’s work on semantic memory in the 1960s represented concepts through networks of connections. The attraction was that a system could follow links to find relevant information. Meaning did not have to sit in one isolated entry.
John F. Sowa later developed conceptual graphs, connecting graph-shaped representations with logical reasoning. His own history of semantic networks traces several traditions, including Quillian’s work and the much earlier logical diagrams of Charles Sanders Peirce. There was no single moment when someone invented the idea of connecting concepts. The important developments concerned what those connections expressed and what could legitimately follow from them. Sowa, Semantic Networks
A library subject system already distinguished broader, narrower, and related subjects. AI representation brought additional demands. A program might need to reason about individual objects, events, participants, and conditions, not just lead a reader from one subject to another.
Take an illustrative maintenance model. “Centrifugal pump” is a kind of pump. P-17 is a particular centrifugal pump. If the model says every pump is equipment, a reasoner can classify P-17 as equipment without someone separately entering that conclusion.
That is a modest result. It is also useful: one general relationship supports consistent classification across many individual records.
Now add “P-17 was inspected by Lena.” That statement does not make Lena a pump, equipment, or an inspection. The model needs distinct roles for the inspected object, the event, and its participant. The ordinary grammar of the sentence gives us a clue about the distinctions the graph must preserve.
Agreeing on enough meaning
By 1993, Thomas Gruber was addressing how knowledge-based systems could share reusable descriptions. His paper on portable ontologies treated an ontology as an explicit specification of a conceptualization: a stated account of the concepts and relationships a system commits to using. The work supported translation between representation languages through Ontolingua. Gruber, A Translation Approach to Portable Ontology Specifications
The practical issue is easier to understand than the terminology. Two applications cannot reliably cooperate if each uses “inspection” differently.
One application might use the term for a scheduled appointment. Another might use it only for completed work with recorded findings. If the applications exchange an inspection count, the receiving team needs to know which meaning applies.
An ontology can make the distinction explicit: a planned inspection is an activity that has been scheduled; a completed inspection has occurred. The evidence required to accept completion can be described separately. A record can then move from one status to another without forcing people to pretend that a plan and an event are the same thing.
Gruber’s formulation is useful because it makes the agreement visible. It does not require everyone to settle every philosophical question about inspections. It requires enough shared meaning for the intended work.
That is recognizably close to the older library discipline. A catalogue heading was useful because its use was governed, not because a word had been typed neatly.
The dangerous convenience of “related to”
Professionals often begin an ontology by connecting the terms they already have. The result can become large before it becomes clear.
Suppose a project is linked to a standard. Did the project have to comply with that standard? Did a report cite it? Did someone consider it and decide that it did not apply? Those three connections lead to different answers when a colleague asks which projects are affected by a revision.
Replacing all three with “related to” preserves an association while losing the reason for it.
The repair is to name the relationships people need: “must comply with,” “cites,” and “assessed as not applicable,” each with appropriate context. A requirement may apply only to one part of a project or during a particular period. Recording that context can matter more than adding another hundred concept names.
There is a limit to how much detail is useful. If the only task is to browse a small collection, a broad association may be sufficient. If the system recommends work after a standard changes, that same association is too vague. The task determines how much meaning the model must carry.
Reasoning stays inside the agreement
A logical conclusion can be valid within a model while the model contains a bad premise. If an asset has been wrongly classified, a reasoner may propagate that mistake impeccably.
This is why ontology work includes examples, counterexamples, and conversations with people who know the subject. Try a temporary installation. Try an inspection that was started but abandoned. Try a component replaced while its identifier remained unchanged. Such cases reveal what the neat diagram leaves unresolved.
The earlier library principles remain useful here. Keep identity separate from names. Distinguish a kind from a part. Preserve the source of a description. Design around questions people need answered.
AI added a consequence: software could now carry the distinctions into further conclusions. A careless connection could travel farther than its author intended. As these models moved onto the web, their identifiers and relationships would become available to people and systems the original modeller had never met.