Re: knowing which field contributed the search result
Hi David: Can you further explain which calls specically would solve my problem? Thanks -John On Mon, 21 Feb 2005 12:20:15 -0800, David Spencer [EMAIL PROTECTED] wrote: John Wang wrote: Anyone has any thoughts on this? Does this help? http://jakarta.apache.org/lucene/docs/api/org/apache/lucene/search/Searchable.html#explain(org.apache.lucene.search.Query,%20int) Thanks -John On Wed, 16 Feb 2005 14:39:52 -0800, John Wang [EMAIL PROTECTED] wrote: Hi: Is there way to find out given a hit from a search, find out which fields contributed to the hit? e.g. If my search for: contents1=brown fox OR contents2=black bear can the document founded by this query also have information on whether it was found via contents1 or contents2 or both. Thanks -John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: knowing which field contributed the search result
John Wang wrote: Hi David: Can you further explain which calls specically would solve my problem? Not in depth but anyway: Examine the output of Explanation.toHtml() and/or Explanation.toString(). Does it contain the info you want..if so call the other Explanation methods and/or dig into the src if necessary. getValue() is the score, so all that's missing is the name of the field and I'm not sure if that's directly returned or not. Thanks -John On Mon, 21 Feb 2005 12:20:15 -0800, David Spencer [EMAIL PROTECTED] wrote: John Wang wrote: Anyone has any thoughts on this? Does this help? http://jakarta.apache.org/lucene/docs/api/org/apache/lucene/search/Searchable.html#explain(org.apache.lucene.search.Query,%20int) Thanks -John On Wed, 16 Feb 2005 14:39:52 -0800, John Wang [EMAIL PROTECTED] wrote: Hi: Is there way to find out given a hit from a search, find out which fields contributed to the hit? e.g. If my search for: contents1=brown fox OR contents2=black bear can the document founded by this query also have information on whether it was found via contents1 or contents2 or both. Thanks -John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
MultiField Queries without the QueryParser
Hello; The book meantions the MultiFieldQueryParser as one way of dealing with multifield queries. Can someone point me in the direction of other ways? Thanks, Luke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MultiField Queries without the QueryParser
Responding to this posts. Please disreguard. Sorry. - Original Message - From: Luke Shannon [EMAIL PROTECTED] To: Lucene Users List lucene-user@jakarta.apache.org Sent: Tuesday, February 22, 2005 5:16 PM Subject: MultiField Queries without the QueryParser Hello; The book meantions the MultiFieldQueryParser as one way of dealing with multifield queries. Can someone point me in the direction of other ways? Thanks, Luke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lucene vs. in-DB-full-text-searching
On Sat, 19 Feb 2005 09:31, Otis Gospodnetic wrote: You are right. Since there are C++ and now C ports of Lucene, it would be interesting to integrate them directly with DBs, so that the RDBMS full-text search under the hood is actually powered by one of the Lucene ports. Or to see Lucene + Derby (100% JAVA embedded database donated from IBM currently in Apache incubation) integrated together... that would be really nice and powerful. Does anyone know if there are any integration plans? -- Cheers, David This message is intended only for the named recipient. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lucene in the Humanities
: Just curious: it would seem easier to use multiple fields for the : original case and lowercase searching. Is there any particular reason : you analyzed the documents to multiple indexes instead of multiple : fields? : : I considered that approach, however to expose QueryParser I'd have to : get tricky. If I have title_orig and title_lc fields, how would I : allow freeform queries of title:something? Why have seperate fields? Why not index the title into the title field twice, once with each term lowercased and once with the case left alone. (Using an analyzer that tokenizes The Quick BrOwN fox as [the] [quick] [brown] [fox] [The] [Quick] [BrOwN] [fox]) Then at search time, depending on the value of of the checkbox, construct your QueryParser using the appropriate Analyzer. The only problem i can think of would be inflated scores for terms that are naturally lowercased, because they would wind up getting added to the index twice, but based on what i've seen of hte data you are working with, i imageing that if you used UPPERCASE instead of lowercase you could drasticly reduce the likelyhood of any problems with that. -Hoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
