To start the discussion, I went to datahub.io and searched for ‘budget’. A quick survey brought up five different existing approaches. What are the views of implementers of DCAT-AP? Do one or more of these approaches also exist in your implementations?

 

Approach 1: one Dataset per year with one or more files (Distributions) that contain Budget figures for that year.

Examples:

• European Union Budget for 2013, https://datahub.io/dataset/european-union-budget-2013: One data file for that one year.
• Bund Offener Haushalt, https://datahub.io/dataset/bund-offener-haushalt: data files for one year in different formats

 

Approach 2: one Dataset for a range of years with data files for each of the individual years as Distributions with descriptions that contain the year covered.

Example:

• EU Budget for years 2003 to present, https://datahub.io/dataset/eu-budget: Several data files for individual years.

 

Approach 3: one Dataset for a range of years with one or more data files (Distributions) that cover the whole range of years

• Hungarian Government Budget 1995-2009, https://datahub.io/dataset/government_budget_hungary: One data file that contains all data for 1995-2009.

 

Approach 4: one Dataset describing a Website where a user might search, browse or navigate in a collection of data with no data files (Distributions)

Example:

• Poland - Ministry of Finance – Budget, https://datahub.io/dataset/pl-budget: No data files.

 

Approach 5: one Dataset for a Website with one or more data files (Distributions) that link to a SPARQL endpoint or Website where a user might search, browse or navigate in a collection of data

Examples:

• Where Does My Money Go? – Data, https://datahub.io/dataset/wdmmg: One data file that contains a link to a Website.
• EU: fintrans.publicdata.eu, https://datahub.io/dataset/beneficiaries-of-the-european-commission: Multiple data files that link to a SPARQL end point and an HTML browsing interface.

Maybe a Dataset should have assigned the optional parameters:

dct:hasPart

dct:isPartOf

 

Then it would be easy to model these relations between datasets...

Uwe, it would be interesting to know how people are doing this in practice. If approach 1 is prevalent, then indeed the use of dct:hasPart and dct:isPartOf works. However, it does not help with the other approaches.

 

Proposed resolution:

• No common approach across data providers.
• Suggestions for modelling:
  • Create multiple Distributions of a single Dataset if users are mostly interested in the collection as such
  • Create different Datasets if users are mostly interested in the individual members
  • If user expectations are difficult to determine, create separate Datasets and one combined Dataset with the members as Distributions.

Dataset series - versioning

• DCAT-AP allows relating datasets as ‘versions’ using dct:hasVersion/dct:isVersionOf but it is not clearly described in which cases to use these properties.
• Putting a versioning scheme in place and assigning the version number as value to owl:versionInfo can be used for indicating precedence/sequence among different versions.
• adms:versionNotes can be used for describing the differences between and version and its previous one, or for indicating that a newer version is more valid than an older one.

Create multiple Distributions of a single Dataset if users are mostly interested in the collection as such

I do not agree that it is a good idea to create multiple distributions to represent a dataset-series. This will mean that a distribution also is a Dataset. We think it is a better idea to use the dct:type mechanism and define DatasetSeries as a type of dataset that may have relations to its instances. Alternatively one could create a new Entity called DatasetSeries to represent the semantics of a dataset series.

The current situation is that a lot of people model members of dataset series, e.g. time-series -- see approach 2 in comment #1 -- but also slices/extractions of larger data files, as Distributions for a single Dataset. Some people might think it is not a good idea, but it is existing practice.

 

In last year's revision process, there were two opposing opinions in the group, one for approach 1 and one for approach 2. We did not reach consensus.

 

So the guideline tries to identify under which circumstances you might want to do one or the other. I tried to look at it from the perspective of user expectations, rather than from a more theoretical modelling perspective.

 

We currently don't have DatasetSeries as a dataset type or as a class, so that approach would have to go on the list for future revisions of the profile.

From the DCAT spec:

dcat:Distribution represents an accessible form of a dataset as for example a downloadable file. 

  A dat:Distribution is not meant to provide subsets of a dataset. A dcat:Distribution aims to cover casese where different forms of the same dataset. Existing cases that missuse the dcat:Distribution should not prevail as the de facto way of dealing with subsets of a dcat:Dataset (if dataset series can be considered as subsets of a single dcat:Dataset).    Perhaps, expressing dataset series is even out of scope for the DCAT spec, because its semantics are beyond the description of the dataset per se. Describing the continuation might be faced as an independent issue whose semantics can be described on the side, since it is a certain case of relationship between datasets (as indicated also in the introduction of the issue).   An alternative solution could be that a dataset series is addressed as pagination is addressed in the case of Web APIs (i.e. something like previousDataset/nextDataset in the same context as Web APIs consider previousPage/nextPage). I.e. each dataset of a dataset series remains a dcat:Dataset and their sequence is described with at property like ex:previousDataset/ex:nextDataset. See hydra spec for details [1]. In this case, the semantics of the property should clearly indicate that the sequence is chronological (unless explicitely it is explicitely defined the type of collection, see below).   Considering dataset series as a way of grouping certain datasets is only one way of describing a collection of datasets that share certain properties. I am not convinced that such metadata is required to be so explicitely defined as trying to describe all possible relationships might prove to be impossible, redundant or even out of scope. However, if so, a ex:Collection might be a ex:TimeSeriesCollection (narrower of a ex:SeriesCollection concept which is narrower of the ex:Collection concept), as PagedCollection is in the case of the Hydra spec for the Web APIs [1] and each dcat:Dataset may declare membership to a certain Collection.   [1] http://www.hydra-cg.com/spec/latest/core/

Øystein, Makx,

About using dct:type to denote a dataset as a series, this is actually what is done in GeoDCAT-AP, by using the relevant resource type from the INSPIRE Registry:

http://inspire.ec.europa.eu/metadata-codelist/ResourceType/series

For the background and motivation of this approach, see the following comment https://joinup.ec.europa.eu/discussion/pr11-add-new-properties-dataset-express-haspart-and-ispartof-relationships#comment-16527

 

Andrea,

We could maybe include a reference to the GeoDCAT approach in the guideline under the option "Create different Datasets if users are mostly interested in the individual members".

 

I could include:

 

The GeoDCAT Application Profile proposes the following approach:

• one Dataset description is created with a dct:type of http://inspire.ec.europa.eu/metadata-codelist/ResourceType/series, linking to the members in the series using dct:hasPart;
• for the individual members of the series, separate Dataset descriptions are created that can link back to the series using dct:isPartOf.

Is this statement accurate?

Andrea,

We could maybe include a reference to the GeoDCAT approach in the guideline under the option "Create different Datasets if users are mostly interested in the individual members".

I could include:

 

The GeoDCAT Application Profile proposes the following approach:

• one Dataset description is created with a dct:type of http://inspire.ec.europa.eu/metadata-codelist/ResourceType/series, linking to the members in the series using dct:hasPart;

• for the individual members of the series, separate Dataset descriptions are created that can link back to the series using dct:isPartOf.

Is this statement accurate?

 

Actually, GeoDCAT-AP does not say how to link series to its children. The reason is twofold:

1. This is not required in INSPIRE metadata, and it is not supported in the core profile of ISO 19115
2. How to do this was not agreed upon in DCAT-AP 1.1

So, the only thing that can be said by referring to GeoDCAT-AP is:

• The GeoDCAT Application Profile models series by creating a Dataset description with a dct:type of http://inspire.ec.europa.eu/metadata-codelist/ResourceType/series

We have worked on a use case about dataset series (periodical). Find attached here a google slides document you can comment with a description of the use case and a proposal for datasets representation. 

https://docs.google.com/presentation/d/1bSMi8ZzUcaFPMByWdp8PG3N4aMlXkl4bRo6u48rIKt0/edit?usp=sharing

Jean on the behalf of OP/OpenDataPortal

@Jean, thanks for sharing the presentation.

May I ask why you decided to use properties :memberOf / :hasMember, instead of dct:isPartOf / dct:hasPart?

@Andrea

I propose :hasMember to be conformant with FRBRoo which has a good representation of complexWork such as series, but using dct:isPartOf, might be simplier as the dct ontology is already used. Using dct:isPart will not differentiate the Dastaset representing a serie from an other Dataset which really has parts. If we use dct:isPartOf, it could be useful to have an other way to indicate that Dataset is a serial work, without Distributions.