Annotations

Using annotations, the application can be configured and adapted to customer requirements. Existing element types and their properties can be modified and new, customer-specific properties can be added.

Tooltip

All default element types and properties that can be modified using annotations are described in the metamodel. The metamodel documents all element types and properties in dataspot and can be accessed in the predefined database meta.

Annotations have an immediate impact on the user interface and in all programming interfaces (metadata REST/API, metadata upload/download). In the user interface, modified properties and new, customer-specific properties are displayed in the respective elements as input fields. New properties are also taken into account in the programming interfaces during import and export.

Annotations are specified in YAML (. YAML, . YML). YAML is a simplified markup language, based on XML, and designed for human-readability. In YAML, data structures are represented exclusively with key/value pairs (associative arrays), lists and scalars.

Note

Only users with the access level Administrator are authorized to edit annotations on the tenant page.

Configuration

Existing element types and their properties can be modified in YAML. New, customer-specific properties can be added to existing element types.

Element type

Note

Element type names are written in UpperCamelCase.

First, the name of the element type (according to the metamodel) is specified at the top level. The element type can then be modified using the appropriate keys.

# Rename element type 'BusinessAttribute' and change icon
BusinessAttribute:
  label: Property
  icon: wrench

Tooltip

The key label changes the label of the element type. The key icon changes the displayed icon.

Tooltip

A detailed description of all keys can be found here.

Property

Note

Property names are written in lowerCamelCase.

Existing properties of an element type can be modified with the key properties. Following properties, the name of the property (according to the metamodel) is specified.

# Rename existing property 'title'
BusinessAttribute:
  properties:
    title:
      label: Caption

New, customer-specific properties can be added to an existing element type with the key customProperties. Following customProperties, the name of the new property assigned. This name must uniquely identify the property and may not conflict with other existing properties of the element type.

Note

The technical name of a custom property must start with a letter, : or _ and may further only contain letters, digits, ., :, - or _ but no spaces or other special characters (/, &, ?, <, >, +, =, etc.).

# New properties 'confidentiality' and 'priority'
BusinessAttribute:
  customProperties:
    confidentiality:
      label: Confidentiality
      baseType: STRING
    priority:
      label: Priority
      literals:
        LOW:
          label: Low
        MEDIUM:
          label: Medium
        HIGH:
          label: High

Tooltip

The key baseType defines the data type of the property. The key literals defines a list of valid values. In the user interface, these values are displayed in a dropdown list.

New properties become part of the metamodel. In the user interface, they are displayed as input fields for the respective element. New properties are also taken into account in the programming interfaces during import and export.

Tooltip

Element types can be stereotyped with the key stereotype. The key customProperties then defines distinct, customer-specific properties for each stereotype.

Note

In YAML, each level must be indented with two spaces.

An element type may only occur once in the configuration. All customizations of the element type should be done there.

Attention

If customer-specific properties are deleted, it must be ensured that the affected properties are empty before deletion. This is particularly important for stereotypes, as otherwise there may be problems in processing.

Multi-tenancy

The configuration of a base tenant is inherited to all subordinate tenants, i.e. all subordinate tenants adopt the configuration of their base tenant.

A subordinate tenant cannot delete the inherited configuration of the base tenant, but can extend or overwrite it:

The configuration of the subordinate tenant can add new properties.
The configuration of the subordinate tenant can overwrite properties already defined in the base tenant.

Note

On the tenant page of a subordinate tenant, the tenant annotations and tenant profiles of the base tenant are displayed but cannot be edited.

Tenant profiles of the base tenant can be assigned to models of the subordinate tenant.

Element types

Tooltip

The metamodel describes all element types.

The following list specifies all relevant, concrete element types that can be configured. The element types are grouped according to the model types in which they occur:

Name	Label (`labelEn`)
`BusinessDataModel`	Business data model
`BusinessObject`	Business object
`BusinessAttribute`	Business attribute
`Relationship`	Relationship
`BusinessConstraint`	Business constraint

`MeasuresCatalog`	Measures catalog
`Measure`	Measure
`Dimension`	Dimension
`Dimensioning`	Dimensioning

`DataCatalog`	Data catalog
`Dataset`	Dataset
`SubDataset`	Subdataset
`Distribution`	Distribution
`Composition`	Component

`ReferenceDataModel`	Reference data model
`ReferenceObject`	Reference object
`ReferenceValue`	Reference value
`Mapping`	Mapping
`Translation`	Translation

`SystemCatalog`	System catalog
`System`	System
`Subsystem`	Subsystem

`ProcessingRecords`	Processing directory
`Processing`	Processing
`Usage`	Usage

`ProjectDirectory`	Project directory
`Project`	Project
`Subproject`	Subproject
`Usage`	Usage

`DataDomainModel`	Data domain model
`DataDomain`	Data domain

`QualityModel`	Quality model
`Indicator`	Indicator
`Application`	Assignment
`Measurement`	Measurement

`UmlModel`	Data model
`UmlClass`	Data object
`UmlAttribute`	Attribute
`UmlAssociation`	Relationship
`UmlOperation`	Operation
`UmlParameter`	Parameter
`UmlDatatype`	Data type
`UmlEnumeration`	Enumeration
`UmlLiteral`	Literal
`UmlConstraint`	Constraint

`DxOrganization`	Organization
`Role`	Role
`Post`	Post
`Group`	Group
`Person`	Person
`Task`	Task

`Tenant`	Tenant
`User`	User
`Workflow`	Workflow
`Issue`	Issue
`Approval`	Approval
`Discussion`	Discussion

In addition, there are element types that cannot be associated with a single model type, but occur in different models:

Name	Label (`labelEn`)
`Collection`	Collection
`Attribution`	Attribution
`Derivation`	Derivation
`Deployment`	Deplyoment
`Dependency`	Dependency
`Transformation`	Transformation
`Rule`	Rule

Hierarchy

The metamodel describes a hierarchy of element types. In this hierarchy, concrete element types (e.g. BusinessDataModel, BusinessObject, BusinessAttribute or Group) are derived from abstract element types (e.g. Scheme, Classifier, Attribute or Agent). The concrete element types inherit the properties from the abstract element types (e.g. BusinessDataModel inherits from Scheme, BusinessObject inherits from Classifier, BusinessAttribute inherits from Attribute and Group inherits from Agent).

Note

Annotations can be defined for abstract element types. All concrete element types derived from these abstract element types also inherit their annotations.

The following list specifies some abstract element types and their derived, concrete element types:

Abstract element type	Derived, concrete element type
`Classifier`	`BusinessObject` `UmlClass`
`Attribute`	`BusinessAttribute` `UmlAttribute`
`Association`	`Relationship` `UmlAssociation`
`Constraint`	`BusinessConstraint` `UmlConstraint`
`Enumeration`	`ReferenceObject` `UmlEnumeration`
`Literal`	`ReferenceValue` `UmlLiteral`
`Scheme`	`BusinessDataModel` `ReferenceDataModel` `MeasuresCatalog` `DataCatalog` `QualityModel` `ProjectDirectory` `ProcessingRecords` `DataDomainModel` `SystemCatalog` `UmlModel`
`Ticket`	`Issue` `Approval` `Discussion`

Note

The entire hierarchy of configurable element types, including all abstract and concrete element types and their derivatives, is described in the metamodel.

A specific distinction can be made as to whether a concrete element type (e.g. BusinessDataModel) or an abstract element type (e.g. Scheme) - including all derived element types - should be configured.

# Customer-specific property 'confidentiality' in all models
Scheme:
  customProperties:
    confidentiality:
      label: Vertraulichkeit
      labelEn: Confidentiality

# Customer-specific property 'priority' only in business data models
BusinessDataModel:
  customProperties:
    priority:
      label: Prioriät
      labelEn: Priority

Status

Each metadata object has a specific status within a workflow. During processing, transitions occur from one status to another. Using annotations, the available statuses can be modified or removed or new, customer-specific status can be defined.

Each status is assigned to one of the following groups:

Asset:
  properties:
    status:
      groups:
        DRAFT:
          label: Entwurf
          labelEn: Draft
        NOT_PUBLIC:
          label: Nicht öffentlich
          labelEn: Not Public
        PUBLIC:
          label: Öffentlich
          labelEn: Public

Metadata objects, whose status is from the group DRAFT, are only visible to administrators and editors. The latest published version is visible to read-only users.
Metadata objects, whose status is from the group NOT_PUBLIC, are only visible to administrators and editors. The latest published version is not visible to read-only users.
Metadata objects, whose status is from the group PUBLIC, are visible to all users.

By default, the following statuses are defined:

Asset:
  properties:
    status:
      literals:
        WORKING:
          label: In Arbeit
          labelEn: Working
          title: Noch in Arbeit bzw. in Überarbeitung
          titleEn: Work in progress or in revision
          icon: wrench
          order: 0
          group: DRAFT
        SUBMITTED:
          label: Abgestimmt
          labelEn: Submitted
          icon: scale-balanced
          order: 1
          group: DRAFT
        ACCEPTED:
          label: Abgenommen
          labelEn: Accepted
          icon: gavel
          order: 2
          group: DRAFT
        FINAL:
          label: Finalisiert
          labelEn: Final
          icon: badge-check
          order: 3
          group: NOT_PUBLIC
        PUBLISHED:
          label: Veröffentlicht
          labelEn: Published
          icon: globe
          order: 4
          group: PUBLIC
        INACTIVE:
          label: Inaktiv
          labelEn: Inactive
          icon: solid-do-not-enter
          order: 5
          group: NOT_PUBLIC
          inactive: true
        REJECTED:
          label: Abgelehnt
          labelEn: Rejected
          icon: thumbs-down
          order: 6
          group: DRAFT
          inactive: true

Note

The key inactive marks a status as inactive. Inactive status are displayed accordingly in the user interface.

Status	Group	Visibility of metadata objects
`Working`	`DRAFT`	Metadata objects are visible to administrators and editors. The latest published version is visible to read-only users.
`Submitted`	`DRAFT`	Metadata objects are visible to administrators and editors. The latest published version is visible to read-only users.
`Accepted`	`DRAFT`	Metadata objects are visible to administrators and editors. The latest published version is visible to read-only users.
`Final`	`NOT_PUBLIC`	Metadata objects are visible to administrators and editors but not visible to read-only users.
`Published`	`PUBLIC`	Metadata objects are visible to all users.
`Inactive`	`NOT_PUBLIC`	Metadata objects are visible to administrators and editors but not visible to read-only users.
`Rejected`	`DRAFT`	Metadata objects are visible to administrators and editors. The latest published version is visible to read-only users.

In order to customize the existing status or add new, customer-specific status, the key literals must be extended or modified accordingly in the property status in the element type Asset.

Attention

If a status is deleted, it must be ensured that the status is removed from all workflows before deletion.

Theme

Each theme can be customized. It is possible to select the underlying color scheme, define the colors of selected screen components (e.g. sidebar, status colors) and change the font.

Note

It is only possible to customize the existing standard themes LIGHT (Light), DARK (Dark) und CVD (Color vision deficiency). It is not possible to add new themes.

Theme:
  instances:
    LIGHT:
      label: Hell
      labelEn: Light
      icon: sun-bright
      order: 1
      appFont: Nunito Sans
      sidebarBackgroundColor: "d1dfe2"
      sidebarBorderColor: "dcdcdc"
      sidebarHeaderColor: "656565"
      sidebarHeaderHoverColor: "464646"
      sidebarButtonColor: "464646"
      sidebarButtonHoverBackgroundColor: "84b2ba"
      sidebarButtonActiveColor: "ffffff"
      sidebarButtonActiveBackgroundColor: "096574"
      statusDraftColor: "a24372"
      statusPublicColor: "1b5860"
      statusNotPublicColor: "49506c"
      statusInactiveColor: "ff6347"
      statusNoneColor: "98661f"
    DARK:
      label: Dunkel
      labelEn: Dark
      icon: moon
      order: 2
      appFont: Nunito Sans
      sidebarBackgroundColor: "03353d"
      sidebarBorderColor: "323232"
      sidebarHeaderColor: "9fa6ad"
      sidebarHeaderHoverColor: "cdd7e1"
      sidebarButtonColor: "cdd7e1"
      sidebarButtonHoverBackgroundColor: "076574"
      sidebarButtonActiveColor: "464646"
      sidebarButtonActiveBackgroundColor: "d1dfe2"
      statusDraftColor: "d384b0" 
      statusPublicColor: "84b2ba" 
      statusNotPublicColor: "b7a9d6" 
      statusInactiveColor: "db9180"
      statusNoneColor: "b6876a"
    CVD:
      label: Farbsehschwäche
      labelEn: Color vision deficiency
      icon: eye-slash
      order: 3
      appFont: Inter
      sidebarBackgroundColor: "272727"
      sidebarBorderColor: "323232"
      sidebarHeaderColor: "9f9f9f"
      sidebarHeaderHoverColor: "cdcdcd"
      sidebarButtonColor: "cdcdcd"
      sidebarButtonHoverBackgroundColor: "1a1a1a"
      sidebarButtonActiveColor: "464646"
      sidebarButtonActiveBackgroundColor: "d1d1d1"
      statusDraftColor: "b5889b"
      statusPublicColor: "6a8fda"
      statusNotPublicColor: "b4b3ef"
      statusInactiveColor: "db9180"
      statusNoneColor: "b6876a"
      colorScheme: DARK

Note

Colors are specified as RGB values (hexadecimal color code). It is recommended to specify the RGB values with double quotes.

It is possible to overwrite individual keys without changing the other settings.

Theme:
  instances:
    CVD:
      appFont: Lato

The following keys can be customized:

Key	Description
`label`, `labelEn`	The label of the theme in the menu.
`icon`	The icon of the theme in the menu.
`order`	The ordinal number used for sorting the themes in the menu.
`appFont`	The application font [`Inter`,`Lato`,`Noto Sans`, `Nunito Sans`].
`sidebarBackgroundColor`	The background color of the sidebar and the buttons in the menu bar.
`sidebarBorderColor`	The border color of the sidebar and the buttons in the menu bar.
`sidebarHeaderColor`	The font color of the titles in the sidebar.
`sidebarHeaderHoverColor`	The font color of the titles in the sidebar when hovered.
`sidebarButtonColor`	The font color of the buttons in the sidebar and menu bar.
`sidebarButtonHoverBackgroundColor`	The background color of the buttons in the sidebar and menu bar when hovered.
`sidebarButtonActiveColor`	The font color of the selected buttons in the sidebar.
`sidebarButtonActiveBackgroundColor`	The background color of the selected buttons in the sidebar.
`appBarBackgroundColor` (deprecated)	The background color of the menu bar.
`appBarColor` (deprecated)	The font color of the menu bar.
`statusDraftColor`	The color for assets in publication state draft.
`statusPublicColor`	The color for assets in publication state public.
`statusNotPublicColor`	The color for assets in publication state not public.
`statusInactiveColor`	The color for assets in an inactive status.
`statusNoneColor`	The color for elements without a status.
`colorScheme`	The underlying color scheme [`LIGHT`,`DARK`].

Note

The key colorScheme can only be changed for the theme CVD (Color vision deficiency).

Note

For compatibility reasons, the keys appBarBackgroundColor and appBarColor (deprecated), if present, are automatically converted to the keys sidebarButtonColor, sidebarBackgroundColor, sidebarHeaderColor, etc. and overwrite their explicitly set values, if any. To be able to explicitly set the keys sidebarButtonColor, sidebarBackgroundColor, sidebarHeaderColor, etc. the keys appBarBackgroundColor and appBarColor must be removed.

The input fields of the login dialog can be customized by specifying the properties loginId and password of the element type User in the default tenant.

The key label (or labelEn) defines the label displayed next to the input field in the login dialog.
The key title (or titleEn) defines the description displayed as a tooltip above the input field in the login dialog.

# Customer-specific login dialog
User:
  properties:
    loginId:
      label: Login-ID
      labelEn: Login ID
      title: Die Benutzerkennung des Benutzers
      titleEn: The login ID of the user
    password:
      label: Passwort
      labelEn: Password
      title: Das Passwort des Benutzers (mind. 8 Zeichen)
      titleEn: The password of the user (min. 8 characters)

Configuration​

Element type​

Property​

Multi-tenancy​

Element types​

Hierarchy​

Status​

Theme​

Login Dialog​

Configuration

Element type

Property

Multi-tenancy

Element types

Hierarchy

Status

Theme

Login Dialog