Personal Construct Theory is a constructivist system of
psychology developed by George Kelly, in his work “Principles of Personal
Construct Psychology” (1955), assuming that knowledge is a constructed version
of the world, rather than a direct representation. George Kelly explores how
people experience the world, categorize these experiences and classify their
environment. The fundamental postulate of Personal Construct Theory is that "a
person’s processes are psychologically canalized by the way in which he
anticipates events.”
The Personal Construct Theory is based on the model of “man-the-scientist”, in which each individual predicts and controls events by constructing theories, testing hypotheses, and reflecting on the experimental evidence. In Kelly’s theory of “personal scientist” each individual creates his or her own ways of seeing the world in which he lives. The individual creates constructs or templates which he attempts to fit over the realities of the world, anticipating the events based on the constructs created previously. The individual revises his constructs when predictions prove to be incorrect, or strengthens and validates the constructs when the anticipations of the events were accurate.
This theory is based on the primitive of construct, or dichotomous distinction. The constructs are formed by each person’s way of seeing relationships between things, by drawing distinctions between elements. These constructs are perceived by Kelly as personal, bipolar abstractions with limited ranges of convenience, being used to organize the aspects of a person’s world. Each construct will have an individual meaning, and will represent dimensions with opposite poles.
The focus of the Personal Construct Theory is the analysis of the construct systems which an individual uses to analyze, understand, structure and change his environment. Kelly defined the notion of repertory grid as a method of representing personal constructs like a set of distinctions made about the elements which are relevant to the problem domain. The Repertory Grid Technique was introduced to explore and evaluate these constructs and construct systems.
In the last 40 years, the theory has found a wide applicability in the areas of artificial intelligence, education, management studies and human computer interaction. It is extensively used in knowledge acquisition research to model the cognitive processes of human experts (Gaines and Shaw, 1997). This theory provides a model of human knowledge representation, acquisition and processing which was made operational through computer programs for knowledge elicitation from a subject matter expert. This model can be used to develop the expert’s vocabulary and to encode the aspects of his reasoning into a rule-based system.
The Repertory Grid Elicitation Technique has been widely used as a knowledge acquisition technique to elicit information from subject matter experts. In this approach, the expert interacts with a system that helps him to make clear the distinctions he uses in applying his expertise. The system assists the expert to structure his knowledge and to identify and formalize his concepts. In this approach, the knowledge elicitation process consists of the phases shown in Figure 1:
Figure 1: Repertory Grid Elicitation Phases
Initially, the expert interacts with the system to define the relevant elements that will be analyzed from the application domain. The elements can be concrete or abstract entities that define the area of the topic, representing the vocabulary that will be used by the expert in applying his expertise. It follows the elicitation of the attributes (constructs) which distinguish the elements in the domain, using the triad method:
the elements are presented in groups of three
the expert is asked to name an attribute that
two elements share and the third one does not
both similarity and difference poles of the
construct are named.
The system compares the elicited constructs and elements, analyzing their similarities. If two elements are very similar, the system guides the expert to define a new construct that distinguishes between them. Similarly, if two constructs are found very similar, the expert is guided to define a new element that differentiates between them. The elicitation process is repeated until all elements and the constructs are distinct among themselves.
Based on the analysis of the dependencies between the elicited constructs, the system develops simple rules which are applied in making inferences on new test cases.
The Repertory Grid Elicitation Technique exhibits the following strengths:
1.
Captures
distinctions among closely related concepts which are useful to the expert, for
applying his expertise.
2.
Elicits
the expert’s personal concepts and the attributes distinguishing them, when a
public agreed vocabulary does not exist.
3.
The
structure of the repertory grid which is constructed by the expert is not
imposed as in a questionnaire, but represents the expert’s own construction and
modeling of his knowledge.
4.
The
technique is relatively efficient and easy to use, the expert being able to
define a complete grid with a reasonable amount of time and effort.
Weaknesses
The Repertory Grid Elicitation Technique is impeded in its applications by several weaknesses that are presented in this section.
1.
Some
of the elicited constructs may not be applicable to all the elements.
Using the triadic method to elicit the constructs, the expert can define constructs that are not applicable to all the elements. When the repertory grid contains a large set of elements, it becomes difficult to analyze if a construct that is defined to distinguish among three elements, is applicable to all the remaining ones.
In Figure 2 is shown a repertory grid which compares several news sources.
The system proposes to the expert the elements USA Today, Washington Post and Adevarul in order to distinguish among them. The expert accessed all these sources online and he defines the construct characterizing the internet speed access, expressing the distinction that the first two elements were very rapidly accessed online, compared with the third. However, the source Solia cannot be accessed online, therefore this construct will not be applicable to it.
Figure 2: Evaluation of News Sources
Repertory Grid
2.
A
larger set of concepts require a great amount of effort from the expert.
It becomes difficult for the expert to define all the attributes that distinguish among a large set of closely related concepts. The elicitation process becomes time consuming and may result in an incomplete repertory grid. Even the definition of a single construct to distinguish among a large set of concepts requires the expert’s analysis of all the elements, and the definition of the construct’s values for all the elements.
3.
May
require an elicitation session with both the expert and the knowledge engineer,
to agree on the interpretation of the distinctions created.
The language which is used by the expert to express his knowledge can be ambiguous and elliptic. The constructs defined by the expert may not have a unique interpretation, being sometimes ambiguous. Therefore this technique can require the knowledge engineer to inspect and analyze the elements and the constructs created by the expert. In the case in which the created distinctions are ambiguous, the knowledge engineer guides the expert to assign them a clearer name and meaning.
4.
The
constructs are bipolar, taking only two values.
This limitation becomes difficult to overcome when the expert needs to define attributes having a numerical or nominal scale with a large set of values.
For example, when defining a repertory grid for buying a car, the user can define an attribute that characterizes the place where the cars are produced, distinguishing the elements among themselves. Using the Repertory Grid Technique, the user needs to define a trait with its negation for each country: US/not US; Japan/not Japan; Germany/not Germany. But it would be more convenient to define an attribute “produced-in” with all the possible values: {US, Japan, Germany}.
5. The elements may not be known at the same level of detail.
The elements that are analyzed by the user may not be known at the same level of detail. This will cause problems when the constructs are elicited, because the attributes applied to some concepts will be at different levels of abstraction than those applied to the other concepts.
Let consider the example of defining a repertory grid to evaluate persons for their aptitude to conduct research. For the persons that are very well known, the evaluator can define detailed and specific attributes such as: reasoning speed, profoundness in thinking, intuition. However, for the persons that are less known, the evaluator will define only a general attribute that characterizes the level of intelligence.
6.
The
emphasis on finding the distinctions among the elements can result in missing
important and even definitional characteristics of the elements analyzed.
Let consider the repertory grid for distinguishing several types of wine, shown in Figure 3.
Figure 3: Comparison of Wines Repertory
Grid
The definitional characteristic that the wines are made of grapes is missing from this repertory grid. The accent on defining attributes to distinguish among the elements from a domain may result in omitting attributes that characterize these elements.
7. This
method does not capture procedural or causal aspects of expert knowledge.
The elicited constructs have no clear usability in the problem solving process, and generally capture only declarative knowledge. Therefore, the repertory grid methodology is mostly applicable to analytic expert system problems like diagnosis, interpretation, and classification. The technique cannot be applied to synthesis tasks such as design or planning, or to tasks that combine analysis and synthesis, such as monitoring, prediction, and repair.
Several knowledge acquisition systems use the Repertory Grid Elicitation Technique to acquire the information from the subject matter experts. This section will briefly describe some of these expert systems and their applications.
WebGrid
WebGrid is a knowledge acquisition and inference server on the World Wide Web, developed by Gaines and Shaw from the University of Calgary, in Canada (1996). This server uses a repertory grid system for knowledge acquisition, inductive inference for knowledge modeling, and an integrated knowledge-based system shell for making inferences. It supports the development of expert systems based on the Repertory Grid Elicitation Technique.
WebGrid was integrated with APECKS system (Adaptive Presentation Environment for Collaborative Knowledge Structuring), by Tennison (1997), in order to provide a virtual environment in which people who are not in the same place can collaborate. It supports a repeated process of construction and comparison of knowledge representations through which an organizational memory is gradually built.
WebGrid has been used to support collaborative learning activities in undergraduate and graduate courses at the University of Calgary, providing techniques for comparison of construct systems. It enables the collaborative students to explore the similarities and the differences in their constructions of the domain.
The Repertory Grid Elicitation Tool
The Repertory Grid Elicitation tool was developed by Simon White, at the University of Aberdeen, in Scotland (1997). This elicitation tool was incorporated into MUSKRAT, a MultiStrategy Refinement and Acquisition Toolbox, which contains several knowledge acquisition tools and problem solvers. This tool serves to elicit initial knowledge from the expert that is further refined and extended.
DART (Design Alternatives Rationale Tradeoffs)
DART system is an application of the Repertory Grid Elicitation Technique, developed by Boose, Shema and Bradshaw (1990) in order to trade studies in engineering design. This system was initially developed for NASA, to capture design knowledge for the Space Station Freedom program.
This section presents Disciple’s approach in developing the object ontology, based on the exceptions accumulated during the learning process.
To solve complex real-world problems is difficult, because the representation of their domains in knowledge-based systems is generally incomplete. Disciple’s ontology, which represents the generalization hierarchy supporting the learning process, is generally incomplete. The missing or incompletely defined elements from Disciple’s ontology manifest themselves as exceptions to the rules learned by the agent, impeding the efficiency and the accuracy of the problem solving process. When a rule is applied, the solution is verified to not match with one of the negative exceptions of the rule. Also, the positive exceptions need to be generated as solutions. These actions take time, therefore they impede the efficiency of the problem solving process. Also, a negative exception of a rule hints that the lower bound is over generalized. However, being an exception, it does not help in preventing the generation of other incorrect solutions. This will decrease the accuracy of the problem solving process.
Figure 4 illustrates the representation space of a plausible version space condition rule in Disciple.
Figure 4: Plausible Version Space
Representation
The condition of the rule is represented by a plausible upper bound and a plausible lower bound which approximate the hypothetical exact condition of the rule. During the learning process, they will converge towards the hypothetical condition of the rule. The hypothetical exact condition of the rule can contain elements which are not present in the current representation space, requiring its extension with the missing elements. The process of extending the current representation space to a final representation space that completely supports the hypothetical exact condition of the rules is driven by the exceptions of the rules learned by the agent.
The plausible version space rules learned by Disciple can contain exceptions generated by the incompleteness of the representation space. A negative exception represents a negative example that is covered by the plausible lower bound of the rule and any specialization of the plausible lower bound that would uncover the exception would results also in uncovering some positive examples of the rule. A positive exception represents a positive example that is not covered by the plausible upper bound of the rule and any generalization of the plausible upper bound that would cover the exception would result also in covering some of the negative examples of the rule.
During the learning process the exceptions of the rules accumulate themselves, but the agent cannot use them in refining the rules. The rules that contain exceptions are only partially learned, even though we obtain exact condition, in which the plausible lower bound is the same with the plausible upper bound of the rule. The exceptions of these rules are the consequence of the incompleteness of the object ontology.
The solution to these problems is the Exception Handling module, which aims to develop methods to discover and learn ontological elements (new features and concepts) in order to reduce the exceptions of the rules and to improve the completeness of the knowledge base (Tecuci, 1998).
The development and the refinement of the object ontology is a very important phase in the agent development process. The object ontology represents the generalization hierarchy which sustains the learning process. Based on the ontological elements, the agent learns rules which are used in the problem solving process. Therefore, the task of refining and completing the ontology with the missing or incompletely defined elements represents a very important and in the same time a very difficult process. This task requires the understanding of Disciple’s ontology, of how the elements are formalized to best represent the problem application domain. The refinement and development of the object ontology requires the revision of the final ontology, in order to examine if any inconsistencies were introduced. The new elicited information can have implications for the problem solving process, as some rules may become inapplicable after the modifications effectuated in the ontology.
The Exception Handling module can be called in two situations, during the development of the Disciple agent, as shown in Figure 5. It can be called as a local process, in conjunction with Rule Refinement, or it can be called as a global process, being part of the knowledge base refinement phase in the agent development.
Figure 5: Exception Handling in the Agent
Training Process
As a local process, Exception Handling can help the Rule Refinement module, focusing on a single rule with its exception at a time. For example, let consider a rule that generated a reduction which is rejected by the expert, considering it a negative example. The expert calls the Rule Refinement module to explain why this is an incorrect example of the rule. In the case in which the expert cannot find in the current ontology the elements that he needs to express why this is a wrong example, the negative example will be kept as a negative exception of the rule. At this moment, the expert can call the Exception Handling module to analyze this rule and to remove the exception of the rule. The agent guides the expert in the elicitation of new ontological elements that distinguish between the positive examples and this negative exception of the rule. Based on this new elicited knowledge, the rule is refined, by removing the negative exception and keeping it as a negative example. The object ontology is also refined to incorporate this new elicited information from the expert.
Exception Handling can also be part of a global process of knowledge base refinement. Instead of focusing on a single rule with its exceptions at a time, the goal is to analyze all the rules with exceptions from the current loaded knowledge base, or from all the knowledge bases which have rules with exceptions. First each rule with exceptions is analyzed, in order to discover new concepts or features that would reduce some exceptions of that rule. Based on these ontological elements discovered, conceptual clustering and generalization techniques can be used to define a minimal set of concepts and features, each one reducing exceptions from several rules. These concepts and features can be elicited in a mixed-initiative manner from the expert, or they can be imported from external ontologies, using the ontology import module. These ontological elements can also be transferred from previously developed Disciple object ontologies.
Exception Handling is a mixed-initiative process between the expert and the knowledge engineer, which consists of the following two phases:
Phase I: Automatic Candidates Determination
Find
features or concepts candidates that can solve the exception
Order
the candidates based on the estimated cost of the elicitation interaction with
the expert
Phase II: Interactive Knowledge Elicitation
Interact
with the expert to select a candidate
Guide
the expert in the elicitation of new knowledge about the selected candidate
Refine
the ontology and the rule to incorporate the new elicited information
In the automatic candidates determination phase, the agent analyzes the rule with its exception, in order to find candidates of type feature or concept that can solve the exception. The agent searches in the ontology for pieces of knowledge that distinguish between the positive examples and the exception of the rule. In the case of a rule with a negative exception, it looks for features that characterize all or most of the objects from the positive examples, and which do not describe the object from the negative exception. In a similar way, the agent can look for a concept in the ontology that covers the objects from the positive examples without covering the object from the negative example. It can also be the case in which the agent finds in the ontology pieces of knowledge that characterizes the object from the negative exception, without being applicable to the objects from the positive examples. This piece of knowledge will represent the basis for an except-when condition of the rule, which the positive examples must not satisfy. To each of the candidates that are automatically determined by the agent is associated an estimated cost of the elicitation interaction with the expert. The candidates are ordered in ascending order based on the estimated cost of the elicitation effort, and are presented to the expert to be examined.
In the interactive knowledge elicitation phase, the expert interacts with the system to select a proposed candidate in order to remove the exception of the rule. For each candidate which is selected by the expert, the system presents a detailed description explaining the candidate. After the expert selected a candidate, he is guided by the agent in the elicitation of new knowledge about it. For example, let consider a rule with two positive examples and a negative exception that needs to be reduced. The expert selects as candidate the property P which is defined for one positive example. The expert enters in the elicitation dialog with the system to completely define this property for all objects from the positive examples and from the negative exception to which the property P applies. The expert gives the value of P for the second positive example, and expresses the fact that this property is not applicable to the negative exception. Based on this new elicited information, the rule is refined, adding the condition that the objects from the positive examples must have the property P with one of the values given by the expert. The negative exception is removed from the rule, being kept as a negative example. The ontology is also refined, to incorporate this new information provided by the expert.
The Mixed-Initiative Exception Handling module in Disciple exhibits the following strengths:
1.
Develops
methods to discover and learn new ontological elements in order to reduce the
exceptions of the rules.
2.
Supports
and extends a complex knowledge representation, by refining the ontology and
helping the rule refinement process.
3.
Helps
in improving the rules competence and the problem solving efficiency.
Weaknesses
The Mixed-Initiative Exception Handling module in Disciple exhibits the following weaknesses:
1. The process of finding the ontological knowledge that is needed in order to remove the exceptions of the rules requires the expert’s understanding of the ontology.
In order to discover the elements that are missing or incompletely defined in Disciple’s ontology, the expert needs to analyze the ontology and to understand how the knowledge from the problem application domain is formalized. This requires a minimal familiarity of the expert with the representation of knowledge in a knowledge-based expert system.
2. The process of developing the ontology with the elements needed to remove the exceptions of the rules generally requires the assistance of a knowledge engineer, to help the expert in defining the knowledge that he has in mind.
Even though the expert may become familiar with Disciple’s object ontology and may understand how the knowledge is formalized, the process of correctly and completely defining new ontological elements requires complex operations and a great amount of effort. The expert may need to be assisted by a knowledge engineer in order to define these new ontological elements. After the modifications of the ontology, the knowledge engineer should verify the ontology, for any inconsistency that might have been introduced.
Both the Repertory Grid Elicitation Technique and the Mixed-Initiative Exception Handling in Disciple have the goal to elicit knowledge from the expert to differentiate between some elements or examples in a problem domain.
A synthesis of the comparison between these two approaches is shown in Table 1.
Table 1
: Comparative Study
One criterion to compare the Repertory Grid Elicitation Technique and Exception Handling in Disciple is the complexity of the elicited knowledge from the expert. In the Repertory Grid approach, the elicited knowledge is relatively simple, consisting in elements and bipolar constructs. In the Exception Handling approach, complex knowledge is elicited, such as features and concepts which are represented in a semantic network.
From the point of view of the complexity of the internal knowledge representation, in the Repertory Grid approach is required a simple knowledge representation, to support the elements and the elicited constructs, and the rules generated through entailment analysis of the constructs. In the Exception Handling approach, the internal knowledge representation is complex, consisting of a hierarchical organization of the object ontology and complex plausible version space rules.
In the Repertory Grid approach, the process of eliciting knowledge from the expert is very intuitive and the acquisition of elements and bipolar constructs to distinguish between the elements can easily be done by an expert. In the Exception Handling approach, the elicitation process is very complex, and can require the assistance of a knowledge engineer. This process requires a minimal understanding from the expert of Disciple’s ontology and representation of knowledge. The operations required to define the new ontological elements are very complex and have implications for the entire learning and problem solving process. Therefore, the modifications performed in the ontology must not create inconsistencies. The revision of the knowledge base to check if any inconsistencies were introduced can only be done by a knowledge engineer.
In conclusion, the Repertory Grid approach excels in simplicity, the expert being able to easily define the knowledge that is needed. However, the knowledge elicited from the expert is relatively simple, and cannot support a very complex problem solving. The Exception Handling approach excels in the complexity of the knowledge elicited from the expert, and in the complexity of the knowledge representation supported and extended. The elicitation process is more complex and requires more effort from the expert. There is a trade-off between the complexity of the knowledge acquired and the elicitation effort.
Based on the comparative study of these two knowledge elicitation approaches I will present some new research ideas that can be further explored in developing the Mixed-Initiative Exception Handling capabilities in Disciple.
One of these directions focuses on developing two Exception Handling tools and methodologies for discovering and learning new objects and features that will reduce the exceptions of the rules and of the learned knowledge pieces. The capabilities of these two methodologies and tools are described below.
One methodology and tool will allow a subject matter expert to define new ontological elements without needing the assistance of the knowledge engineer. This tool will provide limited capabilities, but will require simpler operations that can be performed only by the subject matter expert. This tool will allow the expert to define new features values or relationships between objects, for features which are already defined in the ontology. The tool will allow the expert only to partially define new features or concepts, requiring further revision by the knowledge engineer. This tool will require from the expert only a limited understanding of Disciple’s ontology and internal representation of knowledge. The tool will require no assistance from the knowledge engineer, requiring simpler ontology development operations that will reduce the exceptions of the rules.
The other methodology and tool will provide advanced capabilities to define new features and concepts, to modify and delete concepts or features in the current ontology, and to reorganize the structure of the ontology, in order to remove the exceptions of the learned knowledge pieces. This tool will require the assistance of a knowledge engineer, to encode the knowledge that the expert uses in differentiating between the objects from the examples and the objects from the exceptions. This tool will require from the expert only a limited understanding of the Disciple’s ontology, because he will be assisted by the knowledge engineer in performing the complex operations.
Both methodologies and tools will emphasize the knowledge visualization during the elicitation process. When the expert needs to define a feature value for an object, the fragment of the ontology containing the object and its features can be shown. This will facilitate the analysis of the current represented knowledge and the acquiring of new knowledge that is necessary. Both methodologies and tools will emphasize the role of on-line analysis and feedback during the process of knowledge elicitation.
The other direction is to find a more intuitive and more natural elicitation process, when acquiring the knowledge from the subject matter expert. The elicitation of knowledge from the expert may be done using an adaptation of the triadic method. When the rule that is analyzed has many positive examples and/or many exceptions that need to be removed, only few representative ones can be selected by the system in order to be shown to the expert. In this manner, the elicitation of new features/concepts that distinguish among these representative examples becomes easier. The system can also allow the user to select his own representative examples if he considers them easier to analyze than the examples shown by the agent. The Exception Handling module should analyze all the examples and all the exceptions of the examined rule, and it should propose to the user the candidates that apply to all/most the examples, in order to minimize the elicitation effort.
Boose, J. H., Shema, D. B., Bradshaw, D. M. (1990). Capturing Design Knowledge for Engineering Trade Studies. Wielinga, B., Boose, J, Gaines, S., Schreiber, G., van Someren, M., Ed. Current Trends in Knowledge Acquisition. pp. 78-89. Amsterdam, IOS Press.
Gaines, B.R. and Shaw, M.L.G. (1999). Embedding formal knowledge models in active documents. Communications of the ACM. 42(1), 57-63.
Gaines, B.R. and Shaw, M.L.G. (1997). Knowledge
acquisition, modeling and inference through the World Wide Web. International
Journal of Human-Computer Studies 46(6) 729-759.
Gaines, B.R. and Shaw, M.L.G. (1996). WebGrid: Knowledge
Modeling and Inference through the World Wide Web. Gaines, B.R. and Musen,
M.A., Ed. Proceedings of Tenth Knowledge
Acquisition Workshop.
Gaines, B.R. and Shaw, M.L.G. (1993). Knowledge
acquisition tools based on Personal Construct Psychology. Knowledge Engineering Review. 8(1), 49-85.
Shaw, M.L.G. and Gaines, B.R. (1998). WebGrid II: Developing hierarchical knowledge structures from flat grids. Proceedings of the 11th Workshop on Knowledge Acquisition, Modeling and Management (KAW'98). Banff, Canada.
Shaw, M.L.G. and Gaines, B.R. (1995). Comparing constructions through the web. Schnase, J.L. and Cunnius, E.L., Ed. Proceedings of CSCL95: Computer Support for Collaborative Learning. pp 300-307.
Tecuci, G. (1998). Building Intelligent Agents: An Apprenticeship Multistrategy Learning Theory, Methodology, Tool and Case Studies. London, England: Academic Press.
Tecuci, G. (1999). Collaborative Assistant for Rapid Knowledge Formation and Reasoning. RKF Proposal.
Tecuci, G. (1999). Mixed-Initiative Knowledge Base Development. AFOSR Proposal.