Automatic Creation of Interface Specifications from Ontologies
Iryna Gurevycha0 Stefan Mertena1 Robert Porzela0
a2 European Media Lab GmbH
Schloss-Wolfsbrunnenweg 31c
D-69118 Heidelberg, Germany
a3 gurevych,porzel
a4 @eml.org
a5 DFKI GmbH
Erwin-Schr¨odinger-Str.57
D-67608 Kaiserslautern, Germany
merten@dfki.de
Abstract
The paper presents a system architecture for
the automatic generation of interface specifica-
tions from ontologies.1 The ensuing interfaces
(XML schema definitions) preserve a signifi-
cant amount of the knowledge originally en-
coded in the ontology. The approach is rele-
vant for the engineering of large-scale language
technology systems. It has been successfully
deployed in a complex multi-modal dialogue
system SMARTKOM.
1 Introduction
Interface specifications are an important part of the com-
putational infrastructure in engineering language technol-
ogy (LT) systems. This is a challenging task, especially
for large-scale and multi-domain systems with numerous
processing modules. To a great extent, the successful op-
eration of such a system depends on the high-quality do-
main representations exchanged between individual mod-
ules.
Ontologies have traditionally been used to represent
domain knowledge and are employed for various lin-
guistic tasks, e. g., semantic interpretation, anaphora, or
metonymy resolution. We propose an additional way of
employing ontologies, i. e., to use the knowledge mod-
eled therein as the basis for defining the semantics and the
content of the information exchanged between the mod-
ules of LT systems.
In language technology systems, modules typically
exchange messages, e. g., a parser of a dialogue sys-
tem might get word lattices as input and produce cor-
responding semantic representations for later processing
modules, such as a discourse manager. The increasing
employment of XML-based interfaces for agent-based
or other multi-blackboard communication systems sets
a de facto standard for syntax and expressive capabili-
ties of the information that is exchanged amongst mod-
ules. The content and structure of the information to be
1The resulting software is licensed under the
GPL and is a free software project. The package
and respective documentation can be obtained from
http://savannah.nongnu.org/projects/oil2xsd.
represented is typically defined in corresponding XML
schemata (XMLS) or Document Type Definitions (DTD).
Employing the approach introduced below, XMLS and
DTDs are created such that they:
a6 stay logically consistent, as the logical consistency
of ontologies can be checked with the help of avail-
able tools,
a6 are easy to manage,
a6 enable a straight-forward mapping back to the re-
spective knowledge representation for inference,
a6 allow the handling of language processing tasks im-
mediately on the basis of XMLS.
This paper is organized as follows. In Section 2 we will
give an overview of the approaches to knowledge stor-
age as employed in LT systems. Section 3 outlines the
task that we address, highlights the problems which arise
when mapping knowledge structures from ontologies to
XMLS and how these have been solved in our implemen-
tation. Section 4 discusses how the approach has been
deployed in a real-life dialogue system as well as some
of the additional advantages resulting from its applica-
tion. Related approaches are, then, discussed in Section
5. Concluding remarks are found in Section 6.
2 Approaches to Knowledge Storage
Efforts originating in various W3C and Semantic Web
projects brought about several knowledge modeling
standards: Resource Description Framework (RDF),
DARPA Agent Mark-up Language (DAML), Ontology
Interchange Language (OIL), Web Ontology Language
(OWL).2 As for intra-agent or intra-module communica-
tion languages, either XMLS or DTDs have become stan-
dards for interface specifications, due to the fact that in-
stance documents can be automatically validated during
run-time and software has been developed for parsing and
marshaling information represented in these formats.3
2See www.w3c.org/RDF, www.ontoknowledge.org/oil,
www.daml.org, and www.w3.org/2001/sw/WebOnt for the
individual specifications.
3See Xerces (xml.apache.org) for parsing and Castor (cas-
tor.exolabs.org) for marshaling XML documents.
Current systems often feature both XMLS- or DTD-
based communication languages as well as DAML- or
RDF-based knowledge stores. However, those are often
structurally and terminologically heterogeneous. Map-
pings from the message content to the ontology are of-
ten difficult and costly. Attempts to hand-craft XMLS
or DTDs for defining communication between various
processing modules show that several problems grow
roughly linear to the complexity of the domains to be de-
fined by means of the individual representations. These
problems are:
a6 inconsistencies in modeling choices, e.g. elements
versus attributes,
a6 inconsistencies in the hierarchy, e.g. flat-ness versus
depth of individual branches,
a6 readability and understandability of the schemata.
In a system involving multiple domains it becomes
pretty much impossible to manually define suitable XML
schemata for the modules that exchange information
about the multitude of possible utterances. The ensuing
inadequacies of the representations constitute a substan-
tial obstacle for system development and its functionality.
Processing modules operating on such schemata can also
not apply inferencing algorithms directly on these struc-
tures, as they do not represent enough knowledge. This
has the effect that individual knowledge stores have to
be hand-crafted for specific components, causing the het-
erogeneity between the communicated and the modeled
objects to increase further. Additionally, readability de-
creases as more complex XMLS structures, such as ex-
tension hierarchies or substitution groups, are used and
potential links to semantic web ontologies are lost or be-
come costly.
3 The Task: From Knowledge to
Interfaces
Ontologies are a suitable means for knowledge represen-
tation, i.e. for the definition of an explicit and detailed
model of the system’s domains. That way, they provide a
shared domain theory, which can be used for communi-
cation. Additionally, they can be employed for deductive
reasoning and manipulations of models. The meaning of
ontology constructs relies on a translation to some logic.
This way, the inference implications of statements, e.g.
whether a class can be related to another class via a sub-
class or some other relation, can be determined from the
formal specification of the semantics of the ontology lan-
guage. However, this does not make any claims about the
syntactic appearance of the representations exchanged,
e.g. an ordering of the properties of a class.
An interface specification framework, such as XMLS
or DTD, constitutes a suitable means for defining con-
straints on the syntax and structure of XML documents.
Ideally, the definition of the content communicated be-
tween the components of a language technology system
should relate both the syntax and the semantics of the
XML documents exchanged. Those can then be seen
as instances of the ontology represented as XMLS-based
XML documents. However, this requires that the knowl-
edge, originally encoded in the ontology, is represented
in the XMLS syntax.
3.1 Ontology to XMLS transformation
The solution presented here states that the knowledge
representations to be expressed in XMLS are first mod-
eled in OIL-RDFS or DAML+OIL as an ontology proper,
using the advantages of ontology engineering systems
available, and then transformed into a communication in-
terface automatically with the help of the software devel-
oped for that purpose. Before showing how the problems
mentioned in Section 2 can be minimized, we will intro-
duce the basic formal properties of the given source and
target representations.
Ontology representation languages: Domain knowl-
edge stored in the ontology may be encoded using XML-
based semantic mark-up languages, such as OIL, or
DAML+OIL. In the work reported here, we used an on-
tology defined in the OIL-RDFS syntax, but the basic
transformation algorithms are as well applicable to OIL
or DAML+OIL .
OIL-RDFS is a representation format which allows to
express any OIL ontology in RDF syntax. This has the
advantage that the ontology is partially understandable
for non-OIL aware RDFS applications. Additionally it
allows for all the formal semantics and reasoning sup-
port available for OIL. A detailed characterization of the
formal properties of the OIL language can be found in
Fensel et al. (2001).
The semantics of OIL is based on a combination
of frame and description logic extended with concrete
datatypes. The FACT system4 can be used as a reason-
ing engine for OIL ontologies, providing some automated
reasoning capabilities, such as class consistency or sub-
sumption checking. The OIL language employs frame
semantics and provides most of the modeling primitives
commonly used in frame-based knowledge representa-
tion systems. Graphical ontology engineering front-ends
and visualization tools are available for editing, maintain-
ing, and visualizing the ontology.5
XML Schema: XML schemata provide a grammar for
prescribing the structure of XML documents, data typing
4See also www.cs.man.ac.uk/ horroks/FaCT/.
5See OilEd (oiled.man.ac.uk) and for editing and
FrodoRDFSViz (www.dfki.uni-kl.de/frodo/RDFSViz) for
visualization.
as well as inclusion and derivation mechanisms. XMLS
definitions are themselves XML documents, which have
the immediate advantage that all tools developed for
XML, e.g. validation tools, can be immediately used for
XMLS.6
3.2 Differences between ontology languages and
XMLS
In comparing ontology languages and XML schema it is
important to realize, that while both of them provide vo-
cabulary and structure to represent knowledge, the under-
lying formalisms show different formal properties since
their purpose is different.
OIL-RDFS definition is a directed acyclic graph, while
XMLS establish a tree structure. Ontology languages,
such as OIL provide much richer modeling primitives, i.e.
classes, slots. They also incorporate the notion of (multi-
ple) inheritance, which may be either explicitly stated or
implied.
XMLS have different modeling primitives, i.e. ele-
ments of certain types, which can be either simple or
complex types. However, no precise semantic interpreta-
tion is assigned to them. There is no inheritance as such,
but types can be derived by extension or restriction, i.e.
types can share some structures between them. Gener-
ally the XMLS language is much richer in terms of its
datatyping capabilities and grammar for prescribing the
structure and content of the elements.
In contrast to that, ontologies constitute high level do-
main models. Because of different formal properties
of the underlying representation formalisms, a straight-
forward mapping between them is not always possible.
In some cases it may be rather intricate, so that special
transformation algorithms are required. These algorithms
are responsible for explicating and mapping knowledge
structures from the ontology to XMLS.
3.3 Transforming OIL definitions into XMLS
definitions
In this section, we provide a description of the algorithms
employed by the transformation software. We will show
how OIL definitions can be written in XMLS. Let’s as-
sume the existence of the ontology shown in Figure 1.
Step 1 Mapping of class definitions: According to
this ontology, the class WatchPerceptualProcess is a
subclass of PerceptualProcess, and its instances have
an object to be watched, i.e. AvEntertainment. A
corresponding OIL definition looks as follows:
6The specification of the language is given in
www.w3c.org/XML/Schema.
Agent
Broadcast Performance
Animal Person AvEntertainmentCity Lights
has−agent
has−agent
has−actoris−a is−a
is−a
is−a
is−a
is−a
is−a
The General
has−watchable_object
PerceptualProcess
has−agent:Animal OR Person 
WatchPerceptualProcessAvMedium
has−genre:{Love|Science|Humor} 
has−actor: Person has−watchable_object : AvEntertainment 
Figure 1: A sample ontology
class-def WatchPerceptualProcess
subclass-of PerceptualProcess
slot-constraint
has-watchable object
has-value AvEntertainment
The translation of the class definition header is done
in a straight-forward manner using the XML schema
complexType construct to assign a name:
a0 complexType name="WatchPerceptualProcess
a1
Step 2 Resolving inheritance: The notion of inheri-
tance is important for many language processing algo-
rithms operating either on the basis of an ontology or
equivalent XMLS. It allows, for example, underspecifi-
cation in semantic representations, when a more general
class is used in place where specific derived classes can
also occur. The generalization hierarchy found in the on-
tology should be made explicit to an equivalent type ex-
tension structure in the XMLS.
The subclass-of statement would thus be translated to
XML schema. This corresponds to the type extension7
and results in a construct:
a0 complexType name="WatchPerceptualProcess
a1
a0 complexContent
a1
a0 extension base="ns:PerceptualProcess"
a2a3a1
a0 /complexContent
a1
a0 /complexType
a1
However, in more complicated cases, in particular when
the class in question has subclasses and consequently
shares some structures (slots) with its superclass, as
in the example below, a direct mapping to the type
extension in XML schema may result in a problem.
7As XML schema does not allow to express multiple inher-
itance, only unary inheritance can be handled. This is a con-
straint on the modeling side which should be taken into account.
Also ns: in our examples stands for any namespace, which can
be assigned freely.
class-def Agent
class-def Animal
subclass-of Agent
class-def Person
subclass-of Agent
The instance documents would become ambiguous, if
some non-abstract types (i.e. types that can be instanti-
ated, e.g. Agent) have derived types (e.g. Person). As
some substructures are shared by the types, in the in-
stance documents it is no longer possible to determine
whether a specific element matches the content model
of Agent, Person or possibly another type derived from
Agent by extension, e.g. Animal.
To avoid this sort of ambiguity, a specific algorithm
is proposed. The basic idea is to move the information
needed to identify the type of the element to additional ar-
tificially created complex types.8 This way, each class in
the ontology is translated to a set of three complex types.
Type abstract: Type abstract serves to preserve the
original class definition in the ontology, but is given an
attribute abstract in the XML schema, i.e. it may never
be instantiated, resulting in:
a0 complexType name="Agent abstract"
abstract="true"/a1
Type final: Type final is a direct derivation of the
Type abstract adding no new content, but it is final,
i.e. no more type may be derived from it. Type final is
used when elements are given a type. There is no more
ambiguity in the instance documents, as Type final does
not have any derived types, e.g.:
a0 complexType name="Agent final"
a1
a0 complexContent
a1
a0 extension base="ns:Agent abstract"/
a1
a0 /complexContent
a1
a0 /complexType
a1
Type: Type can be used by the elements because it
is not derived from anything. It consists of a choice
XMLS construct containing an element for each of
the possible derivations of the Type abstract including
Type abstract itself. As a result, any element tag of
the choice, which is a derivation of the given base type
can be actually used in the instance document, as follows:
8An alternative solution is to use xsi:type attributes in the
instance documents. This, however, ceases to make inheritance
structures visible through the element tags.
a0 complexType name="Agent"
a1
a0 choice
a1
a0 element name="agent"
type="ns:Agent final"/a1
a0 element name="animal"
type="ns:Animal final"
minOccurs="0"/a1
a0 element name="person"
type="ns:Person final"
minOccurs="0"/a1
a0 /choice
a1
a0 /complexType
a1
Step 3 Mapping of slot constraints: Class descrip-
tions in the ontology may typically contain one or
more slot constraints of certain kinds. For each slot
constraint associated with a class a sequence element
of the corresponding complex type in XMLS is created,
like in the example below:
class-def WatchPerceptualProcess
subclass-of PerceptualProcess
slot-constraint
has-watchable object
has-value AvEntertainment
<complexType
name="WatchPerceptualProcess abstract"
abstract="true">
<complexContent>
<extension
base="ns:PerceptualProcessabstract">
<sequence>
<element name="watchableObject"
type="ns:AvEntertainment"
minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
The slot constraint has-watchable object of Watch-
PerceptualProcess is mapped to an element watch-
ableObject. The cardinality of the slot is transformed
to the cardinality of the element accordingly. The type
of the element in a sequence is determined from the
appropriate slot filler in the ontology. There exist a
variety of possibilities to specify the domain of slots in
the ontology (see Step 4 for a detailed discussion). As
each of them requires special treatment while translating
to XMLS, we discuss this in a separate step.
Step 4 Resolving fillers of slot constraints: The do-
main of the slot in the ontology can be specified by class
expressions of different complexity, individual or a set of
those and some elementary data types. However, XMLS
require that an element representing a slot in the corre-
sponding complex type definition is always given a single
non-ambiguous type. This may be the case when a slot
is filled with a single class having no subclasses; in other
cases it is not directly expressible in XMLS and a special
mechanism is required. We support the transformation of
the following slot fillers:
A non-final class definition: A non-final class in the
ontology is a class having further subclasses in the gener-
alization hierarchy. The semantics of such a class in the
slot definition is that any instance of this class or any of its
subclasses can fill the slot. As XMLS lack the notion of
implicit semantics, the subclass hierarchy of the respec-
tive non-final class must be made explicit. The complex
type Type containing a choice running across all possi-
ble derivations is employed as an unambiguous type of
the sequence element within the corresponding complex
type definition (cf. Step 3).
<complexType name="AvEntertainment">
<choice>
<element name="avEntertainment"
type="ns:AvEntertainment final"/>
<element name="broadcast"
type="ns:Broadcast final"
minOccurs="0"/>
<element name="performance"
type="ns:Performance final"
minOccurs="0"/>
</choice>
</complexType>
Boolean class expressions with OR: In the ontology,
slots can be filled with a boolean expression of classes.
class-def PerceptualProcess
slot-constraint
has-agent has-value Animal or Person
The semantics of such an expression as slot-filler
is that any instance of the evaluated expression can
fill the slot. As XMLS does not support the use of
logical operators, placeholder complex types, e.g.
Or PerceptualProcess agent in the example below,
should be introduced at this point to XMLS. These
artificially created complex types consist of a choice of
elements corresponding to each of the operands of the
boolean class expression. The elements are given a type
of the respective class.
<complexType name="PerceptualProcessabstract"
abstract="true">
<sequence>
<element name="agent"
type="ns:Or PerceptualProcess agent"
minOccurs="0"/>
</sequence>
</complexType>
<complexType name="Or PerceptualProcess agent">
<choice>
<element name="animal"
type="ns:Animal final"/>
<element name="person"
type="ns:Person final"/>
</choice>
</complexType>
Similar algorithms exist for resolving AND and NOT
operators. The only difference for AND is that elements
of a placeholder complex type would not be combined
in a choice, but in a sequence. For NOT, the choice of
the complex type would contain elements for all classes,
except the class which is the operand in the respective
expression.
Individuals: In the following ontology definition, the
slot-constraint has-genre is filled with a set of individual
values love, humor, science.
class-def AvMedium
slot-constraint has-genre has-value
(one-of love humor science)
The slot has-genre is translated to a sequence el-
ement genre of the complex type corresponding to
the AvMedium class definition. In order to give this
element an unambiguous type, a placeholder simple
type OneOf AvMedium genre is introduced. The content
model of this type is then restricted to the set of enu-
meration values corresponding to the set of individuals
specified in the original slot definition.
<complexType name="AvMedium abstract"
abstract="true">
<sequence>
<element name="genre"
type="ns:OneOf AvMedium genre"
minOccurs="0"/>
</sequence>
</complexType>
<simpleType name="OneOf AvMedium genre">
<restriction base="ns:NMTOKEN">
<enumeration value="humor"/>
<enumeration value="love"/>
<enumeration value="science"/>
</restriction>
</simpleType>
Step 5 Mapping of individuals: The last step to be
taken in transforming the ontology to XMLS is mapping
the individuals which represent instances of specific
classes in the ontology, e.g. The General and City Lights
are modeled as instances of the AvMedium class.
instance-of The General AvMedium
instance-of City Lights AvMedium
For instances of individual classes, a simple type with
the name of the respective class is created. The content
model of this simple type is an enumeration of specific
values which correspond to the names of individuals in
the ontology.
<simpleType name="AvMedium">
<restriction base="ns:NMTOKEN">
<enumeration value="The General"/>
<enumeration value="City Lights"/>
</restriction>
</simpleType>
4 Application in a Dialogue System
Our approach to the automatic creation of interface spec-
ifications from an ontology has been successfully tested
in SMARTKOM, a complex multi-modal dialogue system
(Wahlster et al., 2001). The system comprises a large set
of input and output modalities which the most advanced
current systems feature, together with an efficient fusion
and fission pipeline. SMARTKOM supports speech input
with prosodic analysis, gesture input via infrared cam-
era, recognition of facial expressions and their emotional
states. On the output side, the system features a gesturing
and speaking life-like character together with displayed
generated text and multimedia graphical output.
The system currently comprises nearly 50 modules
running on a parallel virtual machine-based integration
software called Multiplatform (Herzog et al., 2003). The
modules exchange messages whose content is encoded
in XML. The interfaces are defined by a set of XML
schemata. The part of them containing the system’s
knowledge about application domains was obtained via
the automatic transformation of an OIL-RDFS ontol-
ogy (Gurevych et al., 2003b). Thusly, all components
of the system operate on a common knowledge store -
XML schemata resulting from the ontology transforma-
tion, e. g., the parser (Engel, 2002), the dialogue manager
(L¨ockelt et al., 2002).
In this trial, our initial hypothesis that employing onto-
logical knowledge for interface specifications will make
them more consistent, better-structured and more read-
able as compared to manually defined interfaces was fully
satisfied. Some additional advantages that were not antic-
ipated originally also resulted from this approach.
Enhancing the OIL-RDFS datatyping capabilities:
As previously stated, ontologies are a suitable means for
specifying high-level domain knowledge. However, if
knowledge represented in the ontology is to become part
of the common XML schema based representation ex-
changed between the modules, it is important to have a
mechanism for referencing structures, i. e., datatypes de-
fined elsewhere in a larger XML context.
It should be noted that the datatyping capabilities of
the OIL-RDFS ontology per se are very limited. There-
fore, enabling references to XMLS datatypes within the
ontology, or more generally, referencing any datatype de-
fined elsewhere in a larger XML context, is in practice
beneficial to the ontology.
We provide a special mechanism which allows to em-
ploy external datatypes in the ontology, e. g., NmToken
(a built-in XML schema datatype) or derived datatypes,
such as ns:TimeExpression (as parts of other ontologies,
like a time ontology). To make use of this feature, exter-
nal datatypes have to be modeled as instances in the on-
tology. Thus, they can be employed, e. g., as slot fillers.
Consequently, the ontology converted to XML schema
can be embedded in a larger XML context.
Supporting multiple applications with a single ontol-
ogy: Ontology construction is known to be labor and
cost intensive. To reduce the cost of ontology design
and maintenance, it is necessary to construct ontologies
which are re-usable, i. e., support multiple applications
and domains. This may, however, often result in the side
effect that an ontology covers more domains than are ad-
dressed by the specific system in question. Transforming
the ontology to XMLS as is, would then lead to overload-
ing the domain model and slowing down the system and
development performance.
As a solution to this problem we enabled different
(system-dependent) views on a single ontology cover-
ing multiple domains. This solution requires that certain
parts of the ontology are marked up as being relevant for
a particular system in question. The mark-up is examined
automatically and a decision is made which parts of the
ontology are irrelevant for the specific system at hand.
These parts are, then, skipped in the process of transfor-
mation to XMLS. As a result, the XML schema-based
domain model contains exactly the knowledge relevant
for a particular system and presents one of the possible
views on the underlying ontology.
Language processing tasks on XMLS: Resulting
from the transformation a maximal amount of the knowl-
edge from the ontology has been preserved and made
explicit in the produced XMLS. Various linguistic oper-
ations, e. g., anaphora, bridging and metonymy resolu-
tion or discourse processing techniques such as overlay
(Alexandersson and Becker, 2003) can, therefore, work
directly on the schemata.
5 Related Work
The relation between ontologies and schema-languages
has been addressed previously in the AI and Semantic
Web communities. Gil and Ratnakar (2002) carried out
a detailed comparison of semantic mark-up languages in
the course of looking for a language suitable for develop-
ing user-oriented tools for the Semantic Web.
Klein et al. (2000) relate ontologies to the XMLS lan-
guage definition, applicable in the context of defining the
content of on-line information sources. Their conclusion
is that both refer to different levels of abstraction and
should therefore be used at the different stages of the de-
velopment of information sources. They also provide a
translation procedure from OIL to XMLS which is sim-
ilar to ours, yet differs in the technical details. In con-
trast to our work, Klein et al. (2000) do not verify their
approach via practical implementation, i. e., while it is
stated that most of the steps could be automated, the fo-
cus of their work remains on a fairly theoretical level.
The approach proposed herein has been implemented and
successfully deployed in a language technology system.
It is available as a free software project, thus enabling its
practical re-use in other systems.
Some research is also underway to explore the reverse
direction, i.e. from XML schema to ontology content9.
The motivation for that is twofold: firstly to enable rea-
soning about XML content for DAML-enabled software
and secondly to create DAML content from XML in a
quick and automated fashion. The main objective of our
approach is, however, to bring semantics to XML doc-
uments, i.e., derive appropriate interface specifications
from the given domain model, thereby enabling high-
quality reasoning immediately on the XMLS level.
9For example, http://www.davincinetbook.com:8080/daml/
xmltodaml/xmltodaml.html
6 Discussion
The system architecture presented herein eliminates the
necessity of crafting interface specifications manually.
Instead, the domain knowledge of LT systems is first
modeled as an ontology and then transformed into XMLS
automatically. The resulting schemata capture the hierar-
chical structure and a significant part of the semantics of
the ontology. This provides a standard mechanism for the
creation of XMLS-based interface specifications storing
knowledge about the system’s domains.
The ontology employed in our system has been de-
signed as a general purpose component for knowledge-
based language processing. It can be accessed automat-
ically, 10 if additional reasoning operations are desired.
E.g., it has been successfully applied to the task of scor-
ing sets of concepts in terms of their semantic coher-
ence (Gurevych et al., 2003a). Important to note is that
this single ontology can be re-used not only for differ-
ent tasks, but also for different systems as multiple views
and creation of application-specific interface specifica-
tions are possible.
A further advantage of our approach is that it com-
bines the power of ontological knowledge representation
with the strengths of XMLS as an interface specification
framework in a single and consistent knowledge store.
Our experience suggests that this is not feasible for large-
scale LT systems, if XML schema were defined from
scratch or hand-crafted. Successfully deployed in a com-
plex dialogue system, which is just a particular instance
of its application, the system architecture constitutes a
more general and practical approach to the automatic in-
terface generation in language technology systems.
Acknowledgments
This work has been partially funded by the German Fed-
eral Ministry of Research and Technology (BMBF) as
part of the SmartKom project under Grant 01 IL 905C/0
and by the Klaus Tschira Foundation. We would like to
thank Michael Strube for his helpful comments on the
previous versions of this paper.

References
Jan Alexandersson and Tilman Becker. 2003. The For-
mal Foundations Underlying Overlay. In Proceedings
of the Fifth International Workshop on Computational
Semantics (IWCS-5), Tilburg, The Netherlands.
Ralf Engel. 2002. SPIN: Language understanding for
spoken dialogue systems using a production system ap-
proach. In Proceedings of ICSLP 2002.
10See APIs such as JENA (www.hpl.hp.com/semweb/jena-
top.html) and corresponding query languages, such as RDQL.
Dieter Fensel, Frank van Harmelen, Ian Horrocks, Deb-
orah McGuinness, and Peter Patel-Schneider. 2001.
OIL: An ontology infrastructure for the semantic web.
IEEE Intelligent Systems, 16(2).
Yolanda Gil and Varun Ratnakar. 2002. A comparison of
(semantic) markup languages. In Proc.of the 15th Int.
FLAIRS Conference, Florida.
Iryna Gurevych, Rainer Malaka, Robert Porzel, and
Hans-Peter Zorn. 2003a. Semantic coherence scoring
using an ontology. In Proceedings of the HLT-NAACL
Conference, Edmonton, Canada.
Iryna Gurevych, Robert Porzel, Elena Slinko, Norbert
Pfleger, Jan Alexandersson, and Stefan Merten. 2003b.
Less is more: Using a single knowledge represen-
tation in dialogue systems. In Proceedings of the
HLT-NAACL’03 Workshop on Text Meaning, Edmon-
ton, Canada.
G. Herzog, H. Kirchmann, S. Merten, A. Ndiaye, and
P. Poller. 2003. Multiplatform testbed: An integration
platform for multimodal dialog systems. In Proceed-
ings of the HLT-NAACL’03 Workshop on the Software
Engineering and Architecture of Language Technology
Systems (SEALTS), Edmonton, Canada.
Michel Klein, Dieter Fensel, Frank van Harmelen, and
Ian Horrocks. 2000. The relation between ontologies
and schema-languages: translating OIL-specifications
in XML-schema. In Proc. of the Workshop on Ap-
plication of Ontologies and Problem Solving Methods,
Berlin, Germany.
Markus L¨ockelt, Tilman Becker, Norbert Pfleger, and Jan
Alexandersson. 2002. Making sense of partial. In
Proceedings of the sixth workshop on the semantics
and pragmatics of dialogue (EDILOG 2002), pages
101–107, Edinburgh, UK.
Wolfgang Wahlster, Norbert Reithinger, and Anselm
Blocher. 2001. SmartKom: Multimodal communi-
cation with a life-like character. In Proceedings of the
7th European Conference on Speech Communication
and Technology, pages 1547–1550.
