mobilityDCAT-AP is a mobility-related extension of the "DCAT Application profile for data portals in Europe" ([[DCAT-AP]]).
It allows for a structured, interoperable and harmonised way to describe and exchange metadata about data platforms and datasets with a mobility relevance.
It is compatible with the parallel specifications [[DCAT-AP-v3.0.1]] and [[GeoDCAT-AP-v3.0.0]].
This document is a product of the [[NAPCORE-Metadata-Working-Group]].
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. for representing the data topic, the data provider or the data format. It is highly recommended that the metadata management of National Access Points (NAPs) in Europe, or any other mobility data portals, is based on mobilityDCAT-AP in order to harmonise their data descriptions and ease the exchange of metadata in the mobility data ecosystem. Furthermore, this will ensure the basis for extended interoperability, among others, with other NAPs or data portals.
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 sub-working group 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.
Scope description
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
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
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.
Revision history
The revision history of the mobilityDCAT-AP specification is documented in the table below.
Status
This version is currently published as an Editor's Draft and may change before publication as a NAPCORE Recommendation.
Information about the process and the decisions involved in the creation of this specification are consultable at the Changelog - see .
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 descriptiona 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 .
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 and ,
and also summarised in section .
For the properties listed in the table in section , the associated controlled vocabularies must be used. Additional controlled vocabularies may be used.
Receiver requirements
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 and ,
and also summarised in section .
Process information for all controlled vocabularies specified in section .
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.).
Terminology used in mobilityDCAT-AP
RDF core definitions
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]].
SEMIC core definitions
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.
mobilityDCAT-AP core definitions
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.
Namespaces
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.
shows an excerpt of the UML diagram of the mobilityDCAT-AP model, showing these four central classes and their connecting properties.
Excerpt of mobilityDCAT-AP UML Class Diagram with 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.
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 (+).
Excerpt of mobilityDCAT-AP UML Class Diagram with focus on added classes and properties
shows a reduced UML diagram with classes and properties that are declared mandatory in mobilityDCAT-AP.
Excerpt of mobilityDCAT-AP UML Class Diagram with focus on mandatory classes and properties
shows a complete UML diagram with all elements used in mobilityDCAT-AP.
Complete mobilityDCAT-AP UML Class Diagram
Main entities
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 assessement 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 .
Agent
+Assessment
Catalogue
Catalogue Record
Dataset
Dataset Series
Distribution
Kind
Licence Document
Location
+Mobility Data Standard
+Quality Annotation
Supportive entities
The supportive entities are supporting the main entities in mobilityDCAT-AP. They are included because they form the range of properties.
+Address (Core Location)
+Address (vCard)
Concept
Concept Scheme
Document
+Email (vCard)
Frequency
Geometry
Identifier
Legal Resource
Linguistic System
Literal
Media Type or Extent
+Organisation
Period of Time
Resource
Rights Statement
Standard
Datatypes
The following datatypes are used within this specification.
Controlled Vocabularies
Requirements for controlled vocabularies
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]].
Applied 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.
Properties with controlled vocabularies that MUST be used for the listed properties
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.
Properties with AT LEAST 1 value from the controlled vocabularies
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.
Properties with a RECOMMENDED use of controlled vocabularies
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.
Accessibility and Multilingual Aspects
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.
Privacy and security considerations
The mobilityDCAT-AP vocabulary supports the attribution of data and metadata to various participants such as resource creators, publishers and other parties or agents, and as such defines terms that may be related to personal information. In addition, it also supports the association of rights and licenses with catalogued Resources and Distributions. These rights and licenses could potentially include or reference sensitive information such as user and asset identifiers as described in [[VOCAB-ODRL]].
Implementations that produce, maintain, publish or consume such vocabulary terms must take steps to ensure security and privacy considerations are addressed at the application level.
Acknowledgements
This work was elaborated by the NAPCORE Sub-Working Group (SWG) 4.4 [[NAPCORE-Metadata-Working-Group]].
This section provides a tabular overview of the mentioned classes and properties in mobilityDCAT-AP.
These are listed as class and property URIs, which are linked to detailed specifications in sections and .
The properties are grouped under headings "mandatory" and "optional". Properties are "mandatory", if their cardinalities are defined as "1..1" or "1..*", otherwise they are "optional".
This classification has implications on the conformance requirements, see the Conformance Statement.
For classes without further definitions of properties, only the class URI is mentioned.
Properties deprecated from previous version of mobilityDCAT-AP
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.
Classes and properties not used from DCAT-AP
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.
Classes not used from DCAT-AP
Properties not used from DCAT-AP
Mapping to Coordinated Metadata Catalogue (CMC)
A previous European activity to harmonise metadata at National Access Point was the Coordinated Metadata Catalogue (CMC) [[EU-EIP-CMC]].) This Catalogue describes a common minimum metadata set for NAP. The most recent version from 2019 contains definitions for 32 Metadata elements, including their description, types and obligation levels. These definitions are in a proprietary, human-readable format only.
The following mapping table has been prepared to show how the Metadata elements from the original Coordinated Metadata Catalogue compare to the classes and properties of mobilityDCAT-AP.
Please note that some CMC elements are mapped to 2 properties of mobilityDCAT-AP, due to semantic ambiguities of some CMC elements. When mapping such elements, the correct semantics need to be considered.
mobilityDCAT-AP minimum profile
A minimum profile describes a minimum population of mobilityDCAT-AP-compliant metadata descriptions. Such minimum population can be derived from the following documents throughout this specification:
To show how mobilityDCAT-AP can be deployed in practice, some example files have been produced. These denote how metadata descriptions can be populated using the mobilityDCAT-AP data vocabulary.
The first example is related to a real-life NAP data offering from the Swedish NAP. See the corresponding human-readable metadata description on the NAP portal.
The Swedish NAP also provides machine-readable representations of its metadata records in a proprietary DCAT-AP dialect, see the RDF/XML file for the example above.
This RDF/XML was converted into a metadata description according to the mobilityDCAT-AP v3.0.0 specification. It is fulfilling all mandatory and some recommended and optional elements from mobilityDCAT-AP v3.0.0. Within the RDF/XML example file, several comments are given regarding the original RDF/XML as follows:
OK = this element can remain from the original
PROPOSAL = this element can remain from the original; however, a proposal is given following the usage notes of mobilityDCAT-AP
MODIFIED = changed element
ADDED = new element
The above RDF/XML example population was further formatted as a TTL file. Lastly, a reduced example population is provided, only considering mandatory elements from mobilityDCAT-AP v3.0.0.
Altogether, the following files are provided as example population:
SE NAP dataset expressed in original proprietary DCAT-AP (RDF/XML)
SE NAP dataset expressed in mobilityDCAT-AP: original population (RDF/XML)
SE NAP dataset expressed in mobilityDCAT-AP: original population (TTL)
SE NAP dataset expressed in mobilityDCAT-AP: minimum population (RDF/XML)
SE NAP dataset expressed in mobilityDCAT-AP: minimum population (TTL)
These files can be retrieved in the examples directory on the GitHub repository.
Further example populations, also looking at real-life data offerings on other NAPS, will be provided in the future.
mobilityDCAT-AP Wikipage
As an addition to this specification, a "mobilityDCAT-AP Wiki" has been published. This serves as a practical orientation for users of mobilityDCAT-AP.
In particular, it guides deployers (e.g., developers and operators of NAPs and data platforms) in the implementation phase of mobilityDCAT-AP.
This includes additional explanations and examples for specific vocabulary elements, recommendations for metadata handling and exposure on individual IT systems, as well as advice on metadata quality and validation processes.
Serialisation files the allow for IT implementations of mobilityDCAT-AP are available as RDF/XML, Turtle, and JSON-LD syntaxes at this Github subfolder.
Changes since [[mobilityDCAT-AP-v1.1.0]] (17 January 2025)
Section is shortened .
Generic description about mobilityDCAT-AP is now compiled at the Wikipage.
See issue #59.
Section 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 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 , and .
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 lenghty discussions how to classify individual properties.
Section 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 terms 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 .
The implications of elements "not used from DCAT-AP" are further explained in a special Wiki page.
See issue #130.
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.
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.
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.
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.
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".
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 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:version of class Dataset: URI changed from previously owl:versionInfo to dcat:version.
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",
at the same time range changed from previously owl:Thing to rdfs:Resource.
Property foaf:phone of class Agent: cardinality fixed from previously "0..*" to "0..1",
at the same time 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,
at the same time 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 dct:identifier of class Licence Document is deprecated.
See issue #165.
Property rdfs:label of class Licence Document is deprecated.
See issue #165.
Property rdfs:label of class Rights Statementt 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 .
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 .
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 .
See issue #193.
Changes since mobilityDCAT-AP 1.0.1 (04 April 2024)
Cardinality of property "schema" changed from 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.
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.
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.
Changes since mobilityDCAT-AP 1.0.0 (16 October 2023)
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)
Starting point of mobilityDCAT-AP 1.0.0 (01 January 2023)
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.
