Combining Pragmatics and Intelligence in Semantic Web Service

Combining Pragmatics and Intelligence in Semantic Web Service Discovery Electra Tamani and Paraskevas Evripidou Department of Computer Science, University of Cyprus 5 Kallipoleos St., T.K. 537, 1678 Nicosia, Cyprus {electrat,skevos}@cs.ucy.ac.cy

Abstract. In this paper we present an architecture that augments existing semantic-based web service discovery solutions. The idea is to combine principles from the semantic and pragmatic web in order for the web service selection process to become more efficient and effective. We utilize offer and request xml files to describe the functional properties (inputs/outputs) and context parameters of web services. Our approach distinguishes from others in that it 1) applies to any semantic web service language and 2) provides the means for web service providers and requestors to make ontological commitments and establish common understanding in an intelligent way.

1 Introduction The goal of the Semantic Web is to develop the basis for intelligent applications that enable more efficient information use by not just providing a set of linked documents but a collection of knowledge repositories with meaningful content and additional logic structure [SdMD06]. The main components for implementing the Semantic Web are ontologies. Ontologies however, as pragmatic web researchers argue, should not be exploited as fixed conceptualizations of some domains, as they are, but rather as dynamic structures which co-evolve with their communities of use. Members of a community have to communicate and continuously negotiate on their shared background/context. To do so, they need to understand each other especially when they 1) come from different professional, social, or cultural backgrounds and 2) use different terminology from other organizations/entities. Web services is one widely used standard which has been established as the de facto for interoperability. The last years, the Semantic Web researchers proposed semantic enhancements to web services descriptions in order to facilitate more efficient discovery and composition in intelligent systems. Services should not be described independently of how they are used, because communities of practise use services in novel, unexpected ways [Mo05, Si02]. Semantic web services should not assume context-independent annotations. For these reasons service-oriented systems require social mechanisms that consider the contexts and interactions. In this paper, we recognize these limitations and propose an architecture which augments existing semantic-based web service discovery techniques by combining pragmatic and semantic web principles. Our approach aims to make the web service R. Meersman, Z. Tari, P. Herrero et al. (Eds.): OTM 2007 Ws, Part II, LNCS 4806, pp. 824–833, 2007. c Springer-Verlag Berlin Heidelberg 2007 

Combining Pragmatics and Intelligence in Semantic Web Service Discovery

825

selection process even more efficient and effective. We capture personal, functional and contextual information of the providers/requestors [TE06] in offer/request profile repositories, perform the matching between the various offer/request parts and produce ontologies with the ontological commitments made by the agents of both parties (provider and requestor). The rest of the paper is organized as follows: Section 2 describes how the web service discovery can be improved, thus making the process more effective and efficient, and presents an example. Section 3 introduces the patterns of pragmatic web and operationalizes these patterns for the web service discovery scenario. Section 4 presents the proposed architecture that matches requests against offers, generates a matching degree based on which the selection is made and produces an ontology describing the common (agreed-upon) concepts between providers and requestors. Section 5 introduces related work. Finally, we conclude in Section 6.

2 Improving Web Service Discovery Web Service discovery is of paramount importance for Service Oriented Systems. Consequently, if the services identified are not the most appropriate then neither the requestor will be satisfied nor the intelligent agents could be able to construct meaningful real life processes (workflows of web services). For these reasons it is essential that the discovery phase should be as effective as possible and meet the expectations of humans. Semantic Web researchers proposed enhancements, through ontologies usage1 , to web services’ definitions to enable some form of automation of the services in the semantic web. To this extend, they base the “matching” on various meaning resolution techniques. Particularly, the OWL-S (Ontology Web Language for Services) Matchmaker utilizes an algorithm for finding the best match between two descriptions (offer and request) and identifying the different relations (matching degree) (exact-match, subsumes-match, plug-in-match and fail-match) [PKP02, PSS04]. The WSDL-S (Web Service Semantics) Matcher is a combination of two types of matching algorithms (element level and schema) which complement one another in order to find all possible mappings between WSDL and ontology concepts [SVM05]. The WSMO (Web Service Modeling Ontology) Matcher offers almost the same type of matching (exact-match, subsumes-match, plug-in-match, intersection and non-match) with OWLS Matchmaker but distinguishes itself in the fact that it separates a web service from a service [D.04]. Finally, other matchmaking techniques utilize algorithms that compare stateless web services (those that do not alter the state of world and thus do not require pre- and post- conditions processing) with different intentions [HZB06]. Although the semantic solutions allowed some form of automation, still the matching can greatly be improved. The most cumbersome assumption lies in the fact that web services’ annotations (ontological references) are context-independent. However context should not be neglected especially in such highly intelligent environments as those involved with web services and agents (s/w applications) of humans coming from different professional/social/cultural backgrounds or utilizing different terminology. The 1

Knowledge repositories of meaningful and structured content.

E. Tamani and P. Evripidou owl:Thing AccommodationPrefType AccommodationAmenityPrefType AccommodationClassPrefType AccomodationClassPref < 1 [Condominium, Guest house, Health spa, Holiday resort, Hostel, Hotel, Motel, Ranch, Cottage] RecreationSrvcPrefType

owl:Thing HotelPrefType RecreationSrvcPrefType PropertyClassPrefType PropertyClassPref < 1 [Guest house, Health spa, Holiday resort, Hotel, Villa, Ski, Castle] A A

826

A A

A

Fig. 1. Domain-specific Ontologies

matchmaking technique should therefore additionally consider the context. Augmenting the matcher functionality to check for context dependencies is a step towards a more effective and efficient web service discovery. The following example demonstrates the need for context-dependent annotations. For the sake of this example, let us assume that the agents represent humans (the provider and the requestor in this case) coming from different cultural backgrounds and the web service (being offered and requested) returns a hotel list given some hotel search criteria. Figure 1 shows the ontologies utilized by the provider (ontology on the left) and the requestor (ontology on the right) to annotate their web services. The classes HotelPrefType and AccomodationPrefType take all values from classes RecreationSrvcPrefType PropertyClassType and AccomodationClassPrefType AccomodationAmenityPrefType RecreationSrvcPrefType respectively on some properties. In the case of PropertyClassPref it can take any one value from the list [Guest house, Health spa, Holiday resort, Hotel, Villa, Ski, Castle] and in the case of AccomodationClassPref any one from [Condominium, Guest house, Health spa, Holiday resort, Hostel,Hotel, Motel, Ranch, Cottage]. Since each party used his own domain specific context-dependent ontology to annotate the web service, the traditional plug-in, subsume and exact matches between the request and the offer are not enough. A context-depended ontology is the one that is defined and/or altered according always to the context of web service usage. If for example the provider decides to add another subclass to the AccomodationPrefType class in order for his ontology to become more accurate and his web service input annotation more meaningful, still the traditional matchers would have just checked the schema of the two ontologies to decide the type of match. The addition of the new subclass may correctly make sense for the provider but the requestor may have his own perception of the concept which does not agree with such modification. Thus both the provider and the requestor must share common understanding and mutually agree in any modifications made to the context-specific ontologies.

3 The Patterns of Pragmatic Web The Pragmatic Web can greatly assist in augmenting the web discovery because it is more or less a set of pragmatic contexts about the semantic resources. To model these contexts and operationalize the vision of Pragmatic Web, scientists have introduced some core pragmatic patterns [Mo05]. These pragmatic patterns model the context of interest to the community as a whole, the context of the individual members of the

Combining Pragmatics and Intelligence in Semantic Web Service Discovery

827

community and the common context established during a negotiation process. In the following section we revisit the example introduced previously and adopt the pragmatic patterns in order to: 1) show how these can help adequately capture the contextual information of the parties and their actions in a web service discovery scenario and 2) resolve possible meaning conflicts during the matching process (assume an intelligent agent environment). 3.1 Operationalize the Pragmatic Patterns for the Web Service Discovery Scenario In order to operationalize our scenario we choose to use xml and xpath queries due to their wide acceptability and versatility. The pragmatic patterns, as being adjusted to our scenario, are the following: – Pragmatic context: a pattern that captures the individual members, namely the providers and the requestors2, of the web service discovery community. The pattern also contains identifiers to the individual and common contexts of the community. – Individual context: a pattern that defines an individual community member, individual context parameters and identifiers to the individual context ontology. The individual context ontology in our case is captured in offer and request xml files (extensive analysis can be found in [TE06, TE07]) as follows:

– Common context: a pattern that defines the common context parameters and an identifier to the common context ontology of a community (to be generated dynamically). – Individual pragmatic pattern: a meaning pattern relevant to individual community member. These patterns in our case are expressed as xpath queries. – Common pragmatic pattern: a meaning pattern relevant to the community as a whole. The common context ontology contains all common pragmatic patterns (to be generated dynamically). 2

The terms provider and requestor refer to intelligent applications acting on behalf of provider and the requestor respectively.

828

E. Tamani and P. Evripidou

T

Context_Par

Comm_Role requestor provider

purpose

goal

“why”

“who” Concept

Comm_Proc

output input ws_for_use

request

offer

| * * |

“request”| “offer”

“what”

Fig. 2. The Web Service Discovery Context Ontology

T

T

Offer Provider Concept input name annotation

goal purpose

Request Requestor Concept

output name annotation

HotelPrefType HotelList HotelSearchCriteria

……….

//what/input/@name = HotelSearchCriteria //what/input/@annotation = HotelPrefType

goal purpose output

input name

name annotation annotation ………. AccommodationPrefType

HotelSearchInfomation

HotelCatalogue

//what/input/@name = HotelSearchInfomation //what/input/@annotation = AccommodationPrefType

Fig. 3. The Offer and Request Context Ontologies

As you can see in Figure 2 the context ontology of the web service discovery community, consists of the concept web service (WS). Two important properties of this concept are the input and output parameters. These parameters specify what the service does i.e what it outputs given a certain input. The two communication roles (Comm Role) encountered in a web service discovery are the provider and the requestor. The community distinguishes two types of communication processes (Comm Proc): the offer of a web service, initiated by the provider and the request for a web service, initiated by the requestor. The context parameters (Context Par) considered in the community, although other parameters can be included in the future (i.e temporal), are the purpose and the goal. The purpose indicates the reason this web service is being offered/requested and the goal indicates the targeted goal for its provision/offering. The provider X and the requestor Y defined their individual context (ontologies) to contain among the others the input/output parameters of the web services being offered/requested respectively. These ontologies, which are shown in Figure 3, present in a greater detail the “what” part of the offer/request xml files. The individual pragmatic patterns that allow us to retrieve the input parameters of the “what” part from an offer/request file correspond to the xpath queries shown below each ontology (the same applies for the output parameters).

Combining Pragmatics and Intelligence in Semantic Web Service Discovery

829

Let us now present the architecture we propose to cope with the matching of offers and requests during the web service discovery.

4 Matching: The Architecture The idea behind the architecture we propose is to allow providers/requestors define their offers/requests asynchronously and intelligently select/return the offer which is the most appropriate for each request. At first, the provider and the requestor specify asynchronously their context information (who, why, what parameters) in a user-friendly web-enabled application (not focus of this paper). The system converts this information, in a completely transparent way, into the xml structure presented in Section 3 and stores it in the server of the requestor or the provider depending on the type of the xml (request/offer). Subsequently the matchers retrieve the requests and the offers and compare them against each other until the most appropriate offer is found for each request. A key feature of the matchers is that they can traverse any xml/rdf-based ontology (owl, daml etc). The components of proposed architecture, as depicted in Figure 4, are in short the following: 1) The Central Manager (CenMan) is a centralized component responsible for the dispatching of requests to the distributed components and the coordination of the distributed components’ activities. The CenMan utilizes a request profile, a profile manager and common profile repositories and 2) The Profile Manager (ProfMan) is a distributed component responsible for carrying out the matching between the offers and the requests for web services. It can be considered as the agent of the provider. The ProfMan consists of the What Matcher and the Why Matcher and utilizes an offer profile repository and trusted ontologies (i.e WordNet, OTA) to carry out its tasks. In the following sections the various components are analyzed in detail. 4.1 Central Manager The Central Manager is the core component of the architecture. It is responsible for the transparent coordination of the various components. In general the Central Manager’s

Off Prof Off Rep Prof Off Rep Prof Rep

Central Manager

Trusted Ontologies Trusted Ontologies Trusted

Ontologies What Why Matcher Matcher What Why MatcherProfMan Matcher What Why

Req Prof Rep

Com Prof Rep

MatcherProfMan Matcher

Tomcat Server 4.1.+

ProfMan Tomcat Server 4.1.+ Tomcat Server 4.1.+

Fig. 4. The proposed architecture

Prof Man Rep

830

E. Tamani and P. Evripidou

methodology is to retrieve the request from the Request Profile Repository (ReqProfRep) as well as the registered P rof M ans (providers) from the Profile Manager Repository (ProfManRep), and in a threaded fashion forward to each ProfMan the “what” and “why” parts of the request. Subsequently it will wait for the result from each ProfMan and upon receipt of all results (from all P rof M ans ) it will select the offer which successfully established common context and has the highest context similarity value. Request Profile Repository: The Request Profile Repository (ReqProfRep) is a repository where all request xml files are stored. (contains the identifiers to the Individual Context Ontologies of the requestors). Common Profile Repository: The Common Profile Repository (ComProfRep) is a repository where all the request and offer xml files that shared common context are stored(Common Context Ontology of the community as a whole). Profile Manager Repository: The Profile Manager Repository (ProfManRep) is the repository where the information for each registered ProfMan component are kept (URL address, registration date etc). 4.2 Profile Manager The Profile Manager (ProfMan) is a distributed agent component that executes on the machine of each provider. It the most important part of the architecture because it carries out all the matching between the offers and requests and subsequently hands out the results to the Central Manager. The reasons we have considered a distributed solution for the matching are 1) it is less costly than centralized approaches since the machine resources utilized are minimal and 2) the Central Manager is freed from carrying out messy time-consuming matching tasks and therefore focused in its coordination activities. In order to carry out its activities the ProfMan invokes the Why Matcher and the What Matcher. The What Matcher is responsible to apply a combination of language processing techniques and pragmatic principles between the “what” parts of an offer and a request. The Why Matcher is responsible to apply semantic/language processing techniques to resolve any meaning conflicts between the “why” parts of an offer and a request. These processing techniques are synonym matching [Mi90], NGram [AFW83], and order/frequency of sentence words [BM03]. After each ProfMan receives the “what” and “why” request parts from the Central Manager, it retrieves all offers from OffProRep and for each offer it handles: 1) the “what” part of that offer and the request to the WhatMatcher and 2) the “why” part of that offer and the request to the WhyMatcher. Then it waits for the responses from both matchers and upon receipt it adds them to a list. Then it checks that list and finds/selects the offer with the highest context similarity value which has established common context with the request. WhyMatcher’s methodology is to first apply some preprocessing techniques on the “why” part of the offer and the request before it attempts to match them. This preprocessing involves tokenizing the “why” parts based on punctuation and capitalization,

Combining Pragmatics and Intelligence in Semantic Web Service Discovery

{ { Ø

if result(WhatMatcher) = ø

result(WhyMatcher)

otherwise

831

matching_degree

if (alg1 V alg2 V alg3) = 1 1 if (alg1 = alg2 = alg3) = ø result(WhyMatcher) Ø avg(alg1,alg2,alg3) if 0 < (alg1 V alg2 V alg3) < 1 where alg1 = Ngram, alg2 = Synonym Matching, alg3 = Position Checking

Fig. 5. Formula for the calculating matching degree

converting everything to lowercase and removing unnecessary words (i.e the, of etc). If after the preprocessing the matching was unsuccessful, it stems the tokens using porter stemmer algorithm and tries to match them using NGram technique [AFW83]. Also it checks for synonymity of tokens by referencing WordNet [Mi90]. Moreover it applies some order/frequency algorithms that check the position of the tokens in the overall “why” parts of the request/offer [BM03]. The result of the WhyMatcher algorithm, which ranges from 0 to 1, will be the average of the three techniques. WhatMatcher’s role on the input/output parameters of the “what” parts between an offer and a request is dual. At first it performs similarity checks on the name of an input/output and at second it applies the pragmatic principles on the annotation part of an input/output. The similarity checks applied on the name part are the same as the synonymity checking applied by the WhyMatcher. The synonymity checks reference trusted ontologies as OTA and WordNet (explained below) to resolve meaning ambiguities and establish common context. The checks performed on the annotation part are a mixture of the synonymity checking mentioned above and the schema comparison of the ontology part/class involved with the annotation (including their subclasses, restrictions etc). If the schema comparison does not produce an exact match (even after meaning resolution occurred) i.e the request parameter (input or output) is a subClassOf of the offer parameter (subsume match) or the opposite (plug-in match), then extra measures must be taken. In either case the provider and the requestor, especially when social/professional/cultural backgrounds apply, must agree on common context: the ontologies they reference must be understandable by both. Therefore the agents of both parties must apply the pragmatics patterns, discussed earlier, to establish common context. If a concept exists in one ontology but not in the other one, the WhatMatcher has to reference OTA (trustful for both parties) to examine whether the concept exists there. If it does then the concept/common pragmatic pattern is saved in the common context ontology. If it does not, then the parties are said not to share common context so nothing is added in the common context ontology. If a common context have been established for all ontology concepts identified with subsume or plug-in match, then both parties are said to commit on the common context ontology derived. If common context on the “what” part of a request and an offer is established, the matching degree equals that of the “why” part or ∅ otherwise. The Figure 5 summarizes the formulas used for calculating the matching degree. Offer Profile Repository: The Offer Profile Repository (OffProfRep) is a repository where all offer xml files are stored (contains the identifiers to the Individual Context Ontologies of the providers).

832

E. Tamani and P. Evripidou

Trusted Ontologies: The Open Travel Alliance (OTA) (www.opentravel.org) and the WordNet (http://wordnet.princeton.edu/) are two widely used ontologies in our framework. The OTA ontology is well accepted ontology in the travel industry which helps business sectors to build common understanding (exchange, share, use information) in the area of travel. WordNet, is also a widely accepted lexical database (dictionary) which organizes words into sets of cognitive synonyms (synsets) and thus makes it easy for applications to process natural language.

5 Related Work The idea of this paper is inspired from Pragmatic Web principles as these have been defined in [Mo05, SdMD06]. The Pragmatic Web is a new research direction which aims to extend the Semantic Web by capturing the context of ontologies’ usage, from the participants’ point of view, in a given communication process. We have attempted to provide a rigorous application of pragmatic principles in the web service discovery scenario. In order to effectively discover web services we have proposed the maintenance of offer and request files. These xml files contain information regarding the functionality of the web service (i.e what the service does: input and output parameters), who is requesting/offering the service and finally why this service is being offered/requested in the first place. The structure of the xml files posses a lot of similarities with the profile schema file proposed by OWL-S scientists [DMJ04]. Specifically, the actor details maintained in the OWL-S profile correspond to “who” part and and the service parameters (functional properties) correspond to “what” part of our methodology. The differences are 1) in our solution we additionally maintain context parameters, the why part, to capture valuable information about web services usage and 2) the xml specification we utilize is independent of the semantic web service language used underneath thus it is more expressive. The matching techniques facilitated by the “WhyMat” component in our architecture are very similar to the Element Level Schema matching techniques applied in METEOR-S [POS04]. We, as in METEOR-S, consider a combination of techniques ranging from preprocessing of texts, tokenization, and stemming algorithms to synonymity checking. However in our solution we additionally consider text position checking and utilize all the senses (synonyms usage rankings) of the texts for more accurate matching results.

6 Conclusion In this paper we have proposed an architecture which augments existing semantic-based web service discovery techniques with pragmatic web principles in order to make the selection process more efficient. As we have presented in the paper, the context of web services usage (context of ontological annotations) must be taken into consideration when we semantically match web services. To operationalize the principles of pragmatic web and tackle the problem, we have considered both the functionality/IO parameters

Combining Pragmatics and Intelligence in Semantic Web Service Discovery

833

(what part) and the context (why part) of web services offers and requests and proposed an architecture capable of performing the matching of the various request/ offer parts. The technique utilized by the WhyMatcher is based on natural language/semantic processing. However it is also possible, at this level, to restrict the matching by 1) classifying the relevance of concepts and 2) applying the pragmatics as we did with WhatMatcher to resolve any meaning conflicts. It is possible to modify/enrich the ontologies utilized for the annotation of web services using the common context ontology produced. We plan to offer this kind of extensions in our architecture in the future. The disadvantages of the approach lie on the need for 1) a centralized architecture and 2) the acceptance of providers to install software on their machines, an action that might raises security, trust and other problems. We plan to examine these issues at a later stage.

References [AFW83] [BM03]

[D.04] [DMJ04]

[HZB06] [Mi90] [Mo05]

[PKP02] [POS04]

[PSS04] [SdMD06] [Si02]

[SVM05] [TE06] [TE07]

Angell, R.C., Freund, G.E., Willett, P.: Automatic Spelling Correction Using a Trigram Similarity Measure. Inf. Process. Manage. 19(4), 255–261 (1983) De Boni, M., Manandhar, S.: The Use of Sentence Similarity as a Semantic Relevance Metric for Question Answering. In: New Directions in Question Answering, pp. 138–144 (2003) Roman, D.: WSMO: Current status and open points (November 2004) Martin, D., Burstein, M., Hobbs, J., Lassila, O., McDermott, D., McIlraith, S., Narayanan, S., Paolucci, M., Parsia, B., Payne, T., Sirin, E., Srinivasan, N., Sycara, K.: OWL-S: Semantic Markup for Web Services (November 2004) Hull, D., Zolin, E., Bovykin, A., Horrocks, I., Sattler, U., Stevens, R.: Deciding Semantic Matching of Stateless Services. In: AAAI, AAAI Press (2006) Miller, G.: WordNet: An on-line lexical database. International Journal of Lexicography Special Issue (1990) De Moor, A.: Patterns for the Pragmatic Web (invited paper). In: Sunderam, V.S., van Albada, G.D., Sloot, P.M.A., Dongarra, J.J. (eds.) ICCS 2005. LNCS, vol. 3514, pp. 1–18. Springer, Heidelberg (2005) Paolucci, M., Kawmura, T., Payne, T., Sycara, K.: Semantic Matching of Web Services Capabilities (2002) Patil, A., Oundhakar, S., Sheth, A., Verma, K.: METEOR-S Web service Annotation Framework. In: Proceedings of the 13th international conference on World Wide Web, ACM Press, New York (2004) Paolucci, M., Soundry, J., Srinivasan, N., Sycara, K.: A Broker for OWL-S Web Services. In: AAAI Symbosium (2004) Schoop, M., de Moor, A., Dietz, J.L.G.: The pragmatic web: a manifesto. Commun. ACM 49(5), 75–76 (2006) Singh, M.P.: The Pragmatic Web: Pleliminary thoughts. In: NSF-OntoWeb Workshop on Database and Information Systems Research for Semantic Web and Enterprises, April 2002, pp. 82–90 (2002) Sheth, A., Verma, K., Miller, J., Rajasekaran, P.: Enhancing Web Service Descriptions using WSDL-S (2005) Tamani, E., Evripidou, P.: A Pragmatic and Pervasive Methodology to Web Service Discovery. In: OTM Workshops, pp. 1285–1294 (2006) Tamani, E., Evripidou, P.: A Pragmatic Methodology to Web Service Discovery. In: ICWS, pp. 1168–1171 (2007)