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 are using a standard model and vocabulary that facilitates the consumption and aggregation of metadata from multiple catalogs,
and in doing so can increase the discoverability of datasets. It also makes it possible to have a decentralized approach to publishing data catalogs and makes federated search for datasets across catalogs in multiple sites possible using the same query mechanism and structure. Aggregated DCAT metadata can serve as a manifest file as part of the digital preservation process.
The namespace for DCAT terms is http://www.w3.org/ns/dcat#
The suggested prefix for the DCAT namespace is dcat
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 https://www.w3.org/TR/.
This revised version of DCAT was developed by the Dataset Exchange Working Group in response to a new set of Use Cases and Requirements [DCAT-UCR] submitted on the basis of experience with the DCAT vocabulary from the time of the original version, and new applications not originally considered.
DCAT incorporates terms from pre-existing vocabularies where stable terms with appropriate meanings could be found, such as foaf:homepage and dct:title. Informal summary definitions of the externally-defined terms are included here for convenience, while authoritative definitions are available in the normative references. Changes to definitions in the references, if any, supersede the summaries given in this specification. Note that conformance to DCAT (Section 4) concerns usage of only the terms in the DCAT namespace itself, so possible changes to the external definitions will not affect the conformance of DCAT implementations.
Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
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.
Data can come in many formats, ranging from spreadsheets, through XML and RDF, to various speciality formats. DCAT does not make any assumptions about the serialisation 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. Motivation for Change
This section is non-normative.
The original Recommendation, published in January 2014, provided the basic framework for describing datasets. Importantly, it made the distinction between a dataset as an abstract idea and a distribution as a manifestation of the dataset. Although DCAT has been widely adopted, it has became clear that the original specification lacked a number of essential features that were added either through application profiles, such as the European Commission's DCAT-AP [DCAT-AP], or the development of larger vocabularies that, to a greater or lesser extent, built upon the base standard, such as the Healthcare and Life Sciences Community Profile [HCLS-Dataset], the Data Tag Suite [DATS] and more. This version of DCAT has been developed to address the specific shortcomings that have come to light through the experiences of different communities, the aim being, of course, to improve interoperability between the outputs of these larger vocabularies.
3. 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 [DCTERMS].
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/
owl
http://www.w3.org/2002/07/owl#
prov
http://www.w3.org/ns/prov#
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#
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 and SHOULD are
to be interpreted as described in [RFC2119].
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.
A DCAT profile is a specification for data catalogs that adds additional constraints to DCAT. A data catalog that conforms to the profile also conforms to DCAT. Additional constraints in a profile MAY include:
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
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 the 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.
Note
The scope of DCAT 2014 was limited to catalogs of datasets.
A number of use cases for the revision involve also having data services (aka distribution services) as members of a catalog - see DCAT Distribution to describe web services - ID6 and
Modeling service-based data access - ID18.
It has been decided to add an explicit class for Data Distribution Services in this revision of DCAT, and to enable these to be part of a Catalog.
Provision for other services to also be part of a Catalog will also be made, as well as for Catalogs to be composed of other Catalogs.
See Issue #172.
Milestone 5 collects a number of issues related to this requirement.
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 dcat:CatalogRecord is considered optional. It is used to capture provenance information about dataset entries in a catalog. If this distinction is not necessary then dcat:CatalogRecord can be safely ignored.
The publisher of the catalog has the relative URI :transparency-office. Further description of the publisher can be provided as in the following example:
The catalog lists each of its datasets via the dcat:dataset property. In the example above, an example dataset was mentioned with the relative URI :dataset-001. A possible description of it using DCAT is shown below:
In order to express the 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 [VOCAB-DATA-CUBE] 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 ;
.
5.2 Classifying datasets thematically
The catalog classifies its datasets according to a set of domains represented by the relative URI :themes. SKOS can be used to describe the domains used:
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:
The scope of DCAT Datasets is a lot more than tabular data, so a type/genre indication is required.
A number of controlled vocabularies are available for classification of datasets according to type.
In some cases, each individual classifier is denoted by a URI so it can be linked directly.
However, in other cases there is only a text list, or a vocabulary is embedded in a document or code, so the way to indicate an individual item is less direct.
Guidance about how to use items from various styles of controlled vocabulary are needed alongside the simple case.
The type or genre of a dataset may be indicated using the dct:type property:
:dataset-001dct:typedctype:Text .
5.4 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:
:dataset-002 is available as a CSV file. However :dataset-002 can only be obtained through some Web page
where the user needs to follow some links, provide some information and check some boxes
before accessing the data
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.
6. Vocabulary specification
6.1 RDF representation
Note
The DCAT RDF representation is modularized into several files or graphs to help users access a version of DCAT with just the alignments that they need. This mechanism may also be used to capture different levels of axiomatization, though the status of such proposals has not been finalized. See Issue #134 and the issues enumerated below.
Guidance on the use DCAT in a weakly-axiomatized environment, such as schema.org, has been identified as a requirement to be satisfied in this revision of DCAT.
The axiomatization of DCAT 2014 used global domain and range constraints for many of the properties defined in the DCAT namespace. This makes quite strong ontological commitments, some of which are now being reconsidered - see individual issues noted inline below.
The (revised) DCAT vocabulary is available in RDF.
The primary artefact dcat.ttl is a serialization of the core DCAT vocabulary.
Alongside it are a set of other RDF files that provide additional information, including:
alignments to other vocabularies
additional axioms, which may be useful in some contexts
some profiles of DCAT, including a DCAT 2014 profile that corresponds to the 2014 version of DCAT
The implementation of a DCAT 2014 profile of the revised DCAT is being considered.
6.2 Dependencies
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], [DCTERMS], [FOAF], [RDF-SCHEMA], [SKOS-REFERENCE], [XMLSCHEMA11-2] and [VCARD-RDF].
Note
Description of DCAT vocabulary elements from DCAT 2014 [VOCAB-DCAT] except where indicated.
The use of guarded constraints (existence, cardinality, range-type) to control the use of the recommended properties in the context of a class is being considered as part of the revision of DCAT.
Note
The scope of DCAT 2014 was limited to catalogs of datasets.
A number of use cases for the revision involve also having data services (aka distribution services) as members of a catalog - see DCAT Distribution to describe web services - ID6 and
Modeling service-based data access - ID18.
It has been decided to add an explicit class for Data Distribution Services in this revision of DCAT, and to enable these to be part of a Catalog.
Provision for other services to also be part of a Catalog will also be made, as well as for Catalogs to be composed of other Catalogs.
See Issue #172.
Milestone 5 collects a number of issues related to this requirement.
Date of formal issuance (e.g., publication) of 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]
Most recent date on which the catalog 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]
The language of the catalog. This refers to the language used in the textual metadata describing titles, descriptions, etc. of the datasets in the catalog.
Range:
dct:LinguisticSystem
Resources defined by the Library of Congress (1,
2) SHOULD be used.
If a ISO 639-1 (two-letter) code is defined for language, then its corresponding IRI SHOULD be used; if no ISO 639-1 code is defined, then IRI corresponding to the ISO 639-2 (three-letter) code SHOULD be used.
Usage note:
Multiple values can be used. The publisher might also choose to describe the language on the dataset level (see dataset language).
foaf:homepage is an inverse functional property (IFP) which means that it should be unique and precisely identify the catalog. This allows smushing various descriptions of the catalog when different URIs are used.
This links to the license document under which the catalog
is made available and not the datasets. Even if the license of the catalog applies to all of its
datasets and distributions, it should be replicated on each distribution.
This describes the rights under which the catalog
can be used/reused and not the datasets. Even if theses rights apply to all the catalog
datasets and distributions, it should be replicated on each distribution.
The need to be able to express rights relating to the re-use of DCAT metadata has been identified as a requirement to be satisfied in the revision of DCAT.
The use of guarded constraints (existence, cardinality, range-type) to control the usage of the recommended properties in the context of a class is being considered as part of the revision of DCAT.
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.
If a catalog is represented as an RDF Dataset with named graphs (as defined in [SPARQL11-QUERY]),
then it is appropriate to place the description of each dataset
(consisting of all RDF triples that mention the dcat:Dataset, dcat:CatalogRecord, and any of its dcat:Distributions)
into a separate named graph. The name of that graph should be the IRI of the catalog record.
The date of listing the corresponding dataset in the catalog.
Range:
rdfs:Literal
encoded using the relevant ISO 8601 Date and Time compliant string [DATETIME] and typed using the appropriate XML Schema datatype [XMLSCHEMA11-2]
Usage note:
This indicates the date of listing the dataset in the catalog and not the publication date of the dataset itself.
Most recent date on which the catalog entry was changed, updated or modified.
Range:
rdfs:Literal
encoded using the relevant ISO 8601 Date and Time compliant string [DATETIME] and typed using the appropriate XML Schema datatype [XMLSCHEMA11-2]
Usage note:
This indicates the date of last change of a catalog entry, i.e. the catalog metadata description of the dataset, and not the date of the dataset itself.
The need to provide hook for quality information concerning a dcat:Dataset has been identified as a requirement to be satisfied in the revision of DCAT.
The need to more formally encode access restrictions for both datasets and distributions has been identified as a requirement to be satisfied in the revision of DCAT.
The need to provide richer descriptions of dataset aspects (e.g. instrument/sensor used, spatial feature, observable property, quantity kind) has been identified as a requirement to be satisfied in the revision of DCAT.
The need to provide better guidance and vocabulary elements for dataset citation has been identified as a requirement to be satisfied in the revision of DCAT.
The need to be able to link a dataset with the source of funding that supported its production has been identified as a requirement to be satisfied in the revision of DCAT.
The need to be able to describe the business or project context related to dataset production has been identified as a requirement to be satisfied in the revision of DCAT.
The need provide a more comprehensive method for describing dataset provenance has been identified as a requirement to be satisfied in the revision of DCAT. A preliminary alignment of DCAT with PROV-O is available.
The need to be able to link a dataset with the business or project context of its production has been identified as a requirement to be satisfied in the revision of DCAT.
The need to be able to describe version relationships of datasets has been identified as a requirement to be satisfied in the revision of DCAT. Also see detailed requirements in
Issue #89,
Issue #91,
Issue #92,
Issue #93,
The option of allowing license and rights information to be associated with a dcat:Dataset, as well as dcat:Distribution, is being considered as part of the revision of DCAT.
The use of guarded constraints (existence, cardinality, range-type) to control the usage of the recommended properties in the context of a class is being considered as part of the revision of DCAT.
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:
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.
Date of formal issuance (e.g., publication) of the dataset.
Range:
rdfs:Literal
encoded using the relevant ISO 8601 Date and Time compliant string [DATETIME] and typed using the appropriate XML Schema datatype [XMLSCHEMA11-2]
Usage note:
This property should be set using the first known date of issuance.
Most recent date on which the dataset was changed, updated or modified.
Range:
rdfs:Literal
encoded using the relevant ISO 8601 Date and Time compliant string [DATETIME] and typed using the appropriate XML Schema datatype [XMLSCHEMA11-2]
Usage note:
The value of this property indicates a change to the actual dataset, not a change to the catalog record. An absent value may indicate that the dataset has never changed after its initial publication, or that the date of last modification is not known, or that the dataset is continuously updated.
dct:LinguisticSystem
Resources defined by the Library of Congress (1,
2) SHOULD be used.
If a ISO 639-1 (two-letter) code is defined for language, then its corresponding IRI SHOULD be used; if no ISO 639-1 code is defined, then IRI corresponding to the ISO 639-2 (three-letter) code SHOULD be used.
Usage note:
This overrides the value of the catalog language in case of conflict.
If the dataset is available in multiple languages, use multiple values for this property. If each language is available separately, define an instance of dcat:Distribution for each language and describe the specific language of each distribution using dct:language (i.e. the dataset will have multiple dct:language values and each distribution will have one of these languages as value of its dct:language property).
The desire to have qualified forms of properties (as done in [PROV-O]) has been raised. If dcat:Dataset is a prov:Entity (not decided yet) then `publisher` could be a qualified prov:Entity -> prov:Agent relationship.
The desirability of dereferenceable identifiers has been raised as an item for consideration in the revision of DCAT. dct:identifier has limited expressivity for this. It has been suggested that ADMS identifier, or a property from another ontology might be recruited to help DCAT in this area.
The need to clearly distinguish between primary and legacy identifiers for a dataset has been identified as a requirement to be satisfied in the revision of DCAT.
The need to indicate the scheme or authority for identifiers for a dataset has been identified as a requirement to be satisfied in the revision of DCAT.
The need to indicate the spatial reference system used in the spatial description of a dataset has been identified as a requirement to be satisfied in the revision of DCAT.
The need to be able to describe the spatial coverage of a dataset as a geometry has been identified as a requirement to be satisfied in the revision of DCAT.
The need to be able to describe the temporal coverage of a dataset in a structure way has been identified as a requirement to be satisfied in the revision of DCAT.
dct:PeriodOfTime (An interval of time that is named or defined by its start and end dates)
6.5.11 Property: theme/category
Note
In DCAT 2014 [VOCAB-DCAT] the domain of dcat:theme was dcat:Dataset,
which limited use of this property in other contexts. The domain has been relaxed in this revision -
see Issue #123.
The set of skos:Concepts used to categorize the resources are organized in a skos:ConceptScheme describing all the categories and their relations in the catalog.
To describe the file format, physical medium, or dimensions of the resource, use the dct:format element.
6.5.13 Property: keyword/tag
Note
In DCAT 2014 [VOCAB-DCAT] the domain of dcat:keyword was dcat:Dataset,
which limited use of this property in other contexts. The domain has been relaxed in this revision -
see Issue #121.
In DCAT 2014 [VOCAB-DCAT] the domain of dcat:contactPoint was dcat:Dataset,
which limited use of this property in other contexts. The domain has been relaxed in this revision -
see Issue #95.
In DCAT 2014 [VOCAB-DCAT] the domain of dcat:landingPage was dcat:Dataset,
which limited use of this property in other contexts. The domain has been relaxed in this revision -
see Issue #122.
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 example 4.4)
The definition of dcat:Distribution is being re-evaluated as part of the revision of DCAT. In particular to clarify if distribution includes services as well as files.
The need to provide a way to indicate the structure or schema of data in a dcat:Distribution (in addition to the media-type or serialization) has been identified as a requirement to be satisfied in the revision of DCAT.
The need to provide more information about the nature of data service - a kind of dcat:Distribution - has been identified as a requirement to be satisfied in the revision of DCAT.
The need to more formally encode access restrictions for both datasets and distributions has been identified as a requirement to be satisfied in the revision of DCAT.
The use of guarded constraints (existence, cardinality, range-type) to control the usage of the recommended properties in the context of a class is being considered as part of the revision of DCAT.
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.
Date of formal issuance (e.g., publication) of the distribution.
Range:
rdfs:Literal
encoded using the relevant ISO 8601 Date and Time compliant string [DATETIME] and typed using the appropriate XML Schema datatype [XMLSCHEMA11-2]
Usage note:
This property should be set using the first known date of issuance.
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]
dct:license, which is a sub-property of dct:rights, can be used to link
a distribution to a license document. However, dct:rights allows linking to a rights statement that
can include licensing information as well as other information that supplements the licence such as attribution.
The granularity of dcat:accessURL is being re-considered to provide different usages for list and item endpoints as well as supporting the declaration of different profiles (for list results and data payload).
Use dcat:accessURL, and not dcat:downloadURL, when it is definitely not a download or when you are not sure whether it is.
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 example 4.4)
dcat:downloadURL is a specific form of dcat:accessURL. Nevertheless, DCAT does not define dcat:downloadURL as a subproperty of dcat:accessURL not to enforce this entailment as DCAT profiles may wish to impose a stronger separation where they only use dcat:accessURL for non-download locations.
This property SHOULD be used when the media type of the distribution is defined in IANA [IANA-MEDIA-TYPES], otherwise dct:format MAY be used with different values.
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
In this chapter it is planned to describe patterns for the use of the [PROV-O] vocabulary to support the various provenance-related requirements.
See Milestone 2 for more discussion.
8. License and rights statements
Note
DCAT 2014 handling of license and rights do not appear to satisfy all requirements.
The recently completed W3C ODRL vocabulary [ODRL-VOCAB] provides a rich language for describing many kinds of rights and obligations.
In this chapter it is planned to describe some patterns for linking DCAT Datasets and/or Distributions to suitable rights expressions.
See Milestone 1 for more discussion.
The need to be able to describe version relationships of datasets has been identified as a requirement to be satisfied in the revision of DCAT. Also see detailed requirements in
Issue #89,
Issue #91,
Issue #92,
Issue #93,
Note
In this chapter it is planned to describe some patterns for describing Dataset and/or Distribution versions.
See Milestone 6 for more discussion.
DCAT provides a generic metadata vocabulary for cataloguing datasets.
Profiles of DCAT are required for spcific applications and disciplines.
Providing a model and formalization for DCAT profiles is planned to be an important part of this revision.
Also see Issue #73, Issue #74, Issue #75.
The editors also gratefully acknowledge the chairs of this Working Group: Karen Coyle, Caroline Burle and Peter Winstanley — and staff contacts Phil Archer and Dave Raggett.
Property: theme/category:
In DCAT 2014 [VOCAB-DCAT] the domain of dcat:theme was dcat:Dataset,
which limited use of this property in other contexts. The domain has been relaxed in this revision -
see Issue #123.
Property: keyword/tag:
In DCAT 2014 [VOCAB-DCAT] the domain of dcat:keyword was dcat:Dataset,
which limited use of this property in other contexts. The domain has been relaxed in this revision -
see Issue #121.
Property: contact point:
In DCAT 2014 [VOCAB-DCAT] the domain of dcat:contactPoint was dcat:Dataset,
which limited use of this property in other contexts. The domain has been relaxed in this revision -
see Issue #95.
Property: landing page:
In DCAT 2014 [VOCAB-DCAT] the domain of dcat:landingPage was dcat:Dataset,
which limited use of this property in other contexts. The domain has been relaxed in this revision -
see Issue #122.
Metadata Schema for the Description of Research Data Repositories: version 3. Jessika Rücknagel; Paul Vierkant; Robert Ulrich; Gabriele Kloska; Edeltraud Schnepf; David Fichtmüller; Evelyn Reuter; Angelika Semrau; Maxi Kindling; Heinz Pampel; Michael Witt; Florian Fritze; Stephanie van de Sandt; Jens Klump; Hans-Jürgen Goebelbecker; Michael Skarupianski; Roland Bertelmann; Peter Schirmbacher; Frank Scholze; Claudia Kramer; Claudio Fuchs; Shaked Spier; Agnes Kirchhoff. GFZ Potsdam. 17 December 2015. URL: https://doi.org/10.2312/re3.008
