Managed Metadata in SharePoint 2010 a key ECM enhancement

Last week I did a talk on Enterprise Content Management enhancements in SharePoint 2010 at the UK SharePoint User Group. Since the talk was 70% demos simply posting the slide deck doesnt really convey the discussion, so over the next 2 posts Ill cover the same ground in written form. So this ECM enhancements mini-series consists of: Part 1: Managed Metadata in SharePoint 2010 a key ECM enhancement (this post) UPDATE: Part 1.5: Managed Metadata in SharePoint 2010 - some notes on the "why" Part 2: ECM platform enhancements - Enterprise Content Types, Content Organizer, Scalability etc. I want to focus on Managed Metadata first as it will be such a key ECM building block in SharePoint 2010. Background In SharePoint 2007, metadata was a huge blind spot many organizations have a fundamental requirement to only allow certain approved terms from a central list to be used as metadata. Broadly, the options were:

Use a choice or lookup field (scoped to web, or possibly deployed as Feature which can give broader reach but more maintenance problems) Build a custom field type Buy a vendors solution (which will involve a custom field type somewhere) Attempt to simply guide authors to use the correct terms in a plain old textbox

Frequently, metadata terms are in a hierarchy which counts some of those options out. Otherwise the first and last options were lame/unsuitable across large deployments, and I can practically guarantee that any vendor or custom solution out there wouldnt be as rich as a proper baked-into-SharePoint implementation. And this is what weve now got in SharePoint 2010 with the Managed Metadata capability I wouldnt say it covers all of the bases, but it can be extended easily. In my talk I joked that I couldnt bear to do a talk without any code, and so showed how a notable hole in the metadata framework

in can be plugged in 10 minutes flat by using the Microsoft.SharePoint.Taxonomy namespace. More on this later. A key thing to note is that the new Managed Metadata field now exists by default on many core content types such as Document so its right there without having to explicitly add it to your content. SharePoint 2010 - Creating the central taxonomy An organisations taxonomy is defined in the Term Store Management Tool this is part of the Managed Metadata service application, and can be accessed either from Central Administration or from within Site Settings. Permissions are defined within the Term Store itself. For my demo I borrowed the taxonomy from a popular UK electrical retailer, and added the terms manually (but note you can also import from CSV). The following image shows the different types of node used to structure and manage SharePoint 2010 taxonomy, and also the options available to manage a particular term:

Adding site columns - making terms available for use In order for authors to be able to use the terms on a document library, a column needs to be created (most likely on the appropriate content types) of type Managed Metadata. There are 2 key steps here:

1. Mapping the column to the area of the taxonomy which contains the terms we wish to use for this field:

Some notes on this:

o

The node selected is used as the top-level node if it has children, these values can also be used in this field.

Site collections can optionally define their own terms sets at the column level (i.e. leverage the authoring experience youre about to see, but not just for organization-wide terms sets) rather than use the central one. This is labeled as Customize your term set in the image above, and allows terms to be added when this radio button is selected.

2. Specifying whether Fill-in choices are allowed (shown on lower part of above image):
o

First thing to note is that fill-in choices are only possible when the Submission Policy of the linked parent term set is set to Open. This provides centralized master control to override the local setting on the column.

When the Allow Fill-in choices option on the column is set to Yes, we specify that authors can add terms into the taxonomy as they are tagging items - in taxonomic terms, this model is known as a folksonomy, meaning it is controlled by end users/community rather than centrally defined. Although the setting is quite innocuous, but this is hugely different in Information Architecture terms typically it is often beneficial when content authors are trusted and capable and there is a desire to grow the taxonomy organically, perhaps because a mature one doesnt exist yet.

I can imagine some document libraries may use both types (traditional taxonomy and folksonomy). One column is understood to be more controlled the other free and easy. With some custom dev work on the search side, it would probably be possible (definitely if you have FAST) to weight the more controlled field higher than the folksonomy field in search queries thus providing the best combination of tagging and searchability.

The end user experience web browser Now that we have a managed metadata site column, when a user is tagging a document in an appropriate library they can either get a type-ahead experience where suggestions will be derived from the allowed terms:

..Or they can click the icon to the right and use a picker to select (e.g. if they dont know the first letters to type):

The document is now tagged with an approved term from the taxonomy. Note that if the field allows fill-in choices (i.e. its a folksonomy field), this dialog has an extra Add new item link for this purpose:

The end user experience Office 2010 client Alternatively, content authors can tag metadata fields natively from within Office 2010 applications if they prefer. This can be done within the Document Information Panel, but also in the new Office Backstage view which I like more and more. They get exactly the same rich experience both type-ahead and the picker can be used just as in the browser:

And its things like this which other implementations (e.g. vendor/custom) just typically do not provide. So thats the basics, onto some other aspects I discussed or demod. Managed Metadata framework features

Synonyms a term can have any number of synonyms. So if you want your authors to say, tag items with SharePoint Foundation instead of WSS, youd define the latter as a synonym of the former. In my television specifications demo, I added some phoney terms Plasma Super and Plasma Ultra to my preferred term of Plasma, and showed that in the user experience the synonyms show up (indented) in the type-ahead, but cannot actually be selected the preferred term of Plasma will always end up in the textbox:

In case youre curious as to equivalent picker experience, this shows synonyms in a tooltip kind of way when you hover over the term.

Multi-lingual for deployments in more than one language, the metadata framework fully supports the SharePoint 2010 MUI (Multi-lingual User Interface), meaning that if the translations have been defined, users can tag items in the language tied to the locale of the current web. The underlying association is the same as the value actually stored in the SharePoint field is partly made up of the ID.

Taxonomy management as shown in the term store screenshot way above, terms can be copied, reused (so a term can exist in multiple locations in the taxonomy tree without being a duplicate i.e. in a polyhierarchy fashion a

common requirement for some clients), deprecated (so no new assignments of the term can occur), merged and moved etc. In short, the types of operation youd expect to need at various times.
o

Id add a note that these are possible against terms in the taxonomy the parent node types of term set and group (in ascending order) logically dont have the same options, so if you make the beginners mistake of creating a term set when you really wanted a term with a hierarchy of child terms underneath, you have some retyping to do as you cant restructure by demoting a term set to a term. The key is simply understanding the different node types and ideally having more brain cells than I do.

Descriptions minor point, but big deal. Add a description to a term to provide a message to users (in a tooltip) about when and how to use a term. This can be used to disambiguate terms or otherwise guide the user e.g. This tag should only be used for Sony, not Sony Bravia models.

Delegation/security permissions to manage the taxonomy are defined at the group level (top-level node), so if you wish to have different departments managing different areas of the tree, you can do this if you create separate groups. Related to this, each term set can be allocated a different owner and set of stakeholders this isnt security partitioning, but does provide a place to specify who is responsible and who should be informed of changes at this level (in a RACI kind of way).

User feedback if the term set has a contact e-mail address defined, a Send feedback mailto link appears in the term picker, thus providing a low-tech but potentially effective way of users suggesting terms or providing feedback on existing terms.

Social a users tagging activity will be shown in their activity feed

No doubt Ive missed some add a comment if any spring to mind please!

Extending the metadata framework adding approval So there are some great features in the framework, but one thing that seems to be missing is the idea of being able to approve terms before they make it into the central

taxonomy. So perhaps we want to allow regular users to add terms into the taxonomy quite easily, but only if they are approved by a certain user/group - this would give a nice balance between a centrally-controlled taxonomy and a true folksonomy. I put the word missing in quotes just now because quite frankly, its pretty trivial to build such a thing based on a SharePoint list and thats just what I did in my talk. Im sure more thought would need to go into it for production, but probably not much more. All we really need is to set up a list somewhere, add some columns, and add an event receiver. Adding an item to my list looked like this I need to specify the term to add and also the parent term to add it under (using a managed keywords column mapped to the base of my taxonomy, meaning terms can be added anywhere):

Then I just need some event receiver code to detect when an item is approved, and then add it to the term store:
1: public class TaxonomyItemReceiver : SPItemEventReceiver 2: { 3: public override void ItemUpdated(SPItemEventProperties properties) 4: { 5: if (properties.ListItem["Approval Status"].ToString() == "0")

6: { 7: string newTerm = properties.ListItem.Title; 8: TaxonomyFieldValue parentTerm = properties.ListItem["Parent term"] as TaxonomyFieldValue; 9: 10: TaxonomySession session = new TaxonomySession(properties.Web.Site); 11: TermStore mainTermStore = session.TermStores[0]; 12: Term foundTerm = session.GetTerm(new Guid(parentTerm.TermGuid)); 13: Term addedTerm = foundTerm.CreateTerm(newTerm, session.TermStores[0].DefaultLanguage); 14: mainTermStore.CommitAll(); 15: } 16: 17: base.ItemUpdated (properties); 18: } 19: }

My code simply finds the term specified in the Parent term column, then adds the new term using Term.CreateTerm () in Microsoft.SharePoint.Taxonomy. Note the use of the TaxonomyFieldValue wrapper class this is just like the SPFieldLookupValue class you may have used for lookup fields, as terms are stored in the same format with both an ID and label so this class wraps and provides properties.

Once this code has run, the term has been added to the store and is available for use throughout the organization perhaps the best of both worlds. Amusingly, when we got to the soooo, did it work? bit in my talk the demo gods mocked me and the type-ahead on the term picker waited a full 10 seconds before the term came in, leading to a big ooof[pause]..woohoo! from the audience which capped off a hugely fun talk (for me at least).