incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <gary.mar...@wandisco.com>
Subject Improved Search Architecture - Query Results View and Resource Query (Was: Re: [Apache Bloodhound] Proposals/BEP-0004 added)
Date Thu, 22 Nov 2012 12:56:57 GMT
Next a few comments on the Query Result view and Resource Query sections:

On 22/11/12 11:08, Andrej Golcov wrote:
> Hi all,
>
> I've just added first draft of proposal for search improvements. So, let's
> discuss it :)
>
> I suggest that we agree on functional requirements and then pass to
> possible implementation.
>
> Regards, Andrej
>
>
> On 22 November 2012 11:32, Apache Bloodhound <
> bloodhound-dev@incubator.apache.org> wrote:
>
>> Page "Proposals/BEP-0004" was added by andrej
>> Content:
>> -------8<------8<------8<------8<------8<------8<------8<------8<--------
>>
>> = BEP 4 : Improved search architecture #overview
[snip]
>>
>> === Query Result view
>>
>> Query Result view represents consistent view of query result for different
>> resources. Result may be represented as
>>    - All resources result tab - default, common for all resources columns
>> e.g. name and description
>>    - Resource result tabs - resource specific fields are shown e.g. id,
>> status, summary for ticket.
>>    - Query Result view can be instructed to limit result to specific
>> resource type e.g. show only tickets in result. In this case, resource tabs
>> can be omitted.

Presumably, this would be a part of the new query syntax so that it can 
be relatively easy to filter before getting to this page.
>> User can refine search conditions either by editing query or by using
>> Query Builder.

I would like to see others comment on the mockup for the query builder. 
Consistency with other views suggest that there may be space on the 
right hand side, replacing the activity area - I assume that we will not 
be displying activity on any search/query screen.

>> User can specify what fields should be selected and in what results order
>> should be applied. A new order type is introduced for free-text search:
>> score
>>
>> Query Result view should support facets (
>> http://searchhub.org/2009/09/02/faceted-search-with-solr/)  for example:
>>    - All resources result tab can show facets for resource type and product
>>    - Ticket result tab can show facets for products and ticket status

Facets seem to me to be a very important enhancement.
>>
>> Other nice to have features in no particular order:
>>    - Possibility to save a query for specific user and sharing of saved
>> queries
>>    - Search highlighting

Saved/stored queries have been discussed in the mailing list before a 
few times so I think this is probably an expectation beyond the ability 
to put a search macro on a wiki page. I think that this should probably 
be considered separately of this solution but we should make sure that 
such stored queries support any implementation that arises from this.

Search highlighting might also be worth separating out so that we make 
sure that we focus on getting searches done correctly, even if it turns 
out it is just a small enhancement on top. I assume that this is 
referring to terms being highlighted when you click on a link result 
here so it is probably out of scope of the Query result view section anyway.

>> === Resource Query
>>
>> New Resource Query should provide the following functionality:
>>    - free-text search support
>>    - facet support
>>    - it is a superset of TracQuery functionality
So we can embed TracQuery syntax within the new queries?
>>    - basic query expressions AND, OR, NOT, search by specific field, search
>> [FROM TO] - TBD (can be similar to SQL or lucene/solr like)

I think that this could also be considered from the point of view of a 
set operation syntax which could be interesting. Not sure if it is worth 
it of course. Anyway, in addition to logical operators, we do need to be 
able to express a grouping syntax to build more advanced expressions 
from the basics.

It would also be nice if we were able to express these queries 
relatively easily in a query string so that it is possible to just write 
your query directly in a link and be understandable.
>>    - search through different resources not only tickets: wiki, milestones,
>> changesets and other pluggable resources
>>    - search through all resource fields
>>    - search through attachments, history and comments
>>    - multi-product aware - apply security context etc
>>    - order by free-text score. Score calculation can be configured, for
>> example if found in summary: id: score:100, score*10, in keywords: score*5,
>> in components: score*3 …

I would probably suggest that we keep configurability of scores in mind 
but don't provide the interface to change it until a bit later. A bit of 
clarification might be helpful here too. Presumably term found in 
summary would be score*=100 rather than just assigned 100. In addition, 
we could consider modifying the score based on the date. There is a 
further possibility of including fairly simple "favour [something]" 
(e.g. "newer", "older", etc) radio boxes to adjust the scoring 
dynamically as I am not convinced that users should be expected to 
adjust these values for themselves at the moment.

>> Nice to have features
>>    - Support search in attachments of specific types e.g word, exel etc.
I seem to remember that you get this in solr for free but I am not so 
sure about the others.

Cheers,
     Gary

Mime
View raw message