I was a little disappointed with some aspects of how FAST was bolted on to SharePoint 2010. We had a fantastic new search engine but its capabilities were throttled by the depth of integration with SharePoint. One aspect of this was access to the power of the FAST Query Language (FQL).
FQL is a rich language designed specifically to access the full capability of the FAST search engine. In the FAST scenario, an end-user or developer would express their search query using Keyword Query Language (KQL) which would then be processed and executed against FAST. The disappointing aspect for any developer was that we could see the richness and power of FQL but were limited by the capabilities of KQL unless we were prepared to do a significant amount of custom development (e.g. write our own version of the CoreResultsWebPart from scratch).
A lot of my recent search experience has been in the legal industry helping attorneys find work product documents, court opinions and memos etc. Attorneys are busy people and their time is very valuable. The faster we can help them find their document the more productive they can be and the faster they can respond to their client. Working with attorneys I am frequently asked “why can’t our search be more like WestLaw?”. When I dug a little deeper I found that features of the WestLaw search syntax like proximity searching were very important for searching legal documents.
SharePoint 2010 Keyword Query Language (KQL) did have a NEAR operator but it was fixed at an implied 8 token distance. Typically I found that attorneys wanted to search very specific distances in order to find specific legal phrases. Whilst this was technically possible in FQL and FAST the only way to access it was to start writing our own custom search WebParts from scratch.
I am delighted to see that in SharePoint 2013 we have some major upgrades to Search. In my opinion, we are now really unlocking the capability of the FAST technology and making it much easier to access from the SharePoint user interface.
In SharePoint 2013, KQL gets an upgrade and we get a lot closer to the capability of FQL. The NEAR operator now has an optional parameter specifying proximity e.g.
“motion” NEAR(n=5) “dismiss”
Would find results where “motion” was within 5 tokens of “dismiss”. NEAR preserves the order of the tokens i.e. “motion” must appear before “dismiss”. To disregard order, there is also an ONEAR operator which works in the same way but ignores order.
Another example of KQL improvement is the inclusion of the XRANK operator. This was previously only available in FQL but we now get it in KQL too. e.g.
(lawyer OR attorney) XRANK(cb=100) delaware
Matches “lawyer” or “attorney” but also boosts the results which contain “delaware” by the constant rank boost of 100 i.e. we are looking for a “lawyer” or “attorney” but we are specifically interested in one who has something to do with “delaware”. There are other types of boosting using XRANK, this is a simple example, but the inclusion of XRANK in KQL is great news and is potentially very powerful.
So KQL is now a lot closer to FQL and will allow an end-user or developer to be more expressive and precise with their query. However, should a developer need to use FQL it is now a little more accessible via the new REST API using the enablefql parameter.
SharePoint 2013 Search Series:
SharePoint 2013 Search Part 1 – What happened to FAST?
SharePoint 2013 Search Part 2 – Richer Query Language
SharePoint 2013 Search Part 3 – User Experience and WebParts
SharePoint 2013 Search Part 4 – Search Result Customization
SharePoint 2013 Search Part 5 – Search-based Solutions
SharePoint 2013 Search Part 2 – Richer Query Language
by Chris Hines on November 1st, 2012 | ~ minute read
