Domain Model
The following figure shows the domain model of the CIVITAS/CORE platform. Every entity in it exists in v2 — concepts that had no implementation behind them were removed from the model rather than carried along as intent.
Several entities are named differently in the implementation, or are realised as an attribute rather than as an entity of their own. The In the implementation column below says which, for every entity, and Where the naming differs at the end of the page collects the renames.
All entities are described in the table below.
| Name | In the implementation | Description | Relations | Synonyms |
|---|---|---|---|---|
| DataCatalog | Catalog — a basic implementation only; it will be extended | Central registry of DataPools and DataSets. | Each DataCatalog contains one or more DataPools. | Catalog |
| DataPool | As modelled | Logical domain grouping datasets and related metadata. Example is "Verkehrsdaten". | Each DataCatalog contains one or more DataPools. A DataPool contains of multiple DataSets. Each DataPool belongs to one Tenant. Previously Datapools were called DataSpaces. | |
| DataSet | As modelled | Structured collection of highly related data with metadata. Examples include "Ladesäulen". A DataSet describes a single information ("Ladesäulen") and references multiple Distributions (i.e. representations) of this information, as well as the transformations that are used to generate those Distributions. | Each DataPool contains of multiple DataSets. Each DataSet has MetaData. Each DataSet may contain multiple Pipelines and Distributions. | |
| MetaData | attributes of DataSet and Distribution, not as an entity of its own; DCAT-AP.DE is produced by the DCAT endpoint. A basic implementation only; it will be extended | Descriptive information about datasets or distributions. This information includes properties defined in DCAT-AP.DE. | MetaData can describe DataSets or Distributions. | |
| Distribution | As modelled | Published or shareable representation of a DataSet. | Each Distribution is described by DistributionMetaData and is based on exactly one DataStructure. | Information Representation |
| PayloadData | Conceptual — the data itself; no registry entity | The actual content of a DataSet conforming to a DataStructure. | Each PayloadData conforms to exactly one DataStructure. | Data payload, Raw data |
| DataStructure | versioned through DataStructureVersion | Defines schema and relationships of data, e.g. PayloadData. | Each DataStructure may have one parent DataStructure. PayloadData that conforms to a DataStructure can be transformed by multiple Transformations. | Schema, Data model |
| DataStructureRepository | the Model Forge artifact registry (ADR 049) | Repository for storing DataStructures and Templates. | Each DataStructureRepository stores multiple DataStructures. | Schema registry, Model registry |
| Persistence | DataSink (FROST, PostGIS) | Mechanism for storing and retrieving data. | PayloadData is stored in one Persistence. | Storage, Source, Target |
| Pipeline | As modelled | Workflow defining a sequence of data processing steps. | Each Pipeline contains one or more Transformations and can be associated with one or more DataSets. | Data pipeline, ETL flow, Flow |
| Transformation | Mapping, held as a Model Forge artifact (ADR 045) | Defines how data is converted between structures. | Each Transformation is typed by one or more DataStructures and belongs to exactly one Pipeline. | Mapping, Conversion |
| DataSource | As modelled | Origin of PayloadData (internal or external). A DataSource is typed by a DataStructure and uses a connector to retrieve the PayloadData. | Each DataSource uses one Connector and belongs to one DataPool. A DataSource may have one ConnectorConfiguration. | Input source, Data provider |
| Connector | the ConnectorType discriminator (MQTT, SQL), not as an entity | Manages data exchange between systems. | Each DataSource uses one Connector, configured by a ConnectorConfiguration. | Adapter, Integration connector |
| ConnectorConfiguration | MQTT and SQL configurations | Configuration of a Connector (e.g., URLs, credentials). | Each DataSource uses exactly one ConnectorConfiguration to configure the used Connector. | Connector setup, Connection config |
| Tenant | As modelled | Organizational entity owning DataPools, DataSets, and users. | Each Tenant contains multiple DataPools, DataSets, Users, and UserGroups. | Organization, Client |
| User | As modelled | Individual with access to data and systems. | Each Tenant contains multiple Users. Each User belongs to one Tenant and can have multiple Assignments linking to Roles. | Account, Person |
| UserGroup | Group | Group of Users for shared permissions. | Each Tenant contains multiple UserGroups. Each UserGroup can have multiple Assignments to Roles. | Group, Team |
| Assignment | As modelled | Links a User or UserGroup to a Role for a specific Scope (i.e. DataPool, DataSet, or Tenant). | Each Assignment connects one User or one UserGroup to one Role. | Role binding, Access assignment |
| Role | As modelled | Abstract role defining access or responsibility. | Each Role can have multiple Assignments. Specialized into DataRole and SystemRole. | Access role, Permission group |
| DataRole | RoleType.DATA on Role, not as a subclass | Grants access to datasets. | Each DataRole grants multiple DataPermissions. | |
| SystemRole | RoleType.SYSTEM on Role, not as a subclass | Grants system-level or administrative privileges. | Each SystemRole grants multiple SystemPermissions. | |
| DataPermission | PermissionType.DATA on Permission, not as a subclass | Permission to access datasets. | Each DataRole grants multiple DataPermissions. | |
| SystemPermission | PermissionType.SYSTEM on Permission, not as a subclass | Permission for system operations. | Each SystemRole grants multiple SystemPermissions. | |
| Scope | ScopeType plus the scope reference on Assignment, not as an entity | A scope defines which resources can be used in the assignment of roles and groups. | Scopes are linked to assignments |
Where the naming differs
| Figure | Implementation | Why |
|---|---|---|
| DataCatalog | Catalog | Shorter, and catalogs nest — a Catalog may contain child Catalogs. |
| UserGroup | Group | Groups carry assignments and nest; they are not limited to users. |
| Persistence | DataSink | The platform writes into a sink; persistence also names the JPA layer, which is something else. |
| Transformation | Mapping | Canonical vocabulary from ADR 060; Mappings are Model Forge artifacts, not portal entities. |
| DataStructureRepository | Model Forge artifact registry | The registry stores every artifact kind, not only Data structures (ADR 049). |
| DataRole / SystemRole | RoleType on Role | A discriminator, not a subclass. The same holds for DataPermission / SystemPermission and PermissionType. |