“ Who are the strongest candidates in Europe for competing on software ideas?”
“ Who is the best doctor who can cure insomnia in a close-by hospital?”
“ Where can I attend an interesting scientific conference in my field and at the same time relax on a beautiful beach nearby?”
This information is available on Internet, but no software system is capable of computing the answer. Queries span over multiple semantic domains and require composing ranking of results.
Their Common Aspect
Individual answers are on the Web
A knowledgeable user would do the query step-by-step:
Search database conferences, get their city
Check that the city average temperature is warm enough
Search low-cost flights via a broker for that city
Search luxury hotels via another broker
We want a system for supporting this search process
Build several “solutions” which already integrate all dimensions
Rank “solutions” according to a rank function and outputing results in rank order
Possibly add dimensions while the search proceeds or change the relative weight of each search
Search Computing architecture: overall view Main Query flow <Uses> relation High level query “ Where can I attend a DB scientific conference close to a beautiful beach reachable with cheap flights?” Sub query 1 “ Where can I attend a DB scientific conference?” Sub query 2 “ place close to a beautiful beach?” Sub query 3 “ place reachable with cheap flight?” Low level query 1 ConfSearch(“DB”,placeX,dateY) Low level query 2 TourSearch(“Beach”,PlaceX) Low level query 3 Flight(“cost<200”,PlaceX,DateY) Services invocations and operators execution Presented results MSVVEIS’08 - Barcelona – Iberia LID’08 – Rome - Alitalia RCIS’08- Marrakech- AirFrance Query plan Results
Semantic Resource Framework
Wrapping Technology and Ontological Annotation
Search Computing and Research Evaluation
Conceptual representation of resources as entities and connections
Logical representation of signatures
Physical repre. as service implementations
Query Planner includes:
Language for querying services
Models for building (top-k vs top-flow) query plans
Methods for query optimization
Query Engine includes:
Panta Rhei , a query execution model.
Front-end Research in the SeCo framework
Client-side framework for configuration and automatic rendering of query and result interfaces
User interaction primitives that allow to perform explanatory search
Search as a Process
Visual Interfaces for Complex Search
Model Driven Development Process of SeCo Applications
A Model-driven Perspective on Search Computing
MDE approaches applied to search computing
metamodels describing the objects of interest,
shared knowledge and vision
bases for future tool interoperability
specification of applications through model transformations
formalized representation of the intended semantics
definition of a domain specific language (DSL) for query processing
Simplified definition and visual representation of the query manipulation processes
SeCo: MDE Overview
The SeCo system can be seen as a set of models and model transformations
At design time
At runtime ( Query plan execution)
SeCo Overview: Models
4 artifact models
Service Mart, Query, Query Parameters, Result
A query plan model
For the runtime query transformation
Service Mart Metamodel
Service Mart Metamodel
A ServiceMart is an abstraction (e.g., Hotel) of one or more Web service implementations (e.g., Bookings and Expedia)
capable of accepting queries and of returning results
possibly ranked and chunked into page
ServiceMart contains Attributes
Attributes can be Atomic or Composite
An AccessPattern specifies RankingType and AttributeDirection (I/O) for every Attribute of the ServiceMart, thus allowing its actual invocation
is defined as an input-output relationship between pairs of service marts that can be exploited for joining them
e.g., the output city of the Concert can be used as input for the Hotel.
physical interface of the service, with details about chunk size, cost, …
Exact or Search (ranked)
is a conjunctive query over services
can be defined at an abstract level ( AccessPatternLevelQuery ) or at physical level ( InterfaceLevelQuery ).
a LogicalQuery is composed by a set of QueryClauses
a QueryClause can refer to the SM level or to the SI level
Several types of clauses
SeCo Overview: Transformations
Vertical transformations for Queries and ServiceMarts
Query Execution transformation (at runtime)
Result transformation (at runtime)
1 1 2 4 3
For moving among different conceptualization levels
For providing recommendations
For transforming informations
service mart and query: for moving from conceptual to logic to phisical level
for reshaping the data in the resultset (exploratory approach implemented by liquid query)
For enriching the results with personalization and recommendations
Query Execution transformation
Query execution as a transformation
model of the query parameters -> model of the query results
Represented as a Query Plan model
well-defined scheduling of service invocations, possibly parallelized, that complies with their service interface and exploits the ranking in which search services return results to rank the combined query results.
QueryPlan metamodel + Concrete Syntax = Panta Rhei Language
Query plan metamodel
Transformations: Panta Rhei
describes both the execution flow and the data flow between nodes.
Several types of nodes exist
service invocators, sorting, join, and chunk operators, clocks (defining the frequency of invocations), caches, and others.
The query result model is constructed stepwise, following the execution flow
Transformations: Query to Plan (1/2)
1 st phase: an ATL helper (functional program) encapsulates the scheduling algorithm of the execution plan.
The function produces a representation of a partial order of the clauses
Several very different scheduling algorithms can be used in this phase, and the transformation structure allows to easily swap the preferred one, also at runtime
2 nd phase generates the output Pantha Rhei query plan. In this phase the following mappings are assumed:
Invocation clauses become Service invocation nodes
Join clauses become parallel joins or pipe joins
The connections between the nodes are generated based on the ordering calculated in the first phase.
A Higher Order Transformation (HOT) could be used to automatically modify the logic of the plan, based on domain-specific needs or insights
User interaction metamodel
Implemented by the Liquid Query paradigm
Model Transformation Challenges
Specification of mappings for data extraction
Simple interface based on MT
e.g. using Model Weaving, Transformations by Example.
Transformations for building views of the results.
views and viewpoints on models
i.e. model transformations to filter or change the representation of a given data set
Search process orchestration in light of model transformations.
the Pantha Rhei DSL can be seen as a model transformation.
formalization is needed to represent query plans as composition of operations on models.
Search on query models.
Search within the domain of the queries themselves
Ex: most typical queries and their relationship to usage patterns
Experiments and prototypes
Main SeCo concept models in ECORE
Implemented ATL transformation that generates the query plan from query and service mart definitions, using trivial strategies
Further works: implementing different optimization strategies, by adopting rule-based optimization (old concept in the DB field)
Prototypes available online: http://dbgroup.como.polimi.it/brambilla/SeCoMDA
Search Computing as integration of several interacting models,
Partition of the design space and responsibilities on the different roles and involved expertise, in a non-trivial way
Objective: is to replace programming with model driven development wherever possible, yielding to flexibility and efficiency.
A model transformation approach is a good tool for clarifying the problem and solution space
Probably not viable for actual implementation of the search system, because of performance /scalability issues
Current status of the project and state of the art recorded in the book: Search Computing Challenges and Directions (Springer LNCS, vol. 5950, Ceri-Brambilla eds.)