<?xml version="1.0" encoding="UTF-8"?>
<TEI xml:space="preserve" xmlns="http://www.tei-c.org/ns/1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.tei-c.org/ns/1.0 https://raw.githubusercontent.com/kermitt2/grobid/master/grobid-home/schemas/xsd/Grobid.xsd"
 xmlns:xlink="http://www.w3.org/1999/xlink">
	<teiHeader xml:lang="en">
		<fileDesc>
			<titleStmt>
				<title level="a" type="main">Multilingual Agents: Ontologies, Languages and Abstractions</title>
			</titleStmt>
			<publicationStmt>
				<publisher/>
				<availability status="unknown"><licence/></availability>
			</publicationStmt>
			<sourceDesc>
				<biblStruct>
					<analytic>
						<author>
							<persName><forename type="first">Steven</forename><surname>Willmott</surname></persName>
							<affiliation key="aff0">
								<orgName type="laboratory">Laboratoire d&apos;Intelligence Artificielle</orgName>
								<orgName type="institution">Ecole Polytechnique Federal de Lausanne</orgName>
								<address>
									<settlement>Lausanne</settlement>
									<country key="CH">Switzerland</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Ion</forename><surname>Constantinescu</surname></persName>
							<affiliation key="aff1">
								<orgName type="laboratory">Laboratoire d&apos;Intelligence Artificielle</orgName>
								<orgName type="institution">Ecole Polytechnique Federal de Lausanne</orgName>
								<address>
									<settlement>Lausanne</settlement>
									<country key="CH">Switzerland</country>
								</address>
							</affiliation>
						</author>
						<author>
							<persName><forename type="first">Monique</forename><surname>Calisti</surname></persName>
							<affiliation key="aff2">
								<orgName type="laboratory">Laboratoire d&apos;Intelligence Artificielle</orgName>
								<orgName type="institution">Ecole Polytechnique Federal de Lausanne</orgName>
								<address>
									<settlement>Lausanne</settlement>
									<country key="CH">Switzerland</country>
								</address>
							</affiliation>
						</author>
						<title level="a" type="main">Multilingual Agents: Ontologies, Languages and Abstractions</title>
					</analytic>
					<monogr>
						<imprint>
							<date/>
						</imprint>
					</monogr>
					<idno type="MD5">F6BAFE35CF0B0C882702EDE64BABBCB9</idno>
				</biblStruct>
			</sourceDesc>
		</fileDesc>
		<encodingDesc>
			<appInfo>
				<application version="0.7.2" ident="GROBID" when="2023-03-24T01:41+0000">
					<desc>GROBID - A machine learning software for extracting information from scholarly documents</desc>
					<ref target="https://github.com/kermitt2/grobid"/>
				</application>
			</appInfo>
		</encodingDesc>
		<profileDesc>
			<textClass>
				<keywords>
					<term>Ontologies</term>
					<term>Agent Languages</term>
					<term>Content Expressions</term>
					<term>Representations</term>
					<term>Abstraction</term>
					<term>Agent toolkits</term>
				</keywords>
			</textClass>
			<abstract>
<div xmlns="http://www.tei-c.org/ns/1.0"><p>Agent Environments are becoming increasingly open, interconnected and heterogeneous. This suggests that future agents will need to be able to deal with multiple agent c o mmunication languages, multiple ways of expressing content and multiple ontology representations.</p><p>One way to deal with this heterogeneity i s b y identifying an agent's internal knowledge representation with an abstract ontology representation (AOR). This AOR then can be used to capture abstract models of communication related knowledge (domain models, agent communication languages, content languages and models of how these interact) and make it possible for the agent to manipulate all elements of messages in a uniform way -as instances of its ontological knowledge.</p><p>The paper outlines the approach, highlights interesting issues and describes a prototype implementation.</p></div>
			</abstract>
		</profileDesc>
	</teiHeader>
	<text xml:lang="en">
		<body>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1.">INTRODUCTION</head><p>Recent years have seen signi cant e ort invested in the study of communication mechanisms for agents. Particular attention has been paid to Agent Communication Languages (such as FIPA-ACL and KQML), Content Languages (such as KIF and FIPA-SL) and Ontology representations (DAML, OIL and others). These frameworks can be used to describe both the structure and meaning of the messages agents might exchange. For an agent to make e ective use of these frameworks it must be able to construct and manipulate messages combining aspects from all three areas (ontology, content language, agent communication language). Often constraints (structural and semantic) imposed by the frameworks being used must be respected to ensure that the message has meaning.</p><p>Whilst this task is di cult enough if Agent C o m m unication Language (ACL), Content Language (CL) and Ontology Representation (OR) are xed in advance, agents in heterogeneous environments are increasingly likely to be faced with: Author for correspondence. Email: Steven.Willmott@ep .ch Multiple ACLs, each w i t h m ultiple possible encodings. Multiple CLs, each w i t h m ultiple possible encodings. Multiple ORs, each w i t h m ultiple possible encodings. <ref type="bibr" target="#b1">1</ref> How w i l l agents deal with this heterogeneity? How can agent toolkits support developers in exploiting the di erent language frameworks? How c a n w e ensure that code is reusable across many agent languages? What is the best way to bridge between the ACL, CL and OR levels? In answer to some of these questions, the central thesis of this paper is that:</p><p>1. An agent's internal knowledge representation can be seen as an abstract ontology representation (AOR). 2. This AOR can be used to capture abstract models of communication related knowledge (domain models, agent communication languages, content languages and models of how these interact). 3. This makes it possible for the agent to manipulate elements from all levels of messages (ACL, CL and domain) in a uniform way -as instances of its ontological knowledge.</p><p>The main idea is therefore to give agents explicit representations of languages and domains to manipulate at runtime. The approach is described in three parts: abstract ontology representation (Section 3.1), the de nition of languages structures as ontologies (Section 3.2) and how these c a n b e u s e d t o d e v elop communicating agents (Section 3.3). Section 4 then details a prototype implementation of the architecture supporting all of the main ideas presented and, in particular:</p><p>The abstract ontology representation described in Section 3.1. An interface for a restricted version of DAML ontology representation as a rei cation of the AOR. <ref type="bibr" target="#b1">1</ref> Here an Ontology Representation is taken to be de ned by the information which can be represented (entities, relations and constraints allowed) and its encoding is the physical representation. An Object Oriented OR may h a ve t wo representations for example: one in UML and another in XMI/XML. Conceptual models of the agent languages FIPA-SL, FIPA-KIF, First order logic (content languages) and FIPA-ACL (agent c o m m unication language) expressed as DAML ontologies. Codecs for the rei cation of instances of messages in three of the languages listed above to their respective syntaxes (FIPA-SL S-Expression syntax, FIPA-KIF Standard syntax and FIPA-ACL S-Expression syntax). This work described here is in many w ays a logical progression of previous work by others in the following areas: 1) work on modelling agent languages as ontologies such a s 1], 2) implementations of Agent toolkits such as Jade 9], FIPA-OS 7] and Jat-Lite 10] which p r o vide ACL, Content Language or Ontology access for speci c languages and 3) Ontology frameworks such a s D AML, OIL, DAML+OIL and UML approaches which form the basis of the example AOR given in Section 3.1.</p><p>It should be noted that the objective of this paper is to provide a global view of the feasibility a n d p o t e n tial utility of this approach rather than provide de nitive results in any one area.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.">DEFINITIONS</head><p>Before delving into the main body of the paper this section de nes important terms. The following example of an agent message using FIPA-ACL (S-expression syntax 4]), FIPA-SL 6] and an ontology about cars illustrates one way of seeing the relationship between di erent l e v els of agent communication:</p><p>(inform :sender (agent-identifier :name i) :receiver (agent-identifier :name j) :ontology car :language FIPA-SL :content "((= (any ?x (is-car ?x)) (car :colour lightgrey :registration VD 3651 :make VW :type Golf ) )" )</p><p>Elements in the world are de ned in the domain ontology (the predicate \is-car" and the \car" object would be de ned in the ontology \car"). A content language expression (the argument of the \:content" parameter in the example) is then used to represent and bind instances of these entities together into a statement a b o u t t h e w orld. Finally a speech act de ned in an agent communication language expressing an agent's opinion about this state of a airs is wrapped around the content expression. A similar structure exists for messages using, for example, KQML with KIF as a content language. These three levels are also linked by constraints such a s :</p><p>In FIPA-ACL, the ACL expresses which c o n tent l a nguage, encoding and ontologies are to be used in the content e l d .</p><p>Often the speech act used at the ACL level constrains the type of content a l l o wed -a FIPA \request" should be for an action and not a proposition for example. Content Languages usually interface with ontologies via certain constructs able to express entities de ned in an ontology (the car construct in the message above is represented by an SL functional term for example).</p><p>Ontologies often express constraints on composition of concepts in the ontology, e . g . that the value of a car's colour attribute must be a \colour" of some sort. Some of these constraints are expressed in language grammars, others in ontology de nitions and others as free text descriptions.</p><p>This paper also makes use of the following terms:</p><p>Agent Language: a language which is either an Agent Communication Language or a Content Language.</p><p>Concept (or Class): A notion de ning a named class of entities.</p><p>Conceptual Model: a model (or meta model) containing de nitions of a number of concepts and relationships between these concepts.</p><p>Public: stable de nition (of a language, encoding or other) or structure which i s a vailable to all agents in a g i v en community and something which can be relied upon to enable interoperability.</p><p>Internal: something which is not necessarily public. Instance Knowledge: statements about particular instances of concepts (classes). (E.g. \Harry the cat is blue".)</p><p>Ontological Knowledge (or Meta Knowledge):</p><p>statements about classes and relationships -instances of conceptual models. Meta knowledge w.r.t. instance knowledge (E.g. \Cats are animals", \Blue is a colour".)</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.">ABSTRACTIONS AND ARCHITECTURE</head><p>The presentation of the approach is divided into three parts: abstract ontology representations (Section 3.1), modelling languages as ontologies (Section 3.2) and usage in agent systems (Section 3.3).</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.1">Abstract Ontology Representations</head><p>As shown in Figure <ref type="figure" target="#fig_0">1</ref>, most agent architectures store and manipulate knowledge in several areas: conceptual models, knowledge bases and messages involved in communication with other agents. The underlying model the agent uses to represent knowledge of conceptual models of the world is called its \knowledge representation".</p><p>Since we are primarily concerned with communicating agents, it is important that this knowledge representation is able to represent o n tological knowledge and in particular ontologies de ned in one or more public ORs. Given that there are already a number of di erent public OR frameworks (DAML, OIL, UML based approaches) and that there may be more in the future, choices on what an agent's internal knowledge representation is able to capture is of great importance. Choices here impact both the e ectiveness of the agent a n d  the future re-usability of its code. The problem has two levels as illustrated in Figure <ref type="figure" target="#fig_2">2:</ref> 1. Encoding: abstracting from multiple encodings of one OR to extract a conceptual model for that OR.  The product of the second step is then a potential candidate for use as the agent's internal knowledge representation. <ref type="bibr" target="#b2">2</ref> In the context of this paper it is referred to as an Abstract Ontology Representation (AOR). In general there may be several useful abstractions and more than simply two abstraction steps. We focus on these two major transitions (encoding -conceptual model, conceptual modelsuni ed conceptual model) to simply presentation however.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.1.1">Abstraction from Encodings</head><p>There is clear value in separating internal representations of knowledge from any one particular public encoding since supporting new encodings can then normally be supported <ref type="bibr" target="#b2">2</ref> Note that an agent may well use several knowledge representations internally, or that the AOR described here is simply mapped to an internal KR when necessary. One KR assumed here for clarity. by simply adding new codecs. <ref type="bibr" target="#b3">3</ref> This type of abstraction is generally relatively straightforward since most encodings of a single OR will attempt to express the same elements of the ORs underlying conceptual model.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.1.2">Abstraction from Conceptual Models</head><p>Whilst dealing with multiple encodings is normally relatively simple, dealing with multiple conceptual models of ORs is much more problematic. It is highly likely that some types of knowledge (e.g. certain types of relations or constraints) are allowed by some frameworks and not by others. Java class hierarchies, for example, forbid multiple inheritance but this is allowed by D AML and OIL. There are two straightforward approaches to generating abstractions of a set of target ORs (the ORs a designer wishes to consider):</p><p>Feature intersection: Supporting representations of only the features which fall into the intersection of features of all target ORs. This approach ensures that all of an agent's ontological knowledge could be represented in any of the target ORs but means that it may n o t be able to represent/reason with all the information in ontologies it shares with others.</p><p>Feature union: Supporting representations of all features of all the target ORs. This extreme ensures that the agent is able to represent all aspects of the knowledge expressed in each of the target ORs. The negative consequence is that there may be subsets of the agent's knowledge which cannot be expressed in any single OR (particularly if the agent is able to derive new ontology information).</p><p>There are clearly complex tradeo s involved here and the choices made are directly linked to an agent's reasoning capabilities and potential functionality. In reality, m o s t a g e n t systems will likely fall somewhere between these extremes and pick and choose OR features to represent.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.1.3">Example Abstract Ontology</head><p>The above are rather general statements, this section denes an abstract ontology representation which is used throughout the rest of the paper. The intention is not to argue that the model chosen is in anyway \the best" for the combination of target ORs but to draw out common aspects which appeared to be necessary for a basic systems. Target ORs are: DAML, OIL, UML, Frames (such as those currently used in FIPA speci cations), simple language grammars expressed in BNF/EBNF. Although a detailed study of the similarities between these frameworks is beyond the scope of this paper, a useful intersection appears to include the elements below. The following is the example AOR which will be used from now on:</p><p>1. Class: corresponding to a concept describing a named class of entities.</p><p>2. subClassOf relations: indicating that one class is a more speci c version of another (can also be read as \can substitute", as in \VW" can substitute \car"). <ref type="bibr" target="#b3">3</ref> Codec is used to refer to software modules which translate a single public representation to and from an internal data structure.</p><p>3. sameConceptAs relations: indicating that two classes are identical, includes implict equivalences between properties of the class. The terminology used here is taken from the DAML+OIL speci cation 2] but equivalent formulations could be made using (for example) frames and slots. <ref type="bibr" target="#b4">4</ref> The resulting structure is a directed graph corresponding to a class diagram but which a l l o ws multiple inheritance and equivalence. Figure <ref type="figure" target="#fig_4">3</ref> shows several linked ontology de nitions using the model de ned. The boxes in the gure each represent a namespace de ned by a single ontology de nition. In addition to the subClassOf and sameClassAs relations each c l a s s may a l s o h a ve properties assigned. There is clearly a lot of richness from the target ORs which is lost is this model but it should be remembered that the main purpose of this representation is to illustrate the approach rather than to propose a speci c abstract ontology representation.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.2">Abstract Agent Languages</head><p>The AOR given in the previous section gives the agent a xed model for its ontology knowledge. The next step is to allow it to do the same with instance knowledge, speci cally with instance knowledge expressed in varied agent languages (we are less concerned with knowledge bases). For any g i v en language, this problem is again at two l e v els: encoding and conceptual model.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.2.1">Abstraction from Encodings</head><p>In principle this can be solved as simply as for ontologiesby presuming a common representation of message elements <ref type="bibr" target="#b4">4</ref> The terms \class" and \concept" are used interchangeably throughout the paper. which are extracted from diverse encodings by encoding speci c codecs. The question of how the conceptual model of a language is expressed arises however. This question is more obvious for languages than for ontology representations since: Language grammars can be relatively complex and capture a good deal of information about the meaning of expressions in the language Agents will often need to manipulate instances of messages and require access to the conceptual model of the language to ensure correctness. The interaction between agent languages and between agent languages and entities de ned in domain ontologies are particularly important. Language syntax de nitions come in a variety of forms (XML Schemas, DTD, EBNF grammars etc.) but these tend to be highly dependent upon the individual syntax involved. As Crane eld et. al. point out in 1] however, ontologies can in fact be seen as abstract grammars for languages. An OR can be used to construct conceptual models of languages. A logical usage of this is to give the agent access to these language models at runtime and allow it to manipulate them. This enables the agent to treat knowledge about languages it knows at the same level as domain knowledge. The objective is to model languages in a formalism compatible with the AOR de ned in the previous section. For a language based on an EBNF grammar a rst pass at generating the model could be done as follows:</p><p>Disjunctions become Classes: E a c h disjunction on the right hand side (RHS) of a production rule in the grammar can be used to generate a new class. The class name can be derived either from the rst constant symbol on the RHS of the expansion or (if there is no such constant), from the name of the non-terminal on the LHS of the production.</p><p>Elements become Properties: The elements in the expansion of a single RHS disjunction to the new class each generate a new property, s . t . the property's domain = class generated by the disjunction, range = type of the element, cardinality is determined w.r.t. cardinality expressed in EBNF (+, * etc.).</p><p>Generating the Class Hierarchy: The concepts so generated can be linked by subClassOf relationships which express which grammatical elements can be substituted for others (e.g. in FIPA-SL, a term may b e replaced by a constant, giving rise to a relation de ning constant as a sub class of term.) Similar schemes could be de ned for XML Schema and XML DTDs. This method is only a sketch and needs to be applied with interpretation by the designer to deal with ambiguities it might generate. Furthermore, grammars are often optimised or compacted to reduce overhead. It may be necessary to restructure the grammar to generate a clear conceptual model.</p><p>It should be clear what is being done here -the conceptual model represents only the syntactic/lexical constraints between the concepts in the language. The information so generated does include a important part of the language structure (such as, for example, the fact that an \+" operator may only take \ n umbers" as arguments) but it does not capture more than an EBNF or Schema grammar -i.e. it does not attempt to capture the semantics. The concepts extracted for a language such as FIPA-SL include classes such a s : Class: "BinaryTermOp" SubClassOf: AtomicFormula Property: argument range: Term, Cardinality: 2.</p><p>Class: "=" SubClassOf: BinaryTermOp Class: "Term"</p><p>Where there are a number of sub classes of \Term". Concepts such as BinaryTermOp and Term are never normally instantiated in messages but are useful to structure the model of the language. In the case of Term for example it is clearly useful since it is used in the de nition of the equals operator.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.2.2">Abstraction from Conceptual Models</head><p>A further reason for considering how conceptual models of languages are expressed (and made available to the agent) is that the approach can be re-used for modelling abstract languages and how they relate to each other. An example of a conceptual di erence between two languages is the belief modal operator \B" which i s a vailable in FIPA-SL but not de ned in KIF. This means that:</p><p>\(and X Y)" is de ned in both languages. \(B fred (and X Y))" is only de ned in FIPA-SL. The reason \de ned" is used and not \expressed" is that the second statement can be expressed in KIF. KIF simply attaches no special meaning to the belief operator.</p><p>FIPA-SL and KIF are in fact a good example for the potential use of abstraction since they are both extensions of First Oder Logic (FOL -see 8] for example). Due to this common heritage, FOL concepts such a s term, variable, constant, predicate appear in both FIPA-SL and KIF and account for a signi cant subset of both languages. As noted above, in many cases speci c constructions such as \member" etc. in FIPA-SL and KIF are captured in a more general way b y F OL functions. Figure <ref type="figure" target="#fig_3">4</ref> sketches how languages might be de ned as three separate but linked ontologies. Although FOL cannot be said to abstract all of KIF and FIPA-SL it is clearly more abstract. Agent code manipulating messages using only FOL concepts would be more language independent than code using using concepts which appear only in SL or KIF respectively (and not in FOL). Messages using concepts only from FOL could be represented in both SL and KIF and hence any of their encodings (potentially also in potentially other FOL derivatives such as Prolog). De nitions of languages as hierarchies of ontologies could also be applied to non-logical languages and at the ACL level -there are performatives in KQML and ACL which are roughly equivalent (such a s \tell" and \inform") and others which are only found in one of the languages (such as \stream").</p><p>Relationships between concepts in di erent languages become easy to model once a common meta model is used to express conceptual models. In particular the sameClas-sAs relation can be used to match equivalent concepts in di erent languages. This is especially important for declaring mappings between concepts such as objects, actions and functions which m a y be declared in a domain ontology and the concepts in any given language which may represent them.</p><p>The most abstract (general) language allowed by the AOR given in Section 3.1 appears to be:</p><formula xml:id="formula_0">Class ::= ( ClassName Class* )</formula><p>This provides a lot of leeway for di erent l e v els of abstraction of languages. It should be remembered, however, that languages tend not to be very useful unless speci c semantics are attached to the concepts involved and the range of things which can be expressed is well delimited. FOL is also an especially good example because it covers a well de ned range of expressions with known computational properties. It seems likely that the languages agents may know w i l l n o t form a neat hierarchy of abstractions but a patchwork of communications concepts. This is especially true if, as suggested in 1], models of language are exploited to construct ad-hoc domain speci c content languages linking conceptual models of languages with domain models. Agents could then potentially construct application speci c languages at runtime (to negotiate a particular contract for example).</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.3">Building Multilingual Agents</head><p>Up until now there has been little discussion on how these developments impact the building of agents. In principle it is possible to now limit an API for manipulating messages to two areas: Ontological/Meta Knowledge: accessing and manipulating stored ontology information stored in the AOR representation.</p><p>Instance Knowledge: accessing and manipulating instances of concepts de ned in the ontology knowledge.</p><p>Again, the important point is that both areas (ontology and instance) represent A CLs, CLs and domains -removing the need for Developer interfaces for each new language, OR or domain the agent wishes to deal with. Developer code is isolated from communication details such a s s y n tax and perhaps language if abstract languages are de ned and used. A simpli ed view of the architecture is shown in Figure <ref type="figure" target="#fig_6">5</ref>. . These in turn are abstractions and independent of any particular language or encoding.</p><p>As the gure shows, there would usually be interaction between the instances of messages / concepts and conceptual models. The most obvious uses of the models applied to instances are:</p><p>Validation: Checking that a particular combination of instances of concepts respects all the constraints imposedby the applicable models. This is the most basic usage of the conceptual models and very important for languages modelled in particular since it allows agents to recognise whether a particular message (incoming or outgoing) respects the constraints of a particular language or not.</p><p>Translation: Equivalences expressed in conceptual models can be used to map instances from one model (ontology) to another, in terms of language for example -mapping from SL to FOL could render a incoming message suitable for an FOL theorem prover the agent has built in.</p><p>Generation: When constructing messages it can be useful to be able to generate the concepts which could be inserted at a particular point in a message.</p><p>Learning: If a message instance arrives which references the concept \orange" in ontology \fruit" (unknown to the agent) the agent m a y b e a b l e t o r e a d i n the referenced ontology and nd a link between \orange" and the \food" concept in some more general ontology it already knows. This allows it to infer that the construction \(eat sally orange)" makes some sort of sense even if it has only a super cial understanding of \orange". There is also no reason why additional information about domain ontologies or languages could not also be encoded in message instances. This information could then be assimilated into existing conceptual models, mixing the sources of the two t ypes of knowledge. Further processing of instances could include variable scope management, uni cation, simple evaluations (e.g. executing associated functions in arithmetic etc.). Add on features for the conceptual models could include summarisation of knowledge, forgetting, macros to extract well known schemas etc.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4.">IMPLEMENTATION</head><p>This section describes ATOMIK <ref type="bibr" target="#b5">5</ref> which is a simple prototype implementation of the architecture presented in Section 3. ATOMIK is intended to: Provide a proof of concept for the ideas presented in this paper.</p><p>Act as an additional illustration of the approach (the source code is available -see Section 4.3).</p><p>(if it proves useful) be evolved into a library which could be plugged into existing agent toolkits.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4.1">Overview</head><p>ATOMIK has a modular architecture and implements the following:</p><p>A kernel providing: an implementation of the AOR described in Section 3.1 as a compact directed graph (ontological knowledge) as well as an API for creating instances of concepts and composing them (instance knowledge). A v alidator module which i s a b l e t o t h e c heck all the relationships de ned in known ontologies are respected by a particular combination of concept instances.</p><p>A codec for a subset of the DAML+OIL Ontology Representation in RDF which corresponds to the AOR (so ontologies can be loaded and saved from DAML les) Conceptual models (coded as DAML ontologies) and codec modules for the following languages: A simple agent able to perform tests of the above f u n ctionalities.</p><p>The implementation is in Java<ref type="foot" target="#foot_1">6</ref> (version 1.2) and uses the SIRPAC R D F p a c kage <ref type="bibr" target="#b7">7</ref> to handle parsing for DAML RDF. All other codecs were implemented using JavaCC<ref type="foot" target="#foot_3">8</ref> .</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4.2">Examples of Operation</head><p>The following examples illustrate the current status of ATOMIK's capabilities based on the languages/representations currently available (FIPA-SL, KIF, ACL, DAML):</p><p>Validation of messages involving concepts from several ontologies. Given a de nition for a car ontology specifying that the colour property of a car must contain a colour concept found in a second ontology and has de ned colours red, yellow, blue. AT O M I K i s a b l e t o tell that: { \(for-sale (car :colour black))" must be bogus but that:</p><p>{ \(for-sale (car :colour blue))" is potentially a legitimate statement.</p><p>Detecting messages which are invalid according to a particular language grammar. The following are detected as illegal in FIPA-SL for example: { \(forall days (make-tea :milk true :sugar false))".</p><p>Fails because \days" is not a variable. { \(or A B C)". Disjunction in FIPA-SL is a binary operator.</p><p>Checking validity of complete FIPA-ACL messages such as:</p><p>(request :sender (agent-identifier :name j) :receiver (set (agent-identifier :name i)) :ontology car :language FIPA-SL :content "((action (agent-identifier :name i) (lend-to (agent-identifier :name j) (car :colour lightgrey :registration VD 3651 :make VW :type Golf )) ))" )</p><p>Including checks on the ACL level concepts, content lanaguage expressions and ontology aspects. Reifying expressions in FOL into FIPA-KIF and FIPA-SL: the expression \((not X) =&gt; Y)" can be constructed using concepts only from FOL and mapped into both FIPA-KIF and FIPA-SL: { in FIPA-KIF this becomes: \(=&gt; (not X) Y)". { in FIPA-SL this becomes: \(implies (not X) Y)".</p><p>In fact the syntaxes of FIPA-SL and KIF are very similar for the subset of elements which correspond to FOL hence this exibility does not appear very useful. For other languages with other syntaxes however (or other syntaxes) this capability i s l i k ely to be of great importance.</p><p>In summary, the prototype is able to check correctness of constructions in the de ned languages based on their conceptual models, link language concepts to domain concepts, check constraints imposed by domain ontologies. translate between languages in a limited way and make use of abstract languages.</p><p>The most important things the prototype cannot do are related to the AOR model applied, it cannot:</p><p>Cope with variable scoping -i.e. it is not possible to check i n F I P A-SL that variables used in a message instance have been declared or not. Enforce semantic constraints between (e.g.) performatives and content. These arise because they are constraints which cross more than one node in the graph (i.e. they do not apply from a concept to one of its properties). In principle those named are not di cult to add but a more general solution would be preferable.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4.3">Resources</head><p>Since this paper can onl give an overview of the implementation work done, the following can be found on-line at http://liawww.ep .ch/ATOMIK/: Fu l l s o u r c e c o d e t o t h e A TOMIK implementation (LPGL license) DAML ontology de nitions for: FIPA-SL, FIPA-ACL, FOL, KIF and several example domain ontologies We hope these will provide a useful support to the issues discussed in this paper and might be re-used by others implementing agent systems.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5.">INTERESTING ISSUES</head><p>The work presented here raises a number of interesting issues:</p><p>1. What should the AOR include/exclude?: As noted in Section 3.1 the choice of internal representation has a profound e ect on the agent system. Although it is \internal" and not shared with the outside world choices by agent toolkit developers will have a e ect on how large numbers of agents may use of ontologies de ned. ) and what aspects of languages which could be regarded as part of the conceptual model cannot be represented (variable scoping for example). 4. How can we cope with equivalences between groups of concepts?: Currently the AOR chosen allows class equivalence, more generally however a combination of concepts in one ontology may b e e q u i v alent t o a c o m bination of concepts in another.</p><p>5. How could semantic constraints be represented in the OR?: How could constraints such a s the fact that a FIPA-ACL \inform" speech act may only contain a proposition as content be generically represented in the ontology de nition? 6. What happened to the semantics anyway?: As with current language descriptions the conceptual models only capture the basic concepts of a language and their \syntactic" relationships but say nothing about how semantics might be managed or enforced. Although beyond the immediate scope of the paper it would be interesting to see if the abstractions described would support e ective semantic checking tools. 7. How easy/valid is it to generate abstractions from CLs?:</p><p>Extracting FOL concepts as common to SL and KIF is clearly a special case. Although there may be others (such as predicate logic from FOL) it is not clear how easy it is to perform this abstraction in general. It is also not clear that there will always be neat 1-1 mappings between language concepts. 8. How valid is it to construct CLs on the y?: As discussed in Section 3.2, de ning languages as ontologies makes it easy in principle for agents to put together arbitrary combinations of language concepts at runtime. Although this may b e useful it could clearly lead to the construction of intractable languages -could this process be guided to allow agents to reason about the power of the languages they create? 9. How should ontology de nitions be l i n k e d?: Like t h e i r counterparts in DAML, subClassOf and sameClassAs relations allow linking of entities in di erent o n tologies -this is important to (for example) infer that objects from a domain ontology can be referenced in a content language statement such as \(= (car :colour red) fashionable)". It appears to be useful to identify a set of common concepts which act as bridging points between ontologies. What should these concepts be? How m a n y should there be and at what granularity? 10. How can concept de nitions be l i n k e d to functions and Actions?: two important classes of ontological entities are likely to be functions (e.g. \(+ 1 1)") and actions (e.g. \paint", \eval"). These are things which may have computation or activities to carry out associated with them. It appears to be useful therefore, to have a general mechanism for linking concept de nitions with function and action de nitions (and/or code).</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="6.">CONCLUSIONS</head><p>There is no doubt that agents will need to deal with considerably heterogeneity at all levels of communication and that they will need to e ectively compose agent communication language, content expressions and domain knowledge. This paper proposed strategies for equipping agents with exible communications interfaces which: Isolate code intensive areas such as reasoners, theorem provers and agent behaviour from languages and encodings.</p><p>Give the agent access to explicit representations of conceptual models of all levels of communication.</p><p>Allow manipulation of message instances at a single uniform level.</p><p>The paper describes the approach and a prototype implementation. Future work includes: Theoretical: more detailed investigation of the link between AI knowledge representation and ontology frameworks, requirements for representing conceptual models of languages, mechanisms for linking language and domain ontologies. Development: potential integration with existing agent toolkits, developing a stable API which could be used to interface with existing AI/Agent tools such a s t h eorem provers, planners etc. Application: testing the resulting system on a signicant project -one potential example being a multi-way translation agent able to act as a gateway between groups of agents using di erent languages and/or ontology representations.</p></div><figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_0"><head>Figure 1 :</head><label>1</label><figDesc>Figure 1: An agent's knowledge is usually divided into instance knowledge (knowledge of individual facts) and meta knowledge (knowledge about classes of entities).</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_1"><head>2 .</head><label>2</label><figDesc>Conceptual Model: abstracting from the (usually di erent) conceptual models of multiple ORs to extract a common concept model.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_2"><head>Figure 2 :</head><label>2</label><figDesc>Figure2: Abstraction from encoding is the rst step, followed by abstraction from conceptual models to nd common features. The nal abstract ontology representation matches the agent's internal knowledge representation.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_3"><head>4 .</head><label>4</label><figDesc>Properties: corresponds to attribute value pairs which express something about one or more classes. The following constraints can be applied to properties: Domain: the classes the property applies to. Range: the range of values the property m a y t a k e. Cardinality: the number of times it may o r m ust o c c u r f o r a g i v en class.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_4"><head>Figure 3 :</head><label>3</label><figDesc>Figure 3: Ontologies are represented as directed graphs.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_5"><head>Figure 4 :</head><label>4</label><figDesc>Figure 4: Hierarchical ontology de nitions for FOL, FIPA-SL and KIF.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_6"><head>FOLFigure 5 :</head><label>5</label><figDesc>Figure5: Development intensive aspects of the agent implementation such as behaviours and reasoning are built on APIs accessing conceptual models and instances of concepts (classes). These in turn are abstractions and independent of any particular language or encoding.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_7"><head>{</head><label></label><figDesc>FIPA-SL 6]. { A subset of FIPA-KIF 5], corresponding to SKIF (a limited form of KIF covering only KIF sentences). { FIPA-ACL 3], S-expression syntax 4]. { FOL ( 8] conceptual model only -no codec since it is used internally only).</figDesc></figure>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="5" xml:id="foot_0">Obligatory hastily chosen acronym: \AgenT Ontology Ma-nipulatIon Kernel".</note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="6" xml:id="foot_1"><ref type="bibr" target="#b6">6</ref> The system could perhaps have been even more easily written in Prolog, Lisp, Scheme etc. but Java w as chosen simply because most current agent toolkits are Java</note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="7" xml:id="foot_2">based.<ref type="bibr" target="#b7">7</ref> See: http://www.w3.org/RDF/Implementations</note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="8" xml:id="foot_3">/SIRPAC 8 See: http://www.metamata.com/JavaCC/</note>
		</body>
		<back>

			<div type="acknowledgement">
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="7.">ACKNOWLEDGEMENTS</head><p>Many thanks go to Fabio Bellifemine, Federico Bergenti, Giovanni Caire, Giovanni Rimassa and Tiziana Trucco for interesting discussions on the issue of agent language support in FIPA compliant agent platforms. Thanks also to the reviewers for their useful comments.</p></div>
			</div>

			<div type="references">

				<listBibl>

<biblStruct xml:id="b0">
	<monogr>
		<title/>
		<author>
			<persName><surname>References</surname></persName>
		</author>
		<imprint/>
	</monogr>
</biblStruct>

<biblStruct xml:id="b1">
	<analytic>
		<title level="a" type="main">Is it an Ontology or an Abstract Syntax? -Modelling Objects, Knowledge and Agent Messages</title>
		<author>
			<persName><forename type="first">S</forename><surname>Crane Eld</surname></persName>
		</author>
		<author>
			<persName><forename type="first">M</forename><surname>Purvis</surname></persName>
		</author>
		<author>
			<persName><forename type="first">M</forename><surname>Nowostawski</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Proceedings of the Workshop on Applications of Ontologies and Problem-Solving Methods, 14th European Conference on Arti cial Intelligence</title>
				<meeting>the Workshop on Applications of Ontologies and Problem-Solving Methods, 14th European Conference on Arti cial Intelligence</meeting>
		<imprint>
			<date type="published" when="2000">2000. 2000</date>
			<biblScope unit="volume">16</biblScope>
			<biblScope unit="page">4</biblScope>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b2">
	<monogr>
		<author>
			<persName><surname>Daml</surname></persName>
		</author>
		<title level="m">Darpa Agent Markup Language: DAML+OIL speci cation v 1.7</title>
				<imprint>
			<date type="published" when="2001">2001</date>
		</imprint>
		<respStmt>
			<orgName>DAML Project</orgName>
		</respStmt>
	</monogr>
	<note type="report_type">Technical report</note>
</biblStruct>

<biblStruct xml:id="b3">
	<analytic>
		<title level="a" type="main">FIPA A CL Message Structure Speci cation</title>
		<author>
			<persName><surname>Fipa</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Foundation for Intelligence Physical Agents</title>
		<imprint>
			<biblScope unit="volume">19</biblScope>
			<date>00037</date>
		</imprint>
	</monogr>
	<note type="report_type">Technical report</note>
</biblStruct>

<biblStruct xml:id="b4">
	<monogr>
		<author>
			<persName><surname>Fipa</surname></persName>
		</author>
		<title level="m">FIPA A CL Message Representation in String Speci cation</title>
				<imprint>
			<publisher>Foundation for Intelligence Physical Agents</publisher>
			<date type="published" when="2000">00070. 2000</date>
		</imprint>
	</monogr>
	<note type="report_type">Technical report</note>
</biblStruct>

<biblStruct xml:id="b5">
	<monogr>
		<author>
			<persName><surname>Fipa</surname></persName>
		</author>
		<title level="m">FIPA KIF Content Language Speci cation</title>
				<imprint>
			<date type="published" when="2000">00010. 2000</date>
		</imprint>
		<respStmt>
			<orgName>Foundation for Intelligence Physical Agents</orgName>
		</respStmt>
	</monogr>
	<note type="report_type">Technical report</note>
</biblStruct>

<biblStruct xml:id="b6">
	<monogr>
		<author>
			<persName><surname>Fipa</surname></persName>
		</author>
		<title level="m">FIPA S L C o n tent Language Speci cation</title>
				<imprint>
			<publisher>Foundation for Intelligence Physical Agents</publisher>
			<date type="published" when="2000">00008. 2000</date>
		</imprint>
	</monogr>
	<note type="report_type">Technical report</note>
</biblStruct>

<biblStruct xml:id="b7">
	<monogr>
		<title level="m">FIPA OS v1</title>
				<imprint>
			<publisher>FIPA-OS Open Source Team</publisher>
			<date type="published" when="2000">2000</date>
		</imprint>
	</monogr>
	<note type="report_type">Technical report</note>
	<note>FIPA-OS. 3.3</note>
</biblStruct>

<biblStruct xml:id="b8">
	<monogr>
		<title level="m" type="main">Logical Foundations of Arti cial Intelligence</title>
		<author>
			<persName><forename type="first">M</forename><surname>Genesereth</surname></persName>
		</author>
		<author>
			<persName><forename type="first">N</forename><forename type="middle">J</forename><surname>Nilsson</surname></persName>
		</author>
		<imprint>
			<date type="published" when="1988">1988</date>
			<publisher>Morgan Kaufmann</publisher>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b9">
	<monogr>
		<author>
			<persName><forename type="first">Jade</forename></persName>
		</author>
		<title level="m">Java Agent D e v elopment E n vironment (JADE) v2.0</title>
				<imprint>
			<publisher>Jade Open Source Team</publisher>
			<date type="published" when="2000">2000</date>
		</imprint>
	</monogr>
	<note type="report_type">Technical report</note>
</biblStruct>

<biblStruct xml:id="b10">
	<analytic>
		<title level="a" type="main">Agent-based engineering, the web, and intelligence</title>
		<author>
			<persName><forename type="first">C</forename><surname>Petrie</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">IEEE Expert</title>
		<imprint>
			<biblScope unit="volume">11</biblScope>
			<biblScope unit="issue">6</biblScope>
			<biblScope unit="page" from="24" to="29" />
			<date type="published" when="1996-12">Dec. 1996</date>
		</imprint>
	</monogr>
</biblStruct>

				</listBibl>
			</div>
		</back>
	</text>
</TEI>
