Data Catalog vocabulary (DCAT)

(1)

Data Catalog Vocabulary (DCAT)

W3C Recommendation 16 January 2014

This version:

http://www.w3.org/TR/2014/REC-vocab-dcat-20140116/ Latest published version:

http://www.w3.org/TR/vocab-dcat/

Implementation report:

http://www.w3.org/2011/gld/wiki/DCAT_Implementations Previous version:

http://www.w3.org/TR/2013/PR-vocab-dcat-20131217/ Editors:

Fadi Maali, DERI, NUI Galway

John Erickson, Tetherless World Constellation (RPI) Contributors:

Phil Archer, W3C/ERCIM

Please refer to the errata, a list of issues with this document discovered after publication.

This document is also available in this non-normative format: diff to previous version

The English version of this specification is the only normative version. Non-normative translations may also be available.

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.

By using DCAT to describe datasets in data catalogs, publishers increase discoverability and enable applications easily to consume metadata from multiple catalogs. It further enables decentralized publishing of catalogs and facilitates federated dataset search across sites. Aggregated DCAT metadata can serve as a manifest file to facilitate digital preservation.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at

http://www.w3.org/TR/.

This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

The original DCAT vocabulary was developed at DERI, refined by the eGov Interest Group, and then finally standardized by the Government Linked Data (GLD) Working Group.

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

This document was published by the Government Linked Data Working Group as a Recommendation. If you wish to make comments regarding this document, please send them to [email protected] (subscribe, archives). All comments are welcome.

Please see the Working Group's implementation report.

This document was produced by a group operating under the 5 February 2004 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.

1. Introduction

This section is non-normative.

Data can come in many formats, ranging from spreadsheets over XML and RDF to various speciality formats. DCAT does not make any assumptions about the format of the datasets described in a catalog. Other, complementary vocabularies may be used together with DCAT to provide more detailed format-specific information. For example, properties from the VoID vocabulary [void] can be used to express various statistics about a DCAT-described dataset if that dataset is in RDF format.

This document does not prescribe any particular method of deploying data expressed in DCAT. DCAT is applicable in many contexts including RDF accessible via SPARQL endpoints, embedded in HTML pages as RDFa, or serialized as e.g. RDF/XML or Turtle. The examples in this document use Turtle simply because of Turtle's readability.

2. Namespaces

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

Prefix Namespace

dcat http://www.w3.org/ns/dcat#

dct http://purl.org/dc/terms/

dctype http://purl.org/dc/dcmitype/

foaf http://xmlns.com/foaf/0.1/

rdf http://www.w3.org/1999/02/22-rdf-syntax-ns#

rdfs http://www.w3.org/2000/01/rdf-schema#

skos http://www.w3.org/2004/02/skos/core#

vcard http://www.w3.org/2006/vcard/ns#

xsd http://www.w3.org/2001/XMLSchema#

3. 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 MUST, MUSTNOT, REQUIRED, SHOULD, SHOULDNOT, RECOMMENDED, MAY, and OPTIONAL in this specification are to be interpreted as described in [RFC2119].

A data catalog conforms to DCAT if:

It is organized into datasets and distributions.

An RDF description of the catalog itself and its datasets and distributions is available (but the choice of RDF syntaxes, access protocols, and access policies is 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 and its dataset and

distributions, are included in this RDF description, 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.

(3)

A minimum set of required metadata fields

Classes and properties for additional metadata fields not covered in DCAT Controlled vocabularies or URI sets as acceptable values for properties

Requirements for specific access mechanisms (RDF syntaxes, protocols) to the catalog's RDF description

4. Vocabulary Overview

This section is non-normative.

DCAT is an RDF vocabulary well-suited to representing government data catalogs such as Data.gov and data.gov.uk. DCAT defines three main classes:

dcat:Catalog represents the catalog

dcat:Dataset represents a dataset in a catalog.

dcat:Distribution represents an accessible form of a dataset as for example a downloadable file, an RSS feed or a web service that provides the data.

Notice that 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 formats". A dataset does not have to be available as a downloadable file. For example, a dataset that is available via an API can be defined as an instance of dcat:Dataset and the API can be defined as an instance of dcat:Distribution. DCAT itself does not define

properties specific to APIs description. These are considered out of the scope of this version of the vocabulary. Nevertheless, this can be defined as a profile of the DCAT vocabulary.

Another important class in DCAT is dcat:CatalogRecord which describes a dataset entry in the catalog. Notice that while dcat:Dataset represents the dataset itself, dcat:CatalogRecord represents the record that describes a dataset in the catalog. The use of the CatalogRecord is considered optional. It is used to capture provenance information about dataset entries in a catalog. If this distinction is not necessary then CatalogRecord can be safely ignored.

All RDF examples in this document are written in Turtle syntax [turtle].

4.1 Basic Example

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

First, the catalog description:

:catalog

a dcat:Catalog ;

dct:title "Imaginary Catalog" ; rdfs:label "Imaginary Catalog" ;

foaf:homepage <http://example.org/catalog> ; dct:publisher :transparency-office ;

(4)

dcat:dataset :dataset-001 , :dataset-002 , :dataset-003 ; .

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

:transparency-office a foaf:Organization ;

rdfs:label "Transparency Office" ; .

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

:dataset-001 a dcat:Dataset ;

dct:title "Imaginary dataset" ;

dcat:keyword "accountability","transparency" ,"payments" ; dct:issued "2011-12-05"^^xsd:date ;

dct:modified "2011-12-05"^^xsd:date ;

dcat:contactPoint <http://example.org/transparency-office/contact> ; dct:temporal <http://reference.data.gov.uk/id/quarter/2006-Q1> ; dct:spatial <http://www.geonames.org/6695072> ;

dct:publisher :finance-ministry ;

dct:language <http://id.loc.gov/vocabulary/iso639-1/en> ;

dct:accrualPeriodicity <http://purl.org/linked-data/sdmx/2009/code#freq-W> ; dcat:distribution :dataset-001-csv ;

.

In order to express frequency of update in the example above, we chose to use an instance from the Content-Oriented Guidelines developed as part of the W3C Data Cube Vocabulary efforts. Additionally, we chose to describe the spatial and temporal coverage of the example dataset using URIs from Geonames and the Interval dataset from data.gov.uk, respectively. A contact point is also 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].

The dataset distribution :dataset-001-csv can be downloaded as a 5Kb CSV file. This information is represented via an RDF resource of type dcat:Distribution.

:dataset-001-csv

a dcat:Distribution ;

dcat:downloadURL <http://www.example.org/files/001.csv> ; dct:title "CSV distribution of imaginary dataset 001" ; dcat:mediaType "text/csv" ;

dcat:byteSize "5120"^^xsd:decimal ; .

4.2 Classifying datasets

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

:catalog dcat:themeTaxonomy :themes .

:themes

a skos:ConceptScheme ;

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

:dataset-001 dcat:theme :accountability .

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

:accountability a skos:Concept ; skos:inScheme :themes ;

skos:prefLabel "Accountability" ; .

4.3 Describing catalog records metadata

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

:catalog dcat:record :record-001 .

:record-001

a dcat:CatalogRecord ;

(5)

4.4 A dataset available only behind some Web page

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

dcat:landingPage <http://example.org/dataset-002.html> ; dcat:distribution :dataset-002-csv ;

.

:dataset-002-csv a dcat:Distribution ;

dcat:accessURL <http://example.org/dataset-002.html> ; dcat:mediaType "text/csv" ;

.

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

4.5 A dataset available as download and behind some Web page

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

dcat:landingPage <http://example.org/dataset-003.html> ; dcat:distribution :dataset-003-csv ;

.

:dataset-003-csv a dcat:Distribution ;

dcat:downloadURL <http://example.org/dataset-003.csv> . dcat:mediaType "text/csv" ;

.

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

5. Vocabulary specification

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: [DC11], [FOAF], [RDF-SCHEMA], [SKOS-REFERENCE], [xmlschema-2] and [vcard-rdf].

5.1 Class: Catalog

The following properties are recommended for use on this class: catalog record, dataset, description, homepage, language, license, publisher, release date, rights, spatial, themes, title, update date

RDF Class: dcat:Catalog

Definition: A data catalog is a curated collection of metadata about datasets.

Usage note: Typically, a web-based data catalog is represented as a single instance of this class.

5.2 Class: Catalog record

The following properties are recommended for use on this class: description, listing date, primary topic, title, update date

RDF Class: dcat:CatalogRecord

Definition: A record in a data catalog, describing a single dataset.

Usage note

This class is optional and not all catalogs will use it. It exists for catalogs where a distinction is made between metadata about a dataset and metadata about the dataset's entry in the catalog. 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.

5.3 Class: Dataset

The following properties are recommended for use on this class: contact point, description, distribution, frequency, identifier, keyword, landing page, language, publisher, release date, spatial coverage, temporal coverage, theme, title, update date,

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 formats.}

Sub class of: dctype:Dataset

Usage note:

This class represents the actual dataset as published by the dataset publisher. In cases where a distinction between the actual dataset and its entry in the catalog is necessary (because metadata such as modification date and maintainer might differ), the catalog record class can be used for the latter.

5.4 Class: Distribution

The following properties are recommended for use on this class: access URL, byte size, description, download URL, format, license, media type, release date, rights, title, update date

RDF class: dcat:Distribution

Definition:

Represents a specific available form of a dataset. Each dataset might be available in different forms, these forms might represent different formats of the dataset or different endpoints. Examples of distributions include a downloadable CSV file, an API or an RSS feed

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 it is a direct download, API, or some through Web page. The use of dcat:downloadURL property indicates directly downloadable distributions.

Property: title

Definition: A name given to the distribution.

Range: rdfs:Literal

Definition: free-text account of the distribution.

Range: rdfs:Literal

Property: release date

Definition: Date of formal issuance (e.g., publication) of the distribution.

(13)

Usage note: This property should be set using the first known date of issuance.

5.5 Class: Concept scheme

(15)

Definition: The knowledge organization system (KOS) used to represent themes/categories of datasets in the catalog.

5.6 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

5.7 Class: Organization/Person

RDF Classes: foaf:Person for people and foaf:Organization for government agencies or other entities.

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

A. Acknowledgements

This document contains a significant contribution from Richard Cyganiak. Richard Cyganiak is one of the initiators of the DCAT work and significantly contributed to the work on this specification as it made its way through the W3C process.

The editors would like to thank Vassilios Peristeras for his comments and support for the original DCAT work. Vassilios Peristeras is also one of the initiators of the DCAT work. We would also like to thank Rufus Pollock for his significant input and comments.

This document has benefited from inputs from many members of the Government Linked Data Working Group. Specific thanks are due to Ghislain Atemezing, Martin Alvarez and Makx Dekkers.

B. Change history

Changes since the W3C Proposed Recommendation 17 December 2013: None.

Changes since the W3C Candidate Recommendation 05 November 2013:

Section 5.4 Property: download URL; usage note added to clarify the relationship to dcat:accessURL Section 5.1: A domain row is added to the table describing dcat:themeTaxonomy property

Section 5.3: A domain row is added to the tables describing dcat:theme, dcat:keyword and dcat:contactPoint properties

Section 5.4: A domain row is added to the table describing dcat:accessURL, dcat:downloadURL, dcat:byteSize and dcat:mediaType properties

Section 5: clarified that this spec is non-normative concerning terms outside the DCAT namespace, and added normative references for those terms.

Changes since the second W3C Last Call working Draft 01 August 2013:

Section 4.1: the provided example is extended with example usage of properties dct:spatial, dct:temporal and dcat:contactPoint Section 5.4 Property: access URL; definition and usage note texts clarified

Section 5.4 Property: download URL; usage note saying "this value is a URL" is removed as it is confusing given that the range is rdfs:Resource

Section 5.3 Property: contact point; change range from vcard:VCard to vcard:Kind. These two classes are equivalent however vcard:VCard is deprecated.

Section 5.3 Property: language; usage note is expanded to describe the case of multiple language datasets.

Section 4. Clarification text regarding versioning is added: "DCAT itself does not define properties specific to APIs description. These are considered out of the scope of this version of the vocabulary. Nevertheless, this can be defined as a profile of the DCAT vocabulary."

Changes since W3C Last Call working Draft 12 March 2013:

Section 4: diagram updated with new properties

Section 4: add text to clarify describing datasets available via API

Section 5.1: description of properties dct:issued and dct:modified updated Section 5.1: dct:rights added

Section 5.2: description of properties dct:issued and dct:modified updated Section 5.3: description of properties dct:issued and dct:modified updated Section 5.3: dcat:contactPoint added

Section 5.4: description of properties dct:issued and dct:modified updated Section 5.4: dct:rights added

Section 5.5: split into two sections 5.5 and 5.6

(16)

C.1 Normative references

[DC11]

Dublin Core metadata initiative. Dublin Core metadata element set, version 1.1. July 1999. Dublin Core recommendation. URL: http://dublincore.org/documents/dcmi-terms/

[FOAF]

Dan Brickley, Libby Miller. FOAF Vocabulary Specification 0.98. 9 August 2010. URL: http://xmlns.com/foaf/spec/ [RDF-SCHEMA]

Dan Brickley; Ramanathan Guha. RDF Schema 1.1. 9 January 2014. W3C Proposed Edited Recommendation. URL: http://www.w3.org/TR/rdf-schema/

[RFC2119]

S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Internet RFC 2119. URL: http://www.ietf.org/rfc/rfc2119.txt

[SKOS-REFERENCE]

Alistair Miles; Sean Bechhofer. SKOS Simple Knowledge Organization System Reference. 18 August 2009. W3C Recommendation. URL: http://www.w3.org/TR/skos-reference

[vcard-rdf]

Renato Iannella; James McKinney. vCard Ontology. 24 September 2013. W3C Working Draft. URL: http://www.w3.org/TR/vcard-rdf/ [xmlschema-2]

Paul V. Biron; Ashok Malhotra. XML Schema Part 2: Datatypes Second Edition. 28 October 2004. W3C Recommendation. URL: http://www.w3.org/TR/xmlschema-2/

C.2 Informative references

[prov-o]

Timothy Lebo; Satya Sahoo; Deborah McGuinness. PROV-O: The PROV Ontology. 30 April 2013. W3C Recommendation. URL: http://www.w3.org/TR/prov-o/

[sparql11-query]

Steven Harris; Andy Seaborne. SPARQL 1.1 Query Language. 21 March 2013. W3C Recommendation. URL: http://www.w3.org/TR/sparql11-query/

[turtle]

Eric Prud'hommeaux; Gavin Carothers. RDF 1.1 Turtle. 9 January 2014. W3C Proposed Recommendation. URL: http://www.w3.org/TR/turtle/

[void]

Data Catalog vocabulary (DCAT)