In order to make any information more retrievable, you want to add some form of metadata. In the most primitive scenario’s a relevant document-title will suffice or maybe a description. But with the avalanche of information which we must process on a daily basis, this kind of metadata simply is not enough.

 

 

 

 

 

 

 

Platforms like SharePoint offer us a multitude of options to enhance our information further. Some of these options are integrated into the platform or work alongside Microsoft Office.

In this post I want to look at some of these options. To be more specific, to look at the ways in which a platform like SharePoint supports us in adding our own metadata. Can we use SharePoint to make information better available in a way we, the end-user, want to? And what are the consequences of this for the organization?

Should all metadata be mandatory and centrally managed or should we go for a free format, optional and even folksonomy metadata model? These are questions many enterprises are dealing with and for which platforms like SharePoint, with their multitude of options, don’t have a definite answer.

I’ll try to give you mine in this post.

First things first though. What are metadata?

Metadata

“Metadata is “data about data”. The term is ambiguous, as it is used for two fundamentally different concepts (types). Structural metadata is about the design and specification of data structures and is more properly called “data about the containers of data”; descriptive metadata, on the other hand, is about individual instances of application data, the data content.

Metadata are traditionally found in the card catalogs of libraries. As information has become increasingly digital, metadata are also used to describe digital data using metadata standards specific to a particular discipline. By describing the contents and context of data files, the quality of the original data/files is greatly increased. For example, a webpage may include metadata specifying what language it is written in, what tools were used to create it, and where to go for more on the subject, allowing browsers to automatically improve the experience of users.”

This is from Wikipedia. So, in my own words; Metadata are additional data fields used to enhance an object. Take a document for example. It will have an author and perhaps a subject. But metadata provides us with an opportunity to link more information to this document. The type of document for example or the version number or even the number of likes. In general, metadata are used to be able to search or (more general) to be able to locate your information more easily.

Metadata are everywhere. Even when just writing a blog article using Microsoft Word, metadata are collected. Properties like the author of the document and the creation date are automatically stored with the document, and thus enabling platforms like Microsoft SharePoint to store these as metadata. But these are not all the metadata possibilities.

Types of metadata in document management

In this post I’ll be discussing the type of metadata that describes or enhances content. And basically when looking at this from the SharePoint perspective, there are four types of metadata:

• System metadata.
• Standard metadata.
• Organizational specific metadata (formal metadata).
• Informal metadata.

Just for fun, look at the metadata of a SharePoint document.

System and standard

The first two categories are the ones that we, as a user, cannot modify. System metadata are items like “created by” or “modified by”. The system (i.e. SharePoint) provides these free of charge and automatically. We can use these metadata, but won’t be able to change them.

Next is the standard metadata. And I use the term standard because this is metadata which are regarded as standard in the content management arena. Take the Dublin Core document metadata standard for example. When adding a document to SharePoint you should at least expect an author field or a title field. These can be optional or mandatory or even filled automatically by Microsoft Office.

Either way, the system and standard metadata are out of the box. You don’t have to change these and you can use them right away.

Organizational specific

But is most cases, these forms of metadata are not enough. As an enterprise you will need to add your own metadata. And perhaps even allow your employees to add values of their own. That’s when things become tricky.

I won’t go into the solutions to store these metadata, as I assume we are all aware of these (site columns, content types, content type hub, and etcetera). Nor will I mention the nice additional feature you can have using metadata field. So I won’t mention default values based on the location of the document, input validation, allowing separate values in a selection field, etc……

But when you do decide to provide your own metadata, there are a lot of different options available. To name but a view:

• Text: A free-format way to add text. Either one line or multiple. Either plain or rich text.
• Managed metadata: They epiphany of formal metadata. Presented as a list of managed values.
• Choice: Presented as a list of managed values, but within the column itself.
• Number: An integer, basically.
• Date/time: A selection field for date/time (duh).
• People: The SharePoint Peoplepicker.

Some of these fields are no problem at all. A date/time field will limit the users input somewhat J But when do you need a text field? And should you go for choice fields or managed metadata?

So when you’re deciding on the use of metadata, you almost automatically need to decide if you want to provide mandatory and choice only metadata or a more lenient model.

This all depends on your enterprise. In my experience, you should at least have a basic metadata model which you use to create your columns. Based on this, you go on to discuss formal and informal metadata.

Formal metadata – taxonomy

Formal metadata are the metadata that your organization would like you (are expects you) to use. A taxonomy normally comes into play here. A taxonomy contains a centrally managed collection of metadata terms. These terms can be used in a multilingual environment, can be linked to other terms and can have synonyms (in a nutshell). In SharePoint you can delegate this taxonomy and provide a separate one for each department for example. Or you can go for an enterprise wide taxonomy.

A taxonomy has at least one problem: it’s centrally managed (even if this has been delegated). This seems odd, but let me explain. A taxonomy will never be able to contain every term which might be useful in the enterprise. Employees will have their own values which they find useful. You might consider opening up the taxonomy. Employees can then simply add their own values. But this is contra dictionary to the philosophy behind the taxonomy.

So if you need to provide these employees the means to add their own values, look a bit further. And delve into the realm of the more informal metadata.

Informal metadata – bring your own metadata (BYOM)

Ok, here’s where metadata like tags, notes, likes, keywords, comments, well… you get the drift, come into play. In my opinion: informal metadata.

By the way. You can discuss if metadata is formal or informal. Enterprise keywords are part of the metadata of a document, so these could be seen as formal. But by my definition, formal metadata is mandatory and can only be selected. Informal metadata allows people to add their own values.

Free text and “Allow fill-in choice”

One of the easier ways to add your own value to a metadata field, is to use the “allow fill-in choice” option when using a choice field. A user will be able to add his/her own value to the list. The problem is, this value is only available to this particular user. It won’t show up when a different user selects the metadata. So perhaps this is not the way to go.

Another option is to add a “comments” metadata field to documents. Most of the time this is a free text field. I won’t go in on the subject of usefulness. When versioning is enabled, every version of the document has the system metadata field “comments”, so adding the same field might be overkill.

But this kind of field does enable your employees to add their own values. But this type of field is not supposed to be used to categorize documents. It’s needed to provide extra information on the document. When people use this kind of field as a metadata field, you might run into problems.

First of all, it’s error prone. Typos are easily made and SharePoint will not correct them or suggest an alternative. Second, not all documents will be retrieved when searching, because of these typos and the information in text fields will not be used as search refiners. And third, there is no way of managing the content of these fields.

So from a metadata perspective, free text fields (including fill-in choices) have a limited usability. So what are other options? In all, we have two. And these two have similarities but are also very different. We’re talking about enterprise keywords and tags.

Enterprise keywords

Enterprise keywords allow users to add their own metadata to a documents. If it is a new keyword, SharePoint will store this in the managed metadata Keywords section. If the keyword already exists, then the user is prompted with the similar keyword. But that’s not all. When the user types their value, SharePoint will check if the keyword already exists in the taxonomy as-well! So you get a best-of-both-worlds scenario.

 

 

 

 

 

 

The keywords are part of the document management environment. This means that you can add them when adding a document to a documentlibrary or when creating the document in Microsoft Word. The keywords also appear (if you choose) in the view(s) of the documentlibrary.

Some other features of enterprise keywords:

• Can be added and/or changed from within the documentlibrary;
• Can be changed using the Quick Edit mode in the documentlibrary;
• They can be used to filter documents in the documentlibrary;
• They appear (alongside tags) in the tag cloud (see below);
• You can “follow” a keyword or add the keyword to your profile;
• The keyword will not appear on the social newsfeed.

Tags

Another option to add your own metadata values is tagging. This is somewhat similar to the enterprise keywords in that SharePoint will also store the tags in the managed metadata Keywords section. It will also check if the tag already exists in the taxonomy. But that’s basically were the similarity ends.

 

 

 

 

 

 

 

 

Tagging is mostly a social feature. It’s the most informal of all metadata options. When someone tags information (e.g. a document), this tagging action will be displayed in the social newsfeeds. But the tags won’t show up as metadata in the documentlibrary. I won’t see a column “tags”, for example.

Tagging works differently from a document management perspective. From this perspective, you would expect all document management options to be available when you’re adding documents. But tags can only be added to existing documents and you will need to select the Tags and notes option from the ribbon. Tags are therefore not part of the documentlibrary.

Some other features of tagging:

• Tags don’t show up in the view(s) of the documentlibrary;
• Tags cannot be added or modified using the Quick Edit option;
• Tags will appear on the tag cloud (duh…);
• You can “follow” a tag or add the tag to your profile;
• Tags show up in the newsfeeds;
• You cannot add or modify tags when using Microsoft Office;
• Tags can be personalized (no one sees that I tagged the item, but it will count).

Manageable

Most enterprise will be skeptical on implementing keywords or tags. Most will be wondering if these types of metadata can be managed. Well…… Yes and no. With keywords or labels you won’t get the nice managed metadata management options. You can’t add synonyms to a tag or have different languages for a keyword. Let face it: these are informal (user generated) metadata!

But you do get an overview of all keywords and tags within the organization. These are stored in the managed metadata service, under Keywords. Let’s say the scenario unfolds where you decide that a tag is “worthy” of transforming from the informal to the formal side. In that case, you can move the tag to the taxonomy. All management option will become available and the tag is still available as a tag. Nice!

Overview

At this moment I believe I’ve told you a lot about metadata. But perhaps it’s a bit too much. So here’s an easier table:

	Formal metadata		Informal metadata
	Text/number/date	Taxonomy	Keywords	Tags
Option	Selectable/fill-in	Selectable	Fill-in	Fill-in
Shown	In views	In views	In views In tag cloud Keyword property page	Tag cloud Newsfeed Tag property page
Searchable	Yes	Yes	Yes	Yes
Can be made mandatory	Yes	Yes	No	No
Risk of typo	Yes	No	Yes	Yes
Will move to record center	Yes	Yes	Yes	No
Manageable	No/minimal	Full	Minimal	Minimal
Microsoft Office integration	Yes	Yes	Yes	No
Add to profile or subscribe	No	No	Yes	Yes

Concluding

Having an option for the users to add their own metadata values does have its rewards. If can help to professionalize the information management within the enterprise. Let’s face it: two know more than one and by using keywords or tags, you will soon discover the hidden metadata of the organization. Users will be able to find more information and more quickly and are themselves found more easily when adding keywords or tags to their profile.

Implementing

But it does have its drawbacks. For one: what to choose? You will need to have a clear understanding of the workings of taxonomy and folksonomy in order to create the most optimal metadata environment. Tags thrive in a social environment (Sogeti Social Intranet) with lots of newsfeeds, profiles and interaction. In a document management environment I would advise to keep the formal metadata to a minimum and introduce the keywords.

But then again, this does depend on the enterprise. In a highly regulated environment you will probable like to have specific taxonomy fields which are mandatory. In a more social environment (an R&D department for example) you might want to go for less taxonomy and more tagging.

It also depends on the expected effort needed to implement the required metadata model. And this is not just the technical side of it. Yes, we will need a social database, user profile synchronization and the distributed cache service to get the most out of the platform. But that’s where the SharePoint architect comes in. But implementing also means getting the people to use it. It needs to be clear to them what they will get out of this.

Adoption

Just adding 25 mandatory fields to a document just because the Document & Information Management department has lost track of document usage within the enterprise is not valid reason. Adding them because you are in the business of developing a cure for leukemia is. The first scenario will be more difficult to implement then the latter.

On the other hand, adding informal metadata to a document library should have its reasons as well. Because you still have to explain why this is necessary when you already have (let say) 10 formal metadata fields as well.

So, communication and adoption is part of this subject as well.

Drawbacks

Another possible drawback is the tagging overload. Because of the tsunami of tags, people can’t find their information anymore. Which might be a very ironic thing indeed. And there might be a small community of people tagging, which will give this community some form of control of the metadata.

I don’t agree with some of these points. The best way to get some experience with all types of metadata is simply: start using them. See what fits. Accelerate this by motivating your users to use you metadata model. And evaluate this in a couple of months.