1 Scope
The model of agent communication in FIPA is based on the assumption that two agents, who wish to converse, share a common ontology for the domain of discourse. It ensures that the agents ascribe the same meaning to the symbols used in the message. For a given domain, designers may decide to use ontologies that are explicit, declaratively represented (and stored somewhere) or, alternatively, ontologies that are implicitly encoded with the actual software implementation of the agent themselves and thus are not formally published to an ontology service.
This FIPA specification deals with technologies enabling agents to manage explicit, declaratively represented ontologies. An ontology service for a community of agents is specified for this purpose. It is required that the service be provided by a dedicated agent, called an Ontology Agent (OA), whose role in the community is to provide some or all of the following services:
· discovery of public ontologies in order to access them,
· maintain (for example, register with the DF, upload, download, and modify) a set of public ontologies,
· translate expressions between different ontologies and/or different content languages,
· respond to query for relationships between terms or between ontologies, and,
· facilitate the identification of a shared ontology for communication between two agents.
This specification deals only with the communicative interface to such a service while internal implementation and capabilities are left to developers. It is not mandated that every OA be able to execute all those tasks (for example, translation between ontologies, and identification of a shared ontology are in general very difficult and not always possible to realize), but every OA must be able to participate into a communication about these tasks (possibly responding that it is not able to execute the translation task). The interface is specified at the agent communication level (see [FIPAacl] and [FIPA00023]) as opposed to a computational API. Therefore, the specification defines the interaction protocols, the communicative acts and, in general, the vocabulary that agents must adopt when using this service.
This specification enables developers to build:
· agents that access such a service,
· agents that provide it, and,
· agents able to negotiate at run-time a shared ontology for communication.
The application of this specification does not prevent the existence of agents that, for a given domain, use ontologies implicitly encoded with the implementation of the agents themselves. In these cases full agent communication and understanding can still be obtained, however the services provided by the OA cannot apply to implicit encoded ontologies.
It is not intention of this document to mandate that every AP must include an Ontology Agent. However, in order to promote interoperability, if one OA exists, then it must comply with this specification. And, if the services here described are required by a specific agent platform implementation, then they must be implemented in compliance with this specification.
In order to keep the applicability of the specification as unrestricted as possible, the approach used is platform independent. In particular, this specification does not mandate the storage format of ontologies but only the way agents access an ontology service. However, in order to specify the service, an explicit representation formalism has been specified. It is the FIPA-Meta-Ontology (see section 5) that allows communication of knowledge between agents. As far as possible, care has been taken to integrate existing formalisms, such as [OKBC] and [W3CRDF].
2 Ontology Service
An OA is an agent that provides access to one or more ontology servers and which provide ontology services to an agent community. As well as all the other agents, the OA registers its service with the DF and it also registers the list of maintained ontologies and their translation capabilities in order to allow agents to query the DF for the specific OA that manages a specific ontology.
Every agent can then request the services of the OA by using the communicative interface specified in section 6. In particular, they can request to define, modify or remove terms and definitions of the ontology; they can request to translate expressions between two ontologies for which there exists a mapping; they can query for definitions, or relationships between terms or between ontologies; finally, they can request to find a shared ontology for communication with another agent. Even if any agent requests one of the above services, the OA reserves the right to refuse the request.
The realization of this communication obviously needs an agreement on the language to communicate facts about ontologies. This is described in section 3.2, Ontology Naming where the subsumed knowledge model and the FIPA meta-ontology is specified. It describes the primitives, and normatively defines their names, used in the communication, like concepts, parameters, relations, etc. It must be noticed that this specification is neutral in respect to the language used to store and represent the ontology (for example, RDF, KIF, ODL, …), while it only specifies the language to communicate about ontologies.
Section 5.3, Interaction Protocol to Agree on a Shared Ontology specifies the interaction protocol that two agents can use to agree on a shared ontology for communication.
The document concludes with two informative annexes. Section 7, gives a clear definition of what is intended with the term ontology and, in particular, what is the difference between a conceptualization, an ontology, and a knowledge base. Section 8, lists an informative set of guidelines to help developers to define well-founded new ontologies.
2.1 Rationale for Explicit Ontologies
The FIPA communication model defined in [FIPA00023] is based on the assumption that communicating agents share an ontology of communication defining speech acts and protocols (see Figure 1). In order to have fruitful communication, agents must also share an ontology of their domain of application. In an open environment, agents are designed around various ontologies (either implicit or explicit). For allowing their communication, explicit ontologies are however necessary, together with a standard mechanism to access and refer to them (such as an access protocol or a naming space).
Figure 1: Ontology-Based Communication Model
Without explicit ontologies, agents need to share intrinsically the same ontology to be able to communicate and this is a strong constraint in an open environment where agents, designed by different programmers or organizations, may enter into communication.
An explicit ontology is considered to be declaratively represented as opposed to implicitly, procedurally encoded. It can be then considered as “a referring knowledge” and, as a consequence, could be outside the communicating agents; managed by a dedicated ontology agent.
As described in section 7, an ontology is not only a vocabulary but also contains explicit axioms to approximate meaning, that is, to constrain the set of intended models. Explicit axioms allow validation of specifications, unambiguous definition of vocabulary, automation of operations like classification and translation.
Several benefits can be envisioned by having explicitly represented ontologies, such as enabling querying for concepts, updating an ontology, reusing ontologies by extending or specializing existing ones, translation between different ontologies, sharing through referring to ontology names and locations, etc.
2.2 Benefits for Applications
There are many applications that benefit from having a dedicated agent that manages and controls access to a set of explicit ontologies.
In information retrieval applications, the size of some linguistic ontologies may prevent an agent from storing the ontology in its address space, so that agents need to remotely access and refer to ontologies for disambiguation of user queries, for using information about taxonomies of terms or thesauri to enhance the quality of retrieved results, etc. The definition of a standard interface to access and query an ontology service can increase and simplify the interoperability between different systems.
Semantic integration of heterogeneous information sources in an open and dynamic
environment, such as the Internet or a digital library, may also benefit from
an ontology service. There are already implementations [Bayardo96] that use one domain ontology to integrate several
information sources, managed by a dedicated agent, whilst still allowing each
source to use its private ontology. Every user can also have their own ontology
depending on their preference, their role in the domain or simply their known
language. Every used ontology is a subset of the domain ontology or there exists
a map between it and the domain ontology; the knowledge about these
relationships (subset and mapping) is usually maintained by some
ontology-dedicated agents.
Some applications use machine-learning techniques to adaptively extend an ontology based on the interaction of the user with the system. In this case, at the execution time, several user agents may compete or collaborate to request a dedicated agent to modify an ontology.
2.3 Sample Scenarios
2.3.1 Scenario 1 – Definition of Terms Querying
This scenario shows the usage of an Ontology Agent to access definition of terms when using large linguistic ontologies:
Let’s consider Agent B able to index pictures based on their captions and send them on a demand basis:
1. Agent A, which for instance is a user interface agent, is willing to get pictures of diseased citrus for its user, who is a farmer and wants to discover a diagnosis for his citrus trees. Agent A, then, requests Agent B, to send pictures of diseased citrus by referring to a given domain ontology, for example, the farmer ontology.
2. Agent B discovers that no pictures under the name citrus are available. Before sending the answer to Agent A, Agent B queries the appropriate OA (where the farmer ontology resides) to obtain sub-species of citrus (which may be also sub-species of the diseased property) within the given ontology.
3. The OA answers Agent B, informing it that oranges and lemon are sub-species of citrus.
4. Then, Agent B finds pictures of diseased lemon and diseased orange and sends them to the Agent A.
5. The scenario might continue with the user, that is, the farmer, looking at the several pictures and finding a match with the problem his trees have. When he has found the problem, he may then ask Agent A to find a diagnosis and a cure for it. Even in this case, the service provided by the OA might be useful again.
6. The existence of an explicit declarative ontology managed by an external agent, the OA, allows Agent B to concentrate on its actual task of indexing and sending pictures rather than on the maintenance of the ontology itself. Agent B may also be more lightweight as it is not necessary for it to encode all the ontology since relations and definition of concepts can be accessed on demand by querying the OA.
Even Agent A may need to access the same OA, for instance to explain to its user the type of diseased as in the figure.
2.3.2 Scenario 2 – Shared Ontology Selection
Agent SP is the service provider for electronic commerce of a given merchant. It has simple behaviours referring to the sell-products ontology. It has other more complex behaviours referring to the sell-wholesale-products ontology. The complex behaviours are designed as extensions of the simple ones. The sell-wholesale-products ontology is defined explicitly in an ontology server (for example, Ontolingua) as an extension of the sell-products ontology.
The ontology server is accessible by agents of a given FIPA compliant platform through an OA named OA1. Following the FIPA ontologies naming scheme, these two ontologies are named as follows: sell-products and sell-wholesale-product. Both of these ontologies refer to the electronic commerce domain.
Agent SP would like to sell products. It makes a call for proposal using a call-for-proposals (CFP) communicative act (see [FIPA00042]); the content of this communicative act refers to the sell-wholesale-products ontology.
Agent C is a customer. It has only simple behaviours referring to the sell-products ontology. Agent C does not know the sell-wholesale-products ontology and as a consequence has no precise idea of the purpose of this CFP. However Agent C believes that the CFP of Agent SP is interesting to it, for instance because:
· it believes that all CFPs from Agent SP are interesting to it, or,
· a third party agent knowing the needs of Agent C and understanding this CFP has recommended Agent C to answer this CFP, or,
· it has behaviour referring to the electronic commerce domain (that is at least the case in this example).
Following the CFP of Agent SP, three different protocols of interaction could be considered:
1. Agent C queries Agent SP to know if other ontologies can be used in this CFP. Agent SP answers that the sell-products ontology can be used. If Agent C does not know this ontology (this general case does not apply in this example), the process of interaction is repeated.
2. Agent C queries the DF to determine if it knows OAs providing access to electronic commerce domain. The DF answers to Agent C with a list of OAs including OA1. Agent C queries all these OAs about ontologies related to the sell-wholesale-products. OA1 informs Agent C that the sell-wholesale-products ontology is an extension of sell-wholesale-products ontology. Agent C asks Agent SP if it can use the sell-products ontology.
3. Agent C queries the DF to determine if it knows the address of OA1 which the DF gives back. Agent C queries OA1 about ontologies and OA1 informs Agent C that the sell-wholesale-products ontology is an extension of sell-products ontology. Agent C asks Agent SP if it can use the sell-products ontology.
2.3.3 Scenario 3 – Equivalence Testing
In this scenario an agent has to check the logical equivalence of two ontologies:
1. An ontology designer in US declares the car-product ontology and associated this to the ontology agent OA2, which is referred within the OA2 under the name car-product, following the FIPA ontologies naming scheme.
2. The ontology designer declares a complete French translation of its car-product ontology to the ontology agent OA1 in France as thevoiture ontology. Moreover these two ontologies are declared equivalent to OA1. The exact mapping is provided to OA1.
3. Agent A (in the US) requests OA2 to provide an ontology of domain cars which returns the ontology name car-product.
4. Agent A wants to communicate with Agent B (in France) about cars with the ontology car-product. Note that agent Agent A does not know this ontology.
5. Agent A queries if OA1 is able to provide an ontology equivalent to car-product. If it is, OA1 returns voiture to Agent A;
6. Agent A informs Agent B that these two ontologies voiture and car-product are equivalent and that OA1 can be used as a translator.
7. The dialogue between Agent A and Agent B can then start.
2.3.4 Scenario 4 – Ontology Location
In this scenario, an Agent A wants to know the list of ontologies referring to the term car. The agent believes that such an ontology exists because it has received a natural language request from a user including this term. However, it has no idea of the kind of concepts underlying this symbol, and it would like to access its definition without any human intervention.
1. Agent A wants to know the list of ontologies referring to a given term.
2. Agent A queries the DF for the list of OAs available.
3. Agent A queries each OA for the list of ontologies that include the given term.
4. The OA queries all the ontologies that it is able to access, about an object, a property and a class labelled with the given term.
2.3.5 Scenario 5 – Term Translation
This scenario gives a pragmatic example illustrating the "use of translation of terms" in a multi-agent context and it involves the naming of terms.
Consider a project integrating two legacy databases. Users of the integrated system want to continue seeing the integrated databases in the terms they are used to, the terms of the legacy database they were using. The first database contains information about the aircraft parts owned by the aircraft manufacturer; the second database describes aircraft parts owned by the aircraft operator.
In each database, an aircraft part has a name. However, one database calls it a name and the other calls it nomenclature. In other words, name and nomenclature are based on the same concept definition (the name of a part).
A query server answers queries from user agents (user interfaces and agents acting for users). The query server uses a domain ontology that integrates the data source ontologies. The user interface is based on a user model with user ontologies. This permits one user to specify and see part nomenclature in his user interface while another will see part name. We translate terms to answer queries based on each user ontology, and we also translate queries for each database (see Figure 2).
Figure 2: Model of Scenario 5
1. An agent, Agent A, wants to translate a given term from a first ontology into the corresponding term from a second one.
2. Agent A queries the DF for an OA which supports the translation between these ontologies.
3. The DF returns the name of a given OA; this OA knows the format of the ontologies involved (XML, OKBC, etc.) and has capabilities to make translation between these ones.
4. Agent A queries this OA.
5. The OA translates the requested term from Ontology Server 1 to Ontology Server 2 where Ontologies 1 and 2 contain the terms defined respectively in Databases 1 and 2.
3 Ontology Service Reference Model
Ontologies are stored at an ontology server. In general, several servers may exist with different interfaces and different capabilities. The OA allows agents to discover ontologies and servers and to access their services in a unique way, that is more suitable to the agent communication mechanism. Furthermore, it can implement extra functionalities such as a translation service or it can bring to the agent community knowledge about relationships between the different ontologies. This reference model given in Figure 3 does not preclude that in some particular implementations, the OA might wrap directly one ontology server.
Figure 3: Ontology Service Reference Model
The scope of this FIPA specification is ACL level communication between agents and not communication between the OAs and the ontology servers (for example, OKBC, OQL or any other proprietary protocol). Therefore, a FIPA-compliant OA will have to be developed on a custom basis to support interfaces with non-FIPA compliant ontology severs.
3.1.1 Ontology Agent Services
The OA must be able to participate in a communication about the following tasks, possibly responding that it is not able to execute these tasks:
· helping a FIPA agent in selecting a shared (sub)ontology for communication,
· creating and updating an ontology, or only some terms of an ontology,
· translating expressions between different ontologies (different names with same meanings),
· responding to queries for relationships between terms or between ontologies, and,
· discovering public ontologies in order to access them.
Furthermore, the OA allows the Ontology Server to make its ontologies publicly available in the agent domain.
3.2 Ontology Naming
Each ontology is stored at an ontology server. The OA registers the list of supported ontologies with the DF and within an OA, each ontology is uniquely named, registered and identified by a logical name managed by the OA. It hides from the agent community the physical name of the ontology, both the name of the server (for example, Ontolingua) and the actual name of the ontology itself. The OA is only responsible for knowing about the mapping to the physical name, while all ACL messages and references are assumed to refer directly to this ontology identifier[1].
3.3 Relationships Between Ontologies
In an open environment, agents may benefit, in some applications, from knowing the existence of some relationships between ontologies, for instance to decide if and how to communicate with other agents. Even if in principle every agent may believe such relationships, the ontology agent has the most adequate role in the community to know that. It can be then queried for the value of such relationships and it can use that for translation or for facilitating the selection of a shared ontology for agent communication. The following predicate must be used for this purpose:
(ontol-relationship ?O1 ?O2 ?level)
which is defined to be true when a relationship of level level exists between the two ontologies in the arguments O1 and O2. The argument level may assume one of the values specified in Table 1[2].
|
Extension |
When O1 extends the ontology O2 |
|
Identical |
When the two ontologies O1 and O2 are identical |
|
Equivalent |
When the two ontologies O1 and O2 are equivalent |
|
Weakly-Translatable |
When the source ontology O1 is weakly translatable to the target ontology O2 |
|
Strongly-Translatable |
When the source ontology O1 is strongly translatable to the target ontology O2 |
|
Approx-Translatable |
When the source ontology O1 is approximately translatable to the target ontology O2 |
Table 1: Ontology Relationship Levels
3.3.1 Extending Ontologies
It is common and good engineering practice to build a new ontology by extending or combining existing ones. The extension level of relationship captures this reuse practice.
When (ontol-relationship O1 O2 extension) holds, then the ontology O1 extends or includes the ontology O2. Informally this means that all the symbols that are defined within the O2 ontology are found in the O1 ontology, with the very important restriction that the properties expressed between the entities in the O2 ontology are conserved in the O1 ontology.
This specification makes no distinction between extension and inclusion relationships between ontologies.
Figure 4: Example Extension of an Ontology
Example 1 (extension): In the Ontology O1 (see Figure 4) the class Fruit is split into the Apple, Lemon and Orange classes. The ontology O2 extends O1 by inserting the class Citrus between the class Fruit and both classes Orange and Lemon. In this case the predicate holds since all entities in O1 are in O2 and since all relations in O1 still hold. For instance, in O1 Lemon is a Fruit, and in O2 Lemon is a Citrus and Citrus is a Fruit implies that Lemon is a Fruit.
Example 2 (inclusion): O1 defines Cars, O2 defines Cars and Vans by reusing without any modification all classes involved in the Cars class defined in O1. Once more (ontol-relationship O2 O1 extension) holds.
3.3.2 Identical Ontologies
This level is used to assert that two ontologies O1 and O2 are identical. By identical, we mean that the vocabulary, the axiomatization and the representation language used are physically identical, like are for instance two mirror copies of a file. However two identical ontologies could be named and referred under different names[3].
3.3.3 Equivalently Ontologies
Two ontologies O1 and O2 are said to be equivalent whenever they share the same vocabulary and the same logical axiomatization, but possibly are expressed using different representation languages (for instance, Ontolingua and XML).
If we consider a particular ontology server with given deduction capabilities, everything that is provable or deductible from O1 will be provable from O2 and vice versa. Moreover, the following property holds: if O1 and O2 are equivalent then O1 and O2 are strongly translatable in both ways. In this case only a mapping between the representation languages is required[4].
3.3.4 Weakly Translatable Ontologies
This level relates two ontologies Osource and Odest when it is possible to translate from Osource to Odest, even if with a possible loss of information. Odest is then supposed to share a subset of the vocabulary and axiomatization of Osource. It means that some terms or relationships from Osource will be possibly simplified when translated to Odest. It means also that some terms or relationships will not be translatable to Odest, because they do not appear in the Odest axiomatizations. Nevertheless, a weak translation should not introduce any inconsistency.
For example, let us consider the French (Osource) and English (Odest) simple ontologies on fruit such as (see Figure 5):
· In Osource a Fruit is an Agrume or Pomme or Poire and an Agrume is either a Citron, an Orange or a Pamplemousse.
· In Odest a Fruit is either a Lemon, an Orange or an Apple.
Osource is weakly translatable to Odest with the vocabulary mapping (PommeÞ Apple; CitronÞ Lemon; OrangeÞ Orange; FruitÞ Fruit) with a loss of information concerning Pamplemousse, Poire and the conceptualization of Agrume as the subclass of Fruit containing Citron, Pamplemousse and Orange. Nevertheless after translation Lemons and Oranges are still Fruits.
Figure 5: Example Weakly Translatable Ontologies
3.3.5 Strongly Translatable Ontologies
An ontology Osource is said to be related with level Strongly-Translatable to ontology Odest if:
1. the vocabulary of Osource can be totally translated to the vocabulary of Odest,
2. the axiomatization of Osource holds in Odest,
3. there is no loss of information from Osource to Odest, and,
4. there is no introduction of inconsistency.
However, the representation languages used by Osource and Odest can still be different.
For example, let us consider the English (Osource) and French (Odest) ontologies, such as (see Figure 6):
· In Osource a Fruit is a either a Citrus, an Apple or a Pear, and a Citrus is either a Lemon or an Orange.
· In Odest a Fruit is an Agrume or a Pomme or a Poire, and an Agrume is either a Citron an Orange or a Pamplemousse.
Osource is Strongly Translatable to Odest with the vocabulary mapping (AppleÞ Pomme; LemonÞ Citron; OrangeÞ Orange; FruitÞ Fruit, PearÞ Poire, Citrus Þ Agrume). Moreover every property that holds in Osource holds in Odest after translation. Thus this is an example of a strongly translatable predicate. The reverse translation, that is, Odest to Osource is not strongly translatable since Pamplemousse is not defined in Osource.
Figure 6: Example of Strongly Translatable Ontologies
3.3.6 Approximately Translatable Ontologies
This level is the less restrictive. Two ontologies Osource and Odest are said to be related with level Approx-Translatable if they are Weakly-Translatable with introduction of possible inconsistencies, for example, some of the relations become no more valid and some constraints do not apply anymore.
For example, let us consider two ontologies that refer to a term which has slightly different meanings according to the context in which it is used. The two ontologies are respectively ingredients-for-chinese-cooking and ingredients-for-european-cooking. In both ontologies, we consider the two following classes Parsley and Pepper. The difference is that in the ingredients-for-chinese-cooking ontology, Coriander is classified as a sort of Parsley, because its leaves are used and that in the ingredients-for-european-cooking ontology, Coriander is classified as a sort of Pepper, because only its seeds (called “Chinese” pepper) are used. The term Coriander enjoys different properties in the two ontologies, even if it refers to the same plant.
If we consider a translation between these two ontologies, the translation of Coriander (in the ingredients-for-chinese-cooking ontology) by Coriander (in the ingredients-for-european-cooking ontology) can be useful mainly because as said previously the term designates the same plant. Nevertheless, some of the properties expressed in the ingredients-for-chinese-cooking ontology do not hold any more in the ingredients-for-european-cooking ontology and vice versa.
3.3.7 General Properties
The following properties hold between level of relationships:
· Strongly-TranslatableÞWeakly-TranslatableÞApprox-Translatable
· Equivalent (O1, O2)ÞStrongly-Translatable (O1, O2)ÙStrongly-Translatable (O2, O1)
· IdenticalÞEquivalent
3.4 Registration of the Ontology Agent with the DF
In order for an agent to advertise its willingness to provide a set of ontology services to an agent domain, it must register with a DF (as described in [FIPA00023]). Of course, the DF is not responsible for ensuring the validity of the provided service.
As part of this registration process a number of constant values are introduced which universally identify the ontology services. The service-description object registered with the DF must include the following parameters:
· :type must be declared as a fipa-oa service,
· :ontology must include the constant FIPA-Ontol-Service-Ontology, which identifies the set of actions that can be requested to be performed by an OA, and,
· :properties must include the set of supported ontologies:
property (
:name supported-ontologies
:value (set ontology-description))
In addition to the set of supported ontologies, the OA may also register its translation capabilities between different ontologies (if it has any). Notice that the specification does not prevent non-OA agents to also have translation capabilities. The translation capabilities may include ontology translation, language translation or both. The following constant values must be used to register translation services:
· :type parameter must be declared as a translation-service,
· :ontology must include the constant FIPA-Meta-Ontology, which identifies the set of actions that can be requested to be performed by an OA, regarding translation services, and,
· :properties must include the set of available ontology translations:
property (
:name ontology-translation-types
:value (set translation-description))
and/or the list of available language translation types:
property (
:name language-translation-types
:value (set translation-description))
The definitions for the objects ontology-description and translation-description are given in section 4, Ontology Service Ontology.
The following is an example of registration of an OA with the DF:
(request
:sender
(agent-identifier
:name oa@foo.com
:addresses (sequence iiop://foo.com/acc))
:receiver (set
(agent-identifier
:name df@bar.com
:addresses (sequence iiop://bar.com/acc)))
:language FIPA-SL0
:protocol FIPA-Request
:ontology FIPA-Agent-Management
:content
(action
(agent-identifier
:name df@bar.com
:addresses (sequence iiop://bar.com/acc))
(register
(df-description
:name
(agent-identifier
:name oa@foo.com
:addresses (sequence iiop://foo.com/acc))
:services (set
(service-description
:name Serv_Name1
:type fipa-oa
:ontology (set FIPA-Ontol-Service-Ontology)
:properties (set
(property
:name supported-ontologies
:value (set
(ontology-description
:ontology-name FIPA-VPN-Provisioning
:version "1.0"
:source-languages (set XML)
:domains (set Telecomms))
(ontology-description
:ontology-name Product
:source-languages (set KIF)
:domains (set Commerce))))))
(service-description
:name Serv_Name2
:type translation-service
:ontology (set FIPA-Ontol-Service-Ontology)
:properties (set
(property
:name ontology-translation-types
:value (set
(translation-description
:from FIPA-VPN-Provisioning
:to Product
:level Weakly-Translatable)
(translation-description
:from Product
:to Italian-Product
:level Strongly-Translatable)))
(property
:name language-translation-types
:value (set
(translation-description
:from FIPA-SL
:to KIF
:level Weakly-Translatable)
(translation-description
:from OntoLingua
:to LOOM
:level Strongly-Translatable)))))
:protocol FIPA-Request
:ontology FIPA-Ontol-Service-Ontology))))
3.4.1 Querying the DF
The search action (see [FIPA00023] enables an agent to query the DF for available ontology related services, namely:
· the list of registered OAs,
· the list of OAs that support ontologies in a given domain,
· the basic properties of a given ontology (for example, domain, source-language), and,
· the list of OAs that provide a specific translation service.
It is also possible for an agent to query a DF to establish what agents claim to understand a given ontology. The reply could be a list of OA who offer such an ontology, the requesting agent can then use it intelligence to decide which ontology service is wishes to use.
For example, the following example describes the case where an agent (the pca-agent in the example) queries a DF to establish what OA agents can support the FIPA-VPN-Provisioning ontology:
(request
:sender
(agent-identifier
:name pca-agent@foo.com
:addresses (sequence iiop://foo.com/acc))
:receiver (set
(agent-identifier
:name df@bar.com
:addresses (sequence iiop://bar.com/acc)))
:language FIPA-SL0
:protocol FIPA-Request
:ontology FIPA-Agent-Management
:reply-with search-123
:content
(action
(agent-identifier
:name df@bar.com
:addresses (sequence iiop://bar.com/acc))
(search
(df-agent-description
:services (set
(service-description
:type fipa-oa
:ontology (set FIPA-Ontol-Service-Ontology)
:properties (set
(property
:name supported-ontologies
:value (set