Subject: Re: [MORG] Review: draft-ietf-morg-fuzzy-search-02

From: Cyrus Daboo <[email-masked]>
Date: Sun, 01 Aug 2010 14:56:19 +0200

Hi Timo,

--On July 31, 2010 8:32:41 PM +0100 Timo Sirainen <[email-masked]> wrote:

>> 6) Do clients need to care that the FUZZY search key is not
>> distributive, e.g.:
>>
>> FUZZY OR SUBJECT x SUBJECT y != OR FUZZY SUBJECT x FUZZY SUBJECT y
>
> I agree with Barry, those are the same. Added example:

I am not totally convinced. My point is how a server deals with two FUZZY's 
- does it somehow treats those as one, does it do the two separately (as 
per the OR example right-hand side) and then combine relevance in some 
fashion for the aggregate? How does you server handle multiple FUZZY's?

Note that I do think this is an edge case so its probably not worth 
debating too much, but I'd like to understand this for my own sanity...

> FUZZY is applied to all search keys when parenthesis or OR is used. For
> example in this search query everything is matched fuzzily:
>
>  C: A03 SEARCH FUZZY OR (SUBJECT work FROM [email-masked]) SUBJECT home
>  S: * SEARCH 2 5
>  S: A03 OK Search completed.

Well that automatically falls out from the syntax since "OR" is itself a 
search-key that is the argument for FUZZY.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 01 Aug 2010 14:58:25 +0200

Hi Timo,

--On July 31, 2010 8:38:59 PM +0100 Timo Sirainen <[email-masked]> wrote:

>> I'm not sure I like that requirement.  Maybe you have to use SORT if
>> you want that.  What happens in the general case of PARTIAL?  Might a
>> client that wants the *newest* 10 results be unhappy if it got the
>> OLDEST 10?
>
> Yes, I think SORT (RELEVANCY) should be required for that.  RFC 5267
> isn't super clear on if SORT supports PARTIAL, but I guess it should
> according to ABNF.

Can we get clarification on that? Even add an example to fuzzy search 
showing a client finding the top-10 relevant items.

-- 
Cyrus Daboo

---

From: Timo Sirainen <[email-masked]>
Date: Fri, 20 Aug 2010 19:33:27 +0100

On Sun, 2010-08-01 at 14:56 +0200, Cyrus Daboo wrote:

> fashion for the aggregate? 

"Implementation-determined"? :)

> How does you server handle multiple FUZZY's?

I haven't actually implemented FUZZY yet, only the relevancy parts of it
as part of other non-standard search keys. Looking at the code, it
doesn't handle scores for multiple fuzzy searches well at all, simply
drops the earlier searches' scores..

> search-key that is the argument for FUZZY.

So no point in having that example?

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 20 Aug 2010 14:35:27 -0400

Hi Timo,

--On August 20, 2010 7:33:27 PM +0100 Timo Sirainen <[email-masked]> wrote:

>> >  C: A03 SEARCH FUZZY OR (SUBJECT work FROM [email-masked]) SUBJECT
>> >  home S: * SEARCH 2 5

No need for that.

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Mon, 23 Aug 2010 14:04:34 -0500

> "Implementation-determined"? :)

After initially not being sure what people were on about here, I think
I see that the point is determining relevancy.  For anything else, one
just distributes the fuzz.

I suppose I could contrive an example with, say, date searches, where
"or fuzzy (date1) fuzzy (date2)" might be implemented as "within 2
days of date1 or within two days of date2", while (maaaaaybe) "fuzzy
or (date1) (date2)" might be implemented as spanning the entire range
from two days before the earlier date to two days after the later one.

But that seems a stretch.

In any case, I'm happy to see something added that says that it's up
to the implementation how to combine fuzzy searches in boolean
expressions, just as it's up to the implementation how to do the fuzzy
searches in the first place.

Barry