Knowledge Engineering - Chapter 3: Knowledge Modeling Part Two

KM Methodologies Part Two

Overview of MASK Method

MASK (Method for Analysing and Structuring Knowledge) is a method designed to analyze, formalize, and structure an organization’s knowledge. It focuses on viewing knowledge as a distinct system, rather than just information or documents. MASK uses multiple models (or “lenses”) to capture different perspectives of that knowledge.

Importance of MASK

• Helps make tacit (expert) knowledge explicit, which aids in training, decision-making, and innovation.

• Provides a structured approach for understanding the “what,” “how,” and “why” of organizational know-how.

• Facilitates knowledge sharing and avoids loss of expertise when employees change roles or retire.

Axioms of MASK

• Axiom 1: Knowledge as a System
  Knowledge is distinct from information/documents; it interacts with but is independent of organizational subsystems (operations, IT, HR).

• Axiom 2: Macroscope Structure Analyze knowledge through:

  • Semiotic layers: Information (data), Meaning (interpretation), Context (environment).

  • Systemic views: Structure (components), Function (processes), Evolution (history).

Key Principles of MASK

1. Knowledge System: Knowledge in an organization is its own system, distinct from information systems or document systems.

2. Knowledge Macroscope: Any knowledge can be analyzed through its information, meaning, and context, combined with views of structure, function, and evolution.

3. Multiple Models: A single model is insufficient; MASK employs several (e.g., Activity, Phenomenon, Concept, Task, etc.).

4. Knowledge Book: Integrates all the resulting models and reference sheets, partially capturing and structuring a knowledge domain.

Seven Core Models in MASK

1. Reference System (Système de Référence)

2. Phenomenon Model (Modèle de Phénomène)

3. Activity Model (Modèle d’Activité)

4. Concept Model (Modèle de Concept)

5. Task Model (Modèle de Tâche)

6. History Model (Modèle d’Historique)

7. Lineage Model (Modèle de Lignée)

Model 1: Reference System

• Purpose: Define the scope of the knowledge to be analyzed (which domain or area of expertise).

• Identify the main inputs (resources or data), outputs (results or products), objectives, and the people/systems that hold or use the knowledge.

• Key Ideas for Beginners: Picture a boundary around your chosen process or activity, showing what goes in and what comes out.

• Everyone or everything that provides or consumes knowledge within that boundary is part of the system.

• Clarify goals or final purposes, so you know exactly why you are capturing the knowledge.

Model 2: Phenomenon Model

• Purpose: Identify and describe the significant phenomena (physical, chemical, social, or other) that the organization must understand or control in its processes.

• Clarify how these phenomena originate, how they propagate (flux), and what factors influence them.

• Key Elements:

  • Source System: The entity or environment where the phenomenon begins.

  • Flux: The energy, matter, or information traveling to a target.

  • Target System: Where the phenomenon is received or observed.

  • Active Field: External conditions (like temperature, rules, catalysts) that modify the phenomenon.

Model 3: Activity Model

• Purpose: Depict what the organization or domain does through a set of higher-level activities and sub-activities.

• Show how each activity uses knowledge, transforms inputs into outputs, and who the main actors are.

• Structure: Often visualized like a flow diagram (inspired by techniques such as SADT).

• Each box is an activity, linked to others by inputs/outputs and sometimes constraints.

• Decomposition can continue until you reach a desired level of detail.

• Practical Tip: If an activity has multiple actors or distinct resources, or if you need to see intermediate steps, break it into sub-activities.

Model 4: Concept Model

• Purpose: Describe the static elements of knowledge — objects or data you manipulate, their attributes, and how they relate.

• Build a conceptual vocabulary so everyone agrees on definitions.

• Main Points: Concepts have attributes (like “color” or “price”) and can specialize one another (e.g., “Vehicle” can be specialized into “Car” and “Truck”).

• This forms a hierarchy or a network of relationships, helping clarify terminology.

• Example: If your domain involves “clients,” “invoices,” and “products,” you would specify:
  Client has Name, Address, PurchaseHistory, and so on.

Model 5: Task Model

• Purpose: Capture the dynamic side of knowledge: How does an expert solve a problem or carry out a procedure?

• Show sequences, branches, loops, or parallel actions used in reasoning or execution.

• Decomposition: Start with a major task (e.g., “Diagnose Machine Failure”).

• Break it into smaller steps (e.g., “Check Power,” “Inspect Fuse,” “Replace Component”).

• Describe how these steps connect (sequentially, alternatively, or in loops).

• Benefit: Provides a clear view of an expert’s thought process and decision criteria.

• Useful for training new personnel or automating parts of the procedure.

Model 6: History Model

• Purpose: Present the evolution of knowledge over time, focusing on external events or internal decisions that changed the way things are done.

• Highlight key milestones (like a timeline) that shaped current practices.

• Typical Features:

  • Major changes in regulations, technology, or organizational structure.

  • Shifts in strategy that influenced processes or knowledge requirements.

• Why it’s Helpful: It shows why knowledge looks the way it does today.

• Encourages learning from past transitions or breakthroughs.

Model 7: Lineage Model

• Purpose: Depict a “genealogy” or sequence of generations for key objects or concepts over time.

• Explain how one version or generation led to the next (innovation drivers, pros/cons).

• Structure: Similar to a family tree, but for technologies, processes, or product lines.

• Each “branch” shows a new generation with distinct features or objectives.

• Utility: Helps predict future trends or plan new iterations by analyzing past changes.

• Provides context for why certain design choices were made or dropped.

Real Scenario: Pizza Restaurant

Applying the MASK method to analyze and structure knowledge related to a small pizza restaurant. The goal is to capture how the restaurant operates, the phenomena it must control, the concepts it uses, its tasks, and how it all evolved. The seven models are applied step by step.

1. Reference System

• Scope and Purpose:

  • Focus: The entire pizza-making and sales process.

  • Objective: Provide high-quality pizzas efficiently while ensuring customer satisfaction.

• Inputs: Ingredients (flour, tomatoes, cheese, toppings), orders (phone, website, walk-in), staff expertise.

• Outputs: Finished pizzas, customer service, profit.

• Actors (Cognitive Agents):

  • Head Chef (expert in pizza dough and recipes).

  • Assistant Cooks (preparation, toppings).

  • Cashier/Waiter (customer service, order handling).

  • Owner/Manager (decision-making, procurement).

2. Phenomenon Model

• Key Phenomena:

  • Dough Fermentation: Yeast-based reaction that makes dough rise.

  • Baking Process: Heat transfer in the oven that cooks the dough and melts cheese.

  • Customer Satisfaction: Influenced by taste, speed, service.

• Example Diagram Concepts:

  • Source System (Dough Bowl) produces a rising action due to yeast activity.

  • Flux is the release of $CO_2$ gas expanding inside the dough.

  • Target System (Dough Itself) is the medium receiving the flux (causing the dough to inflate).

  • Active Field includes temperature, humidity, resting time, and flour quality.

3. Activity Model

• High-Level Activities:

  • Prepare Dough (mix ingredients, knead, rest).

  • Assemble Pizza (roll dough, add sauce and toppings).

  • Bake Pizza (monitor oven, manage time and temperature).

  • Serve or Package Pizza (dine-in or takeaway).

  • Manage Orders and Payments (take orders, handle cash/card, record sales).

• Flow of Inputs/Outputs:

  • Prepare Dough outputs dough balls to Assemble Pizza.

  • Assemble Pizza outputs raw pizza to Bake Pizza.

  • Bake Pizza outputs finished pizzas to Serve or Package.

  • Manage Orders and Payments interacts with customers and provides order details to kitchen staff.

4. Concept Model

• Core Concepts:

  • Dough: Has attributes such as flour type, hydration level, resting time.

  • Sauce: Has a recipe (tomatoes, herbs), consistency, flavor profile.

  • Topping: Examples include cheese, pepperoni, mushrooms.

  • Pizza: Composed of dough + sauce + toppings, specialized as Margherita, Pepperoni, Vegetarian, etc.

  • Order: Contains customer details (name, contact, pizza choices, special requests).

• Relationships:

  • Pizza → Dough (attribute link: each pizza uses exactly one dough base).

  • Pizza → Topping (one pizza can have multiple toppings).

  • Topping → Cheese or Vegetable or Meat (specialization hierarchy).

  • Order → CustomerInfo (name, phone, address).

5. Task Model

• Example Task: “Bake Pizza”

  • Check Oven Temperature: Ensure it has reached the required heat (e.g., $250°C$).

  • Place Pizza into Oven: Carefully slide the raw pizza inside.

  • Monitor Baking Time: Typically 10–12 minutes, but can vary by dough thickness.

  • Rotate Pizza if Needed: For even cooking if the oven has hot spots.

  • Remove Pizza: Once crust is golden and cheese is melted.

• Decision Logic or Branches:

  • If the Pizza is undercooked, bake a few more minutes.

  • If the Pizza looks charred, reduce temperature for the next batch.

  • If a customer wants a crispier crust, keep it in for an extra minute.

6. History Model

• Notable Milestones:

  • Year 1: Restaurant opened with a basic dough recipe and classic toppings.

  • Year 2: Introduced whole-wheat dough option due to customer health trends.

  • Year 3: Upgraded to a new stone oven after demand increased.

  • Year 4: Added online ordering system, changing how staff handle orders.

• Influential Events:

  • Local food fair led to new topping ideas (vegan cheese, gluten-free dough).

  • A surge in takeout orders drove new packaging solutions and delivery partnerships.

7. Lineage Model

• Generations of Pizza Dough:

  • Generation A: Original basic dough (high-gluten flour, standard yeast, 2-hour rise).

  • Generation B: Whole-wheat dough introduced (healthier option, slightly different taste).

  • Generation C: Sourdough-based crust (long fermentation, unique flavor).

• Evolution Drivers:

  • Consumer Preferences: Demand for healthier or more artisanal pizzas.

  • Trial and Error: Chef experimentation leading to improved texture/flavor.

  • Feedback Loop: Customer satisfaction surveys guiding new dough versions.

Implementing MASK in an Organization

• Elicitation: Conduct interviews with experts; record discussions; iterate to refine the models.

• Validation: Present interim models to experts to check accuracy and coherence.

• Knowledge Book: Combine the diagrams with descriptive “fact sheets” for phenomena, best practices, and experience feedback.

• Maintenance and Diffusion: Keep models updated as the domain evolves; integrate them into training, intranet systems, decision-support tools, etc.

Ontology-Based Knowledge Modeling

What is an Ontology?

• Gruber’s Definition (1993): "Explicit specification of a conceptualization" for:

  • Classes: Abstract categories (e.g., Vehicle, Disease)

  • Properties: Relationships (hasPart, treats)

  • Axioms: Logical rules (e.g., Car ≡ Vehicle ⊓ ∃hasPart.Engine)

• Tools: Protégé (editing), Pellet (reasoning), SWRL (rules).

Why Move Beyond Simple Data?

Traditional Data Approach:

• Relational databases or spreadsheets store rows and columns.

• Data is structured, but meaning is only implicit.

• Understanding relationships often relies on documentation or user interpretation.

Ontology Approach:

• Concepts and relationships are made explicit.

• Formally defines “what things are” and “how they connect."

• Reduces ambiguity by capturing domain knowledge in a consistent, logical manner.

• Example:

  • Data: (Car_123, 4, V6)

  • Ontology: Car_123 hasWheelCount 4 ⊓ hasEngineType V6

• Industry Use Case: Google Knowledge Graph uses ontologies to unify disparate data sources.

Capturing Fundamental & Operational Knowledge

• Fundamental (Theoretical) Knowledge: Abstract principles, definitions, and classifications.

  • Example: In a manufacturing domain, the concept of a “Machine” and its theoretical properties (power rating, capacity).

• Operational (Practical) Knowledge: Actionable steps, procedures, or workflows.

  • Example: “How to operate Machine X,” “Safety rules,” “Maintenance schedule.”

• Why Both Matter: Ontologies ensure both fundamental concepts and hands-on procedures fit coherently into one model.

• This unified view supports more powerful applications (e.g., training systems, diagnostic tools).

Example: Merging Fundamental & Operational Knowledge

• Scenario: Car Maintenance Ontology

  • Fundamental concepts: Car, Engine, Transmission, Mechanic, Workshop.

  • Operational concepts: “Maintenance procedure,” “Diagnostic step,” “Error code,” “Tool usage.”

• Illustrative Relations:

  • part_of(Engine, Car)

  • requires(MaintenanceProcedure, Tool)

  • performed_by(MaintenanceProcedure, Mechanic)

  • has_error_code(Engine, ErrorCode42)

• Outcome: A system can reason about maintenance tasks (e.g., diagnosing engine trouble).

• Connects conceptual definitions (Engine = part of Car) with real procedures (a Mechanic performs maintenance).

Ontology Modeling: Core Elements

1. Classes & Hierarchy
   Abstract categories organized via is-a relationships

2. Individuals (Instances)
   Concrete entities belonging to classes (e.g., Car_A is an instance of Car).
   Examples in OWL: <Car rdf:about="#Car_A"/>

3. Properties & Characteristics

   • Relationships between entities:

     • Object Properties: hasOwner(Car, Person)

     • Datatype Properties: manufactureYear(Car, integer)

4. Axioms & Constraints

   • TBox (Terminology): Class definitions

     • ElectricCar ≡ Car ⊓ ∃hasBattery.Battery

   • RBox (Rules): Property behavior

     • Transitive(hasPart)

     • Inverse(owns, ownedBy)

   • Constraints:

     • Disjoint(Car, Truck)

     • Cardinality(hasDriver ≤ 1)

Steps for Creating an Ontology

1. Define the Purpose and Boundaries

   • Clarify why the ontology is needed and what domain it covers.

   • Determine the scope (Is it for a training system? A diagnostic tool? An integrated knowledge base?).

2. Collect & Organize Domain Knowledge

   • Conduct interviews or workshops with subject-matter experts.

   • Gather documentation, existing data models, or workflows.

   • Identify the key concepts, terminology, and relationships.

3. Structure the Classes & Relationships

   • Build a hierarchy (general → specific).

   • Add properties (e.g., is_a, part_of, depends_on).

   • Determine domains and ranges for each property (e.g., “An operates property links an Operator to a Machine”).

4. Incorporate Constraints and Axioms

   • Add rules or cardinalities (e.g., “A car has exactly 4 wheels,” or “A disease must have at least one symptom”).

   • Use automated checks (a reasoner) to ensure consistency (e.g., no contradiction like “Wheel part_of Engine”).

5. Validate with Competency Questions

   • Formulate queries reflecting real domain needs:

     • “Which machines require periodic inspections every 6 months?”

     • “Which patients are at risk if taking Drug A conflicts with Condition B?”

   • Check if the ontology can answer these questions or identify gaps.

6. Maintain & Evolve the Ontology

   • Domains are dynamic; new concepts, procedures, or regulations appear.

   • Versioning and collaborative editing tools help keep the ontology updated without losing integrity.

Key Benefits of Ontology-Based Modeling

• Enhanced Clarity: Reduces ambiguity through explicit, logically sound definitions.

• Knowledge Reuse: The same ontology can be reused in different applications (e.g., training modules, expert systems, data integration).

• Interoperability: Different teams or systems can align on the same conceptual framework, simplifying data exchange.

• Better Decision Support: Automated reasoning can suggest solutions, identify conflicts, or highlight new insights.

• Scalability: As the domain grows, the ontology can be extended and maintained systematically.

Frame-Based Knowledge Modeling

What is Frame-Based Modeling?

• A frame is a data structure for representing a stereotyped situation or object.

• Inspired by human cognitive structures – similar to mental “schemas”.

• Knowledge is organized into frames, each with slots (attributes) and values.

• Commonly used in expert systems and object-oriented AI.

• Example: Frame for a Car

  • Frame: Car

  • Slots: Make, Model, Color, EngineType

  • Values: Toyota, Corolla, Red, Hybrid

Structure of a Frame

• Basic Components of a Frame:

  • Frame Name – the entity being described (e.g., Car).

  • Slots – attributes or properties (e.g., Color, EngineType).

  • Facets – constraints or metadata about a slot (e.g., default value, data type, allowed range).

  • Values – actual or default values for slots.

• Example:

  • Frame: Car

  • Slot: Color → Facet: Type = String → Value = Red

  • Slot: EngineType → Facet: Allowed = [Diesel, Petrol, Hybrid]

Inheritance in Frame-Based Models

• What is Inheritance in Frames?

  • Frames support hierarchical relationships – one frame can inherit from another.

  • Promotes reuse and modularity.

• Example:

  • Frame: Vehicle has slots NumberOfWheels, FuelType.

  • Frame: Car inherits from Vehicle, adds TrunkCapacity.

• Benefits:

  • Reduces redundancy.

  • Allows default values to be overridden in subframes.

Reasoning with Frames

Frames can be used for reasoning in AI systems:

• Default reasoning: Use default slot values unless specified otherwise.

• Inheritance reasoning: Infer values from parent frames.

• Procedural attachment: Invoke rules/procedures when slot values are accessed.

• Example:

  • If no Color is specified for a Car, default to Black.

  • If Car.EngineType = Electric, infer Car.Emission = Zero.

  • Frame: Person, Slot: age, Value: (computed from birthYear), Procedural Attachment: calculate current age based on current year.

How to Implement Frame-Based Modeling

Steps:

1. Identify domain entities to be modeled (e.g., Person, Car, Symptom).

2. Define frames for each entity.

3. Add slots and default values.

4. Use facets to constrain and document slot behavior.

5. Define inheritance hierarchy among frames.

Tools: AI languages: LISP, PROLOG. Knowledge platforms: Protégé, CLIPS.

Applications of Frame-Based Modeling

Common Use Cases:

• Expert Systems: Medical diagnosis, legal advice.

• Intelligent Agents: Store and recall structured knowledge.

• Natural Language Understanding: Represent sentence meaning.

• Robotics: Model parts, tools, and interactions.

• Example: Medical Diagnosis

  • Frame: Disease with slots: Symptoms, Causes, Treatment.

  • Used in systems like MYCIN.

Rule-Based Knowledge Modeling

What is Rule-Based Modeling?

• A rule-based system encodes expert knowledge as IF-THEN rules.

• Suitable for domains where knowledge is explicitly defined.

• Used in diagnostic systems, decision-making, and control systems.

• Example: IF temperature > $38°C$ THEN diagnosis = fever.

Structure of a Rule-Based System

• Key Components:

  • Knowledge Base: Contains domain-specific rules.

  • Working Memory: Stores current facts/data.

  • Inference Engine: Evaluates rules and derives conclusions.

• Rule Format:

  • IF condition THEN action/conclusion.

• Multiple rules can be chained for complex reasoning.

Forward vs. Backward Chaining

• Forward Chaining (Data-Driven):

  • Starts with known facts, applies rules to infer new facts.

  • Used in real-time systems and automation.

• Backward Chaining (Goal-Driven):

  • Starts with a goal and works backward to find supporting facts.

  • Used in diagnosis and advisory systems.

• Example:

  • Goal: Is the patient infected?

  • Rule: IF cough AND fever THEN infection = likely.

Steps to Build a Rule-Based System

1. Define the Domain
   Understand the problem space (e.g., medical, finance).

2. Extract Rules
   Interview experts, analyze data, identify key patterns.

3. Build the Knowledge Base
   Encode rules using IF-THEN format.

4. Implement the Inference Engine
   Choose forward or backward chaining.

5. Test and Validate
   Use case studies and test scenarios.

Tools and Platforms

• Popular Platforms for Rule-Based Systems:

  • CLIPS – C Language Production System, open-source.

  • Jess – Java Expert System Shell.

  • Drools – Business rules engine in Java.

  • Prolog – Logic programming for rule-based reasoning.

• Features: Rule management, conflict resolution, chaining support.

• Easy integration into software systems.

Advantages and Limitations

• Advantages:

  • Easy to read and maintain rules.

  • High explainability (transparent decision paths).

  • Good for domains with expert-driven knowledge.

• Limitations:

  • Not scalable for large, complex systems.

  • Conflicts between rules may occur.

  • Performance degrades with too many rules.

Applications of Rule-Based Systems

• Where Rule-Based Modeling is Used:

  • Medical Expert Systems: e.g., MYCIN for diagnosis.

  • Fraud Detection: Pattern-based rule evaluation.

  • Customer Support: Chatbots and ticket routing.

  • Industrial Control: Automation rules for machines.

• Example Rule:

  • IF user = premium AND issue = urgent THEN escalate to supervisor.

Conclusion & Key Takeaways

Knowledge Modeling transforms raw expertise into structured, AI-readable models. Fundamentals ensure your model is complete, consistent, modular and scalable across evolving domains. Core Components — task, inference, concept models and the knowledge base — work together to support robust reasoning. Methodologies (CommonKADS, MASK, Ontologies, Frames, Rules) provide repeatable, disciplined approaches for different problem contexts. A well-modeled knowledge base enables AI systems to reason, decide, and explain with clarity and adaptability. Knowledge Modeling sits at the heart of the KE pipeline.