Skip to content

Open Metadata Archive

An open metadata archive is a portable collection of open metadata type definitions and instances. It can be loaded each time a metadata access server starts up or added to a running metadata access server.

The open metadata archive has three types that are used to signal how the archive is intended to be used:

  • A content pack contains standard metadata that is generally useful. It may come from the Egeria community or third parties. It can be loaded into many repositories, whether these repositories are connected or not via cohorts. This is a useful way to distribute open metadata types or definitions for a standard.
  • A metadata export contains a collection of metadata elements that have been extracted from a specific open metadata repository to load into another. It is used to transfer metadata between repositories that are not connected via cohorts.
  • A repository backup contains a collection of metadata elements that is intended to act as a backup for a server. It typically contains metadata instances from the server's local metadata collection. This archive is expected to be loaded back into the same repository. This can be done at any time. If the repository contains more recent content, the older content in the archive is ignored.

Raise an issue or comment below

Structure of an Open Metadata Archive

The logical structure of an open metadata archive is as follows:

Logical structure of an open metadata archive

Example of the header from the Cloud Information Model archive
{
  "class":"OpenMetadataArchive",
  "archiveProperties":
      {
          "class":"OpenMetadataArchiveProperties",
          "archiveGUID":"9dc75637-92a7-4926-b47b-a3d407546f89",
          "archiveName":"Cloud Information Model (CIM) glossary and concept model",
          "archiveDescription":"Data types for commerce focused cloud applications.",
          "archiveType":"CONTENT_PACK",
          "originatorName":"The Cloud Information Model",
          "originatorLicense":"Apache-2.0",
          "creationDate":1570383385107,
          "dependsOnArchives":["bce3b0a0-662a-4f87-b8dc-844078a11a6e"]
      }, 
   "archiveTypeStore":{},
   "archiveInstanceStore":{}
}

Instances are linked together as follows:

  • Entities are stored as EntityDetail structures.
  • Relationships are stored as Relationship structures and link to their entities through the embedded EntityProxy structure.
  • The entities will include their classifications; however, for classifications that are attached to entities that are not included in the archive, they are stored in an ClassificationEntityExtension structure.

Instance structures in an open metadata archive

Typically, open metadata archives are encoded in JSON format and stored in a file; however, both the format and storage method can be changed by changing the open metadata archive connector.


Raise an issue or comment below

What happens when the archive is loaded into the server

Open metadata archives are introduced into the server through the admin services either:

  1. provided as part of the contents of the server's configuration document, or
  2. through the operational command that added the archive directly into the running server's repository.

Processing of an open metadata archive

The archive is passed to the repository services' operational services, which in turn passes it on to the archive manager. Type information is passed to the repository content manager.

Both the types and instances are passed to the local repository (if there is one).

The archive loads in the following order:

  1. Attribute Type Definitions (AttributeTypeDefs) from the type store, through verifyAttributeTypeDef() and then addAttributeTypeDef():
    1. PrimitiveDefs
    2. CollectionDefs
    3. EnumDefs
  2. New Type Definitions (TypeDefs) from the type store, through verifyTypeDef() and addTypeDef() calls to the local repository:
    1. EntityDefs
    2. RelationshipDefs
    3. ClassificationDefs
  3. Updates to types (TypeDefPatches)
  4. Instances, as reference copies:
    1. Entities
    2. Relationships
    3. Classifications

Cohort propagation

If the server is connected to the cohort, the new content is sent as notifications to the rest of the cohort.


Raise an issue or comment below

Further information

Raise an issue or comment below