> *All* of the terms in the field must be matched by the query....not > vice-versa.
Exactly. This is why I was trying to explain it as a reverse search. I just realized I describe it as a *large list of known keywords when really its small; no more than 1000. Forgetting about performance how hard do you think this would be to implement? How should I even start? Thanks for the input On Aug 9, 2013, at 6:56 AM, Yonik Seeley <yo...@lucidworks.com> wrote: > *All* of the terms in the field must be matched by the query....not > vice-versa. > And no, we don't have a query for that out of the box. To implement, > it seems like it would require the total number of terms indexed for a > field (for each document). > I guess you could also index start and end tokens and then use query > expansion to all possible combinations... messy though. > > -Yonik > http://lucidworks.com > > On Fri, Aug 9, 2013 at 8:19 AM, Erick Erickson <erickerick...@gmail.com> > wrote: >> This _looks_ like simple phrase matching (no slop) and highlighting... >> >> But whenever I think the answer is really simple, it usually means >> that I'm missing something.... >> >> Best >> Erick >> >> >> On Thu, Aug 8, 2013 at 11:18 PM, Mark <static.void....@gmail.com> wrote: >> >>> Ok forget the mention of percolate. >>> >>> We have a large list of known keywords we would like to match against. >>> >>> Product keyword: "Sony" >>> Product keyword: "Samsung Galaxy" >>> >>> We would like to be able to detect given a product title whether or not it >>> matches any known keywords. For a keyword to be matched all of it's terms >>> must be present in the product title given. >>> >>> Product Title: "Sony Experia" >>> Matches and returns a highlight: "<em>Sony</em> Experia" >>> >>> Product Title: "Samsung 52inch LC" >>> Does not match >>> >>> Product Title: "Samsung Galaxy S4" >>> Matches a returns a highlight: "<em>Samsung Galaxy</em>" >>> >>> Product Title: "Galaxy Samsung S4" >>> Matches a returns a highlight: "<em> Galaxy Samsung</em>" >>> >>> What would be the best way to approach this? >>> >>> >>> >>> >>> On Aug 5, 2013, at 7:02 PM, Chris Hostetter <hossman_luc...@fucit.org> >>> wrote: >>> >>>> >>>> : Subject: Percolate feature? >>>> >>>> can you give a more concrete, realistic example of what you are trying to >>>> do? your synthetic hypothetical example is kind of hard to make sense of. >>>> >>>> your Subject line and comment that the "percolate" feature of elastic >>>> search sounds like what you want seems to have some lead people down a >>>> path of assuming you want to run these types of queries as documents are >>>> indexed -- but that isn't at all clear to me from the way you worded your >>>> question other then that. >>>> >>>> it's also not clear what aspect of the "results" you really care about -- >>>> are you only looking for the *number* of documents that "match" according >>>> to your concept of matching, or are you looking for a list of matches? >>>> what multiple documents have all of their terms in the query string -- >>> how >>>> should they score relative to eachother? what if a document contains the >>>> same term multiple times, do you expect it to be a match of a query only >>>> if that term appears in the query multiple times as well? do you care >>>> about hte ordering of the terms in the query? the ordering of hte terms >>> in >>>> the document? >>>> >>>> Ideally: describe for us what you wnat to do, w/o assuming >>>> solr/elasticsearch/anything specific about the implementation -- just >>>> describe your actual use case for us, with several real document/query >>>> examples. >>>> >>>> >>>> >>>> https://people.apache.org/~hossman/#xyproblem >>>> XY Problem >>>> >>>> Your question appears to be an "XY Problem" ... that is: you are dealing >>>> with "X", you are assuming "Y" will help you, and you are asking about >>> "Y" >>>> without giving more details about the "X" so that we can understand the >>>> full issue. Perhaps the best solution doesn't involve "Y" at all? >>>> See Also: http://www.perlmonks.org/index.pl?node_id=542341 >>>> >>>> >>>> >>>> >>>> >>>> >>>> -Hoss >>> >>>