What Is Knowledge Architecture?

Last Updated May 27, 2026

Knowledge architecture is the design of intellectual infrastructure: the frameworks, taxonomies, ontologies, metadata systems, semantic relationships, article maps, repositories, and governance practices that make complex knowledge usable at scale. It is the discipline of turning scattered information into a coherent system of meaning. Where information merely accumulates, knowledge architecture organizes. Where content grows into sprawl, knowledge architecture builds pathways. Where platforms become difficult to navigate, knowledge architecture restores structure, context, and interpretive continuity.

At its simplest, knowledge architecture asks how ideas should be defined, grouped, related, sequenced, documented, retrieved, revised, and extended. At its strongest, it asks how an entire knowledge environment can remain coherent as it grows: how concepts connect across fields, how article maps support learning, how metadata preserves context, how ontologies formalize relationships, how knowledge graphs reveal networks of meaning, and how governance prevents intellectual systems from decaying into disconnected fragments.

Knowledge architecture is not merely information architecture, content strategy, taxonomy design, library classification, ontology engineering, digital asset management, or knowledge management. It draws from each of these fields, but its central concern is broader: the design of structures that allow knowledge to become navigable, cumulative, interpretable, reproducible, and responsibly maintained across time.

Definition of Knowledge Architecture

Knowledge architecture is the structured design of concepts, categories, relationships, metadata, frameworks, pathways, repositories, and governance systems that make knowledge findable, understandable, reusable, and expandable. It is concerned with how knowledge is organized not only for storage, but for interpretation, navigation, learning, research, decision-making, and long-term institutional memory.

A knowledge architecture defines what the major concepts are, how they are grouped, how they relate to one another, how they are named, how they are documented, how they are retrieved, how they are updated, and how they connect to broader systems of meaning. It turns a collection into an intellectual environment.

This definition is intentionally broad because knowledge architecture is not limited to one medium. It applies to websites, digital libraries, research repositories, article maps, knowledge bases, learning systems, institutional archives, policy evidence systems, semantic platforms, AI retrieval systems, and interdisciplinary research environments. What changes across these contexts is the implementation. The architectural problem remains similar: how should knowledge be structured so that it can remain meaningful as it grows?

In practice, knowledge architecture is both intellectual and technical. It requires conceptual judgment, disciplinary understanding, editorial design, metadata practice, database thinking, semantic modeling, and governance. It may use code, but it is not reducible to code. It may use taxonomies, but it is not reducible to categories. It may use design, but it is not merely visual organization. Its core concern is the preservation of meaning across complexity.

Back to top ↑

Why Knowledge Architecture Exists

Knowledge architecture exists because knowledge systems tend to fail as they scale. Small collections can often survive through informal memory. A few documents can be remembered. A few categories can be managed manually. A small website can remain navigable through simple menus. But as the system grows, informal organization breaks down.

Concepts begin to overlap. Tags multiply. Categories become too broad. Some areas become overdeveloped while others remain invisible. Older material becomes difficult to retrieve. Links decay. Sources become detached from arguments. Datasets lose context. Readers cannot tell where to begin. Editors cannot remember how decisions were made. AI systems retrieve fragments without adequate structure. The problem is not simply volume. The problem is architecture.

Knowledge architecture exists to prevent that decay. It creates structures that allow knowledge systems to remain coherent under expansion. It gives a platform a map, a vocabulary, a set of relationships, a method of documentation, and a way to revise itself. It makes growth possible without allowing growth to become fragmentation.

This is why knowledge architecture matters for any serious intellectual project. A platform that publishes hundreds of articles without an architecture becomes an archive of isolated work. A research repository without metadata becomes a storage site. A digital library without classification becomes a pile of documents. A knowledge base without governance becomes a graveyard of outdated answers. A learning system without pathways becomes a confusing catalog. Architecture is what lets knowledge systems support inquiry rather than merely accumulate material.

Back to top ↑

What Knowledge Architecture Is Not

Knowledge architecture is often confused with adjacent practices. These overlaps are useful, but the distinctions matter. Knowledge architecture is not just navigation design. It is not just taxonomy. It is not just metadata. It is not just a database schema. It is not just search optimization. It is not merely a content calendar, menu hierarchy, folder tree, or tagging system.

A navigation system helps users move through visible pages. A taxonomy classifies topics. Metadata describes objects. A database schema structures records. A content strategy plans publication. Knowledge architecture asks how all of these structures work together as a coherent intellectual system. It is concerned not only with where something is placed, but with why it belongs there, how it relates to other objects, what assumptions structure the relationship, and how the system should evolve over time.

The point is not to separate these fields sharply. Knowledge architecture needs them. But it also asks a broader question: what intellectual infrastructure is required for knowledge to remain meaningful, navigable, and trustworthy as a system grows?

Back to top ↑

Core Components of Knowledge Architecture

Knowledge architecture is built from several interdependent components. A serious architecture must define concepts, group them into categories, arrange levels of abstraction, document relationships, preserve context through metadata, support retrieval, provide pathways for users, and maintain the system through governance.

The concept is the basic unit of meaning. Categories group concepts into usable domains. Hierarchies arrange broader and narrower ideas. Relationships connect concepts across the system. Metadata preserves context. Frameworks organize interpretation. Ontologies formalize entities and relationships. Knowledge graphs model networks. Repositories preserve reproducible artifacts. Governance keeps the system coherent over time.

The strength of a knowledge architecture depends less on any one component than on the alignment among components. A taxonomy without governance will drift. Metadata without relationships will remain shallow. A graph without controlled concepts will become noisy. A repository without documentation will be hard to reuse. A framework without implementation will remain abstract. Architecture is the work of making these components function as one system.

Back to top ↑

Knowledge Architecture and Information Architecture

Information architecture and knowledge architecture are closely related, but they are not identical. Information architecture is often concerned with findability, navigation, labeling, user flows, and the structure of digital environments. It asks how users move through information. Knowledge architecture asks how meaning itself is structured, related, documented, interpreted, and governed.

Information architecture may ask whether a website menu is clear. Knowledge architecture asks whether the menu reflects a coherent intellectual model. Information architecture may organize pages into sections. Knowledge architecture asks whether the underlying concepts, relationships, and research pathways are well designed. Information architecture may improve search and navigation. Knowledge architecture improves the structure that makes search and navigation meaningful.

The distinction is especially important in large knowledge systems. A website may be easy to navigate at the surface while still being conceptually weak. It may have attractive menus but poor category logic. It may have good page templates but inconsistent metadata. It may have clear labels but no deeper relationships among articles, datasets, methods, and frameworks. Knowledge architecture evaluates the deeper system beneath the interface.

In practice, the two fields should work together. Knowledge architecture without user-facing information architecture can become invisible and difficult to use. Information architecture without knowledge architecture can become shallow and cosmetic. A strong digital knowledge environment needs both: visible pathways for users and deeper structures that preserve meaning.

Back to top ↑

Taxonomies, Ontologies, and Knowledge Graphs

Taxonomies, ontologies, and knowledge graphs are three of the most important structural tools in knowledge architecture. Each organizes meaning differently.

A taxonomy classifies. It arranges concepts into categories and subcategories. It helps users understand where an item belongs and how topics are grouped. A taxonomy may be hierarchical, faceted, or controlled by a vocabulary. It supports navigation, filtering, consistency, and scope management.

An ontology formalizes. It defines what kinds of entities exist in a domain, what properties they have, and what relationships can connect them. Ontologies are especially useful when knowledge needs to be machine-readable, interoperable, or logically structured. They provide semantic precision.

A knowledge graph networks. It represents concepts, entities, documents, datasets, methods, people, institutions, and events as nodes connected by relationships. Graphs are especially useful when knowledge does not fit cleanly into a single hierarchy. They make cross-domain pathways visible.

Knowledge architecture often requires all three. A taxonomy gives the system order. An ontology gives it formal meaning. A knowledge graph gives it relational depth. The architectural question is not which one is best in the abstract, but how each supports the purpose of the knowledge system.

Back to top ↑

Metadata and Context

Metadata is the structured context that travels with a knowledge object. It may describe title, author, date, topic, status, source, format, series, version, relationship, citation, license, method, audience, or review history. In knowledge architecture, metadata is not an administrative afterthought. It is one of the main ways a system preserves meaning.

Without metadata, knowledge objects become difficult to evaluate. A document may exist, but users may not know whether it is current. A dataset may be available, but users may not know how it was generated. An article may be published, but users may not know which series it belongs to. A concept may appear repeatedly, but users may not know whether it is being used consistently.

Metadata supports retrieval, filtering, governance, provenance, and reuse. It helps users find the right material, understand its status, trace its sources, connect it to related objects, and decide whether it can be trusted for a given purpose. In research systems, metadata also supports reproducibility and auditability.

Strong metadata also supports machine systems. AI retrieval, semantic search, recommendation engines, and digital library systems are more reliable when documents and concepts carry structured context. Poor metadata causes automated systems to retrieve loosely related material without enough interpretive boundary. Good metadata does not guarantee good interpretation, but it gives both humans and machines a stronger foundation.

Back to top ↑

Architectural Layers of a Knowledge System

A mature knowledge architecture operates across multiple layers. The visible layer includes menus, article maps, search, headings, links, and user pathways. The editorial layer includes titles, categories, excerpts, references, style conventions, and related articles. The semantic layer includes concepts, relationships, metadata, controlled vocabularies, and ontologies. The computational layer includes databases, repositories, schemas, scripts, notebooks, and validation tools. The governance layer includes review cycles, naming conventions, versioning, revision logs, and maintenance practices.

These layers are often handled by different people or systems, which is why they can fall out of alignment. Designers may focus on the interface. Editors may focus on prose. Developers may focus on database structures. Researchers may focus on sources. Analysts may focus on data. Knowledge architecture asks how these layers can support one coherent intellectual system.

When these layers align, the system becomes much stronger. Article maps reflect the conceptual framework. Metadata supports retrieval and governance. Repositories mirror the article structure. Code produces outputs that support interpretation. Related articles create meaningful pathways. The visible interface becomes an expression of deeper intellectual order rather than a decorative layer placed on top of disconnected material.

Back to top ↑

Knowledge Architecture as Systems Thinking

Knowledge architecture is a form of systems thinking because it treats knowledge environments as interconnected systems rather than collections of isolated objects. It asks how concepts, categories, sources, metadata, users, platforms, workflows, algorithms, and institutions interact. It examines feedback, scale, hierarchy, boundary-setting, path dependence, and system maintenance.

A knowledge system can become unstable in ways that resemble other complex systems. Categories can become overloaded. Old structures can lock in poor assumptions. New topics can appear faster than the architecture can absorb them. Search can amplify already visible material. Neglected areas can become invisible. Tags can proliferate until they lose meaning. AI summaries can reinforce the structure’s existing biases. These are systems problems, not just editorial problems.

Systems thinking helps knowledge architecture move beyond static classification. It asks how the architecture changes over time. Which concepts become hubs? Which areas remain underconnected? Which pathways guide users repeatedly toward the same material? Which concepts bridge domains? Which categories should be split, merged, retired, or renamed? Which structures are resilient, and which are fragile?

For this reason, knowledge architecture should not be designed once and forgotten. It should be monitored, revised, and maintained as a living system. The goal is not perfect order, but durable coherence under change.

Back to top ↑

Knowledge Architecture in Research Platforms

Research platforms require especially strong knowledge architecture because they must preserve relationships among claims, sources, methods, datasets, models, disciplines, and interpretive contexts. A research platform is not merely a publication site. It is an environment for inquiry.

In a research platform, knowledge architecture can organize article maps, code repositories, datasets, references, model documentation, disciplinary pathways, and related topics. It can show which articles are introductory, which are methodological, which are applied, and which are synthetic. It can connect conceptual essays to reproducible code, figures, tables, datasets, and source lists.

This kind of architecture supports both readers and authors. Readers gain orientation. Authors gain a structure for building cumulatively. Editors gain a framework for deciding where new work belongs. Researchers gain pathways through methods, concepts, and evidence. Over time, the platform becomes more than a collection of outputs. It becomes a structured environment for knowledge development.

Research platforms also need architecture because they often operate across disciplines. A sustainability knowledge system may need ecology, economics, law, infrastructure, ethics, governance, data systems, and public health. An AI knowledge system may need computer science, statistics, philosophy, engineering, law, labor, education, and social impact. Without architecture, these domains sit beside one another. With architecture, their relationships can be made visible without collapsing their differences.

Back to top ↑

Knowledge Architecture and AI

AI-assisted systems make knowledge architecture more important. Large language models, retrieval-augmented generation, semantic search, recommendation engines, and automated summarization systems all depend on the structure of the knowledge they retrieve, summarize, rank, and recombine. If the underlying architecture is weak, AI systems inherit that weakness.

Poorly structured knowledge can lead AI systems to merge incompatible concepts, retrieve outdated material, ignore provenance, flatten disciplinary differences, or generate confident summaries from disconnected fragments. Strong architecture helps reduce these risks by preserving context, relationships, status, source structure, and domain boundaries.

Knowledge architecture can support AI systems through metadata, controlled vocabularies, ontologies, knowledge graphs, source hierarchies, document status fields, revision dates, and article relationships. These structures help retrieval systems find not only similar text, but relevant knowledge objects within a governed intellectual environment.

However, knowledge architecture should not be designed only for machines. Human understanding remains central. A system that is machine-readable but humanly obscure is incomplete. A system that supports automated retrieval but hides provenance is risky. A system that optimizes search while weakening interpretation is not a strong knowledge architecture. The goal is accountable intellectual infrastructure that can support both human inquiry and machine assistance.

Back to top ↑

Mathematical and Computational Modeling

Knowledge architecture can be modeled computationally because many of its structures resemble graphs, trees, tables, networks, and schemas. A taxonomy can be represented as a tree or directed acyclic graph. A knowledge graph can be represented as nodes and edges. Metadata can be represented as structured fields. Article relationships can be represented as adjacency lists. Ontology relationships can be expressed as triples.

Computational modeling makes architectural properties visible. It can identify orphaned nodes, overloaded hubs, excessive taxonomy depth, weakly connected domains, missing metadata, inconsistent labels, duplicate topics, and underdeveloped pathways. These models do not replace editorial judgment, but they provide evidence for architectural review.

Metrics must be interpreted carefully. A highly connected concept may be important, but it may also be overloaded. A deep taxonomy may support precision, but it may also create navigation burden. An isolated cluster may represent a neglected area, but it may also reflect a specialized subfield. Computational methods provide signals. Interpretation decides what those signals mean.

Back to top ↑

Python Section: Modeling Knowledge Architecture as a Graph

The following Python example represents a small knowledge architecture as a graph-like edge list and calculates basic degree counts without requiring external packages. It demonstrates how concepts and relationships can be made inspectable.

# what_is_knowledge_architecture_graph.py
# Lightweight graph-style model for knowledge architecture.

from pathlib import Path
import csv

ROOT = Path(".")
OUTPUTS = ROOT / "outputs"
OUTPUTS.mkdir(exist_ok=True)

concepts = [
    "Knowledge Architecture",
    "Taxonomy Design",
    "Ontology Modeling",
    "Metadata",
    "Knowledge Graphs",
    "Information Architecture",
    "Research Platforms",
    "Governance",
    "AI-Assisted Retrieval",
]

relationships = [
    ("Knowledge Architecture", "Taxonomy Design", "uses"),
    ("Knowledge Architecture", "Ontology Modeling", "uses"),
    ("Knowledge Architecture", "Metadata", "requires"),
    ("Knowledge Architecture", "Knowledge Graphs", "can_use"),
    ("Knowledge Architecture", "Information Architecture", "extends"),
    ("Knowledge Architecture", "Research Platforms", "supports"),
    ("Governance", "Taxonomy Design", "maintains"),
    ("Governance", "Metadata", "maintains"),
    ("Knowledge Graphs", "AI-Assisted Retrieval", "supports"),
    ("Metadata", "AI-Assisted Retrieval", "improves"),
]

degree = {concept: 0 for concept in concepts}

for source, target, relationship in relationships:
    degree[source] = degree.get(source, 0) + 1
    degree[target] = degree.get(target, 0) + 1

with (OUTPUTS / "knowledge_architecture_degree_summary.csv").open("w", newline="", encoding="utf-8") as f:
    writer = csv.writer(f)
    writer.writerow(["concept", "degree"])
    for concept, value in sorted(degree.items(), key=lambda item: item[1], reverse=True):
        writer.writerow([concept, value])

print("Degree summary written to outputs/knowledge_architecture_degree_summary.csv")

This simple model can be expanded into a full knowledge graph with typed relationships, metadata fields, article references, graph centrality, semantic similarity, and validation rules. The architectural value lies not in the code alone, but in the discipline of making concept relationships explicit enough to inspect and revise.

Back to top ↑

R Section: Auditing Taxonomy Balance

The following R example creates a small taxonomy table and summarizes domain balance. In a larger article map, similar workflows can help identify overdeveloped areas, weakly represented domains, excessive depth, and possible gaps.

# what_is_knowledge_architecture_taxonomy_audit.R
# Lightweight taxonomy balance audit.

concepts <- data.frame(
  concept = c(
    "Knowledge Architecture",
    "Taxonomy Design",
    "Ontology Modeling",
    "Metadata",
    "Knowledge Graphs",
    "Information Architecture",
    "Research Platforms",
    "Governance",
    "AI-Assisted Retrieval"
  ),
  domain = c(
    "root",
    "classification",
    "semantic",
    "context",
    "network",
    "navigation",
    "infrastructure",
    "governance",
    "technology"
  ),
  depth = c(0, 1, 1, 1, 1, 1, 2, 2, 2)
)

dir.create("outputs", showWarnings = FALSE)

domain_summary <- as.data.frame(table(concepts$domain))
names(domain_summary) <- c("domain", "concept_count")

depth_summary <- data.frame(
  total_concepts = nrow(concepts),
  max_depth = max(concepts$depth),
  mean_depth = mean(concepts$depth),
  median_depth = median(concepts$depth)
)

write.csv(domain_summary, "outputs/domain_summary.csv", row.names = FALSE)
write.csv(depth_summary, "outputs/depth_summary.csv", row.names = FALSE)

print(domain_summary)
print(depth_summary)

Taxonomy audits should not be mechanical. A balanced taxonomy is not always better than an uneven one. Some domains deserve more detail than others. The value of the audit is that it makes structural patterns visible so they can be interpreted rather than ignored.

Back to top ↑

SQL Section: A Minimal Knowledge Architecture Schema

SQL can support knowledge architecture by storing concepts, articles, relationships, metadata, and review status in a structured way. Even when a system later uses graph databases or semantic web standards, relational schemas remain useful for governance, audits, exports, and reproducible documentation.

-- what_is_knowledge_architecture_schema.sql
-- Minimal schema for concepts, articles, and relationships.

CREATE TABLE IF NOT EXISTS concepts (
  concept_id TEXT PRIMARY KEY,
  label TEXT NOT NULL,
  domain TEXT,
  definition TEXT,
  status TEXT DEFAULT 'active'
);

CREATE TABLE IF NOT EXISTS articles (
  article_id TEXT PRIMARY KEY,
  title TEXT NOT NULL,
  slug TEXT NOT NULL,
  series TEXT NOT NULL,
  status TEXT DEFAULT 'draft',
  last_reviewed DATE
);

CREATE TABLE IF NOT EXISTS relationships (
  relationship_id INTEGER PRIMARY KEY,
  source_concept_id TEXT NOT NULL,
  target_concept_id TEXT NOT NULL,
  relationship_type TEXT NOT NULL,
  evidence_note TEXT,
  FOREIGN KEY (source_concept_id) REFERENCES concepts(concept_id),
  FOREIGN KEY (target_concept_id) REFERENCES concepts(concept_id)
);

CREATE TABLE IF NOT EXISTS article_concepts (
  article_id TEXT NOT NULL,
  concept_id TEXT NOT NULL,
  role TEXT,
  PRIMARY KEY (article_id, concept_id),
  FOREIGN KEY (article_id) REFERENCES articles(article_id),
  FOREIGN KEY (concept_id) REFERENCES concepts(concept_id)
);

This schema reflects a core principle: articles and concepts should not be treated as identical. An article is a publication object. A concept is a unit of meaning. A single article may discuss many concepts, and a single concept may appear across many articles. Separating them allows a knowledge architecture to support richer relationships, better retrieval, and more durable governance.

Back to top ↑

GitHub Repository

This article is supported by a companion repository folder with reproducible examples, small synthetic datasets, documentation, and language-specific modeling scaffolds for knowledge-system analysis.

The repository structure mirrors the article’s architectural argument. Python supports graph-style concept modeling. R supports taxonomy auditing and domain summaries. SQL supports concepts, article metadata, and relationship schemas. Systems-language folders provide space for validation utilities, graph-processing experiments, and lower-level tooling. Documentation, data, and outputs preserve the relationship between explanation, model, and reproducible artifact.

Back to top ↑

Governance and Maintenance

Knowledge architecture must be governed because knowledge systems change. New concepts appear. Old categories become too broad. Some areas need subdivision. Some labels become outdated. Relationships change as fields develop. Metadata fields need refinement. Repositories need validation. Article maps need revision. Governance is the practice of maintaining coherence through change.

Governance includes naming conventions, taxonomy rules, metadata requirements, review cycles, versioning, relationship standards, archive policies, and revision logs. It also includes judgment: when to split a category, when to merge two topics, when to retire an outdated term, when to create a new article pathway, and when to preserve disagreement rather than force consensus.

A governed knowledge architecture does not try to freeze knowledge. It allows the system to evolve without losing traceability. It makes change visible. It records why structures were altered. It distinguishes current from archival material. It gives future editors, researchers, and users enough context to understand how the architecture developed.

Maintenance is not clerical work. It is intellectual stewardship. When a knowledge system is poorly maintained, users lose trust. When it is carefully maintained, the system becomes more durable, more navigable, and more capable of supporting serious inquiry over time.

Back to top ↑

Interpretive and Ethical Cautions

Knowledge architecture is powerful because it structures visibility. It determines what appears central, what appears peripheral, what is easy to retrieve, what is hidden, what is grouped together, what is separated, and what relationships become obvious. For that reason, it carries interpretive and ethical responsibility.

Classification systems can reproduce institutional assumptions. Archives can preserve dominant voices while marginalizing others. Metadata schemas can privilege some forms of knowledge over others. Ontologies can make contested categories appear fixed. Search systems can amplify what is already well connected. AI systems can inherit and intensify weaknesses in the underlying architecture.

A serious knowledge architecture must therefore be structured and self-critical. It should ask whose categories are being used, whose knowledge is included, whose language is treated as authoritative, which relationships are being made visible, and which forms of knowledge risk being flattened or excluded. The goal is not to avoid structure. Without structure, knowledge becomes inaccessible. The goal is to design structures that remain transparent, revisable, and accountable.

Good architecture preserves complexity without surrendering to chaos. It supports navigation without pretending that every boundary is final. It makes knowledge usable without erasing disagreement. It gives users pathways while allowing the system to acknowledge plurality, uncertainty, and historical context.

Back to top ↑

Why Knowledge Architecture Matters

Knowledge architecture matters because modern knowledge environments are too large, too interdisciplinary, and too dynamic to rely on informal organization. Research platforms, digital libraries, educational systems, policy archives, knowledge bases, AI retrieval systems, and public knowledge projects all require structures that preserve meaning across scale.

It matters because publishing more is not the same as knowing more. A system can contain thousands of articles and still fail to support understanding. A database can store millions of records and still fail to preserve context. A library can provide access and still fail to show relationships. Knowledge architecture is what turns accumulation into organized inquiry.

It matters because knowledge is not only stored; it is interpreted. Every category, tag, hierarchy, link, metadata field, ontology, and graph edge makes an interpretive decision. These decisions shape what users can find, understand, compare, and trust. The architecture of a knowledge system is therefore part of the knowledge itself.

Most importantly, knowledge architecture matters because it supports continuity. It allows ideas to build on one another. It helps institutions remember. It helps learners move from foundations to complexity. It helps researchers connect methods, evidence, and theory. It helps digital platforms grow without becoming incoherent. It provides the intellectual infrastructure through which knowledge can remain alive, navigable, and responsible over time.

Back to top ↑

Related Articles

• Foundations of Knowledge Architecture
• Conceptual Frameworks in Research
• Research Frameworks and Analytical Models
• Taxonomy Design for Knowledge Systems
• Information Architecture vs. Knowledge Architecture
• Knowledge Graphs and Semantic Relationships

Further Reading

• Aitchison, J., Gilchrist, A. and Bawden, D. (2000) Thesaurus Construction and Use: A Practical Manual. 4th edn. London: Aslib.
• Allemang, D. and Hendler, J. (2011) Semantic Web for the Working Ontologist: Effective Modeling in RDFS and OWL. 2nd edn. Amsterdam: Morgan Kaufmann.
• Broughton, V. (2015) Essential Classification. 2nd edn. London: Facet Publishing.
• Lambe, P. (2007) Organising Knowledge: Taxonomies, Knowledge and Organisational Effectiveness. Oxford: Chandos Publishing.
• Morville, P. and Rosenfeld, L. (2006) Information Architecture for the World Wide Web. 3rd edn. Sebastopol, CA: O’Reilly.
• Rowley, J. and Hartley, R. (2017) Organizing Knowledge: An Introduction to Managing Access to Information. 4th edn. London: Routledge.
• Sowa, J.F. (2000) Knowledge Representation: Logical, Philosophical, and Computational Foundations. Pacific Grove, CA: Brooks/Cole.

Back to top ↑

References

• Hodge, G. (2000) Systems of Knowledge Organization for Digital Libraries: Beyond Traditional Authority Files. Washington, DC: Council on Library and Information Resources. Available at: https://www.clir.org/pubs/reports/pub91/
• International Organization for Standardization (2011) ISO 25964-1: Information and Documentation — Thesauri and Interoperability with Other Vocabularies — Part 1: Thesauri for Information Retrieval. Available at: https://www.iso.org/standard/53657.html
• International Organization for Standardization (2013) ISO 25964-2: Information and Documentation — Thesauri and Interoperability with Other Vocabularies — Part 2: Interoperability with Other Vocabularies. Available at: https://www.iso.org/standard/53658.html
• Library of Congress (n.d.) Library of Congress Subject Headings. Available at: https://www.loc.gov/aba/cataloging/subject/
• National Information Standards Organization (2010) Guidelines for the Construction, Format, and Management of Monolingual Controlled Vocabularies. Available at: https://www.niso.org/publications/ansiniso-z3919-2005-r2010
• W3C (2012) OWL 2 Web Ontology Language Document Overview. Available at: https://www.w3.org/TR/owl2-overview/
• W3C (2014) RDF 1.1 Concepts and Abstract Syntax. Available at: https://www.w3.org/TR/rdf11-concepts/
• W3C (2014) RDF Schema 1.1. Available at: https://www.w3.org/TR/rdf-schema/
• W3C (2014) SKOS Simple Knowledge Organization System Reference. Available at: https://www.w3.org/TR/skos-reference/

Back to top ↑