Making Reusable Knowledge Objects in mTropolis

n       n       n       n       n       n      n       n       n       n       n       n       n       n       n       n      n       n       n       n       n       n       n       n       n       n      n       n       n       n       n       n       n       n

Steven D. Tripp

tripp@u-aizu.ac.jp Center for Language Research

University of Aizu

Aizu-Wakamatsu, Japan

 

 


Abstract:

 The production of multimedia computer-based educational materials is time-consuming and expensive.  There is a need for methodologies which allow the efficient production of courseware.  One approach is to define standards for the representation of knowledge.  This paper investigates the design of re-usable and sharable knowledge objects. A new object-oriented authoring system, mTropolis™, facilitates the development of reusable objects, but little is known about how to make reusable instructional knowledge objects.

<keywords> ontologies, CBI, knowledge objects, authoring systems, education


Introduction

Creating more efficient instructional methodologies is always a priority for instructional designers. Currently there is interest in AI circles in the production of ontologies, or reusable knowledge bases (Gruber, n.d.).  There has been little reported in educational technology on this subject, perhaps because of the lack of a convenient authoring system for true object-oriented applications.  The advent of mTropolis now affords instructional designers an opportunity to experiment with the design of instructional ontologies, or knowledge bases for instructional purposes.  mTropolis affords the creation of complex knowledge objects that may be saved in libraries and reused.  However, without some standard notions of how to represent knowledge objects, agents will not be able to manipulate them.  This paper addresses that issue.

Ontologies and Knowledge Objects

In AI circles, an ontology is a specification of a conceptualization  (Gruber,  n.d.).  The purpose of an ontology is to enable knowledge sharing and reuse.  In practical terms this means that a vocabulary is defined that is consistent (but not complete) with respect to a body of knowledge.  It allows the exchange of queries and assertions between agents.  Gruber (1993) describes some principles for the design of knowledge-sharing ontologies.  He says that an ontology should exhibit the following qualities:  Clarity, coherence, extendibility, minimal encoding bias, and minimal ontological commitments.  Clarity means that it should communicate the meanings of its defined terms.  Coherence means that it should allow logical inferences based on its axioms.  Its shared vocabulary should allow the extension of definitions without redefinition of terms.  Encoding bias refers to decisions which are made solely because of limitations of the representation system.  Finally, minimal ontological commitment means that the system should make as few claims about the world as possible (i.e., should be the weakest possible theory).  Because designing an ontology is engineering and not science or philosophy, there will inevitable be trade-offs and compromises in its development.

The idea that there are certain limited kinds of knowledge objects for instructional purposes has been exploited in the design of the Electronic Trainer™ developed by David Merrill’s group at Utah State University. In the Electronic Trainer, information is entered into certain object categories.  For example, one type of category is an entity and its parts.  Another type of category is a procedure.  Because there are certain standard ways of teaching and testing a thing and its parts or a procedure, the instructional strategies can be built into the authoring system and applied to the knowledge objects without any additional authoring.  In addition different instructional strategies can be applied to the same knowledge objects.  For example a person may learn about the parts of machine by having them introduced one-by-one.  Alternatively one can learn by exploring the parts of the machine in any order and receiving the name by clicking on the parts.  Essentially this design follows the traditional computer science strategy of dividing program and data.  It asserts that there a limited set of instructional strategies and for any kind of knowledge object and that if the object is described in a standard way, a generic strategy can be applied to that object.

These ideas are further expanded in his recent paper (Merrill, n.d.).  This paper describes a state simulator.  Once a set of knowledge objects and their relation are entered into the system, a set of instructional strategies can be applied to that set of objects automatically, i.e., without human intervention.  In this case the strategies (transactions) are:  Identifying the parts, executing a set of procedures, or interpreting a process.

The advantages of this approach should be obvious.  It allows multiple (and perhaps yet untried, instructional strategies to be applied to the same knowledge objects.  Secondly, the same strategies can be applied to new, yet undescribed, content without any further programming.  In the inefficient world of multimedia education, Merrill’s approach represents significant progress.

Logical Databases

Merrill’s approach is a good first step but it has some weaknesses.  The most obvious one from a programmer’s point of view is that the knowledge objects do not have a logical status.  That is, inferences (other than on explicitly described and anticipated relations) cannot be performed.  Another problem is that the knowledge objects exist at only one level of representation so objects cannot contain objects.  In other words, in the real world, processes may contain concepts that may contain parts that may have relationships that may be the result of processes.  This kind of logical embedding of multiple objects is not possible in Merrill’s programs.

Design Parameters for Knowledge Objects

Essentially what is needed for the design of instructional knowledge objects is a set of concepts and relations (i.e., an ontology) that can be combined in certain regular ways to describe a set of knowledge sufficiently rigorously that an agent such as an inference engine or an instructional discourse engine can act upon it (commit to it).  In other words, we need a grammar of knowledge that can represent any and all objects and relations that we might want to teach.  Such ontologies could be shared and reused by instructional designers throughout the world and could be acted upon by instructional agents given that they committed to that grammar of instructional objects, that ontology.

At the current time such a grammar does not exist but it is the purpose of this paper to speculate on what kinds of objects would need to be represented and how those objects should be joined in complex structures.

We do not know what form our ontology should take, but we first need to define some of the primitives which would be structured by our grammar.  As an example, we can imagine that some of the parameters of instructional knowledge objects might be as follows:

·                Viewpoint: self-centered, other-centered

·                Concepts: name, representation, features, examples, kinds

·                Representation:  text, picture, movie, audio, scene(s)

·                Procedures: actor, purpose, steps, order, actions, results

·                Processes:  order, actions, results, initial state, final state

·                Structures/Quantity/Magnitude

·                Entities:  parts

·                Relationships:  unary, binary, symmetrical, asymmetrical, one-to-many, cause/effect, produces, is produced by, is part of, is connected to , connects, has a part, includes, shows, requires, is modeled by, hides,

·                History:  historical period, cause/effect, predecessor, descendant,

This list is not intended to be complete, but is offered as a suggestion about the kind of specifications knowledge objects would require in order to be interpreted by an instructional agent.  In order to represent such objects we need an authoring environment which allows us to create reusable objects, define their inner structure, and embed them in more complex structures.  A multimedia authoring  program called mTropolis™ seems to afford all these activities, at least as a first approximation.

Some Features of mTropolis™

Until recently, it was difficult to create multimedia, programmable objects which were clearly independent of the program they were imbedded in.  mTropolis is a multimedia authoring environment which allows a programmer to assemble graphic, video, and sound elements and link them to programmable objects embedded in a project structure.  Objects created in mTropolis are connected in a hierarchical structure but are portable; that is, they may be moved and shared independently from the program structure they are embedded in.  Objects may contain variables called behaviors which themselves can contain complex combinations of variables and scripts.  Behaviors may contain behaviors.  Media objects cannot contain objects, but an object may be made the child of another object and thus receive cascading messages, so it is logically embedded in a hierarchical structure.

Both objects and behaviors may be stored in separate, independent objects called libraries.  These libraries may be exchanged, independently from the programs where they were created.  Since the embedded variables stored in libraries may be empty, such library objects may thought of as pure structures.  Thus a set of such empty objects implicitly defines a grammar of instructional objects.  Such empty objects and their behaviors may be shared with other authors and used in other projects.  Also, instantiated objects can just as easily copied and shared.  The creation of objects, behaviors, and libraries is mostly a drag-and-drop operation and is therefore quite efficient.

Representing Knowledge Objects for Instructional Purposes

Following Merrill, in instructional design it is common to speak of entities, concepts, processes and procedures.  I have followed this pattern in designing my basic knowledge objects, while adding a fifth object, Relationships.

An Ontological Grammar

I have chosen to represent my ontology as a phrase-structure grammar to allow the recursive definition of knowledge objects.

The basic rules of the grammar are as follows.  First it consists of the fundamental “parts of speech” of the grammar, i.e., the knowledge objects:

O = Object

R = Relationship Object

C = Concept Object

E = Entity Object

Ps = Process Object

Pd = Procedure Object

Then the grammar defines a combinatorial algebra for the objects:

O Ž O R O

In a grammar such as this, the arrow (Ž) may be read as “may be rewritten as.”

O Ž   -- Curly brackets are used to indicate a choice.


C Ž N + Rep + K + F + D + Sub-B+ Ex+Non-Ex

E Ž N+ Rep + P + Q + U + Mq + Mu + Syn + Part-Sub

Ps Ž N + Rep + Ph+ Sub-El + Purp

Pd Ž N + Rep + Steps + Sub-El + Goal

R Ž  N + One2One? + Concept

Each object represented in the grammar is a complex combination of variables and behaviors.

N  Ž (Name (text variable)

Rep  Ž (Representation:  text, picture, movie, audio, or scene(s))

K  Ž (Kinds:  list variable)

F  Ž (Features:  list variable)

D  Ž (Definition:  text variable)

Sub-B  Ž (Sub-behaviors.  Concept behaviors related to the kinds)

Ex  Ž (Examples:  Entity behaviors)

Non-Ex  Ž (Non-examples:  Entity Behaviors)

P  Ž (Parts:  A list variable)

Q  Ž (Quantity:  A floating point variable)

U  Ž (Units:  A text variable)

Mq  Ž (Magnitude-quantity:  quantity in standard measure)

Mu  Ž (Magnitude units:  standard units)

Syn  Ž (Synonyms:  A text list)

Part-sub  Ž (Parts of the Entity:  behaviors corresponding to the parts list)

Ph  Ž (Phases:  A text list)

Sub-El  Ž (Sub elements of the Process.  Each is  a concept)

Purp  Ž (Purpose of the process:  A Concept behavior)

Steps  Ž (Steps of the procedure:  A text list.  )

Sub-El  Ž (Sub-elements corresponding to the Steps list:  Each is a concept)

Goal  Ž (Goal of the procedure:  A concept behavior)

One2One?  Ž (One to one?:  An integer range variable which defines whether the relation is one to one or one to many)


Combining Objects into Logical Structures

As defined by the above grammar, any object can be transformed into an Object-Relation-Object structure.  Needless to say, Relations are also objects but they are defined in a special way in this grammar.  They can only be the child of another object and must stand between two other objects.  Relations seem to be a difficult concept to define and may need to be left open for the time being.

In mTropolis parent child-relationships between objects are created easily.  As this transformation illustrates, an object can be a child of another object.  In other words a Process can be the child of a Concept or an Entity can be the child of a Concept.  Whether all these relationships are necessary or coherent is an empirical question and will be resolved by testing the grammar against actual instructional content.

There is a limitation about the embedding of objects within objects in mTropolis.  Objects which are added to scenes are automatically children (mTropolis terminology) of that scene.  Objects in the same scene can also be grouped in parent-child relationships, as explained above.  However objects within scenes are not contained by other objects, even if there is a parent-child relationship.  Intuitively, if one is designing instruction about some coherent body of knowledge, say engines, one would like the lower level parts and their behaviors to be embedded with a middle-level object such engines.  Thus for each kind of knowledge object, except Relations, their is an associated Behavior.  The term, Behavior, is a mTropolis term but it coincidentally has also been used by people working in ontology design.  Since Behaviors are also mTropolis  objects, and not necessarily executable code, there is some danger of misunderstanding in using this term, but I will be using it until a better expression is suggested.

Logically in this grammar , a Concept object and a Concept behavior are nearly the same thing.  Every Concept object (which is actually an “empty” graphic object in mTropolis ) contains a Concept behavior and it is in the behavior where all the information associated with the object is stored.  Thus all logical operations on objects must be targeted at their corresponding behaviors, not at the object itself.  Strictly speaking the objects are redundant and could be eliminated, but it is my feeling that we are not just creating a logical language for representation of knowledge but also an authoring environment.  Objects are somewhat more concrete than behaviors and may be more intuitive to the instructional designer.  The advantage of separating objects and behaviors is that a designer may create an engine object (a Concept object) with an accompanying engine behavior.  The engine behavior may then contain parts (ignition systems) which contain processes (the four-stroke cycle), concepts (displacement), and procedures (cleaning the valves), all embedded to the limits of the grammar and the program.

In this way an infinite set of knowledge object trees can be constructed from a finite set of objects and relations.  Such an ontology, in its present form, is only an portion of what would be needed for an actual instructional design authoring environment.  The first order of business is to design an input program which allows the convenient construction or attachment of knowledge objects without the author worrying about syntax.  Secondly, we need an instructional agent which can navigate the knowledge tree based upon input from a student and some standard instructional transactions.  In principle, it seems do-able.

Summary

These suggestions represent an early stage in the design of an instructional ontology and are intended to only sketch the main outlines of such an approach.  The actual structure of the grammar will need to be adjusted to conform to the results of empirical experience.  However, it is plain that if an approach such as this is fruitful, all further development will have to proceed along these lines.

References

Gruber, T. R. (1993).  Towards principles for the design of ontologies used for knowledge sharing.  Technical Report KS L 93-04,  Knowledge Systems Laboratory, Stanford University.

Gruber, T.R. (n.d.).  What is an ontology?  [WWW document] URL http://www-ksl.stanford.edu/kst/what-is-an-ontology.html.

Merrill, M.D.  (n.d.).  Instructional transaction theory (ITT):  Instructional design based on knowledge objects.  [www document] URL http://www.coe.usu.edu/coe/id2/ddc0997.html)