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/