Folder Adaptation Method

The following method of adapting folder hierarchies to create taxonomies for a workspace originated from project management within Microsoft that used SharePoint Portal Server. This method requires organization, subject expertise, and intuition. The method assumes an existing folder hierarchy as a starting point. An organization that starts a workspace taxonomy from scratch may find that some of these methods still apply with modification.

Many organizations have already undertaken significant taxonomy efforts as part of a knowledge management initiative. You should use the results of those efforts before turning to this folder adaptation method. Other organizations have no resources to create the tailored structure that this method yields. Simply dragging and dropping an existing folder hierarchy into the workspace still functions but lacks optimization.

Converting Folder Hierarchies

The overall goal of folder adaptation is to convert a folder hierarchy into a set of folders, document profiles, properties, and property value lists (dictionaries) that capture all the information embedded in the original folder hierarchy, and then extend that taxonomy to capture richer information. The resulting taxonomy

• Has fewer folders than the original hierarchy.
• Creates a set of workspace document profiles, properties, and dictionaries.
• Exposes implicit metadata as explicit properties.
• Produces a workspace that looks familiar to users.

Building taxonomies requires human expertise. Although you can automate some of the organization, you derive decisions from knowledge of the content and its purpose and how various compromises occur within an organization.

This author-focused method creates no categories. For more information about creating taxonomies by using categories, see the section Categories later in this chapter.

Creating Document Profiles

The first goal is to attach a document profile to each document in each folder in the original hierarchy.

To achieve this goal, you must perform an audit of the content migrating into the workspace. Review each folder in the original hierarchy and examine each file. For each one, attach a document profile that roughly describes what the document is. Choose whatever level of detail seems appropriate. You can modify this information later in this process.

For example, a folder might contain two test specifications, a presentation, and a set of meeting notes. The next folder might contain a sales invoice, a personnel report, and another presentation. You should reuse document profiles when documents with the same purpose appear in multiple folders.

As the audit progresses, the number of reused document profiles from previous folders increases, while the number of new document profiles decreases.

This step requires at least recognition of the purpose of everything in the folder hierarchy. Accomplishing this step may require consultation with subject matter experts more familiar with a particular region of the hierarchy.

Adapting Folders into Properties

The second goal is a reduced folder list. You might apply security policies to some folders. Also, you have populated document profiles with mandatory and optional properties and dictionaries for some of the properties.

The second step addresses the idea that you can represent implicit metadata explicitly as properties in the workspace. Each folder receives an evaluation of its reasons for existence. From this evaluation, you can either convert this implicit purpose into properties on a document profile or tag the folder with an appropriate security policy. Later, you can decide whether to retain the folder based on its stated purpose.

To do this, apply the following algorithm to the subfolders of each parent folder:

• For each subfolder, determine whether the folder needs to exist for security reasons (such as to limit access, to delegate coordination, to specify approval routes, etc.).
• If the subfolder has a reason for existing, tag it with that reason.
• If the subfolder does not have a security reason for existing, add the folder information as a mandatory property to all document profiles in that folder, and add the folder name as a value for the dictionary of the new property. Then, move all subfolder content to the parent folder, add all subfolder document profiles to the parent folder's document profile set, and remove the subfolder.

  For example, if you have a folder called "1998," add a mandatory property called "year" to all document profiles in the folder, and a value "1998" to the dictionary for the property "year." If the property already exists from another document profile, reuse it and add the dictionary value to the existing dictionary for that property.

Reducing the List of Document Profiles

For this step, your goal is to reduce the list of document profiles and to change some mandatory properties to optional.

Because the audit produced just a list of document profiles, an examination of the results of converting folder information into properties shows redundancies between document profiles where closely related profiles have similar names and/or similar sets of properties. You can combine these redundant document profiles to reduce the list of document profiles to be managed by coordinators and used by authors.

If two document profiles contain identical sets of mandatory and optional properties, you can combine them. To do so, create a new document profile. After combining them into one document profile, you associate the relevant folders and documents with the new profile. If you must combine two document profiles with different property sets, you may choose to change properties from mandatory to optional as you aggregate them. Any property that applies to only one of the document profiles must become an optional property in the aggregated document profile.

As an example, consider two document profiles, Development Specification and Test Specification. Test Specification contains a mandatory property called Test Case Number. That property does not appear in the Development Specification document profile. A single document profile called Specification that aggregates the two original document profiles cannot contain a mandatory Test Case Number property since that property has no value for Development Specifications. It becomes an optional property in the aggregated document profile.

Although a reduced document profile list is easier for coordinators and authors, users tend to ignore optional properties. The decisions on aggregating document profiles must take into account the metadata enforcement policies of the organization. If the organization insists on mostly mandatory properties in document profiles, the opportunities for aggregating document profiles are reduced.

Even without strong metadata enforcement, over-aggregation of document profiles results in document profiles with a large number of properties. Because authors see a document profile form each time they publish content in the workspace, a large document profile burdens users, reducing their willingness to publish content. The coordinator designing the document profiles must consider this.

Extending the Document Profiles

In this step, you include additional properties in some document profiles in order to represent new metadata.

This step recognizes that the previous steps have accomplished nothing more than, change the representation of the information already contained in the original folder hierarchy. However, document profiles allow the capture of more information to aid in searching, approval, sorting, etc. You can extend the document profiles created in the previous steps with additional properties.

This step relies on business knowledge and a bit of intuition. Coordinators extend document profiles by adding mandatory and optional properties that "make sense." Some of these originate from an inspection of the implicit metadata captured in file names. Some originate from the requirements of approvals, where approvers must know certain information to make an approval decision. Some originate from outside considerations and business needs.

Starting with a New Workspace

Not all workspaces derive from existing file hierarchies. Starting with a new workspace requires more research and thought, but the ideal outcome remains the same: a folder hierarchy that focuses on authors and maps to appropriate document profiles and properties while capturing the needs of the organization using the workspace. Starting with a new workspace requires the same knowledge of the intended content, the organization, and the business needs as building from an existing hierarchy does.

One challenge faced when starting with a new workspace is recognizing when you complete the task. In the method presented previously, the process is complete when you apply the four steps to the entire existing hierarchy. When starting with a new workspace, you must gather requirements to understand how the workspace will be used, and use those requirements to build a taxonomy. The analysis may not fully cover all needs on the first pass, either because they cannot be easily anticipated or are simply missed. The full set of factors affecting folder usage may remain unclear. Starting with a new workspace often requires a more iterative approach, involving an initial taxonomy that develops into an ideal solution over time.

Without an existing hierarchy, the analysis starts by reviewing the flow of relevant information within the organization. Typically, the workspace must support some specific business processes. You can try to answer questions such as the following:

• What key documents do we handle?
• What steps do we execute to produce or approve key documents?
• What key processes do we use, and what information supports these processes?
• What have other groups in my organization built to solve similar problems?
• What taxonomy elements exist within other systems in the organization?

The answers to these and other questions uncover business policies that the workspace must support, and identify information that must be stored and accessed. Security policies of folders, such as role information, identified coordinators, and approval routes, form the motivation for a set of folders. Information about those folders suggests properties and document profiles.

After you answer these questions and identify an initial taxonomy, you can use the method described previously to optimize the results.

Considering Limitations of Modifying Folder Hierarchies

The four-step method presented in this chapter produces a taxonomy for your workspace that derives from an existing folder hierarchy and produces a workspace tailored to the population accustomed to using the original folders. This method does have some drawbacks and limitations.

How much time do you have? The method rigorously ensures that your workspace loses no information when compared to the original folder hierarchy, but the process is time-consuming. For hierarchies that contain a few hundred folders and a few thousand files, the effort is manageable. Beyond that size, the resources required to be thorough might exceed the value of the effort. In some cases, it may be more realistic to take a representative segment of the original folders and use that segment to derive a starting taxonomy. This starting point risks missing key document profiles, properties, or dictionary values, but you can extend it during the life of the workspace to accommodate these omissions.

Garbage in, garbage out. Basing the workspace taxonomy on an existing folder hierarchy preserves familiarity, but it also propagates into the workspace all the structural weaknesses of the original hierarchy. If the hierarchy grew organically to include redundancies, dead ends, and illogical organization, the workspace also exhibits some of these qualities in its folder structure. Fortunately, the ability to aggregate content across folders by using categories, and to search by properties, mitigates the effects on the workspace, but you should consider more extensive folder reorganization when faced with a set of folders in extreme disarray.