Usage Scenario: Ontology Translation
Name: Ontology Translation Service
Author(s): Drew McDermott, Dejing Dou, Peishen Qi
URL(s) or other references: http://cs-www.cs.yale.edu/homes/dvm/daml/
Domain: Facilitating communication between disparate agents
A matchmaking or broker agent wants to connect two agents A and B together. Both agents use RDF or some other declarative notation to communicate. The broker is able to translate the notations to some common syntactic base, such as first-order logic or description logic. However, the agents also declare what ontologies they use. Suppose Agent A uses ontologies N1 and N2, and B uses N2, N3, and N4. There is a partial overlap, but there may be a communication failure if a message contains symbols the recipient doesn't expect.
The broker turns to the ontology translation service. It sends it the URIs for the two ontology sets involve, S1={N1,N2} and S2={N2,N3,N4}. The OTS responds with either a failure message or a claim that it can translate (at least some) messages expressed in the vocabularies in S1 to equivalents in the vocabularies of S2.
The broker must be able to classify messages between A and B as queries or assertions. It handles these differently, as explained in the "Use Cases" listed below.
Scope = relevant issues, says the accompanying hint.
Relevant issues are:
Everyone producing web agents for whom semantic interoperability is an issue.
See above.
None so far.
Translator should be able to respond within seconds. Requests may be coming in from many different potential users, but the load on the translation server per request is light.
We assume the existence of complex ontologies, expressed in predicate calculus. DLs are a special case, but not expressive enough in most cases.
Who does ontology mapping and merging?
This is the initial probe by the broker to see if this translation server can help. There may be several, competing translation servers.
A web agent can identify what notations it uses for messages in and out through various ports, and what ontologies each message might use.
Translation server receives "cold call" from broker giving two lists of ontologies, where each ontology is identified by a URL that contains the actual statements of the relationships among the symbols in the ontology (subclass and subproperty relationships, axioms, etc.)
Server responds with one of two messages:
None.
None
Latency might be on the order of a second or two. Throughput should be high enough that an "assertion" consisting of a thousand subassertions should be processed in a few seconds. Small assertions should take zero time on the usual web scale.
All the interaction between agents A and B will go through the translation server, so there could be a burst of high-frequency interaction between broker and translation server.
The translation server must be capable of doing forward chaining and equality substitution. It must avoid infinite loops or at least detect inference chains that get too long so it can abort them.
Forward chaining is well understood, but exactly what sort of equality substitution are we talking about?
We need equality substitution because cardinality constraints (and their predicate-calculus analogues) often produce equalities between skolem terms and more useful names for the same objects.
The goal is to translate assertions in the scenario laid out above.
The translation server has a robust "merged ontology" that enables it to draw enough inferences from statement Q in ontology N1 (say) that it eventually makes inferences Q1,...,Qk in ontology N2 or N4. These inferences then become its guess as to the equivalent of Q in those ontologies. If the merged ontology is too weak to draw useful inferences, the translation will be inadequate.
Broker intercepts a message from A that (it knows) is intended for B. Broker sends a message to translation server:
Translate A->B,
Statement Q,
using ontology {N1},
target ontologies {N2, N3, N4}
Correlation token X
It includes the correlation token to allow the broker to know
which translation context the request is made in.
Translation server draws conclusions from Q in the merged ontology, collecting all inferences that are expressed purely in terms of N2, N3, and N4.
If translation server draws no conclusions, it sends an error message back to broker.
Otherwise, it sends the collected inferences back as a conjunction, with another correlation token Y identifying the particular transaction.
Broker translates the conjunction into B's syntax (if necessary), then sends it to B.
If B responds with an error message saying "Defective input," then broker sends a message to the translation server:
Possible failed translation
Recipient (B's) error message
Correlation token Y
Just those implied by the possible errors
From the broker's point of view, the use of this translation server to mediate between A and b has failed, and the attempted composition of A and B must be undone.
From the translation server's point of view, the failure must be logged and saved for analysis by experts in the merged ontology for N1-N4.
In most cases, query translation involves little computing power and throughput on the translation server's side.
Backward chaining with some equality substitution.
Same as the previous case.
The broker has the goal of translating a query A has issued to B.
The "merged ontology" (see above) must enable the translation server, given a query Q, to find sets of subqueries
Q11 & Q12 & ... & Q1K1 Q21 & ... & Q2K2 ... Qn1 & & QnKnwhere the vocabulary of each subquery is a subset of the unions of the vocabularies N2, N3, and N4, and and an answer to any conjunction is also an answer to Q.
An agent must send a standardized failure message when it fails due to a query returning an unexpected result.
Broker intercepts a query from A that (it knows) is intended for B.
Translate A->B,
Query Q,
using ontology {N1},
target ontologies {N2, N3, N4}
Correlation token X
It includes the correlation token to allow the broker to know
which translation context the request is made in.
Translation server uses backward chaining to find one or more conjunctive subqueries expressed purely in terms of N2, N3, and N4.
If translation server finds no subqueries, it sends an error message back to broker. Otherwise, it sends the subqueries back to broker, with a correlation token Z identifying the particular transaction.
If broker gets subqueries from the translation server, it sends them to B, collects the answers, and sends the answers to A. If the broker gets the "no subqueries" error message from the translation server, it sends the message "No answers to query" to A.
If A sends an error message to a third party reporting unexpected failure of query, then broker sends report to the translation server,
Apparent query failure
A's error message
Correlation token Z
Obviously, there is a hefty assumption here that the broker can tell
when A has failed because the query's results were unexpected. That's
why we put it in the "Assumptions" list.
None except those already mentioned.
From the broker's point of view, the use of this translation server to mediate between A and b has failed, and the attempted composition of A and B must be undone.
From the translation server's point of view, the failure must be logged and saved for analysis by experts in the merged ontology for N1-N4.