Dynamic composition of web services requires an automated step of contracting, i.e., the computation of a possibly fruitful interaction between two (or more) services, based on their policies and goals. In previous work, the SCIFF abductive logic language was used to represent the services' policies, and the associated proof procedure to perform the contracting. In this paper, we build on that work in order to exploit the results of the Description Logics research area to represent domain speci¯c knowledge, either by importing the knowledge encoded in an ontology into a SCIFF knowledge base, or by interfacing the SCIFF proof procedure to an existing ontological reasoner.
Service Oriented Architectures, exploiting the Internet as a means of communication, are emerging as a simple and e®ective paradigm for distributed application development. Heterogeneous entities, in terms of hardware and software settings, can interoperate e®ectively following well established communication standards.
Service providers can expose their policies, in order for potential customers to evaluate the feasibility of a fruitful interaction. Such an evaluation can be performed manually, if the service's interface is bound not to change over time.
However, a more promising approach is for customers to choose the appropriate service provider at run-time, based on the service provider's exposed policies.
This approach requires a reasoning engine that reasons on the provider and customer's goals and policies, in order to devise a sequence of actions that lets both achieve their goals, while respecting their policies.
In [
However, in a practical perspective, we envisage a possible improvement in representing the domain speci¯c knowledge exploiting the vast body of results from the Knowledge Representation ¯eld and, in particular, Description Logics. In this way, we can address the Ontology layer of the Semantic Web stack.
In this paper, we propose two di®erent approaches to let SCIFF access existing knowledge, expressed by means of an ontology: { by translating (part of) an ontology into SCIFF clauses, which can subsequently be handled by the SCIFF proof procedure in the usual way; { by interfacing SCIFF with ontological reasoners, distinguishing syntactically the ontology-related predicates and delegating their computation to the external reasoners.
This approach bears two main practical advantages: ¯rst, it makes the knowledge encoded in ontologies available to SCIFF, and second (with the second approach) it takes advantage of the formal properties enjoyed by the existing ontological reasoners for the associated computational tasks, in particular concerning decidability and e±ciency.
Our approach di®ers from the one proposed by Matzner and Hitzler in
PrOWLog [
An integration of ontological reasoning into SCIFF, following the ontology
importing approach, is also proposed by Chesani et al. [
The paper is structured as follows: in Sect. 2 we brie°y recall the SCIFF
approach to contracting, in Sect. 3 we show how the relevant domain knowledge
can be expressed by means of an ontology, and in Sect. 4 we describe the two
di®erent approaches to access ontologies from SCIFF: importing an ontology into
a SCIFF knowledge base (Sect. 4.1), and interfacing the SCIFF proof procedure
with the Pellet [
In this section, we brie°y recall the SCIFF-based contracting framework [
A web service's policy is de¯ned, in the SCIFF language, as an abductive logic
program (ALP). An ALP is de¯ned as the triplet hKBS ; A; ICi, where KBS
is a logic program in which the clauses can contain special atoms, that belong
to the set A and are called abducibles. Such atoms are not de¯ned by means of
clauses in the KBS , and, as such, they cannot be proven: their truth value can be
only hypothesized. In order to avoid unconstrained hypotheses, a set of integrity
constraints (IC) must always be satis¯ed. Integrity constraints, in our language,
are in the form of implications, and can relate abducible literals, de¯ned literals,
as well as constraints with Constraint Logic Programming [
In particular, the integrity constraints can relate the web services' information exchanges with the expected input from peer web services. The possible relations can be of various types, and include temporal relations, such as deadlines, linear constraints, disequalities and inequalities, all de¯ned by means of constraints. The de¯nitions stated in this way are then used to make assumptions on the possible evolutions of the interaction.
A web service can reason about happened events, denoted with H(S; R; M; T ), meaning that a Sender S sends message M to a Receiver R in some time T . All the parameters can be logical terms, or variables, possibly subject to constraints. Also, the policy might describe that a peer should provide some input, by sending a message. Such expectation of the incoming message is represented as E(S; R; M; T ), and it will be satis¯ed in case the message, in the form of H atom, actually arrives. In some cases, the expectation could be negative, as in EN(S; R; M; T ): the policy says in this case that a matching H event would be unwelcome, as it would contradict other assumptions.
For example, an integrity constraint can state that, if a peer web service sends me a request, then I will accept:
H(S; me; request(X); T ) ! H(me; S; accept(X); Ta): Another rule can say that, if I send a request, I expect the peer either to accept or to refuse, within 5 time units:
H(me; S; request(X); T ) ! E(S; me; accept(X); Ta); Ta < T + 5
E(S; me; ref use(X); Tr); Tr < T + 5
Once the speci¯cation of a policy is de¯ned by means of integrity constraints and expectations, they are processed by the SCIFF proof procedure, the operational counterpart of the language. The proof-procedure performs abductive reasoning, i.e., it can make assumptions and generate hypotheses. In particular, it can hypothesise that some message will be sent, or that some expectation will be raised. In case the expectations are matched by corresponding events, the abductive process succeeds, otherwise the current branch will fail, and another alternative will be selected (if there exists one). In this way, the SCIFF proofprocedure is able to ¯nd if there exists at least a set of events that satis¯es a given ALP, and provides in output both the abduced events and expectations.
In contracting applications, the potential interacting services expose their policies (in a format resulting from the extension of RuleML), and SCIFF operates on the merging of the policies. A successful computation yields a sequence of actions that satis¯es all the parties' policies. 2.2
A contracting scenario
In [
The two actors are eShop (which wants to sell a device) and alice (a potential customer for that device), each with policies expressed as SCIFF ICs. SCIFF is used as a reasoner in a component that acts as a mediator, considering the actors' policies and trying to devise a course of action that will let both reach their goals. The two actors' policies, expressed in SCIFF integrity constraints, are as follows. alice's policy. \If the shop asks me to pay cash, I will, but if the shop asks me to pay by credit card, I will require evidence of the shop's a±liation to the Better Business Bureau.\
eShop's policy. \If an acceptable customer requests an item from me, then I expect the customer to pay for the item with an acceptable means of payment. If the customer is not acceptable, I will inform him/her of the failure. If an acceptable customer pays with an acceptable means of payment, I will deliver the item. If a customer requests evidence of my a±liation to the Better Business Bureau (BBB), I will provide it."
accepted customer(Customer) ^ H(tell(eShop; Customer; ask(pay(Item; How))); T a)^
H(tell(Customer; eShop; pay(Item; How)); T p) ^ accepted customer(Customer) ^ accepted payment(How) !
(1) (2)
The notion of acceptability for customers and payment methods from
eShop's viewpoint, de¯ned by the accepted customer/1 and accepted payment/1
predicates, is de¯ned in eShop's knowledge base. In [
This knowledge is merged with that provided by the customer, for example resident_in(alice,european_union).
so that in the resulting knowledge base, on which SCIFF operates, accepted customer(alice) is true.
However, this method would not work in case the customer declared resident in(alice,italy), as italy does not unify with european union. One could, of course, add to the knowledge base accepted destination/1 facts for all the current EU members, but such knowledge should be updated when new countries join the EU. In other cases, acceptability could be de¯ned by a transitive, symmetric relation, which could introduce cycles in the knowledge base, possibly leading to loops. 3
Representing domain knowledge with ontologies
An alternative way to represent (part of) the domain speci¯c knowledge is to
use technology and concepts developed, with focus on this very purpose, in
the Knowledge Representation ¯eld, and to rely, in particular, on ontologies.
The W3C recommendation for ontology representation on the Web is the Web
Ontology Language (OWL) [
For instance, in Fig. 1 we show a possible ontological representation of eShop's policies concerning acceptable customers and means of payments, merged with alice's own knowledge.
The following OWL clause says that the acceptedCustomer class is a subclass of the potentialCustomer class, and that it is disjoint from the rejectedCustomer class: <owl:Class rdf:about="#acceptedCustomer"> <rdfs:subClassOf rdf:resource="#potentialCustomer" /> <owl:disjointWith rdf:resource="#rejectedCustomer" /> </owl:Class> The following clause states that cash is an instance of the acceptedPayment class: <owl:Thing rdf:about="#cash">
<rdf:type rdf:resource="#acceptedPayment" /> </owl:Thing> The following clause declares the paysWith property: <owl:ObjectProperty rdf:ID="paysWith"> <rdfs:domain rdf:resource="#potentialCustomer" /> <rdfs:range rdf:resource="#payment" /> </owl:ObjectProperty> The following clause states that alice is an instance of italian, with value ae1254 for the paysWith property: <owl:Thing rdf:about="#alice"> <rdf:type rdf:resource="#italian" /> <paysWith rdf:resource="#ae1254" /> </owl:Thing> It can be noticed that the ontological notation for the KB makes it possible to infer that alice is European (and therefore an accepted customer) even if she just states being Italian, while if we had put resident in(alice, italy) instead of resident in(alice, europe) in the KB at the end of Sect. 2.2 she would not have been recognized as such.
Moreover, we de¯ned a class premiumCustomer representing the accepted customers who pay with a credit card, and which we could use to add re¯nement to policies (for instance providing a faster delivery). Since alice is an accepted customer and pays with her credit card, the ontological reasoning allows to recognize her as a premiumCustomer. 4
We implemented the SCIFF access to OWL ontologies in two di®erent ways, that we describe in this section. In both cases it should be noticed that even if OWL relies on the Open World Assumption, when SCIFF comes to reasoning involving it, the logic programming peculiar Closed World Assumption is reintroduced, thus assuming to have all (relevant) information on the domain available at that time and providing usual features such as negation as failure. In this section we present the two approaches, and their experimental evaluation.
Considering that Logic Programming (LP) and Description Logics (DL) have a
common root in First Order Logic, a ¯rst approach is to ¯nd their intersection
and to translate ontologies to LP clauses. These two problems have already been
addressed by Grosof et al. [
For all these reasons the e-commerce ontology must be modi¯ed, in particular removing the premiumCustomer class, and the DisjointClasses axioms.
An approach that aims to overcome the limitations described in Sect. 4.1 consists of interfacing SCIFF with an external speci¯c ontology-focused component which can be, when necessary, queried by SCIFF and which performs the actual ontological reasoning and gives back results. As represented in Fig. 2, the architecture for this solution involves a Prolog meta-predicate which invokes the ontological reasoning on desired goals, an intercommunication interface from SCIFF to the external component (which incorporates a query and results translation schema) and the actual reasoning module. Both modules can access both local and networked knowledge.
Goals given to the meta-predicate are handled like suggested in [
Performance comparisons of the two approaches are hardly signi¯cant, as they mainly di®er in expressive power. However, to assess their scalability, we experimented with randomly generated ontologies. Each ontology, composed of N classes, was built starting from its root node, and recursively attempting, for each node, ¯ve attempts of child generation, each with probability 1=3.
The reasoners were queried about the belonging of an entity to the hierarchy root class. For both approaches, we report in Tab. 1 the time spent for loading the ontology into the reasoner1 and for the actual query. Both approaches appear to scale reasonably (on PC equipped with an Intel Celeron 2.4 GHz CPU). In both cases, the loading time is higher than the query time; for the importing approach, this is particularly noticeable, and encouraging, as in real applications the ontology would be imported only once. 5
Conclusions In this paper, we proposed an integration of the previously developed SCIFF reasoning framework for service contracting with Description Logics standards. 1 For the importing approach, the load time is the time spent for translating the ontology and parsing the resulting clauses and ICs, while for the Pellet-based approach it is the time spent for parsing ICs and loading the ontology into a persistent OWLOntology object. We proposed two approaches: ¯rst, to translate ontological knowledge into the SCIFF formalism; second, to interface the SCIFF reasoner to ontological reasoners, delegating the ontological reasoning to them. In this way, we make the results (in terms of representation capability and computational e±ciency) obtained in the Description Logics area available to the SCIFF contracting framework.