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

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 [[EUV-CONT]] (continents) and [[EUV-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 [[EUV-CONT]] and [[EUV-COUNTRIES]] - as global and sub-continental areas.

For this reason, DCAT-AP-JRC includes support for [[UNSD-M49]] to complement [[EUV-CONT]] and [[EUV-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 [[EUV-CONT]] and [[EUV-COUNTRIES]] code lists. More precisely, this integrated code list makes use of [[EUV-CONT]] and [[EUV-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 [[?EUV-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 [[EUV-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 [[EUV-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 [[EUV-DT]] code list, and by specifying the service / API type via a URI identifying it (see ).

In addition, following [[DCAT-AP]], the service / API is described by a specific class (see ), and the distribution is linked to it.

Another 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 [[EUV-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 .