Qualified forms [RQF]

Define qualified forms to specify additional attributes of appropriate binary relations (e.g. temporal context).

This requirement is still under review

Publication source [RPS]

Provide a way to cite the original metadata with a dereferenceable identifier.

Datasets vs. Catalog relation [RDSCR]

Clarify the relationships between Datasets and zero, one or multiple Catalogs, e.g. in scenarios of copying, harvesting and aggregation of Dataset descriptions among Catalogs.

Metadata guidance rules [RMDG]

Ability to express 'guidance rules' or 'creation rules' in DCAT

Distribution definition [RDIDF]

Revise definition of Distribution. Make clearer what a Distribution is and what it is not. Provide better guidance for data publishers.

Spatial coverage [RSC]

Provide means to specify spatial coverage with geometries.

Related datasets [RRDS]

Ability to represent the different relationships between datasets, including: versions of a dataset, collection of datasets, to describe their inclusion criteria and to define the 'hasPart'/'partOf' relationship, derivation, e.g. processed data that is derived from raw data

this requriement to be rolled in here: Update method of Dataset: Indicate the update method of a Dataset description, e.g. whether each new dataset entirely supercedes previous ones (is stand-alone), or whether there is a base dataset with files that effect updates to that base.

Reference system [RRS]

Provide means to specify the reference system(s) used in a dataset.

Profile representation [RPFRP]

Create a way to retrieve more information about a profile. This must be flexible enough to support human and machine readable resources, such as input and editing guidance, validation resources, usage notes etc.

Following additional requirements consider the representation of a profile (document), expressing concrete constraints, compared to the definition of the concept in#RPFDF

1. Machine-readable specifications of application profiles need to be easily publishable, and optimize re-use of existing specifications.
2. Application profiles need a rich expression for the validation of metadata
3. Profiles must have properties for at least two levels of documentation: 1) short definition 2) input and editing guidance
4. Profiles must support declaration of vocabulary constraints
5. A mechanism must be available to identify conformance to each inherited profile given conformance to a profile that specialises it.
6. Profiles list valid vocabulary terms for a metadata usage environment
7. Profile vocabulary lists may be defined as closed (no other terms are allowed) or open (other terms are allowed)#ID37
8. Profiles should reuse vocabulary terms defined elsewhere (Dublin Core profiles; no use case)
9. Profiles must be able to support information that can drive data creation functions, including brief and detailed documentation#ID46
10. Profiles must support discoverability via search engines#ID40
11. Profiles must have identifiers that can be used to link the DCAT description to the relevant profile

Project context [RPCX]

Provide a means to define a 'project' as a research, funding or work organzation context of a dataset.

Temporal coverage [RTC]

Allow for specification of the start and/or end date of temporal coverage.

Related vocabularies comparision [RVC]

Analyse and compare similar concepts defined by vocabularies related to DCAT (e.g. VOID, Data Cube dataset).

Profiles listing [RPFL]

Create a way to list the profiles implemented by a dataset or a specific distribution

Some subset of profile metadata that can be included in a DCAT context should have a canonical set of properties recommended. Initial requirements are 1) short definition 2) input and editing guidance. Links should be consistent with#RPFRP

Quality-related information [RDQIF]

Define a way to associate quality-related information with Datasets.

Dataset publications [RDSP]

Provide a way to link publications about a dataset to the dataset.

Summary statistics [RSS]

Express summary statistics and descriptive metrics to characterize a Dataset.

Project relation [RPR]

Provide a means to indicate the relation of Datasets to a project.

Funding source [RFS]

Provide means to describe the funding (amount and source) of a Dataset (or entire Catalog).

Distribution package [RDIP]

Define way to specify content of packaged files in a Distribution. For example, a set of files may be organised in an archive format and then compressed, but dct:hasFormat property only indicates the encoding type of the outer layer of packaging.

Dataset aspects [RDSAT]

Provide recommendations and mechanisms for data providers to describe datasets with a formal description of aspects (e.g. instrument/sensor used, spatial feature, observable property, quantity kind).

Finer grained semantics will also allow dataset dimensions to be described, and distributions described using these semantics - for example how a dataset is composed of multiple subsets, such as a set of image bands or tiles, or parameterised filtering/subsetting services

This requirement applies to catalogues of DCAT records, and is thus related to the concept of profiles, which are expected to define classification dimensions (use of controlled vocabularies in mandatory properties)

Provenance information [RPIF]

Provide a way to link to structured information about the provenance of a dataset including:

• the input data used to create a dataset to the dataset.
• the software used to produce the dataset to the dataset.
• an extensible model different types of agent roles
• funders

dct:creator, dct:publisher etc are special cases, which require guidance, further roles may be defined in provenance or other richer models. The requirement is to establish an extensible mechanism, and for profiles to specify canonical equivalents for the special case properties of dcat:Dataset

Distribution schema [RDIS]

Define a way to include identification of the schema the described data conforms to

This may include rich information via extensions points, URI templates and parameters, dimensions and subsetting operations, dereferenceable identifiers of service behaviour profiles and canonical identifiers of well-known web service interfaces (e.g. OGC - WFS, WMS, OpenDAP, REST apis).

Such a description may be provided through identifier of a suitable profile that defines interoperability conditions the distribution conforms to.

Related vocabularies mapping [RVM]

Define guidelines how to create a DCAT description of a VOID or Data Cube dataset

Entailment of schema.org [RES]

Define schema.org equivalents for DCAT properties to support entailment of schema.org compliant profiles of DCAT records.

Primary and alternative identifier [RIDALT]

Provide means to distinguish the primary and alternative (legacy) identifiers.

Dataset access [RDSA]

Provide a way to specify access restrictions for both a dataset and a distribution.

Provide a way to define the meaning of the access restrictions for a dataset or distribution and to specify what is required to access a dataset and distribution.

Dummy issue [RDMY]

Provide clear guidance on conditions, type and severity of a resource's update that might motivate the creation of a new version in scenarios such as dataset evolution, conversion, translations etc, including how this may assist change management processes for consumers (e.g. semantic versioning techniques)

Identifier type [RIDT]

Indicate type of identifier (e.g.prism:doi, bibo:doi, ISBNetc.).

Distribution service [RDISV]

Ability 1) to describe the type of distribution and 2) provide information about the type of service

Such a description may be provided through a suitable profile identifier that defines a profile of the relevant service type.

Dataset citation [RDSC]

Provide a way to specify information required for data citation (e.g., dataset authors, title, publication year, publisher, persistent identifier)

Profile negotiation [RPFN]

Create a way to negotiate choice of profile between clients and servers

Usage notes [RUN]

Ability to provide information on how to use the data.

Should this also apply to specific distributions?

Dereferenceable identifiers [RDID]

Encode identifiers as dereferenceable HTTP URIs

Data quality model [RDQM]

Identify common modeling patterns for different aspects of data quality based on frequently referenced data quality attributes found in existing standards and practices.

This includes potential use and revision of DQV

Aspects include:

Profile definition [RPFDF]

Create a sufficiently wide definition of an application profile to address declaration of interoperability profiles data may conform to, and through this mechanism provide the means for DCAT instances and collections to also declare the profiles of DCAT they conform to.

These Use case specific requirements apply to the required scope of this definition. Where appropriate these are also captured as additional requirements.

1. Clarify any relationship between profiles and validation languages
2. Profiles have URI identifiers that resolve to more detailed descriptions
3. Each application profile needs to be documented, preferably by showing/reusing what is common across profiles
4. Profiles should provide both machine and human readable views.
5. Profiles may inherit clauses from one or more parent profiles
6. Profiles must support a view that includes all inherited constraints clearly identifying the parent profile the constraint is defined in.
7. Profiles may be used to describe the metadata standard a description conforms to, the standards to which the resource described (e.g. dataset) and the standards each distribution conforms to.
8. Conceptually, profiles can extend other vocabularies or profiles, or can be refinements of other vocabularies or profiles (#ID37)
9. Responses can conform to multiple, modular profiles (#ID3)

Dataset type [RDST]

Provide a mechanism to indicate the type of data being described and recommend vocabularies to use given the dataset type indicated.

Providing examples of scope will provide guidance, without being unnecessarily restrictive. The key requirement is interoperability, achieved by using standardised vocabulary terms. It it unclear whether a canonical registry is required or whether communities should constrain choice via DCAT profiles.

Mapping of qualified and non-qualified forms [RQFM]

Specify mapping of qualified to non-qualified forms (lowering mapping). The reverse requires information (qualification) that might not be present/evident.

This requirement is still under review

Publication control [RPC]

Provide means to express rights relating to reuse of DCAT metadata