Subject: Re: [Zope-dev] Comment on CVS change

[Tres Seaver]

Casey Duncan <cduncan@kaivo.com> wrote:

> "R. David Murray" wrote:
> > 
> > >To: zope-checkins@zope.org
> > >Date: Mon, 19 Mar 2001 19:47:31 -0500 (EST)
> > >From: chrism@digicool.com (Chris McDonough)
> > >Subject: [Zope-Checkins] CVS: Zope2  - UnTextIndex.py:1.33.2.9
> > >
> > >Update of /cvs-repository/Zope2/lib/python/SearchIndex
> > >In directory korak:/home/chrism/sandboxes/2_3Branch/lib/python/SearchIndex
> > >
> > >Modified Files:
> > >      Tag: zope-2_3-branch
> > >       UnTextIndex.py
> > >Log Message:
> > >Changed default query operator to 'AND' instead of 'OR' (way improved
> > >  search results).
> > 
> > This strikes me as a Very Bad Thing.  Not the idea of having AND be the
> > default query operator, but the fact of *changing* the default.  If I
> > remember correctly the default is documented (insofar as it is documented)
> > as being AND, but the default has been OR for so long that I'm sure there
> > are many sites that will break if this change is committed to a release.
> > Worse, the behavior of a site as seen by end users will change.  Finally,
> > it is my experience that most search engines use OR as the default operator.
> > I prefer AND myself, but OR appears to be something of a defacto standard.
> > 
> > I'm willing to be convinced, though <grin>.
> > 
> > A way to set the default would be cool, but might open up a can of worms.
> 
> I'm a little torn between being alarmed at this and agreeing with it. I
> think if this is done there should be an TTW interface in ZCatalog to
> switch between AND and OR as the default. That would be the best
> solution IMHO. Also a _documented_ way to switch it in Catalog as well.

I've gotta weigh in here, too;  the breakage induced by this change
will be large.  Give that what *real* users expect is *neither* a
Boolean "AND" *nor* a Boolean "OR", but instead a DWIM/Googlesque
"affinity" search, I don't think the win is clear enough to warrant
the breakage:

  * "AND" searches return *small* result sets;  non-programmers
    will be surprised by the often-empty lists they get back,
    and won't have any clue how to broaden their search.  False
    negatives suck.

  * "OR" searches return *long* results sets;  non-programmers
    will be unhappy that the items they want are buried in the
    muck.  False positives suck.

Given that any site manager can override the policy trivially, using
only two lines of DTML, should we really be switching the (admittedly
arbitrary) existing polciy embedded in the core?

Tres.

P.S.

  <dtml-let search_terms="_.string.split( search_text )"
            search_with_and="_.string.join( search_terms, ' and ' )">
   <dtml-var searchCatalog>
  </dtml-let>

OK, so it is two and a half lines.

-- 
===============================================================
Tres Seaver                                tseaver@digicool.com
Digital Creations     "Zope Dealers"       http://www.zope.org