Optimization of multi-domain queries on the web

Abstract

Where can I attend an interesting database workshop close to a sunny beach? Who are the strongest experts on service computing based upon their recent publication record and accepted European projects? Can I spend an April weekend in a city served by a low-cost direct flight from Milano offering a Mahler's symphony? We regard the above queries as multi-domain queries, i.e., queries that can be answered by combining knowledge from two or more domains (such as: seaside locations, flights, publications, accepted projects, conference offerings, and so on). This information is available on the Web, but no general-purpose software system can accept the above queries nor compute the answer. At the most, dedicated systems support specific multi-domain compositions (e.g., Google-local locates information such as restaurants and hotels upon geographic maps).This paper presents an overall framework for multi-domain queries on the Web. We address the following problems: (a) expressing multi-domain queries with an abstract formalism, (b) separating the treatment of "search" services within the model, by highlighting their differences from "exact" Web services, (c) explaining how the same query can be mapped to multiple "query plans", i.e., a well-defined scheduling of service invocations, possibly in parallel, which complies with their access limitations and preserves the ranking order in which search services return results; (d) introducing crossdomain joins as first-class operation within plans; (e) evaluating the query plans against several cost metrics so as to choose the most promising one for execution. This framework adapts to a variety of application contexts, ranging from end-user-oriented mash-up scenarios up to complex application integration scenarios.

Queries over Web Services

“…The only work that deals with IR-like queries is presented in [10]. [10] deals with the joint problem of selecting the more appropriate services to invoke, when multiple services have the same functionality but different binding patterns, and of ordering the selected services in a distributed and static execution environment that employees pipelined parallelism. However, no performance guarantees have been provided.…”

“…Search queries belong to a different paradigm. In [10], Braga et al deal with the joint problem of finding a WSs plan and an access pattern for each service for search query optimization. The execution environment is distributed and static, while the services can exchange data directly through pipelining.…”

Exploiting Parallelism to Accelerate Keyword Search on Deep-Web Sources

“…However, this system does not consider the possibility of inter-dependence between data sources, and therefore, the implementation is much simpler. Braga et al [10] present a parallel framework for multi-domain queries on the Web that constructs multiple query plans for the same query, and then selects the optimal one according to cost metrics. While the system exploits task parallelism in executing query plans, it does not consider thread or pipeline parallelism.…”

Service-oriented execution model supporting data sharing and adaptive query processing

“…Instead, it investigates on constraints to reduce the access to the WSs. Multi-domain queries considered in [9] also need to query over two kinds of WSs: exact services and search services. The work presented in [9] focuses on query optimization rather than execution, which is our research point.…”

“…Query facilities [5,9,24,25,30,31,34] have been developed to support service-oriented queries, which enable users to access multiple WSs in a transparent and integrated fashion. Meanwhile, techniques on improving efficiency of service-oriented queries have been studied, which often include: (a) selecting the best WS from WSs with similar functionalities but from different service providers [13,25]: Quality Of Web Service (QoWS), with parameters such as availability, latency, and fees, is usually considered as a key feature of distinguishing competing WSs, (b) ordering the selected WSs to form a best execution plan [9,25,30] determined according to the criteria of minimum query execution time, minimum monetary costs, or minimum monetary costs subjecting to a limit on the query execution time.…”