The data catalog's OCID.
OCID of the user who created this metadata element.
The list of customized properties along with the values for this object
Detailed description of the glossary.
A user-friendly display name. Does not have to be unique, and it's changeable. Avoid entering confidential information.
The unique key of the job definition resource that was used in the Glossary import.
The unique key of the job policy for Glossary import.
Unique glossary key that is immutable.
The unique key of the parent job execution for which the log resource was created.
Status of the latest glossary import job execution, such as running, paused, or completed. This may include additional information like time import started , import file size and % of completion
The current state of the glossary.
OCID of the user who is the owner of the glossary.
The date and time the glossary was created, in the format defined by RFC3339. Example: {@code 2019-03-25T21:10:29.600Z}
The last time that any change was made to the glossary. An RFC3339 formatted datetime string.
OCID of the user who updated this metadata element.
URI to the tag instance in the API.
Status of the approval process workflow for this business glossary.
Full glossary details. A glossary of business terms, such as 'Customer', 'Account', 'Contact' , 'Address', or 'Product', with definitions, used to provide common meaning across disparate data assets. Business glossaries may be hierarchical where some terms may contain child terms to allow them to be used as 'taxonomies'. By linking data assets, data entities, and attributes to glossaries and glossary terms, the glossary can act as a way of organizing data catalog objects in a hierarchy to make a large number of objects more navigable and easier to consume. Objects in the data aatalog, such as data assets or data entities, may be linked to any level in the glossary, so that the glossary can be used to browse the available data according to the business model of the organization.