Chapter 52: Architecting a Community Knowledgebase

Chapter Overview

Part IX showed a pattern: the artifact that lasts across case studies is rarely the map itself. It is the knowledgebase — the structured, maintained, accessible collection of what a community knows about itself. This chapter shifts from using Community Mapping to building the knowledge infrastructure that supports it. You will learn how to design a knowledgebase architecture: how to structure entries, relationships, and metadata; how to establish vocabulary and taxonomy; how to balance authoritative and lived sources; and how to protect privacy while maintaining discoverability.

Learning Outcomes

By the end of this chapter, you will be able to:

Explain why knowledgebases outlast individual mapping projects
Design an information architecture suited to community knowledge domains
Identify when controlled vocabularies support discovery and when they constrain community voice
Distinguish between authoritative sources and lived sources and apply both appropriately
Evaluate privacy risks created by concentrating knowledge in a single system
Apply versioning principles to community knowledge that changes over time
Articulate the governance questions embedded in knowledgebase architecture decisions

Key Terms

Knowledgebase: A structured, maintained collection of knowledge organized for access, search, discovery, and connection — distinct from a database optimized for application transactions.
Information Architecture: The structure, organization, and labeling of content to support findability, usability, and understanding.
Controlled Vocabulary: A predefined, managed set of terms used consistently to tag, classify, or describe content.
Schema.org: A collaborative standard for structured data markup on the web, used for describing entities like organizations, events, places, and people.
Versioning: The practice of preserving previous states of knowledge so changes over time are visible and reversible.

52.1 Why Knowledgebases Outlast Maps

Community Mapping produces outputs: maps, reports, dashboards, presentations. These outputs serve a purpose in the moment — informing a decision, supporting an advocacy campaign, teaching a concept. But outputs age quickly. A map showing service locations becomes outdated as services open, close, or relocate. A report on neighborhood demographics becomes stale after the next census. A dashboard tracking food access loses relevance once the policy it informed is passed or abandoned.

What persists — what has the potential to compound value across time — is the underlying knowledgebase. The knowledgebase is the structured, maintained repository of what is known: which organizations exist, what services they provide, where residents gather, what infrastructure is present, what stories have been told, what relationships connect entities. The knowledgebase does not replace outputs. It generates them. A well-architected knowledgebase can produce multiple maps, multiple reports, and multiple dashboards from a single, maintained source of truth.

This shift in thinking is critical. If Community Mapping treats each project as a one-off exercise — collect data, make a map, deliver a report, close the file — knowledge scatters. The same service gets researched three times by three different organizations. The same community stories get collected twice and stored in incompatible formats. The same geography gets mapped again and again because no one maintained the first map.

A knowledgebase architecture inverts this. Instead of one project → one map → knowledge lost, the pattern becomes: many contributors → shared knowledgebase → many outputs, maintained over time. The knowledgebase becomes infrastructure: something communities invest in once and benefit from repeatedly.

But this permanence brings responsibility. A database supporting a single application can be thrown away when the app sunsets. A knowledgebase designed to outlast any single project must be architected for longevity, clarity, and trustworthiness. It must be understandable to people who did not build it. It must be maintainable by people who were not there at the start. It must be auditable so future users can assess what they are inheriting.

The cases in Part IX illustrated this. The Scarborough immigrant services coordination case (Chapter 49) survived five years not because one agency kept updating a static map, but because the participating organizations maintained a shared directory of services, referral pathways, and contact points. The cultural mapping case in Chapter 51 did not preserve every individual story map — but it preserved the oral histories, the place-story links, and the metadata describing who told the story, when, and under what consent terms. The knowledge outlasted the visualizations.

Architecting a knowledgebase means asking: What will this community need to know five years from now? Ten? What knowledge will compound if we maintain it, and what will become noise if we treat it as permanent? Not everything deserves knowledgebase status. Some data is transient. Some context is only relevant in the moment. Good architecture distinguishes the durable from the disposable.

52.2 Entries, Tags, and Relationships

At its simplest, a knowledgebase is a collection of entries. An entry might represent an organization, a service, a place, a person, an event, a story, a policy, or a relationship. Each entry has attributes (properties that describe it) and relationships (links to other entries).

For example, consider a community health clinic entry. Attributes might include:

Name: "West End Community Health Centre"
Type: Healthcare facility
Services offered: Primary care, mental health counseling, prenatal care
Address: 234 Oak Street
Hours: Monday–Friday 9 AM – 5 PM
Contact: (555) 123-4567
Languages: English, Spanish, Mandarin
Accessibility: Wheelchair accessible entrance, elevator to second floor

Relationships might include:

Located in: West End neighborhood
Funded by: Regional Health Authority
Refers to: Downtown Mental Health Crisis Centre
Partners with: West End Seniors Network
Featured in: 2023 Health Access Mapping Project

A simple knowledgebase architecture might store each entry as a record in a spreadsheet or database table. A more sophisticated architecture uses linked data principles: entries are nodes in a graph, and relationships are edges. This graph structure makes it possible to answer questions like: "What services are available in the West End?" (follow the "located in" relationship) or "Who does the clinic refer clients to?" (follow the "refers to" relationship).

Tags are lightweight classifiers. They allow entries to be grouped, filtered, and discovered. Tags might describe domains (health, housing, education), populations served (seniors, youth, immigrants), or characteristics (wheelchair accessible, open evenings, free services). Tags are flexible — new ones can be added without restructuring the entire system. But flexibility brings risk: without governance, tags proliferate, become inconsistent, and lose utility. (We return to this in 52.5.)

The distinction between attributes, tags, and relationships matters. Attributes describe an entry's intrinsic properties. Tags classify entries into groups. Relationships connect entries to each other. A well-designed knowledgebase uses all three intentionally.

For Community Mapping, relationships are often the most valuable layer. A list of organizations is useful. A list that shows which organizations work together, who refers to whom, and what geographic areas they serve is a system map. The relationships are where insight lives.

52.3 Information Architecture for Communities

Information architecture (IA) is the practice of organizing and labeling content so people can find what they need, understand what they have found, and move confidently through a system. Good IA feels invisible. Bad IA feels like a maze.

For community knowledgebases, IA decisions include:

What entities deserve their own entries? Does each volunteer get an entry, or only organizations? Does each event get an entry, or only recurring programs? Does each park bench with a memorial plaque get an entry, or only parks as a whole? There is no universal right answer. The decision depends on what questions the knowledgebase must answer. If the knowledgebase supports volunteer coordination, individual volunteers need entries. If it supports cultural memory work, individual memorial benches might matter. If it supports service planning, neither is likely necessary.

How are entries categorized? Flat taxonomies (a single list of categories) work for small collections. Hierarchical taxonomies (categories within categories) support larger, more complex systems. For example, a service taxonomy might have top-level categories like Health, Housing, Education, and Employment, with subcategories under each (Health → Primary Care, Mental Health, Dental, etc.). Hierarchies support drill-down discovery but require more effort to maintain and can constrain entries that fit multiple categories.

What metadata is required, and what is optional? Metadata is data about data. For a community organization entry, metadata might include: date added, last updated, added by whom, data source, verification status, and visibility settings. Required metadata ensures consistency. Optional metadata allows flexibility. But every metadata field is a maintenance burden. Choose carefully.

How is the knowledgebase navigated? By search? By browsing categories? By map view? By list view? By network graph? Different users have different mental models. A resident looking for food assistance may start with a map ("What's near me?"). A service coordinator may start with a category browse ("Show me all food programs"). A researcher may start with a search ("Where did we document that food sovereignty workshop?"). Good IA supports multiple entry points.

Schema.org provides one useful reference architecture. It is a collaborative standard for structured data on the web, defining entity types (Organization, Event, Place, Person) and properties (name, location, openingHours, contactPoint). Many community knowledgebase platforms adopt Schema.org as a foundation and extend it with domain-specific entities (Referral, Story, Asset). Using a standard schema has advantages: tools understand it, data can be exchanged, and the architecture is self-documenting. But standards can also constrain. If Schema.org does not have an entity type for "Informal Leader" or "Cultural Protocol," you must either extend the schema or work around it.

Another useful principle: design for browsability as well as searchability. Search assumes users know what they are looking for. Browsing supports exploratory discovery. A knowledgebase that only offers a search box is inhospitable to users who want to see "what's here" or "what kinds of things can I learn about."

52.4 Choosing What to Document

Not everything a community knows belongs in the knowledgebase. Some knowledge is too sensitive. Some is too transient. Some is better held as unstructured story than forced into structured fields.

The decision of what to document — and with what level of detail — is both practical and ethical.

Practical considerations:

Maintenance burden. Every entry must be maintained. If an entry requires weekly updates to stay accurate, is there capacity to do that work? If not, the entry will decay, and the knowledgebase will lose credibility.
Relevance over time. Some information has a shelf life. A one-time event does not need permanent knowledgebase status unless it has lasting significance (e.g., it shaped community identity or produced ongoing initiatives). Transient data can be archived, not maintained.
Granularity. How specific should entries be? Should a community garden be one entry, or should each plot, each volunteer, and each harvest be separate entries? Fine-grained detail supports rich analysis but multiplies complexity. Coarse-grained entries are easier to maintain but limit what questions can be answered.

Ethical considerations:

Consent. Does the subject of an entry know they are being documented? Did they consent? Under what terms? (Consent is covered in depth in 52.9, but it shapes what gets documented in the first place.)
Harm potential. Could this entry be used to surveil, target, or exploit the people or places it describes? A map of informal immigrant support networks could be used by deportation enforcement. A database of youth hangout spots could be used for policing. If harm is plausible, the entry does not belong in the knowledgebase — or it belongs under strict access controls.
Cultural authority. Who has the right to document this knowledge? A sacred site may be known to a community, but that does not mean outsiders should document its location or significance. Indigenous data sovereignty principles (OCAP) apply here: Ownership, Control, Access, and Possession belong to the community whose knowledge it is.

The case in Chapter 51 (cultural mapping in a Métis community) showed this in practice. The community chose to document some stories in full detail, some stories as metadata only (title, teller, date, but no content without permission), and some stories as "known to exist" without any details in the public knowledgebase. The architecture supported all three levels. That flexibility was not a technical choice — it was a governance and ethics choice, reflected in architecture.

A useful heuristic: document what supports the community's stated purposes. If the knowledgebase exists to support service coordination, document services. If it exists to preserve cultural memory, document stories and places. If it exists to inform advocacy, document gaps and disparities. Do not document everything just because you can.

52.5 Naming and Vocabulary

What you call things matters. In a knowledgebase, naming shapes search, discovery, understanding, and trust.

Consider a simple example: is a drop-in center where people experiencing homelessness can get a meal called a "soup kitchen," a "community meal program," a "drop-in center," or a "hospitality service"? Each term carries different connotations. "Soup kitchen" may feel stigmatizing to some. "Hospitality service" may feel obscure. "Drop-in center" may be too vague if the knowledgebase includes many kinds of drop-in programs.

One solution is controlled vocabularies: a managed list of preferred terms that are used consistently across the knowledgebase. Controlled vocabularies support precision and consistency. If every entry about food programs uses the same term, searching and filtering is reliable. If every contributor uses their own terminology, the knowledgebase fractures.

But controlled vocabularies have costs. They require governance: someone must decide which term is preferred, document the decision, train contributors, and update the vocabulary as language evolves. They can also erase local language. If a community calls something by a specific name, forcing a "standard" term can feel like outsider imposition.

The alternative is free-text tagging: contributors use whatever terms feel right. This approach honors local language and adapts quickly to new concepts. But it creates inconsistency. One person tags an entry "seniors," another tags it "older adults," a third tags it "elders." A search for "seniors" misses two-thirds of the relevant entries.

Hybrid approaches are common: a core set of controlled terms for high-level categories (health, housing, education), plus free-text tagging for specifics and local nuance. The knowledgebase might also include synonym lists or mapping tables so a search for "seniors" also finds entries tagged "older adults" or "elders."

This is not just a UX question. It is a governance question, discussed in Chapter 35. Who decides what terms are used? Is it a centralized authority? A community committee? Individual contributors with peer review? The answer shapes whether the knowledgebase feels like community knowledge or institutional knowledge.

Naming also intersects with cultural competence. The term "Indigenous" may be appropriate in some contexts; in others, specific nations or communities must be named. The term "low-income" may be analytically useful but stigmatizing in public-facing displays. Some communities prefer "people experiencing homelessness" over "the homeless." These are not trivial word choices — they reflect power, respect, and whose voice shapes the knowledge.

A practical recommendation: document your vocabulary decisions. Create a glossary or data dictionary that explains what each term means, why it was chosen, and what alternatives exist. This transparency supports onboarding new contributors, resolves ambiguities, and makes the knowledgebase's values visible.

52.6 Authoritative vs Lived Sources

Community knowledgebases draw from two kinds of sources: authoritative sources (official, institutional, published) and lived sources (experiential, narrative, resident knowledge).

Authoritative sources include census data, municipal service directories, licensed datasets, published research, government records, and nonprofit annual reports. These sources are typically structured, verifiable, and stable. They carry institutional credibility. A service directory listing from a municipal website can be cited, fact-checked, and updated through official channels.

Lived sources include resident interviews, community workshops, oral histories, participatory mapping sessions, and direct observation. These sources are typically unstructured, subjective, and fluid. They carry community credibility. A resident's testimony that a park feels unsafe after dark may not appear in any official report, but it is knowledge that matters.

Both are necessary. Authoritative sources provide breadth, consistency, and baseline facts. Lived sources provide depth, nuance, and context. A knowledgebase that only includes authoritative sources is incomplete — it misses what communities know that institutions do not document. A knowledgebase that only includes lived sources is fragile — it lacks the anchoring facts that make findings credible to decision-makers.

But integrating both is not simple. Authoritative and lived sources sometimes contradict each other. A municipal service directory may list a clinic as "open Monday–Friday 9 AM – 5 PM," but residents report that the clinic frequently closes early or turns people away due to capacity. Which source is "correct"? Both, in different senses. The directory reflects official policy. The resident reports reflect lived reality. A good knowledgebase does not erase the contradiction — it holds both and flags the tension.

Handling contradictions requires provenance tracking: every entry or claim in the knowledgebase should document its source. When an entry says a clinic is open 9 AM – 5 PM, the knowledgebase should show: Source: Municipal Health Services Directory, updated March 2024. When another entry says the clinic often closes early, the knowledgebase should show: Source: Resident interview, August 2024. This transparency allows users to weigh the sources and make their own judgments.

Lived sources also require different verification practices. An authoritative source can be verified by checking the original document. A lived source is verified through triangulation: multiple residents report the same experience, or direct observation confirms the claim. Verification does not mean dismissing lived sources as "anecdotal." It means being as rigorous with experiential knowledge as with institutional knowledge.

Ethical practice also requires protecting lived sources. Residents who share knowledge may not want to be named, especially if the knowledge is sensitive (e.g., reporting that a service discriminates, or that a place feels unsafe). Anonymization and consent protocols are essential (covered in 52.9).

52.7 Versioning Community Knowledge

Communities change. Services open and close. Policies shift. Populations move. Infrastructure is built or falls into disrepair. A knowledgebase that does not accommodate change becomes a historical artifact — accurate once, misleading now.

Versioning is the practice of preserving previous states of knowledge so that changes over time are visible, understandable, and reversible. Versioning prevents two failure modes: the disappearing-history problem (where updates erase what came before, making it impossible to understand trajectories) and the frozen-snapshot problem (where fear of losing history prevents updates, leaving the knowledgebase stale).

The simplest versioning approach is timestamping: every entry records when it was created and last updated. This allows users to see how old the knowledge is and decide whether to trust it. But timestamps alone do not preserve history. If an entry is updated, the old version is overwritten.

A more robust approach is change logs: each update to an entry appends a record of what changed, when, and by whom. A service entry might show:

March 2023: Added by Maria Gonzalez (Community Health Network)
July 2023: Hours updated by Jamal Thompson (field verification)
October 2024: Status changed to "temporarily closed" by System Admin (source: clinic voicemail)

Change logs make knowledge evolution transparent and allow errors to be traced and corrected.

The most complete approach is full versioning: every change creates a new version of the entry, and all versions are retained. Users can view the current version or browse history. This is how Wikipedia works. It supports accountability (who said what, when), error correction (revert to a previous version if an update was wrong), and temporal analysis (how has service availability changed over five years?).

But versioning has costs. Storage grows. Interfaces become more complex. Maintenance burden increases. For small knowledgebases, timestamping may suffice. For large, multi-contributor, high-stakes systems, full versioning is worth the investment.

Versioning also raises governance questions. Who is allowed to update entries? Anyone? Only verified contributors? Only the original author? What review process applies? How are disputes resolved when two contributors disagree on the current state? These are not technical questions — they are community knowledge governance questions, discussed in Chapter 35. Architecture must support the governance model, but it does not replace it.

52.8 Searchability and Discoverability

A knowledgebase is only useful if people can find what they need. Searchability (finding by query) and discoverability (finding by exploration) are two sides of the same coin.

Search requires indexing: every entry is analyzed to extract searchable terms (words in the title, description, tags, location, etc.), and those terms are stored in an index. When a user searches for "mental health services," the system looks up those terms in the index and returns matching entries. Good search supports:

Full-text search (find entries containing specific words anywhere in the record)
Field-specific search (find entries where the organization name contains "health")
Filters (find entries tagged "wheelchair accessible" AND located in "West End")
Fuzzy matching (find "counceling" even if it is misspelled)

Search also requires thoughtful defaults. Should results rank by relevance (entries matching more terms appear first), recency (newest entries appear first), or proximity (if the user's location is known, nearest entries appear first)? The answer depends on use case.

Discovery requires structure and navigation. Browsable taxonomies, map views, network graphs, and curated collections support exploration. A knowledgebase might offer:

Category browse ("Show me all entries tagged 'Youth Services'")
Map view ("Show me what is near this location")
Related entries ("People who viewed this clinic also viewed these food programs")
Curated collections ("Featured stories from the 2024 Cultural Mapping Project")

Discoverability also benefits from metadata richness. An entry with a clear title, a concise summary, relevant tags, and a featured image is easier to discover than a sparse entry with only a name and address. But metadata requires effort. Balancing detail with sustainability is an ongoing design challenge.

An important accessibility consideration: search and discovery must work for users with varying abilities, literacies, and languages. Voice search, autocomplete, visual navigation, and multilingual interfaces expand who can use the knowledgebase. A system optimized only for text-savvy, English-speaking users excludes many community members.

52.9 Privacy in the Knowledgebase

Knowledgebases concentrate knowledge. Concentration creates power — and risk.

A knowledgebase that shows where vulnerable populations live, where informal support networks operate, or where sensitive activities occur can be used to help or to harm. It can support service delivery or enable surveillance. It can protect cultural knowledge or expose it to exploitation.

Privacy in knowledgebases is not the same as privacy in transactional databases. A transactional system (e.g., a clinic's patient records) is designed for confidentiality: each user sees only their own data. A knowledgebase is designed for discovery: the point is to make knowledge findable. The tension is structural.

Privacy risks include:

Re-identification. Even if a knowledgebase does not include names, combining multiple attributes (location + age range + service use) can identify individuals, especially in small communities.
Surveillance. A map of where undocumented immigrants access services could be used by immigration enforcement. A directory of Indigenous sacred sites could be used by extractive industries.
Exploitation. Knowledge about community assets (e.g., informal economies, cultural practices, volunteer networks) can be extracted and monetized by outsiders.
Breach. Concentrating knowledge in one system creates a single point of failure. If the system is hacked, all the knowledge is exposed at once.

Chapter 32 covered privacy and data ethics in detail. The principles apply here with added weight because knowledgebases are designed to persist. A transient dataset used for one project and then deleted has limited exposure. A knowledgebase maintained for years accumulates risk over time.

Mitigation strategies include:

Access controls. Not all knowledge should be public. Sensitive entries can be restricted to trusted users, specific roles, or community members only.
Granularity limits. Do not document at a level of detail that enables harm. A map showing "service deserts in the West End" is less risky than a map showing individual addresses of people receiving services.
Community authority. The community whose knowledge is represented should control what is documented, who can access it, and under what terms. This is especially critical for Indigenous knowledge (OCAP principles apply).
Transparency. Users should know what is being collected, how it will be used, and who has access. Privacy policies should be written in plain language, not legal jargon.
Consent. People and organizations represented in the knowledgebase should consent to inclusion. Consent should be informed, specific, and revocable.

A practical example: the cultural mapping case in Chapter 51 used a three-tier access model. Tier 1 (public) included stories cleared for public sharing. Tier 2 (community members) included stories available only to verified community members. Tier 3 (restricted) included metadata only, with full content held offline and accessible only with individual permission from the knowledge holder. The architecture supported all three tiers. That design was not technically complex, but it required deliberate governance and trust infrastructure.

Privacy is not a one-time design choice. It is an ongoing commitment. As the knowledgebase grows, as contributors change, and as political contexts shift, privacy risks evolve. Regular audits, community oversight, and the ability to remove or restrict entries are essential.

52.10 Synthesis and Implications

This chapter has argued that knowledgebase architecture is not a backend technical concern — it is a strategic, ethical, and governance decision that shapes what knowledge persists, who can access it, and how communities understand themselves over time.

Several themes emerge:

Knowledgebases are infrastructure. Like roads or water systems, they require upfront investment, ongoing maintenance, and long-term governance. They are not projects with end dates; they are systems with lifecycles.

Architecture embeds values. The choice of what to document, how to name it, who controls updates, and what privacy protections exist are not neutral. They reflect whose knowledge is valued, whose voice is centered, and whose safety is prioritized.

Structure and flexibility must coexist. Too much structure (rigid taxonomies, mandatory fields, controlled vocabularies) constrains community voice and adaptability. Too much flexibility (no standards, no verification, no governance) produces chaos. Good architecture finds the balance.

Provenance and versioning build trust. Transparency about where knowledge comes from, who contributed it, and how it has changed over time allows users to assess credibility and hold contributors accountable.

Privacy is not optional. Concentrating knowledge creates risk. Mitigation requires access controls, consent processes, community authority, and the ability to restrict or remove entries.

The implications for Community Mapping practice are clear. If you are starting a mapping project, ask early: Will this knowledge outlive this project? Should it? If the answer is yes, invest in knowledgebase architecture from the start. Design for longevity, maintainability, and governance. Do not treat the knowledgebase as a byproduct of the mapping work — treat it as the core asset.

If you inherit an existing knowledgebase, audit it. Is the architecture documented? Are governance roles clear? Is provenance tracked? Are privacy protections adequate? Is the system maintainable by people other than its creator? Many knowledgebases fail not because the data is wrong, but because the architecture is opaque, brittle, or ungoverned.

Finally, recognize that knowledgebase work is not just technical — it is relational. The architecture must support the relationships between contributors, between contributors and users, and between the system and the community it represents. Technology alone does not build trust. Governance, transparency, and accountability do.

52.11 Knowledgebase Architecture Lab

Purpose: This exercise helps you practice designing a knowledgebase architecture tailored to a specific community and purpose. You will define entities, attributes, relationships, vocabulary, and privacy rules.

Materials Needed:

Blank paper, whiteboard, or digital diagramming tool
Sample community scenario (use one provided below or define your own)

Sample Scenarios:

Rural Health Network: Five small towns share healthcare providers, transportation services, and referral pathways. The network wants a knowledgebase to coordinate care, track where gaps exist, and support patient navigation.
Immigrant Services Ecosystem: Fifteen organizations provide settlement, language training, employment support, and legal aid to newcomers in a mid-sized city. The ecosystem wants a shared knowledgebase to reduce duplication, improve referrals, and track unmet needs.
Indigenous Cultural Mapping: A First Nation community is documenting traditional place names, seasonal gathering sites, oral histories, and cultural protocols. The knowledgebase must respect OCAP principles and protect sensitive knowledge.

Steps:

Choose a scenario (or define your own). Write a 2–3 sentence purpose statement: What is this knowledgebase for? Who will use it?
Identify entities. List the types of things that will have entries (organizations, services, people, places, events, stories, etc.). For each entity type, note 3–5 key attributes.
Define relationships. Draw or describe how entities connect. For example: "Organization A refers to Organization B," "Service X is located at Place Y," "Story Z is told by Person P."
Establish vocabulary. Choose 5–7 top-level categories or tags. Decide whether to use controlled vocabulary, free-text tagging, or a hybrid. Document your reasoning.
Address privacy. Identify which entities or attributes are sensitive. Define access tiers (public, community-only, restricted). Specify consent requirements.
Plan for versioning. Decide how updates will be handled. Will you use timestamps only, change logs, or full versioning? Why?
Sketch a user interface. Draw a simple wireframe showing how a user would search, browse, or explore the knowledgebase.

Deliverable: A 2–3 page architecture design document including: purpose statement, entity list, relationship diagram, vocabulary decisions, privacy rules, versioning approach, and interface sketch.

Time Estimate: 90–120 minutes

Safety and Ethics Notes: If you choose a scenario involving vulnerable populations or sensitive knowledge, apply the privacy and consent principles discussed in 52.9. If you are designing for a real community, consult with community members before finalizing the architecture.

Key Takeaways

Knowledgebases outlast individual mapping projects because they provide maintained, structured infrastructure that can generate multiple outputs over time.
Good information architecture balances structure (to support search and consistency) with flexibility (to adapt to community voice and change).
Vocabulary and naming decisions are governance questions, not just UX choices — they shape whose language is centered and whose knowledge is findable.
Authoritative sources and lived sources are both necessary; provenance tracking allows users to assess credibility and navigate contradictions.
Privacy risks intensify when knowledge is concentrated in a single system; access controls, consent, and community authority are essential safeguards.
Versioning makes knowledge evolution transparent, supports error correction, and enables temporal analysis of community change.

Plain-Language Summary

A knowledgebase is like a community's long-term memory — a place where everything you learn gets stored, organized, and kept up to date so it can be used again and again. Unlike a one-time map or report, a good knowledgebase lasts. It can create many maps, answer many questions, and serve many purposes over the years.

But building one requires careful choices. What gets included? How is it organized? Who decides what words to use? What stays private and what is shared? How do you track when things change? These decisions shape whether the knowledgebase becomes a trusted resource or a confusing mess.

Good knowledgebase design respects both official sources (like government records) and community knowledge (like resident stories). It makes information easy to find, protects people's privacy, and documents where knowledge comes from so users can judge its trustworthiness. Most importantly, it is built to be maintained by the community over time, not abandoned when the people who started it move on.

End of Chapter 52.

Chapter 52. Architecting a Community Knowledgebase