1. Open the Term Store Management Tool (Site Actions > Site Settings > Term Store Management) an download the sample import file. (Remember, Service Applications are configured on a per Web Application basis, so use any site collection inside a WebApp configured with your MMS.)
2. Insert your data. In the photo below, I demonstrate creating a term called USA. Under that, I create the term Alabama. Under that, 4 cities. Then under USA, a term called Alaska. The point is that the we have a hierarchy. Using the import file, we can go 7 layers deep.
3. Save the file, head back into the Term Store Management Tool, select/create a group, and Import the file.
How SharePoint Updates listitems when the Managed Metadata changes.
First, be sure to have configured a Managed Metadata Service and have a termset to use.
Second, go to a site collection and configure a Managed Metedata field to use that termset.
Create a list item and assign it a value for the Managed Metedata field. Take note of the value.
Now locate the Timer Jobs in Central Admin > Monitoring. Scroll down or page over to the Taxonomy Update Scheduler jobs. I disabled all of the Taxonomy jobs for this demo.
Here are a list of my Web Applications. You can see how each Web App (image below) has a Taxonomy Update Scheduler job (image above) assigned to it.
Now go into your Term Store Management Tool (via /_layouts/termstoremanager.aspx”>http://<siteurl>/_layouts/termstoremanager.aspx ) and update the value.
The original value was Houston.
The updated value is Houston, Tejas.
Back on the site, it still shows the old value, Houston.
If we go into Central Administration and open up the Taxonomy Update Scheduler job, we can Enable it. Then we can Run Now.
After a few seconds, the Taxonomy Update Scheduler Timer Job will have completed. And after F5’ing our list view, we’ll see the updated value.
So that’s how changes to the MMS are pushed down to content.
I hope this post will help explain how Managed Metadata is actually stored in a list.
I’ve created a Team Site (can be any template of course) on my demo portal.
I’ve created a Managed Metadata Service in Central Admin.
I’ve wired up my demo portal Web App and my MMS Service App.
I’ve imported a Country-State-City taxonomy termset.
I’ve created a custom list (CustomListA) in my demo portal.
I’ve added a Managed Metadata field to my list and configured it to use my Country-State-City taxonomy termset.
I’ve added two items to my CustomListA. And I’ve chosen USA:Alabama:Huntsville as my item locatoin for each item.
I’ve used PowerShell to dump out my CustomListA xml.
Let’s take a look at how the data is stored. First, you can easily see the ows_Location field pointing to “12;Hunstville”. The 12 comes from the fact that Huntsville is the 12th Managed Metadata term to be used in my Site Collection. If I had only used 3 others, then Huntsville would be #4. I think you get the idea here. Note: I’m not sure why it needs to keep the 12 when another attribute contains the GUID — notice the 63371559-… after the Huntsville in ows_LocationTaxHTField0 field [Line 7]. But it is what it is.
After looking over the CustomListA XML file, I then used PowerShell to render my TaxonomyHiddenList. This list is what ties all other lists in it’s site collection to the Managed Metadata Service or TermStore. If you scroll down to line 656, you’ll see ows_IdForTerm=63371559… This is the same value in Line 7 of the CustomListA xml file. This GUID is our link.
For what it’s worth, here are the powershell scripts used to create these XML files. First, the script to create out custom list xml file.
Second, the script to create our TaxonomyHiddenList xml file.