# 05 — Knowledge Representation **The Curiosity Lab** Version: 0.1 Status: Working Draft Path: `/research/domains/05-Knowledge-Representation.md` --- ## 1. Purpose This document defines the fifth research domain for The Curiosity Lab: **knowledge representation**. Its purpose is to establish how the programme should represent objects, concepts, questions, narratives, relationships, evidence and curiosity journeys in a way that can support: - research traceability; - ontology design; - information architecture; - MVP experimentation; - future reasoning and recommendation; - human-facing meaning. This document is not intended to produce a final ontology. It asks: > **How should The Curiosity Lab represent knowledge so that meaningful curiosity journeys can be designed, explained, tested and revised?** --- ## 2. Current Status This is a Version 0.1 working draft. It is suitable for: - identifying candidate ontology principles; - distinguishing internal representation from user-facing information architecture; - defining provisional entities and relationships; - establishing constraints before ontology work begins; - preparing for `/architecture/Ontology.md`. It is not yet suitable for: - final ontology design; - production data modelling; - automated reasoning claims; - formal semantic web implementation; - external publication. Current confidence: **Moderate** Reason: - Knowledge representation and ontology engineering are mature fields. - Several foundational sources have been identified and partially registered. - The programme’s specific domain — curiosity-oriented information architecture — is novel enough that direct evidence is limited. - The system’s eventual technical stack has not yet been defined. - No MVP validation has tested whether represented relationships become meaningful to users. --- ## 3. Domain Question The domain question is: > **What representational structures are required to support curiosity-oriented information architecture?** Supporting questions: 1. What is a knowledge representation? 2. What is an ontology? 3. What does it mean for a representation to make commitments? 4. Which entities and relationships are required by The Curiosity Lab? 5. What must be represented internally but not necessarily shown to users? 6. How should evidence, confidence and uncertainty be represented? 7. How should narrative, interpretation and analogy be represented? 8. How should user-facing meaning differ from machine-readable structure? 9. What should be represented in the MVP, and what should be deferred? 10. What design principles follow from knowledge representation research? --- ## 4. Working Definitions --- ### 4.1 Knowledge Representation A knowledge representation is a structured way of describing some part of the world so that it can be reasoned about, communicated, stored or used. For The Curiosity Lab, knowledge representation is not merely data storage. It is the system’s model of what kinds of things matter. --- ### 4.2 Ontology An ontology is an explicit specification of the concepts and relationships in a domain. For The Curiosity Lab, an ontology should define the core entities and relationships required to represent curiosity journeys. Examples: ```text Object Question Knowledge Gap Interpretation Narrative Event Connection Analogy Evidence Confidence Doorway ``` --- ### 4.3 Entity An entity is a thing the system treats as distinct enough to represent. Examples: ```text Roman Coin Question Knowledge Gap Interpretive Frame Narrative Event Analogy ``` An entity should not be created casually. If something can be represented as an attribute, relationship or note, it may not need to be an entity. --- ### 4.4 Relationship A relationship describes how two or more entities are connected. Examples: ```text raises_question is_analogous_to supports_interpretation reveals_gap opens_doorway_to is_evidence_for ``` For The Curiosity Lab, relationships are especially important because the programme’s hypothesis depends on meaningful connection. --- ### 4.5 Attribute An attribute describes a property of an entity or relationship. Examples: ```text confidence_level source_type complexity_level relationship_label evidence_strength uncertainty_level ``` Attributes should help the system support meaning, validation or governance. --- ### 4.6 Ontological Commitment An ontological commitment is a decision that something is important enough to represent. If the system represents `KnowledgeGap`, it is committed to the idea that knowledge gaps matter. If it represents `Doorway`, it is committed to the idea that designed transitions between ideas matter. If it represents `Wonder`, it is committed to treating wonder as part of the curiosity cycle. The ontology is therefore not neutral. It expresses the programme’s theory. --- ### 4.7 User-Facing Representation A user-facing representation is how knowledge is presented to the user. Examples: ```text diagram card journey label question map timeline story path doorway ``` This may differ from the internal representation. The system may internally use entities and relationships that users never see directly. --- ## 5. Core Distinctions --- ### 5.1 Knowledge Representation vs Information Architecture Knowledge representation concerns the internal structure of knowledge. Information architecture concerns the user-facing organisation and navigation of information. They are related but not identical. ```text Knowledge Representation: What does the system know and how is it structured? Information Architecture: How does the user encounter, navigate and understand it? ``` Design implication: ```text Do not expose the ontology directly unless doing so helps the user. ``` --- ### 5.2 Ontology vs Taxonomy A taxonomy organises things into categories. An ontology represents entities, relationships, attributes, constraints and sometimes rules. Example taxonomy: ```text Artefacts Coins Tools Ceramics ``` Example ontology: ```text Coin issued_by Authority Coin made_from Material Coin found_in Place Coin raises_question Question Coin opens_doorway_to TradeNetwork ``` Design implication: ```text The Curiosity Lab requires relationships, not only categories. ``` --- ### 5.3 Graph vs Meaning A graph is a structure of nodes and edges. Meaning is not automatically produced by connecting nodes. A connection becomes meaningful only when the user can understand why it matters. Design implication: ```text Every exposed relationship should have a human-readable explanation. ``` --- ### 5.4 Representation vs Reality A representation is a simplification. It selects what matters and omits what does not. No ontology captures the world fully. Design implication: ```text Representations should include confidence, evidence and known limitations. ``` --- ### 5.5 Internal Model vs Research Model The research model may include broad ideas such as curiosity, wonder and meaning. The implementation model may need simpler operational structures. Example: ```text Research model: Wonder Possible implementation model: post-journey reflection new question return to observation self-reported surprise ``` Design implication: ```text Abstract research concepts need operational proxies before MVP use. ``` --- ### 5.6 Formal Semantics vs Practical MVP Formal ontology languages such as RDF and OWL may eventually be useful. However, early MVP work should not begin with heavy formalisation unless it directly supports learning. Design implication: ```text Start with a clear conceptual ontology before choosing formal tooling. ``` --- ## 6. Major Theoretical Strands --- ## 6.1 Knowledge Representation as Surrogate, Commitment and Reasoning Medium Davis, Shrobe and Szolovits describe knowledge representation as more than notation. Their account identifies multiple roles for a representation, including: ```text a surrogate for the world a set of ontological commitments a fragmentary theory of intelligent reasoning a medium for efficient computation a medium of human expression ``` This is one of the most important ideas for The Curiosity Lab. It means that the ontology is not just an implementation detail. It shapes what the system can notice, explain, connect and test. ### Implication for The Curiosity Lab If the system represents `Question`, `KnowledgeGap`, `Analogy`, `Interpretation` and `Doorway`, it becomes possible to design around those concepts. If it does not represent them, they remain hidden inside prose. ### Design principle > **A representation is a commitment to what the system can notice, reason about and express.** ### Architecture implication Potential ontology requirements: ```text Entity Relationship Attribute Evidence Confidence Interpretation User-Facing Label Reasoning Purpose ``` ### MVP implication The MVP should represent at least a minimal set of curiosity-specific entities rather than only articles and tags. ### Confidence High for the general knowledge representation principle. Moderate for the specific curiosity-domain translation. --- ## 6.2 Ontology as Explicit Specification of a Conceptualisation Gruber’s definition of ontology as an explicit specification of a conceptualisation is foundational. It matters because The Curiosity Lab is developing a conceptual model of curiosity, meaning, connection and interpretation. The ontology should make this model explicit enough to critique. A hidden conceptualisation is dangerous. It allows architecture to evolve without research governance. ### Implication for The Curiosity Lab The ontology should not simply emerge from implementation convenience. It should be explicitly linked to research. Each candidate entity should answer: ```text What does this represent? Why does this matter? What evidence supports it? What user experience does it enable? What experiment could test it? ``` ### Design principle > **The ontology should make the programme’s conceptual assumptions explicit and reviewable.** ### Architecture implication The ontology should include commentary or metadata for each entity: ```text definition rationale source confidence status examples related experiments ``` ### MVP implication Before implementing the ontology in code, create a human-readable ontology document. ### Confidence High for the ontology principle. Moderate for how much formal ontology is needed in the MVP. --- ## 6.3 Ontology Engineering and Competency Questions Ontology engineering methods often begin by defining scope and competency questions. A competency question is a question the ontology should be able to answer. For The Curiosity Lab, this is essential. Without competency questions, the ontology may grow by enthusiasm rather than need. Example competency questions: ```text What questions does this object raise? What wider systems does this object connect to? Which interpretation is supported by which evidence? What kind of relationship connects these two concepts? Which pathways support surface-to-structure movement? Which connections are analogies rather than causal links? What evidence supports this doorway? ``` ### Implication for The Curiosity Lab Every ontology entity should help answer at least one competency question. ### Design principle > **Ontology design should be driven by questions the system must answer.** ### Architecture implication The first ontology document should include competency questions before entity lists. ### MVP implication The MVP should implement only the subset of the ontology required to answer first-cycle experiment questions. ### Confidence Moderate to High. The method is well established, but scope must remain controlled. --- ## 6.4 Representation for Human Meaning, Not Only Machine Processing Knowledge representation often focuses on machine reasoning. The Curiosity Lab has an additional requirement: ```text The representation must support human meaning. ``` A relationship may be technically valid but meaningless to the user. Example: ```text Coin related_to Empire ``` This is weak. A stronger representation includes: ```text Coin opens_doorway_to ImperialAuthority because coin imagery carried authority across distance supported_by Source confidence Moderate ``` ### Implication for The Curiosity Lab Relationships should carry explanatory metadata. A user-facing connection should answer: ```text Why are these connected? Why should I care? What question does this open? ``` ### Design principle > **A relationship is not meaningful until it can be explained.** ### Architecture implication Relationships need attributes: ```text relationship_type user_label explanation evidence_source confidence_level curiosity_value complexity_level ``` ### MVP implication Test whether relationship explanations improve curiosity and understanding compared with bare links. ### Confidence Moderate. Strong programme relevance; direct evidence requires MVP validation. --- ## 6.5 RDF, Triples and Graph Representation RDF represents information through subject-predicate-object triples. Example: ```text RomanCoin issued_by Emperor RomanCoin made_from Silver RomanCoin found_in Britain ``` This model is relevant because The Curiosity Lab is likely to require graph-like representation. However, RDF-style triples are not automatically sufficient for curiosity-oriented meaning. The relationship must be semantically useful and interpretively clear. ### Implication for The Curiosity Lab A graph structure may be appropriate, but it should not be exposed prematurely as a full user interface. The first requirement is a meaningful relationship model. ### Design principle > **Use graph structures to support traversal, but use interpretation to make traversal meaningful.** ### Architecture implication Potential technical representation: ```text Entity — Relationship — Entity Relationship has Label Relationship has Evidence Relationship has Confidence Relationship has User Explanation ``` ### MVP implication Begin with a small manually curated graph before automating graph generation. ### Confidence Moderate. RDF and graph structures are appropriate candidates, but tooling should not drive the research. --- ## 6.6 OWL and Formal Ontology OWL provides a formal ontology language for the Semantic Web. It supports classes, properties, individuals and reasoning. This may eventually be useful for The Curiosity Lab, especially if the ontology becomes large, shared or reasoning-heavy. However, OWL may be unnecessary for the first MVP. The early need is conceptual clarity. ### Implication for The Curiosity Lab Do not begin with OWL unless the project has a reasoning need that simpler models cannot satisfy. Potential future uses: ```text class hierarchy relationship constraints inference consistency checking semantic interoperability ``` ### Design principle > **Formalise only after the conceptual model is stable enough to deserve formalisation.** ### Architecture implication The ontology should start as a human-readable conceptual model, then later map to formal representations if needed. ### MVP implication Use simple JSON / graph structures initially, unless formal reasoning becomes necessary. ### Confidence Moderate. OWL is relevant but probably not an immediate implementation priority. --- ## 6.7 Concept Maps and User-Facing Representation Concept maps make knowledge relationships visible through nodes and labelled links. They are relevant because The Curiosity Lab cares about visible connection. However, concept maps are not the same as ontologies. A concept map may be user-facing, selective and explanatory. An ontology may be internal, formal and systematic. ### Implication for The Curiosity Lab The project should distinguish: ```text Internal ontology: complete enough for reasoning and traceability. User-facing map: small enough to support orientation and curiosity. ``` ### Design principle > **User-facing maps should reveal useful structure, not the whole ontology.** ### Architecture implication Create separate artefacts: ```text Ontology.md Pattern-Catalogue.md Experience-Patterns.md User-facing diagrams ``` ### MVP implication Test small maps or pathway diagrams before exposing larger graphs. ### Confidence Moderate. --- ## 6.8 Evidence, Confidence and Provenance The Curiosity Lab’s ontology must represent not only claims but also their evidence status. This is because the programme has already committed to distinguishing: ```text Established Evidence Supported Interpretation Working Hypothesis Design Decision Speculation ``` If the system cannot represent evidence and confidence, it may present weak relationships as strong ones. ### Implication for The Curiosity Lab Every major relationship should be able to point to: ```text source evidence category confidence level interpretation note research debt ``` ### Design principle > **Represent uncertainty as part of the knowledge model, not as an afterthought.** ### Architecture implication Potential entities: ```text Source Evidence Claim ConfidenceLevel ResearchDebt InterpretationNote ``` Potential relationships: ```text supports weakens contradicts requires_review ``` ### MVP implication User-facing uncertainty may be shown selectively, for example: ```text Well supported Interpretation Open question Speculative connection ``` ### Confidence High as a governance requirement. Moderate for exact implementation. --- ## 6.9 Narrative, Interpretation and Analogy as Representable Structures Previous domain papers introduced narrative, museum interpretation and analogy. Knowledge representation must now ask whether these are representable. Narrative may require: ```text Event Actor Sequence Cause Consequence Tension Resolution ``` Interpretation may require: ```text Object Evidence Claim Frame Perspective Context Uncertainty ``` Analogy may require: ```text Base Domain Target Domain Shared Structure Mapped Relationship Difference ``` ### Implication for The Curiosity Lab These should not remain only writing techniques. They should become representable structures where useful. ### Design principle > **If narrative, interpretation or analogy drives curiosity, it should be represented explicitly enough to test.** ### Architecture implication The ontology may need modules: ```text Curiosity module Object / interpretation module Narrative module Analogy module Evidence module Journey module ``` ### MVP implication The first MVP should implement only the modules needed for initial experiments. ### Confidence Moderate. --- ## 6.10 Representation Trade-Offs Every representation makes some things easier and others harder. A highly formal ontology may support reasoning but slow iteration. A simple tag model may be easy to build but too weak for meaningful curiosity. A graph may support exploration but increase complexity. A narrative path may support coherence but reduce open exploration. ### Implication for The Curiosity Lab The project must select representations according to research needs. There is no neutral best model. ### Design principle > **Choose the simplest representation that preserves the relationship needed for curiosity, meaning and validation.** ### Architecture implication Start with a layered model: ```text Content layer Entity layer Relationship layer Evidence layer Experience layer Experiment layer ``` ### MVP implication Implement a minimum viable ontology, not a complete ontology. ### Confidence High as an engineering and research discipline. --- ## 7. Working Model: Representation as Curiosity Infrastructure The current working model is: ```text Object / Concept ↓ Entity ↓ Relationship ↓ Evidence and Confidence ↓ Interpretive Label ↓ Doorway ↓ Curiosity Journey ↓ Validation Result ``` This model says that curiosity journeys require more than content. They require represented relationships with enough evidence, explanation and structure to support meaningful movement. --- ## 8. Relationship to the Curiosity Cycle The Curiosity Cycle is: ```text Observation ↓ Curiosity ↓ Connection ↓ Understanding ↓ Wonder ↓ Renewed Observation ``` Knowledge representation contributes infrastructure for each step. | Cycle Stage | Representation Need | |---|---| | Observation | Object, detail, context, attention cue | | Curiosity | question, knowledge gap, curiosity trigger | | Connection | relationship, analogy, narrative link, context link | | Understanding | explanation, pattern, model update, interpretation | | Wonder | reflection, open question, next doorway | | Renewed Observation | re-entry point, changed perspective, new observation prompt | --- ## 9. Design Principles The following principles are provisional. --- ### KR-001 — Representation is commitment Every entity and relationship expresses a decision about what matters. --- ### KR-002 — Represent relationships explicitly The programme’s hypothesis depends on meaningful connection, so relationships must be first-class structures. --- ### KR-003 — Do not expose the whole ontology to users Internal representation and user-facing experience should remain distinct. --- ### KR-004 — Every exposed relationship needs a human explanation A connection is not meaningful merely because it exists in a graph. --- ### KR-005 — Represent evidence and confidence The system must distinguish established evidence, supported interpretation, hypothesis and speculation. --- ### KR-006 — Start with competency questions Ontology design should begin with the questions the system must answer. --- ### KR-007 — Formalise late Formal semantic tools should be adopted only when the conceptual model and reasoning needs justify them. --- ### KR-008 — Keep the MVP ontology small The first ontology should support the first experiments, not the entire research programme. --- ### KR-009 — Represent uncertainty honestly Unknowns, contradictions and contested interpretations should not be hidden. --- ### KR-010 — Preserve human meaning Machine-readable structure is insufficient unless it supports human curiosity, interpretation and understanding. --- ## 10. Proposed Layered Representation Model A first conceptual architecture may use the following layers. --- ### 10.1 Content Layer Represents raw or authored material. ```text Article Image Object Description Story Source Extract Quote Note ``` --- ### 10.2 Entity Layer Represents things the system can reason about. ```text Object Concept Person Place Event Question KnowledgeGap Interpretation Analogy Pattern ``` --- ### 10.3 Relationship Layer Represents meaningful connections. ```text raises_question opens_doorway_to is_evidence_for is_analogous_to causes contrasts_with supports_interpretation reveals_pattern ``` --- ### 10.4 Evidence Layer Represents source grounding. ```text Source Citation EvidenceCategory ConfidenceLevel ResearchDebt Contradiction ``` --- ### 10.5 Experience Layer Represents user-facing journey structures. ```text Doorway Prompt Path Waypoint Reflection MapSegment NarrativeThread ``` --- ### 10.6 Experiment Layer Represents validation. ```text Experiment Hypothesis Variant BehaviourSignal Outcome ValidationResult ``` --- ## 11. Initial Competency Questions The ontology should eventually answer questions such as: ### Object and Interpretation ```text What questions does this object raise? Which details should the user notice? What interpretations are supported by evidence? What wider systems does this object open? ``` ### Curiosity ```text What knowledge gap does this doorway reveal? What kind of curiosity trigger is this? What follow-up questions are available? ``` ### Knowledge and Meaning ```text What prior knowledge anchor can introduce this concept? What deeper structure does this surface feature reveal? What pattern can transfer to another domain? ``` ### Narrative ```text What event does this object participate in? What tension or consequence gives this story meaning? What unresolved question remains? ``` ### Analogy and Patterns ```text What two domains share a structure? What is mapped between them? Where does the analogy fail? ``` ### Evidence and Governance ```text What source supports this relationship? What confidence level does it have? Is this evidence, interpretation, hypothesis or speculation? What research debt remains? ``` ### MVP ```text Which experiment tests this relationship? What behaviour would support the hypothesis? What result would weaken it? ``` --- ## 12. Candidate Ontology Modules --- ### 12.1 Curiosity Module Candidate entities: ```text Observation Question KnowledgeGap CuriosityTrigger CuriosityType Doorway Reflection Wonder ``` Candidate relationships: ```text raises_question reveals_gap opens_doorway_to invites_reflection renews_observation ``` --- ### 12.2 Object and Interpretation Module Candidate entities: ```text Object ObjectDetail Interpretation InterpretiveFrame Evidence Claim Context Perspective ``` Candidate relationships: ```text has_detail interpreted_through supported_by contextualises contested_by ``` --- ### 12.3 Narrative Module Candidate entities: ```text Narrative Event Actor Place Time Cause Consequence Tension Resolution ``` Candidate relationships: ```text involves occurs_in causes leads_to creates_tension partially_resolves ``` --- ### 12.4 Analogy and Pattern Module Candidate entities: ```text Analogy BaseDomain TargetDomain SharedStructure Pattern TransferPath Difference ``` Candidate relationships: ```text maps_to shares_structure_with supports_transfer differs_from reveals_pattern ``` --- ### 12.5 Evidence Module Candidate entities: ```text Source Citation Evidence Claim ConfidenceLevel EvidenceCategory ResearchDebt Contradiction ``` Candidate relationships: ```text supports weakens contradicts requires_review ``` --- ### 12.6 Experience Module Candidate entities: ```text Journey Path Waypoint Prompt Doorway MapSegment UserChoice Reflection ``` Candidate relationships: ```text contains branches_to guides_to prompts records_reflection ``` --- ### 12.7 Experiment Module Candidate entities: ```text Experiment ResearchQuestion Hypothesis Variant Metric BehaviourSignal ValidationResult ``` Candidate relationships: ```text tests measures supports weakens validates ``` --- ## 13. MVP Implications The MVP should not implement the whole ontology. It should implement the smallest subset required to test the first research claims. --- ### MVP Ontology v0.1 — Minimum Candidate ```text Object Question KnowledgeGap Doorway Concept Relationship Source ConfidenceLevel Prompt Journey Reflection Experiment ``` Minimum relationships: ```text Object raises_question Question Question reveals_gap KnowledgeGap Object opens_doorway_to Concept Concept connects_to Concept Relationship supported_by Source Doorway has_confidence ConfidenceLevel Prompt invites Reflection Experiment tests Hypothesis ``` This is intentionally small. --- ### EXP-KR-001 — Bare Link vs Explained Relationship Research question: > Does a relationship explanation improve curiosity and understanding compared with a bare link? Variants: ```text A: Related link B: Relationship label C: Relationship label + explanation + evidence cue ``` Measures: - click-through; - relationship comprehension; - explanation quality; - trust; - continuation. --- ### EXP-KR-002 — Internal Graph vs Guided Doorways Research question: > Does a curated set of doorways outperform exposure to a larger graph? Variants: ```text A: many visible connected nodes B: three curated labelled doorways ``` Measures: - perceived overload; - continuation; - confidence; - relationship recall; - explanation quality. --- ### EXP-KR-003 — Evidence Cue Research question: > Does showing evidence/confidence cues improve trust without reducing curiosity? Variants: ```text A: no evidence cue B: simple confidence cue C: confidence cue + source type ``` Measures: - trust; - curiosity; - perceived credibility; - continuation; - confusion. --- ### EXP-KR-004 — Question as Entity Research question: > Does structuring a journey around an explicit question improve exploration compared with topic-based navigation? Variants: ```text A: topic card B: question card ``` Measures: - continuation; - generated follow-up questions; - recall; - perceived purpose; - explanation quality. --- ## 14. Measurement Candidates Knowledge representation itself is not directly visible to users. Its success must be measured through experience outcomes. Possible indicators: ```text users understand why two things are connected users can explain a relationship users trust the distinction between evidence and interpretation users choose meaningful doorways users are not overwhelmed by graph complexity users generate deeper questions users can transfer a pattern to another example ``` Possible system indicators: ```text every exposed relationship has a type every exposed relationship has a label every exposed relationship has a source or rationale every speculative connection is marked every MVP experiment maps to a hypothesis ``` --- ## 15. Implications for The Curiosity Lab Hypothesis Current hypothesis: > **Meaningful curiosity emerges when knowledge is experienced as an interconnected network rather than as isolated information.** Knowledge representation refines this hypothesis. A better version is: > **Meaningful curiosity may emerge when relationships between knowledge elements are represented explicitly enough to be explained, explored, trusted and tested.** This refinement matters because it avoids a weak graph assumption. The issue is not simply: ```text Are things connected? ``` The issue is: ```text Are the connections meaningful? Are they evidenced? Are they understandable? Do they support curiosity? Can they be tested? ``` Current confidence: **Moderate** --- ## 16. Known Weaknesses This document has the following weaknesses: 1. It is conceptually strong but not yet implementation-specific. 2. It risks over-formalising early research. 3. It relies on knowledge representation literature that may not directly address user curiosity. 4. It does not yet define a final ontology schema. 5. It does not yet decide between JSON, graph database, RDF, OWL or other tooling. 6. It does not yet include enough sources on knowledge graphs and semantic web practice. 7. It does not yet include enough sources on uncertainty representation. 8. It does not yet resolve how much representation should be visible to users. 9. It may overstate the value of explicit relationships without MVP validation. 10. It does not yet address maintenance and governance of the ontology. --- ## 17. Contradictions and Cautions --- ### 17.1 Representation can overfit theory If the ontology is built too early, it may encode premature assumptions. --- ### 17.2 A graph is not a user experience A graph may support the system but overwhelm users. --- ### 17.3 Not everything should become an entity Entity proliferation creates complexity and weakens clarity. --- ### 17.4 Formal semantics can slow learning OWL or similar tooling may be useful later, but premature formalisation may reduce iteration speed. --- ### 17.5 Representation choices are political and epistemic What the system represents becomes what it can value. This requires governance. --- ### 17.6 Internal precision does not guarantee external meaning A technically correct relationship may still fail to help the user understand. --- ## 18. Research Debt | ID | Debt | Priority | Status | |---|---|---:|---| | RD-KR-001 | Register Davis, Shrobe & Szolovits as a full Research Register entry. | High | Open | | RD-KR-002 | Register Gruber on ontology specification. | High | Open | | RD-KR-003 | Register Uschold & Grüninger on ontology principles. | Medium | Open | | RD-KR-004 | Register Noy & McGuinness on ontology development. | High | Open | | RD-KR-005 | Register W3C RDF 1.1 Concepts. | Medium | Open | | RD-KR-006 | Register W3C OWL 2 Overview / Primer. | Medium | Open | | RD-KR-007 | Add sources on knowledge graphs. | High | Open | | RD-KR-008 | Add sources on uncertainty and provenance. | High | Open | | RD-KR-009 | Define first competency questions for Ontology.md. | High | Open | | RD-KR-010 | Define MVP ontology v0.1. | High | Open | | RD-KR-011 | Decide whether formal ontology tooling is needed before MVP. | Medium | Open | | RD-KR-012 | Separate user-facing maps from internal ontology diagrams. | High | Open | | RD-KR-013 | Define relationship label taxonomy. | High | Open | | RD-KR-014 | Define evidence/confidence metadata model. | High | Open | --- ## 19. Register Entries to Create or Expand Minimum entries: ```text RR-KR-0001 — Davis, Shrobe & Szolovits (1993), What Is a Knowledge Representation? RR-KR-0002 — Gruber (1993), A Translation Approach to Portable Ontology Specifications RR-KR-0003 — Uschold & Grüninger (1996), Ontologies: Principles, Methods and Applications RR-KR-0004 — Studer, Benjamins & Fensel (1998), Knowledge Engineering: Principles and Methods RR-KR-0005 — Noy & McGuinness (2001), Ontology Development 101 RR-KR-0006 — W3C RDF 1.1 Concepts and Abstract Syntax RR-KR-0007 — W3C OWL 2 Web Ontology Language Overview / Primer RR-KR-0008 — Novak & Cañas (2008), Concept Maps ``` --- ## 20. Immediate Architecture Promotions The following items should be considered for `/architecture/Ontology.md`. ### Candidate Entities ```text Entity Relationship Attribute Source Evidence Claim ConfidenceLevel EvidenceCategory KnowledgeGap Question Doorway Interpretation Analogy Pattern Journey Prompt Reflection Experiment ValidationResult ``` ### Candidate Relationships ```text represents commits_to raises_question reveals_gap opens_doorway_to connects_to is_analogous_to supports_interpretation supported_by weakens contradicts tests validates ``` ### Candidate Attributes ```text definition status confidence_level evidence_category source_reference user_label user_explanation relationship_type complexity_level visibility research_debt ``` Status: **Provisional** --- ## 21. Immediate Pattern Promotions The following items should be considered for `/architecture/Pattern-Catalogue.md`. ```text Representation as Commitment Relationship as First-Class Object Evidence-Aware Connection Human-Readable Relationship Ontology Hidden, Meaning Visible Competency Question First Minimum Viable Ontology Formalise Late Graph Supports, Doorway Guides ``` Status: **Emerging** --- ## 22. Immediate MVP Promotions The following items should be considered for `/mvp/Experiments.md`. ```text EXP-KR-001 — Bare Link vs Explained Relationship EXP-KR-002 — Internal Graph vs Guided Doorways EXP-KR-003 — Evidence Cue EXP-KR-004 — Question as Entity ``` Status: **Candidate** --- ## 23. Relationship to Previous Domain Papers --- ### Relationship to 01-Curiosity.md Curiosity requires representation of: ```text Question KnowledgeGap CuriosityTrigger Doorway Reflection ``` Without these, curiosity remains only a prose concept. --- ### Relationship to 02-Knowledge-and-Meaning.md Meaning requires representation of: ```text Concept Relationship Explanation PriorKnowledgeAnchor TransferPath Pattern ``` --- ### Relationship to 03-Narrative.md Narrative requires representation of: ```text Event Actor Cause Consequence Tension Resolution NarrativeThread ``` --- ### Relationship to 04-Museum-Interpretation.md Museum interpretation requires representation of: ```text Object ObjectDetail InterpretiveFrame Evidence Claim Context Perspective ``` --- ## 24. Provisional Conclusion Knowledge representation is the point at which The Curiosity Lab’s ideas become explicit commitments. The strongest conclusion of this document is: > **The Curiosity Lab should represent relationships, evidence, confidence and interpretive purpose as first-class structures, because curiosity-oriented information architecture depends on meaningful, explainable and testable connections.** The key warning is: > **A graph is not enough.** A graph may show that things are connected. The Curiosity Lab must show why the connection matters. A useful representation must support: ```text meaning curiosity explanation evidence uncertainty journey design validation ``` Current confidence: **Moderate** --- ## 25. References Brachman, R. J., & Levesque, H. J. (2004). *Knowledge Representation and Reasoning*. Morgan Kaufmann. Davis, R., Shrobe, H., & Szolovits, P. (1993). What is a knowledge representation? *AI Magazine*, 14(1), 17–33. https://doi.org/10.1609/aimag.v14i1.1029 Gruber, T. R. (1993). A translation approach to portable ontology specifications. *Knowledge Acquisition*, 5(2), 199–220. https://doi.org/10.1006/knac.1993.1008 Noy, N. F., & McGuinness, D. L. (2001). *Ontology Development 101: A Guide to Creating Your First Ontology*. Stanford Knowledge Systems Laboratory Technical Report KSL-01-05. Novak, J. D., & Cañas, A. J. (2008). *The Theory Underlying Concept Maps and How to Construct and Use Them*. Florida Institute for Human and Machine Cognition. Studer, R., Benjamins, V. R., & Fensel, D. (1998). Knowledge engineering: Principles and methods. *Data & Knowledge Engineering*, 25(1–2), 161–197. https://doi.org/10.1016/S0169-023X(97)00056-6 Uschold, M., & Grüninger, M. (1996). Ontologies: Principles, methods and applications. *The Knowledge Engineering Review*, 11(2), 93–136. https://doi.org/10.1017/S0269888900007797 W3C. (2014). *RDF 1.1 Concepts and Abstract Syntax*. W3C Recommendation. https://www.w3.org/TR/rdf11-concepts/ W3C. (2012). *OWL 2 Web Ontology Language Document Overview*. W3C Recommendation. https://www.w3.org/TR/owl2-overview/ W3C. (2012). *OWL 2 Web Ontology Language Primer*. W3C Recommendation. https://www.w3.org/TR/owl2-primer/ --- ## 26. Next Action Do not build the full ontology next. The stronger order is: ```text /research/domains/06-Information-Architecture.md then /architecture/Ontology.md ``` Reason: The ontology should be informed by both the knowledge representation requirements and the user-facing information architecture requirements. After `06-Information-Architecture.md`, the programme should be ready to produce: ```text /architecture/Ontology.md /architecture/Pattern-Catalogue.md ```