Ontologies play a relevant role to support service matchmaking in the discovery process. In fact, the elements used for service capability description refer to concepts that can be properly defined and semantically related in domain ontologies. Semantic relationships between concepts are then exploited to establish the type of matching between advertisements and requests. In this paper we propose an ontologybased approach to service discovery characterized by a hybrid multimode matching, that is, a deductive capability matching extended with a flexible similarity evaluation scheme. In the approach, the semantic service description results from the cooperation of several components: a UDDI registry is responsible for managing offered service descriptions, a Domain Ontology provides the general knowledge about concepts from the business domain in which services are used, a Service Ontology organizes services at different levels of abstraction. The proposed approach provides service advice at multiple levels of granularity and rates adviced services according to different kinds of comparison strategies.
In the recent years many companies have heavily invested in Web Service
technologies and, as a consequence, a growing number of services is being made
available. A Web Service is a set of related functionalities that can be accessed
through the Web and provides a way for interoperating independently developed
Web applications. Service proliferation over the Web has been facilitated by the
development of several standards, like WSDL for service description, UDDI for
service registry, SOAP for message exchange and BPEL4WS for service
orchestration [
The use of ontologies specifically enables service matchmaking in the discovery process. In fact, the elements used for service capability description refer to concepts that can be properly defined and semantically related in domain ontologies. Semantic relationships between concepts are then exploited to establish the type of matching between advertisements and requests. In this paper we propose an ontology-based approach to service discovery. In the approach, the semantic service description results from the cooperation of several components: a UDDI registry is responsible for managing offered service descriptions, a Domain Ontology provides the general knowledge about concepts from the business domain in which services are used, a Service Ontology organizes services at different levels of abstraction. The service discovery process is based on a hybrid multimode matching, that is, a deductive capability matching extended with a flexible similarity evaluation scheme. The proposed approach has the advantage of providing service advice at multiple levels of granularity and of rating adviced services according to different kinds of comparison strategies. In Section 2 we briefly discuss the related work. Section 3 formally defines the semantic service modeling components. Section 4 describes the hybrid multimode matching approach. Section 5 presents the Service Ontology architecture and its deployment. In Section 6 we conclude with advantages of the proposed approach and future work. 2
Service matchmaking has been addressed by several approaches in literature:
given a request R and a set of advertisements S, the matching procedure must
return the set of advertised services that match better with R, possibly ranked
with respect to their level of matching (if it can be evaluated). In most
approaches the starting point is the UDDI Registry, where service descriptions are
published; UDDI Registry offers searching functionalities that use traditional
keyword-based techniques, featured by low precision and recall. To provide
semantic matching between service descriptions, some approaches consider concept
definitions within ontologies (concept-based techniques). In [
Our aim in this work is to propose an ontology-based hybrid approach where different kinds of comparison strategies are combined together to provide a flexible and efficient matchmaking between service descriptions. We extends the keyword-based approach of UDDI Registry by considering semantic matching on the basis of a Domain Ontology (where elements used for service description refer to concepts semantically described and related) and a Service Ontology (where services are organized by means of semantic relationships at multiple levels of granularity). Moreover, we consider service operation names as meaningful for matching purposes. Service comparison is performed on the basis of the Domain Ontology by means of a DL-based approach, made more flexible by exploiting a similarity evaluation scheme and more efficient by exploiting semantic relationships in the Service Ontology. Furthermore, similarity evaluation scheme is used also to make more precise ranking of searching results. 3
It is widely accepted that ontologies are a formal tool useful for modeling semantics and support inferencing procedure. For effective service discovery, the use of ontologies for modeling service semantics is recommended. In our approach, a Domain Ontology is used to conceptualize domain knowledge and to provide semantics to service descriptions. The Domain Ontology contains definitions of concepts to which elements used to describe services (input/output parameters, operation names, service categories) refer. Concepts are related by means of the usual semantic relationships: concept generalization/specialization, concept equivalence, concept disjunction and instance-of. The Domain Ontology therefore supports service matchmaking. Reasoning on service properties viewed as concepts in the Domain Ontology allows to identify semantic relationships also among services. In our approach, we explicitly represent such semantic relationships in a Service Ontology where services are described at different levels of abstraction to support multimode matching and querying. The Service Ontology architecture is described in Section 5. Ontologies are described using SHOIN (D+) Description Logic which has been implemented using the XMLbased syntax of OWL-DL sublanguage. In the literature OWL-S and WSMO are the emerging languages for semantic service description, but there is no accepted standard. In our approach, a service is semantically described by means of a category, representing the domain of interest of the service, and the service capability in terms of provided operations. Formally, the description is given by a conjunction of: – a concept in the form ∃hasCategory.CAT , where CAT is a concept which represents the associated service category; – one or more concepts in the form ∃hasOperation.OP , where OP is a concept representing an operation of the current service; each operation OP is described as a conjunction of: • the operation name, expressed by means of an atomic concept; • a conjunction of one or more concepts IN , where IN is a concept representing an input parameter; • a conjunction of one or more concepts OU T , where OU T is a concept representing an output parameter.
IN and OU T are specified in the form ∃R.C, where R represents the name of the parameter and C is a concept representing possible parameter values. C can be defined as an atomic concept, an enumeration {i1, i2, . . . in} of individuals or a complex concept obtained by applying the intersection operator (⊓), the union operator (⊔) and the negation operator (¬) to other concepts. Example. We consider a ticket reservation service for flights from European to US cities. Using Description Logic formalism, we can write:
FlightBookingEuropeToUSA ⊑ ∃hasCategory.AirTransfer ⊓ ∃hasOperation.(flightBooking ⊓ ∃departureCity.EuropeanCity ⊓ ∃arrivalCity.USCity ⊓ ∃departureDate.Date
⊓ ∃arrivalDate.Date ⊓ ∃ticket.flightTicket) while in the Domain Ontology we have the following assertions, to express that EuropeanCity and USCity are cities and represent disjoint sets of objects, that flightBooking and bookFlight and that flightTicket and ticketReceipt constitute equivalent concepts:
DomON T EuropeanCity ⊑ City
USCity ⊑ City EuropeanCity ⊑ ¬USCity flightBooking ≡ bookFlight flightTicket ≡ ticketReceipt In this example, we considered only one operation (flightBooking). 4 4.1
In a deductive approach based on Description Logics the request R is compared with an offer S by exploiting the underlying Domain Ontology.
To verify matching between a description S and a request R, we verify the
satisfiability w.r.t. DomON T between concepts to which the service description
elements refer. As in [
Note that, from the request viewpoint, the first two kinds of match can be considered equivalent, since in both cases the offer fulfills the request; in the case of subsume and intersection match, otherwise, the offer satisfies only partially the request.
To verify the five kinds of match listed above, we separate service description components by considering service categories, operation names and input/output parameter names for each operation. Firstly, we consider the service categories CATR of the request and CATS of the offer and we verify if
DomON T |= CATR ⊑ CATS that is, CATR ⊑ CATS is true in DomON T . If this is not verified, then the match fails (mismatch), otherwise the other kinds of match are investigated. Exact match. It occurs when, for each operation OPiR there exists a corresponding operation OPj S such that – DomON T |= OPiR.name ≡ OPj S.name; – for each output OPiR.OU Th there exists a corresponding output OPj S.OU Tq such that DomON T |= OPiR.OU Th ≡ OPj S .OU Tq; – for each input OPj S .INp there exists a corresponding input OPiR.INk such that DomON T |= OPjS .INp ≡ OPiR.INk.
Each operation of R is compared with each operation of S. Note that in the matching process (for each kind of match) we require that for each comparison between two operations (respectively, between corresponding parameters of two operations) when a kind of match is established for a pair of corresponding operations (corresponding parameters) such operations (parameters) do not participate in further comparisons.
Plug-in match. It occurs when, for each operation OPiR, there exists a corresponding operation OPj S such that – DomON T |= OPiR.name ⊑ OPj S.name; – for each output OPiR.OU Th there exists a corresponding output OPj S.OU Tq such that DomON T |= OPiR.OU Th ⊑ OPj S .OU Tq; – for each input OPj S .INp there exists a corresponding input OPiR.INk such that DomON T |= OPjS .INp ⊑ OPiR.INk.
The subsume match is verified in the same way, with the roles of R and S exchanged.
Intersection match. If neither exact or plug-in or subsume match occurs, but there exist pairs of operations OPiR and OPj S with the following conditions verified – DomON T |= ¬(OPiR.name ⊓ OPj S.name ⊑ ⊥); – for at least one output OPiR.OU Th there exists a corresponding output
OPj S.OU Tq such that DomON T |= ¬(OPiR.OU Th ⊓ OPj S.OU Tq ⊑ ⊥); – for at least one input OPj S.INp there exists a corresponding input OPiR.INk such that DomON T |= ¬(OPj S.INp ⊓ OPiR.INk ⊑ ⊥); then intersection match is recognized between R and S.
If all the previous comparisons fail, then the match fails (mismatch). We can
recognize a qualitative ranking among the considered kinds of match, that is,
exact > plug-in > subsume > intersection > mismatch. To verify these kinds
of match, an automatic reasoner based on Description Logics is used (Racer [
R ⊑ ∃hasCategory.AirTransfer ⊓ ∃hasOperation.(bookFlight ⊓
∃departureCity.EuropeanCity ⊓ ∃arrivalCity.EuropeanCity ⊓ ∃ticket.ticketReceipt) Since the offer and the request have the same service category, we can proceed to verify the kind of match between them; in this case we have an intersection match. The offer partially fulfills the request, because – DomON T |= bookFlight ≡ flightBooking; – DomON T |= (∃ticket.ticketReceipt ≡ ∃ticket.flightTicket); – exact, plug-in and subsume match fails, since DomON T |= (∃arrivalCity.
EuropeanCity ⊓ ∃arrivalCity.USCity) ⊑ ⊥, while the other input/output parameters are related in some generalization hierarchies. 4.2
In [
1 if Cnh ≡ Cnk N A(nh, nk) = 0.8L if Cnh ⊑ Cnk or viceversa with L levels of generalization/specialization 0 otherwise (1) where Cnh and Cnk are the concepts associated to the names nh and nk, respectively. We say that nh and nk have Name Affinity (nh ∼ nk) if N A(nh, nk) ≥ α, where α > 0 is a given threshold imposed to filter names with high degree of affinity.
The Name Affinity coefficient is used to compute the values for the
Entitybased similarity coefficient and the Functionality-based similarity coefficient.
Entity-based similarity coefficient. Given two service descriptions R and S, we
denote with INR and INS (resp., OU TR and OU TS ) the sets of input parameter
names (resp., output parameter names) of the overall services. The Entity-based
similarity coefficient between R and S, denoted by ESim(R, S), is the measure
of affinity between names of I/O parameters, considered in their totality, that is
ESim(R, S) = 2|·IANtRot(|I+N|RI, NINSS|) + 2|·OAUtoTtR(O|U+TR|O,OUUTSTS|) ∈ [
Functionality-based similarity coefficient. Given two services R and S, we
consider each pair of operations OPiR and OPj S , one from R and one from S.
We denote with OPiR.IN and OPj S .IN (resp., OPiR.OU T and OPj S .OU T )
the sets of input parameters (resp., output parameters) of OPiR and OPj S . The
Operation similarity coefficient between OPiR and OPj S (OpSim(OPiR, OPj S ))
is computed as follows
where N A(OPiR, OPj S ) evaluates the Name Affinity between operation names.
We note that OpSim(OPiR, OPj S ) ∈ [
The Functionality-based similarity coefficient between R and S, denoted by F Sim(R, S), is the measure of similarity of their operations, computed as follows F Sim(R, S) = 2 · P h,k OpSim(OPhR, OPkS)
| OPR | + | OPS |
where OPhR ∼ OPkS holds and | OPR | and | OPS | denote the number
of operations of R and S. Note that F Sim(R, S) ∈ [
Finally, the Global similarity coefficient between R and S (GSim(R, S)) is
the measure of their level of overall similarity computed as the weighted sum of
the Entity-based and Functionality-based similarity coefficients as follows:
(4)
(6)
(7)
(8)
GSim(R, S) = w1 · NormESim(R, S) + w2 · NormF Sim(R, S)
(5)
where GSim() ∈ [
Example. If we compare the two previous service descriptions by means of the similarity approach, we obtain the following values for the similarity coefficients ESim(R, S) = 2 · (1 + 0 + 0 + 0) 2 + 4 + 2 · 1 1 + 1 = 1.133 OpSim(OP1R, OP1S ) = 1 + = 2.133 = F Sim(R, S) 2 · 1 2 + 4 + 2 · 1 1 + 1 GSim(R, S) = We use both deductive and similarity-based approach to enhance precision and flexibility of the matching process. Firstly, inference is used to classify the match between the request R and available services S into one of the five kinds proposed in Section 4.1. Successively, similarity evaluation can be exploited to further refine and quantify the functional similarity between R and S, according to the following rules: – if exact or plug-in match occurs, from the request viewpoint the offer provides completely the required functionalities, so GSim(R, S) is set to 1 (full similarity) without computing the similarity coefficients; – if mismatch occurs, GSim(R, S) is directly set to zero; – if subsume or intersection match occurs, the offer fulfills the request only partially and similarity coefficients are computed to quantify how much the offer satisfies the request; in this case, GSim(R, S) ∈ (0, 1).
Only available services for which the GSim(R, S) is equal or greater than a given threshold are proposed among the searching results, ranked with respect to the GSim() values.
The application of this hybrid approach ensures flexibility, since not only exact or plug-in match are considered (this would seem quite unrealistic), but also partial matches are taken into consideration by evaluating the similarity degree. Moreover, this evaluation decreases false negatives, since it does not exclude from the searching results those services that do not have exact or plugin match, but are quite similar from the functional viewpoint with the request R. In the example presented above, the FlightBookingEuropeToUSA service is classified in the intersection match, but it is not excluded from the searching results thanks to similarity evaluation, that reveals similarity between the service and the request. 5
In our approach a Service Ontology is deployed to organize services in three layers of increasing abstraction by means of semantic relationships. We distinguish between concrete services, abstract services and subject categories.
Concrete services are directly invocable services, described by means of their public WSDL interface; they are stored in the UDDI Registry, where Web links to their concrete implementation on the net are available. Concrete services are described as explained in Section 3. Their descriptions are compared by applying similarity coefficients proposed in Section 4.2 and are clustered on the basis of their global similarity value. Concrete services constitute the Concrete layer of the Service Ontology.
Each cluster of similar concrete services is associated to an abstract service in the middle layer of the ontology. Abstract services are not directly invocable services and represent the functionalities of similar concrete services. They are also described by means of a functional interface, with input/output parameters and operations, as explained in Section 3. Interface description of an abstract service is obtained by means of an integration process that identifies correspondences among similar operations of concrete services in the same cluster (such correspondences are recognized both between operation and I/O parameter names) and represents the corresponding operations in the abstract service; mapping rules are maintained between the operation and I/O parameter names of the abstract functionalities and the original concrete ones. Abstract services are semantically organized according to two kinds of semantic relationships: – an abstract service Sα is a generalization of another abstract service Sβ if, informally stated, Sβ provides at least the operations of Sα, as established by properties of plug-in match discussed in Section 4.1; – an abstract service Sα isComposedOf a set Φ = {S1, S2, . . . , Sn} of other abstract services if the operations of Sα are included in the union set of operations of S1, S2, . . . , Sn; in particular, Φ must be minimal (no redundancy); the service Sα is often called the composite service, while S1, S2, . . . , Sn are called the component services.
Semantic relationships between abstract services are set by the ontology
designer possibly supported by an automatic system that applies Description Logic
matching techniques explained in Section 4.1 to identify candidate abstract
services between which semantic relationships could be set. This approach is not
new: also OWL-S specification admits profile hierarchies by sub-classing the
profile model introducing new properties or placing restrictions on existing
properties [
Finally, subject categories correspond to categories of services organized into standard available taxonomies (such as UNSPSC or NAICS) and provide a topicdriven access to the underlying abstract services. These categories are the same that are used in the UDDI Registry to classify published concrete services; in our Service Ontology, each abstract service is associated to the set of all the categories related to the concrete services belonging to the corresponding cluster. Subject categories constitute the Category Layer of the ontology. Figure 1 is an example of the portion of a Service Ontology for the touristic domain considered in this work.
Semantic relationships between concrete services, abstract services and subject categories in the Service Ontology can be exploited to make more efficient the service discovery procedure. Matching algorithm exposed in the previous sections is applied at the category and abstract layers and can be speed up by considering the semantic relationships between abstract services, according to the following intuition: if an abstract service Sa matches with a given service request R, then also abstract services that provide the same capabilities of Sa (as expressed by means of semantic relationships) match with R. According to this intuition, the following rules are applied: – if Sai presents an exact or a plug-in match with R and Sai is a generalization of another abstract service Saj, then also Saj presents a plug-in match with R and the application of matching algorithm to Saj is not required; we can set GSim(R, Sai) = GSim(R, Saj) = 1; – if Sai presents a mismatch with R and another abstract service Saj is a generalization of Sai, then we can say that also Saj presents a mismatch with R; – the same procedure applies when Sai is a composite service and Saj is the union of its component ones; – otherwise, we cannot say anything about GSim(R, Saj) and the matching procedure must be applied also to it.
Finally, once abstract services that match with the request are extracted from the Service Ontology, then concrete services belonging to the corresponding clusters are included into the searching results, by setting the GSim() value of each concrete service w.r.t. R equal to the GSim() value of the corresponding abstract service. 6
In this paper we have presented a novel service discovery approach that combines a full deductive matching based on Description Logics and a similarity-based matching, also exploiting semantic organization of services in a Service Ontology to speed up semantic discovery. The combination of two types of matching enhances flexibility and effectiveness of the matching process, while use of Service Ontology improves efficiency. The proposed approach is being experimented in the touristic domain to discover suitable available services for flight booking, hotel reservation, travel planning. Future efforts will investigate further matching modalities also according to levels of granularity in a wide usage scenario.