Configuration
Breadcrumbs

Metamodel and Metadata Templates

The metamodel in Anjana Data constitutes the conceptual foundation on which the various data and information assets of the organization are governed. Its configuration allows explicitly defining:

  • The entities that will be managed (e.g. datasets, reports, AI models, business terms).

  • The relationships between those entities (e.g. trained with, composed of, used).

The correct definition of the metamodel is fundamental for:

  • Representing the reality of data in the organization in a clear and structured way.

  • Establishing a common framework that supports governance and asset management processes.

  • Ensuring consistency in navigation, search, lineage, and auditing within the Data Portal.

This section details the steps and considerations necessary to configure the different components of the metamodel:

  • Entity sub-types: definition of the types of objects to be governed (e.g. datasets, reports, AI models, business terms).

  • Relationship sub-types: definition of the links between entities that reflect dependencies, hierarchies, or associations (e.g. trained with, composed of, used).

Together with the metamodel, metadata templates allow parameterizing the way data assets and their relationships are described and documented in the platform. These templates include the creation and adjustment of:

  • Menus and sections to structure information.

  • Attributes of various types (text, numeric, taxonomies, lists, etc.).

  • Validations and versioning rules that ensure quality, consistency, and impact control in data management.

Important notes

  • The metamodel should remain relatively stable over time, as it reflects the semantic and business logic of the organization.

  • Changes to the metamodel structure can directly impact:

    • The history of governed assets.

    • The data lineage.

    • The configured workflows.

    • The permissions configuration.

    • The user experience in the Data Portal.

  • Anjana Data includes a native metamodel that provides logic and support for the platform's own functionalities.

Anjana Data native metamodel

Anjana Data includes a native metamodel that defines a set of entities and relationships with internal logic within the platform. This metamodel provides the minimum foundation necessary for the data portal to function consistently from the start and for administrators to extend and adapt it according to the organization's governance needs.

Native entities

The entities natively governed in Anjana Data are:

  • DATASET: A set of structured, semi-structured, or unstructured data —persistent or transient— that can represent database tables, files in data lakes, documents, images, audio, or video.

  • DATASET_FIELD: A field or column of a structured dataset, with its own metadata, that allows governing data at the level of individual attributes.

  • DSA (Data Sharing Agreement): a data sharing agreement or contract.

  • PROCESS: a business or technical process that manages data.

  • INSTANCE: a specific execution or instance of a process.

  • SOLUTION: a solution or application that groups and manages instances and processes.

Native relationships between native entities

The native metamodel also includes the following predefined relationships:

  • STRUCTURE: between a dataset (source) and its dataset fields (target).

  • DSA_CONTENT: between a DSA (source) and the entities it contains (target).

  • ADHERENCE: between a DSA (source) and a User (target).

  • INSTANCE_PROCESS: membership of an instance (target) to its process (source).

  • INSTANCE_DATASET_IN: between an instance (target) and the datasets it reads from (source).

  • INSTANCE_DATASET_OUT: between an instance (source) and the datasets it writes to (target).

  • SOLUTION_RELATED_INSTANCE: between a solution (source) and its related instances (target).

  • SOLUTION_OWNED_INSTANCE: membership of an instance (target) to its owning solution (source).


Important note:

  • These entities and relationships are part of the native core of Anjana Data and provide the logic necessary for basic platform functionalities such as search, lineage, and adherence control.

  • The administrator can extend and customize the metamodel by incorporating new entities, relationships, and rules, always respecting consistency with this base metamodel.

Configuration order for the metamodel and metadata templates

Once the native metamodel of Anjana Data (predefined entities and relationships) is understood, it is important to follow a logical order when configuring the extended metamodel and the metadata templates.

The recommended process is as follows:

  1. Metamodel – Entities and relationships: definition of the object sub-types (entities and relationships) that will make up the metamodel.

  2. Template menus: creation of the top-level main blocks that organize information in dynamic forms.

  3. Template sections: configuration of sub-sections within each menu, which allow grouping related attributes.

  4. Metadata attributes: definition of the attributes that describe entities and relationships, reusable across different templates.

  5. Reference values: parameterization of the available values for selection-type attributes (lists, taxonomies, icons, etc.).

  6. Assignment of attributes to templates: inclusion of attributes in the corresponding sections of each template.

  7. Validations on templates: definition of rules to ensure consistency and restrictions on attributes.

  8. Relationships between reference values: establishment of dependencies between reference attribute values or hierarchical structures in taxonomies.

  9. Versioning rules: configuration of the changes that generate a new version of the governed objects.

  10. Exception rules for workflow triggering: definition of exceptions that prevent approval workflows from being triggered on specific modifications or versioning events.

In this way, an ordered, consistent, and sustainable configuration of the metamodel and metadata templates is ensured.