The work reported in this article aims to the discovery of WSDL specifications that are assessed to match to specific data requirements1: Going beyond the syntactic level, we aim at exploiting the human-intended semantics of WSDL specifications At the core of the proposed method lies the Latent Semantic Indexing (LSI) method, which automatically maps data requirements specified in a query to part elements of WSDL input and output messages. We study extensively the performance of the proposed method for different types of experiments' configurations. Experiments have been performed over an extended number of services for various domains, with very encouraging results.
The infrastructure for Web services is based mostly on standards such as UDDI [
The key technology to the “semantic discovery” (and thus to the “semantic
matchmaking”) of Web services is ontologies. The key idea here is that the use of
1 This work is supported partially by the European Commission project Grid4All under grant
number FP6, project IST-Grid4All-2006-034567
ontologies for the specification of web services shall support agents to exploit the
semantics of services via logic-based inference mechanisms, gaining flexibility to the
service manipulation tasks. Three main approaches have been proposed for bringing
semantics to web services: OWL-S [
Focusing on data semantics, the aim of this paper is to support the semantic matchmaking of WSDL specifications, by exploiting the human-intended semantics of specifications, without the use of ontologies. Towards this target, our approach exploits the human-intended semantics of WSDL input/output messages and parts captured mainly via commentary and descriptive textual information. Such textual information regarding WSDL elements may be “fetched” from the service code, or they may be given by the service providers during service advertisement. This information is being exploited for the computation of the position that WSDL specifications can obtain in a semantic space, where the data semantics of WSDL specifications are expressed by means of a number of latent features. Given a query (this is considered to be a specification for the requested service’s data semantics) the objective of the proposed method is to represent this query using the computed latent features and find the registered WSDL specifications that are close enough – and thus similar – to the query, in the semantic space. Doing so, one may consider that these latent features are the concepts of an ontology, which serve as intermediates for the matching of WSDL specifications.
At this point we need to emphasize that although latent features are being used for expressing the data semantics of requested and advertised services, the lack of ontologies prohibit logic-based inferences, leading to the inability of the method to explicitly identify inferred subsumption relations between services’ specifications.
The rest of the paper is structured in the following way: Section 2 provides the related work, Section 3 provides a description of the problem and the background technology, and outlines the matchmaking method. Section 4 presents the experiments conducted towards evaluating the proposed method and finally, section 5 concludes the paper.
Although several approaches introduce the semantic matchmaking of web services (e.g. [6, 7, 8, 9, 10 and 12]), most of them require the use of a shared and well-agreed ontology: Although this constraint may be relaxed by exploiting ontology mapping techniques, these techniques need to be further enhanced towards their generic deployment. Furthermore, the difficulties mentioned in Section 1 regarding the semantic description of web services need to be tackled.
In this section we emphasize on the approaches that are closely related to the proposed approach, i.e. to approaches that exploit the content of WSDL specifications, and/or exploit textual information related to these specifications.
The OWLS-MX matchmaker [
Dealing also with WSDL specifications, aiming to address the challenges involved
in searching for web services, authors in [
Another web-service search engine (combining folksonomies and Semantic Web
Services technologies) [
In [
This paper deals with the following problem:
“Given, (a) a repository R of WSDL specifications and (b) a specification of a query Q that specifies the signature of the requested service, provide those services in R that match with Q”.
As already pointed, we deal only with services’ signatures specified in WSDL (i.e. with data semantics). More specifically: - The signature of a service s specifies a set of input/output messages. These are denoted <s,X,i>, where s is the service id, X is the type of the message, input or output, and i is the id of the specific message. - Each message <s,X,i> is associated with textual annotations: <s,i,Y,text>, where s and i are as above, Y is the type of annotation provided, description or comment, and text is the actual annotation text (possibly null). Each message may be associated with more than one annotation. - Each message <s,X,i> has one or more parameters (or parts): <s,X,i,name,data_type>, where s,X,i are as above, name is the name of the parameter, and data_type specifies a (atomic or complex) data type. - Each parameter is associated with textual annotations: <s,i,name,Y,text>, where s, i, name, Y and text are as specified above. Each parameter may be associated with more than one annotation.
The way WSDL specifications are associated with annotations is thoroughly explained in the following paragraphs.
Each WSDL specification in the registry includes a specification of the corresponding service signature, as specified above. A query Q is also a specification of the requested service signature using the above constructs.
The aim of the discovery mechanism is to find the service s in the registry that matches the query Q. Formally, a service s matches a query Q , iff ∀ < s, input, i > ∃ < Q, input, j >: match(< s, input, i >, < Q, input, j >) ∧ ∀ < Q, output, i > ∃ < s, output, j >: match(< Q, output, i >, < s, output, j >) (1)
Given the above formula, for every input parameter of the advertised service there must be a matching input parameter of the required service. Also, for each output parameter of the required service there must be a matching output parameter of the advertised service. We have to notice that alternative definitions, maybe allowing greater matching flexibility, may be provided.
The function match determines whether the corresponding parameters match, and provides their similarity degree. In the proposed approach the match function is being computed by means of the Latent Semantic Indexing method.
The Latent Semantic Indexing (LSI) is a vector space technique originally proposed
for information retrieval and indexing [
Given these factors, each term and document is represented by a vector of values, indicating its strength of association with each of these underlying concepts. In other words, the meaning of each term and document is expressed by k factor values, or equivalently, by the location of a vector in the k-space defined by the factors. Then, a document is the (weighted) sum of its component term vectors. The similarity between two documents is computed by means of the dot product between the corresponding representation vectors.
Concerning our problem, each document corresponds to each input/output message or a message part, and each term is a distinct word in any of these “documents” (as it will be explained, these pseudo-documents are being constructed by means of annotations and message/part names).
For the computation of the k factors LSI employs a two-mode factor analysis by decomposing the original association matrix into three other matrices of a very similar form. This is done by a process called “Singular Value Decomposition (SVD)”. This results in a breakdown of the original term-document relationships into linearly independent factors. Some of these factors are not significant and are ignored. The resulting k factors specify the dimensionality of the semantic space. By virtue of dimension reduction from the N terms space to the k factors space, where k < N, terms that did not actually appear in a document may still end up close to the document, if this is consistent with the major patterns of association in the data.
When one searches an LSI-indexed database of documents, it provides a query (i.e. a pseudo-document), which is a list of terms. The similarity between the query and any document is computed by means of the dot product between the corresponding representation vectors. Doing so, LSI returns a ranked list of documents, according to their similarity to the query.
The proposed matchmaking method assumes as input a specification of the desired web service (i.e. the query Q) and a repository R of registered services’ WSDL specifications. All these services are “accompanied” by annotation files that associate descriptive and commentary information to services’ specifications. After applying the matchmaking method to the advertised web services, the output is a ranked list of services according to their semantic similarity to the query. Although in our experiments (for implementation convenience, only) queries are being specified in WSDL, the proposed approach does not necessarily require the use of WSDL for the syntax of the query: Given that the queries are transformed in “bags of words” (as required by LSI), the proposed approach can also be used with keyword-based or template-driven querying forms as in Web-services search engines (e.g. Opossum in http://dori.technion.ac.il/, SeekDa in http://seekda.com/).
The proposed matchmaking method combines multiple sources of evidence to determine similarity between the signatures of two web services. In particular it considers the similarity between input and output messages, and between their parameters (i.e. input parts and output parts, respectively).
More precisely our approach is divided into the following stages: a) the matching of input messages, b) the matching of output messages, c) the matching of input parts and d) the matching of output parts. The algorithm determines the matching of each of these elements individually. The results are linearly combined to a single similarity measure between WSDL specifications (Figure 2).
The external annotation files (EAF) provide “slots” for the textual annotation of WSDL elements: “Comments” and “description” slots for the service itself, for each service’s interface, operation and input/output messages, and for each of the corresponding parameters. It also provides support for specifying mappings between WSDL elements and ontologies. The EAF is an XML file aligned with the WSDL specification via XPATH expressions. Currently, comments and descriptions are considered to aggregate any type of textual information.
Although we plan to incorporate SAWSDL [
Let us consider a message <s,X,i>, where s is the service id, X is the type of the message (input or output) and i is the id of the specific message; as well as its associated textual annotations <s,i,Y,text>, where Y is the type of annotation provided (description or comment). We construct a bag of words including all words comprising the message name and all words in the texts that annotate this specific message: This constitutes the pseudo-document corresponding to the message. Each word may be considered as a single term, or as a set of words (in case it is being constructed by concatenating a number of simple terms, e.g. getinputdate_of_arrival): We deal with both cases in our experiments. To improve the precision of our method we eliminate words with little substantive meaning, i.e. stop-words, and we consider only words that appear more than a certain number of times in the specific bag.
We compute the semantic similarity between each input (output) message of the query Q and the input (respectively, output) messages of all the web services in the registry by means of the LSI method: The method computes the semantic space by building the association matrix, associating words occurring in the web services’ inputs (or outputs) and in their annotations, with the input (respectively, output) messages’ pseudo-documents.
Similarly, each query to LSI is being constructed by means of the words in the corresponding messages of the query specification Q: In other words, for each message in Q, the proposed method constructs a separate LSI query. For each input/output message of the query Q, LSI returns a matrix of registered services’ messages, together with a matching degree: Since each input/output message of Q can match only with an input/output message of each s in the registry, the proposed method keeps the highest ranked message per service s (i.e. the most similar one). For each registered service s whose input/output messages match with the messages of Q, a ranking (matching) degree ds is computed by averaging the similarities of all input and output messages.
Let us consider a parameter (message part) <s,X,i,name,data_type>, of a message i of a service s, where name is the name of the parameter, and data_type specifies its data type. This parameter is associated with textual annotations of the form <s,i,name,Y,text>, where Y denotes the type of annotation and text the annotation text. In this case, we construct a bag of words including all words in name and all words in each text annotating this specific parameter: This constitutes the pseudo-document corresponding to this parameter. As in messages, each word may be considered as a single term, or as a set of words (in case it is being constructed by concatenating a number of simple terms): We deal with both cases in our experiments. The preprocessing stage of eliminating stop-words, and words that do not occur many times in the specific bag, applies here as well.
We compute the semantic similarity between each input (output) parameter of the query Q and the input (respectively, output) parameters of all the web services in the registry by means of the LSI method: The method computes the semantic space by building the association matrix, associating words that occur in the web services’ input (output) parameters and in their annotations, with the pseudo-documents corresponding to the parameters. Similarly, each query to LSI is being constructed by means of the words corresponding to an input/output parameter of the query Q.
For each input/output parameter of the query Q, LSI returns a matrix of registered services’ parameters, together with a matching degree: Since each input/output parameter of Q can match only with an input/output parameter of each s in the registry, the proposed method keeps the highest ranked parameter per service s. For each registered service s whose input/output parameters match with the messages of Q, a ranking degree ds is computed by averaging the matching degree of all input and output parameters.
Since the method of ranking registered services using input/output messages, as well as the method of using input/output parameters, is the same, let us exemplify the computations with a simple example concerning input parameters. Suppose we have the following advertised services: i) service s1 with three input parts: a, b, c, ii) service s2 with one input part: d, and iii) service s3 with two input parts: e, f. The service request Q has two input parts: x, y. The method uses LSI to compute the similarity between the input part x of Q and all input parts of the advertised services, i.e. a, b, c, d, e and f. The results are shown in table (a) of Figure 3. The method keeps for each service only the input part that has the maximum degree of match. The result after this step is shown in table (b) of Figure 3. Then, LSI computes the similarity between the other input part y and all the input parts of the advertised services. The results are shown in table (c) of Figure 3. Again, the method keeps for each service only the input part that has the maximum degree of match. The result after this step is shown in table (d) of Figure 3. Finally, these two tables (b) and (d) are summed and the result is divided by the number of input parts of the request, as shown in table (e). This final matrix associates each advertised service with a similarity to the query Q, based on the computation of their input parts’ similarities.
In addition to the above described approach, we have been experimenting with an alternative method for the computation of input/output messages’ similarities, so as to enrich the information consulted for the matching of messages: We construct the bag of words for each input/output message not only using the message names with their textual annotations, but adding also the associated input/output parts with their annotations. In particular, we identify the input/output messages of a web service operation together with the corresponding input/output parts of it. Then, the method computes the matching similarity of the advertised services with the query in the same way as we have described in the previous paragraphs.
The result of the matching algorithm is a list of registered services matching to the query Q, with their rankings. These ranking degrees result from averaging the degrees computed by each of the individual stages described: a) the matching of input messages, b) the matching of output messages, c) the matching of input parts and d) the matching of output parts.
To evaluate our approach, we have used service specifications from the OWL-S
Service Retrieval Test Collection (OWLS-TC) version 2 [
Concerning the WSDL specifications for domains 2 to 6, message part names are mainly composed by a single-word term capitalized and an underscore character as a prefix (e.g. _COUNTRY). For the domain 7, the messages part names are composed by multi-word terms, either separated with an underscore or with no separator, or using a combination of these (e.g. GetPatientMedicalRecords_AuthorizedMedicalRecords). We handle individual, distinct terms of multi-word terms separately, only in cases these are separated by an underscore separator, which is one of the most generic case considered.
WSDL specifications have been manually annotated by human annotators that have adequate knowledge of the related domains and services. They have been advised to carefully choose the annotations in order to indicate as close as possible the intended meaning of the input/output messages and of their parameters. Where possible, annotators have been advised to get feedback from xsd-schema complex types included in the WSDL specifications. Services in the “Network Simulation” domain have been annotated by their developers. More specifically, we can identify 3 different annotation cases that have been applied in the corpus:
Annotations that are formed by “free text including terms from xsd-schema types and from the WSDL message part name”.
Annotations that are formed by “free text including terms only from the WSDL message part name”.
Annotations that are formed by “a single term”. In this case, annotators choose a single term without considering xsd-schema types or message’s part names. For instance, for the “wsdl:part name="Capital_City"”, the annotator has chosen the single-term-description “<description> Capital </description>”, which “captures” the intended meaning of the entity “Capital City”.
The result of this process is a set of annotations with terms belonging in one of the following three categories: a) terms from xsd-schema types, b) terms from WSDL message part names, or c) terms chosen by human annotators. The use of free text with terms from the xsd-schema types and/or the WSDL message part names, means that the annotator is allowed to form a natural language sentence using these terms: E.g. “<description> The service requests accommodation using country information </description>”. Although the use of free text may distract the matching method (due to the incorporation of noisy terms), the freedom that the approach gives to the annotator is important and realistic. In this example of annotation, the annotator has combined terms (e.g. “country”) from messages’ part names (category b). As another example, in the comment “<comment> The country name is a string. A country is described with its capital, its currency, and its government </comment>” the annotator has used terms (terms “capital”, “currency”, “government”) from the xsd-schema type that corresponds to the specific message part name (category a). Table 2 summarizes information concerning annotations per domain. It must be noticed that all annotations contain 5 to 7 “significant” terms; i.e. non stop-words that may drive the computation of elements’ intended mappings. Given a query Q, we consider that the repository R includes one matching service. For evaluation purposes we measured the precision (p) of the method (i.e. the percentage of times that the method returns the correct service at the top of the ranked list), as well as the Top-k precision (pk) of the method (i.e. the percentage of times that the correct service is among the top k in the ranked list). Specifically, we have measured p5 and p10.
The evaluation of the approach has been extensively conducted with a large number of variations of the queries, so as to test the robustness of the proposed approach, even in cases where annotations are misleading, or missing. According to these variations, the words that are being used for the construction of the queries for the input/output messages and parts vary significantly.
Specifically, words concerning the query Q may be fetched from: - WSDL input/output message and part names without splitting them into single words (this is considered to be the default case and it is not denoted in the experiments). - Splitting all words in the bag (this case is denoted by “split”) - WSDL input/output messages’ annotations (this case is denoted by “in/out”) - WSDL input/output parts’ annotations (this case is denoted by “inP/outP”) - WSDL input/output messages’ annotations in conjunction with information from the corresponding input/output parts (this case is denoted by “inWP/outWP”)
Combinations of the above cases give the different configurations of the method. For instance, the cases where the method considers only the matching of input/output parts, constructing queries using WSDL input and output parts’ annotations together with part names are denoted as LSA-inP-outP. As another example, the cases where the method considers (a) the matching of input/output messages, constructing queries using words from the WSDL input and output messages’ annotations in combination with words from input and output parts’ annotations (i.e. the last case above), in combination with (b) the matching of messages parameters, constructing queries using WSDL input and output parts’ annotations, together with (c) splitting all words, is denoted as LSA-inWP-outWP-inP-outP-split. Conclusively, as shown in the Figures 4, 5, 6, we have run experiments with eight (8) configurations of the proposed method.
For each case, we have considered alternatives for the filtering of words, based on the times (t) of words’ appearance in the bag. Due to the very low numbers of words’ appearances we distinguished two cases: (a) Filtering out words that appear exactly one time (t>1) and (b) including all words (t>=1).
First, we evaluated the proposed approach by placing each of the 79 WSDL specifications included in the repository R as a query. This may be considered to be the best case for our method since each query matches exactly with an advertised service (Figure 4). In addition, we evaluated the method using each of the 79 services in R as a query, but without considering their textual annotations. The results of these cases are also presented in Figure 4. As shown, annotations play a significant role towards increasing the precision of our method: This is particularly true for cases with t>1. However, when all words are included in the bag of words (t>=1), even if generally the results are better when considering annotations (even better from the cases where t>1), some configurations fail to achieve better results from the corresponding cases with no annotations: This is due to the incorporation of “noisy” words.
To test the robustness of the proposed method in the presence of noisy words and in cases where queries do not contain many “useful” terms, we have been experimenting with a variety of cases for the queries. Thus, we have conducted experiments by adding extra new words (let us call them noise-words) in the bag of words of Q. Noise-words are randomly chosen from the textual annotations of services included in the experimental corpus, given that these services belong to the same domain with the domain of the query service. We have been experimenting with one, three, and five noise-words per query. Figure 5 shows the results of these experiments, together with two more graphs presenting results of the proposed method when WSDL messages and part names are not included in the queries (and without adding noise-words). In addition to the above, we have conducted further experiments with noise-words: This time noise-words replace (one, three, or five) words included in the query. Noise-words are new words and being chosen as in the previous cases. Figure 6 presents the results of these additional experiments, in two different sets of cases: a) Replacement of words with noise-words in queries that include WSDL messages and part names, and b) replacement of words with noisewords in queries that do not include WSDL messages and part names.
In Figures 5 and 6, it can be shown that the precision of the method scales proportionally to the number of noise-words. The best results are achieved in cases where all words are taken into account (t>1). In these cases, when the method considers the input/output messages and their input/output parts separately, together with the part name (split or not) (LSA-in-out-inP-outP-{split}) it achieves the best results, even in cases with increased noise: It manages to present the correct service among the top 5 (respectively, top 10) ranked services with precision greater than 85% (respectively, 93%). It must be pointed that the addition of 5 noise-words with/without replacement, incorporates a major (if not radical) change in the specification of the queries.
The work reported in this article aims to the discovery of WSDL specifications that match specific data requirements by computing the intended semantics of part elements of input/output messages.
Fig. 6. Results of experiments with replacement of query words with noise-words Going beyond the syntactic level, we aim at exploiting the human-intended semantics of WSDL specifications captured by means of comments and descriptions been associated with these elements. The basic constituent of the proposed method is the Latent Semantic Indexing (LSI) method, which maps data requirements specified in a WSDL query to part elements of WSDL input and output messages. Preliminary results for different types of experiments’ configurations are very encouraging: This “basic” method manages to achieve quite high precision. Further work includes testing the method in a large repository of WSDL specifications, and studying extensively its dependency on the quality of annotations, also in combination with other methods.