Free entity SEO learning
Compare knowledge graphs, taxonomies and ontologies
Entity SEO learning
A knowledge graph represents things and the relationships between them. A taxonomy groups things into categories. An ontology defines a vocabulary and the meaning of its relationships. These tools can clarify a subject, but drawing a graph does not establish a search ranking advantage.
Free learning from Semantec SEO.
Compare what each model can answer
Use the same service subject to compare the question each model answers. A browsing category, a relationship claim and a vocabulary rule serve different needs; one does not replace the others.
Taxonomy
- Purpose
- Arrange a subject into broader and narrower categories.
- Components
- Categories and their category relationships.
- Example question
- Where should a reader browse for heating maintenance?
- Output
- A category structure such as heating services, then maintenance.
- Limit
- The category does not prove that a named company offers a service at an address.
Knowledge graph
- Purpose
- Represent particular things and named relationships.
- Components
- Identified subjects, relations and objects, with their source context.
- Example question
- Which company provides this service, and which area is named for it?
- Output
- Separate, directed claims about the company, service and place.
- Limit
- A recorded relationship can still be unsupported or out of date.
Ontology
- Purpose
- Define vocabulary and the meaning of relationships within a stated subject.
- Components
- Types, properties and the distinctions or rules chosen for that model.
- Example question
- What does provides mean in this model, and which kinds of things can it connect?
- Output
- A shared set of meanings for interpreting the statements.
- Limit
- Vocabulary agreement does not verify a particular company’s service claim.
The three roles can coexist. A website can use a taxonomy for browsing, a graph for particular relationships and a vocabulary to keep those relationships consistent.
Start from a question rather than a large diagram
A useful graph has a purpose: identify a company, connect its services with locations, or check which source supports a claim. Select the facts needed for that purpose before adding connections. A large diagram can still leave a simple question unanswered.
Choose the main and supporting subjects from that question. More nodes do not prove that the answer is complete; an unsupported connection can make a larger model less reliable.
Distinguish a class from a particular member
A taxonomy can place boiler maintenance within heating services. That category structure helps people browse. It does not, by itself, tell them which company supplies the service or where the service is available. Those are separate relationships that need evidence.
A class describes a kind of thing, such as an organization or a service. A specific member is a particular thing placed in that class. Do not confuse a company with the category of companies, or a product family with one named model.
“Heating services” is a category. “Heat pump maintenance” names a kind of work. “Alder Heating” names the fictional organization in the example. These labels serve different purposes; none can stand in for all the facts about the others. Review what an entity is before combining records.
Read named and directed graph statements
In a graph, a node represents a thing, concept or literal such as a text string and an edge represents a relationship. The relationship needs a name and direction. “Company provides service” says more than an unlabeled line between a company and a service. A visual connection alone cannot tell a reader what was asserted.
The W3C RDF model expresses statements as subject, predicate and object. This is one formal model for graph data. A sketch made during editorial planning is not automatically an RDF dataset, and a private graph is not evidence that a search provider has adopted its statements.
The attributes and predicates lesson distinguishes a literal entry from a related entity. Keep each relationship’s direction visible in ordinary text as well as any diagram.
Work through Alder Heating and Northfield
The following miniature model is invented for teaching. Alder Heating is a fictional company, heat pump maintenance is a fictional offered service, and Northfield is a fictional service area. No operating business, service availability or client result is being asserted.
Read the model as individual claims. Alder Heating provides heat pump maintenance. That service has an area served of Northfield. Alder Heating employs a technician. A source would need to support each claim before a real company published the equivalent statements.
The service, place and technician are distinct nodes. A link from the company to the service does not prove that every technician can perform it or that it is available at every address. Additional qualifications belong on the relevant claim, rather than disappearing inside a broad connection.
Record the company relationships
Use the record as a planning example. It is ordinary HTML, so the meaning survives without the illustration. For a real project, add source URLs, observation dates and the conditions that limit each relationship.
A company can offer different services and a service can have more than one location. Repeating a name is not the same as resolving identity. Assign a stable record to each thing and keep names as labels attached to those records.
Alder Heating
- Relationship
- provides
- Object
- Heat pump maintenance
- Evidence needed in a real project
- Current first-party service description
Heat pump maintenance
- Relationship
- area served
- Object
- Northfield
- Evidence needed in a real project
- Current coverage statement and exclusions
Alder Heating
- Relationship
- employs
- Object
- Named technician
- Evidence needed in a real project
- Current authorized personnel record
Record conditions and source scope on relationships
The following completed relationship record extends the same fictional exercise. Every source, date and coverage condition is invented for teaching; no service availability is asserted.
A qualified service area claim
- Subject ID
- SV01, fictional heat pump maintenance.
- Relationship
- Area served; the place in which this exercise describes the service as offered.
- Object ID
- PL01, fictional Northfield.
- Source
- Invented company coverage record AH-COVERAGE.
- Date and version
- 24 October 2026, teaching version A.
- Condition
- The exercise excludes addresses outside the confirmed example coverage boundary; no real address is confirmed.
- Evidence state
- Fictional. A real project needs a current coverage statement and its exclusions.
- Review trigger
- A changed offer, location boundary or supporting source.
The company’s address does not establish the service area. An employed technician does not establish every qualification. Resolve uncertain entity identity before linking facts to a record.
Use taxonomy and ontology where their rules help
An ontology defines terms and relationships for a stated domain. Its choices have boundaries: the intended users, supported questions and assumptions. Schema.org supplies a shared vocabulary and explicitly describes its scope as narrower than a universal ontology. Selecting a Schema.org type does not make every property appropriate.
A broader category can give readers a route to a narrower topic. That browsing choice is different from the statement that a company supplies a service. Keep parent and child topic relationships separate from factual service relationships, then use website navigation and architecture to plan access.
For machine readable statements, choose properties from supported facts after checking the vocabulary meaning.
Test the model against the original question
Read the records without their illustrations. Can you name the company, service, place and claimed relationship? Can you identify which source would confirm availability? If the only evidence is a nearby noun or an unlabeled line, the relationship is still unproven.
Bounded review checks
- Direction
- Does each statement connect its intended subject and object in the right direction?
- Identity
- Do two records describe one thing, or are similar names hiding different things?
- Evidence
- Does the cited source support this exact relationship and condition?
- Completeness for the task
- Does the model answer its original question, with unresolved claims kept visible?
Choose the next task without promising a search outcome
Graph planning can reveal an unsupported location claim, two records for the same company, or a missing explanation of how a service relates to a customer task. It can also support navigation and internal records. These are practical uses that can be reviewed directly.
Do not turn every nearby noun into a node or every cooccurrence into a business relationship. Separate what the source states from your interpretation. A diagram is a representation of claims, not verification of them.
Before publishing structured data, check the chosen vocabulary and the search feature requirements that apply. A valid graph, valid markup and eligibility for a search presentation are separate checks. This page does not claim a ranking formula specific to a provider.
For a real project requiring assistance, discuss entity analysis with Semantec SEO. The educational record remains usable without commissioning a service.
Sources and the next useful question
Check Google’s helpful content guidance. Also read Schema.org’s data model and W3C RDF 1.1 Concepts. External documentation supports the stated model or editorial boundary; the fictional examples and record formats are Semantec SEO teaching material.
Continue with main and supporting entities. Return to the entity SEO overview or the semantic SEO learning overview to choose another task.
