In MetaKarta, a glossary is a self-contained and extensible metamodel-based collection of business objects referred to as terms. In turn, the terms may be directly linked (be used to document objects) to objects in the repository, such as tables and columns in a data model, may be associated with data classes to support automatic data class discovery and classification of objects, and also may be semantically mapped to objects throughout the rest of the repository. Once term defined, classified or mapped, the objects will have semantic lineage results such as definition lookups or term semantic usage across any configuration which contains the glossary and mapped or classified objects.
Building a glossary can be as simple as dragging in an existing well documented data model (imported using one of the metadata bridges), imported using a CSV format, or can be populated directly via the user interface. To ensure that the glossary is accurate, up-to-date, available to all who need access to it and integrated properly with the rest of the metadata in the repository, MetaKarta also provides a robust collection of data governance tools and methodologies. The MetaKarta glossary may be managed through a very flexible workflow and publication process that may alternatively be quite sophisticated or quite simple depending upon your needs. In addition, one may maintain any number of business glossaries, each with different workflow and publication characteristics.
Glossary Metamodel and Custom model
The glossary is simply a type of custom model based upon a flexible metamodel. Thus, one may extend/related additional business attribute, object, and relationship types as needed. In addition, associations with other custom models may be defined in the metamodel and then these custom model instances (e.g., glossaries) may be associated.
As the glossary is such an important example of the custom model, this user guide has a specific section for it (what you are reading now). Many of the feature, e.g., workflow, carry over to other custom models, as well.
Workflow processes as applied to object types (terms or acronyms) are detailed in the "glossary" section of the user guide, but can be used for other custom models.
Glossary Object Types
There are three types of objects in the glossary metamodel:
| Glossary Object Type | Description | Impacted by workflow | Contained by |
|---|---|---|---|
| Term | Terminology used generally throughout the architecture | Yes | Glossary rootAnother term |
| Acronym | Acronym (short form) for a term, often used in implementations | Yes | Glossary rootAnother term |
Glossary Terms Hierarchy
A glossary is generally a flat collection of terms, as you may have any number of glossaries, you may include the terminology for particular domains in different glossaries. You may also include terms inside of a term, thus creating a hierarchy of terms.
Glossary hierarchies in the past were represented by folder-like objects called a glossary categories. Currently, though, hierarchies may be built up with terms, in this way those hierarchies may also have all the features of a term.
Glossary Term Associations
Terms may be cross-linked in a wide variety of relationship types, including:
| GlossaryAssociation Type | Description | Effect on inferred name and description assignment | Effect on definition lookup | Effect on semantic usage |
|---|---|---|---|---|
| Synonyms | Terms with nearly identical meaning | N | Yes | Yes |
| See Also | Additional related terms | No | No | No |
| More General | Terms which have a more general context or are a more abstract concept | Yes | Yes | No |
| More Specific | Terms which have a more precise context or are a more specific concept | No | No | Yes |
| Contains | Terms which are considered to contribute to the complete concept, e.g., Name Contains First Name | No | No | No |
| Contained By | Term which is the parent container in which this term is defined, e.g., Street Name is Contained By Physical Address | No | No | No |
| Represents | The relationship between a domain type term and the terms which are expressions of that domain. E.g., Account Amount Available Represents Unified Dollar Amount | No | No | Yes |
| Represented By | The relationship between a term that is an expression of a domain type term. E.g., Unified Dollar Amount is Represented by Account Amount Available | No | Yes | No |
When viewing the semantic usage in the Lineage tab, the List view and the Diagram view do not present the same result set. The List view presents the portion of the semantic definition trace which contributes to the (inferred) Business Name and Business Description of the object. However, the Diagram view shows the complete lineage trace. In this way, you may use the List view to identify how the (inferred) Business Name and Business Description was determined and you may use the Diagram view to see all the lineage impacting related objects.
Simply edit a specific term to do so.
Glossary Workflow
By default, a glossary will have no workflow requirement (including no approval process). In this simple state changes made to the glossary are reflected immediately throughout the system. This is a very useful mode for organizations that do not want the complexity of a workflow process. It is also useful for organizations when they are first building and populating a glossary and related semantic mappings, encouraging rapid building of the glossary and crowd-sourcing.
MetaKarta also provides a very flexible and complete set of possible workflow and publication processes that you may employ. Choose to enforce workflow carefully, as once selected it cannot be undone, though many of the specifics may be changed.
When your company would like to have a formal glossary development process that involves multiple users you can enable the glossary workflow. The workflow is a prepackaged sequence of glossary activities around term proposal, review, acceptance, publishing and/or depreciation. It is a flexible process that can be customized to require only publishing activity, approval with or without review, approval and review by one or multiple users, etc.
The glossary must have a default version before workflow may be enabled.
Workflow object roles
A user with the Workflow Management capability object role assignment on a glossary can enable the workflow and assign the following workflow object roles to one or more terms or the glossary itself:
-
Workflow Editor
-
Workflow Reviewer
-
Workflow Approver
-
Workflow Publisher
A workflow object role can be assigned for any object (term) in the glossary for any user or group.
One must have both the Workflow Editor AND the Metadata Editor capability object role assignment to actually edit terminology for a glossary under workflow. In general this consideration is not important as the default workflow roles which may be assigned are already defined to have the proper metadata capabilities as well as workflow capabilities
Workflow process options
The workflow process applies to all object in a glossary.
When the workflow is enabled, some restrictions apply to the ability to perform certain actions:
-
You cannot delete a term that contains published terms
-
You cannot publish term until its parent is published (when creating them together).
A status of Workflow Published for a term, means whether the term was ever published, it does not mean it is currently in the Published state. If you create a new term and transition it from Draft → Under Review → Approved, you won't see the Workflow Publishe" = true.
A simple and complete workflow process with all possible paths is in the diagram below:
The next diagram presents the workflow in a swim lane diagram with the workflow object capabilities/roles required for each workflow state and action.
You can enable the workflow when you create the glossary or after. You cannot disable the workflow after it has been enabled. However, you may change some of the options.
| Workflow Action | Workflow object role | |||
|---|---|---|---|---|
| Editor | Reviewer | Approver | Publisher | |
| Propose Candidate | X | X | X | X |
| Create Draft | X | |||
| Discard | X | |||
| Start Review | X | |||
| Mark for Deprecation | X | |||
| Submit for Approval | X | |||
| Send to Draft | X | |||
| Recommend Approval | X | |||
| Request Change | X | |||
| Reject (Awaiting Approval) | X | |||
| Approve | X | |||
| Edit (Approved) | X | |||
| Publish | X | |||
| Deprecate | X | |||
| Create, edit or remove attributes and associations | X | X | ||
| Create comments | X | X | X | X |
| Edit or remove comments | X | X | X | |
| Create, edit or remove attachments | X |
Object Management Dashboard
My Workflow Tasks provides an interactive dashboard identifying objects and the actions that need to be taken for business glossaries in a configuration by the logged in user.
Recently Changed Objects provides an interactive dashboard (as part of a worksheet) identifying objects which have changed.
Workflow transition
When working with individual objects which are at some point in the workflow process, workflow transition buttons prompt you with possible actions, e.g., if a term is in Draft status, then the icons would include:
-
Start Review
-
Submit for Approval
-
Mark for Deprecation
-
Discard
Properties Excluded from the Workflow Process
The following properties / addenda are outside of the workflow process:
-
Labels
-
Attachments
-
Curation with comments
Thus, with the appropriate capability object role assignment:
-
Label Editing
-
Attachment Editing
-
Certification Editing
-
Endorsement Editing
-
Warning Editing
-
Comment Editing
you may edit these properties without a workflow transition required.
Versioning and workflow
When you enable workflow MetaKarta creates another version of the glossary named Published. The Published version is the one whose contents are to be presented to most of the users. Its contents are not directly editable (with or without permission). Instead, one edits the contents of Development version and then uses the Publish workflow step to change what is in the Published glossary.
The glossary version you are given access to when using the Browse/Explore/Search/Worksheets/Collections/etc. features is always determined by what your workflow permissions are. In particular, you will have access to:
-
The contents of the Published version the glossary if you do not have any Workflow capability object role assignments, and you will not have any ability to edit the glossary or see current edits and workflow states. You will only see what was published.
-
The contents of the Development version of the glossary if you do not have any Workflow capability object role assignments, and you will have the ability to see glossary object in their current workflow status
In this way, general users are given access to the contents of the Published glossary, and users who are editing the workflow enabled glossary will also be given access to the contents of the Development glossary.
In fact, you will also see a similar behavior in the Repository Manager.
When you expand the glossary to show its versions, you will see both the Published and Development versions, no matter what Workflow capability object role assignments you may have.
In addition, if you open any configuration version containing the glossary, the UI will show that that configuration version contains the:
Published version of the glossary if you do not have any Workflow capability object role assignments,.
Development version of the glossary if you do not have any Workflow capability object role assignments, and you will have the ability to see glossary object in their current workflow status
You will always see this version as the member of any configuration version and trying to assign another version will not be possible. It is entirely system managed and presented to the user this way. It can be a bit confusing to casual users, but generally casual users do not have access to the Repository Manager.
In terms of implementation, it is the Published version of the glossary that is associated with any configuration version, even though you may see a different version in the UI.
Finally, you may associate an archived (historical) version of a glossary with a configuration, thereby making it the Published version for the purposes of presentation.