We are using MarkLogic 7.0-4. We are facing a problem with proximity search, with wildcard terms inside specified elements.
The query looks like following:
cts:near-query(
(
cts:element-word-query(xs:QName("abstract"), "microf*)",
("case-insensitive","diacritic-insensitive","punctuation-insensitive",
"whitespace-sensitive","unstemmed","wildcarded","lang=en"), 1),
cts:element-word-query(xs:QName("abstract"), "transplant*)",
("case-insensitive","diacritic-insensitive","punctuation-insensitive",
"whitespace-sensitive","unstemmed","wildcarded","lang=en"), 1)
), 2, (), 1)
We are running unfiltered. It's supposed to return documents having the wildcard terms within specified elements. Although currently no document matches the query, a document is being returned. Apparently the document is a match because it has an element, not among the specified ones, which has the wildcard terms within the given distance.
Among the related index settings we have the following one enabled:
element word positions,
fast element phrase searches,
three character searches,
three character word positions,
fast element character searches,
fast element word searches,
trailing wildcard searches,
trailing wildcard word positions,
fast element trailing wildcard searches
Sample data to reproduce:
xdmp:document-insert(
'/questions/33865927-1.xml',
<root>
<abstract>microfoo blah blah blah blah transplantbar</abstract>
</root>
)
I added the word positions index and the false positive went away.
You have element word positions turned on. I suspect that only stores where terms are related to the containing element, rather than location in the document overall (don't quote me on that). For this query, even when I turned off element word positions I got the right answer, as long as word positions was on.
Related
I currently use Typesense to search in an HTML database. When I search for a term, I would like to retrieve N characters before and N characters after the term found in search.
For example, I search for "query" and this is the sentence that matches:
Let's repeat the query we made earlier with a group_by parameter
I would like to easy retrieve a fixed number of letters (or words) before and after the term to show it in a presumably small area where the search results is retrieved, without breaking any words.
For this particular example, I would be showing:
..repeat the query we made earlier..
Is there a feature like this in Typesense?
I have checked Typesense's documents, without any luck.
The feature you're referring to is called snippets/highlights and it's enabled by default. You can control how many words are returned on either side of the matched text using the highlight_affix_num_tokens search parameter, documented under the table here: https://typesense.org/docs/0.23.1/api/search.html#results-parameters
highlight_affix_num_tokens
The number of tokens that should surround the highlighted text on each side. This controls the length of the snippet.
I created an ArangoSearch view over a collection and am using the SEARCH keyword with wildcards w/ LIKE to search a field with spaces, similarly to how MySQL would. The problem I am running in to is, I keep getting an empty set even though records with the Star Wars title definitely exist.
Note, searching for '%star%' works and returns results... as soon as I add a space and search for '%star wars%' the query returns empty set.
This is the query
FOR d IN imdb_norm
SEARCH ANALYZER(d.name LIKE "%Star Wars%", "text_en")
RETURN d.name
This is the structure, running arango version 3.7.2
The thing is since you're using text_en, it breaks up strings into individual words Since all spaces are considered as break characters, there is not a single term (a word stored in aragnosearch index) containing a whitespace.
If you don't need tokenization, please can consider indexing a word as it is (i.e. without case conversion, accent removal, etc) using identity analyzer, or check out norm analyzer instead.
https://www.arangodb.com/docs/stable/arangosearch-analyzers.html#analyzer-types
I've made an azure search service and it's up and working. I would like for users to be able to search with 3 characters or more.
I have the following texts in different documents:
Paracet 200mg
Paracet 150mg
Kodein/paracetamol SA
When I search for 'par' I get no results. I have to type 5 characters (parac) and I get 1 & 2 as a result. I want this result for 'par' as well. Is this possible? I can't find anything in the documentation on setting the required number of characters for a search.
For the best performance, you could enable the "fast" prefix analyzer in your index, which will break down every token into a list of prefixes at indexing time. Here's some additional information on how to do that : https://azure.microsoft.com/en-us/blog/custom-analyzers-in-azure-search/
This would require you to re-index your data, so if you are creating a brand new index, this is an option.
If re-indexing is not an option, you can instead use the suffix operation '*' in your query. Here's more information on the suffix operator : https://learn.microsoft.com/en-us/rest/api/searchservice/Simple-query-syntax-in-Azure-Search?redirectedfrom=MSDN
I suspect searching using the suffix operator (or re-indexing while using fast prefix analyzer) will also work with the 3rd document you listed (Kodein/paracetamol SA). If it still does not work, it might be due to you using a tokenizer that does not split on the '/' character. The default analyzer should correctly split on '/', but if you are using a custom analyzer it's possible the whole "Kodein/paracetamol" expression get tokenized into a single term, which would explain why a search for parace* does not return the document, since the prefix of the document is "kode…".
My ElasticSearch index is not correctly indexing and querying non-alphanumeric characters. Specifically, dots and dashes are causing problems.
If I index a document with the name "O.K. Corral," it should match queries for "OK Corral". Similarly, if I index "Whiskey A Go-Go," I'd like it to match "Whiskey A GoGo" and "Whiskey A Go Go".
Right now, only queries with the correct dots and dashes will return these documents.
I'm hoping the solution will also solve any potential problems with other non-alphanumeric characters, like commas and apostrophes.
It sounds like a job for ElasticSearch token filters, but I haven't been able to find one that does what I'm looking for. Also, I would like to do this within ElasticSearch -- I don't want to write custom string manipulations to normalize data before it gets to my ES index.
Thanks for your help!
You might want to have a look at the Word Delimiter Token Filter. It will at least do what you want with "Whiskey A GoGo" and "Whiskey A Go-Go,". You can check its behaviour in advance using the analyze api.
I have stemming enabled in my Solr instance, I had assumed that in order to perform an exact word search without disabling stemming, it would be as simple as putting the word into quotes. This however does not appear to be the case?
Is there a simple way to achieve this?
There is a simple way, if what you're referring to is the "slop" (required similarity) as part of a fuzzy search (see the Lucene Query Syntax here).
For example, if I perform this search:
q=field_name:determine
I see results that contain "determine", "determining", "determined", etc.. If I then modify the query like so:
q=field_name:determine~1
I only see results that contain the word "determine". This is because I'm specifying a required similarity of 1, which means "exact match". I can specify this value anywhere from 0 to 1.
Another thing you can do is index the same text without stemming in one field, and with stemming in another. Boost the non-stemmed field & that should prefer exact versions of words to stemmed versions. Of course you could also write your own query parser that directs quoted phrases to the non-stemmed field only.