Knowledge Life-Cycle Management over a Distributed Architecture

Knowledge Life-Cycle Management
over a Distributed Architecture
Marco Schorlemmer1
Stephen Potter1
David Robertson1
Derek Sleeman2
1Centre for Intelligent Systems and their Applications
School of Informatics
The University of Edinburgh
2Department of Computing Science
University of Aberdeen
Abstract
In order to address problems stemming from the dynamic nature of distributed systems, there is
a need to be able to express the often neglected notions of the evolution and change of the knowledge
components of such systems. This need becomes more pressing when one considers the potential of
the Internet for distributed knowledge-based problem solving — and the pragmatic issues surrounding
knowledge integrity.
In this paper, we introduce a formal calculus for describing transformations in the ‘life cycles’ of
knowledge components, along with ideas about the nature of distributed environments in which the
ideas underpinning the calculus can be realised. The formality and level of abstraction of this language
encourage the analysis of knowledge histories and allows useful properties about this knowledge to be
inferred. These ideas are illustrated through the discussion of a particular case-study in knowledge
evolution.
1
Introduction
The dynamic nature of knowledge has long been realised: knowledge evolves over time as experiences
accumulate; it is revised and augmented in the light of deeper comprehension; entirely new bodies of
knowledge are created while at the same time others pass into obsolescence. However, this dynamism has
rarely been acknowledged in the engineering of knowledge-based systems: systems of static knowledge
elements are assumed to exist in unchanging environments. The increasing desire to deliver knowledge
across distributed environments such as the World-Wide Web highlights the extent of this gulf: the Web
is ever-changing and systems must be able to accommodate change if they are to succeed and thrive.
To be able to describe the dynamics of knowledge, there seems to be a need for some level of formality.
The role of formality is twofold: to give a concise account of what is going on, and to use this account
for practical purposes in maintaining and analysing the ‘life cycles’ of knowledge components from their
creation, through successive phases of modification, to their eventual retirement.
We start in Section 2 with a glimpse into a prototype environment we are currently implementing. Its
constituent agents can interact and use their combined capabilities to solve problems, and it allows the
life cycles of these agents to be described and maintained. Section 3 outlines the essential characteristics
of such an environment, although consideration of the precise forms which these life-cycle descriptions
might take is deferred until Section 4, where the notion of a life-cycle calculus of abstract knowledge
transformations is introduced. These abstractions allow meaningful statements to be made about bodies
of knowledge without sacrificing generality to the demands of any particular domain. By making explicit
the histories of these knowledge components using terms based on this calculus, the sources of knowledge
can be identified, assumptions traced, and useful properties inferred. To better illustrate these ideas, a
case-study of the life cycle of one particular ontology is used. In Section 5 we return to this case-study
1

---

and describe how it might be enacted by the agents in our environment. In doing this, in Section 6
we make more concrete the ideas of formality for knowledge maintenance that lie at the heart of this
research.
2
Ecolingua’s Life Cycle
We shall motivate our research by using a real example — the life cycle of the Ecolingua ontology — and
give a snapshot of the kind of environment we are currently developing so that a knowledge engineer can
interact with the life cycle. In subsequent sections we shall discuss the details of such environment.
Ecolingua is an ontology engineered by Brilhante and Robertson for the description of ecological data
[2, 4]. In order to reuse some of the ontologies made available by the Ontolingua Server [5] the new
ontology Ecolingua was first constructed with the server’s editor by reusing classes from other ontologies
in the server’s library, and then automatically translated into Prolog syntax by the server’s translation
service (see Figure 1).
Because the outcome of the translation process was a large 5.3 Mb file, it was necessary to reduce the
ontology in order to get a smaller and more manageable set of axioms. The definitions of proper Ecolingua
classes use external classes defined in five other ontologies, and the translation service of the server just
joins all ontologies together before performing the translation. This forced Brilhante and Robertson to
implement filters that first deleted all extraneous clauses (over-general facts, definitions of self-subclasses,
duplicated classes), and then pruned the class hierarchy and removed irrelevant clauses. Finally, since
the ontology was specified with KIF expressions (although in Prolog syntax) a final translation into Horn
clauses was performed in order to execute the ontology with a Prolog interpreter, the preferred language
of the authors of the ontology. Figure 1 shows this part of Ecolingua’s life cycle.
Ontoligua Server
Hpkb-Upper-Level
Kif-Numbers
reuses
Ecolingua
Kif-Extensions
Simple-Time
Physical-Quantities
translation into Prolog syntax
5.3M file
Ecolingua in Prolog syntax
clean up extraneous clauses
Clean Ecolingua
prune class hierarchy and irrelevant clauses
Pruned Ecolingua
translation into Horn clauses
220K file
Executable Ecolingua
Figure 1: Ecolingua’s life cycle
We postulate that particular sequences of life-cycle steps like those illustrated in Figure 1 might
be common in particular domains and perhaps to particular forms of knowledge component. As such,
the ability to generalise and ‘compile’ these sequences transforming them into life-cycle patterns and
making them available within the environment as integrated competences would encourage more efficient
behaviour when faced with the need to make similar modifications in the future.
Figure 2 shows a life-cycle editor that enables a knowledge engineer to analyse the life cycle of a
knowledge component, extract its abstract pattern, and devise a formal representation of it. In particular,
it shows Ecolingua’s life cycle at the stage where the engineer is determining that the last transformation
step is a weakening step of the ontology. The definition and choice of abstract life-cycle steps (such
as weakening) is justified by a formal life-cycle calculus that we shall introduce later in Section 4 (see
2

---

Figure 2: Editing Ecolingua’s life cycle
also Figure 7, which gives the formal counterpart of this life cycle). Notice that, although the depicted
life-cycle editor uses an explicitly formal notation, it is possible to hide much of the formality by using
domain/task-specific editing operations.
Once the life cycle of a knowledge component like Ecolingua is formalised, we may publish it as
a competence of a life-cycle interpreter, which is a meta-interpreter capable of executing the formal
representation of a life cycle. This life cycle is described at a generic level; in order to be able to run the
life cycle in a particular domain, the execution is carried out by means of a brokering service that searches
for problem solvers capable of performing abstract life-cycle steps; these solvers should have previously
advertised their capabilities. In this example we have decided to make the broker interactive to enable
the knowledge engineer to choose among several alternative solvers that have the same capability to
carry out particular life-cycle steps in a domain-specific fashion. One might, though, decide to have a
non-interactive broker that has the sufficient information (or is able to acquire it) for choosing among
alternative solvers. In Sections 3 and 5 we further explain how we have done this in a distributed
environment.
Figure 3 shows a task panel during the execution of a particular life cycle, ontology reducer, which
reduces the Ecolingua ontology following the steps of the previously edited formal pattern of Ecolingua’s
life cycle. Figure 4 shows how, at a particular stage of the execution of the life-cycle pattern, the broker
gives the choice of two alternative solvers with the capability of performing the weaken life-cycle step. At
this point the user interactively chooses the solver to perform the domain-specific task required by the
abstract life-cycle step.
Eventually the life-cycle execution ends, yielding as a response a term that expresses the life-cycle
history of the knowledge component (Ecolingua in this case). This life-cycle history can later be used
3

---

Figure 3: Executing Ecolingua’s life cycle
to infer properties of the components by looking at its evolutionary path rather than by inspecting the
specification of the component itself. In the next section we give a fuller description of an environment
that facilitates the sort of knowledge management we have briefly illustrated so far.
3
A Knowledge Life-Cycle Management Environment
We shall now describe a generalised system in which formal notions of knowledge life cycles can be
exploited to effect a coherent knowledge management environment.
These life cycles correspond to
sequences of transformations described by a formal calculus; however, discussion of the precise form of
this calculus is deferred until Section 4 so as to emphasise that this environment is not predicated upon
any particular life-cycle language.
We envisage a distributed agent-based environment which mirrors the most general structures of
knowledge-intensive problem solving at both micro- and macro-levels (including the Internet). In general,
a typical agent will contain:
• some knowledge component, along with a life-cycle history that describes the evolution of that
component from (at least) the inception of the system: it is a requirement of the system that all
agents store — and make available for inspection — the corresponding life-cycle history alongside
their knowledge components.
4

---

Figure 4: Choosing a particular solver for an abstract life-cycle step
• the means to communicate with its environment, sending messages addressed to other agents, and
receiving messages addressed to it.
• the means to invoke its knowledge, as appropriate, for problem solving purposes.
• a succinct expression of the capabilities of its knowledge (the agent’s competences), including any
assumptions it makes and any requirements and constraints it imposes in the exploitation of that
knowledge. An agent’s competences are advertised as a statement of the services it is both willing
and able to provide, under the stipulated conditions.
Given a common communication language with agreed semantics, some notion of how each agent may
connect to the system and an appropriate mechanism for co-ordinating the competences of individual
agents, a system of this sort would be able to solve problems that lie within its global competence.
(Here we assume that this mechanism would be in the form of some sort of centralised brokering service,
similar to that seen in the previous section, but more distributed models of co-operation could play
this co-ordination role equally well.) In this manner, the system as a whole would be able to act as a
conventional ‘knowledge-based system’, exploiting its collective knowledge-base to act intelligently in the
face of (both internal and external) appeals to that knowledge. However, the availability of the formal
life-cycle histories that accompany the knowledge components of the system adds an extra facet to this
process and to the environment as a whole. We anticipate that the histories of the individual knowledge
components can be inspected and reasoned with. Subsequently, properties of these components and of
the system in its entirety can be proved and used to form a more complete picture of the state of the
system, which enables the more considered exploitation of the resources it offers.
5

---

Now consider this system to contain additional agents that have some very particular properties (while
still conforming to the general description of agents given above):
knowledge transformers: These are agents whose competences include the ability to perform some
transformation on a knowledge component, like cleaning up extraneous clauses or pruning the class
hierarchy in the Ecolingua example of Section 2 — they have the ability to perform one or more
life-cycle steps on these components. It is a requirement of the system that all its knowledge trans-
formers agree to act in a principled manner: knowledge components must be altered in accordance
with the calculus, and it is imperative that the knowledge transformer also modifies appropriately
the current life-cycle history associated with that component.
life-cycle interpreters: These are agents capable of following the sequence of generalised life-cycle steps
specified in some predefined life-cycle pattern, like the one shown in Figure 7. Although they are
able to follow the sequence, in general they will not be able to alter knowledge components. For
that reason they will have to ask for the service of knowledge transformers that are capable of
performing such transformations.
Should a life-cycle interpreter itself be capable of executing one or more life-cycle steps, then it must also
be considered a knowledge transformer (with all the constraints on its behaviour this entails).
As mentioned in Section 2, we claim that particular sequences of transformations applied to certain
forms of knowledge components might be common to specific domains. Generalising and compiling these
sequences into ‘life-cycle patterns’ and making them available within the environment as the competence
of agents that can ‘execute’ these patterns would allow for the management of life cycles when faced with
the need to make similar transformations in the future. The role of the life-cycle interpreter is to offer
one or more of these life-cycle patterns to the system.
The knowledge components of other agents — including those of other knowledge transformers —
can be altered and recorded in a formalised manner using knowledge transformers. As a result, the
system is able to coordinate and control the evolution of its knowledge, enabling its global competences
to evolve and develop in accordance with the changing demands of its problem-solving domain. The steps
in the development of the various knowledge components would be traceable from their inception to their
final retirement from the system. Users of the services provided by the system would be fully aware
of the provenance of that service, and able to make informed judgements about its reliability, inherent
assumptions and trustworthiness.
4
Formal Knowledge Life Cycles
In Section 5 we describe a concrete system of this kind, but first we need to introduce the necessary
formal machinery to capture and represent the abstract structure of knowledge life cycles.
4.1
Life-Cycle Calculus
We capture the structure of the life cycle through which a knowledge component like Ecolingua has gone
by means of abstract transformations drawn from the set of life-cycle calculus rules given in Figure 5.
We wanted these rules to be general, since we attempt to capture only the essentials of the knowledge
engineering activity and do not want to describe formally the details of numerous individual techniques.
On the other hand, we wanted them not to be so general that they do not have any relevance to the
technologies we wish to analyse. We claim to have achieved a sensible level of abstraction as the example
of distributed life-cycle management described in Section 5 illustrates. Nevertheless we envisage particular
specialisations of this general calculus that are closer to particular classes of transformation techniques
and, subsequently, capture more properties of these techniques.
The rules of the calculus are to be interpreted as particular kinds of ‘inference rules’ with premises
(or input components) above the horizontal line, and conclusions (or output components) below it. The
life-cycle rules operate on abstract knowledge components; each component is characterised as a pair
O, S , consisting of the specification S of the component and the ontology O in which the specification
is given. If the knowledge component currently under consideration is itself an ontology, as it is the case
6

---

Ontology Strengthening (OS)
O, S
f
if
O −→ O
O , f [S]
Ontology Weakening (OW)
O, S
f
if
O ←− O
O , f −1[S]
Specification Strengthening (SS)
O, S
if
S
S
O, S
Specification Weakening (SW)
O, S
if
S
S
O, S
Component Connection (CC)
O, S
O , S
f
g
if
O → O ← O
O , f [S]
g[S ]
Figure 5: Life-cycle calculus
of Ecolingua, then S is the content of the ontology, while O is actually the meta-ontology in which the
ontology is specified.
The application of these life-cycle rules is further conditioned by either the existence of an order
between specifications (as in the rules of Specification Strengthening/Weakening) or of particular map-
f
pings O −→ O between ontologies (as in the rules of Ontology Strengthening/Weakening and Component
Connection).
Ontology Strengthening captures, for instance, transformations that add ontological constraints or
that translate the component into a more expressive logical language, and Ontology Weakening captures
transformations that remove ontological constraints or translate the component into a less expressive
logical language. In these cases, the specification is changed according to the change of ontology, which
is denoted with f [S] and f −1[S], the set image and inverse set image of a specification with respect to an
ontology mapping, respectively. The mathematical principles upon which the calculus is founded have
been discussed in [6] and are beyond the scope of this paper. They are based on a mathematical theory
of information flow proposed by Barwise and Seligman in [1].
Specification Strengthening captures, for example, transformations that add axioms to the compon-
ent’s specification or that generalise it, and Specification Weakening captures transformations that remove
axioms from the component’s specification or that specialise it. This is modelled with an order relation
on specifications. Finally, Component Connection captures transformations that take two knowledge
components (perhaps expressed using different ontologies O and O ) and merge them into a unified com-
ponent, whenever their respective ontologies can be mapped into a common global ontology O . Here
the join operator
models the merging operation, and is usually defined as a least upper bound in the
order
of specifications.
Figure 6 shows the application of several life-cycle calculus rules as they occurred in Ecolingua’s
life cycle (Figure 1) in form of an inference tree. In the tree, Ool, Okif , Opl denote the ontologies for
Ontolingua, KIF terms, and Prolog clauses, respectively; S is the proper specification of Ecolingua, while
S1, . . . , S5 are the specifications of the ontologies that are reused.
During the first steps, several Component Connection rules are applied until an Ontology Strengthening
step is performed to get the whole specification written with KIF terms in Prolog syntax. These are the
steps that were performed at the Ontolingua Server. They are justified by the fact that all ontologies are
written in Ontolingua, hence no translation (or only identity (id) translations) had to be done before the
specifications can be merged. The translation into KIF terms is justified by the existence of a translator,
ol2kif
that we abstractly denote as Ool −→ Okif .
The final three steps in the tree — two applications of Specification Weakening plus one application
of Ontology Weakening — were performed afterwards in order to clean up, prune, and finally translate
7

---

Ool, S
Ool, S1
CC
Ool, S
S1
Ool, S2
CC
Ool, S
S1
S2
·
·
·
· various applications of CC
·
Ool, S
S1
· · · S5 OS
Okif , ol2kif[S
S1
· · · S5]
SW
Okif , S6
SW
Okif , S7
OW
Opl, kif2pl−1[S7]
Figure 6: Inference tree for Ecolingua’s life cycle
the component into Prolog clauses. Here, S6 and S7 denote the specification of our component after
the clean-up and pruning transformations, respectively (i.e., ol2kif [S
· · · S5]
S6
S7). The
translation into Prolog clauses is justified by the existence of a translator, that we abstractly denote as
kif2pl
Okif ←− Opl. (The fact that the arrow is represented in the opposite direction of the translation and
also that its inverse is used in the inference tree is justified by the underlying formal semantics of the
life-cycle calculus, which lies outside the scope of this paper.)
4.2
Life-Cycle Patterns
We have implemented a prototype tool that supports the generation of patterns of life cycles based on
the life-cycle calculus discussed in Section 4.1. Figure 7 presents a set of Horn clauses corresponding to
the life cycle of Ecolingua discussed in Section 2 (see Figure 1 and the inference tree in Figure 6); this is
the life cycle shown in the editor in Figure 2.
ecolingua lifecycle ( O1, S1 , O2, S2 ) ←−
import ( O1, S1 , O3, S3 ) ∧
reduce( O3, S3 , O2, S2 )
import ( O1, S1 , O2, S2 ) ←−
all imported ( O1, S1 ) ∧
ol2kif
strengthen onto(O1 → O2, O1, S1 , O2, S2 )
import ( O1, S1 , O2, S2 ) ←−
acquire( O1, S4 ) ∧
connect(O id
id
1 → O1, O1 → O1, O1, S1 , O1, S4 , O1, S5 ) ∧
import ( O1, S5 , O2, S2 )
reduce( O1, S1 , O2, S2 ) ←−
weaken spec( O1, S1 , O1, S3 ) ∧
weaken spec( O1, S3 , O1, S4 ) ∧
kif2pl
weaken onto(O1 ← O2, O1, S4 , O2, S2 )
Figure 7: Formal representation of Ecolingua’s life cycle as a life-cycle pattern
The recursive import predicate captures that part of the life cycle Ecolingua underwent in the Ontolin-
gua Server and corresponds to the sequence of applications of Component Connection and the application
8

---

of Ontology Strengthening illustrated in the inference tree of Figure 6. At each call of import a new
component is acquired and subsequently connected to our current component, until some termination
condition is satisfied. The reduce predicate captures the subsequent reduction performed on the output
file of the server and corresponds to the two applications of Specification Weakening and the application
of Ontology Weakening illustrated in the inference tree of Figure 6.
Focusing on the reduce predicate, for instance, the two goals weaken spec represent the clean-up and
pruning steps the ontology went through and correspond to particular applications of the Specification
Weakening rule of the calculus. It takes knowledge component O1, S1 and delivers component O1, S4 ,
where S4 is going to be a weaker specification than S1, according to the calculus rule, since, after
cleaning up and pruning, the ontology will have less constraints. The weaken onto goal captures the final
translation into Prolog clauses and corresponds to a particular application of Ontology Weakening. It
takes knowledge component O1, S4 of the previous goal and delivers component O2, S2 , where O2 is
the new meta-ontology (in this particular example it is that of Prolog clauses) while S2 is the translation
of S4 into the new syntax. Since Horn-clause logic is a less expressive logical language than KIF, which is
essentially predicate calculus, the output component O2, S2 will be in principle weaker than component
O1, S4 .
We have chosen a Horn-clause representation of knowledge life cycles to readily implement a meta-
interpreter that allows the execution of a life cycle, so that we can recreate the same pattern in different
knowledge-engineering scenarios. The life-cycle calculus, however, is independent of the enactment system
in which it may be embedded. We consider that, when acquiring ontologies from sources such as the
Ontolingua Server in the future, it is quite likely that we will have to perform similar importing and
reducing operations, and so it is worthwhile formalising these steps and publishing them as a generic
life-cycle pattern.
4.3
Managing Formal Life Cycles
Having the essentials of the knowledge-engineering activity expressed as formal life-cycle patterns allows
the study and analysis of life cycles as first-class citizens: we may consider life cycles as knowledge
components themselves and reuse them in other knowledge management activities. This allows us to
devise frameworks — like the one envisaged in Section 3 and further developed in Section 5 — in which
we can keep track of the several life-cycle transformations a knowledge component goes through, and to
infer properties that are preserved during different stages of a life cycle.
For instance, transforming a knowledge component by weakening its specification preserves its sound-
ness but not the completeness of the logic that models the component. On the other hand weakening
the ontology of a knowledge component by representing it in a less expressive logical language preserves
the completeness but not the soundness of the logic that models the component. These statements are
justified by the underlying semantics of the life-cycle calculus based on channel theory, the theory of in-
formation flow proposed in [1]. Such properties would be difficult to prove, let alone infer, by inspecting
the specification of the knowledge components, because it would require the cumbersome task of reason-
ing with the axioms that constitute the specification. Instead, they are easily proved by a theorem prover
on a ‘life-cycle level’, namely by inspecting the structure of the life cycle and using knowledge about
channel-theoretic operations and knowledge (or assumptions) of the initial properties of the component.
Although the life-cycle calculus rules given in Figure 5 suffice for the purposes of high-level knowledge
management on the ‘life-cycle level’, calculus-specific goals like weaken spec or weaken onto are far too
general for a meta-intepreter to be able to solve them in any particular domain by applying the trans-
formation steps they capture. Suppose we wanted to recreate the execution of the reduction fragment of
Ecolingua’s life cycle as represented in the last clause of Figure 7. Within a distributed environment, the
meta-interpreter should appeal to the local competences of knowledge transformers to execute this life
cycle.
5
Executing Ecolingua’s Life Cycle
We present a description of how agents might interact in the environment outlined in Section 3, based
upon the reduce life-cycle pattern represented in the last clause of Figure 7. In the environment, the
9

---

Ecolingua ontology, in all its successive guises, would be the knowledge component owned by an agent,
called, say, ecolingua. Hence, initially this agent would have as its knowledge component O, S , where
O represents the meta-ontology over which the specification, S, of Ecolingua is given.
The constructs used to build the corresponding life-cycle history are shown in Table 1. They corres-
pond to the transformation rules of the calculus (now expressed in terms of the agent-based environment),
along with an additional construct, acq, used to describe the acquisition of some knowledge component,
and its introduction into the system. This acquisition step is not covered by a calculus rule since it rep-
resents merely the introduction of some knowledge component into the domain of discourse, and not some
particular transformation of it. However, it is needed in practical situations where we admit components
that have histories external to the system.
In accordance with these constructs, then, the initial life-cycle history of component
O, S
is
acq(ontolingua-server, t0), indicating that the first recorded step (at time t0) in the life of this com-
ponent, as far as this environment is concerned, has been its acquisition from the Ontolingua Server. It
is necessary to record the time of each life-cycle step since the precise behaviour of the transformation
described may itself be time dependent. Configured in this manner, then, ecolingua is available for
general problem-solving in the system; as its competence it may offer, for example, query services and
property-checking upon the Ecolingua ontology.
construct
description
acq(Source, T )
The knowledge component has been
acquired from source Source at time T .
ss(LC, Agent, T )
The specification of the component, previously
having life-cycle history LC, has been strengthened
by the actions of knowledge transformer Agent at time T .
sw(LC, Agent, T )
The specification of the component, previously
having life-cycle history LC, has been weakened
by the actions of knowledge transformer Agent at time T .
os(LC, Agent, T )
The ontology of the component, previously
having life-cycle history LC, has been strengthened
by the actions of knowledge transformer Agent at time T .
ow(LC, Agent, T )
The ontology of the component, previously
having life-cycle history LC, has been weakened
by the actions of knowledge transformer Agent at time T .
cc(LC, SA, CA, T )
The component, previously having life-cycle history
LC, is connected to the component of agent CA
through the actions of knowledge transformer SA at time T .
Table 1: Life-cycle history constructs (times may be absolute or relative to the environment).
Now, assuming the system also contains the following knowledge transformers:
• cleanup, which offers the competence:
weaken spec(A)
where A is the name of some agent that is constrained to hold an appropriate knowledge component.
The effect of the operation is to ‘clean up’ that ontology, with the removal of extraneous clauses in
the manner described above in Section 2. Notice that this operation is equivalent to a Specification
Weakening step in the reduction of the Ecolingua ontology.
• prune, which also offers the competence:
weaken spec(A)
10

---