I have setup a search scope for the current members of a website (a "Phone book" type of search). It is setup to automatically suggest limiting search results by people's jobtitles, adding something like "jobtitle:Manager" to the search query.
For single words ("Manager", "Supervisor", etc.) this works fine, but as soon as the title contains more than one word ("Managing Supervisor"), it returns zero search results. My gut feeling is that it's because when the url is entered as jobtitle:Managing Supervisor, it limits results by jobtitle = Managing, and then Supervisor simply becomes a generic search term.
I tried testing with manually added quotation marks, jobtitle:"Supervising Manager", but they are removed when I land on the search page and the effects are the same.
Is there any way to allow limiting of search results by fields with multiple words?
This is running SharePoint 2007.
Did you try adding a + between the words?
Related
I'm using OpenSearchServer to provide search functionality on a web site. I want to crawl all pages on the site for links to follow but I want to exclude some pages from the index. I can't work out how to do this.
Specifically the website includes a shop that has its own product search and I am keeping this search for products and categories. The product pages have URLs like http://www.thesite/p/123 so I don't want to include any page like this in the search results. However some product pages reference background info pages and I want these to be included in the search index.
The problem I have is that the filter has no effect on the results - it doesn't filter out the /p/ and /c/ results. If I change the filter by unticking the negative box I get no results so it seems to be either the contents of the field or the filter criteria that is causing the problem.
I've tried adding a negative filter to the default query called search in the Query > Filter tab on the index with url:"http://www.thesite/p/*"
but it seems that wildcards are not supported for query filters although they are supported for Crawler > Exclusion list filters.
I've tried adding a new field called urlField in Schema > Fields and populating it using an analyzer configured using the Whitespace Tokenizer and a regular expression (http://www.thesite/(c|p)/). When I use the Test button it seems to generate two tokens for my test URL http://www.thesite/p/123:
http://www.thesite/p/
p
I'd hoped to be able to use the first one in a Query > Filter to exclude all the shop results and optionally be able to use the p (for product) or c (for category) if I need to search the product pages sometime in the future.
The urlShop field in the schema is set up as follows:
Indexed: yes
Stored: no (because I don't need the field back, just want to be able to filter on it)
TermVector: No
Analyzer: urlShop
Copy of: url
I've added urlFilter:"http://www.thesite/p/" to Query > Filters with the negative box ticked.
This seems to have no effect on the results when I use the default renderer.
To see whether it affects the returned results I unticked the negative box in the query filter I get no results in the default renderer. This leads me to believe that the urlShop field is not being populated but I'm not sure how to check this directly.
I would like to know whether there is an easier way to do this but if my approach makes sense in the context of OpenSearchServer please can you help me identify what's wrong?
The website is running under IIS and OpenSearchServer will be configured on the same server running in Tomcat.
Finally figured this out...
Go to query and hit edit for your configured query. Then go to the filters tab. Add a query filter like this:
urlExact:"http://myurltoexclude*"
Check the "negative" box. Click add.
Now make sure to click "save in the tiny little button on the right hand side. This is the part I missed. The URLS are still in the DB and crawl, but at least they aren't returned in results.
We have a website where users put up ads for stuff they want to sell, with parameters such as price, location, title and description. These can then be searched for using sphinx and allowing users to specify min- and maxprice, a location with a searchradius (using google maps) etc. Users can choose to save these searches and get emails when new ads appear that fit their search. Herein lies the problem: We want to perform a reverse search every time an ad is posted. With the price, location, title and description as parameters we want to search through all the saved "searches" and get the ones that would have found the ad. The min- and maxprice should just be performed in a query i suppose, and some Quorom syntax to get all ads with at least 2 or mby just 1 occurance in the title/description. Our problem lies mostly in the geo-search. How do we find all searches where the "search-circles" would include our newly posted location without performing a search for every saved search?
That is the main-question, any comment on our suggested solution to the other problems is also very welcome. Thank you in advance / Jenny
The standard 'geo-search' support on sphinx should work just as well on a Prospective Index, as a normal retrospective search.
Having built a sphinx 'index' of all the saved searches...
And you run a query using the 'ad' as the search query:- rather than the 'filter' using a fixed radius, you just use the radius from the attribute (ie the radius stored on the particular query) - if using the API cant use setFilterRange directly, need to use setSelect, to make a new virtual attribute.
$cl->setSelect("*,IF(#geodist<radius,1,0) as myfilter");
$cl->setFilter('myfilter',array(1));
(and yes, the min/maxprice can just be done with normal filters too - just inverting the logic to that you would use in a retrospective search)
... the complication is in the 'full-text' query, if the saved search is anything more than a single keyword, but you appear to have already figured out that part.
I have one issue which I am in desperate need for your help. I am on Magento ver. 1.6.1.0, whenever I am searching with a sentence like "baby's cute shoes" in magento then the results are not accurate but when I search only a word like "cute" or "shoes" then it gives me the result.
I have a feeling that magento is not able to search a sentence but it is able to search products with words. Is there anything I can do to better optimize the search in magento?
The options for search can be found in the backend under System > Catalog > Catalog search, you probably have search type set to LIKE. You will potentially get better results using FULLTEXT mode.
Magento does not search the entered string as a full sentence. Instead it splits (tokenizes) your search string into words and will search for products containing ANY of these words (implementing "OR" logic). So if you are searching for "red shoes", it will find everything containing words "red" OR containing words "shoes". Obviously it is not very useful in most cases as it will produce a lot of totally irrelevant results.
You can check this free extension to refine your search: Catalog Search Refinement FREE. This extension modifies the search behavior to only find the products that have ALL keywords ("AND" logic in other words). This will find only products that have both "red" and "shoes" keywords. There is also Advanced Search version of that extension that also looks up for similar words based on phonetic distance among other things as well as weighted search attributes, allowing to bubble up the most relevant products.
I got my issue resolved by this link - https://stackoverflow.com/questions/1953715/magento-search-not-returning-expected-results
I went to this line in app/code/core/Mage/CatalogSearch/Model/Resource/Fulltext.php
and did this (below)
copy app/code/core/Mage/CatalogSearch/Model/Mysql4/Fulltext.php to app/code/local/Mage/CatalogSearch/Model/Mysql4/Fulltext.php
line 341 - 343 app/code/local/Mage/CatalogSearch/Model/Mysql4/Fulltext.php
if ($like) {
$likeCond = '(' . join(' OR ', $like) . ')';
}
change into
if ($like) {
$likeCond = '(' . join(' AND ', $like) . ')';
}
Also make sure to change the order in which the results are shown. Default Magento is to serve it backwards.
Add the following to /app/design/frontend/default/default/layout/catalogsearch.xml
<reference name="search_result_list">
<action method="setDefaultDirection"><string>asc</string></action>
<action method="setDefaultOrder"><string>relevance</string></action>
</reference>
Between the following:
<catalogsearch_result_index translate="label">
...
</catalogsearch_result_index>
Stock Magento search needs a few tweaks to get it functional. The Like search was changed from AND logic to OR logic in 1.5/1.6 and gives better results when reverted back to AND logic. This has been solved in several threads over in the Magento forums on Magento's website. Another fix is to to chop the s off of plurals which is also addressed over there.
The reason for cutting trailin "s" is that most people don't search for "an oil pressure gauge", but "oil pressure gauges" which gives total misses when you're selling a "0-100 psi Oil Pressure Gauge". Also alias all items ending in "ies" to their singular. Rarely do you sell an "rc aircraft batteries", it will be specific like "1200aH aircraft battery" and so your less savvy customer's searches never match.
"Baby's cute shoes" will never register a hit unless it shows up in the items you use to populate the Fulltext search index. Who sells an item called "baby's cute shoes" anyway? I usually synonym these types of searches to hit a specific category where the items are listed. Some customer searches are just too subjective to match the objective nature of product search (actual items vs. nebulous idea).
Have a bit of a difficult question which as far as I can see, no one has really managed to fix yet.
Here's the scenario. Sharepoint 2010 EnterPrise Search Centre.
I've created a custom Search Results Page. I want people who type any word in the Search box to only display results where the Value provided by the user matches with a specific Managed Search Property.
Now I know a user can search for People with specific criteria by entering for example
Continent:Europe in the actual Search Box. Sharepoint will refresh the page with the following added to the Query String: k=Continent:Europe and the results will only show people who are from Europe.
So my question is : How can I fix this so that the user does not have to enter the Continent:Europe in the Search box and can just type Europe?
Thanks
One option is to create your own webpart that acts as the search box and replaces the standard one with your custom search box. The advantage of this is that you can more tightly control the user interface and then set up the query passed to the server (with the "k" parameter). You could prepend "Continent:" before the search term entered to help narrow the search.
Another use for this is to append * onto any search term because the People search does include partial words by default.
We did this on one site to simplify the input and allow users to search with one text box (without the advanced features) and then users can use the refinements to narrow the search.
I'm storing information about local "events". They are described by 3 things - address, date, keywords(tags). I want to have only one search box for at least address and keywords. The date might go to a separate field. I'm assuming that most people will search for events that are taking place "today" so this filter won't get that much traffic.
I need those addresses to be correct (because I'm geocoding them afterwards) so I need to validate them before submitting the form and display a list of "did you mean" if a user made a typo there. I can't do life search here. I can do a live search on keywords. Keep in mind that a user can make a typo there too and I want to catch that.
Is there a clever way to design the input's parser in this case to guess which is supposed to be address and which keywords?
OR
Is there a way to actually parse it as user is entering his query? Maybe I should show autocomplete hints for keywords, after 3 first characters are entered, and if user denies to use them then to assume that it's a part of an address he's typing.
What do You think?
Take a look at Document Cloud's Visual search
http://documentcloud.github.com/visualsearch/#demo