THE DICTIONARY PARADIGM FOR EXTENDING OFFICE SYSTEMSfaculty.wiu.edu/C-Amaravadi/res/ieee.doc  · Web viewKnowledge Management for Administrative Knowledge † Chandra S. Amaravadi.

Knowledge Management for Administrative Knowledge†

Chandra S. Amaravadi

Department of Information Management and Decision SciencesCollege of Business and TechnologyStipes Hall 435Western Illinois UniversityMacomb, IL 61455Ph:309-298-2034Email: [email protected]

Paper Submitted to

IEEE Intelligent Systems

July 2003

------------

†A previous version of this paper was Presented at the Second European Conference on Knowledge Management, Bled, Slovenia, Nov 8th-9th, 2001

Knowledge Management for Administrative Knowledge

Abstract – Administrative knowledge or office knowledge is the knowledge used in conjunction with the support operations in an organization. Systems managing this knowledge are referred to as Extended Office Systems (EOS). EOS will be used to support knowledge exchanges in organizations. The types of knowledge handled by EOS are illustrated and their characteristics highlighted. Based on these characteristics, a formalism is proposed, which utilizes structural and descriptive links to achieve an extensible, open-ended representation. A prototype system using the representation and incorporating approximately two hundred items of knowledge has been developed and can answer questions about a software engineering company.

Index Terms: knowledge management, knowledge management systems, knowledge management models, office information systems, administrative support, administrative knowledge.

I. INTRODUCTION

The explicit management of organizational knowledge or knowledge management (KM)

is increasingly a competitive response in many organizations. Knowledge can exist

implicitly in the form of mental schemas, shared metaphors and experiences or explicitly in

the form of documents, procedures and job descriptions. Much of the KM literature has

focused on the methods to manage the implicit type of knowledge, and includes case studies,

assessment techniques and organizational processes (Hackbarth and Grover, ’99, Mann et al.

’97, Martiny ’98). Comparatively little attention has been given to explicit knowledge and

the technical problems of organizing it. Further, the emphasis in the KM literature has been

on strategic/professional type of knowledge rather than on operational or administrative

knowledge. We define operational or administrative knowledge as the knowledge used in

conjunction with the support operations in an organization such as administering benefits, or

troubleshooting problem accounts (Garvin ‘97). Case studies suggest that employees spend a

significant amount of time in obtaining administrative knowledge. The lack of such

knowledge can seriously hinder office operations. In one consulting firm for instancei,

knowledge of project costing is embedded in the minds of its project managers, preventing

the company from bidding for projects in their absence. We will refer to systems managing

1

operational knowledge as Extended Office Systems (EOS) to denote the fact that this variant

of KM systems will be based on extending existing office technologies.

II. EOS AS A KNOWLEDGE EXCHANGE

In the knowledge management literature, a number of metaphors have been advanced to

characterize the acquisition, storage and retrieval of knowledge. Hackbarth and Grover

(1999), propose accumulating organizational memory in a knowledge repository based on the

framework proposed by Walsh and Ungson. In their conception, the repository consists of

six bins, the individual, information, transformation, structure, culture and ecology which are

organized to facilitate retrieval. Thus they rely on the metaphor of a Knowledge Repository.

Similarly, Glance et al. (1998), introduce the concept of a Knowledge Pump, which collects

and distributes knowledge to employees in an organization. We will use the Knowledge

Exchange metaphor to characterize a similar idea. EOS will function as exchanges to collect

knowledge from office workers and to distribute it to those who need it. Such systems will

be based on the collective knowledge of all office workers, implying that they will actively

contribute to the system; there are unfortunately no tests of completeness due to the

amorphous nature of the commodity. At the same time, as there are no upper limits to the

knowledge, the system must be robust and designed for volume. It is anticipated that for

large organizations an EOS system will handle at least 10,000 items of knowledge. The

participants of an EOS will be both producers and consumers of knowledge and the system

must accommodate this dual role. Since the success of the system will depend upon the

extent to which employees contribute their knowledge, the cost of participation must be

minimal. Correspondingly, the interfaces must be unobstrusive but ubiquitous. Each

transaction with the participant involves either collection or dissemination of knowledge.

Unlike in systems, like EPRINET (Mann et al. ’97) which rely on specialists to enter and

2

manage the knowledge base, knowledge in an EOS will be entered and updated by office

workers. Consequently the system design must accommodate knowledge inputs in the raw

form, viz. natural language. Given the current limitations in natural language processing we

will relax this requirement in this paper and impose a transaction-overhead on users in the

form of manual knowledge editing. The system should also handle incomplete knowledge

since organizational knowledge is often fragmented. Thus in a software engineering context,

a company might know only the budget, the project mission and the scheduled due date of a

particular project. Other details such as the target environment and team composition may be

known later. When accepting new knowledge, the system needs to examine the stored

knowledge to ensure there are no contradictions. We will also relax this requirement in this

paper, as our focus is simply a robust design for administrative knowledge, that can serve as a

foundation for EOS. The principles of an EOS are summarized below:

Principle 1: An EOS will function as a knowledge exchange, collecting, storing and disseminating knowledge. It will have the necessary facilities to support this function.

Principle 2: The scope of an EOS will be defined by its use. Thus the greater the usage the greater its scope. An EOS will be restricted to administrative knowledge.

Principle3: The exchange facilities must be ubiquitously accessible.Principle4: The efficiency of the exchange facilities must be independent of volume of usage.Principle5: Participants in the exchange will be both producers and consumers of knowledge. Principle6: The cost of participation in an EOS i.e. the “transaction cost” must be minimal.Principle7: The EOS must accept transactions in their raw form viz. natural language.Principle8: The exchange facilities must support complete knowledge transactions

whenever possible. Principle9: The facilities must be designed with maintenance in mind, thus they must be

simple, flexible and robust. Principle10: The exchange must be implemented with current and widely available

technologies.

One can readily visualize the external aspects of the system. The EOS will take the form of a

3

knowledge server with a graphical interface that can be ubiquitously accessed from various

applications, including word processing, email and web browsers. The interface will allow

users to access, update and visualize organizational knowledge. Knowledge exchanges will

ideally take place in natural language.

III. THE NATURE OF ADMINISTRATIVE KNOWLEDGE

As important as the topic is, there is a paucity of literature concerning the nature of

administrative knowledge. Lacking empirical evidence, we can infer characteristics based

on the representative examples illustratedii in Table 1. The knowledge is routine, diverse,

fragmented, open ended, dynamic, implicit and potentially contradictory. As evidenced from

Table 1, the number of concepts even within the span of few examples is rather large and

diverse viz. projects, training programs, company visits, van schedules, new recruits,

software tools, ISO-9000, travel arrangements etc. The nature of the knowledge concerns

assertions about these concepts. Yet the knowledge is fairly routine, dealing with day to day

issues of office life. There are interrelationships among the concepts. For instance, item#6,

“Shank arranges the induction program” is related to the concept of training program (in

item #5). The knowledge is incomplete since we do not know the other functions carried out

by Shank. Moreover, the knowledge is subject to change. Van schedules, company visits

and task assignments can potentially change. New concepts can also be introduced such as

for instance, project managers going “on-site.” When a new item of knowledge is

introduced, it can potentially conflict with existing knowledge. At the present time we are

not examining the issues introduced by such conflicts.

Extended Office Systems are intended to fulfill the ever present need of office workers for

operational knowledge of the type illustrated in Table 1. The primary goal of this research is

4

to provide a viable representation scheme for such knowledge without being concerned with

advanced issues such as tense, modality and anaphora. Following the characteristics of

knowledge identified, the scheme will suitably be declarative, relationship oriented,

extensible, open ended and flexible. Popular schemes such as rules and frames will not be

suitable given these characteristics. Frames will be restrictive and will impose an overhead in

terms of unused slots (due to the knowledge being incomplete), while rules lack the

flexibility and the declarativeness necessary for the application. Given these constraints, we

favor the use of semantic networks.

Table 1: Illustrative Examples of Administrative Knowledge

No. Example

1. Every project has a Business Development Manager and a Project Manager.

2. BSS cannot own fixed assets.

3. The Van leaves BSS at 11:00 AM.

4. A project can be initiated by a CEO or by a PM.

5. Induction program is a two day training program for new recruits.

6. Shank arranges the induction program.

7. Mary White, manager of Manugistics, USA, will be visiting BSS on May 3rd.

8. Rangarajan of Man M/C systems is the best C++ instructor.

9. Qualify is an in-house tool to support ISO-9000 procedures.

10. Travel arrangements are made by Allison.

11. The travel agency for BSS is Vacation Travels.

5

IV. KNOWLEDGE ENGINEERING FOR EOS

Semantic nets have been widely used as a vehicle for knowledge representation,

particularly in connection with natural language processing. The semantic net was initially

introduced into the AI literature by Ross M. Quillian, as a way to model associative memory.

The nodes in Quillian’s network stood for word concepts which were pointer-linked to other

word concepts mimicking the way in which humans stored related information. The purpose

of the net was to simulate the human model of associative memory. Inferencing was carried

out by propagating “markers” through the nodes to see if they shared a path in common. For

e.g. in order to find if there is a physical path from “happy” node to a “wealth” node,

markers are propagated through both nodes and if they intersect i.e. visit common nodes (the

“state” of a person), these concepts are considered to be related. Semantic nets are often

preferred as a representation scheme due to the declarativeness of the representation, their

suitability to model concepts and associations and the ease with which inferencing can be

carried out.

Despite their appeal there are several major problems with semantic nets. The first of

these concerns the semantics of the structure itself. Although all semantic nets shared a

node plus link structure in common, they varied greatly in the meanings (semantics) assigned

to these constructs. This is due in part to the different paradigms which were brought to bear

on the problem: Implementational, Linguistic, Logical, Conceptual and Epistemic (Brachman

‘79).

The earliest nets were implementational and linguistic level networks. The former type

networks are simply data structures implemented with pointers, with no semantics as such.

In linguistic nets, the nodes represented word concepts and the links were sometimes logical

6

operators and in some cases, merely pointers. Some types of linguistic nets used links to

denote any arbitrary relationship; these were restricted to binary relationships (Woods ‘85).

In logical networks, nodes represent predicates and propositions (“father-of”, “loves”)

while links represent logical operators such as conjunction, disjunction, subset etc. Logical

notations can be effective but at the expense of notational clarity. For instance, the inclusion

of functions (is-greater-than, father-of) and the special way of handling multi-way predicates

add to the expressive-ness of the net but detract from its comprehensibility. Conceptual-level

networks relied on the case frame approach for representing knowledge. The nodes stood for

verb concepts (such as “buy,” “interview” etc.) while the links stood for the verb cases (such

as object, instrument, recipient etc.). These type of nets assumed a set of primitives thought

to be sufficient to represent natural language but experience has proved that unconstrained

natural language is far too rich to lend itself to any set of primitives (Woods ‘85).

In addition to the variation in the notation of semantic nets, there were other fundamental

problems in the early networks (Woods ‘85). One is a failure to distinguish clearly between

a class and an instance, thereby causing confusion on the part of the interpreter about where

to anchor knowledge pertaining to a general type of object (class) and a specific example of

an object (instance). A second problem was a failure to separate structural knowledge from

assertional knowledge (Brachman ’79). For example, there is a difference in meaning

between a wheel being part of a car and a wheel being punctured. In many of the early nets,

both types of knowledge were captured with the same link, causing problems in network

interpretation. These type of problems were addressed to some extent in Epistemic nets

which are networks with knowledge-structuring primitives distinguishing between structural

relationships and attributes. For instance, in a car, the engine, transmission etc. can be

7

represented as “structural descriptions” while attributes such as color, make etc were treated

as the “roles.” Inspite of these improvements, the focus of these early nets was so much on

addressing semantic problems such as expressing beliefs, negations of beliefs, quantification

etc. that they neglected an aspect critical to Extended Office Systems, namely that of network

organization and appearance. Propositional semantic nets (which represented logical

propositions), Partitioned nets (used set operators as basic constructs), procedural semantics

(a network of goals), KRS (Marcke et. al. ‘87) and KL-One (a system based on epistemic

nets) are all cases in point. In these cases, the profusion of network constructs, their inter-

connections and the esoteric notations that were followed tended to render them intractable.

These limitations of semantic nets in retrospect, can be attributed to a number of reasons,

including: the rather ambitious goal of representing natural language in its entirety, which we

are avoiding here; a failure to recognize the mechanisms which could simplify and structure

the networks such as separating classes from instances, separating structural and descriptive

assertions and assigning proper semantics to the links.

The goals and objectives of our representation (and system) which we are referring to as

AEI-3iii are more modest in comparison with previous efforts:

The primary objective is to manage administrative knowledge, which is being regarded as more manageable than the “competence” type knowledge found in knowledge management systems.

It is assumed that unlike in question answering systems, there will not be an extensive dialog with the users and each session is “stateless” i.e. the system has no knowledge of previous conversation.

As per the philosophy of an EOS, the system must store complete knowledge when possible. Implied structural knowledge must thus be added to the structure if needed. Conversely, the system must handle incomplete knowledge.

The representation is supported with a thesaurus i.e. a synonym finder for purposes of retrieval as well as a suffix table.

Since the objective of the scheme is not to understand natural language, the scheme will not handle intractable problems of representation such as quantification, pronomial reference, assertions about beliefs, tense and adverbs. Similarly it is not considered necessary for the system to understand concepts such as “teaching,” “availability,” “initiates,” etc.

8

In keeping with the nature of administrative knowledge, the scheme must be open-ended, extensible and easy to maintain.

The strength of the system will be in robustly handling large volumes of simple but assorted items of knowledge.

V. REPRESENTATION FOR ADMINISTRATIVE KNOWLEDGE

Earlier, we have characterized administrative knowledge as being routine, diverse,

fragmented, dynamic and implicit. It involves assertions about concepts, which can include

classes, instances and relationships. For instance consider item#9 in Table1: “Travel

arrangements are made by Allison.” This is an assertion/proposition about Allison’s job, viz.

travel arrangements. It is our view that these propositions are of two types (see Table 1).

They can describe the structure (structural assertion) or they can describe any fact about the

structure (descriptive assertion). The former type of propositions are stored with the help of

nodes connected by structural links. Consider for example, the knowledge “Rangarajan is an

instructor.” This is an assertion of a structural relationship, specifically a class-instance

relationship and would be incorporated as such into the representation (See figure 1).

----------------------Insert figure 1 here-----------------------

The fact that Rangarajan teaches DBMS is shown as a descriptive link (“D:teaches”) between

Rangarajan and DBMS. Note that DBMS is an instance of course as shown in figure 1. The

implicit fact that an instructor teaches courses can be recorded by placing a Descriptive (“D”)

link between INSTRUCTOR (class) and COURSE (class). The same comments apply for

any assertion that implies structural assumptions such as “Rangarajan is the best C++

instructor.” The assertion implies that “Rangarajan” is an instructor and must be incorporated

into the representation as a structural assumption (if it is not already stored). Structural

concepts are thus stored with the help of classes, instances and the links between them. A

9

class is represented as a double rectangle, somewhat like the complex entity class of

TEMPORA (Loucopoulis et. al. ‘91) while an instance is simply represented by a rectangle.

Structural concepts are assumed permanent and universal as long as the structures are kept

intact i.e. if a person has been asserted as an instructor, he or she remains an instructor until

the information is deleted. In contrast, it will generally be the descriptive assertions which

will be changed. Nodes can designate classes or instances of classes and extensions (i.e.

what a link refers to) of attributes. Thus if Susan’s availability were to be treated as an

attribute (link), the extension of that is “August.”

There are two types of links, structural (“S”) and descriptive links (“D”). ‘S’ links can

designate any structural relationship such as part-subpart (“has_a”) or class-instance (“is_a”),

while “D” links designate attributes and are defined between classes, instances and/or

“extensions”. In figure 2, note the “D” link between “Allison” and “travel arrangements”

describing the fact that Allison’s job is to make travel arrangements. Allison’s job at BSS is

actually that of a HR Administrator (not shown), but since she is the only HR person doing

travel arrangements, her job appears as a “D link” originating from her node. If all HR

Administrators carried out travel arrangements, the “D link” would appear from the class

(rather than the instance). There are no restrictions on link descriptors (“travel

arrangements”) except that they be minimalist.

----------------------Insert figure 2 here-----------------------

Additional assertions about the structure or assertions involving multiple classes are

made by reproducing the structure and then making the assertion. The fact that Susan is a

new instructor is stored by duplicating the structure INSTRUCTOR Susan and asserting

that she is “New.” Arrows are significant in depicting the direction of the relationship. Thus

if we want to assert that “Mary White” is a manager, we draw an arrow from the MANAGER

10

class to the instance “Mary White.” A query such as “who are all the new instructors?” will

be handled by examining the Instructor class, tracing all its instances and then checking

matching instances in the assertion base. Obviously some types of knowledge such as the

instructor being new, will be invalidated by the progress of time. The duration of validity for

an assertion could conceivably be incorporated into the representation of each. The system

could periodically dump outdated assertions into an archive. The separation between

assertions and the concept relationships is desirable for various reasons including clarity of

representation, ease of maintenance and ease of inferencing.

VI. A PROTOTYPE SYSTEM

A prototype system incorporating the AEI-3 representation scheme was developed in

Visual Prolog 5.1. The system incorporates operational knowledge from a company we

shall call BSS. The semantic network has been implemented with predicates as follows:

Predicate: Link(link label, link type, from node, to node)

Example1: link(is_a, s, company, bss)Example2: link(job, d, allison, “travel arrangements”)Example3: link(is_a, s, “software tool”, “paradigm plus”)Example4: link(ordered_by, d, “paradigm plus”, “IDG group”)Example5: link(is_a, s, “project”, “IDG group”)

The first example asserts the fact that bss is a company. Note the link label (“is_a”), link type

(“s”) and direction of the link (left to right). The second example asserts that Allison’s job is

to make travel arrangements. Note the descriptive link here. The third and fourth examples

assert that paradigm plus is a software tool and that it is ordered by IDG group. Note also

that a fifth fact had to be added regarding IDG group since it was not already described.

Approximately 200 items of knowledge gathered by the author, while at the company are

stored in the system and have been tested successfully. The system is capable of answering a

number of questions about BSS, such as “Who is Allison?” “What does Allison do?,” “What

11

is Manugistics?” “Who is the project manager of IDG?” etc. The user’s query is typed in

natural language, broken down into a list of words and processed by clauses (similar to

modules in a 3rd GL). Clauses are based on expected query patterns to simulate natural

language processing. Example patterns are shown below:

Example pattern1: “Who is responsible for X” where X is a job function.Example pattern2: “Who does X?” where X is a job function.Example pattern3: “What is X?” where X is an inanimate object (company). Example pattern4: “What do you know about X?” where X could be any object.Example pattern5: “How many X does Y have?” where X and Y are objects.

A question such as “what is paradigm plus?” is answered by tracing its structural links (it is a

software tool) and displaying the result. If the question were to be “what do you know about

paradigm plus?,” all the links (“S” and “D” links) associated with Paradigm Plus would be

searched and the results displayed. A simplified version of the clause for this pattern is listed

below (text following % sign are comments):

search_net(what, do, you, know, about, X, Result) :- % the output is ‘Result’

findall(To_nodes, link(_,_,d,X, To_nodes), Child_nodes), % find all nodes connected % to ‘X’ with ‘d’ links findall(D_links, link(D_links,_,d,X,_), D_list), % find list of link labels

list_to_string(X, Child_nodes, D_list, "", Return_str1), % format them for output findall(Nodes_Class, link(_,_,s, Nodes_Class, X), Parent_nodes) % find all nodes connected

% to ‘X’ with ‘s’ links get_prep_list(P_list) % a list of prepositions % ( “is,” “is”,… for s links) list_to_string(X, Parent_nodes, P_list, "", Return_str2), % format for output concat(Return_str2, Return_str1, Result). % combine both strings

Please refer to figure 3 for an example query that involves this clause and the result of

searching the network. The results are formatted and written to a window. At the present

time, updates to the knowledge are handled manually by updating the link predicates.

Planned directions for the system include utilizing Visual Prolog’s built-in database to more

easily manage the knowledge, to add knowledge-browsing and update capability, to add the

assertion base, to web-enable the system and finally to implement the system in a production

12

setting.

----------------------Insert figure 3 here-----------------------

VII. DISCUSSION OF THE RESEARCH AND FUTURE DIRECTIONS

We have attempted to model everyday office knowledge with the assumption that it is

of the utmost operational importance. Our approach takes the form of a structured semantic

network, whose main constructs are classes, instances, “S”, and “D” links and assertions

which involve multiple nodes. The prototype system and the illustration of AEI-3

demonstrate the viability of the scheme. The representation is able to handle simple

assertions such as “Allison makes travel arrangements,” as well as more complex [yet still

mundane] assertions such as item#6 in Table1: “Mary White, manager of Manugistics USA

will be visiting BSS on May 3rd “. As illustrated in Figure 2, this has been broken down into

its descriptive and structural components and represented. “Manugistics” is an instance of

COMPANY and “Mary” an instance of a “Manager” who is an EMPLOYEE of the company.

The timing of the visit is May, which is an instance of MONTH which in turn is an instance

of TIME. Since Mary’s visit is modified both by the timing of the visit as well as the location

to be visited, note the corresponding two “D” links (originating from the node “Mary”) with

the same label, “visits.” Thus, all the facts pertaining to Mary’s visit will be retrieved based

on the “visit” link. If there is a possibility of more than one visit, it will be numbered

consecutively as visit1, visit2 etc.

The conversion of operational knowledge into AEI-3 is subjective particularly when

deciding between whether an item of knowledge is descriptive or structural. For instance,

given that “Fifth P is in the prototyping stage,” (Fifth P is a research project) should one

13

record this as a descriptive assertion or structural assertion? This issue could bear further

investigation. Relative concepts such as Tom’s comments on Mary’s report or that Susan is a

better instructor than Rangarajan lead to the concept of user defined structures.

Implementation of relative concepts will require the user to abstract parts of the structure and

assert the relationship between them. Thus, there will be two propositions, one which asserts

“Rangarajan is an instructor” and another which asserts “Susan is an instructor,” (both are

abridged from the knowledge base) with another proposition between them. Thus the scheme

will have to provide support for user defined structures (essentially boiling down to the

equivalent of higher order logics). Doing this dynamically, i.e. without recompilation, is

probably infeasible with current technologies.

By keeping the network structured, we believe we have addressed the problems of

tractability and comprehensibility. The structure is extensible because new knowledge can be

added easily. For instance we can declare the fact that “Susan teaches DBMS” by adding a

descriptive link between “Susan” and “DBMS.” Additional assertions and classes can also be

easily added. By steering away from case type representations (which would use typed links

such as object, agent, action) we believe we have addressed the open-ended-ness issue.

The clauses demonstrate the ease with which the structure can be navigated. The

network primitives provide an index into the structure and thereby facilitate retrieval. If the

system is asked a question, “Is Rangarajan available in March?” it retrieves the substructure

corresponding to Rangarajan’s availability, finds out that there is an empty node and then

searches the assertion base, finding that Rangarajan is not available March 5th. Similarly if

the system were asked about what courses are taught by “Susan”, it retrieves the instance of

Susan and attempts to see if any of its descriptive links matches with teaches, which in this

14

case there are none. It is evident from this discussion that the proposed knowledge structure

facilitates inferencing.

Because of its attempt to represent knowledge, the research bears comparison to many

different modeling paradigms including: ER approaches such as the ERT model

(Loucopoulos et al. ‘91), semantic models such as conceptual structures (Sowa ‘84) and CD

theory, knowledge representation languages such as Krypton and KRS (Marcke et al. ‘87).

The fundamental differences between these and AEI-3 lie in the target domain and the type of

constructs employed. For instance, the ERT approach was utilized to model rules in a

database environment, while CD theory was employed to understand natural language. The

type of constructs employed in the representation (“S” links and “D” links) is unique to

epistemeological networks. We are not aware of any research within the knowledge

management stream which has addressed the problem of administrative knowledge.

Based on our goals and design criteria, and based on the prototype and qualitative

evidence presented, AEI-3 appears viable. However, from a knowledge representation

standpoint there are several shortcomings (please refer to Table 2). The system does not

handle beliefs, tense, modality and pronouns. For instance it would be difficult to completely

express an item of knowledge such as “He believes that X makes good decisions.” The

representation also cannot distinguish between these two statements: “Mary visited with the

Pilot team yesterday” and “Mary will visit the Pilot team today” unless the statements were

expressed in absolute time terms (July 3rd, July 4th etc.). Further the system does not

effectively handle conjunctions/disjunctions such as “Projects can be initiated by a CEO or a

Project Manager.” Whether or not such capabilities are important for an EOS will need to be

established via empirical studies of office knowledge.

15

While we have attempted to establish semantic adequacy and inferential adequacy

within the parameters that were specified at the outset, there is an abundant amount of

research still to be carried out. The research seems to warrant a production implementation to

establish that AEI-3 system can handle large volumes of knowledge and that the manner in

which the knowledge is stored and retrieved is useful. The knowledge engineering task even

for the types of knowledge illustrated are substantial since each item has to be represented at

the atomic level. There will be practical difficulties in surfacing the knowledge and storing it

in the system without having contradictions. We have not focused on algorithms for storing

and updating the knowledge and this in itself is an important research direction. Lastly, in

production implementations, it will be necessary to have mechanisms for tracking the

contribution of each participant and for monitoring the usage of knowledge. Research is

under way to address these issues.

i Based on personal observation in a software consulting company we will refer to as BSS.ii These samples have been gathered by the author while at BSS.iii We will refer to the prototype and representation scheme as AEI-3 as this is a continuation of earlier work, motivated to model Agents, Entities and Information. Refer to Journal of Management Information Systems, summer 1992 for more details.

16

Table 2: Qualitative Evaluation of EOS-KM

Representation feature Comments

Classes/instances

distinguished?

Yes

Semantics for links? Yes, limited to structural and descriptive links.

Network partitioned? Partitioning is governed by presence of relationships among

concepts. Qualitative assertions are partitioned.

Structural/descriptive

assertions distinguished?

Yes, additionally qualitative assertions are separated.

Conjunctions/disjunctions? Not effectively.

Incomplete knowledge? Yes

Probabilistic knowledge? No

Beliefs, tense and modality? No

Pronomial references No

Quantification Can express number as a “D” link and an instance of the

class of numbers.

Relativity among concepts Feasible with the use of user-defined meta-classes but not

discussed at the present time.

17

Fig1. The basic constructs of AEI-3

18

S: is_a

D: teaches DbmsRangarajan

COURSE

S: is_a

Legend:

--- Class S: structural link

--- Instance D: descriptive link

INSTRUCTOR

D: teaches

Fig 2: A more detailed illustration of AEI-3

S: has_aS: is_a

S: is_a

D: availability

19

D: visits S: is_a S: is_aS: is_aS: is_a S: is_aD:availability

FIG 1: ILLUSTRATION OF EOS-KM

D: visits

D: availability

D: teaches

D: teaches

D: Job

D: works with

S: is_a

D: visits

S: has_agency

S: has_a

S: is_a

S: is_a

S: is_a

S: is_a

S: is_a

S: is_a

S: is_a

S: is_a

S: is_a Bss

Allison

C++

Manugistics

EMP.

EMP.

RameshTravels

TravelArrang-ements

Rangarajan

TIME

COURSES

MaryWhite

INSTRUCTORMANAGER

Susan

May

MONTHAugust

S: is_a

S: is_a

S: is_a

S: has_aS: is_a

D: availability

Dbms

?

COMPANY

(a)

(b)

Fig. 3: Screen Shots of AEI3. (a) sample query to the system, (b) sample response from the system.

20

REFERENCES

Brachman, Ronald, J., (1979). “On the epistemological status of semantic networks,” in Findler, Nicholas, Associative Networks: Representation and Use of Knowledge by Computers, Academic Press: New York, pp. 3-50.

Garvin, David (1997). “The processes of organization and management.” Sloan Management Review, 39(4), pp. 33-50.

Glance, N., Arregui, D., and Dardenne, M. (1998). “Knowledge pump: supporting the flow and use of knowledge” in Borghoff Uwe M., and Pareschi, Remo (Eds.). Information technology for knowledge management. Springer Verlag, pp 35-51.

Hackbarth, Gary, and Grover, Varun (1999). “The knowledge repository: organizational memory” Information Systems Management, Summer 1999, 16,3, 21-35.

Loucopoulos, P., McBrien, P., Schumacker, 'F., Theodoulidis, B., Kopanas, V., And Wangler, B. (1991). Integrating database technology, rule-based systems and temporal reasoning for effective information systems: the TEMPORA paradigm. Journal of Information Systems, Vol. 1, No. 4, pp. 129-140.

Mann, M. M., Rudman, R. L., Jenckes, T. A. and Mc Nurlin, B.C., (1997). “EPRINET: Leveraging knowledge in the electric utility industry, in Prusak, L. (Ed.) Knowledge in Organizations, pp. 73-97. Butterworth-Heinemann: MA.

Marcke, K. V., Jonckers V., Daelemans, W. (1987). Representation aspects of knowledge based office systems. In Esprit 87, Achievements and Impacts. New York: North Holland, 1226-1238.

Martiny, Marilyn, (1998). Knowledge management at HP Consulting, Organizational Dynamics, 27,2 71-77. Sowa, J. F., (1984). Conceptual Structures: Information Processing in Mind and Machine, Addison Wesley.

Woods, William A., (1985). What’s in a Link?: Foundations for Semantic Networks, In Brachman R.J. and Levesque, H. J. (ed) Readings in knowledge representation, Los Altos, CA: Morgan Kaufman Publishers, 218-241.

END NOTES

21