Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://www.w3.org/TR/vocab-dcat-2/ below:

Data Catalog Vocabulary (DCAT) - Version 2

Note

DCAT 2 supersedes DCAT [VOCAB-DCAT-20140116], but it does not make it obsolete. DCAT 2 maintains the DCAT namespace as its terms preserve backward compatibility with DCAT [VOCAB-DCAT-20140116]. DCAT 2 relaxes constraints and adds new classes and properties, but these changes do not break the definition of previous terms.

Any new implementation is expected to adopt DCAT 2, while the existing implementations do not need to upgrade to it, unless they want to use the new features. In particular, current DCAT deployments that do not overlap with the DCAT 2 new features (e.g., data services, time and space properties qualified relations, packaging) don't need to change anything to remain in conformance with DCAT 2.

DCAT is an RDF vocabulary designed to facilitate interoperability between data catalogs published on the Web. This document defines the schema and provides examples for its use.

DCAT enables a publisher to describe datasets and data services in a catalog using a standard model and vocabulary that facilitates the consumption and aggregation of metadata from multiple catalogs. This can increase the discoverability of datasets and data services. It also makes it possible to have a decentralized approach to publishing data catalogs and makes federated search for datasets across catalogs in multiple sites possible using the same query mechanism and structure. Aggregated DCAT metadata can serve as a manifest file as part of the digital preservation process.

The namespace for DCAT terms is 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 document was published by the Dataset Exchange Working Group as a Superseded Recommendation. A newer specification exists that is recommended for new adoption in place of this specification.

For purposes of the W3C Patent Policy, this Superseded Recommendation has the same status as an active Recommendation; it retains licensing commitments and remains available as a reference for old -- and possibly still deployed -- implementations, but is not recommended for future implementation. New implementations should follow the latest version of the Data Catalog Vocabulary (DCAT) specification.

This document defines a major revision of the original DCAT vocabulary ([VOCAB-DCAT-20140116]) in response to new use cases, requirements and community experience since that publication. This revision extends the original DCAT standard in line with community practice while supporting diverse approaches to data description and dataset exchange. The main changes to the DCAT vocabulary have been:

• loosening of constraints in class and property definitions to promote re-use of terms and modularity
• addition of a dcat:Resource class for representing any asset 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 catalog service end-points providing access to data assets
• addition of ways to represent loosely structured catalogs, where there is no distinction between a dataset and its distributions
• more details for the ways of representing dataset provenance and quality
• an alignment between the DCAT vocabulary and the schema.org vocabulary

This new version of the vocabulary updates and expands the original but preserves backward compatibility. A full list of the significant changes (with links to the relevent github issues) is described in § D. Change history.

The exit criteria for CR focussed on v2 new features that replicate features that were included in application profiles of v1 as a way of remedying missing and necessary elements. The exit criteria also included recent commitments by organisations such as EC Joinup to adopt the DCAT v2 model in their work. Implementation will be evidenced by showing use of the new properties/classes (or terms with equivalent meaning) in implementations of catalogs.

Issues, requirements, and features that have been considered and discussed by the Data eXchange Working Group but have not been addressed due to lack of maturity or consensus are collected in GitHub. Those believed to be a priority for a future release are in the milestone DCAT Future Priority Work.

The original DCAT vocabulary was developed and hosted at the Digital Enterprise Research Institute (DERI), then refined by the eGov Interest Group, and finally standardized in 2014 [VOCAB-DCAT-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] gathered from peoples' experience with the DCAT vocabulary from the time of the original version, and new applications that were not considered in the first version. A summary of the changes from [VOCAB-DCAT-20140116] is provided in § D. Change history.

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 in the DCAT vocabulary for convenience, while authoritative definitions are available in the normative references. Changes to definitions in the references, if any, supersede the summaries given in this specification. Note that conformance to DCAT (§ 4. Conformance) concerns usage of only the terms in the DCAT vocabulary specification, so possible changes to other external definitions will not affect the conformance of DCAT implementations.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 March 2019 W3C Process Document.

1. 1. Introduction
2. 2. Motivation for change
3. 3. Namespaces
   1. 3.1 Normative namespaces
   2. 3.2 Non-normative namespaces
4. 4. Conformance
5. 5. Vocabulary overview
   1. 5.1 DCAT scope
   2. 5.2 RDF considerations
   3. 5.3 Basic example
   4. 5.4 Classifying datasets thematically
   5. 5.5 Classifying dataset types
   6. 5.6 Describing catalog records metadata
   7. 5.7 Dataset available only behind some Web page
   8. 5.8 A dataset available as a download and behind some Web page
   9. 5.9 A dataset available through a service
6. 6. Vocabulary specification
   1. 6.1 RDF representation
   2. 6.2 Elements from other vocabularies
      1. 6.2.1 Complementary vocabularies
      2. 6.2.2 Element definitions
   3. 6.3 Class: Catalog
      1. 6.3.1 Property: homepage
      2. 6.3.2 Property: themes
      3. 6.3.3 Property: has part
      4. 6.3.4 Property: dataset
      5. 6.3.5 Property: service
      6. 6.3.6 Property: catalog
      7. 6.3.7 Property: catalog record
   4. 6.4 Class: Cataloged Resource
      1. 6.4.1 Property: access rights
      2. 6.4.2 Property: conforms to
      3. 6.4.3 Property: contact point
      4. 6.4.4 Property: resource creator
      5. 6.4.5 Property: description
      6. 6.4.6 Property: title
      7. 6.4.7 Property: release date
      8. 6.4.8 Property: update/modification date
      9. 6.4.9 Property: language
      10. 6.4.10 Property: publisher
      11. 6.4.11 Property: identifier
      12. 6.4.12 Property: theme/category
      13. 6.4.13 Property: type/genre
      14. 6.4.14 Property: resource relation
      15. 6.4.15 Property: qualified relation
      16. 6.4.16 Property: keyword/tag
      17. 6.4.17 Property: landing page
      18. 6.4.18 Property: qualified attribution
      19. 6.4.19 Property: license
      20. 6.4.20 Property: rights
      21. 6.4.21 Property: has policy
      22. 6.4.22 Property: is referenced by
   5. 6.5 Class: Catalog Record
      1. 6.5.1 Property: title
      2. 6.5.2 Property: description
      3. 6.5.3 Property: listing date
      4. 6.5.4 Property: update/modification date
      5. 6.5.5 Property: primary topic
      6. 6.5.6 Property: conforms to
   6. 6.6 Class: Dataset
      1. 6.6.1 Property: dataset distribution
      2. 6.6.2 Property: frequency
      3. 6.6.3 Property: spatial/geographical coverage
      4. 6.6.4 Property: spatial resolution
      5. 6.6.5 Property: temporal coverage
      6. 6.6.6 Property: temporal resolution
      7. 6.6.7 Property: was generated by
   7. 6.7 Class: Distribution
      1. 6.7.1 Property: title
      2. 6.7.2 Property: description
      3. 6.7.3 Property: release date
      4. 6.7.4 Property: update/modification date
      5. 6.7.5 Property: license
      6. 6.7.6 Property: access rights
      7. 6.7.7 Property: rights
      8. 6.7.8 Property: has policy
      9. 6.7.9 Property: access URL
      10. 6.7.10 Property: access service
      11. 6.7.11 Property: download URL
      12. 6.7.12 Property: byte size
      13. 6.7.13 Property: spatial resolution
      14. 6.7.14 Property: temporal resolution
      15. 6.7.15 Property: conforms to
      16. 6.7.16 Property: media type
      17. 6.7.17 Property: format
      18. 6.7.18 Property: compression format
      19. 6.7.19 Property: packaging format
   8. 6.8 Class: Data Service
      1. 6.8.1 Property: endpoint URL
      2. 6.8.2 Property: endpoint description
      3. 6.8.3 Property: serves dataset
   9. 6.9 Class: Concept Scheme
   10. 6.10 Class: Concept
   11. 6.11 Class: Organization/Person
   12. 6.12 Class: Relationship
       1. 6.12.1 Property: relation
       2. 6.12.2 Property: had role
   13. 6.13 Class: Role
   14. 6.14 Class: Period of Time
       1. 6.14.1 Property: start date
       2. 6.14.2 Property: end date
       3. 6.14.3 Property: beginning
       4. 6.14.4 Property: end
   15. 6.15 Class: Location
       1. 6.15.1 Property: geometry
       2. 6.15.2 Property: bounding box
       3. 6.15.3 Property: centroid
7. 7. Dereferenceable identifiers
   1. 7.1 Indicating common identifier types
8. 8. License and rights statements
9. 9. Time and space
   1. 9.1 Temporal properties
   2. 9.2 Spatial properties
10. 10. Versioning
11. 11. Data citation
12. 12. Quality information
    1. 12.1 Providing quality information
    2. 12.2 Documenting conformance to standards
       1. 12.2.1 Conformance to a standard
       2. 12.2.2 Degree of conformance
       3. 12.2.3 Conformance test results
13. 13. Qualified relations
    1. 13.1 Relationships between datasets and agents
    2. 13.2 Relationships between datasets and other resources
14. 14. DCAT Profiles
15. 15. Security and Privacy
16. A. Acknowledgments
17. B. Alignment with Schema.org
18. C. Examples
    1. C.1 Loosely structured catalog
    2. C.2 Dataset provenance
    3. C.3 Link datasets and publications
    4. C.4 Data services
    5. C.5 Compressed and packaged distributions
19. D. Change history
    1. D.1 Changes since the W3C Recommendation of 16 January 2014
20. E. References
    1. E.1 Normative references
    2. E.2 Informative references

This section is non-normative.

Sharing data resources among different organizations, researchers, governments and citizens requires the provision of metadata. This is irrespective of the data being open or not. DCAT is a vocabulary for publishing data catalogs on the Web, which was originally developed in the context of government data catalogs such as data.gov and data.gov.uk, but it is also applicable and has been used in other contexts.

This revision of DCAT has extended the previous version to support further use cases and requirements [DCAT-UCR]. These include the possibility of cataloging other resources in addition to datasets, such as data services. The revision also supports describing relationships between datasets as well as between datasets and other cataloged resources. Guidance on how to document licenses and rights statements associated with the cataloged items is provided.

DCAT provides RDF classes and properties to allow datasets and data services to be described and included in a catalog. The use of a standard model and vocabulary facilitates the consumption and aggregation of metadata from multiple catalogs, which can:

1. increase the discoverability of datasets and data services
2. allow federated search for datasets across catalogs in multiple sites

Data described in a catalog can come in many formats, ranging from spreadsheets, through XML and RDF to various specialized formats. DCAT does not make any assumptions about these serialization formats of the datasets but it does distinguish between the abstract dataset and its different manifestations or distributions.

Data is often provided through a service which supports selection of an extract, sub-set, or combination of existing data, or of new data generated by some data processing function. DCAT allows the description of a data access service to be included in a catalog.

Complementary vocabularies can be used together with DCAT to provide more detailed format-specific information. For example, properties from the VoID vocabulary [VOID] can be used within DCAT to express various statistics about a dataset if that dataset is in RDF format.

This document does not prescribe any particular method of deploying data catalogs expressed in DCAT. DCAT information can be presented in many forms including RDF accessible via SPARQL endpoints, embedded in HTML pages as [HTML-RDFa], or serialized as RDF/XML [RDF-SYNTAX-GRAMMAR], [N3], [Turtle], [JSON-LD] or other formats. Within this document the examples use [Turtle] because of its readability.

This section is non-normative.

The original Recommendation [VOCAB-DCAT-20140116] published in January 2014 provided the basic framework for describing datasets. It made an important distinction between a dataset as an abstract idea and a distribution as a manifestation of the dataset. Although DCAT has been widely adopted, it has become clear that the original specification lacked a number of essential features that were added either through the mechanism of a profile, such as the European Commission's DCAT-AP [DCAT-AP], or the development of larger vocabularies that to a greater or lesser extent built upon the base standard, such as the Healthcare and Life Sciences Community Profile [HCLS-Dataset], the Data Tag Suite [DATS] and more. This revision of DCAT has been developed to address the specific shortcomings that have come to light through the experiences of different communities, the aim being to improve interoperability between the outputs of these larger vocabularies. For example, in this new DCAT version we provide classes, properties and guidance to address identifiers, dataset quality information, and data citation issues.

This revision 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 § D. Change history.

The namespace for DCAT is http://www.w3.org/ns/dcat#. DCAT also makes extensive use of terms from other vocabularies, in particular Dublin Core [DCTERMS]. DCAT defines a minimal set of classes and properties of its own.

Namespaces and prefixes used in normative parts of this recommendation are shown in the following table.

This section is non-normative.

Namespaces and prefixes used in examples and guidelines in the document and not from normative parts of the recommendation are shown in the following table.

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, and SHOULD in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

A data catalog conforms to DCAT if:

• Access to data is organized into datasets, distributions, and data-services.
• An RDF description of the catalog itself, the corresponding cataloged resources, and distributions is available (but the choice of RDF syntax, access protocol, and access policy are not mandated by this specification).
• The contents of all metadata fields that are held in the catalog and that contain data about the catalog itself, the corresponding cataloged resources, and distributions are included in this RDF description and are expressed using the appropriate classes and properties from DCAT, except where no such class or property exists.
• All classes and properties defined in DCAT are used in a way consistent with the semantics declared in this specification.

A DCAT profile is a specification for a data catalog that adds additional constraints to DCAT. A data catalog that conforms to the profile also conforms to DCAT. Additional constraints in a profile MAY include:

• Cardinality constraints, including a minimum set of required metadata fields
• Sub-classes and sub-properties of the standard DCAT classes and properties
• Classes and properties for additional metadata fields not covered in DCAT vocabulary specification
• Controlled vocabularies or URI sets as acceptable values for properties
• Requirements for specific access mechanisms (RDF syntaxes, protocols) to the catalog's RDF description

Note

The notion of profile used in this document denotes metadata specifications that the Dublin Core community would call application profiles [DCAP].

This section is non-normative.

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

• dcat:Catalog represents a catalog, which is a dataset in which each individual item is a metadata record describing some resource; the scope of dcat:Catalog is collections of metadata about datasets or data services.
• dcat:Resource represents a dataset, a data service or any other resource that may be described by a metadata record in a catalog. This class is not intended to be used directly, but is the parent class of dcat:Dataset, dcat:DataService and dcat:Catalog. Member items in a catalog should be members of one of the sub-classes, or of a sub-class of these, or of a sub-class of dcat:Resource defined in a DCAT profile or other DCAT application. dcat:Resource is effectively an extension point for defining a catalog of any kind of resource. dcat:Dataset and dcat:DataService can be used for datasets and services which are not documented in any catalog.
• dcat:Dataset represents a dataset. A dataset is a collection of data, published or curated by a single agent. Data comes in many forms including numbers, words, pixels, imagery, sound and other multi-media, and potentially other types, any of which might be collected into a dataset.
• dcat:Distribution represents an accessible form of a dataset such as a downloadable file.
• dcat:DataService represents a data service. A data service is a collection of operations accessible through an interface (API) that provide access to one or more datasets or data processing functions.
• dcat:CatalogRecord represents a metadata item in the catalog, primarily concerning the registration information, such as who added the item and when.

Note

Along with the rest of § 5. 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 specified in the descriptions of classes in § 6. 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 (normative) 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 serializations or formats". A dataset is a conceptual entity, and can be represented by one or more distributions that serialize the dataset for transfer. Distributions of a dataset can be provided via data services.

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

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

Note

The scope of DCAT 2014 [VOCAB-DCAT-20140116] was limited to catalogs of datasets. A number of use cases for the revision [DCAT-UCR] involve data services as members of a catalog - see § 5.16 DCAT Distribution to describe Web services and § 5.18 Modeling service-based data access. Hence, the scope of this revision of DCAT includes both datasets and data services to enable these to be part of a DCAT conformant catalog. Provision for catalogs to be composed of other catalogs is also made. See Issue #172.

Catalogs of other kinds of things might be designed following the DCAT pattern, e.g. dealing with facilities, instruments, samples and specimens, other physical artefacts, events or activities. These are currently out of scope for DCAT, but might be defined through further sub-classes of dcat:Resource, which could be specified in a DCAT profile or other DCAT application.

A catalog record describes an entry in the catalog. Notice that while dcat:Resource represents the dataset or service itself, dcat:CatalogRecord is the record that describes the registration of 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 explicitly. If this is not necessary then dcat:CatalogRecord can be safely ignored.

The DCAT vocabulary is an OWL2 ontology [OWL2-OVERVIEW] formalized using [RDF-SCHEMA]. Each class and property in DCAT is denoted by an [IRI]. Locally defined elements are in the namespace http://www.w3.org/ns/dcat#. Elements are also adopted from several external vocabularies, in particular [FOAF], [DCTERMS] and [PROV-O]

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

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

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.

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

First, the catalog description:

:catalog
  a dcat:Catalog ;
  dct:title "Imaginary Catalog"@en ;
  rdfs:label "Imaginary Catalog"@en ;
  foaf:homepage <http://example.org/catalog> ;
  dct:publisher :transparency-office ;
  dct:language <http://id.loc.gov/vocabulary/iso639-1/en>  ;
  dcat:dataset :dataset-001  , :dataset-002 , :dataset-003 ;
  .

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

:transparency-office
  a foaf:Organization ;
  rdfs:label "Transparency Office"@en ;
  .

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

:dataset-001
  a dcat:Dataset ;
  dct:title "Imaginary dataset"@en ;
  dcat:keyword "accountability"@en, "transparency"@en, "payments"@en ;
  dct:creator :finance-employee-001 ;
  dct:issued "2011-12-05"^^xsd:date ;
  dct:modified "2011-12-15"^^xsd:date ;
  dcat:contactPoint <http://example.org/transparency-office/contact> ;
  dct:temporal <http://reference.data.gov.uk/id/quarter/2006-Q1> ;
  dcat:temporalResolution "P1D"^^xsd:duration ;
  dct:spatial <http://sws.geonames.org/6695072/> ;
  dcat:spatialResolutionInMeters "30.0"^^xsd:decimal ;
  dct:publisher :finance-ministry ;
  dct:language <http://id.loc.gov/vocabulary/iso639-1/en>  ;
  dct:accrualPeriodicity <http://purl.org/linked-data/sdmx/2009/code#freq-W>  ;
  dcat:distribution :dataset-001-csv ;
  .

Five distinct temporal descriptors are shown for this dataset. The dataset publication and revision dates are shown in dct:issued and dct:modified. For the frequency of update of the dataset in dct:accrualPeriodicity, we use an instance from the content-oriented guidelines developed as part of the W3C Data Cube Vocabulary [VOCAB-DATA-CUBE] efforts. The temporal coverage or extent is given in dct:temporal using an item from the Interval dataset (originally available from http://reference.data.gov.uk/id/interval) from data.gov.uk. The temporal resolution, which describes the minimum spacing of items within the dataset, is given in dcat:temporalResolution using the standard datatype xsd:duration.

Additionally, the spatial coverage or extent is given dct:spatial using a URI from Geonames. The spatial resolution, which describes the minimum spatial separation of items within the dataset, is given in dcat:spatialResolutionInMeters using the standard datatype xsd:decimal.

A contact point is provided where comments and feedback about the dataset can be sent. Further details about the contact point, such as email address or telephone number, can be provided using vCard [VCARD-RDF].

One representation of the dataset :dataset-001-csv can be downloaded as a 5kB CSV file. This is represented as 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"@en ;
  dcat:mediaType <https://www.iana.org/assignments/media-types/text/csv> ;
  dcat:byteSize "5120"^^xsd:decimal ;
  .

The catalog classifies its datasets according to a set of domains represented by the relative URI :themes. SKOS [SKOS-REFERENCE] 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"@en ;
  .

:dataset-001 dcat:theme :accountability  .

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

:accountability
  a skos:Concept ;
  skos:inScheme :themes ;
  skos:prefLabel "Accountability"@en ;
  .

The type or genre of a dataset can be indicated using the dct:type property. It is recommended that the value of the property is taken from a well governed and broadly recognised set of resource types, such as the DCMI Type Vocabulary [DCTERMS], the MARC Genre/Terms Scheme, the [ISO-19115-1] MD_Scope codes, the DataCite resource types, or the PARSE.Insight content-types from Re3data [RE3DATA-SCHEMA].

In the following examples, a (notional) dataset is classified separately using values from different vocabularies.

:dataset-001
  rdf:type  dcat:Dataset ;
  dct:type  <http://purl.org/dc/dcmitype/Text> ;
  .

:dataset-001
  rdf:type  dcat:Dataset ;
  dct:type  <http://id.loc.gov/vocabulary/marcgt/man> ;
  .

It is also possible for multiple classifications to be present in a single description.

:dataset-001
  rdf:type  dcat:Dataset ;
  dct:type  <http://purl.org/dc/dcmitype/Text> ;
  dct:type  <http://id.loc.gov/vocabulary/marcgt/man> ;
  dct:type  <http://registry.it.csiro.au/def/datacite/resourceType/Text> ;
  dct:type  <http://registry.it.csiro.au/def/re3data/contentType/doc> ;
.

<http://registry.it.csiro.au/def/datacite/resourceType/Text>
  rdfs:label "Text"@en ;
  dct:source "DataCite resource types"@en ;
  .

<http://registry.it.csiro.au/def/re3data/contentType/doc>
  rdfs:label "Standard office documents"@en ;
  dct:source "Re3data content types"@en ;
  .

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 Example 9:

:catalog  dcat:record :record-001  .

:record-001
  a dcat:CatalogRecord ;
  foaf:primaryTopic :dataset-001  ;
  dct:issued "2011-12-11"^^xsd:date  ;
  .

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

:dataset-002
  a dcat:Dataset ;
  dcat:landingPage <http://example.org/dataset-002.html> ;
  dcat:distribution :dataset-002-csv ;
  .
:dataset-002-csv
  a dcat:Distribution ;
  dcat:accessURL <http://example.org/dataset-002.html> ;
  dcat:mediaType <https://www.iana.org/assignments/media-types/text/csv> ;
  .

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

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

:dataset-003
  a dcat:Dataset ;
  dcat:landingPage <http://example.org/dataset-003.html> ;
  dcat:distribution :dataset-003-csv ;
  .
:dataset-003-csv
  a dcat:Distribution ;
  dcat:downloadURL <http://example.org/dataset-003.csv> ;
  dcat:mediaType <https://www.iana.org/assignments/media-types/text/csv> ;
  .

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.

:dataset-004 is distributed in different representations from different services. The dcat:accessURL for each dcat:Distribution corresponds with the dcat:endpointURL of the service. Each service is characterized by its general type using dct:type (here using values from the INSPIRE spatial data service type vocabulary), its specific API definition using dct:conformsTo, with the detailed description of the individual endpoint parameters and options linked using dcat:endpointDescription.

:dataset-004
  rdf:type dcat:Dataset ;
  dcat:distribution :dataset-004-csv ;
  dcat:distribution :dataset-004-png ;
  .

:dataset-004-csv
  rdf:type dcat:Distribution ;
  dcat:accessService :table-service-005 ;
  dcat:accessURL <http://example.org/api/table-005> ;
  dcat:mediaType <https://www.iana.org/assignments/media-types/text/csv> ;
  .

:dataset-004-png
  rdf:type dcat:Distribution ;
  dcat:accessService :figure-service-006 ;
  dcat:accessURL <http://example.org/api/figure-006> ;
  dcat:mediaType <https://www.iana.org/assignments/media-types/image/png> ;
  .

:figure-service-006
  rdf:type dcat:DataService ;
  dct:conformsTo <http://example.org/apidef/figure/v1.0> ;
  dct:type <https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/view> ;
  dcat:endpointDescription <http://example.org/api/figure-006/params> ;
  dcat:endpointURL <http://example.org/api/figure-006> ;
  dcat:servesDataset :dataset-004 ;
  .

:table-service-005
  rdf:type dcat:DataService ;
  dct:conformsTo <http://example.org/apidef/table/v2.2> ;
  dct:type <https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/download> ;
  dcat:endpointDescription <http://example.org/api/table-005/capability> ;
  dcat:endpointURL <http://example.org/api/table-005> ;
  dcat:servesDataset :dataset-003, :dataset-004 ;
  .

The (revised) DCAT vocabulary is available in RDF. The primary artefact dcat2.ttl is a serialization of the core DCAT vocabulary. Alongside it are a set of other RDF files that provide additional information, including:

1. non-normative alignments to other vocabularies, provided for guidance
2. additional axioms, which can be useful in some contexts
3. the files dcat2014.ttl and dcat2014.rdf that correspond to the 2014 version of DCAT [VOCAB-DCAT-20140116]

DCAT requires use of elements from a number of other vocabularies. Furthermore, DCAT may be augmented by additional elements from external vocabularies, following the usual RDFS [RDF-SCHEMA] and OWL2 [OWL2-OVERVIEW] rules and patterns.

Elements from a number of complementary vocabularies MAY be used together with DCAT to provide more detailed information. For example: properties from the VoID vocabulary [VOID] allow the description of various statistics about a DCAT-described dataset if that dataset is in RDF format; properties from the Provenance ontology [PROV-O] can be used to provide more information about the workflow that generated a dataset or service and related activities and agents; classes and properties from the Organization Ontology [VOCAB-ORG] can be used to explain additional details of responsible agents.

The definitions (including domain and range) of terms outside the DCAT namespace are provided here only for convenience and MUST NOT be considered normative. The authoritative definitions of these terms are in the corresponding specifications, i.e. [DC11], [DCTERMS], [FOAF], [PROV-O], [RDF-SCHEMA], [SKOS-REFERENCE], [XMLSCHEMA11-2] and [VCARD-RDF].

Note

The scope of DCAT 2014 was catalogs of datasets [VOCAB-DCAT-20140116]. This has been generalized, and properties common to all cataloged resources are now associated with a super-class dcat:Resource.

Moreover, an explicit class for data services has been added in this revision of DCAT, to enable these to be part of a catalog.

Finally, dcat:Catalog has been made a sub-class of dcat:Dataset, and provision for catalogs to be composed of other catalogs is also enabled.

See Issue #116 and Issue #172.

The following properties are specific to this class: catalog record, has part, dataset, service, catalog, homepage, themes.

The following properties are inherited from the super-class dcat:Dataset: distribution, frequency, spatial/geographic coverage, spatial resolution, temporal coverage, temporal resolution, was generated by.

The following properties are inherited from the super-class dcat:Resource: access rights, conforms to, contact point, creator, description, has policy, identifier, is referenced by, keyword/tag, landing page, license, catalog language, relation, rights, qualified relation, publisher, release date, theme/category, title, type/genre, update/modification date, qualified attribution.

Note

Property added in this context in this revision of DCAT.

Note

New property added in this revision of DCAT.

Note

New property added in this revision of DCAT.

Note

New class added in this revision of DCAT.

The following properties are specific to this class: access rights, conforms to, contact point, creator, description, has policy, identifier, is referenced by, keyword/tag, landing page, license, resource language, relation, rights, qualified relation, publisher, release date, theme/category, title, type/genre, update/modification date, qualified attribution.

Note

Property added in this revision of DCAT.

Note

Property added in this revision of DCAT.

Note

dct:Standard is defined in [DCTERMS] as "A basis for comparison; a reference point against which other things can be evaluated." The target resource is not restricted to formal standards issued by bodies like ISO and W3C. In this context, it is any resource that specifies one or more aspects of the cataloged resource content, for example schema, semantics, syntax, usage guidelines, file format, or specific serialization. The meaning of conformance is determined by provisions in the target standard.

Note

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.

Note

Property added in this revision of DCAT, specifically to address data citation requirements.

dct:LinguisticSystem

Resources defined by the Library of Congress (ISO 639-1, ISO 639-2) SHOULD be used.

If a ISO 639-1 (two-letter) code is defined for language, then its corresponding IRI SHOULD be used; if no ISO 639-1 code is defined, then IRI corresponding to the ISO 639-2 (three-letter) code SHOULD be used.

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.

Note

Property added in this revision of DCAT. See Issue #64.

1. DCMI Type vocabulary [DCTERMS]
2. [ISO-19115-1] scope codes
3. Datacite resource types [DataCite]
4. PARSE.Insight content-types used by re3data.org [RE3DATA-SCHEMA] (see item 15 contentType)
5. MARC intellectual resource types

Note

Property added in this revision of DCAT.

Many existing and legacy catalogs do not distinguish between dataset components, representations, documentation, schemata and other resources that are lumped together as part of a dataset. 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.

Note

New property added in this revision of DCAT.

This DCAT property follows the common qualified relation pattern described in § 13. Qualified relations .

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.

Note

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.

Note

Property added in this context in this revision of DCAT.

This DCAT property follows the common qualified relation pattern described in § 13. Qualified relations .

Note

Use of this property on an individual entails that the context resource is a member of the class prov:Entity [PROV-O].

Note

Property added in this revision of DCAT.

Note

Property added in this revision of DCAT.

For examples on the use of this property, see § C.3 Link datasets and publications.

The following properties are specific to this class (dcat:CatalogRecord): conforms to, description, listing date, primary topic, title, update/modification date.

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.

Note

Property added in this context in this revision of DCAT.

Note

dct:Standard is defined in [DCTERMS] as "A basis for comparison; a reference point against which other things can be evaluated." The target resource is not restricted to formal standards issued by bodies like ISO and W3C. In this context, it is any resource that specifies one or more aspects of the catalog record content, for example schema, semantics, syntax, usage guidelines, file format, or specific serialization. The meaning of conformance is determined by provisions in the target standard.

The following properties are specific to this class: distribution, frequency, spatial/geographic coverage, spatial resolution, temporal coverage, temporal resolution, was generated by.

The following properties are inherited from the super-class dcat:Resource: access rights, conforms to, contact point, creator, description, has policy, identifier, is referenced by, keyword/tag, landing page, license, resource language, relation, rights, qualified relation, publisher, release date, theme/category, title, type/genre, update/modification date, qualified attribution.

Information about licenses and rights SHOULD be provided on the level of Distribution. Information about licenses and rights MAY be provided for a Dataset in addition to but not instead of the information provided for the Distributions of that Dataset. Providing license or rights information for a Dataset that is different from information provided for a Distribution of that Dataset SHOULD be avoided as this can create legal conflicts.

Examples showing how dct:accrualPeriodicity and dcat:temporalResolution may be combined are given in § 9.1 Temporal properties.

Options for expressing the details of a dct:Location are provided in § 6.15 Class: Location.

Note

New property added in this revision of DCAT.

The range of this property is a decimal number representing a length in meters. This is intended to provide a summary indication of the spatial resolution of the data as a single number. More complex descriptions of various aspects of spatial precision, accuracy, resolution and other statistics can be provided using the Data Quality Vocabulary [VOCAB-DQV].

Options for expressing the details of a dct:PeriodOfTime are provided in § 6.14 Class: Period of Time.

Note

New property added in this revision of DCAT.

This is intended to provide a summary indication of the temporal resolution of the data distribution as a single value. More complex descriptions of various aspects of temporal precision, accuracy, resolution and other statistics can be provided using the Data Quality Vocabulary [VOCAB-DQV].

The distinction between dcat:temporalResolution and dct:accrualPeriodicity is illustrated by examples in § 9.1 Temporal properties.

Note

Property added in this context in this revision of DCAT.

Note

Use of this property on an individual entails that the context resource is a member of the class prov:Entity [PROV-O] .

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.

The following properties are specific to this class: access rights, access URL, access service, byte size, compression format, conforms to, description, download URL, format, has policy, license, media type, packaging format, release date, rights, spatial resolution, temporal resolution, title, update/modification date.

Note

Examples of distributions include a CSV file, a [netCDF] file, a JSON document, or a data-cube, files made accessible according to different profiles, such as XML or JSON schemas or [ShEx] or [SHACL] expressions.

In some cases all distributions of a dataset will be fully informationally equivalent, in the sense that lossless transformations between the representations are possible. An example would be different serializations of an RDF graph using RDF/XML [RDF-SYNTAX-GRAMMAR], [Turtle], [N3], [JSON-LD]. However, in other cases the distributions might have different levels of fidelity to the underlying data. For example, a graphical representation about the data on a CSV file may not contain the same total information recorded in the CSV file, but they could be considered as two distributions for the same dataset as they are about the same data.

As a counter-example, budget data for different years would usually be modelled as different datasets, each with their own distributions, since all distributions of one dataset should broadly contain the same data.

Nevertheless, the question of whether different representations can be understood to be distributions of the same dataset, or distributions of different datasets, is application specific. Judgement about how to describe them is the responsibility of the provider, taking into account their understanding of the expectations of users, and practices in the relevant community.

Links between a dcat:Distribution and services or Web addresses where it can be accessed are expressed using dcat:accessURL, dcat:accessService, dcat:downloadURL, as shown in Figure 1 and described in the definitions below.

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 license such as attribution.

Information about licenses and rights SHOULD be provided on the level of Distribution. Information about licenses and rights MAY be provided for a Dataset in addition to but not instead of the information provided for the Distributions of that Dataset. Providing license or rights information for a Dataset that is different from information provided for a Distribution of that Dataset SHOULD be avoided as this can create legal conflicts. See also guidance at § 8. License and rights statements.

Note

Property added in this context in this revision of DCAT.

dcat:accessURL matches the property-chain dcat:accessService/dcat:endpointURL. In the RDF representation of DCAT this is axiomatized as an OWL property-chain axiom.

Note

New property added in this revision of DCAT.

Note

New property added in this revision of DCAT.

The range of this property is a decimal number representing a length in meters. This is intended to provide a summary indication of the spatial resolution of the data distribution as a single number. More complex descriptions of various aspects of spatial precision, accuracy, resolution and other statistics can be provided using the Data Quality Vocabulary [VOCAB-DQV].

Note

New property added in this revision of DCAT.

This is intended to provide a summary indication of the temporal resolution of the data distribution as a single value. More complex descriptions of various aspects of temporal precision, accuracy, resolution and other statistics can be provided using the Data Quality Vocabulary [VOCAB-DQV].

Note

Property added in this context in this revision of DCAT.

Note

dct:Standard is defined in [DCTERMS] 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 distribution. This is not necessarily tied to a single encoding or serialization.

Note

The range of dcat:mediaType has been tightened from dct:MediaTypeOrExtent to dct:MediaType as part of the revision of DCAT.

Note

New property added in this revision of DCAT.

For examples on the use of this property, see § C.5 Compressed and packaged distributions.

Note

New property added in this revision of DCAT.

For examples on the use of this property, see § C.5 Compressed and packaged distributions.

Note

New class added in this revision of DCAT.

The following properties are specific to this class: endpoint description, endpoint URL, serves dataset.

The following properties are inherited from the super-class dcat:Resource: access rights, conforms to, contact point, creator, description, has policy, identifier, is referenced by, keyword/tag, landing page, license, resource language, relation, rights, qualified relation, publisher, release date, theme/category, title, type/genre, update/modification date, qualified attribution.

For examples on the use of this class and related properties, see § C.4 Data services.

Note

New class added in this revision of DCAT.

The following properties are specific to this class: relation, had role.

Examples illustrating use of this class and its properties are given in § 13. Qualified relations.

Note

New property added in this revision of DCAT.

This DCAT property complements prov:hadRole which provides the function of an entity or agent with respect to an activity.

Note

New class added in this revision of DCAT.

Examples illustrating use of this class are given in § 13. Qualified relations.

Used in a qualified-relation to specify the role of an Entity with respect to another Entity. It is recommended that the values be managed as a controlled vocabulary of entity roles such as

• [ISO-19115-1] DS_AssociationTypeCode
• IANA Registry of Link Relations [IANA-RELATIONS]
• DataCite metadata schema [DataCite]
• MARC relators

This DCAT class complements prov:Role which provides the function of an entity or agent with respect to an activity.

Note

Class added in this context in this revision of DCAT.

The following properties are specific to this class: start date, end date. beginning, end.

Examples illustrating use of these options for the temporal coverage of a dataset are given in § 9.1 Temporal properties.

Note

New property added in this revision of DCAT.

Note

New property added in this revision of DCAT.

Note

Property added in this context in this revision of DCAT.

Note

The value of time:hasEnd is a time:Instant for whose position several options are available. In particular times that do not use the conventional Gregorian calendar can be expressed, such as geological and archeological periods, and times given as numeric positions on a time-line.

Note

Property added in this context in this revision of DCAT.

Note

The value of time:hasEnd is a time:Instant for whose position several options are available. In particular times that do not use the conventional Gregorian calendar can be expressed, such as geological and archeological periods, and times given as numeric positions on a time-line.

Note

Class added in this context in this revision of DCAT.

The following properties are specific to this class: geometry, bounding box, centroid.

Examples illustrating use of these options for the spatial coverage of a dataset are given in § 9.2 Spatial properties.

• For an extensive geometry (i.e., a set of coordinates denoting the vertices of the relevant geographic area), the property locn:geometry [LOCN] SHOULD be used.
• For a geographic bounding box delimiting a spatial area the property dcat:bbox SHOULD be used.
• For the geographic center of a spatial area, or another characteristic point, the property dcat:centroid SHOULD be used.

Note

Property added in this context in this revision of DCAT.

Note

The WKT encoding supports geospatial positions expressed in coordinate reference systems other than WGS84.

Note

New property added in this revision of DCAT.

Note

The WKT encoding supports geospatial positions expressed in coordinate reference systems other than WGS84.

Note

New property added in this revision of DCAT.

Note

The WKT encoding supports geospatial positions expressed in coordinate reference systems other than WGS84.

This section is non-normative.

The scientific and data provider communities use a number of different identifiers for publications, authors and data. DCAT primarily relies on persistent HTTP URIs as an effective way of making identifiers actionable. Notably, quite a few identifier schemes can be encoded as dereferenceable HTTP URIs, and some of them are also returning machine-readable metadata (e.g., DOIs [ISO-26324] and ORCIDs). Regardless, data providers still might need to refer to legacy identifiers, non-HTTP dereferenceable identifiers, locally minted or third-party-provided identifiers. In these cases, [DCTERMS] and [VOCAB-ADMS] can be of use.

The property dct:identifier explicitly indicates HTTP URIs as well as legacy identifiers. In the following examples, dct:identifier identifies a dataset, but it can similarly be used with any kind of resources.

<https://example.org/id> a dcat:Dataset;
  dct:identifier "https://example.org/id"^^xsd:anyURI ;
  .

Proxy dereferenceable URIs can be used when resources have not HTTP dereferenceable IDs. For example, in Example 14, https://example.org/proxyid is a proxy for id.

<https://example.org/proxyid> a dcat:Dataset;
  dct:identifier "id"^^xsd:string ;
  .

The property adms:identifier [VOCAB-ADMS] can express other locally minted identifiers or external identifiers, like DOI, ELI, arΧiv for creative works and ORCID, VIAF, ISNI for actors such as authors and publishers, as long as the identifiers are globally unique and stable.

Example 15 uses adms:schemaAgency and dct:creator to represent the authority that defines the identifier scheme (e.g., the DOI foundation in the example), adms:schemaAgency is used when the authority has no URI associated. The CrossRef and DataCite display guidelines recommend displaying DOIs as full URL link in the form https://doi.org/10.xxxx/xxxxx/.

<https://dcat.example.org/id> a dcat:Dataset;
  adms:identifier  <https://example.org/iddoi> ;
  dct:publisher <https://example.org/PoelenJorritH> ;
  .

<https://dcat.example.org/iddoi> a adms:Identifier ;
  # reading https://www.w3.org/TR/skos-reference/#notations more than one skos:notation can be set
  skos:notation "https://doi.org/10.5281/zenodo.1486279"^^xsd:anyURI;
  # the authority/agency defining the identifier scheme, used if the agency has no URI
  adms:schemaAgency "International DOI Foundation" ;
  # the authority/agency defining the identifier scheme, used if the agency has URI
  dct:creator  ex:InternationalDOIFundation ;
  .

ex:InternationalDOIFundation a foaf:Organization ;
  rdfs:label "International DOI Foundation" ;
  foaf:homepage <https://www.doi.org/> ;
  .

<https://dcat.example.org/PoelenJorritH> a foaf:Person;
  foaf:name "Jorrit H. Poelen" ;
  adms:identifier <https://example.org/PoelenJorritHID> ;
  .

<https://dcat.example.org/PoelenJorritHID> a adms:Identifier;
  skos:notation "https://orcid.org/0000-0003-3138-4118"^^xsd:anyURI ;
  # the authority/agency defining the identifier scheme, used if the agency has no URI
  adms:schemaAgency "ORCID" ;
  .

Example 15 does not represent the authority responsible for assigning and maintaining identifiers using that scheme (e.g., Zenodo) as naming the registrant goes against the philosophy of DOI, where the sub-spaces are abstracted from the organization that registers them, with the advantage that DOIs do not change when the organization changes or the responsibility for that sub-space is handed over to someone else. Example 15 shows a locally minted identifier for the creator of the dataset (e.g., https://example.org/PoelenJorritHID) and its correspondent ORCID identifier (e.g., https://orcid.org/0000-0003-3138-4118).

When the HTTP dereferenceable ID returns an RDF/OWL description for the dataset, the use of owl:sameAs might be considered. For example,

<https://dcat.example.org/id3> a dcat:Dataset;
  ...
  owl:sameAs <https://doi.org/10.5281/zenodo.1486279> ;
  .

when dereferenced with media type text/turtle, https://doi.org/10.5281/zenodo.1486279 returns a [SCHEMA-ORG] description for the dataset, which might dynamically enrich the description provided by https://example.org/id.

The need to distinguish between primary and alternative (or legacy) identifiers for a dataset within DCAT has been posed as a requirement. However, it is very much application-specific and would be better addressed in DCAT profiles rather than mandating a general approach.

Depending on the application context, specific guidelines such as "DCAT-AP: How to manage duplicates?" can be adopted for distinguishing authoritative datasets from dataset harvested by third parties catalogs.

If identifiers are not HTTP dereferenceable, common identifier types can be served as RDF datatypes [RDF11-CONCEPTS] or custom OWL datatypes [OWL2-SYNTAX] for the sake of interoperability, see ex:type in Example 17.

<https://dcat.example.org/id4> a dcat:Dataset;
  ...
  adms:identifier <https://example.org/sid> .

<https://dcat.example.org/sid5> rdf:type adms:Identifier ;
  # the actual id
  skos:notation "PA 1-060-815"^^ex:type ;
  # Human readable schema agency
  adms:schemaAgency "US Copyright Office" ;
  dct:issued "2001-09-12"^^xsd:date ;
  .

If a registered URI type is used (following [RFC3986], § 3.1 Scheme), the identifier scheme is part of the URI; thus indicating a separate identifier scheme in 'type' is redundant. For example, DOI is registered as a namespace in the info URI scheme [IANA-URI-SCHEMES] (see DOI FAQ #11), so according to [RFC3986], it should be encoded as in Example 18.

<https://dcat.example.org/sid6> rdf:type adms:Identifier ;
  # the actual id
  skos:notation "info:doi/10.1109/5.771073"^^xsd:anyURI .

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

This section is non-normative.

Note

DCAT 2014 handling of license and rights do not appear to satisfy all requirements [VOCAB-DCAT-20140116]. The recently completed W3C ODRL model [ODRL-MODEL] and vocabulary [ODRL-VOCAB] provide a rich language for describing many kinds of rights and obligations. In this section, we describe some patterns for linking DCAT Datasets and/or Distributions to suitable license and rights expressions.

Selecting the right way to express conditions for access to and re-use of resources can be complex. Implementers should always seek legal advice before deciding which conditions apply to the resource being described.

This specification distinguishes three main situations: one where a statement is associated with a resource that is explicitly declared as a 'license'; a second, where the statement is associated with a resource denoting only access rights; a third, covering all the other cases - i.e., statements not concerning licensing conditions and/or access rights (e.g., copyright statements).

To address these scenarios, it is recommended to use the property dct:rights, and its sub-properties dct:license and dct:accessRights. More precisely:

1. use dct:license to refer to licenses;

2. use dct:accessRights to express statements concerning only access rights (e.g., whether data can be accessed by anyone or just by authorized parties);

3. use dct:rights for all the other types of rights statements - those which are not covered by dct:license and dct:accessRights, such as copyright statements.

   Note

   A more sophisticated approach to express rights, based on and extending [DCTERMS], is provided by the Open Data Rights Statement Vocabulary (ODRS) [ODRS], which defines properties for specifying, among others, copyright statements and copyright notices.

Finally, in the particular case when rights are expressed via ODRL policies, it is recommended to use the odrl:hasPolicy property as the link from the description of the cataloged resource or distribution to the ODRL policy, in addition to the corresponding [DCTERMS] property that matches the same ODRL policy type.

Note

The Open Digital Rights Language (ODRL) [ODRL-VOCAB] is a policy expression language that provides a flexible and interoperable information model, vocabulary, and encoding mechanisms for representing statements about usage (i.e. permissions, prohibitions, and obligations) of content and services.

Recommendations on the use of these properties on the different types of resources defined in DCAT are provided in the relevant class descriptions.

This section is non-normative.

Five temporal properties of resources may be described using DCAT.

1. The release time of a resource is given using dct:issued. The value is usually encoded as a xsd:date.
2. The revision or update time of a resource is given using dct:modified. The value is usually encoded as a xsd:date.
3. The update schedule for a resource is indicated using dct:accrualPeriodicity. The value should be taken from a controlled vocabulary such as Dublin Core Collection Description Frequency Vocabulary.
4. The minimum temporal separation of items in a dataset is given using dcat:temporalResolution. The value is encoded as a xsd:duration. The update schedule and the temporal resolution can be combined to support the description of different kinds of time-series data as shown below.
5. The temporal extent of a dataset is given using dct:temporal. The value is a dct:PeriodOfTime. A number of options for expressing the details of a dct:PeriodOfTime are recommended in § 6.14 Class: Period of Time. Examples of these follow.

<ds913>
  a dcat:Dataset ;
  dct:accrualPeriodicity <http://purl.org/cld/freq/daily> ;
  dcat:temporalResolution "PT15M"^^xsd:duration ;
.

<ds782>
  a dcat:Dataset ;
  dct:accrualPeriodicity <http://purl.org/cld/freq/continuous> ;
  dcat:temporalResolution "PT1H"^^xsd:duration ;
.

<ds257> a dcat:Dataset ;
  dct:temporal [ a dct:PeriodOfTime ;
    dcat:startDate "2016-03-04"^^xsd:date ;
    dcat:endDate   "2018-08-05"^^xsd:date ;
  ] .

The following dataset specification is equivalent to the one in Example 21, but it uses [OWL-TIME]:

<ds348> a dcat:Dataset ;
  dct:temporal [ a dct:PeriodOfTime , time:ProperInterval ;
    time:hasBeginning [ a time:Instant ;
      time:inXSDDate "2016-03-04"^^xsd:date ;
    ] ;
    time:hasEnd [ a time:Instant ;
      time:inXSDDate "2018-08-05"^^xsd:date ;
    ] ;
  ] .

<ds429> a dcat:Dataset ;
  dct:temporal [ a dct:PeriodOfTime , time:ProperInterval ;
    time:hasBeginning [ a time:Instant ;
      time:inXSDgYear "1914"^^xsd:gYear ;
    ] ;
    time:hasEnd [ a time:Instant ;
      time:inXSDgYear "1939"^^xsd:gYear ;
    ] ;
  ] .

<ds850> a dcat:Dataset ;
  dct:temporal [ a dct:PeriodOfTime , time:ProperInterval ;
    time:hasBeginning [ a time:Instant ;
      time:inTimePosition [ a time:TimePosition ;
        time:hasTRS <http://resource.geosciml.org/classifier/cgi/geologicage/ma> ;
        time:numericPosition "541.0"^^xsd:decimal ;
      ] ;
    ] ;
    time:hasEnd [ a time:Instant ;
      time:inTimePosition [ a time:TimePosition ;
        time:hasTRS <http://resource.geosciml.org/classifier/cgi/geologicage/ma> ;
        time:numericPosition "251.902"^^xsd:decimal ;
      ] ;
    ] ;
  ] .

<ds127> a dcat:Dataset ;
  dct:temporal [ a dct:PeriodOfTime ;
    dcat:startDate "2016-03-04"^^xsd:date ;
  ] .

<ds586> a dcat:Dataset ;
  dct:temporal [ a dct:PeriodOfTime , time:ProperInterval ;
    time:hasEnd [ time:inXSDDate "2018-08-05"^^xsd:date ] ;
  ] .

Two spatial properties of datasets may be described using DCAT.

1. The minimum spatial separation of items in a dataset is given using dcat:spatialResolutionInMeters. The value is a decimal number.

   An example of the use of dcat:spatialResolutionInMeters is given in Example 3.

2. The spatial extent of a dataset is given using dct:spatial. The value is a dct:Location. A number of options for expressing the details of a dct:Location are recommended in § 6.15 Class: Location.

   Examples of these follow.

Note

The following examples are built on the relevant ones included in [SDW-BP] (in particular, § 12.2.2 Geometries and coordinate reference systems).

In the examples, for properties locn:geometry, dct:bbox, and dcat:centroid, the geometry is always specified with WKT. As per [GeoSPARQL], when the CRS specification is omitted this implies that the default CRS is used - namely CRS84 (corresponding to WGS84, but with axis order longitude/latitude).

For more details on coordinate reference systems and geometry encoding, we refer the reader to [SDW-BP], and, in particular, to the following sections:

• § 9 Coordinate Reference Systems (CRS)
• § 12.2.2 Geometries and coordinate reference systems

A dataset whose spatial coverage corresponds to Anne Frank's house in Amsterdam, specified as a polygon (the coordinate reference system is CRS84).

<AnneFrank_0> a dcat:Dataset ;
  dct:spatial [
    a dct:Location ;
    locn:geometry """POLYGON ((
      4.8842353 52.375108 , 4.884276 52.375153 ,
      4.8842567 52.375159 , 4.883981 52.375254 ,
      4.8838502 52.375109 , 4.883819 52.375075 ,
      4.8841037 52.374979 , 4.884143 52.374965 ,
      4.8842069 52.375035 , 4.884263 52.375016 ,
      4.8843200 52.374996 , 4.884255 52.374926 ,
      4.8843289 52.374901 , 4.884451 52.375034 ,
      4.8842353 52.375108
    ))"""^^geosparql:asWKT ;
  ] .

The same dataset in Example 27, but where the coordinates of the polygon are specified by using the national Dutch CRS - EPSG:28992 ("Amersfoort / RD New").

<AnneFrank_1> a dcat:Dataset ;
  dct:spatial [
    a dct:Location ;
    locn:geometry """<http://www.opengis.net/def/crs/EPSG/0/28992> POLYGON ((
      120749.725 487589.422 , 120752.55 487594.375  ,
      120751.227 487595.129 , 120732.539 487605.788 ,
      120723.505 487589.745 , 120721.387 487585.939 ,
      120740.668 487575.07  , 120743.316 487573.589 ,
      120747.735 487581.337 , 120751.564 487579.154 ,
      120755.411 487576.96  , 120750.935 487569.172 ,
      120755.941 487566.288 , 120764.369 487581.066 ,
      120749.725 487589.422
    ))"""^^geosparql:asWKT ;
  ] .

The same dataset of Example 27, buth where spatial coverage is specified by using the centroid / representative point of Anne Frank's house.

<AnneFrank_2> a dcat:Dataset ;
  dct:spatial [
    a dct:Location ;
    dcat:centroid "POINT(4.88412 52.37509)"^^geosparql:asWKT ;
  ] .

Note

This point location could be expressed using the [W3C-BASIC-GEO] vocabulary. If it is required to provide the w3cgeo:Point formulation, then it should be in addition to, not in place of, a dcat:centroid containing a WKT literal (geosparql:asWKT [GeoSPARQL]). This ensures interoperability with other DCAT dataset descriptions. For example:

<AnneFrank_3> a dcat:Dataset ;
  dct:spatial [
    a dct:Location , w3cgeo:Point ;
    dcat:centroid "POINT(4.88412 52.37509)"^^geosparql:asWKT ;
    w3cgeo:lat  "52.37509"^^xsd:decimal ;
    w3cgeo:long "4.88412"^^xsd:decimal ;
  ] .

The Dutch dataset of postal addresses, with its spatial coverage (Netherlands) specified as a bounding box.

<Dutch-postal> a dcat:Dataset ;
  dct:title "Adressen"@nl ;
  dct:title "Addresses"@en ;
  dct:description """INSPIRE Adressen afkomstig uit de basisregistratie Adressen,
                   beschikbaar voor heel Nederland"""@nl ;
  dct:description """INSPIRE addresses derived from the Addresses base registry,
                   available for the Netherlands"""@en ;
  dcat:theme <http://inspire.ec.europa.eu/theme/ad> ;
  dct:spatial [
    a dct:Location ;
    dcat:bbox """POLYGON((
      3.053 47.975 , 7.24  47.975 ,
      7.24  53.504 , 3.053 53.504 ,
      3.053 47.975
    ))"""^^geosparql:asWKT ;
  ] .

This section is non-normative.

Versioning can be applied to any of the first class citizens DCAT resources including Catalogs, Datasets, Distributions. The notion of version is very much related to the community practices, data management policy and the workflows in place. It is up to data providers to decide when and why a new version should be released. For this reason, DCAT refrains from providing definitions or rules about when changes in a resource should turn in a new release of it.

Versioning may be understood as involving relationships between datasets, which is supported by the dcat:qualifiedRelation and described in § 13.2 Relationships between datasets and other resources. The class dcat:Relationship supports providing information about the relationship, and could be extended for versioning information.

This section is non-normative.

Dataset citation is one of the requirements identified for this 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 supporting proper attribution and credit to those producing the data, facilitating data discovery, supporting tracking the impact and reuse of data, allowing for collaboration and re-use of data, and enabling the reproducibility of results based on the data.

To support data citation, the dataset description should include at a minimum: the dataset identifier, the dataset creator(s), the dataset title, the dataset publisher and the dataset publication or release date. These elements are those required by the DataCite metadata schema [DataCite], which is the metadata associated by the persistent identifiers (Digital Object Identifiers or DOIs) assigned by [DataCite] to research data.

In order to support data citation, this DCAT revision has added the consideration of dereferenceable identifiers and support for indicating the creators of the cataloged resources. The remaining properties necessary for data citation were already available in DCAT 2014 [VOCAB-DCAT-20140116].

The constraints on the availability of properties required for data citation in the dataset description can be represented as a DCAT data citation profile.

This section is non-normative.

Note

This section is non-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) [VOCAB-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 [ISO-IEC-25012] and [ZaveriEtAl] as two possible starting points. It also provides an RDF representation for the quality dimensions and categories defined in the latter. Ultimately, implementers will need to choose themselves the collection of quality dimensions that best fits their needs. The following section shows how DCAT and DQV can be coupled to describe the quality of datasets and distributions. For a comprehensive introduction and further examples of use, please refer to [VOCAB-DQV].

Note

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 [VOCAB-DQV] is neutral to the data portal design choices on how to collect quality information. For example, data portals can collect [VOCAB-DQV] instances by implementing specific UI to annotate data or by taking inputs from 3rd-party services.

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 "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"@en .
  # 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"@en ;
  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 .

Other examples of quality documentation are available in [VOCAB-DQV], including examples about how to express dataset accuracy and precision.

This section shows different modelling patterns combining [VOCAB-DQV] with [PROV-O] and EARL [EARL10-Schema] to represent the conformance degree to a stated quality standard and the details about the conformance tests.

The use of dct:conformsTo and dct:Standard is a well-known pattern to represent the conformance to a standard. Example 33, directly borrowed from [SDW-BP] (Example 51), declares a fictional a:Dataset conformant to the EU INSPIRE Regulation on interoperability of spatial data sets and services ("Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services").

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

Another example concerns the specification of the coordinate reference system (CRS) used in a dataset - an information which is typically included in geospatial metadata. Example 34 shows how the CRS of a dataset can be specified in DCAT:

:Dataset-2 a dcat:Dataset;
  dct:conformsTo <http://www.opengis.net/def/crs/EPSG/0/28992> .

In Example 34, http://www.opengis.net/def/crs/EPSG/0/28992 is a URI from the OGC CRS Registry, corresponding to EPSG:28992 ("Amersfoort / RD New") (see also Example 28).

Some legal context requires to specify the degree of conformance. For example, INSPIRE metadata adopts a specific controlled vocabulary [INSPIRE-DoC] to express non-conformance and non-evaluation beside the full compliance. Similar controlled vocabularies can be defined in other contexts.

Example 35 specifies some newly minted concepts representing the degree of conformance (i.e., conformant, not conformant) and declares the dct:type for indicating the result of conformance test. Following a pattern used in [GeoDCAT-AP], the example uses a prov:Entity to model the conformance test (e.g., a:testResult), a prov:Activity to model the testing activity (e.g., a:testingActivity), a prov:Plan derived from the Data on the Web Best Practices [DWBP] (e.g., a:conformanceTest) to check for the whole set of best practices. A qualified PROV association binds the testing activity to the conformance test.

Note

Depending of the kind of dataset, other best practices and standards, such as the FAIR Principles [FAIR] or the Spatial Data on the Web Best Practices [SDW-BP], can be considered as a replacement or used in combination with [DWBP].

:Dataset-3 a dcat:Dataset ;
  prov:wasUsedBy :testingActivity .

:testingActivity a prov:Activity ;
  prov:generated :testResult ;
  prov:qualifiedAssociation [
    a prov:Association ;
    # http://validator.example.org/ is the agent who ran the test.
    prov:agent  <http://validator.example.org/>
    # following the plan a:conformanceTest
    prov:hadPlan :conformanceTest
  ] .

# Conformance test result
:testResult a prov:Entity ;
  # :notConformant belongs to a SKOS concept scheme about conformance
  dct:type :notConformant .

:conformanceTest a prov:Plan ;
  # Here one can specify additional information on the test, which in the example is derived by the W3C Data on the Web Best Practices
  prov:wasDerivedFrom <https://www.w3.org/TR/dwbp/> .

Also, [VOCAB-DQV] can be deployed to measure the compliance to a specific standard. In Example 36, the :levelOfComplianceToDWBP is a quality metrics which measures the compliance of a dataset to [DWBP] in terms of the percentage of passed compliance tests. Example 36 assumes iso as a namespace prefix representing the quality dimensions and categories defined in the ISO/IEC 25012 [ISO-IEC-25012].

:levelOfComplianceToDWBP a dqv:Metric ;
  skos:definition "The degree of compliance to DWBP defined as the percentage of passed compliance 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_complianceToDWBP represents the level of compliance for dataset a:Dataset, namely, measurement of the metric :levelOfComplianceToDWBP. If only a part of the compliance tests succeeds (e.g. half of the compliance tests), the measurement would look like in Example 37.

:measurement_complianceToDWBP a dqv:QualityMeasurement ;
  dqv:computedOn a:Dataset ;
  dqv:value "50"^^xsd:double ;
  sdmx-attribute:unitMeasure <http://www.wurvoc.org/vocabularies/om-1.8/Percentage> ;
  dct:date "2018-01-10"^^xsd:date ;
  dqv:isMeasurementOf :levelOfComplianceToDWBP .

Further information about the tests can be provided using EARL [EARL10-Schema]. EARL provides specific classes to describe the testing activity, which can be adopted in conjunction with [PROV-O]. Example 38 describes the Testing activity a:testingActivity as an earl:Assertion instead of a qualified association on the prov:Activity. The earl:Assertion states that 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 from the W3C Data on the Web Best Practices"@en ;
  # it includes different subtests
  dct:hasPart a:testBP1, a:testBP2, ...,  a:testBP35 ;
  #It is derived  by the reference standard
  prov:wasDerivedFrom  <https://www.w3.org/TR/dwbp/> .

a:testResult a earl:TestResult ;
  #  results in conformancy .
  dct:type  a: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 ;
  dct:description "A test execution service that runs conformance test suites."@en ;
  dct: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/> .

Example 39 shows how the description would have looked like if the subtest a:testq1 had failed. In particular, dct: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
    dct:type a:nonConformant ;
    #the overall set of tests have not been passed (!?)
    dct:date "2015-09-29T11:50:00+00:00"^^xsd:dateTime ;
    # Some XML encoding of the error
      dct:description """
        <ul xmlns="http://www.w3.org/1999/xhtml">
          <li> test 1 has failed. Some description of the errors found</li>
        </ul>"""^^rdf:HTML ;
      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, [VOCAB-DQV] can express the testing activity and errors as well. In Example 40, :error is a quality annotation that represents the previous error, and a:testResult is defined as a dqv:QualityMetadata to collect the above annotations and the compliance measurements providing provenance information.

:errors
  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
    dc:format  "application/xml" ;
  ] ;
  oa:motivatedBy dqv:qualityAssessment , oa:assessing ;
  dqv:inDimension iso:compliance ;
  .

a:testResult
  a dqv:QualityMetadata ;
  #  change the the dct:type according to the resulted compliance
  dct: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.
# The graph is expressed according to TRIG syntax not TTL (see https://www.w3.org/TR/trig/)
a:testResult {
  a dcat:Dataset ;
  dqv:hasQualityMeasurement :measurement_complianceToDWBP ;
  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.

This section is non-normative.

DCAT includes elements to support description of many aspects of datasets and data-services. Nevertheless, additional information is required in order to fully express the semantics of some relationships. An example is that, while [DCTERMS] provides the standard roles creator, contributor and publisher for attribution of a resource to a responsible party or agent, there are many other potential roles, see for example the CI_RoleCode values from [ISO-19115-1]. Similarly, while [DCTERMS] and [PROV-O] provide some properties to capture relationships between resources, including was derived from, was quoted from, is version of, references and several others, many additional concerns are seen in the list of [ISO-19115-1] DS_AssociationTypeCodes, the IANA Registry of Link Relations [IANA-RELATIONS], the DataCite metadata schema [DataCite] and the MARC relators. While these relations could be captured with additional sub-properties of dct:relation, dct:contributor, etc, this would lead to an explosion in the number of properties, and anyway the full set of potential roles and relationships is unknown.

A common approach for meeting these kinds of requirement is to introduce an additional resource to carry parameters that qualify the relationship. Precedents are the qualified terms in [PROV-O] and the sample relations in the Semantic Sensor Network ontology [VOCAB-SSN]. The general Qualified Relation pattern is described in [LinkedDataPatterns].

Many of the qualified terms from [PROV-O] are relevant to the description of resources in catalogs but these are incomplete due to the activity-centric viewpoint taken by PROV-O. Addressing some of the gaps, additional forms are included in the DCAT vocabulary to satisfy requirements that do not involve explicit activities. These are summarized in Figure 5:

Note that, while the focus of these qualified forms is to allow for additional roles on a relationship, other aspect of the relationships, such as the applicable time interval, are easily attached when a specific node is used to describe the relationship like this (e.g. see the chart of Influence relations in [PROV-O] for some examples).

The standard [DCTERMS] properties dct:contributor, dct:creator and dct:publisher, and the generic prov:wasAttributedTo from [PROV-O], support basic associations of responsible agents with a cataloged resource. However, there are many other roles of importance in relation to datasets and services - e.g. funder, distributor, custodian, editor. Some of these roles are enumerated in the CI_RoleCode values from [ISO-19115-1], in the [DataCite] metadata schema, and included within the MARC relators.

A general method for assigning an agent to a resource with a specified role is provided by using the qualified form prov:qualifiedAttribution from [PROV-O]. Example 41 provides an illustration:

ex:DS987
  a dcat:Dataset ;
  prov:qualifiedAttribution [
    a prov:Attribution ;
    prov:agent <https://www.ala.org.au/> ;
    dcat:hadRole <http://registry.it.csiro.au/def/isotc211/CI_RoleCode/distributor>
  ] ;
  prov:qualifiedAttribution [
    a prov:Attribution ;
    prov:agent <https://www.education.gov.au/> ;
    dcat:hadRole <http://registry.it.csiro.au/def/isotc211/CI_RoleCode/funder>
  ] ;
.

In Example 41 the roles are denoted by IRIs from a (non-normative) linked data representation of the CI_RoleCode codelist from [ISO-19115-1].

The standard [DCTERMS] properties dct:relation and sub-properties such as dct:hasPart / dct:isPartOf, dct:hasVersion / dct:isVersionOf, dct:replaces / dct:isReplacedBy, dct:requires / dct:isRequiredBy, prov:wasDerivedFrom, prov:wasQuotedFrom, support the description of relationships between datasets and other cataloged resources. However, there are many other relationships of importance - e.g. alternate, canonical, original, preview, stereo-mate, working-copy-of. Some of these roles are enumerated in the DS_AssociationTypeCodes values from [ISO-19115-1], the IANA Registry of Link Relations [IANA-RELATIONS], in the [DataCite] metadata schema, and included within the MARC relators.

A general method for relating a resource to another resource with a specified role is provided by using the qualified form dcat:qualifiedRelation. Example 42 provides illustrations:

ex:Test987
  a dcat:Dataset ;
  dcat:qualifiedRelation [
    a dcat:Relationship ;
    dct:relation <http://example.org/Original987> ;
    dcat:hadRole <http://www.iana.org/assignments/relation/original>
  ] ;
.

ex:Test543L
  a dcat:Dataset ;
  dcat:qualifiedRelation [
    a dcat:Relationship ;
    dct:relation <http://example.org/Test543R> ;
    dcat:hadRole <http://registry.it.csiro.au/def/isotc211/DS_AssociationTypeCode/stereoMate>
  ] ;
.

In Example 42 the roles are denoted by IRIs from [IANA-RELATIONS] and from a (non-normative) linked data representation of the DS_AssociationTypeCode codelist from [ISO-19115-1].

Note

The property dcat:qualifiedRelation and association-class dcat:Relationship follow the pattern established in W3C [PROV-O] and described in § 3.3 Qualified Terms. However, [PROV-O] is activity-centric, and does not support Entity-Entity relations except for the single case of 'was derived from', thus necessitating the new elements shown here to support the general case.

This section is non-normative.

The DCAT-2014 vocabulary [VOCAB-DCAT-20140116] has been extended for application in data catalogs in different domains. Each of these new specifications constitutes a DCAT profile, i.e. a named set of constraints based on DCAT (see § 4. Conformance). In some cases, a profile extends one of the DCAT profiles themselves, by adding classes and properties for metadata fields not covered in the reference DCAT profile.

Some of the DCAT profiles are:

• DCAT-AP [DCAT-AP]: The DCAT application profile for data portals in Europe
• GeoDCAT-AP [GeoDCAT-AP]: Geospatial profile of [DCAT-AP]
• StatDCAT-AP [StatDCAT-AP]: Statistical profile of [DCAT-AP]
• DCAT-AP_IT [DCAT-AP-IT]: Italian profile of [DCAT-AP]
• GeoDCAT-AP_IT [GeoDCAT-AP-IT]: Italian profile of [GeoDCAT-AP]
• DCAT-AP-NO [DCAT-AP-NO]: Norwegian profile of [DCAT-AP]
• DCAT-AP.de [DCAT-AP.de]: German profile of [DCAT-AP]
• DCAT-BE [DCAT-BE]: Belgian profile of [DCAT-AP]
• DCAT-AP-SE [DCAT-AP-SE]: Swedish profile of [DCAT-AP]

The DCAT vocabulary supports the attribution of data and metadata to various participants such as resource creators, publishers and other parties or agents via qualified relations, and as such defines terms that may be related to personal information. In addition, it also supports the association of rights and licenses with cataloged Resources and Distributions. These rights and licenses could potentially include or reference sensitive information such as user and asset identifiers as described in [ODRL-VOCAB]. Implementations that produce, maintain, publish or consume such vocabulary terms must take steps to ensure security and privacy considerations are addressed at the application level.

The editors gratefully acknowledge the contributions made to this document by all members of the working group, especially Annette Greiner, Antoine Isaac, Armin Haller, Dan Brickley, Ine de Visser, Jaroslav Pullmann, Lars G. Svensson, Linda van den Brink, Makx Dekkers, Nicholas Car, Rob Atkinson, Tom Baker.

The editors would also like to thank the following for comments received: Addison Phillips, Andreas Kuckartz, Anna Odgaard Ingram, Armando Stellato, Bert van Nuffelen, Chris Little, Chris Sweeney, Chris Wood, Clemens Portele, Daniel Pop, Dave Reynolds, Guillaume Duffes, Ian Davis, Jakob Voß, Jakub Klímek, James Passmore, Leigh Dodds, Luca Trani, Marco Brattinga, Matthias Palmér, Melanie Barlow, Nancy Fallgren, Nuno Freire, Øystein Åsnes, Pano Maria, Peter Parslow, Renato Iannella, Ruth Duerr, Siri Jodha S. Khalsa, Stephane Fellah, Stephen Richard, Stijn Goedertier, Tom Kralidis, Vladimir Alexiev, Wouter Beek, Yves Coene.

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.

This section is non-normative.

Schema.org [SCHEMA-ORG] includes a number of types and properties based on the original DCAT work (see sdo:Dataset as a starting point), and the index for Google's Dataset Search service relies on structured description in Web pages about datasets using both schema.org and DCAT. A comparison of the DCAT backbone, shown in Figure 1 above with the related classes from [SCHEMA-ORG] in Figure 6 shows the similarity, in particular: .

• the distinction between (abstract) Dataset and (concrete) DataDownload matches dcat:Dataset / dcat:Distribution
• the relationship of Datasets to DataCatalogs

General purpose Web search services that use metadata at all rely primarily on [SCHEMA-ORG], so the relationship of DCAT to [SCHEMA-ORG] is of interest for data providers and catalog publishers who wish their datasets and services to be exposed through those indexes.

A mapping between DCAT 2014 and schema.org was discussed on the original proposal to extend [SCHEMA-ORG] for describing datasets and data catalogs. Partial mappings between DCAT 2014 [VOCAB-DCAT-20140116] and [SCHEMA-ORG] were provided earlier by the Spatial Data on the Web Working Group, building upon previous work.

A recommended mapping from the revised DCAT (this document) to [SCHEMA-ORG] version 3.4 is available in an RDF file. This mapping is axiomatized using the predicates rdfs:subClassOf, rdfs:subPropertyOf, owl:equivalentClass, owl:equivalentProperty, skos:closeMatch, and also using the annotation properties sdo:domainIncludes and sdo:rangeIncludes to match [SCHEMA-ORG] semantics. The alignment is summarized in the table below, considering the prefix sdo as http://schema.org/.

This section is non-normative.

Note

The background to this example is discussed in Issue #253 ("Best practice for a loosely-structured catalog").

In many legacy catalogs 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 catalog, 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, ..."@en ;
  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.

:d33937
  rdf:type dcat:Dataset ;
  dct:description "A set of RDF graphs representing the International [Chrono]stratigraphic Chart, ..."@en ;
  dct:identifier "https://doi.org/10.25919/5b4d2b83cbf2d"^^xsd:anyURI ;
  dct:relation <https://vocabs.ands.org.au/viewById/196> ;
  dct:relation :ChronostratChart2017-02.pdf  ;
  dct:relation :ChronostratChart2017-02.jpg ;
  dct:relation :timescale.zip ;
  dcat:distribution :d33937-jsonld ;
  dcat:distribution :d33937-nt ;
  dcat:distribution :d33937-rdf ;
  dcat:distribution :d33937-ttl ;
.
:d33937-jsonld  rdf:type dcat:Distribution ;
  dcat:downloadURL :isc2017.jsonld ;
  dcat:byteSize "698039"^^xsd:decimal ;
  dcat:mediaType <https://www.iana.org/assignments/media-types/application/ld+json> ;
.
:d33937-nt  rdf:type dcat:Distribution ;
  dcat:downloadURL :isc2017.nt ;
  dcat:byteSize "2047874"^^xsd:decimal ;
  dcat:mediaType <https://www.iana.org/assignments/media-types/application/n-triples> ;
.
:d33937-rdf  rdf:type dcat:Distribution ;
  dcat:downloadURL :isc2017.rdf ;
  dcat:byteSize "1600569"^^xsd:decimal ;
  dcat:mediaType <https://www.iana.org/assignments/media-types/application/rdf+xml> ;
.
:d33937-ttl  rdf:type dcat:Distribution ;
  dcat:downloadURL :isc2017.ttl ;
  dcat:byteSize "531703"^^xsd:decimal ;
  dcat:mediaType <https://www.iana.org/assignments/media-types/text/turtle> ;
.

This example is available from the DXWG code repository at csiro-dap-examples.ttl.

Additional detail about the nature of the related resources can be given using suitable elements from other RDF vocabularies, along with dataset descriptors from DCAT. For example, the example above might be more fully expressed as follows (embedded comments explain the different resources in the graph):

dap:d33937
  rdf:type dcat:Dataset ;
  dct:title "The data"@en ;
  dct:conformsTo <http://resource.geosciml.org/ontology/timescale/gts> ;
  dct:description "A set of RDF graphs representing the International [Chrono]stratigraphic Chart [...]"@en ;
  dct:identifier "https://doi.org/10.25919/5b4d2b83cbf2d" ;
  dct:issued "2018-07-07"^^xsd:date ;
  dct:license <https://creativecommons.org/licenses/by/4.0/> ;
  dct:publisher <http://www.csiro.au> ;
  dct:relation <http://stratigraphy.org/ICSchart/ChronostratChart2017-02.jpg> ;
  dct:relation <http://stratigraphy.org/ICSchart/ChronostratChart2017-02.pdf> ;
  dct:relation [
    rdf:type dcat:Dataset ;
    dct:conformsTo <https://www.w3.org/TR/owl2-overview/> ;
    dct:title "The ontology used for the data"@en ;
    dct:description "This is an RDF/OWL representation of the GeoSciML Geologic Timescale model ..."@en ;
    dct:issued "2011-01-01"^^xsd:date ;
    dct:modified "2017-04-28"^^xsd:date ;
    dct:title "Geologic Timescale model" ;
    dct:type <http://purl.org/adms/assettype/DomainModel> ;
    dcat:distribution [
      rdf:type dcat:Distribution ;
      dct:title "RDF/XML representation of the ontology used for the data"@en ;
      dcat:downloadURL <http://resource.geosciml.org/ontology/timescale/gts.rdf> ;
      dcat:mediaType <https://www.iana.org/assignments/media-types/application/rdf+xml> ;
    ] ;
    dcat:distribution [
      rdf:type dcat:Distribution ;
      dct:title "TTL representation of the ontology used for the data"@en ;
      dcat:downloadURL <http://resource.geosciml.org/ontology/timescale/gts.ttl> ;
      dcat:mediaType <https://www.iana.org/assignments/media-types/text/turtle> ;
    ] ;
    dcat:distribution [
      rdf:type dcat:Distribution ;
      dct:title "Webpage describing the ontology used for the data"@en ;
      dcat:downloadURL <http://resource.geosciml.org/ontology/timescale/gts.html> ;
      dcat:mediaType <https://www.iana.org/assignments/media-types/text/html> ;
    ] ;
    dcat:landingPage <http://resource.geosciml.org/ontology/timescale/gts> ;
  ] ;
  dcat:distribution [
    rdf:type dcat:Distribution ;
    dct:conformsTo <https://www.w3.org/TR/rdf-schema/> ;
    dct:title "RDF representation of the data"@en ;
    dcat:accessService [
      rdf:type dcat:DataService ;
      dct:conformsTo <https://www.w3.org/TR/sparql11-query/> ;
      dct:title "International Chronostratigraphic Chart hosted at Research Vocabularies Australia"@en ;
      dct:description "Service that supports queries to obtain RDF representations of subsets of the data"@en ;
      dcat:endpointURL <http://vocabs.ands.org.au/repository/api/sparql/csiro_international-chronostratigraphic-chart_2017> ;
      dcat:landingPage <https://vocabs.ands.org.au/viewById/196> ;
    ] ;
  ] ;
  dcat:distribution [
    rdf:type dcat:Distribution ;
    dct:identifier "isc2017.jsonld" ;
    dct:title "JSON-LD serialization of the RDF representation of the entire dataset"@en ;
    dcat:mediaType <https://www.iana.org/assignments/media-types/application/ld+json> ;
  ] ;
  dcat:distribution [
    rdf:type dcat:Distribution ;
    dct:identifier "isc2017.nt" ;
    dct:title "N-Triples serialization of the RDF representation of the entire dataset"@en ;
    dcat:mediaType <https://www.iana.org/assignments/media-types/application/n-triples> ;
  ] ;
  dcat:distribution [
    rdf:type dcat:Distribution ;
    dct:identifier "isc2017.rdf" ;
    dct:title "RDF/XML serialization of the RDF representation of the entire dataset"@en ;
    dcat:mediaType <https://www.iana.org/assignments/media-types/application/rdf+xml> ;
  ] ;
  dcat:distribution [
    rdf:type dcat:Distribution ;
    dct:identifier "isc2017.ttl" ;
    dct:title "TTL serialization of the RDF representation of the entire dataset"@en ;
    dcat:mediaType <https://www.iana.org/assignments/media-types/text/turtle> ;
  ] ;
  dcat:landingPage <https://data.csiro.au/dap/landingpage?pid=csiro:33937> ;
.

<http://stratigraphy.org/ICSchart/ChronostratChart2017-02.jpg>
  rdf:type foaf:Document ;
  dct:type <http://purl.org/dc/dcmitype/Image> ;
  dct:format  <https://www.iana.org/assignments/media-types/img/jpeg> ;
  dct:description "Coloured image representation of the International Chronostratigraphic Chart"@en ;
  dct:issued "2017-02-01"^^xsd:date ;
  dct:title "International Chronostratigraphic Chart"@en ;
.
<http://stratigraphy.org/ICSchart/ChronostratChart2017-02.pdf>
  rdf:type foaf:Document ;
  dct:type <http://purl.org/dc/dcmitype/Image> ;
  dct:format <https://www.iana.org/assignments/media-types/application/pdf> ;
  dct:description "Coloured image representation of the International Chronostratigraphic Chart"@en ;
  dct:issued "2017-02-01"^^xsd:date ;
  dct:title "International Chronostratigraphic Chart"@en ;
.

This example is available from the DXWG code repository at csiro-stratchart.ttl.

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):

dap:atnf-P366-2003SEPT
  rdf:type dcat:Dataset ;
  dct:bibliographicCitation "Burgay, M; McLaughlin, M; Kramer, M; Lyne, A; Joshi, B; Pearce, G; D'Amico, N; Possenti, A; Manchester, R; Camilo, F (2017): Parkes observations for project P366 semester 2003SEPT. v1. CSIRO. Data Collection. https://doi.org/10.4225/08/598dc08d07bb7" ;
  dct:title "Parkes observations for project P366 semester 2003SEPT"@en ;
  dcat:landingPage <https://data.csiro.au/dap/landingpage?pid=csiro:P366-2003SEPT> ;
  prov:wasGeneratedBy dap:P366 ;
  .

dap:P366
  rdf:type prov:Activity ;
  dct:type <http://dbpedia.org/resource/Observation> ;
  prov:startedAtTime "2000-11-01"^^xsd:date ;
  prov:used dap:Parkes-radio-telescope ;
  prov:wasInformedBy dap:ATNF ;
  rdfs:label "P366 - Parkes multibeam high-latitude pulsar survey"@en ;
  rdfs:seeAlso <https://doi.org/10.1111/j.1365-2966.2006.10100.x> ;
  .

This example is available from the DXWG code repository at csiro-dap-examples.ttl.

Several properties capture provenance information, including within the citation and title, but the primary link to a formal description of the project is through prov:wasGeneratedBy. A terse description of the project is shown as a prov:Activity, though this would not necessarily be part of the same catalog. Note that as the project is ongoing, the activity has no end date.

Further provenance information might be provided using the other starting point properties from PROV, in particular prov:wasAttributedTo (to link to an agent associated with the dataset production) and prov:wasDerivedFrom (to link to a predecessor dataset). Both of these complement Dublin Core properties already used in DCAT, as follows:

• prov:wasAttributedTo provides a general link to all kinds of associated agents, such as project sponsors, managers, dataset owners, etc which are not correctly characterized using 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.

Further patterns for the use of qualified properties for resource attribution and interrelationships are described in § 13. Qualified relations.

Often datasets are associated with publications (scholarly articles, reports, etc) and this version of DCAT relies on the property dct:isReferencedBy to provide a way to link publications about a dataset to the dataset

The following example shows how a dataset published in the Dryad repository is linked to a publication available in the Nature Scientific Data journal:

:globtherm
  dct:title "Data from: GlobTherm, a global database on thermal tolerances for aquatic and terrestrial organisms"@en ;
  dct:description "How climate affects species distributions is a longstanding question receiving renewed interest owing to the need to predict the impacts of global warming on biodiversity. Is climate change forcing species to live near their critical thermal limits? Are these limits likely to change through natural selection? These and other important questions can be addressed with models relating geographical distributions of species with climate data, but inferences made with these models are highly contingent on non-climatic factors such as biotic interactions. Improved understanding of climate change effects on species will require extensive analysis of thermal physiological traits, but such data are scarce and scattered. To overcome current limitations, we created the GlobTherm database. The database contains experimentally derived species’ thermal tolerance data currently comprising over 2,000 species of terrestrial, freshwater, intertidal and marine multicellular algae, pl ants, fungi, and animals. The GlobTherm database will be maintained and curated by iDiv with the aim of expanding it, and enable further investigations on the effects of climate on the distribution of life on Earth."@en ;
  dct:identifier "https://doi.org/10.5061/dryad.1cv08"^^xsd:anyURI ;
  dct:creator <https://orcid.org/0000-0002-7883-3577> ;
  dct:relation <https://doi.org/10.5061/dryad.1cv08/6> ;
  dct:relation <https://doi.org/10.5061/dryad.1cv08/7> ;
  dct:isReferencedBy <https://doi.org/10.1038/sdata.2018.22>.

This examples is available from the DXWG code repository at dryad-globtherm-sdata.ttl

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.

The first example describes a data catalog hosted by the European Environment Agency (EEA). This is classified as a dcat:DataService and has the dct:type set to "discovery" from the INSPIRE classification of spatial data service types [INSPIRE-SDST].

This example is available from the DXWG code repository at eea-csw.ttl

a:EEA-CSW-Endpoint
  rdf:type dcat:DataService ;
  dct:type <http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceCategory/infoCatalogueService> ;
  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 ;
    dcat:bbox "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> ;
.

Example 49 shows a dataset hosted by Geoscience Australia, which is available from three distinct services, as indicated by the value of the dcat:servesDataset property of each of the service descriptions. These are classified as a dcat:DataService and also have the dct:type set to "download" and "view" from the INSPIRE classification of spatial data service types [INSPIRE-SDST].

Example 49 is available from the DXWG code repository at ga-courts.ttl

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."@en ;
  dct:spatial [
    rdf:type dct:Location ;
      dcat:bbox """<http://www.opengis.net/def/crs/EPSG/0/4283> POLYGON((
      -42.885989 115.864566 , -12.460578 115.864566 ,
      -12.460578 153.276835 , -42.885989 153.276835 ,
      -42.885989 115.864566
    ))"""^^geosparql:wktLiteral ;
  ] ;
  dct:title "Judicial Courts"@en ;
  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:DataService ;
  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."@en ;
  dct:identifier "2b8540c8-4a43-144d-e053-12a3070a3ff7" ;
  dct:title "National Judicial Courts MapServer"@en ;
  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:DataService ;
  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."@en ;
  dct:identifier "2b8540c8-4a42-144d-e053-12a3070a3ff7" ;
  dct:title "National Judicial Courts WFS"@en ;
  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:DataService ;
  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."@en ;
  dct:identifier "2b8540c8-4a41-144d-e053-12a3070a3ff7" ;
  dct:title "National Judicial Courts WMS"@en ;
  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 ;
.

The first example is for a distribution with a downloadable file that is compressed into a GZIP file.

@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix dct: <http://purl.org/dc/terms/> .

<https://data.gov.cz/zdroj/datová-sada/247025684/22> a dcat:Distribution ;
  dcat:accessURL <https://mvcr1.opendata.cz/czechpoint/2007.csv.gz> ;
  dcat:downloadURL <https://mvcr1.opendata.cz/czechpoint/2007.csv.gz> ;
  dct:license <https://data.gov.cz/podmínky-užití/volný-přístup/> ;
  dct:conformsTo <https://mvcr1.opendata.cz/czechpoint/2007.json> ;
  dct:format <http://publications.europa.eu/resource/authority/file-type/CSV> ;
  dcat:mediaType <http://www.iana.org/assignments/media-types/text/csv> ;
  dcat:compressFormat <http://www.iana.org/assignments/media-types/application/gzip>
.

The second example is for a distribution with several files packed into a TAR file.

@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix dct: <http://purl.org/dc/terms/> .

<https://data.gov.cz/zdroj/datová-sada/247025684/22> a dcat:Distribution ;
  dcat:accessURL <https://mvcr1.opendata.cz/czechpoint/data.tar> ;
  dcat:downloadURL <https://mvcr1.opendata.cz/czechpoint/data.tar> ;
  dct:license <https://data.gov.cz/podmínky-užití/volný-přístup/> ;
  dct:conformsTo <https://mvcr1.opendata.cz/czechpoint/2007.json> ;
  dct:format <http://publications.europa.eu/resource/authority/file-type/CSV> ;
  dcat:mediaType <http://www.iana.org/assignments/media-types/text/csv> ;
  dcat:packageFormat <http://publications.europa.eu/resource/authority/file-type/TAR>
.

The third example is for a distribution with several files packed into a TAR file which has been compressed into a GZIP file.

@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix dct: <http://purl.org/dc/terms/> .

<https://data.gov.cz/zdroj/datová-sada/247025684/22> a dcat:Distribution ;
  dcat:accessURL <https://mvcr1.opendata.cz/czechpoint/data.tar.gz> ;
  dcat:downloadURL <https://mvcr1.opendata.cz/czechpoint/data.tar.gz> ;
  dct:conformsTo <https://mvcr1.opendata.cz/czechpoint/2007.json> ;
  dct:license <https://data.gov.cz/podmínky-užití/volný-přístup/> ;
  dct:format <http://publications.europa.eu/resource/authority/file-type/CSV> ;
  dcat:mediaType <http://www.iana.org/assignments/media-types/text/csv> ;
  dcat:packageFormat <http://publications.europa.eu/resource/authority/file-type/TAR> ;
  dcat:compressFormat <http://www.iana.org/assignments/media-types/application/gzip>
  .

These examples are available from the DXWG code repository at compress-and-package.ttl

A full change-log is available on GitHub

The document has undergone the following changes since the W3C Recommendation of 16 January 2014 [VOCAB-DCAT-20140116]:

• A new property dct:isReferencedBy was added to the class dcat:Resource to associate the resource described in the catalog with an external resource that references, cites, or points to the cataloged resource. In particular, in the case of datasets, this property supports the data citation use case where a publication references a dataset. For other types of relations not covered by this or other known properties, the specification provides the qualified relations pattern. See Issue #63.
• A new section § 9. Time and space was added to describe how to indicate the temporal and spatial characteristics of a resource. See Issue #83, Issue #84, Issue #85.
• A new class dct:Location and three new properties (locn:geometry, dcat:bbox, dcat:centroid) added to support description of the coordinates of a geographical area, to be used for specifying the spatial coverage of a resource. See Issue #83.
• A new class dct:PeriodOftime and four new properties (dcat:startDate, dcat:endDate, time:hasBeginning, time:hasEnd) added to support description of a temporal interval, to be used for specifying the temporal coverage of a resource. See Issue #85.
• The global range of the property dcat:themeTaxonomy relaxed to allow linking to a taxonomy that is not formalized as a skos:ConceptScheme. See Issue #119.
• A new property dcat:spatialResolutionInMeters added to support description of the spatial resolution of datasets and distributions. See Issue #84.
• A new property dcat:temporalResolution added to support description of the temporal resolution of datasets and distributions. See Issue #84.
• Two new properties, dcat:packageFormat and dcat:compressFormat, were added to specify packaged and compressed distributions, respectively. See Issue #54.
• A new section § 13.2 Relationships between datasets and other resources, a new property dcat:qualifiedRelation and a new class dcat:Relationship added to support relationships between datasets or other resources. See Issue #79.
• A new section § 7. Dereferenceable identifiers was added to describe how to indicate different types of identifiers by using [DCTERMS] and [VOCAB-ADMS]. See Issue #53 and Issue #68.
• A new section § 13.1 Relationships between datasets and agents was added to recommend a pattern for assigning an agent to a cataloged resource with a qualified relationship. See Issue #79.
• Property: had role: The property dcat:hadRole is added to support the use of prov:qualifiedAttribution to associate an agent with a resource, where the role of the agent with relation to the resource is specified, and is something other than the standard [DCTERMS] roles: creator, publisher or contributor. See Issue #79
• Property: resource creator: The property dct:creator is recommended for use in the context of a dataset or other resource to allow the entity responsible for generating the resource 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 cataloged resource to capture general relationships, including the case where the package of resources associated with a cataloged item includes a mixture of representations, parts, documentation and other elements which are not strictly 'distributions' of a dataset - see Issue #253. The more general use of dct:relation is driven by the requirement documented in Issue #81.
• 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.
• Errors in examples of dcat:mediaType usage fixed. See Issue #170.
• A new section § 12. Quality information was added to provie recommendations for how to associate quality information to datasets using elements from the W3C DQV vocabulary [VOCAB-DQV]. Since [VOCAB-DQV] is not a rec-track document, these are non-normative. See Issue #57 and Issue #58.
• Class: Cataloged resource: In DCAT 2014 [VOCAB-DCAT-20140116] the scope of a dcat:Catalog was limited to datasets. This has been generalized, and properties common to all cataloged resources are now associated with a super-class dcat:Resource. See Issue #172 and Issue #116.
• Class: Data service: In DCAT 2014 [VOCAB-DCAT-20140116] the scope of a dcat:Catalog was limited to datasets. The new class dcat:DataService has been added to support cataloging of various kinds of data services. See Issue #172, Issue #56, Issue #432, Issue #821.
• Class: Dataset: In DCAT 2014 [VOCAB-DCAT-20140116] dcat:Dataset was a sub-class of dctype:Dataset, which is a term of the DCMI Types vocabulary [DCTERMS]. This relationship has been removed in the revised DCAT vocabulary. See Issue #98.
• 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: type/genre: Added in DCAT revision. See Issue #64, with examples of usage in overview section.
• 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.
• Property: conforms to: DCAT 2014 [VOCAB-DCAT-20140116] had no way of representing the conformance of a record metadata with a metadata standard. This revision has added the property dct:conformsTo for dcat:CatalogRecord to cover this requirement. See Issue #502.
• Each relevant class section was extended with properties to deal with licensing, access rights, other rights and policies associated with the classes, as recommended in § 8. License and rights statements.
• A new section § 8. License and rights statements was added to provide guidance and recommendations for the use of dct:license, dct:accessRights, and dct:rights in the context of dcat catalogs and distributions. See Issue #114 for the background discussion.

• Class: Catalog: This class has been made a sub-class of dcat:Dataset. Moreover, the following properties have been added: dct:hasPart, to specify a cataloged resource, irrespective of its type; dcat:service, to specify a cataloged data service; dcat:catalog, to specify sub-catalogs. See Issue #172.

[DC11]

Dublin Core Metadata Element Set, Version 1.1. DCMI. 14 June 2012. DCMI Recommendation. URL: http://dublincore.org/documents/dces/

[DCTERMS]

DCMI Metadata Terms. DCMI Usage Board. DCMI. 14 June 2012. DCMI Recommendation. URL: http://dublincore.org/documents/dcmi-terms/

[FOAF]

FOAF Vocabulary Specification 0.99 (Paddington Edition). Dan Brickley; Libby Miller. FOAF project. 14 January 2014. URL: http://xmlns.com/foaf/spec

[GeoSPARQL]

GeoSPARQL - A Geographic Query Language for RDF Data. Matthew Perry; John Herring. OGC. 10 September 2012. URL: http://www.opengeospatial.org/standards/geosparql

[IANA-MEDIA-TYPES]

Media Types. IANA. URL: https://www.iana.org/assignments/media-types/

[LOCN]

ISA Programme Location Core Vocabulary. Andrea Perego; Michael Lutz. European Commission. 23 March 2015. Second version in w3.org/ns space. URL: http://www.w3.org/ns/locn

[ODRL-MODEL]

ODRL Information Model 2.2. Renato Iannella; Serena Villata. W3C. 15 February 2018. W3C Recommendation. URL: https://www.w3.org/TR/odrl-model/

[ODRL-VOCAB]

ODRL Vocabulary & Expression 2.2. Renato Iannella; Michael Steidl; Stuart Myles; Víctor Rodríguez-Doncel. W3C. 15 February 2018. W3C Recommendation. URL: https://www.w3.org/TR/odrl-vocab/

[OWL-TIME]

Time Ontology in OWL. Simon Cox; Chris Little. W3C. 19 October 2017. W3C Recommendation. URL: https://www.w3.org/TR/owl-time/

[OWL2-OVERVIEW]

OWL 2 Web Ontology Language Document Overview (Second Edition). W3C OWL Working Group. W3C. 11 December 2012. W3C Recommendation. URL: https://www.w3.org/TR/owl2-overview/

[PROV-O]

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

[RDF-SCHEMA]

RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/

[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119

[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://tools.ietf.org/html/rfc8174

[SKOS-REFERENCE]

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

[XMLSCHEMA11-2]

W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. W3C. 5 April 2012. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema11-2/

[DataCite]

DataCite Metadata Schema. DataCite Metadata Working Group. DataCite e.V. 16 August 2019. URL: https://schema.datacite.org/

[DATETIME]

Date and Time Formats. W3C. 27 August 1998. W3C Note. URL: https://www.w3.org/TR/NOTE-datetime

[DATS]

Data Tag Suite. Alejandra Gonzalez-Beltran; Philippe Rocca-Serra. NIH Big Data 2 Knowledge bioCADDIE and NIH Data Commons projects. 2016. URL: https://datatagsuite.github.io/docs/html/

[DBPEDIA-ONT]

DBPedia ontology. URL: http://dbpedia.org/ontology/

[DCAP]

Guidelines for Dublin Core Application Profiles. Karen Coyle; Thomas Baker. DCMI. 18 May 2009. DCMI Recommended Resource. URL: http://dublincore.org/documents/profile-guidelines/

[DCAT-AP]

DCAT Application Profile for data portals in Europe. Version 1.2.1. European Commission. 28 May 2019. URL: https://joinup.ec.europa.eu/solution/dcat-application-profile-data-portals-europe

[DCAT-AP-IT]

Profilo metadatazione DCAT-AP_IT. AgID & Team Digitale. URL: https://docs.italia.it/italia/daf/linee-guida-cataloghi-dati-dcat-ap-it/it/stabile/dcat-ap_it.html

[DCAT-AP-NO]

Standard for beskrivelse av datasett og datakataloger (DCAT-AP-NO). URL: https://doc.difi.no/dcat-ap-no/

[DCAT-AP-SE]

DCAT-AP-SE: Swedish recommendation for DCAT-AP1.1. Matthias Palmér. URL: https://lankadedata.se/spec/DCAT-AP-SE

[DCAT-AP.de]

Vokabulare und Dokumente für DCAT-AP.de. URL: https://dcat-ap.de/def/

[DCAT-BE]

Linking data portals across Belgium.. URL: http://dcat.be/

[DCAT-UCR]

Dataset Exchange Use Cases and Requirements. Jaroslav Pullmann; Rob Atkinson; Antoine Isaac; Ixchel Faniel. W3C. 17 January 2019. W3C Note. URL: https://www.w3.org/TR/dcat-ucr/

[DOAP]

Description of a Project. Edd Wilder-James. URL: https://github.com/ewilderj/doap/wiki

[DWBP]

Data on the Web Best Practices. Bernadette Farias Loscio; Caroline Burle; Newton Calegari. W3C. 31 January 2017. W3C Recommendation. URL: https://www.w3.org/TR/dwbp/

[EARL10-Schema]

Evaluation and Report Language (EARL) 1.0 Schema. Shadi Abou-Zahra. W3C. 2 February 2017. W3C Note. URL: https://www.w3.org/TR/EARL10-Schema/

[FAIR]

The FAIR Guiding Principles for scientific data management and stewardship. Mark D. Wilkinson et al. Nature. Scientific Data, vol. 3, Article nr. 160018. URL: https://doi.org/10.1038/sdata.2016.18

[GeoDCAT-AP]

GeoDCAT-AP: A geospatial extension for the DCAT application profile for data portals in Europe. Version 1.0.1. European Commission. 2 August 2016. URL: https://joinup.ec.europa.eu/solution/geodcat-application-profile-data-portals-europe

[GeoDCAT-AP-IT]

GeoDCAT-AP in Italy, the national guidelines published. URL: https://joinup.ec.europa.eu/news/geodcat-apit

[HCLS-Dataset]

Dataset Descriptions: HCLS Community Profile. Alasdair Gray; M. Scott Marshall; Michel Dumontier. W3C. 14 May 2015. W3C Note. URL: https://www.w3.org/TR/hcls-dataset/

[HTML-RDFa]

HTML+RDFa 1.1 - Second Edition. Manu Sporny. W3C. 17 March 2015. W3C Recommendation. URL: https://www.w3.org/TR/html-rdfa/

[HYDRA]

Hydra Core Vocabulary. Markus Lanthaler. Hydra W3C Community Group. 15 March 2018. Unofficial Draft. URL: https://www.hydra-cg.com/spec/latest/core/

[IANA-RELATIONS]

Link Relations. IANA. URL: https://www.iana.org/assignments/link-relations/

[IANA-URI-SCHEMES]

Uniform Resource Identifier (URI) Schemes. IANA. URL: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

[INSPIRE-DoC]

INSPIRE Registry: Degrees of conformity. European Commission. URL: http://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity/

[INSPIRE-SDST]

INSPIRE Registry: Spatial data service types. European Commission. URL: http://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/

[IRI]

Internationalized Resource Identifiers (IRIs). M. Duerst; M. Suignard. IETF. January 2005. Proposed Standard. URL: https://tools.ietf.org/html/rfc3987

[ISO-19115]

Geographic information -- Metadata. ISO/TC 211. ISO. 2003. International Standard. URL: https://www.iso.org/standard/26020.html

[ISO-19115-1]

Geographic information -- Metadata -- Part 1: Fundamentals. ISO/TC 211. ISO. 2014. International Standard. URL: https://www.iso.org/standard/53798.html

[ISO-19128]

Geographic information -- Web map server interface. ISO/TC 211. ISO. 2005. International Standard. URL: https://www.iso.org/standard/32546.html

[ISO-19142]

Geographic information -- Web Feature Service. ISO/TC 211. ISO. 2010. International Standard. URL: https://www.iso.org/standard/42136.html

[ISO-26324]

Information and documentation -- Digital object identifier system. ISO/TC 46/SC 9. ISO. 2012. International Standard. URL: https://www.iso.org/standard/43506.html

[ISO-IEC-25012]

ISO/IEC 25012 - Data Quality model. URL: http://iso25000.com/index.php/en/iso-25000-standards/iso-25012

[JSON-LD]

JSON-LD 1.0. Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/json-ld/

[LinkedDataPatterns]

Linked Data Patterns: A pattern catalogue for modelling, publishing, and consuming Linked Data. Leigh Dodds; Ian Davis. 31 May 2012. URL: http://patterns.dataincubator.org/book/

[MDR-AR]

Named Authority List: Access rights. Publications Office of the European Union. URL: https://publications.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/access-right

[N3]

Notation3 (N3): A readable RDF syntax. Tim Berners-Lee; Dan Connolly. W3C. 14 January 2008. W3C Team Submission. URL: https://www.w3.org/TeamSubmission/2008/SUBM-n3-20080114/

[netCDF]

Network Common Data Form (NetCDF). UNIDATA. URL: https://www.unidata.ucar.edu/software/netcdf/

[ODRS]

Open Data Rights Statement Vocabulary. Leigh Dodds. ODI. 29 July 2013. URL: http://schema.theodi.org/odrs

[OpenAPI]

OpenAPI Specification. Darrell Miller; Jeremy Whitlock; Marsh Gardiner; Mike Ralphson; Ron Ratovsky; Uri Sarid; Tony Tam; Jason Harmon. OpenAPI Initiative. URL: https://www.openapis.org/

[OpenSearch]

OpenSearch 1.1 Draft 6. DeWitt Clinton. OpenSearch. 17 April 2018. URL: https://github.com/dewitt/opensearch/blob/master/opensearch-1-1-draft-6.md

[OWL2-SYNTAX]

OWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax (Second Edition). Boris Motik; Peter Patel-Schneider; Bijan Parsia. W3C. 11 December 2012. W3C Recommendation. URL: https://www.w3.org/TR/owl2-syntax/

[RDF-SYNTAX-GRAMMAR]

RDF 1.1 XML Syntax. Dave Beckett. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-syntax-grammar/

[RDF11-CONCEPTS]

RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/

[RDF11-PRIMER]

RDF 1.1 Primer. Guus Schreiber; Yves Raimond. W3C. 24 June 2014. W3C Note. URL: https://www.w3.org/TR/rdf11-primer/

[RE3DATA-SCHEMA]

Metadata Schema for the Description of Research Data Repositories: version 3. Jessika Rücknagel et al. GFZ Potsdam. 17 December 2015. URL: https://doi.org/10.2312/re3.008

[RFC3986]

Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://tools.ietf.org/html/rfc3986

[SCHEMA-ORG]

Schema.org. URL: https://schema.org/

[SDW-BP]

Spatial Data on the Web Best Practices. Jeremy Tandy; Linda van den Brink; Payam Barnaghi. W3C. 28 September 2017. W3C Note. URL: https://www.w3.org/TR/sdw-bp/

[SHACL]

Shapes Constraint Language (SHACL). Holger Knublauch; Dimitris Kontokostas. W3C. 20 July 2017. W3C Recommendation. URL: https://www.w3.org/TR/shacl/

[ShEx]

Shape Expressions Language 2.1. Shape Expressions W3C Community Group. 17 November 2018. Draft Community Group Report. URL: http://shex.io/shex-semantics/

[SPARQL11-QUERY]

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

[SPARQL11-SERVICE-DESCRIPTION]

SPARQL 1.1 Service Description. Gregory Williams. W3C. 21 March 2013. W3C Recommendation. URL: https://www.w3.org/TR/sparql11-service-description/

[StatDCAT-AP]

StatDCAT-AP – DCAT Application Profile for description of statistical datasets. Version 1.0.1. European Commission. 28 May 2019. URL: https://joinup.ec.europa.eu/solution/statdcat-application-profile-data-portals-europe

[Turtle]

RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/turtle/

[VCARD-RDF]

vCard Ontology - for describing People and Organizations. Renato Iannella; James McKinney. W3C. 22 May 2014. W3C Note. URL: https://www.w3.org/TR/vcard-rdf/

[VIVO-ISF]

VIVO-ISF Data Standard. URL: https://github.com/vivo-isf/vivo-isf

[VOCAB-ADMS]

Asset Description Metadata Schema (ADMS). Phil Archer; Gofran Shukair. W3C. 1 August 2013. W3C Note. URL: https://www.w3.org/TR/vocab-adms/

[VOCAB-DATA-CUBE]

The RDF Data Cube Vocabulary. Richard Cyganiak; Dave Reynolds. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/vocab-data-cube/

[VOCAB-DCAT-20140116]

Data Catalog Vocabulary (DCAT). Fadi Maali; John Erickson. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/2014/REC-vocab-dcat-20140116/

[VOCAB-DQV]

Data on the Web Best Practices: Data Quality Vocabulary. Riccardo Albertoni; Antoine Isaac. W3C. 15 December 2016. W3C Note. URL: https://www.w3.org/TR/vocab-dqv/

[VOCAB-ORG]

The Organization Ontology. Dave Reynolds. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/vocab-org/

[VOCAB-SSN]

Semantic Sensor Network Ontology. Armin Haller; Krzysztof Janowicz; Simon Cox; Danh Le Phuoc; Kerry Taylor; Maxime Lefrançois. W3C. 19 October 2017. W3C Recommendation. URL: https://www.w3.org/TR/vocab-ssn/

[VOID]

Describing Linked Datasets with the VoID Vocabulary. Keith Alexander; Richard Cyganiak; Michael Hausenblas; Jun Zhao. W3C. 3 March 2011. W3C Note. URL: https://www.w3.org/TR/void/

[W3C-BASIC-GEO]

Basic Geo (WGS84 lat/long) Vocabulary. Dan Brickley. W3C Semantic Web Interest Group. 1 February 2006. URL: https://www.w3.org/2003/01/geo/

[WFS]

Web Feature Service 2.0 Interface Standard. Panagiotis (Peter) A. Vretanos. OGC. 10 July 2014. OGC Interface Standard. URL: http://www.opengeospatial.org/standards/wfs

[WMS]

Web Map Service Implementation Specification. Jeff de la Beaujardiere. OGC. 15 March 2006. OpenGIS Implementation Standard. URL: http://www.opengeospatial.org/standards/wms

[WSDL20]

Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. Roberto Chinnici; Jean-Jacques Moreau; Arthur Ryman; Sanjiva Weerawarana et al. W3C. 26 June 2007. W3C Recommendation. URL: https://www.w3.org/TR/wsdl20/

[ZaveriEtAl]

Quality assessment for Linked Data: A Survey. Amrapali Zaveri et al. IOS Press. 2015. Semantic Web, vol. 7, no. 1, pp. 63-93. URL: https://doi.org/10.3233/SW-150175

↑

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.5