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.


Profiling allows administrators to create subsets of metadata fields based on triggers. The following are just a few of the more advanced modeling techniques and use cases that can be deployed:

  • Group Metadata fields: grouping like metadata fields helps users to fill out information in a coordinated fashion.
  • Hide or Display fields: based on the type of content being searched for or checked in, criteria options can drive which fields from the global set are displayed.
  • Make fields required based on criteria: in the “old days,” establishing a metadata field as required was a global action. With profiling, values of other metadata selections can determine if a field should be required or not. Administrators can even test against User Information to determine if a field is required; for example, a user has a “User Metadata” field for Department set to Finance. When the user goes to a check-in screen, the content metadata field “Workflow Path” may be required. For users who belong to “Marketing,” this field may be optional.
  • Derived values: metadata field values can be derived based on values from other fields by combining the values of multiple fields, or can even be generated by code triggered by values from other fields.

A New Approach to Unleash the Power

While working on a few of my most recent projects, I’ve started taking a different approach to metadata modeling for Document-centric applications of the Oracle UCM. By working from the outside-in, a model can be built that better drives the user experience.

The following is a simple guideline for building a metadata model without having to waste all of those sticky notes stuck to the wall. While this is specific to the Oracle UCM, it could be modified for other content management applications.

Source 1 - StickySorter Free from OfficeLabs published Novermber 28, 2008 by

Step 1. Determine the types of content that will need unique metadata options. Examples of these may include Marketing, Finance, IT, and Compliance. Content may also have special needs based on the formatting of the content such as images or video files.

Step 2. Create a usage modeling spreadsheet and layout the required fields for each type and what the optional fields will be; include notes on how the field will be used or specific criteria for the fields:

Step 3. Insert all required and optional metadata fields into the Configuration Manager or Metadata tool (note that some fields may already exist as system metadata fields).

Step 4. Determine which metadata field will be used to drive the profiles. It is best to use something like ProfileTrigger.

Step 5. Create Rules for Global Required fields and for Profile-specific required fields.

Step 6. Create Rules for Profile-specific Optional metadata and include any special field handling requirements gathered from usage modeling:



Step 7. Create Profiles for the specific types of content that require different screens and add the appropriate rules:



Step 8. Test the new profiles and validate with the end users.


Final Thoughts

Profiles within Oracle’s UCM allows administrators to create better interfaces for their users while improving the systems capabilities around the metadata it collects for each managed object. If a user is presented with too many fields or has to put too much thinking into the tasks of checking in content or searching for it, they will find ways not to use the system.