Documents and Other Elements

Most IR systems don't store term locations as raw numbers, as we have been doing in our schema independent set-up.
Instead, the collection is split into documents.
Within a document there might be tags, and so a document can be split into smaller units.
Using our absolute positioning, we could still find smaller units. For example, if we knew "first witch" appears as the interval [745406, 745407] and we knew prev("<SPEECH>", 745406) = 745404 and we knew next("</SPEECH>", 745407) = 745408, we could conclude that "first which" appeared in a SPEECH sub-document.
One can show using this set-up that our simple ADT approach would work for many XPath style queries.
At the whole document level, however, people usually do not use absolute offsets. Instead, they use a pair n:m. Here n is a docid of a document and m is a location within that document.

Document-oriented Indexes

Perhaps the most common way to split up a collection of text is into documents.
Because of this, typically people optimize their indices around the notion of document.
We use the notation m:n to mean offset n into the document with id m.
Using this notation, we modify our inverted index methods first, last, prev, next to output such pairs.
So for example, next("thunder", `22:288`) = `22:310` means that the next occurrence of the term "thunder" after the occurrence in the `22`nd document at location `288` is in the `22`nd document at location `310`.

Measuring Retrieval Effectiveness

Measuring the effectiveness of a retrieval method depends on human assessments of relevance.
TREC experiments often use binary relevance judgements by humans. i.e., someone says, document X is or is not relevant to the topic A.
A document is typically judged relevant if any part of it is relevant.
For example, for TREC topic 426, a user might formulate the Boolean query:
(("law" AND "enforcement") OR "police") AND ("dog" OR "dogs").
Using the TREC45, (disk 4 and disk 5 of a TREC dataset of newspaper articles), this query produces 881 documents of the 500,000 or so in the collection.

Recall and Precision

In order to determine the effectiveness of a Boolean Query, we compare (1) the set of documents returned by the query, Res, and (2) the set of relevant documents for the topic contained in the collection, Rel.
From these two sets we can compute two common standard measures of effectiveness, recall and precision.
`mbox(recall) = frac(|Rel cap Res|)(|Rel|)`
`mbox(precision) = frac(|Rel cap Res|)(|Res|)`
Recall indicates the fraction of relevant documents that appear in the result set, precision indicates the fraction of the result set that is relevant.
According to NIST there are `202` relevant documents for topic 426. The above Boolean query only returns `167` of these. So the precision is `0.190`, and the recall is `0.827`.

Document Statistics

When working with documents there are several common statistics which people typically keep track of:

`N_t` (document frequency): the number of documents in the collection containing the term `t`.
`f_(t,d)` (term frequency): the number of occurrences of the term `t` in the document `d`.
`l_d` (document length): the length of document `d` measured in tokens.
`l_(avg)` (average length): the average document length across the collection.
`N` (document count): the total number of documents in the collection.

Also, when working with document-oriented indexes it is common to support coarser grained methods in our ADT, such as firstDoc(`t`), lastDoc(`t`), nextDoc(`t`, `mbox(current)`), and prevDoc(`t`, `mbox(current)`). The idea of a method like nextDoc, is that it returns the first document with the term `t` after `current` in the corpus. i.e., we don't care about position in the document with this method.

Posting Lists and Index Types

When using a schema-dependent index, like a document index, it is common to modify the way we store posting lists for a term `t`.
Rather than have a sequence of offsets for that terms, instead we have postings of the form:
`langle d, f_(t,d), langle p_0, ... p_(f_(t,d)-1)rangle rangle` in which we group all occurrences of the term `t` in the same document together. For example a posting for "witch" might look like: `langle 1, 3, langle 1598, 27555, 31463 rangle rangle` which says witch occurs in document 1, 3 times and that it occurs at locations 1598, 27555, and 31463.
Often times, storing the exact positions of the terms is not necessary, and can take a lot of space.
Document-oriented indexes can actually be classified by what components of this basic posting 3-tuple we decide to store:
- A docid index stores for each term just the documents in which it appears.
- A frequency index stores for each term and for each document it appears in the pair `langle d, f_(t,d) rangle`
- A positional index stores for each term and for each document contain the term the full triple `langle d, f_(t,d), langle p_0, ... p_(f_(t,d))rangle rangle`.
- Finally, as we have already discussed, a schema-independent index does not store any of the document oriented optimizations of a positional index, but otherwise stores the same info.

Ranking and Retrieval

We now look at some ways we can use our document-oriented ADT for retrieval documents, and ordering the results returned according to relevance.
Queries for ranked retrieval are often called term vectors.
The components of this vector when entered into an IR system are typically delimited by white space.
So the query:
william shakespeare wedding
would be viewed as the vector `langle "william", "shakespeare", "wedding" rangle`.
Using vectors rather than sets is useful because some meaningful queries might involve repeated terms. For example, "to be or not to be", which if we ignore the duplicates might yield sub-standard results because it would not be so closely identified with Hamlet.
When we retrieve using term vectors we often are interested in documents whose own vector is somehow close to the query term vector.
Closeness might not mean the document has all of the terms that occur in the term vector.
Another way to build up queries is using the operations "AND", "OR", "NOT". For example,
"william" AND "shakespeare" AND NOT ("marlowe" OR "bacon")
For a document to be returned in the case of an AND both of its inputs must hold true for that document. Similarly, for OR, either or both of its input must be true, and NOT means its input does not hold. So for a document to be returned on the query "william" and "shakespeare", the document MUST contain both terms.
We call a query only using ANDs a conjunctive query and one only using ORs a disjunctive query.

The Vector Space Model

The vector space model is one of the earliest information retrieval models, going back to work by Salton (on SMART at Harvard/Cornell) in the 1960s.
In this model, both queries and documents are viewed as vectors.
These vectors have one component for each term that occurs in the vocabulary `V` of the collection. You can think of a component as storing a real number that somehow measures how important that term was to the query or to the document.
We call the vector corresponding to a query, a query vector and a vector corresponding to a document a document vector.
Unlike term vectors, query vectors don't allow for repeated terms, they are also of much higher dimensionality as they have components (often many of these will be zero) for each vocabulary term.

Cosine Similarity

Given two such `|V|`-dimensional vectors: `vec x, vec y`; say one for a query, one for a document; we can measure their closeness by taking their dot product.
Recall from linear algebra that the dot product is straightforward to compute using the formula:
`vec x cdot vec y = sum_(i=1)^(|V|)x_i cdot y_i`.
The dot product has the following geometric meaning:
`vec x cdot vec y = |vec x||vec y| cos theta`
where `theta` is the angle between `vec x, vec y`. `|vec v|` means the length of the vector `vec v`. It can be computed as
`|vec v| = sqrt(sum_(i=1)^(|V|)v_i^2)`.
Using these equations, we can solve for `theta` as:
`cos(theta) = frac(sum_(i-1)^(|V|)x_i cdot y_i)(sqrt(sum_(i=1)^(|V|)x_i^2)sqrt(sum_(i=1)^(|V|)y_i^2))`.
Notice when `theta = 0^circ`, `cos(theta) = 1`, and the two vectors are collinear and could be viewed as similar, and if `theta = 90^circ`, `cos(theta) = 0`, and the two vectors are orthogonal, or as far apart as possible.
We will only have positive components of our vectors so we won't get negative cosine values.
Thus, if given a query vector `vec q` and a document vector `vec d` it makes sense to define their similarity as the cosine of the angle between them. i.e., Define: `sim(vec d, vec q) = frac(vec d)(|vec d|)cdot frac(vec q)(|vec q|)`

Quiz

Which of the following is true?

Galloping/Exponential search makes use of binary search.
The binary search implementation of prev() is always faster than the sequential scan implementation of prev().
The PHP syntax $x = file("my.dat"); can be used to read the file my.dat into a single string $x.

TF-IDF

Using our vector space model, the dimensionality of the vectors in question might be in the millions -- there could be a lot of distinct words in our corpus. So at first blush it might seem for even a small corpus that computing this cosine similarity would be costly.
The important thing to note is that the actual runtime depends on only the number of non-zero entries in the vector with fewer non-zero entries (usually the query), and this is typically small.
We still have to figure out what real values to use for the components of our query and document vectors.
The most common way to do this is to use TF-IDF weights.
Here TF means Term Frequency and is some function which measures how common the term is in the given document, and IDF is inverse document frequency which is typically relates the document frequency to the total number of documents in the corpus.
Over the years, several different functions have been proposed for TF and for IDF. For this class, we will define `IDF = log(frac(N)(N_t))` and we will define `TF = log (f_(t,d)) + 1` if `f_(t,d) > 0` and `0` otherwise.
We use log's (base 2) for TF since this models the number of bits of information we are getting by knowing the exact frequency of the number of occurrences of the term in the document.
Notice if a term appears in close to every document, it doesn't tell you much to say the document has the term. The IDF in this case is small.
For example, if we have a collection of five documents and the word "sir" appears in four, then `IDF(sir) = log(5/4) = 0.32`. If in document 2 the term "sir" occurs twice, then its TF would be `log(f_(t,d)) + 1 = 2`. So the TF-IDF("doc 2","sir"), which is the product of these two values, would be 0.64.
This would represent the weight we would use for the "sir" component of doc 2's document vector. We could have one such component for each vocabulary term.

Algorithm to Compute Cosine Rank

rankCosine(t[1],...t[n], k) 
// t is an array of query terms
// k is the number of documents we want to return
{
    j := 1
    d := min_(1 <= i <= n) nextDoc(t[i], - infty)
    //we only need to consider docs containing at least one term
    while d < infty do
        Result[j].docid := d;
        Result[j].score := sim(vec d, vec t)
        j++;
        d := min_(1 <= i <= n, nextDoc(t[i], d))
    sort Result by score;
    return Result[1 .. k];
}

Index Types, VSM Ranking

Outline

Introduction