Grunddatamodellen (The Fundamental Data Model) is the unified, interlinked data model developed collaboratively by Danish public data authorities. It forms the backbone of Datafordeleren and defines the structure, semantics, and relationships of fundamental datasets that underpin the Danish spatial, administrative, and economic information ecosystem.

Overview

The model consists of interconnected domain models (domænemodeller), each describing a core data registry. The relationships between domains are bidirectional and represent logical dependencies—for example, addresses depend on administrative divisions, which depend on geographical foundations.

Key Resources:


Core Registeries by Domain

Business & Economic Domain (Forretningsregistre)

Registries that capture organizational entities and economic activities.

  • CentraleVirksomhedsregister (CVR) - The central business registry; contains company entities, ownership structures, leadership, production units, accounts, and all relationships between them. Covers all organizations, from one-person businesses to multinational enterprises.

  • Skatteforvaltningens Virksomhedsregister - Tax-administration business registry; contains tax-facing enterprise identities, addresses, names, ownership, leadership, contact channels, operating form, and registration status.

  • Person - Individual persons with their civil registration number (CPR), name, birth date, citizenship, family relations, and other personal identifiers.

Geographic & Cadastral Domain (Geografiregistre & Ejendomsregistre)

Registries that define Danish geography, property, and spatial boundaries.

  • Matrikel - The cadastral register; defines all land parcels with their unique identification (matrikelID), area, usage codes, and spatial extent.

  • DanmarksAdresser (DAR) - The national address registry; contains all valid addresses in Denmark with postal codes, coordinates, and administrative linkages.

  • Stednavne - Place names registry; geographic features, localities, and their official names and classifications.

  • DAGI - Administrative Geography of Denmark; administrative boundaries (municipalities, regions, districts, statistical regions, electoral districts, etc.).

  • GeoDanmark - Fundamental geographic reference data (coastlines, island definitions, administrative boundaries at multiple scales).

  • BygningerOgBoliger - Building and dwelling registry (BBR); buildings, units, floors, entrances, grounds, technical installations, and their property relations.

  • Ejendomsbeliggenhed - Property location and linking registry; connects cadastral parcels (Matrikel) to addresses (DAR) and administrative hierarchies.

Ownership & Rights Domain (Ejendomsrettighedsregistre)

Registries capturing legal relationships to property and cadastral parcels.

  • Ejerfortegnelsen - The ownership register; legal ownership and usufruct rights on cadastral parcels, including persons and organizations.

Spatial Reference & Geodetic Domain

Registries for precise geographic positioning and reference.

  • Fikspunkter - Geodetic reference points; fixed points with precise coordinates for surveying and spatial reference.

Derived & Valuation Domain

Registries computed or assessed from fundamental data.

  • Ejendomsvurdering - Property valuation; assessed values of cadastral parcels for taxation and statistical purposes.

Administrative & Statistical Support

  • DHMOprindelse - Digital Elevation Model origin data; source and metadata for terrain elevation data.

  • HistoriskeKortbladsinddelinger - Historical map sheet divisions; legacy spatial reference grids for map research.

  • Højdekurver - Elevation contour data; topographic representation of terrain.

  • GrunddataTyper - Fundamental data types and classifications; semantic definitions of data categories used across registries.


Design Principles

Bitemporality

Fundamental data registries maintain two temporal dimensions:

  • Transaction Time: When data was recorded in the system (audit trail)
  • Valid Time: When the data truth applies in the real world (lifecycle)

This enables point-in-time queries and historical analysis while maintaining a complete audit log.

Shared Superclass Contract (All Registries)

To avoid repeating common temporal/status logic across every register page, SemanticGIS treats all Grunddatamodellen registries as inheriting a shared superclass contract.

Shared attributes:

  • id
  • registreringFra, registreringTil, registreringsaktør
  • virkningFra, virkningTil, virkningsaktør
  • status

Shared interpretation resources:

Relationships & Dependencies

The Grunddatamodellen explicitly models dependencies between registries:

Danmarks Geografi (Base)
    ↓
DAGI (Administrative Boundaries)
    ↓ ↙ ↖
DAR (Addresses) ← Matrikel (Cadastral Parcels)
    ↓           ↓
Ejendomsbeliggenhed (Linking Registry)
    ↓     ↓
CVR (Companies) ↔ Person (Individuals)

When data changes upstream (e.g., new administrative district), downstream registries may need updates or re-validation.


Accessing Grunddatamodellen

Via Datafordeleren Services

All registries are accessible through standardized services:

  • GraphQL - Query data with flexible field selection
  • OData / REST - RESTful data access
  • WMS/WFS - Web Mapping Services (geographic data)
  • SOAP - Legacy SOAP interfaces (where applicable)

See Datafordeleren Services for details.

Shared Access Strategy

For every normalized Grunddata register:

  1. Declare temporal mode first (current, temporal, bitemporal)
  2. Choose access mode (GraphQL or filedownload)
  3. Reconstruct normalized entity graph to analysis model
  4. Document join quality and temporal assumptions

This shared strategy prevents duplicated and conflicting extraction logic across dataset pages.


Hierarchical Structure Contract

Register folders under the Grunddatamodellen should live under:

  • Datasets by Collection/Grunddatamodellen/<Register>/...

This structure keeps shared contracts at the framework level and register-specific execution guidance at the collection level.

  1. Keep one shared contract layer in Grunddatamodellen/ for time, access, and common data semantics
  2. Let each register page inherit the shared layer and only define register-specific execution rules and joins
  3. Keep concept-heavy interpretation in the leaves, not duplicated in every collection page

This preserves a clear hierarchy while reducing repetitive human-facing documentation at the dataset level.

Via SemanticGIS Project Framework

To build projects grounded in Grunddatamodellen:

  1. Start with Bootstrap Manifest
  2. Define your data sanctuary with source manifests pointing to Grunddatamodellen registries
  3. Use NOIR data semantics to classify fields and validate data quality
  4. Document your data lineage and transformations

Further Reading

20 items under this folder.