Educational Technology & Society 3(3) 2000
ISSN 1436-4522

Can abstraction be used as a unifying guideline to design intelligent educational systems?

Moderator: Ruddy Lelouche
Département d’informatique
Université Laval
Québec G1K 7P4 Canada
Tel.: +1 418 656 2131 ext. 2597
Fax: +1 418 656 2324
lelouche@ift.ulaval.ca

Summariser: Magali Seguran
I.A.E., Centre de Recherche
Université Jean Moulin
15, quai Claude Bernard, B.P. 0638
69239 Lyon Cedex 02, France
Tel: +33 4 7272 2158
Fax: +33 4 7272 4550
seguran@univ-lyon3.fr

Discussion Schedule
Discussion: 13 - 22 March 2000
Summing up: 23 - 24 March 2000


Pre-discussion paper

0.  Summary of the intended discussion

The construction of automated intelligent educational systems or IESs (these include various types of systems, like intelligent tutoring systems, interactive learning environments, or systems for computer-supported collaborative learning) presently suffers from two unfortunate situations. On the one hand, to be effective, education must be more user-adapted and highly interactive. On the other hand, the development of ITSs and other educational systems has been made mainly on a stand-alone basis, where every designer or developer starts from scratch. Therefore, there is a necessity to do some work towards a more generic, cost-effective and reusable approach to the design and development of intelligent educational systems.

In the proposed discussion, we favour a top-down approach to that problem, which consists in building one or several conceptual hierarchies defining the possible functions that may be expected from an IES. This could lead to a generic architecture, into which any existing or desired component, fulfilling a tutoring function, could later be placed. Naturally, such an architecture will also have to provide adequate means of communication to allow the various components or functions to communicate their knowledge to one another. The cognitive inferences drawn from that knowledge will then be immediately applicable, without having to program them into each new system.

We focus our study on problem-solving domains. We use the known distinction between the declarative domain knowledge and the problem-solving knowledge as a fundamental starting point of our proposed discussion. For example, for any educational system in such a domain, we can define four generic operating modes based only on that distinction and on the student’s main goal for using the system.

We choose abstraction, in a general sense, as the unifying concept to guide our discussion. Indeed, the use of abstraction facilitates and enhances reasoning, and at the same time it can relieve the learner’s short-term memory. With that guideline in mind, the discussion can be conducted in three main directions, which can overlap given the brevity of the formal discussion. (1) We can apply abstraction first to better and further formalise the domain knowledge and the problem-solving knowledge, then to refine the four corresponding generic operating modes. (2) Afterwards, or in parallel, we can proceed likewise with the tutoring knowledge, that I propose to conceptually view as a “society” of pedagogical agents ; abstraction can be used there to define the scope and granularity of each agent invocation, and consequently the level of the interactions between pedagogical agents or between a pedagogical agent and a student. (3) Finally, or in parallel, we can also apply abstraction to some of the various tutoring functions, performed in our case by pedagogical agents, which may be present in a given educational or training system ; some of these functions are: task selection, explanation generation, variation in the system-student interactions, subject presentation, example generation, etc.

The next sections give more details about the intended discussion.

 

1. Motivation and background

1.1  Research problem: need for a reusable approach for the development of IESs

The construction of automated intelligent educational systems presently suffers from two unfortunate situations. On the one hand, to be effective, education must be more user-adapted and highly interactive (Bork, 1997). On the other hand, the development of IESs has been made mainly on a stand-alone basis, where every designer or developer starts from scratch. Certainly some authoring tools have been developed, but, as it has been stressed at the AAAI Fall 97 Symposium on ITS Authoring Tools, most of them are not yet available commercially.

Therefore, there is a necessity to do some work towards a more generic, cost-effective and reusable approach to the design and development of IESs. That need was also emphasised at workshops specifi­cally devoted to that theme, in particular at the ITS-96, AIED-97 and AIED 99 international conferences.

Several approaches can be followed in that direction.

  • In a bottom-up approach, one puts together some components, i.e. a given system is assumed to be built by assembling well-defined and well-specified existing components, chosen according to the system purpose and the users’ profiles.
  • In a top-down approach, one first builds a conceptual frame defining the possible functions that may be expected from a system. This can lead to a generic architecture, into which any existing or desired component, fulfilling a tutoring function, could later be placed. The inferences drawn from the knowledge of that component will then be immediately applicable, without having to program them into each new system.

 

Therefore, in either approach, the main problem to be solved is that of the communication between components or functions, so that they can appropriately exchange and share their knowledge. The proposed discussion is more in the line of the second approach.

 

1.2  Rationale: why use abstraction?

We propose to use abstraction as the unifying guideline for our approach (detailed in section 5). That choice is related to our previous experience in the use of abstraction (see section 4). Besides, educators have also shown that the human mind cannot in general deal with more than seven concepts or ideas simultaneously. Hence our motto for wanting to use abstraction in human learning.

Abstraction appears as a good approach to study educational systems. Firstly, teaching by itself is a complex process, where the educator normally is able to present a given topic in various ways, according to the learner’s background and goals. Secondly, the domains actually taught vary considerably in range, depending on whether and how they refer to memory, to problem-solving, to behaviours and attitudes, etc. Thirdly, almost all teachable domains vary in complexity, from simple basics to intricate constructs and relatively complex problems to solve. For all these reasons, when a human tutor detects errors or misunderstandings, he usually draws the learner’s attention on a small subset of the involved knowledge, so that the detected errors and/or misunderstandings can be corrected at the proper abstraction level.

 

2.  Discussion objectives

For the discussion, I propose to use abstraction as the unifying guideline for the design of IESs and abstraction levels to formalise this design. Questions to be addressed are:

  • How are defined the level(s) at which two modules interact?
  • To what extent can educational computer modules be defined only by their specifications, like electrical or electronic circuits are?
  • How can be defined the level(s) at which a human teacher and a student interact?
  • Can such level(s) be simulated by a computer artefact? Under what conditions?
  • Are there different ways to define abstraction, depending on the type of concept, of activity, or of process at hand?

 

Depending on the discussants’ preferences or interests, such questions can be tackled from two complementary perspectives. One more practical may attempt to define and show how abstraction is or can be used in the design and analysis of various modules or functions of educational systems (see examples in section 5.2, item 4). Another perspective, more theoretical, may consist in defining and formalising some various facets of abstraction, like generalisation, complexity levels, hierarchical organisation of concepts, metalevel descriptions, etc., both within an educational subject domain and in domain-independent studies. Of course, it would be great if the two perspectives were to converge...

As a more immediate starting point, I suggest the following approach (although the discussants may elect to proceed otherwise). In a problem-solving domain educational system, one can define four fundamental operating modes (Lelouche & Morin, 1997b), based solely on the student’s main goal for using the system (either to learn or to assess his learning) and the underlying type of knowledge (either domain knowledge or problem-solving knowledge). Thus we could begin by making explicit the abstraction types and abstraction levels used in these four operating modes.

 

3.  Related work

This section presents some background material that may be useful for our discussion.

 

3.1  Abstraction in A.I.

Abstraction levels have been used for a long time in artificial intelligence. Indeed, in the Encyclopedia of Artificial Intelligence (Shapiro, 1992), abstraction appears in various chapters. Sriram (1992) associates abstraction levels with the term “hierarchical planning”. Amarel (1992) relates abstraction to learning, theory formation, and analogy, like I do, although he does not mention abstraction levels. Finally and mainly, Korf (1992) stresses, among the sources of knowledge, abstraction as being the process through which one can concentrate first on what is essential, leaving the details for later processing.

Michalski and Tecuci (1993) define learning as the “organisation of knowledge into new more effective representations”. They distinguish generalisation (as increasing the reference set) from abstraction (as decreasing the amount of detail specified in the description of the reference set), although our discussion will consider both, simultaneously or alternatively as the case may be. They also make a distinction between (a) specific, (b) abstract and (c) operational object descriptions: (a) describes specific instances, while (c) resorts only to observable criteria, which may then be used to derive criteria used by the intermediate representation (b). I believe this distinction to be very fruitful for human learning, and therefore in the educational domain.

 

3.2  Abstraction and cognitive science research outside IESs

Abstraction has been used widely in problem solving and in task analysis (Lenat & al., 1979; Malec, 1989). Dearden & Harrison’s introductory first sentence (1997) is self-sufficient: “This paper investigates the use of mathematical models in the design of interactive systems and considers how the level of abstraction at which such models are constructed affects their usefulness in the design of human–computer interaction.”. Their ideas about abstraction levels can certainly and interestingly be applied or extended to educational systems. Similarly, “layered protocols” (Eggen & al., 1996), which represent abstraction levels intervening in interactions between “communicating partners”, are exploited mainly for the user interface, whereas we can use it more generally with all our tutoring agents (Lelouche & Morin, 1997a; Morin & Lelouche, 1998).

Some other studies are more specific. For example, Kao and Archer (1997) deal with abstraction techniques: “vertical” (top-down analysis, like us), “horizontal” (different aspects of a problem at similar levels) and “general” (aimed at enforcing the consistency between horizontal and vertical abstractions). Benaroch’s “design metaknowledge” (1996) could be considered as of a higher abstrac­tion level. As a last example, Ricaud (1997) deals with problem-solving domains, as we do, although not in an educational context; his abstrac­tion mechanisms do not introduce abstraction levels as such, but do suggest to reason on a simplified (i.e. abstract) case; this simplification, the processing done at that level, and its integration into the original game may be viewed as using various abstraction (or complexity) levels.

 

3.3  Intelligent educational systems

Abstraction has been used in many reference books on ITSs as a key concept in procedural domains, e.g. Wenger’s (1987), in particular for problem solving. Some recent works on ITSs also use abstraction, but on a limited scope. For example, the programming systems Bridge (Bonar & Cunningham, 1988) and TIRPA (Malouin, 1993) both use abstract representations, but only in the problem-solving design and process. We can try to make this type of approach systematic, and to use it for all system components and functions.

Finally, related efforts and resources are also available on the WWW. The most signifi­cant for us is probably the Personal Learning System (PLS) Initiative, initially focused on student-centred learning, and which subsequently evolved into the IEEE P1484 Working and Study Groups, now collectively called the Learning Technology Standards Committee or LTSC http://ltsc.ieee.org/. One of these groups, like us, is aimed at reducing CAI system production costs by leveraging the power of computer reuse, although its mean to reach that goal is different from ours. Another one, P1484.2, is aimed at representing knowledge elements in “multiple levels of granularity”, i.e. of abstraction, but only to describe the learner model.

 

4. Progress report

My experience in the design and development of ITSs goes back to when I joined Université Laval in 1984, and it happens that I have used abstraction in several instances since. In summary, I have a good experience with expert system design and development and with knowledge representation and modelling. Both capacities have been put to work in a variety of approaches for ITS design (in such diverse domains as natural language, programming, algorithmics, cost engineering and soon mathematics). In addition, I have been confronted with abstraction and metalevels in several instances, some of them outside scientific research. All these reasons motivated me to propose to animate a discussion around the question titling this paper, and I look forward to doing so.

 

5.  Proposed approach for the discussion

5.1  Starting foundations

We are mainly interested in problem-solving domains. As usual, we separate the declarative domain knowledge (DK) from the problem-solving knowledge (PSK) and use that distinction as a fundamental starting point of our discussion proposal. For example, for any educational system in such a domain, we can define four generic operating modes into which any pedagogical user–interaction can be subsumed (Lelouche & Morin, 1997b). These modes, named domain-presentation, domain-assessment, demonstration, and exercising, are defined solely on the learner’s main goal for using the system (either to learn or to assess his learning), and on the underlying type of knowledge (either DK or PSK). That approach could then constitutes a first step towards a “general functioning theory” of such an IES.

 

5.2  Intended method of investigation

Our approach for the sequel is definitely pragmatic, as a discussion should be. The following steps are presented as sequential for the sake of simplicity, but the discussion may address them in parallel, or even navigate between them. However, I might come back to these “steps” when summarising the discussion. To help the discussants indicate concisely where their comments or ideas stand, I invite them to refer to these steps by number in their postings.

Step 1. We are first to exploit the use of abstraction to better and further formalise each one of the two types of knowledge. Abstraction can be applied to the definition of the concepts and relations of DK, as well as to the problem-solving processes of PSK. Based on the work already done (albeit informally) with TIGE in the cost engineering domain (Lelouche & Morin, 1997b), the discussion can shed a light on the general case that might be abstracted from this, possibly considering other domains (e.g. mathematics) and systems on which the same approach has been or could be applied.

Step 2. Afterwards, quite naturally, we can extend the application of abstraction to the refinement of our four operating modes. That may be quite a challenge, because that implies to deal with abstraction levels in the system–student interactions, i.e. identify them, define them, define the characteristics of each level, etc.

Step 3. As a third step, we can proceed likewise with the tutoring knowledge. We view it conceptually as a “society” of pedagogical agents (Morin & Lelouche, 1998), and for the discussants interested in agents we can attempt to make the use of abstraction on these agents more precise. For example, for any given activa­tion of an agent, abstraction can act either on the scope or on the granularity (or both) of the “domain region” in which that agent is to operate. In our model, following our functioning theory, I propose to have four “main” agents, each one initially in charge of one of the four operating modes. However, in any given mode, some unplanned interaction may take place, the type of which would normally be associated with another mode. These mode shifts (Lelouche & Morin, 1997b) must still be refined, using abstraction of tutoring goals, as well as of the student–system interactions (or more precisely the student–student, agent–agent, and agent–student interactions).

Step 4. Finally, we can apply abstraction to the various tutoring functions that a given educational or training system is to perform. Some of these functions are: task selection, explanation generation, variation in the system-student interactions, subject presentation, example generation, etc. The order and the depth in which we deal with them will depend on the work done at that point and on the discussants’ interests and preferences.

Step 5. As far as implementation is concerned, we are considering the use of application frameworks based on object-oriented concepts, but this is normally outside the scope of our discussion.

 

6. Anticipated significance of the discussion

As explained in section 1, building and maintaining intelligent educational systems is presently very expensive, because of the time, human and financial resources required. Also, because researchers and developers use a stand-alone “start from scratch” approach, fewer resources are available for addressing the primary research and development issues, the results are hard to replicate, the existing systems are used only on the platforms for which they were developed and they lack interoperability.

In moderating this discussion, my inner belief is that abstraction may play an important role, first to make the modelling of the various knowledge elements of an educational system as simple and systematic as possible, and possibly later to guide the description of a generic framework for designing such a system. In the long run, abstraction could well contribute to reducing the work needed to build and maintain an IES, thereby helping to make them economically viable, ultimately increasing the number of IESs actually used in schools and in the workplace.

 

7.  Relevant bibliography

  • Amarel, S. (1992). Problem solving. In Shapiro, S. C. (Ed.) Encyclopedia of Artificial Intelligence, 2nd ed., New York: Wiley, 1214-1229.
  • Benaroch, M. (1996). Roles of design knowledge in knowledge-based systems. International Journal of Human–Computer Studies, 44, 689–721.
  • Bonar, J. G. & Cunningham, R. (1988). Intelligent tutoring with intermediate representation. Paper presented at the Intelligent Tutoring Systems Conference, 1-3 June, Montreal, Canada.
  • Bork, A. (1997). The future of computers and learning. T.H.E. Journal, 24 (11), 69-77.
  • Dearden, A. M. & Harrison, M. D. (1997). Abstract models for HCI. International Journal of Human–Computer Studies, 46, 151–177.
  • Eggen, J. H., Haakma, R. & Westerink, J. H. D. M. (1996). Layered protocols: hands-on experience. International Journal of Human–Computer Studies, 44, 45–72.
  • Kao, D. & Archer, N. P. (1997). Abstraction in conceptual model design. International Journal of Human–Computer Studies, 46, 125–150.
  • Korf, R. E. (1992). Search. In Shapiro, S. C. (Ed.) Encyclopedia of Artificial Intelligence, 2nd ed., New York: Wiley, 1460-1467.
  • Lelouche, R. & Morin, J.-F. (1998). Introduction of pedagogical concepts in domain modelling for an ITS.. European Journal of Engineering Education, 23 (2), 255-271,
    http://www.ift.ulaval.ca/~lelouche/Publications/Lelouche_Morin_1998EJEE.pdf.
  • Lelouche, R. & Morin, J.-F. (1997a). Use of abstraction and complexity levels in intelligent educational systems design. Paper presented at the 15th International Joint Conference on Artificial Intelligence, 23-29 August, Nagoya, Aichi, Japan,
    http://www.ift.ulaval.ca/~lelouche/Publications/Lelouche_Morin_1997IJCAI.pdf.
  • Lelouche, R. & Morin, J.-F. (1997b). Knowledge types and tutoring interactions in an ITS in a problem-solving domain. Paper presented at the 10th International FLorida Artificial Intelligence Research Symposium, 10-14 May, Daytona Beach, Florida,
    http://www.ift.ulaval.ca/~lelouche/Publications/Lelouche_Morin_1997FLAIRS.pdf.
  • Lenat, D., Hayes-Roth, F. & Klahr, P. (1979). Cognitive Economy, Working paper HPP-79-15, Stanford Heuristic Programming Project, Stanford, CA: Stanford University.
  • Malec, J. (1989). Knowledge elicitation during dynamic scene description. ACM-SIGART Newsletter: special issue on knowledge acquisition, 108, 162-163.
  • Malouin, J. (1993). Du Système Expert au Tuteur Intelligent: Application d’un Modèle d’Apprentissage au Développement d’un Système d’Enseignement de l’Algorithmique, Ph.D. Thesis (Education sciences), Quebec, Canada: Université Laval.
  • Michalski, R. & Tecuci, G. (1993). Multi-Strategy Learning, Tutorial T15, IJCAI 93, Savoie, France: Chambéry.
  • Morin, J.-F. & Lelouche, R. (1998). Agent-oriented tutoring knowledge modelling in a problem-solving ITS. Paper presented at the ACM-SIGART Workshop on Interaction Agents (IA 98), 24 May, L’Aquila, Italy,
    http://www.ift.ulaval.ca/~lelouche/Publications/Morin_Lelouche_1998InteractionAgents.pdf.
  • Ricaud, P. (1997). A model of strategy for the game of Go using abstraction mechanisms. Paper presented at the IJCAI 97, 23-29 August, Nagoya, Aichi, Japan.
  • Shapiro, S. C. (1992). Encyclopedia of Artificial Intelligence, 2nd ed., New York: Wiley.
  • Sriram, D. (1992). Knowledge-based expert systems in engineering. In Shapiro, S. C. (Ed.) Encyclopedia of Artificial Intelligence, 2nd ed., New York: Wiley, 448-454.
  • Wenger, E. (1987). Artificial Intelligence and Tutoring Systems, Los Altos, CA: Morgan Kaufmann.

 

Post-discussion summary

Introduction

As shown in the pre-discussion paper, there is a necessity to strive towards a more generic, cost-effective and reusable approach to the design and development of intelligent educational systems (IESs). In that context, the discussion proposed to use abstraction as a unifying guideline.

Besides the moderator Ruddy Lelouche and the summariser Magali Seguran, participants in that discussion were (in alphabetical order):

  • Tom Abeles <TAbeles@tmn.com>, from Sagacity, Inc., U.S.A.;
  • Jean-Jacques d’Aquin <jdaquin@jaguar1.usouthal.edu>, from the University of South Alabama, U.S.A.;
  • Muhammad Betz <mbetz@sosu.edu>, from Southeastern Oklahoma State University, U.S.A.;
  • Ania Lian <ania@lingua.arts.uq.edu.au>, from the University of Queensland, Brisbane, Australia;
  • Dennis Nelson <NelsonD@ny-smtp.army.mil>, from the NYS Division of Military and Naval Affairs, U.S.A.;
  • Clark Quinn <CQuinn@knowledgeplanet.com>, from KnowledgePlanet.com, Emeryville, California, U.S.A.;
  • Jenny Ure <atsJU@garthdee1.rgu.ac.uk>, from the Robert Gordon University, Scotland, U.K.;
  • Crispin Weston <crispinw@dircon.co.uk>, from Alpha Courseware, U.K.

 

The pre-discussion papers offered the participants to discuss along three directions : what abstraction is, why abstraction is useful, and how abstraction can be used in the design of IESs. As it turned out, the discussion focused on the nature of abstraction and several of its facets in general, which are presented in section 1. Simultaneously, an important part of the discussion also addressed the issue of how this abstraction could be used in relationship with the knowledge types in an IES. That is examined in section 2. However, because of the specific nature of IESs, another direction can also be applied to them, namely instructional design, which was also addressed during the discusiion and which is reported in section 3.

 

1.  Abstraction in general

This section is intended to report the reactions from the discussants regarding the first two questions offered in the moderator’s message starting the discussion: why use abstraction, and what is abstraction. However, the participants brought up some other interesting aspects of abstraction in general; we thus also examine them in this section.

 

1.1 Why use abstraction ?

In his first message to the list, Ruddy Lelouche suggested three answers:

  • because teaching itself is a complex process;
  • because the domains actually taught encompass a considerable range, from know to know-how to know-how-to-be;
  • because almost all teachable domains vary in complexity.

 

And gave as an example the error detection and correction process: when a human tutor detects errors or misunderstandings, (s)he usually draws the learner's attention on “where (s)he thinks the error is”, i.e. a small subset of the involved knowledge, so that the detected error and/or misunderstanding can be corrected at the proper abstraction level. Thus it would be nice to have automated systems do likewise...

However, Ania Lian questioned the teacher’s ability to know where the error is or what can heal the error if his (her) representation of the error is already an abstract itself: in the end all that the teacher would do is to play with more abstracts. According to Lelouche, that pitfall can be avoided if the tutor prompts the student in order to locate the error and make it appear, either by asking the student more precise questions to make the substeps of his (her) reasoning and actions explicit, or by asking the student to solve a different exercise, possibly simpler, but still exhibiting the ingredients which might make the error appear.

 

1.2 What is abstraction ?

Still in his first address to the discussion list, noting that abstraction is a very broad term, Lelouche compared the abstraction process to using a bottom-up approach for defining concepts or solving problems. The converse process would be using a top-down approach, or refinement. Indeed, depending on the context, the concrete vs. abstract continuum can take different flavours, like aggregation, generalization, increase in the complexity level, metalevel description, etc.

This attempt to define the nature of abstraction gave rise to several interesting discussions about its relationships with the “what” vs. “how” dichotomy, with reduction, with the life span of knowledge, with protocols, and with containment. We now relate these exchanges.

 

1.3 The “what” and the “how”

With respect to the opposition presented in the pre-discussion paper between the declarative knowledge DK, which examplifies the “what”, and the procedural or problem-solving knowledge PSK, which examplifies the “how”, Ania Lian considered that delarative knowledge is also the “how”. Her argument is that “the how of processing in fact is the what of processing, since we can do only what we know; in other words, logic (hence the processes) does not live separately from the objects that it manipulates.”

That argument is true, but not the converse: for example, one may have one’s house painted without knowing how to paint. However, Lelouche replied that, regarding abstraction, what and how are quite intertwined in practice. We sort them out by changing the level of abstraction at which we are, using a zoom-in or zoom-out process. Giving the various phases of an airplane trip as an example, he explained that a how at a given level becomes a succession of what at the lower level, and that the details of a what at a given level are found in the how of the same level.

 

1.4 Abstraction and reduction

Tom Abeles started the discussion on abstraction. He first interpreted the model presented in the prediscussion paper like a reduction rather than an abstraction. He viewed DK and PSK (we refer here to the notations introduced in the prediscussion paper; see 2.1 below for a reminder) as two modes, where DK would be like a warehousing of knowledge, in which one gathers information and stores it in some retrievable matrix, and PSK would be equivalent to an assembly operation in which one takes various pieces and puts them together. However, Lelouche explained that, rather than two modes, DK and PSK should be viewed as two types of knowledge, on which abstraction can then operate (Lelouche & Morin, 1997a). He gave geometry as an example, where concepts and properties are part of DK, and where theorems are problems to be solved using PSK.

While agreeing with the use of abstraction to develop reusability and interoperability between learning systems, Crispin Weston thinks that the process of abstraction implies the development of protocols (see 1.5 below). The protocols can become restrictive if they are constrained by too many assumptions. Thus, he thinks there is a fine border line between abstraction and reduction.

 

1.5 Abstraction and knowledge life span

Tom Abeles also wondered how the half life of knowledge is processed by the model (whether knowledge is stored or needed to solve a problem), how the model takes into account knowledge “scaffolding”, and how the model manages the lack of information for human requests.

Taking a humanistic stand, Dennis Nelson first replied that the knowledge as a whole has an eternal life (mechanical, mental or spiritual). Secondly, regarding “scaffolded” knowledge, he asserted that “we still must learn each lesson on our own” instead of starting with the knowledge of our ancestors. Actually, dismissing the notion of half-life of knowledge, he noted the short time-life of knowledge in the face of eternity. Thirdly, the information we have had, our offspring will have also. So, information does not disappear and can be transmitted between generations. On top of that, Ruddy Lelouche detailed an example, the learning-by-exploration technique, where there is no previous information in a wharehouse or procedure. Whereas Tom Abeles wondered how the model translates to just-in-time manufacturing “where knowledge would be acquired to solve an immediate problem”, Lelouche noted that this often occurs with human learning as well: in geometry a student never encounters a given problem more than once, but (s)he can use his (her) knowledge thus acquired to solve another problem.

 

1.6 Abstraction and protocols

Crispin Weston supported the desire to use abstraction to encourage reusability of, and interoperability between, learning systems. He introduced the idea that, in practical computing terms, the process of abstraction means the development of protocols. However, he thinks that, although valid, the distinction between DK and PSK is not abstract enough to be written into a protocol. For Weston, the ideal is extensible protocols, providing an interoperable cooperative overarching framework within which proprietary elements can exist.

More than a classification (e.g. between DK and PSK), a protocol is required in order to allow the creation and the use of learning objective objects. For Crispin Weston, these schemas could exist at any level of abstraction: very abstract (DK and PSK) or much more particular (addition, subtraction, multiplication and division). This is a higher level of abstraction, he said, than what is being proposed by Professor Lelouche. Actually Lelouche thinks that learning objects are not at a higher level of abstraction, but rather in a different space, than the dichotomy between DK and PSK: they are the same as what he calls tutoring goals (Lelouche & Morin, 1997a; Morin & Lelouche, 1998), which are part of the tutoring knowledge.

Still about abstraction and protocols, Crespin Weston noted that another distinction should be made between the generalisations of educational theories (see section 3 below) and the technical abstractions, which can be used for developing protocols. Their aims are different, the former dealing with pedagogical aspects and the latter with technical ones. However, the technical side allows interoperability and reusability, and it maybe the most important one in the design of an IES.

 

1.7 Abstraction and containment

Finally, Dennis Nelson suggested that the relationship between a car wheel and a car, brought up by Lelouche when opening the discussion, is a relationship of containment, not of abstraction. Lelouche replied that sometimes both go together, as in the case of a subprogram, which is made up of computer instructions, but which is also used by the calling program as a single instruction, although more powerful, more abstract than the computer-provided ones. He wonders what precisely can make a part-of containment relationship also one of abstraction: the fact that the part is of the same type as the whole?

On the relationship between abstraction and containment, Weston thinks that abstraction allows containment, and is therefore prior to containment. Indeed, containment is just one form of relationship between two objects, but all relationships between objects requires some understanding of their mutual roles. Abstraction is like grammar: without grammar sentences are impossible.

To continue on this idea, Seguran thinks that it may be possible to assert that abstraction is a type of meta-knowledge domain where there is some keys of understanding …. It may be a generic framework witch provides rules that could be used by other levels.

 

2. Knowledge types and abstraction in an IES

As shown in the preceeding section, abstraction can be used in various ways. Regarding intelligent educational systems, most of the discussion turned around the meaning and the formalisation of knowledge elements. So, in this section, we first give briefly a reminder on knowledge types in a problem-solving IES. We then show how the discussion somehow introduced new relationships between these knowledge types, and how it also gave the discussion a kick towards qualitative approaches to teaching and learning. We finally conclude with some other possible uses of abstraction in relationship with these knowledge types.

 

2.1 Short reminder on knowledge types in a problem-solving IES

In order to understand better the exchanges about the use of abstraction in an IES, it may be useful to recall the three knowledge types that co-exist in a problem-solving IES, as presented in the pre-discussion paper. For more details, see (Lelouche & Morin, 1997b).

The first type of knowledge is called the Domain Knowledge (DK). It contains all theoretical and factual aspects of the knowledge to be taught to the student and learned by him (her).

The second type of knowledge is the Problem-Solving Knowledge (PSK). It contains all inferential and computational processes used to solve a problem, i. e a practical situation based on the domain knowledge. It is also to be taught to the student and learned by him (her). This separation between a domain itself (DK) and the skills used to solve a practical problem in that domain (DSK) is useful for reusability, since many problem-solving techniques and processes are largely domain independent. Besides, although some PSK techniques can be learned as such, they cannot be used in a practical way by themselves, since PSK is strongly linked to the context of the problem, i.e. DK. From a learning standpoint, before being able to apply any problem-solving skills (practical aspects), the student must first learn the domain theoretical aspects.

The third type of knowledge is the Tutoring Knowledge (TK). It contains all tutoring processes enclosed in the IES. It is not to be learned or taught, but it is there to help the student understand, assimilate and master the knowledge included in DK and PSK. Again, this distinction between the knowledge to be learned (DK-PSK) and the tutoring knowledge (TK) is crucial for reusability, since many teaching or learning strategies are largely independent from any particular domain (in the scope of this discussion, as long as it is a problem-solving domain).

 

2.2 Relationships between the types of knowledge to be taught

The discussion showed the necessity to have more precisions about the relationships and even the distinction between DK and PSK (TK was not addressed directly in the discussion too often).

Crespin Weston emphasized that, besides the relationship expressed above between PSK and DK, there exist others. For example, they are complementary, but PSK is not a form of knowledge more advanced than DK. He also suggested that DK is more abstract than PSK. This point of view was challenged by Lelouche, because we cannot effectively solve a problem without knowing its domain knowledge. However, that does not always apply to a “real life” problem: thanks to their abilities to use similarities or past experiences (among others), humans can sometimes solve a problem in an unknown domain by adapting their PSK to that domain.

The comparison between DK and PSK also led the discussion towards the use of DK and PSK in courseware management. For example, Crespin Weston claimed that it would be reasonable for a piece of courseware to credit PSK directly, but that it would never be reasonable to credit DK directly. Lelouche disgreed with that statement, giving examples of questions typically assessing DK only, which are not problem-solving questions. Of course, he continued, the DK knowledge thus assessed would still be necessary to solve problems bearing upon it; this is why such questions could be asked by a tutor to a student “goofing” on a particular problem where that knowledge would be challenged.

 

2.3 Abstraction and qualitative reasoning

Extending Tom Abeles’s concern with the concept of knowledge and learning as only an assembly of modularised parts, also shared by Lelouche, Jenny Ure brought up the interesting issue of using a qualitative approach for the learning process. Viewing the concept of knowledge simply like an assembly of modularised parts has been criticised in the past, because, as Jenny Ure recalls, the whole is surely more than the sum of the parts. Indeed, she adds, the most valuable insights are not easy to capture by reduction to a measurable concrete unit, and more qualitative approaches are needed. Lelouche agreed, saying that the distinction between DK and PSK does not refer to the concept of measure, and that he also favours the use of qualitative knowledge (DK) and qualitative reasoning (PSK) in learning, even for numerical concepts like the factors in cost engineering (Lelouche & Morin, 1998).

 

2.4 Other possible uses of abstraction

Abstraction may thus be found in different places in the design of in an IES. As shown above, it can be used to formalize PSK and DK and sometimes to clarify their interrelationships. But we can also use abstraction similarly to refine the foundation or the implementation of TK. For example, as suggested by the pre-discussion paper, TK could conceptually be viewed as a “society” of pedagogical agents. An agent can be used to define the scope and granularity of each agent invocation, and consequently the level of interactions between a pedagogical agent and a student.

Crispin Weston also made interesting comments about the use of abstraction across various knowledge types: “when the protocol designer starts to think about the relationships which might be needed, we [...] also need criteria to be able to relate to other criteria, some representing finer granularity, others coarser.” Lelouche viewed that statement as a good example of an interaction between two types of abstractions, here, some abstractions dealing with the types of objects (object in the broadest sense, whether they refer to DK, PSK or TK objects), and another abstraction dealing with the granularity size (which can be used, e.g. for relevancy purposes, across DK, PSK and/or TK).

 

3. Abstraction and instructional design

In an IES, relationships between knowledge types can be referred to through other types of abstraction than those encountered in other areas. Such is the case of instructional design, since it is based on emphasizing the mutual importance of DK–PSK and of TK.

The discussion on that topic started off with a detailed statement by Clark Quinn praising the work of people like Gagné (Gagné & al., 1992) and Merrill (Merrill & al., 1991), who have worked hard at identifying finer granularity than the distinctions made between DK-PSK and TK. They have rich matrixes of learner activities goals by knowledge types, and Clark Quinn questioned the move to a more sparse representation. He also argued that, a learning goal being the ability to do something different, we are always interested in exercises as the end goals, and there is no knowledge acquisition independent from domain application: a learner is not really interested in a distinction between building knowledge or assessing it in a domain, or even in assessing per se, but just in acquiring useful knowledge. Finally, he also suggested that conceptual presentations and demonstrations are part of a cycle of learning, as in Collins, Brown, and Newman’s (1989) cognitive apprenticeship or in Laurillard’s (1993) reflective model, and therefore attempting to narrow down a learner to one mode is like saying that going to a restaurant is ordering or eating or paying...

On one side, Jean-Jacques d'Aquin “most positively endorsed” that view, claiming that “any needs assessment of any situation of learning” which does not refer to Gagné’s hierarchy of learned capabilities may become ineffective and possibly misleading.

On the other side, Muhammad Betz tended “to disagree with those who want more complex representations of learning tasks, learning domains, and learners, as well as the many components of instruction”, because “there is no end to that type of thing”: “there seems to be a hang-up here on deductive reasoning which builds more and more complex neologisms to explain phenomena of learning”. He suggested to use rather an ontology of learning and instruction (finally a type of abstraction) that supersedes the complexity of analysis or of matrixes. Indeed, the purpose here is not to go as deeply into details as Gagné and Merrill did, but to use guidelines for the whole process of designing an IES (guidelines may be abstraction or ontology or generalisations, according to the conceptual approach).

As for himself, Lelouche agreed with Clark Quinn’s view of application being the ultimate goal of learning. But sometimes, he said, the student, because of tiredness, or because of a particular motivation, etc., may want to decide the type of activity (s)he wants to engage primarily in his (her) learning process, because (s)he is more in a mood for that, for example. That does not imply that (s)he will do only that, but mainly that. Such is the purpose of his operating modes and the associated mode shifts (Lelouche & Morin, 1997b).

 

Conclusion

To end this post-discussion summary, we could say that several threads have been emphasized, like abstraction or the types of knowledge, and that other points have been explained deeply, like the relationships between knowledge types.

However, we also note that some important issues have not come up during this discussion. For example, we did not deal really with the use of abstraction in TK, be it represented as pedagogical agents or otherwise, and we did not deal with the existence of any existing systems using abstraction. Maybe, it could be interesting to address such issues in a next discussion. Certainly we are still far from a complete abstraction-based reuse mechanism in IESs (if we ever get there!).

 

References

  • Collins, A., Brown, J. S. & Newman, S. (1989). Cognitive apprenticeship : Teaching the craft of reading, writing and mathematics. In L. B. Resnick (Ed.) Knowing, learning and instruction : Essays in honor of Robert Glaser, Hillsdale, NJ: Laurence Erlbaum Associates.
  • Gagné, R., Briggs, L. & Wager, W. (1992). Principles of Instructional Design, 4th Ed., Fort Worth, TX: HBJ College Publishers.
  • Laurillard, D. (1993). Rethinking university teaching: a framework for effective use of educational technology, London : Routledge.
  • Lelouche, R. & Morin, J.-F. (1998). Introduction of pedagogical concepts in domain modelling for an ITS. European Journal of Engineering Education, 23 (2), 255-271,
    http://www.ift.ulaval.ca/~lelouche/Publications/Lelouche_Morin_1998EJEE.pdf.
  • Lelouche, R. & Morin, J.-F. (1997a). Use of abstraction and complexity levels in intelligent educational systems design. Paper presented at the IJCAI 1997, 23-29 August, Nagoya, Aichi, Japan,
    http://www.ift.ulaval.ca/~lelouche/Publications/Lelouche_Morin_1997IJCAI.pdf.
  • Lelouche, R. & Morin, J.-F. (1997b). Knowledge types and tutoring interactions in an ITS in a problem-solving domain. Paper presented at the 10th International FLorida Artificial Intelligence Research Symposium, 10-14 May, Daytona Beach, Florida,
    http://www.ift.ulaval.ca/~lelouche/Publications/Lelouche_Morin_1997FLAIRS.pdf.
  • Merrill, M. D., Li, Z. & Jones, M. K. (1991). Instructional transaction theory: an introduction. Educational Technology, 31 (6), 7-12.
  • Morin, J.-F. & Lelouche, R. (1998). Agent-oriented tutoring knowledge modelling in a problem-solving ITS. Paper presented at the ACM-SIGART Workshop on Interaction Agents (IA 98), 24 May, L’Aquila, Italy,
    http://www.ift.ulaval.ca/~lelouche/Publications/Morin_Lelouche_1998InteractionAgents.pdf.

decoration