Tried but still didn't get correct result. I guess the reason is because I use block join with the document. My current solution is to use a name tagged to extract persons then put name field restriction before it. This will not work with all situations though. Thanks for the reply.
On Tuesday, November 3, 2015, Imtiaz Shakil Siddique < shakilsust...@gmail.com> wrote: > I think edismax query parser perfectly fits for your needs. > You can make edismax search for query words on multiple fields using the > "qf" parameter and you can also set the priority of those searched fields. > > Edismax also auto generates phrase query for specified fields . ( look into > the "pf" and "pf2" parameter ) > > Here is an example --> > qf: name^3.0 text^1.0 > pf: name > ps:2 > pf2:name text^0.5 > > Now when you search for "Kate Winslet" you'll get docs matching the query > word from name field. > If you search for "Kate Winslet Movie" then "pf" will pick up "Kate > Winslet" from name field and the "movie" will be picked up from text field. > You can experiment the query time boosting to fine tune your needs. > > Regards > Imtiaz Shakil Siddique > On Nov 3, 2015 9:36 PM, "scott chu" <scott....@udngroup.com <javascript:;>> > wrote: > > > solr-user，妳好 > > > > With repsect to querying, Dismax makes solr query syntax quite like > > Google's, you type simple keywords, you can boost them, you can use +/- > > just like Google's. Meaning they give users a lot of covenince and less > > boolean knowlege to establish intended query string. Normal Lucene search > > syntax are treated as escaped characters except AND & OR. You can say > > Dismax gives some room for phrase querying. eDismax improve something > > of Dismax but it depends on if you need thorse improvement or not. You > can > > see it here: > > > https://cwiki.apache.org/confluence/display/solr/The+Extended+DisMax+Query+Parser > > > > > > > > ----- Original Message ----- > > *From: *Yangrui Guo <guoyang...@gmail.com <javascript:;>> > > *To: *solr-user@lucene.apache.org <javascript:;> > > *Date: *2015-11-01, 23:58:27 > > *Subject: *Re: Kate Winslet vs Winslet Kate > > > > Could you tell me more about the edismax approach? I'm new to it. Thanks > a > > > > lot > > > > On Sunday, November 1, 2015, Erick Erickson <erickerick...@gmail.com > <javascript:;> > > <+erickerick...@gmail.com <javascript:;>>> wrote: > > > > > If your goal is to have docs with "kate" and "winslet" > > > in the _name_ field be scored higher, just make that > > > explicit as > > > name:(kate AND winslet) > > > perhaps boosting as > > > name:(kate AND winslet)^10 > > > or add it as a clause > > > q=kate AND winslet OR name:(kate AND winslet)^10 > > > or even > > > q=kate AND winslet OR name:(kate AND winslet)^10 OR name:"kate > > winslet"^20 > > > > > > > > > Or use edismax to do this kind of thing for you, that's > > > its purpose. > > > > > > Best, > > > Erick > > > > > > On Sun, Nov 1, 2015 at 7:06 AM, Yangrui Guo <guoyang...@gmail.com > <javascript:;> > > <+guoyang...@gmail.com <javascript:;>> > > > <javascript:;>> wrote: > > > > I debugged the query and found the query has been translated into > > > > _text_:Kate AND _text_:Winslet, which _text_ is the default search > > field. > > > > Because my documents use parent/child relation it appeared that if > > > there's > > > > no exact match of Kate Winslet, solr will return all documents > contains > > > > "Kate" and "Winslet" in anywhere. However it will more sense if solr > > can > > > > rank docs that have "Kate" and "Winslet" in the same field higher. Of > > > > course I can use some NLP tricks with named entity recognition but it > > > would > > > > be more expensive to develop. > > > > > > > > On Sunday, November 1, 2015, Paul Libbrecht <p...@hoplahup.net > <javascript:;> > > <+p...@hoplahup.net <javascript:;>> > > > <javascript:;>> wrote: > > > > > > > >> Alexandre, > > > >> > > > >> I guess you are talking about that post: > > > >> > > > >> > > > >> > > > > > > http://lucidworks.com/blog/2015/06/06/query-autofiltering-extended-language-logic-search/ > > > >> > > > >> I think it is very often impossible to solve properly. > > > >> > > > >> Words such as "direction" have very many meanings and would come in > > > >> different fields. > > > >> In IMDB, words such as the names of persons would come in at least > > > >> different roles; similarly, the actors' role's name is likely to > match > > > >> the family name of persons... > > > >> > > > >> Paul > > > >> > > > >> > > > >> > > > >> > As others indicated having intelligence to recognize the terms > (e.g. > > > >> > Kate should be in name) or some user indication to do so can make > > > thing > > > >> > more precise but is rarely done. > > > >> > Alexandre Rafalovitch <mailto:arafa...@gmail.com <javascript:;> > > <+arafa...@gmail.com <javascript:;>> <javascript:;> > > > <javascript:;>> > > > >> > 1 novembre 2015 13:07 > > > >> > Which is what I believe Ted Sullivan is working on and presented > at > > > > > >> > the latest Lucene/Solr Revolution. His presentation does not seem > to > > > >> > be up, but he was writing about it on: > > > >> > http://lucidworks.com/blog/author/tedsullivan/ > > > >> > > > >> > Erick Erickson <mailto:erickerick...@gmail.com <javascript:;> > > <+erickerick...@gmail.com <javascript:;>> <javascript:;> > > > <javascript:;>> > > > >> > 1 novembre 2015 07:40 > > > >> > Yeah, that's actually a tough one. You have no control over what > the > > > >> > user types, > > > >> > you have to try to guess what they meant. > > > >> > > > >> > > > > > > > > > > > ----- > > 未在此訊息中找到病毒。 > > 已透過 AVG 檢查 - www.avg.com > > 版本: 2015.0.6173 / 病毒庫: 4455/10925 - 發佈日期: 10/31/15 > > > > > > >
