mobilityDCAT-AP - Version 3.0.0

This document presents version 3.0.0 of the specification for mobilityDCAT-AP, a mobility-related extension of the "DCAT Application profile for data portals in Europe" ([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-v3.0.1] specification, while extending and customizing it for the mobility sector.

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-Information-about-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. 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, the [NAPCORE-Metadata-Working-Group] has developed a formal metadata specification called mobilityDCAT-AP.

mobilityDCAT-AP enables harmonised, platform-independent metadata descriptions in the mobility domain 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), mobilityDCAT-AP leverages semantic technologies, enabling advanced querying and inference capabilities based on metadata.

mobilityDCAT-AP provides precise and unambiguous metadata designations for any data offering with mobility relevance, e.g., to represent 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.

mobilityDCAT-AP is compatible with the parallel specifications [DCAT-AP-v3.0.1] and [GeoDCAT-AP-v3.0.0].

This work has been carried out in the context of Task 4.4 of the [NAPCORE] project. NAPCORE is an EU-cofunded Programme Support Action under the GRANT AGREEMENT No 101234721-25-EU-TG-NAPCORE-X.

mobilityDCAT-AP is designed as an extension of [DCAT-AP-v3.0.1] in conformance with the [DCAT-AP-Implementation-Guidelines], the [SEMIC-Style-Guide-for-Semantic-Engineers] and the [DCAT-AP-Reuse-Guidelines].

The scope description of [DCAT-AP-v3.0.1] is also valid for this version of mobilityDCAT-AP. In particular, the purpose of this specification 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. Further, this specification, 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.

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 v3.0.0 to [DCAT-AP-v3.0.1], the following edits have been made:

Addition of classes, including reusage of classes from [GeoDCAT-AP-v3.0.0], and the creation of new classes under the mobilityDCAT-AP namespace
Non-usage of optional classes from [DCAT-AP-v3.0.1], see A.3 Classes and properties not used from DCAT-AP
Addition of properties to existing classes in [DCAT-AP-v3.0.1], including reusage of properties from [GeoDCAT-AP-v3.0.0], and the creation of new properties under the mobilityDCAT-AP namespace
Change to obligation levels for some existing properties in [DCAT-AP-v3.0.1]
Non-usage of optional properties from [DCAT-AP-v3.0.1], see A.3 Classes and properties not used from DCAT-AP
Refinement of usage notes for existing classes and properties from [DCAT-AP-v3.0.1]
Reference to additional controlled vocabularies, including the creation of new controlled vocabularies under the mobilityDCAT-AP namespace

Some of the class and property additions align with the parallel DCAT-AP extension [GeoDCAT-AP-v3.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.

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

These edits aim to capture some specific characteristics and features of mobility data, when exposed on NAPs and mobility data portals. Thus, they are meant to provide a DCAT-AP-conformant representation of metadata specific to mobility data.

The revision history of the mobilityDCAT-AP specification is documented in the table below.

Version	Date	Description	Action	Change Log
3.0.0	19/10/2026	Major semantic release	Publication	I.1 Changes since [mobilityDCAT-AP-v1.1.0] (17 January 2025)
1.1.0	17/01/2025	Minor semantic release	Publication	I.2 Changes since mobilityDCAT-AP 1.0.1 (04 April 2024)
1.0.1	04/04/2024	Bug fix release	Publication	I.3 Changes since mobilityDCAT-AP 1.0.0 (16 October 2023)
1.0.0	16/10/2023	Recommendation	Publication	I.4 Starting point of mobilityDCAT-AP 1.0.0 (01 January 2023)
0.1	11/05/2023	First Public Working Draft	Creation	N/A

This version is published as a NAPCORE Recommendation.

Information about the process and the decisions involved in the creation of this specification are consultable at the Changelog - see I. Change Log.

In order to conform to mobilityDCAT-AP, an application that provides metadata must:

Provide a description of the Catalogue (i.e., a concrete mobility data portal), including at least the mandatory properties specified for the class dcat:Catalog.
Provide descriptions of the Catalogue Records in the Catalogue, including at least the mandatory properties specified for the class dcat:CatalogRecord.
Provide descriptions of Datasets in the Catalogue, including at least the mandatory properties specified for the class dcat:Dataset.
Provide descriptions of Distributions of Datasets in the Catalogue, including at least the mandatory properties specified for the class dcat:Distribution.
Provide descriptions of persons or organisations involved in the descriptions of the Catalogue, Catalogue Records, Datasets, and Dataset Series, including at least the mandatory properties for the class foaf:Agent.
Provide other mandatory properties defined for classes that are used as ranges of properties of the above-mentioned classes.
Apply the publication requirements for the controlled vocabularies as mentioned in section 10. Controlled Vocabularies.

In addition to the mandatory properties, any of the optional properties defined in mobilityDCAT-AP may be provided.

All properties are specified in the sections 7. Main entities and 8. Supportive entities, and also summarised in section A. Quick Reference of Classes and Properties.

For the properties listed in the tables in section 10.2 Applied controlled vocabularies, the associated controlled vocabularies must be used according to the usage expectation of each category: a closed value space (10.2.1 Properties with controlled vocabularies that MUST be used for the listed properties), at least one value from the vocabulary with other values tolerated (10.2.2 Properties with AT LEAST 1 value from the controlled vocabularies), or a recommended use with other values tolerated (10.2.3 Properties with a RECOMMENDED use of controlled vocabularies).

In order to conform to mobilityDCAT-AP, an application that receives metadata must be able to:

Process information for all classes and properties defined in mobilityDCAT-AP. These classes and properties are specified in the sections 7. Main entities and 8. Supportive entities, and also summarised in section A. Quick Reference of Classes and Properties.
Process information for all controlled vocabularies specified in section 10. Controlled Vocabularies.

To "process" 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.).

mobilityDCAT-AP builds on core RDF definitions and familiarity with these concepts is assumed in this document. An introduction to the main concepts can be found in the [RDF-Primer].

mobilityDCAT-AP follows the terminology defined in the [SEMIC-Style-Guide-for-Semantic-Engineers]. Key concepts are reported below.

An Application Profile is a specification that reuses 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. Application refers to the usage context of the specification. It may cover a data theme such as mobility data with mobilityDCAT-AP. It also may refer to specific tools like open data portals. For DCAT-AP the usage scope is broad and in the first place taking into account the European legal context.

An Extension is further specifying a given Application Profile like DCAT-AP. Many groups, who are interested in sharing Datasets related to very specific application domains, or within a certain European country, found the need to define application profiles that are more specific than DCAT-AP. As a result, there exist a number of DCAT-AP extensions (or synonymously derivatives). mobilityDCAT-AP is such an extension for the mobility domain.

Part of the following text has been reused from [DCAT-AP-v3.0.1] and the [NAPCORE-Information-about-NAPs].

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. This data collection might be published in parallel in DATEX II and APDS formats.

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, a synonym to a data portal is a National Access Point (NAP), which is "a node in which ITS-related data are concentrated and published in the form of datasets". It is "set up to facilitate access, easy exchange and reuse of transport related data in Europe, in order to help support the provision of EU-wide interoperable travel and traffic services to end users."

A Metadata entry (or synonymously a metadata record or a metadata set) describes the administration, organisation, and content of an individual dataset, as well as the formatting and access conditions of corresponding distributions.

A Metadata registry is a digital recording or a database of all metadata entries in a data portal.

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

The suggested namespace prefix is: mobilitydcatap

mobilityDCAT-AP 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-3]
`dcatap`	`http://data.europa.eu/r5r/`	[DCAT-AP]
`dct`	`http://purl.org/dc/terms/`	[DCTERMS]
`dqv`	`http://www.w3.org/ns/dqv#`	[VOCAB-DQV]
`eli`	`http://data.europa.eu/eli/ontology#`	[ELI-Ontology]
`foaf`	`http://xmlns.com/foaf/0.1/`	[FOAF]
`geodcatap`	`http://data.europa.eu/930/`	[GeoDCAT-AP-v3.0.0]
`locn`	`http://www.w3.org/ns/locn#`	[CORE-LOCATION-VOCABULARY]
`mobilitydcatap`	`https://w3id.org/mobilitydcat-ap#`	current website
`oa`	`http://www.w3.org/ns/oa#`	[WEB-ANNOTATION-ONTOLOGY]
`org`	`http://www.w3.org/ns/org#`	[CORE-ORGANIZATION-ONTOLOGY]
`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]
`vcard`	`http://www.w3.org/2006/vcard/ns#`	[VCARD-RDF]
`xsd`	`http://www.w3.org/2001/XMLSchema#`	[XMLSCHEMA11-2]

For a first orientation in mobilityDCAT-AP, these four central classes should be considered: dcat:Catalog, 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.

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, are mandatory, in contrast to [DCAT-AP-v3.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-v3.0.1]. All additions are marked with a prepended “plus” sign (+).

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.

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

Figure 4 shows a complete UML diagram with all elements used in mobilityDCAT-AP.

Figure 4 Complete mobilityDCAT-AP UML Class Diagram

The main entities are those that form the core of mobilityDCAT-AP. The properties and their associated constraints that apply in the context of this profile are listed in a tabular form. Each row corresponds to one property. In addition, cross-references are provided for reused properties (i.e., their parallel definitions in [DCAT-AP-v3.0.1] and [GeoDCAT-AP-v3.0.0]), with the following abbreviations:

A: reused as-is defined and expressed in [DCAT-AP-v3.0.1]
E: reused with additional usage notes or additional restrictions compared to [DCAT-AP-v3.0.1]
GA: reused as-is defined and expressed in [GeoDCAT-AP-v3.0.0]
GE: reused with additional usage notes or additional restrictions compared to [GeoDCAT-AP-v3.0.0]
P: proprietary definition (i.e., mobilityDCAT-AP extension, no previous definitions by neither [DCAT-AP-v3.0.1] nor [GeoDCAT-AP-v3.0.0])

This reuse qualification assessment is with respect to a specific version of DCAT. Therefore it may vary over time when new versions of DCAT-AP are created.

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

Definition	An entity (e.g., an individual or an organisation) that is associated with Catalogues, Catalogue Records, Datasets or Dataset Series.
URI	`foaf:Agent`
References	DCAT: Link DCAT-AP: Link geoDCAT-AP: Link
Usage note	According to [FOAF], an 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 is preferred. In such case, the use of the Organization Ontology is recommended. If a person is mentioned as an agent, 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`. The agent might be populated with the same information as for a kind, see class `vcard:Kind`. When providing agent information, data publishers should prioritize organizational information over personal details. The exposure of personal information, such as a personal name and email address, may be restricted to the public. Instead, there might be an anonymous contact channel, e.g. a contact button on the GUI that triggers an email to the agent. See 12.1 Privacy and security considerations. See also the Wiki page with more recommendations on the usage of organisational and personal information.
Properties	For this entity the following properties are defined: address, affiliation, email, first name, name, phone, surname, type, URL.

Property name and URI	Range	Card.	Definition	Usage note	Reuse
+address `locn:address`	`locn:Address`	0..1	The postal address of the agent.	This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GA
+affiliation `org:memberOf`	`org:Organization`	0..1	The affiliation of the agent.	This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GA
+email `foaf:mbox`	`rdfs:Resource`	0..1	The email address of the agent, specified using fully qualified mailto: URI scheme RFC6068.	This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GA
+first name `foaf:firstName`	`rdfs:Literal`	0..1	The first name of the agent.	To be used if the agent is of type person.	P
name `foaf:name`	`rdfs:Literal`	1..*	A name of the agent.	This property can be repeated for different versions of the name (e.g. the name in different languages) - see 11. Accessibility and Multilingual Aspects.	A
+phone `foaf:phone`	`rdfs:Resource`	0..1	The phone number of the agent, specified using fully qualified tel: URI scheme RFC3966.	This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GA
+surname `foaf:surname`	`rdfs:Literal`	0..1	The surname of the agent.	To be used if the agent is of type person.	P
type `dct:type`	`skos:Concept`	0..1	The nature of the agent.	A controlled vocabulary is provided.	E
+URL `foaf:workplaceHomepage`	`rdfs:Resource`	0..1	The Web site of the agent.	This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GA

Definition	An assessment procedure by an external organisation. This organisation may be a National Body in the context of EU Delegated Regulations ([NAPCORE-Information-about-National-Bodies]). 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 and installed individually in each Member State.
URI	`mobilitydcatap:Assessment`
References	DCAT: none DCAT-AP: none geoDCAT-AP: none
Usage note	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.
Properties	For this entity the following properties are defined: assessment date, assessment result .

Property name and URI	Range	Card.	Definition	Usage note	Reuse
+assessment date `dct:issued`	`rdfs:Literal` (Datatype: Temporal Literal)	0..1	The date of the latest assessment procedure.		P
+assessment result `oa:hasBody`	`rdfs:Resource`	0..1	The result of the latest assessment procedure, in form of a URL linking to further details or results. Alternatively, textual information is provided using the Embedded Textual Body construction of the Web Annotation Data Model, which allows to specify text formats and languages which might be relevant for multilingual purposes.		P

Property name and URI

Range

Card.

Definition

Usage note

Reuse

+assessment date

dct:issued

rdfs:Literal

(Datatype: Temporal Literal)

0..1

The date of the latest assessment procedure.

+assessment result

oa:hasBody

rdfs:Resource

0..1

The result of the latest assessment procedure, in form of a URL linking to further details or results. Alternatively, textual information is provided using the Embedded Textual Body construction of the Web Annotation Data Model, which allows to specify text formats and languages which might be relevant for multilingual purposes.

Definition	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.
URI	`dcat:Catalog`
References	DCAT: Link DCAT-AP: Link geoDCAT-AP: Link
Usage note
Properties	For this entity the following properties are defined: dataset, description, geographical coverage, has part, homepage, identifier, language, licence, modification date, other identifier, publisher, record, release date, themes, title .

Property name and URI	Range	Card.	Definition	Usage note	Reuse
dataset `dcat:dataset`	`dcat:Dataset`	0..*	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 mandatory to use the property `dcat:record` to link to a data set. The usage of `dcat:dataset` may be then redundant.	E
description `dct:description`	`rdfs:Literal`	1..*	A free-text account of the mobility data portal.	This property can be repeated for parallel language versions of the description - see 11. Accessibility and Multilingual Aspects.	A
geographical coverage `dct:spatial`	`dct:Location`	1..*	A geographical area covered by the mobility data portal.	For National Access Points (NAPs), this corresponds to the EU 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-v3.0.1].	E
has part `dct:hasPart`	`dcat:Catalog`	0..*	A related Catalogue that is part of the described mobility data portal.	May 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.	E
homepage `foaf:homepage`	`foaf:Document`	1..1	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-v3.0.1].	E
+identifier `dct:identifier`	`rdfs:Literal`	0..*	The main identifier for the mobility data portal, e.g. the URI or other unique identifier. 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 be populated by the URI used within the RDF statement (via `rdf:about`). This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GE
language `dct:language`	`dct:LinguisticSystem`	0..*	Language used in the user interface of the mobility data portal, in particular the textual metadata describing the datasets registered in the portal.	This property can be repeated if the user interface and textual metadata are provided in multiple languages - see 11. Accessibility and Multilingual Aspects. A corresponding controlled vocabulary is provided.	E
licence `dct:license`	`dct:LicenseDocument`	0..1	A licence under which the mobility data portal can be used or reused.		A
modification date `dct:modified`	`rdfs:Literal` (Datatype: Temporal Literal)	0..1	The most recent date on which the mobility data portal was modified. Indicates modifications of the portal system as such (e.g., major technical updates of the portal or its features), rather than modifications of the hosted datasets, since datasets on mobility data portals are updated frequently.		E
+other identifier `adms:identifier`	`adms:Identifier`	0..1	This property may be used as an additional identifier, besides `dct:identifier`.	This property may be referring to a dedicated, EU-wide identifier system of NAPs or other portals, to be introduced in the future. This property is an addition by mobilityDCAT-AP.	P
publisher `dct:publisher`	`foaf:Agent`	1..1	An entity (organisation) responsible for making the mobility data portal available. This organisation is the direct contact for platform users, who have questions or issues about the platform and its system.	This information should correspond to the information in the disclaimer of the platform website.	E
record `dcat:record`	`dcat:CatalogRecord`	1..*	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-v3.0.1].	E
release date `dct:issued`	`rdfs:Literal` (Datatype: Temporal Literal)	0..1	The date of formal issuance (e.g., publication) of the mobility data portal.		E
themes `dcat:themeTaxonomy`	`skos:ConceptScheme`	0..*	A knowledge organization system used to classify the mobility data portal's datasets.	Recommended to indicate the usage of the controlled vocabulary "Mobility Theme": `<https://w3id.org/mobilitydcat-ap/mobility-theme>`.	E
title `dct:title`	`rdfs:Literal`	1..*	A name given to the mobility data portal.	This property can be repeated for parallel language versions of the name - see 11. Accessibility and Multilingual Aspects.	E

Definition	A description of a metadata entry in the mobility data portal, referring to one dataset and its distributions published on the portal.
URI	`dcat:CatalogRecord`
References	DCAT: Link DCAT-AP: Link geoDCAT-AP: Link
Usage note	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-v3.0.1].
Properties	For this entity the following properties are defined: application profile, language, listing date, modification date, primary topic, publisher, source metadata .

Property name and URI	Range	Card.	Definition	Usage note	Reuse
application profile `dct:conformsTo`	`dct:Standard`	0..*	An Application Profile that the catalogued resource's metadata conforms to. In particular, specify which mobilityDCAT-AP version is used to describe the metadata.	As the range, it is recommended to use the mobilityDCAT-AP IRI with versioning, e.g., `dct:conformsTo <https://w3id.org/mobilitydcat-ap/releases/3.0.0>`. The value may be generated automatically by the NAP system, corresponding to the currently used mobilityDCAT-AP version.	E
language `dct:language`	`dct:LinguisticSystem`	1..*	The 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 11. Accessibility and Multilingual Aspects. The obligation of this property is raised to “mandatory”, comparing to [DCAT-AP-v3.0.1]. A corresponding controlled vocabulary is provided.	E
listing date `dct:issued`	`rdfs:Literal` (Datatype: Temporal Literal)	1..1	The date on which the metadata entry was included in the Catalogue.	It should be generated by the system, whenever a platform user enters the metadata entry. The obligation of this property is raised to “mandatory”, compared to [DCAT-AP-v3.0.1].	E
modification date `dct:modified`	`rdfs:Literal` (Datatype: Temporal Literal)	1..1	The most recent date on which the metadata entry was changed or 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 `dct:issued` should be taken.	E
primary topic `foaf:primaryTopic`	`dcat:Resource`	1..1	Links the metadata entry to the dataset or dataset series described in the entry.		E
+publisher `dct:publisher`	`foaf:Agent`	0..1	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, 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. The information might be identical to the property `dct:publisher` of the corresponding dataset. This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GE
source metadata `dct:source`	`dcat:CatalogRecord`	0..1	The original metadata record that was used in creating the metadata record.	Used for metadata records that are harvested from other portals. Harvesting, i.e., the automated import of metadata information from external portals, seems to be a common case for some NAPs. With this property, a data user can see, if the metadata was harvested, and from where. The property should link to a public URL of the dataset description on the original data portal, from where the metadata was harvested.	E

Definition	Resource published or curated by a single agent.
URI	`dcat:Resource`
References	DCAT: Link DCAT-AP: Link geoDCAT-AP: Link
Usage note	This class is an abstract class. Only subclasses should be used in a data exchange, such as `dcat:Dataset` and `dcat:DatasetSeries`.
Properties	This specification does not impose any additional requirements to properties for this entity.

Definition	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.
URI	`dcat:Dataset`
References	DCAT: Link DCAT-AP: Link geoDCAT-AP: Link
Usage note
Properties	For this entity the following properties are defined: applicable legislation, assessment result, contact point, dataset distribution, description, documentation, frequency, geographical coverage, georeferencing method, has version, identifier, in series, intended information service, keyword, language, mobility theme, modification date, network coverage, other identifier, publisher, quality description, reference system, related resource, release date, rights holder, source, temporal coverage, theme, title, transport mode, version, version notes. .

Property name and URI	Range	Card.	Definition	Usage note	Reuse
applicable legislation `dcatap:applicableLegislation`	`eli:LegalResource`	0..*	A legal framework being relevant for the dataset, e.g., an EC Delegated Regulation which stipulates the provisioning of the corresponding dataset, or some other international or national frameworks, e.g., Open Data regulations.		E
+assessment result `mobilitydcatap:assessmentResult`	`mobilitydcatap:Assessment`	0..1	The results and outcomes from an assessment process by an external 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 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.	P
contact point `dcat:contactPoint`	`vcard:Kind`	0..*	Contact information that can be used for communication with a company or person responsible for the dataset. Used for questions or issues about a dataset and its provisioning, as raised by a platform user or a platform operator.	When providing contact information, data publishers should prioritize organizational information over personal details. The exposure of personal information, such as a personal name and email address, may be restricted to the public. Instead, there might be an anonymous contact channel, e.g. a contact button on the GUI that triggers an email to the contact point. See 12.1 Privacy and security considerations. The contact point might be populated with the same information as for property `dct:publisher`.	E
dataset distribution `dcat:distribution`	`dcat:Distribution`	1..*	An available Distribution for the Dataset.	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-v3.0.1].	E
description `dct:description`	`rdfs:Literal`	1..*	Information about the dataset as a 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 11. Accessibility and Multilingual Aspects. The language version 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.	E
documentation `foaf:page`	`foaf:Document`	0..*	A page or document about this dataset.	This property is meant to link to other resources which document the dataset, e.g., PDF manuals, other websites or similar. In contrast, the property `dct:description` is meant to provide a textual documentation. Please note there is also the same property `foaf:page` on the distribution level. Depending if the documentation is data set- or distribution-dependent, the property should be used on the data set or distribution level.	A
frequency `dct:accrualPeriodicity`	`dct:Frequency`	1..1	Describes how often the delivered content is updated. This information tells a data consumer how often it is updated on the data platform, so the data consumer might align the frequency of data retrieval accordingly.	For dynamic 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 is provided. The obligation of this property is raised to “mandatory”, compared to [DCAT-AP-v3.0.1].	E
geographical coverage `dct:spatial`	`dct:Location`	1..*	A geographic region that is covered by the delivered content.	The obligation of this property is raised to “mandatory”, compared to [DCAT-AP-v3.0.1].	E
+georeferencing method `mobilitydcatap:georeferencingMethod`	`skos:Concept`	0..*	The georeferencing method used in the delivered content.	A corresponding controlled vocabulary is provided, denoting commonly used georeferencing methods for mobility data.	P
has version `dcat:hasVersion`	`dcat:Dataset`	0..*	A related dataset that is a version, edition, or adaptation of the described dataset	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 `dcat:version` and `adms:versionNotes`.	E
identifier `dct:identifier`	`rdfs:Literal`	0..1	The main identifier for the dataset, e.g. the URI or other unique identifier. 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 be populated by the URI used within the RDF statement (via `rdf:about`).	E
in series `dcat:inSeries`	`dcat:DatasetSeries`	0..*	A dataset series of which the dataset is part.		A
+intended information service `mobilitydcatap:intendedInformationService`	`skos:Concept`	0..*	A type of information service, which the data content is intended to support. Such services may be, e.g., information services for multimodal mobility, as specified by [EC-Regulation-2024/490-on-MMTIS]. 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 on timetables.	A corresponding controlled vocabulary is provided.	P
keyword `dcat:keyword`	`rdfs:Literal`	0..*	A keyword or tag describing the Dataset.	For the purposes of mobility data portals, it is not recommended to use keywords, as they might be ambiguous, language-dependent and make data search difficult. Instead, usage of mobility-related properties with Controlled Vocabularies is recommended, in particular `mobilitydcatap:mobilityTheme`, `mobilitydcatap:networkCoverage` and `mobilitydcatap:transportMode`. If there are relevant keywords that are not part of such Controlled Vocabularies, please contact the authors of mobilityDCAT-AP, in order to update the Controlled Vocabularies.	E
language `dct:language`	`dct:LinguisticSystem`	0..*	The language of the content data in a dataset, if this content has a natural language embedded, such as text fields, addresses etc.	This property can be repeated if there are multiple languages in the dataset - see 11. Accessibility and Multilingual Aspects A corresponding controlled vocabulary is provided.	E
+mobility theme `mobilitydcatap:mobilityTheme`	`skos:Concept`	1..*	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 the following controlled vocabularies: First, the mobility theme per se is described 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. In addition, an optional controlled vocabulary "energy fuel type" specifies datasets related to the [EC-Regulation-2023/1804-on-AFIR], indicating a fuel-/energy-type covered by the dataset.	A corresponding controlled vocabulary for the Mobility Theme and controlled vocabulary for the Energy Fuel Type are provided. This property is a sub-property of `dcat:theme`, being a further property of Dataset. To distinguish these two 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 property `dcat:keyword`. However, the usage of "mobility theme" is preferred, to avoid ambiguity and uncontrolled theme descriptions.	P
modification date `dct:modified`	`rdfs:Literal` (Datatype: Temporal Literal)	0..1	The most recent date on which the content of the dataset was changed or modified.	This is redundant for high-frequency data feeds (e.g., DATEX II feeds), where the change date can be derived from the time stamp within the data feed.	E
+network coverage `mobilitydcatap:networkCoverage`	`skos:Concept`	0..*	This property describes the part of the transport network that is covered by the delivered content. For road traffic, the property should refer to the network classification for which the data is provided. As a minimum, an international or higher-level classification, e.g., via functional road classes, is recommended to allow data search across different countries. In addition, national classifications are allowed. For other transport modes, the property is meant to refer to the physical infrastructure which is used by the services covered by the data. For all modes, the property should also indicate if the data content relates to the EU’s trans-European transport network.	A corresponding controlled vocabulary is provided, denoting commonly used road and infrastructure network classes.	P
other identifier `adms:identifier`	`adms:Identifier`	0..*	This property may be used as an additional identifier, besides `dct:identifier`.	This property may be referring to a dedicated, EU-wide identifier system of NAP datasets, to be introduced in the future, or other identifier systems such as [DataCite-Metadata-Schema], [DOI], or [W3ID].	E
publisher `dct:publisher`	`foaf:Agent`	1..1	An entity (company and person) that publishes the 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. The information might be identical to the property `dct:publisher` of class Catalogue Record and/or `dct:rightsHolder` of class Dataset. To establish a contact with a company or person responsible for the dataset, the property `dcat:contactPoint` should be used. However, the publisher and the contact point might be populated with the same information. The obligation of this property is raised to “mandatory”, comparing to [DCAT-AP-v3.0.1].	E
+quality description `dqv:hasQualityAnnotation`	`dqv:QualityAnnotation`	0..*	Any quality aspects regarding the delivered content, in particular methods, metrics/indicators and results of a quality assessment. 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 [NAPCORE-Quality-Frameworks], these frameworks should be referenced.	P
+reference system `geodcatap:referenceSystem`	`skos:Concept`	0..*	The spatial reference system used in the delivered content. To be specified via the “EPSG coordinate reference systems” register operated by OGC.	A corresponding controlled vocabulary is provided. This is a sub-property of `dct:conformsTo`. This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GA
related resource `dct:relation`	`rdfs:Resource`	0..*	A reference, citation, or otherwise pointing to another, related resource, such as another dataset.	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.	E
release date `dct:issued`	`rdfs:Literal` (Datatype: Temporal Literal)	0..1	The date of formal issuance (e.g., publication) of the dataset.	There might be a difference in the listing date of the metadata entry; see the property `dct:issued` of class Catalogue Record. Imagine the dataset is published outside the mobility data portal first, and afterwards published as a metadata entry on the portal, leading to two different dates. However, both dates can also be the same.	E
+rights holder `dct:rightsHolder`	`foaf:Agent`	0..*	An entity that legally owns or holds the rights of the data provided in a dataset. This entity is legally responsible for the content of the data and (if applicable) for the relevance to legal frameworks (see property `dcatap:applicableLegislation`).	The rights holder will be in many cases identical with the publisher of the dataset (see property `dct:publisher`) and/or of the catalogue record (see property `dct:publisher`). In such case, the rights holder data may be copied from the corresponding publisher entries. There might be also cases with non-identical entities: e.g., when one or several rights holders contract a third-party publisher (e.g., an IT service company), which is producing, hosting and publishing a dataset. This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GE
source `dct:source`	`dcat:Dataset`	0..*	A related Dataset from which the described Dataset is derived.	There is the same property `dct:source` on the Catalogue Record level. The source of a dataset relates to the content data, whereas the source of a catalogue record relates to the metadata.	E
temporal coverage `dct:temporal`	`dct:PeriodOfTime`	0..*	A temporal period, i.e., the beginning and the end, of the time reference of the delivered content (e.g., validity time of a public-transport time table).		E
theme `dcat:theme`	`skos:Concept`	0..*	The generic theme (i.e., a specific subject, category, or type) of the content of the dataset.	A controlled vocabulary is provided.	E
title `dct:title`	`rdfs:Literal`	1..*	The 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 title - see 11. Accessibility and Multilingual Aspects. The language version 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.	E
+transport mode `mobilitydcatap:transportMode`	`skos:Concept`	0..*	The transport mode that is covered by the delivered content. It is described via the following controlled vocabularies: First, the transport mode per se is described in a narrower sense, with a focus on the physical means of transport (car, bus, etc.). In addition, an optional controlled vocabulary "mobility service" specifies datasets, which cover transport modes with specific mobility services (e.g., sharing, hiring, transport, etc.).	A corresponding controlled vocabulary for the Transport Mode and controlled vocabulary for the Mobility or Transport Service are provided.	P
version `dcat:version`	`rdfs:Literal`	0..1	The version indicator (name or identifier) of a dataset.	The version number 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.	E
version notes `adms:versionNotes`	`rdfs:Literal`	0..*	A textual description of the differences between this version and a previous version of the dataset.	This property should be an addition to the property `dcat:version`. This property can be repeated for parallel language versions of the version notes - see 11. Accessibility and Multilingual Aspects.	E

Definition	A collection of datasets that are published separately, but share some characteristics that group them.
URI	`dcat:DatasetSeries`
References	DCAT: Link DCAT-AP: Link geoDCAT-AP: Link
Usage note	It is recommended to avoid Dataset Series without a dataset in the collection. Therefore at least one Dataset should refer to a Dataset Series using the property in series (`dcat:inSeries`). Further instructions on the usage of Dataset Series are given in the Wiki page on Dataset Series, the [DCAT-AP-v3.0.1-Usage-guide-on-Dataset-Series] and the [DCAT-AP-v3.0.1-Examples-for-Dataset-Series].
Properties	For this entity the following properties are defined: applicable legislation, contact point, description, frequency, geographical coverage, mobility theme, modification date, publisher, release date, temporal coverage, title .

Property name and URI	Range	Card.	Definition	Usage note	Reuse
applicable legislation `dcatap:applicableLegislation`	`eli:LegalResource`	0..*	A legal framework being relevant for the dataset series.		E
contact point `dcat:contactPoint`	`vcard:Kind`	0..*	Contact information that can be used for communication with a company or person responsible for the dataset series. Used for questions or issues about a dataset series and its provisioning, as raised by a platform user or a platform operator.	When providing contact information, data publishers SHOULD prioritize organizational information over personal details. The exposure of personal information, such as a personal name and email address, may be restricted to the public. Instead, there might be an anonymous contact channel, e.g. a contact button on the GUI that triggers an email to the contact point. See 12.1 Privacy and security considerations.	E
description `dct:description`	`rdfs:Literal`	1..*	Information about the dataset series as a free-text description.	It is recommended to provide an indication about the dimensions the Dataset Series evolves, e.g., if it evolves according to the time, geolocation or other dimensions. This property can be repeated for parallel language versions of the description - see 11. Accessibility and Multilingual Aspects. The language version 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.	E
frequency `dct:accrualPeriodicity`	`dct:Frequency`	0..1	Describes how often the dataset series is updated.	The frequency of a dataset series is understood differently to the frequency of the dataset in the series, as declared via property `dct:accrualPeriodicity`. See the examples no. 5 and 6 in the [DCAT-AP-v3.0.1-Examples-for-Dataset-Series]. A controlled vocabulary is provided.	A
geographical coverage `dct:spatial`	`dct:Location`	0..*	A geographic region that is covered by the dataset series.	When spatial coverage is a dimension in the dataset series then the spatial coverage of each dataset in the series should be part of the spatial coverage of the dataset series. In that case, the value of the spatial coverage of the dataset series should be as wide as possible. E.g., if datasets in a series are about different regions in a country, the spatial coverage of the dataset series should note the entire country. See also the examples no. 7 and 8 in the [DCAT-AP-v3.0.1-Examples-for-Dataset-Series].	E
+mobility theme `mobilitydcatap:mobilityTheme`	`skos:Concept`	0..*	This property refers to the mobility-related theme (i.e., a specific subject, category, or type) of the dataset series. See the definition of property with the same name `mobilitydcatap:mobilityTheme` of class Dataset. It is recommended that the theme does not change among datasets in the series, i.e., the theme of the dataset series should be equal to the theme of each dataset in the series.	Corresponding controlled vocabularies are provided as for `mobilitydcatap:mobilityTheme` of class Dataset.	P
modification date `dct:modified`	`rdfs:Literal` (Datatype: Temporal Literal)	0..1	The most recent date on which the dataset series was changed or modified.	This should correspond to the most recent modification date of all datasets in the series, as declared via property `dct:modified`. See also the example no. 11 in the [DCAT-AP-v3.0.1-Examples-for-Dataset-Series].	E
publisher `dct:publisher`	`foaf:Agent`	0..1	An entity (company and person) that publishes the dataset series. This entity is also responsible for ensuring the coherency of the dataset series.	The publisher of the dataset series may be (but does not need to be) the publisher of datasets in the series, as declared via property `dct:publisher`. An example for a case where the publisher is different from the publisher of datasets in the series: a digital archive could take over the publishing of older datasets in the series.	E
release date `dct:issued`	`rdfs:Literal` (Datatype: Temporal Literal)	0..1	The date of formal issuance (e.g., publication) of the dataset series.	The moment when the dataset series was established as a managed resource. This might correspond to the earliest release date of the dataset in the series, as declared via property `dct:issued`. See also the examples no. 9 and 10 in the [DCAT-AP-v3.0.1-Examples-for-Dataset-Series].	E
temporal coverage `dct:temporal`	`dct:PeriodOfTime`	0..*	A temporal period, i.e., the beginning and the end, of the time reference that the Dataset Series covers.	When temporal coverage is a dimension in the dataset series then the temporal coverage of each dataset in the series should be part of the temporal coverage. In that case, an open ended value is recommended, e.g. "after 2012".	E
title `dct:title`	`rdfs:Literal`	1..*	The name given to the dataset series 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 title - see 11. Accessibility and Multilingual Aspects.	E

Definition	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 REST web service. These are two distributions based on one dataset.
URI	`dcat:Distribution`
References	DCAT: Link DCAT-AP: Link geoDCAT-AP: Link
Usage note	For the context of mobility data portals, it can be expected that all datasets have one or more distributions. Thus, there must be at least one instance of class Distribution related to one dataset. This is in contrast to [DCAT-AP-v3.0.1], which allows for datasets without distributions.
Properties	For this entity the following properties are defined: access url, application layer protocol, applicable legislation, character encoding, communication method, data format notes, description, documentation, download url, format, language, licence, linked schemas, mobility data standard, modification date, release date, rights, sample, status, temporal coverage, title.

Property name and URI	Range	Card.	Definition	Usage note	Reuse
access url `dcat:accessURL`	`rdfs:Resource`	1..1	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. If the data is accessed via an API, the URL should be the end point of such API. If some agreements between the data provider and the data user need to be established first, the access URL should link to web page, where the access is further arranged, e.g., initiating a subscription process. For data which can be downloaded directly, the download URL should be copied from the 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.	E
+application layer protocol `mobilitydcatap:applicationLayerProtocol`	`skos:Concept`	0..1	The transmitting channel, i.e., the Application Layer Protocol, of the distribution.	A corresponding controlled vocabulary is provided.	P
applicable legislation `dcatap:applicableLegislation`	`eli:LegalResource`	0..*	A legal framework being relevant for the distribution.	The legal framework is usually provided on the dataset level, see property `dcatap:applicableLegislation`. However, there is a special case of if a High Value Dataset (HVD) is provided. Here, the [DCAT-AP-High-Value-Datasets] specification stipulates that this property links to the [EC-Regulation-2023/138-on-HVD] both on the dataset and distribution levels. In other words, a RDF statement is required under the dataset and distribution class, if a HVD is published on the portal. For other cases outside HVD, the use of this property is not recommended.	E
+character encoding `cnt:characterEncoding`	`rdfs:Literal`	0..1	The technical encoding format of the delivered content within the distribution.	It should be expressed using a character set name defined in the [IANA-CHARACTER-SETS] register. This property is analogue to an addition by [GeoDCAT-AP-v3.0.0].	GE
+communication method `mobilitydcatap:communicationMethod`	`skos:Concept`	0..1	Indicates for dynamically provided distributions, e.g., data feeds, if the data interface of the data provider system functions in a push or pull mode.	A corresponding controlled vocabulary is provided.	P
+data format notes `mobilitydcatap:dataFormatNotes`	`rdfs:Literal`	0..*	Any additional information about the format of the delivered content within the distribution in a textual format.	This property can be repeated for parallel language versions of the data format notes - see 11. Accessibility and Multilingual Aspects.	P
description `dct:description`	`rdfs:Literal`	0..*	A free-text account of the Distribution.	This property can be repeated for parallel language versions of the description - see 11. Accessibility and Multilingual Aspects.	E
documentation `foaf:page`	`foaf:Document`	0..*	A page or document about the distribution.	This property is meant to link to other resources which document the data distribution, e.g., PDF manuals, other websites or similar. In contrast, the property `dct:description` is meant to provide a textual documentation. Please note there is also the same property `foaf:page` on the dataset level. Depending if the documentation is data set- or distribution-dependent, the property should be used on the data set or distribution level.	A
download url `dcat:downloadURL`	`rdfs:Resource`	0..1	A URL that is a direct link to a downloadable file in a given format.		A
format `dct:format`	`dct:MediaTypeOrExtent`	1..1	The technical syntax of the delivered content within the distribution. It describes the base standard that specifies syntactically correct documents. On this level, base elements are properly specified on how to build a document. The resulting document can then be validated by syntax checks.	A controlled vocabulary is provided. The obligation of this property is raised to “mandatory”, compared to [DCAT-AP-v3.0.1]. There is a similar property in [DCAT-AP-v3.0.1] called `dcat:mediaType`. This one is not used in mobilityDCAT-AP. The reason is the use of controlled vocabularies: `dct:format` uses the EU Authority List about file types ([EUV-FT]), whereas `dcat:mediaType` uses the [IANA-Media-Types] register. The first one, however, is sufficient to describe the syntaxes commonly used in mobility data portals.	E
language `dct:language`	`dct:LinguisticSystem`	0..*	The language of the content data in a distribution, if this content has a natural language embedded, such as text fields, addresses etc.	There is the same property `dct:language` under class Dataset. Language information on the distribution level is only recommended, if there are multiple distributions for the same dataset with a different language each. A corresponding controlled vocabulary is provided. This property can be repeated if there are multiple languages in the distribution - see 11. Accessibility and Multilingual Aspects.	E
licence `dct:license`	`dct:LicenseDocument`	0..1	The licence under which the distribution is made available. This should be a reference to a concrete (standard) licence.	A controlled vocabulary is provided.	E
linked schemas `dct:conformsTo`	`dct:Standard`	0..*	An established schema to which the described Distribution conforms.	To inform about a mobility data standard (and also related profiles) applied to the delivered data, property `mobilitydcatap:mobilityDataStandard` should be preferably used. In addition, property `dct:conformsTo` can be used to serve the needs of standard DCAT/DCAT‑AP open data portals. Such portals usually cannot process information exposed indirectly via property `mobilitydcatap:mobilityDataStandard`, i.e., they cannot dereference or validate such references. Thus, this property would expose the standards/profiles information directly at the Distribution.	E
+mobility data standard `mobilitydcatap:mobilityDataStandard`	`mobilitydcatap:MobilityDataStandard`	1..*	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. This is a sub-property of `dct:conformsTo`.	A corresponding controlled vocabulary is provided, listing common mobility data standards. At least one value from this controlled vocabulary is required. If no suitable standard is found in this vocabulary, the "other" entry should be used. Optionally, a new individual instance of class `mobilitydcatap:MobilityDataStandard` can be provided. This instance might be used to (a) reference a mobility data standard that is not listed in the controlled vocabulary; or (b) provide additional information on an applied mobility data standard (even if listed in the controlled vocabulary), such as version or schema details. See the Wiki page for a code example with a reference to a mobility data standard (listed in the controlled vocabulary), and detailed information via an individual instance of class `mobilitydcatap:MobilityDataStandard`.	P
modification date `dct:modified`	`rdfs:Literal` (Datatype: Temporal Literal)	0..1	The most recent date on which the Distribution was changed or modified.	There is the same property `dct:modified` under the Dataset level. Under the distribution level, this property describes temporal changes in the characteristics of a distribution, e.g., a new data format or similar.	E
release date `dct:issued`	`rdfs:Literal` (Datatype: Temporal Literal)	0..1	The date of formal issuance (e.g., publication) of the Distribution.	There is the same property `dct:issued` at the Dataset level. Under the distribution level, this property relates to the release time of a distribution, which might be different than the release time of a dataset.	E
rights `dct:rights`	`dct:RightsStatement`	1..*	A statement that specifies rights associated with the distribution. In particular, 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-v3.0.1].	E
+sample `adms:sample`	`rdfs:Resource`	0..*	A sample of the delivered content, using the same conditions (e.g., the same format and licence) as the regular distribution. A 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-v3.0.1], there is a property `adms:sample` under class Dataset, with class Distribution as the range. This implies that all mandatory properties for a distribution, e.g., the applied Mobility Data Standard, must be applied for a sample. To simplify the description of the sample, mobilityDCAT-AP recommends to describe the sample via a property under class Distribution, instead under class Dataset.	P
status `adms:status`	`skos:Concept`	0..1	The status of the distribution in the context of maturity lifecycle.	It must take one of the values Completed, Deprecated, Under Development, Withdrawn. A corresponding controlled vocabulary is provided.	A
+temporal coverage `dct:temporal`	`dct:PeriodOfTime`	0..1	The time interval when a distribution is facilitated (i.e., activated) technically via the data platform. Might be used if data access via a distribution is limited in time.	If there is no entry it means that the distribution has no explicit start time (i.e., it is facilitated immediately) and has no end time (i.e., it is facilitated infinitely).	P
title `dct:title`	`rdfs:Literal`	0..*	A name given to the distribution.	This property can be repeated for parallel language versions of the title - see 11. Accessibility and Multilingual Aspects.	E

Definition	A description following the [VCARD-RDF], e.g., to provide telephone number and e-mail address for a contact point.
URI	`vcard:Kind`
References	DCAT: none DCAT-AP: Link geoDCAT-AP: Link
Usage note	This class is the parent class for the four explicit types of vCards (`vcard:Individual`, `vcard:Organization`, `vcard:Location`, `vcard:Group`). The contact point might be populated with the same information as for an agent, see class `foaf:Agent`. When providing contact information, data publishers SHOULD prioritize organizational information over personal details. The exposure of personal information, such as a personal name and email address, may be restricted to the public. Instead, there might be an anonymous contact channel, e.g. a contact button on the GUI that triggers an email to the agent. See 12.1 Privacy and security considerations.
Properties	For this entity the following properties are defined: address, affiliation, email, name, phone, URL .

Property name and URI	Range	Card.	Definition	Usage note	Reuse
+address `vcard:hasAddress`	`vcard:Address`	0..1	The postal address of the kind, i.e., of an individual, an organization, a location or a group.	This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GA
+affiliation `vcard:organization-name`	`rdfs:Literal`	0..1	The affiliation of the kind, i.e., of an individual, an organization, a location or a group.	This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GA
+email `vcard:hasEmail`	`vcard:Email`	1..1	The email address of the kind (i.e., an individual, an organization, a location or a group), specified using fully qualified mailto: URI scheme RFC6068.	This property corresponds to an addition by [GeoDCAT-AP-v3.0.0], however, with a raised obligation level.	GE
+name `vcard:fn`	`rdfs:Literal`	1..1	A name of the kind, i.e., a unique name of an individual, an organization, a location or a group.	This property corresponds to an addition by [GeoDCAT-AP-v3.0.0], however, with a raised obligation level.	GE
+phone `vcard:hasTelephone`	`rdfs:Resource`	0..1	The phone number of the kind (i.e., an individual, an organization, a location or a group), specified using fully qualified tel: URI scheme RFC3966.	This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GA
+URL `vcard:hasURL`	`rdfs:Resource`	0..1	A web site of the kind., i.e., of an individual, an organization, a location or a group.	This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GA

Definition	A legal document, e.g., a concrete license, giving official permission to do something with a resource.
URI	`dct:LicenseDocument`
References	DCAT: none DCAT-AP: Link geoDCAT-AP: Link
Usage note	This class is used to reference an applicable (standard) licence via an IRI, so a data user can assess the license conditions in machine- and human-readable formats, before using the data. Via an instance of this class, a reference to a standard or a organisation-specific license can be given. For standard licenses, a Controlled Vocabulary is provided. See the Wiki page on Rights and Licenses for further guidance.
Properties	This specification does not impose any additional requirements to properties for this entity.

Definition	A spatial region or named place.
URI	`dct:Location`
References	DCAT: none DCAT-AP: Link geoDCAT-AP: Link
Usage note	It can be represented via a geocode (= a named place) or with geographic coordinates, according to DCAT-AP guidelines [DCAT-AP-guideline-spatial]. For mobility data portals, usage of geocodes 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 geocodes, IRIs from predefined controlled vocabularies such as the EU authority tables, NUTS (Nomenclature des unités territoriales statistiques) or Geonames.org should be used. These IRIs can be linked directly from class `dct:Location`, or indirectly via custom instances of class `dct:Location`, from the `dct:identifier` property of this class. See the Wiki page on Geographical coverage for more guidance and code examples on how to use the class `dct:Location`.
Properties	For this entity the following properties are defined: bounding box, centroid, gazetteer, geographic identifier, geographic name, geometry .

Property name and URI	Range	Card.	Definition	Usage note	Reuse
bounding box `dcat:bbox`	`rdfs:Literal`	0..1	The geographic bounding box of the location.		A
centroid `dcat:centroid`	`rdfs:Literal`	0..1	The geographic center (centroid) of the location.		A
+gazetteer `skos:inScheme`	`skos:ConceptScheme`	0..1	The gazetteer, i.e., a codelist to which the location belongs.	This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GA
+geographic identifier `dct:identifier`	`rdfs:Literal`	0..*	This property contains the geographic identifier for the location, e.g., the URI or other unique identifier in the context of the relevant gazetteer.	Corresponding controlled vocabularies are provided, denoting commonly used geographic identifiers. This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GA
+geographic name `skos:prefLabel`	`rdfs:Literal`	0..*	A preferred label of the location.	This property can be repeated for parallel language versions of the label - see 11. Accessibility and Multilingual Aspects. This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GA
geometry `locn:geometry`	`locn:Geometry`	0..1	The corresponding geometry for the location.		A

Definition	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.
URI	`mobilitydcatap:MobilityDataStandard`
References	DCAT: none DCAT-AP: none geoDCAT-AP: none
Subclass of	`dct:Standard`.
Usage note	Further instructions on the usage of Mobility Data Standard are given in the Wiki page on Mobility Data Standard.
Properties	For this entity the following properties are defined: conforms to, title, version .

Property name and URI	Range	Card.	Definition	Usage note	Reuse
+conforms to `dct:conformsTo`	`dct:Standard`	0..*	Reference to the applied mobility data standard, as well as to individual/national/content-specific profiles or representations of the applied standard.	This property is necessary if a custom instance of class `mobilitydcatap:MobilityDataStandard` is defined. This property would then reference a common mobility data standard (e.g., "NeTeX" via the controlled vocabulary), as well as additionally further individual/national/content-specific profiles or representations of the applied standard (e.g., an Italian NeTEx profile).	P
+title `dct:title`	`rdfs:Literal`	0..*	A name given to the mobility data standard.	This property can be repeated for parallel language versions of the title - see 11. Accessibility and Multilingual Aspects.	P
+version `dcat:version`	`rdfs:Literal`	0..1	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., "3.2", without redundant acronyms such as "v", underscores etc.	P

Definition	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.
URI	`dqv:QualityAnnotation`
References	DCAT: none DCAT-AP: none geoDCAT-AP: none
Usage note	There is a similar class `dqv:Quality Measurement` in [GeoDCAT-AP-v3.0.0]. Both `dqv:QualityAnnotation` and `dqv:Quality Measurement` are reusing the [VOCAB-DQV]. `dqv:Quality Measurement` is referring to concrete metrics, like sub-types of spatial resolutions being used in GeoDCAT-AP. At mobility data portals, however, the practice so far is to provide a more generic quality description, e.g., via a free-text report. Thus, `dqv:QualityAnnotation` refers to an unspecified form of quality annotation.
Properties	For this entity the following properties are defined: quality annotation resource.

Property name and URI	Range	Card.	Definition	Usage note	Reuse
+quality annotation resource `oa:hasBody`	`rdfs:Resource`	0..1	Any quality aspects regarding the delivered content, in form of a URL linking to further details or results, or textual information.	Textual information should be provided using the Embedded Textual Body construction of the [Web-Annotation-Data-Model], which allows to specify text formats and languages which might be relevant for multilingual purposes.	P

Property name and URI

Range

Card.

Definition

Usage note

Reuse

+quality annotation resource

oa:hasBody

rdfs:Resource

0..1

Any quality aspects regarding the delivered content, in form of a URL linking to further details or results, or textual information.

Textual information should be provided using the Embedded Textual Body construction of the [Web-Annotation-Data-Model], which allows to specify text formats and languages which might be relevant for multilingual purposes.

The supportive entities are supporting the main entities in mobilityDCAT-AP. They are included because they form the range of properties.

Definition	A postal address used for agent information.
URI	`locn:Address`
References	DCAT: none DCAT-AP: none geoDCAT-AP: Link
Usage note	See the definition of the Address entity in the [CORE-LOCATION-VOCABULARY]. This class corresponds to an addition by [GeoDCAT-AP-v3.0.0].
Properties	For this entity the following properties are defined: administrative area, city, country, postal code, street address.

Property	URI	Range	Card.	Definition	Usage note	Reuse
+administrative area	`locn:adminUnitL2`	`rdfs:Literal`	0..1	The administrative area of an address. Depending on the country, this corresponds to a province, a county, a region, or a state.	This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GE
+city	`locn:postName`	`rdfs:Literal`	0..1	The name of the city of the address.	This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GE
+country	`locn:adminUnitL1`	`rdfs:Literal`	0..1	The country of an address.	This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GE
+postal code	`locn:postCode`	`rdfs:Literal`	0..1	The postal code of an address.	This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GE
+street address	`locn:thoroughfare`	`rdfs:Literal`	0..1	The street name and civic number of the address.	This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GE

Definition	A postal address used for contact point information.
URI	`vcard:Address`
References	DCAT: none DCAT-AP: none geoDCAT-AP: Link
Usage note	This class corresponds to an addition by [GeoDCAT-AP-v3.0.0].
Properties	For this entity the following properties are defined: administrative area, city, country, postal code, street address.

Property	URI	Range	Card.	Definition	Usage note	Reuse
+administrative area	`vcard:region`	`rdfs:Literal`	0..1	The administrative area of an address. Depending on the country, this corresponds to a province, a county, a region, or a state.	This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GA
+city	`vcard:locality`	`rdfs:Literal`	0..1	The name of the city of the address.	This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GA
+country	`vcard:country-name`	`rdfs:Literal`	0..1	The country of an address.	This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GA
+postal code	`vcard:postal-code`	`rdfs:Literal`	0..1	The postal code of an address.	This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GA
+street address	`vcard:street-address`	`rdfs:Literal`	0..1	The street name and civic number of the address.	This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GA

Definition	An idea or notion; a unit of thought.
URI	`skos:Concept`
References	DCAT: none DCAT-AP: Link geoDCAT-AP: Link
Usage note	A Concept is used to denote codes within a codelist. In mobilityDCAT-AP, this property is used to denote a specific value from a controlled vocabulary, see 10. Controlled Vocabularies.
Properties	For this entity the following properties are defined: preferred label, concept scheme .

Property name and URI	Range	Card.	Definition	Usage note	Reuse
preferred label `skos:prefLabel`	`rdfs:Literal`	1..*	A preferred label of the concept.	This property can be repeated for parallel language versions of the label - see 11. Accessibility and Multilingual Aspects.	A
+concept scheme `skos:inScheme`	`skos:ConceptScheme`	0..1	Relates a concept to a concept scheme in which it is included.	This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GE

Property name and URI

Range

Card.

Definition

Usage note

Reuse

preferred label

skos:prefLabel

rdfs:Literal

1..*

A preferred label of the concept.

This property can be repeated for parallel language versions of the label - see 11. Accessibility and Multilingual Aspects.

+concept scheme

skos:inScheme

skos:ConceptScheme

0..1

Relates a concept to a concept scheme in which it is included.

This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].

Definition	An aggregation of one or more SKOS concepts, see class `skos:Concept`. Semantic relationships (links) between those concepts may also be viewed as part of a concept scheme.
URI	`skos:ConceptScheme`
References	DCAT: none DCAT-AP: Link geoDCAT-AP: Link
Usage note	A Concept Scheme is used to denote a codelist. In mobilityDCAT-AP, this property is used to denote a specific controlled vocabulary, see 10. Controlled Vocabularies.
Properties	For this entity the following properties are defined: title .

Property name and URI	Range	Card.	Definition	Usage note	Reuse
title `dct:title`	`rdfs:Literal`	1..*	A name of the concept scheme.	This property can be repeated for parallel language versions of the name - see 11. Accessibility and Multilingual Aspects.	A

Property name and URI

Range

Card.

Definition

Usage note

Reuse

title

dct:title

rdfs:Literal

1..*

A name of the concept scheme.

This property can be repeated for parallel language versions of the name - see 11. Accessibility and Multilingual Aspects.

Definition	A textual resource intended for human consumption that contains information, e.g. a web page about a Dataset.
URI	`foaf:Document`
References	DCAT: none DCAT-AP: Link geoDCAT-AP: Link
Usage note	N/A
Properties	This specification does not impose any additional requirements to properties for this entity.

Definition	The electronic mail address for communication with the object.
URI	`vcard:Email`
References	DCAT: none DCAT-AP: none geoDCAT-AP: Link
Usage note	See the definition of class `vcard:Email` in the [VCARD-RDF]. This class corresponds to an addition by [GeoDCAT-AP-v3.0.0].
Properties	This specification does not impose any additional requirements to properties for this entity.

Definition	A rate at which something recurs, e.g., the update rate of a dataset.
URI	`dct:Frequency`
References	DCAT: none DCAT-AP: Link geoDCAT-AP: Link
Usage note	none
Properties	This specification does not impose any additional requirements to properties for this entity.

Definition	The means to identify a location as a point, line, polygon, etc. expressed using coordinates in some coordinate reference system.
URI	`locn:Geometry`
References	DCAT: none DCAT-AP: Link geoDCAT-AP: Link
Usage note	none
Properties	This specification does not impose any additional requirements to properties for this entity.

Definition	This is based on the UN/CEFACT Identifier class.
URI	`adms:Identifier`
References	DCAT: none DCAT-AP: Link geoDCAT-AP: Link
Usage note	An identifier in a particular context, consisting of the content 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
Properties	For this entity the following properties are defined: notation .

Property name and URI	Range	Card.	Definition	Usage note	Reuse
notation `skos:notation`	`rdfs:Literal`	1..1	A string that is an identifier in the context of the identifier scheme referenced by its datatype.		A

Property name and URI

Range

Card.

Definition

Usage note

Reuse

notation

skos:notation

rdfs:Literal

1..1

A string that is an identifier in the context of the identifier scheme referenced by its datatype.

Definition	The legislation, policy or policies that lie behind the rules that govern the service.
URI	`eli:LegalResource`
References	DCAT: none DCAT-AP: Link geoDCAT-AP: Link
Usage note	The definition and properties of the Legal Resource should follow the European Legislation Identifier Standard ([ELI-Standard]). For describing the attributes of a Legal Resource (labels, preferred labels, alternative labels, definition, etc.), the [ELI-Ontology] should be followed.
Properties	This specification does not impose any additional requirements to properties for this entity.

Definition	A system of signs, symbols, sounds, gestures, or rules used in communication, e.g. a language.
URI	`dct:LinguisticSystem`
References	DCAT: none DCAT-AP: Link geoDCAT-AP: Link
Usage note
Properties	This specification does not impose any additional requirements to properties for this entity.

Definition	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 the Best-Current-Practice [BCP47].
URI	`rdfs:Literal`
References	DCAT: none DCAT-AP: Link geoDCAT-AP: Link
Usage note
Properties	This specification does not impose any additional requirements to properties for this entity.

Definition	A media type or extent.
URI	`dct:MediaTypeOrExtent`
References	DCAT: none DCAT-AP: Link geoDCAT-AP: Link
Usage note	In mobilityDCAT-AP, this class is only used as the range of property `dct:format` for class Distribution.
Properties	This specification does not impose any additional requirements to properties for this entity.

Definition	Represents a collection of people organized together into a community or other social, commercial or political structure. The group has some common purpose or reason for existence which goes beyond the set of people belonging to it and can act as an Agent. Organizations are often decomposable into hierarchical structures.
URI	`org:Organization`
References	DCAT: none DCAT-AP: none geoDCAT-AP: Link
Usage note	See the definition of class `org:Organization` in the [CORE-ORGANIZATION-ONTOLOGY]. This class corresponds to an addition by [GeoDCAT-AP-v3.0.0].
Properties	This specification does not impose any additional requirements to properties for this entity.

Definition	An interval of time that is named or defined by its start and end dates.
URI	`dct:PeriodOfTime`
References	DCAT: none DCAT-AP: Link geoDCAT-AP: Link
Usage note	None
Properties	For this entity the following properties are defined: end date, start date .

Property name and URI	Range	Card.	Definition	Usage note	Reuse
end date `dcat:endDate`	`rdfs:Literal` (Datatype: Temporal Literal)	0..1	The end of the period.		A
start date `dcat:startDate`	`rdfs:Literal` (Datatype: Temporal Literal)	0..1	The start of the period		A

Property name and URI

Range

Card.

Definition

Usage note

Reuse

end date

dcat:endDate

rdfs:Literal

(Datatype: Temporal Literal)

0..1

The end of the period.

start date

dcat:startDate

rdfs:Literal

(Datatype: Temporal Literal)

0..1

The start of the period

Definition	Anything described by RDF.
URI	`rdfs:Resource`
References	DCAT: none DCAT-AP: Link geoDCAT-AP: Link
Usage note	none
Properties	This specification does not impose any additional requirements to properties for this entity.

Definition	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.
URI	`dct:RightsStatement`
References	DCAT: none DCAT-AP: Link geoDCAT-AP: Link
Usage note	Reference to concrete (standard) licenses can be provided via another class `dct:LicenseDocument`. See the Wiki page on Rights and Licenses for further guidance.
Properties	For this entity the following properties are defined: conditions for access and usage, rights statement text .

Property name and URI	Range	Card.	Definition	Usage note	Reuse
+conditions for access and usage `dct:type`	`skos:Concept`	1..*	An indication of the conditions if any contracts, licences or other arrangements are applied for the use of the distribution. The conditions are declared on an aggregated level: whether a free and unrestricted use is possible, a contract has to be concluded and/or a licence has to be agreed on to use a dataset.	A controlled vocabulary is provided. The values can be logically mapped with instances of class `dct:LicenseDocument`, denoting a concrete standard license. For example, if the `dct:LicenseDocument` is referring to standard licence "CC BY 4.0", the property `dct:type` can be given the value "Licence provided, free of charge".	P
+Rights statement text `dct:description`	`rdfs:Literal`	0..*	The text of the Rights Statement. I.e., any textual information about access, usage or licensing conditions, beyond information given via other properties under classes `dct:RightsStatement` and `dct:LicenseDocument`.	This property can be repeated for parallel language versions of the information - see 11. Accessibility and Multilingual Aspects. This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GE

Property name and URI

Range

Card.

Definition

Usage note

Reuse

+conditions for access and usage

dct:type

skos:Concept

1..*

An indication of the conditions if any contracts, licences or other arrangements are applied for the use of the distribution. The conditions are declared on an aggregated level: whether a free and unrestricted use is possible, a contract has to be concluded and/or a licence has to be agreed on to use a dataset.

A controlled vocabulary is provided.

The values can be logically mapped with instances of class dct:LicenseDocument, denoting a concrete standard license. For example, if the dct:LicenseDocument is referring to standard licence "CC BY 4.0", the property dct:type can be given the value "Licence provided, free of charge".

+Rights statement text

dct:description

rdfs:Literal

0..*

The text of the Rights Statement. I.e., any textual information about access, usage or licensing conditions, beyond information given via other properties under classes dct:RightsStatement and dct:LicenseDocument.

This property can be repeated for parallel language versions of the information - see 11. Accessibility and Multilingual Aspects.

This property corresponds to an addition by [GeoDCAT-AP-v3.0.0].

Definition	A standard or other specification to which a resource conforms.
URI	`dct:Standard`
References	DCAT: none DCAT-AP: Link geoDCAT-AP: Link
Usage note	To inform about a mobility data standard applied to the delivered data, mobilityDCAT-AP introduces a separate class `mobilitydcatap:MobilityDataStandard`. This class `mobilitydcatap:MobilityDataStandard` is a sub-class of `dct:Standard` and used as the range of property `mobilitydcatap:mobilityDataStandard` of class Distribution. In contrast, class `dct:Standard` can be applied to refer to (other or more precise) data standards/specifications/profiles at the Distribution and/or the Mobility Data Standard levels. In such case, this class is used as the range of property `dct:conformsTo` of class Distribution and/or of property `dct:conformsTo` of class Mobility Data Standard. Class `dct:Standard` can be also used as the range of property `dct:conformsTo` of class Catalogue Record.
Properties	This specification does not impose any additional requirements to properties for this entity.

The following datatypes are used within this specification.

Class	Definition	URI	Reference DCAT-AP	Reference geoDCAT-AP
Temporal Literal	`rdfs:Literal` encoded using the relevant [ISO-8601] Date and Time compliant string and typed using the appropriate XML Schema datatype (`xsd:gYear`, `xsd:gYearMonth`, `xsd:date`, or `xsd:dateTime`).	`rdfs:Literal`	Link	Link

mobilityDCAT-AP makes use of several controlled vocabularies for selected properties introduced above. These define harmonised value spaces, or, more concretely, harmonised URI sets to be used as ranges for the related properties. The selection of the applied controlled vocabularies adheres to requirements defined by [DCAT-AP-v3.0.1-Requirements-for-Controlled-Vocabularies].

The tables below list controlled vocabularies, as applied for properties defined by mobilityDCAT-AP.

The tables are separated by three categories with different usage expectations, following a similar categorisation by [DCAT-AP-v3.0.1].

Compared with [DCAT-AP-v3.0.1], mobilityDCAT-AP makes use of additional controlled vocabularies. These are either maintained by external organisations, or created and maintained by mobilityDCAT-AP.

Usage expectation:

The property MUST use as range values codes from the controlled vocabulary. This means the value space is closed under the controlled vocabularies. Validation systems SHOULD produce errors.

Property URI	Used for Class	Vocabulary name and URI	Usage note
`dct:accrualPeriodicity` `dct:accrualPeriodicity`	`dcat:Dataset` `dcat:DatasetSeries`	EU Authority Table "Frequency"	This is a vocabulary by the Publications Office of the European Union.
+`geodcatap:referenceSystem`	`dcat:Dataset`	+OGC EPSG Coordinate Reference Systems Register	This is a vocabulary added by mobilityDCAT-AP, corresponding to an addition by [GeoDCAT-AP-v3.0.0].
`dct:format`	`dcat:Distribution`	EU Authority Table "File Type"	This is a vocabulary by the Publications Office of the European Union. Please note that mobilityDCAT-AP has different properties related to the format, including `mobilitydcatap:mobilityDataStandard`, `dct:format`, `cnt:characterEncoding`. This controlled vocabulary relates only to `dct:format`, i.e., the base standard that specifies syntactically correct documents.
`dct:language` `dct:language` `dct:language` `dct:language`	`dcat:Catalog` `dcat:CatalogRecord` `dcat:Dataset` `dcat:Distribution`	EU Authority Table "Language"	This is a vocabulary by the Publications Office of the European Union.
`adms:status`	`dcat:Distribution`	EU Authority Table "Distribution Status"	This is a vocabulary by the Publications Office of the European Union.

Usage expectation:

The property MUST have at least one value from the controlled vocabulary. This means the value space is minimally constrained. If no applicable value is found in the controlled vocabulary, the "other" value SHOULD be used. Validation systems SHOULD produce warnings. In addition, values not included in the controlled vocabulary are tolerated.

Property URI	Used for Class	Vocabulary name and URI	Usage note
+`mobilitydcatap:mobilityTheme` +`mobilitydcatap:mobilityTheme`	`dcat:Dataset` `dcat:DatasetSeries`	+mobilityDCAT-AP Vocabulary "Mobility Theme" (recommended) +mobilityDCAT-AP Vocabulary "Energy Fuel Type"	This is a vocabulary created by mobilityDCAT-AP. There are two hierarchical levels: "Data content category" (mandatory) and "Data content sub-category” (optional), see the usage note for property `mobilitydcatap:mobilityTheme`. For datasets relevant to the [EC-Regulation-2023/1804-on-AFIR], it is RECOMMENDED to also specify a fuel-/energy-type covered by the dataset by relying on the Energy Fuel Type vocabulary created by mobilityDCAT-AP.
`dcat:theme`	`dcat:Dataset`	EU Authority Table "Data Theme"	This is a vocabulary by the Publications Office of the European Union. In most cases, it is assumed that the relevant value for mobility data portals is Transport, see the usage note for property `dcat:theme`.
+`mobilitydcatap:georeferencingMethod`	`dcat:Dataset`	+mobilityDCAT-AP Vocabulary "Georeferencing method"	This is a vocabulary created by mobilityDCAT-AP.
+`mobilitydcatap:networkCoverage`	`dcat:Dataset`	+mobilityDCAT-AP Vocabulary "Network coverage"	This is a vocabulary created by mobilityDCAT-AP.
+`mobilitydcatap:transportMode`	`dcat:Dataset`	+mobilityDCAT-AP Vocabulary "Transport mode" (recommended) +mobilityDCAT-AP Vocabulary "Mobility service"	This is a vocabulary created by mobilityDCAT-AP to specify which type of vehicle is relevant for the dataset. It is RECOMMENDED to specify also relevant values from the Mobility Service vocabulary defined by mobilityDCAT-AP, which allows to describe the type of mobility service associated with the dataset (e.g., sharing, hiring, transport, etc.). See also the usage note for property `mobilitydcatap:transportMode`.
+`mobilitydcatap:intendedInformationService`	`dcat:Dataset`	+mobilityDCAT-AP Vocabulary "Intended information service"	This is a vocabulary created by mobilityDCAT-AP.
+`mobilitydcatap:mobilityDataStandard`	`dcat:Distribution`	+mobilityDCAT-AP Vocabulary "Mobility data standard"	This is a vocabulary created by mobilityDCAT-AP.
+`mobilitydcatap:applicationLayerProtocol`	`dcat:Distribution`	+mobilityDCAT-AP Vocabulary "Application layer protocol"	This is a vocabulary created by mobilityDCAT-AP.
+`dct:type`	`dct:RightsStatement`	+mobilityDCAT-AP Vocabulary "Conditions for access and usage"	This is a vocabulary created by mobilityDCAT-AP.

Usage expectation:

The property is RECOMMENDED to use as range values codes from the controlled vocabulary. This means other values are tolerated. Validation systems SHOULD produce warnings.

Property URI	Used for Class	Vocabulary name and URI	Usage note
`dct:type`	`foaf:Agent`	ADMS publisher type vocabulary	This is a vocabulary "Publisher Type", based on the [ADMS] specification.
`dct:spatial` `dct:spatial` `dct:spatial`	`dcat:Catalog` `dcat:Dataset` `dcat:DatasetSeries`	EU Authority Table "Continent" EU Authority Table "Countries and territories" EU Authority Table "Places" GeoNames geographical database EU Taxonomy "Nomenclature of Territorial Units for Statistics" (NUTS)	The EU Authority Tables 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 EU Authority Tables or Geonames, NUTS URIs may be used.
`dct:publisher` `dct:publisher` `dct:publisher` `dct:publisher`	`dcat:Catalog` `dcat:CatalogRecord` `dcat:Dataset` `dcat:DatasetSeries`	EU Authority Table "Corporate body"	This is a vocabulary 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.
+`mobilitydcatap:communicationMethod`	`dcat:Distribution`	+mobilityDCAT-AP Vocabulary "Communication method"	This is a vocabulary created by mobilityDCAT-AP.
`dct:license`	`dcat:Distribution`	EU Authority Table "Licence"	This is a vocabulary by the Publications Office of the European Union, newly referenced by mobilityDCAT-AP.

This section aligns with the section of the same name in [DCAT-AP-v3.0.1].

Accessibility in the context of mobilityDCAT-AP is limited to information about the technical format of distributions of datasets. There are three format-related properties cnt:characterEncoding, dct:format and mobilitydcatap:mobilityDataStandard providing information that can be used to determine what software can be deployed to process the data. See the Wiki page on Format information for further guidance on these three properties. 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 mobilityDCAT-AP.

Multilingual aspects related to mobilityDCAT-AP 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:

The string is free text. Examples are descriptions and labels. Such text may be translated into several languages.
The string is an appellation of a ‘named entity’. Examples are names of organisations or persons. These names may have parallel versions in other languages but those versions don’t need to be literal translations.

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 mobilityDCAT-AP.

This section is non-normative. This section aligns with the section of the same name in [GeoDCAT-AP-v3.0.0].

The considerations for expressing legal information follow the guidelines and approach of [DCAT-AP-v3.0.1]. Readers should consult the [DCAT-AP-v3.0.1-section-on-legal-information].

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.

This section is non-normative. This section aligns with the section of the same name in [DCAT-AP-v3.0.1].

In light of the growing importance of data, the European Commission has adopted an implementing regulation focused on high-value datasets on 21 December 2022 [EC-Regulation-2023/138-on-HVD]. The ambition of this regulation is to improve the quality, the accessibility and use of a selective number of core datasets within the public sector. To achieve this the regulation sets, among others, requirements on the metadata associated with the disclosed datasets. These requirements can be expressed as additional constraints and usage notes on mobilityDCAT-AP and are collected in an annex of [DCAT-AP-v3.0.1] dedicated to the implementation of the HVD regulation [DCAT-AP-High-Value-Datasets].

This work was elaborated by NAPCORE Task 4.4 [NAPCORE-Metadata-Working-Group].

Editors of ReSpec documentation:

Valentina Carriero, Cefriel, Milano, Italy
Lina Teresa Molinas Comet, Fraunhofer Institute for Applied Information Technology FIT, Sankt Augustin, Germany
Peter Lubrich, Federal Highway and Transport Research Institute BASt, Bergisch Gladbach, Germany
Julien Martineau, Nationaal Geografisch Instituut, Brussels, Belgium
Daham Mohammed Mustafa, Fraunhofer Institute for Applied Information Technology FIT, Sankt Augustin, Germany
Ed Ooms, Nationaal Dataportaal Wegverkeer, Utrecht, the Netherlands
Mario Scrocca, Cefriel, Milano, Italy
Andrej Tibaut, University of Maribor, Maribor, Slovenia

Reviewers of ReSpec documentation, producers of technical artifacts and contributors to preparatory activities:

Hilde Austlid, Norwegian Public Roads Administration, Trondheim, Norway
Antonia Azzini, Cefriel, Milano, Italy
Jasper Beernaerts, Nationaal Geografisch Instituut, Brussels, Belgium
Tina Bollmann-Dodd, AustriaTech – Gesellschaft des Bundes für technologiepolitische Maßnahmen GmbH, Vienna, Austria
Julija Buzinske, Via Lietuva, Vilnius, Lithuania
Petr Bureš, Czech Technical University in Prague, Prague, Czech Republic
Marco Comerio, Cefriel, Milano, Italy
Darko Ilić, Bundesamt für Strassen ASTRA, Ittigen, Switzerland
Elena Eikari, Swedish Transport Administration, Sweden
Jörg Freudenstein, AlbrechtConsult GmbH, Aachen, Germany
Roman Hořeňovský, TamTam Research s.r.o. ,Březová-Oleško, Czech Republic
Mohanad Ismail, WSP, Birningham, UK
Jonas Jäderberg, Viati, Sweden
Arthur Keesen, Nationaal Dataportaal Wegverkeer, Utrecht, the Netherlands
Christoph Lange-Bever, Fraunhofer Institute for Applied Information Technology FIT, Sankt Augustin, Germany
Chrysostomos Mylonas, Centre for Research and Technology Hellas (CERTH)/Hellenic Institute of Transport (HIT), Thessaloniki, Greece
Sara Filipa Guerra De Oliveira, University of Maribor, Maribor, Slovenia
Ludger Rinsche, ]init[ AG für digitale Kommunikation , Berlin, Germany
Rodolfo Da Silva, KIOS Research and Innovation Center of Excellence, Nicosia, Cyprus
Benjamin Witsch-Kovács, AustriaTech – Gesellschaft des Bundes für technologiepolitische Maßnahmen GmbH, Vienna, Austria
Jan Vlčinský, TamTam Research s.r.o., Karviná-Ráj, Czech Republic

Other contributors and followers:

Nighat John Akhtar, Malta
Cosmin Bigică, National Company of Road Infrastructure Administration (NCRIA), Romania
Christina Faßbender, Fraunhofer Institute for Applied Information Technology FIT, Sankt Augustin, Germany
Lars-Olof Hjärp, Swedish Transport Administration, Sweden
Christian Rantzow von Huth, Vejdirektoratet, Copenhagen, Denmark
Tomasz Karnafel, Poland
Raivis Liepa, Latvian State Roads, Latvia
Sara Linhas, ARMIS, Porto, Portugal
Sebastian Pretzsch, Fraunhofer Institute for Transportation and Infrastructure Systems IVI, Dresden, Germany
András Selmeczy, Hungarian Public Roads, Budapest, Hungary
Kenneth Sørensen, Vejdirektoratet, Copenhagen, Denmark
Eva Thelisson, The Federal Department of the Environment, Transport, Energy and Communications (DETEC), Bern, Switzerland
Stephen T'Siobbel, ERTICO, Brussels, Belgium

The following properties from [mobilityDCAT-AP-v1.1.0] have been deprecated.

Elements that are deprecated will continue to be accepted until an upcoming major release of mobilityDCAT-AP. However, it is not recommended to introduce them at new mobilityDCAT-AP deployments.

Class	Property name and URI	Range	Card.	Definition	Usage note	Reuse
Catalogue	is part of `dct:isPartOf`	`dcat:Catalog`	0..1	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.		A
Catalogue Record	+creation date `dct:created`	`rdfs:Literal`	0..*	The date stamp 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 corresponds to an addition by [GeoDCAT-AP-v3.0.0].	GE
Dataset	is version of `dct:isVersionOf`	`dcat:Dataset`	0..*	This property may refer to a related dataset of which the described dataset is a version, edition, or adaptation. Corresponds to property `dcat:hasVersion` with contrary relationship.		P
Distribution	+grammar `mobilitydcatap:grammar`	`skos:Concept`	0..1	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 corresponding controlled vocabulary (now deprecated) is provided. This is a sub-property of `dct:conformsTo`.	P
Licence Document	+standard licence `dct:identifier`	`skos:Concept`	0..1	A concrete standard license.	A controlled vocabulary is provided.	A
Licence Document	+licence text `rdfs:label`	`rdfs:Literal`	0..*	The full text of a licence document, as a free text.	This property can be repeated for parallel language versions of the licence text - see 11. Accessibility and Multilingual Aspects.	A
Mobility Data Standard	+schema `mobilitydcatap:schema`	`rdfs:Resource`	0..*	The schema of the mobility data standard, as applied within the delivered content. E.g., an XSD representation of a specific DATEX II profile.	This is a sub-property of `dct:conformsTo`.	P
Rights Statement	+Additional information for access and usage `rdfs:label`	`rdfs:Literal`	0..*	This property may describe in a textual form any additional access, usage or licensing information, besides other information under classes `dct:RightsStatement` and `dct:LicenseDocument`.		P
Quality Annotation	+quality annotation target `oa:hasTarget`	`dcat:Dataset`	0..1	The target of the quality annotation, referring back to the dataset being described.	It is the inverse property of `dqv:hasQualityAnnotation` for class Dataset.	P

mobilityDCAT-AP is reusing many of the classes and properties defined by [DCAT-AP-v3.0.1]. The selection of the used classes and properties is based on the mobilityDCAT-AP Conceptual Model, defining essential metadata elements for NAPs and mobility data portals, see the documentation of the [NAPCORE-Metadata-Preparatory-Activities]. Thus, mobilityDCAT-AP is leaving out many classes/properties from DCAT-AP model, also keeping the data model compact. The following tables show an overview of classes/properties that are not used from DCAT-AP, with additional notes on the reasoning and alternative approaches.

Class Name	Class URI	Reference DCAT-AP	Note
Checksum	`spdx:Checksum`	Link	In DCAT-AP-v3.0.1, this class is only used as the range for the optional property `spdx:checksum` of class Distribution. However, in mobilityDCAT-AP, this property is not used. So, the class is without function in mobilityDCAT-AP.
Data Service	`dcat:DataService`	Link	In DCAT-AP-v3.0.1, a Data Service is a collection of operations that provides access to one or more datasets or data processing functions. After discussions in mobility DCAT-AP and an analysis of potential use cases of this class in DCAT-AP-v3.0.1, it has been decided not to introduce Data Service for the following reasons. 1. Potential use as the range to property `dcat:accessService` of class Distribution. This property might describe additional information about an end point of one distribution. However, looking at today's set-ups of NAPs and mobility data portals, the characteristics and mechanisms of a distribution's end point are sufficiently described via property `dcat:accessURL` of class Distribution. 2. Potential use as the range to property `foaf:primaryTopic` of class Catalogue Record 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, but might be used in the future when such portals also explicitly list data services.
Relationship	`dcat:Relationship`	Link	In DCAT-AP-v3.0.1, this class is only used as the range of the optional property `dcat:qualifiedRelation` of class Dataset. In mobilityDCAT-AP, this property is not used. So, the class is without function in mobilityDCAT-AP.
Activity	`prov:Activity`	Link	In DCAT-AP-v3.0.1, this class is only used as the range of the optional property `prov:wasGeneratedBy` of class Dataset. In mobilityDCAT-AP, this property is not used. So, the class is without function in mobilityDCAT-AP.
Attribution	`prov:Attribution`	Link	In DCAT-AP-v3.0.1, this class is only used as the range of the optional property `prov:qualifiedAttribution` of class Dataset. In mobilityDCAT-AP, this property is not used. So, the class is without function in mobilityDCAT-AP.
Checksum Algorithm	`spdx:ChecksumAlgorithm`	Link	In DCAT-AP-v3.0.1, this class is only used as the range of the optional property `spdx:algorithm` of class Checksum. In mobilityDCAT-AP, the entire class Checksum is not used (see above). So, the class Checksum Algorithm is without function in mobilityDCAT-AP.
Media Type	`dct:MediaType`	Link	In DCAT-AP-v3.0.1, this class is only used as the range of the optional properties `dcat:compressFormat`, `dcat:mediaType` and `dcat:packageFormat`. of class Distribution. In mobilityDCAT-AP, these properties are not used. So, the class is without function in mobilityDCAT-AP.
Policy	`odrl:Policy`	Link	In DCAT-AP-v3.0.1, this class is only used as the range of the optional property `odrl:hasPolicy` of class Distribution. In mobilityDCAT-AP, this property is not used. So, the class is without function in mobilityDCAT-AP.
Provenance	`dct:ProvenanceStatement`	Link	In DCAT-AP-v3.0.1, this class is only used as the range of the optional property `dct:provenance` of class Dataset. In mobilityDCAT-AP, this property is not used. So, the class is without function in mobilityDCAT-AP.
Role	`dcat:Role`	Link	In DCAT-AP-v3.0.1, this class is only used as the range of the optional property `dcat:hadRole` of class Relationship. In mobilityDCAT-AP, the entire class Relationship is not used (see above). So, the class Role is without function in mobilityDCAT-AP.

Class Name	Property Name	Property URI	Reference DCAT-AP	Note
Catalogue	applicable legislation	`dcatap:applicableLegislation`	Link	In mobilityDCAT-AP, a reference to an applicable legislation is only made for Datasets (see property `dcatap:applicableLegislation`), for Dataset Series (see property `dcatap:applicableLegislation`), and for Distributions (see property `dcatap:applicableLegislation`).
Catalogue	catalogue	`dcat:catalog`	Link	No use case for cross-referencing of catalogues identified for mobility data portals or NAPs.
Catalogue	creator	`dct:creator`	Link	In mobilityDCAT-AP, an agent description on the Catalogue level is only provided in property `dct:publisher`.
Catalogue	rights	`dct:rights`	Link	In mobilityDCAT-AP, rights and license information is only provided for Distributions (see property `dct:rights`).
Catalogue	service	`dcat:service`	Link	In mobilityDCAT-AP, end points of services are only provided for Distributions (see property `dcat:accessURL`).
Catalogue	temporal coverage	`dct:temporal`	Link	In mobilityDCAT-AP, we assume mobility data portals and NAPs are installed permanently.
Catalogue Record	change type	`adms:status`	Link
Catalogue Record	description	`dct:description`	Link
Catalogue Record	title	`dct:title`	Link
Dataset	access rights	`dct:accessRights`	Link	In mobilityDCAT-AP, rights and license information is only provided for Distributions (see property `dct:rights`).
Dataset	conforms to	`dct:conformsTo`	Link	In mobilityDCAT-AP, information on standards related to the content data is only provided for Distributions (see property `mobilitydcatap:mobilityDataStandard`).
Dataset	creator	`dct:creator`	Link	In mobilityDCAT-AP, information about agents related to datasets is provided via properties `dct:publisher` and `dct:rightsHolder`.
Dataset	is referenced by	`dct:isReferencedBy`	Link	In mobilityDCAT-AP, a reference to another dataset is possible via parallel property `dct:relation`.
Dataset	landing page	`dcat:landingPage`	Link	In mobilityDCAT-AP, information about the access to the content data is only provided for Distributions (see property `dcat:accessURL`).
Dataset	provenance	`dct:provenance`	Link	In mobilityDCAT-AP, information on the lineage to the content data is provided via properties `dcat:version` and`adms:versionNotes`.
Dataset	qualified attribution	`prov:qualifiedAttribution`	Link	In mobilityDCAT-AP, information about agents related to datasets is provided in properties `dct:publisher` and `dct:rightsHolder`.
Dataset	qualified relation	`dcat:qualifiedRelation`	Link	In mobilityDCAT-AP, information on how datasets are related to each other is provided in properties `dcat:hasVersion` and `dct:relation`.
Dataset	sample	`adms:sample`	Link	In mobilityDCAT-AP, information on data samples is only provided for Distributions (see property `adms:sample`).
Dataset	spatial resolution	`dcat:spatialResolutionInMeters`	Link	In mobilityDCAT-AP, such information might be provided as a free text via property `dct:description`.
Dataset	temporal resolution	`dcat:temporalResolution`	Link	In mobilityDCAT-AP, such information might be provided as a free text via property `dct:description`.
Dataset	type	`dct:type`	Link	In mobilityDCAT-AP, such information might be provided as a theme or category via properties `mobilitydcatap:mobilityTheme` and `dcat:theme`.
Dataset	was generated by	`prov:wasGeneratedBy`	Link	In mobilityDCAT-AP, information about activities related to datasets is provided in properties `dct:publisher` and `dct:rightsHolder`.
Distribution	access service	`dcat:accessService`	Link	In mobilityDCAT-AP, the class `dcat:DataService`, as well as all properties using this class as a range, are not used.
Distribution	availability	`dcatap:availability`	Link
Distribution	byte size	`dcat:byteSize`	Link
Distribution	check sum	`spdx:checksum`	Link
Distribution	compression format	`dcat:compressFormat`	Link
Distribution	has policy	`odrl:hasPolicy`	Link
Distribution	media type	`dcat:mediaType`	Link	In mobilityDCAT-AP, format information is only given via property `dct:format`.
Distribution	packaging format	`dcat:packageFormat`	Link
Distribution	spatial resolution	`dcat:spatialResolutionInMeters`	Link
Distribution	temporal resolution	`dcat:temporalResolution`	Link
Licence Document	type	`dct:type`	Link	In mobilityDCAT-AP, the type of a licence is only provided on the level of a rights statement via property `dct:type`.
Period of Time	beginning	`time:hasBeginning`	Link	In mobilityDCAT-AP, the beginning of a period is only provided via property `dcat:startDate`.
Period of Time	end	`time:hasEnd`	Link	In mobilityDCAT-AP, the end of a period is only provided via property `dcat:endDate`.

mobilityDCAT-AP does not repeat constraints that DCAT-AP 3.0.1 already defines. Where DCAT-AP constrains a property as mobilityDCAT-AP requires, that constraint is inherited and left in DCAT-AP. A constraint appears in the mobilityDCAT-AP shapes only where mobilityDCAT-AP is stricter than, or adds to, DCAT-AP — that is, to make an optional property mandatory, tighten a cardinality, add a check such as an EU language tag, or introduce a class or property DCAT-AP does not have. This keeps the shapes focused on what is specific to mobilityDCAT-AP and avoids reporting the same issue twice.

Because imported and local constraints apply together, the shapes can make a rule stricter but cannot loosen an inherited one. In the few cases where the DCAT-AP shapes are stricter than the mobilityDCAT-AP text intends, the inherited rule prevails; these are noted in the specification and raised with the DCAT-AP maintainers rather than worked around.

The controlled-vocabulary constraints are the one exception: they are kept in their own self-contained file rather than importing DCAT-AP's, because DCAT-AP's controlled-vocabulary shapes cover a different set of properties than mobilityDCAT-AP uses.

The shapes are organised by the kind of check each file performs, so that an implementer can apply the checks relevant to a given data exchange.

File	What it checks
`shapes.ttl`	Whether required properties are present, how many times they may occur, and what kind of value they take.
`ranges.ttl`	What class the value of a property belongs to.
`mdr-vocabularies.ttl`	Whether a value comes from the controlled vocabulary required for that property (10.2 Applied controlled vocabularies).
`deprecated-uris.ttl`	Whether a property deprecated in v3.0.0 is being used (A.2 Properties deprecated from previous version of mobilityDCAT-AP); reported as a warning.
`imports.ttl`	Loads the base vocabularies, including the DCAT-AP 3.0.1 shapes.
`mdr-imports.ttl`	Loads the controlled vocabularies used in 10.2 Applied controlled vocabularies.

The same property may be checked in more than one file. Update frequency, for instance, is checked for presence in shapes.ttl, for its value type in ranges.ttl, and for membership of the EU Frequency vocabulary in mdr-vocabularies.ttl.

Because the shapes reuse DCAT-AP and reference external controlled vocabularies, validation needs more than the mobilityDCAT-AP files alone. The DCAT-AP 3.0.1 shapes and the controlled vocabularies listed in the imports files have to be available to the validator; otherwise valid data can be reported as failing and some checks will not run at all. The imports.ttl and mdr-imports.ttl files list what is needed. A validator that supports these imports — such as the SEMIC SHACL validator of the Interoperable Europe Testbed — will load them and produce a complete result; the mobilityDCAT-AP shapes have been validated there against real National Access Point records.

As DCAT-AP notes, the shapes are a starting point rather than a fixed rule set. Each data exchange has its own context, and a reported constraint may not be relevant to it. Where publishers are identified by a dereferenceable URI and their details live in a separate register, for example, a check requiring an inline organisation name may not apply, even though a strict run reports it. Implementers should decide which constraints are in scope for their exchange.

The shapes distinguish two levels of result. A violation marks a mandatory requirement and should be treated as an error. A warning marks a recommended or optional requirement, or a controlled vocabulary where values from outside are tolerated, and indicates something to review rather than a failure. A validation setup should act on this distinction rather than treating every result as an error.

Further material, including worked examples and the validation workflow, is maintained in the mobilityDCAT-AP validation Wiki.

Section 1. Introduction is shortened. Generic description about mobilityDCAT-AP is now compiled at the Wikipage. See issue #59.
Section 5. Terminology used in mobilityDCAT-AP is restructured with several subsections and cleaned up, removing ambiguous terms like "Publication". See issue #51 and #52.
Section "Agent Types, Agent Roles and Contact Information" is removed. All guidance and detailed information about using organisation/personal information (including agent roles etc.) is now compiled in a new Wiki page "Organisational and personal information". See issue #228.
The Wiki section "Chapter 3: Extra explanations on specific classes and properties" has been expanded, with additional usage notes, background information and example codes. This way, the usage notes in the original class/property definitions are kept short, but refer to the relevant Wiki pages for more information. Specific Wiki references are made for classes foaf:Agent, dcat:DatasetSeries, mobilitydcatap:MobilityDataStandard, dct:LicenseDocument, dct:Location, and dct:RightsStatement.
The organisation and the layout of the elements of the ReSpec documentation are modified, with the goal of alignment with the ReSpec pages of [DCAT-AP-v3.0.1] and [GeoDCAT-AP-v3.0.0]. In particular, the class and property definitions are now under new sections 7. Main entities, 8. Supportive entities and 9. Datatypes. Further, all property tables are reformatted with new columns for "Definition", "Usage notes" and "Reusage". See issue #108.
Reorganisation of obligation settings for classes and properties. In [mobilityDCAT-AP-v1.1.0], classes and properties were classified as "mandatory", "recommended" and "optional", similar to previous versions of [DCAT-AP]. This is reorganised as follows:
- Classes are not classified any longer, adopting the approach of [DCAT-AP-v3.0.1].
- Properties are only classified as "mandatory" and "optional", thus dropping the "recommended" option. Even in [DCAT-AP-v3.0.1], the "recommended" option is only used at parts of the documentation. Without the "recommended" option, the mobilityDCAT-AP specification is simplified, also avoiding lengthy discussions how to classify individual properties.
See issue #155.
Section 10.2 Applied controlled vocabularies considers a new categorisation on the expected usage of the applied controlled vocabularies, according to [DCAT-AP-v3.0.1]. Thus, new sub-sections are provided, with different usage categories each. See issue #229.
New notion about classes and properties "not used from DCAT-AP". In [mobilityDCAT-AP-v1.1.0], several classes and properties from the original [DCAT-AP] were declared as "removed", following the former Guidelines for DCAT-AP Extensions [DCAT-AP-EG]. The term "removed" caused some confusion, so it is replaced with "not used from DCAT-AP". This term refers to classes and properties that are defined in [DCAT-AP-v3.0.1], but are not defined in mobilityDCAT-AP. These classes are compiled in a new annex A.3 Classes and properties not used from DCAT-AP. The implications of elements "not used from DCAT-AP" are further explained in a special Wiki page. See issue #130.
Appendix D (mobilityDCAT-AP example populations): the examples are replaced by a minimum and a complete population, each in Turtle, RDF/XML and JSON-LD. See issues #170 and #226.
Appendix G (mobilityDCAT-AP Validation Guidance) rewritten, and the SHACL shapes rebuilt for v3.0.0: six files (shapes, ranges, mdr-vocabularies, deprecated-uris, imports, mdr-imports) with a versioned namespace per file. They extend the [DCAT-AP-v3.0.1] shapes and add only constraints specific to mobilityDCAT-AP. File names changed, so validator configurations pointing to the [mobilityDCAT-AP-v1.1.0] files need updating. See issues #207, #227 and #248.
Appendix H (mobilityDCAT-AP Migration Guide) added. See issue #166.
Previous Appendix H (mobilityDCAT-AP Enterprise Architect files), as provided in [mobilityDCAT-AP-v1.1.0], is not provided any longer. This is due to lacking resources to maintain such files, and also the current lack of interest of stakeholders to have such files available. See issue #163.
Class additions with the goal to expand the expressiveness of mobilityDCAT-AP. These classes have been already defined in [DCAT-AP-v3.0.1] or [GeoDCAT-AP-v3.0.0], but now are also explicitly used in mobilityDCAT-AP.

Class dcat:DatasetSeries is added to reflect the new notions in [VOCAB-DCAT-3]. See issue #115.
Class vcard:Address is added to allow the necessary range for property vcard:hasAddress of class Kind.

Property additions with the goal to expand the expressiveness of mobilityDCAT-AP. These properties have been already defined in [DCAT-AP-v3.0.1] or [GeoDCAT-AP-v3.0.0], but now are also explicitly used in mobilityDCAT-AP.

Property dct:conformsTo of class Catalogue Record added. See issue #82.
Property dct:issued of class Catalogue Record added, replacing the semantically similar property dct:created. See issue #167.
Property dcat:inSeries of class Dataset added, to allow for relating a dataset to a dataset series. See issue #115.
Property foaf:page of class Dataset added. See issue #121.
Property dct:source of class Dataset added. See issue #122.
Property foaf:page of class Distribution added. See issue #89.
Property dct:language of class Distribution added. See issue #92.
Property dct:conformsTo of class Distribution added. See issue #153.
Property dct:modified of class Distribution added. See issue #94.
Property dct:issued of class Distribution added. See issue #94.
Property adms:status of class Distribution added. See issue #96.
Property dct:title of class Mobility Data Standard added. See issue #153.
Property dct:description of class Rights Statement added. See issue #165.
All 10 properties of class dcat:DatasetSeries, as defined for the same class dcat:DatasetSeries in [DCAT-AP-v3.0.1], added. Also, property mobilitydcatap:mobilityTheme of class Dataset Series added, corresponding to the same property mobilitydcatap:mobilityTheme of class Dataset. See issue #115.
All 5 properties of class vcard:Address, as defined for the same class vcard:Address in [GeoDCAT-AP-v3.0.0], added.

Other changes of existing classes:

Usage notes revised for classes foaf:Agent and vcard:Kind. See issue #61.

Other changes of existing properties:

Usage notes revised for class Location dct:Location. See issue #134.
Cardinality of property mobilitydcatap:dataFormatNotes of class Distribution changed from 0..1 to 0..*, to allow for multilingual versions of such notes. See issue #120.
Usage notes revised for property dcat:contactPoint of classes Dataset and DatasetSeries. See issue #61.
Property mobilitydcatap:mobilityDataStandard of class Distribution is defined as a sub-property of dct:conformsTo. See issue #153.
Cardinality of property mobilitydcatap:mobilityDataStandard of class Distribution changed from 1..1 to 1..*, to allow for information about an applied common mobility data standard PLUS information about individual/national/content-specific profiles or representations of the applied standard. See issue #153.
Usage notes revised for property mobilitydcatap:mobilityDataStandard of class Distribution. See issue #153.
New semantic concept for property dct:conformsTo of class Mobility Data Standard: Label changed from "standard name" to "conforms to". Range changed from skos:Concept to dct:Standard. Cardinality changed from "0..1" to "0..*". Usage notes revised. See issue #153.
Range for property oa:hasBody of class Quality Annotation: changed from previously rdfs:Literal to rdfs:Resource. See issue #230.

Changes in classes and properties, with the goal of alignment with the [DCAT-AP-v3.0.1] and [GeoDCAT-AP-v3.0.0] data models. See issue #18.

Classes aligned with the [DCAT-AP-v3.0.1] data model:

Class skos:Concept is renamed from previously "Category".
Class skos:ConceptScheme is renamed from previously "Category Scheme".

Properties aligned with the [DCAT-AP-v3.0.1] data model:

Property foaf:homepage of class Catalogue: range changed from previously rdfs:Resource to foaf:Document.
Property dcat:dataset of class Catalogue: cardinality relaxed from previously "1..*" to "0..*".
Property dct:spatial of class Catalogue: label changed from previously "spatial/geographic" to "geographical coverage".
Property foaf:primaryTopic of class Catalogue Record: range changed from previously dcat:Dataset to dcat:Resource.
Property dcatap:applicableLegislation of class Dataset: property is now directly reused from DCAT-AP v3. Previously it was an addition by mobilityDCAT-AP. In this context, the range of this property is changed from previously skos:Concept to eli:LegalResource.
Property dcat:hasVersion of class Dataset: URI changed from previously dct:hasVersion to dcat:hasVersion.
Property dcat:version of class Dataset: URI changed from previously owl:versionInfo to dcat:version.
Property dcatap:applicableLegislation of class Distribution: property added (reason: compliance with the spec [DCAT-AP-High-Value-Datasets]).
Property dct:rights of class Distribution: cardinality relaxed from previously "1..1" to "1..*".
Property locn:geometry of class Location: range changed from previously "rdfs:Literal typed as gsp:wktLiteral or gsp:gmlLiteral" to locn:Geometry.
Property dcat:version of class Mobility Data Standard: URI changed from previously owl:versionInfo to dcat:version.
Property dcat:endDate of class Period of Time: range changed from previously "rdfs:Literal typed as xsd:date or xsd:dateTime" to a new datatype Temporal Literal.
Property dcat:startDate of class Period of Time: range changed from previously "rdfs:Literal typed as xsd:date or xsd:dateTime" to a new datatype Temporal Literal.

Properties aligned with the [GeoDCAT-AP-v3.0.0] data model:

Property locn:address of class Agent: cardinality fixed from previously "0..*" to "0..1".
Property org:memberOf of class Agent: cardinality fixed from previously "0..*" to "0..1".
Property foaf:mbox of class Agent: cardinality fixed from previously "0..*" to "0..1". Also, the range changed from previously owl:Thing to rdfs:Resource.
Property foaf:phone of class Agent: cardinality fixed from previously "0..*" to "0..1". Also, the range changed from previously owl:Thing to rdfs:Resource.
Property dct:identifier of class Catalogue: cardinality relaxed from previously "0..1" to "0..*".
Property geodcatap:referenceSystem of class Dataset: URI changed from previously dct:conformsTo. Also, the range changed from previously dct:Standard to skos:Concept.
Property vcard:hasEmail of class Kind: range changed from previously owl:Thing to vcard:Email.
Property vcard:hasEmail of class Kind: cardinality fixed from previously "1..*" to "1..1".
Property vcard:fn of class Kind: cardinality fixed from previously "1..*" to "1..1".
Property vcard:hasURL of class Kind: range changed from previously owl:Thing to rdfs:Resource.
Property vcard:hasTelephone of class Kind: range changed from previously owl:Thing to rdfs:Resource.

Deprecations of properties:

Property dct:isPartOf of class Catalogue is deprecated, being an inverse property to dct:hasPart. This adheres to the [DCAT-AP-v3.0.1-Note-on-Inverse-Properties], recommending not to use the inverse of properties.
Property dct:isVersionOf of class Dataset is deprecated, being an inverse property to dcat:hasVersion. This adheres to the [DCAT-AP-v3.0.1-Note-on-Inverse-Properties], recommending not to use the inverse of properties.
Property oa:hasTarget of class Quality Annotation is deprecated, being an inverse property to dqv:hasQualityAnnotation. This adheres to the [DCAT-AP-v3.0.1-Note-on-Inverse-Properties], recommending not to use the inverse of properties.
Property dct:created of class Catalogue Record is deprecated. See issue #167.
Property mobilitydcatap:grammar of class Distribution is deprecated. See issue #90.
Property mobilitydcatap:schema of class Mobility Data Standard is deprecated. See issue #153.
Property dct:identifier of class License Document is deprecated. See issue #165.
Property rdfs:label of class License Document is deprecated. See issue #165.
Property rdfs:label of class Rights Statement is deprecated. See issue #165.

Relabeling of classes and properties as "not used from DCAT-AP":

Classes spdx:Checksum, dcat:DataService, dct:MediaType, dct:ProvenanceStatement, dcat:Relationship do exist in [DCAT-AP-v3.0.1], and were also listed in [mobilityDCAT-AP-v1.1.0] for compatibility reasons. However, they are without function in mobilityDCAT-AP, so they are labeled as "not used from DCAT-AP". This also applies to all properties belonging to the above classes. See A.3 Classes and properties not used from DCAT-AP.
Property dcat:accessService of class Distribution does exist in [DCAT-AP-v3.0.1], and was also listed in [mobilityDCAT-AP-v1.1.0] for compatibility reasons. However, the class dcat:DataService, as well as all properties using this class as a range, are without function in mobilityDCAT-AP, so they are labeled as "not used from DCAT-AP". See A.3 Classes and properties not used from DCAT-AP.
Property dct:isReferencedBy of class Dataset does exist in [DCAT-AP-v3.0.1] and was also listed in [mobilityDCAT-AP-v1.1.0]. For ambiguity reasons, it is not used in mobilityDCAT-AP v3, so it is labeled as "not used from DCAT-AP". See A.3 Classes and properties not used from DCAT-AP. See issue #193.

Property dct:source added under optional properties for Class Catalogue Record. This property was used at DCAT-AP v2.0.1, but removed in mobilityDCAT-AP 1.0.1. However, it is used again for harvesting use cases, see the usage note for dct:source. See issue #57.
Cardinality of property "schema" changed from 0..1 to 0..n. Reason: allow for naming multiple schemas. See issue #56
Property dct:conformsTo added under optional properties for Class Mobility Data Standard. This property describes the name of the mobility data standard. This property is used when a custom instance of class mobilitydcatap:MobilityDataStandard is defined, see the usage note for this property. See issue #65.
Errata and editorial improvements:

Corrected usage note for property cnt:characterEncoding (now linking to IANA register [IANA-CHARACTER-SETS]). See issue #34.
Corrected all figures showing UML diagrams (new arrow types). See issue #37.
Corrected reference to [NUTS-CODES] under controlled vocabularies for property dct:spatial. See issue #58.
All controlled vocabularies that are referenced at class and property descriptions are now directly hyperlinked to the specific controlled vocabulary. Before, a generic link to chapter 5.2 Controlled Vocabularies was only given.
several typos corrected

Appendix F (mobilityDCAT-AP Serialisation Files) added.
Appendix G (mobilityDCAT-AP Validation Guidance) added.
Appendix H (mobilityDCAT-AP Enterprise Architect files) added.
Changes in controlled vocabularies:

Frequency: The original controlled vocabulary "update frequency" by mobilityDCAT-AP is deprecated, as it is not needed any longer. Only the EU Authority Table "Frequency" is now used, as it now contains all necessary values. See issue #11.
Mobility Theme: Added references to EC Delegated Regulations via additional dcatap:applicableLegislation properties for all values used in this vocabulary. This allows for an automated tagging of EC Regulations to individual datasets. See issue #8.
Conditions for access and usage: Value list extended to allow for constellations such as "License provided, free of charge". See issue #27

Ongoing refinements and additions in mobilityDCAT-AP Wikipage

Errata:
- UML class diagram corrected
- Class mobilitydcatap:MobilityDataStandard was sometimes misspelled as mobilitydcatap:mobilityDataStandard, corrected
- Property mobilitydcatap:mobilityDataStandard of class dcat:Distribution had the range skos:Concept instead of mobilitydcatap:MobilityDataStandard, corrected
- URL linking to Controlled Vocabulary "http://publications.europa.eu/resource/authority/licence" repaired
- text at the beginning of the properties section was leading to a wrong directory with examples, removed (examples are now published under Appendix D)
- several typos corrected
SHACL file updated:
- validations for the controlled vocabularies added (so that the user does not have to add such specifications to their metadata)
- all constraints (Mandatory, Recommended, Optional) added (previously only the Mandatory ones were covered)
UML Class Diagram with focus on mandatory classes and properties added, see section 2.2 mobilityDCAT-AP Overview
Appendix C (mobilityDCAT-AP minimum profile) added
Appendix D (mobilityDCAT-AP example populations) added
Appendix E (mobilityDCAT-AP Wikipage) added

Document completely re-written starting from the [DCAT-AP-v2.0.1] and [GEODCAT-AP-v2.0.0] specifications, with the purpose of using a consistent document structure across DCAT-AP specifications.

[ADMS]: Joinup. Asset Description Metadata Schema (ADMS). European Commission. URL: https://joinup.ec.europa.eu/solution/asset-description-metadata-schema-adms
[BCP47]: Tags for Identifying Languages. Addison Phillips; Mark Davis. IETF. September 2009. Best Current Practice. URL: https://www.rfc-editor.org/info/bcp47
[CLDR]: CLDR - Unicode Common Locale Data Repository. BCP47, transform_mt.xml. UNICODE Consortium. URL: https://github.com/unicode-org/cldr/blob/main/common/bcp47/transform_mt.xml
[CNT]: Representing Content in RDF. 2 February 2017. URL: https://www.w3.org/TR/Content-in-RDF/
[CONNEG]: Apache Web Server: content negotiation. Apache Foundation. URL: http://httpd.apache.org/docs/current/content-negotiation.html
[CORE-LOCATION-VOCABULARY]: Core Location Vocabulary. SEMIC. 06 May 2024. URL: https://semiceu.github.io/Core-Location-Vocabulary/releases/2.1.0/
[CORE-ORGANIZATION-ONTOLOGY]: Core organization ontology. 16 January 2014. URL: https://www.w3.org/TR/vocab-org/
[DataCite-Metadata-Schema]: DataCite Metadata Schema. DataCite. 3 March 2026. URL: https://schema.datacite.org/
[DCAT-AP]: DCAT-AP. European Commission. URL: https://op.europa.eu/en/web/eu-vocabularies/dcat-ap
[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
[DCAT-AP-guideline-spatial]: How should dct:spatial and dct:Location be used?. SEMIC. URL: https://joinup.ec.europa.eu/release/how-should-dctspatial-and-dctlocation-be-used
[DCAT-AP-High-Value-Datasets]: DCAT-AP High Value Datasets. SEMIC. 25 October 2024. URL: https://semiceu.github.io/DCAT-AP/releases/3.0.0-hvd/
[DCAT-AP-Implementation-Guidelines]: DCAT-AP implementation guidelines. SEMIC. 11 December 2015. URL: https://interoperable-europe.ec.europa.eu/collection/semic-support-centre/solution/dcat-application-profile-implementation-guidelines
[DCAT-AP-Reuse-Guidelines]: DCAT-AP Reuse Guidelines. SEMIC. 17 June 2026. URL: https://semiceu.github.io/DCAT-AP-reuse-guidelines/
[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-v3.0.1]: DCAT-AP 3.0.1. SEMIC. 27 October 2025. URL: https://semiceu.github.io/DCAT-AP/releases/3.0.1/
[DCAT-AP-v3.0.1-Examples-for-Dataset-Series]: DCAT-AP v3.0.1 Examples for Dataset Series. SEMIC. 27 October 2025. URL: https://semiceu.github.io/DCAT-AP/releases/3.0.1/#example-dataset-series
[DCAT-AP-v3.0.1-Note-on-Inverse-Properties]: DCAT-AP v3.0.1 Note on Inverse Properties. SEMIC. 27 October 2025. URL: https://semiceu.github.io/DCAT-AP/releases/3.0.1/#inverse-properties
[DCAT-AP-v3.0.1-Requirements-for-Controlled-Vocabularies]: DCAT-AP v3.0.1 Requirements for Controlled Vocabularies. SEMIC. 27 October 2025. URL: https://semiceu.github.io/DCAT-AP/releases/3.0.1/#requirements-for-controlled-vocabularies
[DCAT-AP-v3.0.1-section-on-legal-information]: DCAT-AP v3.0.1 Section on Legal Information. SEMIC. 27 October 2025. URL: https://semiceu.github.io/DCAT-AP/releases/3.0.1/#legal-information
[DCAT-AP-v3.0.1-Usage-guide-on-Dataset-Series]: DCAT-AP v3.0.1 Usage guide on Dataset Series. SEMIC. 27 October 2025. URL: https://semiceu.github.io/DCAT-AP/releases/3.0.1/#usage-guide-on-dataset-series
[DCTERMS]: DCMI Metadata Terms. DCMI Usage Board. DCMI. 20 January 2020. DCMI Recommendation. URL: https://www.dublincore.org/specifications/dublin-core/dcmi-terms/
[DOI]: Digital Object Identifier. DOI. URL: http://www.doi.org/
[EC-Regulation-2023/138-on-HVD]: Commission Implementing Regulation (EU) 2023/138 of 21 December 2022 laying down a list of specific high-value datasets and the arrangements for their publication and re-use. European Commission. URL: https://eur-lex.europa.eu/eli/reg_impl/2023/138/oj/eng
[EC-Regulation-2023/1804-on-AFIR]: Regulation (EU) 2023/1804 of the European Parliament and of the Council of 13 September 2023 on the deployment of alternative fuels infrastructure, and repealing Directive 2014/94/EU. European Commission. URL: https://eur-lex.europa.eu/eli/reg/2023/1804/oj
[EC-Regulation-2024/490-on-MMTIS]: Commission Delegated Regulation (EU) 2024/490 of 29 November 2023 amending Delegated Regulation (EU) 2017/1926 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. European Commission. URL: https://eur-lex.europa.eu/eli/reg_del/2024/490/oj/eng
[ELI-Ontology]: European Legislation Identifier (ELI) Standard. EU Publications Office. URL: https://op.europa.eu/documents/3938058/11669184/eli.owl/
[ELI-Standard]: European Legislation Identifier (ELI) Standard. EU Publications Office. URL: https://op.europa.eu/en/web/eu-vocabularies/eli
[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/
[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
[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/2.0.0/
[GeoDCAT-AP-v3.0.0]: GeoDCAT-AP - Version 3.0.0. European Commission. 04 October 2024. URL: https://semiceu.github.io/GeoDCAT-AP/releases/3.0.0/
[IANA-CHARACTER-SETS]: Character Sets. IANA. URL: https://www.iana.org/assignments/character-sets/
[IANA-Media-Types]: IANA Media Types. IANA. URL: https://www.iana.org/assignments/media-types/media-types.xhtml
[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
[ISO-8601]: Date and time — Representations for information interchange. ISO/TC 154. ISO. 2019. International Standard. URL: https://www.iso.org/standard/70907.html
[mobilityDCAT-AP-v1.1.0]: mobilityDCAT-AP v1.1.0. NAPCORE Consortium. 17 January 2025. URL: https://mobilitydcat-ap.github.io/mobilityDCAT-AP/releases/1.1.0/index.html
[NAPCORE]: Website of the NAPCORE project. NAPCORE Consortium. URL: https://napcore.eu/
[NAPCORE-Information-about-NAPs]: NAPCORE information about National Access Points (NAPs). NAPCORE Consortium. URL: https://napcore.eu/description-naps/
[NAPCORE-Information-about-National-Bodies]: NAPCORE information about National Bodies. NAPCORE Consortium. URL: https://napcore.eu/national-bodies-3/
[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/
[NAPCORE-Metadata-Working-Group]: Information about the NAPCORE Sub-Working Group on Metadata. NAPCORE Consortium. URL: https://napcore.eu/metadata/
[NAPCORE-Quality-Frameworks]: NAPCORE-Quality-Frameworks. NAPCORE Consortium. URL: https://napcore.eu/quality/
[NUTS-CODES]: EU NUTS (Nomenclature of Territorial Units for Statistics) Vocabulary. Publications Office of the European Union. URL: https://op.europa.eu/en/web/eu-vocabularies/dataset/-/resource?uri=http://publications.europa.eu/resource/dataset/nuts
[RDF-Primer]: RDF Primer. W3C Working Group. 24 June 2014. URL: https://www.w3.org/TR/rdf11-primer/
[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/info/rfc2119/
[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/info/rfc6497/
[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/info/rfc8174/
[SEMIC-Style-Guide-for-Semantic-Engineers]: SEMIC Style Guide for Semantic Engineers. SEMIC. URL: https://semiceu.github.io/style-guide/1.0.0/index.html
[SHACL]: Shapes Constraint Language (SHACL). Holger Knublauch; Dimitris Kontokostas. W3C. 20 July 2017. W3C Recommendation. URL: https://www.w3.org/TR/shacl/
[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/
[VCARD-RDF]: vCard Ontology - for describing People and Organizations. Renato Iannella; James McKinney. W3C. 22 May 2014. W3C Working Group 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 Working Group Note. URL: https://www.w3.org/TR/vocab-adms/
[VOCAB-DCAT-3]: Data Catalog Vocabulary (DCAT) - Version 3. Simon Cox; Andrea Perego; Alejandra Gonzalez Beltran; Peter Winstanley; Riccardo Albertoni; David Browning. W3C. 22 August 2024. W3C Recommendation. URL: https://www.w3.org/TR/vocab-dcat-3/
[VOCAB-DQV]: Data on the Web Best Practices: Data Quality Vocabulary. Riccardo Albertoni; Antoine Isaac. W3C. 15 December 2016. W3C Working Group 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/
[W3ID]: Permanent Identifiers for the Web. W3C Permanent Identifier Community Group. URL: https://w3id.org/
[Web-Annotation-Data-Model]: Web Annotation Data Model. W3C. 23 February 2017. URL: https://www.w3.org/TR/annotation-model/
[WEB-ANNOTATION-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/

[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/

Class	Mandatory properties	Optional properties
+locn:Address		+locn:adminUnitL2
		+locn:postName
		+locn:adminUnitL1
		+locn:postCode
		+locn:thoroughfare
+vcard:Address		+vcard:region
		+vcard:locality
		+vcard:country-name
		+vcard:postal-code
		+vcard:street-address
foaf:Agent	foaf:name
		+locn:address
		+org:memberOf
		+foaf:mbox
		+foaf:firstName
		+foaf:phone
		+foaf:surname
		dct:type
		+foaf:workplaceHomepage
+mobilitydcatap:Assessment		+dct:issued
+mobilitydcatap:Assessment		+oa:hasBody
dcat:Catalog	dct:description
	foaf:homepage
	dct:publisher
	dcat:record
	dct:spatial
	dct:title
		dcat:dataset
		dct:hasPart
		dct:identifier
		adms:identifier
		dct:language
		dct:license
		dct:modified
		dct:issued
		dcat:themeTaxonomy
dcat:CatalogRecord	dct:issued
	dct:language
	dct:modified
	foaf:primaryTopic
		dct:conformsTo
		+dct:publisher
		dct:source
skos:Concept		skos:prefLabel
skos:Concept		+skos:inScheme
skos:ConceptScheme		dct:title
dcat:Dataset	dct:accrualPeriodicity
	dct:description
	dcat:distribution
	+mobilitydcatap:mobilityTheme
	dct:publisher
	dct:spatial
	dct:title
		dcatap:applicableLegislation
		+mobilitydcatap:assessmentResult
		dcat:contactPoint
		+mobilitydcatap:georeferencingMethod
		dcat:hasVersion
		+dqv:hasQualityAnnotation
		dct:identifier
		dcat:inSeries
		+mobilitydcatap:intendedInformationService
		dct:issued
		dcat:keyword
		dct:language
		dct:modified
		+mobilitydcatap:networkCoverage
		adms:identifier
		foaf:page
		+geodcatap:referenceSystem
		dct:relation
		+dct:rightsHolder
		dct:source
		dct:temporal
		dcat:theme
		+mobilitydcatap:transportMode
		dcat:version
		adms:versionNotes
dcat:DatasetSeries	dct:description
	dct:title
		dct:accrualPeriodicity
		dcatap:applicableLegislation
		dcat:contactPoint
		dct:publisher
		dct:issued
		+mobilitydcatap:mobilityTheme
		dct:modified
		dct:spatial
		dct:temporal
dcat:Distribution	dcat:accessURL
	dct:format
	+mobilitydcatap:mobilityDataStandard
	dct:rights
		+mobilitydcatap:applicationLayerProtocol
		+cnt:characterEncoding
		+mobilitydcatap:communicationMethod
		dct:conformsTo
		+mobilitydcatap:dataFormatNotes
		dct:description
		foaf:page
		dcat:downloadURL
		dct:issued
		dct:language
		dct:license
		dct:modified
		dcatap:applicableLegislation
		adms:sample
		adms:status
		dct:temporal
		dct:title
foaf:Document
+vcard:Email
dct:Frequency
locn:Geometry
adms:Identifier	skos:notation
vcard:Kind	vcard:hasEmail
	vcard:fn
		vcard:hasAddress
		vcard:organization-name
		vcard:hasTelephone
		vcard:hasURL
eli:LegalResource
dct:LicenseDocument
dct:LinguisticSystem
rdfs:Literal
dct:Location		dcat:bbox
		dcat:centroid
		skos:inScheme
		dct:identifier
		skos:prefLabel
		locn:geometry
dct:MediaTypeOrExtent
+mobilitydcatap:MobilityDataStandard		dct:conformsTo
		dct:title
		dcat:version
+org:Organization
dct:PeriodOfTime		dcat:endDate
dct:PeriodOfTime		dcat:startDate
+dqv:QualityAnnotation		+oa:hasBody
rdfs:Resource
dct:RightsStatement		dct:type
dct:RightsStatement		dct:description
dct:Standard

CMC section	CMC element name	Class Name	Class URI	Property Name	Property URI
2.2.1.1	Metadata date	Catalogue Record	`dcat:CatalogRecord`	listing date modification date	`dct:issued` `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:intendedInformationService`
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	+`geodcatap:referenceSystem` +`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`	geographical coverage	`dct:spatial`
2.2.4.2	Network coverage	Dataset	`dcat:Dataset`	network 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`	transport 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			grammar (deprecated property)	`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`

mobilityDCAT-AP - Version 3.0.0

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

Abstract

1. Introduction

1.1 Context

1.2 Scope description

1.3 Revision history

2. Status

3. License

4. Conformance Statement

4.1 Provider requirements

4.2 Receiver requirements

5. Terminology used in mobilityDCAT-AP

5.1 RDF core definitions

5.2 SEMIC core definitions

5.3 mobilityDCAT-AP core definitions

5.4 Namespaces

6. Overview

6.1 mobilityDCAT-AP UML diagram

7. Main entities

7.1 Agent

7.2 +Assessment

7.3 Catalogue

7.4 Catalogue Record

7.5 Catalogued Resource

7.6 Dataset

7.7 Dataset Series

7.8 Distribution

7.9 Kind

7.10 License Document

7.11 Location

7.12 +Mobility Data Standard

7.13 +Quality Annotation

8. Supportive entities

8.1 +Address (Core Location)

8.2 +Address (vCard)

8.3 Concept

8.4 Concept Scheme

8.5 Document

8.6 +Email (vCard)

8.7 Frequency

8.8 Geometry

8.9 Identifier

8.10 Legal Resource

8.11 Linguistic System

8.12 Literal

8.13 Media Type or Extent

8.14 +Organisation

8.15 Period of Time

8.16 Resource

8.17 Rights Statement

8.18 Standard

9. Datatypes

10. Controlled Vocabularies

10.1 Requirements for controlled vocabularies

10.2 Applied controlled vocabularies

10.2.1 Properties with controlled vocabularies that MUST be used for the listed properties

10.2.2 Properties with AT LEAST 1 value from the controlled vocabularies

10.2.3 Properties with a RECOMMENDED use of controlled vocabularies

11. Accessibility and Multilingual Aspects

12. Legal information

12.1 Privacy and security considerations

13. High Value Datasets

14. Acknowledgements

A. Quick Reference of Classes and Properties

A.1 Classes and Properties used in mobilityDCAT-AP

A.2 Properties deprecated from previous version of mobilityDCAT-AP

A.3 Classes and properties not used from DCAT-AP

A.3.1 Classes not used from DCAT-AP

A.3.2 Properties not used from DCAT-AP

B. Mapping to Coordinated Metadata Catalogue (CMC)

C. mobilityDCAT-AP minimum profile

D. mobilityDCAT-AP example populations

E. mobilityDCAT-AP Wikipage

F. mobilityDCAT-AP Serialisation Files

G. mobilityDCAT-AP Validation Guidance

G.1 Rationale: extend DCAT-AP, do not re-encode it

G.2 The shape files

G.3 Applying the shapes

G.4 Integrating the results