Agile design of data intensive web applications can rely on existing and well-tested third parties data services as components providing access methods to valuable data sources. Producers of real data services are more and more publishing their services in repositories according to light semantic pro les with simple tag-based descriptions. In this paper, we discuss techniques for data service exploration and retrieval that consider service co-usage in existing applications, patterns of tags co-usage, and ratings declared by developers who used a data service in their own development experiences.
Nowadays, we have been observing a growth of research e orts for explorative
techniques and methods to deal with the increasing volume and heterogeneity
of information made available over the Web [
In literature, service recommendations approaches have been proposed to
consider service co-occurrence in existing applications as an implicit measure
of relatedness of services [
The paper is organized as follows. In Section 2 provides some comparison with related work to underline the speci c features of our approach. Section 3 developer’s credibility creates aggregationcontextual rating
Terminological (tag) perspective Aggregation perspective
Service perspective describes a multi-perspective data service model. In Section 4 we describe the data service exploration process. Section 5 discusses some preliminary validation. Finally, Section 6 closes the paper with some nal remarks. 2
There are several approaches related to our work. In particular, we mention
recent Web service recommendation approaches, that rely on lightweight
descriptions of services, such as the ones featuring public repositories (e.g.,
ProgrammableWeb or Mashape.com): categories, tags or semantic tags, with the
application of advanced IR techniques to enhance topic-based service
recommendation [
Our proposal supports a conversation between the system, used to search for services, and the developer, who is designing a new web application through the selection and aggregation of services. 3
We model data services and organize collective intelligence on them by two interconnected frameworks, namely a Data Service Framework and an Experience Framework, that are illustrated in Figure 1 and separately detailed in the next sections. Each framework focuses on speci c elements further enriched with cross-framework relationships. Elements considered in such a multi-perspective data service model are the ones included in lightweight descriptions available within most popular repositories (e.g., Mashape.com, ProgrammableWeb.com).
Service Service name Technical features s1 HotWire DataF ormat = fXML,JSONg
FsP1rotocol = fRSS, Atom, RESTg s2 EasyToBook FsD1ataF ormat = fXMLg
FsP2rotocol = fSOAPg s3 MyAgentDeals FFssPD24raottaoFcoorlm=atfH=TTfPXgML,JSONg
Fs4
Tags fCity, Star, Hotel, Travelg fCity, Hotel, Travelg fCity, Star, Near, Hotel, Travelg The Data Service Framework is organized according to three perspectives as shown in Figure 1. Each perspective considers speci c elements, namely services, aggregations and terms used to describe them, further described with proper features and relationships between elements.
Service Perspective. This perspective focuses on data services, according to the following de nition.
De nition 1. We de ne a data service s (hereafter, service) as an operation/method/query to access data of a web source, whose underlying data schema might be unknown to those who use the service. Within the scope of this chapter, we model a service s as hns; Fs; ftsgi, where: ns is the service name; Fs is an array of elements, where each element FsX represents the technical feature X (e.g., protocols, data formats, authentication mechanisms) and is modeled as a set of allowed values for that feature (e.g., XML or JSON among data formats); ftsg is a set of tags. We denote with S the overall set of available services. A tag in Ts may be: (a) a category, taken from a top-down classi cation imposed within the repository where the data service is stored and advertised1; (b) a user tag, that is, a term assigned by developers, aimed at classifying the data service in a folksonomy-like style; (c) a keyword, that is, a recurrent term extracted from the service name and textual description using common IR techniques. In Figure 2 data services taken from ProgrammableWeb.com for the running example are listed.
Aggregation Perspective. Concerning modern application development, to implement a web application starting from available data services, developer has to explore the set of available services, select the most suitable ones, integrate and compose them, in order to deploy the nal application. Within the scope of this paper, we focus on the rst step, i.e., service exploration for selection purposes, and we talk about service aggregations, instead of web applications that are the nal product of the development process. We model aggregations according to the following de nition.
De nition 2. A service aggregation represents a set of services that can be composed to deploy a Web application. An aggregation g is modeled as a triple hng; S(g); di, where: ng is the aggregation name; S(g) = fs1; : : : ; sng is the set of data services used in g; d2D is the developer who designed the web application by 1 See, for instance, the list of ProgrammableWeb.com categories at http://www.programmableweb.com/category-api.
v2 composing services in g. We denote with G the overall set of service aggregations, that is, g2G, and with G(s) the set of aggregations where s has been included. Fictious examples of aggregations are listed in the following.
g1 ) hTravelPlan, Sg1 = fs1; s3g, dg1 i g2 ) hStay&Fun, Sg2 = fs2; s3g, dg2 i Terminological Perspective. The Terminological Perspective collects and organises for supporting service exploration the terminological items used to describe data services. The aim is to provide a term graph, described as shown in this section, to start from in order to support data service exploration (see Section 4). We will explain the structure of the graph with the help of the example shown in Figure 3. Formally, the graph is represented as hV; E i, where V is the set of nodes and E is the set of edges. In particular, each node vi2V is formally described as vi = hTvi ; coocvi i, where Tvi is a set of tags jointly used to describe a number coocvi of data services (intra-service term co-occurrence degree). Each edge eij 2E V V N is formally described as eij = hvi; vj ; cooceij i, where vi and vj are nodes (with corresponding sets of tags Tvi and Tvj , respectively), such that tags in Tvi [Tvj have been jointly used within a number cooceij of aggregations (intraaggregation term co-occurrence degree). For example in Figure 3, tags in fCity, Hotel, Travelg have been used to describe three data services (namely, s1, s2 and s3). The same tags, together with fCuisine,City,Restaurant,Tourismg, are associated with two aggregations (namely, TravelPlan and Stay&Fun). Tags aim at grouping services that are close from the data viewpoint.
With reference to same gure, Tv1 and Tv5 can be used to suggest developers
to aggregate services s1, s2 and s3 with s5. The framework suggests rstly sets
corresponding to an existing aggregation already deployed and tested (let us
suppose, fs1; s5g). Other solutions are suggested as well although they do not
correspond to existing aggregations (for example fs2; s5g and fs3; s5g).
Therefore, the intra-aggregation term co-occurrence enables developers to explore
services that have not been aggregated yet, but can be considered for aggregation
because tagged with tags forming patterns used in some existing aggregation.
This enables a greater coverage of proposed solutions, at the cost of a lower
precision, that however can be acceptable in an explorative process. The term
graph can be built and maintained in a fully automatic way.
3.2
We integrate the Data Service Framework with methods and techniques designed
to exploit the experience of developers in selecting data services, thus enabling
their ranked recommendation. Such a framework, that in this paper we refer to
as Experience Framework (EF), has been investigated in our previous work [
The Experience Framework is focused on the set D of developers. Given a
data service s2S, we denote with (s; g; d)2[0; 1] the vote assigned to s by a
developer d2D with reference to the aggregation g2G in which s has been used
(aggregation-contextual rating). Votes are assigned according to the NHLBI
9point Scoring System2. Furthermore, in [
De nition 3. A developer represents an actor that is in charge of exploring services and using them to design new aggregations. A developer might also assign aggregation-contextual votes to services. A developer d is modeled as hnd; c(d)i, where: (i) nd is the developer nickname in the considered repository; (ii) c(d)2[0; 1] is the estimated developer's credibility. 4
We envision the service exploration process as a sequence of exploration steps
between the developer and the system, used to search for services. The
developer starts the exploration by specifying: (i) the set T r of terms used within the
search request, that provide some initial hints about developer's interests; (ii)
the set F r of required technical features, for further re ning requester's search
constraints. Sets T r and F r compose the service request R, that is completed
with the set gr of services, representing the current composition of the
aggregation that is being designed. The framework is equipped with proper wizards
(described in [
A ranking function over the set of services in Se, denoted with : Se 7! [0; 1], is de ned as follows: (si) = 1 N
X[ (si; gk; di) c(di) AggSim(gr; gk)]
N
(1)
where N votes have been assigned to si, each vote (si; gk; di) is weighted with
the credibility c(di)2[0; 1] of di2D as computed in [
Exploration by simple search. The system also looks for nodes vi2V such that T r Tvi . If multiple nodes are found, for each vi2V the system will suggest to the developer additional terms to be included within the set T r considering the set Tvi nT r. A suggestion is given for each vi2V, ranked in decreasing order with respect to the coocvi value. The developer can explore these suggestions in order to consider services alternative to Se and to formulate a di erent request. For instance, with reference to Figure 3, if T r = fCity, Hotel, Travelg, the system might also suggests as additional terminological item the term fStarg rst (coocv2 = 2), and fNearg as second option (coocv3 = 1). In this way, the developer might realize that hotels can be searched either based on the number of stars or based on the proximity to a given location and he/she might re ne the request by choosing one of the two options.
Exploration by proactive completion. The developer selects a subset Se Se of services he/she is interested in. The system suggests services that could be used together with services in gr, by updating the set Se, according to the intra-aggregation co-occurrence. Let's consider the example shown in Figure 4. After performing a search based on T r = fCity; Hotel; Travelg, thus obtaining Se = fs1; s2; s3g as results, the developer chooses s1 to be included in gr. With reference to Figure 3, s1 is associated with v1 and v2 nodes. Considering node v1, other nodes connected to v1 by graph edges are v4 (associated with s4, cooce14 = 2) and v5 (associated with s5, cooce15 = 1). Similarly, considering node v2, cooce24 = 1 and cooce25 = 1. Therefore, the system ranks better the service s4 than s5, since cooce14 + cooce24 > cooce15 + cooce25 . The developer can accept one of these results. If more than one service is included in gr, the step of retrieving services is repeated for each service in gr.
Exploration by hybrid completion. This explorative modality is a combination of proactive completion and simple search. After Se has been updated, the developer selects a subset Se Se of services he/she is interested in, as well as
T e Se fCity; Hotel; s1
Travelg s2
s3 w he/she speci es a new set T r of terms. The system suggests services that could be used together with services in gr, by updating the set Se. In order to obtain this set, a proactive completion step on gr retrieves some services as explained before. 5
The exploration process described in Section 4 calls for a quantitative evaluation of the scalability of the exploration activities and the execution of experiments with developers, to test the e ectiveness of the approach in supporting data service exploration. In this section, we present preliminary experiments on scalability, performed on a dataset of 1317 services extracted from ProgrammableWeb.
We initially considered a set of service pairs hs1; s2i in the dataset and we manually compared them according to tags, technical feature and aggregation similarity, considering aggregations where they have been used. We run the similarity evaluator to compute Sim(s1; s2) by varying the threshold from 0.0 to 1.0 and we chose the value of that maximized the F-measure.
Then, experiments have been performed ten times using di erent requests. To this purpose we randomly retrieved aggregations from the repository and we considered as relevant the services included in the aggregations. We then issued the requests using the features of the services in the selected aggregations and we calculated the precision and recall of search results given by our system. The aim of these preliminary experiments is to con rm the advantages for service search brought by our approach, that considers the elements from the multiple perspectives described in the model. For these reasons, we compared our approach against: (a) the keyword-based search facilities made available within the ProgrammableWeb repository; (b) a partial implementation of our system, where we excluded the aggregation similarity from Sim(R; s) computation. Table 1 shows the precision, recall and F-measure results, the standard deviation and the variance of F-measure for the compared systems. As expected, the complete implementation of the system presents the best F-measure value. Although the exploitation of term and technical feature similarity bring signi cant improvements compared to the basic searching facilities of the ProgrammableWeb repository, it is quite evident as the highest enhancement in F-measure value is due to the integration also of aggregation similarity, that mainly relies on service co-occurrence.
System ProgrammableWeb WISeR (no AggSim) WISeR
In this paper, we proposed an approach for data service explorative search, based on a multi-perspective model for data services and speci c collective intelligence on them. The approach includes proactive search facilities and enables developers to iteratively increase their knowledge on available web data services. Future work will be devoted to the study of techniques for including latent factors (e.g., related to the perceived QoS) in the exploration process. Further open research includes the de nition of the visualization interface to further increase the exploration experience of developers.