Uddam Chukmol

Aïcha-Nabila Benharkat

Youssef Amghar
email: youssef.amghar@insa-lyon.fr

Bringing socialized semantics into Web services based on user-centric collaborative tagging and usage experience

Keywords: Social Web service, user annotation, collaborative social semantics I

The semantics of Web services is often provided by suppliers and embedded physically inside the service descriptions expressed in WSDL. This type of annotation can be very costly and is generally performed by well-trained cognitive or knowledge engineers. In this research work, we aim at providing an alternative to the actual Semantic Web Service (SWS) technologies by bringing a community-based or social semantics into Web services. This semantics is created by users through collaborative tagging on the capabilities of Web services after testing or using them. We argue that this type of semantic annotation can be very pragmatic and facilitate the process of Web service discovery, composition or clustering assisted by users.

INTRODUCTION

Semantic Web community proposes numerous formalisms based on logics or ontologies to extend standard Web service description expressed in WSDL such as OWL-S [START_REF]OWL-S: Semantic Markup for Web Services[END_REF], WSMO [START_REF]Web Service Modeling Ontology (WSMO)[END_REF], WSDL-S [START_REF]Web Service Semantics -WSDL-S[END_REF], SAWSDL [START_REF]Semantic Annotations for WSDL and XML Schema[END_REF] or WSMO-Lite [START_REF]D11v0.2 WSMO-Lite[END_REF]. Semantic annotations based on these formalisms can be done at the service supplier sides only and may represent some cost and rigidity to them. In effect, modifying and maintaining ontologies are very complex and timeconsuming tasks and in order to master completely the annotation process, the suppliers must acquire sufficient expertise in cognitive or knowledge engineering. In addition to the heterogeneity of semantics representations that may provoke several interoperability issues, the absence of fully semantic supported Web service registries in business environment discourages even more the enterprises in adopting SWS at large scale [START_REF] Shi | Semantic Web Services: An Unfulfilled Promise[END_REF]. Besides, the SWS community itself reveals that there are still many challenges to convince practitioners to adopt their technologies [START_REF] Martin | Semantic Web Services, Part 1[END_REF] [START_REF] Martin | Semantic Web Services, Part 2[END_REF]. At the user sides, exploiting SWS technologies means at least a proficiency in description logics or knowledge engineering, which can be considered as a burden. Moreover, there are not many tools supporting these technologies that are robust and in a form that developers find attractive and easy to learn and use [START_REF] Martin | Semantic Web Services, Part 2[END_REF].

The recent emergence of Internet of Service [START_REF] Schroth | Web 2.0 and SOA: Converging Concepts Enabling the Internet of Services[END_REF][10] and the increasing number of public accessible Web services in the Internet [START_REF] Wu | Searching Services "on the Web": A Public Web Services Discovery Approach[END_REF] [START_REF] Hageman | [END_REF] [START_REF] Al-Masri | Discovering Web Services in Search Engines[END_REF] through portals or catalogs lead us to several other research issues. The main one that interests us is how to assist users at best in the discovery and composition of Web service in the aforementioned environment (publicly accessible Web services in the Internet). We are aware of the limit met in the keyword based service discovery systems due to the poor textual descriptions that can be extracted from WSDL descriptions of Web services [START_REF] Hageman | [END_REF]. We assume also that users who browse Web service portals in the Internet are not proficient enough in constructing discovery queries using description logics or SPARQL to exploit the semantic metadata embedded in the WSDL contents of Web services. Thus, it is interesting to provide them intuitive and easily approachable ways to discover, to compose or to classify Web services.

Inspired by the dynamics of Web 2.0, we encourage user communities to participate in sharing their perceptions on Web services by tagging collaboratively any Web service that they used or tested before. Only through real world testing and usage, a user can have a clear idea on how to comment or give feedback on a Web service. Service usage experience can be expressed as comments or feedbacks on several aspects of Web service that can be observed by users during its testing or usage. We are interested in bridging the gap between original description and real world usage of service.

In this research work, we propose a folksonomic annotation model allowing users to express their perception on service functionality (after testing or using them). The annotations issued from users form incrementally community-based semantics on annotated Web services. This semantic metadata can be viewed by other users of the system and can be used to assist them in the task of discovery, composition or clustering of services. We propose also a collaborative tagging system supporting the aforementioned annotation model and allowing collect and construct social semantics of Web services.

This paper is organized as follows. Section 2 discusses similar research works. Section 3 describes the annotation/tagging model followed by the supporting tagging system in section 4. Section 5 argues on some applicative usage scenarios of the annotation to prove the pragmatism of our approach. Finally we conclude and present some future directions of the proposal.

II. RELATED WORKS

To our knowledge, there are still few existing proposals that adhere to the idea of using community-based semantics of Web services. We choose some significant proposals that follow the concepts and try to point out their strengths and limits.

The earliest proposal to use tagging to represent the semantics of Web service is discussed in [START_REF] Meyer | Light-Weight Semantic Service Annotations Through Tagging[END_REF]. It is still a rudimentary approach by considering keywords provided by users and associated to Web services as sufficient to describe their semantics. It is a collaborative tagging process but there is no discussion on how to merge tags provided by different users to annotate a specific service. Later on, a similar approach follows the same tagging mechanism but improves the system with more complete tags management in terms of variety and aggregation [START_REF] Chukmol | Enhancing Web Service Discovery by Using Collaborative Tagging System[END_REF]. However, it shares with the previous one the same downside. Despite all, this concept of user-provided semantics of Web service is exploited in the real world situation in [START_REF] Papathanasiou | Combining Service Models, Semantic and Web 2.0 Technologies to Create a Rich Citizen Experience[END_REF] and [START_REF]seekda! -About seekda[END_REF] to help users in searching for services.

Some improvement of the concept has been made in [START_REF] Bouillet | A Folksonomy-Based Model of Web Services for Discovery and Automatic Composition[END_REF] by tagging only the input and output parts of Web services with the final goal to facilitate the discovery for composition process. However, the main drawback of the approach is that the original description of Web services is modified, which can be done only by the providers. Tags are then used to build a hierarchy with help from a machine learning approach, which requires a great quantity of annotated services and time. The discovery process using tags is based on this hierarchy. This idea of tag hierarchy is also picked up by [START_REF] Silva-Lepe | SOAlive Service Catalog: A Simplified Approach to Describing, Discovering and Composing Situational Enterprise Services[END_REF] with help from WordNet [START_REF]About WordNet -WordNet -About WordNet[END_REF] and Wikipedia [START_REF]Wikipedia, the free encyclopedia[END_REF] by exploiting their linguistic relations between terms. This hierarchy is also served to facilitate the discovery by tag. Nonetheless, both approaches ignore how tags are merged when provided by several users and associated to a service and still consider freeform tags as representative enough to reflect the service semantics.

In brief, there are common limits of the aforementioned proposals such as:

x Considering service semantics as global and taking freeform tags that are associated to the service as sufficient semantic expression of the service. This concept is still very vague because the semantics of service should be expressed in a more elaborated way by favoring more expression on the capability of the services x Several users can tag a service but their aggregations are usually ignored. In fact, in a collaborative tagging system tag weight or tag frequency is an important factor to assess the significance of the tagged object via that tag and x Tag ambiguity is often ignored. This issue can cause very weak ratio of precision and recall in the search of tagged objects by using tags. Our proposal attempts to provide some solutions to improve the aforementioned limits encountered in the existing approaches.

III. ANNOTATION/TAGGING MODEL

It is worth mentioning that we work with publicly accessible Web services that can be collected from various Web service portals or catalogs on the Internet. Therefore, users are not allowed to add services into the system. Only the service providers can modify the service collection. Users can only add metadata to annotate or tag the existing Web services in the collection. Generally, a public Web service can be discovered, tested, tagged or annotated (in our case) and used (e.g. in a composition). This cycle can be repeated as many times as possible and conducted by any user on any service. Thus, a public Web service can be present in various states of the aforementioned cycle (see Figure 1). At the user side, in order to get a full and clear idea on the functionality of a Web service, testing it is strongly recommended. Testing a service generally refers to testing the operations of the service by providing input data and observing output data. Therefore, at this state, the functionality of a Web service is qualified by its operations and for each of them what input and output is required (see the unit test interface of Seekda [START_REF]seekda! -About seekda[END_REF] and Directory of public SOAP Web services [START_REF]Directory of public SOAP Web Services[END_REF]).

However, a service can be employed differently with respect to usage context or user requirement (e.g. a weather forecast service can be used perfectly in either "holiday preparation" or "wedding party organization" context). Thus, operational and contextual information are necessary to fully describe the user perception on a Web service after a usage experience of the service.

In brief, given a Web service described by WSDL content, there can be several operations to test and for each operation there can be several input parameters to enter and output results to observe. Consequently, a tester can annotate a Web service at usage (describing the situation or context in which he/she uses the service), operation (describing different atomic functions of the service), input (describing what to offer as input when testing an operation) and output (describing the observable result after testing an operation) level.

Therefore, given a service, we can identify four types of taggable object that correspond to the four aforementioned levels (see Figure 2). We ignore the pre-condition and effect at operation level because a unit testing is done completely stateless and these aspects are hardly perceived by users. A user can annotated a Web service as efficient to be used in a certain context or situation, as providing several functions and each of them executes an action or as requiring some input data and providing certain output result.

The system allows collaborative participation of users in the tagging or annotation activities. In effect, a taggable object can be annotated by several users with different keywords and a user can annotate many taggable objects as well. Keywords from several users are used to construct tags and then feed the tag cloud that is associated to the corresponding taggable object (see Figure 3). The next section discusses in detail the tagging system and describes its core components. We attempt to illustrate the functionality of such system by presenting the abstract architecture of the system and its interactions with users.

IV. ANNOTATION/TAGGING SYSTEM

After choosing a Web service to tag, the identifier of the service (its invocation URL) is input to the system. The system parses the WSDL file (with help from WSDL Parser module -(see Figure 4)) corresponding to the description of Web service in order to display its interfaces, operations, inputs and outputs. This parsing process is needed to visualize the Web service as structurally perceived by the user, mentioned in Figure 2.

A WSDL file can offer x taggable objects with x=1+number of operations + number of inputs + number of outputs. An operation, input, output object is identified by the Web service identifier and its XPath path (including namespace) of the corresponding element in the WSDL file.

After the parsing, the system searches for the existing tag cloud that is associated to each taggable object and displays them to users. This can give the user some ideas of how the others perceive the service he/she is tagging. Partial tagging is completely allowed in order to diminish the user effort in interacting with the system; i.e. the user is not obliged to tag every single item of the Web service.

Then the user can proceed to the effective tagging by providing a list of keywords to be associated to a chosen object. Each keyword is delimited by "" and separated by ;. We recommend users to provide dictionary vocabularies instead of personalized terms as keywords. In effect, personalized terms (e.g. nyc for New York City, fb for Facebook, etc.) can represent an important source of littering tags for the global tag cloud, thereby affects the quality of search operations using tags.

Each keyword can be associated to a set of meanings proposed by the system. The user chooses a meaning that suits best his/her keyword to form a tag. In effect, there are several linguistic issues related to collaborative tagging systems mainly synonymy and polysemy [START_REF] Golder | The Structure of Collaborative Tagging Systems[END_REF]. We decide to treat only polysemous keywords in our system because it represents an important element judging the precision rate of discovery/search system based on tags. This issue goes against our initial objective that proposes to use collaborative tags to enhance Web service discovery, reuse and composition processes, where precision rate is important for the system performance.

As soon as the keywords are semantified and the tags are formed, they are aggregated with the existing ones, given a taggable object. We opt for bag-of-words aggregation method that consists of increasing the frequency of tags in the tag cloud. A recent research proves that tag frequency is significant to qualify the tagged object by the related tag because in most of the cases, tag distribution follows a power law [START_REF] Robu | Emergence of consensus and shared vocabularies in collaborative tagging systems[END_REF].

The result of the aggregation is another tag cloud combining the tags provided by the user and those associated to the tagged object before the tagging. Finally, the tagged object and its tag cloud are saved back into the system (see Figure 4).

In detail, given a Web service identifier (its invocation URL), the Tagged Web Serivce Collection can output the corresponding WSDL file using its Access Interface. All the existing tags associated with this Web service are output by the same interface also.

In this collection, we store different instances of our folksonomy represented by 3 relations (see Figure 5) such as User-Tag: given a user u and a tag t, this relation offers the list of objects tagged by t. For each object, it indicates also the number of times (weight or frequency) t is used by u to tag the object, Object-Tag: given an object o and a tag t, this relation offer the list of users employing t to tag o. For each user, it indicates number of times he/she has used t to tag o and User-Object: given a user u and an object o, this relation offers the list of tags used by u to tag o. For each tag, it indicates its frequency also. First, tagging an object consists of fetching input keywords from users and for each keyword, the system checks through Wikipedia [START_REF]Wikipedia, the free encyclopedia[END_REF] for its various meanings. This operation is called disambiguation of keyword. It is simply done by inquiring for the disambiguation pages of Wikipedia using some API such as [START_REF]JWPL[END_REF] and [START_REF]Wikipedia API -Wikipedia-Lab[END_REF]. Each disambiguation page corresponds to the meaning that users chose to qualify a keyword.

In effect, the choice for Wikipedia is because it is a collaboratively edited free encyclopedia that evolves with strong support from community and covers a large number of vocabularies. It is possible that users leave the meaning of a keyword as null if none of the meanings proposed by Wikipedia suits him/her.

Secondly, after the meanings are selected by users, the tags are formed; i.e. couples of keywords and meanings. These tags are then aggregated with the existing tag cloud associated to the tagged object. The aggregation of two tag t i <k i , m i > and t j <k j , m j > having respectively f i and f j as frequency is a bag of tags (tag cloud) containing t i if and only if t i and t j are identical (keyword k i =k j and meaning m i =m j ) with the new frequency that is equal to (f i +f j )(one tag only); else, t i and t j with their previous frequencies respectively (two tags). After associating the aggregated tag cloud to the tagged object, the system updates the Tagged Web Service Collection by updating its three relations mention before, respectively.

V. SOME APPLICATIVE USAGE SCENARIOS USING OUR ANNOTATION/TAGGING MODEL The fact that users can annotate Web services with their own tags implies more plentiful and community supported semantics. Beyond syntactic information, these semantics can enhance the discoverability, reusability and composability of Web services.

During the Web service discovery process at design time, our annotation can be used to help application developers in finding relevant capabilities of services. In this case, tags at Web service (usage context) and operation level are considered because they are significant to get the functional offer of the services. Web services can also be browsed via tags and that is more intuitive for developer to create his/her discovery query easily, quickly and efficiently. However, it is recommended that service user communities care enough participating in tagging Web services at the two aforementioned levels to make social semantics of the services emerge.

Web service composition can be assisted by users also. In this case, tags at input and output levels are more considered than those of usage context or operation level. When a user would like to have on-time effects or interventions on the composition of Web services, he/she can check the tag clouds at his/her disposal for atomic service that responds to his/her prompt need in order to create his/her composite Web service. The requirement formulation is easy as our tagging model favors the annotation on input and output level of Web services.

Tags themselves can be used to create user profile and propose the recommendation to help in the discovery and composition process. User profile may be constructed from tag sets offered by the user and be used in the filtering phase of the discovery process whereas recommendation can be used in the composition process to enhance the composability of the service. Moreover, our annotation can help in the user-oriented and semi-automatic Web service clustering or classification also. With the increasing number of tags at operation levels, we can employ different natural language processing techniques on these tags to classify the tagged Web services.

Despite all, there are several challenges to overcome in order to evaluate our annotation model. Our system demands user participation to populate the tag clouds and their volume are important to access the quality and performance of the model. This factor is common to other collaborative tagging system as mentioned in [START_REF] Robu | Emergence of consensus and shared vocabularies in collaborative tagging systems[END_REF] and [START_REF] Golder | The Structure of Collaborative Tagging Systems[END_REF]. Besides, it is even harder to conduct a comparative qualitative evaluation on our because of the weak number of existing semantic annotation models of the kind and their supporting systems.

VI. CONCLUSION AND FUTURE WORKS

In this paper, we have proposed an annotation model that is easy to use and issued from the user perception on the functionality of Web services after testing or using them. The annotation model covers four levels of Web services: usage context, operation, input and output. Elements extracted from WSDL descriptions of Web services corresponding to each level represent system taggable/annotatable objects.

Several users can tag/annotate several objects during his/her system use. The tagging allows users to provide a list of keywords associated to an object and the system proposes several meaning of the keywords before asking the taggers to validate the suitable meanings. Thus, a tag is represented by a name entity and a meaning that is richer and unambiguous comparing to traditional freeform tags. The disambiguation of name entities or keywords is based the disambiguation functions/pages of Wikipedia which is the largest community supported and evolving encyclopedia.

The frequency of tag or tag weight evolves through user tagging activities and is essential to qualify the significance or semantic of the tagged object via the keywords.

We propose some applicative usage scenarios in which our annotation model can contribute in enhancing the overall performance and facilitating user interventions. It is also important to note that our annotation model does not modify the original descriptions of Web services and it is very plausible to use this model with the ontology-based semantic annotations presented in section 1. Both approaches are complementary because ours is more focused on the emerging semantics from the user side and those presented in section 1 are more used at the service provider sides.

In our future work, we would like to extend our annotation model to cover other semantic aspects of Web services such as non-functional or behavioral characteristics and use or adapt it in RESTful service context. We aim also at making use of existing SWS annotations by lowering them into human readable keyword meanings and employ them in the keyword disambiguation phase. We further provide multiple meaning bases to users allowing them to enrich their tag meanings and offer users the possibilities to add tailored meaning to their tags if none of the ones proposed by the system suits.

Figure 1 .

 1 Figure 1. Web service annotation/tagging cycle

Figure 2 .

 2 Figure 2. Web service annotation/tagging level

Figure 3 .

 3 Figure 3. An instance of folksonomy structure The annotations from a user on a service can be viewed by other users of the system in order to insure the community-based collaborative criterion. Therefore, we can define our annotation model as a folksonomy F (O × T × U) where O, T and U are distinct sets and U: represents the set of users subscribed to the system and capable of annotating and tagging the Web service collection provided by the system, O: represents the set of objects that can be tagged (taggable object) by users. Each object can be a Web service (service usage context or

Figure 4 .

 4 Figure 4. User-System modules interaction while tagging WSDL Parser parses the description WSDL of the service to tag by proposing a structure of taggable objects. Users can then choose some objects to tag.

Figure 5 .

 5 Figure 5. Taggable object -Tag -User relations


Uddam Chukmol
email: uddam.chukmol@insa-lyon.fr

Aı ¨cha-Nabila

Youssef Benharkat

U Amghar

Chukmol

A.-N Benharkat
email: nabila.benharkat@insa-lyon.fr

Y Amghar

Towards a Supporting Framework for Public Web Service Efficient Reuse: A Model Based on Social and Collective Usage Experience

Introduction

Public Web services are accessible and available Web services in the Internet. They are generally published within Web portals, catalogues or repositories directly managed by their providers [START_REF] Fan | A snapshot of public web services[END_REF]. At the back end, service providers are not obliged to respect the UDDI standard for the implementation of their repositories [START_REF] Wu | Searching services "on the Web": a public web services discovery approach[END_REF]. Service providers offer to end users service lookup interface implemented within their repositories, and end users can invoke directly a found service from those repositories [START_REF] Abujarour | Collecting, annotating, and classifying public web services[END_REF].

Recent access to seekda1 shows around 28,606 public Web services out of 7,739 providers, which is not negligible as a source of interest in promoting SOA adoption to a larger public than the one traditionally identified in intra-corporate environment. However, exploiting those publicly exposed Web services may come with some challenges due to the following facts:

• Poor textual documentation found in service description makes end users put more effort in understanding what a service can do, what it needs as input and what it can produce as output. Consumers may have to infer the operation names or message types used in the service in order to utilize them correctly [START_REF] De ´cembre Li | An exploratory study of web services on the internet[END_REF]). • Poor semantic extension reduces considerably the possibility to automate different essential tasks such as Web service discovery, composition and substitution. Semantic mark-up on Web services comes from Web semantic communities by extending original WSDL descriptions with various semantic formalisms based on ontology. Several available formalisms do not really facilitate the automation process but bring somehow burdens to both service providers, in choosing an appropriate formalism and domain ontology to use as semantic annotation, and consumers in acquiring expertise to construct discovery query or building business process schema for composing Web services (Hageman). • Non-situational refers to the fact that public Web services are for generalpurposed usage. They are not predestined to be used in a planned composition schema or any specific context. End users can consume them appropriately in their own ways which could be different from the original applicative aims targeted by service providers [START_REF] Tanaka | Towards service supervision for public web services[END_REF].

Difficult usage begets hard reuse. In effect, Web service reuse can be simply and practically put as several or repetitive usages of the same Web service instance through time and within different situations. The service is designed and published once, then used and reused over and over again by different consumers in different contexts. Web service reuse is strongly influenced by its usage and represents a great return on investment if it is well achieved.

Public Web services that are available "on the Web" provide unlimited values for a great number of online service consumers and developers, whereas most private registries would focus on a specific, closed domain such as the corporate network [START_REF] Wu | Searching services "on the Web": a public web services discovery approach[END_REF]. Hence, in an open, loosely coupled, demand-driven business environment, a maximal reuse of public Web services is still essential to SOA adoption from a wide range of users such as service consumers, service developers and service brokers.

In this chapter, we would like to tackle the reuse of publicly available Web services from the end-user point of view. In effect, after being published, end users discover, select and consume public Web services in their applications. They are then apt to comment such services on functional or non-functional aspect. Such feedbacks are recommended as supplementary semantics of Web services and can be served to enhance the discoverability and the recommendability of those services [START_REF] Loutas | Rethinking the semantic annotation of services[END_REF][START_REF] Petrie | Practical web services[END_REF][START_REF] El-Goarany | The social service network -web 2.0 can make semantic web services happen[END_REF]. Other users would consider if a service can be reused in their application based on the other usage experiences. We attempt in this chapter to provide a simple way by which users can express their service usage experiences. We outline a set of service reusability criteria and show how end-user feedback on the services can be used to satisfy those criteria and reinforce implicitly the service reusability.

This chapter is organized as follows: Sect. 2 discusses related works on Web service reusability and offers a synthesized set of criteria on Web service reusability. Section 3 proposes a formalism allowing end users to express their service usage experiences. Section 4 presents the architecture of a supporting system exploiting aforementioned feedbacks to promote and enhance Web service reusability. We end up with a conclusion and perspective on future works.

Related Works

Web service reusability is generally discussed as an issue in service design phase and rarely in consumption phase (published and ready to use). A main challenge is how to bridge the gap between Web services and general public. In effect, the benefit from reusable Web services helps consumers in getting better return on investment because the services can be employed in different situations in their applications and providers in attracting more consumers, gaining more credibility and being more trustworthy.

The existing works on reusable Web services are mostly focused on service providers rather than considering end-user perceptions on services. In [START_REF] Johnson | SOA service reuse by design[END_REF], reusing Web services refers to good governance in SOA lifecycle. The proposal is very enterprise oriented and consists of using a common language with consistent business term to describe services, governing new service creation and discovery of existing services, providing assurance to both service users and owners and supporting new requirements against existing services. Following the same idea, the proposal in [START_REF] Chu | Design web services: towards service reuse at the design level[END_REF] considers designing reuse-oriented Web service through a top-down process by modelling business requirement as business processes, breaking them down and identifying fine-grained requirement before the real service design. These two solutions may be applied efficiently in supervised and inter/intra-corporate environment where business terms can be controlled by internal glossary or domain ontology; business processes are predefined, imposed and slightly evolving, and expertise in SOA governance is present. In contrary, public Web services use the Internet, and the latter represents an unsupervised environment but focuses more on end users. Therefore, applying the aforementioned concepts to public Web services may not bring interesting outcome.

Besides, another work is interested in providing reusable data-centric Web services [START_REF] Saleh | A reusable model for data-centric web services[END_REF]) through a formal specification of Web service model. Their model attempts to deal with the interpretation of data that must be marshalled between service consumers and producer systems. It is again an answer to reusability of a specific kind of Web service and may not cover all existing categories found among public Web services.

Nonetheless, Bechara and Feuerlicht and Wijayaweera (2007) consider reusable Web services as respecting some general criteria:

• Loose coupling: between services, it refers to minimal dependency among them and between providers and consumers; it means that the service providers shall hide service implementation detail from their consumer by using standard interface (e.g. WSDL, SOAP messages). • Functional cohesion: a service can contain several operations, and each of them should execute a specific task in order to guarantee the modularity of services. • Granularity: it is normally hard to achieve. Coarse-grained services return the result after aggregating several response messages. They are then easy to identify. Fine-grained services execute elementary function. They need more breakdown to identify lowest-level elementary actions that they will implement.

• Statelessness: it refers to the fact that during its execution, a service does not wait for any event or callback. There should not be any temporary state during a service execution because it can be very costly to take into account such states. • Autonomy: it refers to autonomous resource usage of a service (e.g. databases, documents). • Discoverability: ability of a service to be identified given a user request that expresses his/her requirement. • Composability: ability of a service to participate in a composition or a mashup scenario given a requirement.

From user point of view, we reduce these reusability criteria into usability, discoverability and composability. Usability covers, in effect, loose coupling, functional cohesion, granularity, statelessness and autonomy. This criterion (usability) requires works from service providers to realize, particularly in service design time. Once a service respecting this criterion is published and deployed, it should only be or seen as runnable or executable by consumers via testing or try interface provided by service providers. Thus, service usability is designed by service providers and perceived by consumers.

Discoverability and composability, however, can depend both on textual documentation and/or semantic annotation that service providers attach with their services. The mentioned supplementary information can be consulted by service end users but may submerge them into technical difficulty in interpreting or understanding how to use the documented or annotated services. We are facing problems related to common terminology and domain ontology usage between service providers and consumers. Moreover, expertise at both sides is needed in order to work coherently on the service semantic annotations and to construct correct semantic discovery or composition requests.

In the actual work, we choose to tackle the public Web service reusability from end-user point of view by encouraging end users to express their service usage experience for the benefit of the others in the community. We initiate our proposal based on the following observation (see Fig. 50.1): We consider that end users can observe what happens when they use a service and can report what goes through their perceptions to the others and make them taking profit from previous usage experiences to enhance on one hand the reusability of Web services and on the other hand provide real situational meta-data on published Web services to their communities. Our approach is oriented to socially provided service semantics as advocated by [START_REF] Averbakh | Exploiting user feedback to improve semantic web service discovery[END_REF], [START_REF] Jansen | Pragmatic and opportunistic reuse in innovative start-up companies[END_REF], and [START_REF] Leitner | Selecting web services based on past user experiences[END_REF]. We then have to provide possibilities to end users, allowing them to express their usage experience in a simple way and to exploit those experiences to promote public Web service reusability.

Expressing Service Usage Experience

We define the process of providing service usage experience as a socialization one. It is based on a simple observatory hypothesis which is "more a service is socialized, more it has been tested or tried". If a service is repetitively used in various situations, then it is considered as reusable. In this case, functional aspect interests us more than non-functional one. In effect, the latter is often use to compute the selectivity of Web services.

We opt for collaborative socialization process, i.e. users can comment on the services they have been using, and those comments are available to other users. Comments from different users on a service are aggregated to reflect the importance of the commented service. Thus, collaborative tagging [START_REF] Papathanasiou | Combining service models, semantic and web 2.0 technologies to create a rich citizen experience[END_REF]) is a relevant option for expressing this kind of feedback after using, testing or trying a service.

A service (taggable object) can be tagged by several users with several tags. A tag can be used by several users to tag several services. Therefore, the tagging model can be summarized as a triplet <User, Tag, TaggableObject> (see Fig. 50.2). The model illustrated above can be stored in the folksonomy base in our supporting system.

Expressing a service usage experience consists then of reporting on it usage situation, what operation has been used, what input is required and what output is produced. Such information can be observed during a test or a try on a service.

According to the structure of WSDL that is normally used to describe Web services, a Web service can be considered as an object that can be parsed into several operations, and each of them is respectively into several pairs of input and output. We allow end users to express such features related to a service they used in their usage experience by focusing particularly on the functional capacity of the service (see Fig. 50.3).

Using tags is both flexible and easy for nonexpert consumers. However, synonymy of terms can generate ambiguity in providing the correct meaning of a used term. Therefore, our tag is associated with a meaning. Each tag has a weight which is its occurrence number, and this weight reflects the importance of the tag related to the tagged service. We impose a simple tagging convention by using ";"a s separator, "{}" as block definition and "_" for multiple term tag (see Fig. 50.4 for an example: {flight, sense{flight, 0}, 10} means that the tag "flight" is associated to the first meaning found in the term meaning base (indexed by 0) and is tagged 10 times on the service).

The next section depicts how we can exploit the user-provided annotation on Web services to promote and enhance the reusability of public Web services. We emphasize on the fact that a reusable Web service is most likely usable, discoverable and composable. These criteria should be perceived by end users within public Web service lifecycle in order to encourage them to use and then reuse the published Web services.

Public Web Service Reuse Supporting Framework Architecture

The main goal of this supporting framework is twofold: service providers can use it to advertise their published Web services with help from end-user community by making their service more and more usable, discoverable and composable. Service consumers, via this framework, should be able to test, try, use, discover, compose, substitute and annotate published Web services (see Fig. 50.5). Retriever module allows end users to discover tagged Web services based on tags. Looking up Web services this way is more extensive and richer than using simple keyword because in our case, tags are disambiguated and bundled into a structure. We then exploit the lexical and structural information related to the searched services. Moreover, inside the service usage experience expression, usage situation is given, and it can help enhance the quality of discovery process. A discovery request must be formalized as how tags are organized around services. It is represented by four tag vectors (usage situation, operation, input and output), but each tag item has no weight (see Figs. 50.8 and 50.9). Tag-wise similarity is the core of the discovery algorithm, and we define that two tags are identical if and only if they share the same meaning and the same term. Two tags are similar if they have synonymy relatedness or their meanings reveal a certain degree of textual similarity (e.g. computed by co-occurrence, cosine, Jaccard or dice measures) [START_REF] Cattuto | Semantic grounding of tag relatedness in social bookmarking systems[END_REF].

Recommender module can be used as the extension of the three above modules. Its role is to exploit the co-occurrence between tags, determine which tag appears frequently with another, compute closeness of user profile generated from tagging activity in order to propose similar service tagged by user having the similar profile and propose other services tagged by similar tags.

Composer module allows end users to establish a visual composition of a number of services by drag-and-drop actions. After a service is dropped in the composition space, the system has to look up for the most appropriate candidate to pipe from its output by exploiting the exact or similar tag match. This module is served as a concept-proof of likely composability of a chosen service. It is still very hard to achieve real composite services this way due to input, output and constraint on manipulated data type.

Conclusion and Future Works

The main contribution of this chapter lies in the identification of service reusability features. We then propose a tagging model allowing service consumers to express their usage experience by using tags. We bring in the concepts of using tags to enhance or promote the likely usability, discoverability and composability of services. We propose also some service recommendation mechanisms and the concept of visual service composition.

Then, we provide the architecture of a supporting system that allows end users and service providers to easily enhance and promote public Web service reuse. It can also be a potential candidate to be employed for realizing different tasks such as:

• Web service discovery at design time: service-oriented application engineers can dispose of such system to assist his/her task in finding services that are relevant to the functional requirement of clients However, dealing with tags provokes some issues also such as tag bombing or tag spamming. We do not tackle such issues in the scope of this chapter.

As the perspective of our proposal, technical issues need to be studied in order to implement an appropriate system based on our aforementioned architecture. Several elements need to be considered such as the complexity of tag disambiguation process, the quality and scalability of service discovery and composition based on tags. Service recommendation process should be studied in more detail in order to exploit the minimum amount of data for the acceptable results.

To sum up, we attempt to promote the likelihood of public Web service reuse by socializing those services. Service providers can take benefit from such approach without heavy additional work. End users are however encouraged to express their service usage experience in a collective and collaborative environment in order to promote service reusability.

Fig. 50 . 1

 501 Fig. 50.1 Public web service lifecycle seen by end users

Fig. 50. 2

 2 Fig. 50.2 Folksonomic tagging model

Fig. 50

 50 Fig. 50.6 User-system interaction while expressing a service usage experience

Fig. 50

 50 Fig. 50.7 User-system interaction while browsing a tag for services or users

Fig. 50 . 8

 508 Fig. 50.8 Discovery request model

Fig. 50 . 9

 509 Fig. 50.9 Textual example of discovery request

  . Such system allows engineers to browse different services in the enterprise collection by simple tags and formulate easily his/her request by just following a simple guide. Usage experience of services can be shared among engineer community to improve the reuse of locally available Web services, if those engineers care enough participating in the tagging activities after testing or using the services.• User-assisted Web service composition: when a user would like to have on-time effects or interventions on the composition of Web services, he/she can check the tag clouds at his/her disposal for atomic service that responds to his/her prompt need in order to create his/her composite service. The need formulation is easy, and our tagging model favours the annotations on input/output of Web services which are habitually useful for the composition process. • User-oriented and semi-automatic Web services clustering or classification: with the increasing number of tags on functionality of services provided by users, the

	Find a service:
	+ used in: { {flight, sense<flight, 0>};
		{confirmation, sense<confirmation, 0>}
	}
	+ with an operation performing: { {send, sense<send, 0>};
		}	{sms, sense<sms, 0>}
	+ by consuming: {	{flight, sense<flight, 0>};
		{number, sense<number, 0>};
		{phoneNumber, sense<phoneNumber, null>}
	}
	+ and producing: { {sms, sense<sms, 0>};
		{flight, sense<flight, 0>};
		{schedule, sense<schedule, 0>}
	}

http://webservices.seekda.com

http://wordnet.princeton.edu

http://commontag.org/Home

http://dbpedia.org/About

This system is divided into several modules. It also depends on a tag sense base that contains not only a terminological relationship base between tags such as synonym but also for each tag an array of possible meanings associated to that tag. Several existing lightweight knowledge bases or thesaurus can be used to


Uddam Chukmol

Aïcha-Nabila Benharkat

Youssef Amghar

An approach for Web service discovery based on collaborative

Keywords: Web Service Discovery, Structured Tagging, Semantic Annotation, Folksonomy, User-centricity Frequency Auto 5 Mobile 10 Transport 15 Vehicle 3

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

INTRODUCTION

Web service discovery is a major operation in the development cycle of service-oriented applications. It consists of identifying services having functional capabilities that are relevant to user needs. The increasing number of Web services makes this task even more complicated.

The existing solutions to this problem are often based on information retrieval techniques (IR) which suffers due to poor textual description of Web services or semantic Web technologies. Keyword search applying IR technique seems to be inefficient because of the poor textual description of Web services. Semantic Web technologies, if they are applied within Web service discovery processes, require the extension of original Web service description with ontology-based annotations. The latter hinders not only the service providers but also the service users because the competence in ontology or cognitive engineering is necessary to master the process and to maintain the systems. Besides, very few attempts consider the post-usage information provided by service users to enhance incrementally the process of Web service discovery.

Our proposal is inspired by the user centricity and collaboration found in Web 2.0 environment that aims at generating descriptive data associated to a Web resource (image, document, video, etc.) and the fact that other users exploit this evolving data to share and classify online resources.

Within our research case, users can tag/annotate a Web service that he/she has used with his/her own vocabularies. By analyzing the functional characteristics of Web service through numerous WSDL contents, we propose a specific structural tag/annotation model that takes into account the capability of Web services and their usage domain. We can consider that our tagging approach is based on a folksonomic model that combines the participation of users and the richness of their vocabularies used in tagging process with the structural aspect of annotation met in semantic Web technologies.

Tagging provided by users is not used to extend literally the original content of Web services expressed in WSDL but associated to the invocation URL of the service. We propose consequently a Web service retrieval system that makes use of this data, aggregates them when they are issued from different users and offers a mechanism to search for Web services and rank the output result.

In order to reinforce the quality of discovery and help users in the selection of found Web services, a user profiling scheme is approached and it is served as information that our system further processes to propose user reputation and tag recommendation.

The paper is organized as follows. Section 2 presents the related work. Section 3 describes our system including tagging and query model, tags aggregation, retrieval algorithm, result ranking and user profiling. Section 4 shows the strategy that we opt for evaluating our system performance and Section 5 concludes the research work and envisions its future perspectives.

RELATED WORK

The emergence of collaborative tagging system [START_REF] Golder | The Structure of Collaborative Tagging Systems[END_REF] and the abandon of UDDI registry development by its initial creators benefit the increasing number of Internet Web service portals or catalogs (Chen [START_REF] Wu | Searching Services "on the Web": A Public Web Services Discovery Approach[END_REF], [START_REF] Al-Masri | Discovering Web Services in Search Engines[END_REF] and facilitate a lot the service suppliers in terms of publication and maintenance. They also allow users to use a single common search interface to look up for different services published by various suppliers.

Traditional information retrieval (IR) or natural language processing (NLP) techniques perform poorly when they are used to solve Web service discovery problems due to insufficient textual descriptions of Web service WSDL contents [START_REF] Garofalakis | Contemporary Web service discovery mechanisms[END_REF]. They also do not seem to be scalable enough and offer low search precision rate.

Besides, semantic Web community offers another alternative solution to this discovery problem by proposing several semantic annotation techniques based on ontology or logical formalisms such as WSMO ("Web Service Modeling Ontology"), OWL-S ("OWL-S 1.2 Release"), WSDL-S ("Web Service Semantics -WSDL-S"), SAWSDL ("Semantic Annotations for WSDL and XML Schema") and WSMO-Lite [START_REF] Kopecky | WSMO-Lite: Lowering the Semantic Web Services Barrier with Modular and Light-Weight Annotations[END_REF]. They aim at allowing software agents to operate Web service discovery automatically at runtime (on-the-fly) when needed by primarily extending WSDL contents of Web services by semantic annotations. Without automatic semantics annotation process, they may bring more burdens to service suppliers. In effect, on one hand, they have to be competent in cognitive or knowledge engineering in order to master completely the semantics designs and annotation process and on the other hand, they have to choose among the existing aforementioned formalisms the one that suits them best without bringing more cost and effort in training to their service engineers. More effort is also needed to propose semantic-aware service portals or registries in which services can be published and Web service discoveries can be run seamlessly and successfully. Additionally, with multitude semantic annotation formalisms, rare, if not to say, none has proposed such semantic supported registries yet and users of such systems have to be apt in constructing their discovery queries conforming to the imposed semantic annotation formalism from the providers. Despite the theoretical efficiency proved by different semantic Web service discovery proposals, they are struggling at getting widely adopted by real world service industries [START_REF] Shi | Semantic Web Services: An Unfulfilled Promise[END_REF].

Some discovery methods exploit the data offered implicitly or explicitly by users such as preference or feedback on services. Service usage data is collected throughout a framework based on Implicit Culture via a deployment of a client-server system and used to improve further Web service discovery in [START_REF] Birukou | Improving Web Service Discovery with Usage Data[END_REF]. At the user side, a client application must be installed to report the way Web services are used to the server. This behavioral information is the processed to compute the similarity between user's request and the set of used and stored services. The system might fail due to the increasing number of users and can be sensitive to confidentiality and privacy policy at client side. Preference of user can be treated as non-functional information to help improve the quality of service discovery, such in [START_REF] Kovacs | Handling User Preferences and Added Value in Discovery of Semantic Web Services[END_REF] where Web services and user's requests need to be enriched with specific logic based formalism in order to compute the similarity through a Prolog-based inference engine. [START_REF] Lamparter | Preference-based selection of highly configurable web services[END_REF] extend original Web service descriptions and discovery queries with semantic data expressed in OWL conforming to their developed preference ontology before proceeding to service-request similarity computing. However, they oblige users to express the queries in logic based or ontology format and finally increase effort, time and investment of service suppliers to extend the descriptions of their published services.

Users are allowed to express their service usage satisfactions as tags (keyword tokens) in [START_REF] Leitner | Selecting Web Services Based on Past User Experiences[END_REF]. Those tags are used to qualify the non-functional constraints of services. These constraints are then exploited to help in the selection of retrieved and used services. Simpler method is adopted in [START_REF] Averbakh | Exploiting User Feedback to Improve Semantic Web Service Discovery[END_REF] by allowing users to rate (as a score) Web services referring to some queries. These ratings are then exploited to enhance the service discovery quality. These approaches seem strongly to be more appropriate to Web service selection rather than discovery because no functional characteristics of services can be reflected and expressed within their proposals. [START_REF] Hagemann | Web Service Discovery -Reality Check 2[END_REF] recommend users to associate semantics to Web services using tags -those are considered more light-weight and accessible to real world use comparing to semantic annotations in ontology-based formalisms. Such annotation is introduced in [START_REF] Meyer | Light-Weight Semantic Service Annotations Through Tagging[END_REF]. Then, by taking into account the user collaborations, [START_REF] Chukmol | Enhancing Web Service Discovery by Using Collaborative Tagging System[END_REF] propose a Web service discovery method based on such collaborative and folksonomic annotation.

Nonetheless, most of the latter makes use of flat tags without any structure, relation or hierarchy. Thus, it is still vague to consider that such tagging can be used to reflect the functional capability of Web service.

By considering all the drawbacks and advantages met in analyzed related work, we are convinced that through usage experiences, the quality of Web service discovery can be notably improved by exploiting post-experience data provided by users referring to services. This Web 2.0 style of lightweight semantic provision is not costly and can be processed in a bottom-up and minimalistic way. In effect, service suppliers are not forced to invest in such process of semantic annotation and more interesting semantics can be extracted from real user perception on services.

In this research work, we are going to propose a method for Web service discovery based on Web 2.0 collaborative tagging. Our tagging model is easy to use and respects a structure that can reflect the functional capability of services. A simple yet efficient aggregation of tags is also proposed in the overall system.

SOLUTION OUTLINE

A number of definitions related to Web service, tag, query and user are proposed in order to facilitate the further comprehension of our proposal.

Defining Web Service

Functionally, a Web service, through WSDL, can be briefly defined as: Definition 1. A Web service w is a triplet w<name, doc, ope>, where name is the service name corresponding to the attribute name of <definition> tag of WSDL, doc is the functional description of Web service corresponding to the <documentation> tag of WSDL and ope is the list of operations of Web service corresponding to <operation> tags of WSDL. Definition 2. An operation ope is quadruplet ope<OName, ODoc, In, Out>, where OName is the operation name corresponding to the attribute name of <operation> tag, ODoc is the description of the operation corresponding also to the <documentation> tag under <operation>, In is the list of input parameters of the operation corresponding to <input> tags and Out is the list of output parameters of the operation corresponding to <output> tags.

Each input and output parameter has a name and a data type.

Our tagging model aims at expressing with the maximal ease of use the aforementioned functional capability of Web services. We allow users to express the contexts of service within their tags also. In effect, it is important to bring forward the usage experience perception of the service and share them with other users. This may lead to more clarity in understanding the situation in which a service is successfully used and can respond at best to the requester's needs.

Through the above definitions, there can be several basic operations or functions a service can offer. Each operation can also be described by users as atomic function offered by the incorporating service. However, if we consider only such operation by itself, it can be used in different situation (e.g. an operation GetCityWeather that outputs the weather forecast report given a city name can be invoked in the situation of "Holiday Preparation" or "Wedding party organization").

More detail can also be added to make an operation more precise. The operation profile can also described by a set of inputs and outputs.

Defining Tag and Query

Therefore, according to the aforementioned functional definition of Web service, we can conformingly model our structured tag as: Definition 3. A structured tag STag is a quadruplet STag<ctxt, funct, input, output>, where ctxt contains the list of keywords separated by ;, encapsulated in "" and describing the situation in which the service is / can be used or tested. Its structure is a single dimension table indexed by keywords and each of them has a weight referring to term frequency, funct has the same format as ctxt but is for describing different operations within the service that can be used or tested, input has the same format as funct but is for describing different input parameters that service operations require to execute and output has the same format as input but is for describing different output parameters that service operations produce.

Thus, when a service is tagged by a user respecting the STag structure, it is associated to 4 keyword bags (a.k.a. cloud) -see Figure 1. Hypothesis 1. A query q has the same structure as the tag STag defined in Definition 3.

Our annotation or tagging model can be considered as a folksonomy F defined by F ⊆ U × T × R where U refers to users, R refers to resource that is Web service description file in our case and T refers to tags (conforming to STag structure defined in Definition 3) provided by user U and associated to resource R. Our tagging process is collaborative which means that many users can annotate a Web service by using their own tags. The annotations are visible to other users in the system. Annotated Web services are also accessible to the system users. Therefore, in our system, each Web service is associated to 4 tag clouds and each of them represents accordingly each element of STag (context, function, input and output).

Tag Aggregation Algorithm

When there are several users annotating a Web service, these annotations are aggregated. Each element of STag structure is considered respectively and separately. Thus, the 4 tag clouds associated to a service evolves through the tagging activity from users.

The aggregation between two STags can be expressed by the following algorithm: Let STagA and STagB two structured tags (STag) provided by two users A and B to annotate the Web service ws.

Let STagAgg the structured tag resulted from the aggregation of STagA and STagB.

After the aggregation, STagAgg is the only tag that is associated to ws. We can define STagAgg as follows: STagAgg=aggregate(STagA, STagB). We detail only the merging of ctxt elements of STagA and STagB because it is applied exactly to other elements. We would like to recall that ctxt is a single dimension table indexed by keywords and each of them has a weight (see Definition 3). Suppose that c i is a keyword and an index of ctxt and cw i the weight of c i ; then ctxt[c i ]=cw i . Therefore, merging STagA.ctxt and STagB.ctxt can be described by:

User, Tag and Web Service Relation

We illustrate the different relations between each element (user, tag and Web service) of our folksonomy model with the goal to further exploit them in computing of similarity between a discovery request and the corpus of our tagged Web services.

The relation between Web services and tags or annotations in our system is the space of 4 twodimension tables indexed by keywords and Web service identifier (access path to its WSDL file). Each table corresponds to every element or part of the STag structure. We can model them as:

TabCtxt WS (Ctxt×WS) where Ctxt is the list of keywords provided by users to annotate the contextual part of a structured tag associated to a service and WS is the list of annotated Web services. Given a keyword c i ∈Ctxt and a Web service ws j ∈WS, TabCtxt WS [c i , ws j ] is the frequency of the term c i that is used to annotate the usage context of ws j .

TabFunct WS (Funct×WS) where Funct is the list of keywords provided by users to annotate the operation part of a structured tag and WS is the list of annotated Web services. Given a keyword f i ∈Funct and a Web service ws j ∈WS,

TabFunct WS [f i , ws j ] is the frequency of the term f i that is used to annotate the operations of ws j .

TabInput WS (Input×WS) where Input is the list of keywords provided by users to annotate the input part of a structured tag and WS is the list of annotated Web services. Given a keyword in i ∈Input and a service ws j ∈WS, TabInput WS [in i ,

ws j ] is the frequency of the term in i that is used to annotate the input parameters of ws j .

TabOutput WS (Ouput, WS) where out i ∈Output is the list of keywords provided by users to annotate the output part of a structured tag and WS is the list of annotated Web services. Given a keyword out i ∈Output and a service ws j ∈WS,

TabOutput WS [out i , ws j ] is the frequency of the term out i that is used to annotate the input parameters of ws j .

The relation between users and tags is also a space of 4 two-dimension tables indexed by keywords and user identifiers because it refers to services tagged by users. We define the 4 tables as:

TabCtxt USER (Ctxt×User) where Ctxt is the list of keywords provided by users to annotate the contextual part of the structured tags associated to Web services and User is the list of system annotating users. Given a keyword c i ∈Ctxt and a user u j ∈User, TabCtxt USER [c i , u j ] is the frequency of the term c i that is used by the user u j to annotate the usage context of the system Web services.

TabFunct USER (Funct×User) where f i ∈Funct is the list of keywords provided by users to annotate the operation part of the structured tags associated to Web services and User is the list of system annotating users. Given a keyword f i ∈Funct and a user u j ∈User,

TabFunct USER [f i , u j ]
is the frequency of the term f i that is used by the user u j to annotate the operation part of the system Web services.

TabInput USER (Input×User) where in i ∈Input is the list of keywords provided by users to annotate the input part of the structured tags associated to Web services and User is the list of system annotating users. Given a keyword in i ∈Input and a user u j ∈User, TabInput USER [in i ,u j ] is the frequency of the term in i that is used by the user u j to annotate the input parameters of the system Web services.

TabOutput USER (Ouput×User) where Output is the list of keywords provided by users to annotate the output part of the structured tags associated to Web services and User is the list of system annotating users. Given a keyword out i ∈ Output and a user u j ∈User, TabOutput USER [out i , u j ] is the frequency of the term out i that is used by the user u j to annotate the input parameters of the system Web services.

The relation between users and services is the simplest because it can be modeled as a twodimension table: TabUser WS (User×WS) where User is the list of system annotating users and WS is the list of annotated Web services. Given a user u i ∈User and a Web service ws j ∈WS, TabUser WS [u i , ws j ] is the frequency number of how often the user u i annotates the service ws j . However, based on the Hypothesis 1, a discovery request Q issued by user can be modeled as a space of 4 single dimension tables indexed by keywords such as: We are going to discus in more detail about how to discover Web services using collaborative structured tags.

TabCtxt(Ctxt)

Web Service Discovery based on Collaborative Structured Tagging

Let Q a discovery request expressed by a user and aWS∈WS an annotated Web service in the tagged Web Service collection denoted by WS. aWS is discovered by Q if and only if there is a similarity degree between Q and its structured annotation ∈ [0, 1].

Therefore a Web service aWS is represented in this similarity computing by its structured annotation denoted as STag aWS .

According to Hypothesis 1 and section 3.4, we can present Q and STag WS as follows:

Q <TabCtxt, TabFunct, TabInput, TabOutput> STag aWS <TabCtxt WS [Ctxt, aWS], TabFunct WS [Funct, aWS], TabInput WS [Input,aWS],

TabOutput WS [Output, aWS]> Each element of STag aWS is a single dimension table because it is a two-dimension table with a unique column indexed by aWS.

The similarity of a Web service aWS (represented by STag aWS ) and the query Q is the weighted sum of four basic similarities: simCtxt(TabCtxt,TabCtxt WS [Ctxt, aWS]): the context similarity between Q and STag aWS . simFunct(TabFunct,TabFunct WS [Funct, aWS]): the operation similarity between Q and STag aWS . simInput(TabInput,TabInput WS [Input,aWS]): the input similarity between Q and STag aWS . simOutput(TabOutput,TabOutput WS [Output, aWS]): the output similarity between Q and STag aWS .

Each basic similarity value is ∈ [0,1]. We use 4 coefficients associated to each similarity and their sum is 1: coeff_ctxt ∈ [0,1] is the coefficient for usage context similarity, coeff_funct ∈ [0,1] is the coefficient for operation similarity, coeff_input ∈ [0,1] is the coefficient for input similarity and coeff_output ∈ [0,1] is the coefficient for output similarity. Thus, the final similarity is computed by:

similarity = coeff_ctxt*simCtxt + coeff_funct*simFunct+ coeff_input*simInput+ coeff_output*simOutput; (1)
According to the previous modeling of STag aWS and Q, each basic similarity can be computed by using the vector space similarity. Some analytic studies recommend using term frequency as the weight of each keyword representing the context (respectively operation, input and output part) of STag aWS . In effect, keyword distribution in collaborative tagging systems often respects the Zipf's power law [START_REF] Halpin | The complex dynamics of collaborative tagging[END_REF] [START_REF] Robu | Emergence of consensus and shared vocabularies in collaborative tagging systems[END_REF] where a few representative tags cover most of the distribution. We grant more importance to most frequently used tags to represent the tagged resource. Thus, the basic similarity between the context (respectively operation, input and output) part of the STag aWS and the context (respectively operation, input and output) part of the query Q is: The detail of the cosine measure of similarity between two term vectors can be consulted in (D. [START_REF] Manning | Introduction to Information Retrieval[END_REF] and [START_REF] Markines | Evaluating similarity measures for emergent semantics of social tagging[END_REF].

In order to illustrate this basic similarity computing, we propose a case example as follows:

Let:

V WS =STag aWS .TabCtxt [Ctxt,aWS]: the context part vector of the structured annotation associated to the service aWS. The cosine measure of similarity between V Q and V WS can be computed as:

cosine(V Q ,V WS )= 2 2 2 2 2 2 1 1 3 15 10 5 1 3 1 15 0 10 0 5 + × + + + × + × + × + × cosine(V Q ,V WS )=0.95.

Result Set Filtering

The result set of the discovery is ranked by the overall degree of similarity (see ( 1)). Users are allowed to filter this result set in order to keep the Web services that interest them only.

We propose two types of filtering: by threshold and by user implicit profile.

Filtering by Threshold

This is the simplest yet efficient way of filtering a retrieval or discovery result. It consists of eliminating any discovered Web service in the result set whose global similarity value given the requestor's query is below a limit value threshold. This latter can be defined by user him/herself or proposed by the discovery system.

Filtering by User Profile

A user signs up to the system by providing his/her personal information (name, address, email, signature, etc.) and his/her working domain or expertise domain. This latter can be described using a list of keywords (e.g. "networking"; "databases"; "administration").

While the user's personal information is mainly used by the system to authenticate a user, keyword set related to expertise domain is evolved according the way user employ the system (i.e. how often a user tags? What tags does a user add? How many Web services a user tags?, etc.)

The implicit user profile in our study case has the same structure as the annotations of Web service (see Definition 3). Therefore, a user profile is just a structured annotation that is generated implicitly and is changed throughout time and the tagging habit or behavior of the user.

We opt for simple method for generating such profile by taking into account the top k keywords used regularly by the user to tag Web services. k is an integer value that is computed automatically by the system and it is variable for different part of profile information (i. e. usage context, operation, input and output). In effect, an active user that tags more often different Web services with the converging set of vocabularies can be described or profiled by those frequent terms.

We discuss in more detail how k related to usage context part of the profile is computed and how this part of profile is generated as follows.

Assume that the profile of a user u is defined by ImProf(u)=<TabCtxt [Ctxt, u], TabFunct [Funct,u], TabInput [Input, u], TabOutput [Output, u]> where:

TabCtxt [Ctxt, u] is the usage context vector associated to the profile of user u, in which Ctxt is the list of keywords used to describe the usage context part of the profile and TabCtxt[c i ,u] is the frequency of the keyword c i ∈Ctxt used by the user u in his/her overall tagging activities on the usage context part of Web service collection.

TabFunct [Funct, u] is the operation vector associated to the profile of user u, in which Funct is the list of keywords used to describe the operation part of the profile and TabFunct[f i ,u] is the frequency of the keyword f i ∈Funct used by the user u in his/her overall tagging activities on the operation part of Web service collection.

TabInput [Input, u] is the input vector associated to the profile of user u, in which Input is the list of keywords used to describe the input part of the profile and TabInput[in i , u] is the frequency of the keyword in i ∈ Input used by the user u in his/her overall tagging activities on the input part of Web service collection.

TabOutput [Output, u] is the output vector associated to the profile of user u, in which Output is the list of keywords used to describe the output part of the profile and TabOutput[out i , u] is the frequency of the keyword out i ∈ Input used by the user u in his/her overall tagging activities on the output part of Web service collection.

We are going to illustrate only how to compute the user context part of the profile for the user u. The other parts of the profile are generated by the same way. After generating the profile, we consider it as a filtering query that is used with the result set of discovered Web services annotated by structured tags. The same similarity computing in (1) is used to calculate the distance between the requestor's profile and the set of discovered Web services.

Initiation of Discovery System

When the proposed discovery system is at its initial state, there are two particular tasks that need to be done automatically:

Creating Structured Tags Automatically

We can parse the WSDL content of each service and extract only the WSDL tags (e.g. <documentation>, <operation>, etc.) or their attributes that corresponds to each part of our STag structure. For the primary version of this proposal, we adapt the string tokenization method of (Natallia [START_REF] Kokash | A Comparison of Web Service Interface Similarity Measures[END_REF] to create keywords lists for different parts of the structured tagging associated to the corresponding service.

The initial structured annotation is evolved when the tagging activities of users increase.

Creating Initial User's Implicit Profile

When a user is signed up, except from prompting him from offering his personal information (name, address, mail, signature, etc.), a list of keywords describing the working or expertise domain of the user is required. These keywords are affected directly to the usage context part of the user's implicit profile because they are susceptible to describe best the situations in which the user can employ the services.

User is recommended to have a digital identifier to facilitate and reinforce his/her authentication with the system. Digital signature based on OpenID ("OpenID Foundation") seems strongly to be an interesting candidate model that we further take into account.

To partially sum up, the proposed system suits best semi-automatic and user-centric or user-assisted discovery of Web service where users can participate and collaborate with each other to make public knowledge on the usage of Web services emerge and exploitable to further enhance the discovery quality. It is recommended that users test or use at least once a service Web before annotating it with our structured tagging. By doing so, he/she has a clearer idea and perception of what feed back or annotation he/she should attach to the Web service. A prototype of our system is under development and we have proposed a strategic evaluation of this system that is discussed in the next section.

APPLICATIVE SCENARIOS OF THE DISCOVERY SYSTEM

SYSTEM EVALUATION METHOD

The performance of our discovery system can be evaluated from several points of view, notably (i) Tags: tag quantity can be the first parameter to let us know more about the quality of discovered services.

The evolution of tag quantity needs to be followed up for comparing the evolution of system performance (ii) Users: user participation is to be considered in terms of tagging provision and frequency. This participation can influence the tag quantity and quality also. We would like to study the evolution of implicit user profile and determine if this profile can be stable through continuing tagging activities. It is also important to verify if the way we recommend using user's implicit profile can improve the discovery result set (iii) Basic Similarity Coefficients: our system computes the overall similarity between a query and an annotated Web service based on 4 coefficients. A tuning mechanism of these coefficients is important so that at the initial state of the system, coefficients by default are suitably proposed to users (iv) Precision/Recall rate: High precision and low recall rates signify good performance of the system. (v) Term Weight: term frequency is used as weight in our case but there are also many more ways to compute term weight such as shown in (D. [START_REF] Manning | Introduction to Information Retrieval[END_REF] and [START_REF] Markines | Evaluating similarity measures for emergent semantics of social tagging[END_REF]. We would like to define practically the best term weight computing that can yield the best precision/recall rate of discovery (vi) Similarity Measure: cosine similarity measure is used in our system because in general case, this measure outperforms other measures. However, [START_REF] Markines | Evaluating similarity measures for emergent semantics of social tagging[END_REF] recommends other measures also such as Pearson, Dice or Jaccard. We would like to verify if these three latter can outperform the cosine measure. These are the specification that we follow to evaluate the performance of our under-development prototype. We particularly accentuate our effort in examining the precision/recall rates because they are obvious indicators of a retrieval system.

CONCLUSIONS AND FUTURE WORKS

In this research work, we have described a structured tagging method of Web service that covers and expresses the functional capability and the usage context of the service easily. A Web service discovery system based on collaborative structured tagging is proposed to exploit the aforementioned tags to enhance the Web service discovery process. Tags issued from different users on a Web service are aggregated according the bag-of-word model. We also propose a query model that takes the exact form as a tag for users in order to search for Web services relevant to their need.

The similarity of a query and an annotated Web service is computed based on four basic similarities: usage context, operation, input and output similarity. Each one of them corresponds to a composite part of our proposed tag model. This kind of query and annotation is expressive enough and very easy to construct and use in the task of discovering or tagging the Web services. The proposed basic similarities reflect the degree of relatedness between a query and the functional capability of a Web service, in case that the service is annotated. Finally, the overall similarity degree between a query and an annotated Web service is calculated a weighted sum of the four basic similarities mentioned above.

We use four coefficients respectively for computing the overall similarity because they can allow users to tune the result sets of their discovery request and give them more flexibility to improve the quality of their discoveries by just according more importance to a specific part describing the functional capability of services, i. e. usage context, operation, input or output.

The discovered services are ranked according to their similarity values down from highest to lowest values. Users can, however, filter this result set with a defined or pre-defined threshold value to eliminate the non-interesting, irrelevant or ignorable discovery candidates. We offer another method of filtering based on implicit user profile. The latter is gradually built and evolved through the tagging activities of the user. Finally this profile gives more important to a user according to his/her tagging frequency, tag quantity and annotated Web service number. The implicit user profile takes the form a refining query. The filtering processing based on this profile is no other operation than computing the similarity between the user profile and the set of already discovered services. We apply the same discovery algorithm in both cases: overall similarity computing between initial discovery query and annotated Web services and filtering based on user implicit profile and discovered service candidates.

Then we propose some applicative scenarios in which our approach can be employed and recommend a strategic evaluation on our underdevelopment prototype.

Despite the ongoing work on this discovery engine, we envisage some future extensions of the system and future directions of the research work already such as (i)Treating free text (document) respecting minimally our tagging model as the tagging data (ii)Tag disambiguation (iii) Alternative discovery algorithm (iv) User profile and reputation (v)Result ranking and (vi) Lowering ontology to tags.

Based on our heuristic proposal, it seems strongly plausible that Web service semantic annotation become a much easier task for service suppliers or requestors, the service discovery quality can be enhanced based on this kind of annotation. Nonetheless, users are strongly encouraged to participate in the usage or testing of services before he/she tags them with our proposed tagging model. Participative data provided by users are crucial source for our approach to process the degree of semantic correspondence between a request and an annotated Web service and for building up user profile that is used in the result set filtering task.

It is finally very possible to combine our approach with the exploitation of other semantic annotations to propose a better Web service discovery system.

Figure 1 :

 1 Figure 1: A Web service tagged by STag.

  merge(STagA.ctxt,STagB.ctxt) { //initialize STagAgg.ctxt with //STagA.ctxt STagAgg.ctxt.Init(STagA.ctxt); Foreach c of STagB.ctxt { If c not in STagAgg.ctxt { STagAgg.ctxt.add(c); STagAgg.ctxt[c]=0; } STagAgg.ctxt[c]+=STagB.ctxt[c]; } }

  Float simCtxt(Q.TabCtxt, STag aWS .TabCtxt WS [Ctxt, aWS]) { return cosine(Q.TabCtxt, STag aWS .TabCtxt ws ,aWS]; }

  The aggregate function executes 4 merging operations on ctxt (respectively funct, in and out) elements of STagA and STagB. The ctxt (respectively funct, in and out) element of STagAgg is the result of the merging between the ctxt (respectively funct, in and out) elements of STagA and STagB. We define merge as the merging function. Therefore, each element of STagAgg can be obtained by:

STagAgg.ctxt=merge(STagA.ctxt,STagB.ctxt)

STagAgg.funct=merge(STagA.funct, STagB.funct) STagAgg.input=merge(STagA.input, STagB.input) STagAgg.output=merge

(STagA.output, STagB.output)


Hadi Harb
email: hadi.harb@ec-lyon.fr

Liming Chen
email: liming.chen@ec-lyon.fr

A Query by Example Music Retrieval Algorithm

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Retrieving a piece of music or a song from a very big database requires, until now, knowledge on the performer/artist, or the song's title, or other textual information. This kind of textual queries is efficient for the cases where users have quite precise knowledge on what they are searching for within manually indexed and structured databases. However, this classical approach can not work when users need to search music pieces in highly unstructured databases such as the web, or to discover music pieces without information on artists, or titles.

While Query by Example Image Retrieval is becoming a mature field, the Query by Example Music Retrieval (QEMR) is still in his infancy. QEMR is essential for Music on demand services since the user will be faced to hundreds of thousands of songs. A tool permitting different views of a large music database based on a musical query will be valuable for increasing the usability of those databases.

Knowing that music is generally based on notes, one can use some notebased representation to perform the similarity between a query and files in a database. Such an approach necessitates that the music data is transcribed to some symbolic representation [START_REF] Pickens | A Comparison of Language Modeling and Probabilistic Text Information Retrieval Approaches to Monophonic Music Retrieval[END_REF][START_REF] Lu | A New Approach To Query By Humming In Music Retrieval[END_REF][START_REF] Mo | A melody-based similarity computation algorithm for musical information[END_REF][START_REF] Prechelt | An interface for melody input[END_REF]. Unfortunately, there are no known robust algorithms that can transcribe polyphonic music into such a symbolic representation. Therefore the application of such algorithms will be restrained to MIDI-like formats, which is not interesting since the majority of the music data has a raw audio representation (mp3, WAV). For real world applications, a query by example system must be applicable to the raw audio data without any symbolic representation.

Alternatively, several techniques have been proposed to find similarity between audio segments based on acoustic or psychoacoustic features [START_REF] Cheng | Efficient Acoustic Index for Music Retrieval with Various Degrees of Similarity[END_REF][START_REF] Tzanetakis | Automatic Musical Genre Classification Of Audio Signals[END_REF]. These techniques are, in general, based on a modified version of general audio similarity which, however, does not convey the similarity of music.

In this paper we present a technique for Query by Example Music Retrieval (QEMR) based on local (1s) and global (20s) acoustic similarities in the aim of expressing musical similarity. For the local similarity we use distances between statistical distributions of the spectral features. Further information on the local similarity constitutes the global similarity.

Music Similarity

The similarity of music is based on subjective judgments, making it difficult to define. The same situation is observed for the definition of the term "timbre" also related to the audio perception. The timbre is defined as the feature that permits humans to discriminate two sound objects having the same pitch. We can attempt to define the musical similarity as the feature that lets a human subject create a "playlist" of music pieces based on his/her particular taste. Note that the term "similarity" in this paper is not a melody based similarity. Namely, the system we are trying to build is not aimed at judging if two musical notations are similar or not. One example of the similarity we are trying to express in this paper is the similarity between songs from the same musical genre. Musical genres are labels created by humans to facilitate the management of musical materials. These labels are assigned manually based on the perceived acoustic similarity between songs.

A study on the human performance for music genre classification shows that humans can classify with 53% accuracy the genre of a music piece when listening to a 250 ms excerpt, and this accuracy attains 70% for 3s excerpts [START_REF] Perrot | Scanning the dial: An exploration of factors in the identification of musical style[END_REF]. This means that humans judge on the similarity based on a short term and a long term basis.

Moreover, if we listen to two one second music excerpts, we can say if they are similar or not. The fact that such two short term excerpts are similar doesn't imply that they are from two similar music pieces. For example, while two segments of 1 second extracted from the same song can appear dissimilar, a similarity appears clearly when listening to two 20 seconds segments from the same song. This leads us to say that when designing a QEMR system, we must pay attention to both local and global similarities.

In order to be able to correctly assess the effectiveness of any QEMR technique within the background of real world applications, we also need to pay special attention on the composition and the size of the benchmark dataset. Indeed, if we want to approximate real application conditions, the size of the benchmark dataset should contain several thousands of music pieces according to our experiments which show that the behavior of a music retrieval technique changes with the size of the dataset. Furthermore, the dataset should be as diversified as the musical genres. In our benchmark dataset, we have 7 different music genres ranging from classic to rock. This composition of music genre leads to 600 music pieces by genre which is a minimum as compared to the huge amount of music and song titles available.

Additionally, because of the subjective nature of the similarity judgment, the evaluation is time and resource consuming. We evaluated our system based on subjective and non-subjective judgments. For the non-subjective judgments we assume that excerpts from the same musical genre are relevant for retrieval results.

Local and global similarities

Local Similarity

By local similarity we mean the similarity that a human subject would find if he/she listens to 1 or 2 seconds from two music pieces.

In our system we extract spectral vectors by means of the Short Term Fourier Transform. The original spectrum is further filtered by a filter bank containing 20 filters distributed based on the Mel scale.

To calculate the similarity between audio segments of 1 or 2 seconds, we use the KullBack Leibler (KL) distance. The KullBack-Leibler (KL) distance originates from the information theory [START_REF] Cover | Elements of Information Theory[END_REF]. It is a distance between two random variables. The original KL distance doesn't have the properties of a distance, but the symmetric KL is a distance. In the case of Gaussian distribution of the random variables the symmetric KL distance is computed by:

) 1 1 ( ) ( ) , ( 2 2 2 2 2 2 2 2 Y X Y X X Y Y X Y X KL With Y X Y X and , , ,
are respectively the standard deviation of X and Y and the mean of X and Y. In the case of audio similarity, X and Y are the set of spectral vectors obtained from window X, and window Y (1 second for the two windows in our case).

Global Similarity

We define the Global Similarity or long term similarity as the similarity that a human subject would find when listening to excerpts of 10 to 20 seconds. Assume we have two music pieces: A and B. The duration of each piece is 20 seconds. A and B can be segmented to twenty 1second segments. Any segment from A can be similar to any segment from B, thus the Local Similarity (KL distance) can be calculated between all couples from B and A. The KL distances between all couples of segments from A, and B, constitute a KL matrix that we call Local Similarity Matrix:

AB AB AB AB AB AB AB AB AB B A KL KL KL KL KL KL KL KL KL LSM 3 , 3 3 , 2 3 , 1 2 , 3 2 , 2 2 , 1 1 , 3 1 , 2 1 , 1 ,
The LSM matrix is the basis of the similarity measures that we propose to use, Figure 1.

Min Distance (MD) is the average of the three min values of the LSM. Min Distance for High Frequencies (MDHF) is the calculated as the MD of the LSM for frequencies between 1 and 4 KHZ, and Min Distance for Low Frequencies (MDLF) for frequencies lower than 1 KHZ. Sum Distance (SD) is the average of all values of the LSM. Each of the proposed features is aimed at providing one aspect of musical similarity. The final similarity measure is the average of MD, MDHF, MDLF and SD. (1)

Experimental setup

To evaluate our music similarity measure based on local and global similarities we implemented them and several experiments were carried out on a database containing 4000 music pieces from seven musical genres. The experiments are based on one non-subjective definition of similarity: pieces from the same musical genre are relevant. Also, one subjective evaluation was carried out. It consists of using the system as an automatic playslists generator based on one musical query.

Genre classification

The objective of this experiment is to study the ability of our similarity measures to find similarities between songs from the same musical genre. We recall that our technique is not aimed to be an automatic musical genre recognition system. For every genre in the database (excluding the Pop musical genre), 20 segments were chosen randomly, leading to 120 queries for genre classification on the whole database of 4000 music pieces. The genre of the music piece query is chosen to be the dominant class in the top 30 music pieces in the answer. This classification scheme can be viewed as a k-NN classification approach. Results are in Table 1. As we can see on the table, the best genre classification results are obtained for classical and rock music. Indeed, for the 20 classical music piece queries, more than 20 pieces are classical among the top 30 answers, and if we also apply the majority vote decision process, we reach a classification rate of 100%. The worst result is the Latin music classification which gives only 11 relevant labeling among the top 30 answers. This is probably due to the similar instruments used in Latin and Jazz, which leads to a confusion between these musical genres. However, in average, our technique reaches a precision rate of 81%, though the objective of our technique is not the Automatic Genre Classification of music.

Unfortunately, a comparison to other Automatic Genre Classification systems such as the ones described in [START_REF] Tzanetakis | Automatic Musical Genre Classification Of Audio Signals[END_REF][START_REF] Pye | Content-based methods for the management of digital music[END_REF] is not feasible because of the lack of a common database and musical genres for testing.

Subjective evaluation

In previous experiment the system's performance was evaluated based on nonsubjective judgments. For the subjective evaluation, four subjects were asked to use the system as a Query-by-example music search engine. The four subjects (S1, S2, S3, and S4) were musically not trained. Each subject was asked to submit five queries and then to evaluate the returned playlists by means of a score from 0-20 (0 means very bad, and 20 means very good). The results are presented in Table 2. These results show that the average score given by the subjects is 15/20. This performance is quietly acceptable for a CBMR system. Furthermore, by analyzing the lowest scores (S1-Q5, S3-Q2) we found that they were given to playlists containing a musical genre conflict. This means that subjects are extremely sensitive to the relation between the query's genre and the returned excerpt's genres. Thus, a CBMR system can partially be evaluated by its genre classification performance (section 4.1.).

Conclusion

In this paper we presented a technique for Query by Example Music Retrieval (QEMR) which is based on local and global spectral similarities in order to capture the similarity of music which is rather semantic. Subjective and nonsubjective evaluations were carried out on a database containing more than 4000 music pieces. When using these measures for music genre classification, our technique reaches a classification rate up to 81%, though our benchmark dataset is rather large, including music pieces, such as Latin and Jazz, which are quite similar in the genre. And for the subjective evaluation, human subjects were asked to use the system as a query-by-example music search engine; the system was evaluated 15/20 by the subjects.

Figure 1 ,

 1 Figure 1, LSM in color (the darker the color the lower the value) of one rock musical query and: one rock song (left), one disco song (right)

Table 1 .

 1 Results for genre recognition.

	Genre	Relevant segments Top30	Accuracy
	Rock	16	90 %
	HipHop	13	75 %
	house	18	80 %
	classical	20	100 %
	Latin	11	65 %
	jazz	18	80 %
	total	16	81 %

Table 2 .

 2 Subjective evaluation for 20 Queries.

		Q1	Q2	Q3	Q4	Q5	TOTAL
	S 1	18	18	14	18	5	14.6/20
	S2	12	14	16	12	18	14.4/20
	S3	18	5	15	18	18	14.8/20
	S 4	17	16	18	17	16	16.8/20

† Work partially supported by grant 3691-2001 of the French ministry of research and technology