Syntactic Transformation of Knowledge Bases in …hetland.org/research/1998/syntran.pdfSyntactic...

Syntactic Transformation of Knowledge Basesin Virtual Enterprises

Magnus Lie Hetland

April 28, 1998

Abstract

Virtual enterprises have a great need for distributing knowledge representationsbetween more or less incompatible computer agents/programs. One of the mainsolutions to this problem is to create programs that translate between the differentformats used.

This report describes the syntactic transformation of knowledge bases in gen-eral and a simple syntactic translating program that can translate between tworepresentation languages, the GEM Object Language and the Knowledge Inter-change Format, in particular.

Contents

1 Introduction 51.1 The structure of this report . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Background 72.1 Knowledge representation . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Knowledge Interchange Format . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 The Knowledge Query and Manipulation Language . . . . . 92.3 The process of translation . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.1 Syntactic structure . . . . . . . . . . . . . . . . . . . . . . . . 102.3.2 Semantics and ontologies . . . . . . . . . . . . . . . . . . . . 112.3.3 An example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Work done 173.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2 The represented domain of knowledge . . . . . . . . . . . . . . . . . 173.3 The common format . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Implementation and testing 214.1 Java and JavaCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 Construction and implementation . . . . . . . . . . . . . . . . . . . 22

4.2.1 Class structure . . . . . . . . . . . . . . . . . . . . . . . . . . 224.3 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5 Discussion 275.1 Adequacy of the solution . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1.1 Completeness . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.2 Known problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

A Installation and usage instructions 31

B Grammar of the common format 33

C Description of the JJTree/JavaCC grammar file format 35C.1 JavaCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35C.2 JJTree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4 CONTENTS

D Source code 39D.1 The JJTree/JavaCC source . . . . . . . . . . . . . . . . . . . . . . . . 39

D.1.1 GOLParser.jjt . . . . . . . . . . . . . . . . . . . . . . . . . . . 39D.1.2 KIFParser.jjt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

D.2 The modified AST classes . . . . . . . . . . . . . . . . . . . . . . . . 53D.2.1 ASTgdlObject.java . . . . . . . . . . . . . . . . . . . . . . . . 53D.2.2 ASTgdlSubObject.java . . . . . . . . . . . . . . . . . . . . . . 54D.2.3 ASTgdlRelship.java . . . . . . . . . . . . . . . . . . . . . . . 54D.2.4 ASTvalueSet.java . . . . . . . . . . . . . . . . . . . . . . . . . 55D.2.5 ASTobject.java . . . . . . . . . . . . . . . . . . . . . . . . . . . 56D.2.6 ASTrelationship.java . . . . . . . . . . . . . . . . . . . . . . . 57D.2.7 ASTproperty.java . . . . . . . . . . . . . . . . . . . . . . . . . 58

D.3 The translation visitor classes . . . . . . . . . . . . . . . . . . . . . . 59D.3.1 KIF To GOL Visitor . . . . . . . . . . . . . . . . . . . . . . . 59D.3.2 GOL To KIF Visitor . . . . . . . . . . . . . . . . . . . . . . . 59

Chapter 1

Introduction

Traditionally, companies have largely been structured according to spatial con-straints — people who cooperate closely or are in the same division of a corpo-ration have usually been working at the same location. But as telecommunica-tion technology has improved other corporate models have surfaced. The word“Telecommuting” has been used to describe employees who work at home, con-nected to their workplace through telephone and computer.

Lately, the enormous development seen in global computer networks, espe-cially the Internet, makes this kind of decentralization possible on a larger scale.It is gradually becoming feasible to build enterprises that consist only of peopleand information. The spatial dimension is no longer as crucial as it has been.

These virtual enterprises bring with them many new challenges. One of theseis the problem of compatibility. The basis of a virtual enterprise is communication.A host of information must be shared between its more or less independent parts,and when these parts use different tools that represent knowledge and informa-tion in different ways, there is quite clearly a gap to bridge.

One possible solution is to demand the use of one set of tools that are compati-ble. This is not satisfactory, as the different departments may have different needswith respect to what software they use and would be unduly restricted by such ademand of conformity. The obvious alternative would be to mediate between thedifferent tools in some way. If we assume that the differences between the toolslie mainly in the languages in which they represent knowledge — that is, theirfile formats — this mediation is a process of translation.

This report deals with the construction of a translation program to be used inthe manner described. It is part of the VRIDGE1 project, which is again a partof Globeman 21 which is an umbrella project for several sub-projects dealing withenterprise integration for global manufacturing towards the twenty-first century.

VRIDGE is working with the distribution of information and knowledge be-tween between different divisions of a distributed enterprise. Three of the mostcentral modeling platforms or tools used in this project are AI0Win from KBSI Inc.,FirstSTEP from the Interfacing Technologies Co., and Metis from NCR Norge A.S.The translator described in this report deals only with Metis.

Translation between the different tools will go through a common language,

1Virtual and Real Information Distribution in a Global Enterprise

6 Introduction

to reduce the number of connections. The language chosen is KIF, the KnowledgeInterchange Format (Genesereth & Fikes 1992), basically predicate logic writtenwith Lisp syntax. The translation will be done to and from KIF, but also be-tween different representations in KIF. The former is a purely syntactic transla-tion, whereas the latter is a semantic transformation. This process is described inmore detail later.

The work presented in this report is a syntactic translator that translates be-tween one of the representation languages, the METIS GEM Object Language, orGOL (NCR n.d.), and a subset of KIF. The subset of KIF to be used will also bedeveloped.

1.1 The structure of this report

In chapter 2 I will describe some background material on knowledge represen-tation and the process of translation. In chapter 3 i will describe some of thespecifics of this project, both in terms of basic requirements of the solution, thedomain of knowledge to be represented and an informal specification of the sub-set of KIF used. In chapter 4 I will explain some implementation choices anddescribe some of the implementation details. This chapter also covers the testingperformed on the finished software. In chapter 5 I will discuss the advantages anddrawbacks of the chosen solution and give some suggestions on how to build onmy work.

The appendices contain installation and usage instructions, a simple BNF-grammar of the KIF format used, description of some of the tools used and acomplete source code listing.

Chapter 2

Background

There are several issues involved in the task of translating between differentknowledge representations. Firstly, there is the issue of knowledge representa-tion itself. Some of the representations to be translated are given, and some areunknown, as new representations might appear that should fit into the solution.But to make a practical translation system, one should have one common formatthat is used as a “middle language.” In this way one can reduce the number oftranslating programs needed.

Secondly, there is the matter of translating from a given representation lan-guage to the common format and back again. This may be done as a syntactictransformation without regard to the meaning of the text.

If the information is translated in a purely syntactic manner, it will have tobe translated semantically as well, within the common format. This report dealsmainly with the syntactic translation but will explain some of the concepts ofontologies and the semantics of the representations, for completeness.

2.1 Knowledge representation

Knowledge representation is an important concept in the field of artificial intelli-gence. In Russel & Norvig (1995), its purpose is defined as follows:

The object of knowledge representation is to express knowledge in acomputer-tractable form, such that it can be used to help agents toperform well. (p. 157)

They also describe some of the requirements of a good knowledge represen-tation language. They contrast it with ordinary programming languages like C,Pascal or Lisp — these languages are good at expressing concrete data structuresand algorithms, but are less suited for describing more abstract knowledge in adeclarative way. That is because ordinary programming languages designed tocompletely describe the internal state of a computer. Knowledge representationsshould be able to deal with uncertainty, for example “either it will rain or it willsnow today.”

8 Background

Instead of these languages, a natural choice is predicate logic. Logic was orig-inally created to model formal thought, and has since come to be widely used inartificial intelligence as the formal language of choice. It has many advantages,the main ones being that simple, and that it can express all formal knowledge.

But if one wants to write down first order predicate logic formulas in a stan-dard text format, one quickly runs into trouble. There is no natural way of writingin plain text. Luckily, there is a standard language called KIF — the knowledge in-terchange format, which is described in Genesereth & Fikes (1992) as follows:

Knowledge Interchange Format (KIF) is a computer-oriented languagefor the interchange of knowledge among disparate programs. It hasa declarative semantics [. . . ]; it is logically comprehensive [. . . ] and itprovides for the definition of objects, functions and relations. (p. 2)

2.2 Knowledge Interchange Format

The knowledge interchange format is a collaborative effort at the computer sci-ence department at Stanford University. Its syntax is very similar to that of Lispor Scheme, that is, fully parenthesized expression exclusively constructed withprefix operators. But as opposed to Lisp, it is declarative, based on first orderpredicate logic. In addition to the basics of this logic, KIF contains a standardvocabulary for fields like basic arithmetic and analysis, lists, sets, functions, rela-tions, the representation of meta-knowledge (knowledge about knowledge), non-monotonicity (knowledge may change when new knowledge is added to it) anddefinitions.

KIF is not primarily intended to be a primary language for interacting withhuman beings — it is intended to be used by computer programs and agents fordescribing and communicating their knowledge bases. These programs will thenmost likely have their own way of interacting with the human users, so in generalthe KIF text stays hidden. It is not supposed to be an internal representation ofknowledge within these programs either. It makes no claims of being effectivean effective representation for manipulating knowledge while the programs areexecuting. The intention is that the programs reading the KIF text will convert itto a specialized internal format — pointer structures, arrays etc.

This is clearly analogous to other interchange formats, such as GIF1 whichmust be decompressed and decoded and translated into a two-dimensional arrayof pixel values, or PostScript, which is a complete programming language, meantprimarily for use in page description. A device that renders the postscript codeas graphics, be it a printer or a PostScript viewer program, will usually interpretthe code and transform it into its own graphics representation data structures.

1The Compuserve Graphics Interchange Format

2.3 The process of translation 9

2.2.1 The Knowledge Query and Manipulation Language

When discussing communication of knowledge between computer agents an-other language deserves mention: KQML, The Knowledge Query and Manip-ulation Language (Finin, McKay & Fritzson 1992, Finin & Weber 1993, Labrou& Finin 1997). Rather than representing knowledge itself, it acts as a protocol forcommunicating with languages like KIF (KRSL (Lehrer 1992), LOOM (MacGregor& Bates 1992), Prolog. . . ). It is based on “protocol stack” like that used in for in-stance TCP/IP. On top of the stack is a statement (or a set of statements) aboutthe knowledge base. Below this is the message layer, which encodes the type ofstatement (question, assertion etc.) and other meta-information (like which con-tents language and ontology is used). Below this is the communication layerwhich specifies the sender and receiver(s), and other information pertaining tothe communication itself.

2.3 The process of translation

Translating between different formats has at least two different aspects — a syn-tactic one and a semantic one. The two are closely connected, but for our currentpurposes, they may be divided as follows: Syntax deals with the legal structure ofa text, whereas semantics deal with its meaning. The structure of a text largely de-termines its meaning, but we are here interested only in what is a legal structure.

Having divided the subject thus, we may describe the different processes ofsyntactic and semantic translation. Syntactic translation deals with mapping fromone structure to another. That is, a syntactic translator takes a text which is legalin one language, and — without regarding its meaning — translates it onto a textwhich is syntactically legal in another (specified) language. If the two languagesare based on sufficiently similar semantic models, this might be sufficient. Often,however, there will be major discrepancies. This necessitates a semantic transla-tion, which considers the meaning of words, terms and concepts in the differentlanguages, making sure that the intended meaning is preserved in the new form.

Jeffrey Van Baalen and Richard E. Fikes, in their article “The Role of ReversibleGrammars in Translating Between Representational Languages” (1993), treat thistranslation process in a formal manner. They argue in favour of using an interlin-gua, a common format, and divide the translation into three separate steps:

1. Translation from the source language into a subset of the interlingua

2. Translation between subsets of the interlingua

3. Translation from a subset of the interlingua into the target language

The first and last steps correspond to what I call syntactic translation, while thesecond step corresponds to what I call semantic translation. Baalen and Fikes de-scribe a formalism they call “Definite Clause Translation Grammars” to developa method for proving whether or not a grammar is reversible2. I will not focus

2By reversible they mean that the same grammar will suffice for translating both to and fromthe language.

10 Background

AI0Win

FirstSTEP Metis X YAI0Win

FirstSTEPMetisXY

AI0Win

KIF

FirstSTEP Metis X Y

Figure 2.1: Number of translations with and without an interlingua

much on this problem, but there are a few points to be picked up from their for-malism:

� The use of an interlingua greatly reduces the number of different transla-tion programs needed. If one were to translate directly between n differentlanguages, one would need n(n� 1) translation programs. However, if onewere to only translate to and from a common language, one would onlyneed 2n programs. (See figure 2.1.)

� A translation is defined as a tuple hTL;Li;BTLi, where TL;Li is a binary relationbetween sentences3 in a language L and an interlingua Li, and BTL is a setof sentences in Li. TL;Li is a predicate of translation, whereas BTL is a setof “axioms” that might be needed in the interlingua to correctly representthe sentences that are to be translated. For instance, the language L mightuse units like centimeters and inches. Even though the relationship betweenthese may be implicit in the language L, there may be no such relationshipdefined in Li. Therefore, it has to be defined explicitly, in BTL.

So, to implement a translation mechanism between a number of languages, acommon language should be chosen which can adequately represent all of theother languages, including any implicit knowledge.

2.3.1 Syntactic structure

The syntax of a language is described mainly in terms of structure, that is, the legalstructures of its sentences. The structure of a sentence means how its parts relateto each other. Many methods have been devised for describing such structure

3Baalen & Fikes (1993) define it as a relationship between top-level forms in the language. Forsimplicity, I will use sentences instead.


S

NP VP

D N V NP

The mouse ate

D N

the cheese

Label SignificanceS SentenceNP Noun phraseVP Verb phraseD DeterminerN NounV Verb

Figure 2.2: The structure of a simple sentence

(see Aitchison 1992), but the basis is a hierarchic division. The structure of eachtext may be represented by an acyclic graph, or tree (see figure 2.2).

The grammar of a language is specified in terms of how each structural partmay be composed of other sub-parts. The example given would be legal in alanguage where a sentence could be composed by a noun phrase followed by averb phrase etc. Each part might have several legal compositions.

2.3.2 Semantics and ontologies

Even though it will not be a part of the syntactic translator described in this report,semantic translation is an essential part of the process.

A knowledge representation consists of many levels. As the name implies, itis supposed to represent knowledge, much in the same way as natural languagedoes. But on a “lower” level, it must be formalized to be of any use to a computer.

12 Background

Level Primitive concepts. . .Implementational are memory cells and pointers

Logical are predicatesEpistemological are structuring primitives

Ontological satisfy meaning postulatesConceptual are cognitive primitivesLinguistic are linguistic primitives

Figure 2.3: Main levels of knowledge representation.

At the bottom level, it consists only of pointers and registers, bits and bytes. Be-tween these extremes are several other levels, each with its separate function.

Nicola Guarino, in his article The Ontological Level (1994) extends a model pre-sented by Brachman (1979) to include the six levels shown in figure 2.3.

The ontological level is especially important in automated translation. AsFinin et al. (1992) describe it:

[Communication between knowledge-based systems] may only be ef-fective where the ontologies match, are shared, can be circumscribedand can be translated. (p. 5)

Gruber (1993) defines an ontology as “an explicit specification of a conceptual-ization.” So an ontology gives meaning to the language. It defines the meaning ofthe vocabulary, and constrain there correct usage. To translate between two lan-guages one must either create a common ontology for the systems, as shown byFox & Gruninger (1993), or one must be able to translate between ontologies, oreven translate the ontologies themselves from a canonical format like Ontolingua(Gruber 1992, Gruber 1993).

2.3.3 An example

In this section I will go through a simple example to illustrate the process of trans-lation.

The languages

The languages used in this example are the ones that the finished translator willuse, the GOL language (NCR n.d.) and KIF. The subset of KIF used here, will bemore thoroughly discussed in section 3.3.

Translating a simple model

Let’s assume we want to translate the simple GOL model in figure 2.4 into anotherrepresentation format — another language.

According to the semantics of the GOL language, this model represents a sin-gle object — object number 2883625 — of the type “GEM PRODUCT CONT.” The


gdlObject 2883625 GEM_PRODUCT_CONT {{InstanceId {2883626 847378031}}{IsChinaBox}{State Open}{Coordinates {-48 16 197.1999969482421875 256}}{RefScale 2}{Valueset "2b000a.3281aa18.TEST_ASCII" "" {

{IDENTIFIER "Products"}}}

}

Figure 2.4: A simple GOL model

first step in translating this model, is a syntactic translation into the interlingua.That requires first parsing it, to find its underlying syntactic structure. This canbe seen in figure 2.5.

Once this structure has been found, a transformation must be applied, thatcreates a new syntax tree. In this example, let us say that the rules of this trans-formation are as follows:

1. “gdlObject” is transformed into “object”

2. “InstanceId,” “IsChinaBox,” “State,” “Coordinates,” and “RefScale” are ig-nored, since they are specific to METIS, and not relevant to the knowledgebeing translated.

3. “ValueSet” is split into a number of “property” nodes, one for each childnode.

The result of applying this transformation is shown in figure 2.6.To create a text in the target language, in this case KIF, it is only necessary

to create a textual representation of the syntax tree, almost a “reverse parsing.”KIF uses Lisp s-expression syntax, so the mapping between syntax tree and textualsentences is trivial. The result is shown in figure 2.7.

What happens next?

After the model has been syntactically translated into the interlingua, it must betranslated into another subset of this language. It must be translated into a for-mat that supports the same ontology as the ultimate target language. The resultingtext will have a similar syntactic structure, but the vocabulary will have changed.A simple example might be a property of length. If language “A” uses the met-ric system, we might get a KIF expression containing (property HEIGHT 178"cm"). Before we can translate this into “B” which uses the old imperial units ofmeasurement, we must do a semantic translation within the interlingua. First ofall, the string "cm" is changed to "in", and then the number 178 is changed to452.12, resulting in (property HEIGHT 452.12 "in").

14 Background

gdlObject2883625

GEM_PRODUCT_CONT

InstanceId

IsChinaBox

State

Coordinates

RefScale

Valueset2b000a.3...

2883625

847378031

Open

-48

...

2

IDENTIFIER Products

Figure 2.5: Structure of the GOL model

object2883625

GEM_PRODUCT_CONTproperty IDENTIFIER Products

Figure 2.6: Transformed structure of the GOL model

(object 2883625 GEM_PRODUCT_CONT(property IDENTIFIER "Products")

)

Figure 2.7: The resulting KIF model


In a more realistic example, like translating between different business mod-els, the semantic differences might lie in the concepts used, as in “operation” vs.“function” vs. “process.” These might mean the same, and in that case the seman-tic translation would be a simple substitution. In most cases, however, it wouldrequire a more restructuring of the whole model, to accommodate all the differ-ent concepts used — to make it fit the new ontology. The full complexity of asemantic translation is far beyond the scope of this report.

Chapter 3

Work done

3.1 Requirements

For the translation system to be usable, the following basic functional require-ments must be met:

F1 It must use a common format that is able to represent all the knowledge thatmust be translated between the other formats.

F2 It must be able to parse the various formats as specified and create a text inthe common format with the same knowledge contents.

F3 It must be able to create texts in the various given formats from a text in thecommon format, again preserving the knowledge contents of the text.

In addition, there are some non-functional requirements that should be met:

N1 The system should be portable.

N2 The system should be extensible.

3.2 The represented domain of knowledge

The domain of knowledge represented by a common format in a translation sys-tem for communicating between heterogenous agents is, generally speaking, un-limited. If nothing was known about the agents, one might well use a full knowl-edge language like KIF, without restrictions. But in the system developed here,there is some domain specific constraints known.

The domain to be represented is quite generic. The given languages all de-scribe models of businesses or enterprises in one way or another. According tothe METIS meta-meta-model, used in the METIS GEM system, and the GOL lan-guage (NCR n.d.), the main entities of this domain are “objects” and “relation-ships.” Objects may be any element of a business — from a customer, to a product,or an order, or a procedure. The relationships describe the structure of the model.There might for instance be a relationship between a product and the division in

18 Work done

which it was produced, or between an order and the customer that placed it. Arelationship has a direction — that is, it would not be correct to say, using the sameexample, that an order placed a customer. This should be modeled.

In an “object oriented”1 it model like this, it is important to distinguish be-tween separate instances, but also to show which “class” or “type” they belongto. There is no real need to represent types as first order objects — they will beseen only as a special property of the instances. So if one has access to one in-stance, one should be able to decide whether it is, for instance, a human being oran animal. But given the class “human” it will not be trivial to find all instancesof this type.

To distinguish and refer to the instances, each object and relationship shouldhave a unique identifier.

With these concepts it is possible to describe the structure of a model, but itis not possible to represent much knowledge without making the model overlycomplex. One natural part is still lacking: Properties.

Both relationships and objects may have properties. Conceptually, propertiesare aspects of an instance denoted by a name and having a value. A person mightfor instance have a property with the name “height” and the value 178cm. Noconstraints are given on the properties an instance may have.

There are many similarities between this basic model and the entity–relation-ship model (the “ER”-model) introduced by Chen (1976).

3.3 The common format

The task of designing a common format for the translating consists of selecting asubset of KIF that can adequately represent the domain of knowledge describedabove. The following concepts must be present:

1. Objects

2. Relationships

3. Types

4. Identities

5. Properties

In addition, the relationships must clearly show between which objects theyhold.

In the common format, objects and relationships are represented by predicatesthat assert their existence. A model in this format is completely described by asequence of such predicates. The basic forms of these are:

1The knowledge model is not really object oriented, as defined in object oriented program-ming. I am here referring to the use of objects as the basic building block.

3.3 The common format 19

(object 235346 MAN)(object 523643 WOMAN)(relationship 142526 LOVE(from 235346)(to 523643))

This simple model describes a man and a woman and the fact that he lovesher. The from and to keywords are used solely for legibility. Semantically, theyare functions that return some abstract objects that represent a connection to orfrom an object, given by their single ID arguments. The two first arguments ofthe predicates are the ID of the instances, and their types.

Properties are constructed with the function property and are given as op-tional arguments at the end of the object and relationship predicates, likethis:

(object 425235 APPLE(property COLOUR "red")(property WEIGHT 4))

Chapter 4

Implementation and testing

4.1 Java and JavaCC

The choice of Java as implementation language has several reasons. One of themost important reasons was that it was the expressed wish of the end users of thesystem that it be implemented in Java. Another important factor is its portability.Once the program works on one platform, it is guaranteed to work on most ma-jour platforms. As opposed to for instance Prolog and Lisp, who might seem likenatural choices for a symbolic manipulation task such as translation, Java is objectoriented. That means that the resulting program will be much easier to extend andmaintain that it would be otherwise. Another possibility would of course be touse a fairly standard language such as C or C++, but these are not as portableby far as Java is. And since high performance in terms of execution speed is notreally an issue, there are no great advantages to using these languages instead ofJava.

Instead of implementing a parser from the bottom up, the reasonable thingto do is to use a parser generator. A parser generator creates a parser, based ona specified grammar. In this way, the parser may be specified declaratively (interms of its grammar) which means that it will take less work to create, and it willbe easier to maintain or extend, and probably easier to understand.

There are several parser generators available for Java. JLex (Berk 1997) is ascanner (lexical analyzer) generator. It has the advantage of being compatiblewith JavaCUP (Hudson 1998), a much used parser generator, but JLex only gen-erates scanners, and using two different programs should be avoided to keep thesystem simple. JavaCUP is similar to the standard UNIX utility yacc, which cre-ates parsers in C. One serious drawback is its low level of integration between lex-ical and syntactic analysis. Jax and Jell (Sriram n.d.) are two companion programsthat together cover the task of scanning and parsing. They have their drawbackstoo — the scanner generator cannot handle Unicode characters, and the parsergenerator can only handle a restricted type of grammar (LL grammars).

The program JavaCC (Sankar, Sreenivasa & Duncan n.d., McManis 1996) isprobably the best choice. Together with its preprocessor for generating syntaxtrees, JJTree, it covers all of the aspects of parser generation, and has several fea-tures not found in other such programs.One advantage is that it is developed by

22 Implementation and testing

ASTgdlObject ASTgdlRelship ASTgdlSubObject ASTmodel ASTvalueSet

GOLParserVisitor

GOL_To_KIF_Visitor

SimpleNode

ASTobject ASTrelationship ASTtext ASTproperty KIFParserVisitor

KIF_To_GOL_VisitorSimpleNode

Figure 4.1: Classes of the system

a branch of Sun Microsystems, who also created Java, so it will probably sup-port the developments of the Java language. One drawback is that is is quite big,compared to the others. I feel that this is not enough to outweigh its advantages.

4.2 Construction and implementation

The construction of the translation system was pretty straightforward, given theway the parser works by creating parse trees. The mechanism used is simply tocreate a textual representation in the target language directly from the parse tree.One way of doing this (which was, in fact the way I did it at first) is to includemethods in each node class to create a text. An “object” node would print out itsheader, including its ID and type. Then it would call each of its children in thesyntax tree in turn (they are all “property” nodes) so they print out themselves.Then, finally, the object would close itself with a right parenthesis (or whateverwould be appropriate to the target language).

This approach has several drawbacks. Firstly, the automatically generatednode classes would have to be extensively redefined, which would pose greatproblems if they had to be generated anew. Secondly, the code for generating textwould be spread over several classes. Thirdly, the translation mechanism wouldbe hardwired into the parser. If one wanted to use the KIF parser to translate intoanother language, one would have to rewrite it. In short — this solution is notvery modular and does not support code-reuse or ease of code maintenance.

A much better method is to encapsulate the translation and text generation ina separate class — a visitor. This visitor object traverses the syntax tree, creatingthe output as it goes. This solution is a well established object pattern (Felleisen& Friedman 1998), and is well supported by JavaCC.

4.2.1 Class structure

A simple class diagram can be seen in figure 4.1. In addition to these Java classescome the two parsers. They were both written in the grammar format parsed by

4.2 Construction and implementation 23

JJTree.

The AST-classes

These were all generated by JJTree, and are all subclasses of SimpleNode. Mostof their functionality is automatically generated — the only addition done wasthat of data fields. The object and relationship objects all have fields containingtheir ID and type. The relationships also have fields for the IDs and types of their“from” and “to” objects (see 3.3). The property object have fields containing theirname and value, while the valueset objects have Vector1 fields representing thenames and values of the properties they describe.

The translating visitors

These classes are written from scratch. They contain a visit() method for eachof the types of nodes, so that each method can create a textual representation forthis type of node. visit(ASTobject node, Object data), for example, isused to generate a textual representation of an ASTobject, using its fields id andtype, and calling its children nodes with the method childrenAccept() (inASTobject). Generating the text is generally quite straightforward.

There are, however, a few points worth mentioning. Firstly, in GOL relation-ships cannot refer to objects that have not been defined yet. To ensure that thiscondition is not violated, the translation is done in two passes. In the first pass,only object are written. In the second pass, only relationships. In that way, all theobjects come before the relationships. Which nodes are written, is constrained bya parameter to the accept() method.

A similar solution is used with the GOL classes, but to solve a different prob-lem. gdlRelships may have objects (“sub-objects”) defined in their to andfrom fields. This is not permitted in the KIF format. So, the KIF output is writtenin two passes as well — in the first pass all the ordinary objects and relationshipsare written, without the “sub-objects” whereas in the second pass, only these ob-jects are written.

Secondly, there is a need for unique “type” fields in the valueSet definitions.These fields are not stored when converting to KIF, and would probably not existat all when translating from a different language, so they have to be constructedwhen translating to GOL. This is done with the aid of the randomString()method of KIF To GOL Visitor. The fields consist of the ID and type of theobject or relationship, concatenated with a random string of length 10.

The parsers

The parser classes are constructed from two grammar files. The GOL parser isbased on the GOL grammar described in NCR (n.d.), and the KIF parser is basedon the grammar of the common KIF format, which is described in appendix B.The format of the grammar files themselves is described in appendix C.

1A standard Java class representing a variable-length list.

24 Implementation and testing

In addition to building parse trees, the parsers have some inserted Java codethat sets the data fields (i.e. id or type) of the nodes being created.

4.3 User interface

The user interface is described in more detail in appendix A.

4.4 Testing

The testing was done by translating a valid GOL file into KIF and back into GOL,and then trying to get METIS GEM to accept the result. The main problem thatwas encountered was that METIS GEM demanded a specific ordering of the en-tities in its files. If an entity was to refer to another entity, the one referred to hadto be defined first. Since there is not (and probably should not be) such a require-ment in the KIF format, it had to be imposed in the process of translating fromKIF to GOL.

The solution to this problem was reasonably straightforward. The only enti-ties that have recognizable references to other entities in the KIF format are rela-tionships, and they all refer to objects. So instead of a complete topological sortwith respect to references, the resulting GOL text was split in two: First all theobjects were printed, and then all the relationships.

Another problem that surfaced in testing was that for METIS GEM to importan object, its set of values had to have a unique name. Since this name was notrepresented in the KIF model, it had to be generated by concatenating the objectsID and type, and a random alpha-numeric string. Since the object IDs combinedwith types are supposed to be unique it would probably be sufficient to use onlythese two. The random string is just a precaution. (See section 4.2.1.)

Some of the files that were used for testing had been slightly edited by hand,and subsequently would not be translated. The reason was that the parser founda character that it did not know how to interpret — “00a0”. This turned out to bethe Unicode character “non-breaking space” which really has nothing to do in aGOL file. An attempt was made at making the parser read Unicode characters,but it was discarded. The result is, that if one wants to edit the files before theyare translated, the result has to be in plain ASCII text.

During the testing, several things that were a bit unclear about the GOL gram-mar were adjusted in the parser, to make it read the test files correctly. While thismade the parser more flexible, it also suggests that the grammar might containmore features not described in the specification (NCR n.d.). That means that itis quite possible that one must update the grammar files several times in the fu-ture. What was positive about this part of the testing was the discovery that theupdates were quite simple to do, which means that this probably is not a greatproblem after all, as long as one knows how the syntax is supposed to be.

There was also a bug in Metis that was uncovered. Some of the exported ob-jects and relationships had multiple valueSet fields with identical properties.This led to duplicate properties in the KIF files and the resulting GOL files when

4.4 Testing 25

translating back. Solvin this problem was a simple matter of making the trans-lating visitor only translate the first valueSet of any entity, as they really shouldhave only one.

After some adjustments, the system successfully parsed and translated an ex-ported GOL model containing 24534 lines of code both to and from the commonKIF format. On models of this length, the translator turned out to be a bit slow.

Chapter 5

Discussion

5.1 Adequacy of the solution

In this report I have proposed a solution to the problem of communicating andtranslating between different knowledge representations in a distributed enter-prise. There are two main issues to consider when assessing the adequacy of thissolution. First, is the strategy of translating knowledge representation the bestway of distributing information? And second, is the implementation shown anadequate way of implementing this solution?

As I stated in the introduction, an alternative to the translation strategy is en-forcing uniformity. That would make the problem of compatibility disappear,but would restrict the users unduly in their choice of software and perhaps evenoperating system. As long as one cannot enforce a standard file format on theproducers of the software, the only obvious solution is to transform or trans-late between the formats of the different programs. If this is done in a more orless transparent manner, by using the translating programs as filters when savingdata, this would give the impression of having only one format, which is quiteclose to the ideal state of total compatibility.

To asses the success of the implementation in solving the problem, one needsto consider whether it satisfies the requirements given.

5.1.1 Completeness

Does the solution satisfy all the demands of the problem?

F1 It must use a common format that is able to represent all the knowledge thatmust be translated between the other formats.

The common format (as described in section 3.3 and appendix B) does notcover all of the information that might conceivably be found in a GOL file, but itis expressive enough to represent all the portable knowledge contents of the GOLmodels. It is also complete enough so that when the KIF models are translatedback into GOL, they are still legal GOL models with essentially the same contents.What is mainly lost is information about the visual appearance of the model in

28 Discussion

Metis. This sort of information should not be found in the KIF text, as this shouldonly represent the model itself, in such a way that it may easily be recreated inanother modeling tool, with the aid of a suitable translation tool.

F2 It must be able to parse the various formats as specified and create a text inthe common format with the same knowledge contents.

The translator has been created to parse everything that complies with thegrammar of either GOL or KIF subset defined. It has been tested on the exampleGOL file from the GOL manual1 (NCR n.d.) and several real exported modelsfrom Metis. It has also been tested on its own KIF files, manually created KIFfiles, and the GOL files created by translating these KIF files. In general it seemsto fulfill this requirement without reservations.

F3 It must be able to create texts in the various given formats from a text in thecommon format, again preserving the knowledge contents of the text.

This has also been tested by translating exported GOL models to and from KIF,and subsequently importing them into Metis. Unfortunately, as there are no othertranslators implemented for this system yet, there has been no opportunity to testtranslation from another modeling language via KIF to GOL. However, assumingthe translated models conform to the grammar of the common format, and thatthe KIF files are semantically correct, this is not conceptually much different fromthe testing that has actually been done.

N1 The system should be portable.

The system is written completely in Java, which is a highly portable language.No platform-specific features have been used, and it has been shown to run bothon Linux, Solaris and Windows NT. Getting it to run on other operating systemsshould not pose any majour problems.

N2 The system should be extensible.

The way it is constructed, the system is quite extensible. If one wants to createa parser for another language, it is not necessary to change the existing code atall. If one wants to translate from one of the languages that already have a parser,then all one has to do is write a new translating visitor class — the existing codestill does not have to be changed. And if the grammar needs to be refined orchanged, all that is necessary is to change the grammar definition files. Assumingthat one is able to read the grammar definitions, changing the parsers should befairly easy.

1This example seemed to contain some elements that were inconsistent with the specificationitself. I have therefore chosen to treat both the example and the specification as equally valid.

5.2 Known problems 29

5.2 Known problems

There are a few known problems with the current implementation. For instance,the grammar definition for the GOL language suffers from two minor idiosyn-crasies. The first one is correct according to the specification, but wrong accordingto the examples in the same; that is, paths in GOL relationships will be understoodif they are written as follows:

{Path {POS1_X POS1_Y} [{POS2_X POS2_Y} {....}] }

This version is, however not correct:

{Path {{POS1_X POS1_Y} [{POS2_X POS2_Y} {....}] }}

This problem turned out to a bit tricky to solve. If an optional left brace was in-cluded after the “Path” keyword, the following problem occurred: When match-ing the former version of the path construct, the parser finds a left brace after“Path” and assumes this is the latter form. When it subsequently finds an integerliteral an exception is raised, as it expected another left brace. My solution wasto assume that only the latter version will be used, which seems like a reasonableassumption, based in the language specification and the exported models fromMetis.

The other problem has to do with reserved words. The GOL parser has de-fined a lot of keywords (token constants) that are used in parsing various expres-sions. For instance, the (case insensitive) keyword “Red” is used in the “Line-Colour” property of the gdlAttribute object. The problem with this is that when-ever the word “Red” (or “RED”) is used is used, it will be matched as this key-word. In some cases this might not be desirable. For instance, the values of prop-erties in a valueSet may be integers, real numbers, quoted strings or unquotedstrings. Such an unquoted string may legally have the value “Red,” but if oneattempts to use this value, it will not match the “simple literal” token that theparser expects; rather, it will match a “Red” token.

At present, I see no simple solution to this problem, but judging from thenames and values used in the test examples, and from the names of the parserkeywords, it is probably not critical.

5.3 Future work

Future work on this system may include improving the existing programs andcreating additional translators.

The existing programs may be improved in many ways. For instance the userinterface of the program is quite primitive, but it covers all of the functionality. Itlets you choose which way to translate, and which files to translate to and from.A possible addition might be the dynamic loading of new translation modules.

The problems (or “bugs”) described above may be fixed. It would also bepossible to extend the user interface, although the existing one covers the basicfunctionality. Another possibility is to extend the information contents of the

30 Discussion

KIF format. That would necessitate finding a generic way of representing theknowledge/information, so that other programs might use it and generate it, andone would have to extend the translation visitors so that several of the syntacticelements that are now being ignored would be translated.

Creating new translators is also mentioned above, in the section on extensibil-ity. Since the common format is already defined, this would simply be a matter ofcreating a parser for the new language, and two translation visitors, one for eachdirection of translation. (The KIF parser may well be used the way it is.)

In addition to these extensions to the main system one might want to embed itin other systems, for example as an add-on to METIS. Since the program is quitemodular and uses no external resources, save an input file and an output file,starting it from another program should pose no problems.

One feature that has not been implemented, but that might be desirable, isthe possible of having units associated with numbers. This is not implementedbecause the GOL specification does not describe how such units are used in GOL.It would be a simple matter to extend the KIF format to include these, for exampleas an optional last field in the property function, like this:

(property LENGTH 10 "cm")

Updating the translation program would mean to include this field in the gram-mar file for the KIF parser, and change the accept() methods for properties inthe KIF To GOL Visitor. A corresponding adjustmen would have to be madeto account for the unit representation in GOL as well.

Appendix A

Installation and usage instructions

To use the program described in this report you need a Java interpreter (a VirtualMachine). Sun Microsystems’ official version java or a lightweight version, thejre1 can be obtained via the Internet at http://www.java.sun.com or http://www.javasoft.com. (To use the translator program, you need at least version 1.1of the interpreter.)

The translator system is distributed in a single archive called parsers.zip.When you have installed your Java interpreter, put this file in your classpath2. Ifyou prefer, you can unpack the archive and simply put the resulting directoryparsers in one of the base directories of your classpath. (You have to unpackthe archive if you want to recompile the system and/or change the source code.)

When that is done, simply type at a command prompt:

> java parsers.Translator

The window shown in figure A.1 should appear. It is, of course also possible toput this command in a batch file (Windows) or a shell script (Unix) and make itavailable from the desktop. For systems that support direct evaluation of Javaclasses (Macintosh OS 8, Linux) one could simply make an alias (Macintosh) ora symbolic link (Linux) to the class parsers.Translator and execute that di-rectly.

The program is quite self-explanatory. As shown in figure A.1 it consists of asingle window which contains a text field and a menu. The text field is used todisplay information about the progress of the parser, and possibly error messagesif there is something wrong with the input file.

The menu has three items: From GOL to KIF..., From KIF to GOL...,and Quit. The first two start the translation process. The user is asked to choose asource file (with a standard file dialogue box) and a destination file. Then the pro-gram attempts to translate the source into the language specified, and to write theresult to the destination file. The last menu item quite the translator application.

1The “Java Runtime Environment”2The “zip” archive counts as a separate directory, so it must be entered into the environment

variable CLASSPATH, either in autoexec.bat (Windows) or in one of your startup shell scriptslike .login or .bash profile (Unix).

32 Installation and usage instructions

Figure A.1: Screenshot of the program

Appendix B

Grammar of the common format

The common format for representing knowledge in this project is a clearly delin-eated subset of KIF. This appendix describes its grammar in an informal versionof the BNF-form, which is described in [. . . ]. Production rules are written likethis:

h non-terminal i ! h terminal 1 i j h terminal 2 iThe “j” indicates choice between the two possible terminals. The grammar is

described in table B.1.

h text i ! h form i j h form i h text ih form i ! h object i j h relationship i

h object i ! “(object” h id i h type i h properties i “)”h relationship i ! “(relationship” h id i h type i

h from i h to i h properties i “)”h id i ! unique ID string or number

h type i ! string denoting typeh from i ! “(from ” h id i “)”

h to i ! “(from ” h id i “)”h properties i ! h property i j h property i h properties ih property i ! “(property” h name i h value i “)”

h name i ! string denoting name of a propertyh value i ! string or numeric value of a property

Figure B.1: Grammar of the common KIF format

Appendix C

Description of the JJTree/JavaCCgrammar file format

This is a summary of the format of the JJTree/JavaCC grammar file format asused in the files GOLParser.jjt and KIFParser.jjt. This summary covers only a sub-set of this format. A more thorough description can be found in the documenta-tion included in the JavaCC package (Sankar et al. n.d.). To see how this formatworks in practice, please consult the source code for the two files mentioned, inappendix D.

C.1 JavaCC

JavaCC (the Java Compiler Compiler) is a tool for creating lexical analyzers andparsers. It works by transforming a grammar file into a completely functionalparser. The format of these grammar files is very flexible, and allows Java code tobe inserted at any point, and lexical and syntactical specifications may be freelyintermixed.

At the beginning of a grammar file, several options may be set. One may forinstance set the level of lookahead, whether or not Unicode characters are to beescaped and whether the parser class should be based on static (class) methodsor whether one should be able to instantiate several parsers.

After the options have been declared, the main body of the class must be de-fined. This is the code that will be modified (by adding parsing methods) byJavaCC. After this block of Java code, the specification of the grammar begins.

Lexical specifications are done with statements like:

TOKEN:{<INTEGER_LITERAL: ("0"

|["1"-"9"] (["0"-"9"])*)>}

Such an expression may contain several token declarations like the integer literalshown above. (They may also have options like IGNORE CASE.) Other types of

36 Description of the JJTree/JavaCC grammar file format

specification blocks exist as well — such as “SKIP” which describes whitespaceor comments that are to be ignored.

The tokens are described with a kind of regular expressions. The definitionabove describes a kind of token that is either “0” or begins with a character in therange “1”–“9” and is followed by zero or more characters in the range “0”–“9” —a natural definition for an integer literal. That literal type may then be includedin the definition of other syntactic elements.

Syntactic productions are written in a manner reminiscent of Java method def-initions (the braces after the colon are for declaring local variables):

void sentence() : {}{nounPhrase() verbPhrase()

}

void verbPhrase() : {}{(

intransitiveVerb()| transitiveVerb() nounPhrase())

}

This production states that a sentence is composed of a noun phrase followed bya verb phrase, and that a verb phrase is either composed of a single intransitiveverb, or a transitive verb followed by another noun phrase1. As stated above,syntactic and lexical specifications, as well as java code may be freely intermixed:

void intransitiveVerb() : {}{(<SLEEPS>

|<LISTENS>){ System.out.println("Hello, world!"); }

}

This example would print “Hello, world” every time it found an intransitive verb(which is one of “sleeps” or “listens,” assuming these tokens have been definedin the obvious way). Usually the inserted Java code is used for controlling theparsing process or creating tangible results from it, for instance by constructingan abstract syntax tree.

1This simple grammar would be able to parse nonsensical expressions like “The mouse ate thecheese tasted good.”

C.2 JJTree 37

C.2 JJTree

JJTree is a preprocessor for JavaCC, which adds code to the grammar file andcreates a small set of classes for making abstract syntax trees. By simply using theJJTree program on a grammar file, the resulting parser will create a simple syntaxtree. By setting various options and adding some Java code, you can customizethis syntax tree to your needs.

For instance, JJTree defines the option “MULTI” which causes it to create syn-tax trees with separate classes for each element in the grammar (except for thosemarked #void). By setting the option “VISITOR” to true, a visitor interface iscreated, allowing the syntax tree to be visited by a visitor object that may, forinstance, create a textual representation of the it.

JJTree adds possibilities like referring to “jjtThis” in Java code at the end of agrammar production, setting the values of the data fields of the current node inthe syntax tree. That may be done like this:

void telephone() : { Token number }{<TELEPHONE> <COLON>number = <PHONE_NUMBER>{ jjtThis.number = number.image; }

}

Image is a field in the Token objects that contain a string version of the parsedtoken.

More information about this format, and the use of JavaCC and JJTree can befound in the documentation that follows the package (Sankar et al. n.d.). Thesoftware itself can be found at http://suntest.sun.com/JavaCC.

Appendix D

Source code

The programs were made by specifying a grammar in a format understood by theJJTree preprocessor for JavaCC. The classes that were created by JJTree are usedby the resulting parser to form syntax trees — these classes were modified to beable to print themselves in a translated form.

D.1 The JJTree/JavaCC source

D.1.1 GOLParser.jjt1 // File: GOLParser.jjt2 // Author: Magnus Lie Hetland3 // Created: 25 feb 199845 /** Parses the GOL (GEM Object Language) format of METIS GEM and6 produces a syntax tree for translation into KIF. **/78 // There is a problem with STRING_LITERAL vs. SIMPLE_LITERAL - what is9 // legal where?

1011 options {12 MULTI=true;13 LOOKAHEAD=3;14 }1516 PARSER_BEGIN(GOLParser)1718 package golparser;1920 import java.util.Vector;21 import java.io.*;2223 public class GOLParser {2425 protected static GOLParser t;2627 public static void main(String args[]) throws Exception {2829 InputStream in;

40 Source code

30 OutputStream out;3132 // If main() is supplied with two filenames, use them...33 try {34 in = new FileInputStream(args[0]);35 out = new FileOutputStream(args[1]);36 }37 // ... otherwise, use System.in and System.out and behave38 // like a UN*X filter.39 catch (Exception e) {40 in = System.in;41 out = System.out;42 System.err.println("(No arguments given - behaving like filter.)");43 }4445 if (t==null) {46 t = new GOLParser(in);47 }48 else {49 t.ReInit(in);50 }5152 // This might throw an exception:53 ASTmodel n = t.model();54 n.writeTranslated(out);5556 }5758 }5960 PARSER_END(GOLParser)6162 // Lexical specifications:6364 SKIP: /* Whitespace */65 {66 " "67 | "\t"68 | "\n"69 | "\r"70 | <"#" (˜["\n","\r"])* ("\n"|"\r"|"\r\n")> // Comments71 }7273 TOKEN [IGNORE_CASE]: /* Keywords */74 {75 <ADJUSTMENT: "Adjustment">76 | <AREA: "Area">77 | <ATTRIBUTES: "Attributes">78 | <ATTRIBUTE_GROUP: "AttributeGroup">79 | <BACKGROUND: "BackGround">80 | <BLACK: "Black">81 | <BLUE: "Blue">82 | <BOLD: "Bold">83 | <BOLD_ITALICS: "BoldItalics">84 | <CENTRE: "Centre">

42 Source code

140 | <WHITE: "White">141 | <YELLOW: "Yellow">142 }143144 // @@@ Font sizes145 // @@@ Stipple sizes146147 TOKEN: /* Separators */148 {149 <LEFT_BRACE: "{">150 | <RIGHT_BRACE: "}">151 }152153 TOKEN: /* Literals */154 {155156 <SIMPLE_LITERAL: ["a"-"z","A"-"Z"] (["a"-"z","A"-"Z","0"-"9","_"])*>157158 | <STRING_LITERAL:159 "\""160 ( // (˜["\"","\\","\n","\r"]) // Line breaks are allowed.161 (˜["\"","\\"])162 | ("\\"163 ( ["n","t","b","r","f","\\","’","\""]164 | ["0"-"7"] ( ["0"-"7"] )?165 | ["0"-"3"] ["0"-"7"] ["0"-"7"]166 )167 )168 )*169 "\""170 >171 | <INTEGER_LITERAL: (("+"|"-")? ["1"-"9"] (["0"-"9"])*|"0")>172 | <REAL_LITERAL: (("+"|"-")? ["1"-"9"] (["0"-"9"])*|"0")173 ("." (["0"-"9"])+)?>174 | <FONT_SIZE_LITERAL: "12"|"8"|"10"|"14"|"16"|"20"|"24"|"32">175 | <STIPPLE_SIZE_LITERAL: "50"|"0"|"25"|"75"|"100">176 }177178179 // Syntactic specifications180181 ASTmodel model() : {}182 {183 (184 gdlObject()185 | gdlRelship()186 | gdlValueset()187 | gdlAttributeGroup()188 | gdlAttribute()189 | gdlSymbolResource()190 | gdlAlias()191 )*192 { return jjtThis; }193 }194


195 void instanceId() #void : {} // Ignored196 {197 <LEFT_BRACE> <INSTANCE_ID>198 <LEFT_BRACE>199 <INTEGER_LITERAL>200 <INTEGER_LITERAL>201 <RIGHT_BRACE>202 <RIGHT_BRACE>203 }204205 void coordinates() #void : {} // Ignored206 {207 <LEFT_BRACE> <COORDINATES>208 <LEFT_BRACE>209 (<REAL_LITERAL>|<INTEGER_LITERAL>)210 (<REAL_LITERAL>|<INTEGER_LITERAL>)211 (<REAL_LITERAL>|<INTEGER_LITERAL>)212 (<REAL_LITERAL>|<INTEGER_LITERAL>)213 <RIGHT_BRACE>214 <RIGHT_BRACE>215 }216217 void refScale() #void : {} // Ignored218 {219 <LEFT_BRACE> <REFSCALE>220 (<REAL_LITERAL>|<INTEGER_LITERAL>) <RIGHT_BRACE>221 }222223 void isInvisible() #void : {} // Ignored224 {225 <LEFT_BRACE> <IS_INVISIBLE> <RIGHT_BRACE>226 }227228 void isChinaBox() #void : {} // Ignored229 {230 <LEFT_BRACE> <IS_CHINA_BOX> <RIGHT_BRACE>231 }232233 void state() #void : {} // Ignored234 {235 <LEFT_BRACE> <STATE> (<OPEN>|<CLOSED>) <RIGHT_BRACE>236 }237238 void openAttributeGroup() #void : {} // Ignored239 {240 <LEFT_BRACE> <ATTRIBUTE_GROUP>241 <LEFT_BRACE>242 // @@@ This is a bit unclear...243 <OPEN> <SIMPLE_LITERAL> <SIMPLE_LITERAL>244 <RIGHT_BRACE>245 <RIGHT_BRACE>246 }247248 void closedAttributeGroup() #void : {} // Ignored249 {

44 Source code

250 <LEFT_BRACE> <ATTRIBUTE_GROUP>251 <LEFT_BRACE>252 // @@@ This is a bit unclear...253 <CLOSED> <SIMPLE_LITERAL> <SIMPLE_LITERAL>254 <RIGHT_BRACE>255 <RIGHT_BRACE>256 }257258 void valueSet() : {259 Token name, value;260 Vector names = new Vector();261 Vector values = new Vector();262 }263 {264 <LEFT_BRACE> <VALUE_SET> (<STRING_LITERAL>)? (<STRING_LITERAL>)?265 <LEFT_BRACE>266267 (268 // Each pair is written like this: "{PROPERTY VALUE}"269 (<LEFT_BRACE> name = <SIMPLE_LITERAL>270 ( value = <INTEGER_LITERAL>271 | value = <REAL_LITERAL>272 | value = <STRING_LITERAL>)273 <RIGHT_BRACE>)274275 {276 names.addElement(name.image);277 values.addElement(value.image);278 }279280 | // Matrix properties are ignored281 (<LEFT_BRACE> <SIMPLE_LITERAL> <MATRIX>282 <LEFT_BRACE> <COLUMNS> <LEFT_BRACE>283 (<SIMPLE_LITERAL>)+ // @@@ Should be counted284 <RIGHT_BRACE> <RIGHT_BRACE>285 <LEFT_BRACE> <VALUES>286 (<LEFT_BRACE>287 (<SIMPLE_LITERAL>288 |<INTEGER_LITERAL>289 |<REAL_LITERAL>290 |<STRING_LITERAL>)+ // @@@ Should be the same number291 <RIGHT_BRACE>)+292 <RIGHT_BRACE>293 <RIGHT_BRACE>)294295 | // "Points to" properties are ignored296 (<LEFT_BRACE> <POINTS_TO>297 <SIMPLE_LITERAL> <SIMPLE_LITERAL> <SIMPLE_LITERAL>298 <RIGHT_BRACE>)299 )*300301 <RIGHT_BRACE>302 <RIGHT_BRACE>303304 { jjtThis.names = names; jjtThis.values = values; }


305306 }307308 void path() #void : {} // Ignored309 {310 <LEFT_BRACE> <PATH>311 (<LEFT_BRACE>)? // Inconsistency from the GOL manual312 (<LEFT_BRACE>313 (<REAL_LITERAL>|<INTEGER_LITERAL>)314 (<REAL_LITERAL>|<INTEGER_LITERAL>)315 <RIGHT_BRACE>)+316 (<RIGHT_BRACE>)? // Inconsistency from the GOL manual317 <RIGHT_BRACE>318 }319320 String[] from() #void : { Token fromId, fromType; }321 {322 <LEFT_BRACE> <FROM>323 fromId = <INTEGER_LITERAL>324 fromType = <SIMPLE_LITERAL>325 <RIGHT_BRACE>326 {327 String[] pair = new String[2];328 pair[0] = fromId.image;329 pair[1] = fromType.image;330 return pair;331 }332 }333334 String[] to() #void : { Token toId, toType; }335 {336 <LEFT_BRACE> <TO>337 toId = <INTEGER_LITERAL>338 toType = <SIMPLE_LITERAL>339 <RIGHT_BRACE>340 {341 String[] pair = new String[2];342 pair[0] = toId.image;343 pair[1] = toType.image;344 return pair;345 }346 }347348 void symbol() #void : {} // Ignored349 {350 <LEFT_BRACE> <SYMBOL> <SIMPLE_LITERAL> <RIGHT_BRACE>351 }352353 void isUser() #void : {} // Ignored354 {355 <LEFT_BRACE> <IS_USER> <RIGHT_BRACE>356 }357358 void variant() #void : {} // Ignored359 {

46 Source code

360 <LEFT_BRACE> <VARIANT> <SIMPLE_LITERAL> <RIGHT_BRACE>361 }362363 void attributes() #void : {} // Ignored364 {365 <LEFT_BRACE> <ATTRIBUTES>366 (<SIMPLE_LITERAL>|<STRING_LITERAL>)367 <RIGHT_BRACE>368 }369370 void font() #void : {} // Ignored371 {372 <LEFT_BRACE> <FONT>373 (<HELVETICA>|<COURIER>|<TIMES>|<SYMBOL>)?374 <RIGHT_BRACE>375 }376377 void size() #void : {} // Ignored378 {379 <LEFT_BRACE> <SIZE>380 <FONT_SIZE_LITERAL>381 <RIGHT_BRACE>382 }383384 void foreGround() #void : {} // Ignored385 {386 <LEFT_BRACE> <FOREGROUND>387 (<BACKGROUND>|<BLACK>|<WHITE>|<RED>|<ORANGE>|388 <YELLOW>|<GREEN>|<BLUE>|<VIOLET>)389 <RIGHT_BRACE>390 }391392 void backGround() #void : {} // Ignored393 {394 <LEFT_BRACE> <BACKGROUND>395 (<BACKGROUND>|<BLACK>|<WHITE>|<RED>|<ORANGE>|396 <YELLOW>|<GREEN>|<BLUE>|<VIOLET>)397 <RIGHT_BRACE>398 }399400 void style() #void : {} // Ignored401 {402 <LEFT_BRACE> <STYLE>403 (<REGULAR>|<BOLD>|<ITALICS>|<BOLD_ITALICS>)404 <RIGHT_BRACE>405 }406407 void adjustment() #void : {} // Ignored408 {409 <LEFT_BRACE> <ADJUSTMENT>410 (<LEFT>|<RIGHT>|<CENTRE>)411 <RIGHT_BRACE>412 }413414 void lineColour() #void : {} // Ignored


415 {416 <LEFT_BRACE> <LINE_COLOUR>417 (<BACKGROUND>|<BLACK>|<WHITE>|<RED>|<ORANGE>|418 <YELLOW>|<GREEN>|<BLUE>|<VIOLET>)419 <RIGHT_BRACE>420 }421422 void stipple() #void : {} // Ignored423 {424 <LEFT_BRACE> <STIPPLE> <STIPPLE_SIZE_LITERAL> <RIGHT_BRACE>425 }426427 void linePattern() #void : {} // Ignored428 {429 <LEFT_BRACE> <LINE_PATTERN>430 (<LINE>|<DASHED>|<DOTTED>|<DASH_DOTTED>|<NONE>)431 <RIGHT_BRACE>432 }433434 void lineThickness() #void : {} // Ignored435 {436 <LEFT_BRACE> <LINE_THICKNESS>437 (<NARROW>|<THICK>|<FAT>|<EXTRA_FAT>)438 <RIGHT_BRACE>439 }440441 // ***** Top level nodes: *****442443 void gdlObject() : { Token id, type; }444 {445446 // Start of object447 <GDL_OBJECT>448 id = <INTEGER_LITERAL>449 type = <SIMPLE_LITERAL>450 <LEFT_BRACE>451452 // Assumes correct use of mandatory/optional parts453 ( instanceId()454 | coordinates()455 | refScale()456 | isInvisible()457 | isChinaBox()458 | state()459 | openAttributeGroup()460 | closedAttributeGroup()461 | valueSet()462 )+463464 // End of object465 <RIGHT_BRACE>466467 {468 jjtThis.id = id.image;469 jjtThis.type = type.image;

48 Source code

470 }471472 }473474 void gdlRelship() : {475 Token id, type;476 String[] fromPair = {"?","?"},477 toPair = {"?","?"};478 }479 {480 <GDL_RELSHIP>481 id = <INTEGER_LITERAL>482 type = <SIMPLE_LITERAL>483 <LEFT_BRACE>484485 ( instanceId()486 | path()487 | isInvisible()488 | valueSet()489 | fromPair = from()490 | toPair = to()491 )+492493 <RIGHT_BRACE>494495 {496 jjtThis.id = id.image;497 jjtThis.type = type.image;498 jjtThis.fromId = fromPair[0]; jjtThis.fromType = fromPair[1];499 jjtThis.toId = toPair[0]; jjtThis.toType = toPair[1];500 }501502 }503504 void gdlValueset() #void : {} //@ Ignored505 {506 <GDL_VALUESET> <INTEGER_LITERAL> <SIMPLE_LITERAL>507 <STRING_LITERAL> (<STRING_LITERAL>)? <LEFT_BRACE>508509 (510 // {PROPERTY VALUE}511 (<LEFT_BRACE> <SIMPLE_LITERAL>512 (<INTEGER_LITERAL>|<REAL_LITERAL>|<STRING_LITERAL>)513 <RIGHT_BRACE>)514 |515 (<LEFT_BRACE> <SIMPLE_LITERAL> <MATRIX>516 <LEFT_BRACE> <COLUMNS> <LEFT_BRACE>517 (<SIMPLE_LITERAL>)+ // @@@ Should be counted518 <RIGHT_BRACE> <RIGHT_BRACE>519 <LEFT_BRACE> <VALUES>520 (<LEFT_BRACE>521 (<SIMPLE_LITERAL>522 |<INTEGER_LITERAL>523 |<REAL_LITERAL>524 |<STRING_LITERAL>)+ // @@@ Should be the same number


525 <RIGHT_BRACE>)+526 <RIGHT_BRACE>527 <RIGHT_BRACE>)528 |529 (<LEFT_BRACE> <POINTS_TO>530 <SIMPLE_LITERAL> <SIMPLE_LITERAL> <SIMPLE_LITERAL>531 <RIGHT_BRACE>)532 )*533534 <RIGHT_BRACE>535 }536537 void gdlAttributeGroup() #void : {} //@ Ignored538 {539 <GDL_ATTRIBUTE_GROUP> <SIMPLE_LITERAL> <LEFT_BRACE>540541 ( symbol()542 | isUser()543 | variant()544 | attributes()545 )+546547 <RIGHT_BRACE>548 }549550 void gdlAttribute() #void : {} //@ Ignored551 {552 <GDL_ATTRIBUTE> <SIMPLE_LITERAL>553554 ((<TEXT> <LEFT_BRACE>555556 ( font()557 | size()558 | foreGround()559 | backGround()560 | style()561 | adjustment()562 )+563564 )565 |566 (567568 (foreGround()569 |backGround()570 |lineColour()571 |stipple()572 |linePattern()573 |lineThickness()574 )+575576 ))577 <RIGHT_BRACE>578579 }

50 Source code

580581 void gdlSymbolResource() #void : {} //@ Ignored582 {583 <GDL_SYMBOL_RESOURCE> <SIMPLE_LITERAL>584 }585586 void gdlAlias() #void : {} //@ Ignored587 {588 <GDL_ALIAS> <SIMPLE_LITERAL> <SIMPLE_LITERAL>589 }590

D.1.2 KIFParser.jjt1 // File: KIFParser.jjt2 // Author: Magnus Lie Hetland3 // Created: 23. feb 19984 // Updated: 24. apr 199856 options {7 MULTI=true;8 LOOKAHEAD=2;9 }

1011 PARSER_BEGIN(KIFParser)1213 package kifparser;1415 import java.util.Hashtable;16 import java.io.*;1718 public class KIFParser {1920 protected static KIFParser t;2122 public static void main(String[] args) throws Exception {2324 InputStream in;25 OutputStream out;2627 // If main() is supplied with two filenames, use them...28 try {29 in = new FileInputStream(args[0]);30 out = new FileOutputStream(args[1]);31 }32 // ... otherwise, use System.in and System.out and behave33 // like a UN*X filter.34 catch (Exception e) {35 in = System.in;36 out = System.out;37 System.err.println("(No arguments given - behaving like filter.)");38 }3940 if (t==null) {41 t = new KIFParser(in);


42 }43 else {44 t.ReInit(in);45 }4647 // This might throw an exception:48 ASTtext n = t.text();49 n.writeTranslated(out);5051 }5253 }5455 PARSER_END(KIFParser)5657 // Lexical specifications:5859 SKIP: /* Whitespace */60 {61 " "62 | "\t"63 | "\n"64 | "\r"65 | <";" (˜["\n","\r"])* ("\n"|"\r"|"\r\n")>66 }6768 TOKEN [IGNORE_CASE]: /* Special words */69 {70 <OBJECT: "object">71 | <RELATIONSHIP: "relationship">72 | <FROM: "from">73 | <TO: "to">74 | <PROPERTY: "property">75 }7677 TOKEN: /* Separators */78 {79 <LPAREN: "(">80 | <RPAREN: ")">81 }8283 TOKEN: /* Literals */84 {85 <STRING_LITERAL:86 ("\""87 ( // (˜["\"","\\","\n","\r"]) // Line breaks allowed...88 (˜["\"","\\"])89 | ("\\"90 ( ["n","t","b","r","f","\\","’","\""]91 | ["0"-"7"] ( ["0"-"7"] )?92 | ["0"-"3"] ["0"-"7"] ["0"-"7"]93 )94 )95 )*96 "\"")

52 Source code

97 | (["a"-"z","A"-"Z","_"]98 (["a"-"z","A"-"Z","_","0"-"9"])*)99 >

100 |101 <INTEGER_LITERAL: (("+"|"-")? ["1"-"9"] (["0"-"9"])*|"0")>102 }103104105 // Syntactic specifications106107 ASTtext text() : {}108 {109 (sentence())+110 { return jjtThis; }111 }112113 void sentence() #void : {}114 {115 (object() | relationship())116 }117118 void object() :119 {120 Token id, type;121 }122 {123 <LPAREN> <OBJECT>124125 id = <INTEGER_LITERAL>126 type = <STRING_LITERAL>127128 { jjtThis.id = id.image; jjtThis.type = type.image; }129130 (term())*131132 <RPAREN>133 }134135 void relationship() :136 {137 Token id,138 type,139 fromId,140 toId,141 fromType,142 toType;143 }144 {145 <LPAREN> <RELATIONSHIP>146147 id = <INTEGER_LITERAL>148 type = <STRING_LITERAL>149 { jjtThis.id = id.image; jjtThis.type = type.image; }150151 <LPAREN><FROM>

D.2 The modified AST classes 53

152 fromId = <INTEGER_LITERAL>153 fromType = <STRING_LITERAL>154 <RPAREN>155 { jjtThis.fromId = fromId.image; jjtThis.fromType = fromType.image; }156157 <LPAREN><TO>158 toId = <INTEGER_LITERAL>159 toType = <STRING_LITERAL>160 <RPAREN>161 { jjtThis.toId = toId.image; jjtThis.toType = toType.image; }162163 (term())*164165 <RPAREN>166167 }168169 void term() #void : {}170 {171 property()172 }173174 void property() : { Token name, value; }175 {176 <LPAREN> <PROPERTY>177178 name = <STRING_LITERAL>179 (value = <STRING_LITERAL> | value = <INTEGER_LITERAL>)180 { jjtThis.name = name.image; jjtThis.value = value.image; }181182 <RPAREN>183 }

D.2 The modified AST classes

The only modifications done to the classes that comprise the abstract syntax treesis the addition of data fields.

D.2.1 ASTgdlObject.java1 /* Generated By:JJTree: Do not edit this line. ASTgdlObject.java */23 package golparser;45 import java.io.*;67 public class ASTgdlObject extends SimpleNode {89 // Added by mlh:

10 public String id;11 public String type;1213 public String toString() {

54 Source code

14 return toString("");15 }1617 public String toString(String prefix) { // Ignore prefix18 return "(object "+id+" "+type;19 }2021 public void writeTranslated(OutputStream o) throws IOException {22 PrintWriter out = new PrintWriter(o,true);23 out.println(toString());24 if (children != null) {25 for (int i = 0; i < children.length; ++i) {26 SimpleNode n = (SimpleNode)children[i];27 if (n != null) {28 n.writeTranslated(o);29 }30 }31 }32 out.println(")");33 }3435 // Automatically generated:36 public ASTgdlObject(int id) {37 super(id);38 }3940 public ASTgdlObject(GOLParser p, int id) {41 super(p, id);42 }4344 }

D.2.2 ASTgdlSubObject.java

D.2.3 ASTgdlRelship.java1 /* Generated By:JJTree: Do not edit this line. ASTgdlRelship.java */23 package golparser;45 import java.io.*;67 public class ASTgdlRelship extends SimpleNode {89 // Added by mlh:

10 public String id;11 public String type;12 public String fromId;13 public String fromType;14 public String toId;15 public String toType;16


1718 public String toString() {19 return toString("");20 }2122 public String toString(String prefix) { // Ignore prefix23 return "(relationship "+id+" "+type+"\n"24 +" (from "+fromId+" "+fromType+")\n"25 +" (to "+toId+" "+toType+")";26 }2728 public void writeTranslated(OutputStream o) throws IOException {29 PrintWriter out = new PrintWriter(o,true);30 out.println(toString());31 if (children != null) {32 for (int i = 0; i < children.length; ++i) {33 SimpleNode n = (SimpleNode)children[i];34 if (n != null) {35 n.writeTranslated(o);36 }37 }38 }39 out.println(")");40 }4142 // Automatically generated:43 public ASTgdlRelship(int id) {44 super(id);45 }4647 public ASTgdlRelship(GOLParser p, int id) {48 super(p, id);49 }5051 }

D.2.4 ASTvalueSet.java1 /* Generated By:JJTree: Do not edit this line. ASTvalueSet.java */23 package golparser;45 import java.util.Vector;6 import java.io.*;78 public class ASTvalueSet extends SimpleNode {9

10 // Added by mlh:11 public Vector names;12 public Vector values;1314 public void writeTranslated(OutputStream o) throws IOException {15 PrintWriter out = new PrintWriter(o,true);16 for (int i=0; i<names.size(); i++) {17 out.print(" (property ");

56 Source code

18 out.print(names.elementAt(i));19 out.print(" ");20 out.print(values.elementAt(i));21 out.println(")");22 }23 }2425 // Automatically generated:26 public ASTvalueSet(int id) {27 super(id);28 }2930 public ASTvalueSet(GOLParser p, int id) {31 super(p, id);32 }3334 }

D.2.5 ASTobject.java1 /* Generated By:JJTree: Do not edit this line. ASTobject.java */23 package kifparser;45 import java.io.*;67 public class ASTobject extends SimpleNode {89 // Added by mlh:

10 public String id;11 public String type;1213 public String toString() {14 return toString("");15 }1617 public String toString(String prefix) { // Ignore prefix18 return "gdlObject "+id+" "+type+" {\n"19 +" {Coordinates {0 0 0 0}}"; // The coordinates are unknown.2021 }2223 public void writeTranslated(OutputStream o) throws IOException {24 PrintWriter out = new PrintWriter(o,true);2526 out.println(toString());27 if (children != null) {28 // Generate a unique VNAME:29 String vname = id+"_"+stripQuotes(type)+"_"+randomString(10);30 out.println(" {ValueSet \""31 +vname32 +"\" \"\" {");3334 for (int i = 0; i < children.length; ++i) {35 SimpleNode n = (SimpleNode)children[i];


36 if (n != null) {37 n.writeTranslated(o);38 }39 }40 out.println(" } }");41 }42 out.println("}");43 }4445 // Automatically generated:4647 public ASTobject(int id) {48 super(id);49 }5051 public ASTobject(KIFParser p, int id) {52 super(p, id);53 }5455 }

D.2.6 ASTrelationship.java1 /* Generated By:JJTree: Do not edit this line. ASTrelationship.java */23 package kifparser;45 import java.io.*;67 public class ASTrelationship extends SimpleNode {89 // Added by mlh:

10 public String id;11 public String type;12 public String fromId;13 public String fromType;14 public String toId;15 public String toType;161718 public String toString() {19 return toString("");20 }2122 public String toString(String prefix) { // Ignore prefix23 return "gdlRelship "+id+" "+type+" {";24 }2526 public void writeTranslated(OutputStream o) throws IOException {27 PrintWriter out = new PrintWriter(o,true);28 out.println(toString());29 if (children != null) {3031 // Generate a unique VNAME:32 String vname = id+"_"+stripQuotes(type)+"_"+randomString(10);

58 Source code

33 out.println(" {ValueSet \""34 +vname35 +"\" \"\" {");3637 for (int i = 0; i < children.length; ++i) {38 SimpleNode n = (SimpleNode)children[i];39 if (n != null) {40 n.writeTranslated(o);41 }42 }43 out.println(" } }");44 }45 out.println(" {From "+fromId+" "+fromType+"}");46 out.println(" {To "+toId+" "+toType+"}");47 out.println("}");48 }4950 // Automatically generated:51 public ASTrelationship(int id) {52 super(id);53 }5455 public ASTrelationship(KIFParser p, int id) {56 super(p, id);57 }5859 }

D.2.7 ASTproperty.java1 /* Generated By:JJTree: Do not edit this line. ASTproperty.java */23 package kifparser;45 import java.io.*;67 public class ASTproperty extends SimpleNode {89 // Added by mlh:

10 public String name;11 public String value;1213 public String toString() {14 return " {"+name+" "+value+"}";15 }1617 public void writeTranslated(OutputStream o) throws IOException {18 PrintWriter out = new PrintWriter(o,true);19 out.println(this);20 }2122 // Automatically generated:23 public ASTproperty(int id) {24 super(id);25 }

D.3 The translation visitor classes 59

2627 public ASTproperty(KIFParser p, int id) {28 super(p, id);29 }3031 }

D.3 The translation visitor classes

D.3.1 KIF To GOL Visitor

D.3.2 GOL To KIF Visitor

Bibliography

Aitchison, J. (1992), Teach yourself linguistics, fourth edn, Hodder & Stoughton,London.

Baalen, J. V. & Fikes, R. E. (1993), ‘The role of reversible grammars in translatingbetween representation languages’, published on the World Wide Web.*http://www-ksl.stanford.edu/knowledge-sharing/papers/KSL-93-67.ps

Berk, E. (1997), ‘Jlex: A lexical generator for java(tm)’, published on the WorldWide Web. Documentation included in the JLex package.*http://www.cs.princeton.edu/�appel/modern/java/JLex/manual.html

Brachman, R. J. (1979), On the epistomological status of semantic networks, inN. V. Findler, ed., ‘Assosiative Networks: Representation and Use of Knowl-edge by Computers’, Academic Press.

Chen, P. (1976), ‘The entity relationship model — toward a unified view of data’,AST transactions on database systems 1(1).

Felleisen, M. & Friedman, D. P. (1998), A Little Java, A Few Patterns, MIT Press,Massachusetts Institute of Technology, Cambridge, Massachusetts 02142.

Finin, T., McKay, D. & Fritzson, R. (1992), An overview of kqml: A knowledgequery and manipulation language, Technical report, DARPA and Rome Lab-oratory. Written by the KQML Advisory Group with majour contributionsfrom Tim Finin, Don McKay and Rich Fritzson.

Finin, T. & Weber, J. (1993), Specification of the kqml agent-communication lan-guage (draft), Technical report, The DARPA Knowledge Sharing InitiativeExternal Interfaces Working Group.*http://www-ksl.stanford.edu/knowledge-sharing/papers/kqml-spec.ps

Fox, M. S. & Gruninger, M. (1993), Ontologies for enterprise integration, Tech-nical report, Department of industrial engineering, University of Toronto, 4Taddle Creek Road, Toronto, Ontario M5S 1A4.*http://www.ie.utoronto.ca/EIL/public/onto.ps

Genesereth, M. R. & Fikes, R. E. (1992), Knowledge interchange format, version 3.0:Reference Manual, Computer science department, Stanford university, Stan-ford, California 94305.

62 BIBLIOGRAPHY

Gruber, T. R. (1992), Ontolingua: A mechanism to support portable ontologies,Technical report, Knowledge systems laboratory, Stanford University, 701Welch road, building C, Palo Alto, CA 94304.*http://ksl-web.stanford.edu/knowledge-sharing/papers/ontolingua-long.ps

Gruber, T. R. (1993), A translation approach to portable ontology specifications,Technical Report KSL 92-71, Knowledge systems laboratory, Stanforduniversity, 701 Welch road, building C, Palo Alto, CA 94304.*http://ksl-web.stanford.edu/knowledge-sharing/papers/ontolingua-intro.rtf

Guarino, N. (1994), The ontological level. Invited paper presented at the 16thWittgenstein Symposium, Kirchberg, Austria, August 1993.*http://www-ksl.stanford.edu/knowledge-sharing/papers/ontological-level.ps

Hudson, S. E. (1998), CUP User’s Manual, Graphics Visualization and UsabilityCenter, Georgia Institute of Technology. published on the World Wide Web.*http://www.cs.princeton.edu/�appel/modern/java/CUP/manual.html

Labrou, Y. & Finin, T. (1997), A proposal for a new kqml specification, Technicalreport, Computer Science and Electrical Engineering Departmens (CSEE),University of Maryland Baltimore County (UMBC), Baltimore, Maryland21250.

Lehrer, N. (1992), ‘Krsl version 2.0’. Language specification and manual.

MacGregor, R. & Bates, R. (1992), The loom knowledge representation language,in ‘Proceedings of the Knowledge-Based Workshop’.

McManis, C. (1996), ‘Looking for lex and yacc for java? you don’t know jack’, JavaWorld 12. published on the World Wide Web.*http://www.javaworld.com/javaworld/jw-12-1996/jw-12-jack.html

NCR (n.d.), Metis GEM User Manual. Published by NCR Norge; documentationincluded with the program METIS GEM.

Russel, S. & Norvig, P. (1995), Artificial intelligence: a modern approach, PrenticeHall series in artificial intelligence, second edn, Prentice Hall, Upper SaddleRiver, New Jersey 07458.

Sankar, S., Sreenivasa, V. & Duncan, R. (n.d.), JavaCC Documentation, Sun Test,The Java testing unit of Sun Microsystems, Inc., 901 San Antonio Road, PaloAlto, CA 94303 USA. Documentation included in the JavaCC package.*http://suntest.sun.com/JavaCC/DOC/

Sriram, K. B. (n.d.), ‘Free tools for java(tm)’, published on the World Wide Web.*http://gandalf.pht.com/sourcemountain/Java/Tools/Mix/

Index

AI0Win, 5artificial intelligence, 7

BNF, 6, 33

C, 7, 21C++, 21compatibility, 5, 27

enterprise integration, 5entity–relationship, 18ER, see entity–relationship

FirstSTEP, 5

GEM Object Language, 6, 12, 24GIF, see Graphics Interchange FormatGlobeman 21, 5GOL, see GEM Object LanguageGraphics Interchange Format, 8

Interfacing Technologies Co., 5interlingua, 9–10, 13Internet, 5, 31

Java, 21–22, 28Java runtime environment, 31JavaCC, 21–22, 35–36JavaCUP, 21Jax, 21Jell, 21JJTree, 21, 23, 37Jlex, 21

KBSI Inc., 5KIF, see Knowledge Interchange For-

matKnowledge Interchange Format, 6, 8–

9, 12, 17, 18, 24Knowledge Query and Manipulation

Language, 9

knowledge representation, 7–8KQML, see Knowledge Query and

Manipulation LanguageKRSL, 9

Linux, 28, 31Lisp, 7, 8, 13, 21logic, see predicate logicLOOK, 9

Macintosh, 31meta-knowledge, 8Metis, 5, 17, 24, 28, 29

NCR Norge A.S., 5non-monotonicity, 8

object oriented, 18, 21ontolingua, 12ontologies, 11–12ontology, 13operating system, 27

parser generator, 21Pascal, 7pattern, 22predicate logic, 8Prolog, 9, 21

s-expression, 13Scheme, 8semantics, 9, 11–12Solaris, 28Sun Microsystems, 22, 31syntax, 9–11

syntax trees, 11, 13

TCP/IP, 9telecommunication, 5telecommuting, 5translation, 5

64 INDEX

Unicode, 21Unix, 31

virtual enterprises, 5Virtual Machine, 31visitor, 22VRIDGE, 5

Windows, 31Windows NT, 28

yacc, 21

Syntactic Transformation of Knowledge Bases in …hetland.org/research/1998/syntran.pdfSyntactic...

Documents

Transcript of Syntactic Transformation of Knowledge Bases in …hetland.org/research/1998/syntran.pdfSyntactic...