Here we document the model-level mapping between DDI and DCAT, or more precisely from the different DDI products (Codebook, Lifecycle and CDI) to DCAT.
Since the aim is to produce metadata conforming to DCAT profiles, the document is organized according to the DCAT model. Each main section corresponds to a DCAT class, and is further divided according to the DDI product which is source of the mapping.
The DCAT model is detailed in the Recommendation; a summary view of its structure is given below.
---
config:
layout: elk
title: DCAT v3
---
classDiagram
Resource <|-- Dataset
Resource <|-- DataService
Resource <-- Relationship
Relationship <-- Resource
Distribution <-- Dataset
DataService <-- Distribution
Dataset <-- DataService
Dataset <|-- DatasetSeries
DatasetSeries <-- Dataset
Resource <-- CatalogRecord
CatalogRecord <-- Catalog
Resource <-- Catalog
Dataset <-- Catalog
DataService <-- Catalog
Catalog <-- Catalog
The DCAT Recommendation defines the Resource class by: "This class carries properties common to all cataloged resources, including datasets and data services". This class is mainly useful to catalog resources that are not datasets or data services, so we may ignore it in this mapping exercice. However, it bears a great number of properties that are inherited by Dataset and DataService. These properties will be studied in the next section.
The DCAT Recommendation defines the Dataset class as a "collection of data, published or curated by a single agent, and available for access or download in one or more representations".
What DDI-L class corresponds to the DCAT Dataset?
How do we obtain the Dataset properties from DDI-L metadata? We can start with the properties that are actually used (recommended or mandatory) in well-established profiles like DCAT-AP. These are:
| Property | Range | DCAT-AP status |
|---|---|---|
| dct:title | rdfs:Literal | mandatory |
| dct:description | rdfs:Literal | mandatory |
| dcat:contactPoint | vcard:Kind | recommended |
| dcat:keyword | rdfs:Literal | recommended |
| dcat:theme | xkos:Concept | recommended |
The DCAT Recommendation defines the Distribution class as follows:
"A specific representation of a dataset. A dataset might be available in multiple serializations that may differ in various ways, including natural language, media-type or format, schematic organization, temporal and spatial resolution, level of detail or profiles (which might specify any or all of the above)."
What DDI-L class corresponds to the DCAT Distribution?
How do we obtain the Distribution properties from DDI-L metadata? As for the the dataset, we can start with properties used in DCAT-AP, which are:
| Property | Range | DCAT-AP status |
|---|---|---|
| dcat:accessURL | rdfs:Resource | mandatory |
| dct:description | rdfs:Literal | recommended |
| dct:format | dct:MediaTypeOrExtent | recommended |
Note
DCAT-AP also recommmends the "availability" property, but this is an extension not defined in DCAT.
How do we derive the property that links a dataset to a distribution?
The PhysicalInstance class in Lifecycle has a DataFileIdentification field for which the documentation explains:
Identifies the data file documented in the physical instance and provides information about its location.
More specifically, DataFileIdentification has a DataFileURI property.
For this, we should probably use the Citation property. It provides several "DC-like" fields and the possibility to add any Dublin Core terms with DCTerms (here is the XML schema doc for this).
The most direct way to implement this is to use as mentionned earlier the Citation element.
We could also consider the use of the FileFormat property of PhysicalStructure. The lattest is link to the PhysicalInstance through its RecordLayout.