Table of contents

Organizing governance artifacts with categories (Watson Knowledge Catalog)

A category is like a folder or directory that organizes your governance artifacts and the users who can view and manage those artifacts.

Categories provide the logical structure for all types of governance artifacts, except data protection rules. You group your governance artifacts in categories to make them easy to find, to control their visibility, and to manage them. Categories can be organized in a hierarchy based on their meaning and relationships to one another. A category can have subcategories, but a subcategory can have only one direct parent category.

You control which users can view or manage categories and their governance artifacts by adding users as collaborators to categories. You assign category collaborator roles that determine their permissions for the category and their responsibilities to complete assigned tasks in workflows for the category. Subcategories inherit collaborators from their parent categories. However, you can assign more roles to collaborators in subcategories. Therefore, subcategories cannot have more restrictive access than their parent categories. You can easily add all users who have permission to access governance artifacts by adding the predefined All users group to the category.

Watch the following video for an overview of categories.

This video provides a visual method as an alternative to following the written steps in this documentation.

Example of a category structure

Suppose a company that makes parts for energy suppliers wants to set up governance. The Cloud Pak for Data administrator assigns the Manage governance categories permission to Sammy, who is the Chief Data Officer.

Sammy creates these top-level categories:

  • Business units:
    • Has subcategories for different departments, such as Finance, Legal, and Product development.
    • Each second-level category has an executive from the corresponding department as a collaborator with the Owner role.
    • Lower-level categories have data stewards from the corresponding departments as collaborators with the Owner role, plus the All users group with the Viewer role.
    • Most governance artifacts are created in these categories.
  • Geographies:
    • Has subcategories for geographical regions to make it easy to find artifacts by region.
    • Governance artifacts have secondary relationships with these categories.
    • Artifacts are not created in these categories.
    • The All users group has the Viewer role.
  • Supplemental glossary:
    • Has subcategories for types of regulations and other external taxonomies.
    • These categories are used as reference by data stewards when they create business terms under the Business units category.
    • A data steward in the Enterprise data governance department is the Owner of the subcategories. Other data stewards are Viewers in these categories.

The initial category structure looks like this:

Example category structure

Sue is the executive that Sammy added as the Owner of the Product development category. Sue adds these users to the Product development category:

  • Ann, the data steward for her department, with the Admin role.
  • The All users group, with the Viewer role, so that all users who have permission to access governance artifacts can view the category, its subcategories, and its artifacts.

In the Product development category, Sue creates these governance rules to document departmental policies:

  • Information security
  • Information privacy
  • Regulations compliance

Ann creates the Measurement category, and therefore Ann has the Owner role. She also inherits the Admin role in the Measurement category from the Product development category. Sammy, Sue, and All users are collaborators in the Measurement category with their inherited roles.

In the Measurement category, Ann creates business terms that apply to measuring energy in general, such as:

  • Measurement name
  • Measurement type
  • Measurement task

Then, Ann creates two subcategories under the Measurement category:

  • Gas measurement, with these business terms:
    • Gas flow
    • Gas pressure
    • Gas temperature
  • Electric measurement, with these business terms:
    • Frequency
    • Maximum power
    • Minimum power

The following illustration shows these categories, their artifacts, and their collaborators.

Example category structure

When catalog users who are in the All users group find assets with the assigned business term Frequency, the users can see the context for the term in its path: Measurement/Electric measurement/Frequency.

Category collaborators

Category collaborators must have one of these user permissions:

  • Access governance artifacts
  • Manage governance categories

All users with these permissions are in the All users group for categories.

Category collaborators have roles that control which actions they can take within the category:

  • Owner: Manage the category, its artifacts, and its collaborators. Owners can assign any category role, including the Owner role, to other category collaborators.
  • Admin: Manage the category, its artifacts, and its non-owner collaborators. Admins can assign any category role, except the Owner role, to other category collaborators.
  • Editor: View the category and manage its published and draft artifacts.
  • Reviewer: View the category and its published and draft artifacts.
  • Viewer: View the category and its published artifacts.

Category collaborator roles are cumulative down the category hierarchy:

  • A category collaborator can have more than one role assigned.
  • Subcategories inherit the category collaborators with their corresponding roles from all parent and higher-level categories.
  • Collaborators in a subcategory have the roles that they are assigned in the subcategory plus the roles that they are assigned in all higher-level categories.

Viewing a category

You can view a category and its artifacts if either of these conditions is true:

  • You are represented by the All users group and All users is a collaborator in the category.
  • You are a collaborator in the category, either directly or inherited from a parent category.

To view a category, go to Governance > Categories, and then click a category name.

Primary and secondary relationships between categories and artifacts

Categories and artifacts have two types of relationships:

Mandatory. The category owns the artifact and determines who can manage it. Every governance artifact has one primary category that you assign when you create the artifact.
Optional. The category includes the artifact. An artifact can be included in any number of secondary categories. A secondary category is an alternative way to group and discover artifacts.

A category can have both primary and secondary artifacts.

You can view an artifact if you have viewer permission in the artifact’s primary category.

The [uncategorized] category

The [uncategorized] category is created automatically.

The [uncategorized] category differs from other categories in these ways:

  • It can’t be renamed or deleted.
  • It can’t have subcategories.
  • It can’t be assigned as secondary category for governance artifacts.

The [uncategorized] category can be only a primary category for governance artifacts.

By default, the [uncategorized] has these category collaborators:

  • The platform admin user, with the Owner role. The Owner can change the default category collaborators and their roles.

  • The All users group, with the Viewer role.

Categories and workflows

You can configure fine-grained control over governance artifacts by combining categories with workflows. Workflows enforce task-based processes to control the creating, updating, and deleting of governance artifacts. You specify the number of steps in a workflow and who can perform the task for each step. Each workflow controls a combination of categories, artifact types, and actions. Assignees are notified when they must perform a task for a governance artifact that corresponds to a step in the workflow. The assignees for a workflow step can supersede the permissions provided by category roles.

For example, if a workflow step specifies that reviewers for creating an artifact must have the Admin role in the category, then only collaborators who have the Admin role are assignees for that task. A collaborator with the Owner role but not the Admin role is not an assignee, even though the Owner role includes the permission to create artifacts.

Learn more