Roadmap

Introduction to the KACTUS toolkit

VOID, the KACTUS toolkit, is an interactive environment for browsing, editing and managing (libraries of) ontologies. VOID supports the theoretical and application oriented workpackages by providing an environment in which one can experiment with theoretical issues (e.g. organisation of libraries of ontologies, translating between different ontology formalisms) and also perform practical work (e.g. browse, edit and query ontologies in various formalisms).

VOID also provides an API (Application Programmers Interface). The API provides access to the ontologies created with VOID, but does not require the interactive toolkit itself. The API has been used successfully to develop applications in the KACTUS project. The API supports both programs written in C/C++ and programs written Prolog (or both). The distribution contains an example application in the directory ./labein.

VOID consists of various software modules. In normal operation, the user will access the interactive window-based environment. One of the aims of KACTUS is to support reuse of ontologies. In order to support this, the toolkit can handle various ontology formalisms (CML, EXPRESS and Ontolingua) and can perform (partial) translations between these formalisms.

• Formalism support
  • CML
  • EXPRESS
  • Ontolingua
• Library support
• Parsers and translators

Formalism support

The KACTUS project has decided that several formalisms in which one can write down ontologies should be supported. This is partly due to the technical domains being investigated within the project (e.g. information about ship designs is exchanged in EXPRESS) and the fact that not many ontology formalisms can describe task or problem solving knowledge (hence CML).

The main formalism in KACTUS (and the toolkit) is CML (Conceptual Modelling Language). This language was originally developed as part of the KADS and CommonKADS project. In KACTUS, CML has been refined and updated (see CML syntax reference). The other two formalisms currently supported by the toolkit are EXPRESS (a language used for the exchange of information about products) and Ontolingua (mainly used in the AI community; a formal language used to structure knowledge about various domains).

• CML support
• EXPRESS support
• Ontolingua support

CML support

CML (Conceptual Modelling Language) can be used to model knowledge. CML is different from most other ontology formalisms in that it makes an explicit distinction between domain knowledge, inference knowledge, task knowledge and problem-solving knowledge. CML uses a notation that is mostly informal, knowledge modelled in CML cannot be executed by a program.

The most recent reference to CML can be found at ``CML: The CommonKADS conceptual modelling language''. Note that the CML syntax definition in this paper is not up-to-date, a BNF of CML that the KACTUS toolkit accepts can be found at ``CML syntax in BNF''.

Currently, the KACTUS toolkit has the following functionality related to CML:

Import

CML files can be imported into the toolkit through a separate module (the CML parser). The CML parser checks the syntactical correctness of the CML input file and generates ECO (the internal representation of the toolkit). The ECO is imported into the toolkit. The CML parser can also generate LaTeX and HTML from an input file. Importing CML is transparent to users of the toolkit. VOID will call the CML parser automatically.

Export and pretty-printing

The toolkit can generate a CML file from the internal representation, this feature is useful when extracting parts of the CML (e.g. to enhance reuse in the library) or when the CML has been edited inside the toolkit.

Browse (graphically)

The CML can be graphically browsed. The toolkit generates a graphical variant of CML from the internal representation and shows it to the user. Through the interactive UI, the user can navigate for more detail or modify the presentation format (e.g. view concepts in a hierarchy). Graphical browsing is currently not supported for CML PSM knowledge.

Translation to Ontolingua

CML can be translated to Ontolingua. This is a translation from an informal notation (CML) to a formal notation (Ontolingua) and subsequently some of the Ontolingua needs to be edited to arrive at ``real'' Ontolingua. In particular, the text slots in CML end up as text slots in Ontolingua as well.

Translation to C++

CML can be partially translated to C++ header files. The current implementation translates CML concepts and binary-relations to C++ classes. The application developer has to implement the methods associated with the classes. Translation to C++ is available from the ``theory browser'' and the ``workarea''.

Editing

CML can be edited both as plain text and interactively, see ``workarea''.

EXPRESS support

More information on EXPRESS can be found at ``ftp.cme.nist.gov''.

Import

The public-domain TNO EXPRESS parser has been extended with an option to translate EXPRESS to Prolog clauses. The toolkit can import EXPRESS by translating these Prolog clauses to the internal representation.

Export and pretty-printing

EXPRESS can be exported and pretty-printed.

Browse (graphically)

EXPRESS can be graphically browsed as EXPRESS-G.

Instances

The toolkit also supports loading a STEP Physical File (instances of EXPRESS data models) and linking these instances to the data model.

Ontolingua support

More information on Ontolingua can be found at `` Stanford sharable ontology library''.

Import

Ontolingua is imported into the toolkit by a module that translates the Ontolingua to ECO.

Export and pretty-printing

Ontolingua can be exported and pretty-printed.

Browse (graphically)

Ontolingua can be graphically browsed. The graphical notation was designed by Gertjan van Heijst.

Editing (textual)

Ontolingua can be edited within the toolkit.

Library support

VOID supports the construction, maintenance and use of a library of ontologies. Ontologies in all supported formalisms can be imported into the library. In the current implementation, the library appears to the user as a database of theories and definitions within those theories.

Import

Theories in all the supported formalisms can be imported into the library. The library does not support multiple versions of the same theory, importing therefore means that any existing theory with the same name and type will be overriden.

Export and pretty-printing

Theories and definitions can be exported from the library. This enables the user to develop applications based on the contents of the library.

Indexing

Theories can be indexed with a set number of attributes. See the library manager for details.

Querying

The contents of the library can be queried in a variety of ways. Theories and definitions can be queried by name (with completion) and theories can be queried by the indexes.

Parsers and translators

The following contains a summary of the parsers and translators the toolkit uses.

• CML parser
• EXPRESS parser
• Translators

CML parser

In the figure we can see the different formats the CML parser can generate. The CML parser is described in the document CML parser and the translation from CML to ECO is described in the document Specification of CML to ECO 2 translation.

EXPRESS parser

In the figure we see the different formalisms the Xpress/TNO parser would generate.

The Xpress parser is described in the document EXPRESS Tools. The ExpressP translator or parser is described in the document Specification of EXPRESS to ECO 2 translation.

We could not find an EXPRESS to HTML translator to make it possible to view an EXPRESS specification, there we made a pointer mechanism from the ECO 2 format of EXPRESS to the EXPRESS source code. There is a possibility to use the EXP2HTML translator , in the NIST EXPRESS Tools and consequently get an EXPRESS to HTML translator.

Translators

In the figure we can see the different directions of translations between formalisms in the KACTUS project. Some translators are already available other has been implemented within the KACTUS project. It is not trivial to translate between formalism since the ECO format is not a real interlingua, but a sort of intermediate representation adapted to each formalism EXPRESS, CML and Ontolingua.