Skip to content

Managing External Identifiers

Every open metadata instance has a unique identifier called its GUID. This provides a means to locate and retrieve the instance from the metadata repository. However, often the GUID is not known in external systems and tools that integrate with open metadata. Metadata instances that inherit from the Referenceable type have a property called qualifiedName. This is a unique name for the Referenceable instance. When such an instance is created, the qualified name can be set up to be a unique identifier that is a natural unique name for the resource that it represents (such as the full path name of a file) or a unique identifier from an external system or tool. The element can then be retrieved using the qualifiedName.

Now consider the situation where each external system/tool that uses the instance has a different identifier for the instance. There is only one qualified name property in the instance which will not be able to cover all the identifiers from the external systems/tools.

In this situation it is possible to set up multiple external identifiers for an open metadata instance. Each external identifier is linked to the open metadata instance it represents and the software capability of the external system/tool that uses it. You can think of this link to the software capability as providing a scope in which the external identifier is valid.

Synchronizing between an external asset manager an the open metadata ecosystem

Using an integration connector to perform a two-way synchronization between an external asset manager, such as a data catalog or configuration management database (CMDB). In this situation, it is often necessary to use external identifiers to correlate the identifiers between the open metadata and the external asset managers.

The external identifiers can support both one-to-many, many-to-one and many-to-many between metadata elements from external systems/tools and open metadata instances.


Imagine a situation where an external system/tool called myCatalog uses two metadata elements: one for a type it refers to as BusinessTerm and the other of type Example, to represent all the properties that are stored in one open metadata GlossaryTerm.

Many external metadata elements mapping to one open metadata instance

To represent this in open metadata, the unique identifiers for the business term and example metadata elements (gt1 and ex6 respectively) are each stored in their own external identifier that is linked to both the myCatalog's software capability and the corresponding open metadata glossary term. This means the glossary term can be located in an open metadata repository either using the identifier gt1 or ex6. Similarly, it is possible to locate a glossary term's properties in myCatalog by looking up both the gt1 and ex6 elements.


Now imagine the opposite situation: where it takes multiple open metadata instances to represent a single metadata element in an external system/tool. In this example the external system/tool directly links its Database elements to its Table elements. Whereas in the open metadata types, there is a SchemaType (specifically RelationalDBSchemaType) between a DeployedDatabaseSchema instance and the RelationalTable instance.

One external metadata element mapping to many open metadata instances

Again, an external identifier is created for each of the external metadata elements and this is linked to the software capability for myCatalog. Each external identifier is then linked to each of the open metadata instances that have properties that map to its equivalent metadata element in the external system/tool.

The use of external identifiers is particularly important to the integration connectors running in the Open Metadata Integration Services (OMISs), where the ability to maintain consistent metadata stores in both open metadata and third party systems and tools is important.

Open metadata representation

The open metadata types for external identifier are in model 0017. The ExternalIdLink relationship is between the external identifier and the open metadata instance it represents. The ExternalIdScope is the relationship between the external identifier and the software capability that represents the external system/tool.


The Asset Manager OMAS provides support for external identifier mapping on its APIs. This capability is visible through the Catalog Integrator OMIS and the Lineage Integrator OMIS that are based on the Asset Manager OMAS client.

The Open Connector Framework (OCF) provides the ability to query the external identifiers attached to an asset through the connected asset properties. This is also visible through the AssetUniverse interfaces of the:

Back to top