Data Catalog Vocabulary (DCAT) - Version 3

Data Catalog Vocabulary (DCAT) - Version 3
Data Catalog Vocabulary (DCAT) - Version 3
W3C Recommendation
22 August 2024
More details about this document
This version:
Latest published version:
Latest editor's draft:
History:
Commit history
Implementation report:
Previous Recommendation:
Editors:
Riccardo Albertoni
Invited Expert / CNR - Consiglio Nazionale delle Ricerche, Italy
David Browning
Invited Expert
) (Previously at Refinitiv.com)
Simon J D Cox
Invited Expert
) (Previously at CSIRO)
Alejandra Gonzalez Beltran
Invited Expert / Scientific Computing Department, Science and Technology Facilities Council, UK
) (Previously at the University of Oxford)
Andrea Perego
Invited Expert
Peter Winstanley
Invited Expert
Former editors:
Fadi Maali
DERI
John Erickson
Tetherless World Constellation (RPI)
Feedback:
GitHub w3c/dxwg
pull requests
new issue
open issues
public-dxwg-comments@w3.org
with subject line
[vocab-dcat-3]
… message topic …
archives
Errata:
Errata exists
Contributors
Makx Dekkers
See also
translations
This document is also available in these non-normative formats:
Turtle
RDF/XML
, and
JSON-LD
2024
World Wide Web Consortium
W3C
liability
trademark
and
permissive document license
rules apply.
Note
Abstract
DCAT is an RDF vocabulary designed to facilitate interoperability between data catalogs published on the Web.
This document defines the schema and provides examples for its use.
DCAT enables a publisher to describe datasets and data services in a catalog using a standard model and vocabulary that facilitates the consumption and aggregation of metadata from multiple catalogs.
This can increase the discoverability of datasets and data services.
It also makes it possible to have a decentralized approach to publishing data catalogs and makes federated search for datasets across catalogs in multiple sites possible using the same query mechanism and structure.
Aggregated DCAT metadata can serve as a manifest file as part of the digital preservation process.
The namespace for DCAT terms is
The suggested prefix for the DCAT namespace is
dcat
Status of This Document
This section describes the status of this
document at the time of its publication. A list of current
W3C
publications and the latest revision of this technical report can be found
in the
W3C
technical reports index
at
This document defines a major revision of the DCAT 2 vocabulary ([
VOCAB-DCAT-2
]) in response to use cases, requirements and community experience which could not be considered during the previous vocabulary development. This revision extends the DCAT standard in line with community practice while supporting diverse approaches to data description and dataset exchange. The main changes to the DCAT vocabulary have been:
addition of
spdx:checksum
property and
spdx:Checksum
class to provide digest for DCAT distributions
addition of properties for supporting versioning, e.g.,
dcat:version
dcat:previousVersion
dcat:hasCurrentVersion
, see
11.
Versioning
addition of a
dcat:DatasetSeries
class and properties for representing Dataset Series, see
12.
Dataset series
This new version of the vocabulary updates and expands the original but preserves backward compatibility. A full list of the significant changes (with links to the relevant GitHub issues) is described in
D.
Change history
Issues, requirements, and features
that have been considered and discussed by the Data eXchange Working Group but have not been addressed due to lack of maturity or consensus are collected in GitHub. Those believed to be a priority for a future release are in the milestone
DCAT Future Priority Work
DCAT history
The original DCAT vocabulary was developed and hosted at the
Digital Enterprise Research Institute (DERI)
, then refined by the
eGov Interest Group
, and finally standardized in 2014 [
VOCAB-DCAT-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
External terms
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.
Please send comments
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.
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
1.
Introduction
This section is non-normative.
Sharing data resources among different organizations, researchers, governments and citizens requires the provision of metadata.
This is irrespective of the data being open or not.
DCAT is a vocabulary for publishing data catalogs on the Web, which was originally developed in the context of government data catalogs
such as
data.gov
and
data.gov.uk
, but it is also applicable and has been used in other contexts.
DCAT 3 has extended the previous version to support further use cases and requirements [
DCAT-UCR
].
These include the possibility of cataloging other resources in addition to
datasets, such as dataset series. The revision also supports describing versioning of resources. Guidance on how to use inverse properties is provided.
DCAT provides RDF classes and properties to allow datasets and data services to be described and included in a catalog.
The use of a standard model and vocabulary facilitates the consumption and aggregation of metadata from multiple catalogs, which can:
increase the discoverability of datasets and data services
allow federated search for datasets across catalogs in multiple sites
Data described in a catalog can come in many formats, ranging from spreadsheets, through XML and RDF to various specialized formats.
DCAT does not make any assumptions about these serialization formats of the datasets but it does
distinguish between the abstract dataset and its different manifestations or distributions.
Data is often provided through a service which supports selection of an extract, sub-set, or combination of existing data, or of new data generated by some data processing function.
DCAT allows the description of a data access service to be included in a catalog.
Complementary vocabularies can be used together with DCAT to provide more detailed format-specific information.
For example, properties from the VoID vocabulary [
VOID
] can be used within DCAT to express various statistics about a dataset if that dataset is in RDF format.
This document does not prescribe any particular method of deploying data catalogs expressed in DCAT.
DCAT information can be presented in many forms including RDF accessible via SPARQL endpoints, embedded in HTML pages as [
HTML-RDFa
], or serialized as RDF/XML [
RDF-SYNTAX-GRAMMAR
], [
N3
], [
Turtle
], [
JSON-LD
] or other formats.
Within this document the examples use [
Turtle
] because of its readability.
2.
Motivation for change
This section is non-normative.
The original Recommendation [
VOCAB-DCAT-1
] published in January 2014 provided the basic framework for describing datasets. It made an important distinction between a
dataset
as an abstract idea and a
distribution
as a manifestation of the dataset. Although DCAT has been widely adopted, it has become clear that the original specification lacked a number of essential features that were added either through the mechanism of a profile, such as the European Commission's DCAT-AP [
DCAT-AP
], or the development of larger vocabularies that to a greater or lesser extent built upon the base standard, such as the Healthcare and Life Sciences Community Profile [
HCLS-Dataset
], the Data Tag Suite [
DATS
] and more. DCAT 2 [
VOCAB-DCAT-2
] was developed to address the specific shortcomings that have come to light through the experiences of different communities, the aim being to improve interoperability between the outputs of these larger vocabularies.
For example, DCAT 2 provided classes, properties and guidance to address
identifiers
dataset quality information
, and
data citation
issues.
This revision, DCAT 3, updates the specification throughout. Significant changes from the 2014 Recommendation and DCAT 2 are marked within the text using "Note" sections, as well as being described in
D.
Change history
3.
Namespaces
The namespace for DCAT is
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.
3.1
Normative namespaces
Namespaces and prefixes used in normative parts of this recommendation are shown in the following table.
Prefix
Namespace
IRI
Source
adms
VOCAB-ADMS
dc
DCTERMS
dcat
VOCAB-DCAT
dcterms
DCTERMS
dctype
DCTERMS
foaf
FOAF
locn
LOCN
odrl
ODRL-VOCAB
owl
OWL2-SYNTAX
prov
PROV-O
rdf
RDF-SYNTAX-GRAMMAR
rdfs
RDF-SCHEMA
skos
SKOS-REFERENCE
spdx
SPDX
time
OWL-TIME
vcard
VCARD-RDF
xsd
XMLSCHEMA11-2
3.2
Non-normative namespaces
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
VOCAB-DQV
earl
EARL10-Schema
geosparql
GeoSPARQL
oa
ANNOTATION-VOCAB
pav
PAV
sdmx-attribute
VOCAB-DATA-CUBE
sdo
SCHEMA-ORG
xhv
XHTML-VOCAB
4.
Conformance
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.
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
5.
Vocabulary overview
This section is non-normative.
5.1
DCAT scope
DCAT is an RDF vocabulary for representing data catalogs.
DCAT is based around seven main classes (
Figure
):
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.
Figure
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
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
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.
5.2
RDF considerations
The DCAT vocabulary is an OWL2 ontology [
OWL2-OVERVIEW
] formalized using [
RDF-SCHEMA
].
Each class and property in DCAT is denoted by an
IRI
RFC3987
].
Locally defined elements are in the namespace
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
5.3
Basic example
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:
The publisher of the catalog has the relative
IRI
ex:transparency-office
. Further description of the publisher can be provided as in
Example
The catalog lists each of its datasets via the
dcat:dataset
property. In
Example
, an example dataset was mentioned with the relative
IRI
ex:dataset-001
. A possible description of it using DCAT is shown below:
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
5.4
Classifying datasets thematically
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:
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:
5.5
Classifying dataset types
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.
It is also possible for multiple classifications to be present in a single description.
5.6
Describing catalog records metadata
If the catalog publisher decides to keep metadata
describing its records (i.e., the records containing metadata
describing the datasets),
dcat:CatalogRecord
can be used. For example,
while
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
5.7
Dataset available only behind some Web page
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.
Notice the use of a
dcat:landingPage
and the definition of the
dcat:Distribution
instance.
5.8
A dataset available as a download and behind some Web page
On the other hand,
ex:dataset-003
can be obtained through some landing page but also can be downloaded from a known URL.
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.
5.9
A dataset available through a service
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
6.
Vocabulary specification
6.1
RDF representation
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
6.2
Elements from other vocabularies
DCAT requires use of elements from a number of other vocabularies.
Furthermore, DCAT may be augmented by additional elements from external vocabularies, following the usual RDFS [
RDF-SCHEMA
] and OWL2 [
OWL2-OVERVIEW
] rules and patterns.
6.2.1
Complementary vocabularies
Elements from a number of complementary vocabularies
MAY
be used together with DCAT to provide more detailed information.
For example: properties from the VoID vocabulary [
VOID
] allow the description of various statistics about a DCAT-described dataset if that dataset is in RDF format; properties from the Provenance ontology [
PROV-O
] can be used to provide more information about the workflow that generated a dataset or service and related activities and agents; classes and properties from the Organization Ontology [
VOCAB-ORG
] can be used to explain additional details of responsible agents.
6.2.2
Element definitions
The definitions (including domain and range) of terms outside the DCAT namespace are provided here only for convenience and
MUST NOT
be considered normative. The authoritative definitions of these terms are in the corresponding specifications, i.e., [
DC11
], [
DCTERMS
], [
FOAF
], [
PROV-O
], [
RDF-SCHEMA
], [
SKOS-REFERENCE
], [
XMLSCHEMA11-2
] and [
VCARD-RDF
].
6.3
Class: Catalog
Note
The following properties are specific to this class:
catalog record
resource
dataset
service
catalog
homepage
themes
The following properties of the super-class
dcat:Dataset
are also available for use:
distribution
frequency
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:
access rights
conforms to
contact point
creator
description
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: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
6.3.1
Property: homepage
RDF Property:
foaf:homepage
Definition:
A homepage of the catalog (a public Web document usually available in HTML).
Range:
foaf:Document
Usage note:
foaf:homepage
is an inverse functional property (IFP) which means that it
MUST
be unique and precisely identify the Web-page for the resource. This property indicates the canonical Web-page, which might be helpful in cases where there is more than one Web-page about the resource.
6.3.2
Property: themes
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.
6.3.3
Property: resource
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
6.3.4
Property: dataset
RDF Property:
dcat:dataset
Definition:
A dataset that is listed in the catalog.
Sub-property of:
dcat:resource
Domain:
dcat:Catalog
Range:
dcat:Dataset
6.3.5
Property: service
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
6.3.6
Property: catalog
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
6.3.7
Property: catalog record
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
6.4
Class: Cataloged Resource
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
6.4.1
Property: access rights
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
6.4.2
Property: conforms to
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
6.4.3
Property: contact point
Note
RDF Property:
dcat:contactPoint
Definition:
Relevant contact information for the cataloged resource. Use of vCard is recommended [
VCARD-RDF
].
Range:
vcard:Kind
6.4.4
Property: creator
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
6.4.5
Property: description
RDF Property:
dcterms:description
Definition:
A free-text account of the resource.
Range:
rdfs:Literal
6.4.6
Property: title
RDF Property:
dcterms:title
Definition:
A name given to the resource.
Range:
rdfs:Literal
6.4.7
Property: release date
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
6.4.8
Property: update/modification 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
6.4.9
Property: language
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
6.4.10
Property: publisher
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
6.4.11
Property: identifier
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.
6.4.12
Property: theme/category
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
6.4.13
Property: type/genre
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.
6.4.14
Property: relation
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.
6.4.15
Property: qualified relation
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
6.4.16
Property: keyword/tag
Note
RDF Property:
dcat:keyword
Definition:
A keyword or tag describing the resource.
Range:
rdfs:Literal
6.4.17
Property: landing page
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
6.4.18
Property: qualified attribution
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
6.4.19
Property: license
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
6.4.20
Property: rights
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
6.4.21
Property: has part
Note
RDF Property:
dcterms:hasPart
Definition:
A related resource that is included either physically or logically in the described resource.
6.4.22
Property: has policy
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
6.4.23
Property: is referenced by
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
6.4.24
Property: previous version
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
6.4.25
Property: has version
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
6.4.26
Property: current version
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
6.4.27
Property: replaces
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
6.4.28
Property: version
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
6.4.29
Property: version notes
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
6.4.30
Property: status
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
6.4.31
Property: first
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
6.4.32
Property: last
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
6.4.33
Property: previous
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
6.5
Class: Catalog Record
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
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:Distribution
s)
into a separate named graph. The name of that graph
SHOULD
be the
IRI
of the catalog record.
6.5.1
Property: title
RDF Property:
dcterms:title
Definition:
A name given to the record.
Range:
rdfs:Literal
6.5.2
Property: description
RDF Property:
dcterms:description
Definition:
A free-text account of the record.
Range:
rdfs:Literal
6.5.3
Property: listing date
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
6.5.4
Property: update/modification 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
6.5.5
Property: primary topic
RDF Property:
foaf:primaryTopic
Definition:
The
dcat:Resource
(dataset or service) described in the record.
Usage note:
foaf:primaryTopic
property is functional:
each catalog record can have at most one primary topic, i.e., describes one cataloged resource.
6.5.6
Property: conforms to
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
6.6
Class: Dataset
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:
access rights
conforms to
contact point
creator
description
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
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.
6.6.1
Property: distribution
RDF Property:
dcat:distribution
Definition:
An available distribution of the dataset.
Sub-property of:
dcterms:relation
Domain:
dcat:Dataset
Range:
dcat:Distribution
6.6.2
Property: frequency
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
6.6.3
Property: in series
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
6.6.4
Property: spatial/geographical coverage
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
6.6.5
Property: spatial resolution
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
6.6.6
Property: temporal coverage
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
6.6.7
Property: temporal resolution
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
6.6.8
Property: was generated by
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.
6.7
Class: Dataset Series
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
6.8
Class: Distribution
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
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
and described in the definitions below.
6.8.1
Property: title
RDF Property:
dcterms:title
Definition:
A name given to the distribution.
Range:
rdfs:Literal
6.8.2
Property: description
RDF Property:
dcterms:description
Definition:
A free-text account of the distribution.
Range:
rdfs:Literal
6.8.3
Property: release date
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
6.8.4
Property: update/modification 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
6.8.5
Property: license
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
6.8.6
Property: access rights
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
6.8.7
Property: 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
6.8.8
Property: has policy
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
6.8.9
Property: access URL
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.
6.8.10
Property: access service
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
6.8.11
Property: download 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
6.8.12
Property: byte size
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.
6.8.13
Property: spatial resolution
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
].
6.8.14
Property: temporal resolution
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
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
].
6.8.15
Property: conforms to
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
6.8.16
Property: media type
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
6.8.17
Property: format
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
6.8.18
Property: compression format
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
6.8.19
Property: packaging format
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
6.8.20
Property: checksum
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.
6.9
Class: Data Service
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:
access rights
conforms to
contact point
creator
description
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: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
6.9.1
Property: endpoint URL
RDF Property:
dcat:endpointURL
Definition:
The root location or primary endpoint of the service (a Web-resolvable
IRI
).
Domain:
dcat:DataService
Range:
rdfs:Resource
6.9.2
Property: endpoint description
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.
6.9.3
Property: serves dataset
RDF Property:
dcat:servesDataset
Definition:
A collection of data that this data service can distribute.
Range:
dcat:Dataset
6.10
Class: Concept Scheme
RDF Class:
skos:ConceptScheme
Definition:
A knowledge organization system (KOS) used to represent themes/categories of datasets in the catalog.
See also:
6.3.2
Property: themes
6.4.12
Property: theme/category
6.11
Class: Concept
RDF Class:
skos:Concept
Definition:
A category or a theme used to describe datasets in the catalog.
Usage note:
It is recommended to use either
skos:inScheme
or
skos:topConceptOf
on every
skos:Concept
used to classify datasets to link it to the concept scheme it belongs to. This concept scheme is typically associated with the catalog using
dcat:themeTaxonomy
See also:
6.3.2
Property: themes
6.4.12
Property: theme/category
6.12
Class: Organization/Person
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.
6.13
Class: Relationship
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
6.13.1
Property: relation
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.
6.13.2
Property: had role
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.
6.14
Class: Role
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.
6.15
Class: Period of Time
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.
6.15.1
Property: start date
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
).
6.15.2
Property: end date
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
6.15.3
Property: beginning
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
6.15.4
Property: end
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
6.16
Class: Location
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.
6.16.1
Property: geometry
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
].
6.16.2
Property: bounding box
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
6.16.3
Property: centroid
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
6.17
Class: Checksum
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.
6.17.1
Property: algorithm
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
6.17.2
Property: checksum value
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
7.
Use of inverse properties
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
8.
Dereferenceable identifiers
This section is non-normative.
The scientific and data provider communities use a number of different identifiers for publications, authors and data. DCAT primarily relies on persistent HTTP
IRIs
as an effective way of making identifiers actionable. Notably, quite a few identifier schemes can be encoded as dereferenceable HTTP
IRIs
, and some of them are also returning machine-readable metadata (e.g.,
DOIs
ISO-26324
] and
ORCIDs
). Regardless, data providers still might need to refer to legacy identifiers, non-HTTP dereferenceable identifiers, locally minted or third-party-provided identifiers. In these cases, [
DCTERMS
] and [
VOCAB-ADMS
] can be of use.
The property
dcterms:identifier
explicitly indicates HTTP
IRIs
as well as legacy identifiers. In the following examples,
dcterms:identifier
identifies a dataset, but it can similarly be used with any kind of resources.
Proxy dereferenceable
IRIs
can be used when resources do not have HTTP dereferenceable IDs. For example, in
Example
14
dcat.example.org/proxyid
is a proxy for
id
The property
adms:identifier
VOCAB-ADMS
] can express other locally minted identifiers or external identifiers, like DOI,
ELI
arΧiv
for creative works and
ORCID
VIAF
ISNI
for actors such as authors and publishers, as long as the identifiers are globally unique and stable.
Example
15
uses
adms:schemaAgency
and
dcterms:creator
to represent the authority that defines the identifier scheme (e.g., the
DOI foundation
in the example),
adms:schemaAgency
is used when the authority has no
IRI
associated. The
CrossRef
and
DataCite
display guidelines recommend displaying
DOIs
as full URL link in the form
Example
15
does not represent the authority responsible for assigning and maintaining identifiers using that scheme (e.g.,
Zenodo
) as naming the registrant goes against the philosophy of DOI, where the sub-spaces are abstracted from the organization that registers them, with the advantage that
DOIs
do not change when the organization changes or the responsibility for that sub-space is handed over to someone else.
Example
15
shows a locally minted identifier for the creator of the dataset (e.g.,
) and its correspondent ORCID identifier (e.g.,
).
When the HTTP dereferenceable ID returns an RDF/OWL description for the dataset, the use of
owl:sameAs
might be considered. For example,
when dereferenced with media type
text/turtle
returns a [
SCHEMA-ORG
] description for the dataset, which might dynamically enrich the description provided by
Note
The need to distinguish between primary and alternative (or legacy) identifiers for a dataset within DCAT has been posed as a requirement. However, it is very much application-specific and would be better addressed in DCAT profiles rather than mandating a general approach.
Depending on the application context, specific guidelines such as
"DCAT-AP: How to manage duplicates?"
can be adopted for distinguishing authoritative datasets from dataset harvested by third parties catalogs.
8.1
Indicating common identifier types
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
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
Otherwise, examples of common types for identifier scheme (
arXiv
, etc.) are defined in
DataCite schema
DataCite
] and
FAIRsharing Registry
9.
License and rights statements
This section is non-normative.
Selecting the right way to express conditions for access to and re-use of resources can be complex.
Implementers should always seek legal advice before deciding which conditions apply to the resource being described.
This specification distinguishes three main situations:
one where a statement is associated with a resource that is explicitly declared as a 'license';
a second, where the statement is associated with a resource denoting only access rights;
a third, covering all the other cases - i.e., statements not concerning licensing conditions and/or access rights (e.g., copyright statements).
Note
To address these scenarios, it is recommended to use the property
dcterms:rights
, and its sub-properties
dcterms:license
and
dcterms:accessRights
. More precisely:
use
dcterms:license
to refer to licenses;
Note
use
dcterms:accessRights
to express statements concerning only access rights (e.g., whether data can be accessed by anyone or just by authorized parties);
Note
use
dcterms:rights
for all the other types of rights statements - those which are not covered by
dcterms:license
and
dcterms:accessRights
, such as copyright statements.
Note
Finally, in the particular case when rights are expressed via
ODRL
policies
, it is recommended to use the
odrl:hasPolicy
property as the link from the description of the cataloged resource or distribution to the
ODRL
policy.
Note
10.
Time and space
This section is non-normative.
10.1
Temporal properties
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.
10.2
Spatial properties
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
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
11.
Versioning
This section is non-normative.
The notion of
version
is often used as a generic term to denote some kind of relationship between a resource and a derived one. Examples, among others, include revisions, editions, adaptations, and translations.
This section focuses specifically on how to use DCAT to describe versions resulting from a revision - i.e., from changes occurring to a resource as part of its life-cycle.
For this purpose, DCAT builds upon existing vocabularies, in particular the versioning component of the [
PAV
] ontology, and the relevant terms from [
DCTERMS
], [
OWL2-OVERVIEW
], and [
VOCAB-ADMS
].
It is important to note that versioning can be applied to any of the first class citizens DCAT resources, including Catalogs, Catalog Records, Datasets, Distributions.
Note also that the DCAT approach described in the following sections is meant to be complementary with those already used in specific types of resources (e.g., [
OWL2-OVERVIEW
] provides a set of versioning properties for ontologies), as well as in given domains and communities. For a comparison between the DCAT versioning approach and those of other vocabularies, see
11.4
Complementary approaches to versioning
Note
11.1
Relationships between versions
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.
11.1.1
Version chains and hierarchies
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.
11.1.2
Versions replaced by other ones
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.
11.2
Version information
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.
11.3
Resource life-cycle
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
11.4
Complementary approaches to versioning
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
].
12.
Dataset series
This section is non-normative.
With "dataset series" we refer to data, somehow interrelated, that are published separately. An example is budget data split by year and/or country, instead of being made available in a single dataset.
Dataset series are defined in [
ISO-19115
] as a
collection of datasets […] sharing common characteristics
. However, their use is not limited to geospatial data, although in other domains they can be named differently (e.g., time series, data slices) and defined more or less strictly (see, e.g., the notion of "dataset slice" in [
VOCAB-DATA-CUBE
]).
The reasons and criteria for grouping datasets into series are manyfold, and they may be related to, e.g., data characteristics, publishing process, and how they are typically used. For instance, data huge in size (as geospatial ones) are more easily handled (by data providers as well as data consumers) by splitting them into smaller ones. Another example is data released on a yearly basis, which are typically published as separate datasets, instead of appending the new data to the first in the series.
As there are no common rules and criteria across domains to decide when dataset series should be created and how they should be organized, DCAT does not prescribe any specific approach, and refer for guidance and domain- and community practices. The purpose of this section is limited to providing guidance on how dataset series can be specified in DCAT.
12.1
How to specify dataset series
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.
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
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
12.2
Dataset series metadata
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
12.3
Dataset series in existing DCAT implementations
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.
13.
Data citation
This section is non-normative.
Dataset citation
is one of the requirements identified.
Data citation is the practice of referencing data in a similar way as when providing bibliographic references, acknowledging data
as a first class output in any investigative process. Data citation offers multiple benefits, such as supporting proper attribution
and credit to those producing the data, facilitating data discovery, supporting tracking the impact and reuse of data, allowing for
collaboration and re-use of data, and enabling the reproducibility of results based on the data.
To support data citation, the dataset description should include at a minimum: the dataset identifier, the dataset creator(s), the dataset title,
the dataset publisher and the dataset publication or release date. These elements are those required by the DataCite metadata schema [
DataCite
],
which is the metadata associated by the persistent identifiers (Digital Object Identifiers or
DOIs
) assigned by [
DataCite
] to research data.
In order to support data citation, DCAT 2 added the consideration of
dereferenceable identifiers
and support for indicating
the creators of the cataloged resources
. The remaining properties necessary for data citation were already available in DCAT 1 [
VOCAB-DCAT-1
].
The constraints on the availability of properties required for data citation in the dataset description can be represented as a DCAT data citation profile.
14.
Quality information
This section is non-normative.
Note
The Data Quality Vocabulary (DQV) [
VOCAB-DQV
] offers common modeling patterns for different aspects of Data
Quality.
It can relate DCAT datasets and distributions with different types of quality information including:
dqv:QualityAnnotation
, which represents feedback and quality certificates given about the dataset or its distribution.
dqv:QualityPolicy
, which represents a policy or agreement that is chiefly governed by data quality concerns.
dqv:QualityMeasurement
, which represents a metric value providing quantitative or qualitative information about the dataset or distribution.
Each type of quality information can pertain to one or more quality dimensions, namely, quality characteristics relevant
to the consumer. The practice to see the quality as a multi-dimensional space is consolidated in the field of quality
management to split the quality management into addressable chunks. DQV does not define a normative list of quality
dimensions. It offers the quality dimensions proposed in
ISO
/IEC 25012 [
ISO-IEC-25012
] and [
ZaveriEtAl
as two possible starting points. It also provides an
RDF representation
for the quality dimensions and categories defined in the latter. Ultimately, implementers will need to choose themselves
the collection of quality dimensions that best fits their needs.
The following section shows how DCAT and DQV can be coupled to describe the quality of datasets and distributions.
For a comprehensive introduction and further examples of use, please refer to [
VOCAB-DQV
].
Note
14.1
Providing quality information
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.
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
Other examples of quality documentation are available in [
VOCAB-DQV
], including examples about
how to express dataset accuracy and precision
14.2
Documenting conformance to standards
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.
14.2.1
Conformance to a standard
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"
).
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:
In
Example
44
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
, and not
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
and
Example
45
extends
Example
to show how to specify that a given catalog record is conformant with DCAT, by following the above rules.
14.2.2
Degree of conformance
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
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
].
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
14.2.3
Conformance test results
Further information about the tests can be provided using EARL [
EARL10-Schema
]. EARL provides specific
classes to describe the testing activity, which can be adopted in conjunction with [
PROV-O
].
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
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.
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.
Of course, the above modeling patterns can represent any quality tests, not only conformance to standards.
15.
Qualified relations
This section is non-normative.
DCAT includes elements to support description of many aspects of datasets and data services. Nevertheless, additional information is required in order to fully express the semantics of some relationships. An example is that, while [
DCTERMS
] provides the standard roles
creator
contributor
and
publisher
for attribution of a resource to a responsible party or agent, there are many other potential roles, see for example the
CI_RoleCode
values from [
ISO-19115-1
]. Similarly, while [
DCTERMS
] and [
PROV-O
] provide some properties to capture relationships between resources, including
was derived from
was quoted from
is version of
references
and several others, many additional concerns are seen in the list of [
ISO-19115-1
DS_AssociationTypeCodes
, the IANA Registry of Link Relations [
IANA-RELATIONS
], the DataCite metadata schema [
DataCite
and the
MARC relators
. While these relations could be captured with additional sub-properties of
dcterms:relation
dcterms:contributor
, etc., this would lead to an explosion in the number of properties, and anyway the full set of potential roles and relationships is unknown.
A common approach for meeting these kinds of requirements is to introduce an additional resource to carry parameters that qualify the relationship. Precedents are the
qualified terms
in [
PROV-O
] and the
sample relations
in the Semantic Sensor Network ontology [
VOCAB-SSN
]. The general
Qualified Relation pattern
is described in [
LinkedDataPatterns
].
Many of the qualified terms from [
PROV-O
] are relevant to the description of resources in catalogs but these are incomplete due to the activity-centric viewpoint taken by PROV-O. Addressing some of the gaps, additional forms are included in the DCAT vocabulary to satisfy requirements that do not involve explicit activities. These are summarized in
Figure
Figure
Qualified relationships support an extensible set of roles relating resources to agents or to other resources
Note that, while the focus of these qualified forms is to allow for additional
roles
on a relationship, other aspect of the relationships, such as the applicable time interval, are easily attached when a specific node is used to describe the relationship like this (e.g., see the
chart of Influence relations
in [
PROV-O
] for some examples).
Note
15.1
Relationships between datasets and agents
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:
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
15.2
Relationships between datasets and other resources
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:
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
16.
DCAT Profiles
This section is non-normative.
The DCAT-2014 vocabulary [
VOCAB-DCAT-1
] and DCAT 2 [
VOCAB-DCAT-2
] have been extended for application in data catalogs in different domains.
Each of these new specifications constitutes a DCAT profile, i.e., a named set of constraints based on DCAT (see
4.
Conformance
). In some cases,
a profile extends one of the DCAT profiles themselves, by adding classes and properties for metadata fields not covered in the reference DCAT profile.
Some of the DCAT profiles are:
DCAT-AP [
DCAT-AP
]: The
DCAT application profile for data portals in Europe
GeoDCAT-AP [
GeoDCAT-AP
]: Geospatial profile of [
DCAT-AP
StatDCAT-AP [
StatDCAT-AP
]: Statistical profile of [
DCAT-AP
DCAT-AP_IT [
DCAT-AP-IT
]: Italian profile of [
DCAT-AP
GeoDCAT-AP_IT [
GeoDCAT-AP-IT
]: Italian profile of [
GeoDCAT-AP
DCAT-AP-NO [
DCAT-AP-NO
]: Norwegian profile of [
DCAT-AP
DCAT-AP.de [
DCAT-AP.de
]: German profile of [
DCAT-AP
DCAT-BE [
DCAT-BE
]: Belgian profile of [
DCAT-AP
DCAT-AP-SE [
DCAT-AP-SE
]: Swedish profile of [
DCAT-AP
17.
Security and Privacy Considerations
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.
18.
Accessibility Considerations
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
].
A.
Acknowledgments
The editors gratefully acknowledge the contributions made to this document by
all members of the working group
, especially

Annette Greiner,
Antoine Isaac,

Dan Brickley,

Karen Coyle,
Lars G. Svensson,

Makx Dekkers,
Nicholas Car,
Rob Atkinson,
Tom Baker.
The editors would also like to thank the following for comments received:

Addison Phillips,
Alex Nelson,
Andreas Geißner,
Andreas Kuckartz,
Anna Odgaard Ingram,

Aymen Charef,
Bart Hanssens,
Becky Gibson,
Bert van Nuffelen,
Bob Coret,
Brian Donohue,
Chavdar Ivanov,

Claus Stadler,

Cristiano Longo,
Christophe Dzikowski,

Dimitris Zeginis,
Dominik Schneider,
Emidio Stani,

Ivo Velitchkov,
Jakob Voß,
Jakub Klímek,
Jan Voskuil,

Jim J. Yang,
Joep Meindertsma,
Joep van Genuchten,
Katherine Anderson Aur,

Ludger A. Rinsche,

Marielle Adam,
Martial Honsberger,
Mathias Bonduel,
Mathias Richter,

Matthias Palmér,

Nancy Jean,
Nuno Freire,
Øystein Åsnes,

Paul van Genuchten,

Pieter J. C. van Everdingen,
Renato Iannella,
Rajaram Kaliyaperumal,
Robin Gower,

Sabine Maennel,
Sebastian Hellman,

Simson L. Garfinkel,
Siri Jodha S. Khalsa,

Stefan Ollinger,
Stephen Richard,
Stian Soiland-Reyes,
Stig B. Dørmænen,

Susheel Varma,
Sidney Cox,
Thomas Francart,

Vittorio Meloni,

Wouter Beek,
Yves Coene.
The editors also gratefully acknowledge the chairs of this Working Group: Caroline Burle and Peter Winstanley — and staff contacts Philippe Le Hégaret and Pierre-Antoine Champin.
B.
Alignment with Schema.org
This section is non-normative.
Note
Schema.org [
SCHEMA-ORG
] includes a number of types and properties based on the original DCAT work (see
sdo:Dataset
as a starting point),
and the index for Google's
Dataset Search service
relies on structured description in Web pages about datasets using both
schema.org and DCAT
A comparison of the DCAT backbone, shown in
Figure
above with the related classes from [
SCHEMA-ORG
] in
Figure
shows the similarity, in particular: .
the distinction between (abstract) Dataset and (concrete) DataDownload matches dcat:Dataset / dcat:Distribution
the relationship of Datasets to DataCatalogs
Figure
schema.org support for dataset catalogs, showing a selection of schema.org properties related to the classes shown
General purpose Web search services that use metadata at all rely primarily on [
SCHEMA-ORG
], so the relationship of DCAT to [
SCHEMA-ORG
] is of interest for data providers and catalog publishers who wish their datasets and services to be exposed through those indexes.
mapping between DCAT 1 and schema.org
was discussed on the original proposal to extend [
SCHEMA-ORG
] for describing datasets and data catalogs.
Partial mappings between DCAT 1 [
VOCAB-DCAT-1
] and [
SCHEMA-ORG
] were provided earlier by the
Spatial Data on the Web Working Group
, building upon previous work.
A recommended mapping from the revised DCAT (this document) to [
SCHEMA-ORG
] version 3.4 is
available in an RDF file
This mapping is axiomatized using the predicates
rdfs:subClassOf
rdfs:subPropertyOf
owl:equivalentClass
owl:equivalentProperty
skos:closeMatch
and also using the annotation properties
sdo:domainIncludes
and
sdo:rangeIncludes
to match [
SCHEMA-ORG
] semantics. The alignment is summarized in the table below, considering the prefix
sdo
as
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

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
C.
Examples
This section is non-normative.
C.1
Loosely structured catalog
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:
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.
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):
This example is available from the
DXWG DCAT 3 code repository
at
csiro-stratchart.ttl
C.2
Dataset provenance
The provenance or business context of a dataset can be described using elements from the
W3C
Provenance Ontology [
PROV-O
].
For example, a simple link from a dataset description to the project that generated the dataset can be formalized as follows (other details elided for clarity):
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
C.3
Link datasets and publications
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
This example is available from the
DXWG DCAT 3 code repository
at
dryad-globtherm-sdata.ttl
C.4
Data services
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
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 "
" 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
C.5
Compressed and packaged distributions
The first example is for a distribution with a downloadable file that is compressed into a GZIP file.
The second example is for a distribution with several files packed into a TAR file.
The third example is for a distribution with several files packed into a TAR file which has been compressed into a GZIP file.
These examples are available from the
DXWG DCAT 3 code repository
at
compress-and-package.ttl
D.
Change history
A full change-log is available on
GitHub
E.
Changes since the Candidate Recommendation Snapshot 18 January 2024
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.
F.
Changes since the fourth public working draft of 10 May 2022
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.
G.
Changes since the third public working draft of 11 January 2022
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
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
H.
Changes since the second public working draft of 4 May 2021
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
I.
Changes since the first public working draft of 17 December 2020
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
J.
Changes since the
W3C
Recommendation of 4 February 2020
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
).
K.
References
K.1
Normative references
[DC11]
Dublin Core Metadata Element Set, Version 1.1
. DCMI. 14 June 2012. DCMI Recommendation. URL:
[DCTERMS]
DCMI Metadata Terms
. DCMI Usage Board. DCMI. 20 January 2020. DCMI Recommendation. URL:
[DWBP]
Data on the Web Best Practices
. Bernadette Farias Loscio; Caroline Burle; Newton Calegari. W3C. 31 January 2017. W3C Recommendation. URL:
[FOAF]
FOAF Vocabulary Specification 0.99 (Paddington Edition)
. Dan Brickley; Libby Miller. FOAF project. 14 January 2014. URL:
[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:
[IANA-MEDIA-TYPES]
Media Types
. IANA. URL:
[LOCN]
ISA Programme Location Core Vocabulary
. Andrea Perego; Michael Lutz. European Commission. 23 March 2015. Second version in w3.org/ns space. URL:
[ODRL-MODEL]
ODRL Information Model 2.2
. Renato Iannella; Serena Villata. W3C. 15 February 2018. W3C Recommendation. URL:
[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:
[OWL-TIME]
Time Ontology in OWL
. Simon Cox; Chris Little. W3C. 15 November 2022. W3C Candidate Recommendation. URL:
[OWL2-OVERVIEW]
OWL 2 Web Ontology Language Document Overview (Second Edition)
. W3C OWL Working Group. W3C. 11 December 2012. W3C Recommendation. URL:
[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:
[PAV]
PAV - Provenance, Authoring and Versioning. Version 2.3.1
. Paolo Ciccarese; Stian Soiland-Reyes. Mind Informatics. 16 March 2015. URL:
[PROV-O]
PROV-O: The PROV Ontology
. Timothy Lebo; Satya Sahoo; Deborah McGuinness. W3C. 30 April 2013. W3C Recommendation. URL:
[RDF-SCHEMA]
RDF Schema 1.1
. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL:
[RDF-SYNTAX-GRAMMAR]
RDF 1.1 XML Syntax
. Fabien Gandon; Guus Schreiber. W3C. 25 February 2014. W3C Recommendation. URL:
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels
. S. Bradner. IETF. March 1997. Best Current Practice. URL:
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
. B. Leiba. IETF. May 2017. Best Current Practice. URL:
[SKOS-REFERENCE]
SKOS Simple Knowledge Organization System Reference
. Alistair Miles; Sean Bechhofer. W3C. 18 August 2009. W3C Recommendation. URL:
[SPDX]
SPDX 2.2
. SPDX. URL:
[UNDERSTANDING-WCAG20]
Understanding WCAG 2.0
. Michael Cooper; Andrew Kirkpatrick; Joshue O'Connor et al. W3C. 21 September 2023. W3C Working Group Note. URL:
[VCARD-RDF]
vCard Ontology - for describing People and Organizations
. Renato Iannella; James McKinney. W3C. 22 May 2014. W3C Working Group Note. URL:
[VOCAB-ADMS]
Asset Description Metadata Schema (ADMS)
. Phil Archer; Gofran Shukair. W3C. 1 August 2013. W3C Working Group Note. URL:
[VOCAB-DCAT]
Data Catalog Vocabulary (DCAT)
. Fadi Maali; John Erickson. W3C. 4 February 2020. W3C Recommendation. URL:
[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:
K.2
Informative references
[ADMS-SKOS]
Joinup. ADMS Controlled Vocabularies
. European Commission. URL:
[ANNOTATION-VOCAB]
Web Annotation Vocabulary
. Robert Sanderson; Paolo Ciccarese; Benjamin Young. W3C. 23 February 2017. W3C Recommendation. URL:
[BCP47]
Tags for Identifying Languages
. A. Phillips, Ed.; M. Davis, Ed.. IETF. September 2009. Best Current Practice. URL:
[CSW]
Catalogue Services 3.0 - General Model
. Douglas Nebert; Uwe Voges; Lorenzo Bigagli. OGC. 10 June 2016. URL:
[DataCite]
DataCite Metadata Schema
. DataCite Metadata Working Group. DataCite e.V. 22 January 2024. URL:
[DATETIME]
Date and Time Formats
. W3C. 27 August 1998. W3C Working Group Note. URL:
[DATS]
Data Tag Suite
. Alejandra Gonzalez-Beltran; Philippe Rocca-Serra. NIH Big Data 2 Knowledge bioCADDIE and NIH Data Commons projects. 2016. URL:
[DBPEDIA-ONT]
DBPedia ontology
. URL:
[DCAP]
Guidelines for Dublin Core Application Profiles
. Karen Coyle; Thomas Baker. DCMI. 18 May 2009. DCMI Recommended Resource. URL:
[DCAT-AP]
DCAT Application Profile for data portals in Europe. Version 2.0.1
. European Commission. 8 June 2020. URL:
[DCAT-AP-IT]
Profilo metadatazione DCAT-AP_IT
. AgID & Team Digitale. URL:
[DCAT-AP-NO]
Standard for beskrivelse av datasett, datatjenester og datakataloger (DCAT-AP-NO)
. URL:
[DCAT-AP-SE]
DCAT-AP-SE: Clarifications, translations and explanations of DCAT-AP for Sweden
. Matthias Palmér. URL:
[DCAT-AP.de]
Vokabulare und Dokumente für DCAT-AP.de
. URL:
[DCAT-BE]
Linking data portals across Belgium.
. URL:
[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:
[DOAP]
Description of a Project
. Edd Wilder-James. URL:
[EARL10-Schema]
Evaluation and Report Language (EARL) 1.0 Schema
. Shadi Abou-Zahra. W3C. 2 February 2017. W3C Working Group Note. URL:
[EUV-AR]
Named Authority List: Access rights
. Publications Office of the European Union. URL:
[EUV-CS]
Named Authority List: Concept statuses
. Publications Office of the European Union. URL:
[EUV-DS]
Named Authority List: Dataset statuses
. Publications Office of the European Union. URL:
[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:
[GeoDCAT-AP]
GeoDCAT-AP: A geospatial extension for the DCAT application profile for data portals in Europe
. European Commission. 23 December 2020. URL:
[GeoDCAT-AP-IT]
GeoDCAT-AP in Italy, the national guidelines published
. URL:
[HCLS-Dataset]
Dataset Descriptions: HCLS Community Profile
. Alasdair Gray; M. Scott Marshall; Michel Dumontier. W3C. 14 May 2015. W3C Working Group Note. URL:
[HTML-RDFa]
HTML+RDFa 1.1 - Second Edition
. Manu Sporny. W3C. 17 March 2015. W3C Recommendation. URL:
[HYDRA]
Hydra Core Vocabulary
. Markus Lanthaler. Hydra W3C Community Group. 15 March 2018. Unofficial Draft. URL:
[IANA-RELATIONS]
Link Relations
. IANA. URL:
[IANA-URI-SCHEMES]
Uniform Resource Identifier (URI) Schemes
. IANA. URL:
[INSPIRE-DoC]
INSPIRE Registry: Degrees of conformity
. European Commission. URL:
[INSPIRE-SDST]
INSPIRE Registry: Spatial data service types
. European Commission. URL:
[ISO-19115]
Geographic information -- Metadata
. ISO/TC 211. ISO. 2003. International Standard. URL:
[ISO-19115-1]
Geographic information -- Metadata -- Part 1: Fundamentals
. ISO/TC 211. ISO. 2014. International Standard. URL:
[ISO-19128]
Geographic information -- Web map server interface
. ISO/TC 211. ISO. 2005. International Standard. URL:
[ISO-19135]
Geographic information -- Procedures for item registration
. ISO/TC 211. ISO. 2005. International Standard. URL:
[ISO-19142]
Geographic information -- Web Feature Service
. ISO/TC 211. ISO. 2010. International Standard. URL:
[ISO-26324]
Information and documentation -- Digital object identifier system
. ISO/TC 46/SC 9. ISO. 2012. International Standard. URL:
[ISO-IEC-25012]
ISO/IEC 25012 - Data Quality model
. URL:
[JSON-LD]
JSON-LD 1.0
. Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. 3 November 2020. W3C Recommendation. URL:
[LinkedDataPatterns]
Linked Data Patterns: A pattern catalogue for modelling, publishing, and consuming Linked Data
. Leigh Dodds; Ian Davis. 31 May 2012. URL:
[N3]
Notation3 (N3): A readable RDF syntax
. Tim Berners-Lee; Dan Connolly. W3C. 14 January 2008. W3C Team Submission. URL:
[netCDF]
Network Common Data Form (NetCDF)
. UNIDATA. URL:
[ODRS]
Open Data Rights Statement Vocabulary
. Leigh Dodds. ODI. 29 July 2013. URL:
[OpenAPI]
OpenAPI Specification
. Darrell Miller; Jason Harmon; Jeremy Whitlock; Marsh Gardiner; Mike Ralphson; Ron Ratovsky; Tony Tam; Uri Sarid. OpenAPI Initiative. URL:
[OpenSearch]
OpenSearch 1.1 Draft 6
. DeWitt Clinton. OpenSearch. 17 April 2018. URL:
[RDF11-CONCEPTS]
RDF 1.1 Concepts and Abstract Syntax
. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL:
[RDF11-PRIMER]
RDF 1.1 Primer
. Guus Schreiber; Yves Raimond. W3C. 24 June 2014. W3C Working Group Note. URL:
[RE3DATA-SCHEMA]
Metadata Schema for the Description of Research Data Repositories: version 3
. Jessika Rücknagel et al. GFZ Potsdam. 17 December 2015. URL:
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax
. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL:
[RFC3987]
Internationalized Resource Identifiers (IRIs)
. M. Duerst; M. Suignard. IETF. January 2005. Proposed Standard. URL:
[SCHEMA-ORG]
Schema.org
. URL:
[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:
[SHACL]
Shapes Constraint Language (SHACL)
. Holger Knublauch; Dimitris Kontokostas. W3C. 20 July 2017. W3C Recommendation. URL:
[ShEx]
Shape Expressions Language 2.1
. Shape Expressions W3C Community Group. 17 November 2018. Draft Community Group Report. URL:
[SPARQL11-PROTOCOL]
SPARQL 1.1 Protocol
. Lee Feigenbaum; Gregory Williams; Kendall Clark; Elias Torres. W3C. 21 March 2013. W3C Recommendation. URL:
[SPARQL11-QUERY]
SPARQL 1.1 Query Language
. Steven Harris; Andy Seaborne. W3C. 21 March 2013. W3C Recommendation. URL:
[SPARQL11-SERVICE-DESCRIPTION]
SPARQL 1.1 Service Description
. Gregory Williams. W3C. 21 March 2013. W3C Recommendation. URL:
[StatDCAT-AP]
StatDCAT-AP – DCAT Application Profile for description of statistical datasets. Version 1.0.1
. European Commission. 28 May 2019. URL:
[Turtle]
RDF 1.1 Turtle
. Eric Prud'hommeaux; Gavin Carothers. W3C. 25 February 2014. W3C Recommendation. URL:
[UKGOVLD-REG]
Linked Data Registry - Principles and Concepts
. UK Government Linked Data Working Group. URL:
[VIVO-ISF]
VIVO-ISF Data Standard
. URL:
[VOCAB-DATA-CUBE]
The RDF Data Cube Vocabulary
. Richard Cyganiak; Dave Reynolds. W3C. 16 January 2014. W3C Recommendation. URL:
[VOCAB-DCAT-1]
Data Catalog Vocabulary (DCAT)
. Fadi Maali; John Erickson. W3C. 4 February 2020. W3C Recommendation. URL:
[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:
[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:
[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:
[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:
[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:
[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:
[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:
[VOCAB-DQV]
Data on the Web Best Practices: Data Quality Vocabulary
. Riccardo Albertoni; Antoine Isaac. W3C. 15 December 2016. W3C Working Group Note. URL:
[VOCAB-ORG]
The Organization Ontology
. Dave Reynolds. W3C. 16 January 2014. W3C Recommendation. URL:
[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:
[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:
[W3C-BASIC-GEO]
Basic Geo (WGS84 lat/long) Vocabulary
. Dan Brickley. W3C Semantic Web Interest Group. 1 February 2006. URL:
[WFS]
Web Feature Service 2.0 Interface Standard
. Panagiotis (Peter) A. Vretanos. OGC. 10 July 2014. OGC Interface Standard. URL:
[WMS]
Web Map Service Implementation Specification
. Jeff de la Beaujardiere. OGC. 15 March 2006. OpenGIS Implementation Standard. URL:
[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:
[XHTML-VOCAB]
XHTML Vocabulary
. XHTML 2 Working Group. W3C. 27 October 2010. URL:
[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: