Although there have been much philosophical discussion and implementation of intelligent educational systems, there is little in between the two. What we usually see are very abstract discussions and ad hoc implementations. These are mainly caused by the lack of knowledge engineering of educational systems. What we need for filling up this gap are well-designed common vocabulary and frameworks for educational systems. We also need to formalize intelligent educational tasks at the right level of abstraction. We need to explicitly define learner's and system's role and tasks in intelligent educational processes. We are able to find a nice solution to this problem in knowledge engineering in which ontology, especially ontology engineering is extensively discussed. This paper discusses how task ontology contributes to characterizing IESs and hence to facilitating reusable functional component design and standardization of communication protocol among them in an IES. We first discuss what an ontology is together with the roles of task ontology in IES research. We then present preliminary taxonomy of concepts playing important roles in characterizing IESs. We demonstrate the utility of task ontology by describing WEST and GUIDON as examples. In Appendix, a small portion of Ontolingua implementation of task ontology designed up to now is shown.
Building an IES(Intelligent Educational System) requires a lot of work. It is always built from scratch. Little functional components are reusable and we cannot compare or assess the existing systems. In order to design an IES, the designer has to know what an intelligent educational system is, that is, what functions are necessary for his/her goal of education, what components are necessary for what functionality, how to specify each component, what architecture is appropriate for the goal, how to control the behavior of the components, etc. Issues here include how much we know about these fundamental characteristics of an IES. Although there have been much philosophical discussion and implementation of IESs, there is little in between the two. What we usually see are very abstract discussions and idiosyncratic implementations(Wenger, 1987). These discrepancies are mainly caused by the lack of knowledge engineering of IESs.
What we need for filling up this gap are well-designed common vocabulary and frameworks for educational systems. We also need to formalize educational tasks at the right level of abstraction. We need to explicitly define learner's and system's roles and tasks in educational processes. We are able to find a nice solution to this problem in knowledge engineering.
Knowledge engineering has been considered as technology of building expert systems. It has contributed to eliciting expertise, organizing it into a computational structure, and building knowledge bases. While rule base technology has dominated until recently, a new technology based on knowledge modeling has appeared such as KADS project in Europe(Wielinga, 1983), PROTEGE project in USA(Puerta, 1992), and MULTIS project in Japan(Mizoguchi, 1992)(Mizoguchi, 1995). All these technologies are originated from the idea of Generic tasks(Chandra, 1986) and heuristic classification(Clancey, 1985). The latest knowledge engineering technology comes up with an idea of task ontology which serves as a theory of vocabulary/concepts used as building blocks for knowledge-based systems(Mizoguchi, 1993, 1995). We consider ontology consists of task ontology which characterizes the computational architecture of knowledge-based systems and domain ontology which characterizes the domain knowledge.
Task ontology provides us with an effective methodology and vocabulary for both analyzing and synthesizing knowledge-based systems which IESs belong to(Van Marcke, 1995). Ontology is not only a pure theory in fundamental AI. Rather, it is becoming a research field called "Ontology Engineering"(Mizoguchi, 1996) like "Knowledge engineering" in expert systems. Ontology provides us with what we need to overcome the shortcomings the current IESs have we discussed above.
This paper discusses how task ontology contributes to characterizing and formalizing IESs and hence to facilitating reusable functional component design. The next section describes what an ontology is. Section 3 discusses task ontology as well as its roles in IES research. In section 4 we discuss preliminary taxonomy of concepts playing important roles in characterizing IESs. We demonstrate the utility of task ontology by describing WEST(Burton, 1982) and GUIDON(Clancey, 1982) in section 5. In Appendix, a small portion of Ontolingua(Gruber, 1992) implementation of task ontology designed up to now is shown.
Three simple definitions are given below.
Clarification of the differences among taxonomy, terminology, vocabulary, and ontology and explain axioms and axiom-equivalents is done here.
We need to discuss the labels of concepts after coming to an agreement on the meaning of them. Terminology is a theory of labels of concepts.
A set of words. Each word indicates some concepts, so it is similar to ontology. But vocabulary is language-dependent, so it lacks the universality. (We sometimes find a concept which we cannot find any one word in our language for it.) Vocabulary is weak in description of the relations among the terms in it. As for vocabulary, labels exist first, then what concept does each label indicate is discussed contrary to terminology.
Taxonomy is also similar to ontology. It is often a hierarchy of concepts in which each link is a is-a link or a part-of link. Roughly speaking, ontology is a taxonomy of concepts in which each concept is clearly defined.
Following Guarino(Guarino, 95), we use the convention in which capital letter "O" is used to distinguish the "Ontology" in philosophy from others. "Ontology" is a theory which can answer questions such as "what is existence", "What properties exist common to all the existence", "what properties can explain the existence", "How these properties explain the existence", etc.
The design methodology is like one for Ontology, but the target is different from it. Not the "existence" but smaller and concrete thing such as enterprise, thermo-dynamics, problem solving, tutoring, etc. are discussed. We define an ontology as an explicit and unambiguous description of concepts and relations among them appearing in the target thing. Such ontologies exist as many as the possible target things. We do not have to use logic to describe it.
(6) Formal ontology
Axiomatic description of an ontology. It can answer questions on the capability of ontology.
Declaratively and rigorously represented knowledge which has to be accepted without proof. In predicate logic case, a formal inference engine is implicitly assumed to exist. But, anyone seldom mention it.
An axiom has two roles as follows in ontology description: 1) To represent the meaning of concepts rigorously. 2) Within the scope of the knowledge represented declaratively, to answer the questions on the capability of the ontology and things built using the concepts in the ontology.
Questions about the capability of ontology plays an important role in its evaluation and they are divided into the following two: 1) Questions on the formal properties of the ontology and things designed using ontology. 2) Questions on the behavior of the things designed using the ontology.
The former is called "competence" question and the latter "performance" question. Axioms written in predicate calculus are sufficient for answering the former. To answer the latter question, however, we often need procedural engines to interpret the meaning of concepts in the ontology because declarative knowledge with a formal prover cannot answer all the questions. To cope with such situations, we introduce axiom equivalents defined as follows:
(8) Axiom equivalent
An axiom equivalent is not a rigorous or declarative axiom based on formal inference engine, but it is partially declarative knowledge based also on interpretation by a procedural engine to answer performance questions. Axiom equivalent do not have to be formalized completely.
The difference between axioms and axiom equivalents is essential. "Axioms" can be also interpreted as "small number of rules which are represented in a declarative form and can derive all the facts from them". It is true they contribute to making the characteristics of technology clear and explicit if it is represented in a declarative form using axioms. This also applies to ontology. In fact, many researchers have been trying to represent ontology formally. However, we could say such an attempt neglects the reality. It is obvious that declarative and formal methodology cannot cope with the performance of the knowledge required by knowledge engineering. For example, if we adopted the first order predicate calculus, we have to abandon dealing with the knowledge such as "mathematical induction is sound for all the predicates". What we should do for knowledge engineering is to adopt not only formal approaches but also informal ones such as natural language representation and axiom equivalents based on procedural interpretation. This will enable ontology research to contribute to the future knowledge processing community.
Task ontology is a system/theory of vocabulary for describing inherent problem solving structure of all the existing tasks domain-independently. It is obtained by analyzing task structures of real world problems. Design of task ontology is done in order to overcome the shortcomings of generic tasks(Chandra, 86) while preserving their basic philosophies. It does not cover the control structure but do components or primitives of unit inferences taking place during performing tasks. The ultimate goal of task ontology research includes to provide theory of all the vocabulary necessary for building a model of human problem solving process.
When we view a problem solving process based on search as a sentence of natural language, task ontology is a system of semantic vocabulary for representing meaning of the sentence. The determination of the abstraction level of task ontology requires a close consideration on granularity and generality. Representations of the two sentences of the same meaning in terms of task ontology should be the same. These observations suggest task ontology consists of the following four kinds of concepts:
Task ontology for scheduling tasks, for example, looks as follows:
Verbs are defined as a set of procedures representing its operational meaning. So, they collectively serve as a set of reusable components for building IESs.
Roles of task ontology include:
We are currently designing task ontology for IESs and trying to represent it in an ontology description language. Because the research is at an initial stage, we only present a preliminary results of task ontology design in this section.
The top-level categories of task ontology of IESs consist of Goals of education, Learner's state, System's functionality, Learner-system interaction, and Teaching material knowledge because an IES is characterized as an interaction between a system and a learner in which the system's activity is based on its functionality which is performed in a domain according to the learner's state under a certain goal. Then, we have the following top level categories of concepts.
Top-level concepts of IESs Goals of education Learner's state System's functionality Learner-system interaction Teaching material knowledge
In the following hierarchical organization of concepts are composed of nodes linked by the three kinds of links such as Is-a, Part-of, and Has-attribute. The default is Is-a link, "+" indicates Part-of link and "*" has-attribute link.
Let us investigate Goals first. There have been proposed a number of paradigms for IESs to date. While they are seemingly conflicting each other, the reality is not. When we carefully investigate the paradigms, we easily understand most of the them can co-exist, since they have different
educational goals. In this sense, goals enable one to distinguish and identify an appropriate paradigm for his purpose.
Goals of education are first divided into two categories such as augmentation of "Domain-independent" and "Domain-dependent capabilities". The former is mainly related to reasoning capability which has various kinds of subcapabilities. The latter is divided into three subcategories such as "Deep understanding of concepts"(declarative knowledge), "Problem solving capability"(procedural knowledge), and Skills.
Goals of education/training Domain-independent capability Memory Long-term memory Short-term memory Reasoning Creativity Thinking capability Basic capability Deductive thinking Inductive thinking Abductive thinking Analogical thinking Analysis/Synthesis/Modelling Recognition/differentiation/comparison Concept identification/classification Abstraction Generalization/Specialization Scientific thinking(exploration) +Problem identification/formulation +Observation +Hypothesis formation +Prediction +Verification +Hypothesis modification Social capability Argumentation Discussion Communication Negotiation Domain-dependent capability Deep understanding of concepts Learning of new concepts In-depth understanding of the new concepts Assimilation of the concept/knowledge Thorough understanding through its use Problem solving capability Typical problem solving schema Basic schema Knowledge compilation Advanced schema Diagnosis Repair .... Solving a problem by using a known schema Modifying schema or combine several schema Creating a new problem solving schema Skills
Learner's state is composed of "Phase in learning process", "Knowledge state", and "Mental state". Subcategories of the first are similar to those under the domain-dependent capability under Goals of education. "Knowledge state" consists of "Numerical representation" and "Symbolic representation". "Symbolic representation" is composed of two components such as "Location of bugs" and "Types of bugs".
Learner's state +Phase in learning process Learning process/phase of concepts learning +Learning of new concepts +In-depth understanding of the new concepts +Assimilation of the concept/knowledge +Thorough understanding through its use Learning process of problem solving capability +Typical problem solving schema Basic schema Knowledge compilation Advanced schema Diagnosis Repair .... +Solving a problem by using a known schema +Modifying schema or combining several schema +Creating a new problem solving schema +Knowledge state Numerical representation Coverage of concepts/skills mastered Degree of mastery Belief +Content +Confidence Connection strength of relations(causality, etc.) Symbolic representation +Location of bugs Conditions/Premises/Factors/etc. Actions/Conclusions/Hypotheses/etc. Order of rules Attributes Values +Types of bugs Lack of predicates/concepts/relations/rules Insertion of predicates/concepts/relations Incorrect predicates/concepts/relations Incorrect order of operations +Mental state Motivation Concentration Willingness ....
Needless to say, system's functionality is the most important category in IESs. The top level concepts are concerning how to teach which characterizes the type of IESs. Assuming autonomous systems, it is composed of:
Autonomous systems One-to-one interaction Repetitive practice Learning by doing Free exploration in a learning environment Interactive learning environment Coaching Tutoring Training Group learning Collaboration Coordination Cooperation Game-playing Argumentation ....
We also identify non-autonomous systems, that is, tools used with the aid of a human teacher. In this paper, however, we only discuss tutoring systems as a typical autonomous system. Functionality of an ITS includes "Modelling" and "Tutoring". The former characterizes capability of an ITS to model a learner as well as the problem domain which is critical to making an IES behave intelligently. "Tutoring" activity is composed of "Tutoring objectives", "Control", and "Methods". "Methods" is composed of "Actions" and "Objects". The former includes "Help" which simply gives information required upon request, "Getting learners motivated" which encourages and compliments learners, "Exercise" which gives learners problems to solve, "Guide" which gives explanation or hints appropriate for the learner's understanding state and context, and "Evaluate/assess". "Objects" includes "Problems", "Explanation", "Hints", and "Learner's performance".
System's functionality Modeling *Numeric/symbolic *Size of search space *Number of observations used *Granularity of the representation primitives *Computational cost *Analytical/Inductive *Interactiveness *Executability *Typical methods Overlay model Buggy model .... +Operations Building Update/Modification Observation Hypothesis building Evaluation of hypotheses Debugging of hypotheses Bug identification Identification of the corresponding correct knowledge Consistency checking Truth maintenance +Model +Snapshot model +Model representation +Bug +Types of bug +Degree of mastery +Reliability of the model +General capability +Mental state +History of learning +History of bugs +Time taken for each topic +History of tutoring +History of problems given +History of examples used +Personal/Cognitive Data Tutoring +Tutoring objectives *Policy Direct instruction Indirect instruction Transfer of knowledge Introduction of a new topic In-depth understanding of the new concepts Assimilation of the concept/knowledge Thorough understanding through its use Remedy Getting learners motivated to correct bugs Making learners to recognize bugs they have Correcting bugs +Control *Instruction planning Static planning(in advance) Dynamic planning *When to assess *When to interrupt Immediate feedback Planned feedback +C-Actions Plan Select Change Interrupt .... +C-Objects Instruction Topic Problem .... +Methods +Actions Help Answer to the questions/requests posed by learners Getting learners motivated Encourage Compliment .... Exercise Select (problems) Give (problems) Guide Show/Present Explain Simulate Suggest (Hints) Asking learners something to do Evaluate/assess +Objects Problems Similar problems Subproblems Easier problems More difficult problems Explanation *Load given(Difficulty of understanding) *Level Deep/Shallow knowledge level Abstraction level Evaluation of learner's answer Correct answer Knowledge necessary for solving the problem Derivation process Prerequisite knowledge Simulation result Quantitative simulation Qualitative simulation Fake simulation(to show what happens by incorrect knowledge) Hints Deductive hints Verification operation Verification process Intermediate solution Abstract examples Inductive hints Suggestion of missing things Kinds of bugs Counter examples Specific examples Extreme examples Examples of common factors of interest Attributes of the examples Learner's performance Actions Solving a problem Composing a problem for given schema Any action necessary for solving problems Predicting what happens Making hypotheses Doing an experiment to evaluate the hypothesis Explaining the reason, the solution process, etc. .... Results Answer Result ....
Learner's activity, both internal (mental) and external (actions, communication) also seems to play an important role. However, as we cannot directly assess/evaluate his/her mental activity and student model construction mainly consists of filling the chosen framework using learner-system communication as an information source, we will concentrate here at "Learner-system interaction". On the top level we suggest to characterize interaction by the following categories: "Mode of interaction", "Communication roles", "Content type" and "Control/ Sequencing/Protocol". The first concerns technical means and recognition techniques incorporated in IES, Roles reflect learner's attitude to IES, "Content types" describe cognitive content of communication and Control - a communication order.
Learner-system interaction +Mode of interaction Menu Formal language/Text Speech Natural language Graphics Image Video Virtual reality ... +Communication roles Teacher-Learner Assessor-Learner Master-Apprentice or Expert-Novice and vice versa Collaborative partners Game (competitive) partners (opposite interests) .... +Content types Problem Question Example/Counter example Action/operation Hypothesis Explanation Hint Solution Theorem/Rule/Fact - Problem domain knowledge ..... +Control/Sequencing/Protocol In-turn Learner-driven (as in environment) System-driven (as tutoring) Free dialogue Case-oriented
Teaching material knowledge is a heart of education. To make it easier to manipulate various knowledge, it is important to characterize it in terms of a few concepts. We analyzed various teaching material knowledge from the viewpoint of effectiveness of tutoring strategy applied to them. We first came up with the following:
These are factors which explain why a certain set of tutoring strategies are not effective to a certain set of domain knowledge. And then, we came up with the following four attributes for that purpose. Each attribute corresponds to a factor above one by one. Those who are interested in the detailed explanation of this characterization, please refer(Ikeda, 1994).
Teaching material knowledge includes "Domain knowledge", "Search control knowledge" and "Strategic knowledge". The first is composed of "Nodes" and "Links". Nodes include "Concepts", "Facts", "Rules", and "Principles". The latter "Goal", "Subgoal", "Cost/Score", "Preference", "Focus", etc.
Teaching material knowledge *Declarative/procedural *Abstract/concrete *Formal operations on the topic are defined or not *The size of search space Domain knowledge +Nodes(category) *Mandatory/Optional *Difficulty .... Concepts Objects Relations Facts Rules +Conditions/Premises/Factors/Findings/etc. +Actions/Conclusions/Hypotheses/etc. Principles +Links Prerequisite Objectives Is-a Part-of Order .... Search control knowledge Goals Subgoals Cost/Score Preference Focus .... Strategic knowledge
We here pick up some typical verbs and nouns appearing in the above taxonomy of concepts together with informal definition.
Encourage, Compliment, Scold, Present/give, Ask, Interrupt, Plan, Help, Answer, Suggest, etc.
In addition to the above verbs, we need more for describing the derivation process or something implicit. Their roles in task ontology is not to realize the corresponding operation but to modify or specify objects just as adjectives.
Negate, Support, Derive, Solve, Explore/Visit, etc.
In addition to the above concepts, we need some concepts specifying objects, that is, adjectives as follows:
Current, Relevant, Confirmed(hypothesis), Observed/Known(facts), Unknown, Evaluated, Missing, Correct, Incorrect, Mastered, Next(topic), Easier, More-difficult, Analogous, Focussed, etc.
Satisfying, Maximal, Minimal, Larger, Smaller, Largest, Smallest, Best, Better, etc,
We here present the description of two IESs, WEST(Burton, 1982) and GUIDON(Clancey, 1982) using our ontology.
In both IESs,
WEST is a typical COACH system for a GAME, so it plays both the ROLE of a COMPETITIVE PARTNER and a COACH. Therefore, COMMUNICATION SEQUENCE is IN-TURN, breaking by Learner's HELP and System's advice as a HINT or EXPLANATION. Regular CONTENT of COMMUNICATION is a result of calculation. MOTIVATION is supported by GAME situation and COMPLIMENTs from system. PROBLEM SELECTION is based on RULE in FOCUS. FOCUSing uses one of strategies: "FOCUS on the same RULE until it is MASTERed" or "FOCUS on the poor-known RULE that was not mentioned for the longest time". System INTERRUPTs as a COACH only on certain conditions (see example). The only TYPE OF BUG is LACK OF RULE.
Example of West's behavior:
SELECT a PROBLEM GIVE (PRESENT) a PROBLEM ASSESS Learner's RESULT UPDATE LEARNER MODEL IF LEARNER MODEL shows LACK OF RULE AND RESULT (Problem, RULE) is much better than Learner's RESULT (AND Condition to interrupt is Good ) THEN PRESENT ( EXPLANATION (RULE) ) SUGGEST Learner to apply the RULE SELECT a PROBLEM SOLVE the PROBLEM SELECT a PROBLEM .... GIVE (PRESENT) a PROBLEM ASSESS Learner's RESULT UPDATE LEARNER MODEL IF Learner's RESULT is Good AND Learner's RESULT is obtained by Newly taught RULE THEN COMPLIMENT SELECT a PROBLEM .... IF LEARNER's ACTION is ASK_FOR_HELP THEN SYSTEM's ACTION is PRESENT (one_of: EXPLANATION (RULE for the BEST RESULT) HINT (Possible RULES) HINT (RESULTs of RULES) HINT (the BEST RESULT - GOAL) )
GUIDON is a TUTORING system, playing the ROLE of an EXPERT (Diagnostician). COMMUNICATION is SYSTEM-DRIVEN, breaking by HELP and QUESTIONs of a Learner. COMMUNICATION CONTENT includes Learner's QUESTIONs, HYPOTHESes and FACTORs, supporting them; System's QUESTIONs, RULEs, GOALs, and EXPLANATIONs about FACTORS, HYPOTHESES, and RULEs. PROBLEM SELECTION is done once based on a set of chosen RULES, then communication is within one problem. System provides IMMEDIATE FEEDBACK. TYPE OF BUGS recognized - INCORRECT RULE (FACTORs, HYPOTHESIS), LACK OF RULE. MOTIVATION is not considered.
Examples of Guidon's behavior:
IF LEARNER's ACTION is ASK_FOR_HELP AND FOCUS is New GOAL THEN PRESENT (GOAL) EXPLAIN (EVALUATION (GOAL)) IF LEARNER's ACTION is QUESTION (Relation (FACTORS, CURRENT GOAL)) THEN GIVE (EXAMPLE (one_of RULEs (FACTORS, GOAL))) IF LEARNER's ACTION is ASK_FOR_HELP AND GOAL in FOCUS is not EXPLORED THEN CHOOSE one_of (SUBGOAL) PRESENT (SUBGOAL) EXPLAIN (Relation (GOAL, SUBGOAL)) ASK_EVALUATE (SUBGOAL) IF LEARNER's ACTION is QUESTION (FACTs) AND FACTs are RELEVANT to CURRENT GOAL THEN PRESENT (FACTs) IF GOAL in FOCUS is EXPLORED AND LEARNER MODEL shows that RULE is UNKNOWN AND RULE is in TOPIC AND HYPOTHESIS from RULE is similar to HYPOTHESIS in FOCUS THEN ASK_EVALUATE/EXPLAIN HYPOTHESIS IF Learner's HYPOTHESIS is CORRECT THEN Confirm (CORRECT) PRESENT (FACTORs) confirming HYPOTHESIS IF Learner's HYPOTHESIS is WRONG AND LEARNER MODEL shows that RULE which NEGATEs it is not MASTERED THEN PRESENT (FACTORs) confirming HYPOTHESIS PRESENT (FACTORs) rejecting HYPOTHESIS ASK_EVALUATE relevance of FACTORs to HYPOTHESIS IF GOAL is EXPLORED AND HYPOTHESIS is MISSING AND LEARNER MODEL has no RULE to SUPPORT it THEN PRESENT (FACTORs) both RELEVANT and IRRELEVANT ASK_SELECT (RELEVANT FACTORs) EVALUATE (ANSWER) PRESENT (RULE) EXPLAIN (RULEs application)
Although both IESs teach to apply RULEs for Problem solving, WEST mentions the RULE as a whole and compares RESULTs of RULE application, whereas GUIDON discusses RULE components - FACTORS and HYPOTHESES, existence of a RULE to connect some FACTORs to HYPOTHESIS, and GOALs in solution process. Improved version of GUIDON is based on NEOMYCIN framework for problem domain knowledge representation, including concept structuring and strategic knowledge about diagnostic problem solving. To describe these improvements current ontology must be supplied with vocabulary to represent diagnostic problem solving.
We have discussed ontology design and its use for IES specification. Although the step we have made is not large, its implications to the future research in IESs area is not small. Because the research is in an initial stage, the ontology described in this paper is not very rich which should be augmented further. And, most of the description in this paper is informal. Although informal description is easy to understand by humans, they are sometimes ambiguous and computer cannot understand them at all. In order to enable computers manipulate ontology, it has to be formalized. Ontology for communication protocol between IESs for CSCL is not discussed in this paper, though it is also important. A preliminary result is found in (Ikeda, 1995). Ontology represented in a well-defined language with declarative and procedural semantics will contribute to formalization of IESs and hence to promotion of IES research in general.
We here present an example of Ontolingua(Gruber, 1992) implementation of a portion of task ontology.
NOTE: This code is very preliminary and incomplete. Our intention is to show a rough image of ontology implementation.
(define-class IES-concept (?ies) "IES-concept consists of five subconcepts which are represented as its subclasses." :def (individual ?ies) :axiom-def (subclass-partition IES-concept (setof Goals Learner-state System-functionality Interaction Teaching-material-knowledge))) (define-class System-functionality (?sys-func) :def (IES-concept ?sys-func) :axiom-def (subclass-partition System-functionality (setof Modeling Tutoring))) (define-class Tutoring (?tutoring) "Tutoring has three slots such as Tutoring-objectives, Control, and Methods corresponding to its components. Tutoring is said to be Rational if the action taken fits the policy." :def (and (System-functionality ?tutoring) (value-type ?tutoring Tutoring.objective Tutoring-objectives) (value-type ?tutoring Tutoring.control Control) (value-type ?tutoring Tutoring.method Methods) (Tutoring.objective ?tutoring ?objective) (Tutoring.method ?tutoring ?method) (Method.action ?method ?action) (Rational ?objective ?action)))(define-relation Rational (?objective ?action) :def (and (Tutoring-objectives ?objective) (Actions ?action) (Tutoring.policy ?objective ?policy) (=> (= ?policy direct-instruction) (or (Explain ?action) (..... ?action))) (=> (= ?policy indirect-instruction) (or (Suggest ?action) (..... ?action))))) (define-class Tutoring-objectives (?t-obj) "Attributes are also represented as slots." :def (and (individual ?t-obj) (value-type ?t-obj Tutoring.policy Policy)) :axiom-def (subclass-partition Tutoring-objectives (setof Transfer-of-knowledge Remedy))) (define-relation Tutoring.objective (?t ?t-obj) "This relation serves as an access function to the value of a slot together with the following two relations." :def (and (Tutoring ?t) (Tutoring-objectives ?t-obj))) (define-relation Tutoring.control (?t ?cont) :def (and (Tutoring ?t) (Control ?cont))) (define-relation Tutoring.method (?t ?method) :def (and (Tutoring ?t) (Methods ?method))) (define-class Policy (?policy) :def (individual ?policy)) (define-instance direct-instruction (Policy)) (define-instance indirect-instruction (Policy)) (define-relation Tutoring.policy (?t-obj ?policy) :def (and (Tutoring-objectives ?t-obj) (Policy ?policy))) (define-class Methods (?method) "Method is said to be reasonable if the pair of an action and an object is reasonable." :def (and (individual ?method) (value-type ?method Method.action Actions) (value-type ?method Method.object Objects) (Method.action ?method ?action) (Method.object ?method ?object) (Reasonable ?action ?object)))(define-relation Reasonable (?action ?object) :def (and (Actions ?action) (Objects ?object) (=> (Explain ?action) (Explanation ?object)) (=> (Suggest ?action) (Hints ?object)) .... )) (define-class Actions (?action) :def (Verb ?action) :axiom-def (subclass-partition Actions (setof Help Getting-motivated Exercise Guide Evaluate))) (define-class Objects (?obj) :def (individual ?obj) :axiom-def (subclass-partition Objects (setof Problems Explanation Hints Learner-performance))) (define-relation Method.action (?method ?action) :def (and (Methods ?method) (Actions ?action))) (define-relation Method.object (?method ?obj) :def (and (Methods ?method) (Objects ?obj))) (define-class Explanation (?exp) "Load and level are attributes of Explanation. Explanation is used when the policy is Direct-instruction. Refer to definitions of Tutoring and Methods." :def (and (Objects ?exp) (text ?exp) (value-type ?exp Explanation.load Load) (value-type ?exp Explanation.level Level)) :axiom-def (subclass-partition Explanation (setof Evaluation-of-learner's-answer Correct-answer Knowledge-necessary-for-solving-the-problem Derivation-process Simulation-result Prerequisite-knowledge))) (define-class Hints (?hint) "Explanation is used when the policy is Indirect-instruction. Refer to definitions of Tutoring and Methods." :def (and (Objects ?hint) (text ?hint)) :axiom-def (subclass-partition Hints (setof Deductive-hints Inductive-hints))) (define-class Hypothesis (?hypo) :def (and (individual ?hypo) (value-type ?hypo Hypo.Confirm Confirmation))) (define-class Confirmation (?conf) :def (individual ?conf)) (define-instance confirmed-i (Confirmation)) (define-instance not-confirmed-i (Confirmation)) (define-relation Hypo.Confirm (?hypo ?conf) :def (and (Hypothesis ?hypo) (Confirmation ?conf))) (define-relation Confirmed(?x) "Adjectives are represented as relations. The meaning of the adjective 'confirmed' is not be represented." :def (and (Hypothesis ?x) (Hypo.confirm ?x confirmed-i))) (define-class Select (?select) :def (and (Actions ?select) (value-type ?select Select.input list) (value-type ?select Select.output list) (value-type ?select Select.dk Constraint) (Select.input ?select ?input) (Select.output ?select ?output) (forall ?x (=> (member-list ?x ?output) (and (member-list ?x ?input) (exists ?dk (and (Select.ks ?select ?dk) (satisfying ?x ?dk)))))))) (define-relation satisfying (?x ?constraint) "This code is borrowed from Gruber's implementation." :iff-def (and (individual ?x) (constraint ?constraint) (holds (denotation (listof 'kappa (listof (free-variable-in (constraint.expression ?constraint))) (constraint.expression ?constraint))) ?x))) ................... ...................