Abstract

This document describes the profile of DCAT-AP developed by the European Commission's Joint Research Centre (JRC), and used in the JRC Data Catalogue for the documentation of multidisciplinary research data.

Introduction

This document describes DCAT-AP-JRC, the [[DCAT-AP]] extension developed by the European Commission's Joint Research Centre (JRC), and used in the JRC Data Catalogue for the documentation of multidisciplinary research data.

The following sections first illustrate the background () and the methodology () for the design of DCAT-AP-JRC, and then describe the underlying requirements ().

The DCAT-AP-JRC vocabulary specification is introduced by the list of used vocabularies (), a conformance statement (), and a high-level overview by the main entities represented in DCAT-AP-JRC ().

The actual definition of the classes and properties used in DCAT-AP-JRC is organised in the following sections:

Finally, the document is complemented with the following appendices:

Background

The overall mission of the Joint Research Centre of the European Commission (JRC) is to support EU policies with independent evidence throughout the whole policy life-cycle. The activities of the JRC span many different research areas, that address and ensure a healthy and safe environment, secure energy supplies, sustainable mobility and consumer health and safety. Thus, the JRC is a multidisciplinary research organisation and the diversity of its research activities poses challenges in the management of data, since different scientific disciplines have their own traditions, standards and best-practices on how to manage and disseminate research information.

In order to provide a basis for better management of data, in 2014 the JRC developed a corporate data policy [[JRC-DP]], driven by the need of transparency in the policy development life-cycle, and to facilitate open access to research data, in line with the general Open Data trend.

As part of the activities concerning the implementation of the JRC Data Policy, JRC has set up a corporate data catalogue, which is meant to be a single point of access to data produced and/or maintained by JRC. In this context, metadata play a fundamental role, and are meant to address a number of requirements, which include (a) ensuring data documentation and inventory, (b) enabling data discovery and (c) publishing metadata on other catalogues operated by EU institutions and bodies - in particular, the EU Open Data Portal.

For more details about the JRC Data Policy and its implementation, we refer the reader to [[iiWAS17-JRC]].

The multidisciplinary nature of JRC datasets makes it difficult to define a consistent set of metadata elements able to fit all requirements. Therefore, the design of the JRC metadata schema is following a modular approach consisting of a core profile, defining the elements that should be common to all metadata records, and a set of domain-specific extensions.

The reference metadata standard used is the DCAT application profile for European data portals (DCAT-AP) [[DCAT-AP]], and the related domain-specific extensions - namely, [[GeoDCAT-AP]] (for geospatial metadata) and [[StatDCAT-AP]] (for statistical metadata).

[[DCAT-AP]] is a metadata profile developed in the framework of the EU Programme Interoperability Solutions for European Public Administrations (ISA), and based on and compliant with the W3C Data Catalog vocabulary (DCAT) [[VOCAB-DCAT]] - currently, one of the most widely used Semantic Web vocabularies for describing datasets and data catalogues.

The purpose of [[DCAT-AP]] is to define a common interchange metadata format for data portals of the EU and of EU Member States. In order to achieve this, [[DCAT-AP]] defines a set of classes and properties, grouped into mandatory, recommended and optional. Such classes and properties correspond to information on datasets and data catalogues that are shared by many European data portals, aiding interoperability.

The motivation for using [[DCAT-AP]] as the reference metadata schema is manifold:

The core profile of the JRC metadata schema (referred to as DCAT-AP-JRC) is however not using DCAT-AP as is, but it extends it with a number of metadata elements that have been identified as most relevant across scientific domains, and which are required in order to support data citation.

The following sections provide a summary of the adopted solutions, and discuss a number of issues still to be addressed.

Methodology

Reference vocabularies

The reference metadata specifications on which DCAT-AP-JRC is based are the following ones:

DCAT-AP-JRC builds as much as possible upon these specifications to define all those metadata elements that are common across scientific disciplines. However, additional vocabularies have been used whenever the reference specifications were not providing appropriate mechanisms to address the identified requirements.

These additional vocabularies have been chosen based on the following criteria:

  1. They have clear persistence and versioning policies.
  2. Preferably, they should be used across domains and data communities.

The classes and properties from these additional vocabularies have been selected, whenever possible, taking into account other metadata standards. In particular, [[?DataCite]] has been functional to the selection of additional terms from [[?DCTERMS]], as [[?DataCite]] is heavily inspired on it. For this purpose, a preliminary study has been carried out to map DataCite to DCAT-AP [[?CiteDCAT-AP]], and the relevant mapped classes and properties have been incorporated into DCAT-AP-JRC.

DCAT-AP-JRC extensions

As already mentioned in , DCAT-AP-JRC includes all the classes and properties common to all metadata, irrespective of their domain.

Domain-specific metadata are nonetheless supported in DCAT-AP-JRC by integrating the corresponding [[DCAT-AP]] extensions. Currently, the supported extensions are the following ones:

GeoDCAT-AP-JRC
It corresponds to the union of DCAT-AP-JRC and [[GeoDCAT-AP]]. This extension is tipically used for [[?ISO-19115]] metadata converted to DCAT-AP-JRC.
StatDCAT-AP-JRC
It corresponds to the union of DCAT-AP-JRC and [[StatDCAT-AP]]. This extension is tipically used for [[?SDMX]] metadata converted to DCAT-AP-JRC.
CiteDCAT-AP-JRC
It corresponds to the union of DCAT-AP-JRC and [[?CiteDCAT-AP]]. This extension is tipically used for [[?DataCite]] metadata converted to DCAT-AP-JRC.

Metadata scope

As done in [[DCAT-AP]] and the other reference specifications, DCAT-AP-JRC defines the "obligation" for each class and property (namely, whether they are mandatory, recommended, or optional), as well as their cardinality.

Obligations and cardinality determine the minimal requirements for DCAT-AP-JRC-compliant records. However, they just provide an incomplete guidance to determine which classes and properties could be relevant for specific use cases. E.g., describing also catalogue records is not relevant for most use cases, but it is something that cannot be avoided when running a data catalogue.

For this reason, DCAT-AP-JRC classes and properties are annotated also with the "scope(s)" where their use is relevant. The used "metadata scopes" are the following ones:

Data documentation
This is the primary scope of metadata, and it is supposed to be relevant for all use cases. It concerns the description of data for purposes concerning data discovery, provenance, context, as well as data quality and fit for purpose.
Data citation
This covers classes and properties which are relevant to enable data citation.
Metadata management
This covers classes and properties which are relevant to effectively manage and maintain metadata records in a data catalogue, along their whole lifecycle.
Metadata sharing and re-use
This covers classes and properties which are relevant when metadata records are harvested across catalogues or, more in general, shared and re-used across communities and platforms.

It is worth noting that the defined scopes provide just a general classification, and therefore they are neither necessarily exhaustive, nor cover all use cases.

Requirements

This section illustrates the requirements behind the development of DCAT-AP-JRC, and provides as well an outline of the proposed solutions.

Part of these requirements has been described in [[SDSVoc16-27]], and afterwards contributed for further assessment to the the W3C Dataset Exchange Working Group (DXWG), in charge of the revision of [[VOCAB-DCAT]]. For the list of these requirements, and the corresponding DXWG use cases, see .

Requirements for scientific data

Metadata elements relevant across disciplines

The most common, cross-domain requirements we identified for JRC data are following ones:

  1. Ability to indicate dataset authors.
  2. Ability to describe data lineage.
  3. Ability to give potential data consumers information on how to use the data ("usage notes").
  4. Ability to link to (scientific) publications about a dataset.
  5. Ability to link to input data (i.e., data used to create a dataset).

Points (2) (data lineage) and (5) (input data) are already supported by DCAT-AP via, respectively, dct:provenance and dct:source. The other ones are instead not supported by [[DCAT-AP]].

More precisely:

  • [[DCAT-AP]] includes only two agent roles, namely, publisher and contact point, but not one for dataset authors. However, [[GeoDCAT-AP]] does include this role, which is specified by using property dct:creator. DCAT-AP-JRC uses the same approach.

    For more details, see .

  • [[DCAT-AP]] does not include specific properties for usage notes and publications about datasets, and they can only be specified by using the property dct:relation, which is too generic to address the identified requirements. Consequently, new properties have been included in DCAT-AP-JRC for this purpose, namely, vann:usageNote (for usage notes) and dct:isReferencedBy (for publications).

    For more details, see and , respectively.

Data citation

DataCite is an international initiative meant to enable citation for scientific datasets. To achieve this, DataCite operates a metadata infrastructure, following the same approach used by CrossRef for scientific publications. As such, the DataCite infrastructure is responsible for issuing persistent identifiers (in particular, DOIs) for datasets, and for registering dataset metadata. Such metadata are to be provided according to the DataCite metadata schema [[?DataCite]] – which is basically an extension to the one used for DOI records.

Since DataCite is currently the de facto standard for data citation, we started by carrying out a preliminary study concerning the mapping of DataCite with DCAT-AP [[CiteDCAT-AP]].

Based on this work, we recognised that what needs to be added in [[DCAT-AP]] for data citation purposes is basically only one "field" (already mentioned above), namely, "data authors" - which matches one of the requirements illustrated in .

In addition to this, data citation requirements have been taken into account to determine which resource properties are mandatory, as they are essential to create a bibliographic citation. More precisely, these properties are the following ones:

  • Contributor / author (see ).
  • Title (see ).
  • Publisher (see ).
  • Publication date (see ).
  • Identifiers for both the dataset ( and ) and the contributors ().

Finally, the information above has been complemented with a specific field for the full biliographic citation, which is meant to indicate which is the preferred way to cite a resource.

For more details, see (for datasets) and (for publications).

Contributors' / authors' order

This requirement is strictly related to the previous two ones, of which it could be considered a sub-requirement.

It is often the case that the order according to which contributors / authors are listed denotes the role played by each of them in the creation / curation of a resource. Preserving this information is frequently important to correctly acknowledge the level of importance and type of contribution of each contributor / author.

In RDF, there are two specific constructs that can be used to represent an ordered set of resources, namely, RDF Sequences (see § 5.1.3 rdf:Seq in [[RDF-SCHEMA]]) and RDF Collections (see § 5.2 RDF Collections in [[RDF-SCHEMA]]). An alternative approach, adopted in the [[SCoRO]] ontology, is to specify explicitly the actual type of contribution and the level of importance of a contributor.

RDF Sequences and RDF Collections introduce, however, a high level of complexity, which affects also metadata management. On the other hand, [[SCoRO]] has the advantage of providing more useful information, compared with the simple order of contributors (which, in some cases, may not reflect their "importance" in the creation of a resource - e.g., the order can be just alphabetical). However, information about the actual role played by contributors, as well as the importance of their contribution, is typically missing, and contributors themselves may not be able to indicate it.

For the reasons above, DCAT-AP-JRC adopts a simple mechanism, which is meant to record the contributors' / authors' order by listing them as a formatted string, and in addition specifies each single contributor / author as a separate resource.

For more details on this approach, see:

  • for datasets, and
  • for publications, and

Additional requirements

Analysing the characteristics of JRC data, we identified additional requirements which are not specifically related to research data.

Dataset collections

The data published on the JRC Data Catalogue are maintained by different teams, and are the output of different projects. As a result, different people are in charge of documenting only a given subset of the published data.

In order to cope with this situation, DCAT-AP-JRC includes the notion of "dataset collection" ("collection", for short), which includes the datasets whose maintenance and documentation are in charge of a specific team. Moreover, a team can be in charge of multiple collections, in case the related datasets are the output of different projects, or belong to different thematic areas, etc.

The possibility of grouping the datasets of a catalogue into subsets is already supported in [[DCAT-AP]], via the notion of "sub-catalogue". Therefore, DCAT-AP-JRC follows the same approach for modelling collections.

For more details, see .

Catalogue endpoints

The dataset collections published on the JRC Data Catalogue are regularly harvested from different platforms (i.e., other catalogues), making available metadata in different formats ([[?ISO-19115]], [[?DataCite]], [[VOCAB-DCAT]], as well as custom metadata), and via different protocols ([[?CSW]], [[?OAI-PMH]], HTTP/FTP folders, custom APIs and database interfaces). Each of these platforms / catalogues can have one or more of these "harvesting endpoints", and, similarly, each dataset collection may be associated with one or more of them.

In such a scenario, which is a typical situation in federated catalogues, it is important to have information about these harvesting endpoints, their supported metadata schemas and protocols in order to automise the harvesting and metadata transformation procedures. For this reason, DCAT-AP-JRC includes the notion of "catalogue endpoint" ("endpoint", for short), which is modelled as both a catalogue (to denote the set of metadata available from it) and a service / API. Moreover, each endpoint is linked to the relevant catalogue and collection.

To model endpoints as services, DCAT-AP-JRC follows the approach defined in [[GeoDCAT-AP]].

For more details, see .

Dataset-catalogue relationship

When metadata records are harvested across catalogues, one of the important pieces of information is the original catalogue from which a record has been harvested. [[DCAT-AP]] and [[VOCAB-DCAT]] include a relationship, namely, dcat:dataset, to link a catalogue to the documented datasets, but this information will be lost when a dataset record is harvested in another catalogue. In order to address this issue, DCAT-AP-JRC makes use of property dct:isPartOf as the inverse property of dcat:dataset. Notably, dct:isPartOf is the inverse property of dct:hasPart, which is in turn the super-property of dcat:dataset.

For more details, see and .

Dataset quality conformance

The conformance of a dataset with given quality criteria is an important piece of information to understand its fit for purpose, as well as the rules followed for data management.

A typical example, applying both to scientific and government data, are the data policies determining why and how for a dataset is published, its use and access conditions, etc. Other examples concern compliance with best practices (as those defined in [[?DWBP]], [[?SDW-BP]], and [[?FAIR]]), interoperability frameworks (as the one defined in INSPIRE [[?INSPIRE-SDSS-REG]]), and specific quality policies. For a more details and examples on the notion of quality conformance, we refer the reader to [[?VOCAB-DQV]] - in particular, § 6.11 Express the conformance of a dataset's metadata with a standard and § 6.12 Express the conformance of a dataset with a quality policy.

For this purpose, [[DCAT-AP]] supports the use of property dct:conformsTo to express conformance in the general sense, and [[GeoDCAT-AP]] re-uses it specifically to (a) specify conformance with test results against data quality criteria, and (b) the coordinate reference system used. DCAT-AP-JRC follows the same approach and, in addition, it uses property dct:conformsTo with class dct:Policy for the specific cases when the relevant resource is a data policy.

For more details, see and .

"Other" dataset-related resources

Besides landing pages, distributions, publications, data lineage and usage notes, JRC datasets are often associated with resources with other types of relationships. They can be any type of resource - a document, a piece of software, a Web site, a service / API, as well as another dataset.

None of these additional relationships is used in JRC datasets so frequently to require specific properties. For this reason, following [[DCAT-AP]], these resources are specified in DCAT-AP-JRC by using the generic property dct:relation (see ).

To describe this type of generic resources, which are left untyped, DCAT-AP-JRC makes use of the same properties used for distributions. The reason of this choice is that these properties are fit for describing heterogeneous resources. The difference is that the only mandatory properties are the resource title (dct:title) and the resource URL (dcat:accessURL / dcat:downloadURL), whereas description, format, licence, and access restrictions are recommended or optional.

The use of dcat:accessURL / dcat:downloadURL for generic resources is theoretically incorrect, as the range of these properties is dcat:Distribution. However, since these resources are left untyped, formally this use does not break compliance with [[VOCAB-DCAT]] or [[DCAT-AP]].

For more details, see .

Identifiers

Identifiers are applicable to different resource types, and for different purposes.

For simplicity, it is possible to group identifiers into two main types:

  1. Internal / primary identifiers, which are meant to identify a resource internally to a given catalogue, and are also important in federated harvesting scenarios as they are a means to specify from which catalogue they have been harvested (this especially when such identifiers are encoded as dereferenceable URIs).
  2. Additional / secondary identifiers, assigned by existing registers. E.g., the scientific community makes wide use of different (possibly persistent) identifiers, especially for publications, but now increasingly for authors and data. Including in metadata the (possibly multiple) persistent identifier(s) of a resouce is important not only for citation purposes, but also to unambiguously link related resources.

In DCAT-AP-JRC, internal / primary identifiers are assigned to all resources that are maintained in the catalogue, and that are supposed to be harvested by other catalogues. This includes:

  • Catalogues (see )
  • Catalogue records (see )
  • Collections (see )
  • Endpoints (see )
  • Datasets (see )
  • Agents - i.e., contributors, authors, publishers (see for individuals, and for organisations)
  • Publications (see )

As far as additional / secondary identifiers are concerned, they are used in DCAT-AP-JRC for all resources that could be cited, or that could be part of a citation (e.g., authors / contributors). This includes:

  • Catalogues (see )
  • Collections (see )
  • Datasets (see )
  • Agents - i.e., contributors, authors, publishers (see for individuals, and for organisations)
  • Publications (see )

It is worth noting that, for citation purposes, it is important to make explicit the identifier "type" (e.g., DOI, ORCID, ISNI).

For modelling identifiers, DCAT-AP-JRC follows [[DCAT-AP]], which already provides a mechanism to model internal and additional identifiers. More precisely:

  • Property dct:identifier is used for internal / primary identifiers.
  • Property adms:identifier is used for additional / secondary identifiers. The range of this property is class adms:Identifier, which allows the specification of additional information about the identifier - identifier scheme included.

Notably, such solutions are basically reflecting the [[DataCite]] approach, which distinguishes between primary / alternative identifiers, and specifies their type. However, identifiers modelled in this way are of no use for effectively linking the relevant resources. For this reason, DCAT-AP-JRC follows the approach defined in [[CiteDCAT-AP]] (§ 6.2 Identifiers), and specifies identifiers both as literals and, whenever possible, also as URIs.

More precisely:

  • Identifiers are encoded as HTTP URIs, whenever possible, or URNs, using owl:sameAs for URIs concerning additional / secondary identifiers.
  • In addition:
    • Internal / primary identifiers are specified, as literals, with dct:identifier.
    • Additional / secondary identifiers are specified, as literals, with adms:identifier.

For more details, see (for identifiers modelled as literals) and (for identifiers modelled as URIs).

Agent roles

The need of agent roles in addition to those supported in [[DCAT-AP]] has been already illustrated in and , where the importance of being able to specify the dataset author(s) / contributor(s) has been motivated.

However, another issue is that the agent roles supported in [[DCAT-AP]] for specific resource types could also be relevant for other ones. This applies in particular to "contact points", a key role for any type of resource, whereas in [[DCAT-AP]] and [[VOCAB-DCAT]] they are associated only with datasets.

In order to address this issue, DCAT-AP-JRC extends [[DCAT-AP]] by supporting the specification of contact points not only for datasets, but also for catalogues, endpoints, collections, and collection records. Following [[GeoDCAT-AP]], this is done by using property dcat:contactPoint.

It is worth noting that this use of dcat:contactPoint does not respect the domain restriction of this property - namely, dcat:Dataset. This property is however used also on other resource types as the alternative would have been defining a new one, with exactly the same semantics.

For more details on the use of contact points in DCAT-AP-JRC, see:

  • for catalogues,
  • for datasets,
  • for endpoints,
  • for collections,
  • for catalogue records,

Short names / acronyms

Some resource types are frequently referred to by using an acronym rather than their full "name", which act also as a human-targeted / mnemonic identifier. For the same reason, and also because their "length" is more fit for user and administration interfaces, such acronyms / short names are also used as the "primary" name of a resource in data management tools and catalogues.

This information is supported in several metadata schemas, as [[?DataCite]] and [[?RE3DATA-SCHEMA]] (used for cataloguing data repositories), but [[DCAT-AP]] does not include a property for this.

For these reasions, DCAT-AP-JRC uses property dct:alternative for specifying short names / acronyms for resources as catalogues, collections, and endpoints.

For more details on the use of short names / acronyms in DCAT-AP-JRC, see:

  • for catalogues,
  • for endpoints, .
  • for collections,

Spatial coverage code lists

[[DCAT-AP]] recommends the use of code lists [[MDR-CONT]] (continents) and [[MDR-COUNTRIES]] (countries) when spatial coverage is to be specified with a geographical name, with the fall-back option of using [[?GEONAMES]].

By reviewing JRC datasets, we realised that there is another reference code list used, especially for statistical data, namely, the UNSD Standard country or area codes for statistical use (M49) [[UNSD-M49]]. Notably, [[UNSD-M49]] includes geographical areas not covered by [[MDR-CONT]] and [[MDR-COUNTRIES]] - as global and sub-continental areas.

For this reason, DCAT-AP-JRC includes support for [[UNSD-M49]] to complement [[MDR-CONT]] and [[MDR-COUNTRIES]] with additional levels of granularity (global, sub-regions, intermediate regions).

As a formal definition of [[UNSD-M49]] is not available, a SKOS [[SKOS-REFERENCE]] representation of it has been developed, and integrated it with the [[MDR-CONT]] and [[MDR-COUNTRIES]] code lists. More precisely, this integrated code list makes use of [[MDR-CONT]] and [[MDR-COUNTRIES]] for continents and countries, respectively, and of [[UNSD-M49]] for the other geographical areas.

These code lists cover all the relevant geographical areas, also in terms of granularity, used to indicate spatial coverage in JRC data. Therefore, DCAT-AP-JRC does not make use of [[?MDR-PLACES]] and [[?GEONAMES]].

For more details, see and .

Dataset status

Knowing the status of a dataset with respect to its lifecycle can be important both for administrative purposes and for users. E.g., if a catalogue makes use of persistent identifiers, datasets (or, at least, their metadata) cannot be deleted even when they are discontinued, deprecated, or withdrawn. However, it is important for users to know that they should not use those data, or that a given dataset is no longer maintained.

In order to address this issue, DCAT-AP-JRC extends [[DCAT-AP]] by supporting the specification of the dataset status by using the [[MDR-DS]] code list. For more details, see .

Distribution access restrictions

The types of possible access restrictions of a dataset are one of the key filtering criteria for data consumers. For instance, while searching in a data catalogue, users may not be interested in those data they cannot access (closed data), or in those data requiring users provide personal information (as data that can be accessible by anyone, but only after registration).

In [[DCAT-AP]], this issue is partially addressed by supporting the specification of access restrictions at the dataset level via the [[MDR-AR]] code list (which although does not cover the case when data are accessible only after registration). However, in some cases, a dataset is associated with multiple distributions posing different constraints in terms of access rights. E.g., one distribution may be an anonymised version of the dataset, and it can be made publicly available, whereas the other one can be the non-anonymised version, which can therefore be accessible only by authorised users.

For this reason, DCAT-AP-JRC supports the specification of access restrictions at the distribution level.

The identified types of access restrictions are the following ones:

No limitations
The distribution can be anonymously accessed.
Registration required
The distribution can be accessed by anyone, but only after registration.
Authorisation required
The distribution can be accessed only by authorized users.

These access restrictions are defined in an ad hoc code list. For more details, see .

Distribution types and functions

It is often the case that distributions do not point to a file or a download page, but rather to a service / API from which users can access the data. Examples include SPARQL endpoints and services like [[WMS]], [[WFS]], etc., typically used for geospatial data. The result is that users are returned resources (as machine- or human-readable description of the service / API interface) providing no direct means to access the data. Morever, using these services / APIs may require specific expertise and/or software tools.

It is therefore important to flag a distribution to clarify the "type" of resource which will be returned - namely, if it gives access to a service / API, or rather to a file / download page.

This issue was already addressed in the framework of the DCAT-AP Implementation Guidelines [[DCAT-AP-IG]] - see DT2: Service-based data access. DCAT-AP-JRC follows the approach defined there, by using the relevant values from the [[MDR-DT]] code list, and by specifying the service / API type via a URI identifying it (see ).

An additional issue concerns whether the distribution points to a resource which gives access to the data or instead provides a visualisation of it. It is worth noting that this case is ortogonal to the one of the distribution "type" outlined above, as whether a resource has an access or visualisation "function" it is independent of whether this is obtained via a direct link to a file / download page or via a service / API. Although there is not a specific code list for this purpose, the [[MDR-DT]] code list includes a value to state that a distribution provides data visualisation. Therefore, DCAT-AP-JRC uses it for that purpose, whereas when the distribution function is not specified, the assumption is that the distribution gives access to the data.

For more details, see and .

Improving data discoverability on the Web

Last years have seen the publication of an increasing amount and variety of data and a consequent proliferation of data catalogues. If these has had clear benefits for data consumers, who are now no longer limited to domain experts, finding the data you are looking for is not easy, unless you know in advance where they are available from.

In order to address this issue, more and more data catalogues are now taking care not only of documenting data, but also of optimising their publication in order to make them discoverable by mainstream search engines. One of the techniques used for this purpose is to embed metadata in Web pages, with mechanisms as [[?HTML-RDFa]], [[?MICRODATA]], [[?JSON-LD]] (see § 6.20 Embedding JSON-LD in HTML Documents), and by using vocabularies as [[?DCTERMS]], [[?VOCAB-DCAT]], and [[?SCHEMA-ORG]] - which has been specifically developed for this purpose.

To facilitate the indexing and discovery of datasets documented by using DCAT-AP-JRC, mapping rules have been defined to generate a [[?SCHEMA-ORG]] representation, that can be embedded in catalogue pages.

Notably, the [[?SCHEMA-ORG]] subset for describing datasets is historically derived from [[?VOCAB-DCAT]], which in turn widely re-uses classes and properties from [[?DCTERMS]]. Consequently, the mapping between these vocabularies is pretty straightforward, although the conversion may lead to information loss - as illustrated by the [[?DCAT-AP]] to [[?SCHEMA-ORG]] mapping exercise documented in [[?DCAT-AP-SDO]].

For more details, see .

Namespaces

In its current version, DCAT-AP-JRC does not define classes or properties of its own, but it re-uses elements from other vocabularies, following the best practices for data vocabularies described in [[?DWBP]].

The table below indicates the full list of namespaces and prefixes of the vocabularies and specifications used in DCAT-AP-JRC.

Prefix Namespace URI Specification
adms http://www.w3.org/ns/adms# [[!VOCAB-ADMS]]
dc http://purl.org/dc/elements/1.1/ [[!DC11]]
dcat http://www.w3.org/ns/dcat# [[!VOCAB-DCAT]]
dct http://purl.org/dc/terms/ [[!DCTERMS]]
dctype http://purl.org/dc/dcmitype/ [[!DCTERMS]]
foaf http://xmlns.com/foaf/0.1/ [[!FOAF]]
gsp http://www.opengis.net/ont/geosparql# [[!GeoSPARQL]]
locn http://www.w3.org/ns/locn# [[!LOCN]]
org http://www.w3.org/ns/org# [[!VOCAB-ORG]]
owl http://www.w3.org/2002/07/owl# [[!OWL-REF]]
rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# [[!RDF-CONCEPTS]]
rdfs http://www.w3.org/2000/01/rdf-schema# [[!RDF-SCHEMA]]
schema http://schema.org/ [[?SCHEMA-ORG]]
skos http://www.w3.org/2004/02/skos/core# [[!SKOS-REFERENCE]]
vann http://purl.org/vocab/vann/ [[!VANN]]
vcard http://www.w3.org/2006/vcard/ns# [[!VCARD-RDF]]
xsd http://www.w3.org/2001/XMLSchema# [[!XMLSCHEMA11-2]]

Vocabulary overview

provides a high-level description of the main resource types represented in DCAT-AP-JRC, and their relationships. In the figure, grayed boxes denote optional resource types.

The main entities represented in DCAT-AP-JRC
The main entities represented in DCAT-AP-JRC

Vocabulary specification

The following sections define the class and properties used in DCAT-AP-JRC. More precisely, after providing an overview of the classes used in DCAT-AP-JRC (), class definitions and the corresponding properties are grouped as follows:

The tables in the following sections include these columns:

Classes

Primary classes

The following table lists the classes corresponding to the main resource types described in DCAT-AP-JRC.

Label Obl. RDF Class Scope Spec.
Catalogue M dcat:Catalog All [[DCAT-AP]]
Dataset M dcat:Dataset All [[DCAT-AP]]
Contact point M vcard:Kind All [[DCAT-AP]]
Agent Individual M foaf:Person DD, DC [[DCAT-AP]]
Organisation foaf:Organization
Distribution R dcat:Distribution All [[DCAT-AP]]
Publication R foaf:Document DD DCAT-AP-JRC
Endpoint O dcat:Catalog + dctype:Service MM, MS [[GeoDCAT-AP]]
Collection O dcat:Catalog All [[DCAT-AP]]
Catalogue record O dcat:CatalogRecord MM, MS [[DCAT-AP]]
Other resource O owl:Thing DD [[DCAT-AP]]

Secondary classes

The following table lists classes which are merely functional to the specification of characteristics of the primary classes in a structured way.

Label RDF Class Scope Spec.
Lineage dct:ProvenanceStatement DD [[DCAT-AP]]
Usage notes foaf:Document DD DCAT-AP-JRC
Identifier adms:Identifier DD, DC [[DCAT-AP]]
Spatial coverage as geoname dct:Location DD [[DCAT-AP]]
as geometry
Temporal coverage dct:PeriodOfTime DD [[DCAT-AP]]

Mandatory classes

Class: Catalogue

Label Catalogue
Obligation Mandatory
RDF Class dcat:Catalog
Definition A curated collection of metadata about datasets. [[VOCAB-DCAT]]
Scope All
Specification [[DCAT-AP]]

The following table lists the properties used for describing a catalogue.

Label Obl. MC RDF Property Range Scope Spec.
title M 1* dct:title rdfs:Literal All [[DCAT-AP]]
description M 1* dct:description rdfs:Literal All [[DCAT-AP]]
contact point M 1 dcat:contactPoint vcard:Kind All [[GeoDCAT-AP]]
publisher M 1 dct:publisher foaf:Organization All [[DCAT-AP]]
dataset M N dcat:dataset dcat:Dataset All [[DCAT-AP]]
identifier R 1 dct:identifier rdfs:Literal MM, MS DCAT-AP-JRC
acronym R 1 dct:alternative rdfs:Literal DD, MM DCAT-AP-JRC
landing page R 1 foaf:homepage foaf:Document All [[DCAT-AP]]
other identifier R N owl:sameAs owl:Thing DD, DC DCAT-AP-JRC
adms:identifier adms:Identifier
collection O N dct:hasPart dcat:Catalog All [[DCAT-AP]]
catalogue record O N dcat:record dcat:CatalogRecord MM, MS [[DCAT-AP]]

Property: title

Label title
Obligation Mandatory
Max card. 1*
RDF Property dct:title
Range rdfs:Literal
Definition The name / title of the catalogue.
Scope All
Specification [[DCAT-AP]]

Property: description

Label description
Obligation Mandatory
Max card. 1*
RDF Property dct:description
Range rdfs:Literal
Definition The description of the catalogue.
Scope All
Specification [[DCAT-AP]]

Property: contact point

Label contact point
Obligation Mandatory
Max card. 1
RDF Property dcat:contactPoint
Range vcard:Kind ()
Definition The contact point for the catalogue.
Scope All
Specification [[GeoDCAT-AP]]
Requirement

Property: publisher

Label publisher
Obligation Mandatory
Max card. 1
RDF Property dct:publisher
Range foaf:Organization ()
Definition The organisation responsible for the publication of the catalogue.
Usage note This property MUST take as value one of the corporate bodies defined in [[!MDR-CB]] (see ).
Scope All
Specification [[DCAT-AP]]

Property: dataset

Label dataset
Obligation Mandatory
Max card. N
RDF Property dcat:dataset
Range dcat:Dataset ()
Definition A dataset belonging to the catalogue.
Scope All
Specification [[DCAT-AP]]

Property: identifier

Label identifier
Obligation Recommended
Max card. 1
RDF Property dct:identifier
Range rdfs:Literal
Definition Internal identifier for the catalogue.
Scope Metadata Management, Metadata Sharing and Re-use
Specification DCAT-AP-JRC
Requirement

Property: acronym

Label acronym
Obligation Recommended
Max card. 1
RDF Property dct:alternative
Range rdfs:Literal
Definition The short name / acronym used for the catalogue.
Scope Data Documentation, Metadata Management
Specification DCAT-AP-JRC
Requirement

Property: landing page

Label landing page
Obligation Recommended
Max card. 1
RDF Property foaf:homepage
Range foaf:Document
Definition The landing page for the catalogue.
Scope All
Specification [[DCAT-AP]]

Property: other identifier

The identifier is expressed both as a literal, using class adms:Identifier, and as a URI, via owl:sameAs, whenever the identifier can be specified in form of URI (see ).

Property: other identifier (as URI)

Label other identifier
Obligation R
Max card. N
RDF Property owl:sameAs
Range owl:Thing
Definition An additional identifier for the catalogue, expressed as a URI.
Usage note This property SHOULD be used whenever it is possible to specify the identifier as a URI (see ).
Scope Data Documentation, Data Citation
Specification DCAT-AP-JRC
Requirement

Property: other identifier (as literal)

Label other identifier
Obligation R
Max card. N
RDF Property adms:identifier
Range adms:Identifier ()
Definition An additional identifier for the catalogue, expressed as a literal.
Usage note This property SHOULD be used whenever it is necessary to specify the identifier type (see ).
Scope Data Documentation, Data Citation
Specification DCAT-AP-JRC
Requirement

Property: collection

Label collection
Obligation Optional
Max card. N
RDF Property dct:hasPart
Range dcat:Catalog ()
Definition A dataset collection in the catalogue - i.e., a set of datasets in a catalogue, grouped according to a given criterion.
Usage note This property MAY be used when datasets in a catalogue are organised into groups, corresponding to different thematic areas, maintained by different teams, etc. (see ).
Scope All
Specification [[DCAT-AP]]
Requirement

Property: catalogue record

Label catalogue record
Obligation Optional
Max card. N
RDF Property dcat:record
Range dcat:CatalogRecord ()
Definition A metadata record describing a resource in the catalogue.
Scope Metadata Management, Metadata Sharing and Re-use
Specification [[DCAT-AP]]

Class: Dataset

Label Dataset
Obligation Mandatory
RDF Class dcat:Dataset
Definition A collection of data, published or curated by a single agent, and available for access or download in one or more formats. [[VOCAB-DCAT]]
Scope All
Specification [[DCAT-AP]]

The following table lists the properties used for describing a dataset.

Label Obl. MC RDF Property Range Scope Spec.
identifier M 1 dct:identifier rdfs:Literal All [[DCAT-AP]]
title M 1* dct:title rdfs:Literal All [[DCAT-AP]]
description M 1* dct:description rdfs:Literal All [[DCAT-AP]]
publication date M 1 dct:issued rdfs:Literal All [[DCAT-AP]]
bibliographic citation M 1 dct:bibliographicCitation rdfs:Literal DC DCAT-AP-JRC
update frequency M 1 dct:accrualPeriodicity skos:Concept All [[DCAT-AP]]
theme M N dcat:theme skos:Concept All [[DCAT-AP]]
contact point M 1 dcat:contactPoint vcard:Kind All [[DCAT-AP]]
individual contributor M N dct:creator foaf:Person DD, DC [[GeoDCAT-AP]]
corporate contributor M N dct:creator foaf:Organization DD, DC [[GeoDCAT-AP]]
contributor(s) M 1 dc:creator rdfs:Literal DD, DC DCAT-AP-JRC
publisher M 1 dct:publisher foaf:Organization All [[DCAT-AP]]
other identifier R N owl:sameAs owl:Thing DD, DC [[DCAT-AP]]
adms:identifier adms:Identifier
status R 1 adms:status skos:Concept All [[StatDCAT-AP]]
modification date R 1 dct:modified rdfs:Literal All [[DCAT-AP]]
keyword R N dcat:keyword rdfs:Literal All [[DCAT-AP]]
temporal coverage R N dct:temporal dct:PeriodOfTime All [[DCAT-AP]]
spatial coverage R N dct:spatial dct:Location All [[DCAT-AP]]
landing page R 1 dcat:landingPage foaf:Document All [[DCAT-AP]]
distribution R N dcat:distribution dcat:Distribution All [[DCAT-AP]]
publication R N dct:isReferencedBy foaf:Document DD DCAT-AP-JRC
language O N dct:language dct:LinguisticSystem All [[DCAT-AP]]
lineage O N dct:provenance dct:ProvenanceStatement DD [[DCAT-AP]]
usage notes O N vann:usageNote foaf:Document DD DCAT-AP-JRC
input data O N dct:source dcat:Dataset DD [[DCAT-AP]]
other resource O N dct:relation owl:Thing DD [[DCAT-AP]]
catalogue O 1 dct:isPartOf dcat:Catalog MM, MS DCAT-AP-JRC
conforms to O N dct:conformsTo dct:Standard DD, MM, MS [[DCAT-AP]]
data policy O N dct:conformsTo dct:Policy DD, MM, MS DCAT-AP-JRC

Property: identifier

Label identifier
Obligation Mandatory
Max card. 1
RDF Property dct:identifier
Range rdfs:Literal
Definition The internal identifier of the dataset.
Usage note The value for this property MUST correspond to the dataset URI, and it MUST be a persistent identifier.
Scope All
Specification [[DCAT-AP]]
Requirement

Property: title

Label title
Obligation Mandatory
Max card. 1*
RDF Property dct:title
Range rdfs:Literal
Definition The dataset title.
Scope All
Specification [[DCAT-AP]]
Requirement

Property: description

Label description
Obligation Mandatory
Max card. 1*
RDF Property dct:description
Range rdfs:Literal
Definition The dataset title.
Scope All
Specification [[DCAT-AP]]

Property: publication date

Label publication date
Obligation Mandatory
Max card. 1
RDF Property dct:issued
Range rdfs:Literal
Definition The date when the dataset was first published.
Usage note The range of this property is intentionally generic, with the purpose of allowing different level of temporal precision for specifying the publication date. E.g., it can be expressed with a date (xsd:date), a date and time (xsd:dateTime), or a year (xsd:gYear).
Scope All
Specification [[DCAT-AP]]
Requirement

Property: bibliographic citation

Label bibliographic citation
Obligation Mandatory
Max card. 1
RDF Property dct:bibliographicCitation
Range rdfs:Literal
Definition The bibliographic citation of the dataset.
Usage note

This property is meant to indicate which is the preferred way to cite the dataset.

The value for this property MAY be automatically generated by re-using information contained in existing fields - e.g., contributor(s), publication date, title, publisher, persistent identifier(s) - i.e., the dataset URI, plus other persistent identifiers, when available.

Scope Data Citation
Specification DCAT-AP-JRC
Requirement

Property: update frequency

Label update frequency
Obligation Mandatory
Max card. 1
RDF Property dct:accrualPeriodicity
Range skos:Concept
Definition The frequency at which a dataset is updated.
Usage note This property MUST take as value one of the frequency codes defined in [[!MDR-FREQ]]
Scope All
Specification [[DCAT-AP]]

Property: theme

Label theme
Obligation Mandatory
Max card. N
RDF Property dcat:theme
Range skos:Concept
Definition The dataset thematic areas(s).
Usage note This property MUST take as value one of the themes defined in [[MDR-THEMES]]
Scope All
Specification [[DCAT-AP]]

Property: contact point

Label contact point
Obligation Mandatory
Max card. 1
RDF Property dcat:contactPoint
Range vcard:Kind ()
Definition The dataset contact point.
Scope All
Specification [[DCAT-AP]]
Requirement

Property: contributor

The contributors of a dataset can be either individuals or organisations (corporate contributors) - usually, not both -, which are specified with the same property (dct:creator), but using different ranges. For this reason, they are described separately in the following sections.

Note that their obligation is set to "conditional" as at least one of these types of contributors MUST be specified.

Property: individual contributor

Label individual contributor
Obligation Conditional
Max card. N
RDF Property dct:creator
Range foaf:Person ()
Definition An individual who contributed in the creation of the dataset.
Scope Data Documentation, Data Citation
Specification [[GeoDCAT-AP]]
Requirement ,

Property: corporate contributor

Label corporate contributor
Obligation Conditional
Max card. N
RDF Property dct:creator
Range foaf:Organization ()
Definition An organisation who contributed in the creation of the dataset.
Usage note This property MUST take as value one of the corporate bodies defined in [[!MDR-CB]], or a complementary one, in case the organisation is not included in [[!MDR-CB]] - see for more details.
Scope Data Documentation, Data Citation
Specification [[GeoDCAT-AP]]
Requirement ,

Property: contributor(s)

Label contributor(s)
Obligation Mandatory
Max card. 1
RDF Property dc:creator
Range rdfs:Literal
Definition The dataset contributor(s), specified as a formatted string.
Usage note

This property SHOULD be used to specify the contributors' order.

The contributors' list SHOULD be specified as a semi-colon separated string, where each contributor is specified with family name and given name, separated with a comma. E.g.:

Doe, John; Foe, Jane
Scope Data Documentation, Data Citation
Specification DCAT-AP-JRC
Requirement ,

Property: publisher

Label publisher
Obligation Mandatory
Max card. 1
RDF Property dct:publisher
Range foaf:Organization ()
Definition The organisation responsible for the publication of the dataset.
Usage note This property MUST take as value one of the corporate bodies defined in [[!MDR-CB]].
Scope All
Specification [[DCAT-AP]]
Requirement

Property: other identifier

The identifier is expressed both as a literal, using class adms:Identifier, and as a URI, via owl:sameAs, whenever the identifier can be specified in form of URI (see ).

Property: other identifier (as URI)

Label other identifier
Obligation Recommended
Max card. N
RDF Property owl:sameAs
Range owl:Thing
Definition An additional identifier for the dataset, expressed as a URI.
Usage note This property SHOULD be used whenever it is possible to specify the identifier as a URI (see ).
Scope Data Documentation, Data Citation
Specification [[DCAT-AP]]
Requirement

Property: other identifier (as literal)

Label other identifier
Obligation Recommended
RDF Property adms:identifier
Range adms:Identifier ()
Definition An additional identifier for the dataset, expressed as a literal.
Usage note This property SHOULD be used whenever it is necessary to specify the identifier type (see ).
Scope Data Documentation, Data Citation
Specification [[DCAT-AP]]
Requirement

Property: status

Label status
Obligation Recommended
Max card. 1
RDF Property adms:status
Range skos:Concept
Definition The lifecycle status of the dataset.
Usage note This property MUST take as value one of the statuses defined in [[!MDR-DS]].
Scope All
Specification [[StatDCAT-AP]]
Requirement

Property: modification date

Label modification date
Obligation Recommended
Max card. 1
RDF Property dct:modified
Range rdfs:Literal
Definition The date of last modification of the dataset.
Usage note The range of this property is intentionally generic, with the purpose of allowing different level of temporal precision for specifying the modification date. E.g., it can be expressed with a date (xsd:date), a date and time (xsd:dateTime), or a year (xsd:gYear).
Scope All
Specification [[DCAT-AP]]

Property: keyword

Label keyword
Obligation Recommended
Max card. N
RDF Property dcat:keyword
Range rdfs:Literal
Definition A free-text keyword describing the dataset.
Scope All
Specification [[DCAT-AP]]

Property: temporal coverage

Label temporal coverage
Obligation Recommended
Max card. N
RDF Property dct:temporal
Range dct:PeriodOfTime ()
Definition The temporal coverage of the dataset.
Usage note The interval MUST be specified as defined in [[DCAT-AP]], namely, by indicating the start and/or end date by using schema:startDate and schema:endDate, respectively.
Scope All
Specification [[DCAT-AP]]

Property: spatial coverage

Label spatial coverage
Obligation Recommended
Max card. N
RDF Property dct:spatial
Range dct:Location ()
Definition The spatial coverage of the dataset.
Usage note The spatial coverage MUST be specified as defined in [[DCAT-AP]], namely, either by using a geographical name or with a geometry. In the former case, property dct:spatial MUST take as value one of the geographical names defined in [[!MDR-CONT]] (for continents), [[!MDR-COUNTRIES]] (for countries), and [[!UNSD-M49]] (for the other geographical areas). In the latter case, the geometry MUST be specified by using dct:Location, with property locn:geometry [[!LOCN]] (see ).
Scope All
Specification [[DCAT-AP]]

Property: landing page

Label landing page
Obligation Recommended
Max card. 1
RDF Property dcat:landingPage
Range foaf:Document
Definition The landing page of the dataset.
Usage note Typically, the landing page is specified only with its URI.
Scope All
Specification [[DCAT-AP]]

Property: distribution

Label distribution
Max card. N
Obligation Recommended
RDF Property dcat:distribution
Range dcat:Distribution ()
Definition A distribution of the dataset.
Scope All
Specification [[DCAT-AP]]

Property: publication

Label publication
Obligation Recommended
Max card. N
RDF Property dct:isReferencedBy
Range foaf:Document ()
Definition A (scientific) publication about the dataset.
Scope Data Documentation
Specification DCAT-AP-JRC
Requirement

Property: language

Label language
Obligation Optional
Max card. N
RDF Property dct:language
Range dct:LinguisticSystem
Definition A natural language used in the dataset.
Usage note This property MUST take as value one of the languages defined in [[!MDR-LANG]]
Scope All
Specification [[DCAT-AP]]

Property: lineage

Label lineage
Obligation Optional
Max card. N
RDF Property dct:provenance
Range dct:ProvenanceStatement ()
Definition A description of how the dataset has been created, in terms of source data, methodology, etc.
Usage note This property can either point to an existing lineage document (human- or machine-readable) via its URI, or to a dct:ProvenanceStatement including such description (see ).
Scope Data Documentation
Specification [[DCAT-AP]]
Requirement

Property: usage notes

Label usage note
Obligation Optional
Max card. N
RDF Property vann:usageNote
Range foaf:Document ()
Definition A description of how the dataset can be used.
Usage note This property can either point to an existing document (human- or machine-readable) via its URI, or to a foaf:Document including such description (see ).
Scope Data Documentation
Specification DCAT-AP-JRC
Requirement

Property: input data

Label input data
Obligation O
Max card. N
RDF Property dct:source
Range dcat:Dataset
Definition A dataset used to create the described dataset.
Usage note Typically, the input dataset is specified only with its URI.
Scope Data Documentation
Specification [[DCAT-AP]]
Requirement

Property: other resource

Label other resource
Obligation O
Max card. N
RDF Property dct:relation
Range owl:Thing ()
Definition A resource having a relationship with the described dataset.
Usage note This property is meant to be used for resources whose relationship with the dataset are different from distribution, publication, input data, lineage, usage notes. For more information on dataset-related resources, see .
Scope Data Documentation
Specification [[DCAT-AP]]
Requirement

Property: catalogue

Label catalogue
Obligation O
Max card. 1
RDF Property dct:isPartOf
Range dcat:Catalog ()
Definition The catalogue where the dataset is documented.
Usage note The catalogue is typically denoted with its URI. Alternatively, it MAY be described as defined in . In both cases, it MUST be typed as a dcat:Catalog.
Scope Metadata Management, Metadata Sharing and Re-use
Specification DCAT-AP-JRC
Requirement

Property: conforms to

Label conforms to
Obligation O
Max card. N
RDF Property dct:conformsTo
Range dct:Standard
Definition A specification defining the quality criteria the dataset conforms to.
Usage note The specification is typically denoted with its URI. Alternatively, it MAY be described as a document, as defined in .
Scope Data Documentation, Metadata Management, Metadata Sharing and Re-use
Specification [[DCAT-AP]]
Requirement

Property: data policy

Label data policy
Obligation O
Max card. N
RDF Property dct:conformsTo
Range dct:Policy
Definition A data policy determining why and how a dataset is published, its use and access conditions, etc.
Usage note The data policy is typically denoted with its URI. Alternatively, it MAY be described as a document, as defined in . In both cases, it MUST be typed as a dct:Policy.
Scope Data Documentation, Metadata Management, Metadata Sharing and Re-use
Specification DCAT-AP-JRC
Requirement

Class: Contact point

Label Contact point
Obligation Mandatory
RDF Class vcard:Kind
Definition The contact point of a resource.
Scope All
Specification [[DCAT-AP]]

The following table lists the properties used for describing a contact point.

As can be seen, in DCAT-AP-JRC, contact information is limited to the contact email and/or the contact page (typically, just one of the two). Their "obligation" is set to "conditional", as at least one of the two MUST be provided.

Label Obl. MC RDF Property Range Scope Spec.
contact email C 1 vcard:hasEmail owl:Thing All [[GeoDCAT-AP]]
contact page C 1 vcard:hasURL owl:Thing All [[GeoDCAT-AP]]

Property: contact email

Label contact email
Obligation C
Max card. 1
RDF Property vcard:hasEmail
Range owl:Thing
Definition The email of the dataset contact point.
Usage note This property MUST be used, unless the contact page is specified.
Scope All
Specification [[GeoDCAT-AP]]

Property: contact page

Label contact page
Obligation C
Max card. 1
RDF Property vcard:hasURL
Range owl:Thing
Definition The URL of the contact page for the dataset.
Usage note This property MUST be used, unless the contact email is specified.
Scope All
Specification [[GeoDCAT-AP]]

Class: Agent

Class: Individual

Label Individual
Obligation Mandatory
RDF Class foaf:Person
Definition An individual who played / plays a given role with respect to a resource (e.g., as contributor, author, publisher).
Scope Data Documentation, Data Citation
Specification [[DCAT-AP]]
Requirement ,

The following table lists the properties used for describing an individual.

Label Obl. MC RDF Property Range Scope Spec.
given name M 1 foaf:givenName rdfs:Literal DD, DC DCAT-AP-JRC
family name M 1 foaf:familyName rdfs:Literal DD, DC DCAT-AP-JRC
formatted name M 1 foaf:name rdfs:Literal DD, DC DCAT-AP-JRC
identifier R 1 dct:identifier rdfs:Literal MM, MS DCAT-AP-JRC
other identifier R N owl:sameAs owl:Thing DC DCAT-AP-JRC
adms:identifier adms:Identifier
email O 1 foaf:mbox owl:Thing DD [[GeoDCAT-AP]]

Property: given name

Label given name
Obligation M
Max card. 1
RDF Property foaf:givenName
Range rdfs:Literal
Definition The given name of the individual.
Scope Data Documentation, Data Citation
Specification DCAT-AP-JRC
Requirement ,

Property: family name

Label family name
Obligation Mandatory
Max card. 1
RDF Property foaf:familyName
Range rdfs:Literal
Definition The family name of the individual.
Scope Data Documentation, Data Citation
Specification DCAT-AP-JRC
Requirement ,

Property: formatted name

Label formatted name
Obligation M
Max card. 1
RDF Property foaf:name
Range rdfs:Literal
Definition The full name of the individual, formatted according to a given pattern.
Usage note

The formatted name SHOULD be specified with family name and given name, separated with a comma. E.g.: Doe, John

This information can be automatically derived from properties foaf:familyName and foaf:givenName.

Scope Data Documentation, Data Citation
Specification DCAT-AP-JRC
Requirement ,

Property: identifier

Label identifier
Obligation Recommended
RDF Property dct:identifier
Range rdfs:Literal
Definition The internal identifier for the individual.
Scope Metadata Management, Metadata Sharing and Re-use
Specification DCAT-AP-JRC
Requirement

Property: other identifier

The identifier is expressed both as a literal, using class adms:Identifier and as a URI, via owl:sameAs, whenever possible (see ).

Property: other identifier (as URI)

Label other identifier (as URI)
Obligation R
Max card. N
RDF Property owl:sameAs
Range owl:Thing
Definition An identifier for the individual, expressed as a URI.
Usage note This property SHOULD be used whenever it is possible to specify the identifier as a URI (see ).
Scope Data Documentation, Data Citation
Specification DCAT-AP-JRC
Requirement ,

Property: other identifier (as literal)

Label other identifier (as literal)
Obligation R
Max card. N
RDF Property adms:identifier
Range adms:Identifier ()
Definition An identifier for the individual, expressed as a literal.
Usage note This property SHOULD be used whenever it is necessary to specify the identifier type (see ).
Scope Data Documentation, Data Citation
Specification DCAT-AP-JRC
Requirement ,

Property: email

Label email
Obligation O
Max card. 1
RDF Property foaf:mbox
Range owl:Thing
Definition The individual's email.
Scope Data Documentation
Specification [[GeoDCAT-AP]]
Requirement

Class: Organisation

Label Organisation
Obligation Mandatory
RDF Class foaf:Organization
Definition An organisation who played / plays a given role with respect to a resource (e.g., as contributor, author, publisher).
Usage note

Organisations MUST be specified by using the relevant URI from the [[MDR-CB]] code list.

When the organisation is not registered in [[MDR-CB]], they SHOULD be specified by using URIs from other registries.

Scope Data Documentation, Data Citation
Specification [[DCAT-AP]]
Requirement ,

The following table lists the properties used for describing an organisation.

Label Obl. MC RDF Property Range Scope Spec.
name M 1* foaf:name rdfs:Literal DD DCAT-AP-JRC
identifier R 1 dct:identifier rdfs:Literal MM, MS DCAT-AP-JRC
acronym R 1 dct:alternative rdfs:Literal DD DCAT-AP-JRC
home page R 1 foaf:homepage foaf:Document DD DCAT-AP-JRC
other identifier R N owl:sameAs owl:Thing DD, DC DCAT-AP-JRC
adms:identifier adms:Identifier
parent organisation R 1 org:subOrganizationOf foaf:Organization DD DCAT-AP-JRC
logo O 1 foaf:logo owl:Thing DD DCAT-AP-JRC

Property: name

Label name
Obligation Mandatory
RDF Property foaf:name
Range rdfs:Literal
Definition The organisation name.
Scope Data Documentation
Specification DCAT-AP-JRC

Property: identifier

Label identifier
Obligation Recommended
RDF Property dct:identifier
Range rdfs:Literal
Definition The internal identifier for the organisation.
Scope Metadata Management, Metadata Sharing and Re-use
Specification DCAT-AP-JRC
Requirement

Property: acronym

Label acronym
Obligation Recommended
RDF Property dct:alternative
Range rdfs:Literal
Definition The organisation short name / acronym.
Scope Data Documentation
Specification DCAT-AP-JRC

Property: home page

Label home page
Obligation Recommended
RDF Property foaf:homepage
Range foaf:Document
Definition The organisation's Web site.
Scope Data Documentation
Specification DCAT-AP-JRC

Property: other identifier

The identifier is expressed both as a literal, using class adms:Identifier and as a URI, via owl:sameAs, whenever possible (see ).

Property: other identifier (as URI)

Label other identifier (as URI)
Obligation Recommended
Max card. N
RDF Property owl:sameAs
Range owl:Thing
Definition An identifier for the organisation, expressed as a URI.
Usage note This property SHOULD be used whenever it is possible to specify the identifier as a URI (see ).
Scope Data Documentation, Data Citation
Specification DCAT-AP-JRC
Requirement ,

Property: other identifier (as literal)

Label other identifier (as literal)
Obligation Recommended
Max card. N
RDF Property adms:identifier
Range adms:Identifier ()
Definition An identifier for the organisation, expressed as a literal.
Usage note This property SHOULD be used whenever it is necessary to specify the identifier type (see ).
Scope Data Documentation, Data Citation
Specification DCAT-AP-JRC
Requirement ,

Property: parent organisation

Label parent organisation
Obligation Recommended
RDF Property org:subOrganizationOf
Range foaf:Organization
Definition The organisation's parent organisation.
Usage note This property MUST take as value one of the corporate bodies defined in [[!MDR-CB]].
Scope Data Documentation
Specification DCAT-AP-JRC

Optional classes

Class: Endpoint

Label Endpoint
Obligation Optional
RDF Class dcat:Catalog + dctype:Service
Definition A harvesting endpoint of a catalogue, serving metadata in given format(s) and via a given protocol.
Scope Metadata Management, Metadata Sharing and Re-use
Specification [[GeoDCAT-AP]]
Requirement

The following table lists the properties used for describing an endpoint.

Label Obl. MC RDF Property Range Scope Spec.
title M 1* dct:title rdfs:Literal MM, MS [[GeoDCAT-AP]]
contact point M 1 dcat:contactPoint vcard:Kind MM, MS [[GeoDCAT-AP]]
publisher M 1 dct:publisher foaf:Organization MM, MS [[GeoDCAT-AP]]
catalogue M 1 dct:isPartOf dcat:Catalog MM, MS [[GeoDCAT-AP]]
dataset M N dcat:dataset dcat:Dataset MM, MS [[GeoDCAT-AP]]
protocol M 1 dct:conformsTo dct:Standard MM, MS DCAT-AP-JRC
supported schema M N adms:supportedSchema adms:Asset MM, MS DCAT-AP-JRC
access URL M 1 foaf:homepage foaf:Document MM, MS [[GeoDCAT-AP]]
identifier R 1 dct:identifier rdfs:Literal MM, MS DCAT-AP-JRC
acronym R 1 dct:alternative rdfs:Literal MM, MS DCAT-AP-JRC
description R 1* dct:description rdfs:Literal MM, MS [[GeoDCAT-AP]]
collection O 1 dct:isPartOf dcat:Catalog MM, MS DCAT-AP-JRC
catalogue record O N dcat:record dcat:CatalogRecord MM, MS [[GeoDCAT-AP]]

Property: title

Label title
Obligation Mandatory
Max card. 1*
RDF Property dct:title
Range rdfs:Literal
Definition The name / title of the endpoint.
Scope Metadata Management, Metadata Sharing and Re-use
Specification [[GeoDCAT-AP]]
Requirement

Property: contact point

Label contact point
Obligation Mandatory
Max card. 1
RDF Property dcat:contactPoint
Range vcard:Kind
Definition The contact point for the endpoint.
Scope Metadata Management, Metadata Sharing and Re-use
Specification [[GeoDCAT-AP]]
Requirement ,

Property: publisher

Label publisher
Obligation Mandatory
Max card. 1
RDF Property dct:publisher
Range foaf:Organization
Definition The organisation responsible for the publication of the endpoint.
Usage note This property MUST take as value one of the corporate bodies defined in [[!MDR-CB]].
Scope Metadata Management, Metadata Sharing and Re-use
Specification [[GeoDCAT-AP]]
Requirement

Property: catalogue

Label catalogue
Obligation Mandatory
Max card. 1
RDF Property dct:isPartOf
Range dcat:Catalog ()
Definition The catalogue to which the endpoint belongs.
Scope Metadata Management, Metadata Sharing and Re-use
Specification [[GeoDCAT-AP]]
Requirement

Property: dataset

Label dataset
Obligation Mandatory
Max card. N
RDF Property dcat:dataset
Range dcat:Dataset ()
Definition A dataset whose metadata are available from the endpoint.
Scope Metadata Management, Metadata Sharing and Re-use
Specification [[GeoDCAT-AP]]
Requirement

Property: protocol

Label protocol
Obligation Mandatory
Max card. 1
RDF Property dct:conformsTo
Range dct:Standard ()
Definition The service / API protocol of the endpoint.
Usage note This property SHOULD take as value one of the URIs denoting a service / API protocols for catalogue services defined in the register illustrated in .
Scope Metadata Management, Metadata Sharing and Re-use
Specification DCAT-AP-JRC
Requirement

Property: supported schema

Label protocol
Obligation Mandatory
Max card. N
RDF Property adms:supportedSchema
Range adms:Asset ()
Definition A metadata schema supported by the endpoint.
Usage note This property SHOULD take as value one of the URIs denoting one of the metadata schemas defined in the register illustrated in .
Scope Metadata Management, Metadata Sharing and Re-use
Specification DCAT-AP-JRC
Requirement

Property: access URL

Label access URL
Obligation M
Max card. 1
RDF Property foaf:homepage
Range foaf:Document
Definition The endpoint access URL.
Usage note This property is meant to be used to specify the service / API base URL, without querying parameters, or the URL of the service / API machine-actionable description (e.g., the capabilities document of a [[?CSW]] endpoint, the ouput of an Identify request to an [[?OAI-PMH]] endpoint, an [[?OpenAPI]] description, etc.).
Scope Metadata Management, Metadata Sharing and Re-use
Specification [[GeoDCAT-AP]]
Requirement

Property: identifier

Label identifier
Obligation Recommended
Max card. 1
RDF Property dct:identifier
Range rdfs:Literal
Definition Internal identifier for the endpoint.
Scope Metadata Management, Metadata Sharing and Re-use
Specification DCAT-AP-JRC
Requirement

Property: acronym

Label acronym
Obligation Recommended
Max card. 1
RDF Property dct:alternative
Range rdfs:Literal
Definition The short name / acronym used for the endpoint.
Scope Metadata Management, Metadata Sharing and Re-use
Specification DCAT-AP-JRC
Requirement ,

Property: description

Label description
Obligation Recommended
Max card. 1*
RDF Property dct:description
Range rdfs:Literal
Definition The description of the endpoint.
Scope Metadata Management, Metadata Sharing and Re-use
Specification [[GeoDCAT-AP]]
Requirement

Property: collection

Label collection
Obligation Optional
Max card. 1
RDF Property dct:isPartOf
Range dcat:Catalog ()
Definition The collection whose records the endpoint gives access to.
Usage note This property MUST be used when endpoint gives access to resource from only one collection.
Scope Metadata Management, Metadata Sharing and Re-use
Specification DCAT-AP-JRC
Requirement

Property: catalogue record

Label catalogue record
Obligation O
Max card. N
RDF Property dcat:record
Range dcat:CatalogRecord ()
Definition A metadata record available from the endpoint.
Scope Metadata Management, Metadata Sharing and Re-use
Specification [[GeoDCAT-AP]]
Requirement

Class: Collection

Label Collection
Obligation Optional
RDF Class dcat:Catalog
Definition A set of datasets in a catalogue, grouped according to a given criterion.
Scope All
Specification [[DCAT-AP]]
Requirement

A collection denotes a subset of datasets in a catalogue, sharing some characteristics and/or provenance. E.g., they can be datasets produced in the framework of a given activity / project, and/or harvested from another catalogue, and/or having the same thematic scope etc.

A collection can also be used for supporting metadata management in a granular way. E.g., a catalogue used by different organisations, or by different teams of the same organisation, can use collections to limit the maintenance of a given set of records to a specific group. Similarly, a catalogue harvesting from other ones can use the same mechanism to give the owners of the harvested catalogues the possibility to configure the harvesting endpoint, frequency, etc.

As such, a collection is basically equivalent to the [[DCAT-AP]] notion of "sub-catalogue" - i.e., a catalogue whose datasets are included in another catalogue.

The following table lists the properties used for describing a collection.

Label Obl. MC RDF Property Range Scope Spec.
title M 1* dct:title rdfs:Literal All [[DCAT-AP]]
description M 1* dct:description rdfs:Literal All [[DCAT-AP]]
contact point M 1 dcat:contactPoint vcard:Kind All [[GeoDCAT-AP]]
publisher M 1 dct:publisher foaf:Organization All [[DCAT-AP]]
dataset M N dcat:dataset dcat:Dataset All [[DCAT-AP]]
identifier R 1 dct:identifier rdfs:Literal All DCAT-AP-JRC
acronym R 1 dct:alternative rdfs:Literal All DCAT-AP-JRC
landing page R 1 foaf:homepage foaf:Document All [[DCAT-AP]]
other identifier R N owl:sameAs owl:Thing DC DCAT-AP-JRC
adms:identifier adms:Identifier
catalogue record O N dcat:record dcat:CatalogRecord All [[DCAT-AP]]

Property: title

Label title
Obligation Mandatory
Max card. 1*
RDF Property dct:title
Range rdfs:Literal
Definition The name / title of the collection.
Scope All
Specification [[DCAT-AP]]
Requirement

Property: description

Label description
Obligation Mandatory
Max card. 1*
RDF Property dct:description
Range rdfs:Literal
Definition The description of the collection.
Scope All
Specification [[DCAT-AP]]
Requirement

Property: contact point

Label contact point
Obligation Mandatory
Max card. 1
RDF Property dcat:contactPoint
Range vcard:Kind ()
Definition The contact point for the collection.
Scope All
Specification [[GeoDCAT-AP]]
Requirement ,

Property: publisher

Label publisher
Obligation Mandatory
Max card. 1
RDF Property dct:publisher
Range foaf:Organization
Definition The organisation responsible for the publication of the collection.
Usage note This property MUST take as value one of the corporate bodies defined in [[!MDR-CB]].
Scope All
Specification [[DCAT-AP]]
Requirement

Property: dataset

Label dataset
Obligation Mandatory
Max card. N
RDF Property dcat:dataset
Range dcat:Dataset ()
Definition A dataset belonging to the collection.
Scope All
Specification [[DCAT-AP]]
Requirement

Property: identifier

Label identifier
Obligation Recommended
Max card. 1
RDF Property dct:identifier
Range rdfs:Literal
Definition Internal identifier for the collection.
Scope All
Specification DCAT-AP-JRC
Requirement

Property: acronym

Label acronym
Obligation Recommended
Max card. 1
RDF Property dct:alternative
Range rdfs:Literal
Definition The short name / acronym used for the collection.
Scope All
Specification DCAT-AP-JRC
Requirement ,

Property: landing page

Label landing page
Obligation Recommended
Max card. 1
RDF Property foaf:homepage
Range foaf:Document
Definition The landing page for the collection.
Scope All
Specification [[DCAT-AP]]
Requirement

Property: other identifier

The identifier is expressed both as a literal, using class adms:Identifier, and as a URI, via owl:sameAs, whenever the identifier can be specified in form of URI (see ).

Property: other identifier (as URI)

Label other identifier
Obligation Recommended
Max card. N
RDF Property owl:sameAs
Range owl:Thing
Definition An additional identifier for the collection, expressed as a URI.
Usage note This property SHOULD be used whenever it is possible to specify the identifier as a URI (see ).
Scope Data Citation
Specification DCAT-AP-JRC
Requirement

Property: other identifier (as literal)

Label other identifier
Obligation Recommended
Max card. N
RDF Property adms:identifier
Range adms:Identifier ()
Definition An additional identifier for the collection, expressed as a literal.
Usage note This property SHOULD be used whenever it is necessary to specify the identifier type (see ).
Scope Data Citation
Specification DCAT-AP-JRC
Requirement

Property: catalogue record

Label catalogue record
Obligation Optional
Max card. N
RDF Property dcat:record
Range dcat:CatalogRecord ()
Definition A metadata record describing a resource in the collection.
Scope All
Specification [[DCAT-AP]]
Requirement

Class: Catalogue record

Label Collection
Obligation Optional
RDF Class dcat:CatalogRecord
Definition A record in a catalogue, describing a single resource.
Scope Metadata Management, Metadata Sharing and Re-use
Specification [[DCAT-AP]]
Requirement

The following table lists the properties used for describing a catalogue record.

Label Obl. MC RDF Property Range Scope Spec.
primary topic M 1 foaf:primaryTopic owl:Thing MM, MS [[DCAT-AP]]
modification date M 1 dct:modified rdfs:Literal MM, MS [[DCAT-AP]]
status M 1 adms:status skos:Concept MM, MS DCAT-AP-JRC
contact point M 1 dcat:contactPoint vcard:Kind MM, MS [[GeoDCAT-AP]]
identifier R 1 dct:identifier rdfs:Literal MM, MS [[GeoDCAT-AP]]
listing date R 1 dct:created rdfs:Literal MM, MS [[DCAT-AP]]
metadata schema R N dct:conformsTo dct:Standard MM, MS [[DCAT-AP]]
source metadata record R 1 dct:source dcat:CatalogRecord MM, MS [[DCAT-AP]]

Property: primary topic

Label primary topic
Obligation Mandatory
Max card. 1
RDF Property foaf:primaryTopic
Range owl:Thing
Definition The resource described by a catalogue record.
Usage note Typically, the resource described by the catalogue record is specified only with its URI.
Scope Metadata Management, Metadata Sharing and Re-use
Specification [[DCAT-AP]]

Property: modification date

Label modification date
Obligation Mandatory
Max card. 1
RDF Property dct:modified
Range rdfs:Literal
Definition The date when a catalogue record was last modified.
Usage note The range of this property is intentionally generic, with the purpose of allowing different level of temporal precision for specifying the modification date. E.g., it can be expressed with a date (xsd:date) or a date and time (xsd:dateTime).
Scope Metadata Management, Metadata Sharing and Re-use
Specification [[DCAT-AP]]

Property: status

Label status
Obligation Mandatory
Max card. 1
RDF Property adms:status
Range skos:Concept
Definition The lifecycle status of a catalogue record (e.g., deprecated, discontinued, withdrawn).
Usage note This property MUST take as value one of the statuses defined in [[MDR-DS]]
Scope Metadata Management, Metadata Sharing and Re-use
Specification DCAT-AP-JRC

Property: contact point

Label contact point
Obligation Mandatory
Max card. 1
RDF Property dcat:contactPoint
Range vcard:Kind ()
Definition The contact point of a catalogue record.
Scope Metadata Management, Metadata Sharing and Re-use
Specification [[GeoDCAT-AP]]
Requirement

Property: identifier

Label identifier
Obligation Recommended
Max card. 1
RDF Property dct:identifier
Range rdfs:Literal
Definition The internal identifier of a catalogue record.
Scope Metadata Management, Metadata Sharing and Re-use
Specification [[GeoDCAT-AP]]

Property: listing date

Label listing date
Obligation Recommended
Max card. 1
RDF Property dct:created
Range rdfs:Literal
Definition The date when a catalogue record was first created.
Usage note The range of this property is intentionally generic, with the purpose of allowing different level of temporal precision for specifying the creation date. E.g., it can be expressed with a date (xsd:date) or a date and time (xsd:dateTime).
Scope Metadata Management, Metadata Sharing and Re-use
Specification [[DCAT-AP]]

Property: metadata schema

Label metadata schema
Obligation Recommended
Max card. N
RDF Property dct:conformsTo
Range dct:Standard ()
Definition A metadata schema the catalogue record conforms to.
Usage note This property SHOULD take as value one of the URIs denoting one of the metadata schemas defined in the register illustrated in .
Scope Metadata Management, Metadata Sharing and Re-use
Specification [[DCAT-AP]]

Property: source metadata record

Label souce metadata record
Obligation Recommended
Max card. N
RDF Property dct:source
Range dcat:CatalogRecord
Definition The metadata record from which the described record has been derived.
Usage note

This information SHOULD be specified whenever the current record has been harvested (and, possibly, transformed) from another catalogue.

Typically, the source metadata record is specified only with its URI.

Scope Metadata Management, Metadata Sharing and Re-use
Specification [[DCAT-AP]]

Class: Other resource

Label Other resource
Obligation Optional
RDF Class owl:Thing
Definition A resource having a relationship with the described dataset.
Usage note This class is meant to be used for resources whose relationship with the dataset are different from distribution, publication, input data, lineage, usage notes. It can be any type of resource - a document, a piece of software, a Web site, a service / API, as well as another dataset.
Scope Data Documentation
Specification [[DCAT-AP]]
Requirement

The following table lists the properties used for describing a resource related to a dataset.

Label Obl. MC RDF Property Range Scope Spec.
title M 1* dct:title rdfs:Literal DD DCAT-AP-JRC
access URL C 1 dcat:accessURL owl:Thing DD DCAT-AP-JRC
download URL C 1 dcat:downloadURL owl:Thing DD DCAT-AP-JRC
description R 1* dct:description rdfs:Literal DD DCAT-AP-JRC
format R 1 dct:format dct:MediaTypeOrExtent DD DCAT-AP-JRC
licence O 1 dct:license dct:LicenseDocument DD DCAT-AP-JRC
access restrictions O 1 dct:accessRights dct:RightsStatement DD DCAT-AP-JRC

Property: title

Label title
Obligation M
Max card. 1*
RDF Property dct:title
Range rdfs:Literal
Definition The resource title.
Scope Data Documentation
Specification DCAT-AP-JRC
Requirement

Property: access URL

Label access URL
Obligation C
Max card. 1
RDF Property dcat:accessURL
Range owl:Thing
Definition A landing page, feed, SPARQL endpoint, etc. that gives access to the resource.
Usage note

This property MUST be used, unless the download URL is specified.

Typically, the object of this property is specified only with its URI.

Scope Data Documentation
Specification DCAT-AP-JRC
Requirement

Property: download URL

Label download URL
Obligation C
Max card. 1
RDF Property dcat:downloadURL
Range owl:Thing
Definition A URL returning the resource in a given format.
Usage note

This property MUST be used, unless the access URL is specified.

Typically, the object of this property is specified only with its URI.

Scope Data Documentation
Specification DCAT-AP-JRC
Requirement

Property: description

Label description
Obligation R
Max card. 1*
RDF Property dct:description
Range rdfs:Literal
Definition The resource description.
Scope Data Documentation
Specification DCAT-AP-JRC
Requirement

Property: format

Label format
Obligation R
Max card. 1
RDF Property dct:format
Range dct:MediaTypeOrExtent
Definition The resource format.
Usage note This property MUST take as value one of the file formats defined in [[MDR-FT]]
Scope Data Documentation
Specification DCAT-AP-JRC
Requirement

Property: licence

Label licence
Obligation O
Max card. 1
RDF Property dct:license
Range dct:LicenseDocument
Definition The resource licence.
Usage note This property MUST take as value one of the licences defined in [[MDR-LICENCES]]
Scope Data Documentation
Specification DCAT-AP-JRC
Requirement

Property: access restrictions

Label access restrictions
Obligation O
Max card. 1
RDF Property dct:accessRights
Range dct:RightsStatement
Definition The resource access restrictions.
Usage note This property SHOULD take as value one of the access restriction codes defined in the register illustrated in .
Scope Data Documentation
Specification DCAT-AP-JRC
Requirement

Secondary classes

The following classes are denoted as "secondary" since they are merely functional to the specification in a structured way of characteristics of the primary classes (i.e., the classes denoted as mandatory, recommended, and optional).

Class: Lineage

Label Lineage
RDF Class dct:ProvenanceStatement
Definition A statement describing how a resource has been created, in terms of source data, methodology, etc.
Usage note This class is meant to be used to record, in a structured way, the description of the lineage of a resource, instead of pointing to an existing document (see ).
Scope Data Documentation
Specification [[DCAT-AP]]
Requirement

The following table lists the properties used for describing the lineage of a resource.

Label Obl. MC RDF Property Range Scope Spec.
label M 1 rdfs:label rdfs:Literal DD [[GeoDCAT-AP]]

Property: label

Label label
Obligation Mandatory
Max card. 1
RDF Property rdfs:label
Range rdfs:Literal
Definition A free text describing the lineage.
Scope Data Documentation
Specification [[GeoDCAT-AP]]
Requirement

Class: Usage notes

Label Usage notes
RDF Class foaf:Document
Definition A document providing a description of how the resource can be used.
Usage note This class is meant to be used to record, in a structured way, the description of how a resource can be used, instead of pointing to an existing document (see ).
Scope Data Documentation
Specification DCAT-AP-JRC
Requirement

The following table lists the properties used for specifying usage notes.

Label Obl. MC RDF Property Range Scope Spec.
label M 1 rdfs:label rdfs:Literal DD DCAT-AP-JRC

Property: label

Label label
Obligation Mandatory
Max card. 1
RDF Property rdfs:label
Range rdfs:Literal
Definition A free text describing usage notes.
Scope Data Documentation
Specification DCAT-AP-JRC
Requirement

Class: Identifier

Label Identifier
RDF Class adms:Identifier
Definition A structured description of an identifier.
Usage note This class is meant to be used whenever it is necessary to specify the identifier type, and possibly other characteristics (e.g., when the identifier was issued). Typically, this applies to persistent identifiers as ORCIDs, ISNIs, DOIs, etc.
Scope Data Documentation, Data Citation
Specification [[DCAT-AP]]
Requirement ,

The following table lists the properties used for describing an identifier.

Label Obl. MC RDF Property Range Scope Spec.
notation M 1 skos:notation rdfs:Literal DD, DC [[DCAT-AP]]
scheme agency name M 1 adms:schemeAgency rdfs:Literal DD, DC [[DCAT-AP]]
issue date R 1 dct:issued rdfs:Literal DD, DC [[DCAT-AP]]
scheme agency (as URI) O 1 dct:creator owl:Thing DD, DC [[DCAT-AP]]

Property: notation

Label notation
Obligation Mandatory
Max card. 1
RDF Property skos:notation
Range rdfs:Literal
Definition The identifier value (a string).
Scope Data Documentation, Data Citation
Specification [[DCAT-AP]]
Requirement ,

Property: scheme agency name

Label scheme agency
Obligation Mandatory
Max card. 1
RDF Property adms:schemeAgency
Range rdfs:Literal
Definition The agency issuing the identifier.
Usage note

This property MUST take as value one of the identifier scheme names defined in the register illustrated in , and it is used to specify the identifier "type".

This information MUST be specified when the identifier is issued by a scheme agency and/or follows a specific identifier scheme (DOI, ORCID, etc.).

Scope Data Documentation, Data Citation
Specification [[DCAT-AP]]
Requirement ,

Property: issue date

Label issue date
Obligation Recommended
Max card. 1
RDF Property dct:issued
Range rdfs:Literal
Definition The date when the identifier was issued.
Usage note The range of this property is intentionally generic, with the purpose of allowing different level of temporal precision for specifying the issue date. E.g., it can be expressed with a date (xsd:date), a date and time (xsd:dateTime), or a year (xsd:gYear).
Scope Data Documentation, Data Citation
Specification [[DCAT-AP]]
Requirement ,

Property: scheme agency (as URI)

Label scheme agency (as URI)
Obligation Optional
Max card. 1
RDF Property dct:creator
Range owl:Thing
Definition The agency issuing the identifier.
Usage note

This property MUST take as value one of the scheme agency URIs defined in the register illustrated in .

This information is complementary to the one provided by property adms:schemeAgency, and it MAY be specified when the identifier is issued by a scheme agency and/or follows a specific identifier scheme (DOI, ORCID, etc.).

Scope Data Documentation, Data Citation
Specification [[DCAT-AP]]
Requirement ,

Class: Temporal coverage

Label Temporal coverage
RDF Class dct:PeriodOfTime
Definition The period of time (possibly open) denoting the temporal coverage of a dataset.
Scope Data Documentation
Specification [[DCAT-AP]]

The following table lists the properties used for describing a period of time. Their obligation is set to "conditional", as at least one of the two MUST be specified.

Label Obl. MC RDF Property Range Scope Spec.
start date C 1 schema:startDate rdfs:Literal DD [[DCAT-AP]]
end date C 1 schema:endDate rdfs:Literal DD [[DCAT-AP]]

Property: start date

Label start date
Obligation Conditional
Max card. 1
RDF Property schema:startDate
Range rdfs:Literal
Definition The start date of a period of time.
Usage note

This property MUST be specified, if the end date is missing.

The range of this property is intentionally generic, with the purpose of allowing different level of temporal precision for specifying the start of a period. E.g., it can be expressed with a date (xsd:date), a date and time (xsd:dateTime), or a year (xsd:gYear).

Scope Data Documentation
Specification [[DCAT-AP]]

Property: end date

Label end date
Obligation Conditional
Max card. 1
RDF Property schema:endDate
Range rdfs:Literal
Definition The end date of a period of time.
Usage note

This property MUST be specified, if the start date is missing.

The range of this property is intentionally generic, with the purpose of allowing different level of temporal precision for specifying the end of a period. E.g., it can be expressed with a date (xsd:date), a date and time (xsd:dateTime), or a year (xsd:gYear).

Scope Data Documentation
Specification [[DCAT-AP]]

Class: Spatial coverage

Label Spatial coverage
RDF Class dct:Location
Definition The spatial coverage of a dataset, specified either by using a geographical name or a geometry.
Scope Data Documentation
Specification [[DCAT-AP]]

The spatial coverage is specified as defined in [[DCAT-AP]], namely, either by using a geographical name or with a geometry.

These two options are mutually exclusive, namely: if spatial coversage is specified as a geographical name, it MUST NOT be specified also as a geometry - and vice versa.

Spatial coverage as geographical name

When the spatial coverage is specified as geographical name, property dct:spatial MUST take as direct value the URI of one of the geographical areas defined in [[MDR-CONT]], [[MDR-COUNTRIES]], and/or [[UNSD-M49]] (see ), whereas class dct:Location SHOULD be omitted.

Spatial coverage as geometry

The following table lists the properties used for describing a spatial coverage as geometry.

Label Obl. RDF Property Range Scope Spec
geometry C locn:geometry gsp:asWKT, gsp:asGML DD [[DCAT-AP]]

Property: geometry

Label geometry
Obligation Conditional
Max card. N
RDF Property locn:geometry
Range gsp:asWKT, gsp:asGML
Definition The geometry of the spatial coverage.
Usage note The geometry MUST be specified as a literal, by using either the WKT or [[?GML]] encoding, as per the [[!GeoSPARQL]] specification.
Scope Data Documentation
Specification [[DCAT-AP]]

Reference code lists

The following table lists the reference code lists used in DCAT-AP-JRC, along with the metadata specification(s) where their use is defined.

Specification Metadata elements Code list URI Code lists
[[StatDCAT-AP]] Distribution type http://publications.europa.eu/resource/authority/distribution-type [[MDR-DT]]
[[DCAT-AP]] Format http://publications.europa.eu/resource/authority/file-type [[MDR-FT]]
[[DCAT-AP]] Geographical names http://publications.europa.eu/resource/authority/continent [[MDR-CONT]]
http://publications.europa.eu/resource/authority/country [[MDR-COUNTRIES]]
DCAT-AP-JRC https://unstats.un.org/unsd/methodology/m49/ See
[[DCAT-AP]] Language http://publications.europa.eu/resource/authority/language [[MDR-LANG]]
[[DCAT-AP]] Update frequency http://publications.europa.eu/resource/authority/frequency [[MDR-FREQ]]
[[DCAT-AP]] MDR Data themes http://publications.europa.eu/resource/authority/theme [[MDR-THEMES]]
[[DCAT-AP]] Publisher http://publications.europa.eu/resource/authority/corporate-body [[MDR-CB]]
DCAT-AP-JRC Dataset status http://publications.europa.eu/resource/authority/dataset-status [[MDR-DS]]
DCAT-AP-JRC Access restrictions http://data.jrc.ec.europa.eu/access-rights See
DCAT-AP-JRC Service protocols http://data.jrc.ec.europa.eu/service-protocol See

The following sections illustrate the ad hoc code lists used in DCAT-AP-JRC.

Identifier schemes

In order to use a reference register of identifier scheme agencies to denote the identifier "type" (see and ), an ad hoc code list has been created, based on the identifier schemes supported in [[?DataCite]] (and, in turn, used in [[?CiteDCAT-AP]]), plus additional ones.

The following table lists the names and URIs used for the scheme agencies of each of the supported identifiers.

Identifier scheme / type Scheme agency URI
ARK http://n2t.net/e/ark_ids.html
arXiv http://arxiv.org/
bibcode http://adsabs.harvard.edu/abs/
CORDIS https://cordis.europa.eu/
CrossRef Funder ID https://www.crossref.org/services/funder-registry/
DOI https://doi.org/
GRID https://www.grid.ac/
e-ISSN http://issn.org/
EAN13 https://www.gs1.org/
ELI https://eur-lex.europa.eu/eli-register/about.html
Handle http://handle.net/
Identifiers.org https://identifiers.org/
IGSN http://www.igsn.org/
ISBN http://www.isbn.org/
ISNI http://www.isni.org/
ISSN http://issn.org/
ISSN-L http://issn.org/
ISTC http://www.istc-international.org/
LEI https://www.gleif.org/
LSID http://www.lsid.info/
ORCID https://orcid.org/
PMID http://www.ncbi.nlm.nih.gov/pubmed/
PURL http://purl.org/
ROR https://ror.org/
UPC https://www.gs1.org/
URL
URN
w3id https://w3id.org/
Wikidata https://www.wikidata.org/

Access restrictions

As explained in , DCAT-AP-JRC makes use of a code list to specify access restrictions.

In the following table, the URIs of code list values are abbreviated for space constraints, specifying only the local part. For all of them, the base URI is http://data.jrc.ec.europa.eu/acces-rights/

URI (abbr.) Label Description
no-limitations No limitations Anybody can directly and anonymously access the data, without being required to register or authenticate.
registration-required Registration required Anybody can access the data, but they have to register first.
authorisation-required Authorisation required Only some users can access the resource.
unknown Unknown Access restrictions are unknown.

The SKOS representation of the access restrictions code list is included below. The corresponding file is maintained in the DCAT-AP-JRC GitHub repository.

Metadata schemas

In order to use a reference register of metadata schemas (see ), an ad hoc SKOS code list has been created. Such code list is currently limited only to the subset of metadata schemas relevant for the JRC Data Catalogue.

URI Specification
http://data.europa.eu/930/ [[?GeoDCAT-AP]]
http://data.europa.eu/r5r/ [[?DCAT-AP]]
http://data.europa.eu/s1n/ [[?StatDCAT-AP]]
http://datacite.org/schema/ [[?DataCite]]
http://www.isotc211.org/2005/gmd [[?ISO-19115]]
http://www.w3.org/ns/dcat# [[?VOCAB-DCAT]]
https://sdmx.org/ [[?SDMX]]

The SKOS representation of the metadata schema code list is included below. The corresponding file is maintained in the DCAT-AP-JRC GitHub repository.

Service protocols

In order to use a reference register of service protocols (see ), an ad hoc SKOS code list has been created, based on the relevant subset of the lookup table maintained in [[?LINK-PROP]], plus additional ones.

The SKOS representation of the service protocol code list is included below. The corresponding file is maintained in the DCAT-AP-JRC GitHub repository.

UNSD M49

As explained in , DCAT-AP-JRC makes use of a code list based on the UNSD Standard country or area codes for statistical use (M49) [[UNSD-M49]]] for specifying spatial coverage ().

The UNSD M49 code list provides a SKOS representation of [[UNSD-M49]], integrated with the [[MDR-CONT]] and [[MDR-COUNTRIES]] code lists. More precisely, it defines terms in [[UNSD-M49]] not included in [[MDR-CONT]] and [[MDR-COUNTRIES]], and specifies containment relationships between the geographical areas defined in these code lists by using the dct:hasPart / dct:isPartOf properties.

The following table lists the subset of the [[UNSD-M49]] entries used in DCAT-AP-JRC - i.e., all the [[UNSD-M49]] entries, with the exclusion of those corresponding to continents and countries.

The SKOS representation of the [[UNSD-M49]] code list is included below. The corresponding file is maintained in the DCAT-AP-JRC GitHub repository.

Identifiers as URIs

Following the approach defined in [[?CiteDCAT-AP]] (§ 10 Identifiers), in DCAT-AP-JRC, all identifiers are mapped to URIs, by concatenating the identifier with a URI prefix defined for each identifier type / scheme. Whenever possible, dereferenceable HTTP URIs/URLs are used; otherwise, URNs.

The mapping between the identifier type / scheme implemented in DCAT-AP-JRC is based on the relevant registries. No URI prefix is of course used if the identifier is already a URI (as URLs and URNs).

The following table shows, for each identifier type / scheme, which is the URI prefix used in DCAT-AP-JRC, along with examples of the results of such mappings.

Identifier type / scheme URI prefix used in DCAT-AP-JRC Example Comments
Original Transformed
ARK http://n2t.net/ ark:/67531/metapth346793/ http://n2t.net/ark:/67531/metapth346793/
arXiv http://arxiv.org/abs/ arXiv:0706.0001 http://arxiv.org/abs/0706.0001 The URI prefix replaces the namespace prefix arXiv: in the original identifier
bibcode http://adsabs.harvard.edu/abs/ 2014Wthr...69...72C http://adsabs.harvard.edu/abs/2014Wthr...69...72C
CORDIS https://cordis.europa.eu/project/rcn/ 106337 https://cordis.europa.eu/project/rcn/106337
CrossRef Funder ID https://doi.org/ 10.13039/501100000900 https://doi.org/10.13039/501100000900
DOI https://doi.org/ 10.1016/j.epsl.2011.11.037 https://doi.org/10.1016/j.epsl.2011.11.037
e-ISSN http://issn.org/resource/ISSN/ 1562-6865 http://issn.org/resource/ISSN/1562-6865
EAN13 urn:ean-13: 9783468111242 urn:ean-13:9783468111242
ELI http://data.europa.eu/eli/dir/2013/37/oj http://data.europa.eu/eli/dir/2013/37/oj ELIs are URIs - no need for a URI prefix.
GRID https://www.grid.ac/institutes/ grid.270680.b https://www.grid.ac/institutes/grid.270680.b
Handle http://hdl.handle.net/ 10013/epic.10033 http://hdl.handle.net/10013/epic.10033
Identifiers.org https://www.ebi.ac.uk/miriam/main/datatypes/ MIR:00000644 https://www.ebi.ac.uk/miriam/main/datatypes/MIR:00000644
IGSN http://hdl.handle.net/10273/ (https://doi.org/10273/) SSH000SUA http://hdl.handle.net/10273/SSH000SUA (https://doi.org/10273/SSH000SUA)
ISNI http://www.isni.org/ 0000000121032683 http://www.isni.org/0000000121032683
ISBN urn:isbn: 978-3-905673-82-1 urn:isbn:978-3-905673-82-1
ISSN http://issn.org/resource/ISSN/ 0077-5606 http://issn.org/resource/ISSN/0077-5606
ISSN-L http://issn.org/resource/ISSN-L/ 1188-1534 http://issn.org/resource/ISSN-L/1188-1534
ISTC http://istc-search-beta.peppertag.com/ptproc/IstcSearch?tFrame=IstcListing&esfIstc= A12-2014-00013328-5 http://istc-search-beta.peppertag.com/ptproc/IstcSearch?tFrame=IstcListing&tForceNewQuery=Yes&esfIstc=A12-2014-00013328-5
LEI https://search.gleif.org/#/record/ 254900ZNYA1FLUQ9U393 https://search.gleif.org/#/record/254900ZNYA1FLUQ9U393
LSID urn:lsid:ubio.org:namebank:11815 urn:lsid:ubio.org:namebank:11815

LSIDs are implemented as URNs, following the pattern urn:lsid:authority:namespace:identifier:revision

URNs are URIs - no need for a URI prefix.

ORCID https://orcid.org/ 0000-0002-7285-027X https://orcid.org/0000-0002-7285-027X
PMID http://www.ncbi.nlm.nih.gov/pubmed/ 12082125 http://www.ncbi.nlm.nih.gov/pubmed/12082125
PURL http://purl.org/dc/terms/ http://purl.org/dc/terms/ PURLs are HTTP URIs - no need for a URI prefix.
ROR https://ror.org/ 04j5wtv36 https://ror.org/04j5wtv36
UPC urn:upc: 123456789999 urn:upc:123456789999
URL http://www.heatflow.und.edu/index2.html http://www.heatflow.und.edu/index2.html URLs are URIs - no need for a URI prefix.
URN urn:nbn:de:101:1-201102033592 urn:nbn:de:101:1-201102033592 URNs are URIs - no need for a URI prefix.
w3id https://w3id.org/ https://w3id.org/ w3id's are HTTP URIs - no need for a URI prefix.
Wikidata https://www.wikidata.org/wiki/ Q1500915 https://www.wikidata.org/wiki/Q1500915

Schema.org mapping

As explained in , DCAT-AP-JRC is complemented with mapping rules for generating a [[?SCHEMA-ORG]] representation of metadata records, to be used for optimising the indexing of dataset pages.

These mappings are based on those defined in [[?DCAT-AP-SDO]], partially revised to meet the Google guidelines for the description of datasets. These guidelines are also used to choose the subset of DCAT-AP-JRC metadata to be mapped. The motivation for not using a full mapping of DCAT-AP-JRC records is that only a subset of [[?SCHEMA-ORG]] is used for indexing purposes by search engines. Consequently, the defined mappings cover only those classes and properties specified in the guidelines for creating records for the Google Dataset Search service. For the same reason, the mapping is limited to dataset metadata records - which are currently the only type of resources indexed in Google Dataset Search.

The following sections illustrate the defined mapping rules for the selected DCAT-AP-JRC classes and properties. Moreover, shows an example of a [[?SCHEMA-ORG]] representation of a DCAT-AP-JRC record, obtained by applying the defined mapping rules.

Mapped classes

Class DCAT-AP-JRC Schema.org
Catalogue dcat:Catalog schema:DataCatalog
Dataset dcat:Dataset schema:Dataset
Identifier adms:Identifier schema:PropertyValue
schema:Text
Individual foaf:Person schema:Person
Organisation foaf:Organization schema:Organization
Spatial coverage dct:Location schema:Place
Temporal coverage dct:PeriodOfTime schema:DateTime
schema:Text
Distribution dcat:Distribution schema:DataDownload
Publication foaf:Document schema:Article

Mapped properties

Catalogue

Property DCAT-AP-JRC Schema.org Range
title dct:title schema:name schema:Text
landing page foaf:homepage schema:url schema:URL

Dataset

Property DCAT-AP-JRC Schema.org Range
title dct:title schema:name schema:Text
description dct:description schema:description schema:Text
publication date dct:issued schema:datePublished schema:Date
contributor dct:creator schema:creator Individual
Organisation
publisher dct:publisher schema:publisher Organisation
other identifier (as literal) adms:identifier schema:identifier Identifier
theme dcat:theme schema:keywords schema:Text
keyword dcat:keyword
temporal coverage dct:temporal schema:temporalCoverage Temporal coverage
spatial coverage dct:spatial schema:spatialCoverage Spatial coverage
distribution dcat:distribution schema:distribution Distribution
publication dct:isReferencedBy schema:citation Publication
catalogue dct:isPartOf schema:includedInDataCatalog Catalogue
data policy dct:conformsTo schema:publishingPrinciples schema:URL

Additional mapping rules:

  • The dataset URI is used as value of properties schema:url and schema:sameAs.
  • Property dcat:theme is mapped to schema:keywords, although the latter is meant to be used for free text keywords (as property dcat:keyword in [[VOCAB-DCAT]]). The reason is that [[?SCHEMA-ORG]] does not currently support a way to specify terms from controlled vocabularies, code lists, thesauri, and taxonomies. For more details on this issue, see § 4.1 Categories and category schemes in [[?DCAT-AP-SDO]].
  • In DCAT-AP-JRC, dcat:theme takes as value only the URI of the relevant concept. However, since schema:keywords is instead meant to specify textual labels, the mapping rules take this information from the controlled vocabulary used for dcat:theme (namely, [[MDR-THEMES]]).
  • Differently from dcat:theme and dcat:keyword, which take as value a single keyword / concept, property schema:keywords specifies a list of keywords, using a given character as a delimiter (a comma or a semi-colon). Consequently, the mapping rules join the values of possibly multiple instances of dcat:theme and dcat:keyword to generate the string to be used as value of schema:keywords.

Identifier

Identifiers are mapped differently depending of their type. More precisely:

  1. As schema:Text in case of DOIs and ORCIDs, by using the value specified by property skos:notation of class adms:Identifier. This approach follows the guidelines for the Google Dataset Search service.
  2. As schema:PropertyValue in all the other cases.

In the latter case, the relevant DCAT-AP-JRC properties are mapped as follows:

Property DCAT-AP-JRC Schema.org Range
notation skos:notation schema:value schema:Text
scheme agency name adms:schemeAgency schema:propertyID schema:Text

Individual

Property DCAT-AP-JRC Schema.org Range
given name foaf:givenName schema:givenName schema:Text
family name foaf:familyName schema:familyName schema:Text
formatted name foaf:name schema:name schema:Text
other identifier (as URI) owl:sameAs schema:sameAs schema:URL
schema:url
other identifier (as literal) adms:identifier schema:identifier Identifier

Organisation

Property DCAT-AP-JRC Schema.org Range
name foaf:name schema:name schema:Text
home page foaf:homepage schema:url schema:URL

Spatial coverage

The mapping described in the following table are mutually exclusive, and their use depends on whether the spatial coverage is specified as a geographical name or as a geometry.

In the former case, the actual geographical name is taken from the reference code list used, as DCAT-AP-JRC uses only the corresponding URI (see ).

When instead a geometry is used, the mapping rule requires an additional transformation of the geometry encoding from the one used in DCAT-AP-JRC to the one used in [[?SCHEMA-ORG]]. For this specific issue, we refer the reader to § 4.7 Geometries of [[?DCAT-AP-SDO]].

Property DCAT-AP-JRC Schema.org Range
name skos:prefLabel schema:name schema:Text
geometry locn:geometry schema:geo schema:GeoShape

Temporal coverage

Temporal coverage is mapped to the literal value used by property schema:temporalCoverage, namely (quoting) "a textual string indicating a time period in ISO 8601 time interval format", following the syntax YYYY-MM-DD/YYYY-MM-DD [[?ISO-8061]]. The dates before and after the slash (/) are taken from the properties used in DCAT-AP-JRC to specify the start and the end of the interval, respectively.

Distribution

Property DCAT-AP-JRC Schema.org Range
title dct:title schema:name schema:Text
format dct:format schema:fileFormat schema:Text
access URL dcat:accessURL schema:contentUrl schema:URL
download URL dcat:downloadURL

Additional mapping rules:

  • In DCAT-AP-JRC, dct:format takes as value only the URI of the relevant file format / media type. However, since schema:fileFormat is instead meant to specify this information as a textual label, the mapping rules take this information from the controlled vocabulary used for dct:format (namely, [[MDR-FT]]).

Publication

Property DCAT-AP-JRC Schema.org Range
title dct:title schema:name schema:Text
other identifier (as URI) owl:sameAs schema:url schema:URL
other identifier (as literal) adms:identifier schema:identifier Identifier
bibliographic citation dct:bibliographicCitation schema:description schema:Text

Example

The following [[?JSON-LD]] snippet corresponds to the dataset in .

Use cases and requirements contributed to the W3C DXWG

Some of the use cases and requirements behind the development of DCAT-AP-JRC have been contributed to the W3C Dataset Exchange Working Group (DXWG), who is in charge of the revision of [[?VOCAB-DCAT]].

These contributions have been included in the DXWG's Dataset Exchange Use Cases and Requirements [[?DCAT-UCR]], and are listed below:

DXWG Use Cases DCAT-AP-JRC requirements
§ 5.9 Common requirements for scientific data
§ 5.10 Requirements for data citation
§ 5.11 Modeling identifiers and making them actionable
§ 5.12 Modeling data lineage
§ 5.13 Modeling agent roles , ,
§ 5.17 Data access restrictions
§ 5.18 Modeling service-based data access
§ 5.20 Modeling resources different from datasets