[ECODP-dev] CKAN search query operator

Darwin Peltan darwin.peltan at okfn.org
Thu May 2 14:19:41 UTC 2013


Personally I think we should choose the behaviour which gives the best
search results and avoid giving the user the choice.

Darwin Peltan
Project Manager

The Open Knowledge Foundation
http://www.okfn.org

Skype: darwinp
Twitter: @darwin


On 2 May 2013 09:40, John Glover <john.glover at okfn.org> wrote:

> Hi Bert,
>
> Sure, users should be already able to do that at the moment as we
> generally just pass the search query directly through to Solr (with a bit
> of additional parameter checking). However, I have found an alternate way
> to do what you suggest at query time which should allow us to change the
> operator without having to manually parse the query, which is much better
> from a technical point of view. So yes this is feasible.
>
> Thanks,
> John
>
>
> On 1 May 2013 23:02, Bert Van Nuffelen <bert.van.nuffelen at tenforce.com>wrote:
>
>> Hi John,
>>
>> I am not a solr specialist, but the search language of solr allows users
>> to specify and and or (see some easy examples here
>> http://www.solrtutorial.com/solr-query-syntax.html)
>> That is the surface syntax which can be supported by the CKAN search box.
>> Based on your answer,  you state that you do not recommend it, but
>> something is feasible I understand. What do you think of the old school
>> solution: the same semantics for the search box as it is now (a list of
>> keywords) but with an additional operator selection (And/OR). With that the
>> user defines its search operator globally for the search entry.
>>
>> kind regards,
>>
>> Bert
>>
>>
>>
>>
>> 2013/4/30 John Glover <john.glover at okfn.org>
>>
>>> Hello Bert,
>>>
>>> The default query operator (AND vs OR) is set in the Solr config file,
>>> and so cannot currently be updated at query time, only when Solr is
>>> restarted.
>>>
>>> We could add some logic to parse the user's query and insert additional
>>> AND/OR strings at query time if required. We generally don't recommend this
>>> though as it not that straight-forward (what happens if 'and' or 'or' are
>>> in the actual query?) and probably just adds clutter to the UI.
>>>
>>> John
>>>
>>
>>
>>
>> --
>> Bert Van Nuffelen
>>
>> Semantic Technologies Software Architect at TenForce
>> www.tenforce.be
>>
>> Bert.Van.Nuffelen at tenforce.com
>> Office: +32 (0)16 31 48 60
>> Mobile:+32 479 06 24 26
>> skype: bert.van.nuffelen
>>
>
>
> _______________________________________________
> Ecodp-dev mailing list
> Ecodp-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ecodp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.okfn.org/mailman/private/ecodp-dev/attachments/20130502/73e2bfef/attachment.html>


More information about the ecodp-dev mailing list