iSSE an intelligent engine for user oriented web service selection

Using actual web services from xMethods, we show that the iSSE Intelligent Service Selection Engine can accurately select relevant web services for different domains... SOAP Simple Obje

Acknowledgements

First of all, I feel deeply indebted to my supervisors Associate Professor Pung Hung Keng and Dr Ng See-Kiong, without whom the completion of this thesis could not have been possible I would like to take this opportunity to express my deepest appreciation and sincere gratitude to them for their inspiring guidance, advice and kindly patience

I am grateful to the team-workers in M-Comm group of NSS (Network

Systems & Services) lab for their innovative thinking and works during the project I am also grateful to Haman Lee, Zhang Zhuo and all my colleagues in the Knowledge Discovery Department of the Institute for Infocomm Research (I2R) for their valuable instruction and generous assistance, which have been a great source of help I am grateful to He Jun, Zhou Lifeng, Peng Bin and Gu Tao

in NSS lab who have been always encouraging, supporting and helping me during

my postgraduate study

I gratefully acknowledge the financial support from I2R, the Agency for Science, Technology and Research and National University of Singapore for the duration of this project Otherwise, I would not be able to undertake my further study on this project

Finally, I want to show my deep appreciation to my boy friend for his constant caring and support throughout my life There are many others who have assisted

me in various ways during this project I gratefully acknowledge their help

Table of Content

ACKNOWLEDGEMENTS I

TABLE OF CONTENT II

LIST OF TABLES V

LIST OF FIGURES VI

SUMMARY VIII

CHAPTER 1 INTRODUCTION 1

1.1 R ESEARCH P ROBLEM 1

1.2 P ROPOSED A PPROACH 4

1.3 C ONTRIBUTIONS 5

1.4 T HESIS O VERVIEW 6

CHAPTER 2 BACKGROUND AND RELATED WORK 8

2.1 W EB S ERVICE A RCHITECTURE AND S TANDARDS 9

2.1.1 Web Service Architecture 9

2.1.2 Web Service Standards 11

2.2 W EB S ERVICE S ELECTION 15

2.2.1 UDDI for Service Selection 16

2.2.2 Service Selection in B2C 17

2.3 R ELATED W ORK 18

2.3.1 Semantic Annotations to Web Service 18

2.3.2 Semantic Annotations to UDDI 23

2.3.3 Semantic Annotations to WSDL 24

2.3.4 Semantic Annotations to Ontology 26

2.4 O UR A PPROACH – A P REVIEW 28

CHAPTER 3 SERVICE SELECTION IN MOBILE COMMERCE 30

3.1 T HE M-C OMM S YSTEM 30

3.1.1 M-Comm User Scenarios 33

3.2 S ERVICE S ELECTION IN M-C OMM 34

3.2.1 Service Selection System Architecture 35

3.2.2 Discussions 38

CHAPTER 4 INTELLIGENT WEB SERVICE SELECTION ENGINE (ISSE) 40

4.1 S ERVICE D ESCRIPTION BY T EXTUAL I NFORMATION 44

4.1.1 Text-based Web Service Representation 45

4.1.2 Representing Web Services by Words 47

4.2 D OMAIN I DENTIFICATION U SING SVM 49

4.2.1 Motivation 49

4.2.2 Domain Modeling 51

4.2.3 Domain Identification 59

4.3 S ERVICE S ELECTION 62

4.3.1 Ontology Concept Annotation 62

4.3.2 Target Service Template Construction 64

4.4 C ONCLUSION 66

CHAPTER 5 EVALUATION 68

5.1 S YSTEM I MPLEMENTATION 68

5.2 D ATA 69

5.3 E VALUATION 73

5.3.1 Selection accuracy 73

5.3.2 Time latency 78

5.4 C ONCLUSION 79

CHAPTER 6 CONCLUSIONS 80

APPENDIX A: UDDI DATA STRUCTURE 83

A.1 D ATA S TRUCTURES IN UDDI 83

A.2 A N E XAMPLE 90

APPENDIX B SAMPLE OWL FOR POSTAL CODE SERVICE 92

APPENDIX C THE M-COMM SYSTEM 97

C.1 S YSTEM A RCHITECTURE 97

C.2 S YSTEM D EVELOPMENT M ODEL AND M ETHODS 99

APPENDIX D M-COMM SERVICE DISCOVERY SUB-SYSTEM DATA FLOW 103

REFERENCE 107

List of Tables

Table4.1 Presidential Election Results 2004 – Service Presentation 47

Table4.2 Two Web Service Presented in iSSE 57

Table 4.3 Sample Features in Postal Code Service 58

Table 4.4 Mapping Question Words to Noun 60

Table 5.1 System Environment 68

Table5.2 Domain Categories and number of services in each domain 70

Table 5.3 OWL design for Postal Code Service 71

Table5.4 Precision and Recall in Service Selection Process of iSSE 74

List of Figures

Fig 2.1, Service – Oriented Web Services Architecture 10

Fig2.2 Web Service Technology Stack 12

Fig3 1 M-Comm System for Shopping - General Structure 32

Fig3 2 Components of M-Comm Service Discovery Engine 36

Fig4.1 Web Service Discovery in M-Comm System 42

Fig 4.2 iSSE System Process and Components 42

Fig 4.3 Distribution of # of Words and Occurrence 58

Fig5.1 Distribution of Words and Occurrences from the Testing Data 72

Fig 5.2 Precision Comparison between iSSE and SalCentral.com 75

Fig5.3 Recall Comparison between iSSE and SalCentral.com 75

Fig A.1 Five Data Structures defined in UDDI Data Structure Specification 2.03 84

Fig A.2 BusinessEntity data Structure 84

Fig.A.3 BusinessEntity Example 85

Fig A.4 BusinessService Data Structure Specification 85

FigA.5 BusinessService Example 86

Fig A.6 BindingTemplate structure specification 87

FigA.7 BindingTemplate Example 87

Fig A.8 tModel Data Structure Specification 88

FigA.9 tModel Example 89

Fig A.10 CategoryBag Data Structure Specification 90

FigA.11 CategoryBag Example 90

FigA.12 Example of UDDI data structure 91

Figure C.1 System architecture diagram 97

Figure C.2 Technology vs System architecture 101

Figure C.3 Deployment View of M-Comm System 102

Fig D.1 Level 0: DFD Diagram for Service Discovery Sub-system 103

Fig D.2 Level 1 DFD Diagram for Service Invoking 104

Fig D.3 Level 1 DFD Diagram for Query Process 105

Summary

The World Wide Web, once just a simple repository of hyper-linked web pages, is now rapidly evolving into a provider of services Although web services were originally designed for B2B scenarios, as the popularity of the web increases, there is a growing need to adapt web services for B2C scenarios Current web service standards require the user to be conversant with the high technicalities associated with web services in order to select the relevant web services to apply However, B2C scenarios are inherently dynamic and heterogeneous—user-oriented processes are necessary in order for web services to be useful

In this thesis, we investigate the challenging problem of providing an intelligent engine for user-oriented web service selection in a B2C environment Our main contribution in this thesis is a novel light-weight semantic approach that utilizes machine learning and information retrieval techniques to identify web services that are relevant to a user’ query in free text Our approach treats web services as textual web pages from which their semantic content can be extracted using natural language text processing methods We employ a Support Vector Machine to identify the domain of the web services requested by a user’s query, and we then map the semantic content of the user’s free text query to the semantic content of the domain’s web services’ ontology concepts to select a list of relevant web services in the identified domain for the user We have implemented

our intelligent web service selection method as part of the service discovery

engine in the M-Comm system Using actual web services from xMethods, we show that the iSSE (Intelligent Service Selection Engine) can accurately select

relevant web services for different domains

Chapter 1 Introduction

To begin, we provide the motivation of our thesis work in this introductory chapter We also give an overview of our proposed approach and our research contributions in this work

The World Wide Web—once just a simple repository of hyperlinked web pages—

is now evolving into a provider of services, or more specifically, “web services”.[1] Web services are automated resources that can be accessed via the Internet—they have been hailed as the next wave of internet based applications that will dramatically change the use of internet An increasing number of web services have now been published to several service registries Web users can use these published web services to perform many everyday information retrieval tasks and access the information providers’ technology platform directly For example, we can automate our access of catalog data at the online bookstore Amazon.com, create and populate an Amazon online shopping cart (a book sale platform), and even initiate the electronic checkout process by using the web services provided by Amazon (AWS, or Amazon.com Web Service) [4] The

emergence of web services is an increasingly evident phenomenon that cannot be ignored—even the leading online search engine Google has also provided a Web Services Kit for programmers to query for web services recently [5]

Web services offer internet users the possibility to interact with and compose the source of the information directly However, this availability comes at a price In order to decide which web service to use, a user has to scan through lists of service descriptions to interpret the information so as to map the various available services according to his needs If the task at hand happens to be a complex one (that is, one that cannot be accomplished by simply enlisting an individual web service), the user will have to find ways to combine multiple web services in order to accomplish his overall task Because of this, web services are currently typically used only in a B2B (Business-to-Business) scenario where a technically complex contract about how to use the services can be assumed between the participants for involved web transactions For web services to be of good use in a B2C (business-to-customer) scenario, where the customer cannot be expected to

be conversant with the high technicalities currently associated with web services,

an efficient and precise service discovery and selection mechanism for web services is necessary

Web service selection is a process to automatically select one web service or a list of services according to users’ requirement So far, research in the area of web services mainly focuses on B2B web services with well defined interfaces and terminologies defining a shared meaning for machine-to-machine interaction [60]

But web service selection task in B2C scenario is far more complicated than that

in a B2B scenario in the following ways:

o Multiple domains environment: Web services in B2C scenario are

heterogeneous in terms of service domains For instance, the 400 web services registered in xMethods.com1 are related to 24 service domains, including SMS, postal code, medical information and address validation, and so on It is impossible to infer a uniform presentation of the services, as in the case of B2B scenarios Domain selection is the first step of B2C web service selections

o Lacking common language between service providers and human users: In

B2B scenario, a common language, such as taxonomies and specifications, is introduced to seek a common understanding between service providers and service requesters In a B2C scenario, human users cannot be expected to go through the service catalogs to have an understanding about the technicalities associated with web services

This thesis therefore focuses on the research problem of how to intelligently select web services based on a users’ requirement in a B2C environment

1

XMethods.com is a web service repository from XMethods Inc It is founded in 2000 by Tony Hong and James Hong to provide services that facilitate the development, deployment, and usage

1.2 Proposed Approach

We present a novel automated web service selection method that utilizes machine learning and information retrieval techniques to identify relevant web services based on a users’ service query in free text format Our approach is to treat web services as textual web pages that are presented as service descriptions in WSDL

or other service description formats In this way, the domain knowledge of a web service category can be represented by a textual collection of the web services belonging to it The resulting text-based representation of the domain knowledge also introduces an overlap between representation of the services and the presentation of users’ free text queries, which can then be used to guide the computer’s selection of relevant web services

Our proposed approach can be separated into two main phases: build-time and run-time During build-time, we construct domain models that can be used to classify a user query into specific service domains To address the manual bottleneck of domain modeling, we apply machine learning on the training services to automatically derive a support vector machine (SVM) model to intelligently distinguish the different domains of interest We also employ the WordNet [6] to mine the semantic meanings in the concept labels of the service ontologies

During run-time, a user inputs a free-text query to request for some web services This user query must first be mapped to a known service category or domain By applying the SVM from build-time on the meaningful words extracted from the query string by PoS (Part of Speech) tagging, we identify the relevant domain in which to select the appropriate web services based on the user query Next, we partially fill in the web service template for the chosen domain using specific values from the user query The partially-filled service template is then used to find the best matches in the web services published under the chosen domain These web services are then selected by the system and presented to the user In this way, our system provides intelligent service selection for web service applications in a B2C environment.

2 Light-weighted Semantic Approach: A key limitation of the so-called

semantic web approaches for web service selection (see Chapter 2) is that they rely heavily on the availability (as well as the quality and completeness) of the domain knowledge modeling of the manually constructed ontologies By devising a process to automatically generate annotations of the domain ontologies; our approach is applicable even when the domain ontology is not perfectly defined

3 Applicability in B2C Environment: In a B2C environment, the user queries

are in free texts and they cannot be expected to conform to rigid standard structures such as UDDI (Universal Discovery, Description and Integration) Our approach can be applied in such a flexible environment

as it relies on neither pre-determined UDDI categories nor manually constructed ontological models for service selection

The rest of this thesis is organized as follows In Chapter 2, we provide the background of web services and the related works from W3C and Semantic Web research area Since our automated web service selection work is a component of

the M-Comm project, we describe the overall M-Comm architecture in Chapter 3

Then, in Chapter 4, we provide a detailed description of our approach for automatic web service selection In Chapter 5, we present the evaluation results

of our system Finally, in Chapter 6, we conclude our thesis with discussions on possible further work

Chapter 2 Background and Related Work

As mentioned in Introduction, the Web is evolving into a provider of services instead of solely as a conventional repository for hyperlinked text and images Web users can now use the Internet not only to retrieve web pages of stored information but also to enlist useful web services such as a stock-quote service, flight information service and various e-commerce and B2B (business-to-business) applications, to service their operational needs Take the following scenario as an example for a possible use of web services A secretary wants to

book a ticket from Paris to London for her manager She opens a Soogle (

“Soogle” was used as a fictitious example for the future of web services, just like

Google today), and requests to book the cheapest ticket from Paris to London

departing tonight The underlying intelligent system searches the Internet and

discovers some services providing air ticket information and some services that provide online tickets booking The system finds the best match of services and then composes the services The orchestrated services are then seamlessly invoked With only a simple free-text query from the secretary, an appropriate class of ticket for the manager is now waiting for her boss who can claim it when departing the airport From this example, it is clear that web services should be discovered, composed, and invoked automatically To do so requires the establishment of common architecture and standards to enable seamless

interoperability between the underlying software languages, platforms and protocols

2.1 Web Service Architecture and Standards

A web service operates as a software system identified by a URL whose public interfaces and bindings are defined and described, currently using XML Its definition should be open so that can be discovered by other software systems to interact with the web service in a manner prescribed by its definition, using XML based messages conveyed by internet protocols [7, 8, 9] SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) and UDDI (Universal Description, Discovery and Integration) are three current key standards

in Web service architecture They define the protocol of Web Services for messaging, service description and service registry & selection respectively

2.1.1 Web Service Architecture

The web service architecture is a Service-Oriented Architecture (SOA for short), which is also the structure that Grid computing is now based on Three key roles – Service Registry, Service Provider and Service Requester – are defined in the SOA architecture, as shown in Fig 2.1:

1) Service Provider A service provider is the owner and the implementer of a

published web service It must provide the descriptions of the services as well

as a platform where its clients can access to the service

2) Service Requester A service requester is a person or an organization that wishes to make use of a provider's web service It will use a requester agent to exchange messages with the service provider's provider agent [9]

3) Service Registry A service registry is the medium between the interaction of

service requesters and providers It provides the necessary API’s and storage for service registering and browsing An entry in the service registry contains descriptions of the necessary business context of the provided service, such as the service provider’s name, contact information, and so on

Fig 2.1, Service – Oriented Web Services Architecture

Also shown in Figure 2.1 are the three corresponding actions between the

three roles of the web service architecture:

1) Publish Service providers publish their services’ description in the service

registry The UDDI is the current standard protocol for web services, and WSDL is the standard service description language We will provide more detailed descriptions on UDDI and WSDL in the next section

2) Find Service requesters find services by browsing the service registry using

the API’s provided in the service registry

3) Invoke After a service requester identifies a relevant web service published

in the registry, he invokes the service by using the information found in

service description

The messaging standard for the three actions is done with SOAP, which is an XML-based messaging exchanging protocol, and the underlying network protocol can be HTTP, SMTP, and so on

2.1.2 Web Service Standards

To ensure interoperability, there exist published standards for performing the actions on web service architectures for operations involved in business

interactions The standard web service stack is shown in Figure 2.2 The various

web service standards are mainly categorized into two key layers on the web

Fig2.2 Web Service Technology Stack

1) Core Layers Core layers are the lower-level layers in the stack They include

TCP/IP as the network protocol, HTTP and SMTP as the transport protocols, SOAP which is based on XML as the protocol for information exchanging

2) Emerging Layers Emerging layers are upper layers in Web service stack,

including WSDL as the web service description languages, UDDI as the service registry and discovery protocol, and other standards like Web Service Flow Language (WSFL) [10] for business interactions

In the following, we describe each of the standards in the web service stack’s Emerging Layers in further details:

• Simple Object Access Protocol (SOAP): SOAP provides a lightweight

mechanism for exchanging structured information between peers in a

decentralized, distributed environment using XML SOAP provides encoding mechanisms for encoding data within modules, which allows it

to be used in a large variety of systems ranging from messaging systems to RPC [11] SOAP consists of three parts:

o Envelop The SOAP envelop defines an overall framework for

representing the SOAP content, and it contains the other two parts

of SOAP message

o Header The SOAP header is a collection of zero or more SOAP

header blocks each of which might be targeted at any SOAP receiver within the SOAP message path

o Body The SOAP body is a collection of zero or more element

information items targeted at an ultimate SOAP receiver in the SOAP message path

For further details about SOAP, please refer to [12, 13, and 14]

• Web Service Description Language (WSDL): WSDL is an XML-based

interface language It defines the web service in a high level of abstraction, including a set of operations, the messages and a set of data types implemented by the service The service invoking styles (one-way, request-response, solicit-response and notification) are also defined in WSDL

• Universal Description, Discovery and Integration (UDDI): UDDI

provides the storage and API’s (registry API and discovery API) for service providers and service requesters to advertise and browse services respectively Currently, WSDL is most closely associated with UDDI for service descriptions [15]

• Web Service Flow Language (WSFL): WSFL, a language layer on the

top of WSDL, is an XML format for the description of web service composition Two models are contained in WSFL definition: a flow model and a global model Execution sequence of the functionality provided by the composed web services is defined by the flow models Global models specify how composed services interact with each other [10]

These standards in SOA allow the web service actions publish and invoke to

be carried out in a common standardized web service platform between the participants The remaining, and most important action in SOA that concerns both

Service Requesters and Service Provides is find — how can we help Service

Requesters locate the relevant services from the Service Providers based on the Requesters’ specific requirements and the Providers’ specific specifications? We discuss this “Web Service Selection problem” in the next section

2.2 Web Service Selection

Web services were originally designed with B2B (Business-to-Business) interactions in mind For example, the standard for web service registry and selection, UDDI, which is based on catalog-based service registry and discovery,

is applicable for B2B scenarios as the business transactions are carried out by applications that can be programmed to understand the various UDDI categories However, with the impending evolution of web service technology, web service has expanded into the area of B2C (Business-to-Customer) and eventually to peer-to-peer interactions Indeed, B2C and End User (personal agent) Web Services have been described as one of the most important usage scenarios of web services This new development calls for a new variety of web search engines:

user-oriented web service selection engines Future search engines will not only

search web page content by keywords but they will also be expected to provide web searches according to web site capabilities

The traditional search engines such as Yahoo! and Google.com currently work

as follows: a user inputs query keywords and the search engine searches the web pages stored in their database to find the web sites that contain some or all of the user query keywords The new user-oriented web service selection engines will have to parse users’ input requirements in free text for some specific task, and translate them into appropriate service requirement specifications that can be understood by the web service selection engines, and then return (or even invoke)

a list of relevant candidate web services for the user Some efforts have been attempted in adapting the current B2B-focuses web services standards for user-oriented service selection [58, 59, and 60] In the next section, we discuss the pros and cons of using the current web service protocol—UDDI—for service selection tasks

2.2.1 UDDI for Service Selection

In the Web Services SOA (Services Oriented Architecture) shown in Figure 2.1, UDDI takes the central role as the standard protocol for the service registry and provides the mechanism for browsing through and discovering services registered Appendix A describes in further details the various innards of the UDDI

Categorization is the key feature with which an UDDI-compliant registry can provide a service selection platform for the user However, as mentioned earlier, the categorization-based service selection functionality of UDDI is more applicable to a B2B (Business-to-Business) scenario, where corporate e-commerce applications can be programmed to understand the pre-defined structures in UDDI in order to exploit the web services that are available in the registry In other words, users can only use UDDI to find the services already known to them (i.e they must first know exactly which category their desired web service falls under in order to search for it) In a more dynamic environment such

as B2C (Business-to-Customers), such rigidly pre-categorized service selection functionality provided under UDDI is inadequate When a web service provider registers under a specific category along with UDDI registration data, it can only

reach the customers who are searching in the exact category For example, if a business marks itself as “retail—pet-food”, and another simply uses “retail”, the specification and generalization across these two related categories may not be known to the UDDI-challenged users Our work in this thesis seeks to address how to provide more user-oriented web service selection capability for B2C scenarios (see Chapter 4 for details)

2.2.2 Service Selection in B2C

Initially, web services are deployed as one of the most important standards in SOA (Service Oriented Architecture) to seamlessly integrate in B2B scenario Thus major research emphasis and board interest in standardlizing in web services are in applying web services in B2B scenario, whist human user interaction are omitted or taken for granted With the development of web service, especially for mobile services, the ability of web services being able to support B2C application

is a critical problem that cannot be ignored in the design of B2C web services architecture

The service selection process in B2C scenario is more intelligently and as a result more complicated comparing to that in a B2B scenario Heterogeneity is the major difference between web service selection task in B2C scenario and B2B scenario Heterogeneity of the B2C scenario is presented in the following two aspects:

o Web services: Web services in B2C scenario are from different domains, such

as WWW As the example in Chapter 1, 400 services in xMethods.com are from 24 quite different areas It is impossible to infer a uniform presentation

of the services as in a homogeneous environment of B2B scenario

o Users’ query: At the same time, the users have difference understanding about

same object Users will use different requests to present the same query task, which has not been examined in the former research effort in semantic web services so far, even in the research in B2C web service selection

In the following, we present the related work in web service selection in B2B and B2C scenario

2.3 Related Work

Before we proceed to present our approach in Chapter 4, let us review several related approaches toward automated web service selection Generally, this is done through semantic annotations of the web services We review several of the current popular semantic annotation approaches in the remaining sections of this chapter

2.3.1 Semantic Annotations to Web Service

Tim Burners-Lee—often considered as a key developer of the World Wide Web— proposed an approach called Semantic Web [16, 17, and 18] to introduce

intelligence to the Web The aim is to provide a computer-interpretable mark-up

of the Web’s content and capability The Semantic Web extends the ability of the WWW through the use of standards, markup language and related processing tools for the semantic annotation of the web pages

One very important concept in Semantic Web is ontology Ontology here

refers to the shared understanding for a domain in domain-specific knowledge modeling The commonly used and highly cited ontology definition is from Gruber (1993):

“An ontology is a formal, explicit specification of a shared

conceptualization “Conceptualization” refers to an abstract

model of phenomena in the world by having identified the

relevant concepts of these phenomena “Explicit” means that the

type of concepts used, and the constraints on their use are

explicitly defined “Formal” refers to the fact that the

ontology should be machine readable “Shared” reflects that

ontology should capture consensual knowledge accepted by the

communities.” [19]

Ontology is the basis for constructing common understanding through explicitly defined relations [20, 21] It is often conceived as a set of classes (concepts), relations, functions, axioms, and instances [19]

The Semantic Web Service approach takes the cues from Semantic Web into web services: machine-interpreted semantic descriptions are introduced in the

development of web services In Semantic Web Service, service selection is defined functionally as:

“Clients receiving multiple recommendations for services

satisfying (exactly or approximately) the requirements they

have previously specified must be capable of selecting from

among those candidates” [22].

Semantic web service selection (as well as semantic web service discovery) [reference: SWS: architecture] are critical for automatic web service composition and orchestration Currently, the major research focus in semantic web service selection approaches is in the definition of web service ontology languages that can be used for establishing a common vocabulary for partners in web service interactions to understand each other Semantic web services can then be defined

by using some ontology-based description languages In the following sections,

we discuss two respective ontology languages that have been developed for semantic web services: OWL-S (formerly DAML-S) [24, 25, 26, 27, 28], and LARKS [29, 30, 31]

OWL-S

OWL-S (DAML-S) is a web service ontology language developed for describing the properties and capabilities of services in a machine understandable form, so that it can enable automatic service discovery, invocation, interoperation,

composition, orchestration, verification, execution and monitoring More specifically, OWL-S contains the following composition:

• Service Profile: Service Profile describes service and its providers at a

high level It specifies the intended purpose of a service in terms of its functional behavior and functional attributes, such as service names, text description of the service, geography scope of the service, degree of quality of the service, and service category

• Service Mode: Service Mode contains process ontology, which describes

services in terms of their inputs, outputs, preconditions and effects Process control which has not been released yet (specified a time), describes in terms of their execution states

• Service Grounding: Service Grounding component defines how a service

can be accessed

OWL-S (DAML-S) was proposed by W3C as the standard language for semantic web services There are also other implementations and solutions [references] which are based on OWL-S to introduce semantic annotation on web services

LARKS

LARKS (Language for advertisement and request for Knowledge Sharing) is a language developed for annotating software agent capabilities at CMU It was

originally defined to seek a common understanding between the participants about the capabilities with which heterogeneous software components from different platform can communicate Technologies from information retrieval, artificial intelligence, and software engineering have been implemented as five filters to eliminate services that are not qualified to the requirement based on the measurement of syntactic and semantic similarities between descriptions of service request and the candidate services list

Discussions

Unfortunately, these approaches for introducing semantic annotations to web services themselves through the use of ontology-based languages are too expensive First, the domain ontology has to be defined by experts for each and every domain This is not feasible in such an extensive and heterogeneous environment as the Internet Not only that, handcrafted semantic metadata are then needed to describe the services Manually annotating the web services by using the concepts and relationships in the ontology is a non-trivial task In [32,

33], it was stated that even a modest web service “GlobalWeather” by

CapeScience has 53 different elements and 55 different values for parameters

adding up to 108 concepts As a result, there have not been much successes reported using these approaches

2.3.2 Semantic Annotations to UDDI

UDDI currently contains a metadata protocol called tModel (Appendix A) to store

the semantic details of web services In the categorization-based web service

selection of UDDI, tModels are used with categoryBag (Appendix A), which is a

data structure that allows entities to be categorized according to one or more

tModels, and keyedReferenceGroups (Appendix A) to provide convenient web

service selection for the user

But the limitations of category-based service browsing make UDDI an inadequate choice for effective web service selection in a B2C environment, even with semantic annotations As discussed earlier, the B2C environment is inherently heterogeneous and it is not reasonable to expect that the users can understand the complicated category definition in UDDI To overcome the limitations of UDDI as an effective medium for service providers to advertise services and service requesters to retrieve web services, W3C has published several proposals such as Topic maps[34, 35], value set [36, 37] to provide vehicles in UDDI for semantic annotations Generally, these approaches attempt

to implement an ontology or taxonomies (for the technical differences of ontology and taxonomies, please refer to [38]) definitions outside of UDDI and link the

taxonomies or ontologies with the UDDI by tModels, so that semantic annotations

can be introduced into UDDI to enable common semantic understanding between the service providers and services requesters

These approaches to semantically extend UDDI for enhanced service selection ability try to seek a balance between the UDDI compliance and semantic annotation On one hand, they share the same disadvantages from semantic web services On the other hand, they have to maintain compliance with UDDI at a price Take Topic Maps as an example While XTM [34](an XML version of the Topic Maps) can describe complex relationships between items/topic, it forms not just a hierarchy but a complex network structure This makes even simply mapping XTM to UDDI’s key-name-value structure (See Appendix A) a non-trivial task

2.3.3 Semantic Annotations to WSDL

While the web service description language WSDL serves mainly to describe the

syntactic meaning in web service, there are also some semantic descriptions about

the web service that can be used for intelligent service selection For example, the names of the operations, the structures of the web services, and the relationships between the various parameters can be very informative for service selection There are approaches in semantic web services that employ WSDL as a means for applying semantic annotations for intelligent web service selection We discuss here a sub-system from METEOR-S as the representative approach in this category

MWSAF

MWSAF (METEOR-S Web Service Annotation Framework) [32] is a sub system

of METEOR-S, developed by the LSDIS lab of University of Georgia MWSAF

is a framework for semi-automatically marking up web services descriptions with ontology Algorithms were developed to match and annotate WSDL files with relevant ontologies More specifically, four types of semantic metadata in the process of web service lifecycle have been classified:

• Data Semantics: Data semantics are the semantics of the inputs/outputs

data of web services

• Functional Semantics: Functional semantics is the description about the

action of the web services and a functional ontology is applied to annotate what a service dose

• Execution Semantics: Execution semantics is the correctness and

verification of execution

• QoS Semantics: QoS semantics is to define the performance and cost

parameters associated with service

To handle the difference in the ontologies and XML schema used by WSDL, the XML schema for WSDL and ontologies are first transferred to schema graphs The next step then is to map the WSDL concepts with the ontology concepts in the schema graphs, choosing the best mapping concepts using ontology matching scores This is also a process to categorize WSDL to different definitions of ontology, i.e different service domains

There are also other approaches for semantic annotations through WSDL: Java code generated from WSDL [39], or labels and structures [40, 41] from WSDL files are applied to introduce semantic annotations to WSDL While this category of semantic annotation approaches is the most light-weight and extensible for intelligent web service selection, the potentially inexact annotations

of WSDL may also lead to the loss of precision as well as recall

2.3.4 Semantic Annotations to Ontology

As most of the data stored in semantic web service selection processes is represented by using ontology, it is worthwhile to explore semantic annotations to the ontology One possible usage of ontology annotation is to match users’ query into an ontology-based format in semantic web selection The MKBEEN-project

[42] by Heuneche et al is a good example The primary objective of the

MKBEEN system is to integrate knowledge-based processing (knowledge presentation and reasoning) and human language processing in providing multi-lingual e-commerce mediation services The MKBEEN system can therefore allow a customer to use her own language, independent of the country where the product/service provider is based MKBEEN then translates the complex user request input in human language into an ontology-based formulation and subsequently exploit it to identify a web service that best matches the query

Another example of ontology annotation is the work from Magnini et.al [43]

Their work explore the semantic meaning of ontology by applying NLT (Natural

Language Technology) to mine the meaning of labels of concepts in the ontology

as well as the positions of the concepts to extract the semantic meanings of the concepts for service selection

2.3.5 User-Oriented Web Service Selection

Unfortunately, there is not much work being done on user-oriented web service selection User interaction during the web service selection is always omitted in former research In [58, 59, and 60], Balke et.al present their approach to user-centered web service selection In their approach different usage patterns are designed, such as “casual dining”, and “business dinner” When user request web services, they try to infer a usage pattern according to the users’ request, and then compose a SQL-style query to search for adequate services as the result in the underlying ontology

This approach is still heavily depends on the manually designed usage patterns and also underlying ontologies as the other approaches in semantic web services, which has problem in a heterogeneous environment, such as WWW At the same time, though the human users’ interaction is taken into account, the users’ request format, the matching between the users’ request to the user usage pattern have not been explicitly explained

2.4 Our Approach – A Preview

As we can see from the background and related works described so far in this Chapter, semantic annotations to UDDI, web service or WSDL, the underlying theme of semantic web service approaches is to introduce ontology as the vehicle for semantic annotations in web service description and subsequently for web service selection Our work in this thesis follows this general guideline, but we differ from the former approaches in two major ways:

1 Semantic Annotations We introduce additional new channels to help

semantically and automatically annotate the web service:

• We annotate web service by the web service itself using machine

learning A single service doses not contain much of the semantic

meaning of the domain, but a collection of services from the same domain can be used to represent the semantic differences among different domains To represent a domain, we therefore use a collection of (training) services from the domain to extract the common semantic features sharing among the services in the domain

using machine learning

• We annotate the web services using informal (free-text) service

descriptions As stated in [47], the formal knowledge modeled by

using ontology is often strongly related to informal materials The free

text descriptions in the service descriptions from service providers should be mined to extract the underlying semantic meaning of the services In our approach, the semantics of individual web services are also retrieved from the free text descriptions from service providers; an approach which, as far as we know, has not been used before by other

approaches in semantic web service

2 Service Selection We can then enable intelligent web service selection

through mapping these automatically derived, text-based semantic annotations of the web service to users’ free-text input queries We will provide more details on this important step when we describe our

Intelligent Service Selection Engine (iSSE) in Chapter 4

Therefore, our system takes the users’ request into the service selection loop And an algorithm to match the users’ query to the domain and ontology individual

is introduced To avoid the heavy dependence on the design of ontology, technologies from information retrieval and machine learning are implemented in this approach Even the domain knowledge is not perfectly designed; our approach is still applicable and more reliable in a B2C scenario than the former approaches introduced in this chapter

However, before we go into the details of our intelligent service selection

approach, we present the system architecture of the M-Comm system of which our

iSSE is a sub-system next

Chapter 3 Service Selection in Mobile

Commerce

With the rapid increase in the bandwidth of mobile network and the contents provided by service providers, Mobile Commerce (M-commerce) has become a new marketing channel and a powerful revenue engine for marketers According

to a recent Merrill Lynch market survey, wireless Internet access is expected to reach 1 billion users by 2005 [44] With the help of Mobile Commerce system, many on-line content publishers and information providers are now trying to seize the opportunity to increase site traffic, enhance customer relationships and

reinforce brand awareness The M-Comm system [45] was developed in this

scenario

3.1 The M-Comm System

The M-Comm project is being developed by the Network Systems and Services

Lab of School of Computing, National University of Singapore (NUS) It is a project spanning many technological areas, including wireless application, workflow management, artificial intelligence, and CRM (Customer Relation Ship

Management) Central to the M-Comm project is the M-Comm System, which is a middleware for commerce alliance in a commerce network The M-Comm system

is designed to provide a uniform platform to consumers, manufactures, bankers, stakeholders and service providers (i.g retailers) It serves as an information provider as well as a trading platform for the customers to enjoy map navigation, browsing of detailed commodity information, performing E-Payment and receiving good after-service Customers should be able to enjoy these service

from M-Comm system whether they are at home, in a shopping mall or any place

else

Most importantly, the M-Comm system provides a new channel for the

retailers to push products information to the potential customers In summary, the

M-Comm system is:

• an information provider to help customers to locate required information and deliver the information to their mobile devices, anytime and anywhere

• a new means for advertisement for the shopping centers, suppliers, manufacturers, which will help the participates to shorten the sale cycle

• an new channel to make the customers’ current shopping lifestyles more convenient and pleasurable, and improve the quality of after-sales service

Figure 3.1 shows the overall structure of the whole M-Comm system For a detailed description of the M-Comm system, please see Appendix C