DCAT is an RDF vocabulary designed to facilitate interoperability between data catalogs published on the Web. This document defines the schema and provides examples for its use.

DCAT enables a publisher to describe datasets and data services in a catalog using a standard model and vocabulary that facilitates the consumption and aggregation of metadata from multiple catalogs. This can increase the discoverability of datasets and data services. It also makes it possible to have a decentralized approach to publishing data catalogs and makes federated search for datasets across catalogs in multiple sites possible using the same query mechanism and structure. Aggregated DCAT metadata can serve as a manifest file as part of the digital preservation process.

The namespace for DCAT terms is http://www.w3.org/ns/dcat#

The suggested prefix for the DCAT namespace is dcat

The (revised) DCAT vocabulary is available here.

Since the First Public Working Draft, the main changes to the DCAT vocabulary have been:

The detailed differences between the two documents can be seen here and the list of all the changes since the previous version of DCAT in the Change History section.

DCAT history

The original DCAT vocabulary was developed and hosted at the Digital Enterprise Research Institute (DERI), then refined by the eGov Interest Group, and finally standardized in 2014 [[?VOCAB-DCAT-20140116]] by the Government Linked Data (GLD) Working Group.

This revised version of DCAT was developed by the Dataset Exchange Working Group in response to a new set of Use Cases and Requirements [[?DCAT-UCR]] submitted on the basis of experience with the DCAT vocabulary from the time of the original version, and new applications not originally considered. A summary of the changes from [[?VOCAB-DCAT-20140116]] can be found at Change History

External terms

DCAT incorporates terms from pre-existing vocabularies where stable terms with appropriate meanings could be found, such as foaf:homepage and dct:title. Informal summary definitions of the externally-defined terms are included here for convenience, while authoritative definitions are available in the normative references. Changes to definitions in the references, if any, supersede the summaries given in this specification. Note that conformance to DCAT (Section 4) concerns usage of only the terms in the DCAT namespace itself, so possible changes to the external definitions will not affect the conformance of DCAT implementations.

Please send comments

Introduction

Sharing data resources among different organizations, researchers, governments and citizens requires the provision of metadata. This is irrespective of the data being open or not. DCAT is a vocabulary for publishing data catalogs on the Web, which was originally developed in the context of government data catalogs such as data.gov and data.gov.uk, but it has also been used in other contexts.

This revision of DCAT has extended the previous version to support further use cases and requirements [[?DCAT-UCR]]. These include the possibility of cataloguing other data resources in addition to datasets, such as data services. The revision also supports describing relationships between datasets as well as between datasets and other catalogued resources, guidance on how to document licenses and rights statements associated with the catalogued items.

DCAT provides RDF classes and properties to allow datasets and data services to be described and included in a catalog. The use of a standard model and vocabulary facilitates the consumption and aggregation of metadata from multiple catalogs, which can:

  1. increase the discoverability of datasets and data services
  2. allow federated search for datasets across catalogs in multiple sites

Data can come in many formats, ranging from spreadsheets, through XML and RDF, to various specialty formats. DCAT does not make any assumptions about the serialization format of the datasets described in a catalog, but it does distinguish between the abstract dataset and its different manifestations or distributions.

Data is often provided through a service, accessed through a form or API which supports selection of an extract, sub-set, or combination of data. DCAT allows the description of a data access service to be included in a catalog.

Complementary vocabularies can be used together with DCAT to provide more detailed format-specific information. For example, properties from the VoID vocabulary [[?VOID]] can be used to express various statistics about a DCAT-described dataset if that dataset is in RDF format.

This document does not prescribe any particular method of deploying data expressed in DCAT. DCAT is applicable in many contexts including RDF accessible via SPARQL endpoints, embedded in HTML pages as [[?HTML-RDFa]], or serialized as RDF/XML [[?RDF-SYNTAX-GRAMMAR]], [[?N3]], [[?Turtle]], [[?JSON-LD]] or other formats. Within this document the examples use Turtle because of its readability.

Motivation for change

The original Recommendation [[?VOCAB-DCAT-20140116]], published in January 2014, provided the basic framework for describing datasets. Importantly, it made the distinction between a dataset as an abstract idea and a distribution as a manifestation of the dataset. Although DCAT has been widely adopted, it has become clear that the original specification lacked a number of essential features that were added either through application profiles, such as the European Commission's DCAT-AP [[?DCAT-AP]], or the development of larger vocabularies that, to a greater or lesser extent, built upon the base standard, such as the Healthcare and Life Sciences Community Profile [[?HCLS-Dataset]], the Data Tag Suite [[?DATS]] and more. This version of DCAT has been developed to address the specific shortcomings that have come to light through the experiences of different communities, the aim being, of course, to improve interoperability between the outputs of these larger vocabularies. For example, in this new DCAT version, we provide classes, properties and guidance to address identifiers, quality information, data citation issues.

This draft includes re-writing of the specification throughout. Significant changes from the 2014 Recommendation are marked within the text using "Note" sections, as well as being described in the Change History.

Namespaces

The namespace for DCAT is http://www.w3.org/ns/dcat#. However, note that DCAT makes extensive use of terms from other vocabularies, in particular Dublin Core [[?DCTERMS]]. DCAT defines a minimal set of classes and properties of its own. A full set of namespaces and prefixes used in this document is shown in the table below.

PrefixNamespace
admshttps://www.w3.org/ns/adms#
dcathttp://www.w3.org/ns/dcat#
dcthttp://purl.org/dc/terms/
dctypehttp://purl.org/dc/dcmitype/
dqvhttp://www.w3.org/ns/dqv#
foafhttp://xmlns.com/foaf/0.1/
owlhttp://www.w3.org/2002/07/owl#
provhttp://www.w3.org/ns/prov#
rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfshttp://www.w3.org/2000/01/rdf-schema#
schemahttps://schema.org/
skoshttp://www.w3.org/2004/02/skos/core#
vcardhttp://www.w3.org/2006/vcard/ns#
xsdhttp://www.w3.org/2001/XMLSchema#

Modified from DCAT 2014 [[?VOCAB-DCAT-20140116]]

A data catalog conforms to DCAT if:

A DCAT profile is a specification for data catalogs that adds additional constraints to DCAT. A data catalog that conforms to the profile also conforms to DCAT. Additional constraints in a profile MAY include:

The requirement for a DCAT profile to conform to all of DCAT is under discussion.

Vocabulary overview

DCAT scope

DCAT is an RDF vocabulary for representing data catalogs. DCAT is based around eight main classes:

UML model of DCAT classes and properties
Overview of DCAT model, showing the classes of resources that can be members of a Catalog, and the relationships between them.

Along with the rest of the Vocabulary overview, this diagram is non-normative. Furthermore, while the diagram uses UML-style class notation, it should be interpreted following the usual RDF open-world assumptions around the presence/absence of properties, relationships, and their cardinality. The properties shown in each class reflect those recommended in the descriptions of classes in the Vocabulary specification. To assist in understanding the full scope of each class, properties are copied down from each '::super-class'. Cardinalities are shown in a few places to reinforce expectations, but these are not axiomatized or enforced in any way by this recommendation.

A dataset in DCAT is defined as a "collection of data, published or curated by a single agent, and available for access or download in one or more serializations or formats". A dataset is a conceptual entity, and can be represented by one or more distributions that serialize the dataset for transfer. Distributions of a dataset can be provided via data distribution services. Detailed properties for a data distribution service API are out of the scope of this version of DCAT.

A data service in DCAT is a collection of operations or API which provides access to data. An interactive interface such as a web form is often provided to access to the API operations. A data service typically provides selection, extraction, combination, processing or transformation operations over datasets that might be hosted locally or remote to the service. A data service might be tied to specific datasets, or its source data might be configured at request- or run-time. The result of a request to a data service is a representation of a part or all of a dataset or catalog. A data distribution service is a kind of data service that provides the means to select and download a distribution of a dataset or subset. A data discovery service is a kind of data service that provides the means to find the description of a suitable dataset, often through a portal or catalog service. Other kinds of data service might include data transformation services such as coordinate transformation services, re-sampling and interpolation services, and various data processing services, but these are outside the scope of the current DCAT vocabulary.

Descriptions of datasets and data services can be included in a catalog. A catalog is a kind of dataset whose member items are descriptions of datasets and data services. Other types of thing might also be catalogued, but the scope of DCAT is currently limited to datasets and data services. To extend the scope of a catalog beyond datasets and data services it is recommended to define additional sub-classes of dcat:Resource in a DCAT application profile or other DCAT application. To extend the scope of service descriptions beyond data distribution services it is recommended to define additional sub-classes of dcat:DataService in a DCAT application profile or other DCAT application.

The scope of DCAT 2014 [[?VOCAB-DCAT-20140116]] was limited to catalogs of datasets. A number of use cases for the revision involve data distribution services as members of a catalog - see DCAT Distribution to describe web services - ID6 and Modeling service-based data access - ID18. Hence, the scope of this revision of DCAT includes both datasets and data services, with an explicit class for Data Distribution Services, to enable these to be part of a DCAT conformant catalog. Provision for other data services to also be part of a Catalog is also made, as well as for Catalogs to be composed of other Catalogs. See Issue #172.

Catalogs of other kinds of things might be designed following the DCAT pattern, e.g. dealing with facilities, instruments, samples and specimens, other physical artefacts, events or activities. These are currently out of scope for DCAT, but might be defined through further sub-classes of dcat:Resource, which could be specified in a DCAT application profile or other DCAT application.

A CatalogRecord describes an entry in the catalog. Notice that while dcat:Resource represents the dataset or service itself, dcat:CatalogRecord is the record that describes the registration of an item in the catalog. The use of explicit dcat:CatalogRecord is considered optional. It is used to capture provenance information about entries in a catalog explicitly. If this is not necessary then dcat:CatalogRecord can be safely ignored.

RDF considerations

The DCAT vocabulary is an OWL2 ontology [[?OWL2-OVERVIEW]] formalized using [[?RDF-SCHEMA]]. Each class and property in DCAT is denoted by an [[?IRI]]. Locally defined elements are in the namespace http://www.w3.org/ns/dcat#. Elements are also adopted from several external vocabularies, in particular [[?FOAF]], [[?DCTERMS]] and [[?PROV-O]]

RDF allows resources to have global identifiers (IRIs) or to be blank nodes. Blank nodes can be used to denote resources without explicitly naming them with an IRI. They can appear in the subject and object position of a triple [[?RDF11-PRIMER]]. For example, in many actual DCAT catalogs, distributions are represented as blank nodes nested inside the related dataset description. While blank nodes can offer flexibility for some use cases, in a Linked Data context, blank nodes limit our ability to collaboratively annotate data. A blank node resource cannot be the target of a link and it can't be annotated with new information from new sources. As one of the biggest benefits of the Linked Data approach is that "anyone can say anything anywhere", use of blank nodes undermines some of the advantages we can gain from wide adoption of the RDF model. Even within the closed world of a single application dataset, use of blank nodes can quickly become limiting when integrating new data [[?LinkedDataPatterns]]. For these reasons, it is recommended that instances of the DCAT main classes have a global identifier, and use of blank nodes is generally discouraged when encoding DCAT in RDF.

All RDF examples in this document are written in Turtle syntax [[?Turtle]] and many are available from the DXWG code repository.

Each RDF example in this document is intended to demonstrate specific capabilities of DCAT, and therefore only shows a subset of all the potential properties and links which might appear in a complete DCAT resource.

Basic Example

This example provides a quick overview of how DCAT might be used to represent a government catalog and its datasets.

First, the catalog description:

:catalog
  a dcat:Catalog ;
  dct:title "Imaginary Catalog" ;
  rdfs:label "Imaginary Catalog" ;
  foaf:homepage <http://example.org/catalog> ;
  dct:publisher :transparency-office ;
  dct:language <http://id.loc.gov/vocabulary/iso639-1/en>  ;
  dcat:dataset :dataset-001  , :dataset-002 , :dataset-003 ;
  .

The publisher of the catalog has the relative URI :transparency-office. Further description of the publisher can be provided as in the following example:

:transparency-office
  a foaf:Organization ;
  rdfs:label "Transparency Office" ;
  .

The catalog lists each of its datasets via the dcat:dataset property. In the example above, an example dataset was mentioned with the relative URI :dataset-001. A possible description of it using DCAT is shown below:

:dataset-001
  a dcat:Dataset ;
  dct:title "Imaginary dataset" ;
  dcat:keyword "accountability","transparency" ,"payments" ;
  dct:creator :finance-employee-001 ;
  dct:issued "2011-12-05"^^xsd:date ;
  dct:modified "2011-12-15"^^xsd:date ;
  dcat:contactPoint <http://example.org/transparency-office/contact> ;
  dct:temporal <http://reference.data.gov.uk/id/quarter/2006-Q1> ;
  dcat:temporalResolution "P1D"^^xsd:duration ;
  dct:spatial <http://www.geonames.org/6695072> ;
  dcat:spatialResolutionInMeters "30.0"^^xsd:decimal ;
  dct:publisher :finance-ministry ;
  dct:language <http://id.loc.gov/vocabulary/iso639-1/en>  ;
  dct:accrualPeriodicity <http://purl.org/linked-data/sdmx/2009/code#freq-W>  ;
  dcat:distribution :dataset-001-csv ;
  .

Five distinct temporal descriptors are shown for this dataset. The dataset publication and revision dates are shown in dct:issued and dct:modified. For the frequency of update of the dataset in dct:accrualPeriodicity, we use an instance from the Content-Oriented Guidelines developed as part of the W3C Data Cube Vocabulary [[?VOCAB-DATA-CUBE]] efforts. The temporal coverage or extent is given in dct:temporal using an item from the Interval dataset (originally available from http://reference.data.gov.uk/id/interval) from data.gov.uk. The temporal resolution, which describes the minimum spacing of items within the dataset, is given in dcat:temporalResolution using the standard datatype xsd:duration.

Additionally, the spatial coverage or extent is given dct:spatial using a URI from Geonames. The spatial resolution, which describes the minimum spatial separation of items within the dataset, is given in dcat:spatialResolutionInMeters using the standard datatype xsd:decimal.

A contact point is provided where comments and feedback about the dataset can be sent. Further details about the contact point, such as email address or telephone number, can be provided using vCard [[?VCARD-RDF]].

One representation of the dataset :dataset-001-csv can be downloaded as a 5Kb CSV file. This is represented as an RDF resource of type dcat:Distribution.

:dataset-001-csv
  a dcat:Distribution ;
  dcat:downloadURL <http://www.example.org/files/001.csv> ;
  dct:title "CSV distribution of imaginary dataset 001" ;
  dcat:mediaType <https://www.iana.org/assignments/media-types/text/csv> ;
  dcat:byteSize "5120"^^xsd:decimal ;
  .

Classifying datasets thematically

The catalog classifies its datasets according to a set of domains represented by the relative URI :themes. SKOS can be used to describe the domains used:

:catalog dcat:themeTaxonomy :themes .

:themes
  a skos:ConceptScheme ;
  skos:prefLabel "A set of domains to classify documents" ;
  .

:dataset-001 dcat:theme :accountability  .

Notice that this dataset is classified under the domain represented by the relative URI :accountability. It is recommended to define the concept as part of the concepts scheme identified by the URI :themes that was used to describe the catalog domains. An example SKOS description:

:accountability
  a skos:Concept ;
  skos:inScheme :themes ;
  skos:prefLabel "Accountability" ;
  .

Classifying dataset types

The type or genre of a dataset can be indicated using the dct:type property. It is recommended that the value of the property is be taken from a well governed and broadly recognised set of resource types, such as the DCMI Type Vocabulary, the MARC Genre/Terms Scheme, the ISO 19115 MD_Scope codes, the DataCite resource types, or the PARSE.Insight content-types from Re3data [[?RE3DATA-SCHEMA]].

In the following examples, a (notional) dataset is classified separately using values from different vocabularies.

:dataset-001
  rdf:type  dcat:Dataset ;
  dct:type  <http://purl.org/dc/dcmitype/Text> ;
  .

:dataset-001
  rdf:type  dcat:Dataset ;
  dct:type  <http://id.loc.gov/vocabulary/marcgt/man> ;
  .

It is also possible for multiple classifications to be present in a single description.

:dataset-001
  rdf:type  dcat:Dataset ;
  dct:type  <http://purl.org/dc/dcmitype/Text> ;
  dct:type  <http://id.loc.gov/vocabulary/marcgt/man> ;
  dct:type  <http://registry.it.csiro.au/def/datacite/resourceType/Text> ;
  dct:type  <http://registry.it.csiro.au/def/re3data/contentType/doc> ;
.

<http://registry.it.csiro.au/def/datacite/resourceType/Text>
  rdfs:label "Text" ;
  dct:source "DataCite resource types" ;
  .

<http://registry.it.csiro.au/def/re3data/contentType/doc>
  rdfs:label "Standard office documents" ;
  dct:source "Re3data content types" ;
  .

Describing catalog records metadata

If the catalog publisher decides to keep metadata describing its records (i.e. the records containing metadata describing the datasets), dcat:CatalogRecord can be used. For example, while :dataset-001 was issued on 2011-12-05, its description on Imaginary Catalog was added on 2011-12-11. This can be represented by DCAT as in the following:

:catalog  dcat:record :record-001  .

:record-001
  a dcat:CatalogRecord ;
  foaf:primaryTopic :dataset-001 ;
  dct:issued "2011-12-11"^^xsd:date ;
  .

Dataset available only behind some Web page

:dataset-002 is available as a CSV file. However :dataset-002 can only be obtained through some Web page where the user needs to follow some links, provide some information and check some boxes before accessing the data.

:dataset-002
  a dcat:Dataset ;
  dcat:landingPage <http://example.org/dataset-002.html> ;
  dcat:distribution :dataset-002-csv ;
  .
:dataset-002-csv
  a dcat:Distribution ;
  dcat:accessURL <http://example.org/dataset-002.html> ;
  dcat:mediaType <https://www.iana.org/assignments/media-types/text/csv> ;
  .
Notice the use of a dcat:landingPage and the definition of the dcat:Distribution instance.

A dataset available as a download and behind some Web page

On the other hand, :dataset-003 can be obtained through some landing page but also can be downloaded from a known URL.

:dataset-003
  a dcat:Dataset ;
  dcat:landingPage <http://example.org/dataset-003.html> ;
  dcat:distribution :dataset-003-csv ;
  .
:dataset-003-csv
  a dcat:Distribution ;
  dcat:downloadURL <http://example.org/dataset-003.csv> ;
  dcat:mediaType <https://www.iana.org/assignments/media-types/text/csv> ;
  .

Notice that we used dcat:downloadURL with the downloadable distribution and that the other distribution accessible through the landing page does not have to be defined as a separate dcat:Distribution instance.

A dataset available through a service

:dataset-004 is distributed in different representations from different services. The dcat:accessURL for each dcat:Distribution corresponds with the dcat:endpointURL of the service. Each service is characterized by its general type using dct:type (here using values from the INSPIRE spatial data service type vocabulary), its specific API definition using dct:conformsTo, with the detailed description of the individual endpoint parameters and options linked using dcat:endpointDescription.

:dataset-004
  rdf:type dcat:Dataset ;
  dcat:distribution :dataset-004-csv ;
  dcat:distribution :dataset-004-png ;
.
:dataset-004-csv
  rdf:type dcat:Distribution ;
  dcat:accessService :table-service-005 ;
  dcat:accessURL <http://example.org/api/table-005> ;
  dcat:mediaType <https://www.iana.org/assignments/media-types/text/csv> ;
.
:dataset-004-png
  rdf:type dcat:Distribution ;
  dcat:accessService :figure-service-006 ;
  dcat:accessURL <http://example.org/api/figure-006> ;
  dcat:mediaType <https://www.iana.org/assignments/media-types/image/png> ;
.
:figure-service-006
  rdf:type dcat:DataDistributionService ;
  dct:conformsTo <http://example.org/apidef/figure/v1.0> ;
  dct:type <https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/view> ;
  dcat:endpointDescription <http://example.org/api/figure-006/params> ;
  dcat:endpointURL <http://example.org/api/figure-006> ;
  dcat:servesDataset :dataset-004 ;
.
:table-service-005
  rdf:type dcat:DataDistributionService ;
  dct:conformsTo <http://example.org/apidef/table/v2.2> ;
  dct:type <https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/download> ;
  dcat:endpointDescription <http://example.org/api/table-005/capability> ;
  dcat:endpointURL <http://example.org/api/table-005> ;
  dcat:servesDataset :dataset-003, :dataset-004 ;
.  

Vocabulary specification

RDF representation

The DCAT RDF representation is modularized into several files or graphs to help users access a version of DCAT with only the alignments that they need. This mechanism can also be used to capture different levels of axiomatization, though the status of such proposals has not been finalized. See Issue #134 and the issues enumerated below.

Guidance on the use DCAT in a weakly-axiomatized environment, such as schema.org, has been identified as a requirement to be satisfied in this revision of DCAT.

An RDF graph containing a proposed alignment of DCAT with schema.org is available. Comments on this alignment are invited.

The use of guarded constraints (existence, cardinality, range-type) to control the use of the recommended properties in the context of a class is being considered as part of the revision of DCAT.

The axiomatization of DCAT 2014 used global domain and range constraints for many of the properties defined in the DCAT namespace [[?VOCAB-DCAT-20140116]]. This makes quite strong ontological commitments, some of which are now being reconsidered - see individual issues noted inline below.

The (revised) DCAT vocabulary is available in RDF. The primary artefact dcat.ttl is a serialization of the core DCAT vocabulary. Alongside it are a set of other RDF files that provide additional information, including:

  1. alignments to other vocabularies, some of which are normative and some of which are only for guidance
  2. additional axioms, which can be useful in some contexts
  3. some profiles of DCAT, including a profile that corresponds to the 2014 version of DCAT [[?VOCAB-DCAT-20140116]]

The implementation of a DCAT 2014 profile of the revised DCAT is being considered.

Elements from other vocabularies

DCAT requires use of elements from a number of other vocabularies. Furthermore, DCAT may be augmented by additional elements from external vocabularies, following the usual RDFS [[!RDF-SCHEMA]] and OWL2 [[!OWL2-OVERVIEW]] rules and patterns.

Complementary vocabularies

Elements from a number of complementary vocabularies MAY be used together with DCAT to provide more detailed information. For example: properties from the VoID vocabulary [[?VOID]] allow the description of various statistics about a DCAT-described dataset if that dataset is in RDF format; properties from the Provenance ontology [[!PROV-O]] can be used to provide more information about the workflow that generated a dataset or service and related activities and agents; classes and properties from the Organization Ontology [[!VOCAB-ORG]] can be used to explain additional details of responsible agents.

Element definitions

The definitions (including domain and range) of terms outside the DCAT namespace are provided here only for convenience and MUST NOT be considered normative. The authoritative definitions of these terms are in the corresponding specifications, i.e. [[!DC11]], [[!DCTERMS]], [[!FOAF]], [[!PROV-O]], [[!RDF-SCHEMA]], [[!SKOS-REFERENCE]], [[!XMLSCHEMA11-2]] and [[?VCARD-RDF]].

Class: Catalog

The following properties are recommended for use on this class: catalog record, hasPart, dataset, service, catalog, homepage, themes

The following properties are inherited from the super-class dcat:Dataset: distribution, frequency, spatial/geographic coverage, spatial resolution, temporal coverage, temporal resolution, was generated by

The following properties are inherited from the super-class dcat:Resource: conformsTo, contact point, creator, description, identifier, keyword/tag, landing page, catalog language, relation, publisher, release date, theme/category, title, type/genre, license, rights, update/modification date,

The scope of DCAT 2014 was catalogs of datasets [[?VOCAB-DCAT-20140116]]. A number of use cases for the revision involve also having data distribution services as members of a catalog - see DCAT Distribution to describe web services - ID6 and Modeling service-based data access - ID18. It has been decided to add an explicit class for Data Distribution Services in this revision of DCAT, and to enable these to be part of a Catalog. Provision for other services to also be part of a Catalog is also enabled, as well as for Catalogs to be composed of other Catalogs. See Issue #172 and Issue #116.

RDF Class:dcat:Catalog
Sub-class of:Dataset
Definition:A curated collection of metadata about datasets and data services
Usage note:A web-based data catalog is typically represented as a single instance of this class.
See also: Catalog record, Dataset

Property: homepage

RDF Property:foaf:homepage
Definition:A homepage of the catalog (a public web document usually available in HTML).
Range:foaf:Document
Usage note:foaf:homepage is an inverse functional property (IFP) which means that it MUST be unique and precisely identify the web-page for the resource. This property indicates the canonical web-page, which might be helpful in cases where there is more than one web-page about the resource.

Property: themes

RDF Property:dcat:themeTaxonomy
Definition:A knowledge organization system (KOS) used to classify catalog's datasets and services.
Domain:dcat:Catalog
Range:skos:ConceptScheme

Property: hasPart

Explicit use of this property added in this revision of DCAT.

RDF Property:dct:hasPart
Definition:An item that is listed in the catalog.
Domain:dcat:Catalog
Range:dcat:Resource
Usage note:This is the most general predicate for membership of a catalog. Use of a more specific sub-property is recommended when available.
See also:Sub-properties of dct:hasPart in particular dcat:dataset, dcat:catalog, dcat:service.

Property: dataset

RDF Property:dcat:dataset
Definition:A collection of data that is listed in the catalog.
Sub property of:dct:hasPart
Domain:dcat:Catalog
Range:dcat:Dataset

Property: service

Property added in this revision of DCAT.

RDF Property:dcat:service
Definition:A site or end-point that is listed in the catalog.
Sub property of:dct:hasPart
Domain:dcat:Catalog
Range:dcat:DataService

Property: catalog

Property added in this revision of DCAT.

RDF Property:dcat:catalog
Definition:A catalog whose contents are of interest in the context of this catalog
Sub property of:dct:hasPart
Domain:dcat:Catalog
Range:dcat:Catalog

Property: catalog record

RDF Property:dcat:record
Definition:A record describing the registration of a single dataset or dataservice that is part of the catalog.
Domain:dcat:Catalog
Range:dcat:CatalogRecord

Class: Catalogued Resource

The following properties are recommended for use on this class: accessRights, conformsTo, contact point, creator, description, hasPolicy, identifier, keyword/tag, landing page, license, resource language, relation, rights, qualified relation, publisher, release date, theme/category, title, type/genre, update/modification date, qualified attribution

The possible association of items with zero or multiple catalogs has been identified as a requirement to be satisfied in the revision of DCAT.

The need to be able to describe the business or project context related to production of a catalogued resource has been identified as a requirement to be satisfied in the revision of DCAT.

RDF Class:dcat:Resource
Definition:Resource published or curated by a single agent.
Usage note:The class of all catalogued resources, the superclass of dcat:Dataset, dcat:DataService, dcat:Catalog and any other member of a dcat:Catalog. This class carries properties common to all catalogued resources, including datasets and data services. It is strongly recommended to use a more specific sub-class when available.
Usage note:dcat:Resource is an extension point that enables the definition of any kind of catalog. Additional subclasses may be defined in a DCAT application profile or other DCAT application for catalogs of other kinds of resources
See also:Catalog record

The class dcat:Resource has been added to the DCAT vocabulary in this revision.

Property: accessRights

RDF Property:dct:accessRights
Definition:A rights statement that concerns how the resource is accessed.
Range:dct:RightsStatement
Usage note:Information about licenses and rights MAY be provided for the Resource. See also guidance at License and rights statements.
See also:resource rights

Property: conforms to

RDF Property:dct:conformsTo
Definition:An established standard to which the described catalogued resource conforms.
Range:dct:Standard (A basis for comparison; a reference point against which other things can be evaluated.)
Usage note:This property SHOULD be used to indicate the model, schema, ontology, view or profile that the catalogued resource content conforms to.

dct:Standard is defined as "A basis for comparison; a reference point against which other things can be evaluated." The target resource is not restricted to formal standards issued by bodies like ISO and W3C. In this context, it is any resource that specifies one or more aspects of the catalogued resource content, for example schema, semantics, syntax, usage guidelines, file format, or specific serialization. The meaning of conformance is determined by provisions in the target standard.

Property: contact point

In DCAT 2014 [[VOCAB-DCAT-20140116]] the domain of dcat:contactPoint was dcat:Dataset, which limited use of this property in other contexts. The domain has been relaxed in this revision - see Issue #95.

RDF Property:dcat:contactPoint
Definition:Relevant contact information for the catalogued resource. Use of vCard is recommended [[?VCARD-RDF]].
Range:vcard:Kind

Property: resource creator

New property added in this revision of DCAT, specifically added when considering the data citation requirement and added to the dcat:Resource class, as the Dataset superclass. For more details, see the data citation section.

The use of the [[?PROV-O]] qualified-attribution pattern is described below. `dct:creator` corresponds with a general attribution with the role 'creator'.

RDF Property:dct:creator
Definition:The entity responsible for producing the resource.
Range:foaf:Agent
Usage note:Resources of type foaf:Agent are recommended as values for this property.
See also:Class: Organization/Person

Property: description

RDF Property:dct:description
Definition:free-text account of the item.
Range:rdfs:Literal

Property: title

RDF Property:dct:title
Definition:A name given to the item.
Range:rdfs:Literal

Property: release date

RDF Property:dct:issued
Definition:Date of formal issuance (e.g., publication) of the item.
Range:rdfs:Literal encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]]
Usage note:This property SHOULD be set using the first known date of issuance.
See also: catalog record listing date and distribution release date

Property: update/modification date

RDF Property:dct:modified
Definition:Most recent date on which the item was changed, updated or modified.
Range:rdfs:Literal encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]]
Usage note:The value of this property indicates a change to the actual item, not a change to the catalog record. An absent value MAY indicate that the item has never changed after its initial publication, or that the date of last modification is not known, or that the item is continuously updated.
See also:dataset frequency
See also:dataset frequency, catalog record modification date and distribution modification date

Property: language

RDF Property:dct:language
Definition:A language of the item. This refers to the natural language used for textual metadata (i.e. titles, descriptions, etc) of a catalogued resource (i.e. dataset or service) or the textual values of a dataset distribution
Range:dct:LinguisticSystem
Resources defined by the Library of Congress (1, 2) SHOULD be used.
If a ISO 639-1 (two-letter) code is defined for language, then its corresponding IRI SHOULD be used; if no ISO 639-1 code is defined, then IRI corresponding to the ISO 639-2 (three-letter) code SHOULD be used.
Usage note:Repeat this property if the resource is available in multiple languages.
Usage note:The value(s) provided for members of a catalog (i.e. dataset or service) override the value(s) provided for the catalog if they conflict.
Usage note:If representations of a dataset are available for each language separately, define an instance of dcat:Distribution for each language and describe the specific language of each distribution using dct:language (i.e. the dataset will have multiple dct:language values and each distribution will have just one as the value of its dct:language property).

Property: publisher

The use of the [[?PROV-O]] qualified-attribution pattern is described below. `dct:publisher` corresponds with a general attribution with the role 'publisher'.

RDF Property:dct:publisher
Definition:The entity responsible for making the item available.
Usage note:Resources of type foaf:Agent are recommended as values for this property.
See also:Class: Organization/Person

Property: identifier

RDF Property:dct:identifier
Definition:A unique identifier of the item.
Range:rdfs:Literal
Usage note:The identifier might be used as part of the URI of the item, but still having it represented explicitly is useful.

Property: theme/category

In DCAT 2014 [[?VOCAB-DCAT-20140116]] the domain of dcat:theme was dcat:Dataset, which limited use of this property in other contexts. The domain has been relaxed in this revision - see Issue #123.

RDF Property:dcat:theme
Definition:A main category of the resource. A resource can have multiple themes.
Sub property of:dct:subject
Range:skos:Concept
Usage note:The set of skos:Concepts used to categorize the resources are organized in a skos:ConceptScheme describing all the categories and their relations in the catalog.
See also:catalog themes

Property: type/genre

Added in DCAT revision - see Issue #64.

RDF Property:dct:type
Definition:The nature or genre of the resource.
Sub property of:dc:type
Range:rdfs:Class
Usage note:The value SHOULD be taken from a well governed and broadly recognised controlled vocabulary, such as:
  1. DCMI Type vocabulary [[?DCTERMS]]
  2. ISO 19115 scope codes [[?ISO-19115-1]]
  3. Datacite resource types [[?DataCite]]
  4. PARSE.Insight content-types used by re3data.org [[?RE3DATA-SCHEMA]] (see item 15 contentType)
  5. MARC intellectual resource types
Some members of these controlled vocabularies are not strictly suitable for datasets or data services (e.g. DCMI Type Event, PhysicalObject; ISO 19115 CollectionHardware, CollectionSession, Initiative, Sample, Repository), but might be used in the context of other kinds of catalogs defined in DCAT profiles or applications.
Usage note:To describe the file format, physical medium, or dimensions of the resource, use the dct:format element.

Property: resource relation

RDF Property:dct:relation
Definition:A resource with an unspecified relationship to the catalogued item.
Usage note:dct:relation SHOULD be used where the nature of the relationship between a catalogued item and related resources is not known. A more specific sub-property SHOULD be used if the nature of the relationship of the link is known. The property dcat:distribution SHOULD be used to link from a dcat:Dataset to a representation of the dataset, described as a dcat:Distribution
See also:Sub-properties of dct:relation in particular dcat:distribution, dct:hasPart, (and its sub-properties dcat:catalog, dcat:dataset, dcat:service ), dct:isPartOf, dct:conformsTo, dct:isFormatOf, dct:hasFormat, dct:isVersionOf, dct:hasVersion, dct:replaces, dct:isReplacedBy, dct:references, dct:isReferencedBy, dct:requires, dct:isRequiredBy

Many existing and legacy catalogues do not distinguish between dataset components, representations, documentation, schemata and other resources that are lumped together as part of a dataset. dct:relation is a super-property of a number of more specific properties which express more precise relationships, so use of dct:relation is not inconsistent with a subsequent reclassification with more specific semantics, though the more specialized sub-properties SHOULD be used to link a dataset to component and supplementary resources if possible.

Use of this Dublin Core Terms property in this context added in this revision of DCAT.

Property: qualified relation

RDF Property:dcat:qualifiedRelation
Definition:Link to a description of a relationship with another resource
Sub-property of:prov:qualifiedInfluence
Domain:dcat:Resource
Range:dcat:Relationship
Usage note:Used to link to another resource where the nature of the relationship is known but does not match one of the standard Dublin Core properties (dct:hasPart, dct:isPartOf, dct:conformsTo, dct:isFormatOf, dct:hasFormat, dct:isVersionOf, dct:hasVersion, dct:replaces, dct:isReplacedBy, dct:references, dct:isReferencedBy, dct:requires, dct:isRequiredBy) or PROV-O properties (prov:wasDerivedFrom, prov:wasInfluencedBy, prov:wasQuotedFrom, prov:wasRevisionOf, prov:hadPrimarySource, prov:alternateOf, prov:specializationOf).

This DCAT property follows the common qualified relation pattern .

Property added in this revision of DCAT.

Property: keyword/tag

In DCAT 2014 [[?VOCAB-DCAT-20140116]] the domain of dcat:keyword was dcat:Dataset, which limited use of this property in other contexts. The domain has been relaxed in this revision - see Issue #121.

RDF Property:dcat:keyword
Definition:A keyword or tag describing the resource.
Range:rdfs:Literal

Property: landing page

In DCAT 2014 [[?VOCAB-DCAT-20140116]] the domain of dcat:landingPage was dcat:Dataset, which limited use of this property in other contexts. The domain has been relaxed in this revision - see Issue #122.

RDF Property:dcat:landingPage
Definition:A Web page that can be navigated to in a Web browser to gain access to the catalog, a dataset, its distributions and/or additional information.
Sub property of:foaf:page
Range:foaf:Document
Usage note: If the distribution(s) are accessible only through a landing page (i.e. direct download URLs are not known), then the landing page link SHOULD be duplicated as dcat:accessURL on a distribution. (see )

Property: qualified attribution

RDF Property:prov:qualifiedAttribution
Definition:Link to an Agent having some form of responsibility for the resource
Sub-property of:prov:qualifiedInfluence
Domain:prov:Entity
Range:prov:Attribution
Usage note:Used to link to an Agent where the nature of the relationship is known but does not match one of the standard Dublin Core properties (dct:creator, dct:publisher). Use dcat:hadRole on the prov:Attribution to capture the responsibility of the Agent with respect to the Resource. See https://w3c.github.io/dxwg/dcat/#qualified-attribution for usage examples.

This DCAT property follows the common qualified relation pattern .

Property added in this revision of DCAT.

Property: license

RDF Property:dct:license
Definition:A legal document under which the resource is made available.
Range:dct:LicenseDocument
Usage note:Information about licenses and rights MAY be provided for the Resource. See also guidance at License and rights statements.
See also:resource rights, distribution licence

Property: rights

RDF Property:dct:rights
Definition:A statement that concerns all rights not addressed with dct:license or dct:accessRights, such as copyright statements.
Range:dct:RightsStatement
Usage note:Information about licenses and rights MAY be provided for the Resource. See also guidance at License and rights statements.
See also:resource license, distribution rights, resource accessRights

Property: hasPolicy

RDF Property:odrl:hasPolicy
Definition:A policy expressing the rights associated with the resource if using the ODRL vocabulary [[ODRL-VOCAB]].
Range:odrl:Policy
Usage note:Information about rights expressed as ODRL [[ODRL-VOCAB]] policies MAY be provided for the Resource. See also guidance at License and rights statements.
See also:resource license, resource accessRights, resource rights

Class: Catalog Record

The following properties are recommended for use on this class (dcat:CatalogRecord): conforms to, description, listing date, primary topic, title, update/modification date

The need to be able to express rights relating to the re-use of DCAT metadata has been identified as a requirement to be satisfied in the revision of DCAT.

The need to be able to link a metadata record to its original source has been identified as a requirement to be satisfied in the revision of DCAT.

RDF Class:dcat:CatalogRecord
Definition:A record in a catalog, describing the registration of a single dcat:Resource.
Usage noteThis class is optional and not all catalogs will use it. It exists for catalogs where a distinction is made between metadata about a dataset or service and metadata about the entry in the catalog about the dataset or service. For example, the publication date property of the dataset reflects the date when the information was originally made available by the publishing agency, while the publication date of the catalog record is the date when the dataset was added to the catalog. In cases where both dates differ, or where only the latter is known, the publication date SHOULD only be specified for the catalog record. Notice that the W3C PROV Ontology [[?PROV-O]] allows describing further provenance information such as the details of the process and the agent involved in a particular change to a dataset or its registration.
See alsoDataset

If a catalog is represented as an RDF Dataset with named graphs (as defined in [[!SPARQL11-QUERY]]), then it is appropriate to place the description of each dataset (consisting of all RDF triples that mention the dcat:Dataset, dcat:CatalogRecord, and any of its dcat:Distributions) into a separate named graph. The name of that graph SHOULD be the IRI of the catalog record.

Property: title

RDF Property:dct:title
Definition:A name given to the record.
Range:rdfs:Literal

Property: description

RDF Property:dct:description
Definition:A free-text account of the record.
Range:rdfs:Literal

Property: listing date

RDF Property:dct:issued
Definition:The date of listing (i.e. formal recording) of the corresponding dataset or service in the catalog.
Range:rdfs:Literal encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]]
Usage note:This indicates the date of listing the dataset in the catalog and not the publication date of the dataset itself.
See also:resource release date

Property: update/modification date

RDF Property:dct:modified
Definition:Most recent date on which the catalog entry was changed, updated or modified.
Range:rdfs:Literal encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]]
Usage note:This indicates the date of last change of a catalog entry, i.e. the catalog metadata description of the dataset, and not the date of the dataset itself.
See also:resource modification date

Property: primary topic

RDF Property:foaf:primaryTopic
Definition:The dcat:Resource (dataset or service) described in the record.
Usage note:foaf:primaryTopic property is functional: each catalog record can have at most one primary topic i.e. describes one dataset or service.

Property: conforms to

New property in this context in this revision of DCAT.

RDF Property:dct:conformsTo
Definition:An established standard to which the described resource conforms.
Range:dct:Standard (A basis for comparison; a reference point against which other things can be evaluated.)
Usage note:This property SHOULD be used to indicate the model, schema, ontology, view or profile that the catalog record metadata conforms to.

dct:Standard is defined as "A basis for comparison; a reference point against which other things can be evaluated." The target resource is not restricted to formal standards issued by bodies like ISO and W3C. In this context, it is any resource that specifies one or more aspects of the catalog record content, for example schema, semantics, syntax, usage guidelines, file format, or specific serialization. The meaning of conformance is determined by provisions in the target standard.

Class: Dataset

The following properties are recommended for use on this class: distribution, frequency, spatial/geographic coverage, spatial resolution, temporal coverage, temporal resolution, was generated by

The following properties are inherited from the super-class dcat:Resource: accessRights, conformsTo, contact point, creator, description, hasPolicy, identifier, keyword/tag, landing page, license, resource language, relation, rights, qualified relation, publisher, release date, theme/category, title, type/genre, update/modification date, qualified attribution

Information about licenses and rights SHOULD be provided on the level of Distribution. Information about licenses and rights MAY be provided for a Dataset in addition to but not instead of the information provided for the Distributions of that Dataset. Providing license or rights information for a Dataset that is different from information provided for a Distribution of that Dataset SHOULD be avoided as this can create legal conflicts.

The need to provide richer descriptions of dataset aspects (e.g. instrument/sensor used, spatial feature, observable property, quantity kind) has been identified as a requirement to be satisfied in the revision of DCAT.

The need to be able to link a dataset with publications arising from it has been identified as a requirement to be satisfied in the revision of DCAT.

The need provide a more comprehensive method for describing dataset provenance has been identified as a requirement to be satisfied in the revision of DCAT. A preliminary alignment of DCAT with PROV-O is available.

The need to be able to provide summary statistics about a dataset has been identified as a requirement to be satisfied in the revision of DCAT.

The need to be able to provide usage notes for a dataset or distribution has been identified as a requirement to be satisfied in the revision of DCAT.

RDF Class:dcat:Dataset
Definition:A collection of data, published or curated by a single agent, and available for access or download in one or more representations.
Sub class of:dcat:Resource
Usage note:This class describes the conceptual dataset. One or more representations might be available, with differing schematic layouts and formats or serializations.
Usage note:This class describes the actual dataset as published by the dataset provider. In cases where a distinction between the actual dataset and its entry in the catalog is necessary (because metadata such as modification date and maintainer might differ), the catalog record class can be used for the latter.

In DCAT 2014 [[?VOCAB-DCAT-20140116]] dcat:Dataset was a sub-class of dctype:Dataset, which is a member of the DCMI Types vocabulary [[?DCTERMS]]. The scope of dcat:Dataset also includes other members of the DCMI Types vocabulary, such as various multimedia (imagery, sound, video) and text, so the sub-class relationship from DCAT 2014 [[?VOCAB-DCAT-20140116]] has been removed in this revised DCAT vocabulary - see Issue #98.

Note that members of the DCMI Types vocabulary may appear as the value of the dct:type property, as shown in Classifying dataset types.

Property: dataset distribution

RDF Property:dcat:distribution
Definition:An available distribution of the dataset.
Sub property of:dct:relation
Domain:dcat:Dataset
Range:dcat:Distribution

Property: frequency

RDF Property:dct:accrualPeriodicity
Definition:The frequency at which dataset is published.
Range:dct:Frequency (A rate at which something recurs)
Usage note: The value of dct:accrualPeriodicity gives the rate at which the dataset-as-a-whole is updated. This may be complemented by dcat:temporalResolution to give the time between collected data points in a time series.

For example, a 15-minute time-series that is published daily could be described

<ds913>
    a dcat:Dataset ;
    dct:accrualPeriodicity <http://purl.org/cld/freq/daily> ;
    dcat:temporalResolution "PT15M"^^xsd:duration ;
.

A dataset composed of items added hourly and published immediately could be described

<ds782>
    a dcat:Dataset ;
    dct:accrualPeriodicity <http://purl.org/cld/freq/continuous> ;
    dcat:temporalResolution "PT1H"^^xsd:duration ;
.

Property: spatial/geographical coverage

The need to indicate the spatial reference system used in the spatial description of a dataset has been identified as a requirement to be satisfied in the revision of DCAT.

The need to be able to describe the spatial coverage of a dataset as a geometry has been identified as a requirement to be satisfied in the revision of DCAT.

RDF Property:dct:spatial
Definition:The geographical area covered by the dataset.
Range:dct:Location (A spatial region or named place)

Property: spatial resolution

RDF Property:dcat:spatialResolutionInMeters
Definition:minimum spatial separation resolvable in a dataset, measured in meters
Range:xsd:decimal
Usage note:If the dataset is an image or grid this should correspond to the spacing of items. For other kinds of spatial dataset, this property will usually indicate the smallest distance between items in the dataset.

The range of this property is a decimal number representing a length in meters. This is intended to provide a summary indication of the spatial resolution of the data as a single number. More complex descriptions of various aspects of spatial precision, accuracy, resolution and other statistics can be provided using the Data Quality Vocabulary [[VOCAB-DQV]].

New property in this context in this revision of DCAT.

Property: temporal coverage

The need to be able to describe the temporal coverage of a dataset in a structured way has been identified as a requirement to be satisfied in the revision of DCAT.

RDF Property:dct:temporal
Definition:The temporal period that the dataset covers.
Range:dct:PeriodOfTime (An interval of time that is named or defined by its start and end dates)

Property: temporal resolution

RDF Property:dcat:temporalResolution
Definition:minimum time period resolvable in the dataset
Range:xsd:duration
Usage note:If the dataset is a time-series this should correspond to the spacing of items in the series. For other kinds of dataset, this property will usually indicate the smallest time difference between items in the dataset.

This is intended to provide a summary indication of the temporal resolution of the data distribution as a single value. More complex descriptions of various aspects of temporal precision, accuracy, resolution and other statistics can be provided using the Data Quality Vocabulary [[VOCAB-DQV]].

New property in this context in this revision of DCAT.

Property: was generated by

RDF Property:prov:wasGeneratedBy
Definition:An activity that generated, or provides the business context for, the creation of the dataset.
Domain:prov:Entity
Range:prov:Activity An activity is something that occurs over a period of time and acts upon or with entities; it may include consuming, processing, transforming, modifying, relocating, using, or generating entities.
Usage note:The activity associated with generation of a dataset will typically be an initiative, project, mission, survey, on-going activity ("business as usual") etc. Multiple prov:wasGeneratedBy properties can be used to indicate the dataset production context at various levels of granularity.
Usage note:Use prov:qualifiedGeneration to attach additional details about the relationship between the dataset and the activity, e.g. the exact time that the dataset was produced during the lifetime of a project

New property in this context in this revision of DCAT.

Details about how to describe the activity that generated a dataset, such as a project, initiative, on-going activity, mission or survey, are out of scope for this document. prov:Activity provides for some basic properties such as begin and end time, associated agents etc. Further details may be provided through classes defined in applications. A number of ontologies for describing projects are available, for example VIVO for academic research projects [[?VIVO-ISF]], DOAP (Description of a Project) for software projects [[?DOAP]], and DBPedia for general projects [[?DBPEDIA-ONT]] which are expected to be suitable for different applications.

Class: Distribution

The following properties are recommended for use on this class: access rights, access URL, access service, byte size, compression format, conforms to, description, download URL, format, has Policy, license, media type, packaging format, release date, rights, spatial resolution, temporal resolution, title, update/modification date,

RDF class:dcat:Distribution
Definition: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).
Usage note:This represents a general availability of a dataset. It implies no information about the actual access method of the data, i.e. whether by direct download, API, or through a Web page. The use of dcat:downloadURL property indicates directly downloadable distributions.
See also:Data distribution service

Examples of distributions include a CSV file, a netCDF file, a JSON document, or a data-cube, files made accessible according to different profiles, such as XML or JSON schemas or ShEx or SHACL expressions.

In some cases all distributions of a dataset will be fully informationally equivalent, in the sense that lossless transformations between the representations are possible. An example would be different serializations of an RDF graph using RDF/XML, Turtle, N3, JSON-LD. However, in other cases the distributions might have different levels of fidelity to the underlying data. For example, a graphical representation alongside a CSV file. The question of whether different representations can be understood to be distributions of the same dataset is use-case specific, so the judgement is the responsibility of the provider.

The scope of dcat:Distribution here is narrower than in DCAT-2014 [[?VOCAB-DCAT-20140116]], where it also included APIs and feeds. Data catalogues designed using DCAT-2014 therefore used instances of type dcat:Distribution to describe data distribution services. Applications consuming DCAT should be aware that catalogues designed using DCAT-2014 might use dcat:Distribution to represent both services and representations.

Under the revised scope, instances of type dcat:Distribution SHOULD be limited to representations of datasets which might be transported as files, and SHOULD NOT be used for data services such as APIs or feeds. Data services including APIs and feeds SHOULD be described using instances of type dcat:DataService whose sub-class dcat:DataDistributionService MAY serve dcat:Distributions.

Links between a dcat:Distribution and services or web addresses where it can be accessed are expressed using dcat:accessURL, dcat:accessService, dcat:downloadURL, as shown in and described in the definitions below.

The intention of the phrase "informationally equivalent" needs to be clarified, in particular as different serializations may have different expressivity.

Property: title

RDF Property:dct:title
Definition:A name given to the distribution.
Range:rdfs:Literal

Property: description

RDF Property:dct:description
Definition:free-text account of the distribution.
Range:rdfs:Literal

Property: release date

RDF Property:dct:issued
Definition:Date of formal issuance (e.g., publication) of the distribution.
Range:rdfs:Literal encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]]
Usage note:This property SHOULD be set using the first known date of issuance.
See also:resource release date

Property: update/modification date

RDF Property:dct:modified
Definition:Most recent date on which the distribution was changed, updated or modified.
Range:rdfs:Literal encoded using the relevant ISO 8601 Date and Time compliant string [[?DATETIME]] and typed using the appropriate XML Schema datatype [[!XMLSCHEMA11-2]]
See also:resource modification date

Property: license

RDF Property:dct:license
Definition:A legal document under which the distribution is made available.
Range:dct:LicenseDocument
Usage note:Information about licenses and rights SHOULD be provided on the level of Distribution. Information about licenses and rights MAY be provided for a Dataset in addition to but not instead of the information provided for the Distributions of that Dataset. Providing license or rights information for a Dataset that is different from information provided for a Distribution of that Dataset SHOULD be avoided as this can create legal conflicts. See also guidance at License and rights statements.
See also:distribution rights resource license

Property: accessRights

RDF Property:dct:accessRights
Definition:A rights statement that concerns how the distribution is accessed.
Range:dct:RightsStatement
Usage note:Information about licenses and rights MAY be provided for the Distribution. See also guidance at License and rights statements.
See also:distribution license, distribution rights, resource accessRights

Property: rights

RDF Property:dct:rights
Definition:Information about rights held in and over the distribution.
Range:dct:RightsStatement
Usage note:dct:license, which is a sub-property of dct:rights, can be used to link a distribution to a license document. However, dct:rights allows linking to a rights statement that can include licensing information as well as other information that supplements the license such as attribution.
Information about licenses and rights SHOULD be provided on the level of Distribution. Information about licenses and rights MAY be provided for a Dataset in addition to but not instead of the information provided for the Distributions of that Dataset. Providing license or rights information for a Dataset that is different from information provided for a Distribution of that Dataset SHOULD be avoided as this can create legal conflicts. See also guidance at License and rights statements.
See also:distribution license, resource rights

Property: hasPolicy

RDF Property:odrl:hasPolicy
Definition:A policy expressing the rights associated with the distribution if using the ODRL vocabulary [[ODRL-VOCAB]].
Range:odrl:Policy
Usage note:Information about rights expressed as ODRL [[ODRL-VOCAB]] policies MAY be provided for the Distribution. See also guidance at License and rights statements.
See also:resource license, distribution accessRights, distribution rights

Property: access address

The granularity of dcat:accessURL is being re-considered to provide different usages for list and item endpoints as well as supporting the declaration of different profiles (for list results and data payload).

RDF Property:dcat:accessURL
Definition:A URL of the resource that gives access to a distribution of the dataset. E.g. landing page, feed, SPARQL endpoint.
Domain:dcat:Distribution
Range:rdfs:Resource
Usage note:dcat:accessURL SHOULD be used for the address of a service or location that can provide access to this distribution, typically through a web form, query or API call.
dcat:downloadURL is preferred for direct links to downloadable resources.
If the distribution(s) are accessible only through a landing page (i.e. direct download URLs are not known), then the landingPage address associated with the dcat:Dataset SHOULD be duplicated as accessURL on a distribution. (see )
See alsodownload address, access service

dcat:accessURL matches the property-chain dcat:accessService/dcat:endpointURL. In the RDF representation of DCAT this is axiomatized as an OWL property-chain axiom.

Property: access service

New property in this revision of DCAT.

RDF Property:dcat:accessService
Definition:A site or end-point that gives access to the distribution of the dataset
Range:dcat:DataDistributionService
Usage note:dcat:accessService SHOULD be used to link to a description of a dcat:DataDistributionService that can provide access to this distribution.
See alsodownload address, access address

Property: download address

RDF Property:dcat:downloadURL
Definition:The URL of the downloadable file in a given format. E.g. CSV file or RDF file. The format is indicated by the distribution's dct:format and/or dcat:mediaType
Domain:dcat:Distribution
Range:rdfs:Resource
Usage note:dcat:downloadURL SHOULD be used for the address at which this distribution is available directly, typically through a HTTP Get request.
See alsoaccess address, access service

Property: byteSize

The axiomatization of dcat:byteSize is being re-evaluated as part of the revision of DCAT.

RDF Property:dcat:byteSize
Definition:The size of a distribution in bytes.
Domain:dcat:Distribution
Range:rdfs:Literal typed as xsd:decimal.
Usage note:The size in bytes can be approximated when the precise size is not known.

Property: spatial resolution

RDF Property:dcat:spatialResolutionInMeters
Definition:The minimum spatial separation resolvable in a dataset distribution, measured in meters.
Range:xsd:decimal
Usage note:If the dataset is an image or grid this should correspond to the spacing of items. For other kinds of spatial dataset, this property will usually indicate the smallest distance between items in the dataset.
Usage note:Alternative spatial resolutions might be provided as different dataset distributions

The range of this property is a decimal number representing a length in meters. This is intended to provide a summary indication of the spatial resolution of the data distribution as a single number. More complex descriptions of various aspects of spatial precision, accuracy, resolution and other statistics can be provided using the Data Quality Vocabulary [[VOCAB-DQV]].

New property in this context in this revision of DCAT.

Property: temporal resolution

RDF Property:dcat:temporalResolution
Definition:minimum time period resolvable in the dataset distribution
Range:xsd:duration
Usage note:If the dataset is a time-series this should correspond to the spacing of items in the series. For other kinds of dataset, this property will usually indicate the smallest time difference between items in the dataset.
Usage note:Alternative temporal resolutions might be provided in different dataset distributions

This is intended to provide a summary indication of the temporal resolution of the data distribution as a single value. More complex descriptions of various aspects of temporal precision, accuracy, resolution and other statistics can be provided using the Data Quality Vocabulary [[VOCAB-DQV]].

New property in this context in this revision of DCAT.

Property: conforms to

New property in this context in this revision of DCAT.

RDF Property:dct:conformsTo
Definition:An established standard to which the distribution conforms.
Range:dct:Standard (A basis for comparison; a reference point against which other things can be evaluated.)
Usage note:This property SHOULD be used to indicate the model, schema, ontology, view or profile that this representation of a dataset conforms to. This is (generally) a complementary concern to the media-type or format.
See also:format, media type

dct:Standard is defined as "A basis for comparison; a reference point against which other things can be evaluated." It is not restricted to formal standards issued by bodies like ISO and W3C. In this context it will usually be used for a schema, ontology, data model or profile which specifies the structure of a dataset distribution. This is not necessarily tied to a single encoding or serialization.

Property: media type

The range of dcat:mediaType has been tightened from dct:MediaTypeOrExtent to dct:MediaType as part of the revision of DCAT.

RDF Property:dcat:mediaType
Definition:The media type of the distribution as defined by IANA [[!IANA-MEDIA-TYPES]].
Sub property of:dct:format
Domain:dcat:Distribution
Range:dct:MediaType
Usage note:This property SHOULD be used when the media type of the distribution is defined in IANA [[!IANA-MEDIA-TYPES]], otherwise dct:format MAY be used with different values.
See also:format , conforms to

Property: format

RDF Property:dct:format
Definition:The file format of the distribution.
Range:dct:MediaTypeOrExtent
Usage note: dcat:mediaType SHOULD be used if the type of the distribution is defined by IANA [[!IANA-MEDIA-TYPES]].
See also:media type, conforms to

Property: compression format

RDF Property:dcat:compressFormat
Definition:The format of the file in which the data is contained in a compressed form, e.g. to reduce the size of the downloadable file.
Range:dct:MediaType
Usage note:This property to be used when the files in the distribution are compressed, e.g. in a ZIP file. The format SHOULD be expressed using a media type as defined by IANA [[!IANA-MEDIA-TYPES]], if available.
See also:packaging format.

Property: packaging format

RDF Property:dcat:packageFormat
Definition:The format of the file in which one or more data files are grouped together, e.g. to enable a set of related files to be downloaded together.
Range:dct:MediaType
Usage note:This property to be used when the files in the distribution are packaged, e.g. in a TAR file. The format SHOULD be expressed using a media type as defined by IANA [[!IANA-MEDIA-TYPES]], if available.
See also:compression format.

Class: Data Service

The class dcat:DataService has been added to the DCAT vocabulary in this revision.

The following properties are recommended for use on this class: endpointDescription, endpointURL, license, accessRights

The following properties are inherited from the super-class dcat:Resource: accessRights, conformsTo, contact point, creator, description, hasPolicy, identifier, keyword/tag, landing page, license, resource language, relation, rights, qualified relation, publisher, release date, theme/category, title, type/genre, update/modification date, qualified attribution

RDF Class:dcat:DataService
Definition:A site or end-point providing operations related to the discovery of, access to, or processing functions on, data or related resources
Sub class of:dcat:Resource
Sub class of:dctype:Service
Usage note:The class dcat:DataService is an extension point for the description of any kind of data service. Currently only one subclass is defined - DataDistributionService - but additional subclasses may be defined in a DCAT application profile or other DCAT application for catalogs of other kinds of services
Usage note:The kind of service can be indicated using the dct:type property. Its value may be taken from a controlled vocabulary such as the INSPIRE spatial data service type vocabulary

Property: endpoint address

RDF Property:dcat:endpointURL
Definition:The location of the service end-point (an IRI).
Domain:dcat:DataService
Range:rdfs:Resource

Property: endpoint description

RDF Property:dcat:endpointDescription
Definition:A description of the service end-point, including its operations, parameters etc.
Domain:dcat:DataService
Range:rdfs:Resource
Usage note:The endpoint description gives specific details of the actual endpoint instance, while dct:conformsTo is used to indicate the general standard or specification that the endpoint implements.
Usage note:An endpoint description may be expressed in a machine-readable form, such as an OpenAPI (Swagger) description [[?OpenAPI]], an OGC getCapabilities response [[?WFS]], [[?ISO-19142]], [[?WMS]], [[?ISO-19128]], a SPARQL Service Description [[?SPARQL11-SERVICE-DESCRIPTION]], an [[?OpenSearch]] or [[?WSDL20]] document, a Hydra API description [[?HYDRA]], else in text or some other informal mode if a formal representation is not possible.

Property: license

RDF Property:dct:license
Definition:A legal document under which the service is made available.
Range:dct:LicenseDocument
See also:distribution rights, resource license

Property: access rights

RDF Property:dct:accessRights
Definition:Access Rights MAY include information regarding access or restrictions based on privacy, security, or other policies.
Range:dct:RightsStatement

Class: Data Distribution Service

The class dcat:DataDistributionService has been added to the DCAT vocabulary in this revision.

The following properties are recommended for use on this class: servesDataset,

The following properties are inherited from the super-class dcat:DataService: endpointDescription, endpointURL, license, accessRights

The following properties are are inherited from the super-class dcat:Resource: conformsTo, contact point, creator, description, identifier, keyword/tag, landing page, resource language, relation, qualified relation, publisher, release date, theme/category, title, type/genre, update/modification date, qualified attribution

RDF Class:dcat:DataDistributionService
Definition:A site or end-point that provides access to distributions of existing datasets or subsets of datasets
Sub class of:dcat:DataService
Usage note:A DataDistributionService is usually bound to one or more specified Datasets, which are indicated by the dcat:servesDataset property.
Usage note:A data discovery service supports discovery of data, usually by providing access to a Catalog. In that context the data discovery service can be understood as a DataDistributionService in which least one dcat:Catalog appears as the object of its dcat:servesDataset property

Property: serves dataset

RDF Property:dcat:servesDataset
Definition:A collection of data that this DataDistributionService can distribute
Range:dcat:Dataset

Class: Concept Scheme

RDF Class:skos:ConceptScheme
Definition:A knowledge organization system (KOS) used to represent themes/categories of datasets in the catalog.
See also:catalog themes, dataset theme

Class: Concept

RDF Class:skos:Concept
Definition:A category or a theme used to describe datasets in the catalog.
Usage note:It is recommended to use either skos:inScheme or skos:topConceptOf on every skos:Concept used to classify datasets to link it to the concept scheme it belongs to. This concept scheme is typically associated with the catalog using dcat:themeTaxonomy
See also:catalog themes, dataset theme

Class: Organization/Person

RDF Classes:foaf:Person for people and foaf:Organization for government agencies or other entities.
Usage note:[[!FOAF]] provides sufficient properties to describe these entities.

Class: Relationship

The class dcat:Relationship has been added to the DCAT vocabulary in this revision.

The following properties are recommended for use on this class: relation, hadRole,

RDF Class:dcat:Relationship
Definition:An association class for attaching additional information to a relationship between DCAT Resources
Sub class of:prov:EntityInfluence
Usage note:Use to characterize a relationship between datasets, and potentially other resources, where the nature of the relationship is known but is not adequately characterized by the standard Dublin Core properties (dct:hasPart, dct:isPartOf, dct:conformsTo, dct:isFormatOf, dct:hasFormat, dct:isVersionOf, dct:hasVersion, dct:replaces, dct:isReplacedBy, dct:references, dct:isReferencedBy, dct:requires, dct:isRequiredBy) or PROV-O properties (prov:wasDerivedFrom, prov:wasInfluencedBy, prov:wasQuotedFrom, prov:wasRevisionOf, prov:hadPrimarySource, prov:alternateOf, prov:specializationOf)

Property: relation

RDF Property:dct:relation
Definition:The resource related to the source resource
Usage note:In the context of a dcat:Relationship this is expected to point to another dcat:Dataset or other catalogued resource

Property: hadRole

RDF Property:dcat:hadRole
Definition:The function of an entity or agent with respect to another entity or resource.
Domain:prov:Attribution or dcat:Relationship
Range:dcat:Role
Usage note:May be used in a qualified-attribution to specify the role of an Agent with respect to an Entity. It is recommended that the value be taken from a controlled vocabulary of agent roles, such as ISO 19115 CI_RoleCode.
Usage note:May be used in a qualified-relation to specify the role of an Entity with respect to another Entity. It is recommended that the value be taken from a controlled vocabulary of entity roles.

This DCAT property complements prov:hadRole which provides the function of an entity or agent with respect to an activity.

Property added in this revision of DCAT.

Class: Role

RDF Class:dcat:Role
Definition:A role is the function of a resource or agent with respect to another resource, in the context of resource attribution or resource relationships.
Sub class of:skos:Concept
Usage note:Used in a qualified-attribution to specify the role of an Agent with respect to an Entity. It is recommended that the values be managed as a controlled vocabulary of agent roles, such as ISO 19115 CI_RoleCode
Usage note:Used in a qualified-relation to specify the role of an Entity with respect to another Entity. It is recommended that the values be managed as a controlled vocabulary of entity roles such as
- ISO 19115 DS_AssociationTypeCode
- IANA Registry of Link Relations
- DataCite metadata schema [[?DataCite]]
- MARC relators

This DCAT class complements prov:Role which provides the function of an entity or agent with respect to an activity.

Property added in this revision of DCAT.

Dereferenceable identifiers

The scientific and data provider communities use a number of different identifiers for publications, authors and data. DCAT primarily relies on persistent HTTP URIs as an effective way of making identifiers actionable. Notably, quite a few identifier schemes can be encoded as dereferenceable HTTP URIs, and some of them are also returning machine-readable metadata (e.g., DOIs [[?ISO-26324]] and ORCIDs). Regardless, data providers still might need to refer to legacy identifiers, non-HTTP dereferenceable identifiers, locally minted or third-party-provided identifiers. In these cases, [[?DCTERMS]] and [[?VOCAB-ADMS]] can be of use.

The property dct:identifier explicitly indicates HTTP URIs as well as legacy identifiers. In the following examples, dct:identifier identifies a dataset, but it can similarly be used with any kind of resources.

<https://example.org/id> a dcat:Dataset;
	dct:identifier "https://example.org/id"^^xsd:anyURI
  .

Proxy dereferenceable URIs can be used when resources have not HTTP dereferenceable IDs. For example, in the following example, https://example.org/proxyid is a proxy for id.

<https://example.org/proxyid> a dcat:Dataset;
	dct:identifier  "id"^^xsd:string
    .

The property adms:identifier [[?VOCAB-ADMS]] can express other locally minted identifiers or external identifiers, like DOI, ELI, arΧiv for creative works and ORCID, VIAF, ISNI for actors such as authors and publishers, as long as the identifiers are globally unique and stable.

The following example uses adms:schemaAgency and dct:creator to represent the authority that defines the identifier scheme (e.g., the DOI foundation in the example), adms:schemaAgency is used when the authority has no URI associated. The CrossRef and DataCite display guidelines recommend displaying DOIs as full URL link in the form https://doi.org/10.xxxx/xxxxx/.

<https://example.org/id> a dcat:Dataset;
    adms:identifier  <https://example.org/iddoi> ;
    dct:publisher <https://example.org/PoelenJorritH>.

<https://example.org/iddoi> a adms:Identifier ;
    # reading https://www.w3.org/TR/skos-reference/#notations more than one skos:notation can be set
   skos:notation "https://doi.org/10.5281/zenodo.1486279"^^xsd:anyURI;
   # the authority/agency defining the identifier scheme, used if the agency has no URI
   adms:schemaAgency "International DOI Foundation" ;
   # the authority/agency defining the identifier scheme, used if the agency has URI
   dct:creator  ex:InternationalDOIFundation .

ex:InternationalDOIFundation a foaf:Organization ;
    rdfs:label "International DOI Foundation";
    foaf:homepage <https://www.doi.org/> .

<https://example.org/PoelenJorritH> a foaf:Person;
    foaf:name "Jorrit H. Poelen" ;
    adms:identifier <https://example.org/PoelenJorritHID> .

<https://example.org/PoelenJorritHID> a adms:Identifier;
    skos:notation "https://orcid.org/0000-0003-3138-4118"^^xsd:anyURI ;
    # the authority/agency defining the identifier scheme, used if the agency has no URI
   adms:schemaAgency "ORCID" .

The example does not represent the authority responsible for assigning and maintaining identifiers using that scheme (e.g., Zenodo) as naming the registrant goes against the philosophy of DOI, where the sub-spaces are abstracted from the organisation that registers them, with the advantage that DOIs do not change when the organization changes or the responsibility for that sub-space is handed over to someone else. The example shows a locally minted identifier for the creator of the dataset (e.g., https://example.org/PoelenJorritHID) and its correspondent ORCID identifier (e.g., https://orcid.org/0000-0003-3138-4118).

When the HTTP dereferenceable ID returns an RDF/OWL description for the dataset, the use of owl:sameAs might be considered. For example,

<https://example.org/id> a dcat:Dataset;
	...
	owl:sameAs <https://doi.org/10.5281/zenodo.1486279> .

when dereferenced with media type text/turtle, https://doi.org/10.5281/zenodo.1486279 returns a [[?SCHEMA-ORG]] description for the dataset, which might dynamically enrich the description provided by https://example.org/id.

The need to distinguish between primary and alternative (or legacy) identifiers for a dataset within DCAT has been posed as a requirement. However, it is very much application-specific and would be better addressed in application profiles rather than mandating a general approach.

Depending on the application context, specific guidelines such as "DCAT-AP: How to manage duplicates?" can be adopted for distinguishing authoritative datasets from dataset harvested by third parties catalogs.

Indicating common identifier types

If identifiers are not HTTP dereferenceable, common identifier types can be served as RDF datatypes or custom OWL datatypes for the sake of interoperability, see ex:type in the following example.

<https://example.org/id> a dcat:Dataset;
	...
	adms:identifier <https://example.org/sid> .

 <https://example.org/sid> rdf:type adms:Identifier ;
 # the actual id
	 skos:notation "PA 1-060-815"^^ex:type ;
 # Human readable schema agency
	 adms:schemaAgency "US Copyright Office" ;
	 dcterms:issued "2001-09-12"^^xsd:date .

If a registered URI type is used (following [[?RFC3986]], Section 3.1), the identifier scheme is part of the URI; thus indicating a separate identifier scheme in 'type' is redundant. For example, DOI is registered as a namespace in the info URI scheme [[IANA-URI-SCHEMES]] (see DOI FAQ #11), so according to [[?RFC3986]], it should be encoded as in the following

<https://example.org/sid> rdf:type adms:Identifier ;
 # the actual id
	 skos:notation "info:doi/10.1109/5.771073"^^xsd:anyURI
 .

Otherwise, examples of common types for identifier scheme (arXiv, etc.) are defined in DataCite schema and FAIRsharing Registry.

Quality information

The Data Quality Vocabulary (DQV) [[?VOCAB-DQV]] offers common modelling patterns for different aspects of Data Quality. It can relate DCAT datasets and distributions with different types of quality information including:

Each type of quality information can pertain to one or more quality dimensions, namely, quality characteristics relevant to the consumer. The practice to see the quality as a multi-dimensional space is consolidated in the field of quality management to split the quality management into addressable chunks. DQV does not define a normative list of quality dimensions. It offers the quality dimensions proposed in ISO/IEC 25012 [[?ISOIEC25012]] and Zaveri et al. [[?ZaveriEtAl]] as two possible starting points. It also provides an RDF representation for the quality dimensions and categories defined in the latter. Ultimately, implementers will need to choose themselves the collection of quality dimensions that best fits their needs. The following section shows how DCAT and DQV can be coupled to describe the quality of datasets and distributions. For a comprehensive introduction and further examples of use, please refer to [[?VOCAB-DQV]].

We might want to include examples of quality documentation related to services.

Providing quality information

A data consumer (:consumer1) describes the quality of the dataset :genoaBusStopsDataset that includes a georeferenced list of bus stops in Genoa. He/she annotates the dataset with a DQV quality note (:genoaBusStopsDatasetCompletenessNote) about data completeness (ldqd:completeness) to warn that the dataset includes only 20500 out of the 30000 stops.

The activity :myQualityChecking employs the service :myQualityChecker to check the quality of the :genoaBusStopsDataset dataset. The metric :completenessWRTExpectedNumberOfEntities is applied to measure the dataset completeness (ldqd:completeness) and it results in the quality measurement :genoaBusStopsDatasetCompletenessMeasurement.

Other examples of quality documentation are available in [[?VOCAB-DQV]], including examples about how to express dataset accuracy and precision.

Documenting conformance to standards

This subsection shows different modelling patterns combining [[?VOCAB-DQV]] with [[?PROV-O]] and EARL [[?EARL10-Schema]] to represent the conformance degree to a stated quality standard and the details about the conformance tests.

Conformance to a standard

The use of dct:conformsTo and dct:Standard is a well-known pattern to represent the conformance to a standard. The following example, directly borrowed from [[?SDW-BP]] (Example 51), declares a fictional a:dataset conformant to the EU INSPIRE Regulation on interoperability of spatial data sets and services ("Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services").

Degree of conformance

Some legal context requires to specify the degree of conformance. For example, INSPIRE metadata adopts a specific controlled vocabulary to express non-conformance and non-evaluation beside the full compliance. Similar controlled vocabularies can be defined in other contexts.

The following example specifies some newly minted concepts representing the degree of conformance (i.e., conformant, not conformant) and declares the dct:type for indicating the result of conformance test. Following a pattern used in [[?GeoDCAT-AP]], the example uses a prov:Entity to model the conformance test (e.g., a:testResult), a prov:Activity to model the testing activity (e.g., a:testingActivity), a prov:Plan derived from the Data on the Web Best Practices [[?DWBP]] (e.g., a:conformanceTest) to check for the whole set of best practices. A qualified PROV association binds the testing activity to the conformance test.

Also, [[?VOCAB-DQV]] can be deployed to measure the compliance to a specific standard. In the following example, the :levelOfComplianceToDWBP is a quality metrics which measures the compliance of a dataset to [[?DWBP]] in terms of the percentage of passed compliance tests. The example assumes iso as a namespace prefix representing the quality dimensions and categories defined in the ISO/IEC 25012 [[?ISOIEC25012]].

The quality measurement :measurement_complianceToDWBP represents the level of compliance for dataset a:dataset, namely, measurement of the metric :levelOfComplianceToDWBP. If only a part of the compliance tests succeeds (e.g. half of the compliance tests), the measurement would look like in the following:

Conformance test results

Further information about the tests can be provided using EARL [[?EARL10-Schema]]. EARL provides specific classes to describe the testing activity, which can be adopted in conjunction with [[?PROV-O]]. The following example describes the Testing activity a:testingActivity as an earl:Assertion instead of a qualified association on the prov:Activity. The earl:Assertion states that dataset a:dataset has been tested with the conformance test a:conformanceTest, and it has passed the test as described in a:testResult.

The following example shows how the description would have looked like if the subtest a:testq1 had failed. In particular, dcterms:description and earl:info provide additional warnings or error messages in a human-readable form.

Depending on the details required about tests, [[?VOCAB-DQV]] can express the testing activity and errors as well. In the following, :error is a quality annotation that represents the previous error, and a:testResult is defined as a dqv:QualityMetadata to collect the above annotations and the compliance measurements providing provenance information.

Of course, the above modelling patterns can represent any quality tests not only conformance to standards.

Qualified relations

DCAT includes elements to support description of many aspects of datasets and data-services. Nevertheless, additional information is required in order to fully express the semantics of some relationships. An example is that, while Dublin Core [[!DC11]] provides the standard roles creator, contributor and publisher for attribution of a resource to a responsible party or agent, there are many other potential roles, see for example the CI_RoleCode values from [[?ISO-19115-1]]. Similarly, while Dublin Core and [[!PROV-O]] provide some properties to capture relationships between resources, including was derived from, was quoted from, is version of, references and several others, many additional concerns are seen in the list of ISO 19115 DS_AssociationTypeCodes, the IANA Registry of Link Relations, the DataCite metadata schema [[?DataCite]]
and the MARC relators. While these relations could be captured with additional sub-properties of dct:relation, dct:contributor, etc, this would lead to an explosion in the number of properties, and anyway the full set of potential roles and relationships is unknown.

A common approach for meeting these kinds of requirement is to introduce an additional resource to carry parameters that qualify the relationship. Precedents are the qualified terms in [[?PROV-O]] and the sample relations in the Semantic Sensor Network ontology [[?VOCAB-SSN]]. The general Qualified Relation pattern is described in [[?LinkedDataPatterns]].

Many of the qualified terms from [[!PROV-O]] are relevant to the description of resources in catalogs but these are incomplete due to the activity-centric viewpoint taken by PROV-O. Addressing some of the gaps, additional forms are included in the DCAT vocabulary to satisfy requirements that do not involve explicit Activities. These are summarized in :

UML model of DCAT qualified relationships
Qualified relationships support an extensible set of roles relating resources to agents or to other resources

Note that, while the focus of these qualified forms is to allow for additional roles on a relationship, other aspect of the relationships, such as the applicable time interval, are easily attached when a specific node is used to describe the relationship like this (e.g. see the chart of Influence relations in [[?PROV-O]] for some examples).

Relationships between datasets and agents

The standard Dublin Core properties dct:contributor, dct:creator and dct:publisher [[!DC11]], and the generic prov:wasAttributedTo from [[!PROV-O]], support basic associations of responsible agents with a catalogued resource. However, there are many other roles of importance in relation to datasets and services - e.g. funder, distributor, custodian, editor. Some of these roles are enumerated in the CI_RoleCode values from [[?ISO-19115-1]], in the [[?DataCite]] metadata schema, and included within the MARC relators.

A general method for assigning an agent to a resource with a specified role is provided by using the qualified form prov:qualifiedAttribution from [[!PROV-O]]. The following provides an illustration:

ex:DS987
  a dcat:Dataset ;
  prov:qualifiedAttribution [
    a prov:Attribution ;
    prov:agent <https://www.ala.org.au/> ;
    dcat:hadRole <http://registry.it.csiro.au/def/isotc211/CI_RoleCode/distributor>
  ] ;
  prov:qualifiedAttribution [
    a prov:Attribution ;
    prov:agent <https://www.education.gov.au/> ;
    dcat:hadRole <http://registry.it.csiro.au/def/isotc211/CI_RoleCode/funder>
  ] ;
.

In this example the roles are taken from [[?ISO-19115-1]] which are available as linked data in a code list.

Relationships between datasets and other resources

The standard Dublin Core properties dct:relation and sub-properties such as dct:hasPart/dct:isPartOf, dct:hasVersion/dct:isVersionOf, dct:replaces/dct:isReplacedBy, dct:requires/dct:isRequiredBy, prov:wasDerivedFrom, prov:wasQuotedFrom, support the description of relationships between datasets and other catalogued resources. However, there are many other relationships of importance - e.g. alternate, canonical, original, preview, stereo-mate, working-copy-of. Some of these roles are enumerated in the DS_AssociationTypeCode values from [[?ISO-19115-1]], the IANA Registry of Link Relations, in the [[?DataCite]] metadata schema, and included within the MARC relators.

A general method for relating a resource to another resource with a specified role is provided by using the qualified form dcat:qualifiedRelation. The following provides illustrations:

ex:Test987
  a dcat:Dataset ;
  dcat:qualifiedRelation [
    a dcat:Relationship ;
    dct:relation <http://example.org/Original987> ;
    dcat:hadRole <http://www.iana.org/assignments/relation/original>
  ] ;
.

ex:Test543L
  a dcat:Dataset ;
  dcat:qualifiedRelation [
    a dcat:Relationship ;
    dct:relation <http://example.org/Test543R> ;
    dcat:hadRole <http://registry.it.csiro.au/def/isotc211/DS_AssociationTypeCode/stereoMate>
  ] ;
.

The property dcat:qualifiedRelation and association-class dcat:Relationship follow the pattern established in W3C [[!PROV-O]] and described in the section Qualified Terms. However, PROV-O is activity-centric, and does not support Entity-Entity relations except for the single case of 'was derived from', thus necessitating the new elements shown here to support the general case.

Provenance patterns

In this chapter it is planned to describe patterns for the use of the [[!PROV-O]] vocabulary to support the various provenance-related requirements. A number of requirements identify the need to provide better support for Dataset and Record provenance - see Issue #78, Issue #128, Issue #77, Issue #76, Issue #71, Issue #66, Issue #63.

Many of the requirements can be satisfied by using capabilities from the [[?PROV-O]] ontology, in particular by treating dcat:Resource and/or dcat:CatalogRecord a sub-class of prov:Entity. See Issue #128 for the relevant discussion. A preliminary alignment of DCAT with PROV-O is available. See the wiki page on Provenance Patterns for more discussion.

License and rights statements

DCAT 2014 handling of license and rights do not appear to satisfy all requirements [[?VOCAB-DCAT-20140116]]. The recently completed W3C ODRL vocabulary [[!ODRL-VOCAB]] provides a rich language for describing many kinds of rights and obligations. In this chapter, we describe some patterns for linking DCAT Datasets and/or Distributions to suitable license and rights expressions.

Selecting the right way to express conditions for access to and re-use of resources can be complex. Implementers should always seek legal advice before deciding which conditions apply to the resource being described.

This specification distinguishes three main situations: one where a statement is associated with a resource that is explicitly declared as a 'license'; a second, where the statement is associated with a resource denoting only access rights; a third, covering all the other cases - i.e., statements not concerning licensing conditions and/or access rights (e.g., copyright statements).

The provision of licensing conditions and access rights complies with the Best Practices 4 ("Provide data license information") and 22. ("Provide an explanation for data that is not available"), respectively, from [[DWBP]].

To address these scenarios, it is recommended to use the property dct:rights, and its sub-properties dct:license and dct:accessRights. More precisely:

  1. use dct:license to refer to licenses;

    For interoperability, it is recommended to use canonical URIs of well-known licenses such as those defined by Creative Commons.

  2. use dct:accessRights to express statements concerning only access rights (e.g., whether data can be accessed by anyone or just by authorized parties);

    Access rights can also be expressed as code lists / taxonomies. Examples include the access rights code list [[?MDR-AR]] used in [[?DCAT-AP]] and the Eprints Access Rights Vocabulary Encoding Scheme.

  3. use dct:rights for all the other types of rights statements - those which are not covered by dct:license and dct:accessRights, such as copyright statements.

    A more sophisticated approach to express rights, based on and extending [[?DCTERMS]], is provided by the Open Data Rights Statement Vocabulary (ODRS) [[?ODRS]], which defines properties for specifying, among others, copyright statements and copyright notices.

Finally, in the particular case when rights are expressed via ODRL policies, it is recommended to use use the odrl:hasPolicy property as the link from the description of the catalogued resource or distribution to the ODRL policy, in addition to the relevant dct property.

The Open Digital Rights Language (ODRL) [[!ODRL-VOCAB]] is a policy expression language that provides a flexible and interoperable information model, vocabulary, and encoding mechanisms for representing statements about usage (i.e. permissions, prohibitions, and obligations) of content and services.

Recommendations on the use of these properties on the different types of resources defined in DCAT are provided in the relevant class descriptions.

Dataset versions

The need to be able to describe version relationships of datasets has been identified as a requirement to be satisfied in the revision of DCAT. Also see detailed requirements in Issue #89, Issue #91, Issue #92, Issue #93,

In this chapter it is planned to describe some patterns for describing Dataset and/or Distribution versions. See the wiki page on Dataset versioning for more discussion.

Data citation

Dataset citation is one of the requirements identified for this DCAT revision. Data citation is the practice of referencing data in a similar way as when providing bibliographic references, acknowledging data as a first class output in any investigative process. Data citation offers multiple benefits, such as supporting proper attribution and credit to those producing the data, facilitating data discovery, supporting tracking the impact and reuse of data, allowing for collaboration and re-use of data, and enabling the reproducibility of results based on the data.

To support data citation, the dataset description should include at a minimum: the dataset identifier, the dataset creator(s), the dataset title, the dataset publisher and the dataset publication or release date. These elements are those required by the DataCite metadata schema [[?DataCite]], which is the metadata associated by the persistent identifiers (Digital Object Identifiers or DOIs) assigned by [[?DataCite]] to research data.

In order to support data citation, this DCAT revision has added the consideration of dereferenceable identifiers and support for indicating the creators of the catalogued resources. The remaining properties necessary for data citation were already available in DCAT 2014 [[?VOCAB-DCAT-20140116]].

The constraints on the availability of properties required for data citation in the dataset description can be represented as a DCAT data citation profile.

Alignment with other general purpose metadata vocabularies

See the wiki page on Alignments and Crosswalks for more discussion.

Schema.org

Schema.org [[?SCHEMA-ORG]] includes a number of types and properties based on the original DCAT work (see schema:Dataset as a starting point), and the index for Google's Dataset Search service relies on structured description in web pages about datasets based on both schema.org and DCAT. A comparison of the DCAT backbone, shown in above with the related classes from [[?SCHEMA-ORG]] in shows the similarity:

UML model of schema.org classes and properties related to dataset catalogs
schema.org support for dataset catalogs, showing a selection of schema.org properties that have the classes shown within their domain and range

General purpose web search services that use metadata at all rely primarily on [[?SCHEMA-ORG]], so the relationship of DCAT to [[?SCHEMA-ORG]] is of interest for data providers who wish their datasets and services to be exposed through those indexes.

A mapping between DCAT 2014 and schema.org was discussed on the original proposal to extend [[?SCHEMA-ORG]] for describing datasets and data catalogs. Partial mappings between DCAT 2014 [[?VOCAB-DCAT-20140116]] and [[?SCHEMA-ORG]] were provided earlier by the Spatial Data on the Web Working Group, building upon previous work.

A recommended mapping from the revised DCAT (this document) to [[?SCHEMA-ORG]] is available in an RDF file. This mapping is axiomatized using the predicates rdfs:subClassOf, rdfs:subPropertyOf, owl:equivalentClass, owl:equivalentProperty, skos:closeMatch, and also using the annotation properties schema:domainIncludes and schema:rangeIncludes to match [[?SCHEMA-ORG]] semantics. The mapping is summarized in the table below, considering the prefix schema as http://schema.org/.

This alignment of DCAT with schema.org is provisional and non-normative. Feedback is invited in the issue tracker.

DCAT element mapping property target element from schema.org
dct:description owl:equivalentProperty schema:description
dct:format [ owl:inverseOf rdfs:subPropertyOf ] schema:encodingFormat
dct:identifier owl:equivalentProperty schema:identifier
dct:issued skos:closeMatch schema:datePublished
dct:language owl:equivalentProperty schema:inLanguage
dct:license owl:equivalentProperty schema:license
dct:modified owl:equivalentProperty schema:dateModified
dct:publisher owl:equivalentProperty schema:publisher
dct:spatial owl:equivalentProperty schema:spatialCoverage
dct:temporal owl:equivalentProperty schema:temporalCoverage
dct:title owl:equivalentProperty schema:name
dct:type skos:closeMatch schema:additionalType
dcat:Catalog owl:equivalentClass schema:DataCatalog
dcat:DataService skos:closeMatch schema:DataFeed
Unclear if a schema:DataFeed is a data service, or a data collection.
dcat:Dataset owl:equivalentClass schema:Dataset
dcat:Distribution owl:equivalentClass schema:DataDownload
dcat:Resource rdfs:subClassOf schema:Thing
dcat:accessURL rdfs:subPropertyOf schema:contentUrl
schema:domainIncludes dcat:Distribution , schema:DataDownload
schema:rangeIncludes rdfs:Resource , schema:URL
dcat:byteSize rdfs:subPropertyOf schema:contentSize
schema:domainIncludes dcat:Distribution , schema:DataDownload
schema:rangeIncludes rdfs:Literal , schema:Text
dcat:catalog schema:domainIncludes dcat:Catalog , schema:DataCatalog
schema:rangeIncludes dcat:Catalog , schema:DataCatalog
dcat:contactPoint owl:equivalentProperty schema:contactPoint
schema:domainIncludes dcat:Resource , dcat:Dataset , dcat:DataService , schema:Dataset
dcat:dataset owl:equivalentProperty schema:dataset
schema:domainIncludes dcat:Catalog , schema:DataCatalog
schema:rangeIncludes dcat:Dataset , schema:Dataset
dcat:distribution owl:equivalentProperty schema:distribution
schema:domainIncludes dcat:Dataset , schema:Dataset
schema:rangeIncludes dcat:Distribution , schema:DataDownload
dcat:downloadURL rdfs:subPropertyOf schema:contentUrl
schema:domainIncludes dcat:Distribution , schema:DataDownload
schema:rangeIncludes rdfs:Resource , schema:Thing
dcat:keyword rdfs:subPropertyOf schema:keywords
dcat:keyword is singular, schema:keywords is plural
schema:domainIncludes dcat:Resource , dcat:Dataset , dcat:DataService , schema:Dataset
schema:rangeIncludes rdfs:Literal , schema:Text
dcat:landingPage rdfs:subPropertyOf schema:url
schema:domainIncludes dcat:Resource , dcat:Dataset , dcat:DataService , schema:Dataset
schema:rangeIncludes foaf:Document , schema:WebPage
dcat:mediaType owl:equivalentProperty schema:encodingFormat
schema:domainIncludes dcat:Distribution , schema:DataDownload
schema:rangeIncludes dct:MediaTypeOrExtent , schema:Text , schema:url
dcat:record schema:domainIncludes dcat:Catalog , schema:DataCatalog
schema:rangeIncludes dcat:CatalogRecord
dcat:service schema:domainIncludes dcat:Catalog , schema:DataCatalog
schema:rangeIncludes dcat:DataService
dcat:theme owl:equivalentProperty schema:about
schema:domainIncludes dcat:Resource , dcat:Dataset , dcat:DataService , schema:Dataset
schema:rangeIncludes skos:Concept , schema:Class
dcat:themeTaxonomy schema:domainIncludes dcat:Catalog , schema:DataCatalog
schema:rangeIncludes skos:ConceptScheme
foaf:Organization owl:equivalentClass schema:Organization
foaf:Person owl:equivalentClass schema:Person
foaf:homepage owl:equivalentProperty schema:url
foaf:mbox owl:equivalentProperty schema:email

PROV-O

An alignment of DCAT with PROV-O [[?PROV-O]] is being prepared, and has been discussed in Issue #128. A provisional version is available.

DCAT Profiles

The DCAT-2014 vocabulary [[?VOCAB-DCAT-20140116]] has been extended for application in data catalogues in different domains. Each of these new specifications constitutes a DCAT profile, i.e. a named set of constraints based on DCAT. In some cases, an application profile extends one of the DCAT extensions themselves.

Some of the DCAT application profiles are:

Security and Privacy

This section will describe security and privacy considerations relevant to the DCAT revision.

Relation to other W3C Recommendations

DCAT should be aligned with other recent Linked Data based Recommendations.

Linked Data Platform (LDP)

DCAT provides a data model for representation of metadata about datasets in the form of Linked Data, but it does not specify how this metadata can be accessed or modified. The DCAT compatible metadata can be viewed as collections of Catalog Records, Datasets and Data Services contained in a Catalog, and a collection of Distributions contained in a Dataset. The Linked Data Platform [[!LDP]] specification deals with access to and modification of Linked Data Platform Containers (LDPCs). This section provides guidance on how to represent DCAT metadata as LDP Containers, which supports namely the implementation of Solid based DCAT catalogs.

First, we will present an example of a LDPC for datasets in a catalog. There is one catalog with one dataset. The dataset is contained in the </datasets/> LDP Direct Container. To ensure the LDPC discovery, we connect it to the Catalog using the dcat:datasets predicate.

@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix ldp:  <http://www.w3.org/ns/ldp#> .

@base <https://example.org/resource/catalog> .

<> a dcat:Catalog ;
	dcat:datasets </datasets/> ;
	dcat:dataset </datasets/001> .

</datasets/> a ldp:Container, ldp:DirectContainer ;
	ldp:membershipResource <> ;
	ldp:hasMemberRelation dcat:dataset ;
	ldp:contains </datasets/001> .

</datasets/001> a dcat:Dataset .

In the second example, we add LDPCs </records/> for Catalog Records and </services/> for Data Services, discoverable using dcat:records and dcat:services predicates from the Catalog:

@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix ldp:  <http://www.w3.org/ns/ldp#> .

@base <https://example.org/resource/catalog> .

<> a dcat:Catalog ;
	dcat:records </records/> ;
	dcat:datasets </datasets/> ;
	dcat:services </services/> ;
	dcat:dataset </datasets/001> .

</records/> a ldp:Container, ldp:DirectContainer ;
	ldp:membershipResource <> ;
	ldp:hasMemberRelation dcat:record ;
	ldp:contains </records/001> .

</datasets/> a ldp:Container, ldp:DirectContainer ;
	ldp:membershipResource <> ;
	ldp:hasMemberRelation dcat:dataset ;
	ldp:contains </datasets/001> .

</services/> a ldp:Container, ldp:DirectContainer ;
	ldp:membershipResource <> ;
	ldp:hasMemberRelation dcat:service ;
	ldp:contains </services/001> .

</records/001> a dcat:CatalogRecord ;
	foaf:primaryTopic </datasets/001> .

</datasets/001> a dcat:Dataset ;

</services/001> a dcat:DataService .

Each dataset has its own LDPC for its distributions. In the third example, we show the LDPC </datasets/001/distributions/> for distributions of a single dataset, </datasets/001>, discoverable through the dcat:distributions predicate.

@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix ldp:  <http://www.w3.org/ns/ldp#> .

@base <https://example.org/resource/catalog> .

</datasets/001> a dcat:Dataset ;
	dcat:distributions </datasets/001/distributions/> ;
	dcat:distribution </datasets/001/distributions/001> .

</datasets/001/distributions/> a ldp:Container, ldp:DirectContainer ;
	ldp:membershipResource </datasets/001> ;
	ldp:hasMemberRelation dcat:distribution ;
	ldp:contains </datasets/001/distributions/001> .

</datasets/001/distributions/001> a dcat:Distribution .

For catalogs with many datasets, catalog records, data services or distributions, the Linked Data Platform Paging mechanism [[?LDP-Paging]] SHOULD be used to provide access to them.

In the next sections we formally define the additional properties used for discovery of LDP containers.

Property: datasets

RDF Property:dcat:datasets
Definition:Connects a catalog to the LDP container of its datasets.
Domain:dcat:Catalog
Range:ldp:DirectContainer

Property: catalog records

RDF Property:dcat:records
Definition:Connects a catalog to the LDP container of its catalog records.
Domain:dcat:Catalog
Range:ldp:DirectContainer

Property: data services

RDF Property:dcat:services
Definition:Connects a catalog to the LDP container of its data services.
Domain:dcat:Catalog
Range:ldp:DirectContainer

Property: distributions

RDF Property:dcat:distributions
Definition:Connects a dataset to the LDP container of its distributions.
Domain:dcat:Dataset
Range:ldp:DirectContainer

Linked Data Notifications (LDN)

Linked Data Notifications (LDN) [[!LDN]] can be used with DCAT e.g. for feedback collection. Any resource can have an LDN Inbox. In the following example we show a dataset </datasets/001> as an LDN Target with an LDN Inbox.

@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix ldp:  <http://www.w3.org/ns/ldp#> .

@base <https://example.org/resource/catalog> .

</datasets/001> a dcat:Dataset ;
	ldp:inbox </datasets/001/inbox/> .

</datasets/001/inbox/> ldp:contains </datasets/001/inbox/001> .

Alignment with external metadata vocabularies

This annex lists some (planned) alignments between DCAT and some metadata vocabularies that are oriented towards particular applications and domains.

DATS

An alignment of DCAT with DATS [[?DATS]] is being considered.

HCLS

An alignment of DCAT with HCLS [[?HCLS-Dataset]] is being prepared.

ISO 19115

An alignment of DCAT with ISO 19115 [[?ISO-19115-1]] is being prepared.

Datacite

An alignment of DCAT with Datacite metadata schema [[?DataCite]] is being prepared.

DDI

An alignment of DCAT with DDI [[?DDI]] is being prepared.

All currently open issues are available at: https://github.com/w3c/dxwg/labels/dcat

Acknowledgments

The editors gratefully acknowledge the contributions made to this document by all members of the working group.

The editors also gratefully acknowledge the chairs of this Working Group: Karen Coyle, Caroline Burle and Peter Winstanley — and staff contacts Phil Archer and Dave Raggett.

Examples

Loosely structured catalog

The background to this example is discussed in Best practice for a loosely-structured catalog

In many legacy catalogues and repositories (e.g. CKAN), ‘datasets’ are ‘just a bag of files’. There is no distinction made between part/whole, distribution (representation), and other kinds of relationship (e.g. documentation, schema, supporting documents) from the dataset to each of the files.

If the nature of the relationships between a dataset and component resources in a catalogue, repository, or elsewhere are not known, dct:relation can be used:

:d33937
  dct:description "A set of RDF graphs representing the International [Chrono]stratigraphic Chart, ..." ;
  dct:identifier "https://doi.org/10.25919/5b4d2b83cbf2d"^^xsd:anyURI ;
  dct:creator <https://orcid.org/0000-0002-3884-3420>;
  dct:relation <https://vocabs.ands.org.au/viewById/196> ;
  dct:relation :ChronostratChart2017-02.pdf  ;
  dct:relation :ChronostratChart2017-02.jpg ;
  dct:relation :timescale.zip ;
  dct:relation :isc2017.jsonld ;
  dct:relation :isc2017.nt ;
  dct:relation :isc2017.rdf ;
  dct:relation :isc2017.ttl ;
.

If it is clear that any of these related resources is a proper representation of the dataset, dcat:distribution should be used.

:d33937
  rdf:type dcat:Dataset ;
  dct:description "A set of RDF graphs representing the International [Chrono]stratigraphic Chart, ..." ;
  dct:identifier "https://doi.org/10.25919/5b4d2b83cbf2d"^^xsd:anyURI ;
  dct:relation <https://vocabs.ands.org.au/viewById/196> ;
  dct:relation :ChronostratChart2017-02.pdf  ;
  dct:relation :ChronostratChart2017-02.jpg ;
  dct:relation :timescale.zip ;
  dcat:distribution :d33937-jsonld ;
  dcat:distribution :d33937-nt ;
  dcat:distribution :d33937-rdf ;
  dcat:distribution :d33937-ttl ;
.
:d33937-jsonld  rdf:type dcat:Distribution ;
  dcat:downloadURL :isc2017.jsonld ;
  dcat:byteSize "698039"^^xsd:decimal ;
  dcat:mediaType <https://www.iana.org/assignments/media-types/application/ld+json> ;
.
:d33937-nt  rdf:type dcat:Distribution ;
  dcat:downloadURL :isc2017.nt ;
  dcat:byteSize "2047874"^^xsd:decimal ;
  dcat:mediaType <https://www.iana.org/assignments/media-types/application/n-triples> ;
.
:d33937-rdf  rdf:type dcat:Distribution ;
  dcat:downloadURL :isc2017.rdf ;
  dcat:byteSize "1600569"^^xsd:decimal ;
  dcat:mediaType <https://www.iana.org/assignments/media-types/application/rdf+xml> ;
.
:d33937-ttl  rdf:type dcat:Distribution ;
  dcat:downloadURL :isc2017.ttl ;
  dcat:byteSize "531703"^^xsd:decimal ;
  dcat:mediaType <https://www.iana.org/assignments/media-types/text/turtle> ;
.

This example is available from the DXWG code repository at csiro-dap-examples.ttl

Additional detail about the nature of the related resources can be given using suitable elements from other RDF vocabularies, along with dataset descriptors from DCAT. For example, the example above might be more fully expressed as follows (embedded comments explain the different resources in the graph):

dap:d33937
  rdf:type dcat:Dataset ;
  rdfs:comment "The data" ;
  dct:conformsTo <http://resource.geosciml.org/ontology/timescale/gts> ;
  dct:description "A set of RDF graphs representing the International [Chrono]stratigraphic Chart [...]" ;
  dct:identifier "https://doi.org/10.25919/5b4d2b83cbf2d" ;
  dct:issued "2018-07-07"^^xsd:date ;
  dct:license <https://creativecommons.org/licenses/by/4.0/> ;
  dct:publisher <http://www.csiro.au> ;
  dct:relation <http://stratigraphy.org/ICSchart/ChronostratChart2017-02.jpg> ;
  dct:relation <http://stratigraphy.org/ICSchart/ChronostratChart2017-02.pdf> ;
  dct:relation [
      rdf:type dcat:Dataset ;
      dct:conformsTo <https://www.w3.org/TR/owl2-overview/> ;
      rdfs:comment "The ontology used for the data" ;
      dct:description "This is an RDF/OWL representation of the GeoSciML Geologic Timescale model ..." ;
      dct:issued "2011-01-01"^^xsd:date ;
      dct:modified "2017-04-28"^^xsd:date ;
      dct:title "Geologic Timescale model" ;
      dct:type <http://purl.org/adms/assettype/DomainModel> ;
      dcat:distribution [
          rdf:type dcat:Distribution ;
          rdfs:comment "RDF/XML representation of the ontology used for the data" ;
          dcat:downloadURL <http://resource.geosciml.org/ontology/timescale/gts.rdf> ;
          dcat:mediaType <https://www.iana.org/assignments/media-types/application/rdf+xml> ;
        ] ;
      dcat:distribution [
          rdf:type dcat:Distribution ;
          rdfs:comment "TTL representation of the ontology used for the data" ;
          dcat:downloadURL <http://resource.geosciml.org/ontology/timescale/gts.ttl> ;
          dcat:mediaType <https://www.iana.org/assignments/media-types/text/turtle> ;
        ] ;
      dcat:distribution [
          rdf:type dcat:Distribution ;
          rdfs:comment "Webpage describing the ontology used for the data" ;
          dcat:downloadURL <http://resource.geosciml.org/ontology/timescale/gts.html> ;
          dcat:mediaType <https://www.iana.org/assignments/media-types/text/html> ;
        ] ;
      dcat:landingPage <http://resource.geosciml.org/ontology/timescale/gts> ;
    ] ;
  dcat:distribution [
      rdf:type dcat:Distribution ;
      dct:conformsTo <https://www.w3.org/TR/rdf-schema/> ;
      rdfs:comment "RDF representation of the data" ;
      dcat:accessService [
          rdf:type dcat:DataDistributionService ;
          dct:conformsTo <https://www.w3.org/TR/sparql11-query/> ;
          dct:title "International Chronostratigraphic Chart hosted at Research Vocabularies Australia" ;
          rdfs:comment "Service that supports queries to obtain RDF representations of subsets of the data" ;
          dcat:endpointURL <http://vocabs.ands.org.au/repository/api/sparql/csiro_international-chronostratigraphic-chart_2017> ;
          dcat:landingPage <https://vocabs.ands.org.au/viewById/196> ;
        ] ;
    ] ;
  dcat:distribution [
      rdf:type dcat:Distribution ;
      dct:identifier "isc2017.jsonld" ;
      rdfs:comment "JSON-LD serialization of the RDF representation of the entire dataset" ;
      dcat:mediaType <https://www.iana.org/assignments/media-types/application/ld+json> ;
    ] ;
  dcat:distribution [
      rdf:type dcat:Distribution ;
      dct:identifier "isc2017.nt" ;
      rdfs:comment "N-Triples serialization of the RDF representation of the entire dataset" ;
      dcat:mediaType <https://www.iana.org/assignments/media-types/application/n-triples> ;
    ] ;
  dcat:distribution [
      rdf:type dcat:Distribution ;
      dct:identifier "isc2017.rdf" ;
      rdfs:comment "RDF/XML serialization of the RDF representation of the entire dataset" ;
      dcat:mediaType <https://www.iana.org/assignments/media-types/application/rdf+xml> ;
    ] ;
  dcat:distribution [
      rdf:type dcat:Distribution ;
      dct:identifier "isc2017.ttl" ;
      rdfs:comment "TTL serialization of the RDF representation of the entire dataset" ;
      dcat:mediaType <https://www.iana.org/assignments/media-types/text/turtle> ;
    ] ;
  dcat:landingPage <https://data.csiro.au/dap/landingpage?pid=csiro:33937> ;
.

<http://stratigraphy.org/ICSchart/ChronostratChart2017-02.jpg>
    rdf:type foaf:Document ;
    dct:type <http://purl.org/dc/dcmitype/Image> ;
    dct:format  <https://www.iana.org/assignments/media-types/img/jpeg> ;
    dct:description "Coloured image representation of the International Chronostratigraphic Chart" ;
    dct:issued "2017-02-01"^^xsd:date ;
    dct:title "International Chronostratigraphic Chart" ;
.
<http://stratigraphy.org/ICSchart/ChronostratChart2017-02.pdf>
    rdf:type foaf:Document ;
    dct:type <http://purl.org/dc/dcmitype/Image> ;
    dct:format <https://www.iana.org/assignments/media-types/application/pdf> ;
    dct:description "Coloured image representation of the International Chronostratigraphic Chart" ;
    dct:issued "2017-02-01"^^xsd:date ;
    dct:title "International Chronostratigraphic Chart" ;
.
      

This example is available from the DXWG code repository at csiro-stratchart.ttl

Dataset provenance

The provenance or business context of a dataset can be described using elements from the W3C Provenance Ontology [[?PROV-O]].

For example, a simple link from a dataset description to the project that generated the dataset can be formalized as follows (other details elided for clarity):

dap:atnf-P366-2003SEPT
rdf:type dcat:Dataset ;
dct:bibliographicCitation "Burgay, M; McLaughlin, M; Kramer, M; Lyne, A; Joshi, B; Pearce, G; D'Amico, N; Possenti, A; Manchester, R; Camilo, F (2017): Parkes observations for project P366 semester 2003SEPT. v1. CSIRO. Data Collection. https://doi.org/10.4225/08/598dc08d07bb7" ;
dct:title "Parkes observations for project P366 semester 2003SEPT" ;
dcat:landingPage <https://data.csiro.au/dap/landingpage?pid=csiro:P366-2003SEPT> ;
prov:wasGeneratedBy dap:P366 ;
.

dap:P366
rdf:type prov:Activity ;
dct:type "Observation" ;
prov:startedAtTime "2000-11-01"^^xsd:date ;
prov:used dap:Parkes-radio-telescope ;
prov:wasInformedBy dap:ATNF ;
rdfs:label "P366 - Parkes multibeam high-latitude pulsar survey" ;
rdfs:seeAlso <https://doi.org/10.1111/j.1365-2966.2006.10100.x> ;
.

This example is available from the DXWG code repository at csiro-dap-examples.ttl

Several properties capture provenance information, including within the citation and title, but the primary link to a formal description of the project is through prov:wasGeneratedBy. A terse description of the project is shown as a prov:Activity, though this would not necessarily be part of the same catalog. Note that as the project is ongoing, the activity has no end date.

Further provenance information might be provided using the other starting point properties from PROV, in particular prov:wasAttributedTo (to link to an agent associated with the dataset production) and prov:wasDerivedFrom (to link to a predecessor dataset). Both of these complement Dublin Core properties already used in DCAT, as follows:

For a more detailed discussion of the use of PROV for dataset provenance, including recommendations on the use of qualified properties, see the chapter on Provenance Patterns below.

Data services

Data services may be described using DCAT. The values of the classifiers dct:type, dct:conformsTo, and dcat:endpointDescription provide progressively more detail about a service, whose actual endpoint is given by the dcat:endpointURL.

The first example describes a data catalog hosted by the European Environment Agency (EEA). This is classified as a dcat:DataService and has the dct:type set to discovery from the INSPIRE classification of spatial data service types.

This example is available from the DXWG code repository at eea-csw.ttl

a:EEA-CSW-Endpoint
rdf:type dcat:DataService ;
dc:subject "infoCatalogueService"@en ;
dct:accessRights <http://publications.europa.eu/resource/authority/access-right/PUBLIC> ;
dct:conformsTo <http://www.opengis.net/def/serviceType/ogc/csw> ;
dct:description "The EEA public catalogue of spatial datasets references the spatial datasets used by the European Environment Agency as well as the spatial datasets produced by or for the EEA. In the latter case, when datasets are publicly available, a link to the location from where they can be downloaded is included in the dataset's metadata. The catalogue has been initially populated with the most important spatial datasets already available on the data&maps section of the EEA website and is currently updated with any newly published spatial dataset."@en ;
dct:identifier "eea-sdi-public-catalogue" ;
dct:issued "2012-01-01"^^xsd:date ;
dct:license <https://creativecommons.org/licenses/by/2.5/dk/> ;
dct:spatial [
    rdf:type dct:Location ;
    locn:geometry "<gml:Envelope srsName=\"http://www.opengis.net/def/crs/OGC/1.3/CRS84\"><gml:lowerCorner>-180 -90</gml:lowerCorner><gml:upperCorner>180 90</gml:upperCorner></gml:Envelope>"^^gsp:gmlLiteral ;
    locn:geometry "POLYGON((-180 90,180 90,180 -90,-180 -90,-180 90))"^^gsp:wktLiteral ;
  ] ;
dct:title "European Environment Agency's public catalogue of spatial datasets."@en ;
dct:type <http://inspire.ec.europa.eu/metadata-codelist/ResourceType/service> ;
dct:type <http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/discovery> ;
dcat:contactPoint a:EEA ;
dcat:endpointDescription <https://sdi.eea.europa.eu/catalogue/srv/eng/csw?service=CSW&request=GetCapabilities> ;
dcat:endpointURL <http://sdi.eea.europa.eu/catalogue/srv/eng/csw> ;
.

The next example shows a dataset hosted by Geoscience Australia, which is available from three distinct services, as indicated by the value of the dcat:servesDataset property of each of the service descriptions. These are classified as a dcat:DataDistributionService and also have the dct:type set to download and view from the INSPIRE classification of spatial data service types.

This example is available from the DXWG code repository at ga-courts.ttl

ga-courts:jc
rdf:type dcat:Dataset ;
dct:description "The dataset contains spatial locations, in point format, of the Australian High Court, Australian Federal Courts and the Australian Magistrates Courts." ;
dct:spatial [
    rdf:type dct:Location ;
    locn:geometry "<gml:Envelope srsName=\"http://www.opengis.net/def/crs/EPSG/0/4283\"><gml:lowerCorner>115.864566 -42.885989</gml:lowerCorner><gml:upperCorner>153.276835 -12.460578</gml:upperCorner></gml:Envelope>"^^gsp:gmlLiteral ;
  ] ;
dct:title "Judicial Courts" ;
dct:type <http://purl.org/dc/dcmitype/Dataset> ;
dcat:landingPage <https://ecat.ga.gov.au/geonetwork/srv/eng/catalog.search#/metadata/cc365600-294a-597d-e044-00144fdd4fa6> ;
.
ga-courts:jc-esri
rdf:type dcat:DataDistributionService ;
dct:conformsTo <https://developers.arcgis.com/rest/> ;
dct:description "This web service provides access to the National Judicial Courts dataset and presents the spatial locations of all the known Australian High Courts, Australian Federal Courts and the Australian Federal Circuit Courts located within Australia, all complemented with feature attribution." ;
dct:identifier "2b8540c8-4a43-144d-e053-12a3070a3ff7" ;
dct:title "National Judicial Courts MapServer" ;
dct:type <http://purl.org/dc/dcmitype/Service> ;
dct:type <https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/download> ;
dct:type <https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/view> ;
dcat:endpointURL <http://services.ga.gov.au/gis/rest/services/Judicial_Courts/MapServer> ;
dcat:landingPage <https://ecat.ga.gov.au/geonetwork/srv/eng/catalog.search#/metadata/2b8540c8-4a43-144d-e053-12a3070a3ff7> ;
dcat:servesDataset ga-courts:jc ;
.
ga-courts:jc-wfs
rdf:type dcat:DataDistributionService ;
dct:conformsTo <http://www.opengis.net/def/serviceType/ogc/wfs/2.0.0> ;
dct:conformsTo <http://www.opengis.net/def/serviceType/ogc/wfs/1.1.0> ;
dct:conformsTo <http://www.opengis.net/def/serviceType/ogc/wfs/1.0.0> ;
dct:description "This web service provides access to the National Judicial Courts dataset and presents the spatial locations of all the known Australian High Courts, Australian Federal Courts and the Australian Federal Circuit Courts located within Australia, all complemented with feature attribution." ;
dct:identifier "2b8540c8-4a42-144d-e053-12a3070a3ff7" ;
dct:title "National Judicial Courts WFS" ;
dct:type <http://purl.org/dc/dcmitype/Service> ;
dct:type <https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/download> ;
dcat:endpointDescription <http://services.ga.gov.au/gis/services/Judicial_Courts/MapServer/WFSServer?request=GetCapabilities&service=WFS> ;
dcat:endpointURL <http://services.ga.gov.au/gis/services/Judicial_Courts/MapServer/WFSServer> ;
dcat:landingPage <https://ecat.ga.gov.au/geonetwork/srv/eng/catalog.search#/metadata/2b8540c8-4a42-144d-e053-12a3070a3ff7> ;
dcat:servesDataset ga-courts:jc ;
.
ga-courts:jc-wms
rdf:type dcat:DataDistributionService ;
dct:conformsTo <http://www.opengis.net/def/serviceType/ogc/wms/1.3> ;
dct:description "This web service provides access to the National Judicial Courts dataset and presents the spatial locations of all the known Australian High Courts, Australian Federal Courts and the Australian Federal Circuit Courts located within Australia, all complemented with feature attribution." ;
dct:identifier "2b8540c8-4a41-144d-e053-12a3070a3ff7" ;
dct:title "National Judicial Courts WMS" ;
dct:type <http://purl.org/dc/dcmitype/Service> ;
dct:type <https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/view> ;
dcat:endpointDescription <http://services.ga.gov.au/gis/services/Judicial_Courts/MapServer/WMSServer?request=GetCapabilities&service=WMS> ;
dcat:endpointURL <http://services.ga.gov.au/gis/services/Judicial_Courts/MapServer/WMSServer> ;
dcat:landingPage <https://ecat.ga.gov.au/geonetwork/srv/eng/catalog.search#/metadata/2b8540c8-4a41-144d-e053-12a3070a3ff7> ;
dcat:servesDataset ga-courts:jc ;
.

Compressed and packaged distributions

The first example is for a distribution with a downloadable file that is compressed into a GZIP file.


        @prefix dcat: <http://www.w3.org/ns/dcat#> .
        @prefix dct: <http://purl.org/dc/terms/> .

        <https://data.gov.cz/zdroj/datová-sada/247025684/22> a dcat:Distribution ;
          dcat:accessURL <https://mvcr1.opendata.cz/czechpoint/2007.csv.gz> ;
          dcat:downloadURL <https://mvcr1.opendata.cz/czechpoint/2007.csv.gz> ;
          dct:license <https://data.gov.cz/podmínky-užití/volný-přístup/> ;
          dct:conformsTo <https://mvcr1.opendata.cz/czechpoint/2007.json> ;
          dct:format <http://publications.europa.eu/resource/authority/file-type/CSV> ;
          dcat:mediaType <http://www.iana.org/assignments/media-types/text/csv> ;
          dcat:compressFormat <http://www.iana.org/assignments/media-types/application/gzip> .

        

The second example is for a distribution with several files packed into a TAR file.


          @prefix dcat: <http://www.w3.org/ns/dcat#> .
          @prefix dct: <http://purl.org/dc/terms/> .

          <https://data.gov.cz/zdroj/datová-sada/247025684/22> a dcat:Distribution ;
            dcat:accessURL <https://mvcr1.opendata.cz/czechpoint/data.tar> ;
            dcat:downloadURL <https://mvcr1.opendata.cz/czechpoint/data.tar> ;
            dct:license <https://data.gov.cz/podmínky-užití/volný-přístup/> ;
            dct:conformsTo <https://mvcr1.opendata.cz/czechpoint/2007.json> ;
            dct:format <http://publications.europa.eu/resource/authority/file-type/CSV> ;
            dcat:mediaType <http://www.iana.org/assignments/media-types/text/csv> ;
            dcat:packageFormat <http://publications.europa.eu/resource/authority/file-type/TAR> .

        

The third example is for a distribution with several files packed into a TAR file which has been compressed into a GZIP file.


          @prefix dcat: <http://www.w3.org/ns/dcat#> .
          @prefix dct: <http://purl.org/dc/terms/> .

          <https://data.gov.cz/zdroj/datová-sada/247025684/22> a dcat:Distribution ;
            dcat:accessURL <https://mvcr1.opendata.cz/czechpoint/data.tar.gz> ;
            dcat:downloadURL <https://mvcr1.opendata.cz/czechpoint/data.tar.gz> ;
            dct:conformsTo <https://mvcr1.opendata.cz/czechpoint/2007.json> ;
            dct:license <https://data.gov.cz/podmínky-užití/volný-přístup/> ;
            dct:format <http://publications.europa.eu/resource/authority/file-type/CSV> ;
            dcat:mediaType <http://www.iana.org/assignments/media-types/text/csv> ;
            dcat:packageFormat <http://publications.europa.eu/resource/authority/file-type/TAR> ;
            dcat:compressFormat <http://www.iana.org/assignments/media-types/application/gzip> .

        

These examples are available from the DXWG code repository at compress-and-package.ttl

More examples needed

This section will contain more examples on the use of DCAT.

Change history

A full change-log is available on GitHub

Changes since the W3C Recommendation of 16 January 2014

The document has undergone the following changes since the W3C Recommendation of 16 January 2014 [[?VOCAB-DCAT-20140116]]: