Taxonomy, ontology, knowledge graph: the plain guide

Summary:

Taxonomy, ontology, and knowledge graph are three related but distinct concepts routinely conflated in AI and content strategy discussions. Taxonomy is a controlled vocabulary - a set of approved terms for classifying content. Ontology defines typed relationships and rules between those terms. A knowledge graph is the engine that stores and reasons across those relationships at scale. Author-it provides the raw material for all three: structured topics, conditional logic, and metadata-governed content objects ready to seed an enterprise knowledge graph - though we will be honest about what Author-it is and is not in this picture.

‍

Three terms used like they mean the same thing

In the space of twelve months, knowledge graph has gone from an infrastructure term used by data engineers to a phrase appearing in marketing decks, procurement briefs, and executive presentations about AI strategy. Taxonomy and ontology have followed it into mainstream use - often interchangeably, and often incorrectly.

The conflation matters because these three things are distinct layers of a knowledge infrastructure, each with different capabilities, different implementation requirements, and different payoffs for AI systems. Deploying a knowledge graph when you only have a taxonomy is like building a search engine with no index. Calling your taxonomy an ontology overstates what it can do.

Documentation managers and AI project leads increasingly need clean definitions for these terms - not because precision is pedantic, but because the architectural decisions that follow from each are completely different.

​

Taxonomy: the controlled vocabulary

A taxonomy is a hierarchical classification system. It organises concepts into categories and subcategories using is-a relationships. At its simplest, a taxonomy is a list of approved terms that a controlled vocabulary governs.

In a documentation context, a taxonomy might look like this: Product documentation (Installation guides, Configuration guides, Troubleshooting guides); Safety documentation (Warnings, Cautions, Regulatory notices); Compliance documentation (ISO standards, FDA submissions, CE declarations).

Every organisation with a content management system has some form of taxonomy, even if informal. When authors choose a document category from a dropdown, they are applying a taxonomy. When a CMS enforces a controlled vocabulary for subject tags, it is implementing a taxonomy.

Taxonomies are powerful for classification and navigation. They are well-understood, maintainable by non-technical domain experts, and supported by most content management systems. For AI, a well-governed taxonomy enables topic-based filtering at retrieval time - one of the most effective ways to reduce hallucination risk in RAG systems.

What a taxonomy cannot do is express how concepts relate to each other beyond the parent-child hierarchy. A taxonomy can tell you that Calibration Procedure is a type of Maintenance Documentation. It cannot tell you that a calibration procedure applies to a specific instrument family, must be completed before a specific certification step, or supersedes a previous version. For those relationships, you need an ontology.

​

Ontology: typed relationships and rules

An ontology extends taxonomy into a richer model. Where a taxonomy organises concepts into a hierarchy, an ontology defines the types of relationships that can exist between concepts, the rules that govern those relationships, and the logical constraints that apply.

A simple example: a taxonomy can tell you that a Warning is a type of Safety Notice. An ontology can additionally express that a Warning applies to a specific Product Configuration, precedes a specific Procedure Step, and is required by a specific Regulatory Standard. These are not just categorisation relationships - they are typed, directional relationships with semantic meaning.

For AI systems, ontologies unlock capabilities that taxonomies cannot provide:

• Multi-hop reasoning - the ability to answer questions that require following a chain of relationships (which procedures apply to this product configuration, and which warnings are associated with those procedures?)
• Logical inference - deriving facts that are not explicitly stated but follow from the rules encoded in the ontology
• Consistency checking - identifying content that violates the ontological rules, such as a warning applied to a product configuration it is not compatible with

Ontologies are significantly more complex to build and maintain than taxonomies. They typically require specialist knowledge engineers alongside domain experts. The tooling is more demanding, the governance overhead is higher, and the maintenance burden grows with domain complexity. For many organisations, a well-governed taxonomy is the practical right answer - and adding ontological complexity before the taxonomy is stable is a common mistake.

​

Knowledge graph: the engine that reasons across both

A knowledge graph is the system that applies an ontology to instance data at scale. Where an ontology defines the rules and structure - the classes, relationship types, and constraints - a knowledge graph populates that structure with real-world entities and actual relationships.

The ontology says a Product can have a Maintenance Procedure. The knowledge graph records that Product X requires Procedure Y, which was last reviewed on a specific date, applies to serial numbers in a certain range, and references Warning Z.

For enterprise AI, knowledge graphs provide the richest possible grounding layer. They enable AI systems to traverse complex, multi-hop relationships across a large entity space - answering questions that require not just finding relevant content, but reasoning about how entities, procedures, products, and regulations relate to each other.

Knowledge graphs are also the most demanding layer to build. They require a stable ontology, a systematic data population process, ongoing curation, and typically a dedicated knowledge engineering capability. Major enterprises in highly regulated industries - pharmaceutical, aerospace, financial services - have been building knowledge graph infrastructure for years. It is not a weekend project.

​

How the three layers work together

In a mature knowledge infrastructure, the three layers are not alternatives - they are stacked. The taxonomy provides the controlled vocabulary. The ontology defines the relationships and rules. The knowledge graph instantiates them with real entity data.

Think of it this way. Taxonomy is the map legend - it tells you what each symbol means. Ontology is the rules of the road - it tells you how places relate to each other and what you can and cannot do between them. A knowledge graph is the actual map - it represents the real terrain, populated with real entities and real relationships.

Most organisations have the legend. Fewer have formal rules of the road. Very few have a complete, enterprise-scale map. The gap between where most organisations are and where this architecture is headed is significant - and the AI pressure to close it is real.

​

Where Author-it fits in this picture

Author-it is a component content management system, not a knowledge graph platform. It is worth being clear about what that means.

What Author-it provides: a taxonomy framework through classification fields, audience tags, domain assignments, and compliance markers applied at authoring time; structural relationships through topic hierarchies, book structures, component relationships, and conditional applicability logic; governance metadata including version, approval state, review history, and provenance for every content object; and AION output - all of this exported as a structured JSON object that a downstream knowledge infrastructure can consume.

What Author-it is not: a full ontology management platform (Author-it's relationship model is structural, not formally ontological in the OWL/RDF sense), and not a knowledge graph engine (Author-it does not provide graph traversal, inference, or multi-hop reasoning over entities).

The honest positioning is this: Author-it provides the content substrate that a knowledge graph needs to be useful. Structured, governed, metadata-rich content objects - reliably classified, consistently maintained, version-controlled - are the raw material that knowledge graph engineers work with. Organisations that arrive at their knowledge graph project with Author-it-sourced AION content arrive with a material advantage over those whose content is in flat documents, wikis, and shared drives.

​

Where to start if this is new territory

The practical advice for documentation managers beginning to navigate this space: Start with taxonomy. Get your controlled vocabulary agreed, governed, and applied consistently. This alone dramatically improves AI retrieval quality and is the foundation every subsequent layer requires.

Do not build an ontology before your taxonomy is stable. Ontological complexity built on an unstable vocabulary collapses under its own maintenance burden. Treat your structured content as a knowledge graph candidate. If you are authoring in Author-it, your content already carries the structural and governance metadata that knowledge graph population requires.

Separate the knowledge engineering problem from the content operations problem. Ontology design and knowledge graph construction are specialist disciplines requiring different skills from technical writing and content governance. The terminology will keep evolving. The underlying need - to give AI systems structured, governed, relationship-aware content to reason over - will not.

Knowledge Graph FAQ

Q: What is the difference between a taxonomy and an ontology?

A: A taxonomy organises concepts into a hierarchical parent-child classification system using is-a relationships. It tells you what things are. An ontology extends taxonomy into a richer model that defines typed relationships between concepts, rules governing those relationships, and logical constraints. It tells you how things relate to each other and what can be inferred from those relationships. All ontologies contain taxonomy-like structure, but taxonomies alone are not ontologies.

Q: What is a knowledge graph?

A: A knowledge graph is a system that applies an ontology to instance data at scale - connecting real-world entities through explicitly modelled, semantically meaningful relationships. Where an ontology defines that a Product can have a Procedure, a knowledge graph records that a specific product requires a specific procedure, links to its approval record, and connects to the warnings associated with it. Knowledge graphs enable AI systems to perform multi-hop reasoning across large entity spaces.

Q: Do I need an ontology before I can use a knowledge graph?

A: Yes. A knowledge graph requires an ontology - the formal model of types, relationships, and rules - to give the graph its semantic structure. However, ontologies exist on a spectrum of formality. Many practical knowledge graphs begin with a lightweight, domain-specific ontology and extend it over time. The more important prerequisite is a stable taxonomy - without consistent controlled vocabulary, neither ontology nor graph can be maintained reliably.

Q: What role does content metadata play in a knowledge graph?

A: Content metadata is the connection between a document corpus and a knowledge graph. When content objects carry structured metadata - type, topic classification, product applicability, version state - they become entities that can be mapped into the knowledge graph as nodes, with their relationships expressed as edges. Content without metadata remains flat data - searchable by keyword, but not traversable as a graph or reasoned over by an AI system.

Q: Does Author-it produce a knowledge graph?

A: Author-it is a component content management system, not a knowledge graph platform. It provides structured, governed content with a three-layer metadata framework - taxonomy classifications, structural relationships, and governance metadata - that is published via AION as structured JSON. This content is the raw material that knowledge graph projects require. The knowledge graph infrastructure itself is a separate engineering layer that consumes Author-it's output.

Q: What is enterprise knowledge graph content and why is it emerging as a search term?

A: Enterprise knowledge graph content refers to the content infrastructure required to populate and maintain an enterprise knowledge graph - specifically, structured, governed, consistently-classified content objects with rich metadata. It is emerging as a search term because organisations building knowledge graph projects are discovering that their existing content - in PDFs, wikis, and unstructured knowledge bases - is not suitable as graph input without extensive preprocessing. Author-it-sourced AION content is designed to address this gap.

Q: How long does it take to build an enterprise taxonomy?

A: Building a defensible enterprise taxonomy - controlled vocabulary agreed by domain experts, governance process defined, tooling integrated - typically takes three to nine months for a focused content area, and longer for enterprise-wide scope. Author-it supports taxonomy implementation through classification fields and controlled vocabulary management applied at authoring time. The ongoing maintenance of the taxonomy is a content governance function, not a one-time project.