[
https://issues.apache.org/jira/browse/JSPWIKI-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arturo Bernal updated JSPWIKI-1314:
-----------------------------------
Description:
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. In a test, a page whose name matches the query
still ranked first, ahead of pages that mention the word in their text, because
the name field is short. 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: measure first whether the page name or the keywords need a
boost, 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].
was:
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].
> 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. In a test, a page whose name matches the query
> still ranked first, ahead of pages that mention the word in their text,
> because the name field is short. 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: measure first whether the page name or the keywords need
> a boost, 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)
