Roughly 55 percent of the data enterprises collect is “dark”—stored but never analyzed or put to use—and for some sources, such as sensor data, that figure climbs toward 90 percent.[1] The bottleneck is rarely storage or compute. It is meaning; most organizations cannot reliably tell a machine what their data is about. A semantic knowledge management system (SKMS) is the framework that provides the missing layer—an organized structure of concepts, definitions, and relationships that lets both people and machines interpret information consistently and act on it with confidence. This book is about how to build one, stage by stage.

Organized, structured, and semi-structured SKMSs are rapidly emerging as essential for achieving highly performant large language models (LLMs) and AI systems. Many technologists either view SKMSs as overly simplistic (limited to text labels or annotations) or as too labor-intensive to justify investment. In response to this confusion, there has been an overreliance on out-of-the-box public taxonomies, such as the Google Product Taxonomy, resulting in homogenous knowledge ecosystems. This cookie-cutter approach fails to meet the needs of a domain or business.

Failure to model and represent an organization’s unique aspects and attributes is evident in AI implementation failures and challenges in deriving context and meaning from knowledge management systems, such as knowledge graphs.

A semantic knowledge system requires investment in both people and tools, but does not need to be limited to simple annotations or labor-intensive human efforts.

The construction and maintenance of a SKMS often operate as a black box due to a lack of existing frameworks and workflows, making it difficult for businesses to determine the exact scale of investment in both the short- and long-term. Additionally, direct returns on investment can be challenging to measure, as the benefits of a SKMS tend to be secondary and primarily reflected in the success of RAG implementations, entity management systems, and information retrieval metrics.

A formal SKMS program can be scoped, scaled, and positioned as both a product and a unique domain of expertise by structuring knowledge management stages and phases with logical sequences and workflows.

Establishing a robust and dynamic knowledge management program enables organizations to invest in this infrastructure with greater confidence, hiring people and leveraging machines to refine data and information systems while guiding the construction and maintenance of semantically rich ecosystems.

The Library and Information Science domain provides principled, logical methods and frameworks for organizing and structuring data into information, which becomes knowledge when made accessible to all users (human and machine). Librarians have codified these methodologies and strategies to manage complex information ecosystems, thereby enhancing the accuracy and reliability of information retrieval. Having successfully leveraged machine learning (ML) and artificial intelligence (AI) as workflow and cataloging tools for over a decade, the library science domain offers repeatable methodologies for building scalable and extensible SKMSs that drive accuracy and reliability in AI systems.

A quick distinction before we proceed:

Data are raw, uninterpreted facts, values with no context attached.

Information is data placed in a context that answers a question.

Knowledge is information understood well enough to act on. Think of the number “50.”

On its own, it is data, a value that could mean anything. Told that it is the balance in your checking account, we have information: the number now answers a question. And knowing that a $50 balance will not cover an $80 bill, so the purchase has to wait, is knowledge, information put to work to guide a decision. Librarians specialize in moving material up this ladder: turning scattered facts into organized information, and organized information into shared knowledge.

Figure 1: Library science data preparation for AI Systems. Derived from Fuzheado (https://commons.wikimedia.org/w/index.php?curid=128955050 https://www.ontotext.com/blog/vladimir-alexiev-ontology-semantic-enrichment-linked-data).

This introduction is a map, not the territory. It outlines every stage of the Ontology Pipeline: controlled vocabulary, taxonomy, metadata schema, thesaurus, ontology, and knowledge graph, but defines each only briefly. Every one of these terms has its own chapter, with full definitions, worked examples and construction steps. If a term feels dense in this section, know that the details are coming.

The Ontology Pipeline is derived from librarians’ workflows. It offers a systematic methodology for constructing a SKMS. The pipeline consists of iterative building blocks, with each phase preparing for the next stage of building. This iterative process incorporates data cleaning and preparation tasks into the semantic engineering workflow. The iterative processes appear in Figure 2.

Figure 2: The Ontology Pipeline. Derived from ANSI Z39.19 (https://www.niso.org/publications/ansiniso-z3919-2005-r2010).

Figure 2 captures the pipeline at a glance, where each stage prepares the material for the next. A controlled vocabulary establishes clean, disambiguated terms. Metadata standards describe what those terms are about. A taxonomy arranges the terms into a broad-to-narrow hierarchy with concepts organized into parent-child relations. A thesaurus enriches that hierarchy with equivalent, associative, and matching relations using a lightweight upper ontology. An ontology then adds formal classes, properties, and logical relations so machines can reason over the model. Finally, a knowledge graph populates the ontology with real instance data, producing a queryable web of meaning. Each term is introduced only briefly here; each has its own chapter ahead.

The Ontology Pipeline is designed to codify a framework for the architecture and construction of semantic knowledge management systems.

This tangible workflow and process enable a more accurate estimation of investment requirements, both human and machine. Without the Ontology Pipeline, organizations struggle to understand the levels of effort and investment required, let alone how to derive metrics to measure benefits, system performance, and returns on investment.

Leaders and stakeholders gain greater visibility into a semantic system’s requirements when the business understands the system’s components. With clear goals and outcomes in sight, organizations can build and maintain a SKMS with confidence, knowing these investments are crucial to supporting data infrastructure, data transformation, and AI initiatives.

A controlled vocabulary is a curated, finite list of preferred terms—each disambiguated and defined—that an organization agrees to use consistently when describing its data and information. What makes it “controlled” is the discipline: one preferred label per concept, explicit handling of synonyms, and a governed process for adding or retiring terms.

It helps to distinguish it from three things it is often confused with. A general vocabulary is simply the words people happen to use, with no control over duplicates, synonyms, or scope. A data governance glossary defines business terms for human readers but usually is not structured for machine use or bound to a single preferred label. A data dictionary documents the fields, types and constraints of a specific database—it describes how data is stored, not what concepts exist in the domain.

A controlled vocabulary sits above all three: it is the shared, machine-ready set of concepts to which the other artifacts point back. A controlled vocabulary is also the raw material from which we shape a taxonomy and thesaurus. It is the foundation from which we can determine how best to structure a hierarchy, placing vocabulary terms in parent-child relations within a taxonomy, and, for a thesaurus, how to determine which terms remain preferred and which are curated as alternative labels or aliases. For example, a museum requires every object’s medium to be chosen from a fixed list—“oil paint,” “watercolor,” “tempera”—so that a search for “watercolor” reliably surfaces every watercolor in the collection, even if the original donor called it something else.

A controlled vocabulary is the general term used to describe a flat list of terms, a taxonomy, or a thesaurus. In the context of the Ontology Pipeline, a controlled vocabulary is a flat authoritative list of disambiguated, defined terms. Variants or alternative labels may or may not be present in a controlled vocabulary.

A controlled vocabulary is the first building block in constructing a SKMS. It works in tandem with data cleaning and preparation tasks. As part of the vocabulary construction and refinement workflow, data must be deduplicated, merged, and defined to create a clean, disambiguated vocabulary fit for its purpose.

Deduplication involves reconciling synonymous terms to clarify the vocabulary. Best practices include defining each term or concept in the controlled vocabulary list, ensuring all users and stakeholders share a common understanding of the chosen terms. For example, Figure 3, illustrates that Mission to Planet Earth has a definition in NASA’s controlled vocabulary index. The indicator UF means “Use For”, and MTPE is the abbreviated acronym for Mission to Planet Earth. This illustrates how duplicates, near duplicates, and synonyms can be resolved when architecting a controlled vocabulary. A controlled vocabulary is the first step toward creating unified domain vocabularies, fostering alignment across people and machine systems while supporting a shared and common understanding.

Figure 3: Controlled vocabulary (https://ntrs.nasa.gov/citations/20000026924).

Now that we have controlled vocabularies, we develop metadata standards to encode the common understanding or “aboutness” of data and information. A metadata standard is a requirement intended to establish a common understanding of the meaning or semantics of the data, ensuring its proper use and interpretation by its owners and users. To achieve this common understanding, a number of characteristics or attributes of the data have to be defined, also known as metadata (https://en.wikipedia.org/wiki/Metadata_standard).

Metadata standards provide schema-based control for databases and information systems. Metadata elements define the fields that are needed to describe data and information assets. These elements are categorized by their characteristics: STRUCTURAL (for machine readability), DESCRIPTIVE (for context), and ADMINISTRATIVE (for asset maintenance and lineage). For example, a STRUCTURAL element might be the page sequence of a scanned book or the file format of an asset such as a PDF or spreadsheet—information a machine needs to render or process it. A DESCRIPTIVE element might be the title, author, or subject keywords that tell a person or system what the asset is about. An ADMINISTRATIVE element might be the lifecycle.

While these are the most common types of metadata elements, practitioners and stakeholders have expanded these categories to include subject areas such as social or provenance metadata. Regardless of the types of metadata elements, each must be well-defined, with clear direction on what each element type is designed to handle.

With well-defined metadata standards, each metadata element is prepared to accept controlled vocabulary values. A metadata standard can support various workflows and data streams, often serving as the foundational architecture for entity value systems and concept models. The controlled vocabulary provides the controlled or allowable values to pair with metadata elements. By implementing a metadata standard, a natural framework emerges for entity reconciliation, vocabulary management, and schema-based validation matrices to enforce vocabulary control and semantics. Additionally, metadata standards provide valuable insight into extended vocabulary needs, helping scope future requirements in subsequent steps of the Ontology Pipeline.

In Figure 4, the metadata element TITLE has the value of Mad Men Season 5: Plot Predictions. The metadata element TYPE specifies article, indicating the content type. By normalizing the metadata element and its expected allowable values, the metadata standard and controlled vocabulary work together to describe the asset, providing context and meaning.

Figure 4: Metadata standard example.

A taxonomy is a hierarchical classification or categorization system in which all the terms belong to a single hierarchical structure and have parent/child or broader/narrower relationships to other terms. Taxonomies allow for classification according to a predetermined system.

The creation of controlled vocabularies and metadata schemas is often overlooked in the rush to build taxonomies. Without proper data hygiene—resolving synonyms and duplicate concepts, as we do when building controlled vocabularies and metadata schemas—a taxonomy can be difficult to build and quickly becomes unwieldy.

A taxonomy takes the controlled vocabulary and transforms it into a hierarchical structure.

This marks the beginning of building relationships between concepts, paving the way for a more mature, ontology-rich system. These relationships serve as helpful classification structures for machine learning algorithms to assist with front-end navigation and organize assets. Additionally, taxonomies are often used in tagging and annotation systems.

Figure 5 shows two examples. Levels is the simple form: a two-level taxonomy where Level is the parent and Beginner, Intermediate, and Expert are the child concepts. Adobe Experience Manager is the fuller example: a three-level taxonomy taken from a working system. The top concept, level one, is Adobe Experience Manager, with Administration and Security as level two, or its child concepts. Nested beneath Administration are level three concepts, representing more granular concepts such as Access Control and Access Rights. Each term is a child of the one above, so reading down a branch takes you from the platform to a platform feature, finally ending in the specific capabilities of the platform.

A thesaurus is a controlled vocabulary that adds relationships between concepts—not only the broader/narrower hierarchy of a taxonomy, but also associative (“related”) and equivalence (“use / use-for”) relations. Where a taxonomy tells you where a concept sits, a thesaurus also tells you which concepts are interchangeable and which are meaningfully connected. A thesaurus will also include alternative labels and hidden labels, a method for including all of the other expressions used for any given term. Alternative labels include synonyms and acronyms while hidden labels are used for deprecated terms or terms used for search that should not be part of the published thesaurus.

An RDF taxonomy delivers immense value by  defining meaning that is both human and machine readable. Terms become concepts and each concept carries an identifier, its alternative labels, a definition and rich context in the form of documentation properties. I always structure taxonomies to evolve into thesauri because it is the crucial first step toward building a semantic, ontology-based knowledge management system.

A thesaurus handles ambiguity by forming associative relationships between terms, going beyond the parent-child relationships within a hierarchy. A thesaurus further encodes these structures, often using a lightweight, mid-level ontology such as SKOS-XL or the Simple Knowledge Ontology System. Much like a traditional thesaurus used to discover near terms or synonymous concepts in vocabulary management, an ontologically encoded thesaurus matures a controlled vocabulary, metadata standard, and taxonomy to support resolution at scale, while enforcing the logical reasoning embedded within ontologies.  In Figure 6, you will see BT (broader term), SYN (synonym), NT (narrower term), and RT (related term). A thesaurus architected with ontologies and a machine-readable encoding structure supports interoperability and is highly useful for helping both machines and humans understand context and meaning. With context and meaning, a thesaurus establishes semantic reasoning and primitive knowledge management, making it ready for the next step in the Ontology Pipeline.

An ontology is a formal, machine-readable model of a domain that defines classes of things, the properties that describe them, and the logical rules governing how they relate. Where a thesaurus records relationships between terms, an ontology encodes axioms a reasoner can act on to infer new facts. Having followed the iterative stages of the Ontology Pipeline, data and information are now primed and ready for the ontology build. With a basic ontological structure in place to describe vocabulary control, the taxonomy hierarchy, and the thesaurus, we can now add domain ontologies and standard, open ontologies to further expose direct and indirect relations and nuanced, descriptive contexts.

Ontologies enhance vocabularies by describing and contextualizing relationships between concepts, and by introducing logical reasoning. By assigning classes, properties, relations, and attributes, ontologies establish rule bases that define how concepts behave in the wild, ensuring a level of coherence within complex information systems.

Machines love ontologies because of their high-fidelity disambiguation and description, which bring clarity to machine understanding for tasks such as information retrieval, entity management, concept discovery, and RAG implementations for AI systems.

Figure 7: Ontology structure (https://www.ontotext.com/knowledgehub/fundamentals/what-are-ontologies/).

Ontology construction can be very difficult without established controlled vocabularies, metadata standards, taxonomies, and thesauri, as the underlying data and information structures lack integrity and may suffer from data quality issues. It is nearly impossible to build an ontology with messy, undefined vocabularies because introducing logic becomes extremely difficult when the underlying data itself is not logically structured.

Building ontologies is like writing a story that defines domains, complex systems, and the relationships among all the characters, places, things, and concepts.

Finally, we arrive at knowledge graphs, the current Rosetta Stone of a SKMS and the Ontology Pipeline’s visualization layer. The last step in the Ontology Pipeline involves synthesizing the four building blocks to culminate in a knowledge graph, which is essentially a knowledge management tool. Knowledge graphs are an assemblage of controlled vocabularies, metadata schemas, taxonomies, thesauri, and ontologies. The Ontology Pipeline naturally presents a layered knowledge graph, making it easier to troubleshoot broken logic while providing the control planes necessary to scale and extend the graph.

Figure 8: Knowledge graph explanation.

Knowledge graphs represent the synthesis of all stages of the knowledge modeling process, now visualized through clear, graphical representations. Because knowledge management can be complex, the visualization serves as an organizational language and communication interface, creating opportunities for teaching and learning across a domain and within the organization.

Knowledge graphs allow stakeholders, users, and contributors to interact and query a SKMS, demystifying the value proposition of semantics and surfacing knowledge as a first-class citizen. They use query languages such as SPARQL and SHACL, enabling the precise discovery of data and information across the graph. The only dependencies are the logical reasoning rules introduced by the encoded system. A knowledge graph is highly flexible, with its limitations defined by the complexity of the logical rule bases and data encoded within.

By building a SKMS using the logical steps outlined in the Ontology Pipeline framework, organizations can document time, effort, and cost estimates to secure funding and organizational support for future iterations and maintenance. As many organizations struggle to justify investment in a SKMS, a proven, repeatable framework enables them to estimate costs and develop metrics to demonstrate value. It’s crucial to highlight the ancillary and integrated benefits of the semantic build when implementing a semantic system. By following the Ontology Pipeline’s rigorous, iterative process—cleaning, preparation, reconciliation, modeling, testing, enrichment, enforcement, reporting, and measurement—these steps are incorporated naturally. Additionally, since large language models (LLMs) require clean, well-structured, semantically enriched data to deliver accurate, reliable results, who better to ensure data quality than semantic engineers?