mobilityDCAT-AP - Version 1.0.1

A mobility extension for the DCAT application profile for data portals in Europe

NAPCORE

This version:
https://w3id.org/mobilitydcat-ap/releases/1.0.1/
Latest published version:
https://w3id.org/mobilitydcat-ap/releases/
Latest editor's draft:
https://w3id.org/mobilitydcat-ap/drafts/latest/
Previous version:
https://w3id.org/mobilitydcat-ap/drafts/1.0.0-draft-0.1/
Latest Recommendation:
https://w3id.org/mobilitydcat-ap/releases/1.0.1/
Editors:
Lina Molinas Comet (Fraunhofer Institute for Applied Information Technology FIT)
Peter Lubrich (Federal Highway Research Institute (BASt))
Mario Scrocca (Cefriel)
Author:
NAPCORE Sub-Working Group (SWG) 4.4 (NAPCORE (National Access Point Coordination Organisation for Europe) Organization)
Participate:
GitHub mobilityDCAT-AP/mobilityDCAT-AP
File a bug
Commit history
Pull requests
Document status:
Completed
Document version:
1.0.1
Reviewed by:
NAPCORE SWG 4.4
European NAP operators
Editors of DCAT-AP/SEMIC Team
Approved by:
NAPCORE SWG 4.4

Please check the errata for any errors or issues reported since publication.

This document is also available in these non-normative formats: RDF/XML, Turtle, JSON-LD, and SHACL (Turtle)


Abstract

mobilityDCAT-AP is a mobility-related extension of the DCAT application profile for data portals in Europe (DCAT-AP) [DCAT-AP]. It allows for a structured, interoperable and harmonised way to describe and exchange metadata about datasets and data services with a mobility relevance.

This document is a product of sub-working group 4.4 of the NAPCORE project [NAPCORE] consortium.

Comments and queries should be sent via the issue tracker of the dedicated GitHub repository.

Disclaimer

The views expressed in this document are purely those of the Author(s) and may not, in any circumstances, be interpreted as stating an official position of the European Commission.

The NAPCORE consortium does not guarantee the accuracy of the information included in this study, nor does it accept any responsibility for any use thereof.

Reference herein to any specific products, specifications, process, or service by trade name, trademark, manufacturer, or otherwise does not necessarily constitute or imply its endorsement, recommendation, or favouring by the NAPCORE consortium.

All care has been taken by the author to ensure that s/he has obtained, where necessary, permission to use any parts of manuscripts, including illustrations, maps, and graphs, on which intellectual property rights already exist from the titular holder(s) of such rights or from her/his or their legal representative.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document.

This document was published by the NAPCORE Sub-Working Group (SWG) 4.4 as a recommendation.

GitHub Issues are preferred for discussion of this specification. This document is governed by the Change and Release Management Policy for DCAT-AP.

Publication as a Recommendation has received the endorsement of the Working Group.

The Working Group recommends the wide deployment of this specification.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document is governed by the Change and Release Management Policy for DCAT-AP.

Document History

Version Date Description Action Change Log
1.0.1 13/03/2024 Minor revision Publication § F.1 Changes since first publication of 16 October 2023
1.0.0 16/10/2023 Recommendation Publication § F.2 Starting point of mobilityDCAT-AP 1.0.0 (01 January 2023)
0.1 11/05/2023 First Public Working Draft Creation N/A

Issue Summary

There are no issues listed in this specification.

1. Introduction

This section is non-normative.

This document presents version 1.0.1 of the specification for mobilityDCAT-AP, a mobility-related extension of the DCAT application profile for data portals in Europe (DCAT-AP) [DCAT-AP]. mobilityDCAT-AP aims to provide a structured, interoperable and harmonised approach to describing and exchanging metadata about datasets and about access for such datasets related to mobility, and in particular related to Intelligent Transport Systems (ITS). Its primary goal is to enhance the cross-border and cross-sectorial discoverability of ITS- and mobility-related datasets published on relevant data portals.

For this purpose, mobilityDCAT-AP introduces an RDF vocabulary and the corresponding RDF syntax, building upon the foundations of the original [DCAT-AP], while extending and customizing it for the mobility sector.

1.1 Context

Digitalisation in the mobility domain often implies that various data assets from various actors in the mobility system are made discoverable and accessible. Accordingly, internet portals for mobility data have been developed all over the world in recent years. These portals often have specific spatial or thematic coverage, e.g., exposing public-transport timetable data for one specific region. In addition, legal obligations, such as those established through the European Union's National Access Points (NAPs) [NAPCORE-NAPs], mandate the creation and population of such portals.

Metadata is a crucial building block for the accessibility and reusability of datasets within NAPs and other mobility data portals. However, unlike other domains like bibliography, there is currently no established common metadata approach across different mobility data portals. A common metadata approach can act as an important infrastructure and reference basis for providing harmonious and homogenous ITS- and mobility-related data descriptions across Europe, thus accelerating the easiness of searching, discovering, and accessing the proper data resources through the operated relevant data portals.

To serve this need, a dedicated Working Group within the EU-funded project NAPCORE [NAPCORE-Metadata-Working-Group] has been tasked with defining and maintaining a common metadata schema for all NAPs in Europe and other mobility data portals. Starting from the analysis of the European recommendations for the interoperability of data catalogues, the Working Group has defined a roadmap for the design, implementation and publication of the metadata schema.

The roadmap is explained in detail at [NAPCORE-Metadata-preparatory-activities]. It consists of five key steps: (1) gathering of requirements from experts and transport stakeholders, (2) definition of a conceptual model, (3) implementation of the conceptual model as a proper metadata scheme, (4) documentation of the scheme and provision of guidelines, and (5) hosting and publication of all outputs. The conceptual model contains definitions of essential metadata elements for mobility data portals. Further, this model is linked to established metadata specifications, particularly DCAT-AP. Moreover, the conceptual model serves as the foundation for a formal metadata specification as an extension to DCAT-AP, called mobilityDCAT-AP.

mobilityDCAT-AP enables harmonised, platform-independent metadata descriptions both in human-readable and machine-readable formats. The latter one ensures seamless integration of mobility-related platforms with third party systems by enabling the automated import and export of metadata via, for example, an API. As a specification based on the Resource Description Framework (RDF) schema, mobilityDCAT-AP leverages semantic technologies, enabling advanced querying and inference capabilities based on metadata. Following its release in the summer of 2023, this specification is being promoted for wide-scale usage in mobility data portals. To ensure its acceptance and sustainability, formal maintenance and governance structures have been established. Additionally, the development of a cross-border metadata registry will be demonstrated that will make use of mobilityDCAT-AP and provide for it a proof of concept.

mobilityDCAT-AP provides precise and unambiguous metadata designations for any data offering with mobility relevance, e.g. for representing the data topic, the data provider or the data format. It is highly recommended that the metadata management of National Access Points (NAPs) in Europe, or any other mobility data portals, is based on mobilityDCAT-AP in order to harmonise their data descriptions and ease the exchange of metadata in the mobility data ecosystem. Furthermore, this will ensure the basis for extended interoperability, among others, with other NAPs or data portals.

This work has been carried out in the context of sub-working group 4.4 of the [NAPCORE] project. NAPCORE is an EU-cofunded Programme Support Action under the GRANT AGREEMENT No MOVE/B4/SUB/2020-123/SI2.852232. This Programme Support Action aims at supporting the implementation of Delegated Regulations under Directive 2010/40/EU [EC-ITS-Directive], focusing on making infrastructure, safety, traffic, and travel data accurate and accessible to various user types, such as transport authorities or service providers through NAPs. It will stimulate and promote the coordinated provision of Intelligent Transport Systems (ITS) data through NAPs, thereby enhancing the quality of services that are based on this data.

1.2 Scope of this version: Preparatory Activities and Initial Release

This document aims to present the initial release of mobilityDCAT-AP, building upon preceding preparatory activities that include requirement analysis, a roadmap development and conceptual modeling. For detailed information about these preparatory activities, please refer to the relevant documentation at [NAPCORE-Metadata-preparatory-activities].

As [DCAT-AP], the Application Profile specified in this document is based on the specification of the Data Catalog Vocabulary (DCAT), originally developed under the responsibility of the Government Linked Data Working Group [GLD] at W3C, and significantly revised in 2020 by the W3C Dataset Exchange Working Group [DXWG]. DCAT is an RDF [RDF11-CONCEPTS] vocabulary designed to facilitate interoperability between data catalogues published on the Web. mobilityDCAT-AP incorporates additional classes and properties from other well-known vocabularies are re-used, where necessary.

This document, beyond what is defined in Conformance Statement, does not cover implementation issues such as data exchange mechanisms and the expected behavior of systems implementing mobilityDCAT-AP.

The Application Profile purpose is to facilitate data exchange. Therefore, the classes and properties defined in this document are only relevant for the data to be exchanged. There are no specific requirements for the systems involved in the data exchange process to implement particular technical environments, as long as they can export and import metadata in RDF, in conformance with mobilityDCAT-AP.

1.3 A DCAT-AP extension: Enhancing DCAT-AP for Mobility

mobilityDCAT-AP designed as an extension of DCAT-AP in conformance with the guidelines for the creating of DCAT-AP extensions [DCAT-AP-EG]. The DCAT-AP Application Profile, upon which this document is based, is version 2.0.1. of 8 June, 2020 [DCAT-AP-v2.0.1]. According to the same principles, DCAT-AP is in itself an extension of DCAT.

It is important to consider this dependency on the DCAT-AP specifications when reading and implementing mobilityDCAT-AP. The corresponding specifications should be consulted to address any gaps or missing information in this document.

Comparing mobilityDCAT-AP to [DCAT-AP-v2.0.1], the following editions have been made:

The class and property additions aim to capture some specific characteristics and features of mobility data, when exposed on NAPs and mobility data portals.

Some of these class and property additions align with the parallel DCAT-AP extension [GEODCAT-AP-v2.0.0], enabling compatibility between the two extensions in terms of class and property additions.

All classes and property additions are marked with a prepended “plus” sign (+) in this document, and summarised in the reference table in § A.2 Classes and properties added by mobilityDCAT-AP.

The removal of optional or recommended properties from DCAT-AP aims to minimise the vocabulary size of mobilityDCAT-AP, avoiding any misinterpretations and multiple usage of properties among data senders.

Properties removed from [[DCAT-AP-v2.0.1] are marked with a prepended “minus” sign (-).

2. Terminology used in the Application Profile

Part of the following text has been reused and adapted from [DCAT-AP-v2.0.1].

An Application Profile is a specification that re-uses terms from one or more base standards, adding more specificity by identifying mandatory, recommended and optional elements to be used for a particular application, as well as recommendations for controlled vocabularies to be used.

A Dataset is a collection of data published or curated by a single source and available for access or download in one or more formats. In the mobility context, this might be, e.g., a data collection about static parking information for truck drivers published by a road authority.

A Data Portal is a Web-based system that contains a data catalogue with descriptions of datasets and provides services enabling the discovery and re-use of the datasets.

In the context of mobility, this might be a National Access Point addressing the EC ITS Directive [NAPCORE-NAPs]. Accordingly, a NAP aims to "...facilitate access, easy exchange and reuse of transport-related data, in order to help support the provision of EU-wide interoperable travel and traffic services to end users." It is realised as "...a database, data warehouse, data marketplace, repository, and register, web portal or similar...".

In the context of NAPs, the terms "Metadata registry", "Metadata entry", and "Publication" are often used, which are explained in the following.

A Metadata registry is a digital recording of all metadata entries in a data portal, each describing the administration, organisation, and content of individual publications, including the published datasets and the corresponding distributions. The most visible Metadata representation is the dataset descriptions in a GUI of a NAP portal.

A Metadata entry (sometimes called metadata record or metadata set) describes the administration, organisation, and content of an individual publication, including the published dataset and the corresponding distributions.

A Publication is an abstract construct that covers a dataset published by a data publisher and which has one or multiple distributions.

mobilityDCAT-AP (as well as DCAT-AP) is expressed as an RDF schema [RDF-SCHEMA]]. An RDF schema provides a data-modelling vocabulary for RDF data. It provides mechanisms for describing groups of related resources and their relationships. This is done via a class and property system.

A Class is a group of resources. Classes are themselves resources. They are often identified by IRIs and may be described using properties.

A Property is a relation between subject resources and object resources.

The following figure shows the core elements of the DCAT-AP data model, denoting how the above-mentioned terms and relations are expressed as classes and properties. This figure also shows how NAP-related terms, such as publications, are related to this class and property structure.

In the following sections, classes and properties are grouped under headings ‘mandatory’, ‘recommended’ and ‘optional’. These terms have the following meaning, relating to the potential responsibilities of metadata senders and metadata receivers.

Such metadata senders and receivers are important actors for interoperable metadata, i.e., whenever metadata is exchanged between IT systems. This is the case when a data portal has metadata import and export functions. In this case, metadata senders and receivers are individual data portals. So, the following terms refer to the capability of a data portal to provide corresponding metadata in an export function or to read them in an import function.

The meaning of the terms MUST, MUST NOT, SHOULD and MAY in this section and in the following sections are as defined in [RFC2119].

In the given context, the term "processing" means that receivers must accept incoming data and transparently provide these data to applications and services. It does neither imply nor prescribe what applications and services finally do with the data (parse, convert, store, make searchable, display to users, etc.).

Classes are classified as ‘Mandatory’ in § 3.1 Mandatory Classes if they appear as the range of one of the mandatory properties in § 4. Application Profile Properties per Class.

All other classes are classified as ‘Optional’ in § 3.3 Optional Classes. A further description of the optional classes is only included as a sub-section in § 4. Application Profile Properties per Class if the Application Profile specifies mandatory or recommended properties for them.

2.1 Namespaces

The namespace for mobilityDCAT-AP is: https://w3id.org/mobilitydcat-ap

The suggested namespace prefix is: mobilitydcatap

The Application Profile reuses terms from various existing specifications, following established best practices [DWBP]. The following table indicates the full list of corresponding namespaces used in this document.

Prefix Namespace URI Specification
adms http://www.w3.org/ns/adms# [VOCAB-ADMS]
cnt http://www.w3.org/2011/content# [CNT]
dcat http://www.w3.org/ns/dcat# [VOCAB-DCAT-2]
dcatap http://data.europa.eu/r5r/ [DCAT-AP]
dct http://purl.org/dc/terms/ [DCTERMS]
dqv http://www.w3.org/ns/dqv# [VOCAB-DQV]
foaf http://xmlns.com/foaf/0.1/ [FOAF]
locn http://www.w3.org/ns/locn# [CORE-LOCATION-VOCABULARY]
oa https://www.w3.org/ns/oa# [WEB-ANOTATION-ONTOLOGY]
org www.w3.org/ns/org# [CORE-ORGANIZATION-ONTOLOGY]
owl http://www.w3.org/2002/07/owl# [OWL-REF]
rdf http://www.w3.org/1999/02/22-rdf-syntax-ns# [RDF11-CONCEPTS]
rdfs http://www.w3.org/2000/01/rdf-schema# [RDF-SCHEMA]
skos http://www.w3.org/2004/02/skos/core# [SKOS-REFERENCE]
spdx http://spdx.org/rdf/terms# [SPDX]
vcard http://www.w3.org/2006/vcard/ns# [VCARD-RDF]
xsd http://www.w3.org/2001/XMLSchema# [XMLSCHEMA11-2]

2.2 mobilityDCAT-AP Overview

mobilityDCAT-AP extends [DCAT-AP-v2.0.1] by including:

These extensions are meant to provide a DCAT-AP-conformant representation of metadata specific to mobility data.

For a first orientation in mobilityDCAT-AP, these four central classes should be considered: dcat:Catalogue, dcat:CatalogRecord, dcat:Dataset and dcat:Distribution; as well as the properties connecting these four classes.

Figure 1 shows an excerpt of the UML diagram of the mobilityDCAT-AP model, showing these four central classes and their connecting properties.

Excerpt of mobilityDCAT-AP UML Class Diagram with central classes
Figure 1 Excerpt of mobilityDCAT-AP UML Class Diagram with focus on central classes

These four central classes represent a hierarchical concept when describing metadata via mobilityDCAT-AP. Firstly, the Catalogue as such is described, i.e., being the metadata register in a data portal. Secondly, there is the Catalogue Record, which describes the metadata entry, including its publication date. Thirdly, the Dataset is described. In fact, most metadata elements are covered here, including the content theme; the spatial and temporal context; quality information and others. Finally, the distribution describes a technical and organisational way to access the Dataset. In addition to the data format (e.g., a machine-readable syntax standard), the licensing terms are described here.

Please note that two of the connecting properties, dcat:record and dcat:distribution, have a mandatory obligation, in contrast to [DCAT-AP-v2.0.1]. Thus, a complete metadata set in accordance with mobilityDCAT-AP SHOULD contain at least one instance of these four classes. See also the usage notes for properties dcat:record and dcat:distribution.

Figure 2 shows a more complex UML diagram with selected classes and properties included in mobilityDCAT-AP.

It shows the four central classes (marked in orange), as explained above, as well as some supportive classes (marked in yellow).

In this diagram, the focus is on classes and properties which have been added in mobilityDCAT-AP in comparison to [DCAT-AP-v2.0.1]. All additions are marked with a prepended “plus” sign (+), and summarised in the reference table in § A.2 Classes and properties added by mobilityDCAT-AP.

mobilityDCAT-AP UML Class Diagram
Figure 2 Excerpt of mobilityDCAT-AP UML Class Diagram with focus on added classes and properties

Figure 3 shows a reduced UML diagram with classes and properties that are declared mandatory in mobilityDCAT-AP.

mobilityDCAT-AP UML Minimum Class Diagram
Figure 3 Excerpt of mobilityDCAT-AP UML Class Diagram with focus on mandatory classes and properties

A complete UML diagram with all elements is not shown here, but can be reconstructed from the UML diagram on [DCAT-AP-v2.0.1].

3. Application Profile Classes

3.1 Mandatory Classes

Note

Class name

Usage note for the Application Profile

URI

Reference

Agent

An entity (e.g., an individual or an organisation) that is associated with Catalogues, Catalogue Records, or Datasets. If the Agent is an organisation, the use of the Organization Ontology [VOCAB-ORG] is recommended. See § 7. Agent Types, Agent Roles and Contact Information for a discussion on Agent types, roles and properties.

foaf:Agent

§ Class: foaf:Agent [FOAF]

[VOCAB-ORG]

Catalogue

A concrete mobility data portal, i.e, a web portal, where mobility-related datasets and their distributions are described via metadata and discoverable for data users.

dcat:Catalog

§ 6.3 Class: Catalog [VOCAB-DCAT-2]

Catalogue Record

A description of a metadata entry in the mobility data portal, referring to one dataset and its distributions published on the portal. mobilityDCAT-AP assumes that metadata records are essential in mobility data portals, so the obligation of this class is raised to “mandatory”, comparing to [DCAT-AP-v2.0.1].

dcat:CatalogRecord

§ 6.5 Class: Catalog Record [VOCAB-DCAT-2]

Category

A category of a dataset, i.e. a specific subject, theme, or a class about its content. mobilityDCAT-AP recommends to use the Category as the primary descriptor of a Dataset's subject, so the obligation of this class is raised to “mandatory”, comparing to [DCAT-AP-v2.0.1].

skos:Concept

§ 6.10 Class: Concept [VOCAB-DCAT-2]

Dataset

A dataset is a collection of data, published or curated by a single source, and available for access or download at the mobility data portal in one or more distributions. In the context of mobility-related data exchange, this might be, e.g., a data collection about static parking information for truck drivers, published by a road authority.

dcat:Dataset

§ 6.6 Class: Dataset [VOCAB-DCAT-2]

Distribution

A distribution describes the data formats and communication methods for a dataset. There may be one or multiple distributions for one dataset. For example, the same dataset (e.g. static parking information for truck drivers) can be provided in different ways e.g. as downloadable zip file or as XML using a SOAP web service. These are two distributions based on one dataset.

in [DCAT-AP-v2.0.1], this class has been classified as ‘Recommended’, to allow for cases that a particular Dataset does not have a Distribution, i.e. . However, for the context of mobility data portals, it can be expected that all datasets have one or more Distributions. Thus, the obligation of class Distribution is raised to mandatory, comparing to [DCAT-AP-v2.0.1].

dcat:Distribution

§ 6.7 Class: Distribution [VOCAB-DCAT-2]

Location

A spatial region or named place. It can be represented using a controlled vocabulary or with geographic coordinates.

dct:Location

§ Term name: Location [DCTERMS]

Literal

A literal value such as a string or integer; Literals may be typed, e.g. as a date according to xsd:date. Literals that contain human-readable text have an optional language tag as defined by [BCP47].

rdfs:Literal

§ 3.3 Literals [RDF11-CONCEPTS]

+Mobility Data Standard

The mobility data standard applied for the delivered content. A mobility data standard, e.g., DATEX II, combines syntax and semantic definitions of entities in a certain domain (e.g., for DATEX II: road traffic information), and optionally adds technical rules for data exchange.

mobilitydcatap:MobilityDataStandard

Resource

Anything described by RDF.

rdfs:Resource

§ 2.1 rdfs:Resource [RDF-SCHEMA]

Rights statement

A statement about the intellectual property rights (IPR) held in or over a resource, a legal document giving official permission to do something with a resource, or a statement about access rights.

dct:RightsStatement

§ Term name: RightsStatement [DCTERMS]

3.3 Optional Classes

Note

Class name

Usage note for the Application Profile

URI

Reference

+Address (Agent)

A postal address of the Agent. This class addition is analogous to a class addition by [GEODCAT-AP-v2.0.0].

locn:Address

§ Class Address [LOCN]

+Assessment

An assessment procedure by an external organisation. This organisation MAY be a National Body in the context of EU Delegated Regulations. EU Delegated Regulations require Member States to set up procedures to assess the compliance of the Delegated Regulations, e.g. regarding the provisioning of data via a NAP. These assessment processes are handled by National Bodies [NAPCORE-NB] and installed individually in each Member State.

mobilitydcatap:Assessment

Checksum

A value that allows the contents of a file to be authenticated. This class allows the results of a variety of checksum and cryptographic message digest algorithms to be represented.

spdx:Checksum

§ checksum [SPDX]

Data Service

A collection of operations that provides access to one or more datasets or data processing functions.

dcat:DataService

§ 6.8 Class: Data Service [VOCAB-DCAT-2]

Document

A textual resource intended for human consumption that contains information, e.g., a Web page about a Dataset.

foaf:Document

§ Class: foaf:Document [FOAF]

Frequency

A rate at which something recurs, e.g., the publication of a Dataset.

dct:Frequency

§ Term name: Frequency [DCTERMS]

Identifier

An identifier in a particular context, consisting of the string that is the identifier; an optional identifier for the identifier scheme; an optional identifier for the version of the identifier scheme; an optional identifier for the agency that manages the identifier scheme

adms:Identifier

§ 5.2.6 Identifier [VOCAB-ADMS]

Kind

A description following the [VCARD-RDF] specification, e.g. to provide telephone number and e-mail address for a contact point. Note that the class vcard:Kind is the parent class for the four explicit types of vCards (vcard:Individual, vcard:Organization, vcard:Location, vcard:Group).

vcard:Kind

§ Kind [VCARD-RDF]

Linguistic system

A system of signs, symbols, sounds, gestures, or rules used in communication, e.g. a language.

dct:LinguisticSystem

§ Term name: LinguisticSystem [DCTERMS]]

Media type

A media type, e.g. the format of a computer file.

dct:MediaType

§ Term name: MediaType [DCTERMS]

Provenance Statement

A statement of any changes in ownership and custody of a resource since its creation that are significant for its authenticity, integrity, and interpretation

dct:ProvenanceStatement

§ Term name: ProvenanceStatement [DCTERMS]

Publisher type

A type of organisation that acts as a publisher

skos:Concept

§ 5.3.41 dcterms:type [VOCAB-ADMS]

+Quality annotation

An annotation about any quality aspects regarding the delivered content, in particular methods, metrics/indicators and results of a quality assessment in the responsibility of the Data Owner.

dqv:QualityAnnotation

§ 4.2 Class: Metric [VOCAB-DQV]

Relationship

An association class for attaching additional information to a relationship between DCAT Resources

dcat:Relationship

§ 6.12 Class: Relationship [VOCAB-DCAT-2]

Role

A role is the function of a resource or agent with respect to another resource, in the context of resource attribution or resource relationships.

Note it is a subclass of skos:Concept.

dcat:Role

§ 6.13 Class: Role [VOCAB-DCAT-2]

Standard

A standard or other specification to which a Catalogue, Catalogue Record, Data Service, Dataset, or Distribution conforms.

dct:Standard

§ Term name: Standard [DCTERMS]

Status

An indication of the maturity of a Distribution or the type of change of a Catalogue Record.

skos:Concept

§ 5.2.13 Status [VOCAB-ADMS]

4. Application Profile Properties per Class

A quick reference table of properties per class is included in § A. Quick Reference of Classes and Properties.

4.1 +Address (Agent)

Note
Class name Address (Agent)
Obligation Optional
URI

locn:Address

Usage note

A postal address of the Agent.

Reference

§ Class Address [LOCN]

4.2 Agent

Class name Agent
Obligation Mandatory
URI

foaf:Agent

Usage note

An entity (e.g., an individual or an organisation) that is associated with Catalogues, Catalogue Records, or Datasets. If the Agent is an organisation, the use of the Organization Ontology [VOCAB-ORG] is recommended. See § 7. Agent Types, Agent Roles and Contact Information for a discussion on Agent types, roles and properties.

Reference

§ Class: foaf:Agent [FOAF]

[VOCAB-ORG]

4.2.1 Mandatory property for Agent

Property

URI

Range

Usage note

Card.

name

foaf:name

rdfs:Literal

This property contains a name of the Agent. This property can be repeated for different versions of the name (e.g. the name in different languages) - see § 8. Accessibility and Multilingual Aspects.

1..n

4.2.3 Optional properties for Agent

Note

Property

URI

Range

Usage note

Card.

+address

locn:address

locn:Address

This property MAY be used to specify the postal address of the Agent.

This property is analogue to an addition by [GEODCAT-AP-v2.0.0].

0..n

+affiliation

org:memberOf

org:Organization

If the agent is of type person, this property SHOULD be used to specify the affiliation of the Agent, see § 7. Agent Types, Agent Roles and Contact Information.

This property is analogue to an addition by [GEODCAT-AP-v2.0.0].

0..n

+email

foaf:mbox

owl:Thing

This property SHOULD be used to provide the email address of the Agent, specified using fully qualified mailto: URI scheme [RFC6068]. The email SHOULD be used to establish a communication channel to the agent.

This property is analogue to an addition by [GEODCAT-AP-v2.0.0].

0..n

+first name

foaf:firstName

rdfs:Literal

If the agent is of type person, this property SHOULD be used to specify the first name of the Agent, see section § 7. Agent Types, Agent Roles and Contact Information.

0..1

+phone

foaf:phone

owl:Thing

This property MAY be used to provide the phone number of the Agent, specified using fully qualified tel: URI scheme [RFC3966].

This property is analogue to an addition by [GEODCAT-AP-v2.0.0].

0..n

+surname

foaf:surname

rdfs:Literal

If the agent is of type person, this property SHOULD be used to specify the surname of the Agent, see section 7.

0..1

+URL

foaf:workplaceHomepage

rdfs:Resource

This property MAY be used to specify the Web site of the Agent.

0..1

4.3 +Assessment

Class name Assessment
Obligation Optional
URI

mobilitydcatap:Assessment

Usage note

An assessment procedure by an external organisation. This organisation MAY be a National Body in the context of EU Delegated Regulations. EU Delegated Regulations require Member States to set up procedures to assess the compliance with the applicable Delegated Regulations, e.g. regarding the provisioning of data via a NAP. These assessment processes are handled by National Bodies [NAPCORE-NB] and installed individually in each Member State.

The information is optional and needed for the documentation of the assessment procedure. It MAY be an internal information, only visible for assessment organisations or other authorised users.

Reference

4.4 Catalogue

Class name Catalogue
Obligation Mandatory
URI

dcat:Catalog

Usage note

A concrete mobility data portal, i.e, a web portal, where mobility-related datasets and their distributions are described via metadata and discoverable for data users.

Reference

§ 6.3 Class: Catalog [VOCAB-DCAT-2]

4.4.1 Mandatory properties for Catalogue

Property

URI

Range

Usage note

Card.

dataset

dcat:dataset

dcat:Dataset

This property links the mobility data portal with a dataset that is described at the mobility data portal. This is a direct link from the mobility data portal to a dataset. However, in mobilityDCAT-AP, datasets SHOULD be linked indirectly, i.e., via the metadata record of this dataset. Thus, it is also mandatory to use the property dcat:record.

1..n

description

dct:description

rdfs:Literal

This property contains a free-text, individual name of the mobility data platform itself. This property MAY be repeated for parallel language versions of the description - see § 8. Accessibility and Multilingual Aspects.

1..n

homepage

foaf:homepage

rdfs:Resource

This property refers to a Web page that acts as the main page for the mobility data portal.

The obligation of this property is raised to “mandatory”, comparing to [DCAT-AP-v2.0.1].

1..1

publisher

dct:publisher

foaf:Agent

This property refers to an organisation, if applicable a person, which is responsible for creation and maintenance of the mobility data platform. This organisation is the direct contact for platform users, who have questions or issues about the platform and its system. This information is mandatory and should correspond to the information in the disclaimer of the platform website.

1..1

record

dcat:record

dcat:CatalogRecord

This property refers to a metadata record that is part of the mobility data portal. mobilityDCAT-AP assumes that metadata records are essential in mobility data portals, so the obligation of this property is raised to “mandatory”, comparing to [DCAT-AP-v2.0.1].

1..n

spatial / geographic

dct:spatial

dct:Location

This property refers to a country code where the data platform is hosted. For National Access Points (NAPs), this corresponds to the EC Member State or a country that installs such NAP. The property might be used for analyses about available datasets per country, or to identify country-specific metadata in case metadata are federated from multiple national portals into an international portal. It is not to be mixed up with country codes used within the dataset property dct:spatial, which might be different.

The obligation of this property is raised to “mandatory”, comparing to [DCAT-AP-v2.0.1].

1..n

title

dct:title

rdfs:Literal

This property contains a name given to the mobility data portal. This property can be repeated for parallel language versions of the name - see § 8. Accessibility and Multilingual Aspects.

1..n

4.4.3 Optional properties for Catalogue

Note
Note

Property

URI

Range

Usage note

Card.

has part

dct:hasPart

dcat:Catalog

This property refers to a related Catalogue that is part of the described mobility data portal. This property could be used to link the mobility data portal to another data portal, by e.g. harvesting metadata from this other portal into the mobility data portal.

0..n

+identifier

dct:identifier

rdfs:Literal

This property MAY contain an identifier for the mobility data portal. Allows a unique identification of the individual portal and is used for referencing, e.g., when exchanging metadata between mobility data portals.

This property SHOULD populated by the URI used within the RDF statement (via rdf:about).

This property is analogue to an addition by [GEODCAT-AP-v2.0.0].

0..1

is part of

dct:isPartOf

dcat:Catalog

This property refers to a related Catalogue in which the described mobility data portal is physically or logically included. This property could be used to link the mobility data portal to another data portal, by e.g. harvesting metadata from the mobility data portal into this other portal.

0..1

+other identifier

adms:identifier

adms:Identifier

This property MAY be used as an additional identifier, besides dct:identifier. It MAY be referring to a dedicated, EU-wide identificator system of NAPS or other portals, to be introduced in the future.

0..1

4.5 Catalogue Record

Class name Catalogue Record
Obligation Mandatory
URI

dcat:CatalogRecord

Usage note

A description of a metadata entry in the mobility data portal, referring to one dataset and its distributions published on the portal. mobilityDCAT-AP assumes that metadata records are essential in mobility data portals, so the obligation of this class is raised to “mandatory”, comparing to [DCAT-AP-v2.0.1].

Reference

§ 6.5 Class: Catalog Record [VOCAB-DCAT-2]

4.5.1 Mandatory properties for Catalogue Record

Note

Property

URI

Range

Usage note

Card.

+creation date

dct:created

rdfs:Literal typed as xsd:date or xsd:dateTime

This property contains the date stamp (date and time) when the metadata entry was created for the first time. It SHOULD be generated by the system, whenever a platform user enters the metadata entry.

This property is analogue to an addition by [GEODCAT-AP-v2.0.0].

1..1

language

dct:language

dct:LinguisticSystem

This property refers to a language used in the textual metadata describing titles, descriptions, etc. of the metadata entry. The value MAY be generated automatically by the NAP system, corresponding to the currently used language in the user interface. Some portals offer multilingual user interfaces, e.g., in the local language and additionally in English. For multiple languages - see § 8. Accessibility and Multilingual Aspects. A controlled vocabulary § 5.2 Controlled vocabularies to be used is provided.

1..n

primary topic

foaf:primaryTopic

dcat:Dataset

This property links the metadata entry to the dataset described in the entry.

1..1

update / modification date

dct:modified

rdfs:Literal typed as xsd:date or xsd:dateTime

This property contains the date stamp (date and time) when the metadata entry was last modified. It SHOULD be generated by the system, whenever a platform user updates the metadata entry. If there has been no update yet, the value from the property "creation date" SHOULD be taken.

1..1

4.5.3 Optional properties for Catalogue Record

Note
Note

Property

URI

Range

Usage note

Card.

+publisher

dct:publisher

foaf:Agent

This property refers to an entity (an organisation or a person), which is responsible for creation and maintenance of the metadata entry on the data platform. This entity is the direct contact for the data platform operators or data-searching users, who have questions or issues about the metadata entry. This information can be natively created by a data platform, then corresponding to the entity that is registered to the data platform and has the role of a metadata creator. This information can be also harvested from other portals. It should include, as a minimum, the name and email address of the entity. The information might be identical to the property “Publisher” of the corresponding dataset.

This property is analogue to an addition by [GEODCAT-AP-v2.0.0].

0..1

4.6 Category

Class name Category
Obligation Mandatory
URI

skos:Concept

Usage note

A category of a dataset, i.e. a specific subject, theme, or a class about its content.

The category is described via a categorisation scheme, i.e. a classification or a taxonomy. Such scheme lists all potential categories, see class "Category Scheme".

In mobilityDCAT-AP, this class SHOULD only be used in the context of a dataset dcat:theme. In other contexts, e.g. under [geoDCAT-AP-v2.0.0], this might also be used to describe the theme of a Catalogue or Data Service.

Reference

§ 6.10 Class: Concept [VOCAB-DCAT-2]

4.6.1 Mandatory property for Category

Property

URI

Range

Usage note

Card.

preferred label

skos:prefLabel

rdfs:Literal

This property contains a preferred label of the Category. This property can be repeated for parallel language versions of the label - see § 8. Accessibility and Multilingual Aspects.

1..n

4.6.2 Optional property for Category

Note

Property

URI

Range

Usage note

Card.

+category scheme

skos:inScheme

skos:ConceptScheme

This property MAY be used to specify the Category Scheme to which the Category belongs.

This property is analogue to an addition by [GEODCAT-AP-v2.0.0].

0..1

4.7 Category Scheme

Note
>
Class name Category scheme
Obligation Recommended
URI

skos:ConceptScheme

Usage note

A categorisation scheme, i.e. a classification or a taxonomy, listing all potential categories which might be used for instances of class Category.

In mobilityDCAT-AP, this scheme is expressed via a controlled vocabulary for the property "dcat:theme" of class Dataset.

Reference

§ 6.9 Class: Concept Scheme [VOCAB-DCAT-2]

4.7.1 Mandatory property for Category Scheme

Property

URI

Range

Usage note

Card.

title

dct:title

rdfs:Literal

This property contains a name of the Category Scheme. May be repeated for different versions of the name - see § 8. Accessibility and Multilingual Aspects.

1..n

4.8 Checksum

Note
Class name Checksum
Obligation Optional
URI

spdx:Checksum

Usage note

A value that allows the contents of a file to be authenticated. This class allows the results of a variety of checksum and cryptographic message digest algorithms to be represented.

Reference

§ checksum [SPDX]

4.8.1 Mandatory properties for Checksum

Property

URI

Range

Usage note

Card.

algorithm

spdx:algorithm

spdx:checksumAlgorithm_sha1

This property identifies the algorithm used to produce the subject Checksum. Currently, SHA-1 is the only supported algorithm. It is anticipated that other algorithms will be supported at a later time.

1..1

checksum value

spdx:checksumValue

rdfs:Literal typed as xsd:hexBinary

This property provides a lower case hexadecimal encoded digest value produced using a specific algorithm.

1..1

-->

4.9 Data Service

Class name Data Service
Obligation Optional
URI

dcat:DataService

Usage note

A collection of operations that provides access to one or more datasets or data processing functions.

For mobilityDCAP-AP, it was discussed if and how this class should be used. In fact, some mobility data are offered via sophisticated systems, such as APIs or broker interfaces, in contrast to simple downloadable files.

The following advice is based on the guideline provided in [DCAT-AP-v2.1.0-Guideline-Dataservices], and an analysis on how the class dcat:DataService is embedded in the [DCAT-AP-v2.0.1] UML model. Three usage options for dcat:DataService are identified:

1. As a range to class dcat:Distribution via property dcat:accessService.

This construct allows that class dcat:DataService describes additional information, e.g., about an end point, related to one distribution. This, in fact, MAY be useful to describe a dedicated (but optional) data service related to one distribution.

However, looking at today's set-ups of NAPs and mobility data portals, any metadata about the characteristics and mechanisms of a distribution channel MAY ALSO be sufficiently described as properties of class dcat:Distribution. In particular, information provided by property dcat:endpointDescription (mandatory to class dcat:DataService) can be equally provided by the property dcat:accessURL (mandatory to class dcat:Distribution).

This advice contradicts somewhat to the [DCAT-AP-v2.1.0-Guideline-Dataservices], stating that "Anything that has not the intend to provide a downloadable representation of a dataset is a data service.", for cases in which mobility data is offered via APIs, broker services etc. However, the usage note for the property dcat:accessURL also includes "...information about how to get the Dataset", which could allow for a link to one ore more APIs, broker services etc. This way, the class dcat:Distribution is considered sufficient for such cases.

2. As a domain to class dcat:Dataset via property dcat:servesDataset.

Class dcat:DataService would then linking to one or more datasets "...that this data service can distribute". Thus, this property connects the Data Service to the Dataset.

The following figure shows how this contruct, containing above points 1. and 2., is represented in a UML diagram.

mobilityDCAT-AP UML Class Diagram with DataService
Figure 4 Excerpt of mobilityDCAT-AP UML Class Diagram with relations to class DataService

3. As a range to class dcat:CatalogueRecord via property foaf:primaryTopic as 1:1 relationship.

This implies a metadata entry about one Data Service. However, all analysed mobility data portals, including NAPs, store only metadata about datasets, and not about data services. Thus, such relationship is irrelevant for mobilityDCAT-AP as of today. This construct might be used in the future when such portals also explicitely list data services.

Altogether, class dcat:DataService MAY be used for the contruct explained above, but seems to be a rather unnecessary addition to the data model in NAPs and mobility data portals, looking at their set-ups today. It might be more relevant in the future, when data services are more explicit items to be exposed in NAPs or mobility data portals. For this reason, any properties, as associated to class dcat:DataService in [DCAT-AP-v2.0.1], are kept in mobilityDCAT-AP.

Reference

§ 6.8 Class: Data Service [VOCAB-DCAT-2]

4.9.1 Mandatory properties for Data Service

Property

URI

Range

Usage note

Card.

endpoint URL

dcat:endpointURL

rdfs:Resource

The root location or primary endpoint of the Service (an IRI).

1..n

title

dct:title

rdfs:Literal

This property contains a name given to the Data Service. This property can be repeated for parallel language versions of the name - see § 8. Accessibility and Multilingual Aspects.

1..n

4.9.3 Optional properties for Data Service

Property

URI

Range

Usage note

Card.

access rights

dct:accessRights

dct:RightsStatement

This property MAY include information regarding access or restrictions based on privacy, security, or other policies.

For INSPIRE metadata, this property SHOULD be used with the URIs of the "Limitations on public access" code list operated by the INSPIRE Registry [INSPIRE-LPA].

0..1

description

dct:description

rdfs:Literal

This property contains a free-text account of the Data Service. This property can be repeated for parallel language versions of the description - see § 8. Accessibility and Multilingual Aspects.

0..n

licence

dct:license

dct:LicenseDocument

This property contains the licence under which the Data Service is made available.

0..1

4.10 Dataset

Class name Dataset
Obligation Mandatory
URI

dcat:Dataset

Usage note

A dataset is a collection of data, published or curated by a single source, and available for access or download at the mobility data portal in one or more distributions. In the context of mobility-related data exchange, this might be, e.g., a data collection about static parking information for truck drivers, published by a road authority.

Reference

§ 6.6 Class: Dataset [VOCAB-DCAT-2]

4.10.1 Mandatory properties for Dataset

Note

Property

URI

Range

Usage note

Card.

description

dct:description

rdfs:Literal

This property contains more information about the dataset as a brief, free-text description. It is used only for a brief overview, because free-text fields are unsuitable for searches, due to spelling mistakes, different wordings and other aspects. The categorisation and other aspects about the dataset are described within other properties of the dataset.

This property can be repeated for parallel language versions of the description - see § 8. Accessibility and Multilingual Aspects. The language versions should correspond to property dct:language of class Catalogue Record. I.e., if more than one language is provided as a metadata language, there should be as many language versions for the description.

1..n

dataset distribution

dcat:distribution

dcat:Distribution

This property links the dataset to an available distribution.

In mobilityDCAT-AP, it is mandatory that each dataset has at least one distribution. Thus, the obligation of this property is raised to “mandatory”, compared to [DCAT-AP-v2.0.1].

1..n

frequency

dct:accrualPeriodicity

dct:Frequency

This property describes how often the delivered content is updated. This information tells a data consumer, how often it is updated on the on the data platform, so the data consumer might align the frequency of data retrieval accordingly.

For data services, e.g., data feeds, the frequency should correspond to the technical upload / data push frequency. For static datasets, it should correspond to the expected change frequency (see property dct:modified). The frequency might be a specific time interval, or a general remark such as “updated on occurrence”. A controlled vocabulary § 5.2 Controlled vocabularies to be used is provided.

The obligation of this property is raised to “mandatory”, compared to [DCAT-AP-v2.0.1].

1..1

+mobility theme

mobilitydcatap:mobilityTheme

skos:Concept

This property refers to the mobility-related theme (i.e., a specific subject, category, or type) of the delivered content. A dataset may be associated with multiple themes. A theme is important for data seekers who are interested in a particular type of data content.

The theme is described via a controlled vocabulary in two hierarchy levels: The 1st level is a mandatory field labelled "Data content category", describing the classification of the data content on an aggregated level. The 2nd level is an optional field labelled “Data content sub category”, detailing the "Data content category" via one or several sub-categories. When entering the metadata for one dataset, the data provider would first select one or several options of a "Data content category", and then optionally details this with one or more options of corresponding “Data content sub category”. The platform must be able to handle the dependencies between these two levels, i.e., match the allowed options between the 1st and 2nd level.

The corresponding controlled vocabulary § 5.2 Controlled vocabularies to be used is provided.

This property is a sub-property of dcat:theme, which is also a further, recommended property of Dataset. To distinguish the both theme properties, it is recommended to label mobilitydcatap:mobilityTheme as "Mobility Theme", and dcat:theme as "EU Open Data Theme".

The subject of a dataset MAY also be described via a property dcat:keyword. However, the usage of "mobility theme" is preferred, to avoid ambiguity and uncontrolled theme descriptions.

1..n

spatial / geographic coverage

dct:spatial

dct:Location

This property refers to a geographic region that is covered by the delivered content.

There are different options how to describe the geographic region under the class Location, see § 4.16 Location. One of these options MUST be used, as the geographic reference is essential for data seekers.

Thus, the obligation of this property is raised to “mandatory”, compared to [DCAT-AP-v2.0.1].

1..n

title

dct:title

rdfs:Literal

This property contains a name given to the dataset in a generic term. The name should be a meaningful, unique and unambiguous label.

This property can be repeated for parallel language versions of the name - see § 8. Accessibility and Multilingual Aspects.The language versions should correspond to property dct:language of class Catalogue Record. I.e., if more than one language is provided as a metadata language, there should be as many language versions for the title.

1..n

publisher

dct:publisher

foaf:Agent

This property refers to an entity (company and person) that publishes the corresponding dataset. This entity is responsible for the provisioning of a dataset. The entity also concludes a contract, if applicable.

This information can be natively created by a data platform, then corresponding to the entity that is registered to the data platform and has the role of a data publisher. This information can be also harvested from other portals. The information might be identical to the property dct:publisher of class Catalogue Record and/or dct:rightsHolder of class Dataset.

The obligation of this property is raised to “mandatory”, compared to [DCAT-AP-v2.0.1].

To establish a contact with a company or person responsible for the datase, the recommended property dcat:contactPoint SHOULD be used.

1..1

4.10.3 Optional properties for Dataset

Note
Note
#">intended information service<

Property

URI

Range

Usage note

Card.

+applicable legislation

dcatap:applicableLegislation

skos:Concept

This property MAY refer to one or several legal frameworks being relevant for the dataset, e.g., an EC Delegated Regulation which constitutes the purpose of the corresponding data platform (here called National Access Point/NAP), or some other international or national frameworks, e.g., Open Data regulations.

For European legal frameworks, it is recommended to use the European Legislation Identifier [ELI] to refer to legislation whenever possible.

This property is derived from the DCAT-AP HVD extension [DCAT-AP-HVD].

0..n

+assessment result

mobilitydcatap:assessmentResult

mobilitydcatap:Assessment

This property MAY refer to the results and outcomes from an assessment process by some organisation, e.g., a National Body in the context of EU Delegated Regulations. EU Delegated Regulations require Member States to set up procedures to assess the compliance of the Delegated Regulations, e.g. regarding the provisioning of data via a NAP. These assessment processes are handled by National Bodies [NAPCORE-NB] and installed individually in each Member State.

The property MAY point to the most recent assessment procedure, including its date, its result as a free-text and/or a link referring to an assessment report online.

The difference to the property dqv:hasQualityAnnotation is that the latter one is provided by the data provider, while the assessment results are provided by an external organisation.

0..1

has version

dct:hasVersion

dcat:Dataset

This property MAY refer to a related dataset that is a version, edition, or adaptation of the described dataset. Corresponds to the property dct:isVersionOf, with a contrary relationship. It might be used to host multiple versions of the same dataset in the data portal, also enabling a version history. Multiple versions should be differentiated via the properties owl:versionInfo and adms:versionNotes.

0..n

identifier

dct:identifier

rdfs:Literal

This property MAY contain an identifier for the dataset. Allows a unique identification of the individual dataset and is used for referencing, e.g., when exchanging metadata between mobility data portals.

This property SHOULD populated by the URI used within the RDF statement (via rdf:about).

0..1

is referenced by

dct:isReferencedBy

rdfs:Resource

This property MAY reference, cite, or otherwise point to another, related dataset. Corresponds to the property dct:relation, with a contrary relationship. It may be a link between two individual datasets that complement each other, e.g. one dataset with static parking data, and one with dynamic parking data, both covering the same parking facilities.

0..n

is version of

dct:isVersionOf

dcat:Dataset

This property MAY refer to a related dataset of which the described dataset is a version, edition, or adaptation. Corresponds to property dct:hasVersion with contrary relationship. It might be used to host multiple versions of the same dataset in the data portal, also enabling a version history. Multiple versions should be differentiated via the properties owl:versionInfo and adms:versionNotes.

0..n

+intended information service

mobilitydcatap:intendedInformationService

skos:Concept

This property MAY describe predefined information services, which the data content is intended to support.

Such services MAY be, e.g., information services for multimodal mobility, as specified by EC Delegated Regulation 2017/1926 [EC-MMTIS-DR]. Examples of such services include “location search”, which is based on a datasets with address identifiers, or “trip plan computation”, which is based on datasets about a road network. A controlled vocabulary § 5.2 Controlled vocabularies to be used is provided.

0..n

language

dct:language

dct:LinguisticSystem

This property refers to a language of content data, if this data has a natural language embedded. Such data contents include text fields, addresses etc. This property can be repeated if there are multiple languages in the Dataset - see § 8. Accessibility and Multilingual Aspects. A controlled vocabulary § 5.2 Controlled vocabularies to be used is provided.

0..n

other identifier

adms:identifier

adms:Identifier

This property MAY be used as an additional identifier, besides dct:identifier. It MAY be referring to a dedicated, EU-wide identificator system of NAP datasets, to be introduced in the future, or other identificator systems such as MAST/ADS [MAST-ADS], [DataCite], [DOI], [EZID] or [W3ID].

0..n

release date

dct:issued

rdfs:Literal typed as xsd:date or xsd:dateTime

This property contains the date of formal issuance (e.g., publication) of the Dataset. This is redundant to property "created" from class "Catalogue Record" and should not be used.

0..1

update / modification date

dct:modified

rdfs:Literal typed as xsd:date or xsd:dateTime

This property MAY contain the most recent date on which the content of a dataset was changed or modified. This is redundant for high-frequency data services, e.g., via a data feed service, where the change date can be derived from the time stamp within the data feed.

0..1

version

owl:versionInfo

rdfs:Literal

This property MAY contain a version number or other version designation of the dataset. The version should be updated, whenever there are changes to the dataset noted by the property dct:modified. Together with property adms:versionNotes, this MAY also enable a change history (or version history) of the corresponding dataset, which could be hosted and published on the data platform.

It is recommended to follow W3C Data on the Web Best Practices [DWBP]. Version identifiers should enable comparison of versions and distinguishing major from minor versions, such as Semantic Versioning [SEMVER].

0..1

version notes

adms:versionNotes

rdfs:Literal

This property MAY contain a textual description of the differences between this version and a previous version of the dataset, as an addition to the property owl:versionInfo. This property can be repeated for parallel language versions of the version notes - see § 8. Accessibility and Multilingual Aspects.

0..n

+quality description

dqv:hasQualityAnnotation

dqv:QualityAnnotation

This property MAY describe any quality aspects regarding the delivered content, in particular methods, metrics/indicators and results of a quality assessment in the responsibility of the Rights Holder (see property dct:rightsHolder). This information SHOULD assist data consumers in determining the value of data, before actually accessing and processing it. Thus, the information SHOULD be publicly available. Furthermore, it can be helpful for validation processes by 3rd parties, e.g., a National Body in context of EU Delegated Regulations.

Quality aspects SHOULD be noted via a free text and/or via URLs linking to further quality information. If there is absolutely no quality information, at least a note “quality information is unknown” SHOULD be given.

If existing quality frameworks have been applied in the quality assessment, e.g., the Quality Packages from the EU EIP and NAPCORE projects [EU-EIP-QP], these frameworks should be referenced.

0..n

4.11 Distribution

Class name Distribution
Obligation Mandatory
URI

dcat:Distribution

Usage note

A distribution describes the data formats and communication methods for a dataset. There may be one or multiple distributions for one dataset. For example, the same dataset (e.g. static parking information for truck drivers) can be provided in different ways e.g. as downloadable zip file or as XML using a SOAP web service. These are two distributions based on one dataset.

in [DCAT-AP-v2.0.1], this class has been classified as ‘Recommended’, to allow for cases that a particular Dataset does not have a Distribution, i.e. . However, for the context of mobility data portals, it can be expected that all datasets have one or more Distributions. Thus, the obligation of class Distribution is raised to mandatory, comparing to [DCAT-AP-v2.0.1].

Reference

§ 6.7 Class: Distribution [VOCAB-DCAT-2]

4.11.1 Mandatory properties for Distribution

Note

Property

URI

Range

Usage note

Card.

access URL

dcat:accessURL

rdfs:Resource

This property contains a URL that gives access to a Distribution of the Dataset. Depending on the type of data provision, there are different options for describing the URL.

For data services, e.g., API, broker services, data feeds, etc., the URL MAY be the end point of such service. However, if some agreements between the data provider and the data user need to be established first, the access URL may link to web page, where the access is further arranged, e.g., initiating a a subscription process. For data which can be downloaded directly, the download URL should be copied from the optional property dcat:downloadURL. For other cases, where data cannot be directly accessed or downloaded via the platform, the access URL MAY be a link to an external service or a website which enables access to the data.

This way, this property is the primary key to link to a data service. There is also specific class dcat:DataService, which can be linked via property dcat:accessService. See § 4.9 Data Service for a usage note about the class Data Service.

1..1

+mobility data standard

mobilitydcatap:mobilityDataStandard

mobilitydcatap:MobilityDataStandard

This property describes the mobility data standard, as applied for the delivered content within the Distribution. A mobility data standard, e.g., DATEX II, combines syntax and semantic definitions of entities in a certain domain (e.g., for DATEX II: road traffic information), and optionally adds technical rules for data exchange. A controlled vocabulary § 5.2 Controlled vocabularies to be used is provided, listing common mobility data standards. If no established mobility data standard is applied, an information "proprietary standard" is requested.

1..1

format

dct:format

dct:MediaTypeOrExtent

This property refers to the technical syntax of the delivered content within the Distribution. It describes the base standard that specifies syntactically correct documents. On this level, only base elements of building documents properly are specified and can be proved by syntax checks. A controlled vocabulary § 5.2 Controlled vocabularies to be used is provided.

The obligation of this property is raised to “mandatory”, compared to [DCAT-AP-v2.0.1].

There is a similar property in [DCAT-AP-v2.0.1] dcat:mediaType, which is removed in mobilityDCAT-AP. The reason is the use of Controlled vocabularies: dct:format uses the EU Authority List [EUV-FT], whereas dcat:mediaType uses the IANA media types [IANA-MEDIA-TYPES]. The first one, however, is sufficient to describe the syntaxes commonly used in mobility data portals.

1..1

rights

dct:rights

dct:RightsStatement

This property links to a Rights Statement, i.e., a statement about the intellectual property rights (IPR). As a minimum, it should include an information on the type of conditions for access and usage. A concrete (standard) license can be referred via the recommended property dct:license.

The obligation of this property is raised to “mandatory”, compared to [DCAT-AP-v2.0.1].

1..1

4.11.3 Optional properties for Distribution

Note
Note

Property

URI

Range

Usage note

Card.

access service

dcat:accessService

dcat:DataService

This property refers to a Data Service that gives access to the Distribution of the Dataset.

0..n

+character encoding

cnt:characterEncoding

rdfs:Literal

This property describes the technical encoding format of the delivered content within the Distribution. It SHOULD be expressed using a character set name defined in the IANA register [IANA-CHARSETS].

This property is analogue to an addition by [GEODCAT-AP-v2.0.0].

This is a sub-property of dct:conformsTo.

0..1

+communication method

mobilitydcatap:communicationMethod

skos:Concept

This property indicates for data services, e.g., data feeds, if the data interface of the data provider system functions in a push or pull mode. A controlled vocabulary § 5.2 Controlled vocabularies to be used is provided.

0..1

+data format notes

mobilitydcatap:dataFormatNotes

rdfs:Literal

This property contains any additional information about the format of the delivered content within the Distribution (see the corresponding properties dct:format, mobilitydcatap:mobilityDataStandard, mobilitydcatap:grammar), in a textual format. This might be about, e.g., extensions being used in a mobilitydcatap:mobilityDataStandard.

0..1

download URL

dcat:downloadURL

rdfs:Resource

This property contains a URL that is a direct link to a downloadable file in a given format.

0..1

+grammar

mobilitydcatap:grammar

skos:Concept

This property describes the technical data grammar format of the delivered content within the Distribution. It describes the standard on top of the elementary syntax that describe data structures in the dataset. A controlled vocabulary § 5.2 Controlled vocabularies to be used is provided.

This is a sub-property of dct:conformsTo.

0..1

+sample

adms:sample

rdfs:Resource

This property refers to a sample Distribution of the Dataset. A data sample allows data users to investigate the data content and data structure, without subscribing to a data feed or downloading a complete data set.

In [DCAT-AP-v2.0.1], there is a property adms:sample under the class dcat:Dataset , with a range of dcat:Distribution. This implies, that all mandatory properties from dcat:Distribution, e.g., mobilitydcatap:mobilityDataStandard, must be applied. To simplify the description of the Sample, mobilityDCAT-AP recommends to describe the Sample via a property under class dcat:Distribution. It is assumed that all other properties, as already populated for dcat:Distribution, e.g., mobilitydcatap:mobilityDataStandard, also apply for the description of the data sample.

0..n

+temporal coverage

dct:temporal

dct:PeriodOfTime

This property describes the beginning and end of the time interval when a data service, e.g., a data feed, is delivered technically via the data platform. If there is no entry it means that the publication gets valid immediately and the timestamp is the same as the metadata timestamp.

0..1

title

dct:title

rdfs:Literal

This property contains a name given to the Distribution. This property can be repeated for parallel language versions of the description - see § 8. Accessibility and Multilingual Aspects.

0..n

4.12 Document

Note
Class name Document
Obligation Optional
URI

foaf:Document

Usage note

A textual resource intended for human consumption that contains information, e.g., a Web page about a Dataset.

Reference

§ Class: foaf:Document [FOAF]

4.13 Identifier

Class name Identifier
Obligation Optional
URI

adms:Identifier

Usage note

An identifier in a particular context, consisting of the string that is the identifier; an optional identifier for the identifier scheme; an optional identifier for the version of the identifier scheme; an optional identifier for the agency that manages the identifier scheme

Reference

§ 5.2.6 Identifier [VOCAB-ADMS]

4.13.1 Mandatory property for Identifier

Property

URI

Range

Usage note

Card.

notation

skos:notation

rdfs:Literal typed with the URI of one of the members of the DataCite Resource Identifier Scheme [DataCite-RIS]

This property contains a string that is an identifier in the context of the identifier scheme referenced by its data type.

0..1

4.14 Kind

Note
Class name Kind
Obligation Optional
URI

vcard:Kind

Usage note

A description following the [VCARD-RDF] specification, e.g. to provide telephone number and e-mail address for a contact point. Note that the class vcard:Kind is the parent class for the four explicit types of vCards (vcard:Individual, vcard:Organization, vcard:Location, vcard:Group).

Reference

§ Kind [VCARD-RDF]

4.14.1 Mandatory properties for Kind

Note

Property

URI

Range

Usage note

Card.

+email

vcard:hasEmail

owl:Thing

This property contains an email address of the Kind, specified using fully qualified mailto: URI scheme [RFC6068].

This property is analogue to an addition by [GEODCAT-AP-v2.0.0].

1..n

+name

vcard:fn

rdfs:Literal

This property contains a name of the Kind. This property can be repeated for different versions of the name (e.g., the name in different languages) - see § 8. Accessibility and Multilingual Aspects.

This property is analogue to an addition by [GEODCAT-AP-v2.0.0].

1..n

4.14.3 Optional properties for Kind

Note

4.15 Licence Document

Class name Licence Document
Obligation Recommended
URI

dct:LicenseDocument

Usage note

A legal document, e.g., a concrete license, giving official permission to do something with a resource.

It MAY be used to concretise the generic intellectual property rights (IPR) information, as provided via class dct:RightsStatement.

However, if a concrete licence is defined for the Distribution of interest, it SHOULD be provided via this class, so a data user can assess the license conditions in machine- and human-readable formats, before using the data.

Reference

§ Term name: LicenseDocument [DCTERMS]

4.15.2 Optional properties for Licence Document

Note

Property

URI

Range

Usage note

Card.

+licence text

rdfs:label

rdfs:Literal

This property MAY be used to contain the full text of a Licence Document, as a free text. This MAY be used when there is no standard license that can be linked via property dct:identifier. This property can be repeated for parallel language versions of the name - see § 8. Accessibility and Multilingual Aspects.

This property is analogue to an addition by [GEODCAT-AP-v2.0.0].

0..n

4.16 Location

Class name Location
Obligation Mandatory
URI

dct:Location

Usage note

A spatial region or named place. It can be represented via a named place (controlled vocabulary) or with geographic coordinates, according to DCAT-AP guidelines [DCAT-AP-guideline-spatial].

For mobility data portals, usage of a named place is preferred. Many mobility data providers represent public authorities such as states, regions, municipalities etc, which can be easily represented via named places. In contrast, defining of coordinates per dataset might be error-prone and inconsistent. As named spaces, identifiers SHOULD be used via property dct:identifier. These are coded via controlled vocabularies such as the EU authority tables, NUTS (Nomenclature des unités territoriales statistiques) or Geonames, see § 5.2 Controlled vocabularies to be used. Alternatively, geographic clear names MAY be used via property "skos:prefLabel".

Reference

§ Term name: Location [DCTERMS]

4.16.2 Optional properties for Location

Note

Property

URI

Range

Usage note

Card.

bounding box

dcat:bbox

rdfs:Literal typed as gsp:wktLiteral or gsp:gmlLiteral

This property refers to the geographic bounding box of a resource.

0..1

centroid

dcat:centroid

rdfs:Literal typed as gsp:wktLiteral or gsp:gmlLiteral

This property refers to the geographic centre (centroid) of a resource.

0..1

+geographic name

skos:prefLabel

rdfs:Literal

This property contains a preferred label of the Location. This property can be repeated for parallel language versions of the label - see § 8. Accessibility and Multilingual Aspects.

This property is analogue to an addition by [GEODCAT-AP-v2.0.0].

0..n

geometry

locn:geometry

rdfs:Literal typed as gsp:wktLiteral or gsp:gmlLiteral

This property associates any resource with the corresponding geometry.

0..1

Note

4.17 Media Type

Note
Class name Media type
Obligation Optional
URI

dct:MediaType

Usage note

A media type, e.g. the format of a computer file.

Reference

§ Term name: MediaType [DCTERMS]

4.18 +Mobility Data Standard

Class name Mobility Data Standard
Obligation Mandatory
URI

mobilitydcatap:MobilityDataStandard

Usage note

The mobility data standard applied for the delivered content. A mobility data standard, e.g., DATEX II, combines syntax and semantic definitions of entities in a certain domain (e.g., for DATEX II: road traffic information), and optionally adds technical rules for data exchange.

This is a sub-class of dct:Standard.

Reference

§ Term name: Standard [DCTERMS]

4.18.1 Optional properties for Mobility Data Standard

Note

Property

URI

Range

Usage note

Card.

+version

owl:versionInfo

rdfs:Literal

This property describes the version of the mobility data standard, as applied within the delivered content. A version might be, e.g., DATEX II v3.2. This information is provided in a textual format. To avoid ambiguity, only short version identifiers SHOULD be used, e.g., only "3.2", without redundant acronyms such as "v", underscores etc.

0..1

+schema

mobilitydcatap:schema

rdfs:Resource

This property describes the schema of the mobility data standard, as applied within the delivered content. There are different options how to reference the schema. It might be a reference to a portal-internal catalogue of schemas, a reference to an individual schema (that is provided by the data publisher), or a reference to an external catalogue of schemas (like a stakeholder-based DATEX II profile published on the datex2.eu page). The data platform SHOULD keep an archive of commonly used schemas. The data provider SHOULD be able to select an applicable schema from this archive, or to upload an own, individual schema. In any case, the schema should be available as a resource.

This is a sub-property of dct:conformsTo.

0..1

4.19 Period of Time

Class name Period of time
Obligation Recommended
URI

dct:PeriodOfTime

Usage note

An interval of time that is named or defined by its start and end dates.

Reference

§ Term name: PeriodOfTime [DCTERMS]

4.19.2 Optional properties for Period of Time

Note

4.20 Provenance Statement

Note
Class name Provenance Statement
Obligation Optional
URI

dct:ProvenanceStatement

Usage note

A statement of any changes in ownership and custody of a resource since its creation that are significant for its authenticity, integrity, and interpretation

Reference

§ Term name: ProvenanceStatement [DCTERMS]

4.21 +Quality Annotation

Class name Quality Annotation
Obligation Optional
URI

dqv:QualityAnnotation

Usage note

An annotation about any quality aspects regarding the delivered content, in particular methods, metrics/indicators and results of a quality assessment in the responsibility of the Data Owner.

There is a similar class "Quality Measurement" in [GEODCAT-AP-v2.0.0]. Both "Quality Annotation" are "Quality Measurement" are reusing the Data Quality Vocabulary [VOCAB-DQV]. Quality Measurement is referring to concrete metrics, like sub-types of spatial resolutions being used [GEODCAT-AP-v2.0.0]. At mobility data portals, however, the practice so far is to provide some free text about quality aspects. Thus, the Quality Annotation refers to an unspecified form of quality annotation, which MAY be a free text.

Reference

[VOCAB-DQV]

4.21.1 Optional properties for Quality Annotation

Note

Property

URI

Range

Usage note

Card.

+quality annotation resource

oa:hasBody

rdfs:Literal

This property MAY be used to describe any quality aspects regarding the delivered content, in form of a URL linking to further details or results. Alternatively, textual information MAY be provided using the Embedded Textual Body construction of the Web Annotation Data Model [Web-Annotation-Data-Model], which allows to specify text formats and languages which might be relevant for multilingual purposes.

0..1

+quality annotation target

oa:hasTarget

dcat:Dataset

This property MAY be used to describe the target of the quality annotation, referring back to the dataset being described. I.e., it is the inverse property of "dqv:hasQualityAnnotation" for class Dataset.

0..1

4.22 Relationship

Note
Class name Relationship
Obligation Optional
URI

dcat:Relationship

Usage note

An association class for attaching additional information to a relationship between DCAT Resources

Reference

§ 6.12 Class: Relationship [VOCAB-DCAT-2]

4.22.1 Mandatory properties for Relationship

Property

URI

Range

Usage note

Card.

had role

dcat:hadRole

dcat:Role

This property refers to the function of an entity or agent with respect to another entity or resource.

1..n

relation

dct:relation

rdfs:Resource

This property refers to the resource related to the source resource.

1..n

4.23 Rights Statement

Note
Class name Rights statement
Obligation Mandatory
URI

dct:RightsStatement

Usage note

A statement about the intellectual property rights (IPR) held in or over a resource, a legal document giving official permission to do something with a resource, or a statement about access rights.

As a minimum, it should include an information on the type of conditions for access and usage. Information about concrete licenses can be provided via class dct:LicenseDocument.

Reference

§ Term name: RightsStatement [DCTERMS]

4.23.1 Mandatory property for Rights Statement

Note

Property

URI

Range

Usage note

Card.

4.24 Standard

Note
Class name Standard
Obligation Optional
URI

dct:Standard

Usage note

A standard or other specification to which a Catalogue, Catalogue Record, Data Service, Dataset, or Distribution conforms.

Reference

§ Term name: Standard [DCTERMS]

5. Controlled Vocabularies

5.1 Requirements for controlled vocabularies

The following is a list of requirements that were identified for the controlled vocabularies to be recommended in this Application Profile.

Controlled vocabularies SHOULD:

These criteria do not intend to define a set of requirements for controlled vocabularies in general; they are only intended to be used for the selection of the controlled vocabularies that are proposed for this Application Profile.

5.2 Controlled vocabularies to be used

In the table below, some properties are listed with controlled vocabularies that MUST be used for the listed properties. The declaration of the following controlled vocabularies as mandatory ensures a minimum level of interoperability.

Compared with [DCAT-AP-v2.0.1], mobilityDCAT-AP makes use of additional controlled vocabularies. External organisations maintain some of these additional controlled vocabularies, and others are created and maintained by mobilityDCAT-AP.

Further, mobilityDCAT-AP is removing some recommended and properties from [DCAT-AP-v2.0.1], which are linked with controlled vocabularies. Thus, these controlled vocabularies are not relevant for mobilityDCAT-AP and are not listed in the following table.

Property URI

Used for Class

Vocabulary name

Vocabulary URI

Usage note

+mobilitydcatap:mobilityTheme

dcat:Dataset

+mobilityDCAT-AP Vocabulary "Data content category"

+https://w3id.org/mobilitydcat-ap/mobility-theme

This is a vocabulary created by mobilityDCAT-AP. There are two hierarchical levels: "Data content category" (mandatory) and "Data content sub-catagory” (optional), see the usage note for property mobilitydcatap:mobilityTheme.

dcat:theme

dcat:Dataset

EU Authority Table "Data Themes" [EUV-THEMES]

http://publications.europa.eu/resource/authority/data-theme

This is a mandatory vocabulary "Data Themes" by the Publications Office of the European Union. In most cases, it is assumed that the relevant value for mobility data portals is "Transport" [EUV-THEMES-TRANSPORT], see the usage note for property dcat:theme.

dcat:themeTaxonomy

dcat:Catalog

Dataset Theme Vocabulary [EUV-THEMES]

http://publications.europa.eu/resource/authority/data-theme

The value to be used for this property is the URI of the vocabulary itself, i.e. the concept scheme, not the URIs of the concepts in the vocabulary.

dct:accessRights

dcat:DataService

EU Authority Table "Access right" [EUV-AR]

http://publications.europa.eu/resource/authority/access-right

This is an optional vocabulary "Access right" by the Publications Office of the European Union.

dct:accrualPeriodicity

dcat:Dataset

EU Authority Table "Frequency" [EUV-FREQ]

http://publications.europa.eu/resource/authority/frequency

This is a mandatory vocabulary "Frequency" by the Publications Office of the European Union.

The values from this vocabulary do not cover all relevant time intervals used in mobility data portals, e.g., minute-based intervals. Thus, there is a second vocabulary created by mobilityDCAT-AP (see next row), extending this taxonomy with additional missing time intervals.

+mobilityDCAT-AP Vocabulary "Update frequency"

+https://w3id.org/mobilitydcat-ap/update-frequency

This is a vocabulary created by mobilityDCAT-AP, complementing time intervals missing in the EU vocabulary (see row above).

Values from the above-mentioned vocabularies MUST be used as instances of class dct:Frequency, being the range of the property dct:accrualPeriodicity.

+dct:conformsTo

dcat:Dataset

+OGC EPSG Coordinate Reference Systems Register [OGC-EPSG]

+http://www.opengis.net/def/crs/EPSG/0/

This is a optional added by mobilityDCAT-AP, analogue to an addition by [GEODCAT-AP-v2.0.0].

Values from this vocabulary MUST be used as instances of class dct:Standard, being the range of the property dct:conformsTo.

dct:format

dcat:Distribution

EU Authority Table "File Type" [EUV-FT]

http://publications.europa.eu/resource/authority/file-type

This is a mandatory vocabulary "File Type" by the Publications Office of the European Union.

Values from this vocabulary MUST be used as instances of class dct:MediaTypeOrExtent, being the range of the property dct:format.

Please note that mobilityDCAT-AP has different properties related to the format, including mobilitydcatap:mobilityDataStandard, dct:format, cnt:characterEncoding, mobilitydcatap:grammar. This controlled vocabulary relates only to dct:format, i.e., the base standard that specifies syntactically correct documents.

dct:language

dct:language

dct:language

dcat:Catalog

dcat:CatalogRecord

dcat:Dataset

EU Authority Table "language" [EUV-LANG]

http://publications.europa.eu/resource/authority/language

This is a mandatory vocabulary "Language" by the Publications Office of the European Union.

Values from this vocabulary MUST be used as instances of class dct:LinguisticSystem, being the range of the property dct:language.

dct:identifier

dct:LicenseDocument

EU Authority Table "Licence" [EUV-LICENCES]

http://publications.europa.eu/resource/authority/licence

This is an optional vocabulary "Licence" by the Publications Office of the European Union.

dct:publisher

dct:publisher

dct:publisher

dcat:Catalog

dcat:CatalogRecord

dcat:Dataset

EU Authority Table "Corporate body" [EUV-CB]

http://publications.europa.eu/resource/authority/corporate-body

This is a mandatory vocabulary "Corporate body" by the Publications Office of the European Union. It MUST be used for European institutions and a small set of international organisations. In case of other types of organisations, national, regional or local vocabularies about organisations SHOULD be used, if available.

Values from this vocabulary MUST be used as instances of class foaf:Agent, being the range of the property dct:publisher.

dct:spatial

dct:spatial

dcat:Catalog

dcat:Dataset

EU Vocabularies Continents Named Authority List [EUV-CONT], EU Vocabularies Countries Named Authority List [EUV-COUNTRIES], EU Vocabularies Places Named Authority List [EUV-PLACES], [GEONAMES], [NUTS-CODES]

http://publications.europa.eu/resource/authority/continent

http://publications.europa.eu/resource/authority/country

http://publications.europa.eu/resource/authority/place

http://sws.geonames.org/

http://nuts.geovocab.org/

The EU Vocabularies Name Authority Lists must be used for continents, countries and places that are in those lists; if a particular location is not in one of the mentioned Named Authority Lists, [GEONAMES] URIs must be used.

In addition to the Named Authority Lists or [GEONAMES], [NUTS-CODES] URIs MAY be used.

Values from the above-mentioned vocabularies MUST be used as instances of class dct:Location, being the range of the property dct:spatial.

dct:type

foaf:Agent

ADMS publisher type [ADMS-SKOS] vocabulary

http://purl.org/adms/publishertype/

This is an optional vocabulary "Publisher Type", based on the [ADMS] specification.

+mobilitydcatap:georeferencingMethod

dcat:Dataset

+mobilityDCAT-AP Vocabulary "Georeferencing method"

+https://w3id.org/mobilitydcat-ap/georeferencing-method/

This is a mandatory vocabulary created by mobilityDCAT-AP.

+mobilitydcatap:networkCoverage

dcat:Dataset

+mobilityDCAT-AP Vocabulary "Network coverage"

+https://w3id.org/mobilitydcat-ap/network-coverage

This is an optional vocabulary created by mobilityDCAT-AP.

+mobilitydcatap:transportMode

dcat:Dataset

+mobilityDCAT-AP Vocabulary "Transport mode"

+https://w3id.org/mobilitydcat-ap/transport-mode

This is an optional vocabulary created by mobilityDCAT-AP.

+mobilitydcatap:intentedInformationService

dcat:Dataset

+mobilityDCAT-AP Vocabulary "Intended information service"

+https://w3id.org/mobilitydcat-ap/intended-information-service

This is an optional vocabulary created by mobilityDCAT-AP.

+mobilitydcatap:mobilityDataStandard

dcat:Distribution

+mobilityDCAT-AP Vocabulary "Mobility data standard"

+https://w3id.org/mobilitydcat-ap/mobility-data-standard

This is a mandatory vocabulary created by mobilityDCAT-AP.

+mobilitydcatap:grammar

dcat:Distribution

+mobilityDCAT-AP Vocabulary "Grammar"

+https://w3id.org/mobilitydcat-ap/grammar

This is an optional vocabulary created by mobilityDCAT-AP.

+mobilitydcatap:applicationLayerProtocol

dcat:Distribution

+mobilityDCAT-AP Vocabulary "Application layer protocol"

+https://w3id.org/mobilitydcat-ap/application-layer-protocol

This is an optional vocabulary created by mobilityDCAT-AP.

+mobilitydcatap:communicationMethod

dcat:Distribution

+mobilityDCAT-AP Vocabulary "Communication method"

+https://w3id.org/mobilitydcat-ap/communication-method

This is an optional vocabulary created by mobilityDCAT-AP.

+dct:type

dct:RightsStatement

+mobilityDCAT-AP Vocabulary "Conditions for access and usage"

+https://w3id.org/mobilitydcat-ap/conditions-for-access-and-usage

This is an optional vocabulary created by mobilityDCAT-AP.

5.3 Other controlled vocabularies

In [DCAT-AP-v2.0.1], chapter 5.3 and 5.4, several other controlled vocabularies are recommended for consideration, including EuroVoc, CERIF standard vocabularies, the Dewey Decimal Classification and sevaral licence-related vocabularies. For the scope of mobilityDCAT-AP, these other vocabularies have been analysed. However, none of such vocabularies has been found suitable or specific to mobility data portals, so no explicit recommendation for the usage of further vocabularies is given.

Regarding license-related vocabularies, [DCAT-AP-v2.0.1] is referencing to the vocabulary by the Open Digital Rights Language (ODRL) Initiative [VOCAB-ODRL], which seems rather complex for the purpose of mobilityDCAT-AP. Further, it refers to the Open Data Rights Statement (ODRS) Vocabulary [ODRS]. This vocabulary is introducing a central class called odrs:RightsStatement, which is semantically equal to class dct:RightsStatement from [DCAT-AP-v2.0.1]; and reusing some properties from [DCAT-AP-v2.0.1], such as dct:rights. Again, no explicit recommendation for the usage of such license-related vocabularies is given.

6. Conformance

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

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

6.1 Provider requirements

In order to conform to this Application Profile, an application that provides metadata MUST:

For the properties listed in the table in § 5.2 Controlled vocabularies to be used, the associated controlled vocabularies MUST be used. Additional controlled vocabularies MAY be used.

In addition to the mandatory properties, any of the recommended and optional properties defined in § 4. Application Profile Properties per Class MAY be provided.

Recommended and optional classes may have mandatory properties, but those only apply if and when an instance of such a class is present in a description.

6.2 Receiver requirements

In order to conform to this Application Profile, an application that receives metadata MUST be able to:

As stated in § 2. Terminology used in the Application Profile, "processing" means that receivers must accept incoming data and transparently provide this data to applications and services. It does neither imply nor prescribe what applications and services finally do with the data (parse, convert, store, make searchable, display to users, etc.).

7. Agent Types, Agent Roles and Contact Information

This section is non-normative.

[DCAT-AP-v2.0.1] has the following note about agent roles:

The DCAT Application Profile [...] has a single property to relate an Agent (typically, an organisation) to a Dataset. The only such ‘agent role’ that can be expressed in the current version of the profile is through the property dct:publisher (http://purl.org/dc/terms/publisher), defined as “An entity responsible for making the dataset available”. A second property is available in the DCAT recommendation, dcat:contactPoint (http://www.w3.org/TR/vocab-dcat/#Property:dataset_contactPoint), defined as “Link a dataset to relevant contact information which is provided using VCard”, but this is not an agent role as the value of this property is contact data, rather than a representation of the organisation as such.

In specific cases, for example in exchanging data among domain-specific portals, it may be useful to express other, more specific agent roles. In such cases, extensions to the base profile may be defined using additional properties with more specific meanings. ...

mobilityDCAT-AP specifies this note as follows:

According to [FOAF], an Agent (via class foaf:Agent) may be of a type of a person (via sub-class foaf:Person), an organisation (via sub-class foaf:Organization), or a group (via sub-class foaf:Group).

For mobility data portals, it is expected that organisations are the main data actors, so the type organisation SHOULD be used. A person MAY be explicitly mentioned as an agent. In this case, he or she SHOULD be attributed to an organisation via the property org:memberOf, and, additionally, attributed with the personal name via properties foaf:firstName and foaf:surname.

mobilityDCAT-AP uses the class foaf:Agent in the context of describing entities:

Thus, two different agent-role properties are used: Publisher for classes Catalogue (dct:publisher), Catalogue Record (dct:publisher), and Dataset (dct:publisher); and Rights Holder for class Dataset (dct:rightsHolder). In contrast, other agent-role properties such as dct:creator are not used.

Figure 5 shows how the potential usages of foaf:Agent are represented in a UML diagram.

mobilityDCAT-AP UML Class Diagram with Agent
Figure 5 Excerpt of mobilityDCAT-AP UML Class Diagram with focus on agent-role properties

The class foaf:Agent is used to identify the entity with the above-mentioned roles. The properties under the class foaf:Agent also allow for providing (optional) contact details.

There is one further, recommended property dct:type describing the agent's type via a controlled vocabulary. This property MAY be used to determine, among others, the hierarchy of a public authority (local, regional, national, supranational). Such organisation types are often data providers at mobility data portals, so much information is seen beneficial. However, the controlled vocabulary from [ADMS-SKOS], as proposed by [DCAT-AP-v2.0.1], is not sufficient in the mobility context. Thus, further items are added by mobilityDCAT-AP to the controlled vocabulary, see § 5.2 Controlled vocabularies to be used.

In contrast, contact details with the goal to establish a direct contact between a data provider and a data user SHOULD be provided via the property dcat:contactPoint under class dcat:Dataset.

The range of dcat:contactPoint is the class vcard:Kind. A couple of properties for this class are defined, specifying contact information. Of these properties, vcard:fn and vcard:hasEmail are mandatory. The usage note of dcat:contactPoint gives more details on how to handle such contact information.

With such concept, there might be overlaps of the contact information under the properties dct:publisher and dcat:contactPoint. Depending on the portal system, the contact information can be populated to the data portal's user registry (in case, e.g., users are required to sign in before they use the data portal and/or from a dataset-specific contact information. A recommended way is to populate all information for dct:publisher automatically from the user's registry, and to allow an optional field "contact information" (name and email) when entering dataset-specific metadata, which can be freely entered be the metadata publisher. If such optional field is not entered (or not implemented), the user registry can still be retrieved.

8. Accessibility and Multilingual Aspects

This section is non-normative.

Accessibility in the context of this Application Profile is limited to information about the technical format of distributions of datasets. The properties dcat:mediaType and dct:format provide information that can be used to determine what software can be deployed to process the data. The accessibility of the data within the datasets needs to be taken care of by the software that processes the data and is outside of the scope of this Application Profile.

Multilingual aspects related to this Application Profile concern all properties whose contents are expressed as strings (i.e. rdfs:Literal) with human-readable text. Wherever such properties are used, the string values are of one of two types:

Wherever values of properties are expressed with either type of string, the property can be repeated with translations in the case of free text and with parallel versions in case of named entities. For free text, e.g. in the cases of titles, descriptions and keywords, the language tag is mandatory.

Language tags to be used with rdfs:Literal are defined by [BCP47], which allows the use of the "t" extension for text transformations defined in [RFC6497] with the field "t0" [CLDR] indicating a machine translation.

A language tag will look like: "en-t-es-t0-abcd", which conveys the information that the string is in English, translated from Spanish by machine translation using a tool named "abcd".

For named entities, the language tag is optional and should only be provided if the parallel version of the name is strictly associated with a particular language. For example, the name ‘European Union’ has parallel versions in all official languages of the union, while a name like ‘W3C’ is not associated with a particular language and has no parallel versions.

For linking to different language versions of associated web pages (e.g. landing pages) or documentation, a content negotiation [CONNEG] mechanism may be used whereby different content is served based on the Accept-Languages indicated by the browser. Using such a mechanism, the link to the page or document can resolve to different language versions of the page or document.

All the occurrences of the property dct:language, which can be repeated if the metadata is provided in multiple languages, must have a URI as their object, not a literal string from the [ISO-639] code list.

How multilingual information is handled in systems, for example in indexing and user interfaces, is outside of the scope of this Application Profile.

9. Privacy and security considerations

The mobilityDCAT-AP vocabulary supports the attribution of data and metadata to various participants such as resource creators, publishers and other parties or agents, and as such defines terms that may be related to personal information. In addition, it also supports the association of rights and licenses with catalogued Resources and Distributions. These rights and licenses could potentially include or reference sensitive information such as user and asset identifiers as described in [VOCAB-ODRL].

Implementations that produce, maintain, publish or consume such vocabulary terms must take steps to ensure security and privacy considerations are addressed at the application level.

10. Acknowledgements

This work was elaborated by the NAPCORE Sub-Working Group (SWG) 4.4 [NAPCORE-Metadata-Working-Group].

Editors of ReSpec documentation:

Reviewers of ReSpec documentation and contributors to preparatory activities:

Other contributors and followers:

A. Quick Reference of Classes and Properties

A.1 All classes and Properties

Class Class URI Mandatory prop. Recommended prop. Optional prop.
+Address (Agent) locn:Address

+locn:adminUnitL1

+locn:adminUnitL2

+locn:postCode

+locn:postName

+locn:thoroughfare

Agent foaf:Agent

+foaf:mbox

foaf:name

+foaf:workplaceHomepage

dct:type

+locn:address

+org:memberOf

+foaf:firstName

+foaf:phone

+foaf:surname

+Assessment mobilitydcatap:Assessment

+dct:issued

+oa:hasBody

Catalogue dcat:Catalog

dcat:dataset

dct:description

foaf:homepage

dct:publisher

dcat:record

dct:spatial

dct:title

dct:language

dct:license

dct:issued

dcat:themeTaxonomy

dct:modified

dct:hasPart

+dct:identifier

dct:isPartOf

+adms:identifier

Catalogue Record dcat:CatalogRecord

+dct:created

dct:language

foaf:primaryTopic

dct:modified

+dct:publisher

Category skos:Concept

skos:prefLabel

+skos:inScheme

Category scheme skos:ConceptScheme

dct:title

Checksum spdx:Checksum

spdx:algorithm

spdx:checksumValue

Data Service dcat:DataService

dcat:endpointURL

dct:title

dcat:endpointDescription

dcat:servesDataset

dct:accessRights

dct:description

dct:license

Dataset dcat:Dataset

dct:description

dcat:distribution

dct:accrualPeriodicity

+mobilitydcatap:mobilityTheme

dct:spatial

dct:title

dct:publisher

+mobilitydcatap:georeferencingMethod

dcat:contactPoint

dcat:keyword

+mobilitydcatap:networkCoverage

+dct:conformsTo

+dct:rightsHolder

dct:temporal

dcat:theme

+mobilitydcatap:transportMode

+dcatap:applicableLegislation

+mobilitydcatap:assessmentResult

dct:hasVersion

dct:identifier

+mobilitydcatap:intendedInformationService

dct:isReferencedBy

dct:isVersionOf

dct:language

adms:identifier

dct:relation

dct:issued

dct:modified

owl:versionInfo

adms:versionNotes

+dqv:hasQualityAnnotation

Distribution dcat:Distribution

dcat:accessURL

+mobilitydcatap:mobilityDataStandard

dct:format

dct:rights

+mobilitydcatap:applicationLayerProtocol

dct:description

dct:license

dcat:accessService

+cnt:characterEncoding

+mobilitydcatap:communicationMethod

+mobilitydcatap:dataFormatNotes

dcat:downloadURL

+mobilitydcatap:grammar

+adms:sample

+dct:temporal

Document foaf:Document
Frequency dct:Frequency
Identifier adms:Identifier

skos:notation

Kind vcard:Kind

+vcard:hasEmail

+vcard:fn

+vcard:hasURL

+vcard:hasAddress

+vcard:organization-name

+vcard:hasTelephone

Licence Document dct:LicenseDocument

+dct:identifier

+rdfs:label

Linguistic system dct:LinguisticSystem
Literal rdfs:Literal
Location dct:Location

+skos:inScheme

+dct:identifier

dcat:bbox

dcat:centroid

+skos:prefLabel

locn:geometry

+Mobility Data Standard mobilitydcatap:MobilityDataStandard

+owl:versionInfo

+mobilitydcatap:schema

Period of time dct:PeriodOfTime

dcat:endDate

dcat:startDate

Provenance Statement dct:ProvenanceStatement
Publisher type skos:Concept
+Quality Annotation dqv:QualityAnnotation

+oa:hasBody

+oa:hasTarget

Relationship dcat:Relationship

dcat:hadRole

dct:relation

Resource rdfs:Resource
Rights statement dct:RightsStatement

+dct:type

+rdfs:label

Role dcat:Role
Standard dct:Standard
Status skos:Concept

A.2 Classes and properties added by mobilityDCAT-AP

This version of mobilityDCAT-AP extends [DCAT-AP-v2.0.1] with 2 additional classes and 48 additional properties (some of which re-used across classes). They are listed in the following table.

Class Class URI Mandatory prop. Recommended prop. Optional prop.
+Address (Agent) locn:Address

+locn:adminUnitL1

+locn:adminUnitL2

+locn:postCode

+locn:postName

+locn:thoroughfare

Agent foaf:Agent

+foaf:mbox

+foaf:workplaceHomepage

+foaf:phone

+locn:address

+org:memberOf

+foaf:firstName

+foaf:surname

+Assessment mobilitydcatap:Assessment

+dct:issued

+oa:hasBody

Catalogue dcat:Catalog

+dct:identifier

+adms:identifier

Catalogue Record dcat:CatalogRecord

+dct:created

+dct:publisher

Category skos:Concept

+skos:inScheme

Dataset dcat:Dataset

+mobilitydcatap:mobilityTheme

+mobilitydcatap:georeferencingMethod

+dct:conformsTo

+dct:rightsHolder

+mobilitydcatap:networkCoverage

+mobilitydcatap:transportMode

+dcatap:applicableLegislation

+mobilitydcatap:assessmentResult

+mobilitydcatap:intendedInformationService

+dqv:hasQualityAnnotation

Distribution dcat:Distribution

+mobilitydcatap:mobilityDataStandard

+mobilitydcatap:applicationLayerProtocol

+mobilitydcatap:communicationMethod

+mobilitydcatap:dataFormatNotes

+mobilitydcatap:grammar

+adms:sample

+dct:temporal

+cnt:characterEncoding

Kind vcard:Kind

+vcard:hasEmail

+vcard:fn

+vcard:hasURL

+vcard:hasAddress

+vcard:organization-name

+vcard:hasTelephone

Licence Document dct:LicenseDocument

+dct:identifier

+rdfs:label

Location dct:Location

+skos:inScheme

+dct:identifier

+skos:prefLabel

+Mobility Data Standard mobilitydcatap:MobilityDataStandard

+owl:versionInfo

+mobilitydcatap:schema

+Quality Annotation dqv:QualityAnnotation

+oa:hasBody

+oa:hasTarget

Rights statement dct:RightsStatement

+dct:type

+rdfs:label

B. Mapping to Coordinated Metadata Catalogue (CMC)

A previous European activity to harmonise metadata at National Access Point was the Coordinated Metadata Catalogue (CMC) [EU-EIP-CMC].) This Catalogue describes a common minimum metadata set for NAP. The most recent version from 2019 contains definitions for 32 Metadata elements, including their description, types and obligation levels. These definitions are in a proprietary, human-readable format only.

The following mapping table has been prepared to show how the Metadata elements from the original Coordinated Metadata Catalogue compare to the classes and properties of mobilityDCAT-AP.

Please note that some CMC elements are mapped to 2 properties of mobilityDCAT-AP, due to semantic ambiguities of some CMC elements. When mapping such elements, the correct semantics need to be considered.

CMC section

CMC element name

Class

Class URI

Property

Property URI

2.2.1.1

Metadata date

Catalogue Record dcat:CatalogRecord

creation date

update / modification date

dct:created

dct:modified

2.2.1.2

Metadata language

Catalogue Record dcat:CatalogRecord

language

dct:language

2.2.1.3

Metadata point of contact

Catalogue Record

Dataset

dcat:CatalogRecord

dcat:Dataset

publisher

contact point

dct:publisher

dcat:contactPoint

2.2.2.1

Name of dataset

Dataset dcat:Dataset

title

dct:title

2.2.2.2

Description of dataset

Dataset dcat:Dataset

description

dct:description

2.2.2.3

Resource Type

Not used in mobilityDCAT-AP.

2.2.2.4

Dataset type category

Dataset dcat:Dataset

theme / category

mobilitydcatap:mobilityTheme

2.2.2.5

Dataset detailed type

Dataset dcat:Dataset

theme / category

mobilitydcatap:mobilityTheme

2.2.2.6

Service type category

Dataset dcat:Dataset

theme / category

mobilitydcatap:intentedInformationService

2.2.2.7

Dataset language

Dataset dcat:Dataset

language

dct:language

2.2.2.8

Georeferencing method

Dataset dcat:Dataset

reference system

georeferencing method

+dct:conformsTo

+mobilitydcatap:georeferencingMethod

2.2.3.1

Valid from

Dataset

Distribution

dcat:Dataset

dcat:Distribution

temporal coverage

temporal coverage

dct:temporal

dct:temporal

2.2.3.2

Valid to

Dataset

Distribution

dcat:Dataset

dcat:Distribution

temporal coverage

temporal coverage

dct:temporal

dct:temporal

2.2.4.1

Area covered by publication

Dataset dcat:Dataset

spatial / geographic coverage

dct:spatial

2.2.4.2

Network coverage

Dataset dcat:Dataset

spatial / geographic coverage

mobilitydcatap:networkCoverage

2.2.4.3

Network coverage description

Not used in mobilityDCAT-AP.

2.2.5.1

Transportation modes covered

Dataset dcat:Dataset

transportation mode

mobilitydcatap:transportMode

2.2.6.1

Publisher

Dataset dcat:Dataset

publisher

dct:publisher

2.2.6.2

Data owner

Dataset dcat:Dataset

rights holder

+dct:rightsHolder

2.2.7.1

Contract or licence

Distribution dcat:Distribution

rights

dct:rights

2.2.7.2

Condition for use

Distribution dcat:Distribution

licence

dct:license

2.2.8.1

Data Format- Encoding

Distribution dcat:Distribution

character encoding

+cnt:characterEncoding

2.2.8.2

Data Format- Syntax

Distribution dcat:Distribution

format

dct:format

2.2.8.3

Data Format- Grammar

Distribution dcat:Distribution

grammar

mobilitydcatap:grammar

2.2.8.4

Data Format- Data Model

Distribution dcat:Distribution

mobility data standard

mobilitydcatap:mobilityDataStandard

2.2.8.5

Data format description

Distribution dcat:Distribution

data format notes

mobilitydcatap:dataFormatNotes

2.2.8.6

Access interface / application layer protocol

Distribution dcat:Distribution

application layer protocol

mobilitydcatap:applicationLayerProtocol

2.2.8.7

Communication method

Distribution dcat:Distribution

communication method

mobilitydcatap:communicationMethod

2.2.8.8

Access URL

Distribution dcat:Distribution

access URL

download URL

dcat:accessURL

dcat:downloadURL

2.2.9.1

Update frequency

Dataset dcat:Dataset

frequency

dct:accrualPeriodicity

2.2.9.2

Quality Description

Dataset dcat:Dataset

quality description

dqv:hasQualityAnnotation

2.2.9.3

National Body assessment status

Dataset dcat:Dataset

assessment result

mobilitydcatap:assessmentResult

C. mobilityDCAT-AP minimum profile

A minimum profile describes a minimum population of mobilityDCAT-AP-compliant metadata descriptions. Such minimum population can be derived from the following documents throughout this specification:

D. mobilityDCAT-AP example populations

To show how mobilityDCAT-AP can be deployed in practice, some example files have been produced. These denote how metadata descriptions can be populated using the mobilityDCAT-AP data vocabulary.

The first example is related to a real-life NAP data offering from the Swedish NAP. See the corresponding human-readable metadata description on the NAP portal.

The Swedish NAP also provides machine-readable representations of its metadata records in a proprietary DCAT-AP dialect, see the RDF/XML file for the example above.

This RDF/XML was converted into a metadata description according to the mobilityDCAT-AP v1.0.1 specification. It is fullfilling all mandatory and some recommended and optional elements from mobilityDCAT-AP v1.0.1. Within the RDF/XML example file, several comments are given regarding the original RDF/XML as follows:

The above RDF/XML example population was further formatted as a TTL file. Lastly, a reduced example population is provided, only considering mandatory elements from mobilityDCAT-AP v1.0.1.

Altogether, the following files are provided as example population:

These files can be retrieved in the examples directory on the GitHub repository.

Further example populations, also looking at real-life data offerings on other NAPS, will be provided in the future.

E. mobilityDCAT-AP Wikipage

As an addition to this specification, a "mobilityDCAT-AP Wiki" has been published. This serves as a practical orientation for users of mobilityDCAT-AP. In particular, it guides deployers (e.g., developers and operators of NAPs and data platforms) in the implementation phasis of mobilityDCAT-AP​. This includes additional explanations and examples for specific vocabulary elements, recommendations for metadata handling and exposure on individual IT systems, as well as advice on metadata quality and validation processes.

The Wiki page can be retrieved in the Wiki section of the GitHub repository

F. Change Log

A full change-log is available on GitHub

F.1 Changes since mobilityDCAT-AP 1.0.0 (16 October 2023)

F.2 Starting point of mobilityDCAT-AP 1.0.0 (01 January 2023)

F.3 Summary of changes to Application Profile classes and properties

Since this is the initial release of mobilityDCAT-AP, there are no changes yet.

G. References

G.1 Normative references

[ADMS]
Joinup. Asset Description Metadata Schema (ADMS). European Commission. URL: https://joinup.ec.europa.eu/solution/asset-description-metadata-schema-adms
[ADMS-SKOS]
Joinup. ADMS Controlled Vocabularies. European Commission. URL: https://raw.githubusercontent.com/SEMICeu/ADMS-AP/master/purl.org/ADMS_SKOS_v1.00.rdf
[BCP47]
Tags for Identifying Languages. A. Phillips, Ed.; M. Davis, Ed.. IETF. September 2009. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc5646
[CNT]
Representing Content in RDF. 2 February 2017. URL: https://www.w3.org/TR/Content-in-RDF/
[CORE-LOCATION-VOCABULARY]
ISA Programme Location Core Vocabulary. 23 March 2015. URL: https://www.w3.org/TR/Content-in-RDF/
[CORE-ORGANIZATION-ONTOLOGY]
Core organization ontology. 16 January 2014. URL: https://www.w3.org/TR/vocab-org/
[DCAT-AP]
DCAT Application Profile for data portals in Europe. Version 2.0.1. European Commission. 8 June 2020. URL: https://joinup.ec.europa.eu/solution/dcat-application-profile-data-portals-europe
[DCAT-AP-guideline-spatial]
How should dct:spatial and dct:Location be used?. European Commission. URL: https://joinup.ec.europa.eu/release/how-should-dctspatial-and-dctlocation-be-used
[DCAT-AP-HVD]
Usage guidelines of DCAT-AP for High-Value Datasets. European Commission. 19 June 2023. URL: https://semiceu.github.io/DCAT-AP/releases/2.2.0-hvd/
[DCAT-AP-v2.0.1]
DCAT Application Profile for data portals in Europe. Version 2.0.1.. European Commission. 08 June 2020. URL: https://joinup.ec.europa.eu/collection/semantic-interoperability-community-semic/solution/dcat-application-profile-data-portals-europe/release/201-0
[DCAT-AP-v2.1.0-Guideline-Dataservices]
DCAT-AP Usage guide on Datasets, Distributions and Data Services. European Commission. URL: https://github.com/SEMICeu/DCAT-AP/blob/2.1.0-draft/releases/2.1.0/usageguide-dataset-distribution-dataservice.md
[DCTERMS]
DCMI Metadata Terms. DCMI Usage Board. DCMI. 20 January 2020. DCMI Recommendation. URL: https://www.dublincore.org/specifications/dublin-core/dcmi-terms/
[DWBP]
Data on the Web Best Practices. Bernadette Farias Loscio; Caroline Burle; Newton Calegari. W3C. 31 January 2017. W3C Recommendation. URL: https://www.w3.org/TR/dwbp/
[EC-MMTIS-DR]
Commission Delegated Regulation (EU) 2017/1926 of 31 May 2017 supplementing Directive 2010/40/EU of the European Parliament and of the Council with regard to the provision of EU-wide multimodal travel information services (Text with EEA relevance.). European Commission. URL: https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A32017R1926
[ELI]
European Legislation Identifier (ELI) system. EU Publications Office. URL: https://eur-lex.europa.eu/eli-register/eu_publications_office.html
[EU-EIP-CMC]
Information about the Coordinated Metadata Catalogue (CMC) by EU EIP. EU EIP Consortium. URL: https://www.its-platform.eu/achievement/monitoring-harmonisation-of-naps/
[EU-EIP-QP]
Information about the Quality Frameworks by EU EIP. EU EIP Consortium. URL: https://www.its-platform.eu/achievement/quality-of-european-its-services-and-their-data/
[EU-TEN-T]
Information about Trans-European Transport Network (TEN-T). European Commission. URL: https://transport.ec.europa.eu/transport-themes/infrastructure-and-investment/trans-european-transport-network-ten-t_en
[EUV-AR]
Named Authority List: Access rights. Publications Office of the European Union. URL: https://publications.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/access-right
[EUV-CB]
Named Authority List: Corporate bodies. Publications Office of the European Union. URL: https://publications.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/corporate-body
[EUV-CONT]
Named Authority List: Continents. Publications Office of the European Union. URL: https://publications.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/continent
[EUV-COUNTRIES]
Named Authority List: Countries. Publications Office of the European Union. URL: https://publications.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/country
[EUV-FREQ]
Named Authority List: Frequencies. Publications Office of the European Union. URL: https://publications.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/frequency
[EUV-FT]
Named Authority List: File types. Publications Office of the European Union. URL: https://publications.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/file-type
[EUV-LANG]
Named Authority List: Languages. Publications Office of the European Union. URL: https://publications.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/language
[EUV-LICENCES]
Named Authority List: Licences. Publications Office of the European Union. URL: https://publications.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/licence
[EUV-PLACES]
Named Authority List: Places. Publications Office of the European Union. URL: https://publications.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/place
[EUV-THEMES]
Named Authority List: Data Themes. Publications Office of the European Union. URL: https://publications.europa.eu/en/web/eu-vocabularies/at-dataset/-/resource/dataset/data-theme
[EUV-THEMES-TRANSPORT]
Named Authority List: Data Themes - Label: Transport . Publications Office of the European Union. URL: https://op.europa.eu/en/web/eu-vocabularies/concept/-/resource?uri=http://publications.europa.eu/resource/authority/data-theme/TRAN
[FOAF]
FOAF Vocabulary Specification 0.99 (Paddington Edition). Dan Brickley; Libby Miller. FOAF project. 14 January 2014. URL: http://xmlns.com/foaf/spec
[GEODCAT-AP-v2.0.0]
GeoDCAT-AP - Version 2.0.0. European Commission. 23 December 2020. URL: https://semiceu.github.io/GeoDCAT-AP/releases/
[GEONAMES]
Geonames. URL: http://geonames.org/
[IANA-CHARACTER-SETS]
Character Sets. IANA. URL: https://www.iana.org/assignments/character-sets
[IANA-MEDIA-TYPES]
Media Types. IANA. URL: https://www.iana.org/assignments/media-types/
[INSPIRE-LPA]
INSPIRE Registry: Limitations on public access. European Commission. URL: http://inspire.ec.europa.eu/metadata-codelist/LimitationsOnPublicAccess
[LOCN]
ISA Programme Location Core Vocabulary. Andrea Perego; Michael Lutz. European Commission. 23 March 2015. Second version in w3.org/ns space. URL: http://www.w3.org/ns/locn
[NAPCORE-Metadata-Working-Group]
Information about the NAPCORE Sub-Working Group on Metadata. NAPCORE Consortium. URL: https://napcore.eu/metadata/
[NAPCORE-NAPs]
NAPCORE information about National Access Points (NAPs). NAPCORE Consortium. URL: https://napcore.eu/description-naps/
[NAPCORE-NB]
NAPCORE information about National Bodies (NAPs). NAPCORE Consortium. URL: https://napcore.eu/national-bodies/
[NUTS-CODES]
EU NUTS classification as Linked Data. NUTS-RDF project. URL: http://nuts.geovocab.org/
[ODRS]
Open Data Rights Statement Vocabulary. Leigh Dodds. ODI. 29 July 2013. URL: http://schema.theodi.org/odrs
[OGC-EPSG]
EPSG CRS Register. OGC. URL: http://www.opengis.net/def/crs/EPSG/
[OWL-REF]
OWL Web Ontology Language Reference. Mike Dean; Guus Schreiber. W3C. 10 February 2004. W3C Recommendation. URL: https://www.w3.org/TR/owl-ref/
[RDF-SCHEMA]
RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/
[RDF11-CONCEPTS]
RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC3966]
The tel URI for Telephone Numbers. H. Schulzrinne. IETF. December 2004. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc3966
[RFC6068]
The 'mailto' URI Scheme. M. Duerst; L. Masinter; J. Zawinski. IETF. October 2010. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc6068
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[SEMVER]
Semantic Versioning Specification (SemVer). URL: https://semver.org/
[SKOS-REFERENCE]
SKOS Simple Knowledge Organization System Reference. Alistair Miles; Sean Bechhofer. W3C. 18 August 2009. W3C Recommendation. URL: https://www.w3.org/TR/skos-reference/
[SPDX]
SPDX 2.2. SPDX. URL: http://spdx.org/rdf/terms#
[VCARD-RDF]
vCard Ontology - for describing People and Organizations. Renato Iannella; James McKinney. W3C. 22 May 2014. W3C Note. URL: https://www.w3.org/TR/vcard-rdf/
[VOCAB-ADMS]
Asset Description Metadata Schema (ADMS). Phil Archer; Gofran Shukair. W3C. 1 August 2013. W3C Note. URL: https://www.w3.org/TR/vocab-adms/
[VOCAB-DCAT-2]
Data Catalog Vocabulary (DCAT) - Version 2. Riccardo Albertoni; David Browning; Simon Cox; Alejandra Gonzalez Beltran; Andrea Perego; Peter Winstanley. W3C. 4 February 2020. W3C Recommendation. URL: https://www.w3.org/TR/vocab-dcat-2/
[VOCAB-DQV]
Data on the Web Best Practices: Data Quality Vocabulary. Riccardo Albertoni; Antoine Isaac. W3C. 15 December 2016. W3C Note. URL: https://www.w3.org/TR/vocab-dqv/
[VOCAB-ODRL]
ODRL Vocabulary & Expression 2.2. Renato Iannella; Michael Steidl; Stuart Myles; Víctor Rodríguez-Doncel. W3C. 15 February 2018. W3C Recommendation. URL: https://www.w3.org/TR/odrl-vocab/
[VOCAB-ORG]
The Organization Ontology. Dave Reynolds. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/vocab-org/
[Web-Annotation-Data-Model]
Web Annotation Data Model. W3C. 23 February 2017. URL: https://www.w3.org/TR/annotation-model/
[WEB-ANOTATION-ONTOLOGY]
Web Annotation Ontology. 23 February 2017. URL: https://www.w3.org/TR/annotation-vocab/
[XMLSCHEMA11-2]
W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. W3C. 5 April 2012. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema11-2/

G.2 Informative references

[CLDR]
CLDR - Unicode Common Locale Data Repository. BCP47, transform_mt.xml. UNICODE Consortium. URL: http://unicode.org/cldr/trac/browser/trunk/common/bcp47/transform_mt.xml
[CONNEG]
Apache Web Server: content negotiation. Apache Foundation. URL: http://httpd.apache.org/docs/current/content-negotiation.html
[DataCite]
DataCite Metadata Schema. DataCite Metadata Working Group. DataCite e.V. 22 January 2024. URL: https://schema.datacite.org/
[DataCite-RIS]
DataCite Resource Identifier Scheme. URL: http://purl.org/spar/datacite/ResourceIdentifierScheme
[DCAT-AP-EG]
Joinup. DCAT-AP Implementation Guidelines: How to extend DCAT-AP?. European Commission. URL: https://joinup.ec.europa.eu/release/dcat-ap-how-extend-dcat-ap
[DOI]
Digital Object Identifier. DOI. URL: http://www.doi.org/
[DXWG]
Dataset Exchange Working Group (DXWG). W3C. URL: https://www.w3.org/2017/dxwg/
[EC-ITS-Directive]
Directive 2010/40/EU of the European Parliament and of the Council of 7 July 2010 on the framework for the deployment of Intelligent Transport Systems in the field of road transport and for interfaces with other modes of transport Text with EEA relevance. European Commission. URL: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32010L0040
[EZID]
EZID. URL: http://n2t.net/ezid
[GLD]
Government Linked Data (GLD) Working Group. W3C. URL: https://www.w3.org/2011/gld/
[ISO-639]
Code for the representation of names of languages. ISO/TC 37/SC 2. ISO. 1988. International Standard. URL: https://www.iso.org/standard/4766.html
[MAST-ADS]
Referencing Data Sets in Astronomical Literature. Mikulski Archive for Space Telescopes (MAST). URL: http://archive.stsci.edu/pub_dsn.html
[NAPCORE]
Website of the NAPCORE project. NAPCORE Consortium. URL: https://napcore.eu/
[NAPCORE-Metadata-preparatory-activities]
Documentation about preparatory activities for mobilityDCAT-AP. NAPCORE Consortium. URL: https://napcore.eu/providing-a-baseline-for-a-new-metadata-scheme-for-european-naps/
[RFC6497]
BCP 47 Extension T - Transformed Content. M. Davis; A. Phillips; Y. Umaoka; C. Falk. IETF. February 2012. Informational. URL: https://www.rfc-editor.org/rfc/rfc6497
[W3ID]
Permanent Identifiers for the Web. W3C Permanent Identifier Community Group. URL: https://w3id.org/