next up previous
Next: Life-Cycle Execution Up: Knowledge Life-Cycle Management with Previous: Ecolingua's Life Cycle


Editing Life-Cycle Patterns

Let us first illustrate how sequences of transformations may be be generalised and compiled into formal representations of life-cycle patterns, and how these formal representations can actually be useful to the knowledge engineer. Figure 2 shows the overview of an architecture we have been investigating, and of a prototype tool, dubbed F-Life, that is based on it. In such an architecture a knowledge engineer can edit formal representations of abstract life-cycle patterns by means of a life-cycle editor and then pass these patterns to alife-cycle interpreter capable of executing them, provided we link the interpreter to a module that includes those problem solvers that perform the knowledge transformations captured in the abstract pattern in a domain-specific way. F-Life supports the generation of patterns of life cycles based on the life-cycle calculus discussed in [7].

Figure 2:F-Life's life-cycle management architecture
Image architecture.gif

Figure 3 shows the application of several life-cycle calculus rules as they occur in Ecolingua's life cycle (Figure 1) in form of an inference tree. In the tree,$ L_{ol},L_{terms},L_{pl}$ denote languages of Ontolingua, KIF terms, and Prolog clauses, respectively; $ S$ is the proper specification of Ecolingua, while $ S_1,\ldots,S_5$ are the specifications of the ontologies that are reused.

Figure 3:Inference tree for Ecolingua's life cycle
\begin{figure}\begin{displaymath}
\begin{prooftree}
\begin{displaymath}\begin{d...
...S_7] \rangle \using\quad\textsf{LW}
\end{prooftree}\end{displaymath}\end{figure}

During the first steps, several Component Connection rules are applied until a Language 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, and since all KIF sentences can be expressed by means of Prolog terms, we abstractly denote this translation as $ L_{ol} \overset{ol2terms}{\longrightarrow}
L_{terms}$.

The final three steps in the tree--two applications ofSpecification Weakening plus one application of Language Weakening--were performed afterwards in order to clean up, prune, and finally translate the component into Prolog clauses. Here, $ S_6$and $ S_7$ denote the specification of our component after the clean-up and pruning transformations, respectively (i.e., $ ol2terms[S \sqcup
\cdots \sqcup S_5] \sqsupset S_6 \sqsupset S_7$). The translation into Prolog clauses is justified by the existence of a translator, and since in this case not all KIF sentences can be expressed by means of Prolog clauses (because Horn clauses form a proper subset of first-order logic), we abstractly denote this translation as $ L_{terms} \overset{terms2pl}{\longleftarrow} L_{pl}$.

Figure 4:Formal representation of Ecolingua's life cycle as a life-cycle pattern
\begin{figure}\begin{center}\leavevmode \begin{tabbing}MMMMMMMMM \= \kill
$\mat...
..._4 \rangle ,
\langle L_2,S_2 \rangle )$\ \end{tabbing} \end{center}\end{figure}

Figure 4 presents a set of Horn clauses corresponding to the life cycle of Ecolingua discussed in Section 1 (see Figure 1 and the inference tree in Figure 3). We are representing life-cycle rules as atoms, and we compile sequences of several rules within the body of a clause. Life-cycle Specification Strengthening and Specification Weakeningrules are represented with atoms

$\displaystyle strengthen\_spec(InputComponent,OutputComponent)
$
and
$\displaystyle weaken\_spec(InputCcomponent,OutputComponent) \enspace,
$
rules Language Strengthening and Language Weakening with atoms
$\displaystyle strengthen\_lang(LanguageMorphism,InputComponent,OutputComponent)
$
and
$\displaystyle weaken\_lang(LanguageMorphism,InputComponent,OutputComponent) \enspace,
$
and rule Component Connection with atom
\begin{multline*}
connect(LanguageMorphism1, LanguageMorphism2,\\
InputCcomponent1,InputComponent2,OutputComponent) \enspace.
\end{multline*}

The recursive import predicate captures that part of the life cycle Ecolingua underwent in the Ontolingua Server and corresponds to the sequence of applications of Component Connection and the application of Ontology Strengthening illustrated in the inference tree of Figure 3. At each call of import a new component is acquired and subsequently connected to our current component, until some termination condition is satisfied. Thereduce 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 ofOntology Weakening illustrated in the inference tree of Figure 3.

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 theSpecification Weakening rule of the calculus. It takes knowledge component$ \langle L_1,S_1 \rangle $ and delivers component $ \langle L_1,S_4 \rangle $, where $ S_4$ is going to be a weaker specification than $ S_1$, according to the calculus rule, since, after cleaning up and pruning, the ontology will have less constraints. The weaken_lang goal captures the final translation into Prolog clauses and corresponds to a particular application of Language Weakening. It takes knowledge component $ \langle L_1,S_4 \rangle $ of the previous goal and delivers component $ \langle L_2,S_2 \rangle $, where $ L_2$ is the new knowledge-representation language (in this particular example it is Prolog) while $ S_2$ is the translation of $ S_4$ into the new syntax. Since Horn-clause logic is a less expressive logical language than KIF, which is essentially predicate calculus, the output component $ \langle L_2,S_2 \rangle $ will be in principle weaker than component $ \langle L_1,S_4 \rangle $.

A Horn-clause representation of knowledge life cycles has advantages with respect to both its declarative semantics and its procedural semantics. Declarativelly, it shows the logical dependence of composed life-cycle steps with respect to its sequence of primitive steps. Procedurally, it allows us to readily implement a meta-interpreter that enables the execution of life cycles, so that we can recreate the same patterns in different knowledge-engineering scenarios.

Although in [7] we justified our choice of these steps, such as Language Weakening, and we gave definitions for a formal life-cycle calculus, the life-cycle calculus, however, is independent of the enactment system in which it may be embedded. Notice that, in spite of the life-cycle editor using an explicit formal notation as Horn clauses, it is possible to hide much of the formality by using domain- or task-specific editing operations. For example, if we built an editor that was especially for ontology refinement, then we might have translations between specific formal languages such as KIF or Prolog as `primitive steps', and these would fit into the basic underlying calculus as instantiations of sequences of abstract transformation steps, such as Language Strengtheningor Language Weakening.

Figure 5:Editing Ecolingua's life cycle
Image editor.gif

Figure 5 shows the 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. This editor is based on a techniques editor developed by Robertson for Prolog [5]: The knowledge engineer chooses a particular skeleton or life-cycle pattern from a library of patterns and then further refines its clauses by clicking on the appropriate buttons, hence instantiating atoms and its arguments with the required life-cycle rules from the calculus. In particular, Figure 5 shows the formal counterpart of Ecolingua's life cycle as portrayed in Figure 4 at the stage where the engineer is about to determine that the last transformation step should be a Language Weakening step.

We envisage a wide spectrum of possible uses of formal representation of life-cycle patterns, going all the way from non-automation, where the life-cycle calculus that we proposed is used as a formal means for rigorously analysing the structure of knowledge life cycles and the properties of knowledge components, to highly automated environments where life-cycle patterns guide the automatic transformation of knowledge components. The architecture of Figure 2 that we have been investigating so far is of the latter sort: knowledge engineers are highly constrained by an editing tool in their attempt to analyse and represent knowledge life cycles, according to transformation steps grounded on our life-cycle calculus. These representations are then used to fully guide the sequence of transformations that a knowledge component goes through, as we illustrate next.


next up previous
Next: Life-Cycle Execution Up: Knowledge Life-Cycle Management with Previous: Ecolingua's Life Cycle
Marco Schorlemmer 2003-01-29