Links to Exploration step
Le document en format XML
<record><TEI><teiHeader><fileDesc><titleStmt><title xml:lang="en">Is searching full text more effective than searching abstracts?</title>
<author><name sortKey="Lin, Jimmy" sort="Lin, Jimmy" uniqKey="Lin J" first="Jimmy" last="Lin">Jimmy Lin</name>
<affiliation><nlm:aff id="I1">National Center for Biotechnology Information, National Library of Medicine, Bethesda, Maryland, USA</nlm:aff>
</affiliation>
<affiliation><nlm:aff id="I2">The iSchool, University of Maryland, College Park, Maryland, USA</nlm:aff>
</affiliation>
</author>
</titleStmt>
<publicationStmt><idno type="wicri:source">PMC</idno>
<idno type="pmid">19192280</idno>
<idno type="pmc">2695361</idno>
<idno type="url">http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2695361</idno>
<idno type="RBID">PMC:2695361</idno>
<idno type="doi">10.1186/1471-2105-10-46</idno>
<date when="2009">2009</date>
<idno type="wicri:Area/Pmc/Corpus">000124</idno>
<idno type="wicri:explorRef" wicri:stream="Pmc" wicri:step="Corpus" wicri:corpus="PMC">000124</idno>
</publicationStmt>
<sourceDesc><biblStruct><analytic><title xml:lang="en" level="a" type="main">Is searching full text more effective than searching abstracts?</title>
<author><name sortKey="Lin, Jimmy" sort="Lin, Jimmy" uniqKey="Lin J" first="Jimmy" last="Lin">Jimmy Lin</name>
<affiliation><nlm:aff id="I1">National Center for Biotechnology Information, National Library of Medicine, Bethesda, Maryland, USA</nlm:aff>
</affiliation>
<affiliation><nlm:aff id="I2">The iSchool, University of Maryland, College Park, Maryland, USA</nlm:aff>
</affiliation>
</author>
</analytic>
<series><title level="j">BMC Bioinformatics</title>
<idno type="eISSN">1471-2105</idno>
<imprint><date when="2009">2009</date>
</imprint>
</series>
</biblStruct>
</sourceDesc>
</fileDesc>
<profileDesc><textClass></textClass>
</profileDesc>
</teiHeader>
<front><div type="abstract" xml:lang="en"><sec><title>Background</title>
<p>With the growing availability of full-text articles online, scientists and other consumers of the life sciences literature now have the ability to go beyond searching bibliographic records (title, abstract, metadata) to directly access full-text content. Motivated by this emerging trend, I posed the following question: is searching full text more effective than searching abstracts? This question is answered by comparing text retrieval algorithms on MEDLINE<sup>® </sup>
abstracts, full-text articles, and spans (paragraphs) within full-text articles using data from the TREC 2007 genomics track evaluation. Two retrieval models are examined: <italic>bm25 </italic>
and the ranking algorithm implemented in the open-source Lucene search engine.</p>
</sec>
<sec><title>Results</title>
<p>Experiments show that treating an entire article as an indexing unit does not consistently yield higher effectiveness compared to abstract-only search. However, retrieval based on spans, or paragraphs-sized segments of full-text articles, consistently outperforms abstract-only search. Results suggest that highest overall effectiveness may be achieved by combining evidence from spans and full articles.</p>
</sec>
<sec><title>Conclusion</title>
<p>Users searching full text are more likely to find relevant articles than searching only abstracts. This finding affirms the value of full text collections for text retrieval and provides a starting point for future work in exploring algorithms that take advantage of rapidly-growing digital archives. Experimental results also highlight the need to develop distributed text retrieval algorithms, since full-text articles are significantly longer than abstracts and may require the computational resources of multiple machines in a cluster. The MapReduce programming model provides a convenient framework for organizing such computations.</p>
</sec>
</div>
</front>
<back><div1 type="bibliography"><listBibl><biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
</listBibl>
</div1>
</back>
</TEI>
<pmc article-type="research-article"><pmc-dir>properties open_access</pmc-dir>
<front><journal-meta><journal-id journal-id-type="nlm-ta">BMC Bioinformatics</journal-id>
<journal-title>BMC Bioinformatics</journal-title>
<issn pub-type="epub">1471-2105</issn>
<publisher><publisher-name>BioMed Central</publisher-name>
</publisher>
</journal-meta>
<article-meta><article-id pub-id-type="pmid">19192280</article-id>
<article-id pub-id-type="pmc">2695361</article-id>
<article-id pub-id-type="publisher-id">1471-2105-10-46</article-id>
<article-id pub-id-type="doi">10.1186/1471-2105-10-46</article-id>
<article-categories><subj-group subj-group-type="heading"><subject>Research Article</subject>
</subj-group>
</article-categories>
<title-group><article-title>Is searching full text more effective than searching abstracts?</article-title>
</title-group>
<contrib-group><contrib id="A1" corresp="yes" contrib-type="author"><name><surname>Lin</surname>
<given-names>Jimmy</given-names>
</name>
<xref ref-type="aff" rid="I1">1</xref>
<xref ref-type="aff" rid="I2">2</xref>
<email>jimmylin@umd.edu</email>
</contrib>
</contrib-group>
<aff id="I1"><label>1</label>
National Center for Biotechnology Information, National Library of Medicine, Bethesda, Maryland, USA</aff>
<aff id="I2"><label>2</label>
The iSchool, University of Maryland, College Park, Maryland, USA</aff>
<pub-date pub-type="collection"><year>2009</year>
</pub-date>
<pub-date pub-type="epub"><day>3</day>
<month>2</month>
<year>2009</year>
</pub-date>
<volume>10</volume>
<fpage>46</fpage>
<lpage>46</lpage>
<ext-link ext-link-type="uri" xlink:href="http://www.biomedcentral.com/1471-2105/10/46"></ext-link>
<history><date date-type="received"><day>2</day>
<month>10</month>
<year>2008</year>
</date>
<date date-type="accepted"><day>3</day>
<month>2</month>
<year>2009</year>
</date>
</history>
<permissions><copyright-statement>Copyright © 2009 Lin; licensee BioMed Central Ltd.</copyright-statement>
<copyright-year>2009</copyright-year>
<copyright-holder>Lin; licensee BioMed Central Ltd.</copyright-holder>
<license license-type="open-access" xlink:href="http://creativecommons.org/licenses/by/2.0"><p>This is an Open Access article distributed under the terms of the Creative Commons Attribution License (<ext-link ext-link-type="uri" xlink:href="http://creativecommons.org/licenses/by/2.0"></ext-link>
), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.</p>
<pmc-comment>
Lin
Jimmy
jimmylin@umd.edu
Is searching full text more effective than searching abstracts?
2009 BMC Bioinformatics 10(1): 46-. (2009) 1471-2105(2009)10:1<46> urn:ISSN:1471-2105 </pmc-comment>
</license>
</permissions>
<abstract><sec><title>Background</title>
<p>With the growing availability of full-text articles online, scientists and other consumers of the life sciences literature now have the ability to go beyond searching bibliographic records (title, abstract, metadata) to directly access full-text content. Motivated by this emerging trend, I posed the following question: is searching full text more effective than searching abstracts? This question is answered by comparing text retrieval algorithms on MEDLINE<sup>® </sup>
abstracts, full-text articles, and spans (paragraphs) within full-text articles using data from the TREC 2007 genomics track evaluation. Two retrieval models are examined: <italic>bm25 </italic>
and the ranking algorithm implemented in the open-source Lucene search engine.</p>
</sec>
<sec><title>Results</title>
<p>Experiments show that treating an entire article as an indexing unit does not consistently yield higher effectiveness compared to abstract-only search. However, retrieval based on spans, or paragraphs-sized segments of full-text articles, consistently outperforms abstract-only search. Results suggest that highest overall effectiveness may be achieved by combining evidence from spans and full articles.</p>
</sec>
<sec><title>Conclusion</title>
<p>Users searching full text are more likely to find relevant articles than searching only abstracts. This finding affirms the value of full text collections for text retrieval and provides a starting point for future work in exploring algorithms that take advantage of rapidly-growing digital archives. Experimental results also highlight the need to develop distributed text retrieval algorithms, since full-text articles are significantly longer than abstracts and may require the computational resources of multiple machines in a cluster. The MapReduce programming model provides a convenient framework for organizing such computations.</p>
</sec>
</abstract>
</article-meta>
</front>
<body><sec><title>Background</title>
<p>The exponential growth of peer-reviewed literature and the breakdown of disciplinary boundaries heralded by genome-scale instruments have made it harder than ever for scientists to find and assimilate all the publications important to their research [<xref ref-type="bibr" rid="B1">1</xref>
]. Thus, tools such as search engines are becoming indispensable. Motivated by the desire to develop more effective text retrieval algorithms for consumers of the life sciences literature, this study poses a straightforward question: Is searching full text more effective than searching abstracts? That is, given a particular information need expressed as a query, is the user more likely to find relevant articles searching the full text or searching only the abstracts?</p>
<p>This question is highly relevant today due to the growing availability of full-text articles. In the United States, the NIH Public Access Policy now requires that all research published with NIH funding be made publicly accessible. More broadly, the Open Access movement for the dissemination of scientific knowledge has gained significant traction worldwide. These trends have contributed to the accumulation of full-text articles in public archives such as PubMed Central and on the websites of Open Access journal publishers. The growth of freely-available content represents a significant opportunity for scientists, clinicians, and other users of online retrieval systems – it is now possible to go beyond searching bibliographic data (abstract, title, metadata) in sources such as MEDLINE to directly search contents of the full text. Indeed, Zweigenbaum et al. [<xref ref-type="bibr" rid="B2">2</xref>
,<xref ref-type="bibr" rid="B3">3</xref>
] identified analysis of full-text articles as one of the frontiers in biomedical text mining.</p>
<p>To be clear, I refer to full-text search as the ability to perform retrieval on the entire textual content of an article (including its title and abstract), whereas abstract search refers to retrieval based only on abstract and title (similar to what is available in PubMed<sup>® </sup>
today). This work focuses on content-based searching only; experiments do not take advantage of metadata (e.g., authors, journal titles, MeSH<sup>® </sup>
descriptors), since they would presumably be available for both full-text and abstract searches.</p>
<p>Not surprisingly, there isn't a straightforward answer to the question posed in this study. I describe experiments with MEDLINE abstracts, full-text articles, and spans (paragraphs) within full-text articles using data from the TREC 2007 genomics track evaluation. The experiments examined two retrieval models: <italic>bm25 </italic>
and the ranking algorithm implemented in the open-source Lucene search engine. Results show that treating an entire article as an indexing unit does not consistently yield higher effectiveness compared to abstract search. However, retrieval based on spans, or paragraphs-sized segments of full-text articles, consistently outperforms abstract search. Results suggest that highest overall effectiveness may be achieved by combining evidence from spans and full articles. These findings affirm the value of full text collections for text retrieval and provide a starting point for future work in exploring algorithms that take advantage of full text.</p>
<p>One important implication of this work is the need to develop scalable text retrieval algorithms, since full-text articles are significantly longer than abstracts. In the near future, the amount of available content will likely outgrow the capabilities of individual machines, thus requiring the use of clusters for basic processing tasks. I explore this issue with Ivory, a toolkit for distributed text retrieval built on top of Hadoop, an open-source implementation of the MapReduce programming model [<xref ref-type="bibr" rid="B4">4</xref>
].</p>
<sec><title>Related Work</title>
<p>Despite much optimism among researchers about the potential of full-text articles, it is not completely clear how present techniques for mining the biomedical literature, primarily developed for title, abstract, and metadata (e.g., MeSH descriptors), can be adapted to full text. For some tasks, full text does not appear to offer much beyond title and abstract. For example, consider the Medical Text Indexer (MTI), a production tool at the National Library of Medicine (NLM) that assists human indexers in assigning MeSH descriptors to MEDLINE citations based on title and abstract. Gay et al. [<xref ref-type="bibr" rid="B5">5</xref>
] reported their experiences on extending MTI to base MeSH recommendations on full text. After much tuning and careful selection of article sections, a modest gain in effectiveness was achieved. However, the improvements were most likely "not worth the extra effort" (personal communication, Alan Aronson) and there are currently no plans to integrate full-text capabilities into the NLM article processing pipeline. Furthermore, it is unclear whether the particular treatment of article sections is generalizable beyond the relatively small set of articles examined in the study.</p>
<p>Other researchers have also tried to exploit information in full-text articles for various text mining tasks. For example, Yu et al. [<xref ref-type="bibr" rid="B6">6</xref>
] used surface patterns to extract synonyms for gene and protein names, and reported higher precision on full text than on abstracts. More recently, Seki and Mostafa [<xref ref-type="bibr" rid="B7">7</xref>
] explored an "inference network" approach to mining gene-disease associations. Taking advantage of full text yields a small gain in effectiveness (consistent with the MTI findings). However, the results were based on a small collection of articles and can only be characterized as preliminary. As with the MTI experiments, there remain questions about the generalizability of the results beyond those articles examined.</p>
<p>There is no doubt that a significant amount of information is contained in well-written abstracts. Journal requirements for structured abstracts assist authors in crafting highly-informative prose that covers the key aspects of their work. In the clinical domain, for example, Demner-Fushman et al. [<xref ref-type="bibr" rid="B8">8</xref>
] showed that information in abstracts is sufficient to identify articles that are potentially useful for clinical decision support. In the biomedical domain, Yu [<xref ref-type="bibr" rid="B9">9</xref>
] examined text associated with images in articles and concluded that sentences in the abstract suffice to summarize image content. In fact, she suggested that abstract sentences may actually be superior, since associated text in the article typically describes only experimental procedures and often does not include the findings or conclusions of an experiment. In a related study, Yu and Lee [<xref ref-type="bibr" rid="B10">10</xref>
] discovered that 88% of figures and 85% of tables can be summarized by sentences in the abstract, and that 67% of abstract sentences correspond to images in the full-text articles. These results demonstrate that, at least for some tasks, it is unclear what additional value full-text content adds beyond title, abstract, and metadata.</p>
<p>Additionally, researchers have compared the term content of abstracts with that of full text. Shah et al. [<xref ref-type="bibr" rid="B11">11</xref>
] examined a collection of articles and found that abstracts were the richest source of relevant keywords. This finding was echoed by Schuemie et al. [<xref ref-type="bibr" rid="B12">12</xref>
], who concluded that the density of useful information is highest in the abstract, but information coverage in full text is greater than that of abstracts. However, the practicality of mining full-text articles is unclear due to increased computational requirements. Both these articles focused on characterizing texts and did not examine the impact of abstract vs. full text on a text-mining task.</p>
<p>There has been much work on processing full-text content, for example, the automatic extraction of gene names and protein interactions in the BioCreative evaluations [<xref ref-type="bibr" rid="B13">13</xref>
,<xref ref-type="bibr" rid="B14">14</xref>
]. However, that body of research differs significantly from the goals of this study in that I am primarily interested in differences between full text and abstracts, and the impact of these differences on effectiveness in text retrieval. In gene identification and related information extraction tasks, the text collection is fixed, while researchers attempt to develop effective algorithms (as determined by some standard metric such as F-measure). Specifically, the tasks are designed in a manner such that the source of the text is not a relevant factor. Experiments in this article, on the other hand, focus both on algorithms <italic>and </italic>
data.</p>
<p>The problem of retrieving sub-document segments of text has previously been explored in the information retrieval literature [<xref ref-type="bibr" rid="B15">15</xref>
-<xref ref-type="bibr" rid="B24">24</xref>
]; the task is often called passage retrieval. Recently, there has been substantial interest in XML retrieval, which shares many of the same issues as passage retrieval since XML documents naturally support retrieval at different granularities (i.e., every XML element is a potential result). The locus of research activity resides in the INitiative for Evaluation of XML Retrieval (INEX), an annual evaluation forum that began in 2002 [<xref ref-type="bibr" rid="B25">25</xref>
]. For several years, the evaluation used a collection of XML-encoded journal articles from the IEEE Computer Society. Most relevant to this work, the genomics "track" at the 2007 Text Retrieval Conference (TREC) has explored passage retrieval in the life sciences domain. The overview paper [<xref ref-type="bibr" rid="B26">26</xref>
] provides an entry point into that literature (also see Section 5.1). Experiments reported in this article used the test collection from the TREC 2007 evaluation.</p>
<p>There is one important difference between this work and the research discussed above. Whereas I ask the question "Is searching full text more effective than searching abstracts?", previous work simply assumes that the answer is <italic>yes</italic>
. Research papers on passage retrieval often take for granted that retrieving passages provides value to the user. The INEX evaluations implicitly assume that retrieving XML fragments is desirable (although there have been studies that explore the validity of this assumption [<xref ref-type="bibr" rid="B27">27</xref>
,<xref ref-type="bibr" rid="B28">28</xref>
]). Since widespread availability of full text is a relatively recent phenomenon in the life sciences, and searching abstracts has been available for decades (and shown to be reasonably effective), it is worth questioning the premise that searching full text is inherently superior. Focusing on this question, however, certainly does not diminish the contributions of previous work: to the extent that full text is shown to be valuable for text retrieval in this specific domain, findings from related work can be leveraged to inform the development of full-text retrieval algorithms for the life sciences literature.</p>
</sec>
<sec><title>Comparison of Full Text and Abstracts</title>
<p>In comparing search effectiveness on full-text articles and abstracts, it makes sense to begin by discussing their characteristics and enumerating potential advantages and disadvantages. Such an analysis could guide the interpretation of experimental results.</p>
<p>Length is the most obvious difference between full-text articles and abstracts – the former provides systems with significantly more text to process. Most information retrieval algorithms today build on "bag of words" representations, where text is captured as a weighted feature vector with each term as a feature [<xref ref-type="bibr" rid="B29">29</xref>
], or as a probability distribution over terms in the case of language modeling approaches [<xref ref-type="bibr" rid="B30">30</xref>
,<xref ref-type="bibr" rid="B31">31</xref>
]. These models derive from statistical properties such as term frequency and document frequency. More text could yield a more robust characterization of these statistics (for example, in the language modeling framework, longer documents require less smoothing). However, the potential downside is that full text may introduce noise. For example, an article may contain an elaborate discussion about related work that does not directly pertain to the article's main focus. Articles often contain conjectures (that turn out to be incorrect) or future work (which may or may not be fruitful lines of inquiry). In these cases, term statistics may be misleading due to the presence of "distractors" that dilute the impact of important terms. In contrast, abstracts focus on the key ideas presented in the articles and little else. Similar observations have been made with respect to collections of newswire documents (e.g., [<xref ref-type="bibr" rid="B17">17</xref>
]). Many news stories are written about one central topic, but contain many aspects that are only loosely connected – in these cases, a global characterization of the entire document may not accurately capture what the article is "about".</p>
<p>Another challenge with full-text articles is the variety of formats in which they are distributed. Whereas there is a small number of formats for encoding MEDLINE abstracts, full-text collections can be found in XML, SGML, PDF, and even raw HTML (e.g., the result of Web crawls). Each format is associated with idiosyncrasies that make pre-processing a challenge. Just to give one example, there are numerous ways to encode Greek symbols (<italic>α</italic>
, <italic>β</italic>
, ...) – sometimes, they are directly encoded in extended character sets (e.g., Unicode); often, they are "written-out" (e.g., alpha, beta, ...); in other cases, they are encoded as HTML entities (e.g., α). The prevalence of special characters in the literature complicates seemingly simple tasks such as tokenization. The problem is further exacerbated when one tries to combine full-text collections from different sources (in different formats).</p>
<p>Access to full text is necessary for certain fine-grained retrieval tasks, e.g., image search [<xref ref-type="bibr" rid="B3">3</xref>
]. Recently, there has been substantial interest in this problem [<xref ref-type="bibr" rid="B32">32</xref>
-<xref ref-type="bibr" rid="B34">34</xref>
], based on both image features and features derived from text associated with images, e.g., captions and sentences in which the figures are referenced. Full text is obviously essential for extracting these features. For other tasks, access to full text may be desirable, e.g., question answering. Unlike a search engine, a question answering system attempts to return a response that directly answers the user's question. Due to their specificity, users' questions sometimes may not be sufficiently addressed by abstracts – often, useful nuggets of information may be found in parts of articles that are not well reflected in the abstract (e.g., in the related work or discussion sections).</p>
<p>However, it is also important to take into account other considerations in information seeking. Since many users are uncomfortable reading large amounts of text on screen, they often print out journal articles first before reading them in detail. In these cases, finer-grained passage and image access capabilities are most useful in helping users decide what articles they want to read, rather than directly answering users' questions. Often, complex information needs such as those faced by biologists cannot be answered with a paragraph or an image – instead, information returned by the system must be considered in the context of the <italic>entire </italic>
article from which the segment was extracted (for example, so that the scientist can verify the experimental procedure, consider alternative hypotheses mentioned in the discussion section, etc.). For this reason, I focus on a system's ability to identify relevant articles. This corresponds to <italic>ad hoc </italic>
retrieval, a task that has been well studied by information retrieval researchers in large-scale evaluations such as TREC.</p>
<p>Based on this discussion, it is clear that there are advantages and disadvantages to full-text retrieval. However, the extent to which these various factors balance out and affect search effectiveness can only be determined empirically. The next section presents a series of experiments that explore these issues.</p>
</sec>
</sec>
<sec><title>Results</title>
<sec><title>Test Collection</title>
<p>Retrieval experiments in this article were conducted with data from the TREC 2007 genomics track evaluation [<xref ref-type="bibr" rid="B26">26</xref>
], which used a collection of 162,259 full-text articles from Highwire Press. MEDLINE records that correspond to the full-text articles were also provided as supplementary data. To standardize system output, the organizers of the evaluation divided up the entire collection into 12.6 million "legal spans" (i.e., paragraphs) that represent the basic units of retrieval. The test collection contains 36 information needs, called "topics", and relevance judgments, which are lists of legal spans that were assessed by humans to be relevant for each topic. Despite the availability of relevance judgments at the level of spans, I focused on article-level relevance in order to support a meaningful comparison of abstract and full-text search. Section 5.1 describes this test collection in more detail.</p>
</sec>
<sec><title>Retrieval Conditions</title>
<p>A matrix experiment was devised with two different retrieval models (in three separate implementations) and three different data conditions. The goal was to compare the effectiveness of different experimental settings, as quantified by standard retrieval metrics (see Section 2.4). The retrieval models examined were:</p>
<p>• The Okapi <italic>bm25 </italic>
ranking algorithm [<xref ref-type="bibr" rid="B35">35</xref>
,<xref ref-type="bibr" rid="B36">36</xref>
] (described in Section 5.2), as implemented in Ivory, a toolkit for distributed text retrieval. Ivory was developed with Hadoop, an open-source implementation of the MapReduce programming model (see Section 5.3 for details).</p>
<p>• The ranking algorithm implemented in the open-source search engine Lucene, which represents a modified <italic>tf.idf </italic>
retrieval model (described in Section 5.2). Due to its popularity and ease of use, Lucene provides a good baseline for comparison. This ranking algorithm was also implemented in Ivory, primarily for evaluation of efficiency and scalability (see Section 2.6).</p>
<p>The matrix design consisted of three different data conditions. The following indexes were built (one set of indexes for Lucene, another set of indexes for Ivory):</p>
<p>• Abstract index, built on the abstracts and titles of articles in the Highwire collection, taken from the MEDLINE records. Each abstract was considered a "document" for retrieval purposes.</p>
<p>• Article index, built on the full-text articles in the Highwire collection (which include abstracts and titles). The entire text of each article was considered a "document" for retrieval purposes.</p>
<p>• Span index, built on the legal spans in the Highwire collection. In this experimental condition, each of the 12.6 million spans in the collection was treated as if it were a "document".</p>
<p>For each cell in the matrix experiment, I performed a retrieval run with 36 queries, taken verbatim from the TREC 2007 genomics track test data (see Section 5.1 for examples). With the abstract and article indexes, retrieval results consisted of 1000 article ids in rank order. For the span index, the ranked results consisted of span ids. As a post-processing step, I applied a script to create a ranking of articles from a ranking of spans, using two different methods described by Hearst and Plaunt [<xref ref-type="bibr" rid="B17">17</xref>
]:</p>
<p>• Maximum of supporting spans (max): the score for an article is computed as the maximum of scores for all spans contained in that article. Article ids were sorted by this score in descending order. This method favors articles that have a single high-scoring span.</p>
<p>• Sum of supporting spans (sum): the score for an article is computed as the sum of scores for all spans contained in that article. Article ids were sorted by this score in descending order. This method favors articles that have many potentially-relevant spans.</p>
<p>In order to ensure that the post-processing script generated a ranked list of 1000 articles (same as the abstract and article conditions), 5000 spans were retrieved initially.</p>
</sec>
<sec><title>Evidence Combination</title>
<p>An obvious extension to the matrix experiment discussed in the previous section is to integrate evidence from multiple sources. As an initial exploration, I conducted a series of experiments that combined the results of span retrieval with either article or abstract retrieval. In both cases, runs were combined by first normalizing each set of scores and then averaging scores from the different runs. The goal of this experiment was to examine the effect of combining content representations at different granularities. Note that in principle a simple average of the scores could be replaced with weighted linear interpolation (or some other evidence combination technique), but in absence of a principled approach to determining parameters, I opted not to explore this option for fear of overtraining on limited data.</p>
</sec>
<sec><title>Evaluation Metrics</title>
<p>For all experimental conditions, I arrived at a ranking of 1000 articles, which supported a meaningful comparison across all data conditions. To evaluate effectiveness, three different metrics were collected:</p>
<p>• Mean average precision (MAP), the single-point metric of effectiveness most widely accepted by the information retrieval community. The standard cutoff of 1000 hits was used.</p>
<p>• Precision at 20 (P20), the fraction of articles in the top twenty results that are relevant. The cutoff of twenty equals the number of hits on a result page in the present PubMed interface. In a Web environment, many searchers only focus on the first page of results.</p>
<p>• Interpolated precision at recall of 50% (IP@R50), which attempts to capture the experience of a dedicated, recall-oriented searcher (e.g., scientist conducting a literature search). This metric quantifies the amount of irrelevant material a user must tolerate in order to find half of the relevant articles – the higher the IP@R50, the less "junk" a user must sort through. In this study, I characterize IP@R50 as a "recall-oriented" metric. The recall level of 50% was arbitrarily selected.</p>
<p>Section 2.5 focuses on retrieval effectiveness with Ivory, comparing <italic>bm25 </italic>
and the implementation of Lucene's ranking algorithm. Section 2.6 focuses on efficiency, comparing Lucene with the implementation of its ranking algorithm in Ivory.</p>
</sec>
<sec><title>Retrieval Effectiveness</title>
<p>Results of the matrix experiment described in Section 2.2 with Ivory are presented in Table <xref ref-type="table" rid="T1">1</xref>
. The three parts of the table show effectiveness in terms of MAP, P20, and IP@R50. The columns report figures for the two retrieval models: <italic>bm25 </italic>
and the Ivory implementation of Lucene's ranking algorithm. Abstract retrieval (i.e., retrieval using the abstract index) is taken as the baseline, and the table provides relative differences with respect to this condition. The Wilcoxon signed-rank test was applied in all cases to assess the statistical significance of the results.</p>
<table-wrap position="float" id="T1"><label>Table 1</label>
<caption><p>Effectiveness of <italic>bm25 </italic>
and the Lucene ranking algorithm on abstracts, full-text articles, and spans from full text.</p>
</caption>
<table frame="hsides" rules="groups"><thead><tr><td align="center" colspan="3"><bold>MAP</bold>
</td>
</tr>
</thead>
<tbody><tr><td></td>
<td align="left">Ivory (<italic>bm25</italic>
)</td>
<td align="left">Ivory (<italic>Lucene</italic>
)</td>
</tr>
<tr><td colspan="3"><hr></hr>
</td>
</tr>
<tr><td align="left">Abstract</td>
<td align="left">0.163</td>
<td align="left">0.129</td>
</tr>
<tr><td align="left">Article</td>
<td align="left">0.146 (-11%)°</td>
<td align="left">0.235 (+82%)**</td>
</tr>
<tr><td align="left">Span (max)</td>
<td align="left">0.240 (+47%)**</td>
<td align="left">0.206 (+60%)**</td>
</tr>
<tr><td align="left">Span (sum)</td>
<td align="left">0.192 (+18%)*</td>
<td align="left">0.198 (+54%)**</td>
</tr>
<tr><td colspan="3"><hr></hr>
</td>
</tr>
<tr><td></td>
<td></td>
<td></td>
</tr>
<tr><td align="center" colspan="3"><bold>P20</bold>
</td>
</tr>
<tr><td colspan="3"><hr></hr>
</td>
</tr>
<tr><td></td>
<td align="left">Ivory (<italic>bm25</italic>
)</td>
<td align="left">Ivory (<italic>Lucene</italic>
)</td>
</tr>
<tr><td colspan="3"><hr></hr>
</td>
</tr>
<tr><td align="left">Abstract</td>
<td align="left">0.322</td>
<td align="left">0.293</td>
</tr>
<tr><td align="left">Article</td>
<td align="left">0.158 (-51%)**</td>
<td align="left">0.353 (+20%)*</td>
</tr>
<tr><td align="left">Span (max)</td>
<td align="left">0.357 (+11%)°</td>
<td align="left">0.332 (+13%)°</td>
</tr>
<tr><td align="left">Span (sum)</td>
<td align="left">0.314 (-3%)°</td>
<td align="left">0.317 (+8%)*</td>
</tr>
<tr><td colspan="3"><hr></hr>
</td>
</tr>
<tr><td></td>
<td></td>
<td></td>
</tr>
<tr><td align="center" colspan="3"><bold>IP@R50</bold>
</td>
</tr>
<tr><td colspan="3"><hr></hr>
</td>
</tr>
<tr><td></td>
<td align="left">Ivory (<italic>bm25</italic>
)</td>
<td align="left">Ivory (<italic>Lucene</italic>
)</td>
</tr>
<tr><td colspan="3"><hr></hr>
</td>
</tr>
<tr><td align="left">Abstract</td>
<td align="left">0.110</td>
<td align="left">0.090</td>
</tr>
<tr><td align="left">Article</td>
<td align="left">0.163 (+48%)°</td>
<td align="left">0.222 (+146%)**</td>
</tr>
<tr><td align="left">Span (max)</td>
<td align="left">0.212 (+93%)**</td>
<td align="left">0.189 (+109%)**</td>
</tr>
<tr><td align="left">Span (sum)</td>
<td align="left">0.149 (+36%)*</td>
<td align="left">0.159 (+77%)**</td>
</tr>
</tbody>
</table>
<table-wrap-foot><p>For all metrics, relative improvements over baseline are shown; ** = statistically significant (<italic>p </italic>
< 0.01); * = statistically significant (<italic>p </italic>
< 0.05); ° = not significant.</p>
</table-wrap-foot>
</table-wrap>
<p>Results show that for abstract retrieval, <italic>bm25 </italic>
is significantly more effective in terms of MAP than the Lucene ranking algorithm (<italic>p </italic>
< 0.01). Comparing abstract retrieval with article retrieval (i.e., retrieval using the article index), MAP is significantly higher (<italic>p </italic>
< 0.01) for Lucene but differences are not statistically significant for <italic>bm25</italic>
. For the Lucene ranking algorithm, article retrieval significantly outperforms abstract retrieval for the other two metrics as well. On the other hand, for <italic>bm25</italic>
, article retrieval either hurts (P20), or doesn't have a significant impact (IP@P50). Article retrieval, which simply treats full-text articles as longer "documents", does not appear to yield consistent gains in effectiveness.</p>
<p>For retrieval using the span index, the "max" strategy for generating article rankings appears to be more effective than the "sum" strategy. In terms of MAP and IP@R50, both span retrieval strategies significantly outperform retrieval with the abstract index, for both <italic>bm25 </italic>
and the Lucene ranking algorithm. For IP@R50, in particular, the gains are quite substantial. However, span retrieval does not appear to have a significant impact on P20 compared to the abstract retrieval baseline.</p>
<p>Table <xref ref-type="table" rid="T2">2</xref>
shows the results of significance testing between article retrieval and span retrieval with the "max" strategy (the more effective, and thus more interesting, of the two strategies). For <italic>bm25</italic>
, article retrieval is significantly worse in terms of MAP and P20. None of the differences are significant for the Lucene ranking algorithm. Note that for these comparisons, there are often large differences in per-topic scores, but in many cases one run does not consistently outperform another – for this reason, substantial differences in the mean may not necessarily yield statistical significance. These results suggest that span retrieval is at least as effective as treating the entire article as an indexing unit, and at least in a few cases, span retrieval is superior.</p>
<table-wrap position="float" id="T2"><label>Table 2</label>
<caption><p>Results of significance testing comparing article retrieval with span retrieval ("max" strategy).</p>
</caption>
<table frame="hsides" rules="groups"><thead><tr><td></td>
<td align="left">Ivory (<italic>bm25</italic>
)</td>
<td align="left">Ivory (<italic>Lucene</italic>
)</td>
</tr>
</thead>
<tbody><tr><td align="left">MAP</td>
<td align="left"><italic>p </italic>
< 0.01</td>
<td align="left"><italic>n.s.</italic>
</td>
</tr>
<tr><td align="left">P20</td>
<td align="left"><italic>p </italic>
< 0.01</td>
<td align="left"><italic>n.s.</italic>
</td>
</tr>
<tr><td align="left">IP@R50</td>
<td align="left"><italic>n.s.</italic>
</td>
<td align="left"><italic>n.s.</italic>
</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>Results for the evidence combination experiments are shown in Table <xref ref-type="table" rid="T3">3</xref>
, where span retrieval is combined with abstract and article retrieval. In the interest of space, effectiveness metrics are only shown for the "max" strategy. Relative differences are shown with respect to the span retrieval baseline. As with before, the Wilcoxon signed-rank test was applied in all cases to assess the statistical significance of the results. For the Lucene ranking algorithm, combining span retrieval with article retrieval yields significant gains for all three metrics. Other differences are not statistically significant.</p>
<table-wrap position="float" id="T3"><label>Table 3</label>
<caption><p>Effectiveness of <italic>bm25 </italic>
and the Lucene ranking algorithm combining evidence from spans with evidence from abstracts and articles.</p>
</caption>
<table frame="hsides" rules="groups"><thead><tr><td align="center" colspan="3"><bold>MAP</bold>
</td>
</tr>
</thead>
<tbody><tr><td></td>
<td align="left">Ivory (<italic>bm25</italic>
)</td>
<td align="left">Ivory (<italic>Lucene</italic>
)</td>
</tr>
<tr><td colspan="3"><hr></hr>
</td>
</tr>
<tr><td align="left">Span (max)</td>
<td align="left">0.240</td>
<td align="left">0.206</td>
</tr>
<tr><td align="left">Span (max) + Abstract</td>
<td align="left">0.257 (+7%)°</td>
<td align="left">0.216 (+5%)°</td>
</tr>
<tr><td align="left">Span (max) + Article</td>
<td align="left">0.257 (+7%)°</td>
<td align="left">0.262 (+27%)**</td>
</tr>
<tr><td colspan="3"><hr></hr>
</td>
</tr>
<tr><td></td>
<td></td>
<td></td>
</tr>
<tr><td align="center" colspan="3"><bold>P20</bold>
</td>
</tr>
<tr><td colspan="3"><hr></hr>
</td>
</tr>
<tr><td></td>
<td align="left">Ivory (<italic>bm25</italic>
)</td>
<td align="left">Ivory (<italic>Lucene</italic>
)</td>
</tr>
<tr><td colspan="3"><hr></hr>
</td>
</tr>
<tr><td align="left">Span (max)</td>
<td align="left">0.357</td>
<td align="left">0.332</td>
</tr>
<tr><td align="left">Span (max) + Abstract</td>
<td align="left">0.382 (+7%)°</td>
<td align="left">0.349 (+5%)°</td>
</tr>
<tr><td align="left">Span (max) + Article</td>
<td align="left">0.343 (-4%)°</td>
<td align="left">0.404 (+22%)**</td>
</tr>
<tr><td colspan="3"><hr></hr>
</td>
</tr>
<tr><td></td>
<td></td>
<td></td>
</tr>
<tr><td align="center" colspan="3"><bold>IP@R50</bold>
</td>
</tr>
<tr><td colspan="3"><hr></hr>
</td>
</tr>
<tr><td></td>
<td align="left">Ivory (<italic>bm25</italic>
)</td>
<td align="left">Ivory (<italic>Lucene</italic>
)</td>
</tr>
<tr><td colspan="3"><hr></hr>
</td>
</tr>
<tr><td align="left">Span (max)</td>
<td align="left">0.212</td>
<td align="left">0.189</td>
</tr>
<tr><td align="left">Span (max) + Abstract</td>
<td align="left">0.215 (+1%)°</td>
<td align="left">0.190 (+1%)°</td>
</tr>
<tr><td align="left">Span (max) + Article</td>
<td align="left">0.257 (+21%)°</td>
<td align="left">0.244 (+29%)**</td>
</tr>
</tbody>
</table>
<table-wrap-foot><p>For all metrics, relative improvements over baseline are shown; ** = statistically significant (<italic>p </italic>
< 0.01); * = statistically significant (<italic>p </italic>
< 0.05); ° = not significant.</p>
</table-wrap-foot>
</table-wrap>
<p>Table <xref ref-type="table" rid="T4">4</xref>
attempts to summarize findings from all these experiments by establishing a partial rank order of different experimental conditions (based on significance testing), in terms of each effectiveness metric and retrieval model. The "sum" strategy for span retrieval is not considered since the alternative "max" strategy appears to be more effective. In all cases, integrating span-level evidence with article-level evidence either yields the highest effectiveness or is not significantly worse than the condition that yields the highest effectiveness. This suggests that combining article content and span-level analysis is an effective approach to exploiting full text in the life sciences.</p>
<table-wrap position="float" id="T4"><label>Table 4</label>
<caption><p>Comparison of different experimental conditions for <italic>bm25 </italic>
and the Lucene ranking algorithm.</p>
</caption>
<table frame="hsides" rules="groups"><thead><tr><td align="left">Model</td>
<td align="left">Metric</td>
<td align="left">Comparison</td>
</tr>
</thead>
<tbody><tr><td align="left"><italic>bm25</italic>
</td>
<td align="left">MAP</td>
<td align="left">Span (max) + Article, Span (max) >> Abstract, Article</td>
</tr>
<tr><td></td>
<td align="left">P20</td>
<td align="left">Span (max) + Article, Span (max), Abstract >> Article</td>
</tr>
<tr><td></td>
<td align="left">IP@R50</td>
<td align="left">Span (max) + Article >> Abstract, Article; Span (max) >> Abstract</td>
</tr>
<tr><td colspan="3"><hr></hr>
</td>
</tr>
<tr><td align="left">Lucene</td>
<td align="left">MAP</td>
<td align="left">Span (max) + Article >> Span (max), Article >> Abstract</td>
</tr>
<tr><td></td>
<td align="left">P20</td>
<td align="left">Span (max) + Article > Span (max), Article; Article > Abstract</td>
</tr>
<tr><td></td>
<td align="left">IP@R50</td>
<td align="left">Span (max) + Article > Span (max), Article >> Abstract</td>
</tr>
</tbody>
</table>
<table-wrap-foot><p><italic>A </italic>
>> <italic>B </italic>
indicates that <italic>A </italic>
is significantly better than <italic>B </italic>
(<italic>p </italic>
< 0.01); <italic>A </italic>
> <italic>B </italic>
indicates that <italic>A </italic>
is significantly better than <italic>B </italic>
(<italic>p </italic>
< 0.05);</p>
</table-wrap-foot>
</table-wrap>
</sec>
<sec><title>Retrieval Efficiency</title>
<p>Given that there is value in searching full text, the question of efficiency must be addressed. The potential effectiveness gains of full text come at a significant cost in terms of dataset size. In its compressed form as distributed, the collection of 162,259 full-text articles from Highwire Press occupies 3.28 GB (12.6 GB uncompressed). The corresponding MEDLINE abstracts, also in compressed form, take up only 139 MB (502 MB uncompressed). The difference in size is more than an order of magnitude – which means that algorithms must process significantly more data to realize the potential gains of full-text content. Articles in the Highwire collection contain on average 4148 terms (after stopword removal), while abstracts contain on average only 142 terms. For reference, spans average 66 terms, or a bit less than half the length of abstracts.</p>
<p>Open-source text retrieval systems available today, designed to run on individual machines, would have no difficulty handling the Highwire collection and even collections that are much larger. However, these articles represent only a small fraction of the material already available or soon to be available. Based on recent estimates, records are added to MEDLINE at a rate of approximately 65 k per month. A lower bound on the growth of available full-text content can be estimated by examining the growth of PubMed Central. Over the past two years, the digital archive has grown by approximately 40 k articles per month. However, the growth rate is uneven due to retrospective conversion; more recently, this figure is closer to 20 k articles per month. Nevertheless, full-text collections will inevitably outgrow the capabilities of individual machines – the only practical recourse is to distribute computations across multiple machines in a cluster.</p>
<p>I have been exploring the requirements of scaling to larger datasets with Ivory, a toolkit for distributed text retrieval implemented in Java using Hadoop, which is an open-source implementation of the MapReduce framework [<xref ref-type="bibr" rid="B4">4</xref>
]. Section 5.3 describes Ivory in more detail, but an evaluation of its efficiency is presented here. Specifically, I compare the original implementation of Lucene with the Ivory implementation of the Lucene ranking algorithm (to factor out the effects of different retrieval algorithms).</p>
<p>All experiments were conducted with Amazon's Elastic Compute Cloud (EC2) service, which allows one to dynamically provision clusters of different sizes. EC2 is an example of a "utility computing" service, where anyone can "rent" computing cycles at a reasonable cost. For this work, EC2 provided a homogeneous computing environment that supports easy comparison of different cluster configurations. The basic unit of computing resource in EC2 is the small instance-hour, the virtualized equivalent of a processor core with 1.7 GB of memory, running for an hour. I experimented with the following configurations:</p>
<p>• Lucene (version 2.0), running on a single EC2 instance. Default settings "out of the box" were used for all experiments.</p>
<p>• Ivory (with Hadoop version 0.17.0), running on an EC2 cluster with 10 slave instances (plus 1 instance for the master). This is comparable to a cluster with 10 cores.</p>
<p>• Same as above, except with 20 slave instances, comparable to a cluster with 20 cores.</p>
<p>As an aside, note that physical equivalents of these clusters are quite modest by today's standards. Quad-core processors are widely available in server-class machines, and with dual processor packages, a 20-core cluster is within the means of most research groups.</p>
<p>Running times for index construction for the three different configurations are shown in Table <xref ref-type="table" rid="T5">5</xref>
. Lucene, which was not designed to run on a cluster, takes over a day to build the span index (containing 12.6 million spans). With either cluster configurations, indexing takes less than an hour. These figures should be interpreted with the caveat that Lucene builds a richer index that supports complex query operators and that I am comparing a single core to clusters. However, the point is that Lucene cannot be easily adapted to run on multiple machines and thus indexing speed is fundamentally bound by the disk bandwidth of one machine. A cluster can take advantage of the aggregate disk bandwidth of many machines, and MapReduce provides a convenient model for organizing these disk operations (see Section 5.3).</p>
<table-wrap position="float" id="T5"><label>Table 5</label>
<caption><p>Time required for index construction, comparing Lucene to different Ivory configurations.</p>
</caption>
<table frame="hsides" rules="groups"><thead><tr><td></td>
<td align="right">Lucene (1 core)</td>
<td align="right">Ivory (10 cores)</td>
<td align="right">Ivory (20 cores)</td>
</tr>
</thead>
<tbody><tr><td align="left">Abstract</td>
<td align="right">1 h 00 m 58 s</td>
<td align="right">1 m 32 s</td>
<td align="right">1 m 07 s</td>
</tr>
<tr><td align="left">Article</td>
<td align="right">19 h 09 m 23 s</td>
<td align="right">17 m 21 s</td>
<td align="right">9 m 57 s</td>
</tr>
<tr><td align="left">Span</td>
<td align="right">27 h 10 m 46 s</td>
<td align="right">39 m 58 s</td>
<td align="right">24 m 56 s</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>The speedup demonstrated by Ivory is important because time for inverted index construction places an upper bound on how fast a researcher can explore the solution space for algorithms that require manipulating the index. Since research in information retrieval is fundamentally empirical in nature, progress is driven by iterative experimentation. Thus, exceedingly long experimental cycles represent a potential impediment to advances in the state of the art.</p>
<p>In terms of retrieval, running times on the entire set of 36 topics from the TREC 2007 genomics track are shown in Table <xref ref-type="table" rid="T6">6</xref>
. The gains in efficiency are not quite as dramatic, but still substantial. In its present implementation, Ivory was designed for batch-style experiments, not real-time retrieval (see Section 5.3 for more discussion). These numbers are therefore only presented for reference, and should not be taken as indicative of efficiency in operational settings (where techniques such as caching can greatly reduce retrieval latency). My experiments primarily focus on indexing efficiency, which is more important for the issues explored in this study.</p>
<table-wrap position="float" id="T6"><label>Table 6</label>
<caption><p>Time required for retrieval runs, comparing Lucene to different Ivory configurations.</p>
</caption>
<table frame="hsides" rules="groups"><thead><tr><td></td>
<td align="right">Lucene (1 core)</td>
<td align="right">Ivory (10 cores)</td>
<td align="right">Ivory (20 cores)</td>
</tr>
</thead>
<tbody><tr><td align="left">Abstract (1000 hits)</td>
<td align="right">1 m 42 s</td>
<td align="right">51 s</td>
<td align="right">40 s</td>
</tr>
<tr><td align="left">Article (1000 hits)</td>
<td align="right">7 m 00 s</td>
<td align="right">1 m 51 s</td>
<td align="right">1 m 09 s</td>
</tr>
<tr><td align="left">Span (5000 hits)</td>
<td align="right">21 m 32 s</td>
<td align="right">11 m 57 s</td>
<td align="right">8 m 25 s</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>Taking advantage of full-text content requires more computational resources to cope with the increased quantities of data. Inevitably, full-text collections will outgrow retrieval systems designed to run on single machines – necessitating the development of distributed algorithms. The MapReduce framework provides a practical solution for distributed text retrieval.</p>
</sec>
</sec>
<sec><title>Discussion</title>
<p>Is searching full text more effective than searching abstracts? The answer appears to be <italic>yes</italic>
. Furthermore, experimental results suggest that span-level analysis provides a promising strategy for taking advantage of full-text content. Whereas simply treating entire articles as indexing units yields mixed results, span retrieval consistently outperforms abstract retrieval. Combining span- and article-level evidence yields the highest effectiveness across a range of experimental conditions.</p>
<p>Why does span retrieval work? Further analysis of results in Section 2.5 reveals some interesting observations. Focusing on the "max" strategy, Table <xref ref-type="table" rid="T1">1</xref>
shows that, overall, span retrieval has a relatively small effect on precision (seen in the P20 scores), but a large impact on recall (seen in the IP@R50 scores). This makes sense: key ideas in an article are likely reinforced multiple times, often in slightly different ways. This potentially alleviates mismatches between query terms and terms used by authors – in essence, span indexing gives a retrieval algorithm multiple opportunities to identify a relevant article. This enhanced recall leads to higher overall effectiveness in terms of MAP.</p>
<p>In general, the "max" strategy for generating article rankings from span rankings appears to be more effective than the "sum" strategy. Why is this so? One possibility is the issue of length normalization. In the current implementation, longer articles tend to have higher scores simply because they contain more spans; thus, there is an inherent bias in the "sum" strategy. Length normalization plays an important role in text retrieval [<xref ref-type="bibr" rid="B37">37</xref>
,<xref ref-type="bibr" rid="B38">38</xref>
], but I leave a thorough exploration of this issue for future work.</p>
<p>The findings in this article pave the way for future advances in full-text retrieval algorithms for the life sciences, which can draw from a wealth of previous work in the information retrieval literature on passage retrieval, XML retrieval, etc. In fact, the effectiveness of span retrieval confirms a well-known finding: ranking algorithms benefit from techniques that exploit document structure, particularly for longer documents.</p>
<p>Remaining focused on the problem of using full-text content to improve article ranking, how in general can article structure be exploited? Within the space of "bag of words" models, strategies can be organized in terms of two questions:</p>
<p>• At what levels of granularity should retrieval algorithms build representations of full-text content?</p>
<p>• How should evidence from multiple representations be combined to rank articles?</p>
<p>These two questions provide context for future work. As a start, I have experimented with two different indexing granularities (full articles and spans), but alternative approaches include sliding windows [<xref ref-type="bibr" rid="B18">18</xref>
,<xref ref-type="bibr" rid="B20">20</xref>
], multi-paragraph segments [<xref ref-type="bibr" rid="B19">19</xref>
], hierarchically-overlapping segments [<xref ref-type="bibr" rid="B38">38</xref>
,<xref ref-type="bibr" rid="B39">39</xref>
], and segments based on topic shifts [<xref ref-type="bibr" rid="B17">17</xref>
]. There are many strategies for integrating evidence from multiple content representations and representations at different granularities (e.g., [<xref ref-type="bibr" rid="B40">40</xref>
]). I have begun to examine some of these strategies, but there are many more possibilities yet to be explored. For example, differential treatment of article sections may improve effectiveness since some sections are more important than others, i.e., more likely to contain relevant information. Earlier work on a smaller collection of documents from the Federal Register illustrated the potential of assigning weights to different section types [<xref ref-type="bibr" rid="B19">19</xref>
]. More recently, Tbahriti et al. [<xref ref-type="bibr" rid="B41">41</xref>
] found section-specific weights to be helpful for retrieval in the context of structured abstracts in the life sciences. However, one challenge that must be overcome for this strategy to work on a large scale is the lack of standardized section headings – both across journals and different types of articles (e.g., research vs. review articles).</p>
<p>In this work I have focused on exploiting full-text content to better rank articles. Alternatively, one could leverage full text to directly return relevant information, i.e., with passage retrieval techniques. This was, in fact, the original design of the TREC 2007 genomics track evaluation. Of course, this begs the question: How are they related? In the information retrieval literature, a distinction is made between passage retrieval and document retrieval that exploits passage-level evidence. This exactly parallels the present discussion about retrieving segments of full-text content versus leveraging full-text content to enhance article retrieval. However, I argue that the two are complementary from a user interface point of view.</p>
<p>Leaving aside non-traditional search interfaces, a retrieval system must ultimately present users with lists of results. Consider the two approaches to exploiting full text in this context:</p>
<p>Even if the primary goal of a system is to leverage full-text content to enhance article retrieval, results have to be presented in a manner that suggests the relevance of an article. This necessarily involves creating some type of surrogate for the article, which can either be indicative or informative. Common techniques for generating such surrogates include displaying titles and metadata (as with the current PubMed interface) and short keyword-in-context extracts (as with Google Scholar). The first is primarily indicative, while the second aims to be informative. Extraction of informative text segments from articles is essentially a passage retrieval task – and in some cases, this information may already be available as a natural byproduct of the article ranking process. For example, in algorithms that integrate evidence from multiple spans within an article, those salient spans might form the basis of generating article surrogates.</p>
<p>Even if the primary goal of a system is to directly retrieve relevant passages, the passages must still be couched within the context of the article containing the passages (to provide users with pointers back to the original content). In addition, there will be cases where a passage retrieval algorithm suggests multiple passages extracted from the same article (unless this is explicitly suppressed, which may lead to loss of potentially-important information). To facilitate result presentation, it would be desirable to group passages by the articles that contain them – which essentially involves article ranking.</p>
<p>In other words, the distinction between retrieving passages and retrieving articles becomes blurred when one considers elements of the user interface. Both approaches must grapple with the same issues, thus creating synergies where algorithms specifically developed for one purpose may be useful for the other.</p>
</sec>
<sec><title>Conclusion</title>
<p>Experiments in this article with the TREC 2007 genomics track test collection illustrate that there is significant value in searching full-text articles. Given the rapidly growing availability of full text in online digital archives, this is a positive development for scientists who depend on access to the literature for their research. Results show that retrieval at the level of paragraphs within full text is significantly more effective than searching abstracts only. Combining span- and article-level evidence appears to yield the best results. However, much work remains in developing effective full-text retrieval algorithms for the life sciences literature: toward that end, this work presents a first step.</p>
<p>One important issue in moving from searching abstracts to searching full text is that of scalability. Gains in effectiveness come at a cost – algorithms must process significantly more text. Although currently-available tools designed to run on single machines suffice to handle present test collections, it is clear that future systems must distribute computations across multiple machines to cope with ever-growing quantities of text. As illustrated by Ivory, MapReduce provides a convenient framework for distributed text retrieval. The combination of greater effectiveness enabled by full text and greater efficiency enabled by cluster computing paves the way for exciting future developments in information access tools for the life sciences.</p>
</sec>
<sec sec-type="methods"><title>Methods</title>
<sec><title>Test Collection</title>
<p>Experiments reported in this article were conducted with the test collection from the TREC 2007 genomics track evaluation [<xref ref-type="bibr" rid="B26">26</xref>
]. A test collection is a standard laboratory tool for evaluating text retrieval systems, which consists of three components:</p>
<p>• a collection – documents on which retrieval is performed,</p>
<p>• a set of information needs – written statements describing the desired information (called "topics"), which are usually provided as queries to the system, and</p>
<p>• relevance judgments – records specifying the documents that should be retrieved in response to each information need (i.e., which documents are relevant to each topic).</p>
<p>The use of test collections to assess the effectiveness of text retrieval algorithms is a well-established methodology in the information retrieval literature, dating back to the Cranfield experiments in the 60's [<xref ref-type="bibr" rid="B42">42</xref>
]. These tools enable rapid, reproducible experiments in a controlled setting without requiring manual assessment. In modern information retrieval research, test collections are created through large-scale evaluations, such as the Text Retrieval Conferences (TRECs) sponsored by the U.S. National Institute of Standards and Technology (NIST) [<xref ref-type="bibr" rid="B43">43</xref>
]. TREC is an annual evaluation forum that draws together researchers from around the world to work on shared problems in different "tracks". Over the years, TREC has explored a wide variety of problems ranging from multimedia retrieval to spam detection. The genomics track was dedicated to exploring biomedical text retrieval.</p>
<p>The TREC 2007 genomics track used a collection of 162,259 full-text articles assembled in 2006. These articles came from the electronic distribution of 49 genomics-related journals from Highwire Press. The articles were distributed in HTML, which preserved formatting, structure, table and figure legends, etc. In addition, the organizers gathered MEDLINE records corresponding to each of the full-text articles, which were also made available to participants in the evaluation.</p>
<p>The test collection contains 36 official topics in the form of questions that asked for specific entities such as proteins and drugs – the first five topics are shown in Table <xref ref-type="table" rid="T7">7</xref>
. Entities of interest are denoted in square brackets and correspond to controlled terminologies from various sources (e.g., MeSH). The topics were created after surveying biologists about recent information needs, and hence can be considered representative for an important group of users who regularly depend on access to the literature.</p>
<table-wrap position="float" id="T7"><label>Table 7</label>
<caption><p>Sample topics from the TREC 2007 genomics track.</p>
</caption>
<table frame="hsides" rules="groups"><tbody><tr><td align="left">200</td>
<td align="left">What serum [PROTEINS] change expression in association with high disease activity in lupus?</td>
</tr>
<tr><td align="left">201</td>
<td align="left">What [MUTATIONS] in the Raf gene are associated with cancer?</td>
</tr>
<tr><td align="left">202</td>
<td align="left">What [DRUGS] are associated with lysosomal abnormalities in the nervous system?</td>
</tr>
<tr><td align="left">203</td>
<td align="left">What [CELL OR TISSUE TYPES] express receptor binding sites for vasoactive intestinal peptide (VIP) on their cell surface?</td>
</tr>
<tr><td align="left">204</td>
<td align="left">What nervous system [CELL OR TISSUE TYPES] synthesize neurosteroids in the brain?</td>
</tr>
<tr><td align="left">205</td>
<td align="left">What [SIGNS OR SYMPTOMS] of anxiety disorder are related to coronary artery disease?</td>
</tr>
</tbody>
</table>
</table-wrap>
<p>Relevance judgments consist of lists of legal spans that were determined to contain an answer, based on the opinion of human assessors with significant domain knowledge (Ph.D. in the life sciences). A legal span is a prescribed unit of retrieval that corresponds to a paragraph in the full-text article. The notion of a legal span evolved out of an attempt to standardize system output. Since systems varied in their processing of article text (in terms of segmentation, tokenization, etc.), a prescriptively-defined unit of retrieval made results easier to compare. In total, there are 12.6 million legal spans in the collection; a list of all legal spans was distributed alongside the full-text articles. In the context of this study, an article is considered relevant if it contains at least one relevant legal span.</p>
<p>As a final note, organizers of the TREC 2007 genomics track were unable to gather corresponding MEDLINE records for approximately 1% of the full-text articles in the Highwire collection. This was due to inconsistencies between the document identifiers used by Highwire Press and PMIDs in MEDLINE. According to my analysis, this resulted in the abstract index having 13 fewer relevant articles than the full-text index (out of a total of 2477) for the entire test set of 36 topics. To be consistent, the official relevance judgments were used in all experiments. However, I confirmed that the small number of missing abstracts had no significant impact on results.</p>
</sec>
<sec><title>Retrieval Models</title>
<p>Most modern text retrieval systems adopt a "bag of words" model, in which documents are treated as unordered collections of terms. Although such a model ignores the richness and complexity of natural language – disregarding syntax, semantics, and even word order – this simplification has proven to be effective in practice. In one standard formulation of the retrieval problem, a document <italic>d </italic>
is represented as a vector <italic>W</italic>
<sub><italic>d </italic>
</sub>
of term weights <italic>w</italic>
<sub><italic>t</italic>
, <italic>d</italic>
</sub>
, which reflect the importance of each term <italic>t </italic>
in the document. A document vector has dimensions |<italic>V</italic>
|, the size of the vocabulary in the entire collection. As a matter of convenience, "document" generically refers to the unit of indexing (which may in actuality be an abstract, a paragraph, etc.) A query <italic>q </italic>
is represented in the same manner, and the score of a document with respect to the query is computed as follows:</p>
<p><disp-formula id="bmcM1"><label>(1)</label>
<mml:math id="M1" name="1471-2105-10-46-i1" overflow="scroll"><mml:semantics><mml:mrow><mml:mstyle displaystyle="true"><mml:munder><mml:mo>∑</mml:mo>
<mml:mrow><mml:mi>t</mml:mi>
<mml:mo>∈</mml:mo>
<mml:mi>q</mml:mi>
</mml:mrow>
</mml:munder>
<mml:mrow><mml:msub><mml:mi>w</mml:mi>
<mml:mrow><mml:mi>t</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>d</mml:mi>
</mml:mrow>
</mml:msub>
<mml:mo>⋅</mml:mo>
<mml:msub><mml:mi>w</mml:mi>
<mml:mrow><mml:mi>t</mml:mi>
<mml:mo>,</mml:mo>
<mml:mi>q</mml:mi>
</mml:mrow>
</mml:msub>
</mml:mrow>
</mml:mstyle>
</mml:mrow>
</mml:semantics>
</mml:math>
</disp-formula>
</p>
<p>This inner-product formulation is sufficiently general to capture a wide range of retrieval models. Note that since queries are often very short, <italic>w</italic>
<sub><italic>t</italic>
, <italic>q </italic>
</sub>
is generally less important than <italic>w</italic>
<sub><italic>t</italic>
, <italic>d</italic>
</sub>
.</p>
<p>Given a query, a text retrieval system returns a list of documents with respect to a particular retrieval model. In the inner-product formulation, ranking algorithms vary in how term weights are computed. This work explores two different ranking algorithms: the algorithm implemented in the open-source Lucene search engine and Okapi <italic>bm25</italic>
.</p>
<p>Lucene is best described as a modified <italic>tf.idf </italic>
ranking algorithm. Given a query <italic>q</italic>
, the score of a document is computed as the sum of contributions from individual query terms:</p>
<p><disp-formula><mml:math id="M2" name="1471-2105-10-46-i2" overflow="scroll"><mml:semantics><mml:mrow><mml:mi>c</mml:mi>
<mml:mstyle displaystyle="true"><mml:munder><mml:mo>∑</mml:mo>
<mml:mrow><mml:mi>t</mml:mi>
<mml:mo>∈</mml:mo>
<mml:mi>q</mml:mi>
</mml:mrow>
</mml:munder>
<mml:mrow><mml:msqrt><mml:mrow><mml:mi>t</mml:mi>
<mml:mi>f</mml:mi>
</mml:mrow>
</mml:msqrt>
</mml:mrow>
</mml:mstyle>
<mml:msup><mml:mrow><mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mn>1</mml:mn>
<mml:mo>+</mml:mo>
<mml:mi>l</mml:mi>
<mml:mi>o</mml:mi>
<mml:mi>g</mml:mi>
<mml:mfrac><mml:mi>N</mml:mi>
<mml:mrow><mml:mi>n</mml:mi>
<mml:mo>+</mml:mo>
<mml:mn>1</mml:mn>
</mml:mrow>
</mml:mfrac>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
<mml:mn>2</mml:mn>
</mml:msup>
<mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mfrac><mml:mn>1</mml:mn>
<mml:mrow><mml:msqrt><mml:mrow><mml:mi>d</mml:mi>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:msqrt>
</mml:mrow>
</mml:mfrac>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:semantics>
</mml:math>
</disp-formula>
</p>
<p>For each term <italic>t </italic>
that appears in the query <italic>q</italic>
, <italic>tf </italic>
is the term frequency in the document, <italic>N </italic>
is the number of documents in the collection, <italic>n </italic>
is the number of documents containing <italic>t </italic>
(its document frequency), and <italic>dl </italic>
is the document length. The first term inside the summation is the <italic>tf </italic>
component, the second is the <italic>idf </italic>
component, and the third is a length normalization component. On top of a standard inner-product formulation, Lucene introduces <italic>c</italic>
, a "coordination factor", defined as the fraction of query terms found in the document. This factor rewards documents that have many matching terms.</p>
<p>Okapi <italic>bm25 </italic>
[<xref ref-type="bibr" rid="B35">35</xref>
,<xref ref-type="bibr" rid="B36">36</xref>
] models documents as a mixture of two Poisson processes. One process generates so-called <italic>elite </italic>
terms, corresponding to those that an author uses in writing about the topic of a particular document. The other process generates <italic>non-elite </italic>
terms, corresponding to those that the author uses in passing (i.e., words whose appearance is incidental to the topic of the document). Due to the complexity of parameter estimation for the full two-Poisson formulation, <italic>bm25 </italic>
uses an empirically-derived approximation [<xref ref-type="bibr" rid="B44">44</xref>
]. Given a query <italic>q</italic>
, <italic>bm25 </italic>
computes the score of a document as the sum of contributions from individual query terms:</p>
<p><disp-formula><mml:math id="M3" name="1471-2105-10-46-i3" overflow="scroll"><mml:semantics><mml:mrow><mml:mstyle displaystyle="true"><mml:munder><mml:mo>∑</mml:mo>
<mml:mrow><mml:mi>t</mml:mi>
<mml:mo>∈</mml:mo>
<mml:mi>q</mml:mi>
</mml:mrow>
</mml:munder>
<mml:mrow><mml:mi>log</mml:mi>
<mml:mo></mml:mo>
</mml:mrow>
</mml:mstyle>
<mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mfrac><mml:mrow><mml:mi>N</mml:mi>
<mml:mo>−</mml:mo>
<mml:mi>n</mml:mi>
<mml:mo>+</mml:mo>
<mml:mn>0.5</mml:mn>
</mml:mrow>
<mml:mrow><mml:mi>n</mml:mi>
<mml:mo>+</mml:mo>
<mml:mn>0.5</mml:mn>
</mml:mrow>
</mml:mfrac>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
<mml:mfrac><mml:mrow><mml:mo stretchy="false">(</mml:mo>
<mml:msub><mml:mi>k</mml:mi>
<mml:mn>1</mml:mn>
</mml:msub>
<mml:mo>+</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo stretchy="false">)</mml:mo>
<mml:mi>t</mml:mi>
<mml:mi>f</mml:mi>
</mml:mrow>
<mml:mrow><mml:mi>K</mml:mi>
<mml:mo>+</mml:mo>
<mml:mi>t</mml:mi>
<mml:mi>f</mml:mi>
</mml:mrow>
</mml:mfrac>
<mml:mfrac><mml:mrow><mml:mo stretchy="false">(</mml:mo>
<mml:msub><mml:mi>k</mml:mi>
<mml:mn>3</mml:mn>
</mml:msub>
<mml:mo>+</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo stretchy="false">)</mml:mo>
<mml:mi>q</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>f</mml:mi>
</mml:mrow>
<mml:mrow><mml:msub><mml:mi>k</mml:mi>
<mml:mn>3</mml:mn>
</mml:msub>
<mml:mo>+</mml:mo>
<mml:mi>q</mml:mi>
<mml:mi>t</mml:mi>
<mml:mi>f</mml:mi>
</mml:mrow>
</mml:mfrac>
</mml:mrow>
</mml:semantics>
</mml:math>
</disp-formula>
</p>
<p>For each term <italic>t</italic>
, <italic>tf </italic>
and <italic>qtf </italic>
are term frequencies in the document and query, respectively; <italic>N </italic>
is the number of documents in the collection; and <italic>n </italic>
is the number of documents containing the term. <italic>K</italic>
, a length normalization factor, is defined as follows:</p>
<p><disp-formula><mml:math id="M4" name="1471-2105-10-46-i4" overflow="scroll"><mml:semantics><mml:mrow><mml:mi>K</mml:mi>
<mml:mo>=</mml:mo>
<mml:msub><mml:mi>k</mml:mi>
<mml:mn>1</mml:mn>
</mml:msub>
<mml:mrow><mml:mo>(</mml:mo>
<mml:mrow><mml:mo stretchy="false">(</mml:mo>
<mml:mn>1</mml:mn>
<mml:mo>−</mml:mo>
<mml:mi>b</mml:mi>
<mml:mo stretchy="false">)</mml:mo>
<mml:mo>−</mml:mo>
<mml:mi>b</mml:mi>
<mml:mfrac><mml:mrow><mml:mi>d</mml:mi>
<mml:mi>l</mml:mi>
</mml:mrow>
<mml:mrow><mml:mi>a</mml:mi>
<mml:mi>v</mml:mi>
<mml:mi>d</mml:mi>
<mml:mi>l</mml:mi>
</mml:mrow>
</mml:mfrac>
</mml:mrow>
<mml:mo>)</mml:mo>
</mml:mrow>
</mml:mrow>
</mml:semantics>
</mml:math>
</disp-formula>
</p>
<p>where <italic>dl </italic>
is the document length and <italic>avdl </italic>
is the average length of all documents. The constants <italic>k</italic>
<sub>1</sub>
, <italic>b</italic>
, and <italic>k</italic>
<sub>3 </sub>
are tunable parameters. In my experiments, I used <italic>k</italic>
<sub>1 </sub>
= 1.2, <italic>b </italic>
= 0.75, and <italic>k</italic>
<sub>3 </sub>
= 1000, which are typical settings recommended in the literature.</p>
</sec>
<sec><title>Ivory: A Toolkit for Distributed Text Retrieval</title>
<p>Ivory is a toolkit for distributed text retrieval being developed at the University of Maryland to explore scalable algorithms [<xref ref-type="bibr" rid="B45">45</xref>
]. The software was created using Hadoop, which is an open-source Java implementation of the MapReduce programming model [<xref ref-type="bibr" rid="B4">4</xref>
] originally developed by Google. Ivory supports the large class of retrieval models that can be expressed as an inner product of term weights (see Section 5.2), and currently implements both <italic>bm25 </italic>
and the Lucene ranking algorithm (with a special extension to handle the coordination factor).</p>
<p>Certainly, distributed retrieval systems are not new – Web search engines have been in existence for over a decade. However, the exact architectures of these systems are guarded as commercial secrets. Even though outsiders are occasionally offered glimpses into their design [<xref ref-type="bibr" rid="B46">46</xref>
,<xref ref-type="bibr" rid="B47">47</xref>
], few details are available about important engineering tradeoffs. On the other hand, most open-source search engines were not specifically designed for multiple machines (or require tedious manual configuration to run on clusters). Although existing tools can easily support text retrieval experiments involving the Highwire collection (and indeed even much larger collections), the growth of available content will inevitably require transition to cluster-based environments. Ivory represents an initial attempt to develop a toolkit for distributed text retrieval using Hadoop; upon suitable maturity, it will be released as open-source software.</p>
<p>MapReduce is an attractive framework for concurrent programming because it frees the software developer from having to explicitly worry about system-level issues such as fault tolerance, synchronization, inter-process communication, scheduling, etc. The abstraction simplifies the design of scalable, distributed algorithms. With the release of Hadoop, an open-source implementation of the MapReduce programming model led by Yahoo, this versatile framework is available to anyone.</p>
<p>MapReduce draws inspiration from higher-order functions in functional programming and builds on the observation that many information processing tasks have the same basic structure: a computation is applied over a large number of records (e.g., Web pages, nodes in a graph) to generate partial results, which are then aggregated in some fashion. In MapReduce, the programmer defines a "mapper" and a "reducer" with the following signatures:</p>
<p><disp-formula>map: (<italic>k</italic>
<sub>1</sub>
, <italic>v</italic>
<sub>1</sub>
) → [(<italic>k</italic>
<sub>2</sub>
, <italic>v</italic>
<sub>2</sub>
)]</disp-formula>
</p>
<p><disp-formula>reduce: (<italic>k</italic>
<sub>2</sub>
, [<italic>v</italic>
<sub>2</sub>
]) → [(<italic>k</italic>
<sub>3</sub>
, <italic>v</italic>
<sub>3</sub>
)]</disp-formula>
</p>
<p>Key-value pairs form the basic data structure in MapReduce. The mapper is applied to every input key-value pair to generate an arbitrary number of intermediate key-value pairs (I adopt the convention of [...] to denote a list). The reducer is applied to all values associated with the same intermediate key to generate output key-value pairs. This two-stage processing structure is illustrated in Figure <xref ref-type="fig" rid="F1">1</xref>
.</p>
<fig position="float" id="F1"><label>Figure 1</label>
<caption><p><bold>Illustration of the MapReduce framework: the "mapper" is applied to all input records, which generates results that are aggregated by the "reducer"</bold>
. The runtime groups together values by keys.</p>
</caption>
<graphic xlink:href="1471-2105-10-46-1"></graphic>
</fig>
<p>In MapReduce, a programmer need only provide implementations of the mapper and reducer. On top of a distributed file system [<xref ref-type="bibr" rid="B48">48</xref>
], the runtime transparently handles all other aspects of execution, on clusters ranging from a few to a few thousand nodes. The runtime is responsible for scheduling map and reduce workers, detecting and handling faults, delivering input data, shuffling intermediate results, and gathering final output. The MapReduce abstraction allows many complex algorithms to be expressed concisely.</p>
<p>The pseudo-code for Ivory's indexing algorithm is shown in Figure <xref ref-type="fig" rid="F2">2</xref>
. Like nearly all text retrieval systems, Ivory builds a data structure called an inverted index, which given a term provides access to the list of documents that contain the term. An inverted index consists of postings lists, one associated with each term in the collection. A postings list is comprised of individual postings, each of which represents a (document id, term frequency) pair. This information is used to compute term weights during retrieval.</p>
<fig position="float" id="F2"><label>Figure 2</label>
<caption><p><bold>Pseudo-code of Ivory's indexing algorithm in MapReduce</bold>
. The mapper processes each document and emits postings with the associated term as the key. The reducer gathers all postings for each term to create the inverted index.</p>
</caption>
<graphic xlink:href="1471-2105-10-46-2"></graphic>
</fig>
<p>Input to the indexer consists of document ids (keys) and associated document content (values). In each mapper, the document text is tokenized and stemmed term occurrences are first stored in a histogram <italic>H </italic>
(implemented as an associative array). After this histogram has been built, the mapper then iterates over all terms. For each term, a pair consisting of the document id (<italic>k</italic>
) and the frequency of the term in the document (<italic>f</italic>
) is created. Each pair, denoted by ⟨<italic>k</italic>
, <italic>f</italic>
⟩ in the pseudo-code, represents an individual posting.</p>
<p>The mapper then emits an intermediate key-value pair with the term as the key and the posting as the value. MapReduce guarantees that all values associated with the same key will be sent to the same reducer; the reducer gathers up all postings, sorts them by descending term frequency, and emits the complete postings list, which is then written out to the distributed file system. The final key-value pairs (terms and associated postings lists) make up the inverted index.</p>
<p>Typically, computing term weights requires information about document lengths. This is straightforwardly expressed as another MapReduce algorithm: each mapper counts up the number of terms in a document and emits the term count as a value with the associated document id as the key. In this case, there is no need for a reducer – document lengths are directly written to disk. The table of document lengths is relatively compact, and is read into memory by each mapper in the retrieval phase.</p>
<p>Retrieval with an inverted index involves fetching postings lists that correspond to query terms, and then scoring documents based on term weights computed from postings information. For real-time applications, this requires low-latency access to the inverted index. However, Hadoop was primarily designed for high-throughput batch computations, not computations for which low latency is desired. Presently, Hadoop does not provide a mechanism for low-latency random access to the distributed file system. To work around this limitation, Ivory's retrieval algorithm was designed for parallel query execution.</p>
<p>The pseudo-code for Ivory's retrieval algorithm is shown in Figure <xref ref-type="fig" rid="F3">3</xref>
. The input to each mapper is a term <italic>t </italic>
(the key) and its associated postings list <italic>P </italic>
(the value). The mapper loads up <italic>all </italic>
the queries at once and processes each query in turn. If the query does not contain <italic>t</italic>
, no action is performed. If the query contains <italic>t</italic>
, then the corresponding postings must be traversed to compute the partial contributions to the query-document score. For each posting element, the partial contribution to the score (<italic>w</italic>
<sub><italic>t</italic>
, <italic>q</italic>
</sub>
·<italic>w</italic>
<sub><italic>t</italic>
, <italic>d</italic>
</sub>
) is computed based on the actual ranking algorithm. For example, <italic>bm25 </italic>
requires the document frequency of <italic>t </italic>
(known by the length of the postings list), term frequency of <italic>t </italic>
in the document (stored in the posting), query frequency (loaded by the mapper), document length (stored separately and loaded by the mapper; see above), and average document length (same). With all the necessary components, computing the partial score contribution is simply a matter of arithmetic. Each partial score is stored in an associative array <italic>H</italic>
, indexed by the document id <italic>k </italic>
– this structure serves the same functionality as accumulators in a traditional retrieval engine. The mapper emits an intermediate key-value pair with the query number <italic>i </italic>
as the key and <italic>H </italic>
as the value. The result of each mapper is all partial query-document scores associated with term <italic>t </italic>
for all queries that contain the term.</p>
<fig position="float" id="F3"><label>Figure 3</label>
<caption><p><bold>Pseudo-code of Ivory's retrieval algorithm in MapReduce</bold>
. The mapper processes the postings lists in parallel. For each query term, the mapper initializes accumulators to hold partial score contributions from all documents containing the term. The reducer adds up partial scores to produce the final results.</p>
</caption>
<graphic xlink:href="1471-2105-10-46-3"></graphic>
</fig>
<p>In the reduce phase, all associative arrays belonging to the same query are brought together by the runtime. The reducer performs an element-wise sum of all the associative arrays (denoted by the M<sc>ERGE</sc>
function in the pseudo-code): this adds up the contributions for each query term across all documents. The final result is an associative array containing scores for all documents that have at least one query term. This structure is then sorted (outside MapReduce by a separate process) to generate the final ranked list for fixed cutoff.</p>
<p>Note that this retrieval algorithm replaces random access of the postings with a parallel scan of all postings – this modification was necessary due to limitations of Hadoop. However, since disk scans are distributed across the entire cluster, it is possible to exploit the aggregate disk bandwidth of all available machines. In processing a set of queries, each postings list is accessed only once – each mapper computes partial score contributions for <italic>all </italic>
queries that contain the query term. It should be emphasized that this algorithm is not meant for real-time retrieval applications, but rather is intended for running batch-style experiments in a research context.</p>
</sec>
</sec>
</body>
<back><ack><sec><title>Acknowledgements</title>
<p>This work was supported by the Intramural Research Program of the NIH, National Library of Medicine; NSF under awards IIS-0705832 and IIS-0836560; DARPA/IPTO Contract No. HR0011-06-2-0001 under the GALE program. Any opinions, findings, conclusions, or recommendations expressed in this article are the author's and do not necessarily reflect those of the sponsors. I would like to thank Yahoo! for leading the development of Hadoop and Amazon for EC2/S3 support. This article benefited from the comments of two anonymous reviewers. Finally, I am grateful to Esther and Kiri for their kind support.</p>
</sec>
</ack>
<ref-list><ref id="B1"><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Hunter</surname>
<given-names>L</given-names>
</name>
<name><surname>Cohen</surname>
<given-names>KB</given-names>
</name>
</person-group>
<article-title>Biomedical Language Processing: What's Beyond PubMed?</article-title>
<source>Mol Cell</source>
<year>2006</year>
<volume>21</volume>
<fpage>589</fpage>
<lpage>594</lpage>
<pub-id pub-id-type="pmid">16507357</pub-id>
</citation>
</ref>
<ref id="B2"><citation citation-type="book"><person-group person-group-type="author"><name><surname>Zweigenbaum</surname>
<given-names>P</given-names>
</name>
<name><surname>Demner-Fushman</surname>
<given-names>D</given-names>
</name>
<name><surname>Yu</surname>
<given-names>H</given-names>
</name>
<name><surname>Cohen</surname>
<given-names>KB</given-names>
</name>
</person-group>
<article-title>New Frontiers In Biomedical Text Mining</article-title>
<source>Pacific Symposium on Biocomputing 12</source>
<year>2007</year>
<publisher-name>Wailea, Maui, Hawaii</publisher-name>
<fpage>205</fpage>
<lpage>208</lpage>
</citation>
</ref>
<ref id="B3"><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Zweigenbaum</surname>
<given-names>P</given-names>
</name>
<name><surname>Demner-Fushman</surname>
<given-names>D</given-names>
</name>
<name><surname>Yu</surname>
<given-names>H</given-names>
</name>
<name><surname>Cohen</surname>
<given-names>KB</given-names>
</name>
</person-group>
<article-title>Frontiers of Biomedical Text Mining: Current Progress</article-title>
<source>Brief Bioinform</source>
<year>2007</year>
<volume>8</volume>
<fpage>358</fpage>
<lpage>375</lpage>
<pub-id pub-id-type="pmid">17977867</pub-id>
</citation>
</ref>
<ref id="B4"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Dean</surname>
<given-names>J</given-names>
</name>
<name><surname>Ghemawat</surname>
<given-names>S</given-names>
</name>
</person-group>
<article-title>MapReduce: Simplified Data Processing on Large Clusters</article-title>
<source>Proceedings of the 6th Symposium on Operating System Design and Implementation (OSDI 2004), San Francisco, California</source>
<year>2004</year>
<fpage>137</fpage>
<lpage>150</lpage>
</citation>
</ref>
<ref id="B5"><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Gay</surname>
<given-names>CW</given-names>
</name>
<name><surname>Kayaalp</surname>
<given-names>M</given-names>
</name>
<name><surname>Aronson</surname>
<given-names>AR</given-names>
</name>
</person-group>
<article-title>Semi-Automatic Indexing of Full Text Biomedical Articles</article-title>
<source>AMIA Annu Symp Proc</source>
<year>2005</year>
<fpage>271</fpage>
<lpage>275</lpage>
<pub-id pub-id-type="pmid">16779044</pub-id>
</citation>
</ref>
<ref id="B6"><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Yu</surname>
<given-names>H</given-names>
</name>
<name><surname>Hatzivassiloglou</surname>
<given-names>V</given-names>
</name>
<name><surname>Friedman</surname>
<given-names>C</given-names>
</name>
<name><surname>Rzhetsky</surname>
<given-names>A</given-names>
</name>
<name><surname>Wilbur</surname>
<given-names>WJ</given-names>
</name>
</person-group>
<article-title>Automatic Extraction of Gene and Protein Synonyms from MEDLINE and Journal Articles</article-title>
<source>Proc AMIA Symp</source>
<year>2002</year>
<fpage>919</fpage>
<lpage>923</lpage>
<pub-id pub-id-type="pmid">12463959</pub-id>
</citation>
</ref>
<ref id="B7"><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Seki</surname>
<given-names>K</given-names>
</name>
<name><surname>Mostafa</surname>
<given-names>J</given-names>
</name>
</person-group>
<article-title>Discovering Implicit Associations Between Genes and Hereditary Diseases</article-title>
<source>Pac Symp Biocomput</source>
<year>2007</year>
<fpage>316</fpage>
<lpage>327</lpage>
<pub-id pub-id-type="pmid">17990502</pub-id>
</citation>
</ref>
<ref id="B8"><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Demner-Fushman</surname>
<given-names>D</given-names>
</name>
<name><surname>Hauser</surname>
<given-names>S</given-names>
</name>
<name><surname>Thoma</surname>
<given-names>G</given-names>
</name>
</person-group>
<article-title>The Role of Title, Metadata and Abstract in Identifying Clinically Relevant Journal Articles</article-title>
<source>AMIA Annu Symp Proc</source>
<year>2005</year>
<fpage>191</fpage>
<lpage>195</lpage>
<pub-id pub-id-type="pmid">16779028</pub-id>
</citation>
</ref>
<ref id="B9"><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Yu</surname>
<given-names>H</given-names>
</name>
</person-group>
<article-title>Towards Answering Biological Questions with Experimental Evidence: Automatically Identifying Text that Summarize Image Content in Full-Text Articles</article-title>
<source>AMIA Annu Symp Proc</source>
<year>2006</year>
<fpage>834</fpage>
<lpage>838</lpage>
<pub-id pub-id-type="pmid">17238458</pub-id>
</citation>
</ref>
<ref id="B10"><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Yu</surname>
<given-names>H</given-names>
</name>
<name><surname>Lee</surname>
<given-names>M</given-names>
</name>
</person-group>
<article-title>Accessing Bioscience Images from Abstract Sentences</article-title>
<source>Bioinformatics</source>
<year>2006</year>
<volume>22</volume>
<fpage>e547</fpage>
<lpage>e556</lpage>
<pub-id pub-id-type="pmid">16873519</pub-id>
</citation>
</ref>
<ref id="B11"><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Shah</surname>
<given-names>PK</given-names>
</name>
<name><surname>Perez-Iratxeta</surname>
<given-names>C</given-names>
</name>
<name><surname>Bork</surname>
<given-names>P</given-names>
</name>
<name><surname>Andrade</surname>
<given-names>MA</given-names>
</name>
</person-group>
<article-title>Information Extraction from Full Text Scientific Articles: Where are the Keywords?</article-title>
<source>BMC Bioinformatics</source>
<year>2003</year>
<volume>4</volume>
<fpage>20</fpage>
<pub-id pub-id-type="pmid">12775220</pub-id>
</citation>
</ref>
<ref id="B12"><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Schuemie</surname>
<given-names>MJ</given-names>
</name>
<name><surname>Weeber</surname>
<given-names>M</given-names>
</name>
<name><surname>Schijvenaars</surname>
<given-names>BJA</given-names>
</name>
<name><surname>van Mulligen</surname>
<given-names>EM</given-names>
</name>
<name><surname>Eijk</surname>
<given-names>CC van der</given-names>
</name>
<name><surname>Jelier</surname>
<given-names>R</given-names>
</name>
<name><surname>Mons</surname>
<given-names>B</given-names>
</name>
<name><surname>Kors</surname>
<given-names>JA</given-names>
</name>
</person-group>
<article-title>Distribution of Information in Biomedical Abstracts and Full-Text Publications</article-title>
<source>Bioinformatics</source>
<year>2004</year>
<volume>20</volume>
<fpage>2597</fpage>
<lpage>2604</lpage>
<pub-id pub-id-type="pmid">15130936</pub-id>
</citation>
</ref>
<ref id="B13"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Wilbur</surname>
<given-names>WJ</given-names>
</name>
<name><surname>Smith</surname>
<given-names>L</given-names>
</name>
<name><surname>Tanabe</surname>
<given-names>L</given-names>
</name>
</person-group>
<article-title>BioCreative 2. Gene Mention Task</article-title>
<source>Proceedings of the Second BioCreative Challenge Evaluation Workshop, Madrid, Spain</source>
<year>2007</year>
<fpage>7</fpage>
<lpage>16</lpage>
</citation>
</ref>
<ref id="B14"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Krallinger</surname>
<given-names>M</given-names>
</name>
<name><surname>Leitner</surname>
<given-names>F</given-names>
</name>
<name><surname>Valencia</surname>
<given-names>A</given-names>
</name>
</person-group>
<article-title>Assessment of the Second BioCreative PPI Task: Automatic Extraction of Protein-Protein Interactions</article-title>
<source>Proceedings of the Second BioCreative Challenge Evaluation Workshop, Madrid, Spain</source>
<year>2007</year>
<fpage>41</fpage>
<lpage>54</lpage>
</citation>
</ref>
<ref id="B15"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Salton</surname>
<given-names>G</given-names>
</name>
<name><surname>Buckley</surname>
<given-names>C</given-names>
</name>
</person-group>
<article-title>Automatic Text Structuring and Retrieval – Experiments in Automatic Encyclopedia searching</article-title>
<source>Proceedings of the 14th Annual International ACM SIGIR Conference on Research and Development in Information Retrieval (SIGIR 1991), Chicago, Illinois</source>
<year>1991</year>
<fpage>21</fpage>
<lpage>30</lpage>
</citation>
</ref>
<ref id="B16"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Salton</surname>
<given-names>G</given-names>
</name>
<name><surname>Allan</surname>
<given-names>J</given-names>
</name>
<name><surname>Buckley</surname>
<given-names>C</given-names>
</name>
</person-group>
<article-title>Approaches to Passage Retrieval in Full Text Information Systems</article-title>
<source>Proceedings of the 16th Annual International ACM SIGIR Conference on Research and Development in Information Retrieval (SIGIR 1993), Pittsburgh, Pennsylvania</source>
<year>1993</year>
<fpage>49</fpage>
<lpage>58</lpage>
</citation>
</ref>
<ref id="B17"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Hearst</surname>
<given-names>MA</given-names>
</name>
<name><surname>Plaunt</surname>
<given-names>C</given-names>
</name>
</person-group>
<article-title>Subtopic Structuring for Full-Length Document Access</article-title>
<source>Proceedings of the 16th Annual International ACM SIGIR Conference on Research and Development in Information Retrieval (SIGIR 1993), Pittsburgh, Pennsylvania</source>
<year>1993</year>
<fpage>56</fpage>
<lpage>68</lpage>
</citation>
</ref>
<ref id="B18"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Callan</surname>
<given-names>JP</given-names>
</name>
</person-group>
<article-title>Passage-Level Evidence in Document Retrieval</article-title>
<source>Proceedings of the 17th Annual International ACM SIGIR Conference on Research and Development in Information Retrieval (SIGIR 1994), Dublin, Ireland</source>
<year>1994</year>
<fpage>302</fpage>
<lpage>310</lpage>
</citation>
</ref>
<ref id="B19"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Wilkinson</surname>
<given-names>R</given-names>
</name>
</person-group>
<article-title>Effective Retrieval of Structured Documents</article-title>
<source>Proceedings of the 17th Annual International ACM SIGIR Conference on Research and Development in Information Retrieval (SIGIR 1994), Dublin, Ireland</source>
<year>1994</year>
<fpage>311</fpage>
<lpage>317</lpage>
</citation>
</ref>
<ref id="B20"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Kaszkiel</surname>
<given-names>M</given-names>
</name>
<name><surname>Zobel</surname>
<given-names>J</given-names>
</name>
</person-group>
<article-title>Passage Retrieval Revisited</article-title>
<source>Proceedings of the 20th Annual International ACM SIGIR Conference on Research and Development in Information Retrieval (SIGIR 1997), Philadelphia, Pennsylvania</source>
<year>1997</year>
<fpage>178</fpage>
<lpage>185</lpage>
</citation>
</ref>
<ref id="B21"><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Clarke</surname>
<given-names>C</given-names>
</name>
<name><surname>Cormack</surname>
<given-names>G</given-names>
</name>
<name><surname>Tudhope</surname>
<given-names>E</given-names>
</name>
</person-group>
<article-title>Relevance Ranking for One to Three Term Queries</article-title>
<source>Information Processing and Management</source>
<year>2000</year>
<volume>36</volume>
<fpage>291</fpage>
<lpage>311</lpage>
</citation>
</ref>
<ref id="B22"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Liu</surname>
<given-names>X</given-names>
</name>
<name><surname>Croft</surname>
<given-names>WB</given-names>
</name>
</person-group>
<article-title>Passage Retrieval Based on Language Models</article-title>
<source>Proceedings of the Eleventh International Conference on Information and Knowledge Management (CIKM 2002), McLean, Virginia</source>
<year>2002</year>
<fpage>375</fpage>
<lpage>382</lpage>
</citation>
</ref>
<ref id="B23"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Tellex</surname>
<given-names>S</given-names>
</name>
<name><surname>Katz</surname>
<given-names>B</given-names>
</name>
<name><surname>Lin</surname>
<given-names>J</given-names>
</name>
<name><surname>Marton</surname>
<given-names>G</given-names>
</name>
<name><surname>Fernandes</surname>
<given-names>A</given-names>
</name>
</person-group>
<article-title>Quantitative Evaluation of Passage Retrieval Algorithms for Question Answering</article-title>
<source>Proceedings of the 26th Annual International ACM SIGIR Conference on Research and Development in Information Retrieval (SIGIR 2003), Toronto, Canada</source>
<year>2003</year>
<fpage>41</fpage>
<lpage>47</lpage>
</citation>
</ref>
<ref id="B24"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Wang</surname>
<given-names>M</given-names>
</name>
<name><surname>Si</surname>
<given-names>L</given-names>
</name>
</person-group>
<article-title>Discriminative Probabilistic Models for Passage Based Retrieval</article-title>
<source>In Proceedings of the 31st Annual International ACM SIGIR Conference on Research and Development in Information Retrieval (SIGIR 2008), Singapore</source>
<year>2008</year>
<fpage>419</fpage>
<lpage>426</lpage>
</citation>
</ref>
<ref id="B25"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Lalmas</surname>
<given-names>M</given-names>
</name>
<name><surname>Tombros</surname>
<given-names>A</given-names>
</name>
</person-group>
<article-title>INEX 2002–2006: Understanding XML Retrieval Evaluation</article-title>
<source>Digital Libraries: Research and Development – First International DELOS Conference, Revised Selected Papers, Pisa, Italy</source>
<year>2007</year>
<fpage>187</fpage>
<lpage>196</lpage>
</citation>
</ref>
<ref id="B26"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Hersh</surname>
<given-names>WR</given-names>
</name>
<name><surname>Cohen</surname>
<given-names>A</given-names>
</name>
<name><surname>Ruslen</surname>
<given-names>L</given-names>
</name>
<name><surname>Roberts</surname>
<given-names>P</given-names>
</name>
</person-group>
<article-title>TREC 2007 Genomics Track Overview</article-title>
<source>Proceedings of the Sixteenth Text REtrieval Conference (TREC 2007), Gaithersburg, Maryland</source>
<year>2007</year>
</citation>
</ref>
<ref id="B27"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Trotman</surname>
<given-names>A</given-names>
</name>
</person-group>
<article-title>Wanted: Element Retrieval Users</article-title>
<source>Proceedings of the INEX 2005 Workshop on Element Retrieval Methodology, Glasgow, Scotland</source>
<year>2005</year>
<fpage>63</fpage>
<lpage>69</lpage>
</citation>
</ref>
<ref id="B28"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Larsen</surname>
<given-names>B</given-names>
</name>
<name><surname>Tombros</surname>
<given-names>A</given-names>
</name>
<name><surname>Malik</surname>
<given-names>S</given-names>
</name>
</person-group>
<article-title>Is XML Retrieval Meaningful to Users? Searcher Preferences for Full Documents vs. Elements</article-title>
<source>Proceedings of the 29th Annual International ACM SIGIR Conference on Research and Development in Information Retrieval (SIGIR 2006), Seattle, Washington</source>
<year>2006</year>
<fpage>663</fpage>
<lpage>664</lpage>
</citation>
</ref>
<ref id="B29"><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Salton</surname>
<given-names>G</given-names>
</name>
<name><surname>Wong</surname>
<given-names>Y</given-names>
</name>
<name><surname>Yang</surname>
<given-names>CS</given-names>
</name>
</person-group>
<article-title>A Vector Space Model for Automatic Indexing</article-title>
<source>Communications of the ACM</source>
<year>1975</year>
<volume>18</volume>
<fpage>613</fpage>
<lpage>620</lpage>
</citation>
</ref>
<ref id="B30"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Ponte</surname>
<given-names>JM</given-names>
</name>
<name><surname>Croft</surname>
<given-names>WB</given-names>
</name>
</person-group>
<article-title>A Language Modeling Approach to Information Retrieval</article-title>
<source>Proceedings of the 21st Annual International ACM SIGIR Conference on Research and Development in Information Retrieval (SIGIR 1998), Melbourne, Australia</source>
<year>1998</year>
<fpage>275</fpage>
<lpage>281</lpage>
</citation>
</ref>
<ref id="B31"><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Metzler</surname>
<given-names>D</given-names>
</name>
<name><surname>Croft</surname>
<given-names>WB</given-names>
</name>
</person-group>
<article-title>Combining the Language Model and Inference Network Approaches to Retrieval</article-title>
<source>Information Processing and Management</source>
<year>2004</year>
<volume>40</volume>
<fpage>735</fpage>
<lpage>750</lpage>
</citation>
</ref>
<ref id="B32"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Rafkind</surname>
<given-names>B</given-names>
</name>
<name><surname>Lee</surname>
<given-names>M</given-names>
</name>
<name><surname>Chang</surname>
<given-names>SF</given-names>
</name>
<name><surname>Yu</surname>
<given-names>H</given-names>
</name>
</person-group>
<article-title>Exploring Text and Image Features to Classify Images in Bioscience Literature</article-title>
<source>Proceedings of the HLT/NAACL 2006 Workshop on Biomedical Natural Language Processing (BioNLP'06), New York, New York</source>
<year>2006</year>
<fpage>73</fpage>
<lpage>80</lpage>
</citation>
</ref>
<ref id="B33"><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Shatkay</surname>
<given-names>H</given-names>
</name>
<name><surname>Chen</surname>
<given-names>N</given-names>
</name>
<name><surname>Blostein</surname>
<given-names>D</given-names>
</name>
</person-group>
<article-title>Integrating Image Data into Biomedical Text Categorization</article-title>
<source>Bioinformatics</source>
<year>2006</year>
<volume>22</volume>
<fpage>e446</fpage>
<lpage>e453</lpage>
<pub-id pub-id-type="pmid">16873506</pub-id>
</citation>
</ref>
<ref id="B34"><citation citation-type="book"><person-group person-group-type="author"><name><surname>Kou</surname>
<given-names>Z</given-names>
</name>
<name><surname>Cohen</surname>
<given-names>WW</given-names>
</name>
<name><surname>Murphy</surname>
<given-names>RF</given-names>
</name>
</person-group>
<article-title>A Stacked Graphical Model for Associating Sub-Images with Sub-Captions</article-title>
<source>Pacific Symposium on Biocomputing 12</source>
<year>2007</year>
<publisher-name>Wailea, Maui, Hawaii</publisher-name>
<fpage>257</fpage>
<lpage>268</lpage>
</citation>
</ref>
<ref id="B35"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Robertson</surname>
<given-names>SE</given-names>
</name>
<name><surname>Walker</surname>
<given-names>S</given-names>
</name>
<name><surname>Hancock-Beaulieu</surname>
<given-names>M</given-names>
</name>
<name><surname>Gatford</surname>
<given-names>M</given-names>
</name>
<name><surname>Payne</surname>
<given-names>A</given-names>
</name>
</person-group>
<article-title>Okapi at TREC-4</article-title>
<source>Proceedings of the Fourth Text REtrieval Conference (TREC-4), Gaithersburg, Maryland</source>
<year>1995</year>
<fpage>73</fpage>
<lpage>96</lpage>
</citation>
</ref>
<ref id="B36"><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Sparck Jones</surname>
<given-names>K</given-names>
</name>
<name><surname>Walker</surname>
<given-names>S</given-names>
</name>
<name><surname>Robertson</surname>
<given-names>SE</given-names>
</name>
</person-group>
<article-title>A Probabilistic Model of Information Retrieval: Development and Comparative Experiments (Parts 1 and 2)</article-title>
<source>Information Processing and Management</source>
<year>2000</year>
<volume>36</volume>
<fpage>779</fpage>
<lpage>840</lpage>
</citation>
</ref>
<ref id="B37"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Singhal</surname>
<given-names>A</given-names>
</name>
<name><surname>Buckley</surname>
<given-names>C</given-names>
</name>
<name><surname>Mitra</surname>
<given-names>M</given-names>
</name>
</person-group>
<article-title>Pivoted Document Length Normalization</article-title>
<source>Proceedings of the 19th Annual International ACM SIGIR Conference on Research and Development in Information Retrieval (SIGIR 1996), Zürich, Switzerland</source>
<year>1996</year>
<fpage>21</fpage>
<lpage>29</lpage>
</citation>
</ref>
<ref id="B38"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Kamps</surname>
<given-names>J</given-names>
</name>
<name><surname>de Rijke</surname>
<given-names>M</given-names>
</name>
<name><surname>Sigurbjörnsson</surname>
<given-names>B</given-names>
</name>
</person-group>
<article-title>Length Normalization in XML Retrieval</article-title>
<source>Proceedings of the 27th Annual International ACM SIGIR Conference on Research and Development in Information Retrieval (SIGIR 2004), Sheffield, United Kingdom</source>
<year>2004</year>
<fpage>80</fpage>
<lpage>87</lpage>
</citation>
</ref>
<ref id="B39"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Ogilvie</surname>
<given-names>P</given-names>
</name>
<name><surname>Callan</surname>
<given-names>J</given-names>
</name>
</person-group>
<article-title>Parameter Estimation for a Simple Hierarchical Generative Model for XML Retrieval</article-title>
<source>Proceedings of the 2005 Initiative for the Evaluation of XML Retrieval Workshop (INEX 2005), Dagstuhl, Germany</source>
<year>2005</year>
<fpage>211</fpage>
<lpage>224</lpage>
</citation>
</ref>
<ref id="B40"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Sigurbjörnsson</surname>
<given-names>B</given-names>
</name>
<name><surname>Kamps</surname>
<given-names>J</given-names>
</name>
<name><surname>de Rijke</surname>
<given-names>M</given-names>
</name>
</person-group>
<article-title>An Element-based Approach to XML Retrieval</article-title>
<source>Proceedings of the 2003 Initiative for the Evaluation of XML Retrieval Workshop (INEX 2005), Dagstuhl, Germany</source>
<year>2003</year>
<fpage>19</fpage>
<lpage>26</lpage>
</citation>
</ref>
<ref id="B41"><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Tbahriti</surname>
<given-names>I</given-names>
</name>
<name><surname>Chichester</surname>
<given-names>C</given-names>
</name>
<name><surname>Lisacek</surname>
<given-names>F</given-names>
</name>
<name><surname>Ruch</surname>
<given-names>P</given-names>
</name>
</person-group>
<article-title>Using Argumentation to Retrieve Articles with Similar Citations: An Inquiry into Improving Related Articles Search in the MEDLINE Digital Library</article-title>
<source>Int J Med Inform</source>
<year>2006</year>
<volume>75</volume>
<fpage>488</fpage>
<lpage>495</lpage>
<pub-id pub-id-type="pmid">16165395</pub-id>
</citation>
</ref>
<ref id="B42"><citation citation-type="book"><person-group person-group-type="author"><name><surname>Cleverdon</surname>
<given-names>CW</given-names>
</name>
<name><surname>Mills</surname>
<given-names>J</given-names>
</name>
<name><surname>Keen</surname>
<given-names>EM</given-names>
</name>
</person-group>
<source>Factors Determining the Performance of Indexing Systems</source>
<year>1968</year>
<volume>Two</volume>
<publisher-name>ASLIB Cranfield Research Project, Cranfield, England</publisher-name>
</citation>
</ref>
<ref id="B43"><citation citation-type="book"><person-group person-group-type="author"><name><surname>Harman</surname>
<given-names>DK</given-names>
</name>
</person-group>
<person-group person-group-type="editor"><name><surname>Voorhees EM, Harman DK</surname>
</name>
</person-group>
<article-title>The TREC Test Collections</article-title>
<source>TREC: Experiment and Evaluation in Information Retrieval</source>
<year>2005</year>
<publisher-name>Cambridge, Massachusetts: MIT Press</publisher-name>
<fpage>21</fpage>
<lpage>52</lpage>
</citation>
</ref>
<ref id="B44"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Robertson</surname>
<given-names>SE</given-names>
</name>
<name><surname>Walker</surname>
<given-names>S</given-names>
</name>
</person-group>
<article-title>Some Simple Effective Approximations to the 2-Poisson Model for Probabilistic Weighted Retrieval</article-title>
<source>Proceedings of the 17th Annual International ACM SIGIR Conference on Research and Development in Information Retrieval (SIGIR 1994), Dublin, Ireland</source>
<year>1994</year>
<fpage>232</fpage>
<lpage>241</lpage>
</citation>
</ref>
<ref id="B45"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Elsayed</surname>
<given-names>T</given-names>
</name>
<name><surname>Lin</surname>
<given-names>J</given-names>
</name>
<name><surname>Oard</surname>
<given-names>D</given-names>
</name>
</person-group>
<article-title>Pairwise Document Similarity in Large Collections with MapReduce</article-title>
<source>Proceedings of the 46th Annual Meeting of the Association for Computational Linguistics (ACL 2008), Companion Volume, Columbus, Ohio</source>
<year>2008</year>
<fpage>265</fpage>
<lpage>268</lpage>
</citation>
</ref>
<ref id="B46"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Brin</surname>
<given-names>S</given-names>
</name>
<name><surname>Page</surname>
<given-names>L</given-names>
</name>
</person-group>
<article-title>The Anatomy of a Large-Scale Hypertextual Web Search Engine</article-title>
<source>Proceedings of the Seventh International World Wide Web Conference (WWW 7), Brisbane, Australia</source>
<year>1998</year>
<fpage>107</fpage>
<lpage>117</lpage>
</citation>
</ref>
<ref id="B47"><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Barroso</surname>
<given-names>LA</given-names>
</name>
<name><surname>Dean</surname>
<given-names>J</given-names>
</name>
<name><surname>Hölzle</surname>
<given-names>U</given-names>
</name>
</person-group>
<article-title>Web Search for a Planet: The Google Cluster Architecture</article-title>
<source>IEEE Micro</source>
<year>2003</year>
<volume>23</volume>
<fpage>22</fpage>
<lpage>28</lpage>
</citation>
</ref>
<ref id="B48"><citation citation-type="other"><person-group person-group-type="author"><name><surname>Ghemawat</surname>
<given-names>S</given-names>
</name>
<name><surname>Gobioff</surname>
<given-names>H</given-names>
</name>
<name><surname>Leung</surname>
<given-names>ST</given-names>
</name>
</person-group>
<article-title>The Google File System</article-title>
<source>Proceedings of the 19th ACM Symposium on Operating Systems Principles (SOSP 2003), Bolton Landing, New York</source>
<year>2003</year>
<fpage>29</fpage>
<lpage>43</lpage>
</citation>
</ref>
</ref-list>
</back>
</pmc>
</record>
Pour manipuler ce document sous Unix (Dilib)
EXPLOR_STEP=$WICRI_ROOT/Wicri/Informatique/explor/SgmlV1/Data/Pmc/Corpus
HfdSelect -h $EXPLOR_STEP/biblio.hfd -nk 0001240 | SxmlIndent | more
Ou
HfdSelect -h $EXPLOR_AREA/Data/Pmc/Corpus/biblio.hfd -nk 0001240 | SxmlIndent | more
Pour mettre un lien sur cette page dans le réseau Wicri
{{Explor lien |wiki= Wicri/Informatique |area= SgmlV1 |flux= Pmc |étape= Corpus |type= RBID |clé= |texte= }}
![]() | This area was generated with Dilib version V0.6.33. | ![]() |