=Paper=
{{Paper
|id=Vol-316/paper-1
|storemode=property
|title=Two-phase Semantic Web Service Discovery Method for Finding Intersection Matches using Logic Programming
|pdfUrl=https://ceur-ws.org/Vol-316/Paper-1.pdf
|volume=Vol-316
|authors=Laszlo Kovacs,Andras Micsik and Peter Pallinger
|dblpUrl=https://dblp.org/rec/conf/ecows/KovacsMP06
}}
==Two-phase Semantic Web Service Discovery Method for Finding Intersection Matches using Logic Programming==
https://ceur-ws.org/Vol-316/Paper-1.pdf
Two-phase Semantic Web Service Discovery Method for Finding Intersection
Matches using Logic Programming
László Kovács, András Micsik, Péter Pallinger
MTA SZTAKI
Computer and Automation Research Institute
of the Hungarian Academy of Sciences
Department of Distributed Systems
{laszlo.kovacs, micsik, pallinger}@sztaki.hu
Abstract various tools and editors support the creation of
semantic descriptions for existing Web Services. The
Discovering Web Services based on logical resulting ontologies, goals and Semantic Web Services
matching of capabilities is a new requirement for are made accessible in a distributed registry. WSML
Semantic Web Services which cannot be solved with [14] was chosen as the language for describing these
traditional information retrieval (IR) techniques. semantic entities. The runtime phase involves
Building fast and precise logical discovery engines is discovery, selection and execution of the semantic web
an ongoing challenge of the Semantic Web community. services. The runtime environment also collects quality
This paper presents the discovery engine implemented of service data for semantic web services which are fed
for the INFRAWEBS project which combines a back to the phase of discovery and selection.
traditional IR-based pre-filtering step and a logic-
based matching implemented in Prolog. The logic- 1.2. Discovery
based step of discovery uses a novel technique based
on Prolog-style unification of terms. This approach The discovery engine in our scenario receives a
performs well in finding matches of intersection type, WSML goal as input and it has to provide a list of
and it also provides possibilities to compare, rank and matching Semantic Web Services possibly coupled
explain these matches. with additional information that supports ranking and
selection.
1. Introduction Discovery implementation has three steps: a pre-
filtering step, a step for logical matching and a
Using Semantic Web Services is often broken into finalizing step to prepare the result.
the main steps of discovery, selection and execution. The aim of the pre-filtering step is to narrow the list
Discovering Web Services based on logical matching of candidates using traditional text-processing
of capabilities is a new requirement for Semantic Web (keyword matching) algorithms.
Services which cannot be solved with traditional The logical matching is performed on the
information retrieval (IR) techniques. Building fast and precondition, assumptions, postcondition and effects of
precise logical discovery engines is an ongoing the goal and service.
challenge of the Semantic Web community. In the final step the list of matching services are
In this paper we present the discovery engine enhanced with QoS data based on past execution
developed in the INFRAWEBS project of FP6. The experience. QoS data is collected by another module of
INFRAWEBS project develops an ICT framework, the framework, and can be used for service selection.
which enables software and service providers to The rest of the paper describes the discovery
generate and establish open and extensible component implemented for the INFRAWEBS project
development platforms for Web Service applications. and compares it with related work.
The INFRAWEBS project divides the life-cycle of
Semantic Web Services in two different phases: Design
Time and Runtime. During the Design Time phase
2. Keyword-based discovery 3. Logical matching
Each semantic web service and goal capability The WSMO deliverable on discovery [11] defines
definition may be seen as a structured text document. semantic matching as:
This gives us the possibility for a preliminary selection W , G , O |= ∃x ( g ( x ) ∧ ws ( x ))
of Web Services using classical keyword-based
discovery, but at the level of ontology concepts. where W is the definition of the web service, G is the
The WSMO deliverable on discovery [11] suggests definition of the goal, O is a set of ontologies to which
the keyword-based approach to be used in conjunction both descriptions refer, g(x) and ws(x) are the first-
with the keywords given by capability editors and order formulae describing the effects of the goal and
listed as non-functional properties (metadata about web web service respectively. In this case only the desired
services). However, the correctness and quality of such and offered outcomes are matched, and the meaning of
natural language descriptions are hard to ensure and the match is: there exists an outcome offered by the
control. Empty or faulty descriptions make services service which is requested by the user. This definition
inaccessible, even when their capabilities are defined can be further elaborated into various types of matches:
correctly. Multilinguality of metadata is another • Exact match: the possible outcomes of the service
problem of this solution. and the goal are equivalent; the service does
Our approach is different from the WSMO idea, exactly what the user desires.
because here the axioms are indexed instead of the
non-functional properties. The proper formulation of • Subsumption match: each possible outcome of the
the axioms is needed for the correct use of Semantic service is accepted by the goal, i.e. all service
Web Services, therefore the quality of the index data is offers are acceptable by the user, though there
implicitly ensured. might be desires not covered by the service.
It is obvious that the result of keyword-based
• Plugin match: each possible outcome requested
discovery may contain semantically non-matches (e.g.
by the goal can be produced by the service, i.e. all
the capability for selling tickets everywhere except to
user requests can be satisfied by the service,
Budapest). The key criterion is not to filter out any
although the service may provide additional, non-
good semantic match in this phase. In [9] we show that
matching outcomes as well.
by simple conditions on the ontology structure this can
be guaranteed. For example, in case of a single • Intersection match: there is at least one service
homogeneous set of ontologies, the description of each outcome accepted by the user (goal).
relevant capability requires the use of certain concepts;
therefore the goal and service capabilities must both This section details the practical problems of semantic
contain these concepts. matching. Theoretically both Description Logic and
The advantage is the very good response time Logic Programming (the most popular and available
compared to logic reasoning, while the disadvantage is variations of logic in this area) are capable to find all
that logically incorrect results are also collected. the types of matches listed above. However, the
Therefore, this operation is ideal for a so-called pre- assumption based on our real-life scenarios is that the
filtering, to reduce the number of web services for majority of matches will be of type intersection.
which the time-consuming logical matching has to be A method for finding intersection matches using
calculated. Description Logic is described in [18], but its
The Organisational Memory (OM) component of application in case of long and complex capability
the INFRAWEBS framework is specialized on textual descriptions is problematic. For example, it requires
queries. Its main role is to index all available textual that unrelated concepts are defined as disjoint pair
documents with respect to web services, including wise. Overall, the matching process needs complex DL
WSDL and WSML. With its indexes OM helps the modelling which is hard to maintain. Using
creators of Semantic Web Services to find relevant or Description Logic it is decidable whether there is a
similar information for the semantic modelling of web common solution for the goal and the service, but it
services. In the INFRAWEBS framework the cannot tell what the solution is. More details on our
functionality of OM is used in the pre-filtering step, experiments with using Description Logic for service
but another version is implemented using Apache matching are published in [10].
Lucene (Apache’s text search engine library) as well. Logic Programming can tell what the common
solution is if it is able to find it. Let's take two very
simple example conditions:
Goal: based modelling approach [11], it is clear that there can
Ticket from Wien to Graz be tickets fulfilling all conditions. But in the world of
Ticket date 06.06.2006. logic, there is no implication in either direction
between the goal and web service. The goal is
Webservice: specialized in details of desired service, while the web
Ticket from X to Y service is specialised in details of service delivery.
where X and Y are in Austria A further problem is that both goal and service
Ticket issued by Austrian Air descriptions may vary in the level of detail. For
example, sometimes the destination or the date is
This example roughly corresponds to the WSMO omitted, sometimes more conditions are given, for
Virtual Travel Agency use case [17], and also agrees example to have a business class ticket.
with the INFRAWEBS project use cases [6].
For humans this seems a perfect match. If we model
the outcome with a set of tickets according to the set-
Goal Web service
Matching, X,Y unified
with Wien, Graz
Ticket from Wien to Graz Ticket from X to Y
True for X=Wien
X is in Austria
True for Y=Graz
Y is in Austria
No contradiction
Ticket issued by Austrian Air
No contradiction
Ticket date 06/06/2006
Figure 1: Schematic example of matching with unification
3.1. Semantic matching using Logic clause, and (C11 and C12 and … C1n) a clause set. A
Programming DNF is true if at least one clause set is true. A DNF
clause set is true if all its clauses are true. This means
Our solution applies the unification facility of that a clause set provides a complete solution if all its
Prolog engines. If we find matching terms within the clauses are true.
goal and the web service, we can use this information The pre-processing steps needed to create the
to decide on the matching. A schematic explanation of infrastructure for matching:
unification can be found in Figure 1. The goal in the • Ontologies are converted to Prolog. Special
figure describes a request for a ticket from Wien to predicates are used to represent subconcept,
Graz for a given date, while the service advertises attribute and attribute type relationships within
Austrian Air flight tickets within Austria. The ticket concepts.
departure and destination facts are unified in the goal
and the web service, with the consequence that X o Web services are converted to DNF with the
becomes Wien and Y becomes Graz. After that, internal steps of:
whether X and Y are in Austria can be decided. The o Replacing logical constructs such as
last two facts have no correspondence on the other implication or equivalence with an equivalent
side, therefore they cannot generate any contradiction, form using only conjunction, disjunction and
and they can be silently ignored. negation,
In order to reach a comparable list of terms some
kind of normalized form is needed, of which the o Conversion into Negation Normal Form
Disjunctive Normal Form (DNF) was the most (NNF),
suitable, as it represents the set of simple capabilities
o Elimination of forall and exists constructs,
(desires or effects). The DNF consists of clause sets in
skolemization,
the form of (C11 and C12 and … ) or… (Cm1 and Cm2
and …), where Cij are atomic terms. We call Cij a
o Moving disjunctions to the outermost level to The pseudo-code shows a simplified version of this
reach DNF. matching algorithm:
• DNF clause sets are converted to Prolog. % both inputs are lists of clauses
Membership molecules of WSML are converted match(Goal, Webservice) :-
to type/2 predicates and hasValue molecules are % perform possible unifications
represented with attr/3 predicates. unify(Goal, Webservice, UnifiedClauses),
% classify each clause/term in goal as
An example of generated Prolog clauses is given for a % matched/failed/ignored
service providing flights from Innsbruck to Wien: checkClauses(Goal, UnifiedClauses,
MatchedInGoal, IgnoredInGoal,
type(V_FlightPrefs, FailedInGoal),
flightBookingPreferences), % classify each clause in service as
attr(V_FlightPrefs, start, V_Start), % matched/failed/ignored
=(V_Start, innsbruckAirport), checkClauses(Webservice, UnifiedClauses,
attr(V_FlightPrefs, end, V_End) MatchedInService, IgnoredInService,
=(V_End, wienAirport), FailedInService),
attr(V_FlightPrefs, class, V_Class), % decide on matching
type(V_Buyer, buyer), isMatching(MatchedInGoal, IgnoredInGoal,
attr(V_Buyer, contactInformation, FailedInGoal),
V_BuyerContact), isMatching(MatchedInService,
attr(V_BuyerContact, emailaddress, IgnoredInService, FailedInService).
V_BuyerEmail),
type(V_BuyerEmail, string) unify([G|Goal],Webservice,M2) :-
(if member(G, Webservice) then
When the system is initialized, the following steps M2=[G|M1] else M2=M1),
are needed for discovery with a given goal: unify(Goal,Webservice,M1).
• The goal is converted first to DNF and then to unify([],_,[]).
Prolog the same way as web services, the result is
checkClauses([Clause|ClauseSet],
a Prolog list of clause sets for each condition in
UnifiedClauses,
the goal capability, Matched2, Ignored2, Failed2) :-
• The matching algorithm is run: an attempt is check(Clause, UnifiedClauses, Status),
(if Status=m then
made to match each web service with the goal,
Matched2=[Clause|Matched2] else
• The result is a list of matching services which is Matched2=Matched1),
ranked before it is sent to the user. (if Status=i then
Ignored2=[Clause|Ignored2] else
As part of the matching algorithm, in order to match Ignored2=Ignored1),
the postconditions of the web service and the goal we (if Status=f then
need to find a matching between the DNF clause sets Failed2=[Clause|Failed2] else
Failed2=Failed1),
representing postconditions. The steps to be performed
checkClauses(ClauseSet, UnifiedClauses,
for each pair of clause sets (one from the goal and one Matched1, Ignored1, Failed1).
from the web service) are:
checkClauses([],_,[],[],[]).
• Unification of clauses in the clause sets: two
clauses are unified if they have the same The detailed explanation of the algorithm is given
signature, then corresponding variables in the two below. First, all possible unifications are made by the
clauses are unified, unify predicate. Second, the algorithm has to examine
• Labelling each clause: matched, failed or ignored, all clauses in the clause set with the effects of
unifications made. If the clause yields true value after
• Decision of match or failure, the unification, it is labelled as matched. If the clause is
• Generation of matching result (with lists of failed, not true, but all its variables are bound, it is labelled as
ignored and matched facts attached). failed. False clauses with free variables mean that the
condition they represent is not specified in the other
clause set, therefore they are labelled as ignored.
Finally, the algorithm has to decide whether the
goal and the web service match each other. If there is a
failed clause, it means a disagreement of the goal and matched in the goal, and therefore the service gets a
service, so there is no match. If there are only matched higher position in the ranked result list.
and ignored clauses, then a little heuristics is needed to The presented algorithm can thus handle user
decide about the match. As a primary rough heuristics preferences and provide a ranking based on it, if there
we say there is a match if the number of matched is a way to differentiate between clauses modelling
clauses is greater than the number of ignored clauses. core postcondition and clauses modelling user
In fact this is a problem of WSML capabilities: it is preferences in the goal. Currently, we see the only
very hard to tell which variables represent essential, solution to use axioms completely separated from the
basic service issues and which variables are just to help goal to express user preferences.
describe conditions. Figure 1 shows two facts at the For matching preconditions and assumptions we can
bottom which can be safely ignored. It can also happen use a simpler matching mechanism as expressions have
that the service and the goal are totally different except to be fully enforced there: a clause is either matched or
they share the conditions of payment or confirmation failed. Facts from the goal are inserted into the
(for example). In this case the matching result will not knowledge base, and the clause sets (in DNF) of the
contain failed facts, just a lot of ignored clauses (the service precondition and assumption are checked one-
essential service requested) and a lot of matched by-one. In this way not only the failure is detected but
clauses (the not so important buying conditions). If also the failing clauses can be identified and presented
there are no failed facts, the decision of matching to the user.
cannot be completely sure. Conventions are suggested
to by-pass this shortcoming. One such agreement can 3.2. Implementation and Performance
be to define a basic service outcome or service class in
each postcondition or effect. The matching algorithm was implemented in
The list of matching services should be ranked to Prolog, and was tested with SWI-Prolog. The
provide guidance for the user in selection. The usual discovery engine is written in Java, which initializes
solution is to rank the list by some kind of quality the Prolog implementation, and feeds the WSML
aspect or by the categories of exact, subsume, plugin descriptions for ontologies and web services into it.
and intersection match. The algorithm introduced here Then, for each discovery request only the goal is
provides the new possibility of ranking based on the converted into Prolog and the matching algorithm is
number of ignored clauses. Clauses can be ignored on run.
both the service and the goal side. Clauses ignored on Further software components used in the
the goal side means certain conditions are not defined implementation are wsmo4j for parsing WSML files
in the service (e.g. departure date, comfort seats), so a and Interprolog for making Prolog queries from Java.
lower number of ignored facts mean more precise The matching algorithm has the following costs for
fulfilment of user desires. Clauses ignored on the each step (where goal has L clauses and service has M
service side means something additional which is not clauses):
specified in the goal (e.g. more travel information,
company data, etc.). • Unification of clauses: at most L*M operations,
The judgement of these is highly subjective, but a • Checking each clause: L+M operations,
lower number of ignored facts may also mean a more
accurate match here. In our implementation we rank by • Decision of match or failure: constant number of
the sum of ignored facts in both service and goal. operations.
Another possible approach is to rank first by the So the matching of one goal clause set with one
number of ignored facts in the goal, and then by the service clause set takes approximately (L+1)*(M+1)
number of ignored facts in the service. operations. If we take the natural assumption that the
Modelling user preferences and added value in number of clauses has an upper limit m in the system
discovery is an emerging new problem in this area. The (an upper limit for L and M), and the maximal number
presented matching algorithm can handle the added of clause sets representing a service or a goal has an
value in requests and offers as demonstrated in the upper limit c, we get the estimation that the order of
following example. The goal postcondition declares complexity of the discovery algorithm is linear with
that the flight is business class. If the service says respect to the number of services in the system.
nothing about the class, then this requirement is The performance tests were based on the project use
ignored by the matching algorithm. If the service offers case; a frequent flyer system offering bonus flights,
only economy class, then the matching fails. If the hotel stays and car rentals. The test environment
service declares that it can provide both economy and contained 18 ontologies, 25 different web services and
business class tickets, then the corresponding fact is
10 different goals. In order to get more services for the The test bed is available as an online service of
tests, multiple copies were generated from each SZTAKI, it can be reached from the demonstrations
service. page of the INFRAWEBS project website:
The Prolog matcher on a 1.6 GHz P4 desktop PC http://www.infrawebs.eu.
provided the following response times:
250 services: 1.82s (.00728s/ws) Related work
1000 services: 7.47s (.00747s/ws)
4000 services: 32.94s (.00823s/ws) The early experiments to implement matching
8000 services: 65.63s (.00820s/ws) algorithms with Logic Programming are mostly done
using Flora-2, a reasoner supporting F-logic
In the first experiment the number of services was [19][20][21]. The syntax of the Flora-2 language is
25, and the per service discovery time (the total time very close to WSML, which alleviates language
needed for discovery measured in the Java VM divided conversion.
by the number of services checked for matching) In [19] and [20] the matching is based on the
varied between 12 and 103 milliseconds, depending on discovery model in Transaction Logic [11]. After
the complexity of the goal capability. In our next precondition matching, the service postcondition is
experiment the number of web services was increased assumed to be true (inserted into the knowledge base),
to 250 in the same environment. The per service and the fulfilment of goal postcondition is checked.
discovery time in the second experiment varied Finally, the inserted facts are retracted from the
between 12 and 129 milliseconds. knowledge base, and the matching of next service can
Overall, the response time perceived by the user is be started. The matching is done in the traditional way,
between 3 and 25 seconds. This is acceptable for the checking the truth value of the goal postcondition. This
project as the pre-filtering step is assumed to reduce leads us to the matching problem detailed in section 3,
the number of services in this second step of discovery namely, the postcondition of a matching service does
to the magnitude of 2-300 services. not imply the goal postcondition. This solution works
The following conclusions can be drawn from the if goals are prepared by parameterizing goal templates,
response times: but it does not support custom goals and the discovery
• The native Prolog implementation needs only a functionality needed for service composition.
couple of milliseconds to match a web service There are several proof-of-concept experiments for
and a goal. This is scalable until the magnitude of SWS discovery using WSMO, but relatively few
1000 services (result within 5 seconds), which is complete implementations. Della Valle et al. have
satisfying if we consider the pre-filtering step as created a complete discovery solution based on
well. mediators [21]. It is used in Glue, a lightweight
implementation of their suggested execution
• There is a bottleneck in the communication framework for Semantic Web Services. Glue uses pre-
between Java and Prolog. We will experiment defined goals (goal templates), which can be
with other possible communication methods. parameterized by the user for her actual request. A
wgMediator [14] is used to find matching web services
• Little effort was spent on code optimization, and for a specific goal. Therefore, the (simplified) steps of
we think the speed of discovery can still be discovery are:
increased.
• Parameterize a pre-defined goal,
Currently there is little information available about
• Find the wgMediator for that pre-defined goal,
the performance of other discovery implementations.
We think the proposed and implemented solution is • The wgMediator returns matching services for the
comparable in effectiveness and correctness to the few goal.
other approaches. The solution can be used generally, The advantages of this approach are:
and it is also able to provide some explanation of the
match or failure, which can be presented to the user. • Efficient solution which is also easy to
In order to provide an interface for testing and implement,
experimenting, a web-based test bed has been • Straightforward support for mediation between
implemented for the discovery component. This test heterogeneous ontologies using ooMediators and
bed includes not only the software but example data as ggMediators.
well.
The disadvantages of this approach are: INFRAWEBS project: logic-based matching is
expensive, and it is needless to run the expensive
• Goals can only be created based on pre-defined algorithms on services which have no chance to match
goals. If the user’s desire does not match any of with the goal. The concepts are classified into concept
the pre-defined goals, she has no choice to find groups, and services and goals are associated with
matching services, concept groups based on concepts mentioned in the
• The maintenance of pre-defined goals needs capability. Keys are calculated for both services and
continuous effort from the operators of the goals which summarize the concept groups used in the
discovery engine. If composite goals are capability descriptions.
supported, the number of pre-defined composite According to the authors the necessary condition for
goals to be created and maintained may reach a a service to match with a goal is that its description at
huge number. least must contain all concepts related to those
OWL-S is probably the most known approach specified in the goal. We saw in the previous sections
currently for Semantic Web Services. In OWL-S a that this assumption for matching is not necessarily
service can be specified with inputs and outputs, but true. For example, a goal may contain date constraints
also with pre- and postconditions. The typical while services usually say nothing about dates. The
discovery solutions using OWL-S [22][23] match the creators of the system admit that for partial
user’s input with the service input and the service matchmaking some concepts has to be discarded from
output with the user’s desired outcome. This means the goal in the filtering phase, and GUI tools would
that all concepts required by the service as input need help users in doing this. As a comparison of this
to match with a concept provided as user input, and all approach and INFRAWEBS discovery we outline the
concepts required by the user as output match with a following:
concept in the service output. The schematic process of • Both projects use a filtering phase before the
such discovery contains the following steps: logic-based matching, but the filtering rules used
• Locate services with matching input and output in INFRAWEBS are less restrictive.
o For each input concept of the service, find a • QoS data is used to define criteria for matching in
matching input concept provided by the user this work, while INFRAWEBS uses QoS data for
o For each output concept required by the user, ranking the list of matching services.
find a matching output concept of the service
The advantages of this approach are:
Conclusion
• Simple matching algorithm, required reasoning is In this paper we have presented the implementation
minimal of the Discovery Component of the SWS environment
• Fast implementations are possible using indexed created by the INFRAWEBS project.
search The matching algorithm selected for discovery
combines a traditional IR-based pre-filtering step and a
The disadvantage of this approach is that matching logic-based matching implemented in Prolog. The
is based solely on inputs and outputs, and the effects of logic-based step of discovery uses a novel technique
service execution are ignored, so there is no guarantee based on Prolog-style unification of terms. This
that the matching service has the desired effect. (As an approach is able to find intersection and other types of
example: a service with an input of type document and service matches, and also provides possibilities to
an output of type document might perform rather compare, rank and explain service matches (or non-
different tasks on the document.) matches). The performance of the solution is
In [24] a peer-to-peer environment is described for satisfactory within the project scenario. In the lack of
WSMO-based semantic discovery. The system performance details of other solutions it is hard to
(supported by the DIP project) contains several compare the presented implementation with other
novelties, such as decentralized discovery and QoS- discovery engines.
based matching. Here we concentrate on the method of A test bed is available online for the demonstration
discovery. The paper provides minimal information of the approach. It can be reached from the
about the logic-based matching applied in the system. demonstrations page of the INFRAWEBS project
Logic-based matching is preceded by a filtering step, website.
when irrelevant services are filtered out, and the logic-
based matching is only applied on a small set of
services. The rationale is similar to that of the
Acknowledgement The presented work was supported [15] Web Service Modeling Ontology Primer. W3C Member
by the INFRAWEBS project funded by the European Submission 3 June 2005,
Commission. http://www.w3.org/Submission/WSMO-primer/
[16] WSMX Deliverable D10 v0.2, Semantic Web Service
Discovery. WSMX Working Draft October 3, 2005
References [17] D3.3 v0.1 WSMO Use Case "Virtual Travel Agency".
WSMO Working Draft 19 November 2004,
[1] Alejandro López, Jesús Gorroñogoitia. Deliverable http://www.wsmo.org/2004/d3/d3.3/v0.1/
D11.1.2 INFRAWEBS Software Development Process. [18] Lei Li and Ian Horrocks. A software framework for
[2] Alejandro López, Jesús Gorroñogoitia. DS2 Activity matchmaking based on semantic web technology. In
definition. INFRAWEBS Document. Proceedings of the 12th International Conference on the
[3] Alejandro López. DD2 Component interface description. World Wide Web, Budapest, Hungary, May 2003.
INFRAWEBS Document. [19] Michael Kifer, Ruben Lara, Axel Polleres, Chang Zhao,
[4] Chris Preist. A conceptual architecture for semantic web Uwe Keller, Holger Lausen and Dieter Fensel. A Logical
services. In Proceedings of the International Semantic Web Framework for Web Service Discovery. Proceedings of the
Conference 2004 (ISWC 2004), November 2004. ISWC 2004 Workshop on Semantic Web Services: Preparing
[5] Web Services Glossary. W3C Working Group Note 11 to Meet the World of Business Applications, Hiroshima,
February 2004. http://www.w3.org/TR/2004/NOTE-ws- Japan, November 8, 2004. CEUR Workshop Proceedings,
gloss-20040211/ ISSN 1613-0073, Vol-119.
[6] O. López, E. Riceputi, A. López, C. Pezuela, Y. [20] WSML Deliverable D5.1 v0.1 Inferencing Support for
Gorroñogoitia. INFRAWEBS Deliverable 10.1-2-3-4.1 Semantic Web Services: Proof Obligations. WSML Working
Requirement Profile 1 & Knowledge Objects. 2005 Nov 10. Draft – August 2, 2004
[7] Ettore Riceputi. Deliverable D10.5-6-7.2 Requirement [21] Emanuele Della Valle, Dario Cerizza, Irene Celino. The
Profile 2 & Knowledge Objects mediators centric approach to Automatic Web Service
[8] J. Scicluna, T. Haselwanter, A. Polleres. INFRAWEBS Discovery of Glue. First International Workshop on
Deliverable D7.1-2.1 Reduced Rule Base, QoS Metrics, Mediation in Semantic Web Services: MEDIATE 2005,
Running SWS-E and QoSBroker. 2005 Aug 15 Amsterdam, Netherlands, December 12 2005
[9] Cs. Fülöp, L. Kovács, A. Micsik, Z. Tóth, G. Agre, A. [22] Massimo Paolucci, Takahiro Kawamura, Terry R.
Polleres. INFRAWEBS Deliverable D6.1-2.1: Specification Payne, Katia Sycara. Semantic Matching of Web Services
& Realisation User-Interface Agent, Discovery Agent. Nov Capabilities. International Semantic Web Conference 2002.
2005. In: Lecture Notes in Computer Science, Volume 2342, Jan
[10] A. Micsik, L. Kovács, Z. Tóth, P. Pallinger, J. Scicluna. 2002, Page 333
INFRAWEBS Deliverable D6.2.2 – Specification & [23] Michael C. Jaeger, Gregor Rojec-Goldmann, Gero
Realisation of the Discovery Component. Aug 2006. Mühl, Christoph Liebetruth, Kurt Geihs. Ranked Matching
[11] D5.1v0.1 WSMO Web Service Discovery. WSML for Service Descriptions using OWL-S. In Kommunikation
Working Draft 12 11 2004, in verteilten Systemen (KiVS 2005), Informatik Aktuell,
http://www.wsmo.org/2004/d5/d5.1/v0.1/20041112/ Kaiserslautern, Germany, February 2005. Springer.
[12] Ruben Lara: KnowledgeWeb Deliverable 2.4.2 [24] Le-Hung Vu, Manfred Hauswirth, Fabio Porto, Karl
Semantics for Web Service Discovery and Composition. Aberer. A Search Engine for QoS-enabled Discovery of
[13] A.J. Bonner and M. Kifer. A logic for programming Semantic Web Services. International Journal of Business
database transactions. In J. Chomicki and G. Saake, editors, Process Integration and Management, 2006, to be published.
Logics for Databases and Information Systems, chapter 5,
pages 117-166. Kluwer Academic Publishers, March 1998.
[14] D16.1v0.3 The Web Service Modeling Language
WSML. WSML Working Draft 5 October 2005,
http://www.wsmo.org/TR/d16/d16.1/