Information retrieval systems are often contrasted with
relational databases. Traditionally, IR systems have retrieved information from
unstructured text - by which we mean ``raw'' text
without markup. Databases are designed for querying
relational data: sets of records that have values for
predefined attributes such as employee number, title and
salary. There are fundamental differences between
information retrieval and database systems in terms of
retrieval model, data structures and query language as shown
in Table 10.1 .![[*]](http://nlp.stanford.edu/IR-book/html/icons/footnote.png){kind=icon}
Some highly structured text search problems are most efficiently handled by a relational database, for example, if the employee table contains an attribute for short textual job descriptions and you want to find all employees who are involved with invoicing. In this case, the SQL query:
select lastname from employees where job_desc like 'invoic%';
may be sufficient to satisfy your information need with high
precision and recall.
However, many structured data sources containing text are best modeled as structured documents rather than relational data. We call the search over such structured documents structured retrieval . Queries in structured retrieval can be either structured or unstructured, but we will assume in this chapter that the collection consists only of structured documents. Applications of structured retrieval include digital libraries , patent databases , , text in which entities like persons and locations have been tagged (in a process called ) and output from office suites like OpenOffice that save documents as marked up text. In all of these applications, we want to be able to run queries that combine textual criteria with structural criteria. Examples of such queries are give me a full-length article on fast fourier transforms (digital libraries), give me patents whose claims mention RSA public key encryption and that cite US patent 4,405,829 (patents), or give me articles about sightseeing tours of the Vatican and the Coliseum (entity-tagged text). These three queries are structured queries that cannot be answered well by an unranked retrieval system. As we argued in westlaw unranked retrieval models like the Boolean model suffer from low recall. For instance, an unranked system would return a potentially large number of articles that mention the Vatican, the Coliseum and sightseeing tours without ranking the ones that are most relevant for the query first. Most users are also notoriously bad at precisely stating structural constraints. For instance, users may not know for which structured elements the search system supports search. In our example, the user may be unsure whether to issue the query as sightseeing AND (COUNTRY:Vatican OR LANDMARK:Coliseum) , as sightseeing AND (STATE:Vatican OR BUILDING:Coliseum) or in some other form. Users may also be completely unfamiliar with structured search and advanced search interfaces or unwilling to use them. In this chapter, we look at how ranked retrieval methods can be adapted to structured documents to address these problems.
We will only look at one standard for encoding structured documents: Extensible Markup Language or XML , which is currently the most widely used such standard. We will not cover the specifics that distinguish XML from other types of markup such as HTML and SGML. But most of what we say in this chapter is applicable to markup languages in general.
In the context of information retrieval, we are only interested in XML as a language for encoding text and documents. A perhaps more widespread use of XML is to encode non-text data. For example, we may want to export data in XML format from an enterprise resource planning system and then read them into an analytics program to produce graphs for a presentation. This type of application of XML is called data-centric because numerical and non-text attribute-value data dominate and text is usually a small fraction of the overall data. Most data-centric XML is stored in databases - in contrast to the inverted index-based methods for text-centric XML that we present in this chapter.
We call XML retrieval structured retrieval in this chapter. Some researchers prefer the term semistructured retrieval to distinguish XML retrieval from database querying. We have adopted the terminology that is widespread in the XML retrieval community. For instance, the standard way of referring to XML queries is structured queries , not semistructured queries . The term structured retrieval is rarely used for database querying and it always refers to XML retrieval in this book.
There is a second type of information retrieval problem that
is intermediate between unstructured retrieval and querying
a relational database: parametric and zone search, which
we discussed in Section 6.1 (page ![[*]](http://nlp.stanford.edu/IR-book/html/icons/crossref.png){kind=icon}
). In the data
model of parametric and zone search, there are
parametric fields (relational attributes
like date or file-size) and
zones - text attributes that
each take a chunk of unstructured text as value, e.g.,
author and title in
Figure 6.1 (page ).
The data model is
flat, that is, there is no nesting of attributes.
The number of attributes is small.
In
contrast, XML documents have the more complex tree structure
that we see in Figure 10.2 in which attributes are
nested. The number of attributes and nodes is greater than
in parametric and zone search.
After presenting the basic concepts of XML in Section 10.1 , this chapter first discusses the challenges we face in XML retrieval (Section 10.2 ). Next we describe a vector space model for XML retrieval (Section 10.3 ). Section 10.4 presents INEX, a shared task evaluation that has been held for a number of years and currently is the most important venue for XML retrieval research. We discuss the differences between data-centric and text-centric approaches to XML in Section 10.5 .