the pf and qf fields are REALLY nice for this On Fri, Nov 8, 2019 at 12:02 PM Walter Underwood <wun...@wunderwood.org> wrote:
> I always enable phrase searching in edismax for exactly this reason. > > Something like: > > <str name="qf”>title^8 keywords^4 text</str> > <str name="pf”>title^16 keywords^8 text^2</str> > > To deal with concepts in queries, a classifier and/or named entity > extractor can be helpful. If you have a list of concepts (“controlled > vocabulary”) that includes “Lamin A”, and that shows up in a query, that > term can be queried against the field matching that vocabulary. > > This is how LinkedIn separates people, companies, and places, for example. > > wunder > Walter Underwood > wun...@wunderwood.org > http://observer.wunderwood.org/ (my blog) > > > On Nov 8, 2019, at 10:48 AM, Erick Erickson <erickerick...@gmail.com> > wrote: > > > > Look at the “mm” parameter, try setting it to 100%. Although that’t not > entirely likely to do what you want either since virtually every doc will > have “a” in it. But at least you’d get docs that have both terms. > > > > you may also be able to search for things like “Lamin A” _only as a > phrase_ and have some luck. But this is a gnarly problem in general. Some > people have been able to substitute synonyms and/or shingles to make this > work at the expense of a larger index. > > > > This is a generic problem with context. “Lamin A” is really a “concept”, > not just two words that happen to be near each other. Searching as a phrase > is an OOB-but-naive way to try to make it more likely that the ranked > results refer to the _concept_ of “Lamin A”. The assumption here is “if > these two words appear next to each other, they’re more likely to be what I > want”. I say “naive” because “Lamins: A new approach to...” would _also_ be > found for a naive phrase search. (I have no idea whether such a title makes > sense or not, but you figured that out already)... > > > > To do this well you’d have to dive in to NLP/Machine learning. > > > > I truly wish we could have the DWIM search algorithm (Do What I Mean)…. > > > >> On Nov 8, 2019, at 11:29 AM, Guilherme Viteri <gvit...@ebi.ac.uk> > wrote: > >> > >> HI Walter and Paras > >> > >> I indexed it removing all the references to StopWordFilter and I went > from 121 results to near 20K as the search term q="Lymphoid and a > non-Lymphoid cell" is matching entities such as "IFT A" or "Lamin A". So I > don't think removing it completely is the way to go from the scenario we > have, but I appreciate the suggestion… > >> > >> Yes the response is using fl=* > >> I am trying some combinations at the moment, but yet no success. > >> > >> defType=edismax > >> q.alt=Lymphoid and a non-Lymphoid cell > >> Number of results=1599 > >> Quite a considerable increase, even though reasonable meaningful > results. > >> > >> I am sorry but I didn't understand what do you want me to do exactly > with the lst (??) and qf and bf. > >> > >> Thanks everyone with their inputs > >> > >> > >>> On 8 Nov 2019, at 06:45, Paras Lehana <paras.leh...@indiamart.com> > wrote: > >>> > >>> Hi Guilherme > >>> > >>> By accident, I ended up querying the using the default handler > (/select) and it worked. > >>> > >>> You've just found the culprit. Thanks for giving the material I > requested. Your analysis chain is working as expected. I don't see any > issue in either StopWordFilter or your boosts. I also use a boost of 50 > when boosting contextual suggestions (boosting "gold iphone" on a page of > iphone) but I take Walter's suggestion and would try to optimize my > weights. I agree that this 50 thing was not researched much about by us as > well (we never faced performance or relevance issues). > >>> > >>> See the major difference in both the handlers - edismax. I'm pretty > sure that your problem lies in the parsing of queries (you can confirm that > from parsedquery key in debug of both JSON responses). I hope you have > provided the response with fl=*. Replace q with q.alt in your /search > handler query and I think you should start getting responses. That's > because q.alt uses standard parser. If you want to keep using edisMax, I > suggest you to test the responses removing some combination of lst (qf, bf) > and find what's restricting the documents to come up. I'm out of office > today - would have certainly tried analyzing the field values of the > document in /select request and compare it with qf/bq in solrconfig.xml > /search. Do this for me and you'd certainly find something. > >>> > >>> On Thu, 7 Nov 2019 at 21:00, Walter Underwood <wun...@wunderwood.org > <mailto:wun...@wunderwood.org>> wrote: > >>> I normally use a weight of 8 for the most important field, like title. > Other fields might get a 4 or 2. > >>> > >>> I add a “pf” field with the weights doubled, so that phrase matches > have a higher weight. > >>> > >>> The weight of 8 comes from experience at Infoseek and Inktomi, two > early web search engines. With different relevance algorithms and totally > different evaluation and tuning systems, they settled on weights of 8 and > 7.5 for HTML titles. With the the two radically different system getting > the same number, I decided that was a property of the documents, not of the > search engines. > >>> > >>> wunder > >>> Walter Underwood > >>> wun...@wunderwood.org <mailto:wun...@wunderwood.org> > >>> http://observer.wunderwood.org/ <http://observer.wunderwood.org/> > (my blog) > >>> > >>>> On Nov 7, 2019, at 9:03 AM, Guilherme Viteri <gvit...@ebi.ac.uk > <mailto:gvit...@ebi.ac.uk>> wrote: > >>>> > >>>> Hi Wunder, > >>>> > >>>> My indexer takes quite a few hours to be executed I am shortening it > to run faster, but I also need to make sure it gives what we are expecting. > This implementation's been there for >4y, and massively used. > >>>> > >>>>> In your edismax handlers, weights of 20, 50, and 100 are extremely > high. I don’t think I’ve ever used a weight higher than 16 in a dozen years > of configuring Solr. > >>>> I've inherited that implementation and I am really keen to adequate > it, what would you recommend ? > >>>> > >>>> Cheers > >>>> Guilherme > >>>> > >>>>> On 7 Nov 2019, at 14:43, Walter Underwood <wun...@wunderwood.org > <mailto:wun...@wunderwood.org>> wrote: > >>>>> > >>>>> Thanks for posting the files. Looking at schema.xml, I see that you > still are using StopFilterFactory. The first advice we gave you was to > remove that. > >>>>> > >>>>> Remove StopFilterFactory everywhere and reindex. > >>>>> > >>>>> You will continue to have problems matching stopwords until you do > that. > >>>>> > >>>>> In your edismax handlers, weights of 20, 50, and 100 are extremely > high. I don’t think I’ve ever used a weight higher than 16 in a dozen years > of configuring Solr. > >>>>> > >>>>> wunder > >>>>> Walter Underwood > >>>>> wun...@wunderwood.org <mailto:wun...@wunderwood.org> > >>>>> http://observer.wunderwood.org/ <http://observer.wunderwood.org/> > (my blog) > >>>>> > >>>>>> On Nov 7, 2019, at 6:56 AM, Guilherme Viteri <gvit...@ebi.ac.uk > <mailto:gvit...@ebi.ac.uk>> wrote: > >>>>>> > >>>>>> Hi Paras, everyone > >>>>>> > >>>>>> Thank you again for your inputs and suggestions. I sorry to hear > you had trouble with the attachments I will host it somewhere and share the > links. > >>>>>> I don't tweak my index, I get the data from the graph database, > create a document as they are and save to solr. > >>>>>> > >>>>>> So, I am sending the new analysis screen querying the way you > suggested. Also the results with params and solr query url. > >>>>>> > >>>>>> During the process of querying what you asked I found something > really weird (at least for me). By accident, I ended up querying the using > the default handler (/select) and it worked. Then If I use the one I must > use, then sadly doesn't work. I am posting both results and I will also > post the handlers as well. > >>>>>> > >>>>>> Here is the link with all the files mentioned before > >>>>>> > https://www.dropbox.com/sh/fymfm1q94zum1lx/AADwU1c9EUf2A4d7FtzSKR54a?dl=0< > https://www.dropbox.com/sh/fymfm1q94zum1lx/AADwU1c9EUf2A4d7FtzSKR54a?dl=0> > <https://www.dropbox.com/sh/fymfm1q94zum1lx/AADwU1c9EUf2A4d7FtzSKR54a?dl=0 > <https://www.dropbox.com/sh/fymfm1q94zum1lx/AADwU1c9EUf2A4d7FtzSKR54a?dl=0 > >> > >>>>>> If the link doesn't work www dot dropbox dot com slash sh slash > fymfm1q94zum1lx/AADwU1c9EUf2A4d7FtzSKR54a ? dl equals 0 > >>>>>> > >>>>>> Thanks > >>>>>> > >>>>>>> On 7 Nov 2019, at 05:23, Paras Lehana <paras.leh...@indiamart.com > <mailto:paras.leh...@indiamart.com>> wrote: > >>>>>>> > >>>>>>> Hi Guilherme. > >>>>>>> > >>>>>>> I am sending they analysis result and the json result as requested. > >>>>>>> > >>>>>>> > >>>>>>> Thanks for the effort. Luckily, I can see your attachments (low > quality > >>>>>>> though). > >>>>>>> > >>>>>>> From the analysis screen, the analysis is working as expected. One > of the > >>>>>>> reasons for query="lymphoid and *a* non-lymphoid cell" not matching > >>>>>>> document containing "Lymphoid and a non-Lymphoid cell" I can > initially > >>>>>>> think of is: the stopword "a" is probably present in post-analysis > either > >>>>>>> of query or index. Did you tweak your index time analysis after > indexing? > >>>>>>> > >>>>>>> Do two things: > >>>>>>> > >>>>>>> 1. Post the analysis screen for and index=*"Immunoregulatory > >>>>>>> interactions between a Lymphoid and a non-Lymphoid cell"* and > >>>>>>> "query=*"lymphoid > >>>>>>> and a non-lymphoid cell"*. Try hosting the image and providing the > link > >>>>>>> here. > >>>>>>> 2. Give the same JSON output as you have sent but this time with > >>>>>>> *"echoParams=all"*. Also, post the exact Solr query url. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Wed, 6 Nov 2019 at 21:07, Erick Erickson < > erickerick...@gmail.com <mailto:erickerick...@gmail.com>> wrote: > >>>>>>> > >>>>>>>> I don’t see the attachments, maybe I deleted old e-mails or some > such. The > >>>>>>>> Apache server is fairly aggressive about stripping attachments > though, so > >>>>>>>> it’s also possible they didn’t make it through. > >>>>>>>> > >>>>>>>>> On Nov 6, 2019, at 9:28 AM, Guilherme Viteri <gvit...@ebi.ac.uk > <mailto:gvit...@ebi.ac.uk>> wrote: > >>>>>>>>> > >>>>>>>>> Thanks Erick. > >>>>>>>>> > >>>>>>>>>> First, your index and analysis chains are considerably > different, this > >>>>>>>> can easily be a source of problems. In particular, using two > different > >>>>>>>> tokenizers is a huge red flag. I _strongly_ recommend against > this unless > >>>>>>>> you’re totally sure you understand the consequences. > Additionally, your use > >>>>>>>> of the length filter is suspicious, especially since your problem > statement > >>>>>>>> is about the addition of a single letter term and the min length > allowed on > >>>>>>>> that filter is 2. That said, it’s reasonable to suppose that the > ’a’ is > >>>>>>>> filtered out in both cases, but maybe you’ve found something odd > about the > >>>>>>>> interactions. > >>>>>>>>> I will investigate the min length and post the results later. > >>>>>>>>> > >>>>>>>>>> Second, I have no idea what this will do. Are the equal signs > typos? > >>>>>>>> Used by custom code? > >>>>>>>>> This the url in my application, not solr params. That's the > query string. > >>>>>>>>> > >>>>>>>>>> What does “species=“ do? That’s not Solr syntax, so it’s likely > that > >>>>>>>> all the params with an equal-sign are totally ignored unless it’s > just a > >>>>>>>> typo. > >>>>>>>>> This is part of the application. Species will be used later on > in solr > >>>>>>>> to filter out the result. That's not solr. That my app params. > >>>>>>>>> > >>>>>>>>>> Third, the easiest way to see what’s happening under the covers > is to > >>>>>>>> add “&debug=true” to the query and look at the parsed query. > Ignore all the > >>>>>>>> relevance calculations for the nonce, or specify “&debug=query” > to skip > >>>>>>>> that part. > >>>>>>>>> The two json files i've sent, they are debugQuery=on and the > explain tag > >>>>>>>> is present. > >>>>>>>>> I will try the searching the way you mentioned. > >>>>>>>>> > >>>>>>>>> Thank for your inputs > >>>>>>>>> > >>>>>>>>> Guilherme > >>>>>>>>> > >>>>>>>>>> On 6 Nov 2019, at 14:14, Erick Erickson < > erickerick...@gmail.com <mailto:erickerick...@gmail.com>> > >>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> Fwd to another server > >>>>>>>>>> > >>>>>>>>>> First, your index and analysis chains are considerably > different, this > >>>>>>>> can easily be a source of problems. In particular, using two > different > >>>>>>>> tokenizers is a huge red flag. I _strongly_ recommend against > this unless > >>>>>>>> you’re totally sure you understand the consequences. > Additionally, your use > >>>>>>>> of the length filter is suspicious, especially since your problem > statement > >>>>>>>> is about the addition of a single letter term and the min length > allowed on > >>>>>>>> that filter is 2. That said, it’s reasonable to suppose that the > ’a’ is > >>>>>>>> filtered out in both cases, but maybe you’ve found something odd > about the > >>>>>>>> interactions. > >>>>>>>>>> > >>>>>>>>>> Second, I have no idea what this will do. Are the equal signs > typos? > >>>>>>>> Used by custom code? > >>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>> > https://dev.reactome.org/content/query?q=lymphoid+and+a+non-lymphoid+cell&species=Homo+sapiens&species=Entries+without+species&cluster=true > < > https://dev.reactome.org/content/query?q=lymphoid+and+a+non-lymphoid+cell&species=Homo+sapiens&species=Entries+without+species&cluster=true > > > >>>>>>>>>> > >>>>>>>>>> What does “species=“ do? That’s not Solr syntax, so it’s likely > that > >>>>>>>> all the params with an equal-sign are totally ignored unless it’s > just a > >>>>>>>> typo. > >>>>>>>>>> > >>>>>>>>>> Third, the easiest way to see what’s happening under the covers > is to > >>>>>>>> add “&debug=true” to the query and look at the parsed query. > Ignore all the > >>>>>>>> relevance calculations for the nonce, or specify “&debug=query” > to skip > >>>>>>>> that part. > >>>>>>>>>> > >>>>>>>>>> 90% + of the time, the question “why didn’t this query do what I > >>>>>>>> expect” is answered by looking at the “&debug=query” output and > the > >>>>>>>> analysis page in the admin UI. NOTE: for the analysis page be > sure to look > >>>>>>>> at _both_ the query and index output. Also, and very important > about the > >>>>>>>> analysis page (and this is confusing) is that this _assumes_ that > what you > >>>>>>>> put in the text boxes have made it through the query parser > intact and is > >>>>>>>> analyzed by the field selected. Consider the search > "q=field:word1 word2". > >>>>>>>> Now you type “word1 word2” into the analysis text box and it > looks like > >>>>>>>> what you expect. That’s misleading because the query is _parsed_ > as > >>>>>>>> "field:word1 default_search_field:word2”. This is where > “&debug=query” > >>>>>>>> helps. > >>>>>>>>>> > >>>>>>>>>> Best, > >>>>>>>>>> Erick > >>>>>>>>>> > >>>>>>>>>>> On Nov 6, 2019, at 2:36 AM, Paras Lehana < > paras.leh...@indiamart.com <mailto:paras.leh...@indiamart.com>> > >>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> Hi Walter, > >>>>>>>>>>> > >>>>>>>>>>> The solr.StopFilter removes all tokens that are stopwords. > Those words > >>>>>>>> will > >>>>>>>>>>>> not be in the index, so they can never match a query. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> I think the OP's concern is different results when adding a > stopword. I > >>>>>>>>>>> think he's using the filter factory correctly - the query chain > >>>>>>>> includes > >>>>>>>>>>> the filter as well so it should remove "a" while querying. > >>>>>>>>>>> > >>>>>>>>>>> *@Guilherme*, please post results for both the query, the > document in > >>>>>>>>>>> result you are concerned about and post full result of > analysis screen > >>>>>>>> (for > >>>>>>>>>>> both query and index). > >>>>>>>>>>> > >>>>>>>>>>> On Tue, 5 Nov 2019 at 21:38, Walter Underwood < > wun...@wunderwood.org <mailto:wun...@wunderwood.org>> > >>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> No. > >>>>>>>>>>>> > >>>>>>>>>>>> The solr.StopFilter removes all tokens that are stopwords. > Those words > >>>>>>>>>>>> will not be in the index, so they can never match a query. > >>>>>>>>>>>> > >>>>>>>>>>>> 1. Remove the lines with solr.StopFilter from every analysis > chain in > >>>>>>>>>>>> schema.xml. > >>>>>>>>>>>> 2. Reload the collection, restart Solr, or whatever to read > the new > >>>>>>>> config. > >>>>>>>>>>>> 3. Reindex all of the documents. > >>>>>>>>>>>> > >>>>>>>>>>>> When indexed with the new analysis chain, the stopwords will > not be > >>>>>>>>>>>> removed and they will be searchable. > >>>>>>>>>>>> > >>>>>>>>>>>> wunder > >>>>>>>>>>>> Walter Underwood > >>>>>>>>>>>> wun...@wunderwood.org <mailto:wun...@wunderwood.org> > >>>>>>>>>>>> http://observer.wunderwood.org/ < > http://observer.wunderwood.org/> (my blog) > >>>>>>>>>>>> > >>>>>>>>>>>>> On Nov 5, 2019, at 8:56 AM, Guilherme Viteri < > gvit...@ebi.ac.uk <mailto:gvit...@ebi.ac.uk>> > >>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> Ok. I am kind a lost now. > >>>>>>>>>>>>> If I open up the console > analysis and perform it, that's > the final > >>>>>>>>>>>> result. > >>>>>>>>>>>>> <Screenshot 2019-11-05 at 14.54.16.png> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Your suggestion is: get rid of the <filter stopword.txt> in > the > >>>>>>>>>>>> schema.xml and during index phase replaceAll("in > stopwords.txt"," ") > >>>>>>>> then > >>>>>>>>>>>> add to solr. Is that correct ? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks David > >>>>>>>>>>>>> > >>>>>>>>>>>>>> On 5 Nov 2019, at 14:48, David Hastings < > >>>>>>>> hastings.recurs...@gmail.com <mailto:hastings.recurs...@gmail.com > > > >>>>>>>>>>>> <mailto:hastings.recurs...@gmail.com <mailto: > hastings.recurs...@gmail.com>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Fwd to another server > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> no, > >>>>>>>>>>>>>> <filter class="solr.StopFilterFactory" > ignoreCase="true" > >>>>>>>>>>>>>> words="stopwords.txt"/> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> is still using stopwords and should be removed, in my > opinion of > >>>>>>>> course, > >>>>>>>>>>>>>> based on your use case may be different, but i generally > axe any > >>>>>>>>>>>> reference > >>>>>>>>>>>>>> to them at all > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Tue, Nov 5, 2019 at 9:47 AM Guilherme Viteri < > gvit...@ebi.ac.uk <mailto:gvit...@ebi.ac.uk> > >>>>>>>>>>>> <mailto:gvit...@ebi.ac.uk <mailto:gvit...@ebi.ac.uk>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks. > >>>>>>>>>>>>>>> Haven't I done this here ? > >>>>>>>>>>>>>>> <fieldType name="text_field" class="solr.TextField" > >>>>>>>>>>>>>>> positionIncrementGap="100" omitNorms="false" > > >>>>>>>>>>>>>>> <analyzer type="index"> > >>>>>>>>>>>>>>> <tokenizer class="solr.StandardTokenizerFactory"/> > >>>>>>>>>>>>>>> <filter class="solr.ClassicFilterFactory"/> > >>>>>>>>>>>>>>> <filter class="solr.LengthFilterFactory" min="2" > >>>>>>>>>>>> max="20"/> > >>>>>>>>>>>>>>> <filter class="solr.LowerCaseFilterFactory"/> > >>>>>>>>>>>>>>> <filter class="solr.StopFilterFactory" > ignoreCase="true" > >>>>>>>>>>>>>>> words="stopwords.txt"/> > >>>>>>>>>>>>>>> </analyzer> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On 5 Nov 2019, at 14:15, David Hastings < > >>>>>>>> hastings.recurs...@gmail.com <mailto:hastings.recurs...@gmail.com > > > >>>>>>>>>>>> <mailto:hastings.recurs...@gmail.com <mailto: > hastings.recurs...@gmail.com>>> > >>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Fwd to another server > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> The first thing you should do is remove any reference to > stop > >>>>>>>> words > >>>>>>>>>>>> and > >>>>>>>>>>>>>>>> never use them, then re-index your data and try it again. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Tue, Nov 5, 2019 at 9:14 AM Guilherme Viteri < > >>>>>>>> gvit...@ebi.ac.uk <mailto:gvit...@ebi.ac.uk> > >>>>>>>>>>>> <mailto:gvit...@ebi.ac.uk <mailto:gvit...@ebi.ac.uk>>> > >>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> I am performing a search to match a name (text_field), > however > >>>>>>>> this > >>>>>>>>>>>> term > >>>>>>>>>>>>>>>>> contains 'and' and 'a' and it doesn't return any > records. If i > >>>>>>>> remove > >>>>>>>>>>>>>>> 'a' > >>>>>>>>>>>>>>>>> then it works. > >>>>>>>>>>>>>>>>> e.g > >>>>>>>>>>>>>>>>> Search Term: lymphoid and a non-lymphoid cell > >>>>>>>>>>>>>>>>> doesn't work: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>> > https://dev.reactome.org/content/query?q=lymphoid+and+a+non-lymphoid+cell&species=Homo+sapiens&species=Entries+without+species&cluster=true > < > https://dev.reactome.org/content/query?q=lymphoid+and+a+non-lymphoid+cell&species=Homo+sapiens&species=Entries+without+species&cluster=true > > > >>>>>>>>>>>> < > >>>>>>>>>>>> > >>>>>>>> > https://dev.reactome.org/content/query?q=lymphoid+and+a+non-lymphoid+cell&species=Homo+sapiens&species=Entries+without+species&cluster=true > < > https://dev.reactome.org/content/query?q=lymphoid+and+a+non-lymphoid+cell&species=Homo+sapiens&species=Entries+without+species&cluster=true > > > >>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> < > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>> > https://dev.reactome.org/content/query?q=lymphoid+and+a+non-lymphoid+cell&species=Homo+sapiens&species=Entries+without+species&cluster=true > < > https://dev.reactome.org/content/query?q=lymphoid+and+a+non-lymphoid+cell&species=Homo+sapiens&species=Entries+without+species&cluster=true > > > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Search term: lymphoid and non-lymphoid cell > >>>>>>>>>>>>>>>>> works: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>> > https://dev.reactome.org/content/query?q=lymphoid+and+non-lymphoid+cell&species=Homo+sapiens&species=Entries+without+species&cluster=true > < > https://dev.reactome.org/content/query?q=lymphoid+and+non-lymphoid+cell&species=Homo+sapiens&species=Entries+without+species&cluster=true > > > >>>>>>>>>>>>>>>>> < > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>> > https://dev.reactome.org/content/query?q=lymphoid+and+non-lymphoid+cell&species=Homo+sapiens&species=Entries+without+species&cluster=true > < > https://dev.reactome.org/content/query?q=lymphoid+and+non-lymphoid+cell&species=Homo+sapiens&species=Entries+without+species&cluster=true > > > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> interested in the first result > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> schema.xml > >>>>>>>>>>>>>>>>> <field name="name" > type="text_field" > >>>>>>>>>>>>>>>>> indexed="true" stored="true" omitNorms="false" > >>>>>>>> required="true" > >>>>>>>>>>>>>>>>> multiValued="false"/> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> <analyzer type="query"> > >>>>>>>>>>>>>>>>> <tokenizer class="solr.PatternTokenizerFactory" > >>>>>>>>>>>>>>>>> pattern="[^a-zA-Z0-9/._:]"/> > >>>>>>>>>>>>>>>>> <filter class="solr.PatternReplaceFilterFactory" > >>>>>>>>>>>>>>>>> pattern="^[/._:]+" replacement=""/> > >>>>>>>>>>>>>>>>> <filter class="solr.PatternReplaceFilterFactory" > >>>>>>>>>>>>>>>>> pattern="[/._:]+$" replacement=""/> > >>>>>>>>>>>>>>>>> <filter class="solr.PatternReplaceFilterFactory" > >>>>>>>>>>>>>>>>> pattern="[_]" replacement=" "/> > >>>>>>>>>>>>>>>>> <filter class="solr.LengthFilterFactory" min="2" > >>>>>>>>>>>>>>> max="20"/> > >>>>>>>>>>>>>>>>> <filter class="solr.LowerCaseFilterFactory"/> > >>>>>>>>>>>>>>>>> <filter class="solr.StopFilterFactory" > >>>>>>>>>>>> ignoreCase="true" > >>>>>>>>>>>>>>>>> words="stopwords.txt"/> > >>>>>>>>>>>>>>>>> </analyzer> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> <fieldType name="text_field" class="solr.TextField" > >>>>>>>>>>>>>>>>> positionIncrementGap="100" omitNorms="false" > > >>>>>>>>>>>>>>>>> <analyzer type="index"> > >>>>>>>>>>>>>>>>> <tokenizer class="solr.StandardTokenizerFactory"/> > >>>>>>>>>>>>>>>>> <filter class="solr.ClassicFilterFactory"/> > >>>>>>>>>>>>>>>>> <filter class="solr.LengthFilterFactory" min="2" > >>>>>>>>>>>>>>> max="20"/> > >>>>>>>>>>>>>>>>> <filter class="solr.LowerCaseFilterFactory"/> > >>>>>>>>>>>>>>>>> <filter class="solr.StopFilterFactory" > >>>>>>>>>>>> ignoreCase="true" > >>>>>>>>>>>>>>>>> words="stopwords.txt"/> > >>>>>>>>>>>>>>>>> </analyzer> > >>>>>>>>>>>>>>>>> <analyzer type="query"> > >>>>>>>>>>>>>>>>> <tokenizer class="solr.PatternTokenizerFactory" > >>>>>>>>>>>>>>>>> pattern="[^a-zA-Z0-9/._:]"/> > >>>>>>>>>>>>>>>>> <filter class="solr.PatternReplaceFilterFactory" > >>>>>>>>>>>>>>>>> pattern="^[/._:]+" replacement=""/> > >>>>>>>>>>>>>>>>> <filter class="solr.PatternReplaceFilterFactory" > >>>>>>>>>>>>>>>>> pattern="[/._:]+$" replacement=""/> > >>>>>>>>>>>>>>>>> <filter class="solr.PatternReplaceFilterFactory" > >>>>>>>>>>>>>>>>> pattern="[_]" replacement=" "/> > >>>>>>>>>>>>>>>>> <filter class="solr.LengthFilterFactory" min="2" > >>>>>>>>>>>>>>> max="20"/> > >>>>>>>>>>>>>>>>> <filter class="solr.LowerCaseFilterFactory"/> > >>>>>>>>>>>>>>>>> <filter class="solr.StopFilterFactory" > >>>>>>>>>>>> ignoreCase="true" > >>>>>>>>>>>>>>>>> words="stopwords.txt"/> > >>>>>>>>>>>>>>>>> </analyzer> > >>>>>>>>>>>>>>>>> </fieldType> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> stopwords.txt > >>>>>>>>>>>>>>>>> #Standard english stop words taken from Lucene's > StopAnalyzer > >>>>>>>>>>>>>>>>> a > >>>>>>>>>>>>>>>>> b > >>>>>>>>>>>>>>>>> c > >>>>>>>>>>>>>>>>> .... > >>>>>>>>>>>>>>>>> an > >>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>> are > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Running SolR 6.6.2. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Is there anything I could do to prevent this ? > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Thanks > >>>>>>>>>>>>>>>>> Guilherme > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> -- > >>>>>>>>>>> -- > >>>>>>>>>>> Regards, > >>>>>>>>>>> > >>>>>>>>>>> *Paras Lehana* [65871] > >>>>>>>>>>> Development Engineer, Auto-Suggest, > >>>>>>>>>>> IndiaMART Intermesh Ltd. > >>>>>>>>>>> > >>>>>>>>>>> 8th Floor, Tower A, Advant-Navis Business Park, Sector 142, > >>>>>>>>>>> Noida, UP, IN - 201303 > >>>>>>>>>>> > >>>>>>>>>>> Mob.: +91-9560911996 > >>>>>>>>>>> Work: 01203916600 | Extn: *8173* > >>>>>>>>>>> > >>>>>>>>>>> -- > >>>>>>>>>>> IMPORTANT: > >>>>>>>>>>> NEVER share your IndiaMART OTP/ Password with anyone. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> -- > >>>>>>> Regards, > >>>>>>> > >>>>>>> *Paras Lehana* [65871] > >>>>>>> Development Engineer, Auto-Suggest, > >>>>>>> IndiaMART Intermesh Ltd. > >>>>>>> > >>>>>>> 8th Floor, Tower A, Advant-Navis Business Park, Sector 142, > >>>>>>> Noida, UP, IN - 201303 > >>>>>>> > >>>>>>> Mob.: +91-9560911996 > >>>>>>> Work: 01203916600 | Extn: *8173* > >>>>>>> > >>>>>>> -- > >>>>>>> IMPORTANT: > >>>>>>> NEVER share your IndiaMART OTP/ Password with anyone. > >>>>>> > >>>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> -- > >>> Regards, > >>> > >>> Paras Lehana [65871] > >>> Development Engineer, Auto-Suggest, > >>> IndiaMART Intermesh Ltd. > >>> > >>> 8th Floor, Tower A, Advant-Navis Business Park, Sector 142, > >>> Noida, UP, IN - 201303 > >>> > >>> Mob.: +91-9560911996 <tel:+91-9560911996> > >>> Work: 01203916600 | Extn: 8173 > >>> > >>> IMPORTANT: > >>> NEVER share your IndiaMART OTP/ Password with anyone. > > > >
