| 您的位置>>>首页>>>在线学习>>>知识管理>>>TAPS: Knowledge Management System |
|
|
 |
TAPS: Knowledge Management SystemDickson Lukose1, Said Nechab1, Simon Pritchard2, Ashley Lee2, Sajid Hussen2, Jon Clawley2, 1Brightware
Inc., 90 Park Avenue, Suite 1600, New York, NY 10016, USA Email:Dickson.Lukose@brightware.com Abstract In this paper, we describe the architecture and the knowledge modelling techniques developed in the Total Asset Planning System (TAPS). TAPS is composed of a suite of highly interactive graphic based corporate knowledge modelling tools, a flexible knowledge based server, and a knowledge base management system. By using this knowledge modelling environment, a knowledge engineer or a domain expert can build very sophisticated knowledge based systems without writing a single line of code in a conventional Artificial Intelligence (AI) programming language. Several applications have been built using this suite of tools, and several more are in development at the time of writing this paper. 3.1.
Architecture
3.2. Client-Server Interface 3.3. Request Management 3.4. Knowledge Base Constructors
Increasingly, companies are striving to become an organisation that knows how to do new things well and quickly, to enable itself to be locally and globally competitive. To this end, these companies are engaging in the area of Knowledge Management on many facets. Corporate knowledge modelling, engineering, maintenance and transfer of these knowledge bases have been the major emphasis of many progressive companies around the world. The challenges faced by many of these companies are the attrition of their domain experts, and the realisation that knowledge may be a company's greatest competitive advantage. To overcome some of these problems, companies are engaging in the development and use of highly sophisticated knowledge tools and practices for the generation, codification and transfer of corporate knowledge. Some of the contemporary methods and tools for Corporate Knowledge Management can be found in Dieng et al (1998). Knowledge Generation requires tools that can aid in the acquisition, synthesis, and creation of knowledge. The result of knowledge generation activities should to be made available to others in the organisation to realise the full benefits of the knowledge management process. To this end, Knowledge Codification enables the representation and transfer of corporate knowledge. Knowledge tools required for this purpose typically must be able to codify process knowledge and factual knowledge. Several interesting knowledge modelling methodologies (Wielinga et al, 1993; Steels, 1990; Chandrasekaran and Johnson, 1993; Martin, 1993) have been proposed to meet the challenge. Several corresponding knowledge modelling languages have also been proposed (eg., MODEL-K (Karbach and Vob, 1993); TIPS (Punch an Chandrasekaran, 1993); MODEL-ECS (Lukose, 1995)). In recent years, there has been a growing interest in visual knowledge modelling languages and environments (Gaines, 1991; Lukose, 1993; Kremer, 1998). In particular, considerable efforts have been dedicated to developing tools and techniques for executable graphical (nodes and arcs based) knowledge modelling languages. Among them, include the work of Lukose (1993, 1994, 1995, 1996, 1997, and 1998), Kabbaj (1995), Kremer (1995), and Bos et al (1997). In this paper, we will describe the Knowledge Management System called TAPS (Lukose, 1998e), that was developed for a major UK water utility company. This tool takes advantage of the graphical notation developed by Martin (1993) for modelling business process, and the executable knowledge modelling techniques developed by Lukose (1993..1998) for the realisation of an executable knowledge base systems. This Knowledge Management System is composed of a suite of highly interactive graphic based corporate Knowledge Modelling Tools, a flexible Knowledge Base Server, and a highly sophisticated Knowledge Base Management System. By using this Knowledge Management System, a knowledge engineer or a domain expert can build sophisticated knowledge based systems without writing a single line of code in a conventional AI programming language (like Prolog, Lisp, ART Script, Clips, etc). Several applications have been built using this suite of tools, and several more are in development at the time of writing this paper. The conceptual view of the TAPS Knowledge Management System is outlined in Figure 1. The outline of this paper is as follows: Section 2 outlines the Knowledge Modelling Tools, Section 3 describes the architecture of the Knowledge Base Server, and Section 4 will describe the Knowledge Based Management System. Finally, Section 5 will describe an application that was built using this tool set, and we conclude this paper in Section 6 by outlining the direct benefits of using this toolset for developing knowledge base systems.
The Knowledge Modelling Tools allow the knowledge engineer or domain expert to define a Business Model for a particular application. It consists of a series of GUI driven editors (Pritchard, 1998; Pritchard and Clawley, 1998), which enable the definition of entities which makeup the business model (i.e., process, object, calculations, and rules). The key to the application development using the TAPS Knowledge Modelling Tools is the underlying Business Model that can evolve over time. This is achieved by providing the users with self-sufficiency via this highly sophisticated GUI environment to enable them to define and change the Business Model, rather than hard-coding them in a conventional AI programming language. The graphical notation developed by Martin (1993) and the knowledge modelling techniques developed by Lukose (1995, 1996) has been the corner stone in the development of this tool set. A Business Model consists of the following inter-related sub-models:
Figure 2 shows the Business Model, and the inter-relationships of its sub-models. A Process Model is made up of many activities arranged using conventional control structures, and the actions of each activity are defined in terms of rules. In short, we can say that a process is made up of many rules, and a rule is defined using many Objects, Calculations and Messages. Each of these sub-model are built using the respective GUI based editor. In the next section, we will describe the architecture of the Knowledge Modelling Tool A generic, yet simple, architecture has been adopted to implement the Knowledge Modelling Tool. For each of the entity types (i.e., process, object, rule, calculation, and message) that form the business model, there is a corresponding GUI based editor. All these editors are inter-linked and use the data from one another to build up the business model (with all the different entities linked together in a manner outlined in Figure 2). Figure 3 depicts the architecture of this Knowledge Modelling Tool. The main objective of the editors is to provide ease of use for the business user, they facilitate the liberation of the business knowledge from the domain experts thus widening the overall knowledge base of the clients company. As shown above the editors are split into five main areas:
The Process Editor allows the user to produce diagrammatic representations of business process logic. Figure 4 depict the Process Editor. We developed a new stencil on VISIO6.0, and implemented a compiler that will compile the diagram (perform syntax and some semantics checking), and produce a compiled version of the diagram and stores it into a database table. The Process Constructor (described in Section 3.4) will load them into the Knowledge Base Server and produce appropriate ART script representation of the business process. Process Model is made up of activities, events, and triggers (Martin, 1998). In this implementation, the Process model is build using the high-level graphical notations, representing the different types of vertices and edges, as shown in Figure 5. For every ACTIVITY icon (also known as terminal node) that is used in a Process Model, you will need to specify an ACTIVITY NAME and an EVENT NAME. In Figure 5, the ACTIVITY icon has the name ACTIVITY-ONE, and itil event name is ACTIVITY-ONE-EVENT. For every ABSTRACT-ACTIVITY icon (also known as the non-terminal nodes), you will have to specify three items: ACTIVITY-NAME, EVENT-NAME, and SUB-EVENT-NAME. In Figure 5, the ABSTRACT-ACTIVITY icon has the name ABSTRACT-ACTIVITY-TWO, event name is ABSTRACT-ACTIVITY-TWO-EVENT, and its sub-event-name is START-EXPANDED-ACTIVITY-TWO. For every SUB-EVENTS icon you will have to specify the names of the two sub-events. In Figure 5, the names are: SUB-EVENT-ONE, and SUB-EVENT-TWO, respectively. Using the notations outlined in Figure 5, the following modelling constructs can be built:
Each of these are explained further in the following sub-sections.
A Sequential Modelling Construct as shown in Figure 6 will have an activity invoking its event which in turn will trigger another activity, and so on. In this example, the Begin-Sequence activity will invoke the Begin-Sequence-Event event, which in turn will trigger the Seq-Activity-One activity, and so on. The process will terminate when the Abstract-Sequence-Event is reached. 2.3.2. Conditional Branch Modelling Construct A typical Conditional Construct will utilises at least an activity icon, sub-event icon, the trigger arc, and the sub-event trigger arc. Figure 7 depicts an example of a conditional construct. Here, the event Conditional-Branch-Event is sub-evented to Condition-One-Subevent and Condition-Two-Subevent. In addition, there would be two choice rules attached to the activity Start-Conditional-Branch that will determine which of the two sub-events to choose. The Loop Modelling Construct is quite similar to the Conditional Branch Modelling Construct, except for the trigger arc to loop back to the activity before the SUB-EVENT icon, as shown in Figure 8 (i.e., the trigger resulting from the event Loop-Body-Event connects to the activity Begin-Loop). Figure 9 and 10 depicts the use of an abstract activity and how it expands to a Sub-Process. Note that, how the final activity of the Sub-Process invokes an event that is identical to the event that will be invoked by the abstract activity. This is the technique used to return control to the parent (abstract activity). In the example (shown in Figure 9, the abstract activity A2 expands to the process model shown in Figure 10. Note that the final event in Figure 10 is E2, which is also the name of the event resulting from the abstract activity A2). So, when the processor reaches event E2 in Figure 10, it is equivalent to reaching event E2 in Figure 9).
The Calculation Editor (ref. Figure 11) allows the creation and modification of calculations for use in both the left-hand side (LHS) and right-hand side (RHD) of rules. They are used in the premise side for testing against attribute values and are used in the consequence side for setting attribute values. Calculations can be created which contain parameters, which are set to the value of an instance attribute, when the calculation is used in a rule. Any pre-existing calculation can be nested in a new calculation and parameter values can be passed to the nested calculation. There is also a range of built-in mathematical functions, which can be used in building calculations that are more complex. The Calculation Editor stores a calculation in both the infix as well as the prefix form. The original calculation is written in prefix form, and it is also converted by the Calculation Editor into the prefix form, as shown in the example below: Original calculation: Parameter1 / ceiling ( [ 56.55 ] ) - cosh ( [ 56 + Parameter1] ) ART script calculation: (/ ?Parameter1 (- (ceiling 56.55) (cosh (+ 56 ?Parameter1)))) The Calculation Editor also checks the syntax of the calculation, thus limiting the chance of errors like missing brackets or the wrong use of operators and system defined functions.
Objects exist in a hierarchy, and each object has a set of attributes. Some of these attributes, we need to specify possible values. This forms the ontology of the business we are modelling. The Object Editor (ref. Figure 12) allows new objects to be added, and attributes to be added to exiting objects, as well as enabling the definition of possible values for the attributes. The editor also enables the user to specify the inheritance characteristics of a new object. The definition of the Object Model will be the very first thing done in building a Business Model. That is, once the domain is analysed, the Data Model (logical and physical data model) and the Object Model is defined. Data Model to represent the data that will be processed by the knowledge based system, while the Object Model represents the objects that will be manipulated by the rules and calculations. The mapping between the objects in the Object Model to the relations in the Data Model is achieved via the use of the Knowledge Base Management System (refer to Section 4). Also one need to realise that when this tool set is to be used in a different domain, we will have to build up the Object Model of that domain. The tool set is a generic system which only provided all the necessary functionality to enable a user to take it over to a particular domain and start building the Business Model by first building up the Object Model.
The Rule Editor ties together process, objects, calculations, and messages. The type of rules you can build are constrained by what may be created using the Rule Editor. Rules consist of two parts: "Whenever" and "Then do". Existing objects and attributes are dragged and dropped to either side. For example, the rule depicted in Figure 13 states the following: WhenEver: A
Unitil Demand > Tolerance (via a calculation)
ThenDo:
Set
the Unitil Demand-Capacity-ShortFall == TRUE
There are various allowable combinations on the LHS and RHS of a rule. The full description of all combination is beyond the scope of this paper. In brief, on the LHS of the rule, you can do the follows: specify a particular pattern formed by a combination of Objects. We can use the logical operators to compare the values of attributes of an object to the value of another object, result of a calculation, or to a constant value. Further, we can also specify on the LHS of a rule the a non-existence of a particular pattern by using the negation (NOT). For example: WhenEver: NOT
(A Unitil Demand > Tolerance (via a calculation))
ThenDo:
Set
Unitil Demand-Capacity-ShortFall == FALSE
On the RHS of the rule, we can typically perform the following actions: we can set values of an attribute to a constant, result of a calculation, or to a value of an attribute of another object that is pattern matched on the LHS of the rule. Further, you could also create new instance of an object or destroy an object from memory, as well as specify database transaction action (i.e., import, export, delete, and update) to be performed on a particular object. You can also generate audit messages for general system audit purpose, or for use in the debugging of the Business Model during the development phase.
The Message Editor (Lee 1998a, 1998b) is designed and functions in similar manner to the Calculation Editor, in the sense that we are able to specify the number of parameters in the message to enable us to pass values to the message. Also, we can specify constant values within the text of the message.
The Message Editor (ref. Figure 14) allows the creation and editing of messages for use in the RHS of rules. They are used to provide feedback to the user during/after the run about the values of attributes in a rule. The messages consist of text and parameters. When a message is used in a rule consequence (RHS), the parameters are set to the instance/attribute pair from the rule that the user wants the message to contain. When the rule containing the message fires during a run, the server outputs the message to a table in the database, substituting the selected attribute value for the parameter. A message viewer application can then be used to filter and view the messages.
The Knowledge Base Server is the component in TAPS that compiles the knowledge model (i.e., process, rules, objects, calculations, and messages) into ART script, loads necessary data from the database, and processes them in response to the request from the client application. The Knowledge Base Server is made up of a large number of components, but the components of interest to this paper are listed below:
Figure 15 depicts the architecture of the Knowledge Base Server. In the following sub-sections, we will briefly describe each of the above mentioned components. The Client-Server-Interface allows the Knowledge Base Server to sit behind a web server. Clients can then connect using standard web browser technology. The Client-Server-Interface module is responsible for the creation of TAPS:REQUEST objects when external requests arrives from clients. This is achieved using the TAPS Request Protocol (TRP) in the server. The TRP class definition is built as sub-class of the NET class definitions, and thus inherits the HTTP processing mechanisms provided by the ART Web Integrator. When an HTTP request arrives at the Knowledge Based Server, an instance of trp:request is created (where trp:request is derived from net:http-request). The presence of that instance satisfies the LHS of an ART rule that will fire to start the processing of the request. This transfers control from the built-in ART Web handling of the HTTP request to the Request Management module. The RHS of the rule will do the following:
:request-class
?request-class
:request-id ?request :user-id ?user :scenario-id ?scenario :run-mode ?run-mode :message-switch ?message-switch )
The Request Management manages the multi-user and multi-session capabilities of Knowledge Base Server. As described in Sub-Section 3.2, the Client-Server Interface handles the incoming HTTP request, and converts it into a TRP request. The reason for this two-tier approach is that it de-couples the web integration from the internal handling of requests. Requests may take some time to service, but this architecture will allow for new requests to come in while it is processing an earlier request. The TAPS:REQUEST class is defined as follows: (define-class
TAPS:REQUEST (bc:core pa:request-mixin) (taps:request-id)
(taps:user-id) (taps:scenario-id) (taps:initial-activity) (taps:final-event) (taps:run-mode) (taps:message-switch) )
A TAPS:REQUEST object contains the following information:
This allows differentiation between requests from different users and with different scenarios. Once a user request has been processed by the application, it will be ready to process new requests from the same or different users and with different scenarios. A TAPS:REQUEST also inherits from the pa:request-mixin class.This enables the necessary process animator information to be stored in the request; so the system will know what stage it has reached in the process model. Figure 16 depicts the sequences of activities that will take place in the Knowledge Base Server when a request arrives from the client. 3.4. Knowledge Base Constructors The Knowledge Base Constructors convert the Business Model into appropriate ART script (rules, objects, and functions) that the Knowledge Base Server can execute. There are five constructors, one for each of the sub-models (process, rules, objects, message and calculations) that make up the Knowledge Model. The following sub-sections describe briefly each of these constructors.
The Process Editor compiles the Business Process and stores then as tuples in a relational table. The Process Constructor converts them into appropriate ART scripts. The ART objects created are activity, events, sub-events, and triggers. During the conversion process, the necessary syntax and a limited amount semantic checking is also performed to ensure that a correct model in compiled into the server.
The rules constructor creates ART rules for the user defined rules (i.e., graphical representation of the user define rules stored in the database) (Lukose and Brdar, 1998). During the compilation of the rule, the Rule Constructor ensures that all the objects, functions (calculations), and messages associated to a particular rule is already available in the knowledge base. That implies that Rule Construction is always executed last. A typical rule generated by the Rule Constructor is shown below: (define-rule SAID:DMTWPNoMoreWorksToProcessRule (declare
(salience ?TAPS:*LOW*))
(object
?request
(instance-of
taps:request)
(taps:request-id ?request-id) (taps:user-id ?user-id) (taps:scenario-id ?scenario-id) (pa:focus-of-attention DM_PS_and_TWS_Demand_Processing_Start) )
(instance-of
activity)
(taps:request-id ?request-id) (pa:name DM_PS_and_TWS_Demand_Processing_Start) (pa:connected-to ?event) )
(object
?e
(instance-of
event)
(taps:request-id ?request-id) (pa:name ?event) (pa:type sub-evented) (pa:expansion ?subevents &:(and (is-sequence ?subevents) (member$
DM_PS_and_TWS_No_Works_to_Process ?subevents)
) )
)
(not (object ?BM:PS-AND-T__1 (instance-of
BM:PS-AND-TWS-ENTITIES)
(taps:request-id ?request-id) ))
=> (set-attribute-value ?request pa:chosen-event DM_PS_and_TWS_No_Works_to_Process) (add-entry ?*log* "Execute Rule: SAID:DMTWPNoMoreWorksToProcessRule") )
The Object Constructor identifies the relationships between the Object Model and the Data Model, and creates appropriate Object Class definitions, and Data Integrator Class definitions to enable data mapping to take place (Nechab 1998a, 1998b). It also generates the Object Model and stores it into the working memory. Figure 17 shows the relationship between the Object Model and the Data Model. In brief, the Object Constructor performs the following activities:
The Calculation Constructor converts the user defined calculations (which are stored in the database) into an ART method of the TAPS:REQUEST class (Lukose, 1998a). The calculations are stored internally in both infix as well as in prefix format, along with the calculation parameters (e.g., ?parameter1). The Calculation Constructor simply picks them up from the Calculation Table, and constructs equivalent ART methods. For example, the a infix calculation of the following form: expt ( [ ?parameter1 ], [ 2 ] ) * pi ( [ ] ) / 4 will be converted by the Calculation Editor into the following prefix format: (/ ( (expt ?parameter1 2) * (pi)) 4 ) The Calculation Constructor will build the following ART method: (define-method
Calc1 (TAPS:Request ?taps:request) (?parameter1) (/
( (expt ?parameter1 2) * (pi) ) 4)
)
The Message Constructor picks up the tuples from the appropriate database table (generated by the Message Editor) and converts them into appropriate ART objects and text messages. At runtime, parameter values are passed via the message parameters to enable the server to generate meaningful text for use in debugging the systems, as well as for general audit purpose. 3.5.
Process Animator
Process Animator is a component of the Knowledge Base Server that uses the Process Model (i.e., initially drawn in graphical form and compiled using the Process Editor, then the Knowledge Base Constructor builds corresponding ART representation of the Process Model) to transfer control from thectivity� to thectivity� to realise the business logic. Attached to each the ctivity� is a set of rules that can potentially be executed if their pre-conditions are meet. In other words, executing the rules attached to an activity is synonymous to executing the activity within the overall business logic.
The TAPS Knowledge Base Management Tool has been developed to allow SUPER users (TAPS System Administrator) to manage the Business Models, User Registration, Privilege Assignment, Password Control, and many other related administrative function to smoothly run the TAPS System. Figure 18 outlines the main functions of the TAPS Knowledge Base Management System. User
Management: Database
Management: Environment
Management: Reporting:
The Application Shell is always constructed independently for each of the application that is built. A typical Application Shell will contain the following three components:
When an application's Scenario Builder puts together a job to be sent to the Knowledge Base Server, the user decides which bucket he/she wants the job to be run against. Once the user has selected the bucket, the client application will read the port number of the Web Server. Attached to this port is the Knowledge Base Server that will read the input data from the bucket of interest to the user. The user can send as many tasks as he/she wants, to the same Knowledge Base Server. Figure 19 shows how database bucket management is configured, as well as how the Knowledge Base Server is connected with the Database and the Application. In this diagram, we show four applications: (SAIM - Surface Asset Investment Model (Lukose, 1998c, 1998d; Lukose and Ramjee, 1998), Cost Module (Holtzman, 1999), Scheme Builder, and DM - Demand Module (Husain, 1998a, 1998b). Each of these applications are made up of the above mentioned three components. Once the tasks have been sent off to the Knowledge Base Server, the shell's Progress Monitor will enable the user to continuously monitor the completion status of the task. The Knowledge Base Servers will write it's output data into the OUTPUT Bucket (Lukose, 1998b). On completion of a particular task, the user may use the shell's Results Viewer to view the result.
The Demand Module is required to produce 30-year projections of demand on assets. It produces demand projections for 30 different measures of demand on 5000 assets. Assets are classified according to the nature of the process that they perform and the nature of the future investment planning process (that is modeled in SAIM). Each class of asset has it's own set of relevant demand types which are defined by the engineering design rules that form part of the investment planning process. The model reads raw demand data for all assets in an operational area and a high level reconciliation is then performed with demand forecasts for the area as a whole. This abates the potential discrepancy between top-down and bottom up approaches. Once raw demand data has been processed and reconciled, user defined calculations are used to calculate the design measures for demand (or calculated demand types).
In order to run the model, users create Demand Scenarios that scope the demand model run to one or more types of asset (works groups) and one or more operational areas (counties). The Scenario Builder allows the user to define a scenario (i.e., Specify the districts, Gold Book Version and the list of Works for that scenario) and then send it to the Knowledge Base Server for processing. The server would then load the Business Model defined by the user and run the system.
As well as defining the scenario for the demand run the demand application form allows the user to view the results back from the server. These results are displayed in graph as well as in data form and are illustrated in Figure 21. The graphs and data produced by the demand application can be copied into documents or spreadsheets for reporting purpose.
The toolset described in this paper imposes discipline in developing highly maintainable knowledge based systems. For example, the users will have to define the Object Model in a bottom up approach, while building the Process Model in a top down manner. Once the Object Model is defines, the next thing to do will be to build corresponding data model and link the terminal (leave) objects to the database tables. At this point, all data import and export can be tested. Once we have completed the construction of the Object Model, and have built the Process Model, we are in a position to build the business rules and calculations. All these models are modifiable throughout the developed of the knowledge base system. This toolset enables the user to systematically build and test all components of the knowledge base. In addition to the above capability, this toolset also enable the user to carry out WHAT-IF analysis on a copy of the production level knowledge base. That is, a companies decision support team can carry out test on as many different scenarios (by making changes to the business model) to enable them to identify more suitable business processes and rules. Also, this approach will enable the users to identify consequences of changes to their business, by simulating it using this toolset. This toolset also enables the users to continuously change (evolve) the business model as the nature of their business changes. In addition to enabling the corporate knowledge to be generated, codified, and shared, this toolset enables self-documentation of the corporate asset (their corporate knowledge base), via the graphical notations used in modelling the knowledge base. The use of knowledge engineering in this application has allowed the users to define and expand their understanding of the way company assets are managed. The graphical tools give users a clear way of describing and applying their business knowledge. It is possible now that, under user control, the business process which governs this area can be improved and expanded in line with commercial and regulatory pressures taking into account any developments in technology which reduce overall cost. The ability to play 'what if scenarios' with asset information permits the business to optimize is asset replacement strategy and ensure that money is well spent and effectively budgeted. Our experience in using this tool with teams of 'Domain Experts' has demonstrated an effective and clearly understandable methodology for developing knowledge systems that reflect experts thinking.
Bos, C., Botella, B., and Vanheeghe, P., (1997). Modeling and Simulating Human behaviors with Conceptual Graphs,in Proceedings of the Fifth International Conference on Conceptual Structures Seattle, WA., (appeared as LNAI 1257, Conceptual Structures: Fulfilling Peirce's Dream, D. Lukose, H. Delugach, M. Keeler, L. Searle, and J. Sowa (eds.)), pp. 275 - 289. Chandrasekaran, B., and Johnson, T. (1993). Generic tasks and Tasks Structures: History, Critique and New Directions, in J.M. David, J.P. Krivine, and R. Simmons (Eds.), Second Generation Expert Systems, Springer Verlag, Berlin, Germany. Dieng, R., Corby, O., Giboin, A., and Ribiere, M., (1998)., Methods and Tools for Corporate Knowledge Management, in Proceedings of the 11th Banff Knowledge Acquisition For Knowledge Based System Workshop, Banff, Alberta, Canada. Gaines, B.R., (1991). An Interactive Visual Language for Term Subsumption Languages, IJCAI-91, Sydney, Australia. Kabbaj, Adil (1995). "A General Model of Behavior for Conceptual Graph Theory", in Conceptual Structures: Applications, Implementation and Theory. Kabbaj, Adil, Ed., Berlin. Lecture Notes in Artificial Intelligence: 46-60. Karbach, W., and Vob, A. (1993). MODEL-K for prototyping and strategic reasoning at the knowledge level, in J.M. David, J.P. Krivine, and R. Simmons (Eds.), Second Generation Expert Systems, Springer Verlag, Berlin, Germany. Kremer, R., (1995). The Design of a Concept Mapping Environment for Knowledge Acquisition and Knowledge Representation, in Proceedings of the 9th Banff Knowledge Acquisition For Knowledge-Based Systems Workshop, Banff Conference Centre, Banff, Alberta, Canada. Kremer, R., (1998). Visual Languages for Knowledge Representation, of the 11th Banff Knowledge Acquisition For Knowledge-Based Systems Workshop, Banff Conference Centre, Banff, Alberta, Canada. Lukose, D., (1993). Executable Conceptual Structures, in Proceedings of the First International Conference on Conceptual Structures (appeared as LNAI-699, Conceptual Structures: Conceptual Graphs for Knowledge Representation, Guy Mineau, Bernard Moulin, and John Sowa (eds.), Springer-Verlarg, Germany), Quebec City, Quebec, Canada. Lukose, D. (1994). Planning Knowledge Acquisition Techniques and Mechanisms, in Proceedings of the ICCS'94 Workshop on Knowledge Acquisition using Conceptual Graphs, M.L. Mugnier, M. Willims, B. Gaines and D. Lukose (Eds.), Maryland, USA. Lukose, D. (1995). Using Executable Conceptual Structures for Modelling Expertise, in Proceedings of the 9th Banff Knowledge Acquisition For Knowledge-Based Systems Workshop, Banff Conference Centre, Banff, Alberta, Canada. Lukose, D., (1996). MODEL-ECS: Executable Conceptual Modelling Language, in Proceedings of the 10th Workshop on Knowledge Acquisition for Knowledge Based Systems, Banff, Canada. Lukose, D., (1997). Complex Modelling Constructs in MODEL-ECS, in Proceedings of the Fifth International Conference on Conceptual Structures Seattle, WA., (appeared as LNAI 1257, Conceptual Structures: Fulfilling Peirce's Dream, D. Lukose, H. Delugach, M. Keeler, L. Searle, and J. Sowa (eds.)), pp. 228 - 243. Lukose, D., and Mineau, G., (1998). A Comparative Study of Conceptual graphs, in Proceedings of the 11th Workshop on Knowledge acquisition for Knowledge Based Systems, Banff, Canada. Martin, J., (1993). Principles of Object-Oriented Analysis and Design, Prentice-Hall. Punch, W.F., and Chandrasekaran, B. (1993). An Investigation of the Roles of Problem-Solving Methods in Diagnosis, in David, J.M., Krivine, J.P., and Simmons, R., (Eds.), Second Generation Expert Systems, Springer Verlag, Berlin, Germany. Steels, L. (1990). Components of Expertise, AI Magazine, 11(2). Wielinga, B., Schreiber, A.T., and Breuker, J.A. (1993). Modelling Expertise, in KADS: A Principled Approach to Knowledge-Based System Development, Academic Press, London, UK Vadera, S., and Nechab, S., (1991). Are Expert Systems Shells and Toolkits too general? In Proceedings of the IMACS International Workshop on Decision Support Systems and Qualitative Reasoning, M.G. Singh and L. Trave Massuyes (Eds.), North-Holland, pp. 155-160.
The following reference items are not available for public review. Lee, A., (1998a): TAPS Management Tool Useril Guide, TAPS User Guide, December 1998. Lee, A., (1998b): TAPS Management Tool System Administratoril Guide, TAPS System Guide, December 1998. Lukose, D., and Brdar, A., (1998): TD-17 TAPS Rule Converter, TAPS System Design Document, September 1998. Lukose, D., (1998a): TD-18 TAPS Calculation Converter, TAPS System Design Document, March 1998. Lukose, D., (1998b): TD-50 TAPS Bucket Management, TAPS System Design Document, July 1998. Lukose, D., (1998c): Surface Asset Investment Module System Administratoril Guide, TAPS System Guide, September 1998. Lukose, D., (1998d): Surface Asset Investment Module Useril Guide, TAPS User Guide, September 1998. Lukose, D., (1998e). TD-90 TAPS Architecture, TAPS System Design Document, December, 1998. Lukose, D., and Ramjee, N., (1998): SAIM Prototype Development Report (submitted to STS and STW on 23Novmber1998). Nechab, S., (1998a): TD-53 TAPS Object-Model-Data-Model Mapping, TAPS System Design Document, December 1998. Nechab, S., (1998b): TD-54 TAPS Object-Model-Constructor, TAPS System Technical Document, December 1998. Holtzman, P., (1999): Cost Module Implementation, TAPS System Technical Document, August 1999. Husain, S., (1998a): Demand Module Useril Guide, TAPS User Guide, September 1998. Husain, S., (1998b): Demand Module System Administratoril Guide, TAPS System Guide, September 1998. Pritchard, S., and Clawley, J., (1998): TAPS Business Model Editors User Guide, TAPS User Manual, December 1998. Pritchard, S., (1998): TAPS Business Model Editors System Administratorils Guide, TAPS System Guide, September 1998.
|
