Bidirectional Query Planning Algorithm Motivation Bidirectional Query Planning Algorithm Growth of size and popularity of biological deep web data sources Increasing need for querying these data sources Answering cross-source queries manually Identify relevant data sources Submit queries to numerous query forms Keep track of results Manually combine and summarize results Algorithm Overview Bidirectional Exploration Identify target nodes and starting nodes Backward exploration connecting target nodes with starting nodes Forward exploration connecting starting nodes with target nodes Backward and forward exploration queue Heuristic 1: Always explore the least cost node Forward explore: Predecessor u to Descendant v u is single node: edge exploration u is composite node: explore the unexplored nodes in u first Backward explore: Descendant v to Predecessor u Edge Exploration Build paths connecting target with starting nodes Heuristic 2: Always explore the shortest path Explore edge from node u to v u is single node: Dijkstra algorithm u is composite node u’s unshared ancestor: normal u’s shared ancestor: longest path from these ancestors to v Running Example Motivating Example Entity-Attribute Query Q1={ERCC6,SNPID,”ORTH BLAST”,HGNCID} Entity-Entity Relationship Query Q2={MSMB, RET} Experiment Results Conclusion Support cross-source queries in deep web Entity-attribute and entity entity relationship queries Propose a bidirectional query planning algorithm Our planning algorithm has good scalability Our plan outperforms plans from Steiner tree Our plan perform closely to the optimal plan Setup Speedup and Plan Quality 12 biological deep web data sources 20 queries related with SNP study Our algorithm, Exhaustive search (OPT), Steiner tree algorithm Problem Formulation Query Q={e1,…,em,a1,…ak} Entity keyword: initialize the query Attribute keyword: attribute of interest Scalability Data source Multi-source dependency Cost model Access cost Quality cost For 60% queries, our plans have speedup over Steiner tree’s For 80% queries, our plans have the same execution time as OPT’s For 90% queries, quality of our plans is close to that of OPT’s Formulation: Find the lowest cost subgraph SubG from the dependency graph, such that all search terms in query Q are covered by SubG OPT scales poorly, 9 hours for 75 sources Ours scales well, <1 seconds for 75 sources