Understanding Oracle's Universal Content Management Metadata Profiles

By Troy Allen May 11, 2011

There is power in Metadata. Unfortunately, administrators tend to overlook or not fully understand the abilities of the tools that come with most enterprise content management applications. Oracle’s Universal Content Management application has a not-so-hidden gem that is all too often overlooked: Metadata Profiles.

Content management applications have taken different approaches to metadata modeling. While some have allowed administrators to create metadata schemes for different types of managed content, Stellent’s Universal Content Management application (now Oracle Universal Content Management) took a repository wide approach. For years, this meant that all metadata was displayed for searches, check-ins, update, and on the document information page regardless of type of content or intended utilization.

Editor's Note: See CMS Review: Oracle Universal Content Management (UCM)

Over time, savvy developers created components that would allow administrators to hide certain fields based on criteria. These components tended to be unwieldy and required a lot of maintenance during product updates. Several releases ago, product management provided a capability in house to allow administrators to configure their own screens to show only the metadata required based on established criteria. While this capability, called Profiles, has been out for a long time, it is still one of the most under-used utilities of the application.

Search engines like Google, Bing and Yahoo have conditioned users to having a single field that seems to do it all for them while searching. Present a user with 50 or 60 fields on a search page and they will refuse to use the product. The same holds true for check-in pages: the more fields a user has to fill out, the less likely they are to provide good data. Even if you can limit the number of fields required to perform an action, mistakes tend to happen or people are just in a hurry and want to submit their content.

Any modern content management system should be able to support multiple “applications” within the enterprise. Most often, this may be a repository for a website, a human resources document management system, a records management vault, and even a repository for technical CAD drawings all at the same time. Each one of these applications has its own metadata requirements where certain information is needed to allow users to retrieve the stored content in the most efficient manner. Most often, the metadata about the content is used to determine how other applications will integrate and utilize it or may even drive publication rules. When users don’t fill out metadata correctly, processes can be broken.

Forms of Metadata

Metadata can take on many forms. The most common are:

Text Fields — free-form fields that allow users to insert their own values
Lists — pre-defined lists of options for users to select from. These lists may allow users to add adhoc values if needed
Date fields — date fields are often used to drive time-based events within the repository
Integers — numerical fields usually used for rankings
Decimal — numerical fields with defined decimal lengths used for financial information for coordinates

Through Rules and Profiles, administrators can combine these elements to create sophisticated metadata models. One of the most common metadata field enhancements are Dependent Choice List. As the name implies, this allows administrators to create fields where the values are a controlled set of options based upon the value of another field. While this went a long way to making Metadata modeling more efficient, it wasn’t until Profiles came to the scene that true Power was provided to the repository.