From 304884c660824409d88cdc91ddabaa875819f7fe Mon Sep 17 00:00:00 2001 From: Otis Gospodnetic Date: Fri, 25 May 2007 16:07:18 +0000 Subject: [PATCH] - LUCENE-891 doc patch git-svn-id: https://svn.apache.org/repos/asf/lucene/java/trunk@541702 13f79535-47bb-0310-9956-ffa450edef68 --- .../org/apache/lucene/search/package.html | 62 +++++++++---------- 1 file changed, 31 insertions(+), 31 deletions(-) diff --git a/src/java/org/apache/lucene/search/package.html b/src/java/org/apache/lucene/search/package.html index 709e4f26f54..68017b78eba 100644 --- a/src/java/org/apache/lucene/search/package.html +++ b/src/java/org/apache/lucene/search/package.html @@ -52,8 +52,8 @@ org.apache.lucene.search.Searcher#search(Query,Filter)}. TermQuery tq = new TermQuery(new Term("fieldName", "term")); In this example, the Query identifies all Documents that have the Field named "fieldName" and - contain the word "term". + href="../document/Field.html">Field named "fieldName" + containing the word "term".

BooleanQuery @@ -70,15 +70,15 @@ org.apache.lucene.search.Searcher#search(Query,Filter)}. describing how that sub-query is combined with the other clauses:
    -

  1. SHOULD -- Use this operator when a clause can occur in the result set, but is not required. +

  2. SHOULD — Use this operator when a clause can occur in the result set, but is not required. If a query is made up of all SHOULD clauses, then every document in the result set matches at least one of these clauses.

    3. -

  3. MUST -- Use this operator when a clause is required to occur in the result set. Every +

  4. MUST — Use this operator when a clause is required to occur in the result set. Every document in the result set will match all such clauses.

    5. -

  5. MUST NOT -- Use this operator when a +

  6. MUST NOT — Use this operator when a clause must not occur in the result set. No document in the result set will match any such clauses.

    7. @@ -100,18 +100,18 @@ org.apache.lucene.search.Searcher#search(Query,Filter)}.

    Phrases

    Another common search is to find documents containing certain phrases. This - is handled in two different ways. + is handled two different ways:

    1. PhraseQuery - -- Matches a sequence of + — Matches a sequence of Terms. PhraseQuery uses a slop factor to determine how many positions may occur between any two terms in the phrase and still be considered a match.

    2. SpanNearQuery - -- Matches a sequence of other + — Matches a sequence of other SpanQuery instances. SpanNearQuery allows for much more @@ -203,15 +203,15 @@ org.apache.lucene.search.Searcher#search(Query,Filter)}. href="http://www.nabble.com/Overriding-Similarity-tf2128934.html">Overriding Similarity. In summary, here are a few use cases:

        -

      1. SweetSpotSimilarity --

        SweetSpotSimilarity — SweetSpotSimilarity gives small increases as the frequency increases a small amount and then greater increases when you hit the "sweet spot", i.e. where you think the frequency of terms is more significant.

        2. -

      2. Overriding tf -- In some applications, it doesn't matter what the score of a document is as long as a +

      3. Overriding tf — In some applications, it doesn't matter what the score of a document is as long as a matching term occurs. In these cases people have overridden Similarity to return 1 from the tf() method.

        4. -

      4. Changing Length Normalization -- By overriding

        Changing Length Normalization — By overriding lengthNorm, it is possible to discount how the length of a field contributes to a score. In DefaultSimilarity, @@ -227,7 +227,7 @@ org.apache.lucene.search.Searcher#search(Query,Filter)}. Similarity method.

        -

        Changing Scoring -- Expert Level

        +

        Changing Scoring — Expert Level

        Changing scoring is an expert level task, so tread carefully and be prepared to share your code if you want help. @@ -238,16 +238,16 @@ org.apache.lucene.search.Searcher#search(Query,Filter)}. three main classes:

        1. - Query -- The abstract object representation of the + Query — The abstract object representation of the user's information need.
        2. - Weight -- The internal interface representation of + Weight — The internal interface representation of the user's Query, so that Query objects may be reused.
        3. - Scorer -- An abstract class containing common + Scorer — An abstract class containing common functionality for scoring. Provides both scoring and explanation capabilities.
        - Details on each of these classes, and their children can be found in the subsections below. + Details on each of these classes, and their children, can be found in the subsections below.

        The Query Class

        In some sense, the @@ -259,13 +259,13 @@ org.apache.lucene.search.Searcher#search(Query,Filter)}. Query class has several methods that are important for derived classes:

          -
        1. createWeight(Searcher searcher) -- A +
        2. createWeight(Searcher searcher) — A Weight is the internal representation of the Query, so each Query implementation must provide an implementation of Weight. See the subsection on The Weight Interface below for details on implementing the Weight interface.
          3. -
        3. rewrite(IndexReader reader) -- Rewrites queries into primitive queries. Primitive queries are: +
        4. rewrite(IndexReader reader) — Rewrites queries into primitive queries. Primitive queries are: TermQuery, BooleanQuery, OTHERS????
          5. @@ -277,26 +277,26 @@ org.apache.lucene.search.Searcher#search(Query,Filter)}. interface provides an internal representation of the Query so that it can be reused. Any Searcher dependent state should be stored in the Weight implementation, - not in the Query class. The interface defines 6 methods that must be implemented: + not in the Query class. The interface defines six methods that must be implemented:
          1. - Weight#getQuery() -- Pointer to the + Weight#getQuery() — Pointer to the Query that this Weight represents.
          2. - Weight#getValue() -- The weight for + Weight#getValue() — The weight for this Query. For example, the TermQuery.TermWeight value is equal to the idf^2 * boost * queryNorm
          3. - Weight#sumOfSquaredWeights() -- The sum of squared weights. Tor TermQuery, this is (idf * + Weight#sumOfSquaredWeights() — The sum of squared weights. For TermQuery, this is (idf * boost)^2
          4. - Weight#normalize(float) -- Determine the query normalization factor. The query normalization may + Weight#normalize(float) — Determine the query normalization factor. The query normalization may allow for comparing scores between queries.
          5. - Weight#scorer(IndexReader) -- Construct a new + Weight#scorer(IndexReader) — Construct a new Scorer for this Weight. See The Scorer Class @@ -305,7 +305,7 @@ org.apache.lucene.search.Searcher#search(Query,Filter)}.
          6. - Weight#explain(IndexReader, int) -- Provide a means for explaining why a given document was + Weight#explain(IndexReader, int) — Provide a means for explaining why a given document was scored the way it was.
          @@ -318,29 +318,29 @@ org.apache.lucene.search.Searcher#search(Query,Filter)}. must be implemented:
          1. - Scorer#next() -- Advances to the next + Scorer#next() — Advances to the next document that matches this Query, returning true if and only if there is another document that matches.
          2. - Scorer#doc() -- Returns the id of the + Scorer#doc() — Returns the id of the Document - that contains the match. Is not valid until next() has been called at least once. + that contains the match. It is not valid until next() has been called at least once.
          3. - Scorer#score() -- Return the score of the + Scorer#score() — Return the score of the current document. This value can be determined in any appropriate way for an application. For instance, the TermScorer returns the tf * Weight.getValue() * fieldNorm.
          4. - Scorer#skipTo(int) -- Skip ahead in + Scorer#skipTo(int) — Skip ahead in the document matches to the document whose id is greater than or equal to the passed in value. In many instances, skipTo can be implemented more efficiently than simply looping through all the matching documents until the target document is identified.
          5. - Scorer#explain(int) -- Provides + Scorer#explain(int) — Provides details on why the score came about.