1. Knowledge Modelling: Foundations, Techniques and Applications Enrico Motta Knowledge Media Institute The Open University United Kingdom

2. Goals of the Tutorial (1) l To characterize the knowledge modelling research paradigm —Origins —Main Tenets l To explain its relevance to several application areas —Knowledge management —Knowledge acquisition —Knowledge-based system development

3. Goals of the Tutorial (2) l To present key methodologies, technologies, tools and modelling languages related to this paradigm —Ontologies —Problem Solving Methods l To illustrate practical applications of the paradigm to concrete application domains —Engineering Design »KBS Application Development —Electronic News Publishing »Knowledge Management

4. Structure of the Talk The Knowledge Modelling Paradigm Knowledge-level Architectures for Sharing and Reuse Libraries of Reusable Knowledge Components —Ontologies: Reusable Conceptualizations —Sample Area: Design »Design Problem Solving »Library of design components »Task Models »Problem Solving Methods »Applications Knowledge Modelling for Knowledge Management Conclusions

5. The Knowledge Modelling Paradigm Its origins in the knowledge-based system research area

6. What is knowledge modelling? Knowledge Modelling = Knowledge-level Modelling A description of an agent which focuses on its competence and abstracts from implementation details Classical Example: Mycin, a diagnostic medical system: Knowledge-level behaviour: Heuristic Classification Symbol-level behaviour: Rule-based backward-chaining Newell, AI Journal, 18, 1982

7. User Interface Domain Knowledge Base Inference Engine First Generation KBS Architecture Rule-based Backward-chaining Set of Domain rules

8. User Interface Domain Knowledge Base Inference Engine Problems l Focus on implementation-level aspects (backward chaining) rather than knowledge-level functionalities (medical diagnosis) l Poor explanation capabilities l Difficult to assess competence l Low-level reuse support —Rules tend to be application specific

9. Heuristic Classification Model Abstraction Heuristic Match Data Refinement Solutions Clancey, AI Journal, 27, 1985 Data Abstractions Solutions Abstractions

10. Medical Diagnosis Abstraction Heuristic Match Refinement Solutions Data Abstractions Solutions Abstractions Low white blood count Immunosuppressed Data Gram-negative Infection E-coli Infection

11. Book Selection Abstraction Heuristic Match Refinement Solutions Data Abstractions Solutions Abstractions Watches no TV Educated Person Stereotype Data ‘Intelligent Book’ Anna Karenina

12. So What? (Competence vs Performance) l Knowledge-level analysis shows what system actually does, not how it does it —The interesting aspect about Mycin is its classification behaviour, not its depth-first control regime —Separation of competence from performance (or specification from implementation) »Important for both analysis and design of knowledge-intensive systems

13. So What? (Levels of system analysis) l There exist different levels at which a system can be described —knowledge-level (tasks and problem solving methods) —Symbol-level (backward-chaining) —Sub-symbol level (registers) l Shift in the level of analysis: —Wrong question: Can a problem be solved by means of a rule-based system? —Right questions: What type of knowledge- intensive task are we tackling? What are the appropriate problem solving methods?

14. So What? (Reuse) l Knowledge-level analysis uncovers generic reasoning patterns in problem solving agents —E.g., heuristic classification l Shift from rule-based reuse to knowledge-level reuse l Focus on high-level reusable task models and reasoning patterns —Classes of tasks »Design, diagnosis, classification, etc. —Problem solving methods »Design methods, classification methods, etc.

15. So What? (Research & Development) l Model-based knowledge acquisition —From acquiring rules to instantiating task models l Robust KBS development by reuse —KBS as a structured development process »Robustness and economy —Importance of libraries —KBS development not necessarily an ‘art’! l Towards a practical theory of knowledge-based systems —What are the classes of tasks/problem solving methods? —How do we identify/model them? —When are methods appropriate?

16. Knowledge-level Architectures for Sharing and Reuse Application of the modelling paradigm to the specification and use of libraries of reusable components for knowledge systems

17. Modelling Frameworks (1) l A modelling framework identifies the generic types of knowledge which occur in knowledge systems, thus providing a generic epistemological organization for knowledge systems l Several exist —KADS/Common KADS - Un.of Amsterdam —Components of Expertise - Steels —Generic Tasks - Chandrasekaran —Role-limiting Methods - McDermott —Protégé - Musen, Stanford —TMDA - Motta —Ibrow - Fensel, Motta et al.

18. Modelling Frameworks (2) l Much in common —Emphasis on reusable models —Typology of generic tasks —Constructivist paradigm l Some differences —Different degrees of coupling between domain-specific and domain-independent knowledge —Different degrees of flexibility —Different typologies of knowledge categories

19. A Constructive Approach... Let’s define our own framework...

20. Generic Tasks l Informal definition —A generic class of applications - e.g., planning, design, diagnosis, scheduling, etc.. l More precise definition —A knowledge-level, application-independent description of the goal to be attained by a problem solver. l Several typologies exist —e.g., Breuker, 1994 l Viewpoints over applications —No ‘natural categories’ —Different viewpoints can be imposed on a particular application

21. Example: Parametric Design Generic Task Parametric Design Inputs:Parameters, Constraints, Requirements, Cost-Function, Preferences Output:Design-Model Goal: “To produce a complete and consistent design model, which satisfies the given requirements” Preconditions:“At least one requirement and one parameter are provided”

22. Example: Classification Generic Task Classification Inputs:Candidate-classes Observables Output:Best-Matching-Classes Preconditions: “At least one candidate class exists” Goal: “To find the class that best explains the observables”

23. Generic Component 2: Reusable PSMs l A domain-independent, knowledge-level specification of problem solving behaviour, which can be used to solve a class of tasks. l PSM specifications may be partial l PSM can be task-specific —E.g., heuristic classification l PSM can be task-independent —E.g., search methods, such as hill-climbing, A*, etc.....

24. Functional Specification of a PSM Problem solving method search ontology import state-space-terminology competence roles input input: State output output: State preconditions input ≠ 0 postconditions solution_state (output) assumptions  ?s. solution_state (?s) & successor (input, ?s)

25. Operational Description Begin states:= one x. initialize (input input) repeat state:= one x. select _state (states states) if solution_state (state) then return state else succ_states:= one x. derive_successor_states (state state) states:= one x. update_state_space (input1 states input2 succ_states) end if end repeat end

26. Task-Method Structures Problem Type Primitive PSM

27. Multi-Functional Domain Models l Domain-specific models, which are not committed to a specific PSM or task. l Examples —A database of cars —The CYC knowledge base, etc..

28. Picture so far.. Problem Solving Method Classification Simple Classifier Lunar rocks Application Model Generic Task Multi-Functional Domain

29. Problem Solving Method Classification Simple Classifier Lunar rocks Application Model Generic Task Multi-Functional Domain Issue How to link different reusable components?

30. Problem Solving Method Classification Task-Domain Mapping PSM-Domain Mapping Simple Classifier Lunar rocks Application Model Generic Task Multi-Functional Domain Solution: Mappings l Mappings model explicitly the relationship between different components in an application model Task-PSM Mapping

31. Example l Scenario: Office Allocation Application l Generic Task: Parametric Design l Domain: KB about employees and offices Parameter Employee Design Model Pairs Task Level Domain Level

32. Mappings are an example of application-specific knowledge. Are there others? Application-specific knowledge Yes: Application-specific heuristic problem solving knowledge

33. Elevator Design Example l A configuration designer only considers two positions for the counterweight —Half way between platform and U-bracket —A position such that the distance between the counterweight and the platform is at least 0.75 inches

34. Complete Picture Problem Solving Method Application Model Generic Task Multi-Functional Domain Mapping Knowledge Application-specific Problem-Solving Knowledge Application Configuration

35. Formal Libraries of Reusable Components with a Clear Theoretical Basis

36. Generic Typologies are not enough... l Need for clear theoretical basis —What are the principles underlying the construction of a library? —How do components get selected? —Need to go beyond mere ‘component gathering’. l Need for formal specifications of competences —Beyond informal descriptions of tasks, methods and domains —What service do components provide? —How do components relate to each other? »e.g., tasks to other tasks and methods to tasks

37. Approach l Use formal ontologies to support reusable component specifications l Ground problem solving components on a theory of knowledge-based systems

38. Ontologies: Reusable Conceptualizations Definition, examples, design principles

39. Reusable Specifications as Ontologies An ontology is a partial specification of a conceptual vocabulary to be used for formulating knowledge-level theories about a domain of discourse. The fundamental role of an ontology is to support knowledge sharing and reuse. Example: Ontology Simple-Time Defines classes, relations and axioms to support the modelling of time-dependent activities

40. Class Specification (Define-Class Time-Point (?t) "A time-point is a point in real, historical time (on earth). Is independent of observer and context. The time-points at which events occur can be known with various degrees of precision and approximation, but conceptually time-points are point-like and not interval-like. That is, it doesn't make sense to talk about what happens during a time-point, or how long the time-point lasts." :def (individual ?t) :axiom-def (and (domain-of time-point Day-of) (domain-of time-point Minutes-of) (domain-of time-point Month-of) (domain-of time-point Seconds-of) (domain-of time-point Year-of)))

41. Classes and Relations in Simple Time Classes Day-Name Day-Number Duration Hour-Number Minute-Number Month-Name Month-Number Second-Number Time-Point Calendar-Date Calendar-Year Universal-Time-Spec Time-Range Year-Number Relations < > After After= Before Before= Disjoint-Time-Ranges During During= Equals Finishes Finishes= Meets Overlaps Overlaps= Start= Starts

42. Sample Relation Specification (define-relation DURING (?time-range-1 ?time-range-2) "a time range, ?time-range-1, is properly included in a time range, ?time-range-2." :iff-def (and (> (START-TIME-OF ?time-range-1) (START-TIME-OF ?time-range-2)) (< (end-time-of ?time-range-1) (end-time-of ?time-range-2))))

43. Ontology for medical guidelines l What is a medical guideline? — A specification (often partial) of a protocol of care —Aims to define “best practice” —Examples »Protocols for treating AIDS patients »Protocols for the prevention of bed sores l The Ontology —Defines classes, relations and axioms to support the specification of medical guidelines —Builds on a generic medical ontology —Supports both guideline design and execution.

44. Class Hierarchy for Medical Guidelines Temporal-thing Plan Medical-Guideline Therapeutic-GuidelinePreventive-GuidelineDiagnostic-Guideline Ontology Simple-time Planning Ontology Medical-Guidelines Ontology

45. Class Medical-Guideline (def-class medical-guideline (plan) "Each guideline is associated with a medical condition. It also targets a particular population" ((outcome-measure :type string) (target-population :type population-specification) (full-name :type string) (associated-medical-condition :type medical-condition) (temporal-constraints :type string) (location-constraints :type guideline-application-location) (associated-documents :type document-reference) (has-guideline-user-type :type guideline-user-type)))

46. Advantages of Ontologies l Make it possible to formalise a shared viewpoint over a certain universe of discourse —E.g., agreement on how to model time l Can support communication and cooperation between systems developed at different sites —The ontological commitments made by a system are made explicit —E.g., diagnostic and therapy-control medical systems may share the same underlying generic medical ontology »e.,g., notion of pathological state, therapeutic procedure

47. Advantages of Ontologies (2): Reuse base-ontology simple-time common-concepts bibliographic-data generic-events medical-ontology medical-guidelines generic-technologies organization-ontology

48. Advantages of Ontologies (3) l Model-based knowledge acquisition —E.g., use the medical guideline ontology to acquire knowledge about particular medical guidelines in a structured way l Knowledge-level validation and verification —E.g., use the medical guideline ontology to check guideline documents

49. Sample Knowledge Acquisition Form

50. Languages for Ontology Specification l Ontolingua (Gruber, 1993)  Formal basis on set theory  Almost a standard  Big library available on-line  Translators to some executable languages »LOOM, CLIPS, etc…. —Not operational —Batch model does not really work

51. Languages for Ontology Specification (2) l UPML (Fensel et al., IJCAI ‘99)  Formal language, based on algebraic specifications  Community Effort »European and American universities involved in language specification  State of the art modelling framework »Supports for task, PSM and mapping specification —No support for operationality —Still being defined —No library available

52. Languages for Ontology Specification (3) l OCML (Motta, 1995; 1999)  Operational Conceptual Modelling Language  Supports modelling and prototyping »Both operational and non-operational constructs  Library available on line  Advanced Web-based development tools (Web-Onto)  Supports much of the Ontolingua specification  State of the art modelling framework »Support for task, PSM and mapping specification —Lack of translators to other languages

53. Criteria for Ontology Design l Clarity —User-centred definitions —Documentation —Alternative choices l Coherence —Logical consistency —Coherent Style (e.g., naming conventions) l Minimal ontological commitments —Do not impede extensibility by making unnecessary knowledge-level commitments l Minimal encoding bias —Do not pre-judge reuse by making symbol- level commitments (Gruber, 1995)

54. Example of definition with bias (defrelation PHYSICAL-QUANTITY ( (PHYSICAL-QUANTITY ?q) (and (defined (quantity.magnitude ?q)) (double-float (quantity.magnitude ?q)) (defined (quantity.unit ?q)) (member (quantity.unit ?q) (setof meter second kilogram ampere kelvin mole candela))) Physical Quantity = Example:

55. Example of definition with bias (defrelation PHYSICAL-QUANTITY ( (PHYSICAL-QUANTITY ?q) (and (defined (quantity.magnitude ?q)) (double-float (quantity.magnitude ?q)) (defined (quantity.unit ?q)) (member (quantity.unit ?q) (setof meter second kilogram ampere kelvin mole candela))) Encoding Bias Unnecessary Ontological Commitment Physical Quantity = Example:

56. Back to the modelling framework.....

57. Complete Picture Problem Solving Method Generic Task Multi-Functional Domain Mapping Knowledge Application-specific Problem-Solving Knowledge Application Configuration Domain Ontology Task Ontology Method Ontology Mapping Ontology Ontology Application Model

58. Recap l What have we got? —Architecture for reuse »TMDA modelling framework —Technology for reusable specifications »Heterogeneous ontologies l What next? —Foundations of PSMs —Example of library development —Area: design problem solving

59. Design Problem Solving A quick overview

60. Design Problem Solving l Design Problem Solving = Constructive problem solving —Solutions are not selected by constructed from pre-existing templates l Normally more difficult than analytical problem solving l Important application area for AI —Knowledge-intensive —Complex combinatorics —Industrial relevance l Different types —‘Creative Design’, Configuration Design, Parametric Design

61. Generic Characterization Design Constraints Requirements ‘Desires’ ‘Building Blocks’

62. Design Problem Solving l Not all building blocks are given l No solution template ? ? ? ?

63. Configuration Design Problem Solving l Building blocks are given l No solution template ?

64. Parametric Design Problem Solving l Building blocks are given l Parametrized solution template exists

65. A library of reusable components for (mainly parametric) design problem solving

66. Generic Design Tasks

67. Structure of Generic Task Models Generic Design Terminology Design Preferences Design Parametric Design Terminology Parametric Design Optimal Parametric Design Optimal Design Design Solution Ontology Generic Task Legend

68. Generic Design Terminology l Minimalist ontology for design tasks. —Defines a terminology, not a class of tasks. l A design model is defined as a set of design elements. —The relations between these are not modelled in this ontology. but are a matter either for specialised design ontologies, or for domain models. l Generalises from requirements and constraints (design statements) l Supports the modelling of relative preferences between design models.

69. Ontology Signature (in UPML) ontology generic-design-terminology signature elementary sorts Design_Element, Design_Statement; constructed sorts Design_Model: set_of Design_Element; Constraint: subset_of Design_Statement; Requirement: subset_of Design_Statement; Constraints: set_of Constraint; Requirements: set_of Requirement; Design_Statements: set_of Design_Statement; functions violated_statements: Design_Model  Design_Statements; satisfied_statements: Design_Model  Design_Statements; predicates applicable: Design_Statement x Design_Model; holds: Design_Statement x Design_Model; preferred_design: Design_Model x Design_Model;

70. Ontology Axioms /* Only applicable statements can be violated or satisfied */ (?s  violated_statements (?d)  ?s  satisfied_statements (?d))  applicable (?s, ?d); /* A statement is satisfied or violated in a design model iff it holds or does not hold for the design model/* ?s  violated_statements (?d)  applicable (?s, ?d)   holds (?s, ?d); ?s  satisfied_statements (?d)  holds (?s, ?d); /* The relation preferred_design introduces a partial order on design models. /*  preferred_design (?d, ?d); preferred_design (?d 1, ?d 2 )  preferred_design (?d 2, ?d 3 )  preferred_design (?d 1, ?d 3 );

71. Ontology Design-Solution ontology design-solution pragmatics Defines the predicates and axioms needed to describe solutions to design tasks end pragmatics import generic-design-terminology; signature predicates admissible_solution: Design_Model x Constraints x Requirements; consistent: Design_Model x Constraints; suitable: Design_Model x Requirements; variables ?d: Design_Model; ?r, ?r 1, ?r 2 : Requirement; ?c: Constraint; ?rs: Requirements; ?cs: Constraints;

72. Axioms in Design-Solution /* A design model is an admissible solution iff it is consistent with respect to the problem's constraints and it is suitable with respect to the problem's requirements. */ admissible_solution (?d, ?cs, ?rs)  consistent (?d, ?cs)  suitable (?d, ?rs); /* A design model is consistent with respect to a set of constraints iff none of them is violated. */ consistent (?d, ?cs)    ?c (?c  ?cs  ?c  violated_statements (?d)); /* A design model is suitable with respect to a set of requirements iff all the requirements are satisfied. */ suitable (?d, ?rs)   ?r (?r  ?rs  ?r  satisfied_statements (?d));

73. Task Design task design pragmatics A simple class of design tasks, with no preference- related knowledge. end pragmatics ontology import design-solution; specification roles input reqs: Requirements; constrs: Constraints; output design: Design_Model; goal admissible_solution (design, constrs, reqs); preconditions  ?r (?r  reqs);

74. Task Optimal-Design - I/O Spec. task optimal-design pragmatics Augments the definition of task design by requiring that the solution has to be consistent with the global preference order specified by preference knowledge. end pragmatics ontology import design-preferences, design-solution; specification roles input reqs: Requirements; constrs: Constraints; prefs: Preferences; output design: Design_Model; end roles

75. Preconditions, Goal and Assumptions goal optimal_solution (design, constrs, reqs, prefs); preconditions /* Like in the case of the simple design problem, the only precondition is that there should be at least one requirement */  ?r (?r  reqs); assumptions /* An important assumption is that the preferences must be mutually consistent, to guarantee the correctness of the task specification*/  ?pr 1, ?pr 2 (?pr 1  prefs  ?pr 2  prefs)    ?d 1, ?d 2 (preference_applies(?pr 1 ?d 1, ?d 2 )  preference_applies(?pr 2, ?d 2, ?d 1 )));

76. Definition of optimal solution /* An optimal solution is one which is not bettered by another solution. */ optimal_solution (?d, ?cs, ?rs, ?prs)  (admissible_solution (?d, ?cs, ?rs)    ?d 1. (admissible_solution (?d 1, ?cs, ?rs)   ?pr. (?pr  ?prs  preference_applies(?pr, ?d 1, ?d))));

77. Task Parametric Design - I/O Spec. task parametric-design Ontology import parametric-design-terminology; specification roles input reqs: Requirements; constrs: Constraints; params: Parameters; value_ranges: Value_Ranges; output design: Parametric_Design_Model; end roles

78. Preconditions and Goals preconditions /* In contrast with the case of design, there is no requirement on a non-empty requirement set. A meaningful input can be defined simply by providing a set of value ranges.*/ /* The parameter set should not be empty */ $ ?p (?p  params); /* Each parameter should be associated to a value range*/  ?p (?p  params   ?vr (?vr  value_ranges  ?vr = )); goal parametric_solution (design, constrs, reqs, params, value_ranges);

79. Recap l (Good) modelling languages support the specification of generic task models l Specifications rely on ontologies l Task Models can be developed through specializations l Task Models can be used to support knowledge acquisition

80. Organizing a library of problem solving methods

81. A clear theoretical basis for PSMs l Task Models organized through typologies of generic tasks l How can we organize a library of problem solving methods? Answer: Use theory of knowledge-based systems to provide problem solving foundations

82. Definition of Knowledge System “A knowledge system is a computer system that represents and uses knowledge to carry out a task” Mark Stefik “Knowledge is whatever can be ascribed to an agent, such that its behaviour can be computed according to the principle of rationality” Allen Newell

83. Principle of Rationality “If an agent has knowledge that one of its actions will lead to one of its goals, then the agent will select that action” Allen Newell

84. Uhm…not much progress….

85. Key is the type of knowledge... l Problem-solving knowledge is knowledge which is brought to bear during a problem solving process, when a system is faced with uncertainty in choosing among a number of alternatives l Uncertainty => system has to search l Uncertainty => system can fail l Uncertainty => system may have to backtrack

86. Search Model of Problem Solving Initial State Goal States

87. Knowledge vs Conventional Systems l Conventional Systems —Systems which use direct, algorithmic methods l Knowledge Systems —Decision-making systems which use problem solving knowledge when taking decisions under uncertain conditions. Their search-centred behaviour is an inevitable consequence of this existential predicament

88. Knowledge-intensive tasks l Uncertainty is a consequence of the complexity of KBS tasks l Even simple tasks such as classification are NP-hard ÞNo direct methods can exist for such tasks l Alternative: Use problem-solving knowledge

90. The role of knowledge acquisition l Problem-solving knowledge tends to be experiential and has to be acquired —Importance of knowledge acquisition l KBS field as a whole tends to be defined by the predominant approach to knowledge acquisition —KA as mining vs. KA as modelling

91. KA as Mining Representation Formalism:Rules, frames Knowledge Categories:Facts and heuristic problem solving rules KA Methodology:Direct encoding of elicited knowledge in rule-based system Levels of Descriptions: Only one, in terms of the rule-based representation KA Paradigm:Transfer of expertise Cognitive Paradigm: Production systems as general problem solving architectures for intelligence Reuse:Inference engine

92. KA as Modelling Representation Formalism:Level-dependent Knowledge Categories:Differentiation is driven by generic knowledge roles KA Methodology:Model-based Levels of Descriptions: Multiple (e.g. knowledge vs. symbol level) KA Paradigm:Model construction Cognitive Paradigm: Functional view of knowledge Reuse:Generic task, generic problem solving model, generic domain model

93. Back to the library..

94. Structure of Library of PSMs State Space Terminology Search Parametric Design Terminology Gen-Parametric Design-PSM Design as Search Gen-Design-PSM Ontology Generic PSM Legend Design Solution Generic Design Terminology

95. Search PSM: Specification Problem solving method search ontology import state-space-terminology competence roles input input: State output output: State preconditions input ≠ 0 postconditions solution_state (output) assumptions  ?s. solution_state (?s) & successor (input, ?s)

96. Search PSM: Operational Description Begin states:= one x. initialize (input input) repeat state:= one x. select _state (states states) if solution_state (state) then return state else succ_states:= one x. derive_successor_states (state state); states:= one x. update_state_space (input1 states input2 succ_states) end if end repeat end

97. Integrating search and design ontology basic-design-as-search pragmatics This ontology integrates the terminology associated with search problem solving with the basic design one. The aim is to produce the modelling support for defining design problem solvers which subscribe to the search paradigm. import generic-design-terminology, state-space-terminology; signature predicates computable: Design_Element x Design_Model; variables ?s, ?s 1, ?s 2 : State; ?el: Design_Element; end signature

98. Axioms for Basic-Design-as-Search /* The states we consider are characterised in terms of design models */  ?s (?s  State)  ( ?s  Design_Model ); /* A design element, say ?el, is computable in a design model, ?dm, if there is a transition which adds ?el to a successor design model of ?dm */ computable (?el, ?s 1 )  ?el  ?s 1   ?s 2. state_transition(?s 1, ?s 2 )  ?el  ?s 2 );

99. From Search to a Generic Design PSM PSM refiner search  gen-design-psm pragmatics This refiner specialises the generic search PSM for design tasks. It refines the generic input to a search PSM to be a set of requirements and constraints; it replaces the generic initialize task with the specific initialize_design_model; and adds an axiom linking solution_state to the design-specific predicate admissible_solution. ontology basic-design-as-search, design_solution; competence refined roles input reqs, constraints; refined preconditions reqs  refined-subtasks initialize  initialize_design_model; axioms  ?s solution_state (?s)  admissible_solution (?s, reqs, constraints);

100. From Design to Parametric Design PSM refiner gen-design-psm  gen–parametric-design-psm ontology basic-design-as-search, parametric-design-terminology; refined roles input reqs, constraints, params, vrs; output design_model; refined preconditions params ¹  refined-subtasks initialize_design_model  initialize_parametric_design_model; derive_successor_states  derive_next_parametric_design_models; axioms /* We link the generic notion of solution state to the parametric-design-specific notion of parametric solution */  ?s. solution_state (?s)  parametric_solution (?s, constraints, reqs, params, vrs)

101. Parametric Design PSM l Provides ‘the most generic’ PSM for parametric design —defines the ‘typical’ tasks and methods required by PSMs for parametric design —Specific PSMs for parametric design as specializations of this generic model l Formulated as a Task-Method Structure, comprising 52 definitions. l Based on search model, task models and problem solving abstractions —design focus, design context and design operator

102. Main Problem Solving Components Generic Design Control Design from State New Design State Initialize Design Space Generate Successor State Select Design State Evaluate Design State Evaluate feasibility Evaluate cost Evaluate consistency Evaluate completeness Extend design Collect state foci Design from context Select design focus Design from focus Collect focus operators Order focus operators Select design operator Try design operator Apply design operator Reflect Design State

103. Main Types of Knowledge Design Operator Design Extension Operator Design Space Design State Success State Deadend State Incomplete State Inconsistent State Search Control Record Mapping Knowledge Design Context Design Focus Focus Selection Knowledge Operator Selection Knowledge Available Parameter Values

104. Generic Control Loop with State_Space = {Initial_Design_State} with Design_State = Initial_Design_State until Solution (Design_State) do Flag = Evaluate_Design_State (Design_State) Context = Select_Design_Context (Design_State, Flag) Focus = Select_Design_Focus (Design_State, Context) Operator = Select_Design_Operator (Design_State, Context, Focus) Design_Model = Apply_Design_Operator (Design_State) State_Space = Add_Design_State (State_Space, Design_Model) Design_State = Select_Design_State (State_Space)

105. So What? l Library based on a clear theoretical basis l Generic PSM model provides several advantages —An analytical framework for analysing existing PSMs —A high-level method template for constructing specific PSMs for parametric design

106. Constructing New PSMs l Generic Tasks used as high-level building blocks for defining PSMs for parametric design problems —Propose&Backtrack (0 definitions) —Propose&Revise (10 definitions) —A* for parametric design (6 definitions) —Propose&Improve (9 definitions) —Hill-climbing for parametric design (4 definitions) l On average only 10% extra definitions required to add a PSM to the library

107. Knowledge-level Analysis Template l Problem Solving Knowledge l Constraint Types l Additional Subtasks l Control Regime l Contexts l Focus Types l Focus Selection Policy l Design Operator Types l Design Operator Order Policy l Available Design Space l State Selection Policy l Completeness l Optimality

108. Analysis of Existing PSMs ApproachConsistency Centred Completion Centred Cost Centred MethodsGen-design-psm Propose&Backtrack Hc-design Propose&Improve A*-DesignPropose&Revise State Selection Policy 1) Constraints: Min 2) Design Model: Max 3) Cost: Min 1) Design Model: Max 2) Constraints: Min 3) Cost: Min 1) Constraints: Min 2) Cost: Min 3) Design Model: Max

109. Applications l Office allocation —Benchmarking problem (sisyphus-I) —Real-World (my department moved) l Elevator design —Benchmarking problem (sisyphus-II) l Initial Truck Design —Real-world application —Huge improvement in design time l Sliding Bearing Design —Real-world application —Tackled by means of Propose&Revise problem solver

110. Here is the truck.....

111. Modelling an Office Allocation Problem l Scenario: Room Allocation Application l Generic Task: Parametric Design l Domain: KB about employees and offices Parameter Employee Design Model Pairs Task Level Domain Level

113. Sample Constraint (def-domain-instance head-of-group-close-to-secs yqt-constraint ((applicable-to-parameters '(map meta-reference (setofall ?x (or (head-of-group ?x) (secretary ?x))))) (has-expression (kappa (?p ?r) (or (and (head-of-group (domain-reference ?p)) (not (exists ?sec (and (secretary ?sec) (in-room ?sec ?r2) (> (compute-distance ?r ?r2) 2))))) (and (secretary (domain-reference ?p)) (not (exists ?m (and (head-of-group ?m) (in-room ?m ?r2) (> (compute-distance ?r ?r2) 2))))))))))

114. Sample Operator (def-instance assign-head-of-group1 yqt-design-operator ((applicable-to-parameters '(map meta-reference (setofall ?x (head-of-group ?x)))) (has-body (lambda (?x ?rooms) (if (and (secretary ?y) (in-room ?y ?sec-room)) (the ?r1 (and (room ?r1 size 2 central yes usable yes) (not (member ?r1 ?rooms)) (empty ?r1) (not (exists ?r2 (and (room ?r2 size 2 central yes usable yes) (<> ?r2 ?r1) (not (member ?r2 ?rooms)) (empty ?r2) (closer-than ?r2 ?r1 (?sec-room))))))))))))

115. Cost Function Cost =, where —n1 measures the distance between the room of the head of the group and that of the secretaries; —n2 the distance between the manager’s room and the rooms of the head of the group and the secretaries; —n3 the distance between the heads of projects and the head of group and the secretaries; —n4 provides a measure of the ‘project synergy’ afforded by a solution (1 minus the ratio between all shared assignments which maximize synergy and all shared assignments)

116. Operational Mapping Specifications (def-upward-class-mapping yqt-member yqt-parameter) (def-relation-mapping current-design-model :up ((current-design-model ?dm) if (= ?dm (setofall (?p. ?v) (and (in-room ?X ?v) (maps-to ?p ?x)))))) (def-relation-mapping current-design-model (:down :add) (lambda (?x) (loop for ?pair in ?x do (if (maps-to (first ?pair) ?z) (tell (in-room ?z (rest ?pair))))))) (def-relation-mapping current-design-model (:down :remove) (lambda (?x) (unassert (in-room ?x ?y))))

117. Major Recap l Modelling framework makes it possible to build powerful reusable models l Clear theoretical basis provides organization for library l Knowledge-level approach useful for —Analysis and Development of problem solving methods and applications l Existing libraries used in real-world applications

118. Knowledge Modelling for Knowledge Management

119. Knowledge Management l Fuzzy concept, but a ‘Hot Topic’ in organizations l Awareness of organizational knowledge as a key strategic asset, to be managed to maximise its value to a company l External factors —Knowledge-based economy —Increasing importance of intangible assets —New communication and computing technology »Globalization

120. Kn. Mgt: Converting and Connecting l Converting —Individual to Group-available Knowledge »Knowledge elicitation, shared workspaces —Data to Knowledge »Data mining —Text to Knowledge »Information Extraction l Connecting —People to Knowledge »Agents, clever search engines —Knowledge to Knowledge »System integration —People to People »Intranet —Knowledge to People »Push technology O’Leary, IEEE Expert, 1998

121. Document-Centred Knowledge Work l Communication and work-practices in organizations are document-centred l But... —Documents are big. —There are lots of them. —Knowledge retrieval is inefficient. —They are a poor medium to support automated intelligent services. —Do not normally explicitly embed the meta- knowledge required to interpret and use them.

122. Contextually-Enriched Documents l Different forms of enrichment —Through discussion spaces —Through ontology-based formal models l Underlying theoretical framework —Reflection-in-action (linking working and learning) —Domain construction (shared models) —Perspective taking (contextual cues) —SER (Fischer) lifecycle »Seed/extend/restructure

123. D3E Environment

124. Where/With Whom? l Domains —Electronic News Publishing, Medical Guidelines, Engineering Design, Fault log management, Helpdesk support, ‘Best Practice’ Repositories, Engineering Design, Courseware l Users —British Aerospace, GEC, German Coal Mining Industry, Siemens, UK University for Industry.

125. Example: Planet-Onto l Starting point: KMi Planet, an electronic newsletter. l Supports communication within KMi and publicizes KMI activities to external world l Archive has ~100 stories l 480 registered readers l Success story! Customised versions produced for several groups within and outside the OU.

126. KMi Planet Front Page

127. Not a Knowledge Management System... l Information retrieval problem —“Find me stories related to knowledge management research” l Newsletter only part of broad range of information sources —“who else works on medical informatics?” —Need to integrate it with other sources, - e.g. web pages, mailing lists, etc. l Text format not adequate to support additional services —E.g., personalised news feeds; story identification

128. Solution: Planet-Onto l Ontology-driven document formalisation l Integration of newsletter with general- purpose lab KB l Semantic knowledge retrieval l Intelligent Agents

129. Ontology-driven Document Enrichment

130. Steps in Document Enrichment l Identify Scenario: From newsletter to integrated knowledge management system l Select Viewpoint for Ontology: Academic Life l Develop Ontology: KMI-Planet l Populate Ontology: KMi-Planet KB l Develop Query Interface: Lois-based l Develop additional reasoning services: NewsHound, NewsBoy

131. Architecture of Planet-Onto Story Database NewsBoy NewsHound Modelling Language (OCML) Planet KB KA Tool Email Query Interface Planet Ontology Web Browser WebOnto

132. Building Blocks for Ontology l News Stories l Events l Technologies l People l Organisations l Projects

134. Document Annotation

135. Knowledge Retrieval through Lois

136. NewsHound

137. NewsBoy

138. Summary l Knowledge management important challenge for organizations l Knowledge Modelling Technology plays a key role —Knowledge acquisition interfaces —Ontologies —Agents —Integration of text with formalised knowledge models l Planet-Onto is an example of applying knowledge modelling to knowledge management

139. Conclusions

140. Future Developments l Ontologies for e-commerce —Large potential l Large-scale system integration based on shared ontologies —Agents cooperating on the web —Again, e-commerce as key area l Sophisticated on-line reasoning services —Currently, browsers/editors for knowledge modelling —Future: Specialised reasoning services, such as classifiers, planners, information extraction l Intelligent Brokers —IBROW project

141. The End