Working with Enumerations

Licensing and Enablement

The availability of any asset collection is determined by what is (a) licensed and (b) configured under Server Administration. To install a license or to view the currently licensed features, see Administrator Guide section on Product Registration` . To configure which licensed collection types are currently enabled or disabled, see Administrator Guide section on EDG Configuration Parameters.

For general licensing information and available asset collections and packages, see the TopQuadrant website.

TopQuadrant Data Governance Packages

Enumeration Asset Collection

TopBraid EDG offers two types of asset collections for storing reference data or codes – Reference Datasets and Enumerations.

Enumerations are suitable for storing multiple, relatively small and simple codesets in a single asset collection. An example may be gender codes or age group codes. For larger and richer sets of codes, use reference datasets.

With enumerations, you do not need to define an entity type in a separate ontology. You can simply:

  • Create an Enumeration asset collection

  • Define Codesets e.g., Gender, Age Group, etc., as Enumeration classes

  • Create enumerated values or codes for each Codeset

Example is shown in the screenshot below.

TopBraid EDG Enumeration Page

TopBraid EDG Enumeration Page

To add a new Enumeration, select New in the Enumerations List Panel.

Enumerated values or codes are added to an enumeration by selecting it in the upper left panel and then clicking New button in the lower left panel which displays enumerated values. In the screenshot above you see two enumerated values for Gender: Female and Male.

The panel on the right displays the asset you select from the left side panels – either an enumeration or an enumerated value. This is the default layout for enumerations. You can also switch to one of alternative layouts.

For each enumeration you will be able to enter its description using a “comments” field. For a value in the enumeration set, you will be able to capture information described in the table below:

Property Name

Type of Values

Number of Possible Values for a Property


Enumerated Value Properties

This is the main group of property values




Value of the code for a given enumerated value AKA member of an enumeration. For example, M can be a code for Male, 1 can be a code value for January. Since it uniquely identifies an enumerated value within a given enumeration, we will typically refer to an enumerated value as the code.


HTML or string or language string


Optional verbal definition.


string or language string


This is a label for a code. For example, a code may be M for Male. The label would be ‘Male’.


string or language string


Optional machine-readable string for how the enumerated value can be referred to. This can be used when the code value is numeric – as an alternative to using a code. Literal is not the same as label which is intended for human readable display. For example, a code for January may be 1, literal may be ‘J’ or ‘Jan’ and label is ‘January’.




Optional value. Enumerations are often application-specific and this field can capture an order of display of enumerated value in a context of an application. It can also be used to capture ordinality to support comparison and calculations needed to answer requests like “all results for age groups higher than teenagers”. Even when an enumerated value has a numeric code, an order may still be needed because a code number does not necessarily imply natural order or ranking that could be used in calculations.


All fields in this section are optional.


Asset Status


Optional status value for a code. Selection comes from the EDG Enumeration called Asset Status.

superseded by



Optionally, lets you link to the previously used code.

effective end date



Optionally, specifies a date after which a code should no longer be used.

effective start date



Optionally, specifies a date when one can start to use a code.




An optional link to issues.


In addition to the enumerations users define as assets they manage, there are also built-in EDG enumerations such as Asset Status or Confidentiality Level. Values for these enumerations are managed by your EDG Administrator using a special EDG Enumerations asset collection. Values of these enumerations are available for selection within any EDG asset collection.

When should you use an enumeration asset collection versus a reference dataset? The decision is up to you, but here are some best practices:

  • If you have a large number of codes in a specific enumeration, use a reference dataset. Enumeration collection is designed to store relatively small codesets – typically less than 20 per enumeration and often less than 10.

  • If you need to have custom properties for your code values that differ between enumerations, use reference dataset. An example, may want to have Location Codes that will have latitude and longitude values while Gender Codes will not have them. Enumeration collection is designed to store simple, generic codesets that typically a) share the same properties across all enumerations and b) only have pre-defined properties listed above.

  • If you want to define definitive enterprise-wide set of codes for a specific entity such as Gender, you may want to create a separate reference dataset for this purpose. Enumeration collection is better aligned with storing application specific set of codes. For example:

    • You may have application A that uses gender codes, age group codes, marital status codes, etc. Application B also has codes for some or all of these entities.

    • You may create two enumeration collections – enumerations for A and enumerations for B.

    • You may also create an enterprise-wide reference datasets for genders and marital statuses and map application specific codes to the enterprise codes.

    • Alternatively, you could also create an enumeration collection for enterprise-wide codesets. Typically, enterprise-wide codesets tend to be larger than an application specific set of codes for the same entity because they need to align and accommodate a broader range of use cases.

The primarily advantage of using enumeration collection is that all the properties are predefined. You do not need to create and use an ontology for a reference dataset. On the other hand, all the enumerations in a single collection share the same life cycle for updates, publishing and permissions. Thus, reference datasets provide more flexibility for definition and management of codesets.

Enumerations such as Gender and Age Group are classes. While it is possible to add properties for these classes directly in an enumeration collection, we advise against using this practice. A recommended practice is for all enumerations to have the same set of properties. While EDG pre-defines properties you will likely need, you can extend them. If you need to modify common properties for enumerations, we recommend creating an ontology, customizing Enumeration class ( edg:CustomEnumeratedValue class) and including this customization by default in all enumeration collections.