On 06-May-2011, at 2:04 AM, Paul Libbrecht wrote:
>
> Le 6 mai 2011 à 00:20, Otis Gospodnetic a écrit :
>>> thus far, only search-testing has provided some analytics measures for us
>>> (precision and recall ones). We, of course, construct the test-suites from
>>> the
>>> logs.
>>
>> Inter
Our next IR Meetup is at Cengage Learning on May 19, 2011. Please RSVP here:
http://www.meetup.com/Michigan-Information-Retrieval-Enthusiasts-Group/events/17567795/
Presentations:
1. Bayesian Language Model
This talk presents a Bayesian language model, originally described by (Teh
2006), wh
FSTLookup is strictly prefix-based. JaspellLookup should handle the fuzzy
matching, but I know very little about it. The source code is your friend,
though -- just try what works and what doesn't.
Dawid
On Fri, May 6, 2011 at 3:21 PM, Clemens Wyss wrote:
> What if I'd like to add "fuzzy" lookup
Our Lucene/indexing architecture allows any number of index data providers to
register and put their data into a central index. As every provider can/does
add his own specific fields to its documents there is no single schema,... And
yes, this all works, except the problem I have with the "term
What if I'd like to add "fuzzy" lookup for terms?
E.g.:
"melo" should also bring up "merlot"
> -Ursprüngliche Nachricht-
> Von: Dawid Weiss [mailto:dawid.we...@gmail.com]
> Gesendet: Freitag, 6. Mai 2011 11:30
> An: java-user@lucene.apache.org
> Betreff: Re: Using Solr's (Auto)suggest wi
I'm a bit confused by this:
***
With my query, I
would like to only return 'patrol' items and nothing else. Is there a way
to do this?? My current querying code is below. This returns all items with
'patrol' in it.
**
Are you saying that if you're searching on "p
Well, Solr officially uses Lucene, but you'll do disappointingly
little Java coding. Which some people think is a plus :).
The biggest issue will be making really, really sure that your
schema.xml file in Solr reflects your use in the Lucene code
Actually, I'd swallow the blue pill and just make t
I believe creating a large number of fields is not a good match w/the
underlying architecture, and you'd be better off w/a large number of
documents/small number of fields, where the same field occurs in every
document. There is some discussion here:
http://markmail.org/message/hcmt5syca7zdeac
So you'd like case-sensitive lookup, not case-insensitive lookup. FSTLookup
just takes characters from the input and does not perform any normalization.
So, if you feed it terms with casing, you'll get (cased) suggestions back.
If you need cased suggestions, but provide normalized (lowercased) pref
Thx Dawid,
Could you be more precise on 2. ? I'd like to leave the suggested terms
untouched, i.e. cased.
Clemens
> -Ursprüngliche Nachricht-
> Von: Dawid Weiss [mailto:dawid.we...@gmail.com]
> Gesendet: Freitag, 6. Mai 2011 11:12
> An: java-user@lucene.apache.org
> Betreff: Re: Using So
1. FSTLookup is in the trunk only, it has not been released.
2. Case-insensitive lookups are possible, you'd just need to pass normalized
tokens from which the dictionary is built and then use the same
normalization at the time you query for suggestions.
3. "http://search-lucene.com/m/586gA4ccL11";
I have come across TSTLookup.
In which jar Do I find FSTLookup? Does any of these lookup-classes allow case
insensitive lookups? My terms are (unfortunately) cased.
What Lookup "sits" behind this suggester
http://search-lucene.com/m/586gA4ccL11
here?
> -Ursprüngliche Nachricht-
> Von:
Le 6 mai 2011 à 00:20, Otis Gospodnetic a écrit :
>> thus far, only search-testing has provided some analytics measures for us
>> (precision and recall ones). We, of course, construct the test-suites from
>> the
>> logs.
>
> Interesting. It sounds like you don't currently utilize any sort o
13 matches
Mail list logo
