Return-Path: Delivered-To: apmail-jakarta-lucene-dev-archive@apache.org Received: (qmail 22437 invoked from network); 18 Feb 2002 20:40:03 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 18 Feb 2002 20:40:03 -0000 Received: (qmail 16362 invoked by uid 97); 18 Feb 2002 20:40:03 -0000 Delivered-To: qmlist-jakarta-archive-lucene-dev@jakarta.apache.org Received: (qmail 16326 invoked by uid 97); 18 Feb 2002 20:40:02 -0000 Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Lucene Developers List" Reply-To: "Lucene Developers List" Delivered-To: mailing list lucene-dev@jakarta.apache.org Received: (qmail 16218 invoked from network); 18 Feb 2002 20:40:01 -0000 Date: Mon, 18 Feb 2002 12:39:58 -0800 From: Brian Goetz To: Lucene Developers List Subject: Re: Status of proximity in query language Message-ID: <20020218123958.D14869@lx.quiotix.com> References: <20020216101517.D28050@lx.quiotix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from carlson@bookandhammer.com on Mon, Feb 18, 2002 at 10:53:23AM -0800 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > Thanks for the feedback on why the NEAR operator was not yet incorporated. I > didn't understand all the issues for not using the NEAR operator. For my > purposes, I am fine with these limitations and describe them in the search > documentation. Right, but we have to be extra careful with the syntax for the query parser, as it is exposed to users who don't even know what Lucene is, let alone having read the docs. We're designing for typical users here, not programmers. > However, as a potential solution, what do people think about a multi-level > slop functionality? That is having the slop really be an array of distances > between terms. > > So "foo bar" NEAR3 "unga bunga" would be translated into > > Foo within 1 of bar within 3 of unga within 1 of bunga. > > This would become a single phrase query, but the "slop" would be variable > between each word. That's OK when everthing is a term. What about Foo* NEAR Bar We'd need to elevate the concept of 'slop' up the query hierarchy so you could apply slop to arbitrary queries. Doug, is that practical? -- To unsubscribe, e-mail: For additional commands, e-mail: