Skip to content


An asset is a metadata element that describes either a digital or physical resource. This resource is described in a metadata catalog because it provides value to the organization that owns it. Examples of resources that might be catalogued as assets include:

  • Data sources such as databases, files and data feeds.
  • IT infrastructure and applications that automate many aspects of an organization's operation.
  • APIs that provide access to the services offered by the organization.
  • Analytical models and processes.
  • Addresses and other locations.
  • Physical objects such as buildings that can have a digitized representation with a unique identity (for example, serial number).

Governance activities are often centered around an organization's resources since they represent tangible value. This involves maintaining information about the resource and managing events related to the resource in order to keep it protected and to get the maximum value from it.

Egeria is particularly focused on maintaining the information necessary for managing digital resources and the infrastructure that supports them. It also has a flexible type model to allow the definition of asset to be expanded to include new kinds of resources as they become relevant.

Open metadata types

The information about a resource is stored as a linked collection of open metadata instances (entities and relationships) with the Asset entity at the root. The asset entity contains a small amount of information that merely captures the existence of the resource. Then other entities are linked to it to add more information. It is likely that this additional information is identified, captured and stored by different tools. The open metadata services gather this information together and distribute it to provide the most complete view of the resource's properties.

More information on the types of attachments that can be added to an asset can be found in Managing Metadata.

Inheriting from asset is a hierarchy of increasingly-specialized definitions for different types of assets. Each definition adds more properties about the asset:

Figure 1

Figure 1: Hierarchy of asset types defined in the open metadata types

Area 2 of the open metadata types of the open metadata types is where the asset hierarchy is built out.

Accessing asset content through connectors

Egeria provides an open framework for accessing the content of digitized resources and the information about them. It is called the Open Connector Framework (OCF) and it provides specialized connectors (clients) for accessing specific types of assets and the information about them.

The type of connector to use is specified in the connection that is linked to the asset.

Model 0205 in the open metadata types shows how an asset is associated with a connection object. The connection object provides the properties necessary to create a connector to access the asset's contents.

APIs and events for managing asset information (metadata)

Egeria's Open Metadata Access Services (OMAS) provide the specialized services for managing assets. Each OMAS focuses on a particular part of the asset lifecycle or person/tool that is working with the assets.

Some examples:

OMAS Description
Analytics Modeling OMAS enables business intelligence and data virtualization tools to maintain information about the data views and reporting assets they are maintaining.
Asset Catalog OMAS provides a search service for locating assets.
Asset Consumer OMAS provides a service for accessing the content of an asset, extracting additional information that is known about the asset and providing feedback about the asset. It is designed for tools that consume assets to support the work of their users. These users can provide feedback on the asset description and the resource that it describes.
Asset Manager OMAS provides a service for exchanging metadata about assets and related information with a third party asset manager. This API supports the many-to-many correlation of identifiers used in the third party asset manager and the open metadata ecosystem.
Asset Owner OMAS provides a service for the owner of an asset to classify and manage the asset, and understand how it is being used by the organization.
Discovery Engine OMAS provides a service for adding annotations to an asset's information that has been determined by specific analysis of the asset's contents by a discovery service.
Data Manager OMAS enables a data manager (such as a database or file system) to maintain information about the assets it stores.
Governance Engine OMAS provides the metadata services for governance action services that verify, enhance and correct the properties of assets and their associated elements.
IT Infrastructure OMAS provides a service for maintaining information about the IT assets and supporting infrastructure owned or used by an organization.
Data Science OMAS provides a service for maintaining information about analytical models and related assets such as python notebooks.

Figure 2

Figure 2: Example of the type of information that can be attached to an asset

Sharing information about assets

Egeria's Open Metadata Repository Services (OMRS) provides the ability to store and extract information about assets in a distributed collection of servers called an open metadata repository cohort. The cohort provides both peer-to-peer exchange of metadata via an event bus topic and federated queries between different members of the cohort. Egeria provides a metadata access server, a metadata access point and a repository proxy server that are all able to join a cohort. The repository proxy supports the integration of third party servers (typically asset managers) into the cohort. The mapping between the third party server's APIs and the open metadata APIs in this case is implemented in an repository connector.

It is also possible to manage the exchange of asset metadata with other types of third party technologies using the Open Metadata Integration Services (OMISs) running in an integration daemon. Using this pattern is simpler to integrate but involves maintaining a copy of the third party technology's metadata in a metadata access store that can then join one or more open metadata repository cohorts to share this metadata more broadly. The mapping between the third party technology's APIs and the open metadata APIs in this case is implemented in an integration connector.

Back to top