lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anshum <>
Subject Re: Using Lucene for user query parsing
Date Fri, 06 Mar 2009 06:50:36 GMT
Hi Srinivas,

Perhaps what you need here is a query formation logic which assigns the
right keywords to the right fields. Let me know in case I got it wrong. One
way to do that could be by using index time boost for fields and then
running a query (so that a particular field is preferred over the other).
As per my knowledge lucene should be a better solution that anything else
that 'I know of' for such a thing, but there'd be a few things that you
would have to build yourself as well.

Anshum Gupta
Naukri Labs!

The facts expressed here belong to everybody, the opinions to me. The
distinction is yours to draw............

On Fri, Mar 6, 2009 at 11:55 AM, Srinivas Bharghav <
> wrote:

> I am trying to evaluate as to whether Lucene is the right candidate for the
> problem at hand.
> Say I have 3 indexes:
> Index 1 has street names.
> Index 2 has business names.
> Index 3 has area names.
> All these names can be single words or a combination of words like woodward
> street or marks and spencers street etc etc.
> Now the use enters a query saying "mc donalds woodward street kingston
> precinct".
> I have to parse this query and come up with the best match possible. The
> problem is, in the query I do not know which part is the business name or
> area name or street name. Also the user may give the query in any order for
> example he may give it as "kingston precinct mc donalds woodward street".
> There might be spelling mistkaes in the query enterd by the user. Also he
> might use road for street or lane for street and such things. I know that
> Lucene is the right candidate for the synonym and spelling mistakes part
> but
> am a bit hazy regarding the user query parsing part as to in which index to
> search what. Any help is greatly appreciated.
> Thanks,
> Srini.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message