Data Catalog Vocabulary (DCAT)

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-1] by the Government Linked Data (GLD) Working Group.

A second recommended revision of DCAT, DCAT 2 [VOCAB-DCAT-2], was developed by the Dataset Exchange Working Group in response to a new set of Use Cases and Requirements [DCAT-UCR] gathered from peoples' experience with the DCAT vocabulary from the time of the original version, and new applications that were not considered in the first version.

This version of DCAT, DCAT 3, was developed by the Dataset Exchange Working Group, considering some of the more pressing use cases and requests among those left unaddressed in the previous standardization round. A summary of the changes from [VOCAB-DCAT-2] is provided in D. Change history.

DCAT incorporates terms from pre-existing vocabularies where stable terms with appropriate meanings could be found, such as foaf:homepage and dcterms:title. Informal summary definitions of the externally-defined terms are included in the DCAT vocabulary 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 (4. Conformance) concerns usage of only the terms in the DCAT vocabulary specification, so possible changes to other external definitions will not affect the conformance of DCAT implementations.

The Working Group invited publishers to describe their catalogs and datasets with the revised version of DCAT described in this document and to report their implementations following the instruction to reporting DCAT revised implementations. This information and subsequent analysis is published in the implementation report.

This document was published by the Dataset Exchange Working Group as a Recommendation using the Recommendation track.

W3C recommends the wide deployment of this specification as a standard for the Web.

A W3C Recommendation is a specification that, after extensive consensus-building, is endorsed by W3C and its Members, and has commitments from Working Group members to royalty-free licensing for implementations.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 03 November 2023 W3C Process Document.

The namespace for DCAT is http://www.w3.org/ns/dcat#. DCAT also 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.

Namespaces and prefixes used in normative parts of this recommendation are shown in the following table.

Prefix	Namespace IRI	Source
`adms`	`http://www.w3.org/ns/adms#`	[VOCAB-ADMS]
`dc`	`http://purl.org/dc/elements/1.1/`	[DCTERMS]
`dcat`	`http://www.w3.org/ns/dcat#`	[VOCAB-DCAT]
`dcterms`	`http://purl.org/dc/terms/`	[DCTERMS]
`dctype`	`http://purl.org/dc/dcmitype/`	[DCTERMS]
`foaf`	`http://xmlns.com/foaf/0.1/`	[FOAF]
`locn`	`http://www.w3.org/ns/locn#`	[LOCN]
`odrl`	`http://www.w3.org/ns/odrl/2/`	[ODRL-VOCAB]
`owl`	`http://www.w3.org/2002/07/owl#`	[OWL2-SYNTAX]
`prov`	`http://www.w3.org/ns/prov#`	[PROV-O]
`rdf`	`http://www.w3.org/1999/02/22-rdf-syntax-ns#`	[RDF-SYNTAX-GRAMMAR]
`rdfs`	`http://www.w3.org/2000/01/rdf-schema#`	[RDF-SCHEMA]
`skos`	`http://www.w3.org/2004/02/skos/core#`	[SKOS-REFERENCE]
`spdx`	`http://spdx.org/rdf/terms#`	[SPDX]
`time`	`http://www.w3.org/2006/time#`	[OWL-TIME]
`vcard`	`http://www.w3.org/2006/vcard/ns#`	[VCARD-RDF]
`xsd`	`http://www.w3.org/2001/XMLSchema#`	[XMLSCHEMA11-2]

This section is non-normative.

Namespaces and prefixes used in examples and guidelines in the document and not from normative parts of the recommendation are shown in the following table.

Prefix	Namespace IRI	Source
`dqv`	`http://www.w3.org/ns/dqv#`	[VOCAB-DQV]
`earl`	`http://www.w3.org/ns/earl#`	[EARL10-Schema]
`geosparql`	`http://www.opengis.net/ont/geosparql#`	[GeoSPARQL]
`oa`	`http://www.w3.org/ns/oa#`	[ANNOTATION-VOCAB]
`pav`	`http://purl.org/pav/`	[PAV]
`sdmx-attribute`	`http://purl.org/linked-data/sdmx/2009/attribute#`	[VOCAB-DATA-CUBE]
`sdo`	`https://schema.org/`	[SCHEMA-ORG]
`xhv`	`http://www.w3.org/1999/xhtml/vocab#`	[XHTML-VOCAB]

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, and SHOULD in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

A data catalog conforms to DCAT if:

Access to data is organized into datasets, distributions, data services and dataset series.
An RDF description of the catalog itself, the corresponding cataloged resources, and distributions is available (but the choice of RDF syntax, access protocol, and access policy are not mandated by this specification).
The contents of all metadata fields that are held in the catalog and that contain data about the catalog itself, the corresponding cataloged resources, and distributions are included in this RDF description and are expressed using the appropriate classes and properties from DCAT, except where no such class or property exists.
All classes and properties defined in DCAT are used in a way consistent with the semantics declared in this specification.

DCAT-compliant catalogs MAY include additional non-DCAT metadata fields and additional RDF data in the catalog's RDF description.

A DCAT profile is a specification for a data catalog 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:

Cardinality constraints, including a minimum set of required metadata fields
Sub-classes and sub-properties of the standard DCAT classes and properties
Classes and properties for additional metadata fields not covered in DCAT vocabulary specification
Controlled vocabularies or IRI sets as acceptable values for properties
Requirements for specific access mechanisms (RDF syntaxes, protocols) to the catalog's RDF description

Note

DCAT is an RDF vocabulary for representing data catalogs. DCAT is based around seven main classes (Figure 1):

dcat:Catalog represents a catalog, which is a dataset in which each individual item is a metadata record describing some resource; the scope of dcat:Catalog is collections of metadata about datasets, data services, or other resource types.
dcat:Resource represents a dataset, a data service or any other resource that may be described by a metadata record in a catalog. This class is not intended to be used directly, but is the parent class of dcat:Dataset, dcat:DataService and dcat:Catalog. Resources in a catalog should be instances of one of these classes, or of a sub-class of these, or of a sub-class of dcat:Resource defined in a DCAT profile or other DCAT application. dcat:Resource is actually an extension point for defining a catalog of any kind of resources. dcat:Dataset and dcat:DataService can be used for datasets and services which are not documented in any catalog.
dcat:Dataset represents a collection of data, published or curated by a single agent or identifiable community. The notion of dataset in DCAT is broad and inclusive, with the intention of accommodating resource types arising from all communities. Data comes in many forms including numbers, text, pixels, imagery, sound and other multi-media, and potentially other types, any of which might be collected into a dataset.
dcat:Distribution represents an accessible form of a dataset such as a downloadable file.
dcat:DataService represents a collection of operations accessible through an interface (API) that provide access to one or more datasets or data processing functions.
dcat:DatasetSeries is a dataset that represents a collection of datasets that are published separately, but share some characteristics that group them.
dcat:CatalogRecord represents a metadata record in the catalog, primarily concerning the registration information, such as who added the record and when.

UML model of DCAT classes and properties — Figure 1 Overview of DCAT model, showing the classes of resources that can be members of a Catalog, and the relationships between them. Except where specifically indicated, DCAT does not provide cardinality constraints.

Note

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 services.

A data service typically provides selection, extraction, combination, processing or transformation operations over datasets that might be hosted locally or remote to the service. The result of any request to a data service is a representation of a part or all of a dataset or catalog. A data service might be tied to specific datasets, or its source data might be configured at request- or run-time. A data distribution service allows selection and download of a distribution of a dataset or subset. A data discovery service allows a client to find a suitable dataset. Other kinds of data service include data transformation services, such as coordinate transformation services, re-sampling and interpolation services, and various data processing services, including simulation and modeling services. Note that a data service in DCAT is a collection of operations or API which provides access to data. An interactive user-interface is often available to provide convenient access to API operations, but its description is outside the scope of DCAT. The details of a particular data service endpoint will often be specified through a description conforming to a standard service type, which complement the scope of the DCAT vocabulary itself.

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 resources might also be cataloged, 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 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 profile or other DCAT application.

Note

The scope of DCAT 1 [VOCAB-DCAT-1] was limited to catalogs of datasets. A number of use cases for the revision [DCAT-UCR] involve data services as members of a catalog - see § 5.16 DCAT Distribution to describe Web services and § 5.18 Modeling service-based data access. Since DCAT 2 [VOCAB-DCAT-2], DCAT includes both datasets and data services to enable these to be part of a DCAT conformant catalog. Provision for catalogs to be composed of other catalogs is also made. 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 artifacts, 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 profile or other DCAT application.

A catalog record 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 a resource in the catalog. The use of 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.

The DCAT vocabulary is an OWL2 ontology [OWL2-OVERVIEW] formalized using [RDF-SCHEMA]. Each class and property in DCAT is denoted by an IRI [RFC3987]. 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.

Note

This example provides a quick overview of how DCAT might be used to represent a government catalog and its datasets. Titles, labels and keywords are provided both in English and Spanish to demonstrate the use of language tags.

First, the catalog description:

Example 1

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

The publisher of the catalog has the relative IRI ex:transparency-office. Further description of the publisher can be provided as in Example 2:

Example 2

ex:transparency-office
  a foaf:Organization ;
  rdfs:label "Transparency Office"@en ;
  rdfs:label "Oficina de Transparencia"@es ;
  .

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

Example 3

ex:dataset-001
  a dcat:Dataset ;
  dcterms:title "Imaginary dataset"@en ;
  dcterms:title "Conjunto de datos imaginario"@es ;
  dcat:keyword "accountability"@en, "transparency"@en, "payments"@en ;
  dcat:keyword "responsabilidad"@es, "transparencia"@es, "pagos"@es ;
  dcterms:creator ex:finance-employee-001 ;
  dcterms:issued "2011-12-05"^^xsd:date ;
  dcterms:modified "2011-12-15"^^xsd:date ;
  dcat:contactPoint <http://dcat.example.org/transparency-office/contact> ;
  dcterms:temporal [ a dcterms:PeriodOfTime ;
    dcat:startDate "2011-07-01"^^xsd:date ; 
    dcat:endDate   "2011-09-30"^^xsd:date ;
  ];
  dcat:temporalResolution "P1D"^^xsd:duration ;
  dcterms:spatial <http://sws.geonames.org/6695072/> ;
  dcat:spatialResolutionInMeters "30.0"^^xsd:decimal ;
  dcterms:publisher ex:finance-ministry ;
  dcterms:language <http://id.loc.gov/vocabulary/iso639-1/en> ;
  dcterms:accrualPeriodicity <http://purl.org/linked-data/sdmx/2009/code#freq-W>  ;
  dcat:distribution ex:dataset-001-csv ;
  .

Five distinct temporal descriptors are shown for this dataset. The dataset publication and revision dates are shown in dcterms:issued and dcterms:modified. For the frequency of update of the dataset in dcterms: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 dcterms:temporal defining a dcterms:PeriodOfTime as a closed interval indicated by dcat:startDate and dcat:endDate. 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 dcterms:spatial using an IRI 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 ex:dataset-001-csv can be downloaded as a 5kB CSV file. This is represented as an RDF resource of type dcat:Distribution.

Example 4

ex:dataset-001-csv
  a dcat:Distribution ;
  dcat:downloadURL <http://dcat.example.org/files/001.csv> ;
  dcterms:title "CSV distribution of imaginary dataset 001"@en ;
  dcterms:title "distribución en CSV del conjunto de datos imaginario 001"@es ;
  dcat:mediaType <http://www.iana.org/assignments/media-types/text/csv> ;
  dcat:byteSize "5120"^^xsd:nonNegativeInteger ;
  .

The catalog classifies its datasets according to a set of domains represented by the relative IRI ex:themes. SKOS [SKOS-REFERENCE] can be used to describe the domains used:

Example 5

ex:catalog dcat:themeTaxonomy ex:themes .

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

ex:dataset-001 dcat:theme ex:accountability .

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

Example 6

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

The type or genre of a dataset can be indicated using the dcterms:type property. It is recommended that the value of the property is taken from a well governed and broadly recognised set of resource types, such as the DCMI Type Vocabulary [DCTERMS], the MARC Genre/Terms Scheme, the [ISO-19115-1] MD_Scope codes, the DataCite resource types [DataCite], 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.

Example 7

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

ex:dataset-001
  rdf:type  dcat:Dataset ;
  dcterms:type  <http://id.loc.gov/vocabulary/marcgt/dtb> ;
  .

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

Example 8

ex:dataset-001
  rdf:type  dcat:Dataset ;
  dcterms:type  <http://purl.org/dc/dcmitype/Dataset> ;
  dcterms:type  <http://id.loc.gov/vocabulary/marcgt/dtb> ;
  dcterms:type  <urn:example:datacite/resourceType/Dataset> ;
  dcterms:type  <urn:example:re3data/contentType/database> ;
.

<urn:example:datacite/resourceType/Dataset>
  rdfs:label "Dataset"@en ;
  dcterms:source [ rdfs:label "DataCite resource types"@en ] ;
  .

<urn:example:re3data/contentType/database>
  rdfs:label "Database"@en ;
  dcterms:source [ rdfs:label "Re3data content types"@en ] ;
  .

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 ex: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 Example 9:

Example 9

ex:catalog dcat:record ex:record-001  .

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

ex:dataset-002 is available as a CSV file. However ex: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.

Example 10

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

Notice the use of a dcat:landingPage and the definition of the dcat:Distribution instance.

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

Example 11

ex:dataset-003
  a dcat:Dataset ;
  dcat:landingPage <http://dcat.example.org/dataset-003.html> ;
  dcat:distribution ex:dataset-003-csv ;
  .
ex:dataset-003-csv
  a dcat:Distribution ;
  dcat:downloadURL <http://dcat.example.org/dataset-003.csv> ;
  dcat:mediaType <http://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.

ex: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 dcterms:type (here using values from the INSPIRE spatial data service type vocabulary), its specific API definition using dcterms:conformsTo, with the detailed description of the individual endpoint parameters and options linked using dcat:endpointDescription.

Example 12

ex:dataset-004
  rdf:type dcat:Dataset ;
  dcat:distribution ex:dataset-004-csv ;
  dcat:distribution ex:dataset-004-png ;
  .

ex:dataset-004-csv
  rdf:type dcat:Distribution ;
  dcat:accessService ex:table-service-005 ;
  dcat:accessURL <http://dcat.example.org/api/table-005> ;
  dcat:mediaType <http://www.iana.org/assignments/media-types/text/csv> ;
  .

ex:dataset-004-png
  rdf:type dcat:Distribution ;
  dcat:accessService ex:figure-service-006 ;
  dcat:accessURL <http://dcat.example.org/api/figure-006> ;
  dcat:mediaType <http://www.iana.org/assignments/media-types/image/png> ;
  .

ex:figure-service-006
  rdf:type dcat:DataService ;
  dcterms:conformsTo <http://dcat.example.org/apidef/figure/v1.0> ;
  dcterms:type <https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/view> ;
  dcat:endpointDescription <http://dcat.example.org/api/figure-006/params> ;
  dcat:endpointURL <http://dcat.example.org/api/figure-006> ;
  dcat:servesDataset ex:dataset-004 ;
  .

ex:table-service-005
  rdf:type dcat:DataService ;
  dcterms:conformsTo <http://dcat.example.org/apidef/table/v2.2> ;
  dcterms:type <https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/download> ;
  dcat:endpointDescription <http://dcat.example.org/api/table-005/capability> ;
  dcat:endpointURL <http://dcat.example.org/api/table-005> ;
  dcat:servesDataset ex:dataset-003, ex:dataset-004 ;
  .

Editor's note

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

The files dcat-external.ttl, dcat-external.rdf, and dcat-external.jsonld includes externally defined terms where DCAT has provided additional documentation or usage notes.
The files dcat2.ttl, dcat2.rdf, and dcat2.jsonld that correspond to version 2 of DCAT [VOCAB-DCAT-2].
The files dcat2014.ttl and dcat2014.rdf that correspond to the 2014 version of DCAT [VOCAB-DCAT-1].

Note

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.

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.

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].

Note

The following properties are specific to this class:

The following properties of the super-class dcat:Dataset are also available for use:

The following properties of the super-class dcat:Resource are also available for use:

RDF Class:	`dcat:Catalog`
Definition:	A curated collection of metadata about resources.
Sub-class of:	`dcat:Dataset`
Usage note:	A Web-based data catalog is typically represented as a single instance of this class.
Usage note:	Datasets and data services are examples of resources in the context of a data catalog.
See also:	6.5 Class: Catalog Record, 6.6 Class: Dataset

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.

RDF Property:	`dcat:themeTaxonomy`
Definition:	A knowledge organization system (KOS) used to classify the resources documented in the catalog (e.g., datasets and services).
Domain:	`dcat:Catalog`
Range:	`rdfs:Resource`
Usage note:	It is recommended that the taxonomy is organized in a `skos:ConceptScheme`, `skos:Collection`, `owl:Ontology` or similar, which allows each member to be denoted by an IRI and published as Linked Data.

Note

RDF Property:	`dcat:resource`
Definition:	A resource that is listed in the catalog.
Sub-property of:	`dcterms:hasPart`
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 `dcat:resource` in particular `dcat:dataset`, `dcat:catalog`, `dcat:service`.

RDF Property:	`dcat:dataset`
Definition:	A dataset that is listed in the catalog.
Sub-property of:	`dcat:resource`
Domain:	`dcat:Catalog`
Range:	`dcat:Dataset`

Note

RDF Property:	`dcat:service`
Definition:	A service that is listed in the catalog.
Sub-property of:	`dcat:resource`
Domain:	`dcat:Catalog`
Range:	`dcat:DataService`

Note

RDF Property:	`dcat:catalog`
Definition:	A catalog that is listed in the catalog.
Sub-property of:	`dcat:resource`
Domain:	`dcat:Catalog`
Range:	`dcat:Catalog`

RDF Property:	`dcat:record`
Definition:	A record describing the registration of a single resource (e.g., a dataset, a data service) that is part of the catalog.
Domain:	`dcat:Catalog`
Range:	`dcat:CatalogRecord`

Note

The following properties are specific to this class:

access rights
conforms to
contact point
creator
description
has part
has policy
identifier
is referenced by
keyword/tag
landing page
license
language
relation
rights
qualified relation
publisher
release date
theme/category
title
type/genre
update/modification date
qualified attribution
has current version
has version
previous version
replaces
status
version
version notes
first
last
previous

RDF Class:	`dcat:Resource`
Definition:	Resource published or curated by a single agent.
Usage note:	The class of all cataloged resources, the super-class of `dcat:Dataset`, `dcat:DataService`, `dcat:Catalog` and any other member of a `dcat:Catalog`. This class carries properties common to all cataloged resources, including datasets and data services. The instances of this class SHOULD be included in a catalog. When describing a resource which is not a `dcat:Dataset` or `dcat:DataService`, it is recommended to create a suitable sub-class of `dcat:Resource`, or use `dcat:Resource` with the `dcterms:type` property to indicate the specific type.
Usage note:	`dcat:Resource` is an extension point that enables the definition of any kind of catalog. Additional sub-classes may be defined in a DCAT profile or other DCAT application for catalogs of other kinds of resources.
See also:	6.5 Class: Catalog Record

Note

RDF Property:	`dcterms:accessRights`
Definition:	Information about who can access the resource or an indication of its security status.
Range:	`dcterms:RightsStatement`
Usage note:	Information about licenses and rights MAY be provided for the Resource. See also guidance at 9. License and rights statements.
See also:	6.4.20 Property: rights

Note

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

For guidance on the use of this property, see 14.2.1 Conformance to a standard.

Note

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

Note

RDF Property:	`dcterms: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:	6.12 Class: Organization/Person

Note

RDF Property:	`dcterms:description`
Definition:	A free-text account of the resource.
Range:	`rdfs:Literal`

RDF Property:	`dcterms:title`
Definition:	A name given to the resource.
Range:	`rdfs:Literal`

RDF Property:	`dcterms:issued`
Definition:	Date of formal issuance (e.g., publication) of the resource.
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] (`xsd:gYear`, `xsd:gYearMonth`, `xsd:date`, or `xsd:dateTime`).
Usage note:	This property SHOULD be set using the first known date of issuance.
See also:	6.5.3 Property: listing date and 6.8.3 Property: release date

RDF Property:	`dcterms:modified`
Definition:	Most recent date on which the resource 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] (`xsd:gYear`, `xsd:gYearMonth`, `xsd:date`, or `xsd:dateTime`).
Usage note:	The value of this property indicates a change to the actual resource, not a change to the catalog record. An absent value MAY indicate that the resource has never changed after its initial publication, or that the date of last modification is not known, or that the resource is continuously updated.
See also:	6.6.2 Property: frequency, 6.5.4 Property: update/modification date and 6.8.4 Property: update/modification date

RDF Property:	`dcterms:language`
Definition:	A language of the resource. This refers to the natural language used for textual metadata (i.e., titles, descriptions, etc.) of a cataloged resource (i.e., dataset or service) or the textual values of a dataset distribution
Range:	`dcterms:LinguisticSystem` Resources defined by the Library of Congress (ISO 639-1, ISO 639-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 `dcterms:language` (i.e., the dataset will have multiple `dcterms:language` values and each distribution will have just one as the value of its `dcterms:language` property). In case of multilingual distributions, the distributions will have multiple `dcterms:language` values.

Note

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

RDF Property:	`dcterms:identifier`
Definition:	A unique identifier of the resource being described or cataloged.
Range:	`rdfs:Literal`
Usage note:	The identifier might be used as part of the IRI of the resource, but still having it represented explicitly is useful.
Usage note:	The identifier is a text string which is assigned to the resource to provide an unambiguous reference within a particular context.

Note

RDF Property:	`dcat:theme`
Type:	`owl:ObjectProperty`
Definition:	A main category of the resource. A resource can have multiple themes.
Sub-property of:	`dcterms:subject`
Usage note:	The set of themes used to categorize the resources are organized in a `skos:ConceptScheme`, `skos:Collection`, `owl:Ontology` or similar, describing all the categories and their relations in the catalog.
See also:	6.3.2 Property: themes

Note

RDF Property:	`dcterms: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: DCMI Type vocabulary [DCTERMS] [ISO-19115-1] scope codes Datacite resource types [DataCite] PARSE.Insight content-types used by re3data.org [RE3DATA-SCHEMA] (see item 15 contentType) 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-1] 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 `dcterms:format` element.

Note

RDF Property:	`dcterms:relation`
Definition:	A resource with an unspecified relationship to the cataloged resource.
Usage note:	`dcterms:relation` SHOULD be used where the nature of the relationship between a cataloged resource 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 `dcterms:relation` in particular `dcat:distribution`, `dcterms:hasPart`, (and its sub-properties `dcat:resource`, `dcat:catalog`, `dcat:dataset`, `dcat:service` ), `dcterms:isPartOf`, `dcterms:conformsTo`, `dcterms:isFormatOf`, `dcterms:hasFormat`, `dcterms:isVersionOf`, `dcterms:hasVersion` (and its sub-property `dcat:hasVersion` ), `dcterms:replaces`, `dcterms:isReplacedBy`, `dcterms:references`, `dcterms:isReferencedBy`, `dcterms:requires`, `dcterms:isRequiredBy`

Many existing and legacy catalogs do not distinguish between dataset components, representations, documentation, schemata and other resources that are lumped together as part of a dataset. dcterms:relation is a super-property of a number of more specific properties which express more precise relationships, so use of dcterms: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.

Note

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 [DCTERMS] properties (`dcterms:hasPart`, `dcterms:isPartOf`, `dcterms:conformsTo`, `dcterms:isFormatOf`, `dcterms:hasFormat`, `dcterms:isVersionOf`, `dcterms:hasVersion`, `dcterms:replaces`, `dcterms:isReplacedBy`, `dcterms:references`, `dcterms:isReferencedBy`, `dcterms:requires`, `dcterms: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 described in 15. Qualified relations .

Note

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

Note

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 5.7 Dataset available only behind some Web page)

Note

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 [DCTERMS] properties (`dcterms:creator`, `dcterms:publisher`). Use `dcat:hadRole` on the `prov:Attribution` to capture the responsibility of the Agent with respect to the Resource. See 15.1 Relationships between datasets and agents for usage examples.

This DCAT property follows the common qualified relation pattern described in 15. Qualified relations .

Note

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

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

Note

RDF Property:	`dcterms:hasPart`
Definition:	A related resource that is included either physically or logically in the described resource.

Note

RDF Property:	`odrl:hasPolicy`
Definition:	An ODRL conformant policy expressing the rights associated with the resource.
Range:	`odrl:Policy`
Usage note:	Information about rights expressed as an ODRL policy [ODRL-MODEL] using the ODRL vocabulary [ODRL-VOCAB] MAY be provided for the resource. See also guidance at 9. License and rights statements.
See also:	6.4.19 Property: license, 6.4.1 Property: access rights, 6.4.20 Property: rights

Note

RDF Property:	`dcterms:isReferencedBy`
Definition:	A related resource, such as a publication, that references, cites, or otherwise points to the cataloged resource.
Usage note:	In relation to the use case of data citation, when the cataloged resource is a dataset, the `dcterms:isReferencedBy` property allows to relate the dataset to the resources (such as scholarly publications) that cite or point to the dataset. Multiple `dcterms:isReferencedBy` properties can be used to indicate the dataset has been referenced by multiple publications, or other resources.
Usage note:	This property is used to associate a resource with the resource (of type `dcat:Resource`) in question. For other relations to resources not covered with this property, the more generic property `dcat:qualifiedRelation` can be used. See also 15. Qualified relations.

For examples on the use of this property, see C.3 Link datasets and publications.

Note

RDF Property:	`dcat:previousVersion`
Definition:	The previous version of a resource in a lineage [PAV].
Equivalent property:	`pav:previousVersion`
Sub-property of:	`prov:wasRevisionOf`
Usage note:	This property is meant to be used to specify a version chain, consisting of snapshots of a resource. The notion of version used by this property is limited to versions resulting from revisions occurring to a resource as part of its life-cycle. One of the typical cases here is representing the history of the versions of a dataset that have been released over time.
See also:	6.4.26 Property: current version, 6.4.25 Property: has version, 6.4.7 Property: release date, 6.4.27 Property: replaces, 6.4.30 Property: status, 6.4.28 Property: version, 6.4.29 Property: version notes.

For guidance on the use of this property, see 11.1.1 Version chains and hierarchies.

Note

RDF Property:	`dcat:hasVersion`
Definition:	This resource has a more specific, versioned resource [PAV].
Equivalent property:	`pav:hasVersion`
Sub-property of:	`dcterms:hasVersion`
Sub-property of:	`prov:generalizationOf`
Usage note:	This property is intended for relating a non-versioned or abstract resource to several versioned resources, e.g., snapshots [PAV]. The notion of version used by this property is limited to versions resulting from revisions occurring to a resource as part of its life-cycle. Therefore, its semantics is more specific than its super-property `dcterms:hasVersion`, which makes use of a broader notion of version, including editions and adaptations.
See also:	6.4.26 Property: current version, 6.4.24 Property: previous version, 6.4.7 Property: release date, 6.4.27 Property: replaces, 6.4.30 Property: status, 6.4.28 Property: version, 6.4.29 Property: version notes.

For guidance on the use of this property, see 11.1.1 Version chains and hierarchies.

Note

RDF Property:	`dcat:hasCurrentVersion`
Definition:	This resource has a more specific, versioned resource with equivalent content [PAV].
Equivalent property:	`pav:hasCurrentVersion`
Sub-property of:	`pav:hasVersion`
Usage note:	This property is intended for relating a non-versioned or abstract resource to a single snapshot that can be used as a permalink to indicate the current version of the content [PAV]. The notion of version used by this property is limited to versions resulting from revisions occurring to a resource as part of its life-cycle.
See also:	6.4.25 Property: has version, 6.4.24 Property: previous version, 6.4.7 Property: release date, 6.4.27 Property: replaces, 6.4.30 Property: status, 6.4.28 Property: version, 6.4.29 Property: version notes.

For guidance on the use of this property, see 11.1.1 Version chains and hierarchies.

Note

RDF Property:	`dcterms:replaces`
Definition:	A related resource that is supplanted, displaced, or superseded by the described resource [DCTERMS].
Sub-property of:	`dcterms:relation`
See also:	6.4.26 Property: current version, 6.4.25 Property: has version, 7. Use of inverse properties, 6.4.24 Property: previous version, 6.4.7 Property: release date, 6.4.30 Property: status, 6.4.28 Property: version, 6.4.29 Property: version notes.

For guidance on the use of this property, see 11.1.2 Versions replaced by other ones.

Note

RDF Property:	`dcat:version`
Definition:	The version indicator (name or identifier) of a resource.
Equivalent property:	`pav:version`
Range:	`rdfs:Literal`
Usage note:	DCAT does not prescribe how a version name / identifier should be specified, and refers for guidance to [DWBP]'s Best Practice 7: Provide a version indicator.
See also:	6.4.26 Property: current version, 6.4.25 Property: has version, 6.4.24 Property: previous version, 6.4.7 Property: release date, 6.4.27 Property: replaces, 6.4.30 Property: status, 6.4.29 Property: version notes.

For guidance on the use of this property, see 11.2 Version information.

Note

RDF Property:	`adms:versionNotes`
Definition:	A description of changes between this version and the previous version of the resource [VOCAB-ADMS].
Range:	`rdfs:Literal`
Usage note:	In case of backward compatibility issues with the previous version of the resource, a textual description of them SHOULD be specified by using this property.
See also:	6.4.26 Property: current version, 6.4.25 Property: has version, 6.4.24 Property: previous version, 6.4.7 Property: release date, 6.4.27 Property: replaces, 6.4.30 Property: status, 6.4.28 Property: version.

For guidance on the use of this property, see 11.2 Version information.

Note

RDF Property:	`adms:status`
Definition:	The status of the resource in the context of a particular workflow process [VOCAB-ADMS].
Range:	`skos:Concept`
Usage note:	DCAT does not prescribe the use of any specific set of life-cycle statuses, but refers to existing standards and community practices fit for the relevant application scenario.
See also:	6.4.26 Property: current version, 6.4.25 Property: has version, 6.4.24 Property: previous version, 6.4.7 Property: release date, 6.4.27 Property: replaces, 6.4.28 Property: version, 6.4.29 Property: version notes.

For guidance on the use of this property, see 11.3 Resource life-cycle.

Note

RDF Property:	`dcat:first`
Definition:	The first resource in an ordered collection or series of resources, to which the current resource belongs.
Sub-property of:	`xhv:first`
Usage note:	In DCAT this property is used for resources belonging to a `dcat:DatasetSeries`.
See also:	6.4.32 Property: last, 7. Use of inverse properties, 6.4.33 Property: previous.

For guidance on the use of this property, see 12. Dataset series.

Note

RDF Property:	`dcat:last`
Definition:	The last resource in an ordered collection or series of resources, to which the current resource belongs.
Sub-property of:	`xhv:last`
Usage note:	In DCAT this property is used for resources belonging to a `dcat:DatasetSeries`.
See also:	6.4.31 Property: first, 7. Use of inverse properties, 6.4.33 Property: previous.

For guidance on the use of this property, see 12. Dataset series.

Note

RDF Property:	`dcat:prev`
Definition:	The previous resource (before the current one) in an ordered collection or series of resources.
Sub-property of:	`xhv:prev`
Usage note:	In DCAT this property is used for resources belonging to a `dcat:DatasetSeries`. It is important to note that this property is different from `dcat:previousVersion`, as it does not denote a previous version of the same resource, but a distinct resource immediately preceding the current one in an ordered collection of resources.
See also:	6.4.31 Property: first, 6.4.32 Property: last, 7. Use of inverse properties.

For guidance on the use of this property, see 12. Dataset series.

The following properties are specific to this class (dcat:CatalogRecord):

conforms to
description
listing date
primary topic
title
update/modification date

RDF Class:	`dcat:CatalogRecord`
Definition:	A record in a catalog, describing the registration of a single `dcat:Resource`.
Usage note	This 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 also	6.6 Class: Dataset

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.

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

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

RDF Property:	`dcterms: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] (`xsd:gYear`, `xsd:gYearMonth`, `xsd:date`, or `xsd:dateTime`).
Usage note:	This indicates the date of listing the dataset in the catalog and not the publication date of the dataset itself.
See also:	6.4.7 Property: release date

RDF Property:	`dcterms: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] (`xsd:gYear`, `xsd:gYearMonth`, `xsd:date`, or `xsd:dateTime`).
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:	6.4.8 Property: update/modification date

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 cataloged resource.

Note

RDF Property:	`dcterms:conformsTo`
Definition:	An established standard to which the described resource conforms.
Range:	`dcterms: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.

For guidance on the use of this property, see 14.2.1 Conformance to a standard.

Note

The following properties are specific to this class:

distribution
frequency
in series
spatial/geographic coverage
spatial resolution
temporal coverage
temporal resolution
was generated by

The following properties of the super-class dcat:Resource are also available for use:

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.

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 might differ), the `dcat:CatalogRecord` class can be used for the latter.
Usage note:	The notion of dataset in DCAT is broad and inclusive, with the intention of accommodating resource types arising from all communities. Data comes in many forms including numbers, text, pixels, imagery, sound and other multi-media, and potentially other types, any of which might be collected into a dataset.

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

RDF Property:	`dcterms:accrualPeriodicity`
Definition:	The frequency at which a dataset is published.
Range:	`dcterms:Frequency` (A rate at which something recurs)
Usage note:	The value of `dcterms: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.

Examples showing how dcterms:accrualPeriodicity and dcat:temporalResolution may be combined are given in 10.1 Temporal properties.

Note

RDF Property:	`dcat:inSeries`
Definition:	A dataset series of which the dataset is part.
Range:	`dcat:DatasetSeries`
Sub-property of:	`dcterms:isPartOf`
See also:	7. Use of inverse properties

For guidance on the use of this property, see 12. Dataset series.

RDF Property:	`dcterms:spatial`
Definition:	The geographical area covered by the dataset.
Range:	`dcterms:Location` (A spatial region or named place)
Usage note:	The spatial coverage of a dataset may be encoded as an instance of `dcterms:Location`, or may be indicated using an IRI reference (link) to a resource describing a location. It is recommended that links are to entries in a well maintained gazetteer such as Geonames.

Options for expressing the details of a dcterms:Location are provided in 6.16 Class: Location.

Note

RDF Property:	`dcat:spatialResolutionInMeters`
Definition:	Minimum spatial separation resolvable in a dataset, measured in meters.
Range:	`rdfs:Literal` typed as `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 datasets, this property will usually indicate the smallest distance between items in the dataset.

The range of this property is a 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].

Note

As for the use of datatype, note that [JSON-LD] converts numbers to xsd:double or xsd:integer, and properly generating xsd:decimal requires the use of strings with an explicit or coerced datatype. In [Turtle], seemingly minor modifications can change the datatype of a value: 100.0 is an xsd:decimal, while 1e2 is an xsd:double.

Note also that number constants without a decimal part (e.g. 42) will, in [Turtle] or [JSON-LD], produce a literal with datatype xsd:integer. Since [XMLSCHEMA11-2] defines xsd:integer as a derived type of xsd:decimal, such literals are semantically valid as values of dcat:spatialResolutionInMeters. However, syntactic validation tools such as [SHACL] or [ShEx] consider them as distinct datatypes. Authors of validation schemas in these languages should therefore consider adding xsd:integer to the accepted datatypes for dcat:spatialResolutionInMeters.

RDF Property:	`dcterms:temporal`
Definition:	The temporal period that the dataset covers.
Range:	`dcterms:PeriodOfTime` (An interval of time that is named or defined by its start and end dates)
Usage note:	The temporal coverage of a dataset may be encoded as an instance of `dcterms:PeriodOfTime`, or may be indicated using an IRI reference (link) to a resource describing a time period or interval.

Options for expressing the details of a dcterms:PeriodOfTime are provided in 6.15 Class: Period of Time.

Note

RDF Property:	`dcat:temporalResolution`
Definition:	Minimum time period resolvable in the dataset.
Range:	`rdfs:Literal` typed as `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].

The distinction between dcat:temporalResolution and dcterms:accrualPeriodicity is illustrated by examples in 10.1 Temporal properties.

Note

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

Note

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.

Note

The following properties of the super-classes dcat:Resource and dcat:Dataset are also available for use:

access rights
conforms to
contact point
creator
distribution
description
has part
has policy
identifier
in series
is referenced by
keyword/tag
landing page
license
language
relation
rights
qualified relation
publisher
release date
theme/category
title
type/genre
update/modification date
qualified attribution
frequency
spatial/geographic coverage
spatial resolution
temporal coverage
temporal resolution
was generated by
has current version
has version
previous version
replaces
status
version
version notes
first
last
previous

Note

RDF Class:	`dcat:DatasetSeries`
Definition:	A collection of datasets that are published separately, but share some characteristics that group them.
Sub-class of:	`dcat:Dataset`
Usage note:	Dataset series can be also soft-typed via property `dcterms:type` as in the approach used in [GeoDCAT-AP], and adopted in [DCAT-AP-IT] and [GeoDCAT-AP-IT]).
Usage note:	Common scenarios for dataset series include: time series composed of periodically released subsets; map-series composed of items of the same type or theme but with differing spatial footprints.

For guidance on the use of this property, see 12. Dataset series.

The following properties are specific to 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:	6.9 Class: Data Service

Note

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 [RDF-SYNTAX-GRAMMAR], [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 about the data on a CSV file may not contain the same total information recorded in the CSV file, but they could be considered as two distributions for the same dataset as they are about the same data.

As a counter-example, budget data for different years would usually be modeled as different datasets, each with their own distributions, since all distributions of one dataset should broadly contain the same data.

Nevertheless, the question of whether different representations can be understood to be distributions of the same dataset, or distributions of different datasets, is application specific. Judgment about how to describe them is the responsibility of the provider, taking into account their understanding of the expectations of users, and practices in the relevant community.

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 Figure 1 and described in the definitions below.

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

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

RDF Property:	`dcterms: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] (`xsd:gYear`, `xsd:gYearMonth`, `xsd:date`, or `xsd:dateTime`).
Usage note:	This property SHOULD be set using the first known date of issuance.
See also:	6.4.7 Property: release date

RDF Property:	`dcterms: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] (`xsd:gYear`, `xsd:gYearMonth`, `xsd:date`, or `xsd:dateTime`).
See also:	6.4.8 Property: update/modification date

RDF Property:	`dcterms:license`
Definition:	A legal document under which the distribution is made available.
Range:	`dcterms: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 9. License and rights statements.
See also:	6.8.7 Property: rights 6.4.19 Property: license

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

RDF Property:	`dcterms:rights`
Definition:	Information about rights held in and over the distribution.
Range:	`dcterms:RightsStatement`
Usage note:	`dcterms:license`, which is a sub-property of `dcterms:rights`, can be used to link a distribution to a license document. However, `dcterms: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 9. License and rights statements.
See also:	6.8.5 Property: license, 6.4.20 Property: rights

Note

RDF Property:	`odrl:hasPolicy`
Definition:	An ODRL conformant policy expressing the rights associated with the distribution.
Range:	`odrl:Policy`
Usage note:	Information about rights expressed as an ODRL policy [ODRL-MODEL] using the ODRL vocabulary [ODRL-VOCAB] MAY be provided for the distribution. See also guidance at 9. License and rights statements.
See also:	6.4.19 Property: license, 6.8.6 Property: access rights, 6.8.7 Property: rights

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 URL 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 landing page URL associated with the `dcat:Dataset` SHOULD be duplicated as access URL on a distribution (see 5.7 Dataset available only behind some Web page).
See also	6.8.11 Property: download URL, 6.8.10 Property: 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.

Note

RDF Property:	`dcat:accessService`
Definition:	A data service that gives access to the distribution of the dataset
Range:	`dcat:DataService`
Usage note:	`dcat:accessService` SHOULD be used to link to a description of a `dcat:DataService` that can provide access to this distribution.
See also	6.8.11 Property: download URL, 6.8.9 Property: access URL

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 `dcterms:format` and/or `dcat:mediaType`
Domain:	`dcat:Distribution`
Range:	`rdfs:Resource`
Usage note:	`dcat:downloadURL` SHOULD be used for the URL at which this distribution is available directly, typically through a HTTP Get request.
See also	6.8.9 Property: access URL, 6.8.10 Property: access service

RDF Property:	`dcat:byteSize`
Definition:	The size of a distribution in bytes.
Domain:	`dcat:Distribution`
Range:	`rdfs:Literal` typically typed as `xsd:nonNegativeInteger`.
Usage note:	The size in bytes can be approximated (as a non-negative integer) when the precise size is not known.
Usage note:	While it is recommended that the size be given as an integer, alternative literals such as '1.5 MB' are sometimes used.

Note

RDF Property:	`dcat:spatialResolutionInMeters`
Definition:	The minimum spatial separation resolvable in a dataset distribution, measured in meters.
Range:	`xsd:decimal` or `xsd:double`
Usage note:	If the dataset is an image or grid this should correspond to the spacing of items. For other kinds of spatial datasets, 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 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].

Note

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

Note

RDF Property:	`dcterms:conformsTo`
Definition:	An established standard to which the distribution conforms.
Range:	`dcterms: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:	6.8.17 Property: format, 6.8.16 Property: media type

For guidance on the use of this property, see 14.2.1 Conformance to a standard.

Note

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

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

Note

RDF Property:	`dcat:compressFormat`
Definition:	The compression format of the distribution in which the data is contained in a compressed form, e.g., to reduce the size of the downloadable file.
Range:	`dcterms: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:	6.8.19 Property: packaging format.

For examples on the use of this property, see C.5 Compressed and packaged distributions.

Note

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

For examples on the use of this property, see C.5 Compressed and packaged distributions.

Note

RDF Property:	`spdx:checksum`
Definition:	The checksum property provides a mechanism that can be used to verify that the contents of a file or package have not changed [SPDX].
Range:	`spdx:Checksum`
Usage note:	The checksum is related to the download URL.

Note

The following properties are specific to this class: endpoint description, endpoint URL, serves dataset.

The following properties of the super-class dcat:Resource are also available for use:

RDF Class:	`dcat:DataService`
Definition:	A collection of operations that provides access to one or more datasets or data processing functions.
Sub-class of:	`dcat:Resource`
Sub-class of:	`dctype:Service`
Usage note:	If a `dcat:DataService` is bound to one or more specified Datasets, they are indicated by the `dcat:servesDataset` property.
Usage note:	The kind of service can be indicated using the `dcterms:type` property. Its value may be taken from a controlled vocabulary such as the INSPIRE spatial data service type code list [INSPIRE-SDST].

For examples on the use of this class and related properties, see C.4 Data services.

RDF Property:	`dcat:endpointURL`
Definition:	The root location or primary endpoint of the service (a Web-resolvable IRI).
Domain:	`dcat:DataService`
Range:	`rdfs:Resource`

RDF Property:	`dcat:endpointDescription`
Definition:	A description of the services available via the end-points, including their operations, parameters etc.
Domain:	`dcat:DataService`
Range:	`rdfs:Resource`
Usage note:	The endpoint description gives specific details of the actual endpoint instances, while `dcterms:conformsTo` is used to indicate the general standard or specification that the endpoints implement.
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.

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

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

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:	6.3.2 Property: themes, 6.4.12 Property: theme/category

RDF Classes:

foaf:Person (for people)

foaf:Organization (for government agencies or other entities)

Sub-class of: foaf:Agent

Usage note: [FOAF] provides several properties to describe these entities.

Note

The following properties are specific to this class: relation, had role.

Examples illustrating use of this class and its properties are given in 15. Qualified relations.

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 [DCTERMS] properties (`dcterms:hasPart`, `dcterms:isPartOf`, `dcterms:conformsTo`, `dcterms:isFormatOf`, `dcterms:hasFormat`, `dcterms:isVersionOf`, `dcterms:hasVersion`, `dcterms:replaces`, `dcterms:isReplacedBy`, `dcterms:references`, `dcterms:isReferencedBy`, `dcterms:requires`, `dcterms:isRequiredBy`) or [PROV-O] properties (`prov:wasDerivedFrom`, `prov:wasInfluencedBy`, `prov:wasQuotedFrom`, `prov:wasRevisionOf`, `prov:hadPrimarySource`, `prov:alternateOf`, `prov:specializationOf`)

RDF Property:	`dcterms: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 cataloged resource.

Note

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.

Note

Examples illustrating use of this class are given in 15. Qualified relations.

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-1] `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-1] `DS_AssociationTypeCode` IANA Registry of Link Relations [IANA-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.

Note

The following properties are specific to this class: start date, end date. beginning, end.

Examples illustrating use of these options for the temporal coverage of a dataset are given in 10.1 Temporal properties.

RDF Class:	`dcterms:PeriodOfTime`
Definition:	An interval of time that is named or defined by its start and end.
Usage note:	The start and end of the interval SHOULD be given by using properties `dcat:startDate` or `time:hasBeginning`, and `dcat:endDate` or `time:hasEnd`, respectively. The interval can also be open - i.e., it can have just a start or just an end.

Note

RDF Property:	`dcat:startDate`
Definition:	The start of the period.
Domain:	`dcterms:PeriodOfTime`
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] (`xsd:gYear`, `xsd:gYearMonth`, `xsd:date`, or `xsd:dateTime`).

Note

RDF Property:	`dcat:endDate`
Definition:	The end of the period.
Domain:	`dcterms:PeriodOfTime`
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]

Note

RDF Property:	`time:hasBeginning`
Definition:	Beginning of a period or interval.
Range:	`time:Instant`
Usage note:	Use of the property `time:hasBeginning` entails that value of the `dcterms:temporal` property is a member of the `time:TemporalEntity` class from [OWL-TIME]. In this context this could be taken to imply that `dcterms:PeriodOfTime` is equivalent to the sub-class `time:ProperInterval`

Note

RDF Property:	`time:hasEnd`
Definition:	End of a period or interval.
Range:	`time:Instant`
Usage note:	Use of the property `time:hasEnd` entails that value of the `dcterms:temporal` property is a member of the `time:TemporalEntity` class from [OWL-TIME]. In this context this could be taken to imply that `dcterms:PeriodOfTime` is equivalent to the sub-class `time:ProperInterval`

Note

The following properties are specific to this class: geometry, bounding box, centroid.

Examples illustrating use of these options for the spatial coverage of a dataset are given in 10.2 Spatial properties.

RDF Class:	`dcterms:Location`
Definition:	A spatial region or named place.
Usage note:	For an extensive geometry (i.e., a set of coordinates denoting the vertices of the relevant geographic area), the property `locn:geometry` [LOCN] SHOULD be used. For a geographic bounding box delimiting a spatial area the property `dcat:bbox` SHOULD be used. For the geographic center of a spatial area, or another characteristic point, the property `dcat:centroid` SHOULD be used.

Note

RDF Property:	`locn:geometry`
Definition:	Associates a spatial thing [SDW-BP] with a corresponding geometry.
Range:	`locn:Geometry`
Usage note:	The range of this property (`locn:Geometry`) allows for any type of geometry specification. E.g., the geometry could be encoded by a literal, as WKT (`geosparql:wktLiteral` [GeoSPARQL]), or represented by a class, as `geosparql:Geometry` (or any of its subclasses) [GeoSPARQL].

Note

RDF Property:	`dcat:bbox`
Definition:	The geographic bounding box of a spatial thing [SDW-BP].
Range:	`rdfs:Literal`
Usage note:	The range of this property (`rdfs:Literal`) is intentionally generic, with the purpose of allowing different geometry literal encodings. E.g., the geometry could be encoded as a WKT literal (`geosparql:wktLiteral` [GeoSPARQL]).

Note

RDF Property:	`dcat:centroid`
Definition:	The geographic center (centroid) of a spatial thing [SDW-BP].
Range:	`rdfs:Literal`
Usage note:	The range of this property (`rdfs:Literal`) is intentionally generic, with the purpose of allowing different geometry literal encodings. E.g., the geometry could be encoded as a WKT literal (`geosparql:wktLiteral` [GeoSPARQL]).

Note

The following properties are specific to this class: algorithm, checksum value.

RDF Class:	`spdx:Checksum`
Definition:	A Checksum is a value that allows to check the integrity of the contents of a file. Even small changes to the content of the file will change its checksum. This class allows the results of a variety of checksum and cryptographic message digest algorithms to be represented [SPDX].
Usage note:	The Checksum includes the algorithm (`spdx:algorithm`) and value (`spdx:checksumValue`) that allows the integrity of a file to be verified to ensure no errors occurred in transmission or storage.

Note

RDF Property:	`spdx:algorithm`
Definition:	Identifies the algorithm used to produce the subject Checksum [SPDX].
Domain:	`spdx:Checksum`
Range:	The set of individuals of class `spdx:ChecksumAlgorithm`.
Usage note:	Version 2.2 of [SPDX] defines individuals for the following algorithms: MD2, MD4, MD5, MD6, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512.

Note

RDF Property:	`spdx:checksumValue`
Definition:	The checksumValue property provides a lowercase hexadecimal encoded digest value produced using a specific algorithm [SPDX].
Domain:	`spdx:Checksum`
Range:	`xsd:hexBinary`

The properties described in 6. Vocabulary specification do not include inverses intentionally, with the purpose of ensuring interoperability also in systems not making use of OWL reasoning.

However, recognizing that inverses are needed for some use cases, DCAT supports them, but with the requirement that they MAY be used only in addition to those described in 6. Vocabulary specification, and that they MUST NOT be used to replace them.

The following table lists the inverse properties supported in DCAT.

Property	Inverse
`dcat:prev`	`dcat:next`
`dcat:previousVersion`	`dcat:nextVersion`
`dcat:distribution`	`dcat:isDistributionOf`
`dcterms:hasPart`	`dcterms:isPartOf`
`dcat:resource`	`dcat:inCatalog`
`dcterms:replaces`	`dcterms:isReplacedBy`
`dcterms:isReferencedBy`	`dcterms:references`
`dcat:hasVersion`	`dcat:isVersionOf`
`dcat:inSeries`	`dcat:seriesMember`
`foaf:primaryTopic`	`foaf:isPrimaryTopicOf`
`prov:wasGeneratedBy`	`prov:generated`

If identifiers are not HTTP dereferenceable, common identifier types can be served as RDF datatypes [RDF11-CONCEPTS] or custom OWL datatypes [OWL2-SYNTAX] for the sake of interoperability, see ex:type in Example 17.

Example 17

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

<https://dcat.example.org/sid5> 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 IRI type is used (following [RFC3986], § 3.1 Scheme), the identifier scheme is part of the IRI; thus indicating a separate identifier scheme in 'type' is redundant. For example, DOI is registered as a namespace in the info IRI scheme [IANA-URI-SCHEMES] (see DOI FAQ #11), so according to [RFC3986], it should be encoded as in Example 18.

Example 18

<https://dcat.example.org/sid6> 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 [DataCite] and FAIRsharing Registry.

Five temporal properties of resources may be described using DCAT.

The release time of a resource is given using dcterms:issued. The value is usually encoded as a xsd:date.
The revision or update time of a resource is given using dcterms:modified. The value is usually encoded as a xsd:date.
The update schedule for a resource is indicated using dcterms:accrualPeriodicity. The value should be taken from a controlled vocabulary such as Dublin Core Collection Description Frequency Vocabulary.
The minimum temporal separation of items in a dataset is given using dcat:temporalResolution. The value is encoded as a xsd:duration. The update schedule and the temporal resolution can be combined to support the description of different kinds of time-series data as shown below.
The temporal extent of a dataset is given using dcterms:temporal. The value is a dcterms:PeriodOfTime. A number of options for expressing the details of a dcterms:PeriodOfTime are recommended in 6.15 Class: Period of Time. Examples of these follow.

Example 21: 15-minute time-series published daily

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

Example 22: Hourly data published immediately

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

Example 23: Temporal coverage as closed interval

ex:ds257 a dcat:Dataset ;
  dcterms:temporal [ a dcterms:PeriodOfTime ;
    dcat:startDate "2016-03-04"^^xsd:date ;
    dcat:endDate   "2018-08-05"^^xsd:date ;
  ] .

Example 24: Temporal coverage as closed interval, using time:ProperInterval

The following dataset specification is equivalent to the one in Example 23, but it uses [OWL-TIME]:

ex:ds348 a dcat:Dataset ;
  dcterms:temporal [ a dcterms:PeriodOfTime , time:ProperInterval ;
    time:hasBeginning [ a time:Instant ;
      time:inXSDDate "2016-03-04"^^xsd:date ;
    ] ;
    time:hasEnd [ a time:Instant ;
      time:inXSDDate "2018-08-05"^^xsd:date ;
    ] ;
  ] .

Example 25: Temporal coverage as proper interval using gYear

ex:ds429 a dcat:Dataset ;
  dcterms:temporal [ a dcterms:PeriodOfTime , time:ProperInterval ;
    time:hasBeginning [ a time:Instant ;
      time:inXSDgYear "1914"^^xsd:gYear ;
    ] ;
    time:hasEnd [ a time:Instant ;
      time:inXSDgYear "1939"^^xsd:gYear ;
    ] ;
  ] .

Example 26: Temporal coverage for a geologic dataset

ex:ds850 a dcat:Dataset ;
  dcterms:temporal [ a dcterms:PeriodOfTime , time:ProperInterval ;
    time:hasBeginning [ a time:Instant ;
      time:inTimePosition [ a time:TimePosition ;
        time:hasTRS <http://resource.geosciml.org/classifier/cgi/geologicage/ma> ;
        time:numericPosition "541.0"^^xsd:decimal ;
      ] ;
    ] ;
    time:hasEnd [ a time:Instant ;
      time:inTimePosition [ a time:TimePosition ;
        time:hasTRS <http://resource.geosciml.org/classifier/cgi/geologicage/ma> ;
        time:numericPosition "251.902"^^xsd:decimal ;
      ] ;
    ] ;
  ] .

Example 27: Temporal coverage as open interval (no end date)

ex:ds127 a dcat:Dataset ;
  dcterms:temporal [ a dcterms:PeriodOfTime ;
    dcat:startDate "2016-03-04"^^xsd:date ;
  ] .

Example 28: Temporal coverage as open interval (no beginning)

ex:ds586 a dcat:Dataset ;
  dcterms:temporal [ a dcterms:PeriodOfTime , time:ProperInterval ;
    time:hasEnd [ time:inXSDDate "2018-08-05"^^xsd:date ] ;
  ] .

Two spatial properties of datasets may be described using DCAT.

The minimum spatial separation of items in a dataset is given using dcat:spatialResolutionInMeters. The value is a decimal number.

An example of the use of dcat:spatialResolutionInMeters is given in Example 3.
The spatial extent of a dataset is given using dcterms:spatial. The value is a dcterms:Location. A number of options for expressing the details of a dcterms:Location are recommended in 6.16 Class: Location.

Examples of these follow.

Note

Example 29: Spatial coverage as a polygon

A dataset whose spatial coverage corresponds to Anne Frank's house in Amsterdam, specified as a polygon (the coordinate reference system is CRS84).

<AnneFrank_0> a dcat:Dataset ;
  dcterms:spatial [
    a dcterms:Location ;
    locn:geometry """POLYGON ((
      4.8842353 52.375108 , 4.884276 52.375153 ,
      4.8842567 52.375159 , 4.883981 52.375254 ,
      4.8838502 52.375109 , 4.883819 52.375075 ,
      4.8841037 52.374979 , 4.884143 52.374965 ,
      4.8842069 52.375035 , 4.884263 52.375016 ,
      4.8843200 52.374996 , 4.884255 52.374926 ,
      4.8843289 52.374901 , 4.884451 52.375034 ,
      4.8842353 52.375108
    ))"""^^geosparql:wktLiteral ;
  ] .

Figure 2 Map preview of a spatial coverage specified with a geometry

Example 30: Spatial coverage as a polygon, using a specific CRS

The same dataset in Example 29, but where the coordinates of the polygon are specified by using the national Dutch CRS - EPSG:28992 ("Amersfoort / RD New").

<AnneFrank_1> a dcat:Dataset ;
  dcterms:spatial [
    a dcterms:Location ;
    locn:geometry """<http://www.opengis.net/def/crs/EPSG/0/28992> POLYGON ((
      120749.725 487589.422 , 120752.55 487594.375  ,
      120751.227 487595.129 , 120732.539 487605.788 ,
      120723.505 487589.745 , 120721.387 487585.939 ,
      120740.668 487575.07  , 120743.316 487573.589 ,
      120747.735 487581.337 , 120751.564 487579.154 ,
      120755.411 487576.96  , 120750.935 487569.172 ,
      120755.941 487566.288 , 120764.369 487581.066 ,
      120749.725 487589.422
    ))"""^^geosparql:wktLiteral ;
  ] .

Example 31: Spatial coverage as centroid

The same dataset of Example 29, but where spatial coverage is specified by using the centroid / representative point of Anne Frank's house.

<AnneFrank_2> a dcat:Dataset ;
  dcterms:spatial [
    a dcterms:Location ;
    dcat:centroid "POINT(4.88412 52.37509)"^^geosparql:wktLiteral ;
  ] .

Figure 3 Map preview of a spatial coverage specified with a centroid

Example 32: Spatial coverage as bounding box

The Dutch dataset of postal addresses, with its spatial coverage (Netherlands) specified as a bounding box.

ex:Dutch-postal a dcat:Dataset ;
  dcterms:title "Adressen"@nl ;
  dcterms:title "Addresses"@en ;
  dcterms:description """INSPIRE Adressen afkomstig uit de basisregistratie Adressen,
                   beschikbaar voor heel Nederland"""@nl ;
  dcterms:description """INSPIRE addresses derived from the Addresses base registry,
                   available for the Netherlands"""@en ;
  dcat:theme <http://inspire.ec.europa.eu/theme/ad> ;
  dcterms:spatial [
    a dcterms:Location ;
    dcat:bbox """POLYGON((
      3.053 47.975 , 7.24  47.975 ,
      7.24  53.504 , 3.053 53.504 ,
      3.053 47.975
    ))"""^^geosparql:wktLiteral ;
  ] .

Figure 4 Map preview of a spatial coverage specified with a bounding box

DCAT supports the following kinds of relationships between versions:

Those indicating the version chain and hierarchy (the version history).
Those indicating whether a version is replaced/superseded by another one.

DCAT defines specific properties for describing version history, aligned with the corresponding [PAV] ones:

dcat:previousVersion (equivalent to pav:previousVersion)
dcat:hasVersion (equivalent to pav:hasVersion);
dcat:hasCurrentVersion (equivalent to pav:hasCurrentVersion, and subproperty of dcat:hasVersion).

Property dcat:previousVersion is used to build a version chain that can be navigated backward from a given version to the first one. This reflects the most typical use case - i.e., linking different versions published as distinct resources in a catalog.

In addition to this, property dcat:hasVersion can be used to specify a version hierarchy, by linking an abstract resource to its versions.

If needed, the version hierarchy can be further described by specific properties. More precisely, property dcat:hasCurrentVersion link an abstract resource to snapshot corresponding to the current version of the content, whereas property dcat:isVersionOf (inverse of dcat:hasVersion) gives the possibility of specifying a back link from a version to the abstract resource (for the use of this property, see 7. Use of inverse properties).

Note

Note that the only properties necessary to specify a version chain and hierarchy are, respectively, dcat:previousVersion and dcat:hasVersion. Whether to use or not the other ones depends on the requirements of the relevant use case.

The following example reuses those in § 8.6 Data Versioning of [DWBP] and revises them to show how to specify a version chain and hierarchy on a bus stops dataset, by using the properties described in this section.

Example 33: Version history of the MyCity bus stops dataset

The MyCity bus stops dataset is updated whenever the list of bus stops changes. The different versions are preserved in order to keep an historical record of the bus stops available at given points in time. An abstract dataset is used to point to the version with the most up to date list of bus stops.

In Figure 5, the resource with IRI mycity-bus:stops is the abstract resource, corresponding always to the latest version of the MyCity bus stops dataset, whereas the other ones correspond to specific versions of it. The current version is the one with IRI mycity-bus:stops-2015-12-07.

Figure 5 Version chain and hierarchy of the MyCity bus stops dataset

The corresponding [Turtle] representation:

mycity-bus:stops a dcat:Dataset ;
  ...
  dcat:hasVersion mycity-bus:stops-2015-01-01 ,
    mycity-bus:stops-2015-05-05 ,
    mycity-bus:stops-2015-12-07 ;
  dcat:hasCurrentVersion mycity-bus:stops-2015-12-07 ;
.

mycity-bus:stops-2015-01-01 a dcat:Dataset ;
  ...
  dcat:isVersionOf mycity-bus:stops ;
.

mycity-bus:stops-2015-05-05 a dcat:Dataset ;
  ...
  dcat:previousVersion mycity-bus:stops-2015-01-01 ;
  dcat:isVersionOf mycity-bus:stops ;
.

mycity-bus:stops-2015-12-07 a dcat:Dataset ;
  ...
  dcat:previousVersion mycity-bus:stops-2015-05-05 ;
  dcat:isVersionOf mycity-bus:stops ;
.

Another type of relationship concerns whether a given version replaces/supersedes another one. For this purpose, DCAT reuses the relevant [DCTERMS] property, namely, dcterms:replaces, plus its inverse dcterms:isReplacedBy, in case a back link needs to be provided.

It is worth noting that these properties are not denoting by themselves a version chain - i.e., a version is not necessarily replacing its immediate predecessor.

The following example reuses the description of the MyCity bus stop dataset in Example 33 to show how replaced versions can be specified in DCAT.

Example 34: Replaced versions of the MyCity bus stops dataset

mycity-bus:stops-2015-01-01 a dcat:Dataset ;
  ...
  dcat:isVersionOf mycity-bus:stops ;
.

mycity-bus:stops-2015-05-05 a dcat:Dataset ;
  ...
  dcat:previousVersion mycity-bus:stops-2015-01-01 ;
  dcat:isVersionOf mycity-bus:stops ;
  dcterms:replaces mycity-bus:stops-2015-01-01 ;
.

mycity-bus:stops-2015-12-07 a dcat:Dataset ;
  ...
  dcat:previousVersion mycity-bus:stops-2015-05-05 ;
  dcat:isVersionOf mycity-bus:stops ;
  dcterms:replaces mycity-bus:stops-2015-05-05 ;
.

Besides the relationships illustrated in the previous section, versioned resources may be associated with additional information, describing, e.g., their differences with the original resource (the version "delta"), the version identifier, and release date.

For these purposes, DCAT makes use of the following properties:

dcat:version (equivalent to pav:version [PAV]), for the version name / identifier;
dcterms:issued [DCTERMS], for the version release date;
adms:versionNotes [VOCAB-ADMS], for a textual description of the changes, including backward compatibility issues with the previous version of the resource.

Note

The following example reuses the one in [DWBP]'s Best Practice 7: Provide a version indicator to show how version information can be specified in DCAT.

Example 35: First version of the MyCity bus stops dataset

mycity-bus:stops-2015-01-01
  a dcat:Dataset ;
  dcterms:title "Bus stops of MyCity" ;
  ...
  dcterms:issued "2015-01-01"^^xsd:date ;
  ...
  dcat:version "1.0" ;
  adms:versionNotes "First version of the bus stop dataset."@en ;
.

The life-cycle of a resource is an aspect orthogonal to versioning, and sometimes strictly related. The evolution of a resource along its life-cycle (from its conception, to its creation and publication) may result in new versions, although this is not always the case (e.g., in case an approval workflow is in place, the resource may not undergo any change if no revision is needed). Similarly, the creation of a new version may not necessarily lead to a change in status (e.g., when changes are not substantial, and/or are implemented on resources still in development). Moreover, when a resource is replaced because of a revision (correcting errors, adding new content, etc.), it may be moved to a different life-cycle status (e.g., deprecation or withdrawal).

It is worth noting that the status of a resource with respect to its life-cycle is often an important piece of information by itself, from both the data provider's and data consumers' perspectives. For a data consumer, it is important to know if a resource is still in development or not, as well as if it is deprecated or withdrawn (and, in such cases, if there is a new version to be used). On the other hand, for a data provider, flagging a resource with its status in the life-cycle is fundamental for the correct administration of the data management workflow. E.g., a resource before being published may need to be stable, and possibly flagged as approved and/or registered. Finally, besides the actual status of a resource, another useful piece of information is when the resource moved to a different status (e.g., when it was created, reviewed, accepted, published).

As for versioning, the resource life-cycle depends on community practices, data management policies, and the workflows in place. Moreover, different resource types (e.g., datasets vs catalog records) may have different life-cycle statuses.

For the specification of life-cycle statuses, DCAT makes use of property adms:status [VOCAB-ADMS], along with the appropriate [DCTERMS] time-related properties (dcterms:created, dcterms:dateSubmitted, dcterms:dateAccepted, dcterms:dateCopyrighted, dcterms:issued, dcterms:modified, dcterms:valid). However, DCAT does not prescribe the use of any specific set of life-cycle statuses, but refers to existing standards and community practices fit for the relevant application scenario.

Note

Examples of life-cycle statuses include:

Those defined in the ISO standard for item registration [ISO-19135] (accepted / not accepted, deprecated, experimental, reserved, retired, stable, submitted, superseded, valid / invalid).
The progress codes defined in [ISO-19115] (accepted, completed, deprecated, final, historical archive, not accepted, obsolete, ongoing, pending, planned, proposed, required, retired, superseded, tentative, under development, valid, withdrawn).
The ADMS Status vocabulary [ADMS-SKOS], used in [DCAT-AP], which includes four statuses: completed, deprecated, under development, and withdrawn.
The dataset statuses [EUV-DS] and concept statuses [EUV-CS] vocabularies from the EU Vocabularies registry.

The UK Government Linked Data Registry project [UKGOVLD-REG] provides an example of how the life-cycle statuses defined in [ISO-19135] can be used in a registry, along with the criteria for status transition.

The DCAT versioning approach can coexist with existing versioning practices - as those used in specific communities, domains, and resource types.

As an example, the following table shows the correspondences between the DCAT versioning properties and the vocabularies most frequently used to specify similar concepts, namely, OWL, for ontologies, [DCTERMS], and [PROV-O].

Similar (but not equivalent) versioning properties in DCAT, OWL, [DCTERMS], and [PROV-O]
DCAT	OWL	[DCTERMS]	[PROV-O]
`dcat:hasVersion`		`dcterms:hasVersion`	`prov:generalizationOf`
`dcat:isVersionOf`		`dcterms:isVersionOf`	`prov:specializationOf`
`dcat:hasCurrentVersion`	`owl:versionIRI`
`dcat:previousVersion`	`owl:priorVersion`		`prov:wasRevisionOf`
`dcat:version`	`owl:versionInfo`

Note that correspondence does not imply equivalence. These properties have different scopes and semantics, and therefore they can complement but not replace each other. In particular, OWL properties are meant to be used on resources that can be typed as owl:Ontology's, whereas the [DCTERMS] ones use a very broad notion of version (including editions and adaptations). On the other hand, DCAT versioning properties are meant to be used on any resource in a catalog, and they use a very specific notion of version, as explained in the introduction to 11. Versioning. Finally, the [PROV-O] property prov:wasRevisionOf, although semantically similar to dcat:previousVersion, is not explicitly meant to be used to build a version chain, whereas prov:generalizationOf and prov:specializationOf are semantically broader than their sub-properties dcat:hasVersion and dcat:isVersionOf, respectively.

The following example shows how DCAT and OWL can be used complementarily to versioning [VOCAB-DCAT-2].

Example 36: Use of DCAT and OWL for versioning DCAT 3

<http://www.w3.org/ns/dcat> a owl:Ontology , dcat:Dataset ;
  owl:versionInfo "3" ;
  dcat:version "3" ;
  owl:versionIRI <http://www.w3.org/ns/dcat3> ;
  dcat:hasCurrentVersion <http://www.w3.org/ns/dcat3> ;
  owl:priorVersion <http://www.w3.org/ns/dcat2> ;
  dcat:previousVersion <http://www.w3.org/ns/dcat2> ;
  dcat:hasVersion <http://www.w3.org/ns/dcat2014> ,
    <http://www.w3.org/ns/dcat2> ,
    <http://www.w3.org/ns/dcat3> ;
.

Note

DCAT makes dataset series first class citizens of data catalogs by minting a new class dcat:DatasetSeries, defined as a subclass of dcat:Dataset. The datasets are linked to the dataset series by using the property dcat:inSeries. Note that a dataset series can also be hierarchical, and a dataset series can be a member of another dataset series.

Example 37: Yearly budget datasets grouped into a series

In the following example, yearly budget data are grouped into a series. The series is typed as dcat:DatasetSeries, the child datasets are typed as dcat:Dataset. The datasets are linked to the series by using dcat:inSeries.

ex:EUCatalogue a dcat:Catalog ;
  dcterms:title "European Data Catalogue"@en ;
  dcat:dataset ex:budget , ex:employment , ex:finance ;
  .

ex:budget a dcat:DatasetSeries ;
  dcterms:title "Budget data"@en ;
  .
  
ex:budget-2018 a dcat:Dataset ;
  dcterms:title "Budget data for year 2018"@en ;
  dcat:inSeries ex:budget ;
  .
  
ex:budget-2019 a dcat:Dataset ;
  dcterms:title "Budget data for year 2019"@en ;
  dcat:inSeries ex:budget ;
  .
  
ex:budget-2020 a dcat:Dataset ;
  dcterms:title "Budget data for year 2020"@en ;
  dcat:inSeries ex:budget ;
  .

Dataset series may evolve over time, by acquiring new datasets. E.g., a dataset series about yearly budget data will acquire a new child dataset every year. In such cases, it might be important to link the yearly releases with relationships specifying the first, previous, next, and latest ones. In such a scenario, DCAT makes use of properties dcat:first, dcat:prev, and dcat:last, respectively. See 7. Use of inverse properties for dcat:next.

Example 38: Linking datasets in a series

The following example extends Example 37 by specifying the publication date (dcterms:issued) of each child dataset, and the previous (dcat:prev) and next (dcat:next) dataset in the series. Moreover, the dataset series is linked to its first (dcat:first) and last (dcat:last) child datasets.

ex:budget a dcat:DatasetSeries ;
  dcterms:title "Budget data"@en ;
  dcat:first ex:budget-2018 ;
  dcat:last ex:budget-2020 ;
  .
  
ex:budget-2018 a dcat:Dataset ;
  dcterms:title "Budget data for year 2018"@en ;
  dcat:inSeries ex:budget ;
  dcterms:issued "2019-01-01"^^xsd:date ;
  dcat:next ex:budget-2019 ;
  .
  
ex:budget-2019 a dcat:Dataset ;
  dcterms:title "Budget data for year 2019"@en ;
  dcat:inSeries ex:budget ;
  dcterms:issued "2020-01-01"^^xsd:date ;
  dcat:prev ex:budget-2018 ;
  dcat:next ex:budget-2020 ;
  .
  
ex:budget-2020 a dcat:Dataset ;
  dcterms:title "Budget data for year 2020"@en ;
  dcat:inSeries ex:budget ;
  dcterms:issued "2021-01-01"^^xsd:date ;
  dcat:prev ex:budget-2019 ;
  .

Datasets in a series can, of course, be versioned. In such a case, the dataset can be linked to its versions by using the approach illustrated in 11.1.1 Version chains and hierarchies, as shown in Example 39.

Note

Example 39: Combining dataset series and versions

The following example extends Example 38 by supposing that dataset ex:budget-2019 has two different versions, namely, ex:budget-2019-rev0 and ex:budget-2019-rev1. Dataset ex:budget-2019 is linked to its versions by using property dcat:hasVersion, and to its current version (ex:budget-2019-rev1) by using property dcat:hasCurrentVersion.

ex:budget a dcat:DatasetSeries ;
  dcterms:title "Budget data"@en ;
  dcat:first ex:budget-2018 ;
  dcat:last ex:budget-2020 ;
  .
  
ex:budget-2018 a dcat:Dataset ;
  dcterms:title "Budget data for year 2018"@en ;
  dcat:inSeries ex:budget ;
  dcterms:issued "2019-01-01"^^xsd:date ;
  dcat:next ex:budget-2019 ;
  .
  
ex:budget-2019 a dcat:Dataset ;
  dcterms:title "Budget data for year 2019"@en ;
  dcat:inSeries ex:budget ;
  dcat:hasVersion ex:budget-2019-rev0 , ex:budget-2019-rev1 ;
  dcat:hasCurrentVersion ex:budget-2019-rev1 ;
  dcterms:issued "2020-01-01"^^xsd:date ;
  dcat:prev ex:budget-2018 ;
  dcat:next ex:budget-2020 ;
  .

ex:budget-2019-rev0 a dcat:Dataset ;
  dcterms:title "Budget data for year 2019"@en ;
  dcat:version "rev0" ;
  dcat:isVersionOf ex:budget-2019 ;
  dcterms:issued "2020-01-01"^^xsd:date ;
  .

ex:budget-2019-rev1 a dcat:Dataset ;
  dcterms:title "Budget data for year 2019"@en ;
  dcat:version "rev1" ;
  dcat:isVersionOf ex:budget-2019 ;
  dcat:previousVersion ex:budget-2019-rev0 ;
  dcterms:issued "2020-05-10"^^xsd:date ;
  .
  
ex:budget-2020 a dcat:Dataset ;
  dcterms:title "Budget data for year 2020"@en ;
  dcat:inSeries ex:budget ;
  dcterms:issued "2021-01-01"^^xsd:date ;
  dcat:prev ex:budget-2019 ;
  .

Properties about dataset series can be classified into two groups.

The first group is about properties describing the dataset series itself. For instance, this is the case of property dcterms:accrualPeriodicity, whose value should correspond to the frequency upon which a new child dataset is added.

The second group is about properties reflecting the dimensions described in child dataset metadata, via upstream inheritance - i.e., property values of child datasets are inherited by their parent (the dataset series).

Typically, this means that, for each of the relevant properties, the dataset series takes as value the union of those specified in child datasets. For instance:

If the temporal coverage of child datasets is a different year, e.g., 2018, 2019, 2020, the temporal coverage of the series will be the time period between years 2018 and 2020.
If child datasets have a different geographic bounding box as spatial coverage, the spatial coverage of the series will be the union of these bounding boxes (i.e., a bounding box including the ones of the child datasets).
If each child dataset uses a different spatial reference system, the dataset series will have multiple spatial reference systems.

Finally, some annotation properties of child datasets may need to be taken into account as well at the level of dataset series. In particular, properties concerning the creation / publication / update dates of child datasets may affect the corresponding ones in the series. For these properties, DCAT recommends the following approach:

The creation date (dcterms:created) of the dataset series should correspond to the earliest creation date of the child datasets.
The publication date (dcterms:issued) of the dataset series should correspond to the earliest publication date of the child datasets.
The update date (dcterms:modified) of the dataset series should correspond to the latest publication or update date of the child datasets.

Note

Example 40: Dataset series metadata

The following example is a variant of Example 38, with child datasets corresponding to yearly budget data for specific countries. The temporal resolution (dcat:temporalResolution), temporal coverage (dcat:temporal), and spatial coverage (dcat:spatial) of the dataset series correspond to the union of those of the child datasets. Moreover, the dataset series specifies as publication date the one of the first published child dataset, whereas the date of publication of the last child dataset is specified as update date (dcterms:modified). Finally, the update frequency (dcterms:accrualPeriodicity) of the dataset series is annual, as the child datasets are published on a yearly basis.

ex:budget a dcat:DatasetSeries ;
  dcterms:title "Budget data"@en ;
  dcterms:issued "2019-01-01"^^xsd:date ,
  dcterms:modified "2021-01-01"^^xsd:date ;
  dcterms:accrualPeriodicity <http://purl.org/cld/freq/annual> ;
  dcat:temporalResolution "P1Y"^^xsd:duration ;
  dcterms:temporal [ a dcterms:PeriodOfTime ;
    dcat:startDate "2018-01-01"^^xsd:date ;
    dcat:endDate   "2020-12-31"^^xsd:date ;
  ] ;  
  dcterms:spatial <http://publications.europa.eu/resource/dataset/country/BEL> ,
    <http://publications.europa.eu/resource/dataset/country/FRA> ,
    <http://publications.europa.eu/resource/dataset/country/ITA> ,
    ...  ;
  .
  
ex:budget-2018-be a dcat:Dataset ;
  dcterms:title "Belgium budget data for year 2018"@en ;
  dcat:inSeries ex:budget ;
  dcterms:issued "2019-01-01"^^xsd:date ;
  dcat:next ex:budget-2019-be ;
  dcterms:accrualPeriodicity <http://purl.org/cld/freq/annual> ;
  dcat:temporalResolution "P1Y"^^xsd:duration ;
  dcterms:temporal [ a dcterms:PeriodOfTime ;
    dcat:startDate "2018-01-01"^^xsd:date ;
    dcat:endDate   "2018-12-31"^^xsd:date ;
  ] ;  
  dcterms:spatial <http://publications.europa.eu/resource/dataset/country/BEL> ;
  .
  
...
  
ex:budget-2018-fr a dcat:Dataset ;
  dcterms:title "France budget data for year 2018"@en ;
  dcat:inSeries ex:budget ;
  dcterms:issued "2019-01-01"^^xsd:date ;
  dcat:next ex:budget-2019-fr ;
  dcterms:accrualPeriodicity <http://purl.org/cld/freq/annual> ;
  dcat:temporalResolution "P1Y"^^xsd:duration ;
  dcterms:temporal [ a dcterms:PeriodOfTime ;
    dcat:startDate "2018-01-01"^^xsd:date ;
    dcat:endDate   "2018-12-31"^^xsd:date ;
  ] ;  
  dcterms:spatial <http://publications.europa.eu/resource/dataset/country/FRA> ;
  .

...
  
ex:budget-2018-it a dcat:Dataset ;
  dcterms:title "Italy budget data for year 2018"@en ;
  dcat:inSeries ex:budget ;
  dcterms:issued "2019-01-01"^^xsd:date ;
  dcat:next ex:budget-2019-it ;
  dcterms:accrualPeriodicity <http://purl.org/cld/freq/annual> ;
  dcat:temporalResolution "P1Y"^^xsd:duration ;
  dcterms:temporal [ a dcterms:PeriodOfTime ;
    dcat:startDate "2018-01-01"^^xsd:date ;
    dcat:endDate   "2018-12-31"^^xsd:date ;
  ] ;  
  dcterms:spatial <http://publications.europa.eu/resource/dataset/country/ITA> ;
  .
  
...

Existing DCAT implementations adopt two main alternative approaches to specifying dataset series:

The dataset series is typed as a dcat:Dataset, whereas its child datasets are typed as dcat:Distribution's.
Both the dataset series and its child datasets are typed as a dcat:Dataset's, and the two are usually linked by using the [DCTERMS] properties dcterms:hasPart / dcterms:isPartOf.

In both cases, the dataset series is sometimes soft-typed by using the [DCTERMS] property dcterms:type (e.g., this is the approach used in [GeoDCAT-AP], and adopted in [DCAT-AP-IT] and [GeoDCAT-AP-IT]).

These options are not formally incompatible with DCAT, so they can coexist with dcat:DatasetSeries during the upgrade to DCAT 3.

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

Example 41

ex:genoaBusStopsDataset a dcat:Dataset ;
  dqv:hasQualityAnnotation ex:genoaBusStopsDatasetCompletenessNote .

ex:genoaBusStopsDatasetCompletenessNote a dqv:UserQualityFeedback ;
  oa:hasTarget ex:genoaBusStopsDataset ;
  oa:hasBody ex:textBody ;
  oa:motivatedBy dqv:qualityAssessment ;
  prov:wasAttributedTo ex:consumer1 ;
  prov:generatedAtTime "2018-05-27T02:52:02Z"^^xsd:dateTime ;
  dqv:inDimension ldqd:completeness
  .

ex:textBody a oa:TextualBody ;
  rdf:value "Incomplete dataset: it contains only 20500 out of 30000 existing bus stops" ;
  dc:language "en" ;
  dc:format "text/plain"
  .

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

Example 42

ex:genoaBusStopsDataset
  dqv:hasQualityMeasurement ex:genoaBusStopsDatasetCompletenessMeasurement .

ex:genoaBusStopsDatasetCompletenessMeasurement a dqv:QualityMeasurement ;
  dqv:computedOn ex:genoaBusStopsDataset ;
  dqv:isMeasurementOf ex:completenessWRTExpectedNumberOfEntities ;
  dqv:value "0.6833333"^^xsd:decimal  ;
  prov:wasAttributedTo ex:myQualityChecker ;
  prov:generatedAtTime "2018-05-27T02:52:02Z"^^xsd:dateTime ;
  prov:wasGeneratedBy ex:myQualityChecking
  .

ex:completenessWRTExpectedNumberOfEntities a dqv:Metric ;
  skos:definition "The degree of completeness as ratio between the actual number of entities included in the dataset and the declared expected number of entities."@en ;
  dqv:expectedDataType xsd:decimal ;
  dqv:inDimension ldqd:completeness .

# ex:myQualityChecker is a service computing some quality metrics
ex:myQualityChecker a prov:SoftwareAgent ;
  rdfs:label "A quality assessment service"@en .
  # Further details about quality service/software can be provided, for example,
  # deploying  vocabularies such as Dataset Usage Vocabulary (DUV), Dublin Core or ADMS.SW

# ex:myQualityChecking is the activity that has generated 
# ex:genoaBusStopsDatasetCompletenessMeasurement from ex:genoaBusStopsDataset
ex:myQualityChecking a prov:Activity ;
  rdfs:label "The checking of genoaBusStopsDataset's quality"@en ;
  prov:wasAssociatedWith ex:myQualityChecker ;
  prov:used ex:genoaBusStopsDataset ;
  prov:generated ex:genoaBusStopsDatasetCompletenessMeasurement ;
  prov:endedAtTime "2018-05-27T02:52:02Z"^^xsd:dateTime ;
  prov:startedAtTime "2018-05-27T00:52:02Z"^^xsd:dateTime .

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

This section shows different modeling 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.

The use of dcterms:conformsTo and dcterms:Standard is a well-known pattern to represent the conformance to a standard. Example 43, directly borrowed from [SDW-BP] (Example 51), declares a fictitious dcat: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").

Example 43

ex:Dataset-1 a dcat:Dataset;
  dcterms:conformsTo <http://data.europa.eu/eli/reg/2014/1312/oj> .

# Reference standard / specification
<http://data.europa.eu/eli/reg/2014/1312/oj> a dcterms:Standard ;
  dcterms:title "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"@en ;
  dcterms:issued "2010-11-23"^^xsd:date .

Another example concerns the specification of the coordinate reference system (CRS) used in a dataset - an information which is typically included in geospatial metadata. Example 44 shows how the CRS of a dataset can be specified in DCAT:

Example 44

ex:Dataset-2 a dcat:Dataset;
  dcterms:conformsTo <http://www.opengis.net/def/crs/EPSG/0/28992> .

In Example 44, http://www.opengis.net/def/crs/EPSG/0/28992 is an IRI from the OGC CRS Registry, corresponding to EPSG:28992 ("Amersfoort / RD New") (see also Example 30).

Note

In order to ensure interoperability, it is important to consistently use the IRIs identifying the reference standards / specifications. In particular, DCAT recommends the following general rules:

Use IRIs from reference registries, when available. Examples include the W3C TR registry, the OGC Definitions Server, the ISO OBP.
Use the IRI of the standard / specification, and not the namespace IRI. E.g., to express conformance of a dcat:CatalogRecord with DCAT, the IRI to be used is https://www.w3.org/TR/vocab-dcat/, and not http://www.w3.org/ns/dcat#.
Use the canonical, persistent IRI. This is usually specified in the document itself. If you are in doubt, use the one included in the bibliographic citations for that standard / specification.
Use the non-versioned IRI. If you need to express conformance with a specific version of the standard / specification, use both the un-versioned and the versioned IRI. E.g., in case you need to explicitly state conformance of a dcat:CatalogRecord with DCAT 2, use both https://www.w3.org/TR/vocab-dcat/ and https://www.w3.org/TR/vocab-dcat-2/.

Example 45 extends Example 9 to show how to specify that a given catalog record is conformant with DCAT, by following the above rules.

Example 45

ex:catalog dcat:record ex:record-001 .

ex:record-001
  a dcat:CatalogRecord ;
  foaf:primaryTopic ex:dataset-001 ;
  dcterms:issued "2011-12-11"^^xsd:date ;
  dcterms:conformsTo <https://www.w3.org/TR/vocab-dcat/> ;
  .

Example 46: IRIs for standards

The following table shows the IRIs of some of the standards used in the examples included in this document.

IRI	Specification
`https://www.w3.org/TR/owl2-overview/`	[OWL2-OVERVIEW]
`https://www.w3.org/TR/rdf-schema/`	[RDF-SCHEMA]
`https://www.w3.org/TR/sparql11-protocol/`	[SPARQL11-PROTOCOL]
`http://www.opengis.net/def/serviceType/ogc/csw/`	[CSW]
`http://www.opengis.net/def/serviceType/ogc/wfs/`	[WFS]
`http://www.opengis.net/def/serviceType/ogc/wms/`	[WMS]

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

Example 47 specifies some newly minted concepts representing the degree of conformance (i.e., conformant, not conformant) and declares the dcterms: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., ex:testResult), a prov:Activity to model the testing activity (e.g., ex:testingActivity), a prov:Plan derived from the Data on the Web Best Practices [DWBP] (e.g., ex:conformanceTest) to check for the whole set of best practices. A qualified PROV association binds the testing activity to the conformance test.

Note

Example 47

ex:Dataset-3 a dcat:Dataset ;
  prov:wasUsedBy ex:testingActivity .

ex:testingActivity a prov:Activity ;
  prov:generated ex:testResult ;
  prov:qualifiedAssociation [
    a prov:Association ;
    # http://validator.example.org/ is the agent who ran the test.
    prov:agent  <http://validator.example.org/>
    # following the plan ex:conformanceTest
    prov:hadPlan ex:conformanceTest
  ] .

# Conformance test result
ex:testResult a prov:Entity ;
  prov:wasGeneratedBy ex:testingActivity;
  # ex:notConformant belongs to a SKOS concept scheme about conformance
  dcterms:type ex:notConformant .

ex:conformanceTest a prov:Plan ;
  # Here one can specify additional information on the test, which in the example is derived by the W3C Data on the Web Best Practices
  prov:wasDerivedFrom <https://www.w3.org/TR/dwbp/> .

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

Example 48

ex:levelOfComplianceToDWBP a dqv:Metric ;
  skos:definition "The degree of compliance to DWBP defined as the percentage of passed compliance tests."@en ;
  dqv:expectedDataType xsd:double ;
  dqv:inDimension  iso:compliance .

iso:compliance a dqv:Dimension ;
  skos:prefLabel "Compliance"@en ;
  skos:definition "The degree to which data has attributes that adhere to standards, conventions or regulations in force and similar rules relating to data quality in a specific context of use."@en ;
  dqv:inCategory iso:inherentAndSystemDependentDataQuality .
  
iso:inherentAndSystemDependentDataQuality a dqv:Category ;
  skos:prefLabel "Inherent and System-Dependent Data Quality"@en .

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

Example 49

ex:measurement_complianceToDWBP a dqv:QualityMeasurement ;
  dqv:computedOn ex:Dataset ;
  dqv:value "50"^^xsd:double ;
  sdmx-attribute:unitMeasure <http://www.wurvoc.org/vocabularies/om-1.8/Percentage> ;
  dcterms:date "2018-01-10"^^xsd:date ;
  dqv:isMeasurementOf ex:levelOfComplianceToDWBP .

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]. Example 50 describes the Testing activity ex:testingActivity as an earl:Assertion instead of a qualified association on the prov:Activity. The earl:Assertion states that dataset ex:Dataset has been tested with the conformance test ex:conformanceTest, and it has passed the test as described in ex:testResult.

Example 50

ex:assertion a earl:Assertion ;
  earl:subject ex:Dataset ;
  earl:test ex:conformanceTest ;
  earl:result ex:testResult ;
  # let's indicate if the test was manual, automatic, or what ..
  earl:mode earl:automatic ;
  earl:assertedBy <http://validator.example.org/> ;
  prov:wasAttributedTo  <http://validator.example.org/> .

ex:conformanceTest a earl:TestRequirement, prov:Plan ;
  dcterms:title "Set of conformance test derived from the W3C Data on the Web Best Practices"@en ;
  # it includes different subtests
  dcterms:hasPart ex:testBP1, ex:testBP2, ...,  ex:testBP35 ;
  #It is derived  by the reference standard
  prov:wasDerivedFrom  <https://www.w3.org/TR/dwbp/> .

ex:testResult a earl:TestResult ;
  #  results in conformancy .
  dcterms:type  ex:conformant ;
  prov:wasGeneratedBy ex:testingActivity;
  #the overall set of tests have been passed
  earl:outcome earl:passed .

# the description of the validator
<http://validator.example.org/> a earl:Assertor, prov:Agent ;
  dcterms:description "A test execution service that runs conformance test suites."@en ;
  dcterms:title "Validator"@en .

#the testing activity
ex:testingActivity a prov:Activity ;
  prov:generated ex:assertion, ex:testResult ;
  prov:use ex:Dataset ;
  prov:wasAssociatedWith <http://validator.example.org/> .

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

Example 51

ex:assertion1 a earl:Assertion ;
  earl:subject ex:Dataset ;
  earl:test ex:testq1 ;
  earl:result [
    a earl:TestResult ;
    #  results in no conformancy
    dcterms:type ex:nonConformant ;
    #the overall set of tests have not been passed (!?)
    dcterms:date "2015-09-29T11:50:00+00:00"^^xsd:dateTime ;
    # Some XML encoding of the error
      dcterms:description """
        <ul xmlns="http://www.w3.org/1999/xhtml">
          <li> test 1 has failed. Some description of the errors found</li>
        </ul>"""^^rdf:HTML ;
      earl:info """
        <test-method duration-ms="47" finished-at="2015-09-29T11:50:00Z"
        name="validate" signature="validate()" started-at="2015-09-29T11:50:00Z"
        status="FAIL">
          <exception class="java.lang.AssertionError">
            <message>
              Total validation errors found: 2
            </message>
          </exception>
        </test-method>"""^^rdf:XMLLiteral ;
     earl:outcome earl:fail .
  ];
  # we do not know if the test was manual, automatic, or what ..
  earl:mode earl:automatic.

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

Example 52

ex:errors
  a dqv:QualityAnnotation ;
  #this annotation is derived by the measurement
  prov:wasGeneratedBy  ex:testingActivity;
  oa:hasTarget ex:Dataset ;
  oa:hasBody [
    #errors/failed test description
    a oa:TextualBody ;
    rdf:value  """
      <test-method duration-ms="47" finished-at="2015-09-29T11:50:00Z"
        name="validate" signature="validate()" started-at="2015-09-29T11:50:00Z"
        status="FAIL">
        <exception class="java.lang.AssertionError">
          <message>
            Total validation errors found: 2
          </message>
        </exception>
      </test-method>"""^^rdf:XMLLiteral ;
    #it can be in any format supported by dc
    dc:format  "application/xml" ;
  ] ;
  oa:motivatedBy dqv:qualityAssessment , oa:assessing ;
  dqv:inDimension iso:compliance ;
  .

ex:testResult
  a dqv:QualityMetadata ;
  #  change the the dcterms:type according to the resulted compliance
  dcterms:type <http://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity/conformant> ;
  prov:wasAttributedTo <http://validator.example.org/> ;
  prov:generatedAtTime "2018-05-27T02:52:02Z"^^xsd:dateTime ;
  prov:wasGeneratedBy ex:testingActivity .

# The graph contains the rest of the statements presented in the previous examples.
# The graph is expressed according to TRIG syntax not TTL (see https://www.w3.org/TR/trig/)
ex:testResult {
  a dcat:Dataset ;
  dqv:hasQualityMeasurement ex:measurement_complianceToDWBP ;
  dqv:hasQualityAnnotation ex:errors .
}

#the testing activity
ex:testingActivity a prov:Activity ;
  prov:generated  ex:testResult ;
  prov:use ex:Dataset ;
  prov:wasAssociatedWith <http://validator.example.org/> ;
  .

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

The standard [DCTERMS] properties dcterms:contributor, dcterms:creator and dcterms:publisher, and the generic prov:wasAttributedTo from [PROV-O], support basic associations of responsible agents with a cataloged 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]. Example 53 provides an illustration:

Example 53

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

In Example 53 the roles are denoted by IRIs from a non-normative, non-dereferenceable representation of the CI_RoleCode codelist from [ISO-19115-1] (e.g., URN like urn:example:isotc211/CI_RoleCode). Linked data dereferenceable and normative representations should be preferred when available.

Note

The standard [DCTERMS] properties dcterms:relation and sub-properties such as dcterms:hasPart / dcterms:isPartOf, dcterms:hasVersion / dcterms:isVersionOf, dcterms:replaces / dcterms:isReplacedBy, dcterms:requires / dcterms:isRequiredBy, prov:wasDerivedFrom, prov:wasQuotedFrom, support the description of relationships between datasets and other cataloged 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_AssociationTypeCodes values from [ISO-19115-1], the IANA Registry of Link Relations [IANA-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. Example 54 provides illustrations:

Example 54

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

ex:Test543L
  a dcat:Dataset ;
  dcat:qualifiedRelation [
    a dcat:Relationship ;
    dcterms:relation <http://dcat.example.org/Test543R> ;
    dcat:hadRole <urn:example:isotc211/DS_AssociationTypeCode/stereoMate>
  ] ;
.

In Example 54 the roles are denoted by IRIs from [IANA-RELATIONS] and from a (non-normative) linked data representation of the DS_AssociationTypeCode codelist from [ISO-19115-1].

Note

The DCAT vocabulary supports datasets that may contain personal or private information. In addition, the metadata expressed with DCAT may itself contain personal or private information, such as resource creators, publishers, and other parties or agents described via qualified relations. Implementers who produce, maintain, publish or consume such vocabulary terms must take steps to ensure security and privacy considerations are addressed. Sensitive data and metadata must be stored securely and made available only to authorized parties, in accordance with the legal and functional requirements of the type of data involved. Detailing how to secure web content and authenticate users is beyond the scope of DCAT.

Some datasets require assurances of integrity and authenticity (for example, data about software vulnerabilities). For these, checksums can serve as a type of verification. DCAT borrows the spdx:Checksum class from [SPDX] to ensure the integrity and authenticity of DCAT distributions. Publishers may provide a checksum value (a hash) and the algorithm used to generate the hash for each resource in the distribution. A checksum must, however, be provided via a route that is separate from the data it sums. It may be included in metadata that is provided with the data (e.g., a tarfile that includes a file for the distribution and a file for the metadata that includes a checksum for the distribution file), but if so the checksum, or a checksum for the metadata, must also be provided separately to foil an attacker who would manipulate the checksum along with the data. A checksum provided in DCAT metadata will not provide the expected assurances if the integrity and authenticity of the metadata are not also guaranteed.

Integrity and authenticity of DCAT data ultimately depend on the trustworthiness of the source. DCAT providers should address integrity and authenticity at the application level and transport level. For example, they should ensure the integrity and authenticity of their API and download endpoints, make DCAT data and metadata files downloadable from authoritative HTTPS origins, and provide any checksums via a separate channel from the data they represent.

The DCAT vocabulary provides a model for describing data catalogs. The nature of data in the catalogs depends on the specific domains of application and might include non-text data. When possible, it is important to enforce alternative text for non-text data resources through the DCAT profile mechanisms or systems supporting the creation and editing of such data to improve the accessibility to data. The practice to provide text alternatives for any non-text content, which can be changed into other forms people need, such as large print, braille, speech, symbols, or simpler language complies with accessibility guidelines included in [UNDERSTANDING-WCAG20].

Note

In many legacy catalogs and repositories (e.g., CKAN), ‘datasets’ are ‘just a bag of files’. There is no distinction made between 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 catalog, repository, or elsewhere are not known, dcterms:relation or its sub-property dcterms:hasPart can be used:

Example 55

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

If the nature of the relationship is known, then other sub-properties of dcterms:relation should be used to convey this. In particular, if it is clear that any of these related resources is a proper representation of the dataset, then dcat:distribution should be used.

Example 56

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

This example is available from the DXWG DCAT 3 code repository at csiro-dap-examples.ttl and csiro-stratchart_dcat3.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):

Example 57

dap:d33937
  rdf:type dcat:Dataset ;
  dcterms:title "The data"@en ;
  dcterms:conformsTo <http://resource.geosciml.org/ontology/timescale/gts> ;
  dcterms:description "A set of RDF graphs representing the International [Chrono]stratigraphic Chart [...]"@en ;
  dcterms:identifier "https://doi.org/10.25919/5b4d2b83cbf2d" ;
  dcterms:issued "2018-07-07"^^xsd:date ;
  dcterms:license <https://creativecommons.org/licenses/by/4.0/> ;
  dcterms:publisher <http://www.csiro.au> ;
  dcterms:hasPart <http://stratigraphy.org/ICSchart/ChronostratChart2017-02.jpg> ;
  dcterms:hasPart <http://stratigraphy.org/ICSchart/ChronostratChart2017-02.pdf> ;
  dcterms:hasPart [
    rdf:type dcat:Dataset ;
    dcterms:conformsTo <https://www.w3.org/TR/owl2-overview/> ;
    dcterms:title "The ontology used for the data"@en ;
    dcterms:description "This is an RDF/OWL representation of the GeoSciML Geologic Timescale model ..."@en ;
    dcterms:issued "2011-01-01"^^xsd:date ;
    dcterms:modified "2017-04-28"^^xsd:date ;
    dcterms:title "Geologic Timescale model" ;
    dcterms:type <http://purl.org/adms/assettype/DomainModel> ;
    dcat:distribution [
      rdf:type dcat:Distribution ;
      dcterms:title "RDF/XML representation of the ontology used for the data"@en ;
      dcat:downloadURL <http://resource.geosciml.org/ontology/timescale/gts.rdf> ;
      dcat:mediaType <http://www.iana.org/assignments/media-types/application/rdf+xml> ;
    ] ;
    dcat:distribution [
      rdf:type dcat:Distribution ;
      dcterms:title "TTL representation of the ontology used for the data"@en ;
      dcat:downloadURL <http://resource.geosciml.org/ontology/timescale/gts.ttl> ;
      dcat:mediaType <http://www.iana.org/assignments/media-types/text/turtle> ;
    ] ;
    dcat:distribution [
      rdf:type dcat:Distribution ;
      dcterms:title "Webpage describing the ontology used for the data"@en ;
      dcat:downloadURL <http://resource.geosciml.org/ontology/timescale/gts.html> ;
      dcat:mediaType <http://www.iana.org/assignments/media-types/text/html> ;
    ] ;
    dcat:landingPage <http://resource.geosciml.org/ontology/timescale/gts> ;
  ] ;
  dcat:distribution [
    rdf:type dcat:Distribution ;
    dcterms:conformsTo <https://www.w3.org/TR/rdf-schema/> ;
    dcterms:title "RDF representation of the data"@en ;
    dcat:accessService [
      rdf:type dcat:DataService ;
      dcterms:conformsTo <https://www.w3.org/TR/sparql11-protocol/> ;
      dcterms:title "International Chronostratigraphic Chart hosted at Research Vocabularies Australia"@en ;
      dcterms:description "Service that supports queries to obtain RDF representations of subsets of the data"@en ;
      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 ;
    dcterms:identifier "isc2017.jsonld" ;
    dcterms:title "JSON-LD serialization of the RDF representation of the entire dataset"@en ;
    dcat:mediaType <http://www.iana.org/assignments/media-types/application/ld+json> ;
  ] ;
  dcat:distribution [
    rdf:type dcat:Distribution ;
    dcterms:identifier "isc2017.nt" ;
    dcterms:title "N-Triples serialization of the RDF representation of the entire dataset"@en ;
    dcat:mediaType <http://www.iana.org/assignments/media-types/application/n-triples> ;
  ] ;
  dcat:distribution [
    rdf:type dcat:Distribution ;
    dcterms:identifier "isc2017.rdf" ;
    dcterms:title "RDF/XML serialization of the RDF representation of the entire dataset"@en ;
    dcat:mediaType <http://www.iana.org/assignments/media-types/application/rdf+xml> ;
  ] ;
  dcat:distribution [
    rdf:type dcat:Distribution ;
    dcterms:identifier "isc2017.ttl" ;
    dcterms:title "TTL serialization of the RDF representation of the entire dataset"@en ;
    dcat:mediaType <http://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 ;
  dcterms:type <http://purl.org/dc/dcmitype/Image> ;
  dcterms:format  <http://www.iana.org/assignments/media-types/img/jpeg> ;
  dcterms:description "Coloured image representation of the International Chronostratigraphic Chart"@en ;
  dcterms:issued "2017-02-01"^^xsd:date ;
  dcterms:title "International Chronostratigraphic Chart"@en ;
.
<http://stratigraphy.org/ICSchart/ChronostratChart2017-02.pdf>
  rdf:type foaf:Document ;
  dcterms:type <http://purl.org/dc/dcmitype/Image> ;
  dcterms:format <http://www.iana.org/assignments/media-types/application/pdf> ;
  dcterms:description "Coloured image representation of the International Chronostratigraphic Chart"@en ;
  dcterms:issued "2017-02-01"^^xsd:date ;
  dcterms:title "International Chronostratigraphic Chart"@en ;
.

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

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):

Example 58

dap:atnf-P366-2003SEPT
  rdf:type dcat:Dataset ;
  dcterms: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" ;
  dcterms:title "Parkes observations for project P366 semester 2003SEPT"@en ;
  dcat:landingPage <https://data.csiro.au/dap/landingpage?pid=csiro:P366-2003SEPT> ;
  prov:wasGeneratedBy dap:P366 ;
  .

dap:P366
  rdf:type prov:Activity ;
  dcterms:type <http://dbpedia.org/resource/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"@en ;
  rdfs:seeAlso <https://doi.org/10.1111/j.1365-2966.2006.10100.x> ;
  .

This example is available from the DXWG DCAT 3 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:

prov:wasAttributedTo provides a general link to all kinds of associated agents, such as project sponsors, managers, dataset owners, etc., which are not correctly characterized using dcterms:creator, dcterms:contributor or dcterms:publisher.
prov:wasDerivedFrom supports a more specific relationship to an input or predecessor dataset compared with dcterms:source, which is not necessarily a previous dataset.

Further patterns for the use of qualified properties for resource attribution and interrelationships are described in 15. Qualified relations.

Datasets are often associated with publications (scholarly articles, reports, etc.) and DCAT relies on the property dcterms:isReferencedBy to provide a way to link publications about a dataset to the dataset

The following example shows how a dataset published in the Dryad repository is linked to a publication available in the Nature Scientific Data journal:

Example 59

ex:globtherm
  dcterms:title "Data from: GlobTherm, a global database on thermal tolerances for aquatic and terrestrial organisms"@en ;
  dcterms:description "How climate affects species distributions is a longstanding question receiving renewed interest owing to the need to predict the impacts of global warming on biodiversity. Is climate change forcing species to live near their critical thermal limits? Are these limits likely to change through natural selection? These and other important questions can be addressed with models relating geographical distributions of species with climate data, but inferences made with these models are highly contingent on non-climatic factors such as biotic interactions. Improved understanding of climate change effects on species will require extensive analysis of thermal physiological traits, but such data are scarce and scattered. To overcome current limitations, we created the GlobTherm database. The database contains experimentally derived species’ thermal tolerance data currently comprising over 2,000 species of terrestrial, freshwater, intertidal and marine multicellular algae, plants, fungi, and animals. The GlobTherm database will be maintained and curated by iDiv with the aim of expanding it, and enable further investigations on the effects of climate on the distribution of life on Earth."@en ;
  dcterms:identifier "https://doi.org/10.5061/dryad.1cv08"^^xsd:anyURI ;
  dcterms:creator <https://orcid.org/0000-0002-7883-3577> ;
  dcterms:relation <https://doi.org/10.5061/dryad.1cv08/6> ;
  dcterms:relation <https://doi.org/10.5061/dryad.1cv08/7> ;
  dcterms:isReferencedBy <https://doi.org/10.1038/sdata.2018.22>.

This example is available from the DXWG DCAT 3 code repository at dryad-globtherm-sdata.ttl

Data services may be described using DCAT. The values of the classifiers dcterms:type, dcterms: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 dcterms:type set to "discovery" from the INSPIRE classification of spatial data service types [INSPIRE-SDST].

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

Example 60

ex:EEA-CSW-Endpoint
  rdf:type dcat:DataService ;
  dcterms:type <http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory/infoCatalogueService> ;
  dcterms:accessRights <http://publications.europa.eu/resource/authority/access-right/PUBLIC> ;
  dcterms:conformsTo <http://www.opengis.net/def/serviceType/ogc/csw> ;
  dcterms: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 ;
  dcterms:identifier "eea-sdi-public-catalogue" ;
  dcterms:issued "2012-01-01"^^xsd:date ;
  dcterms:license <https://creativecommons.org/licenses/by/2.5/dk/> ;
  dcterms:spatial [
    rdf:type dcterms:Location ;
    dcat:bbox "POLYGON((-180 90,180 90,180 -90,-180 -90,-180 90))"^^gsp:wktLiteral ;
  ] ;
  dcterms:title "European Environment Agency's public catalogue of spatial datasets."@en ;
  dcterms:type <http://inspire.ec.europa.eu/metadata-codelist/ResourceType/service> ;
  dcterms:type <http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/discovery> ;
  dcat:contactPoint ex: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> ;
.

Example 61 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:DataService and also have the dcterms:type set to "download" and "view" from the INSPIRE classification of spatial data service types [INSPIRE-SDST].

Example 61 is available from the DXWG DCAT 3 code repository at ga-courts.ttl

Example 61

ga-courts:jc
  rdf:type dcat:Dataset ;
  dcterms:description "The dataset contains spatial locations, in point format, of the Australian High Court, Australian Federal Courts and the Australian Magistrates Courts."@en ;
  dcterms:spatial [
    rdf:type dcterms:Location ;
      dcat:bbox """<http://www.opengis.net/def/crs/EPSG/0/4283> POLYGON((
      -42.885989 115.864566 , -12.460578 115.864566 ,
      -12.460578 153.276835 , -42.885989 153.276835 ,
      -42.885989 115.864566 
    ))"""^^geosparql:wktLiteral ;
  ] ;
  dcterms:title "Judicial Courts"@en ;
  dcterms: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:DataService ;
  dcterms:conformsTo <https://developers.arcgis.com/rest/> ;
  dcterms: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."@en ;
  dcterms:identifier "2b8540c8-4a43-144d-e053-12a3070a3ff7" ;
  dcterms:title "National Judicial Courts MapServer"@en ;
  dcterms:type <http://purl.org/dc/dcmitype/Service> ;
  dcterms:type <https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/download> ;
  dcterms: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:DataService ;
  dcterms:conformsTo <http://www.opengis.net/def/serviceType/ogc/wfs/2.0.0> ;
  dcterms:conformsTo <http://www.opengis.net/def/serviceType/ogc/wfs/1.1.0> ;
  dcterms:conformsTo <http://www.opengis.net/def/serviceType/ogc/wfs/1.0.0> ;
  dcterms: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."@en ;
  dcterms:identifier "2b8540c8-4a42-144d-e053-12a3070a3ff7" ;
  dcterms:title "National Judicial Courts WFS"@en ;
  dcterms:type <http://purl.org/dc/dcmitype/Service> ;
  dcterms: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:DataService ;
  dcterms:conformsTo <http://www.opengis.net/def/serviceType/ogc/wms/1.3> ;
  dcterms: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."@en ;
  dcterms:identifier "2b8540c8-4a41-144d-e053-12a3070a3ff7" ;
  dcterms:title "National Judicial Courts WMS"@en ;
  dcterms:type <http://purl.org/dc/dcmitype/Service> ;
  dcterms: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 ;
.

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

Example 62

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

<https://data.gov.cz/zdroj/datová-sada/247025684/22> a dcat:Distribution ;
  dcat:downloadURL <https://mvcr1.opendata.cz/czechpoint/2007.csv.gz> ;
  dcterms:license <https://data.gov.cz/podmínky-užití/volný-přístup/> ;
  dcterms:conformsTo <https://mvcr1.opendata.cz/czechpoint/2007.json> ;
  dcterms: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.

Example 63

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

<https://data.gov.cz/zdroj/datová-sada/247025684/22> a dcat:Distribution ;
  dcat:downloadURL <https://mvcr1.opendata.cz/czechpoint/data.tar> ;
  dcterms:license <https://data.gov.cz/podmínky-užití/volný-přístup/> ;
  dcterms:conformsTo <https://mvcr1.opendata.cz/czechpoint/2007.json> ;
  dcterms: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.

Example 64

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

<https://data.gov.cz/zdroj/datová-sada/247025684/22> a dcat:Distribution ;
  dcat:downloadURL <https://mvcr1.opendata.cz/czechpoint/data.tar.gz> ;
  dcterms:conformsTo <https://mvcr1.opendata.cz/czechpoint/2007.json> ;
  dcterms:license <https://data.gov.cz/podmínky-užití/volný-přístup/> ;
  dcterms: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 DCAT 3 code repository at compress-and-package.ttl

The document has undergone the following changes since the Candidate Recommendation Snapshot 18 January 2024 [VOCAB-DCAT-3-20240118]:

Editorial fixes as suggested in Issues #1581, #1583, #1591.
Fixed the wrong link to SPDX 2.2 - see Issue #1592.
Removed the references at risk features in status section, as implementations for those features have been collected in the implementation report.

The document has undergone the following changes since the DCAT 3 fourth public working draft of 10 May 2022 [VOCAB-DCAT-3-20220510]:

The recommended range of properties 6.6.5 Property: spatial resolution and 6.8.13 Property: spatial resolution has been extended to include xsd:double in addition to xsd:decimal - see Issue #1536.
Updated section 17. Security and Privacy Considerations to include suggestions about integrity and authenticity - see Issue #1526.
Updated usage note in 6.4.9 Property: language to provide guidance on the use of dcterms:language in multilingual distributions - see Issue #1532.
Added health warning related to BCP 47 - see Issue #959.
Updated Example 36 (11.4 Complementary approaches to versioning) to illustrate how to use OWL and DCAT to version DCAT 3.
Editorial and bug fixes throughout the document.

The document has undergone the following changes since the DCAT 3 third public working draft of 11 January 2022 [VOCAB-DCAT-3-20220111]:

Editorial fix to the inconsistent use of "item" and "resource" throughout the document, by replacing "item" with "resource" when referring to an instance of dcat:Resource - see Issue #1490. This revision has affected the definitions and/or the usage notes of the following terms in section 6.4 Class: Cataloged Resource: 6.4.5 Property: description, 6.4.6 Property: title, 6.4.7 Property: release date, 6.4.8 Property: update/modification date, 6.4.9 Property: language, 6.4.10 Property: publisher, 6.4.11 Property: identifier, 6.4.14 Property: relation.
Added Example 45 (14.2.1 Conformance to a standard) and introductory paragraph to show how to use property dcterms:conformsTo with a dcat:CatalogRecord - see Issue #1489.
Added property dcat:inCatalog as the inverse of dcat:resource in section 7. Use of inverse properties - see Issue #1484.
Updated class diagram in Figure 1 to align it with the current version of the specification. In particular:
- Added newly defined properties - see Issue #1469.
- Removed inverse properties listed in section 7. Use of inverse properties - see Issues #1410 and #1413.
- Removed cardinality restrictions not present in the RDF definition - see resolution #3 of 8 March 2022.
Added property dcat:seriesMember as the inverse of dcat:inSeries in section 7. Use of inverse properties - see Issue #1335.
Added Example 39 (12.1 How to specify dataset series) and introductory paragraph to show how to combine dataset series and dataset versions - see Issue #1409.
Defined a new property dcat:resource to link a dcat:Catalog to a dcat:Resource, thus replacing property dcterms:hasPart that in DCAT 2 was introduced for this purpose. As a consequence, properties dcat:dataset, dcat:service, and dcat:catalog have been revised to be sub-properties of dcat:resource - see Issue #1469.
Added property dcterms:hasPart under dcat:Resource - see Issue #1469.
Fixed inconsistent URIs in Example 15 (8. Dereferenceable identifiers) - see Issue #1459.
Aligned the definitions of the properties dcat:dataset, dcat:service, dcat:catalog - see Issue #1465.
The definition of property dcat:version has been revised to make it explicit that version indicators can be numeric or textual - see Issue #1442.
Revised Example 62, Example 63, and Example 64 (C.5 Compressed and packaged distributions) to remove all occurrences of property dcat:accessURL when taking as value the same URL of dcat:downloadURL - see Issue #1437.
Revised usage note of property dcat:packageFormat to include the ZIP format as one of the examples of packaging formats - see Issue #1438.
Editorial fixes to 5.1 DCAT scope - see Issue #1440.

The document has undergone the following changes since the DCAT 3 second public working draft of 4 May 2021 [VOCAB-DCAT-3-20210504]:

New section 7. Use of inverse properties has been added, and properties dcat:isVersionOf, dcat:next, and dcterms:isReplacedBy have been removed from 6. Vocabulary specification - see Issue #1336.
New section 18. Accessibility Considerations has been added - see Issue #1358.
Revision of UML diagrams - see Issues #1383, #1294, #1252.
Revision of the usage note of dcat:Resource - see Issue #1388.
Clarified the scope of dcterms:identifier - see Issue #771.
5.3 Basic example has been updated to tell a more coherent story (see Issue #1155) and express temporal coverage by using dcterms:PeriodOfTime, dcat:startDate, and dcat:endDate.
The usage notes of properties dcat:bbox and dcat:centroid have been revised to make it clearer that they are supposed to be used only with geometry literals - see Issue #1359.
The property dcat:theme have been explicitly defined as an OWL object property and its range is dropped; consistency of the usage note of dcat:themeTaxonomy has been improved - see Issues #1364 and #1153.

The document has undergone the following changes since the DCAT 3 first public working draft of 17 December 2020 [VOCAB-DCAT-3-20201217]:

5.3 Basic example has been extended to include titles, labels, and keywords in two different languages (English and Spanish) to illustrate the use of language tags.

The recommended range of property 6.8.12 Property: byte size has been changed from xsd:decimal to xsd:nonNegativeInteger

11. Versioning has been revised to focus specifically on versions derived from the revision of a resource, and by following the [PAV] approach for the specification of version chains and hierarchies - previous, next, current, last version. In particular:
- The introductory text has been revised according to the new scope.
- The section on version types (link to previous version) has been removed, and a new section has been added to describe how to specify relationships between versions.
- Dropped support to the specification of backward (in)compatibility between versions by using properties owl:backwardCompatibleWith and owl:incompatibleWith, originally included in 11.2 Version information.
- A new section has been added at the end to compare the DCAT versioning approach with those used in OWL, [DCTERMS], and [PROV-O].
The other sections include only editorial changes.
6.4 Class: Cataloged Resource has been updated to include the definition of the properties illustrated in 11. Versioning.
12. Dataset series has been revised making dataset series first class citizens of data catalogs and introducing new properties for linking dataset series and datasets. In particular:
- A new class dcat:DatasetSeries has been defined (see 6.7 Class: Dataset Series) - see Issue #1272.
- Property dcat:inSeries has been added to 6.6 Class: Dataset - see Issue #1307.
- Properties dcat:first, dcat:prev, dcat:next, and dcat:last have been added to 6.4 Class: Cataloged Resource - see Issue #1308.
Added property spdx:checksum to 6.8 Class: Distribution; added class spdx:Checksum (see 6.17 Class: Checksum), and its properties spdx:algorithm and spdx:checksumValue - see Issue #1287.
Revised range of property locn:geometry, to align it with its definition in [LOCN]. The usage note of this property has been also revised to make it clear that it can be used with either geometry literals or classes - see Issue #1293.
Added examples to 9. License and rights statements - see Issues #676 and #1333.
Replaced [DCTERMS] namespace prefix dct: with dcterms: throughout the document - see Issue #1314.
Fixed inconsistent use of "URI" and "IRI" throughout the document - see Issue #1341.
Removed NOTE in Example 31 showing an example of the use of [W3C-BASIC-GEO] for the specification of point geometries - see Issue #1347.
Revised textual descriptions of classes and properties to clarify that the resources in a catalog are not limited to datasets and data services - see Issue #1349.
Fixed inconsistent use of property labels - see Issue #1350.
Updated definition for dcat:catalog - see Issue #1156.

The document has undergone the following changes since the DCAT 2 W3C Recommendation of 4 February 2020 [VOCAB-DCAT-2-20200204]:

Examples about loosely structured catalog were updated replacing dcterms:relation with more specific subrelations and emphasizing the use of dcterms:hasPart.
Section 11. Versioning was extended with draft guidelines to deal with version delta (Issue #89), version release date (Issue #91), version identifier (Issue #92), version compatibility (Issue #1258) and resource status (Issue #1238).
A new section 12. Dataset series was added to draft guidelines on dataset series (Issue #868) and to show related examples (Issue #806).

[DC11]: Dublin Core Metadata Element Set, Version 1.1. DCMI. 14 June 2012. DCMI Recommendation. URL: http://dublincore.org/documents/dces/
[DCTERMS]: DCMI Metadata Terms. DCMI Usage Board. DCMI. 20 January 2020. DCMI Recommendation. URL: https://www.dublincore.org/specifications/dublin-core/dcmi-terms/
[DWBP]: Data on the Web Best Practices. Bernadette Farias Loscio; Caroline Burle; Newton Calegari. W3C. 31 January 2017. W3C Recommendation. URL: https://www.w3.org/TR/dwbp/
[FOAF]: FOAF Vocabulary Specification 0.99 (Paddington Edition). Dan Brickley; Libby Miller. FOAF project. 14 January 2014. URL: http://xmlns.com/foaf/spec
[GeoSPARQL]: OGC GeoSPARQL - A Geographic Query Language for RDF Data. Nicholas J. Car; Timo Homburg; Matthew Perry; Frans Knibbe; Simon J.D. Cox; Joseph Abhayaratna; Mathias Bonduel; Paul J. Cripps; Krzysztof Janowicz. OGC. 29 January 2024. OGC Standard. URL: https://docs.ogc.org/is/22-047r1/22-047r1.html
[IANA-MEDIA-TYPES]: Media Types. IANA. URL: https://www.iana.org/assignments/media-types/
[LOCN]: ISA Programme Location Core Vocabulary. Andrea Perego; Michael Lutz. European Commission. 23 March 2015. Second version in w3.org/ns space. URL: http://www.w3.org/ns/locn
[ODRL-MODEL]: ODRL Information Model 2.2. Renato Iannella; Serena Villata. W3C. 15 February 2018. W3C Recommendation. URL: https://www.w3.org/TR/odrl-model/
[ODRL-VOCAB]: ODRL Vocabulary & Expression 2.2. Renato Iannella; Michael Steidl; Stuart Myles; Víctor Rodríguez-Doncel. W3C. 15 February 2018. W3C Recommendation. URL: https://www.w3.org/TR/odrl-vocab/
[OWL-TIME]: Time Ontology in OWL. Simon Cox; Chris Little. W3C. 15 November 2022. W3C Candidate Recommendation. URL: https://www.w3.org/TR/owl-time/
[OWL2-OVERVIEW]: OWL 2 Web Ontology Language Document Overview (Second Edition). W3C OWL Working Group. W3C. 11 December 2012. W3C Recommendation. URL: https://www.w3.org/TR/owl2-overview/
[OWL2-SYNTAX]: OWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax (Second Edition). Boris Motik; Peter Patel-Schneider; Bijan Parsia. W3C. 11 December 2012. W3C Recommendation. URL: https://www.w3.org/TR/owl2-syntax/
[PAV]: PAV - Provenance, Authoring and Versioning. Version 2.3.1. Paolo Ciccarese; Stian Soiland-Reyes. Mind Informatics. 16 March 2015. URL: https://pav-ontology.github.io/pav/
[PROV-O]: PROV-O: The PROV Ontology. Timothy Lebo; Satya Sahoo; Deborah McGuinness. W3C. 30 April 2013. W3C Recommendation. URL: https://www.w3.org/TR/prov-o/
[RDF-SCHEMA]: RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/
[RDF-SYNTAX-GRAMMAR]: RDF 1.1 XML Syntax. Fabien Gandon; Guus Schreiber. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-syntax-grammar/
[RFC2119]: Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[SKOS-REFERENCE]: SKOS Simple Knowledge Organization System Reference. Alistair Miles; Sean Bechhofer. W3C. 18 August 2009. W3C Recommendation. URL: https://www.w3.org/TR/skos-reference/
[SPDX]: SPDX 2.2. SPDX. URL: https://spdx.org/rdf/spdx-terms-v2.2/
[UNDERSTANDING-WCAG20]: Understanding WCAG 2.0. Michael Cooper; Andrew Kirkpatrick; Joshue O'Connor et al. W3C. 21 September 2023. W3C Working Group Note. URL: https://www.w3.org/TR/UNDERSTANDING-WCAG20/
[VCARD-RDF]: vCard Ontology - for describing People and Organizations. Renato Iannella; James McKinney. W3C. 22 May 2014. W3C Working Group Note. URL: https://www.w3.org/TR/vcard-rdf/
[VOCAB-ADMS]: Asset Description Metadata Schema (ADMS). Phil Archer; Gofran Shukair. W3C. 1 August 2013. W3C Working Group Note. URL: https://www.w3.org/TR/vocab-adms/
[VOCAB-DCAT]: Data Catalog Vocabulary (DCAT). Fadi Maali; John Erickson. W3C. 4 February 2020. W3C Recommendation. URL: https://www.w3.org/TR/vocab-dcat/
[XMLSCHEMA11-2]: W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. W3C. 5 April 2012. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema11-2/

[ADMS-SKOS]: Joinup. ADMS Controlled Vocabularies. European Commission. URL: https://web.archive.org/web/20210521035614/https://joinup.ec.europa.eu/svn/adms/ADMS_v1.00/ADMS_SKOS_v1.00.html
[ANNOTATION-VOCAB]: Web Annotation Vocabulary. Robert Sanderson; Paolo Ciccarese; Benjamin Young. W3C. 23 February 2017. W3C Recommendation. URL: https://www.w3.org/TR/annotation-vocab/
[BCP47]: Tags for Identifying Languages. A. Phillips, Ed.; M. Davis, Ed.. IETF. September 2009. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc5646
[CSW]: Catalogue Services 3.0 - General Model. Douglas Nebert; Uwe Voges; Lorenzo Bigagli. OGC. 10 June 2016. URL: http://www.opengeospatial.org/standards/cat
[DataCite]: DataCite Metadata Schema. DataCite Metadata Working Group. DataCite e.V. 22 January 2024. URL: https://schema.datacite.org/
[DATETIME]: Date and Time Formats. W3C. 27 August 1998. W3C Working Group Note. URL: https://www.w3.org/TR/NOTE-datetime
[DATS]: Data Tag Suite. Alejandra Gonzalez-Beltran; Philippe Rocca-Serra. NIH Big Data 2 Knowledge bioCADDIE and NIH Data Commons projects. 2016. URL: https://datatagsuite.github.io/docs/html/
[DBPEDIA-ONT]: DBPedia ontology. URL: http://dbpedia.org/ontology/
[DCAP]: Guidelines for Dublin Core Application Profiles. Karen Coyle; Thomas Baker. DCMI. 18 May 2009. DCMI Recommended Resource. URL: http://dublincore.org/documents/profile-guidelines/
[DCAT-AP]: DCAT Application Profile for data portals in Europe. Version 2.0.1. European Commission. 8 June 2020. URL: https://joinup.ec.europa.eu/solution/dcat-application-profile-data-portals-europe
[DCAT-AP-IT]: Profilo metadatazione DCAT-AP_IT. AgID & Team Digitale. URL: https://docs.italia.it/italia/daf/linee-guida-cataloghi-dati-dcat-ap-it/it/stabile/dcat-ap_it.html
[DCAT-AP-NO]: Standard for beskrivelse av datasett, datatjenester og datakataloger (DCAT-AP-NO). URL: https://data.norge.no/specification/dcat-ap-no/
[DCAT-AP-SE]: DCAT-AP-SE: Clarifications, translations and explanations of DCAT-AP for Sweden. Matthias Palmér. URL: https://docs.dataportal.se/dcat/en/
[DCAT-AP.de]: Vokabulare und Dokumente für DCAT-AP.de. URL: https://dcat-ap.de/def/
[DCAT-BE]: Linking data portals across Belgium.. URL: http://dcat.be/
[DCAT-UCR]: Dataset Exchange Use Cases and Requirements. Jaroslav Pullmann; Rob Atkinson; Antoine Isaac; Ixchel Faniel. W3C. 17 January 2019. W3C Working Group Note. URL: https://www.w3.org/TR/dcat-ucr/
[DOAP]: Description of a Project. Edd Wilder-James. URL: https://github.com/ewilderj/doap/wiki
[EARL10-Schema]: Evaluation and Report Language (EARL) 1.0 Schema. Shadi Abou-Zahra. W3C. 2 February 2017. W3C Working Group Note. URL: https://www.w3.org/TR/EARL10-Schema/
[EUV-AR]: Named Authority List: Access rights. Publications Office of the European Union. URL: https://publications.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/access-right
[EUV-CS]: Named Authority List: Concept statuses. Publications Office of the European Union. URL: https://publications.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/concept-status
[EUV-DS]: Named Authority List: Dataset statuses. Publications Office of the European Union. URL: https://publications.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/dataset-status
[FAIR]: The FAIR Guiding Principles for scientific data management and stewardship. Mark D. Wilkinson et al. Nature. Scientific Data, vol. 3, Article nr. 160018. URL: https://doi.org/10.1038/sdata.2016.18
[GeoDCAT-AP]: GeoDCAT-AP: A geospatial extension for the DCAT application profile for data portals in Europe. European Commission. 23 December 2020. URL: https://semiceu.github.io/GeoDCAT-AP/releases/
[GeoDCAT-AP-IT]: GeoDCAT-AP in Italy, the national guidelines published. URL: https://web.archive.org/web/20200506120557/https://joinup.ec.europa.eu/collection/semantic-interoperability-community-semic/news/geodcat-apit
[HCLS-Dataset]: Dataset Descriptions: HCLS Community Profile. Alasdair Gray; M. Scott Marshall; Michel Dumontier. W3C. 14 May 2015. W3C Working Group Note. URL: https://www.w3.org/TR/hcls-dataset/
[HTML-RDFa]: HTML+RDFa 1.1 - Second Edition. Manu Sporny. W3C. 17 March 2015. W3C Recommendation. URL: https://www.w3.org/TR/html-rdfa/
[HYDRA]: Hydra Core Vocabulary. Markus Lanthaler. Hydra W3C Community Group. 15 March 2018. Unofficial Draft. URL: https://www.hydra-cg.com/spec/latest/core/
[IANA-RELATIONS]: Link Relations. IANA. URL: https://www.iana.org/assignments/link-relations/
[IANA-URI-SCHEMES]: Uniform Resource Identifier (URI) Schemes. IANA. URL: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
[INSPIRE-DoC]: INSPIRE Registry: Degrees of conformity. European Commission. URL: http://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity/
[INSPIRE-SDST]: INSPIRE Registry: Spatial data service types. European Commission. URL: http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/
[ISO-19115]: Geographic information -- Metadata. ISO/TC 211. ISO. 2003. International Standard. URL: https://www.iso.org/standard/26020.html
[ISO-19115-1]: Geographic information -- Metadata -- Part 1: Fundamentals. ISO/TC 211. ISO. 2014. International Standard. URL: https://www.iso.org/standard/53798.html
[ISO-19128]: Geographic information -- Web map server interface. ISO/TC 211. ISO. 2005. International Standard. URL: https://www.iso.org/standard/32546.html
[ISO-19135]: Geographic information -- Procedures for item registration. ISO/TC 211. ISO. 2005. International Standard. URL: https://www.iso.org/standard/32553.html
[ISO-19142]: Geographic information -- Web Feature Service. ISO/TC 211. ISO. 2010. International Standard. URL: https://www.iso.org/standard/42136.html
[ISO-26324]: Information and documentation -- Digital object identifier system. ISO/TC 46/SC 9. ISO. 2012. International Standard. URL: https://www.iso.org/standard/43506.html
[ISO-IEC-25012]: ISO/IEC 25012 - Data Quality model. URL: http://iso25000.com/index.php/en/iso-25000-standards/iso-25012
[JSON-LD]: JSON-LD 1.0. Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. 3 November 2020. W3C Recommendation. URL: https://www.w3.org/TR/json-ld/
[LinkedDataPatterns]: Linked Data Patterns: A pattern catalogue for modelling, publishing, and consuming Linked Data. Leigh Dodds; Ian Davis. 31 May 2012. URL: http://patterns.dataincubator.org/book/
[N3]: Notation3 (N3): A readable RDF syntax. Tim Berners-Lee; Dan Connolly. W3C. 14 January 2008. W3C Team Submission. URL: https://www.w3.org/TeamSubmission/2008/SUBM-n3-20080114/
[netCDF]: Network Common Data Form (NetCDF). UNIDATA. URL: https://www.unidata.ucar.edu/software/netcdf/
[ODRS]: Open Data Rights Statement Vocabulary. Leigh Dodds. ODI. 29 July 2013. URL: http://schema.theodi.org/odrs
[OpenAPI]: OpenAPI Specification. Darrell Miller; Jason Harmon; Jeremy Whitlock; Marsh Gardiner; Mike Ralphson; Ron Ratovsky; Tony Tam; Uri Sarid. OpenAPI Initiative. URL: https://www.openapis.org/
[OpenSearch]: OpenSearch 1.1 Draft 6. DeWitt Clinton. OpenSearch. 17 April 2018. URL: https://github.com/dewitt/opensearch/blob/master/opensearch-1-1-draft-6.md
[RDF11-CONCEPTS]: RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
[RDF11-PRIMER]: RDF 1.1 Primer. Guus Schreiber; Yves Raimond. W3C. 24 June 2014. W3C Working Group Note. URL: https://www.w3.org/TR/rdf11-primer/
[RE3DATA-SCHEMA]: Metadata Schema for the Description of Research Data Repositories: version 3. Jessika Rücknagel et al. GFZ Potsdam. 17 December 2015. URL: https://doi.org/10.2312/re3.008
[RFC3986]: Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc3986
[RFC3987]: Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. January 2005. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc3987
[SCHEMA-ORG]: Schema.org. URL: https://schema.org/
[SDW-BP]: Spatial Data on the Web Best Practices. Payam Barnaghi; Jeremy Tandy; Linda van den Brink; Timo Homburg. W3C. 19 September 2023. W3C Working Group Note. URL: https://www.w3.org/TR/sdw-bp/
[SHACL]: Shapes Constraint Language (SHACL). Holger Knublauch; Dimitris Kontokostas. W3C. 20 July 2017. W3C Recommendation. URL: https://www.w3.org/TR/shacl/
[ShEx]: Shape Expressions Language 2.1. Shape Expressions W3C Community Group. 17 November 2018. Draft Community Group Report. URL: http://shex.io/shex-semantics/
[SPARQL11-PROTOCOL]: SPARQL 1.1 Protocol. Lee Feigenbaum; Gregory Williams; Kendall Clark; Elias Torres. W3C. 21 March 2013. W3C Recommendation. URL: https://www.w3.org/TR/sparql11-protocol/
[SPARQL11-QUERY]: SPARQL 1.1 Query Language. Steven Harris; Andy Seaborne. W3C. 21 March 2013. W3C Recommendation. URL: https://www.w3.org/TR/sparql11-query/
[SPARQL11-SERVICE-DESCRIPTION]: SPARQL 1.1 Service Description. Gregory Williams. W3C. 21 March 2013. W3C Recommendation. URL: https://www.w3.org/TR/sparql11-service-description/
[StatDCAT-AP]: StatDCAT-AP – DCAT Application Profile for description of statistical datasets. Version 1.0.1. European Commission. 28 May 2019. URL: https://joinup.ec.europa.eu/solution/statdcat-application-profile-data-portals-europe
[Turtle]: RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/turtle/
[UKGOVLD-REG]: Linked Data Registry - Principles and Concepts. UK Government Linked Data Working Group. URL: https://github.com/UKGovLD/registry-core/wiki/Principles-and-concepts
[VIVO-ISF]: VIVO-ISF Data Standard. URL: https://github.com/vivo-isf/vivo-isf
[VOCAB-DATA-CUBE]: The RDF Data Cube Vocabulary. Richard Cyganiak; Dave Reynolds. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/vocab-data-cube/
[VOCAB-DCAT-1]: Data Catalog Vocabulary (DCAT). Fadi Maali; John Erickson. W3C. 4 February 2020. W3C Recommendation. URL: https://www.w3.org/TR/vocab-dcat-1/
[VOCAB-DCAT-2]: Data Catalog Vocabulary (DCAT) - Version 2. Riccardo Albertoni; David Browning; Simon Cox; Alejandra Gonzalez Beltran; Andrea Perego; Peter Winstanley. W3C. 4 February 2020. W3C Recommendation. URL: https://www.w3.org/TR/vocab-dcat-2/
[VOCAB-DCAT-2-20200204]: Data Catalog Vocabulary (DCAT) - Version 2. Riccardo Albertoni; David Browning; Simon Cox; Alejandra Gonzalez Beltran; Andrea Perego; Peter Winstanley. W3C. 4 February 2020. W3C Recommendation. URL: https://www.w3.org/TR/2020/REC-vocab-dcat-2-20200204/
[VOCAB-DCAT-3-20201217]: Data Catalog Vocabulary (DCAT) - Version 3. Riccardo Albertoni; David Browning; Simon Cox; Alejandra Gonzalez Beltran; Andrea Perego; Peter Winstanley. W3C. 17 December 2020. W3C Working Draft. URL: https://www.w3.org/TR/2020/WD-vocab-dcat-3-20201217/
[VOCAB-DCAT-3-20210504]: Data Catalog Vocabulary (DCAT) - Version 3. Riccardo Albertoni; David Browning; Simon Cox; Alejandra Gonzalez Beltran; Andrea Perego; Peter Winstanley. W3C. 4 May 2021. W3C Working Draft. URL: https://www.w3.org/TR/2021/WD-vocab-dcat-3-20210504/
[VOCAB-DCAT-3-20220111]: Data Catalog Vocabulary (DCAT) - Version 3. Riccardo Albertoni; David Browning; Simon Cox; Alejandra Gonzalez Beltran; Andrea Perego; Peter Winstanley. W3C. 11 January 2022. W3C Working Draft. URL: https://www.w3.org/TR/2022/WD-vocab-dcat-3-20220111/
[VOCAB-DCAT-3-20220510]: Data Catalog Vocabulary (DCAT) - Version 3. Riccardo Albertoni; David Browning; Simon Cox; Alejandra Gonzalez Beltran; Andrea Perego; Peter Winstanley. W3C. 10 May 2022. W3C Working Draft. URL: https://www.w3.org/TR/2022/WD-vocab-dcat-3-20220510/
[VOCAB-DCAT-3-20240118]: Data Catalog Vocabulary (DCAT) - Version 3. Simon Cox; Andrea Perego; Alejandra Gonzalez Beltran; Peter Winstanley; Riccardo Albertoni; David Browning. W3C. 18 January 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/2024/CR-vocab-dcat-3-20240118/
[VOCAB-DQV]: Data on the Web Best Practices: Data Quality Vocabulary. Riccardo Albertoni; Antoine Isaac. W3C. 15 December 2016. W3C Working Group Note. URL: https://www.w3.org/TR/vocab-dqv/
[VOCAB-ORG]: The Organization Ontology. Dave Reynolds. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/vocab-org/
[VOCAB-SSN]: Semantic Sensor Network Ontology. Armin Haller; Krzysztof Janowicz; Simon Cox; Danh Le Phuoc; Kerry Taylor; Maxime Lefrançois. W3C. 19 October 2017. W3C Recommendation. URL: https://www.w3.org/TR/vocab-ssn/
[VOID]: Describing Linked Datasets with the VoID Vocabulary. Keith Alexander; Richard Cyganiak; Michael Hausenblas; Jun Zhao. W3C. 3 March 2011. W3C Working Group Note. URL: https://www.w3.org/TR/void/
[W3C-BASIC-GEO]: Basic Geo (WGS84 lat/long) Vocabulary. Dan Brickley. W3C Semantic Web Interest Group. 1 February 2006. URL: https://www.w3.org/2003/01/geo/
[WFS]: Web Feature Service 2.0 Interface Standard. Panagiotis (Peter) A. Vretanos. OGC. 10 July 2014. OGC Interface Standard. URL: http://www.opengeospatial.org/standards/wfs
[WMS]: Web Map Service Implementation Specification. Jeff de la Beaujardiere. OGC. 15 March 2006. OpenGIS Implementation Standard. URL: http://www.opengeospatial.org/standards/wms
[WSDL20]: Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. Roberto Chinnici; Jean-Jacques Moreau; Arthur Ryman; Sanjiva Weerawarana et al. W3C. 26 June 2007. W3C Recommendation. URL: https://www.w3.org/TR/wsdl20/
[XHTML-VOCAB]: XHTML Vocabulary. XHTML 2 Working Group. W3C. 27 October 2010. URL: https://www.w3.org/1999/xhtml/vocab
[ZaveriEtAl]: Quality assessment for Linked Data: A Survey. Amrapali Zaveri et al. IOS Press. 2015. Semantic Web, vol. 7, no. 1, pp. 63-93. URL: https://doi.org/10.3233/SW-150175

DCAT element	Target element from schema.org
dcat:Resource	sdo:Thing
dcterms:title	sdo:name
dcterms:description	sdo:description
dcat:keyword dcat:keyword is singular, sdo:keywords is plural	sdo:keywords
dcat:theme	sdo:about
dcterms:identifier	sdo:identifier
dcterms:type	sdo:additionalType
dcterms:issued	sdo:datePublished
dcterms:modified	sdo:dateModified
dcterms:language	sdo:inLanguage
dcterms:relation	sdo:isRelatedTo
dcat:landingPage	sdo:url
dcterms:publisher	sdo:publisher
dcat:contactPoint	sdo:contactPoint
dcat:version	sdo:version
dcat:Catalog	sdo:DataCatalog
dcterms:hasPart	sdo:hasPart
dcat:dataset	sdo:dataset
dcat:distribution	sdo:distribution
dcat:Dataset	sdo:Dataset
dcat:Dataset dcterms:accrualPeriodicity fixed to <http://purl.org/cld/freq/continuous>	sdo:DataFeed
dcterms:spatial	sdo:spatialCoverage
dcterms:temporal	sdo:temporalCoverage
dcterms:accrualPeriodicity	sdo:repeatFrequency
prov:wasGeneratedBy	[ owl:inverseOf sdo:result ]
dcat:inSeries	sdo:isPartOf
dcat:DatasetSeries	sdo:CreativeWorkSeries
dcat:Distribution	sdo:DataDownload
dcterms:format	sdo:encodingFormat
dcat:mediaType	sdo:encodingFormat
dcat:byteSize	sdo:contentSize
dcat:accessURL	sdo:contentUrl
dcat:downloadURL	sdo:contentUrl
dcterms:license	sdo:license
dcat:DataService	sdo:WebAPI
dcat:endpointURL	sdo:url
dcat:endpointDescription	sdo:documentation, sdo:hasOfferCatalog
dcterms:type in context of a dcat:DataService	sdo:serviceType
dcat:servesDataset	sdo:serviceOutput
dcat:Relationship	sdo:Role

Data Catalog Vocabulary (DCAT) - Version 3

Abstract

Status of This Document

DCAT history

External terms

Please send comments

1. Introduction

2. Motivation for change

3. Namespaces

3.1 Normative namespaces

3.2 Non-normative namespaces

4. Conformance

5. Vocabulary overview

5.1 DCAT scope

5.2 RDF considerations

5.3 Basic example

5.4 Classifying datasets thematically

5.5 Classifying dataset types

5.6 Describing catalog records metadata

5.7 Dataset available only behind some Web page

5.8 A dataset available as a download and behind some Web page

5.9 A dataset available through a service

6. Vocabulary specification

6.1 RDF representation

6.2 Elements from other vocabularies

6.2.1 Complementary vocabularies

6.2.2 Element definitions

6.3 Class: Catalog

6.3.1 Property: homepage

6.3.2 Property: themes

6.3.3 Property: resource

6.3.4 Property: dataset

6.3.5 Property: service

6.3.6 Property: catalog

6.3.7 Property: catalog record

6.4 Class: Cataloged Resource

6.4.1 Property: access rights

6.4.2 Property: conforms to

6.4.3 Property: contact point

6.4.4 Property: creator

6.4.5 Property: description

6.4.6 Property: title

6.4.7 Property: release date

6.4.8 Property: update/modification date

6.4.9 Property: language

6.4.10 Property: publisher

6.4.11 Property: identifier

6.4.12 Property: theme/category

6.4.13 Property: type/genre

6.4.14 Property: relation

6.4.15 Property: qualified relation

6.4.16 Property: keyword/tag

6.4.17 Property: landing page

6.4.18 Property: qualified attribution

6.4.19 Property: license

6.4.20 Property: rights

6.4.21 Property: has part

6.4.22 Property: has policy

6.4.23 Property: is referenced by

6.4.24 Property: previous version

6.4.25 Property: has version

6.4.26 Property: current version

6.4.27 Property: replaces

6.4.28 Property: version

6.4.29 Property: version notes

6.4.30 Property: status

6.4.31 Property: first

6.4.32 Property: last

6.4.33 Property: previous

6.5 Class: Catalog Record

6.5.1 Property: title

6.5.2 Property: description

6.5.3 Property: listing date

6.5.4 Property: update/modification date

6.5.5 Property: primary topic

6.5.6 Property: conforms to

6.6 Class: Dataset

6.6.1 Property: distribution

6.6.2 Property: frequency

6.6.3 Property: in series