DCAT scope

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

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

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

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

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

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

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 http://www.w3.org/ns/dcat#. Elements are also adopted from several external vocabularies, in particular [[?FOAF]], [[?DCTERMS]] and [[?PROV-O]]

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

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

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 :

The catalog lists each of its datasets via the dcat:dataset property. In , 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.

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:

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.

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 :

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.

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.

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.

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 .

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 .

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

Temporal properties

Five temporal properties of resources may be described using DCAT.

1. The release time of a resource is given using dcterms:issued. The value is usually encoded as a xsd:date.
2. The revision or update time of a resource is given using dcterms:modified. The value is usually encoded as a xsd:date.
3. 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.
4. 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.
5. 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 . Examples of these follow.

Spatial properties

Two spatial properties of datasets may be described using DCAT.

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

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

   Examples of these follow.

Relationships between versions

DCAT supports the following kinds of relationships between versions:

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

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.

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.

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.

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

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

How to specify dataset series

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 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 , as shown in .

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.

Dataset series in existing DCAT implementations

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

1. The dataset series is typed as a dcat:Dataset, whereas its child datasets are typed as dcat:Distribution's.
2. 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.

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.

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.

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]]. provides an illustration:

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

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. provides illustrations:

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