Originally posted by Troy Allen on CMSWire on May 11, 2011.
Abstract: This article provides an overview of utilizing Metadata Profiles within the Oracle WebCenter Content (formally known as Oracle UCM Server).
Oracle Content Management (UCM) Metadata Profiles
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.
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.