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/.
addition of a dcat:Resource class for representing any resource than can be included in the catalog, this is
now the super-class of dcat:Dataset
addition of dcat:DataService, as a sub-class of dcat:Resource, to support cataloguing service end-points providing access to resources
addition of dcat:DataDistributionService, as a sub-class of dcat:DataService,
representing service end-points providing access to datasets through their distributions, respectively
addition of ways to representing loosely structured catalogs, where there is no distinction between a dataset and its distributions
an alignment between the DCAT vocabulary and the schema.org vocabulary
The detailed differences between the two documents can be seen here
and the list of all the changes since the previous version of DCAT in the Change History section.
DXWG Family of Documents
This document is part of the output of the Dataset Exchange Working Group (DXWG).
All documents from the group are listed here.
DCAT documents
The DCAT documents are about the revised Data Catalog Vocabulary.
[VOCAB-DCAT] (Recommendation) - this document, description of the DCAT RDF vocabulary
Profiling documents
These documents give guidance on profiling. Some of the documents are general while some are technology-specific.
Please consult the Profile Guidance [PROF-GUIDE] document for an overview of all profiling documents. It is the
recommended starting point.
[PROF-GUIDE] (Recommendation) - the top-level general profiling guidance document giving an overview of all other documents
[PROF-CONNEG] (Recommendation) - Specific guidance on how to negotiate for Internet resource content using profiles
The original DCAT vocabulary (originally hosted at http://vocab.deri.ie/dcat) was developed at the Digital Enterprise Research Institute (DERI), refined by the eGov Interest Group, and then finally standardized in 2014 [VOCAB-DCAT-20140116] by the Government Linked Data (GLD) Working Group.
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. A summary of the changes from [VOCAB-DCAT-20140116] can be found at 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 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.
Please send comments
This document was published by the Dataset Exchange Working Group as a Working Draft.
This document is intended to become a W3C Recommendation.
Publication as a 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 specialty formats. DCAT does not make any assumptions about the serialization 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 [VOCAB-DCAT-20140116], 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 become 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.
This draft includes re-writing of the specification throughout. Significant changes from the 2014 Recommendation are marked within the text using "Note" sections, as well as being described in the Change History.
3. Namespaces
The namespace for DCAT is http://www.w3.org/ns/dcat#.
However, note that DCAT 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.
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/
dqv
http://www.w3.org/ns/dqv#
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#
schema
https://schema.org/
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, MUST NOT, SHOULD, and SHOULD NOT are
to be interpreted as described in [RFC2119].
Access to data is organized into datasets, distributions, and data-services.
An RDF description of the catalog itself and its datasets, distributions, and data-services 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 datasets, distributions, and data-services, 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:
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
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:CatalogRecord describes a dataset entry in the catalog, primarily concerning the registration information such as who added the item and when
Figure 1
Overview of DCAT model, showing the classes of resources that can be members of a Catalog, and the relationships between them.
Note
Along with the rest of the Vocabulary overview, this diagram is non-normative.
Furthermore, while the diagram uses UML-style class notation, it should be interpreted following the usual RDF open-world assumptions around the presence/absence of properties, relationships, and their cardinality.
The properties shown in each class reflect those recommended in the descriptions of classes in the Vocabulary specification.
To assist in understanding the full scope of each class, properties are copied down from each '::super-class'.
Cardinalities are shown in a few places to reinforce expectations, but these are not axiomatized or enforced in any way by this recommendation.
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 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 distribution services.
Detailed properties for a data distribution service API are out of the scope of this version of DCAT.
Datasets and data services, and potentially other types of thing, can be included in a catalog.
Types of data service that might be found in a catalog include data distribution services, discovery services such as portals and catalog services, data transformation services such as coordinate transformation services, re-sampling and interpolation services, and various data processing services.
Note
The scope of DCAT 2014 [VOCAB-DCAT-20140116] was limited to catalogs of datasets.
A number of use cases for the revision involve also having data 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 data services to also be part of a Catalog is also made, as well as for Catalogs to be composed of other Catalogs.
See Issue #172.
A CatalogRecord 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 an item in the catalog. The use of dcat:CatalogRecord is considered optional. It is used to capture provenance information about entries in a catalog. If this distinction is not necessary then dcat:CatalogRecord can be safely ignored.
There is ongoing discussion about whether a DCAT Resource represents only a dataset or also a distribution.
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].
While blank nodes may 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.
Note
All RDF examples in this document are written in Turtle syntax [Turtle] and many are available from the DXWG code repository.
Note
Each RDF example in this document is intended to demonstrate specific capabilities of DCAT, and therefore only shows a subset of all the potential properties and links which might appear in a complete DCAT resource.
5.1 Basic Example
This example provides a quick overview of how DCAT might be used to represent a government catalog and its datasets.
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 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 (originally available from http://reference.data.gov.uk/id/interval) 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 <https://www.iana.org/assignments/media-types/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:
: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:
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.
In many legacy catalogues and repositories (e.g. CKAN), ‘datasets’ are ‘just a bag of files’. There is no distinction made between part/whole, 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 catalogue, repository, or elsewhere are not known, dct:relation can be used:
:d33937
dct:description "A set of RDF graphs representing the International [Chrono]stratigraphic Chart, ..." ;
dct:identifier "https://doi.org/10.25919/5b4d2b83cbf2d"^^xsd:anyURI ;
dct:creator <https://orcid.org/0000-0002-3884-3420>;
dct:relation <https://vocabs.ands.org.au/viewById/196> ;
dct:relation :ChronostratChart2017-02.pdf ;
dct:relation :ChronostratChart2017-02.jpg ;
dct:relation :timescale.zip ;
dct:relation :isc2017.jsonld ;
dct:relation :isc2017.nt ;
dct:relation :isc2017.rdf ;
dct:relation :isc2017.ttl ;
.
If it is clear that any of these related resources is a proper representation of the dataset, dcat:distribution should be used.
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):
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 dct:creator, dct:contributor or dct:publisher.
prov:wasDerivedFrom supports a more specific relationship to an input or predecessor dataset compared with dct:source, which is not necessarily a previous dataset.
For a more detailed discussion of the use of PROV for dataset provenance, including recommendations on the use of qualified properties, see the chapter on Provenance Patterns below.
5.9 Data services
Data services may be described using DCAT.
The values of the classifiers dct:type, dct:conformsTo, and dcat:endpointDescription provide progressively more detail about a service, whose actual endpoint is given by the dcat:endpointURL.
a:EEA-CSW-Endpoint
rdf:type dcat:DiscoveryService ;
dc:subject "infoCatalogueService"@en ;
dct:accessRights <http://publications.europa.eu/resource/authority/access-right/PUBLIC> ;
dct:conformsTo <http://www.opengis.net/def/serviceType/ogc/csw> ;
dct:description "The EEA public catalogue of spatial datasets references the spatial datasets used by the European Environment Agency as well as the spatial datasets produced by or for the EEA. In the latter case, when datasets are publicly available, a link to the location from where they can be downloaded is included in the dataset's metadata. The catalogue has been initially populated with the most important spatial datasets already available on the data&maps section of the EEA website and is currently updated with any newly published spatial dataset."@en ;
dct:identifier "eea-sdi-public-catalogue" ;
dct:issued "2012-01-01"^^xsd:date ;
dct:license <https://creativecommons.org/licenses/by/2.5/dk/> ;
dct:spatial [
rdf:type dct:Location ;
locn:geometry "<gml:Envelope srsName=\"http://www.opengis.net/def/crs/OGC/1.3/CRS84\"><gml:lowerCorner>-180 -90</gml:lowerCorner><gml:upperCorner>180 90</gml:upperCorner></gml:Envelope>"^^gsp:gmlLiteral ;
locn:geometry "POLYGON((-180 90,180 90,180 -90,-180 -90,-180 90))"^^gsp:wktLiteral ;
] ;
dct:title "European Environment Agency's public catalogue of spatial datasets."@en ;
dct:type <http://inspire.ec.europa.eu/metadata-codelist/ResourceType/service> ;
dct:type <http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/discovery> ;
dcat:contactPoint a:EEA ;
dcat:endpointDescription <https://sdi.eea.europa.eu/catalogue/srv/eng/csw?service=CSW&request=GetCapabilities> ;
dcat:endpointURL <http://sdi.eea.europa.eu/catalogue/srv/eng/csw> ;
.
ga-courts:jc
rdf:type dcat:Dataset ;
dct:description "The dataset contains spatial locations, in point format, of the Australian High Court, Australian Federal Courts and the Australian Magistrates Courts." ;
dct:spatial [
rdf:type dct:Location ;
locn:geometry "<gml:Envelope srsName=\"http://www.opengis.net/def/crs/EPSG/0/4283\"><gml:lowerCorner>115.864566 -42.885989</gml:lowerCorner><gml:upperCorner>153.276835 -12.460578</gml:upperCorner></gml:Envelope>"^^gsp:gmlLiteral ;
] ;
dct:title "Judicial Courts" ;
dct:type <http://purl.org/dc/dcmitype/Dataset> ;
dcat:landingPage <https://ecat.ga.gov.au/geonetwork/srv/eng/catalog.search#/metadata/cc365600-294a-597d-e044-00144fdd4fa6> ;
.
ga-courts:jc-esri
rdf:type dcat:DataDistributionService ;
dct:conformsTo <https://developers.arcgis.com/rest/> ;
dct:description "This web service provides access to the National Judicial Courts dataset and presents the spatial locations of all the known Australian High Courts, Australian Federal Courts and the Australian Federal Circuit Courts located within Australia, all complemented with feature attribution." ;
dct:identifier "2b8540c8-4a43-144d-e053-12a3070a3ff7" ;
dct:title "National Judicial Courts MapServer" ;
dct:type <http://purl.org/dc/dcmitype/Service> ;
dct:type <https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/download> ;
dct:type <https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/view> ;
dcat:endpointURL <http://services.ga.gov.au/gis/rest/services/Judicial_Courts/MapServer> ;
dcat:landingPage <https://ecat.ga.gov.au/geonetwork/srv/eng/catalog.search#/metadata/2b8540c8-4a43-144d-e053-12a3070a3ff7> ;
dcat:servesDataset ga-courts:jc ;
.
ga-courts:jc-wfs
rdf:type dcat:DataDistributionService ;
dct:conformsTo <http://www.opengis.net/def/serviceType/ogc/wfs/2.0.0> ;
dct:conformsTo <http://www.opengis.net/def/serviceType/ogc/wfs/1.1.0> ;
dct:conformsTo <http://www.opengis.net/def/serviceType/ogc/wfs/1.0.0> ;
dct:description "This web service provides access to the National Judicial Courts dataset and presents the spatial locations of all the known Australian High Courts, Australian Federal Courts and the Australian Federal Circuit Courts located within Australia, all complemented with feature attribution." ;
dct:identifier "2b8540c8-4a42-144d-e053-12a3070a3ff7" ;
dct:title "National Judicial Courts WFS" ;
dct:type <http://purl.org/dc/dcmitype/Service> ;
dct:type <https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/download> ;
dcat:endpointDescription <http://services.ga.gov.au/gis/services/Judicial_Courts/MapServer/WFSServer?request=GetCapabilities&service=WFS> ;
dcat:endpointURL <http://services.ga.gov.au/gis/services/Judicial_Courts/MapServer/WFSServer> ;
dcat:landingPage <https://ecat.ga.gov.au/geonetwork/srv/eng/catalog.search#/metadata/2b8540c8-4a42-144d-e053-12a3070a3ff7> ;
dcat:servesDataset ga-courts:jc ;
.
ga-courts:jc-wms
rdf:type dcat:DataDistributionService ;
dct:conformsTo <http://www.opengis.net/def/serviceType/ogc/wms/1.3> ;
dct:description "This web service provides access to the National Judicial Courts dataset and presents the spatial locations of all the known Australian High Courts, Australian Federal Courts and the Australian Federal Circuit Courts located within Australia, all complemented with feature attribution." ;
dct:identifier "2b8540c8-4a41-144d-e053-12a3070a3ff7" ;
dct:title "National Judicial Courts WMS" ;
dct:type <http://purl.org/dc/dcmitype/Service> ;
dct:type <https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/view> ;
dcat:endpointDescription <http://services.ga.gov.au/gis/services/Judicial_Courts/MapServer/WMSServer?request=GetCapabilities&service=WMS> ;
dcat:endpointURL <http://services.ga.gov.au/gis/services/Judicial_Courts/MapServer/WMSServer> ;
dcat:landingPage <https://ecat.ga.gov.au/geonetwork/srv/eng/catalog.search#/metadata/2b8540c8-4a41-144d-e053-12a3070a3ff7> ;
dcat:servesDataset ga-courts:jc ;
.
5.10 More examples needed
Note
This section will contain more examples on the use of DCAT.
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 can 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 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.
The axiomatization of DCAT 2014 used global domain and range constraints for many of the properties defined in the DCAT namespace [VOCAB-DCAT-20140116]. 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, some of which are normative and some of which are only for guidance
additional axioms, which can be useful in some contexts
some profiles of DCAT, including a profile that corresponds to the 2014 version of DCAT [VOCAB-DCAT-20140116]
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].
The scope of DCAT 2014 was limited to catalogs of datasets [VOCAB-DCAT-20140116].
A number of use cases for the revision involve also having data 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 and Issue #116.
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]
A language of the catalog. This refers to the language used in the textual metadata describing titles, descriptions, etc. of the resources (i.e. datasets and services) 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 resource (e.g. dataset, or service) 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.
Models for the kind of license or rights representation indicated by the dct:license and dct:rights property are being considered as part of the revision of DCAT. See also License and rights statements.
Models for the kind of license or rights representation indicated by the dct:license and dct:rights property are being considered as part of the revision of DCAT. See also License and rights statements.
The need to be able to link a catalogued resource 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 production of a catalogued resource has been identified as a requirement to be satisfied in the revision of DCAT.
The class of all catalogued resources, the superclass of
dcat:Dataset, dcat:DataService, dcat:Catalog and any other member of a dcat:Catalog.
This class carries properties common to all catalogued resources, including datasets and data services.
It is strongly recommended to use a more specific sub-class when available.
Date of formal issuance (e.g., publication) of the item.
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 item 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 item, not a change to the catalog record. An absent value MAY indicate that the item has never changed after its initial publication, or that the date of last modification is not known, or that the item 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 item is available in multiple languages, use multiple values for this property. If each language is available separately for a dataset, 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 identifier might be used as part of the URI of the item, but still having it represented explicitly is useful.
6.4.8 Property: theme/category
Note
In DCAT 2014 [VOCAB-DCAT-20140116] 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.
A resource with an unspecified relationship to the catalogued item.
Usage note:
dct:relationSHOULD be used where the nature of the relationship between a catalogued item 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:distributionSHOULD be used to link from a dcat:Dataset to a representation of the dataset, described as a dcat:Distribution
Many existing and legacy catalogues do not distinguish between dataset components, representations, documentation, schemata and other resources that are lumped together as part of a dataset.
dct:relation is a super-property of a number of more specific properties which express more precise relationships, so use of dct: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.
The general need to describe relationships between datasets has been identified as a requirement to be satisfied in the revision of DCAT.
Guidance on the use of more specific relationship predicates is required, particularly in the context of the dcat:Dataset sub-class.
Note
Use of this Dublin Core Terms property in this context added in this revision of DCAT.
An established standard to which the described resource conforms.
Range:
dct:Standard (A basis for comparison; a reference point against which other things can be evaluated.)
6.4.12 Property: keyword/tag
Note
In DCAT 2014 [VOCAB-DCAT-20140116] 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-20140116] 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-20140116] 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 5.5Dataset available only behind some Web page)
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.
A record in a catalog, describing the registration of a single dataset or data service.
Usage note
This class is optional and not all catalogs will use it. It exists for catalogs where a distinction is made between metadata about
a dataset or service and metadata about the entry in the catalog about the dataset or service. For example, the publication date property of the dataset reflects
the date when the information was originally made available by the publishing agency, while the publication date of the catalog record is the date when the dataset was added to the catalog.
In cases where both dates differ, or where only the latter is known, the publication dateSHOULD 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.
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 (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]
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.
In addition to the properties inherited from the super-class dcat:DataService, the following properties are recommended for use on this class:
servesDataset,
A description of the service end-point, for example an OpenAPI (Swagger) description, an OGC getCapabilities response, a SD Service, an OpenSearch or WSDL document.
Information about licences and rights SHOULD be provided on the level of Distribution. Information about licences 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 licence 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.
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.
Note
Dataset citation is one of the requirements identified for the DCAT revision.
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 crediting those producing the data,
facilitating data discovery, supporting tracking the impact and reuse of data.
To support data citation, the dataset description should include at a minimum: the dataset identifier, the dataset creator (added in this DCAT revision
as part of the properties recommended for Dataset), the dataset title, the dataset publisher and the dataset release date.
The constraints on the availability of such properties in the dataset description can be represented as a DCAT data citation profile.
See the wiki page on Data Citation for more discussion.
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.
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.
Issue #81 concerns the general need to describe relationships between datasets.
Guidance on the use of specializations of dct:relation is required in the context of dcat:Dataset.
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 structured way has been identified as a requirement to be satisfied in the revision of DCAT.
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
New property in this context in this revision of DCAT.
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.9 Class: Discovery Service
In addition to the properties inherited from the super-class dcat:DataDistributionService, the following properties are recommended for use on this class: none yet
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.
A specific representation of a dataset. A dataset might be available in several different forms,
and these forms might comprise both different serializations or different schematic arrangements of the same data.
Examples of distributions include a CSV file, a netCDF file, or a data-cube
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.
The scope of dcat:Distribution here is narrower than in DCAT-2014 [VOCAB-DCAT-20140116], where it also included APIs and feeds.
Data catalogues designed using DCAT-2014 therefore used instances of type dcat:Distribution to describe data distribution services.
Applications consuming DCAT should be aware that catalogues designed using DCAT-2014 might use dcat:Distribution to represent both services and representations.
Under the revised scope, instances of type dcat:Distribution SHOULD be limited to representations of datasets which might be transported as files, and SHOULD NOT be used for data services such as APIs or feeds. Data services including APIs and feeds SHOULD be described using instances of type dcat:DataService whose sub-class dcat:DataDistributionServiceMAY serve dcat:Distributions.
The definition text of dcat:Distribution has been revised to clarify that distributions are primarily representations of datasets. As such, all distributions of a given dataset should be informationally equivalent.
The intention of the phrase "informationally equivalent" needs to be clarified, in particular as different serializations may have different expressivity.
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]
Models for the kind of license or rights representation indicated by the dct:license and dct:rights property are being considered as part of the revision of DCAT. See also License and rights statements.
Information about licences and rights SHOULD be provided on the level of Distribution. Information about licences 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 licence 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.
Models for the kind of license or rights representation indicated by the dct:license and dct:rights property are being considered as part of the revision of DCAT. See also License and rights statements.
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.
Information about licences and rights SHOULD be provided on the level of Distribution. Information about licences 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 licence 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.
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).
dcat:accessURLSHOULD be used for the address 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 landingPage address associated with the dcat:Dataset SHOULD be duplicated as accessURL on a distribution. (see 5.5Dataset available only behind some Web page)
dcat:accessURL generally matches the property-chain dcat:accessService/dcat:endpointURL. In the RDF representation of DCAT this is axiomatized as an OWL property-chain axiom.
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 dct:format and/or dcat:mediaType
An established standard to which the described resource conforms.
Range:
dct: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 conforms to. This is (generally) a complementary concern to the media-type or format.
dct:Standard is defined as "A basis for comparison; a reference point against which other things can be evaluated." It is not restricted to formal standards issued by bodies like ISO and W3C. In this context it will usually be used for a schema, ontology, data model or profile which specifies the structure of a dataset. This is not necessarily tied to a single encoding or serialization.
6.10.12 Property: media type
Note
The range of dcat:mediaType has been tightened from dct:MediaTypeOrExtent to dct:MediaType as part of the revision of DCAT.
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
[FOAF] provides sufficient properties to describe these entities.
7. Quality information
This section is non-normative.
Note
This section is not-normative as it provides guidance on how to document the quality of DCAT first class entities (e.g., datasets, distributions) and it does not define new DCAT terms. The guidance relies on the Data Quality Vocabulary(DQV)[VOCAB-DQV], which is a W3C Group Note.
The Data Quality Vocabulary (DQV) offers common modelling 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 [ISOIEC25012] and Zaveri et al. [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 the Data Quality Vocabulary (DQV) group note [VOCAB-DQV].
Note
The following examples make no comments on where the quality information would reside and how it is managed. That is out of scope for the DCAT vocabulary. The assumption made is that the quality individuals are available using the URIs indicated.
Besides, the examples and more in general the DQV is neutral to the data portal design choices on how to collect quality information. For example, data portals can collect DQV instances by implementing specific UI to annotate data or by taking inputs from 3rd-party services.
We might want to include examples of quality documentation related to services.
7.1 Providing quality information
A data consumer (:consumer1) describes the quality of the dataset :genoaBusStopsDataset that includes a georeferenced list of bus stops in Genoa. He/she annotates the dataset with a DQV quality note (:genoaBusStopsDatasetCompletenessNote) about data completeness (ldqd:completeness) to warn that the dataset includes only 20500 out of the 30000 stops.
:genoaBusStopsDataset a dcat:Dataset ;
dqv:hasQualityAnnotation :genoaBusStopsDatasetCompletenessNote .
:genoaBusStopsDatasetCompletenessNote
a dqv:UserQualityFeedback ;
oa:hasTarget :genoaBusStopsDataset ;
oa:hasBody :textBody ;
oa:motivatedBy dqv:qualityAssessment ;
prov:wasAttributedTo :consumer1 ;
prov:generatedAtTime "2018-05-27T02:52:02Z"^^xsd:dateTime ;
dqv:inDimension ldqd:completeness
.
:textBody a oa:TextualBody ;
rdf:value "Incomplete dataset: it contains only 20500 out of 30000 existing bus stops" ;
dc:language "en" ;
dc:format "text/plain"
.
The activity :myQualityChecking employs the service :myQualityChecker to check the quality of the :genoaBusStopsDataset dataset. The metric :completenessWRTExpectedNumberOfEntities is applied to measure the dataset completeness (ldqd:completeness) and it results in the quality measurement :genoaBusStopsDatasetCompletenessMeasurement.
:genoaBusStopsDataset
dqv:hasQualityMeasurement :genoaBusStopsDatasetCompletenessMeasurement .
:genoaBusStopsDatasetCompletenessMeasurement
a dqv:QualityMeasurement ;
dqv:computedOn :genoaBusStopsDataset ;
dqv:isMeasurementOf :completenessWRTExpectedNumberOfEntities ;
dqv:value "0.6833333"^^xsd:decimal ;
prov:wasAttributedTo :myQualityChecker ;
prov:generatedAtTime "2018-05-27T02:52:02Z"^^xsd:dateTime ;
prov:wasGeneratedBy :myQualityChecking
.
:completenessWRTExpectedNumberOfEntities
a dqv:Metric ;
skos:definition "it returns the degree of completeness as ratio between the actual number of entities included in the dataset and the declared expected number of entities."@en ;
dqv:expectedDataType xsd:decimal ;
dqv:inDimension ldqd:completeness .
# :myQualityChecker is a service computing some quality metrics
:myQualityChecker
a prov:SoftwareAgent ;
rdfs:label "A quality assessment service"^^xsd:string .
# Further details about quality service/software can be provided, for example,
# deploying vocabularies such as Dataset Usage Vocabulary (DUV), Dublin Core or ADMS.SW
# :myQualityChecking is the activity that has generated :genoaBusStopsDatasetCompletenessMeasurement from :genoaBusStopsDataset
:myQualityChecking
a prov:Activity;
rdfs:label "The checking of genoaBusStopsDataset's quality"^^xsd:string;
prov:wasAssociatedWith :myQualityChecker;
prov:used :genoaBusStopsDataset;
prov:generated :genoaBusStopsDatasetCompletenessMeasurement;
prov:endedAtTime "2018-05-27T02:52:02Z"^^xsd:dateTime;
prov:startedAtTime "2018-05-27T00:52:02Z"^^xsd:dateTime .
The issue suggests to represent "the degree a dataset conforms to a stated quality standard" and "the details of data quality conformance test results". This section is a starter to deal with the above requests by relying on the existing W3C vocabularies.
Comments and suggestions about the following examples as well as the proposal of alternative patterns are more than welcome.
This subsection shows different modelling patterns combining DQV [VOCAB-DQV] with PROV [PROV-O] and EARL [EARL10-Schema] to represent the conformance degree to a stated quality standard and the details about the conformance tests.
7.2.1 Conformance to a standard
The use of dct:conformsTo and dct:Standard is a well-known pattern to represent the conformance to a standard. The following example declares a fictional a:Dataset conformant to the "Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC".
a:Dataset a dcat:Dataset;
dct:conformsTo <http://data.europa.eu/eli/reg/2014/1312/oj> .
# Reference standard / specification
<http://data.europa.eu/eli/reg/2014/1312/oj> a dct:Standard ;
dct:title "Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services"@en
dct:issued "2010-11-23"^^xsd:date .
7.2.2 Degree of conformance
Some legal context requires to specify the degree of conformance. For example, INSPIRE metadata adopts a specific controlled vocabulary to express non-conformance and non-evaluation beside the full compliance. As suggested in [GeoDCAT-AP], the following example specifies the degree of conformance (i.e., not conformant) by declaring the dct:type for the result of conformance test. [GeoDCAT-AP] suggests to use a PROV entity to model the conformance test (e.g., a:TestResult), a PROV activity to model the testing activity (e,g., a:TestingActivity), a PROV plan derived by the INSPIRE Directive to represent conformance test (e.g., a:ConformanceTest). A qualified PROV association binds the testing activity to the conformance test.
a:Dataset a dcat:Dataset ;
prov:wasUsedBy a:TestingActivity .
a:TestingActivity a prov:Activity ;
prov:generated a:TestResult ;
prov:qualifiedAssociation [
a prov:Association ;
# http://validator.example.org/ is the agent who did the test.
prov:agent <http://validator.example.org/>
#following the plan a:ConformanceTest
prov:hadPlan a:ConformanceTest
] .
# Conformance test result
a:TestResult a prov:Entity ;
dcterms:type <http://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity/notConformant> .
a:ConformanceTest a prov:Plan ;
# Here you can specify additional information on the test
prov:wasDerivedFrom <http://data.europa.eu/eli/reg/2014/1312/oj> .
Also, DQV [VOCAB-DQV] can be deployed to measure the compliance to a specific standard. In the following, the :levelOfComplianceToINSPIRE is a quality metrics which measures the compliance of a dataset to INSPIRE in terms of the percentage of passed compliance tests. The example assumes iso as a namespace representing the quality dimensions and categories defined in the ISO/IEC 25012.
:levelOfComplianceToINSPIRE
a dqv:Metric ;
skos:definition "It returns the degree of compliance to INSPIRE defined as the percentage of passed compleance tests."@en
dqv:expectedDataType xsd:double ;
dqv:inDimension iso:compliance .
iso:compliance
a dqv:Dimension ;
skos:prefLabel "Compliance"@en ;
skos:definition "The degree to which data has attributes that adhere to standards, conventions or regulations in force and similar rules relating to data quality in a specific context of use."@en ;
dqv:inCategory iso:InherentandSystemDependentDataQuality
.
iso:inherentandSystemDependentDataQuality
a dqv:Category ;
skos:prefLabel "Inherent and System-Dependent Data Quality"@en.
The quality measurement :measurement_complianceToINSPIRE represents the level of compliance for a dataset a:Dataset, namely, measurement of the metric :levelOfComplianceToINSPIRE. If only a part of the compliance tests succeeds (e.g. half of the compliance tests), the measurement would look like in the following:
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.
The following example describes the Testing activity a:TestingActivity as an EARL Assertion instead of a qualified association on the PROV activity. The EARL Assertion states the dataset a:Dataset has been tested with the conformance test a:ConformanceTest, and it has passed the test as described in a:testResult.
a:assertion a earl:Assertion;
earl:subject a:Dataset;
earl:test a:ConformanceTest;
earl:result a:testResult ;
# let's indicate if the test was manual, automatic, or what ..
earl:mode earl:automatic ;
earl:assertedBy <http://validator.example.org/> ;
prov:wasAttributedTo <http://validator.example.org/>.
a:ConformanceTest a earl:TestRequirement, prov:Plan;
dct:title "Set of conformance test derived by the Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services"@en";
# it includes different subtests
dct:hasPart a:test1, a:test2, ..., a:testn.
#It is derived by the reference standard
prov:wasDerivedFrom <http://data.europa.eu/eli/reg/2014/1312/oj>.
a:testResult a earl:TestResult;
# results in conformancy.
dcterms:type <http://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity/conformant>;
#the overall set of tests have been passed
earl:outcome earl:passed .
];
# the description of the validator
<http://validator.example.org/> a earl:Assertor, prov:Agent ;
dcterms:description "A test execution service that runs conformance test suites."@en ;
dcterms:title "Validator"@en .
#the testing activity
a:TestingActivity a prov:Activity;
prov:generated a:TestAssertion, a:TestResult;
prov:use a:Dataset ;
prov:wasAssociatedWith <http://validator.example.org/> .
The following example shows how the description would have looked like if the subtest a:testq1 had failed. In particular, dcterms:description and earl:info provide additional warnings or error messages in a human-readable form.
a:assertion1 a earl:Assertion ;
earl:subject a:Dataset ;
earl:test a:testq1 ;
earl:result [
a earl:TestResult;
# results in no conformancy.
dcterms:type <http://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity/notConformant>
#the overall set of tests have not been passed (!?)
dcterms:date "2015-09-29T11:50:00+00:00"^^xsd:dateTime ;
# Some XML encoding of the error
dcterms:description """
<ul xmlns="http://www.w3.org/1999/xhtml">
<li> test 1 has failed. Some description of the errors found</li>
</ul>"^^rdf:XMLLiteral;
earl:info """"
<test-method duration-ms="47" finished-at="2015-09-29T11:50:00Z"
name="validate" signature="validate()" started-at="2015-09-29T11:50:00Z"
status="FAIL">
<exception class="java.lang.AssertionError">
<message>
Total validation errors found: 2
</message>
</exception>
</test-method>"""^^rdf:XMLLiteral;
earl:outcome earl:fail .
];
# we do not know if the test was manual, automatic, or what ..
earl:mode earl:automatic.
Depending on the details required about tests, DQV can express the testing activity and errors as well. In the following, :error is a quality annotation that represents the previous error, and a:testResult is defined as a DQV quality metadata to collect the above annotations and the compliance measurements providing provenance information.
:error
a dqv:QualityAnnotation ;
#this annotation is derived by the measurement
prov:wasGeneratedBy a:TestingActivity;
oa:hasTarget a:Dataset ;
oa:hasBody [
#errors/failed test description
a oa:TextualBody;
rdf:value """<test-method duration-ms="47" finished-at="2015-09-29T11:50:00Z"
name="validate" signature="validate()" started-at="2015-09-29T11:50:00Z"
status="FAIL">
<exception class="java.lang.AssertionError">
<message>
Total validation errors found: 2
</message>
</exception>
</test-method>"""^^rdf:XMLLiteral ;
#it can be in any format suppored by dc
dct:format "text/xml"
]
oa:motivatedBy dqv:qualityAssessment, oa:assessing ;
dqv:inDimension iso:compliance
.
a:TestResult
a dqv:QualityMetadata ;
# change the the dcterms:type according to the resulted compliance
dcterms:type <http://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity/conformant> ;
prov:wasAttributedTo <http://validator.example.org/> ;
prov:generatedAtTime "2018-05-27T02:52:02Z"^^xsd:dateTime ;
prov:wasGeneratedBy a:TestingActivity .
# The graph contains the rest of the statements presented in the previous examples.
a:testResult {
a:Dataset
dqv:hasQualityMeasurement :measurement_complianceToINSPIRE;
dqv:hasQualityAnnotation :errors .
}
#the testing activity
a:TestingActivity a prov:Activity;
prov:generated a:TestResult;
prov:use a:Dataset ;
prov:wasAssociatedWith <http://validator.example.org/>
.
Of course, the above modelling patterns can represent any quality tests not only conformance to standards.
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 the wiki page on Provenance Patterns for more discussion.
9. License and rights statements
Note
DCAT 2014 handling of license and rights do not appear to satisfy all requirements [VOCAB-DCAT-20140116].
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 the wiki page on License and rights 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 the wiki page on Dataset versioning for more discussion.
Schema.org [SCHEMA-ORG] includes a number of types and properties based on the original DCAT work (see schema:Dataset as a starting point),
and the index for Google's Dataset Search service relies on structured description in web pages about datasets based on both
schema.org and DCAT.
Most general purpose web search services that pay attention to metadata at all rely primarily on schema.org, so the detailed relationship of DCAT to schema.org is of interest for data providers
who wish their datasets and services to be exposed through those indexes.
A recommended mapping from the revised DCAT (this document) to schema.org is available in an RDF file.
This mapping is axiomatized using the standard predicates rdfs:subClassOf, rdfs:subPropertyOf, owl:equivalentClass, owl:equivalentProperty, and also using the
annotation properties schema:domainIncludes and schema:rangeIncludes to match schema.org semantics. The mapping is summarized in the table below, considering the prefix schema as http://schema.org/.
This alignment of DCAT with schema.org is provisional and non-normative. Feedback is invited in the issue tracker.
DCAT element
mapping property
target element from schema.org
dct:description
owl:equivalentProperty
schema:description
dct:format
owl:equivalentProperty
schema:encodingFormat
dct:identifier
owl:equivalentProperty
schema:identifier
dct:issued
owl:equivalentProperty
schema:datePublished
dct:language
owl:equivalentProperty
schema:inLanguage
dct:license
owl:equivalentProperty
schema:license
dct:modified
owl:equivalentProperty
schema:dateModified
dct:publisher
owl:equivalentProperty
schema:publisher
dct:spatial
owl:equivalentProperty
schema:spatialCoverage
dct:temporal
owl:equivalentProperty
schema:temporalCoverage
dct:title
owl:equivalentProperty
schema:name
dct:type
owl:equivalentProperty
schema:additionalType
dcat:Catalog
owl:equivalentClass
schema:DataCatalog
dcat:DataService
owl:equivalentClass
schema:DataFeed
Unclear if a DataFeed is a data service, or a data collection. From a REST viewpoint there is no difference, but some commonly used APIs support additional queries, slices, etc which make the characterization of a service more efficient than listing the (potentially infinite) set of resources available from it.
DCAT provides a generic metadata vocabulary for cataloguing datasets.
Profiles of DCAT are required for specific applications and disciplines.
Providing a model and formalization for profiles is planned to be an important part of the Dataset eXchange Working Group (DXWG).
Also see Issue #73, Issue #74, Issue #75.
DCAT should be aligned with other recent Linked Data based Recommendations.
14.1 Linked Data Platform (LDP)
DCAT provides a data model for representation of metadata about datasets in the form of Linked Data, but it does not specify how this metadata can be accessed or modified.
The DCAT compatible metadata can be viewed as collections of Catalog Records, Datasets and Data Services contained in a Catalog, and a collection of Distributions contained in a Dataset.
The Linked Data Platform [LDP] specification deals with access to and modification of Linked Data Platform Containers (LDPCs).
This section provides guidance on how to represent DCAT metadata as LDP Containers, which supports namely the implementation of Solid based DCAT catalogs.
First, we will present an example of a LDPC for datasets in a catalog.
There is one catalog with one dataset.
The dataset is contained in the </datasets/> LDP Direct Container.
To ensure the LDPC discovery, we connect it to the Catalog using the dcat:datasets predicate.
In the second example, we add LDPCs </records/> for Catalog Records and </services/> for Data Services, discoverable using dcat:records and dcat:services predicates from the Catalog:
Each dataset has its own LDPC for its distributions.
In the third example, we show the LDPC </datasets/001/distributions/> for distributions of a single dataset, </datasets/001>, discoverable through the dcat:distributions predicate.
For catalogs with many datasets, catalog records, data services or distributions,
the Linked Data Platform Paging mechanism [LDP-Paging] SHOULD be used to provide access to them.
In the next sections we formally define the additional properties used for discovery of LDP containers.
Linked Data Notifications (LDN) [LDN] can be used with DCAT e.g. for feedback collection.
Any resource can have an LDN Inbox.
In the following example we show a dataset </datasets/001> as an LDN Target with an LDN Inbox.
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.
C.1 Changes since the W3C Recommendation of 16 January 2014
The document has undergone the following changes since the W3C Recommendation of 16 January 2014 [VOCAB-DCAT-20140116]:
Property: dataset creator: The property dct:creator is recommended for use in the context of a dataset to allow the entity responsible for generating the dataset to be recorded - see Issue #61
Property: was generated by: The property prov:wasGeneratedBy is recommended for use in the context of a dataset to allow the provenance or business context to be recorded - see Issue #71
Property: resource relation: The property dct:relation is recommended for use in the context of a catalogued resource to capture general relationships, including the case where the package of resources associated with a catalogued item includes a mixture of representations, parts, documentation and other elements which are not strictly 'distributions' of a dataset - see Issue #253.
Property:media_type: The range of dcat:mediaType has been tightened from dct:MediaTypeOrExtent to dct:MediaType - see Issue #127.
Property: conforms to: The property dct:conformsTo is recommended for use in the context of a dcat:Distribution to allow the model or schema used for the representation to be indicated as well as the serialization (which is indicated using dct:format and dcat:mediaType) - see Issue #55.
Quality information: Recommendations for how to associate quality information to datasets using elements from the W3C DQV vocabulary [VOCAB-DQV] are provided. Since [VOCAB-DQV] is not a rec-track document, these are non-normative - see Issue #57 and Issue #58.
Class: Distribution
: In DCAT 2014 [VOCAB-DCAT-20140116] the definition of a dcat:Distribution allowed a number of alternative interpretations. The definition has been rephrased to clarify that distributions are primarily representations of datasets. See Issue #52 and related use cases.
Property: theme/category:
In DCAT 2014 [VOCAB-DCAT-20140116] 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-20140116] 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-20140116] 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-20140116] 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.
Property: vann:usageNote:
DCAT 2014 [VOCAB-DCAT-20140116] included documentation captured as text using vann:usageNote elements,
which is a sub-property of rdfs:seeAlso - an owl:ObjectProperty that cannot have a Literal value.
This revision of DCAT has fixed these issues and replaced the use of vann:usageNote with skos:scopeNote -
see Issue #233.
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
