DOCSLIB.ORG

Distributed Multisearch and Resource Selection for the TREC Million Query Track

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Distributed Multisearch and Resource Selection for the TREC Million Query Track Distributed multisearch and resource selection for the TREC Million Query Track Chris Fallen and Greg Newby Arctic Region Supercomputing Center, University of Alaska Fairbanks, Fairbanks, AK 99775 Kylie McCormick Mount Holyoke College, South Hadley, MA 01075 Abstract A distributed information retrieval system with resource‐selection and result‐set merging capability was used to search subsets of the GOV2 document corpus for the 2008 TREC Million Query Track. The GOV2 collection was partitioned into host‐name subcollections and distributed to multiple remote machines. The Multisearch demonstration application restricted each search to a fraction of the available sub‐collections that was pre‐determined by a resource‐selection algorithm. Experiment results from topic‐by‐topic resource selection and aggregate topic resource selection are compared. The sensitivity of Multisearch retrieval performance to variations in the resource selection algorithm is discussed. 1. Overview regression merging strategy [7], modified for The information processing research group at efficiency, to merge results from a metasearch‐ ARSC works on problems affecting the style application that searched and merged results performance of distributed information retrieval from two indexed copies of the GOV2 corpus [8]. applications such as metasearch [1], federated One index was constructed with the Lucene search [2], and collection sampling [3]. An Toolkit and the other index was constructed with ongoing goal of this research is to guide the the Amberfish application [9]. For the 2006 TREC selection of standards and reference [10] TB Track [11], the GOV2 corpus was implementations for Grid Information Retrieval partitioned into approximately 17,000 collections (GIR) applications [4]. Prototype GIR applications by grouping documents with identical URL host developed at ARSC help to evaluate theoretical names [12]. Each query was searched against research and gain experience with the capabilities every collection and the ranked results from each and limitations of existing APIs, middleware, and collection were merged using the logistic security requirements. The TREC experiments regression algorithm used in the 2005 TB track. provide an additional context to test and develop The large number of document collections used in distributed IR technology. the 2006 experiment, coupled with the Prior TREC Terabyte (TB) and Million distribution of collection size (measured in Query (MQ) Track experiments performed at number of documents contained) that spanned ARSC have explored the IR performance and five orders of magnitude, introduced significant search efficiency of result‐set merging and wall‐clock, bandwidth, and IR performance ranking across small numbers of heterogeneous problems. Follow‐up work found that the systems and large numbers of homogeneous bandwidth performance could be improved systems. In the 2005 TREC [5] TB Track [6], the somewhat without sacrificing IR performance by ARSC IR group used a variant of the logistic TREC 17 Million Query Track NOTEBOOK: Multisearch and resource selection 1 / 10 using a simple relation based on collection size to algorithms applied to big‐document truncate the result sets before merging [13]. representations of collections or resources is The host‐name partition of the GOV2 discussed in [2]. corpus used in 2006 was used again for a distributed IR simulation for the 2007 TREC [14] 2. System description MQ track [15] but the full set of collections could Our goal for the 2008 MQ track was to efficiently no longer be searched for every query with the search a large number of document collections resources available because the resources using the Multisearch distributed IR research required to complete the track using a distributed system developed at ARSC. Each document collection approach increase as the product of the collection provides a search service to the number of queries and the number of collections Multisearch portal. The bandwidth cost for each searched rather than just the number of queries query is approximately proportional to the alone. Consequently, only a small fraction of the number of document collections available and this host‐name collections, comprising less than 20% bandwidth cost is split between the transmission of the documents in GOV2, was searched [16]. The of the query to the document collections and the collections were chosen according to historical transmission of the response from each document performance in the previous TREC TB Tracks by collection. Therefore, reducing the number of ranking the collections in decreasing order of total collections searched for each query was number of “relevant” relevance judgments (qrels) important. A resource or collection‐selection associated with their respective documents and algorithm was developed to restrict each search to the top 100 collections were searched. a small number of presumably relevant document For the 2008 MQ track, the ARSC IR group collections. ran several resource‐selection experiments on the host‐partitioned GOV2 collection. The purpose of each experiment was similar in motivation to the 2007 MQ experiment: quickly identify the collections most likely to be relevant to the queries, then search only the top 50 relevant collections, and finally merge the retrieved results into a single relevance‐ranked list. The union of the largest 50 of 996 host‐name collections available in the experiment contains less than 10% of the total documents in GOV2 so each MQ topic search was restricted to about a tenth of the GOV2 collection. Each collection‐ranking technique was based on a virtual “big document” representation of each collection relative to a fixed basis of terms. One of two document relevance‐ranking algorithms was modified to relevance‐rank the document collections or resources before sending the MQ track queries to the Multisearch Figure 1. Schematic of the ARSC Multisearch application: the conventional vector space model system. The resource selector is contained in the (VSM) [17] or Latent Semantic Indexing (LSI) [18]. Multisearch front‐end block and the host‐name Prior work on resource selection techniques using document collections are contained in the data variations of standard document retrieval blocks. TREC 17 Million Query Track NOTEBOOK: Multisearch and resource selection 2 / 10 2.1 Multisearch After the result set is completed, it is sent Multisearch 2.0 is coded entirely in Java with back to the Multisearch front end over the Apache Tomcat and OGSA‐DAI WSI 2.2 as network. There, it is combined with the other middleware. Tomcat is a servlet container, and it result sets from the other back ends. This requires is also a necessary piece of architecture for OGSA‐ the work of a merge algorithm. In our DAI. OGSA‐DAI is a middleware for grid services, experiments, we used Naïve Merge (or “log and it was used because it enables quick, easy merge” in [12]) to bring results together. launching of literally hundreds of back­end web Essentially, Multisearch takes the separate result services using Axis. OGSA‐DAI also provides sets and attempts to merge them into one final, methods of searching secured information by reasonable result set. After this, the final set is having structures for grid credentials, although we produced to the user. did not utilize this ability. Three different servers were used for the 2.2 Resource selection TREC runs. Snowy is a Sun x4500 machine with The resource selection component of Multisearch two dual core Opteron processors at 2.6 GHz with described can relevance‐rank many minimally 16 GB of memory and 48 TB of disk space, and it cooperative document collection servers that runs Ubuntu Linux 7.10. Pileus is an ASL server provide a typical “search” interface that accepts with two hyperthreaded Xeon 3.6 GHz CPUs, 8 GB text queries. To build the data set used by the of memory, and 7 TB of disk space. It also runs resource selection component, the number of Ubuntu 7.10. Finally, Nimbus is a Sun v20z with document hits in each collection for each potential two Opteron processors at 2.2 GHz with 12 GB of query term is required. This data could, at least in memory and 73 GB of disk space. It runs Fedora principle, be constructed by searching each Core 9. Snowy has the majority of the back ends document collection one basis term (defined loaded onto it due to its disk space and speed. It below) at a time through the search interface had 873 back end services running, all loaded provided by the document collection server but in from the OGSA‐DAI architecture. Pileus hosted the this experiment the indexed document collections remaining 121 back ends. Nimbus ran the front‐ were directly accessed to build the resource‐ end client, so all the back ends had to transfer data selector data. back and forth over the network. A query is sent over the network to any number of backend services, as shown in Figure 1. 2.2.1 Vector representation of resources Each service has at least one Data Service The search resources, or back ends, in this Resource (DSR), although some might have experiment were Lucene indexes built from nearly multiple resources available. A DSR provides 1,000 of the largest host‐name document access and to the data within the service, as well collections in the GOV2 corpus. Collection size is as the appropriate methods of getting that data, defined here as the number of unique documents including a credential system if necessary. In the contained in a document collection. The largest case of Multisearch, each service was in fact its 1,000 host‐name collections in GOV2 contain own search engine. It takes the query and passes it approximately 21 million documents out of a total to the DSR which runs the query against the data, of 25 million GOV2 documents. For each of the compiling a result set to be returned to the 10,000 topics in the 2008 MQ Track, collections requesting query.
Load more

Recommended publications
  • Key Issue Cervone 1L
    Serials – 20(1), March 2007 Key issue Key issue Federated searching: today, tomorrow and the future (?) FRANK CERVONE Assistant University Librarian for Information Technology Northwestern University, Evanston, IL, USA Although for many people it may seem that authorization, thereby allowing patrons the ability federated search software has been around forever, to use the resources from wherever they may it has only been a little over three years since happen to be. federated search burst on the library scene. In that time, the software has been evolving in many ways as the landscape of Internet-based searching has Standard features and evolving trends shifted. When many libraries decided to install federated In the current generation of federated searching search software, they were trying to address some products, standard features include the ability to of the issues that have confounded searchers since use multiple protocols for gathering data from the introduction of CD ROM-based indexes in the information products. In addition to the ubiquitous early 1990s. For example, it has been known for Z39.50 protocol, newer protocols such as SRU/SRW some time that when patrons have multiple and OAI-PMH are rapidly becoming basic require- databases available to them, they typically prefer ments for all federated search engines, regardless to use a single interface rather than having to learn of scale. difference interfaces for each database. Further- As the needs of researchers and faculty evolve, more, most people want to have a way to search advanced features are being built into next- those multiple resources simultaneously and then generation federated searching products, such as consolidate the search results into a single, ordered integration of the federated searching software with list.
    [Show full text]
  • Federated Search: New Option for Libraries in the Digital Era Shailendra Kumar Gareema Sanaman Namrata Rai
    International CALIBER-2008 267 Federated Search: New Option for Libraries in the Digital Era Shailendra Kumar Gareema Sanaman Namrata Rai Abstract The article describes the concept of federated searching and demarcates the difference between metasearching and federated searching which are synonymously used. Due to rapid growth of scholarly information, need of federated searching arises. Advantages of federated search have been described along with the search model indicating old search model and federated search model. Various technologies used for federated searching have been discussed. While working with search, the selection of federated search engine and how it works in libraries and other institutions are explained. Article also covers various federated search providers and at the end system advantages and drawbacks in federated search have been listed. Keywords: Federated Search, Meta Search, Google Scholar, SCOPUS, XML, SRW 1. Introduction In the electronic information environment one of the responses to the problem of bringing large amounts of information together has been for libraries to introduce portals. A portal is a gateway, or a point where users can start their search for information on the web. There are a number of different types of portals, for example universities have been introducing “institutional portals”, which can be described as “a layer which aggregates, integrates, personalizes and presents information, transactions and applications to the user according to their role and preferences” (Dolphin, Miller & Sherratt, 2002). A second type of portal is a “subject portals”. A third type of portal is a “federated search tool” which brings together the resources to a library subscribes and allows cross-searching of these resources.
    [Show full text]
  • 1 Public Records Resources Online
    Public Records Resources Online How to Find Everything There Is to Know About "Mr./Ms. X" *Please see disclaimer at end of document* Summary of public records on Mr. / Ms. X . Starting with one or more Background Reports from the sources below can help provide an overview of where the person has lived and worked, as well as other pertinent information for searching, such as middle name or initial. They might also contain adverse filings and licensing information that you can later verify in other sources. Examples of vendors that provide background reports (for a fee): Westlaw/CLEAR (Thomson Reuters) $ Lexis/Accurint $ TLO $ His/her social security number is . These tools can help verify if an SSN is valid and related to a living person. SSN Validator Selective Service Online Verification He/she was born / died / naturalized . In addition to the Summary Reports in the first section of this guide, official death records may be found in resources on the federal, state, and local levels. The Genealogy Resources section of this guide might have other helpful resources for death records. Social Security Death Records The official federal record is the Social Security Death Index (SSDI). Only the subscription databases, such as Lexis, Westlaw, and TLO (all $) will have the most recent SSDI records, due to privacy restrictions. Try variations of spellings, or using only the last name and birth or death year and location if you're not finding an SSDI record. Ancestry Library $ Genealogy Bank SSDI Research Guide SSDI Databases Online State and Local Death, Burial, and Cemetery Records State and local death records will often provide more detailed information than an SSDI record, but they are not as easy to find.
    [Show full text]
  • From Federated to Aggregated Search
    From federated to aggregated search Fernando Diaz, Mounia Lalmas and Milad Shokouhi [email protected] [email protected] [email protected] Outline Introduction and Terminology Architecture Resource Representation Resource Selection Result Presentation Evaluation Open Problems Bibliography 1 Outline Introduction and Terminology Architecture Resource Representation Resource Selection Result Presentation Evaluation Open Problems Bibliography Introduction What is federated search? What is aggregated search? Motivations Challenges Relationships 2 A classical example of federated search One query Collections to be searched www.theeuropeanlibrary.org A classical example of federated search Merged list www.theeuropeanlibrary.org of results 3 Motivation for federated search Search a number of independent collections, with a focus on hidden web collections Collections not easily crawlable (and often should not) Access to up-to-date information and data Parallel search over several collections Effective tool for enterprise and digital library environments Challenges for federated search How to represent collections, so that to know what documents each contain? How to select the collection(s) to be searched for relevant documents? How to merge results retrieved from several collections, to return one list of results to the users? Cooperative environment Uncooperative environment 4 From federated search to aggregated search “Federated search on the web” Peer-to-peer network connects distributed peers (usually for
    [Show full text]
  • Federated Search of Text Search Engines in Uncooperative Environments
    Federated Search of Text Search Engines in Uncooperative Environments Luo Si Language Technology Institute School of Computer Science Carnegie Mellon University [email protected] Thesis Committee: Jamie Callan (Carnegie Mellon University, Chair) Jaime Carbonell (Carnegie Mellon University) Yiming Yang (Carnegie Mellon University) Luis Gravano (Columbia University) 2006 i ACKNOWLEDGEMENTS I would never have been able to finish my dissertation without the guidance of my committee members, help from friends, and support from my family. My first debt of gratitude must go to my advisor, Jamie Callan, for taking me on as a student and for leading me through many aspects of my academic career. Jamie is not only a wonderful advisor but also a great mentor. He told me different ways to approach research problems. He showed me how to collaborate with other researchers and share success. He guided me how to write conference and journal papers, had confidence in me when I doubted myself, and brought out the best in me. Jamie has given me tremendous help on research and life in general. This experience has been extremely valuable to me and I will treasure it for the rest of my life. I would like to express my sincere gratitude towards the other members of my committee, Yiming Yang, Jamie Carbonell and Luis Gravano, for their efforts and constructive suggestions. Yiming has been very supportive for both my work and my life since I came to Carnegie Mellon University. Her insightful comments and suggestions helped a lot to improve the quality of this dissertation. Jamie has kindly pointed out different ways to solve research problems in my dissertation, which results in many helpful discussions.
    [Show full text]
  • Federated Search As a Transformational Technology Enabling Knowledge Discovery: the Role of Worldwidescience.Org
    Federated search as a transformational technology enabling knowledge discovery: the role of WorldWideScience.org ABSTRACT Purpose ­ To describe the work of the Office of Scientific and Technical Information (OSTI) in the U.S. Department of Energy Office of Science and OSTI’s development of the powerful search engine, WorldWideScience.org. With tools such as Science.gov and WorldWideScience.org, the patron gains access to multiple, geographically dispersed deep web databases and can search all of the constituent sources with a single query. Approach – Historical and descriptive Findings – That WorldWideScience.org fills a unique niche in discovering scientific material in an information landscape that includes search engines such as Google and Google Scholar. Value – One of the few articles to describe in depth the important work being done by the U.S. Office of Scientific and Technical Information in the field of search and discovery Paper type – Review Keywords – OSTI, WorldWideScience, ScienceAccelerator.gov, Science.gov, search engines, federated search, Google, multilingual Th h e dd ee vv ee ll oo pp me e nn t oo f OO SS TI Established in 1947, the U.S. Department of Energy (DOE) Office of Scientific and Technical Information (OSTI) (http://www.osti.gov/) fulfills the agency’s responsibilities to collect, preserve, and disseminate scientific and technical information (STI) emanating from DOE research and development (R&D) activities. OSTI was founded on the principle that science progresses only if knowledge is shared. OSTI’s mission is to advance science and sustain creativity by making R&D findings available and useful to DOE and other researchers and the public.
    [Show full text]
  • Resource Discovery – Issues for the UWA Library
    Resource Discovery – Issues for the UWA Library Prepared by Toby Burrows, Kate Croker, Ralph Kiel, and Scott Nicholls 19 November 2007 Introduction In March 2007 the UWA Library’s Online Services Team identified developments in resource discovery interfaces as a significant strategic issue within its brief. Students and researchers are increasingly using a wide range of resource discovery tools to find and access resources relevant to their learning and research. These systems range from library tools such as the catalogue and federated search software like MetaLib, through university systems such as the course management system, to external tools such as Google and Amazon. There are a number of recent studies and reports which indicate that researchers are “becoming more displaced from the library with respect to information finding, access and retrieval” (Research Information Network, 2007). According to one British study, over 70% or researchers routinely used Google to find scholarly content (Research Information Network, 2007). An OCLC report found that most searches by college students began with Google or a similar search engine (OCLC, 2005). New resource discovery tools are proliferating on the Web, often as Open Source software. At the same time, commercial software vendors continue to develop new products, including new single search interfaces like Encore and Primo (Breeding, 2007). This paper aims to assess the current situation, including the services currently offered by the UWA Library as well as significant global developments and trends. It presents recommendations for strategic and operational directions over the next two to three years. Resource Discovery Requirements Different users have different resource discovery requirements.
    [Show full text]
  • ASPECT Approach to Federated Search and Harvesting of Learning Object Repositories
    ASPECT Approach to Federated Search and Harvesting of Learning Object Repositories ECP 2007 EDU 417008 ASPECT ASPECT Approach to Federated Search and Harvesting of Learning Object Repositories Deliverable number D2.1 Dissemination level Public Delivery date 28 February 2009 Status Final KUL, EUN, Author(s) VMG, RWCS, KOB eContentplus This project is funded under the eContentplus programme1, a multiannual Community programme to make digital content in Europe more accessible, usable and exploitable. 1 OJ L 79, 24.3.2005, p. 1. 1/1 ASPECT Approach to Federated Search and Harvesting of Learning Object Repositories 1 INTRODUCTION ........................................................................................................................................... 4 2 METADATA STANDARDS & SPECIFICATIONS ................................................................................... 4 3 SPECIFICATIONS FOR EDUCATIONAL CONTENT DISCOVERY................................................... 5 3.1 SEARCH SPECIFICATIONS............................................................................................................................ 6 3.1.1 SQI ..................................................................................................................................................... 6 3.1.2 SRU/SRW ........................................................................................................................................... 6 3.1.3 Z39.50 ...............................................................................................................................................
    [Show full text]
  • Federated Search
    Foundations and Trends R in sample Vol. xx, No xx (xxxx) 1{109 c xxxx xxxxxxxxx DOI: xxxxxx Federated Search Milad Shokouhi1 and Luo Si2 1 Microsoft Research, 7 JJ Thomson Avenue, Cambridge CB30FB , UK , [email protected] 2 Purdue University, 250N University Street, West Lafayette IN 47907-2066 , USA , [email protected] Abstract Federated search (federated information retrieval or distributed infor- mation retrieval) is a technique for searching multiple text collections simultaneously. Queries are submitted to a subset of collections that are most likely to return relevant answers. The results returned by selected collections are integrated and merged into a single list. Fed- erated search is preferred over centralized search alternatives in many environments. For example, commercial search engines such as Google cannot easily index uncrawlable hidden web collections while feder- ated search systems can search the contents of hidden web collections without crawling. In enterprise environments, where each organization maintains an independent search engine, federated search techniques can provide parallel search over multiple collections. There are three major challenges in federated search. For each query, a subset of collections that are most likely to return relevant documents are selected. This creates the collection selection problem. To be able to select suitable collections, federated search systems need to acquire some knowledge about the contents of each collection, creating the col- lection representation problem. The results returned from the selected collections are merged before the final presentation to the user. This final step is the result merging problem. The goal of this work, is to provide a comprehensive summary of the previous research on the federated search challenges described above.
    [Show full text]
  • Federated Search and Recommendation
    1 Federated Search and Recommendation Federated search systems emerged in late 1990 to support library users to simultaneously search multiple library sources and catalogues [ELG 12]. The first such systems were designed to collect the search criteria from the users, submit search queries to sources to be retrieved, wait for a response to arrive, and finally, filter and organize the query results to be send back to the users. With the maturity of Cloud Computing, Distributed Machine Learning (DML), big data, fog and edge computing technologies, new opportunities for exploiting computing resources on demand appeared, creating huge impacts on many sectors. However, implementing federated search systems is still a challenge for technical solutions, but also governance decisions and policies that need to be implemented and administered. 1.1. Introduction The authors in [ORC 10] differentiate between Windows Search and Federated Search, as two types of search in Windows 7. Windows Search enables searching of the entire local system and a limited amount of external resources such as shared drives. Federated Search enables the simultaneous search of multiple sources, including document repositories, databases, remote repositories and external Web sites. To enable federated features for websites to be searched by the user, special search connectors need to be implemented and configured for each website [ORC 10]. For example, the selection-based search in MacOS Spotlight requires an index of all items and files that exist in Chapter written by Dileepa JAYAKODY, Nirojan SELVANATHAN, Violeta DAMJANOVIC-BEHRENDT 2 ISTE Ltd. the system to be created. One of the biggest issues with the federated search relates to resource accessibility, thus requiring one large index to be created from those multiple sources that constitute federation.
    [Show full text]
  • Federated Search by Milad Shokouhi and Luo Si
    Foundations and TrendsR in Information Retrieval Vol. 5, No. 1 (2011) 1–102 c 2011 M. Shokouhi and L. Si DOI: 10.1561/1500000010 Federated Search By Milad Shokouhi and Luo Si Contents 1 Introduction 3 1.1 Federated Search 6 1.2 Federated Search on the Web 8 1.3 Outline 12 2 Collection Representation 14 2.1 Representation Sets in Cooperative Environments 15 2.2 Representation Sets in Uncooperative Environments 17 2.3 Estimating the Collection Size 22 2.4 Updating Collection Summaries 26 2.5 Wrappers 27 2.6 Evaluating Representation Sets 28 2.7 Summary 32 3 Collection Selection 34 3.1 Lexicon-based Collection Selection 34 3.2 Document-surrogate Methods 38 3.3 Classification (or clustering)-based Collection Selection 44 3.4 Overlap-aware Collection Selection 46 3.5 Other Collection Selection Approaches 47 3.6 Evaluating Collection Selection 49 3.7 Summary 53 4 Result Merging 54 4.1 Federated Search Merging 54 4.2 Terminology 54 4.3 Federated Search Merging 55 4.4 Multilingual Result Merging 59 4.5 Merge-time Duplicate Management for Federated Search 60 4.6 Other Papers on Result Merging 61 4.7 Evaluating Result Merging 66 4.8 Summary 67 5 Federated Search Testbeds 68 5.1 Summary 72 6 Conclusion and Future Research Challenges 73 6.1 The State-of-the-art in Federated Search 74 6.2 Future Research Challenges 76 Acknowledgments 81 References 82 Foundations and TrendsR in Information Retrieval Vol. 5, No. 1 (2011) 1–102 c 2011 M. Shokouhi and L.
    [Show full text]
  • Overview of the TREC 2013 Federated Web Search Track
    Overview of the TREC 2013 Federated Web Search Track Thomas Demeester1, Dolf Trieschnigg2, Dong Nguyen2, Djoerd Hiemstra2 1 Ghent University - iMinds, Belgium 2 University of Twente, The Netherlands [email protected], {d.trieschnigg, d.nguyen, d.hiemstra}@utwente.nl ABSTRACT track. A total of 11 groups (see Table 1) participated in the The TREC Federated Web Search track is intended to pro- two classic distributed search tasks [9]: mote research related to federated search in a realistic web Task 1: Resource Selection setting, and hereto provides a large data collection gathered The goal of resource selection is to select the right re- from a series of online search engines. This overview paper sources from a large number of independent search en- discusses the results of the first edition of the track, FedWeb gines given a query. Participants had to rank the 157 2013. The focus was on basic challenges in federated search: search engines for each test topic without access to (1) resource selection, and (2) results merging. After an the corresponding search results. The FedWeb 2013 overview of the provided data collection and the relevance collection contains search result pages for many other judgments for the test topics, the participants' individual queries, as well as the HTML of the corresponding web approaches and results on both tasks are discussed. Promis- pages. These data could be used by the participants to ing research directions and an outlook on the 2014 edition build resource descriptions. Some of the participants of the track are provided as well. also used external sources such as Wikipedia, ODP, or WordNet.
    [Show full text]