Notes SharePoint Blog

In Part 1 we talked about what the new Managed Metadata fields are good for, especially when migrating a Notes application.  Today we will look at how to configure them in a SharePoint 2010 list or library and how to use Notes Migrator for SharePoint 5.3.3 to migrate to them.

Defining your managed metadata field in SharePoint

First you need to define a column in your target SharePoint list or library that will hold your migrated data.  Unfortunately, Notes Migrator for SharePoint cannot provision this type of column for you as it can with most other column types, so you have to define it using the SharePoint user interface or with SharePoint Designer.

When adding a new column to your list, you can now specify a column type of Managed Metadata.

Next, specify what term store and term set you want to use.  Recall that the term set is the list of all the legal choices for the column (similar to the source view in a lookup column). 

To define a new ad hoc term set just for use with this application, select Customize your term set.  The new term set will be scoped to your site collection.  You can add terms and sub-terms immediately by using the built in editor, or click Edit using Term Set Manager for a more advanced editing experience.  (More about populating your term sets later.)

Alternatively, you can choose an existing term set – either an “Enterprise” term set from one of the shared term stores configured for your SharePoint farm, or a term set that was previously created for this particular site collection.

Note that the above screen shots highlight some additional options you have when defining your Managed Metadata column.  You can specify whether or not the field is required, what the default value is, whether or not the field is multi-valued, and whether or not the user is allowed to add terms not already in the term set.  These are all self-explanatory but are all important decisions to make as you design the ideal experience for your end users.  And, of course, they impact the choices you make when migrating things.

Before going any further, I suggest trying out your new column.  Manually add a few new test documents and make sure the column behaves the way you expect it to.

Adding a managed metadata field to your migration job

Now for the good part…  migrating some Notes data to our new managed metadata column.  In the Notes Migrator for SharePoint client, edit your Target Data Definition and go to the Data Fields tab.  If you are connected to your target SharePoint lists, the easiest way to add a field definition will be to press the trusty “Load From SharePoint List” button.  This will inspect the list and add a new field with many of the properties already set to reasonable defaults.  Alternatively you can press the Add button and manually specify the Name and a Target Type of “Managed Metadata”.

One of the trickier bits of this process is describing how you want your Notes terms to match up to your SharePoint term set terms.  This is especially interesting if your Notes terms and/or your SharePoint terms are hierarchical.  Notes applications typically store hierarchical categories and keywords using slashes or backslashes, for example “Trees\Oak”.

On the SharePoint side, you may or may not have defined a similar hierarchy of terms and sub terms.  In this example we have a term called “Trees” and under that a term called “Oak”.

Notes Migrator for SharePoint gives you several options for dealing with this.  Set the Hierarchy Options property to “Map As Hierarchy” if you want precise matching up of the full term path (all the terms and sub-terms).  For a more forgiving mapping, select “Map Last Leaf Only”, which would allow “Trees\Oak” to match any term named “Oak”, regardless of hierarchy.  Finally, you can select “Not a Hierarchy” which would not treat slashes as special and would simply map “Trees\Oak” to a term with the flat string “Trees\Oak”.

The Match on Alias property allows you to discover terms based on aliases (including internationalized versions of terms).  This way, if some of your old Notes documents has “Oaks” instead of “Oak” you can set up an alias in SharePoint to capture that.  (Tip:  you can safely remove the aliases in SharePoint after your migration is done.)  You can also specify a particular language to use for term matching using the Default Language LCID property.

The Add Missing Terms to Term Store option allows you to populate new terms in your term store as you go.  This is an important migration option as it allows you to migrate all the term values found in your historic Notes data.  If this option is turned on, Notes Migrator for SharePoint will first attempt to locate an existing term (using the options described above) and add it if no match is found.

Finally, back on the Notes Migrator for SharePoint mapping tab, you should map a Notes source column to your new target field, just like you would with any other field you want to migrate.

When you migrate, you can see any term mapping errors, etc., in your log file.  Turn on Verbose logging in the tool Options for maximum debugging detail (but remember not to leave it that way for your entire migration project!)

As a final note, remember that Notes Migrator for SharePoint always gives you option to use formulas in your source fields.  This can be extremely helpful if you do not have a one-to-one mapping of term strings but need to do lookups or otherwise massage the data along the way.

Central to most custom Notes applications are keyword fields, which range from simple pop-up or drop-down lists of terms that users can select from (for example, product codes) to lookups in other views and databases (for example, customer numbers). Some Notes solutions even include custom term-management databases where users could centrally manage the terms, codes, and other resource documents used by other Notes applications.

SharePoint 2007 provided two pretty good ways to achieve this functionality: Choice fields allowed users to select from a simple set of choices, and Lookup fields allowed them to select records from a different list within the same site. These options provided much of the required functionality, but in some situations, these features were too simplistic and their scope was too limited.

A powerful new feature of SharePoint 2010 is Managed Metadata (also referred to as Enterprise Metadata or Managed Keywords). You can think of this as the next level beyond Choice fields and Lookup fields. Now SharePoint enables you to manage all the terms that are important to a particular application domain (the keywords, product codes, customer types, document categories, etc.) in a shared term store. SharePoint 2010 includes a complete interface that enables administrators to maintain terms, along with the following cool features:

• Aliases – Different words that mean the same thing
• Translation – Different words in different languages that mean the same thing
• Context – The same word can mean different things in different settings
• Hierarchy – Organization of terms into categories and sub-categories

Some people think of the term store as a corporate taxonomy. But while the term store does attempt to address the needs of a corporate taxonomy, it conjures up images of full-time taxonomy managers and expensive knowledge management consultants trying to establish the perfect set of terms for the enterprise, This may be well beyond the scope of many SharePoint teams. Happily, the Managed Metadata feature in SharePoint 2010 scales very well from simple needs to enterprise knowledge management solutions. For example, you can easily create a simple Managed Metadata field and a term set that is scoped to just one SharePoint site; multiple lists and libraries within that site can reference that same term set just as easily. Later, if you need to, you can scale out to enterprise term sets that span many site collections and can even be replicated between multiple SharePoint farms.

When you use a term store to classify (or, to use the modern buzzword, “tag”) your content, you get additional benefits. Not only are you using a consistent set of terms across multiple applications, but you can use these terms to find content more easily. For one thing, SharePoint search is tuned to work with managed metadata to search across many applications that use the same term sets.

Of special interest to Notes developers is the ability to quickly build drill-down views of your content based on your metadata. This can replace the proliferation of categorized views within many legacy Notes applications that allowed users to navigate their content in various ways. You can also filter views based on your metadata so you can eliminate many views that simply showed different subsets of your data.

In Part 2 we will dig into how the new release 5.3.3 of Notes Migrator for SharePoint will allow to to actually migrate your Notes data to managed metadata fields.