Corey Roth [MVP]

Every organization wants better search results.  However, few have actually spent the time to create file plans, content types, and managed properties to make it happen.  SharePoint 2013 has a feature called entity extraction though that can actually infer values by comparing what it finds in the body of the document to a dictionary.  This feature is Entity Extraction.  If you are familiar with FAST Search for SharePoint or FAST ESP, you know that entity extraction is nothing new.  What it does is gives you the power to infer the values of managed properties in search without having metadata in your site columns.  FS4SP and SharePoint 2013 come with an extraction dictionaries for company names out-of-the-box.  This means when it crawls it will search the contents of the body of your documents and if it recognizes any companies it knows, you can then search and refine on it.  However, the true value comes when you create your own.  SharePoint 2013 makes it really easy to create these custom dictionaries. 

Let me give you a few more examples to help you really understand the significance.  Most companies have a concept of a department or business unit.  We can create a dictionary with all of the company’s departments such as Accounting, Human Resources, IT, Operations, etc.  With entity extraction, if it finds a document and somewhere the text “Human Resources Organization Chart” is found, it then sets the value of the managed property to Human Resources.  Now, when the user does an advanced search and says “show me all Human Resources documents”, that result comes back with more confidence.  By using the extraction dictionary, we get better results that just using a regular keyword search.  Now you may be wondering that’s nothing special, but we can also add other terms, for example, I could add “HR”, and “Benefits” to that dictionary as well and map them to the Human Resources department.  Once I have a property defined like this, I can combine it with others as well.  This will let us issue queries like “show me all documents from Human Resources with a document type of Policy”. 

As another example, you could pre-load SharePoint with a dictionary of product names.  For those of you in the energy industry, you could pre-populate it with a list of wells or names of leases.  Are you starting to see the significance?  In previous versions of SharePoint, we had to set site columns in our document libraries to capture these values either from the user or programmatically.  Now with the right dictionary, we can assume the values with a reasonable degree of confidence.

Alright, enough explanation, let’s see this in action and hopefully it will make sense.  MSDN has a great post on this but I found and error in it so that is why I am writing this post (plus I know you all like screenshots).  For my example, I have a bunch of PowerPoint documents about SharePoint 2013 on my site.  I’ve created a custom entity extraction dictionary that will help me refine these documents by feature in SharePoint (i.e.: Apps, Business Intelligence, Search, Social, etc). 

Before you build your dictionary file though, you need to decide on what type of extraction to use.  You can choose whether you want it to match a word or just part of it.  You can also specify whether it needs to match exactly.  The MSDN article summarizes this well, but here’s a quick recap of your choices.

• Word Extraction – case-insentive, word has to match, limited to 5 dictionaries
• Word Part Extraction – case-insensitive, only part of a word has to match, limited to 5 dictionaries
• Word Exact Extraction – case-sensitive, word has to match, limited to 1 dictionary
• Word Part Exact Extraction – case-sensitive, only part of a word has to match, limited to 1 dictionary

For today’s example, I am going to use Word Part Extraction as it gives you some of the most flexibility.  You might want to use Word Exact Extraction for extracting IDs from a document.  For example, you could use it to extract part numbers or invoice numbers.  Those aren’t something you would typically want to refine on but you may want to query on them.  FAST Search for SharePoint only provided case-sensitive extraction.  This made the feature less useful as you had to accommodate all possible varieties of case combinations in your dictionary file.

To get started, we need to create a dictionary file. I started with notepad and I also edited with Excel some.  The format is simple “Key,Display form”.  The key is what the crawler matches in the body of the document and the Display form is what gets displayed in the refiner.  Although the Display form is optional, you want to include it as it allows you to control the exact way the text looks in the refiner (including case sensitivity).  Here’s the dictionary file I created.

The next step is to use the PowerShell command, Import-SPEnterpriseSearchCustomExtractionDictionary.  The documentation on this page is correct which is how I found the solution to my problem.  The first step is to get a reference to the Search Service Application using Get-SPEnterpriseSearchServiceApplication.  Then for our import command, we pass the service application, the Filename, and the DictionaryName.  Here’s where the complexity comes in.  The Filename requires a UNC path.  That means something like \\servername\path\file.csv.  It won’t take a relative path.  The next tricky part is where I found an issue in the documentation.  I wanted to use the Word Part extraction, it has the case of the word “WordPart” incorrect in the dictionary name.  If you do specify the DictionaryName wrong, it will not work.  Here are the list of valid values which correspond to the extraction types we talked about above.

• Microsoft.UserDictionaries.EntityExtraction.Custom.Word.n [where n = 1,2,3,4 or 5]
• Microsoft.UserDictionaries.EntityExtraction.Custom.ExactWord.1
• Microsoft.UserDictionaries.EntityExtraction.Custom.WordPart.n [where n = 1,2,3,4 or 5]
• Microsoft.UserDictionaries.EntityExtraction.Custom.ExactWordPart.1

For the non-exact entries, you need to specify a value at the end (1 – 5) which specifies which extraction dictionary it uses.  In the case below, I did number 2 since I already messed up number 1 by specifying the dictionary name incorrectly. :)

$searchApp = Get-SPEnterpriseSearchServiceApplication

Import-SPEnterpriseSearchCustomExtractionDictionary –SearchApplication $searchApp –Filename \\server\c$\folder\WordPartExtraction.csv –DictionaryName Microsoft.UserDictionaries.EntityExtraction.Custom.WordPart.2

When you run the commands, it will look like this.  I put the above in a script file for convenience.

The next part I believe is a little different than the way you did it with FAST Search for SharePoint.  What you need to do is tell search which managed properties to perform entity extraction.  Effectively, what we are doing here is telling search to look at the body of the document and see if anything in there matches items in the dictionary.  To do this, go to your Search Service Application –> Search Schema and edit the property named body. 

Scroll to the bottom and you will see the Custom entity extraction section.  Now, we just need to check the box next to the dictionary we want to use.  In my case, it is Word Part Extraction – Custom2.  If you have multiple dictionaries you may select them here.  Save the managed property after you make your selection.

After you save, you need to start a full crawl on your content source, typically Local SharePoint sites. 

When this finishes, we can now begin to use our new extracted entities in our search center.  The first thing we want to do is add this new extraction to the Refinement web part so that users can refine results by SharePoint feature.  Go to your Search Center and issue a query that is going to get you some results that you know you can refine on.  In my case, I typed the word SharePoint since I knew all of my documents were related to that.  Once you get search results, edit the page.  Then on the left side, edit the Refinement web part.  Now, click the Choose Refiners button. 

This page will list all managed properties marked for refinement.  What’s really nice is that when you click on a managed property, it gives you a preview of the available refiners.

In the list of available refiners, I select WordPartCustomRefiner2.  Below, you see a list of Sample values and the number of times it found a match.  To configure the property, select it and click the Add button.  I also added this new refiner up to the top since I want users to see it first.

Now, I gave it a Display name and you have the option to choose a different Display template as well as how it is sorted.  You can actually customize how the refiner is rendered on the page with the display template too but that’s outside of the scope of today’s post.  At the bottom of the page there is also a Preview button.  Click on it and you will see what your search results look like before you even save the page.

If you’re happy with the way the refiners look, save the page, check it in, and publish it.  Now issue a query.  I am going to use the same one from before.

As you can see, we now see a list of the SharePoint features that we specified in our dictionary.  Let’s try a few refiners.  Let’s start by selecting Electronic Content Management.  I do know that should it read Enterprise, but it was after midnight when I started working on this. :)

Notice, that in the results, that Word Document 3 comes back and you see “ECM” in it.  That’s the only text in the document and it matched it to that feature since we defined it in the dictionary.  Now let’s try Business Connectivity Services.

It returns several slide decks this time because it mentions it in the Intro deck, the BCS deck, UPS, etc.  I’m not sue how Visio Services made a hit to it, but maybe there is something new I need to learn. :)

You can also select multiple refiners.  In this case, I selected Apps and Web Content Management.

By now, I am hoping you are seeing the power of entity extraction.  It gives you a new level of classification on documents and the users never had to tag anything manually at all. 

You can issue queries with these dictionaries as well too.  For example, if I want to search for anything tagged with Apps, I would issue the following query.

WordPartCustomRefiner2:"Apps"

I hope after reading this post, it has got you started thinking.  Most organizations have next to no metadata on their documents.  This isn’t a replacement for taking the time to classify your documents properly with site columns and content types.  Inferring metadata will never be as good as the users taking the time to classify the documents themselves.  However, it is a great stop-gap in dealing with all of that untagged content you have. 

I think this is one of the most significant feature in SharePoint 2013 that most people will probably never use.  :(  Take the time to set up a few dictionaries and you are going to get immediate value out of search and your users are going to notice.