there is an available ontology, it is still not easy for service
providers who do not have much knowledge on ontologies
to select the exact semantic information to annotate their
service description interfaces. About the second assumption,
the semantically heterogeneousproblemswidelyexist
between different services which are often across multiple
domains. For example, service models ws1(UStoRMB) and
ws2(getStockPrice) possibly belong to two different domains
such as Bank and Stock, respectively. Thus, the parameter
concept “USdollar” of ws2 and the concept “USprice” of ws1
are possibly referred by different ontology concepts from
different ontology domains. Further, the semantic connect-
ing between ws2 and ws1 can probably cause to the semantic
inconsistent problem. Analogously, the semantically hetero-
geneous problems between different services are more like
the same problems existing in the information integration
and information retrieval fields. Therefore, the calculation of
semantic similarities between different heterogeneous on-
tology concepts of different ontology domains should be
taken into account when performing the INPUT/OUTPUT
matching between the involved services in a service
composition. About the third assumption, it is not realistic
to expect a general user especially who also does not have
much semantic knowledge to specify the exact semantic
information for mapping his query. To the worst case, such
semantic information is not available.
With the growing number of available services on the
web, for nonexpert users, they are expecting that searching
services should be as simple as possible just like using a
Google search engine to do a general information retrieval
where they only need to type their needed information and
then get the ranked results they want. Apparently, the
above-mentioned three assumptions are becoming consoli-
date barriers to make current semantic composition
approaches far away from the real practice in real-world
applications. Considering the comprehensive advantages
brought by our QSQL-based composition approaches in
[21], we employ a lexical database WordNet and semantic
similarity among multiple heterogeneous ontologies to
extend QSQL by trying to eliminate the above-discussed
limitations for supporting automated service composition.
By doing so, our approaches will become more practical
and reasonable to support general service retrieval and
composition. In the following sections, we will discuss the
concrete strategies on how to extend QSQL by exploiting
WordNet and semantic similar computation.
3.2 Extending QSQL by Using WordNet
When a service is published, it is possible that there is a lack
of a concrete application ontology which is used to annotate
the associated WSDL documents. In our approaches, we use
a general semantically lexical database called WordNet [24]
to approximately address this problem. Recently, WordNet
has been widely used in Information Retrieval community
by calculating and comparing thei r semantic similarity
between words. WordNet can also be seen as ontology for
natural language terms. It contains around 100,000 terms,
organized into taxonomic hierarchies. Nouns, Verbs, Ad-
jectives, and Adverbs are grouped into synonym sets
(synsets). The synsets are also organized into senses (i.e.,
corresponding to different meanings of the same term or
concept). The synsets (or concepts) are related to other
synsets higher or lower in the hierarchy by different types of
relationships. The most common relationships are t he
Hyponym/Hypernym (i.e. , Is-A relationships), and the
Meronym/Holonym (i.e., Part-Of relationships). It is com-
monly argued that language semantics are mostly captured
by nouns (and noun phrases) so that it is common to build
retrieval methods based on the relationships Hyponym/
Hypernym and Meronym/Holonym. Similarly, in our
approaches, we mainly merge the relationship Hyponym/
Hypernym together with our previous definition of semantic
relationships in [22] and [23] (Definitions 1-5), and the
merged relationships are listed as below:
218 IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 4, NO. 3, JULY-SEPTEMBER 2011
Fig. 1. Basic data structures of QSQL element.