dcat:CatalogRecord represents a metadata item in the catalog, primarily concerning the registration information, such as who added the item and when.
-
+
Normally, child datasets in dataset series are represented as dcat:Dataset. The use of dcat:Distribution for typing child datasets is however recognized as a possible alternative, whenever it addresses more effectively the requirements of a given application scenario.
Dataset series can be also soft-typed via property dcterms:type as in the approach used in [[GeoDCAT-AP]], and adopted in [[DCAT-AP-IT]] and [[GeoDCAT-AP-IT]]).
+
Usage note:
Common scenarios for dataset series include: time series composed of periodically released subsets; map-series composed of items of the same type or theme but with differing spatial footprints.
+
+
+
+
+
+
+
@@ -4479,95 +4590,84 @@
Complementary approaches to versioning
Dataset series
+
-
With "dataset series" we refer to data, somehow interrelated, that are published separately, although they could be merged into a single dataset. An example is budget data split by year and/or country, instead of being made available in a single dataset.
+
With "dataset series" we refer to data, somehow interrelated, that are published separately. An example is budget data split by year and/or country, instead of being made available in a single dataset.
Dataset series are defined in [[ISO-19115]] as a collection of datasets […] sharing common characteristics. However, their use is not limited to geospatial data, although in other domains they can be named differently (e.g., time series, data slices) and defined more or less strictly (see, e.g., the notion of "dataset slice" in [[VOCAB-DATA-CUBE]]).
-
The reasons and criteria for splitting data into series are manyfold, and they may be related to, e.g., data characteristics, publishing process, and how they are typically used. For instance, data huge in size (as geospatial ones) are more easily handled (by data providers as well as data consumers) by splitting them into smaller ones. Another example is data released on a yearly basis, which are typically published as separate datasets, instead of appending the new data to the first in the series.
-
-
There are no common rules and criteria across domains to decide when dataset series should be created and how they should be organized. The situation is similar to the one concerning versioning (see ), and, likewise, DCAT does not adopt any specific definition of dataset series, and when and how they should be created and organized. The purpose of this section is limited to providing guidance on how dataset series can be specified in DCAT.
+
The reasons and criteria for grouping datasets into series are manyfold, and they may be related to, e.g., data characteristics, publishing process, and how they are typically used. For instance, data huge in size (as geospatial ones) are more easily handled (by data providers as well as data consumers) by splitting them into smaller ones. Another example is data released on a yearly basis, which are typically published as separate datasets, instead of appending the new data to the first in the series.
+
As there are no common rules and criteria across domains to decide when dataset series should be created and how they should be organized, DCAT does not prescribe any specific approach, and refer for guidance and domain- and community practices. The purpose of this section is limited to providing guidance on how dataset series can be specified in DCAT.
How to specify dataset series
-
Existing DCAT implementations adopt two main alternative approaches to specifying dataset series:
-
-
-
The dataset series is typed as a dcat:Dataset, whereas its child datasets are typed as dcat:Distribution's.
-
Both the dataset series and its child datasets are typed as a dcat:Dataset's, and the two are usually linked by using the [[DCTERMS]] properties dcterms:hasPart / dcterms:isPartOf.
-
-
-
In both cases, the dataset series is sometimes soft-typed by using the [[DCTERMS]] property dcterms:type (e.g., this is the approach used in [[GeoDCAT-AP]], and adopted in [[DCAT-AP-IT]] and [[GeoDCAT-AP-IT]]).
-
-
Compared with the second option, the first one may have the advantage of simplifying metadata management, and avoiding the creation of datasets having the same values for almost all their metadata elements. On the other hand, this approach reduces the ability of being discovered, as distribution metadata are not rich as datasets' ones. Moreover, using distributions may result cumbersome or unfeasible when the number of child datasets is too high.
-
-
As stated in the note to , DCAT recommends, as the default approach, typing both dataset series and child datasets as dcterms:Dataset's, and linking them by using properties dcterms:hasPart and/or dcterms:isPartOf, and possibly soft-typing the dataset series via property dcterms:type.
-
-
-
-
The approach based on the use of dcat:Distribution for typing child datasets is however recognized as a possible alternative, whenever it addresses more effectively the requirements of a given application scenario.
-
-
Here and in the following sections, guidance will focus on the default approach.
-
-
@@ -6072,9 +6204,10 @@
Changes since the first public working draft of 17 December 2020
The other sections include only editorial changes.
has been updated to include the definition of the properties illustrated in .
+
has been revised making dataset series first class citizens of data catalogs and introducing new properties for linking dataset series and datasets (see Issues #1272 and #1307). In particular, the class dcat:DatasetSeries has been minted (see ), the property dcat:inSeries has been added to .
Changes since the W3C Recommendation of 4 February 2020
Section was extended with draft guidelines to deal with version delta (Issue #89), version release date (Issue #91), version identifier (Issue #92), version compatibility (Issue #1258) and resource status (Issue #1238).
-
- A new section was added to draft guidelines on dataset series (Issue #868) and to show related examples (Issue #806).
+
A new section was added to draft guidelines on dataset series (Issue #868) and to show related examples (Issue #806).
