5 Protocols to Electronic Mentoring

Jack M. Alpert Stanford Knowledge Integration Laboratory USA Alpert@cs.stanford.edu

 

Abstract:

The factor that has most limited the development of a universal electronic mentor is that it is too large a task for any one group or institution to build. However, the web node model overcomes this largeness by allowing a very large number of people to collaborate. What they need to collaboration is 5 protocols that:

1) describe learning through hierarchical subgoals

2) standardize the learning interface of all nodes

3) describe the knowledge state of the mentee

4) describe context of the mentee’s goal

5) keep a map of the return path through the hierarchy of goals.

Discovering five protocols

These protocols derive from any experience where completing the project required the learning of information. To complete the project you had to extract, assemble, and manipulate information from what you knew, and from a vast array of sources that included manuals, reference documents, peers, and classroom teachers. In that project, you succeeded but it nearly killed you.

Next time, what kind of help would you like? How about a little guy who sat on your shoulder and whispered short useful answers to your immediate questions. How about a little guy who would sit there all day and all night; waiting for you to ask never making you feel dumb or that your were wasting his time. How about a little guy that understood the problem you faced and the parts you already understood, and never wastes your time repeating what you already knew or adding extraneous information you didn’t need. How about a little guy that was so smart he even knew when you could not understand the answer your needed. Instead of confusing you with gibberish he would say "you have to understand three things." We will work on understanding them first and use them to understand your question.

What you want is an ideal mentor

Forget for a moment that no single human being could be a universal expert in all bodies of knowledge. Forget that no single human could pay attention to your intellectual meanderings 24 hours a day for years. Forget the cost of paying an army of people who could perform such a task. And consider the list of capabilities that mentor or that army must have.

The ideal mentor lets the student set the initial goal, pick the time for learning, the pace of instruction, the duration of effort and not only allows random interruptions but reviews for the student the past progress at restart.

The ideal mentor knows everything and can logically and casually connect the mentee’s objectives to first principles

The ideal mentor packages information so it:

1) is understandable with the knowledge the mentee already has,

2) appears useful in achieving the mentee’s immediate goals. and

3) motivates progress through subgoals.

These packaging objectives are achieved by:

1) using a consistent and uniform presentation format

2) breaking complicated goals into smaller and smaller subgoals

until the subgoals and their components are within the

capabilities of the mentee.

3) limiting the content to the usable

not broadening any explanation beyond that

immediate framework created by the mentee.

"The mentor has no syllabus."

To facilitate this packaging, the mentor must have two measures and a map. The first measure is of the mentee’s knowledge. The second, measure is that of the context of the mentee’s goal. Finally the mentor needs a map to get the packages to fit together. The map shows all the subgoals previously visited and a record of their partial completion. The map keeps the mentor on a path to solve the global goal.

From mentor theory to web mentor

How do we convert this theoretical description to a web implementation. Our question is, "What parts of this ideal mentor are already inherent in web design and what parts need implementation." Let me pose an example problem, and then by tracing pathways to and through some subgoals of that problem make explicit both what activities a mentor is performing and deduce the electronic equivalent of them. Consider a mentee’s goal of sending a person to the moon.

The mentor creates some subgoals. For example propulsion, navigation, life support, communication, etc. The life support goal can be further broken down into more subgoals. For example, temperature, humidity, respiration, nourishment, waste removal etc.

In general the goal tree will appear like A is accomplished if , D, E and F are accomplished. F is accomplished if J, K, L are accomplished. L is accomplished if subgoals S, T, V are accomplished, etc. The branches above these subgoals eventually lead to the laws of nature. The leaves on these tiny branches are definitions of single words in a sentence or definitions of single variables in equations.

The student progresses upward in the tree until the information presented makes sense and can be used to solve the next lower subgoal.

While these nodes are shown as part of a single tree, think of each letter as a web node written and maintained by a single expert.

In real life, an oxidation chemist mentor could play a role in solving many parts of the "person to moon" global goal. For example there could be pointers from the nodes of respiration, nourishment and even more distant branches like propulsion.

The oxidation chemist node being created independently of the man on the moon context, could also be pointed to from branches of trees representing other global goals. For example a heart transplant tree might have its blood gas branch pointing to the oxidation chemist node.

The operation of nodes

The node itself, must act like an expert mentor.

1) evaluate the mentee’s current knowledge, and from this

a) determine which group of subgoals if completed

b) will allow the mentee to solve the super goal.

2) The node then facilitates the mentee’s access to these subgoals.

Finally the node must

3) verify its success. It has to know if it produced the understanding

required by the super node. If not, the node must create a remedial plan.

What the web can do

It is easy to see that the existing web structure accomplishes some of the impossible tasks in the ideal mentor list. For example the web can provide thousands of information sources. Make them accessible 24 hours a day to thousands of mentees. The web can present information using voice, text, symbols, pictures, animations, and simulations

Five problems to be solved

However, in its present state the web can not facilitate efficient mentor based learning To accomplish this it has to overcome 5 problems.

Problem 1 -- The nodes don’t work together.

The designer of a node must find it easy to locate subnodes which efficiently support learning to complete the super goal. This efficiency can only be accomplished if the nodes are designed using the same learning model which explains how to break goals down into sub goals. Until this learning model exists each node maker will design his own, making it harder for others to use them. Each node designer will include activities that should be in a sub node with his node. That node will grow. The job of creating and maintaining such a large node will be difficult. Few if any will want to attempt it.

Thus to keep things distributed in small manageable nodes requires a protocol that tightly defines learning through hierarchical subgoals

Problem 2 — Non standard GUI

Students need a standard view of information that let's them navigate through their learning environment. That is they need to steer from topic to topic, parse confusing presentations, learn the supporting concepts, repeat an explanation, evaluate their comprehension and stop and restart their learning. The user interface must make this easy. If every node builder implements a unique interface, the mentee will have to learn the node’s interface before starting on the node’s content. The overhead will greatly reduce the electronic mentor's value. To prevent such hardship a second protocol is required which defines a single standard interface.

Problem 3 - node’s ignorance of the mentee’s knowledge

A third problem was created when we switched our mentor from a life long friend on our shoulder who was familiar with our unique objectives and capacities, to an army of independent mentors who are strangers. If each mentor has to start from scratch to establish our knowledge and capacities, valuable minutes and possible hours could pass before they could lay block one of their plan to help us.

The resolution of the third problem is the design of a byte code protocol that defines each user’s capacities and knowledge. A byte code that could be read by each node and modified by each node when the mentee learns new knowledge.

Problem — 4 node’s ignorance of the context of question

A fourth unresolved problem, is that a sub node needs the context of the super goal to do its job. What the little guy on your shoulder had, a lifetime of experience with the mentee, the sub node designer has to gain from an interview with the mentee. The resolution is a protocol that allows the super node to create a digital code for the problem's context. and passed this code to the subgoal with the mentee.

Problem 5 — no one is keeping track of the learning path

For hierarchical learning to work a sub node must know to which node to return the mentee to after it completes its work. Once returned to a super node that has several subnodes there must be a record of which of these sub goals have been completed and which remain yet to be done. To solve this problem you create fifth protocol which contains the address and completion information for each active node in the tree. This data structure resides in the head program, which is located on the individual’s home computer or service provider server.

Summary

Thus we have come to the end of our story. What needs to be added to the existing web scaffolding are 5 protocols.

Protocols for:

1) describing learning through hierarchical subgoals

2) standardizing the learning interface of all nodes

3) describing the knowledge state of the mentee

4) describing context of the mentee’s goal

5) keeping a map of the return path through the hierarchy of goals.

 

The factor that has most limited the development of a universal electronic mentor is that it is too large a task for any one group or institution to build. However, the web node model overcomes this largeness by allowing a very large number of people to collaborate. And what they need to collaboration are these 5 protocols.