DataCatalog - Metadata Schema

As opposed to DataPlatform, DataCatalog provides a client with the opportunity to configure a highly customized metadata schema

DataCatalog supports multiple metadata schemas. What fields are present in the metadata schema is controlled using JSON configuration files. The metadata schema consists of a number of building blocks. These building blocks can be combined to create a complete schema. In DataCatalog, a client has more degrees of freedom in defining their metadata schema, since it's an internal catalog. If a listing is forwarded from DataCatalog to DataPlatform a mapping is applied to map the customer specific metadata schema to the DataPlatform harmonized one. Missing values will be replaced with default one. Please consult Civity for an overview of the mapping for your specific DataCatalog schema.

Setting up a metadata schema for DataCatalog is done by Civity.

Schema building blocks

Although a schema can, in consultation with Civity, be customized depending on a client's needs, the default set up of most DataCatalog clients consists of a number of fundamental building blocks.

CKAN

The first (and only mandatory building block) contains the fields required by CKAN. These include for example a title, description, keywords and a license.

DCAT

The second important building block contains the DCAT fields. Currently, this building block is by far the biggest building block, defining more fields than any other building block. Different DCAT application profiles which can be implemented in DataCatalog have been created for different countries. Currently, DCAT-AP-SE (Sweden) and DCAT-AP-DONL (the Netherlands) are available.

caution

Since a DCAT building block is not mandatory, clients can choose to not include (certain) mandatory DCAT fields in their schema. Be aware that this can lead to mapping issues when certain data gets pushed to DataPlatform, since DataPlatform consists for a large part out of DCAT metadata fields.

NGR

For Dutch customers, a building block to collect the information required by the Nationaal Georegister (NGR), a GeoNetwork instance, is present. The metadata fields in this building block consist of geo-data metadata and are based on ISO 19115.

Customer specific

Last but not least, a customer specific building block is created. Using this building block a) fields can be added, b) optional fields can be disabled, c) default values for the organization which seldom (in which case there is an option to override the default value) or never (in which case the field may be hidden) change can be set, d) the code lists from DCAT can be restricted to codes actually in use by the organization and e) optional fields can be turned into mandatory fields.

User Interface layout

In addition to customizing the schema itself, there is also the possibility to customize the user interface by grouping certain metadata together in the metadata edit screen. These groups can be collapsed or expanded when editing/adding a listing's metadata. In addition, with a checkbox, there is the possibility to only show mandatory fields.

Note

Adjusting the grouping of fields can only be done by Civity