incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrej Golcov <and...@digiverse.si>
Subject Re: Improved Search Architecture - Query Results View and Resource Query (Was: Re: [Apache Bloodhound] Proposals/BEP-0004 added)
Date Thu, 22 Nov 2012 21:27:52 GMT
Hi,

> 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.
+1


> 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.
Let's consider saved/stored queries as postponed feature and concentrate on
core changes.

> 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.
By  "search highlighting" I meant highlighting of searching phrases in
result set. Let's consider this as "low priority" feature.


> 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.
What do you mean by grouping? More SQL  like COUNT(...) GROUP BY or display
results grouped by some fields?
I'm thinking about creating separate sub-page for Resource
Query requirements and syntax.

Regards, Andrej

On 22 November 2012 13:56, Gary Martin <gary.martin@wandisco.com> wrote:

> 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<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/<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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message