Conference PaperPDF Available

KBS development through ontology mapping and ontology driven acquisition

Abstract and Figures

Thebenefitsofreusehavelongbeenrecognizedintheknowl- edge engineering community where the dream of creating knowledge based systems (KBSs) on-the-fly from libraries of reusable componentsis still to be fully realised. In this pa- per we present a two stage methodology for creating KBSs: first reusing domain knowledge by mapping it, where ap- propriate, to the requirements of a generic problem solver; and secondly using this mapped knowledge and the require- ments of the problem solver to "drive" the acquisition of the additional knowledge it needs. For example, suppose we have available a KBS which is composed of a propose-and- revise problem solver linked with an appropriate knowledge base/ontology from the elevator domain. Then to create a diagnostic KBS in the same domain, we require to map rele- vantinformationfromtheelevatorknowledgebase/ontology, such as component information, to a diagnostic problem solver, andthento extenditwith diagnosticinformationsuch as malfunctions, symptoms and repairs for each component. We have developed MAKTab, a Protege plug-in which sup- ports both these steps and results in a composite KBS which is executable.
Content may be subject to copyright.
KBS Development through Ontology Mapping and
Ontology Driven Acquisition
David Corsar
Department of Computing Science
University of Aberdeen
Aberdeen, UK
dcorsar@csd.abdn.ac.uk
Derek Sleeman
Department of Computing Science
University of Aberdeen
Aberdeen, UK
dsleeman@csd.abdn.ac.uk
ABSTRACT
The benefits of reuse have long been recognizedin the knowl-
edge engineering community where the dream of creating
knowledge based systems (KBSs) on-the-fly from libraries
of reusable components is still to be fully realised. In this pa-
per we present a two stage methodology for creating KBSs:
first reusing domain knowledge by mapping it, where ap-
propriate, to the requirements of a generic problem solver;
and secondly using this mapped knowledge and the require-
ments of the problem solver to “drive” the acquisition of the
additional knowledge it needs. For example, suppose we
have available a KBS which is composed of a propose-and-
revise problem solver linked with an appropriate knowledge
base/ontology from the elevator domain. Then to create a
diagnostic KBS in the same domain, we require to map rele-
vant information from the elevator knowledge base/ontology,
such as component information, to a diagnostic problem
solver, and then to extend it with diagnostic information such
as malfunctions, symptoms and repairs for each component.
We have developed MAKTab, a Prot´eg´e plug-in which sup-
ports both these steps and results in a composite KBS which
is executable.
Categories and Subject Descriptors
I.2.1 [Artificial Intelligence]: Applications and Expert Sys-
tems; I.2.6 [Artificial Intelligence]: Knowledge Acquisi-
tion
General Terms
Algorithms, Design, Human Factors
Keywords
Reuse, KBS, Problem Solvers, Ontology, Mapping, Knowl-
edge Acquisition
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
K-CAP’07, October 28-31, 2007, Whistler, British Columbia, Canada.
Copyright 2007 ACM 978-1-59593-643-1/07/0010...$5.00.
1. INTRODUCTION
A Knowledge Based System (KBS) is an AI system which
imitates human problem solving by applying some form of
reasoning to domain knowledge stored in a knowledge base.
During the 1980s the KBS community recognised several
problem solving methods (PSMs) which they believed could
meet the reasoning requirements of the majority of KBSs
[2]. This perspective initiated a new approach to KBS de-
velopment in which KBSs were built by selecting and con-
figuring various components from repositories. Typically
such repositories would be libraries of domain knowledge,
libraries of problem solvers (PSs), and so on. When a new
KBS is required the developer would select the appropriate
components from these libraries and, preferably with very
little effort, configure them to work together to solve his
problem. Ideally an automated agent or broker would per-
form much of the process for the developer, reducing de-
velopment times and costs. However, despite considerable
research aimed at achieving this dream, it is, for many rea-
sons, still to be fully realised. While various projects strived
to meet this goal, each produced their own approach to the
problem, developed different, often incompatible, technolo-
gies to support their approach; moreover, none of them have
fully executable implementations.
We believe that the primary reasons why previous approaches
were not completely successful was due to a) the lack of a
standard formalism for domain knowledge, b) the lack of
a standard to represent rules, and c) the lack of tools which
allow standardised rule sets to operate over standardised rep-
resentational schema.
Technologies and standards have progressed however, and
OWL1now provides the standard ontology language; ad-
ditionally SWRL2provides a standard which can be used
for defining rule based PSs; and tools such as Prot´eg´e3pro-
vide a mature, extendable framework for both creating and
using ontologies. In fact, Prot´eg´e provides a good envi-
ronment for building a KBS by combining reusable com-
ponents, as it includes extensive import facilities for differ-
1http://www.w3.org/2004/OWL/
2http://www.w3.org/Submission/SWRL/
3http://protege.stanford.edu
23
ent ontology languages along with several reasoning plug-
ins (called tabs) which allow various types of reasoning to
be performed against an (instantiated) ontology. One of the
most mature reasoning tabs is JessTab4which allows Jess5
production rules to be executed against a knowledge base
(instantiated ontology). By using these standards and tech-
nologies, we are able to focus on developing tools for achiev-
ing the rapid re-configuration of a domain ontology, typi-
cally developed for one type of PS, for use with another type
of PS; additionally we do not need to implement a reasoning
engine.
Our methodology for achieving KBS development through
reuse consists of two phases. After selecting a generic PS
and a domain ontology (possibly initially part of an existing
KBS where the ontology has been decoupled), the user maps
any relevant domain knowledge from the domain ontology
into a form usable by the generic PS. The tool’s knowledge
acquisition (KA) process then uses the requirements of the
generic PS and the mapped domain knowledge to guide the
acquisition of the domain specific problem solving knowl-
edge. After completing the KA process, a KBS is formed
from the selected PS, the acquired domain specific rules, and
the appropriate domain ontology. Further, if the domain spe-
cific rules contain new concepts then the KA system uses
these to enhance the corresponding domain ontology.
The mapping stage is a common technique for enabling reuse
of existing domain knowledge from a domain ontology. How-
ever, the focused KA is unique to our approach and is, we
believe, critical to successful reuse, as a domain ontology de-
veloped for one type of PS will not normally contain all the
information required by another. For example, one would
not expect a rule set nor domain ontology designed for a
configuration KBS to contain all the information required
by a diagnostic KBS.
This paper is structured as follows: first we discuss previous
approaches to KBS development which use domain ontolo-
gies/PS configurations; then we outline our approach and the
tool we have built; we then discuss some further implemen-
tation details; provide an evaluation of our tool/methodology;
and conclude with a summary and future plans.
2. RELATED WORK
There have been various projects which have looked at au-
tomatically configuring PSs and domain ontologies: three of
which are PSM Librarian, CommonKADS, and IBROW3.
The EXPECT project, which deals with extending KBSs, is
also relevant. Additionally, Neches et al. [8] provide a good
overview of the challenges faced with this type of KBS de-
velopment, along with possible solutions. For a more de-
tailed discussion of these projects, see forthcoming thesis
[4].
4http://www.ida.liu.se/
her/JessTab/
5http://www.jessrules.com
2.1 CommonKADS
CommonKADS [2, 14] is the result of a major European
project, which focused on developing a complete KBS de-
velopment methodology, encompassing project management,
organisation analysis, and knowledge and software engineer-
ing.
The CommonKADS methodology specifies a process by wh-
ich a KBS is developed through the construction of a prod-
uct model, which describes the state of an organisation after
the planned KBS has been put in place. The product model
is composed of six separate sub-models, one of which, the
expertise model describes the reasoning component of the
KBS. [14, chap. 6] provides outlines for 11 different Prob-
lem Solving Methods (PSMs), including assessment, diag-
nosis, and design. Each outline (template knowledge model)
is composed of: a general description of the method, an ab-
stract specification of the reasoning algorithm, a suggested
domain schema, and sample variations of the method. When
building the reasoning component, the developer selects the
relevant template knowledge model, which provides him with
guidance for implementing the PS, along with the outline of
an example domain KB. The developer then has to imple-
ment the PS, define and populate the domain KB and “as-
semble” the PS and domain model into a working system.
2.2 PSM Librarian
PSM Librarian [5] provides a KBS development methodol-
ogy based on reuse and configuration of domain ontologies
and problem solving knowledge. The methodology is based
on four types of ontology: domain, method (PSM), PSM
description, and mapping; and involves the user selecting a
domain ontology and a method ontology and providing a set
of mappings between the two by instantiating the mapping
ontology.
The domain ontology is a PSM-independent description of
a particular domain, possibly taken from some library. The
method ontology provides a signature for the PSM, describ-
ing the roles and requirements the domain knowledge must
fulfil. Again, ideally the method ontology will be taken from
a PSM library, which is described, accessed and queried
through the PSM ontology. The UPML (Unified Problem-
Solving Method DevelopmentLanguage) meta-ontology [10]
is used to describe the available PSM libraries. The mapping
ontology [11], a mediating layer in the architecture, provides
a bridge between the domain and method ontologies. Once
all mappings have been defined (manually) they can be ex-
ecuted by the mapping executioner sub-system of the PSM
Librarian, with the resulting instantiated method ontology
providing the KB for the PS to reason over. There is cur-
rently no support for executing the configured KBS however.
2.3 IBROW3 Project
The main objective of the IBROW36project was the devel-
opment of an architecture that facilitated an “intelligent bro-
6http://hcs.science.uva.nl/projects/IBROW3/
home.html
24
kering service” to produce a KBS by reuse of “third-party
knowledge-components through the WWW. UPML was de-
veloped to support the definition of knowledge-components
such as domain ontologies, PSMs, PSM libraries and tasks
(problem specifications). The process involved the user pro-
viding the intelligent broker with the description of a task
and domain ontology, the broker would then select a suitable
generic PSM, configure it to work with the user’s ontology,
execute the new KBS, and return the solution to the user.
Due to the challenges of doing all these steps automatically,
the project did not fully achieve its aim; however UPML has
been used by other approaches (including PSM Librarian)
and has contributed to the IRS7(Internet Reasoning Service)
project.
2.4 EXPECT
The EXPECT system [1] supports a user when extending
and customising an existing KBS to fit their requirements.
Typically this involves taking a KBS which works in some
domain, and customising it to work in another by adding
new rules and methods relevant to the new domain. Users
are guided by a series of KA Scripts [15], which ensure all
necessary information is acquired from the user.
2.5 Shortcomings
Although earlier approaches have made significant theoreti-
cal contributions, their implementations were inadequate as
they lack suitable tools and in some circumstances require
the users to perform complex mapping and/or system con-
figuring tasks manually. The CommonKADS approach re-
quires the developer to build multiple models of the organ-
isation (up to six different models are typically required),
each of which can take a considerable time to develop and
require considerable documentation,which can add substan-
tial overheads to the KBS development project [6]. Fur-
ther, due to a lack of good quality support tools, the Com-
monKADS methodology provides the developer with only
minimal support with the difficult task of developing these
models and assembling them into a complete system.
The PSM Librarian approach also has some shortcomings: it
requires the user to provide many mappings with little sup-
port; it does not provide the PS with knowledge from sources
other than the domain ontology; and currently does not ap-
pear to provide/create an executable KBS. The IBROW3 pro-
ject attempted to perform each step in the development pro-
cess completely automatically by having a broker select a
suitable domain ontology and PS and then configure the two
to work together; an ambitious task which we believe is still
unachievable. The EXPECT system provides an environ-
ment for adding and extending methods to an existing KBS
for use in another domain. This requires the user to have a
very good understanding of the original KBS, the methods it
contains and the consequences of adding/changing methods,
which typically requires the developer to be very familiar
with the original KBS implementation.
7http://kmi.open.ac.uk/projects/irs/
3. OUR APPROACH
We have developed a practical methodology for building
KBSs through reuse. Our methodology performs automat-
ically as much as possible, while supporting the user when
he/she needs to make decisions. We have built MAKTab, a
plug-in for the Prot´eg ´e environment which implements our
methodology. MAKTab uses ontology mapping techniques
to suggest possible mappings between the domain ontology
and the chosen generic PS; and includes a guided KA com-
ponent which uses the requirements of the generic PS and
the knowledge acquired from the mapping phase to aid the
user extend the generic PS to their chosen domain.
This approach builds on our previous work on reusing rule
sets with multiple ontologies [3]. In that project, we devel-
oped PJMappingTab, a plug-in for Prot´eg ´e which helps the
user in configuring a JessTab rule set designed for one ontol-
ogy for use with another. JessTab rules must name specific
concepts from the ontology they use: a requirement which
ties them to that particular ontology. PJMappingTab uses
lexical similarity metrics to suggest mappings between the
concepts referenced in a rule set and those in a new ontol-
ogy. After the user accepts the mappings, the original rule
set is updated to reference the concepts in the new ontology;
the resulting system can then be executed.
3.1 Illustrative Example
Throughout this paper, we use the tasks of developing KBSs
dealing with elevator configuration and elevator diagnosis
to illustrate our approach. Elevator configuration has been
used as a KBS task by various projects. Marcus et al. [7] de-
veloped the original system, SALT, and others, such as the
Sisyphus-2 KA Challenge [13] have used it as a way of eval-
uating KA tools and approaches. Both of these projects used
a propose-and-revise PS combined with knowledge of eleva-
tor components to produce design specifications of complete
elevator systems which meets a set of requirements such as
building dimensions, minimum capacity and lift speed. The
propose-and-revise method uses knowledge of components,
their properties, values these properties can have, constraints
on these values, and fixes for violated constraints to produce,
if one exists, an acceptable combination of components. In
outline its algorithm is:
1. Propose a design, if no proposalreturned then exit with
failure,
2. Verify proposal, if OK then exit with success,
3. If unsuccessful, systematically attempt to repair all the
constraint violations with the sets of fixes provided.
To perform this successfully, the algorithm requires three
types of domain specific knowledge/rules, which are used
in its execution:
1. Configuration rules which specify how a list of sub-
components can be combined to form a complete sys-
tem.
25
Figure 1: Outline architecture and algorithm for reusing
the ONT(lift, [diag]) from KBS(diag, lift) with PS(pnr, -)
to produce KBS(pnr, lift), see section 3.1 for more details.
ious components of the configuration.
3. Sets of Fixes which should be applied to remedy par-
ticular violated constraints.
So from this perspective, a KBS is composed of domain
knowledge and problem solving knowledge. For example,
the elevator configuration KBS described above, henceforth
referred to as KBS(pnr, lift) (see Table 1 for our notation),
is composed of two components: an elevator domain ontol-
ogy designed for propose-and-revise,ONT(lift, [pnr]); and a
propose-and-revise PS, PS(pnr, [lift]). The latter is defined
as a rule set which captures the generic propose-and-revise
algorithm (PS-RS(pnr)), an ontology to capture the essen-
tial components of the propose-and-revise algorithm (i.e. the
constraints, the fixes, etc.) namely PS-ONT(pnr, -), and do-
main specific rules, PS-RS(pnr, [lift]).
Elevator diagnosis can also be a complex task, which in-
volves linking observed symptoms to component malfunc-
tions. Again, in our formalism such a KBS, KBS(diag, lift),
contains two components: a diagnostic lift ontology,
ONT(lift, [diag]) specifying components, component mal-
functions, symptoms and possible causes; and the diagnostic
PS, PS(diag, [lift]).
We have acquired a working version of both the KBS(pnr,
lift) and KBS(diag, lift). Both systems were acquired as
CLIPS8KBSs, and we have re-engineered them to work
within the Prot´eg´e/JessTab environment. Both KBSs were
acquired from independent sources; and we have been very
careful not to alter their domain and PS ontologies to avoid
being accused of designing them to work just within our
framework.
8http://www.ghg.net/clips/CLIPS.html
Abbreviation Meaning
PS Problem Solver (PS-RS + PS-ONT)
PS-RS Rule Set which implements a PS
PS-ONT Ontology used by a PS
ONT Domain Ontology
KBS Knowledge Base System (PS + ONT)
pnr Propose-and-Revise
diag Diagnosis
lift Lift domain
PS(pnr, -) Domain independent pnr PS, which is com-
posed of PS-ONT(pnr, -) and PS-RS(pnr)
PS(pnr, [lift]) pnr PS developed in the context of the
lift domain, composed of components: PS-
ONT(pnr, -), PS-RS(pnr), and PS-RS(pnr,
[lift])
PS-RS(pnr) Rule Set which implements the generic pnr
algorithm
PS-RS(pnr, [domain]) Rule Set which implements the domain spe-
cific pnr rules for the domain domain,e.g.
PS-RS(pnr, [lift]) is the set of lift specific pnr
rules
PS-ONT(pnr, -) PS-ONT which defines the concepts used by
PS-RS(pnr) and PS-RS(pnr, [domain])
PS-ONT(pnr, [lift]) PS-ONT which defines the concepts used by
PS-RS(pnr) and PS-RS(pnr, [lift]) instanti-
ated with relevant lift knowledge (compo-
nents and/or rules)
ONT(lift) Lift domain ontology
ONT(lift, [pnr]) Lift domain ontology used by PS(pnr)
ONT(lift’, [pnr, diag]) Lift domain ontology used by PS(pnr) and ex-
tended with knowledge for PS(diag)
KBS(pnr, lift) A KBS using the pnr PSM for the lift domain.
KBS(pnr, lift) is composed of 2 linked com-
ponents: ONT(lift, [pnr]) and PS(pnr, [lift])
Table 1: Definition of the notation used to describe KBSs
in our work.
Our methodology is such that the user should be able to ex-
tract the domain ontology from an existing KBS and rapidly
configure a further generic PS to work with it to produce a
new KBS. Figure 1 illustrates one such example in which
a diagnostic lift ontology, ONT(lift, [diag]) (extracted from
the composite KBS) and generic propose-and-revise(config-
uration) PS, PS(pnr, -) are configured to work together, pro-
ducing a new configurationKBS in the lift domain, KBS(pnr,
lift). Our algorithm for achieving this is to:
1. Split KBS(diag, lift) into ONT(lift, [diag]) and PS(diag,
[lift]) (this is easy in the Prot´eg´e/JessTab implementa-
tions).
2. Map relevant domain knowledge in ONT(lift, [diag])
to PS-ONT(pnr, -) (extracted from PS(pnr, -)), to pro-
duce an initial PS-ONT(pnr, [lift]) (see section 3.3).
3. Use PS-ONT(pnr, [lift]) with the KA tool to acquire
propose-and-revise rules for the lift domain, to produce
an extended PS-ONT(pnr, [lift]) (see section 3.4).
4. Generate PS-RS(pnr, [lift]) from PS-ONT(pnr, [lift])
(see section 3.4.2).
2. Constraints which specify restrictions between the var-
26
Figure 2: Part of the PS ontology for propose-and-revise,
showing the ViolationFixRule.
5. If any new domain concepts are introduced in step 3,
add these to ONT(lift, [diag]) to create ONT(lift’, [diag,
pnr]) (see section 3.4.2).
6. Combine PS(pnr, [lift]) (which is composed of
PS-RS(pnr, [lift]) and PS-RS(pnr)) with ONT(lift’, [diag,
pnr]) to create KBS(pnr, lift) (see section 3.4.2).
3.2 Describing PS Requirements
As described above, every generic PS is composed of two
components: the rule set which provides the implementation
of the generic PS rules and the ontology which defines the
rule components and the structure of the rule set. To be use-
ful, a generic PS must be supplied with domain knowledge,
which the final KBS can use in the reasoning process. We
have developed a simple PS ontology which can be used by
developers to describe PSs. The purpose of this ontology is
to describe the types of domain knowledge it requires and
the domain rules that (when acquired) relate the generic PS
to a particular domain.
Our basic PS ontology extends SWRL, adding a top-level
class for domain knowledge and three classes which MAK-
Tab uses as part of its focused KA phase. Various SWRL
subclasses are used to describe the structure of domain rules
which the generic PS requires. For example, the
PS-ONT(pnr, -) contains a ViolationFixRule class, w-
hich states that if a constraint has been violated, then a par-
ticular fix should be applied. Figure 2 shows the ontology
components which define this rule. ViolationFixRule,
aswrl:Imp subclass, has its swrl:body (rule antecedents)
constrained to be a ViolationAtomList, which only
contains ViolationAtoms which describe a constraint vi-
olation and its swrl:head (rule consequents) constrained
to be a FixAtomList, which only contains FixAtoms,
each of which describe a possible fix for a violated con-
straint(s). These restrictions ensure any ViolationFix-
Rules comply with the “IF violation THEN fix”natureof
the rule. Table 2 provides an example of how this is used to
define a rule.
Instance Type Instance
Name
Property Description
Constraint
c1
exp (cab-weight-total <
motor-supported-weight)
Violation
v
hasConstraint
(c1)
Violation-
Atom
va
hasViolation
(v)
Violation-
AtomList
val
rdf:first
(va)
rdf:rest
(Nil)
Fix
f
hasAction
(upgrade-motor)
FixAtom
fa
hasFix
(f)
FixAtomList
fal
rdf:first
(fa)
rdf:rest
(Nil)
Violation-
FixRule
vfr
swrl:body
(val)
swrl:head
(fal)
Table 2: An instantiation of the ontology shown in Figure
2 to specify the rule that if constraint c1 is violated then
apply the fix which upgrades the motor.
As mentioned previously, the PS ontology has three classes
which the developer can use to provide MAKTab with ex-
tra information for guiding the process of acquiring new do-
main rules. The main class, ProblemSolver,servessev-
eral purposes. Firstly, it provides the developer with a place
to provide a textual description of the PS and how users can
customise it to their domain (importantif the PS is to be used
by non-knowledge engineers); secondly it allows the PS de-
veloper to provide MAKTab with some information about
the PS, such as which rules it should start the KA process
with, and an implementation of any generic PS rules and
functions. For example, in propose-and-revise these include
rules for checking if the goal state has been reached, or if
no further configurations are possible. It also tells MAKTab
which Java class it should use to convert the acquired rules
into an executable format, which allows the developer to in-
clude any generic PS code along with that for the acquired
rules9. The ontology also features a RuleMetaClass class
which can be used for describing interdependencies between
rules. For example, in PS(pnr, -) it is typical to expect each
rule describing a constraint to have at least one associated
rule describing a fix that should be applied if that constraint
is violated. A PSConcept class which is the superclass of
all concepts used by the PS (for example Doors,Motor,
and Cables in the lift domain), is also specified.
We argue that this basic ontology provides a suitable struc-
ture with which generic PSs can be defined; and that these
can later be configured to work with any domain. A further
justification for the design of this ontology, which allows one
to develop additional PSs, is given in [4].
9We provide converters into JessTab format, but this feature allows
future developers to define converters for other formats.
27
3.3 Ontology Mapping
Mapping is the first step in acquiring domain knowledge for
the generic PS. It provides the user with the facility to reuse
any existing domain (ontology)knowledge already available,
in the development of their new KBS. This is achieved by
mapping the knowledge contained in the user’s domain on-
tology to the PS’s ontology (for example, PS-ONT(pnr, -)
in the case of PS(pnr, -)). We expect the main knowledge
acquired from the mapping stage to relate to domain enti-
ties, which are represented by the PSConcept class (and
its subclasses) in the PS ontology, which are then used in
the development of domain rules in the KA stage. The main
challenge for the user in the mapping stage is determining
which concepts in their ontology map to concepts in the PS
ontology, and how these mappings are defined. As such, we
have designed the mapping tool in MAKTab to have a sim-
ple interface, and to be extendable so that we can incorporate
new mapping requirements in the future as needed. In the
remainder of this section, we discuss the mapping tool with
respect to the four criteria defined by Park et al. [11] for de-
scribing ontology mapping tools (these points are discussed
in sections 3.3.1 to 3.3.4).
3.3.1 Mapping Power/Complexity
This refers to the expressive power and complexity of the
mappings supported by the tool. As the number and type of
transformations (mappings) supported is the limiting factor
in this type of knowledge reuse, our tool supports an extend-
able range of mapping types. These include simple transfor-
mations (the renaming of a property); the concatenation of
multiple properties (from a class in the domain ontology)
into a single target (PS class) property; and more power-
ful mappings such as copying a class and class-to-individual
mappings. In the later an individual of a PS class is created
to represent a class (and its associated individuals) of the
domain ontology. This mapping type allows the user to, for
example, specify that all doors (as represented by individu-
als of the Doors class in ONT(lift, [pnr])) have the same
symptoms, malfunctions and repairs and should therefore
be represented as one individual of the PSConcept class
in PS(diag, [lift]). We believe we currently provide a suit-
able collection of mapping types to meet the requirements
of users; the tool has been designed however so that new
mapping types can be easily incorporated as needed.
3.3.2 Mapping Scope
The scope of a mapping defines the range of domain classes
it can be applied to. In order to reduce the number of map-
pings the user is required to define, the user can specify if the
mapping should be applied only to the class it is defined for,
or if it can be recursively applied to that class’s subclasses,
with the option of specifying how deep it should be applied.
3.3.3 Mapping Dynamicity
Dynamicity refers to when and how the mappings are in-
voked. In MAKTab mappings are invoked when the user is
satisfied with the defined mappings, and instructs the tool to
apply them.
3.3.4 Mapping Cardinality
The cardinality of an ontology mapping tool specifies the
nature of the mappings it supports. MAKTab supports N:1
mappings, allowing multiple domain classes to be mapped
to a single problem solver class. This is necessary to allow,
for example, many subclasses of the Component domain
class (such as Door,Motor, etc.) in ONT(lift, [pnr]) to be
mapped to the single PS(diag, -) Component class. N:N
mappings could be supported if required in the future.
3.3.5 Automatic Suggestions
MAKTab aims to reduce the number of mappings the user
is required to provide. Allowing inheritance of mappings
can help; as can automatically suggesting property renam-
ing mappings to the user. MAKTab suggests mappings by
attempting to match class and property names in the do-
main ontology with those in the PS. These suggestions are
produced by three types of equivalence tests: firstly finding
identical names and those pairings with a similarity value,
as determined by the string similarity metrics library Sim-
metrics10, over a user set value; then matching those with
a (user set) percentage of common constituents; and finally
WordNet11 suggests appropriate synonyms. This algorithm
is based on that of PJMappingTab [3]. We recognise that
ontology mapping/matching is an active research field12 and
have designed the suggestion component to be extendable.
Once the user thinks that he has defined all the necessary
mappings for the ontology, MAKTab applies the mappings
to the ontology, converting the instance data into the form re-
quired by the generic PS. The composite KBS is then usually
executed with several typical tests. At any stage the user is
free to return and define/apply more mappings if necessary.
3.4 Focused Knowledge Acquisition
Having completed the mapping stage, a focused knowledge
acquisition process is then used to extend the knowledge
available to the PS. This process uses the requirements of the
PS, specified by its PS ontology, along with the knowledge
gained about the domain from the mapping stage to guide
the acquisition of the additional rules it requires to function
in the chosen domain. Currently the KA process interacts
with a human user who is assumed to be capable of provid-
ing the required information.
3.4.1 Acquiring Rules
The KA tool of MAKTab uses the information provided in
the PS ontology, described above, to guide the acquisition
of the domain specific rules13. This acquisition is based
10http://www.dcs.shef.ac.uk/
sam/simmetrics.
html
11http://wordnet.princeton.edu/
12See http://www.ontologymatching.org for details on
ontology mapping research.
13If the PS developer has not provided information such as which
rules to start KA with or rule interdependencies, MAKTab attempts
to work out interdependencies by examining the restrictions on the
rules’ swrl:body and swrl:head properties it assumes conse-
28
AssignValueRule-1
IF doors-opening-type has no value
AND doors-model-name =“COSS
THEN doors-opening-type IS “centre
AssignValueRule-2
cab-weight-total =
doors-weight +cab-casing-weight +
safety-features-weight
ConstraintRule-1
IF total-cab-weight >motor-supported-weight
THEN assert a violation of this constraint
Figure 3: Example AssignValueRulesand
ConstraintRule for the PS(pnr,-) in the lift do-
main.
on the concepts that have been gained from the mapping
stage (which can easily be added to by the user at any stage
during KA, if required, by creating new individuals of the
PSConcept class or relevant subclass). The KA tool presents
the user with the list of PSConcept individuals that have
been acquired, allowing the user to select one of them and
then start building the rules relevant to it. In the case of
PS(pnr, -), the first rule to be acquired is an AssignValu-
eRule, which describes how to calculate a value for a com-
ponent of the elevator or a variable in the configuration. Fig-
ure 3 shows two example AssignValueRules: first a
simple rule (AssignValueRule-1) for setting the value
of the doors-opening-type and secondly, a more com-
plex one (AssignValueRule-2) for assigning a value
based on values of other parameters. AssignValueRules
are related to ConstraintRules which define the con-
straints on a value, and assert a violation if one has occurred,
such as ConstraintRule-1 in Figure 3. Constraint-
Rules in turn are related to ViolationFixRules, which
we discuss in section 3.2. MAKTab takes the user through
defining each rule in turn, providing suggestions for anteced-
ents/consequents where possible. Typically this involves de-
fining the antecedent of the first rule based on the selected
(PSConcept) individual, then using the consequent of one
rule as the antecedent of a further related rule (if the relevant
type restrictions allow). A sample protocol for acquiring the
rule defined in Table 2 is provided in Figure 4.
3.4.2 Generating the KBS
After all the necessary rules have been acquired from the
user, MAKTab can then generate an executable KBS. It does
this by producing the domain specific PS rules, for example
PS-RS(pnr, [lift]), and converts the swrl:Imp
(sub-)classes’ individuals into executable code, by using a
Java class provided by the PS developer. MAKTab presents
the user with the results of the conversion, for the user to
copy-and-paste into the relevant inference engine (for exam-
ple, to the JessTab text entry window). For completeness we
also allow the user to extend their original domain ontology
quents derive new facts, and any rules which use the same type of
fact (atom type) in their antecedent are thought to be related.
SYS: Creating a new ViolationFixRule. Current antecedents:
Violation hasConstraint (exp (cab-weight-total <
motor-supported-weight)). Add another antecedent?
USER: No
SYS: Currently, there are no consequents. Add one?
USER: Yes
SYS: Creating a new FixAtom. What is the action for this Fix-
Atom?
USER: upgrade-motor
SYS: Created new FixAtom. The current consequents are: Fix
hasAction upgrade-motor. Add another consequent?
USER: no
SYS: new ViolationFixRule created.
Figure 4: The example protocol showing how the KA tool
interacts with the user to build the rule defined in Table
2. As the user enters values, the KA tool creates the rele-
vant instances in the PS ontology.
with the (domain) enhancements made during the KA pro-
cess, when it becomes ONT(lift’, [diag, pnr]).
4. IMPLEMENTATION
We have implemented MAKTab as a plug-in for Prot ´eg ´e;
it provides the functionality outlined above. By extending
Prot´eg´e we are able to take advantage of its extensive import
facilities. Further, it allows us and other PS developers to
take advantage of the plug-ins which allow reasoning with
various inference engines over an instantiated ontology, by
providing rule converters for their chosen inference engine.
We have also implemented the two generic PSs discussed
throughout the paper PS(pnr,-) and PS(diag,-) as sets of Jess-
Tab rules, based on pre-existing KBSs discussed previously.
Both PSs have converters for translating the acquired rules
into JessTab format. Further details will be provided in [4].
5. EVALUATION
We are evaluating MAKTab by using it with our generic
propose-and-reviseand diagnostic PSs to build related KBSs.
Our initial evaluations have focused on the elevator domain;
the developer has successfully built the KBS(pnr, lift) as out-
lined in Figure 1, and discussed throughout this paper, as
well as KBS(diag, lift). The KBS(pnr, lift) contains all the
rules described in the Sisyphus-2specification, and produces
the anticipated valid elevator configuration. We take this as a
positive result that our tool can be used to build functioning,
correct KBSs.
We are performing a usability study [9] on MAKTab’s in-
terface. In this evaluation we are using a small number of
researchers to judge if the interface adheres to established
usability criteria, based on the Xerox heuristic evaluation
checklist [12]. We have also planned an evaluation of the
tool by a number of knowledge engineers. For these exper-
iments, subjects will be asked to build configuration and di-
agnosis KBSs in the computer hardware domain. We chose
this domain as a basic system requires only a handful of rel-
atively simple rules, while more advanced systems can con-
tain many more, including relatively complex rules. This
29
affords greater flexibility in the KBSs the subjects are asked
to build, than would be available in the lift domain, while
still providing a thorough test of the system within an exper-
imentally acceptable time period. Users are encouraged to
use the “think out loud” approach, to allow us to determine
where they have difficulties, and, after completion of the test
they are also asked to complete a questionnaire in which they
provide details/opinions about their experience of using the
system. Initial results suggest people find the tool easy to
use, with the guided KA tool in particular being very helpful
when adding new rules.
6. CONCLUSION
In this paper we have presented a methodology for building
KBSs by configuring reusable components to work together.
Our methodology, and implementing tool, enable a user to
reuse domain knowledge from a domain ontology, devel-
oped for a KBS which uses one type of PS, with other types
of PSs to produce new KBSs. The first stage in this process
involves mapping relevant domain knowledge to a further
generic PS. In the second stage this knowledge is extendedto
provide the PS with the (additional) rules it requires to func-
tion within the domain. We have developed MAKTab, an
extendable tool which supports our methodology. MAKTab
can easily be extended to incorporate more types of map-
pings, better automatic mapping suggestions, and develop-
ment of executable KBSs in languages other than JessTab.
We believe this work moves the Knowledge Engineering com-
munity closer to fulfilling the dream of KBS creation by
configuring reusable components, as MAKTab supports the
reuse of existing domain knowledge with generic PSs and
produces an KBS which can be executed in the same en-
vironment as MAKTab (Prot´eg´e). We are now planning fur-
ther evaluations of the approach; first building KBSs in other
domains, and then KBSs with other types of PSs.
7. ACKNOWLEDGMENTS
This work is supported under the Advanced Knowledge Tech-
nologies (AKT) IRC, which is sponsored by the UK EPSRC
(grant GR/N15764/01). We are also grateful to the various
developers on the Prot´eg ´e team at Stanford University, Mark
Musen who made available their version of the Sisyphus-VT
code, and JessTab developer Henrik Eriksson, without which
this work would have been significantly more challenging.
8. REFERENCES
[1] J. Blythe, J. Kim, S. Ramachandran, and Y. Gil. An
Integrated Environment for Knowledge Acquisition.
In Proceedings of the 2001 International Conference
on Intelligent User Interfaces (IUI-2001), 2001.
[2] J. Breuker and W. Van de Velde, editors.
CommonKADS Library for Expertise Modelling
Reusable problem solving components. IOS Press,
1994.
[3] D. Corsar and D. Sleeman. Reusing JessTab rules in
Prot´eg´e. Knowledge-Based Systems, 19(5):291–297,
September 2006.
[4] David Corsar. KBS Development through Ontology
Reuse and Ontology Driven Acquisition. PhD thesis,
forthcoming, University of Aberdeen, 2007.
[5] M. Crubezy and M. Musen. Ontologies in Support of
Problem Solving. In S. Staab, and R. Studer, editor,
Handbook on Ontologies in Information Systems,
chapter 16, pages 321–322. Springer, 2003.
[6] J. Kingston. Pragmatic KADS: A methodological
approach to a small knowledge based systems project.
Technical report, Artificial Intelligence Applications
Institute, University of Edinburgh, UK, November
1994. AIAI-TR-110, 1994.
[7] S. Marcus, J. Stout, and J. McDermott. VT: An Expert
Elevator Designer That Uses Knowledge-Based
Backtracking. AI Magazine, 9(1):95–112, Spring
1988.
[8] R. Neches, R. Fikes, T. Finin, T. Gruber, R. Patil,
T. Senator, and W. R. Swartout. Enabling technology
for knowledge sharing. AI Magazine, 12(3):36–56,
Fall 1991.
[9] J. Nielsen and R. Molic. Heuristic evaluation of user
interfaces. In Proceedings of the SIGCHI conference
on Human factors in computing systems: Empowering
people, pages 249–256, New York, NY, USA, 1990.
ACM Press.
[10] B. Omelayenko, M. Crubezy, D. Fensel, R. Benjamins,
B. Wielinga, E. Motta, M. Musen, and Y. Ding.
UPML: The Lanugage and Tool Support for Making
the Semantic Web Alive, chapter 5, pages 141–170.
Spinning the Semantic Web. The MIT Press, 2003.
[11] J. Y. Park, J. Gennari, and M. Musen. Mappings for
Reuse in Knowledge-Based Systems. In 11th
Workshop on Knowledge Acquisition, Modelling and
Management KAW 98, 1998.
[12] Deniese Pierotti. Heuristic evaluation - a system
checklist. Xerox Corporation, 2000.
[13] A. Th. Schreiber and W. P. Birmingham, editors.
International Journal of Human-Computer Studies,
volume 44. Elsevier Ltd, 1996.
[14] G. Schreiber, H. Akkermans, A. Anjewierden,
R. de Hoog, N. Shadbolt, W. Van de Velde, and
B. Wielinga. Knowledge Engineering and
Management: the CommonKADS methodology.MIT
Presss, December 1999.
[15] M. Tallis. A Script-Based Approach to Modifying
Knoweldge-Based Systems. PhD thesis, University of
Southern California, December 2000.
30
... We have also implemented the two generic PSs discussed throughout the paper PS(pnr,-) and PS(diag,-) as sets of JessTab rules, based on pre-existing KBSs discussed previously. We have also developed rule converters for both PSs which translate the acquired rules into JessTab format, [5]. ...
... We have performed three evaluations of MAKTab, namely developer evaluation, user evaluation, and interface evaluation. These evaluations and their results are discused in [5]. ...
Article
Full-text available
The benefits of reuse have long been recognized in the knowledge engineering community where the dream of creating knowledge-based systems on-the-fly from libraries of reusable components is still to be fully realised. In this paper we present a two stage methodology for creating knowledge-based systems: first reusing domain knowledge by mapping it, where appropriate, to the requirements of a generic problem solver; and secondly using this mapped knowledge and the requirements of the problem solver to "drive" the acquisition of the additional knowledge it needs. For example, suppose we have available a knowledge-based systems which is composed of a propose-and-revise problem solver linked with an appropriate knowledge base/ontology from the elevator domain. Then to create a diagnostic knowledge-based systems in the same domain, we require to map relevant information from the elevator knowledge base/ontology, such as component information, to a diagnostic problem solver, and then to extend it with diagnostic information such as malfunctions, symptoms and repairs for each component. We have developed MAKTab, a Prot ´ eg ´ e plug-in which supports both these steps and results in a composite knowledge- based systems which is executable. In the final section of this paper we discuss the issues involved in extending MAKTab so that it would be able to operate in the context of the (Semantic) Web. Here we use the idea of centralised mapping repositories and mapping composition. This work contributes to the vision of the Web, which contains components (both problem solvers and instantiated ontologies (knowledge bases)) that tools (like MAKTab) can use to create knowledge-based systems which subsequently can enhance the richness of the Web by providing yet further knowledge-based Web-services.
... CORSAR & SLEEMAN extend the approach above by an automated mapping between a domain ontology and the requirements of a generic problem solver [5,6]. Furthermore this approach focuses on the assisted acquisition of required additional knowledge. ...
... A knowledge acquisition method is presented to extend the initial domain knowledge with reduced effort for the user. The authors consider to use domain ontologies from the Semantic Web in the future [5,6]. This outlook is based on the original vision of the Semantic Web and sophisticated ontologies to share knowledge. ...
Article
Full-text available
In simple terms, the Web of (Linked) Data is a distributed database with semantic facts about the world or any specific domain. The integration of Linked Data in knowledge-based systems (KBS) has the potential to reduce the maintenance effort for the underlying knowledge base. Using Linked Data in KBS leads to some new challenges that will be outlined in the paper. An important step during the design phase of the KBS is the comparison of the required knowledge and knowledge that is available as Linked Data. The required facts emerge from the problem-solving method and cover all facts that are necessary to conduct the intended decision. Whereas the available knowledge represent all relevant facts in internal and public Linked Data sets. Any remaining knowledge gap between required and available facts has to be closed primarily by rules and mash-ups to generate or transform the required facts automatically and keep everything up-to-date. This is one major step of the presented procedure and architecture to design a KBS based on Linked Data.
... 3. The components of the system may use multiple ontologies [15,16]. Linking specific components together in a certain inference needs certain mapping between all used ontologies [3,17]. 4. Most of the systems developments that were based on CommonKADS methodology have become legacy systems, but they still contain critical business roles and there is a high risk in the replacement operation of these legacy systems [18][19][20]. ...
Article
Full-text available
Common knowledge acquisition and documentation structuring (CommonKADS) methodology is used for building knowledge-based systems. Legacy systems built depending on CommonKADS suffer from weak points regarding reusability. The main objectives of this work are: (1) switching of CommonKADS methodology from just a design model to be an executable application, (2) facilitating the linkage and cooperation between CommonKADS services that are using different terminologies and (3) enhancing suitability and reusability of existing CommonKADS-based systems. An enhancement to the CommonKADS methodology in order to improve its applications reusability is introduced. This enhancement contains an adaptation of the original CommonKADS methodology and utilization of service-oriented architecture (SOA) as a promising software engineering technology. The proposed adaptation model includes two alternative processes: adjusting and converting. An adjusting process performs a transformation of the existing CommonKADS layers to be SOA-enabled so that it includes representing the data in a new standard form to be transformed into set of services. Converting process is concerned with changing CommonKADS-based legacy systems to SOA-enabled systems through using GenericSOA framework. An example application, a potato CommonKADS-based expert system, was used to evaluate the new proposed model through the analysis and automated restructuring of it to be SOA-enabled system.
... (4)How to promote task execution with domain knowledge support? As mentioned in [40], domain knowledge does strongly depend on particular task at hand. In practice, execution-specific domain knowledge is often reified into a group of problem-solving methods. ...
Chapter
In diesem Beitrag wird eine Ontologie-basiertes Entscheidungssystem vorgestellt, welches die Auswahl von geeigneten Werkzeugmaschinen durch die Dienstleistungsplattform unterstützt. Die Wissensverwaltung nutzt das Semantic Web zur dynamischen Bereitstellung einer stets aktuellen lokalen Wissensbasis. Die Wissensbasis enthält die Beschreibung aller verfügbaren Maschinen und deren Eigenschaften. Die Informationen über neue verfügbare Ressourcen wie Werkzeugmaschinen und deren Werkzeuge werden bei Bedarf von der Wissensverwaltung aus verfügbaren Linked Data Quellen abgerufen und in der Wissensbasis ergänzt – oder entfernt, wenn Ressourcen nicht verfügbar sind. Die Auswahl der geeigneten Maschinen für ein zu fertigendes Werkstück ist die Aufgabe der Problemlösungskomponente des WBS. Diese nutzt die Informationen der Wissensbasis um aus den Maschinenbeschreibungen die jeweiligen Bearbeitungsfähigkeiten abzuleiten. Die Bearbeitungsfähigkeiten werden anschließend mit den Fertigungsanforderungen des Werkstücks abgeglichen die zuvor vom NC-Interpreter (siehe Abschn. 2.2.2.4) ermittelt wurden. Vor der Freigabe einer alternativen Maschine wird die Bearbeitung zunächst mit einer Software simuliert (Die Simulation erfolgt auf einem Cluster mit virtuellen Werkzeugmaschinen der ebenfalls ein Bestandteil der Dienstleistungsplattform ist, siehe Kap. 6.).
Article
Full-text available
This paper gives an overview of the mapping mechanism of SEAM-a methodology for the automatic generation of knowledge models and its mapping onto Java codes. It discusses the rules that will be used to map the different components in the knowledge model automatically onto Java classes, properties and methods. The aim of developing this mechanism is to help in the creation of a prototype which will be used to validate the knowledge model which has been generated automatically. It will also help to link the modeling phase with the implementation phase as existing knowledge engineering methodologies do not provide for proper guidelines for the transition from the knowledge modeling phase to development phase. This will decrease the development overheads associated to the development of Knowledge Based Systems.
Article
Reuse has long been a major goal of the knowledge engineering community. We present a case study of the reuse of constraint knowledge acquired for one problem solver, by two further problem solvers. For our analysis, we chose a well-known benchmark knowledge base (KB) system written in CLIPS, which was based on the propose and revise problem-solving method and which had a lift/elevator KB. The KB contained four components, including constraints and data tables, expressed in an ontology that reflects the propose and revise task structure. Sufficient trial data was extracted manually to demonstrate the approach on two alternative problem solvers: a spreadsheet (Excel) and a constraint logic solver (ECLiPSe). The next phase was to implement ExtrAKTor, which automated the process for the whole KB. Each KB that is processed results in a working system that is able to solve the corresponding configuration task (and not only for elevators). This is in contrast to earlier work, which produced abstract formulations of the problem-solving methods but which were unable to perform reuse of actual KBs. We subsequently used the ECLiPSe solver on some more demanding vertical transport configuration tasks. We found that we had to use a little-known propagation technique described by Le Provost and Wallace (1991). Further, our techniques did not use any heuristic “fix”’ information, yet we successfully dealt with a “thrashing” problem that had been a key issue in the original vertical transit work. Consequently, we believe we have developed a widely usable approach for solving this class of parametric design problem, by applying novel constraint-based problem solvers to data and formulae stored in existing KBs.
Article
Full-text available
This paper gives an overview of the work done to develop a task ontology based on the task templates provided by CommonKADS. It discusses how modeling of KBS is done in the CommonKADS and also gives a brief overview of OWL-S which an upper-level ontology for web services. Constructs of OWL-S ontology have been compared with constructs proposed by CommonKADS to see to what extent it can be reused to build a task ontology to model the tasks that are performed by Knowledge Based Systems.
Article
Many of the component failures occurring in service can be delayed by better incorporation of tribological principles into engineering design and maintenance. However, the concept of tribology has not yet penetrated successfully into the industry in general and there is an urgent need for the practical tribology design criteria and transference of tribological knowledge to the engineering designer and maintenance engineer. Knowledge based system offers great potential for effecting tribological knowledge transfer and promoting improved design practice and maintenance strategy. In this present work, the development and implementation of a tribological failure knowledge model (KM) for steam power plant equipment is reported. This failure KM assists the maintenance engineer and design engineer for evolution of an effective maintenance strategy and better, reliable, safe and productive design. The KM has been implemented using Protege 3.0 Beta, JDK 1.4 and Java Swing Package. The model is applied to steam turbine failure in a power plant application.
Article
The objective of this work is to propose a knowledge based requirement engineering framework to arrive at a reusable design and deployment of a flood situation service in emergency management system software. In this proposed framework, the software requirement specifications are treated as input data with their corresponding association in multiple contexts. All such requirement information is fed into an expert system in the domain layer out of which the first class entities are derived to arrive at a meta-modeling of the target services. A set of contexts that concentrate upon the essential services with respect to deployment time and workflow parameters are considered as field knowledge. The knowledge base with all these information in multiple dimensions is treated as an engine to deliver the resulting design for the software services. The evolutionary computations under different conflicts are carried out as per the changing requirements. The proposed knowledge based system for changing emergency requirements of incident management software is evaluated in terms of maximum likelihood of the correct design with the growth and decay of incoming requests. The domain expert, meta-modeler and decision support modules are incorporated as knowledge based framework to arrive at an effective design for emergency management system.
Article
Full-text available
VT (vertical transportation) is an expert system for handling the design of elevator systems that is currently in use at Westinghouse Elevator Company. Although VT tries to postpone each decision in creating a design until all information that constrains the decision is known, for many decisions this postponement is not possible. In these cases, VT uses the strategy of constructing a plausible approximation and successively refining it. VT uses domain-specific knowledge to guide its backtracking search for successful refinements. The VT architecture provides the basis for a knowledge representation that is used by SALT, an automated knowledge-acquisition tool. SALT was used to build VT and provides an analysis of VT's knowledge base to assess its potential for convergence on a solution.
Article
Full-text available
Building new knowledge-based systems today usually entails constructing new knowledge bases from scratch. It could instead be done by assembling reusable components. System developers would then only need to worry about creating the specialized knowledge and reasoners new to the specific task of their system. This new system would interoperate with existing systems, using them to perform some of its reasoning. In this way, declarative knowledge, problem-solving techniques, and reasoning services could all be shared among systems. This approach would facilitate building bigger and better systems cheaply. The infrastructure to support such sharing and reuse would lead to greater ubiquity of these systems, potentially transforming the knowledge industry. This article presents a vision of the future in which knowledge-based system development and operation is facilitated by infrastructure and technology for knowledge sharing. It describes an initiative currently under way to develop these ideas and suggests steps that must be taken in the future to try to realize this vision.
Article
Full-text available
Modifying knowledge-based systems is a complex activity. One of its di#culties is that several related portions of the system mighthavetobechanged in order to maintain the coherence of the system. However, it is di#cult for users to #gure out what has to be changed and how. This paper presents a novel approach for building knowledge acquisition tools that overcomes some of the limitations of current approaches. In this approach, knowledge of prototypical procedures for modifying knowledge-based systems is used to guide users in changing all related portions of a system. These procedures, whichwe call knowledge acquisition scripts #or KA Scripts#, capture how related portions of a knowledge-based system can be changed coordinately.By using KA scripts, a knowledge acquisition tool would be able to relate individual changes in di#erent parts of a system, enabling the analysis of each individual change from the perspective of the overall modi#cation. The paper also describes the ...
Article
Full-text available
By dividing the world into domain knowledge and problem-solving methods that reason over that knowledge, knowledge-based systems seek to promote reusability and shareability of the given components. However, to effect a working system, the components must be mated subsequently within some global structuring scheme. We created a knowledge-based design for one such structuring scheme, for composing working applications from reusable knowledge-based components. The design is based on the concept of declarative mapping relations, which are explicit specifications for the syntactic and semantic connections between entities in the knowledge and method components. We structured the design of the mapping relation types into a principled mapping ontology. We built a functional implementation of this design within the Protg system. To assess its utility, we applied the mapping system to three evaluation studies of component-based reuse. 1. REUSABLE COMPONENTS AND MAPPINGS IN KNOWLEDGEBASED SYSTEMS Knowledge-based applications often make the distinction between declarative domain knowledge and the problem-solving methods that reason over that knowledge. This dichotomous abstraction promotes a degree of independence among the given components, and therefore offers the hope of being able to share and reuse these components. Work over many years in knowledge-based systems has resulted in large numbers of knowledge bases for many diverse domains, and of tested and refined problem-solving methods. Given a new task, there is a good chance that the relevant domain knowledge and an appropriate, implemented method already exist. The windfall would be realized if we could take this instantiated knowledge base and problem-solving method, and, with limited syntactic and semantic glue, bind t...
Article
There has been a growing desire for methodological support for the development of knowledge-based systems, and the KADS methodology is probably the most widely known methodology in Europe. However, KADS has been criticised for the overhead which it places on small and medium-sized KBS projects where the risks of KBS development becoming unmanageable are relatively low. This paper describes the use of ‘pragmatic KADS’, an attempt to extract the most useful elements from the KADS methodology, in the development of the COURSE SELECTOR KBS, which assists undergraduate students to choose courses which comply with University regulations and timetabling restrictions. This KBS was built in six man-weeks. The paper describes the three major phases of a KBS project, giving a brief outline of the KADS approach to each of these stages, and then discusses the techniques which were actually used for COURSE SELECTOR. It concludes with a recommendation of techniques for future small KBS projects.
Article
Protégé provides a complete ontology and knowledge base management tool. Along with JESS, JessTab provides one method of rule based reasoning over a Protégé ontology and knowledge base. However once JessTab rules have been created for a knowledge base, they are explicitly tied to it as they name particular classes and slots, which greatly hinders their reuse with further knowledge bases. We have developed a two phase process and a supporting tool to support the reuse of JessTab rule sets. The first phase involves changing the class and slot references in the rule set into an abstract reference; the second phase involves automatically mapping between the abstract rules and further knowledge bases. Once mappings have been denned and applied for all the classes and slots in the abstract rules, the new rule set can then be run against the new knowledge base. We have satisfactorily tested our tool with several ontologies and associated rule sets; moreover, some of these tests have identified possible future improvements to the tool.