in

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.

This Blog

Syndication

Archives

Corey Roth [MVP]

A SharePoint MVP bringing you the latest time saving tips for SharePoint 2013, Office 365 / SharePoint Online and Visual Studio 2013.

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

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.

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

SearchImportCustomEntityExtractorPowerShell

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

ManagedPropertiesBody

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.

ManagedPropertyCustomEntityExtraction

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. 

RefinementWebPartProperties

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.

CustomEntityExtractionRefinerProperties

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.

CustomEntityExtractionRefinerProperties2

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.

CustonEntityExtractionRefinementPreview

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.

CustomEntityExtractionSearchResultsDefault

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

CustomEntityExtractionSearchResultsECM

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.

CustomEntityExtractionSearchResultsBCS

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.

CustomEntityExtractionSearchResultsCombined

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"

CustomEntityExtractionSearchResultsQuery

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.

Comments

 

My SharePoint links January 8, 2013 | Jeremy Thake's musings said:

Pingback from  My SharePoint links January 8, 2013 | Jeremy Thake's musings

January 8, 2013 4:15 PM
 

Ben McMann said:

Another great search post Corey.  I really enjoy using your blog as another way to increase my knowledge of the SharePoint platform.

January 9, 2013 5:03 PM
 

CoreyRoth said:

@Ben Thanks! Glad you enjoyed it!

January 9, 2013 5:05 PM
 

Ragnar Heil: SharePoint Nuggets said:

Now I am back at my customer`s SharePoint Project after enjoying Christmas holidays, so I want to summarize

January 11, 2013 2:16 AM
 

SharePoint 2013 Nuggets of the weeks 1 & 2 | MSDN Blogs said:

Pingback from  SharePoint 2013 Nuggets of the weeks 1 & 2 | MSDN Blogs

January 11, 2013 5:00 AM
 

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?

January 15, 2013 12:18 PM
 

CoreyRoth said:

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

January 15, 2013 1:02 PM
 

SharePoint Daily » Blog Archive » Increasing SharePoint Productivity; Office 2013 Sentenced to Death; Is the Windows Ecosystem Still Relevant? said:

Pingback from  SharePoint Daily  » Blog Archive   » Increasing SharePoint Productivity; Office 2013 Sentenced to Death; Is the Windows Ecosystem Still Relevant?

February 25, 2013 7:41 AM
 

SharePoint Daily said:

Do you have plans for Wednesday? You should. Bamboo is proud to sponsor a free webinar on How to Use

February 25, 2013 7:49 AM
 

SharePointer said:

Hello Corey,

I don't see anywhere a powershell cmdlet to get the dictionnary or remove it like you could with FAST (Get-FASTResource, Remove-FastResource).

Any idea how to do that now ?

March 26, 2013 3:32 AM
 

CoreyRoth said:

@SharePointer You know I haven't seen anything for that.  Definitely seems like something that is missing.

April 11, 2013 10:13 PM
 

Harish said:

Hi Corey,

Thanks for the article! Is there a limitation on the size of the dictionary or number of keywords that can be specified in the dictionary?

May 31, 2013 5:04 AM
 

CoreyRoth said:

@Harish 1 million items according to the Software Boundaries document.  technet.microsoft.com/.../cc262787.aspx

June 3, 2013 2:13 AM
 

spbreed said:

Very informative article..

July 2, 2013 6:51 AM
 

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.

Thanks

July 10, 2013 4:52 PM
 

Uday said:

am getting error..

my ps1 file contains the following lines

"$searchApp = Get-SPEnterpriseSearchServiceApplication

Import-SPEnterpriseSearchCustomExtractionDictionary –SearchApplication $searchApp –Filename \\C4968397007\c$\extraction.csv –DictionaryName Microsoft.UserDictionaries.EntityExtraction.Custom.WordPart.2"

am getting the following error..

Import-SPEnterpriseSearchCustomExtractionDictionary : Failed to import custom dictionary Microsoft.UserDictionaries.EntityExtraction.Custom.WordPart.2. Check logs for more details....

November 4, 2013 1:19 AM
 

CoreyRoth said:

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

November 12, 2013 11:46 PM
 

CoreyRoth said:

@John I've never tried having extraction look through custom properties.  I assume you configure it the same way by selecting which refiner to map it into on the managed property page.

November 13, 2013 8:21 AM
 

John J said:

@Corey,

Yes. I have configured it the same way as did for OOB properties. Even I had the same contents in the custom metadata column.

Pls suggest further.

November 14, 2013 1:07 AM
 

Marcelo Rosende said:

Is there a way to set up de custom entity extraction by powershell or by C# code ?

Thanks

March 18, 2014 2:23 PM
 

CoreyRoth said:

@Marcelo, you always use PowerShell to configure it.  If you are talking about the input terms, you could always write them out to a CSV file first before doing the import.

March 18, 2014 2:32 PM
 

Pier Giovanni said:

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?

May 28, 2014 5:05 AM
 

CoreyRoth said:

@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?

June 10, 2014 1:44 AM
 

Suresh C said:

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

Leave a Comment

(required)  
(optional)
(required)  
Add

About CoreyRoth

Corey Roth is an independent SharePoint consultant specializing in ECM, Apps, and Search.
2012 dotnetmafia.
Powered by Community Server (Non-Commercial Edition), by Telligent Systems