Reading over five years' worth of notes for an ongoing client knowledge integration project, I realized that it might be useful to summarize the issues we encountered. The project involved creating a knowledge base (metadata repository) that would:

1. produce more accurate and timely information with less effort;
2. serve the needs of multiple departments;
3. feed metadata to multiple applications, such as enterprise search, Web publishing, and data exchange with external agencies.

I call this a "knowledge integration" project rather than an "ontology" or "taxonomy" project because it involved multiple workflows/business functions, subject matter (domain) specialties, both historic and current data formats as well as print and electronic publishing processes.

In this article, I'll discuss both the strategic and nitty-gritty issues we encountered in user interface design, application integration, data structure, and information strategy.

What is "knowledge integration?"
In this project, "knowledge integration" meant creating a repository structure and XML outputs that would aggregate and normalize data. An example of aggregation is to combine the description of a physical object such as a painting (size, catalog number, dimensions, acquisition date) with information about the creator (name, birth/death dates, description, reviews). An example of normalization is to associate the popular name of a law (e.g. "Patriot Act" with its official name "Uniting and Strengthening America by Providing Appropriate Tools Required to Intercept and Obstruct Terrorism (USA PATRIOT ACT) Act of 2001."

The goal was to store data once but use it in unlimited ways. For example, the same person might be at different times a full-time employee, a retiree, or an ex-employee who is now working for the organization as an independent contractor. If the name is stored in three different places (e.g. employee directory, retiree list, and contractor list), it's impossible to get a current, comprehensive, and accurate picture of the person's work history, especially if slightly different names are used in each list (e.g. "Bill Smart" vs. "William H. Smart").

Not only did we want accurate historic data about content and people, but we also wanted to categorize them for search, browse, and reporting purposes. On the one hand, we wanted to standardize categories across the enterprise. On the other hand, we wanted to allow regional offices, business units, and even individual employees to create their own organization schemes and define categories in their own context. To accomplish both of these objectives, we needed to resolve issues in three areas:

• user behavior;
• application integration;
• data structure, display, and quality assurance.

More ... (members only) How to become a member

Created on March 12, 2010 l Updated on March 16, 2010