(solr) 01/03: Doc cleanup. Some typos, but also changing 'may not' to 'must not' for better clarity

[ho...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

hossman pushed a commit to branch jira/SOLR-16858
in repository https://gitbox.apache.org/repos/asf/solr.git

commit 7b0e5ebaa310211d4971dc4ab2f4b00ecffe1ab9
Author: Chris Hostetter <ho...@apache.org>
AuthorDate: Mon Feb 5 14:49:44 2024 -0700

    Doc cleanup. Some typos, but also changing 'may not' to 'must not' for better clarity
---
 .../modules/query-guide/pages/dense-vector-search.adoc       | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/solr/solr-ref-guide/modules/query-guide/pages/dense-vector-search.adoc b/solr/solr-ref-guide/modules/query-guide/pages/dense-vector-search.adoc
index 4380235ebfd..ac96ef827bf 100644
--- a/solr/solr-ref-guide/modules/query-guide/pages/dense-vector-search.adoc
+++ b/solr/solr-ref-guide/modules/query-guide/pages/dense-vector-search.adoc
@@ -240,7 +240,7 @@ client.add(Arrays.asList(d1, d2));
 This is the Apache Solr query approach designed to support dense vector search:
 
 === knn Query Parser
-The `knn` k-nearest neighbors query parser allows to find the k-nearest documents to the target vector according to indexed dense vectors in the given field.  The set of documents can be Pre-Riltered to reduce the number of vector distance calculations that must be computed, and ensure the best `topK` are returned.
+The `knn` k-nearest neighbors query parser allows to find the k-nearest documents to the target vector according to indexed dense vectors in the given field.  The set of documents can be Pre-Filtered to reduce the number of vector distance calculations that must be computed, and ensure the best `topK` are returned.
 
 The score for a retrieved document is the approximate distance to the target vector(defined by the similarityFunction configured at indexing time).
 
@@ -280,7 +280,7 @@ Specifies an explicit list of Pre-Filter query strings to use.
 |Optional |Default: none
 |===
 +
-Indicates that only `fq` filters with the specified `tag` should be considered for implicit Pre-Filtering.  May not be combind with `preFilter`.
+Indicates that only `fq` filters with the specified `tag` should be considered for implicit Pre-Filtering.  Must not be combined with `preFilter`.
 
 
 `excludeTags`::
@@ -290,7 +290,7 @@ Indicates that only `fq` filters with the specified `tag` should be considered f
 |Optional |Default: none
 |===
 +
-Indicates that `fq` filters with the specified `tag` should be excluded from consideration for implicit Pre-Filtering.  May not be combind with `preFilter`.
+Indicates that `fq` filters with the specified `tag` should be excluded from consideration for implicit Pre-Filtering.  Must not be combined with `preFilter`.
 
 
 Here's how to run a simple KNN search:
@@ -312,7 +312,7 @@ In the above example, only documents matching the Pre-Filter `inStock:true` will
 
 The `preFilter` parameter may be blank (ex: `preFilter=""`) to indicate that no Pre-Filtering should be performed; or it may be multi-valued -- either through repetition, or via duplicated xref:local-params.adoc#parameter-dereferencing[Parameter References].
 
-These two examples are equivilent:
+These two examples are equivalent:
 
 [source,text]
 ?q={!knn f=vector topK=10 preFilter=category:AAA preFilter=inStock:true}[1.0, 2.0, 3.0, 4.0]
@@ -332,7 +332,7 @@ While the `preFilter` parameter may be explicitly specified on *_any_* usage of
 ** This default behavior optimizes the number of vector distance calculations considered, eliminating documents that would eventually be excluded by an `fq` filter anyway.
 ** `includeTags` and `excludeTags` may be used to limit the set of `fq` filters used in the Pre-Filter.
 * When used as an `fq` param, or as a subquery clause in a larger query: No implicit Pre-Filter is used.
-** `includeTags` and `excludeTags` may not be used in these situations.
+** `includeTags` and `excludeTags` must not be used in these situations.
 
 
 The example request below shows two usages of the `knn` query parser that will get _no_ implicit Pre-Filtering from any of the `fq` parameters, because neither usage is as the main `q` param:
@@ -366,7 +366,7 @@ If we modify the above request to add tags to the `fq` parameters, we can specif
 In this example, only the `inStock:true` filter will be used for KNN Pre-Filtering to find the the `topK=10` documents, and the `category:AAA` filter will be applied independently; possibly resulting in less then 10 total matches.
 
 
-Some use case where `includeTags` and/or `excludeTags` may be more useful then an explicit `preFilter` parameters:
+Some use cases where `includeTags` and/or `excludeTags` may be more useful then an explicit `preFilter` parameters:
 
 * You have some `fq` parameters that are xref:configuration-guide:requesthandlers-searchcomponents.adoc#paramsets-and-useparams[re-used on many requests] (even when you don't use the `knn` parser) that you wish to be used as KNN Pre-Filters when you _do_ use the `knn` query parser.
 * You typically want all `fq` params to be used as KNN Pre-Filters, but when users "drill down" on Facets, you want the `fq` parameters you add to be excluded from the KNN Pre-Filtering so that the result set gets smaller; instead of just computing a new `topK` set.