Dot Net Mafia

Group site for developer blogs dealing with (usually) .NET, SharePoint 2013, SharePoint 2010, Office 365, SharePoint Online, and other Microsoft products, as well as some discussion of general programming related concepts.

No metadata? No problem! Custom entity extraction in SharePoint 2013

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 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.

Key,Display form

bcs,Business Connectivity Services

Business Connectivity Services,Business Connectivity Services

wcm,Web Content Management

Web Content Management,Web Content Management

bi,Business Intelligence

Business Intelligence,Business Intelligence

ecm,Electronic Content Management

Electronic Content Management,Electronic Content Management

Apps,Apps

Analytics,Analytics

Development,Development

Service Application,Service Application

Excel Services,Excel Services

Office Web Apps,Office Web Apps

owa,Office Web Apps

wac,Office Web Apps

PerformancePoint,Business Intelligence

Search,Search

Social,Social

My Sites,My Sites

Communities,Social

Visio Services,Visio Services

Workflow,Workflow

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.

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. :)

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.

nh
said:

Great post, but i cannot help thinking with one question, this seems that instead of spending effort on Managed Metadata Service Toxonomy, one should focus on entity extraction, which will (with a big question mark) put an end to MMS, as no end user wants to tag.

I know if we can have both taxonomy tagging and entity extration, the world is perfect. But if we would only choose one, entity extration is the winner, can you please comment?

@nh good comment. Entity extraction will never be a replacement for properly tagging your documents with MMS or any other type of site columns. It's just a stop-gap to help you otherwise-unclassified documents. Think about it which would you rather have. Inferred classification or exact classification where your users took the time to set the values? You can definitely use them together though when it makes sense.

Martin
said:

Hi Corey,

Any idea how all this relates to the "Search Dictionaries" option we see in the term store, where we can import a custom term set?

I've worked with the PowerShell import approach you outlined but I see great potential benefit in using the term store option *instead*. To be more specific, my client has a number of well-maintained term sets that could serve as dictionaries directly. So I *pin* from those into a new term set under Search Dictionaries. Sounds like a match made in heaven - no need to keep updating and re-importing dictionaries. But I can't figure out how to get a search refiner to reference that term set dictionary - no obvious way to map it to a managed property.

@Uday check the ULS logs to find out what the problem is. More than likely there is an issue with your CSV file. Make sure it is in CSV format and not Excel.

November 4, 2013 4:11 PM

John J
said:

HI Corey... I am successfully able to get the entity extraction working with OOB properties such as Title and Body. But not able to do the same for custom properties created for SharePoint custom metadata columns. The SP site resides in SP 2010 and I am crawling in SP 2013.

Is there any steps that needs to be done for custom properties? Thanks in advance.

The problem you found with the dictionary name has a simple solution. Simply hit the TAB key after typing the -DictionaryName parameter. The Autocomplete feature will show all possible values, without the risk of mispelling.

April 6, 2014 4:17 PM

Keren Tsur
said:

Can i search for the entities also in Path of the file? (not the full text). In case so - which managed property to map?

@Keren I have tried to get that to work by using the path property but I have been unsuccessful. It doesn't appear to work.

May 28, 2014 9:17 AM

Aditya
said:

Hi Corey,

Thanks for the article.I have a site with some documents which are not tagged and i am using Custom entity extractor i.e Location.csv.I have created managed metadata column "Location" so that the users can tag the new documents with metada.Issue is if I use both the refiners then the values for refiners are repeating which is causing confusion .How should I use both the refiners for same set of metadata?

As you rightly pointed, this is not a replacement for MMS but this perticular feature will be useful for existing sites with tons of documents without proper metadata tagging in place.

Thanks for sharing this!

July 4, 2014 6:56 AM

Richard
said:

@Martin -- I'd like to know the answer to this too. Once a dictionary has been imported via powershell, does it appear in the Search Dictionaries node in the term store like campany name? If so, this would imply that the dictionary can be managed via the term store from then on rather than having to re-import the text file via a cmdlet.

@Richard unfortunately no, it does not appear in the term store. If you need to make an update you have to run the script again.

September 8, 2014 1:51 PM

Maria
said:

Great Post!

I have a question. Can I get the refiners to be prepopulated on a page prior to searchin? For example - If I select "People" search, refiners such as business unit,designation etc should be pre-populated so that the user can select a business unit and see all the people in that unit. Hope its clear. Thanks.

October 7, 2014 12:51 AM

Chris
said:

Great post Corey.

I am trying to import the dictionary file but I received the following error: