Taxonomies in Oracle Content and Experience — Part I

In March release (19.1.5), Oracle Content and Experience (OCE) added support for managing controlled vocabulary organized into a hierarchical structure — Taxonomy and using it for content categorization. In OCE, more than one taxonomy can represent controlled vocabulary as “facets” that characterize different dimensions / contexts for content classification. This allowed you to benefit from using faceted navigation to narrow down search of assets in the repository.

July release (19.3.1) enabled taxonomy publishing to make information about taxonomy and content classification with it available for external consumption. This allows you to use taxonomies in OCE not only to classify assets in the repository, but also to have control over displaying content on a website or custom App page. In summary, you can define taxonomy in OCE, categorize assets with it in the repository, then publish taxonomy and assets to make categorization information on assets available via Content Delivery API.

Use Cases

Let’s start conversation about taxonomies in OCE by looking at examples of typical use cases for content categorization:

• Content editors in your organization need ability to quickly and easily find content in the CMS repository to update, publish it, or use as a reference. They often also need ability to mark content items as related to other content, e.g. articles about events or trade show can be related to content created for a specific product.
• Brand manager needs ability to ensure that content items in the CMS repository are assigned to the correct product brands, models or promotions that their team is working on, i.e. mark them as related to a brand, product or promotion.
• Merchandizer in ecommerce enterprise needs ability to associate images, videos, or documents in the CMS repository to the items in their ecommerce store catalog, i.e. mark them as related categories or SKUs in their product catalog.

After content editors, brand managers or merchandizers have associated content items to products or other content items in the CMS repository, you, as a content architect or front-end developer, often have a requirement to display these content items on a website or an App page together with related items, for example:

• A page on The Metropolitan Museum website that displays information about an art object from the Met collection also displays on the same a list of Related Objects (see here) or a list of related Exhibitions on the same page.
• A product page on Oracle website also displays More Insight, Featured, Customer Stories and other content related to the selected product (see here).
• A product page on Amazon site displays Frequently Bought Together, From the Manufacturer, Compare with Similar Items, Product Videos and other sections with content that is related to the product that you selected.

How would you meet such requirements? As a front-end developer, you need ability to manage content retrieval and its positioning on a page or a section on it by using content queries with parameters based on pre-defined relationships between content items, content items and brands, or content items and your targeted audience.

In addition, on a content-rich site, such as ecommerce storefront or customer support site, you often asked to enable faceted navigation to refine content search by allowing visitors to apply filters based on relevant content classification. To meet this requirement, your CMS should not only support content classification, but also allow search queries with facets.

A Traditional CMS Solution

Irrespective of the CMS you use, for content classification, tagging or indexing you need to have a controlled vocabulary which contains the terms that you can use as categories to attribute content in the CMS repository. Controlled vocabulary would be specific to a use case.

In a traditional CMS, controlled vocabulary is typically managed as a collection of lists of values (LOV) representing vocabulary terms. To enable content classification, your content architect needs to add attributes on a content type that are linked to LOVs in this collection — “category” attributes. Such attributes need to be added to all types of content that you need to categorize in the CMS repository.

Content editors will classify content by picking a relevant value from an LOV and assigning it to a “category” attribute on new content they create in the repository or updating existing items to modify values assigned to such attributes as needed.

To create content rendering solution, a front-end developer will need to work with content architect to learn about the “category” attributes added on content types and the terms in LOVs linked to these attributes to support content classification.

Search engine in a traditional CMS typically does not support content indexing with facets. If you have requirement to enable faceted navigation for refining content search results on the site, you need to integrate an external search solution that supports facets.

Cons of a Traditional CMS Solution

Traditional CMS approach to content classification does allow you to build solution for related content use cases described above. Does it provide a flexible solution that allows you to quickly address new business requirements as they evolve with time? I think NOT, as:

1. Any new business requirement for content classification or changes in the product catalogue require content architects to add or remove “category” attributes on content types and then update term in existing LOVs or add new LOVs.
2. After content types are updated, editors need to modify content items in the CMS repository to re-classify content by setting values on the new or updating values on existing attributes.
3. Changes in the content model typically require front-end developers to change page layouts and page rendering logic.
4. Only after contributors and developers completed their work, an update to the content and site can be released.

Even if changes required in content classification are relatively small, such work requires time and resource to complete. You can do better!

Publishable Taxonomies in OCE

The Oracle Content and Experience offers a far superior approach to content classification and building solutions for related content use cases — Publishable Taxonomies:

By making content classification external to content items and allowing publishing taxonomies together with content, OCE eliminates the need to modify content model, update the content in the repository as well as site pages to meet new business requirements for content classification.

If you prefer, you can still use traditional approach to content classification and building solutions for related content use cases in OCE. Your content architects can use the LOVs that represent controlled vocabulary to define attributes on content types in the data model. Editors will use these LOVs to assign values to attributes on content items. Front-end developers will code page layouts against the content model with LOVs. This is tedious…

How Publishable Taxonomies work

I hope, I got your attention… Let’s now look into details of how Publishable Taxonomies feature works in Oracle Content and Experience.

OCE enable you to organize controlled vocabulary of terms that your organization is using for content classification into a hierarchical structure — Taxonomy:

• Terms within a taxonomy have parent/broader term, child/narrower term relations to other terms (aka nodes or categories).
• A category may be repeated at more than one place within the taxonomy.

To create new taxonomy, navigate to Administration > Assets > Taxonomies and use Create action on the gray toolbar. This will open empty taxonomy in the editor which you can use to define a hierarchy of categories.

New taxonomy is created as a draft version. After you are done with changing taxonomy, you should promote it to make it available for use in OCE repositories. Promotion will create v.1 of your taxonomy. If you need to modify it later, new draft will be created. You can add new, remove categories or change their position in the hierarchy. On update promotion, taxonomy v.2 is created and then assets in OCE repositories that use v.1 are automatically re-categorized to account for the category changes.

To make taxonomy and information about assets categorization with it available for external consumption via OCE Content Delivery REST API, you need to publish promoted taxonomy to a channel. You should keep in mind that:

• Delivery API will always operate with current Published version across all channels this taxonomy is published to.
• Publishing taxonomy will NOT trigger publishing of assets that are categorized with it
• Editors can continue classifying content with Promoted version of taxonomy and publish these assets.
• Publishing of the assets will NOT trigger publishing of taxonomy they are categorized with, i.e. neither information about Promoted version, nor about asset categorization with it will be available via Delivery API as taxonomy is not published yet
• After Promoted version is published, Delivery API will make Published version and information about categorization of published assets with it available through all channels that this taxonomy is published to.

Contributors can use Promoted taxonomies to classify content of any type that exist in OCE repository — there is no need for a content type to have specific attributes to allow classification of items of this type. Neither they need to edit content items to classify them — they can simply select several content items, choose categories and assign them to all or selected items

More than one taxonomy can represent controlled vocabulary. If that is the case, you can assign these taxonomies to a repository which will allow contributors to classify assets with categories in several taxonomies. To summarize, an asset can be added to multiple categories in the same taxonomy or multiple categories in multiple taxonomies.

A content architect can create a group of taxonomies to represent “content facets”, whereby each taxonomy characterizes a different dimension/context for content classification:

• You can easily allow faceted classification of content by attaching such group of taxonomies to an OCE repository. Any asset can be added to multiple categories in the same taxonomy or multiple categories in multiple taxonomies.
• Plus, content contributors can benefit from using faceted navigation to narrow down search result by applying category-based filters to quickly find assets they need to use. Faceted navigation is available OOTB in OCE repository.

After assets and taxonomy are published from an OCE repository, information about taxonomy and content classification with it becomes available via OCE Content Delivery REST API:

• You can use this API to get content that is required to render a page or to display related content on this page by running a taxonomy category-based search for content of any type, instead of relying on content types to have attributes that specify content-to-page or content-to-content relationships.
• If taxonomies represent “facets”, you can in addition, use Search in Delivery API to provide support for faceted navigation on your website or in your custom App.

Taxonomies in OCE can be published to different channels, same as content. This allows you to define and use different taxonomies for organizing content depending on the channel this content is published to. For example, on your ecommerce website you can use a “deep” taxonomy to mange displaying product related information. The same content can be displayed using a “shallow” taxonomy on your mobile App. Sweet!

You can find details of Oracle Content and Experience REST API for Content Delivery here and REST API for Content Management here.

PROS of Oracle Content and Experience Solution

Let me now summarize advantages of using Oracle Content and Experience for delivering solution to support related content use cases:

1. Flexible content model — content of any type can be classified and re-classified after business requirements have changed. There is no need for architects to add extra category fields on content types to enable content classification and later change or delete these fields to meet new requirements for content classification.
2. Ease of content classification — there is no need for contributors to edit content to assign categories. Instead, they can select several items, pick one or more categories and assign them to all or selected content items. In a similar way, they can remove categories from the content.
3. Faceted search — support for filtering assets on categories is available OOTB. If taxonomies were defined to represent “facets”, contributors can use faceted navigation to narrow down content by applying facet value-based filters to find items that they need to use. The front-end developers can use the same taxonomies to enable faceted search of published content on a site.
4. Multi-channel categorization — same content can be classified with several taxonomies; each is specific to the delivery channel to which content is published. This allows rendering the same content in a different way depending on the consumption channel.

Summary

By making content classification external to content items and allowing publishing taxonomies together with content, OCE eliminates the need to modify content model, update the content in the repository as well as site pages in order to meet new business requirements for content classification. This allows Oracle Content and Experience to offer you a far superior approach to content classification and building solutions for related content use cases.

In the Part II of this blog post I will explain how you can build a simple blog site with that makes use of OCE REST API for Content Management and Delivery to display related blog posts.