Web-Didaktik Ontology
The Web-Didaktik is a formal ontology for knowledge organization created by Prof. Dr. Norbert Meder (University of Bielefeld, 2006). It defines three dimensions for classifying any piece of knowledge: what kind of knowledge it is, how it relates to other knowledge, and how it is presented. ORQO implements all three dimensions.
Dimension 1: Knowledge Types
Every piece of content is classified into one of four base classes, each subdivided into specific types. The base class captures the epistemological function — not the topic, but what role the content plays in understanding.
Orientation
Function: Helps the learner perceive and navigate a domain. Orientation knowledge creates awareness without yet enabling specific actions.
| Type | Description | Example |
|---|---|---|
| History | Historical events providing metacognitive context | "The TCP/IP protocol was developed in the 1970s by DARPA..." |
| Scenario | Event complexes from reality or realistic constructs | "Consider a distributed system where three nodes must reach consensus..." |
| Hypothetical | Assumed, unproven states | "Suppose the database goes down during a write operation..." |
| StoryProblem | Scenario presented in narrative form | "Alice runs a web shop. One day her payment gateway starts rejecting..." |
| VirtualWorld | 3D/spatial representations for exploration | Interactive simulations, virtual labs |
| Facts | Objective data and measurements | "PostgreSQL 16 supports up to 32 TB per table" |
| Summary | Brief presentation of expanded material | "In summary, the three consensus algorithms differ in..." |
| Overview | Broad outline of sequences or structures | "This chapter covers: authentication, authorization, and session management" |
| Problem | Identifies issues related to the topic | "The challenge with eventual consistency is that reads may return stale data" |
| DidacticalGoal | Formulates learning objectives | "After this section, you will be able to configure a load balancer" |
Explanation
Function: Provides reasons, arguments, and understanding. Explanation knowledge answers why things are the way they are and what things mean.
Why-Explanations — answering "why":
| Type | Description | Example |
|---|---|---|
| Conclusion | Derivation from premises | "Since all requests go through the gateway, and the gateway logs all traffic, therefore all traffic is logged" |
| Evidence | Chain of conclusions forming proof | Mathematical proofs, formal derivations |
| Causal | Cause-effect relationships | "The outage was caused by a memory leak in the connection pool" |
| History | Events as temporal consequences | "The language evolved from C to C++ because developers needed object orientation" |
| FinalCause | Justifying means to ends | "We use caching to reduce database load" |
What-Explanations — answering "what":
| Type | Description | Example |
|---|---|---|
| Theorem | Logical assertions about facts | "CAP theorem: a distributed system cannot simultaneously provide consistency, availability, and partition tolerance" |
| Description | Representation without derivation | "A load balancer distributes incoming traffic across multiple servers" |
| Definition:Mathematical | Formal mathematical determination | "Let f: A → B be a bijective function..." |
| Definition:Term | Determination of essential characteristics | "An API gateway is a server that acts as the single entry point for a group of microservices" |
| Interpretation | Decoding documents or situations | "The error message 'ECONNREFUSED' means the target machine actively refused the connection" |
Other Explanation types: Case (Example, Counterexample), Argumentation, Assumption (Hypothesis, Idea), Reflection.
Action
Function: Knowledge about human actions, practices, and procedures — the "knowing how."
| Type | Description | Example |
|---|---|---|
| Rule:Individual | Norms for individual action | "Always validate user input before processing" |
| Rule:Cooperative | Norms for cooperative action | "All PRs require at least one review before merge" |
| Procedure:Administrative | Administrative procedures | "To request access: submit form A, wait for approval, then..." |
| Procedure:InstructionManual | Equipment/tool operation steps | "Step 1: Install the CLI. Step 2: Run init. Step 3: Configure..." |
| Procedure:SocialNorm | Social behavior regulations | "During code review, critique the code, not the person" |
| Checklist | Reminder lists for critical factors | "Pre-deploy checklist: tests pass, migrations run, env vars set..." |
| Principle | Basic propositions governing rules | "Separation of concerns: each module should have one responsibility" |
| Strategy | Purpose-rational alternative actions | "For high-availability, deploy across multiple regions with failover" |
| Law | Codified legal knowledge | GDPR articles, licensing terms |
| Example | Practical instantiation of action knowledge | "Here's how to implement the retry pattern in Python..." |
Reference
Function: Points to where information lives — the "knowing where."
| Type | Description | Example |
|---|---|---|
| Document:Statistics | Numerical data summaries | Performance benchmarks, usage reports |
| Document:Report | Bibliographic information of reports | Research papers, audit reports |
| Document:Protocol | Formal meeting summaries | RFC documents, standards specifications |
| Document:EncyclopediaEntry | Encyclopedia articles | Wikipedia-style overviews |
| Document:Handbook | Subject-specific reference works | API reference documentation |
| Communication | Communication materials | Email threads, chat transcripts |
| CrossReference:Annex | Supplementary materials | Appendices, attached datasets |
| CrossReference:Glossary | Indexed word explanations | Term glossaries, acronym lists |
Dimension 2: Relations
Knowledge units don't exist in isolation. The Web-Didaktik defines 48 typed relations (25 canonical types with inverses) that capture how knowledge connects. These relations are what enable structured navigation.
Hierarchical Relations
Relations that express scope, generalization, and decomposition:
| Relation | Inverse | Meaning |
|---|---|---|
Generalizes | Specializes | A is a more general form of B |
PartOf | WholeOf | A is part of the whole B |
ComponentOf | ComponentWholeOf | A is a component within B |
SubProcessOf | ParentProcessOf | A is a sub-process of B |
AspectOf | AspectWholeOf | A is one aspect of the broader B |
Associative Relations (Asymmetric)
Relations with a clear directionality:
| Relation | Inverse | Meaning |
|---|---|---|
BasisFor | UnderpinnedBy | A is the logical foundation for B |
CauseOf | EffectOf | A causes B |
PurposeOf | MeansOf | A is the purpose that B serves |
ContextOf | ContextualizedBy | A frames the context for B |
TimelineBefore | TimelineAfter | A precedes B in time |
ProcessOf | ProcessedBy | A is a process applied to B |
EvaluationOf | EvaluatedBy | A evaluates B |
FunctionOf | FunctionallyDeterminedBy | A is a function of B |
Associative Relations (Symmetric)
Relations where direction doesn't matter:
| Relation | Meaning |
|---|---|
Similar | A and B share significant characteristics |
Alternative | A and B are interchangeable options |
Analogous | A and B share structural parallels in different domains |
Opposite | A and B are in opposition or contrast |
Complementary | A and B complete each other |
Affine | A and B frequently co-occur |
Didactic Relations
Relations specific to learning sequences:
| Relation | Inverse | Meaning |
|---|---|---|
DidacticallyBefore | DidacticallyAfter | A should be learned before B |
BelongsTo | — | A belongs to concept container B |
FormOf | MaterialOf | A is the form of content B |
Dimension 3: Media Types
The third dimension classifies how knowledge is presented, not what it says:
| Category | Types |
|---|---|
| Presentation | Text, Table, Diagram, Image, Video, Audio, Formula |
| Interaction | Simulation, Exercise, Quiz, InteractiveScenario |
| Communication | DiscussionPrompt, GroupTask, PeerReview, Tutoring |
Navigation Directions
The typed relations enable 11 navigation directions — structured ways agents can traverse the knowledge graph:
| Direction | What it follows | Use case |
|---|---|---|
| deeper | Specializes, PartOf, ComponentOf, SubProcessOf, AspectOf | "Tell me more detail about this" |
| broader | Generalizes, WholeOf, ComponentWholeOf, ParentProcessOf | "What's the bigger picture?" |
| why | EffectOf, UnderpinnedBy, DeterminedBy | "Why is this the case?" |
| consequences | CauseOf, BasisFor, Determines | "What follows from this?" |
| context | ContextOf, ContextualizedBy | "What's the surrounding context?" |
| related | Similar, Alternative, Analogous, Complementary, Affine | "What's related to this?" |
| next | DidacticallyBefore, TimelineBefore | "What comes after this?" |
| previous | DidacticallyAfter, TimelineAfter | "What came before this?" |
| examples | Units of type Explanation:Case:Example or Action:Example | "Show me a concrete example" |
| how | Units of type Action (any subtype) | "How do I actually do this?" |
| sources | Units of type Reference (any subtype) | "Where can I read more?" |
This is what makes the Knowledge Engine fundamentally different from RAG. A standard retrieval system can only answer "what's similar?" — ORQO's agents can ask "go deeper," "why?", "show me how," or "what's the broader context?" and follow typed edges to precisely the right knowledge.
The INTUITEL EU FP7 project (2014) demonstrated that just four of these relation types were sufficient for multiple distinct learning paths to emerge from a single knowledge domain. ORQO implements the full taxonomy of 48 relation types.