[
https://issues.apache.org/jira/browse/JSPWIKI-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18132891#comment-18132891
]
Arturo Bernal commented on JSPWIKI-1314:
----------------------------------------
I measured two things with tests against a real engine and the default
ClassicAnalyzer, and one correction to the description follows from them.
Ranking: with three pages, one named Deployment whose text is 200 sentences
that never contain the word, one whose text says deployment three times, and
one with a single mention, the search for deployment returns the page named
Deployment first (score 61, then 42, then 36). So although no field is boosted,
a name match already ranks high because the name field is short. The sentence
in the description saying a name match weighs the same as a text match is not
borne out in this case, and I am not proposing a boost without a test that
shows a problem. Accents: with the pages Cancion (text La cancion del verano)
and Musica (text Una canción muy bonita), searching canción finds only Musica
and searching cancion finds only Cancion. A user who types a word without its
accent does not find the page that has it, and the other way round. One
possible change is an analyzer that adds ASCIIFoldingFilter to the default one.
The filter is already in lucene-analysis-common 9.12.2, which jspwiki-main
uses, so there would be no new dependency. Open questions: whether it should be
on by default or optional, since existing wikis would need a reindex, and how
it behaves with the context highlighter. I will wait for comments before
opening a pull request.
> Improve search relevance and add search filters
> -----------------------------------------------
>
> Key: JSPWIKI-1314
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1314
> Project: JSPWiki
> Issue Type: Improvement
> Reporter: Arturo Bernal
> Priority: Minor
>
> This is a proposal for discussion, not an implementation. The search is
> backed by Lucene, which is up to date, so the room for improvement is in how
> results are ranked and in how they can be narrowed down.
>
> What exists today: LuceneSearchProvider parses the query with a
> MultiFieldQueryParser over the fields contents, name, author, attachment and
> keywords. No field is boosted, so a match in the page name weighs the same as
> a match in the text. The score shown to the user is the Lucene score
> multiplied by 100 and cast to an integer. The result list is limited to
> 99,999 hits and the permission check is done per hit after the search. The
> search page (FindContent.jsp) offers a scope choice (all, authors, page name,
> contents, attachments) which is implemented by prefixing the query with
> author:, name:, contents: or attachment:.
>
> Proposal, relevance: boost the page name and the keywords over the contents,
> explain why a page matched, and add relevance tests with a small set of
> sample pages and queries so that changes in ranking are visible. Proposal,
> filters: restrict by modification date range, by author, by attachment type
> and by page name prefix, in the search page and through the query syntax.
>
> Related issues: JSPWIKI-441 (details in the search summary), JSPWIKI-501
> (underscore in the search term, a fix is proposed in the pull request 543),
> JSPWIKI-409 (results are wrong when a page has changed), JSPWIKI-917 (search
> window in the Haddock template) and JSPWIKI-858 (filters in the IndexPlugin).
> This is less urgent than the other proposals and can be discussed on
> [email protected].
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
