mobilityDCAT-AP is a mobility-related extension of the DCAT application profile for data portals in Europe (DCAT-AP) [DCAT-AP]. It allows for a structured, interoperable and harmonised way to describe and exchange metadata about datasets and data services with a mobility relevance.
This document is a product of sub-working group 4.4 of the NAPCORE project [NAPCORE] consortium.
The views expressed in this document are purely those of the Author(s) and may not, in any circumstances, be interpreted as stating an official position of the European Commission.
The NAPCORE consortium does not guarantee the accuracy of the information included in this study, nor does it accept any responsibility for any use thereof.
Reference herein to any specific products, specifications, process, or service by trade name, trademark, manufacturer, or otherwise does not necessarily constitute or imply its endorsement, recommendation, or favouring by the NAPCORE consortium.
All care has been taken by the author to ensure that s/he has obtained, where necessary, permission to use any parts of manuscripts, including illustrations, maps, and graphs, on which intellectual property rights already exist from the titular holder(s) of such rights or from her/his or their legal representative.
Status of This Document
This section describes the status of this
document at the time of its publication. Other documents may supersede
this document.
Publication as a Recommendation has received the endorsement of the Working Group.
The Working Group recommends the wide deployment of this specification.
This is a draft document and may be updated, replaced
or obsoleted by other documents at any time. It is inappropriate to cite this
document as other than work in progress.
This document presents version 1.0.1 of the specification for mobilityDCAT-AP, a mobility-related extension of the DCAT application profile for data portals in Europe (DCAT-AP) [DCAT-AP]. mobilityDCAT-AP aims to provide a structured, interoperable and harmonised approach to describing and exchanging metadata about datasets and about access for such datasets related to mobility, and in particular related to Intelligent Transport Systems (ITS). Its primary goal is to enhance the cross-border and cross-sectorial discoverability of ITS- and mobility-related datasets published on relevant data portals.
For this purpose, mobilityDCAT-AP introduces an RDF vocabulary and the corresponding RDF syntax, building upon the foundations of the original [DCAT-AP], while extending and customizing it for the mobility sector.
1.1 Context
Digitalisation in the mobility domain often implies that various data assets from various actors in the mobility system are made discoverable and accessible. Accordingly, internet portals for mobility data have been developed all over the world in recent years. These portals often have specific spatial or thematic coverage, e.g., exposing public-transport timetable data for one specific region. In addition, legal obligations, such as those established through the European Union's National Access Points (NAPs) [NAPCORE-NAPs], mandate the creation and population of such portals.
Metadata is a crucial building block for the accessibility and reusability of datasets within NAPs and other mobility data portals. However, unlike other domains like bibliography, there is currently no established common metadata approach across different mobility data portals. A common metadata approach can act as an important infrastructure and reference basis for providing harmonious and homogenous ITS- and mobility-related data descriptions across Europe, thus accelerating the easiness of searching, discovering, and accessing the proper data resources through the operated relevant data portals.
To serve this need, a dedicated Working Group within the EU-funded project NAPCORE [NAPCORE-Metadata-Working-Group] has been tasked with defining and maintaining a common metadata schema for all NAPs in Europe and other mobility data portals. Starting from the analysis of the European recommendations for the interoperability of data catalogues, the Working Group has defined a roadmap for the design, implementation and publication of the metadata schema.
The roadmap is explained in detail at [NAPCORE-Metadata-preparatory-activities]. It consists of five key steps: (1) gathering of requirements from experts and transport stakeholders, (2) definition of a conceptual model, (3) implementation of the conceptual model as a proper metadata scheme, (4) documentation of the scheme and provision of guidelines, and (5) hosting and publication of all outputs. The conceptual model contains definitions of essential metadata elements for mobility data portals. Further, this model is linked to established metadata specifications, particularly DCAT-AP. Moreover, the conceptual model serves as the foundation for a formal metadata specification as an extension to DCAT-AP, called mobilityDCAT-AP.
mobilityDCAT-AP enables harmonised, platform-independent metadata descriptions both in human-readable and machine-readable formats. The latter one ensures seamless integration of mobility-related platforms with third party systems by enabling the automated import and export of metadata via, for example, an API. As a specification based on the Resource Description Framework (RDF) schema, mobilityDCAT-AP leverages semantic technologies, enabling advanced querying and inference capabilities based on metadata. Following its release in the summer of 2023, this specification is being promoted for wide-scale usage in mobility data portals. To ensure its acceptance and sustainability, formal maintenance and governance structures have been established. Additionally, the development of a cross-border metadata registry will be demonstrated that will make use of mobilityDCAT-AP and provide for it a proof of concept.
mobilityDCAT-AP provides precise and unambiguous metadata designations for any data offering with mobility relevance, e.g. for representing the data topic, the data provider or the data format. It is highly recommended that the metadata management of National Access Points (NAPs) in Europe, or any other mobility data portals, is based on mobilityDCAT-AP in order to harmonise their data descriptions and ease the exchange of metadata in the mobility data ecosystem. Furthermore, this will ensure the basis for extended interoperability, among others, with other NAPs or data portals.
This work has been carried out in the context of sub-working group 4.4 of the [NAPCORE] project. NAPCORE is an EU-cofunded Programme Support Action under the GRANT AGREEMENT No MOVE/B4/SUB/2020-123/SI2.852232. This Programme Support Action aims at supporting the implementation of Delegated Regulations under Directive 2010/40/EU [EC-ITS-Directive], focusing on making infrastructure, safety, traffic, and travel data accurate and accessible to various user types, such as transport authorities or service providers through NAPs. It will stimulate and promote the coordinated provision of Intelligent Transport Systems (ITS) data through NAPs, thereby enhancing the quality of services that are based on this data.
1.2 Scope of this version: Preparatory Activities and Initial Release
This document aims to present the initial release of mobilityDCAT-AP, building upon preceding preparatory activities that include requirement analysis, a roadmap development and conceptual modeling. For detailed information about these preparatory activities, please refer to the relevant documentation at [NAPCORE-Metadata-preparatory-activities].
As [DCAT-AP], the Application Profile specified in this document is based on the specification of the Data Catalog Vocabulary (DCAT), originally developed under the responsibility of the Government Linked Data Working Group [GLD] at W3C, and significantly revised in 2020 by the W3C Dataset Exchange Working Group [DXWG]. DCAT is an RDF [RDF11-CONCEPTS] vocabulary designed to facilitate interoperability between data catalogues published on the Web. mobilityDCAT-AP incorporates additional classes and properties from other well-known vocabularies are re-used, where necessary.
This document, beyond what is defined in Conformance Statement, does not cover implementation issues such as data exchange mechanisms and the expected behavior of systems implementing mobilityDCAT-AP.
The Application Profile purpose is to facilitate data exchange. Therefore, the classes and properties defined in this document are only relevant for the data to be exchanged. There are no specific requirements for the systems involved in the data exchange process to implement particular technical environments, as long as they can export and import metadata in RDF, in conformance with mobilityDCAT-AP.
1.3 A DCAT-AP extension: Enhancing DCAT-AP for Mobility
mobilityDCAT-AP designed as an extension of DCAT-AP in conformance with the guidelines for the creating of DCAT-AP extensions [DCAT-AP-EG]. The DCAT-AP Application Profile, upon which this document is based, is version 2.0.1. of 8 June, 2020 [DCAT-AP-v2.0.1]. According to the same principles, DCAT-AP is in itself an extension of DCAT.
It is important to consider this dependency on the DCAT-AP specifications when reading and implementing mobilityDCAT-AP. The corresponding specifications should be consulted to address any gaps or missing information in this document.
Comparing mobilityDCAT-AP to [DCAT-AP-v2.0.1], the following editions have been made:
Introduction of new classes
Change to obligation levels for some existing classes in DCAT-AP
Addition of new properties to existing classes in DCAT-AP, including newly created properties
Change to obligation levels for some existing properties in DCAT-AP
Removal of certain optional or recommended properties from DCAT-AP
Refinement of usage notes for existing classes and properties from DCAT-AP, to address the special considerations in the context of mobility data portals
Reference to additional controlled vocabularies, including newly created controlled vocabularies
The class and property additions aim to capture some specific characteristics and features of mobility data, when exposed on NAPs and mobility data portals.
Some of these class and property additions align with the parallel DCAT-AP extension [GEODCAT-AP-v2.0.0], enabling compatibility between the two extensions in terms of class and property additions.
The removal of optional or recommended properties from DCAT-AP aims to minimise the vocabulary size of mobilityDCAT-AP, avoiding any misinterpretations and multiple usage of properties among data senders.
Properties removed from [[DCAT-AP-v2.0.1] are marked with a prepended “minus” sign (-).
2. Terminology used in the Application Profile
Part of the following text has been reused and adapted from [DCAT-AP-v2.0.1].
An Application Profile is a specification that re-uses terms from one or more base standards, adding more specificity by identifying mandatory, recommended and optional elements to be used for a particular application, as well as recommendations for controlled vocabularies to be used.
A Dataset is a collection of data published or curated by a single source and available for access or download in one or more formats. In the mobility context, this might be, e.g., a data collection about static parking information for truck drivers published by a road authority.
A Data Portal is a Web-based system that contains a data catalogue with descriptions of datasets and provides services enabling the discovery and re-use of the datasets.
In the context of mobility, this might be a National Access Point addressing the EC ITS Directive [NAPCORE-NAPs]. Accordingly, a NAP aims to "...facilitate access, easy exchange and reuse of transport-related data, in order to help support the provision of EU-wide interoperable travel and traffic services to end users." It is realised as "...a database, data warehouse, data marketplace, repository, and register, web portal or similar...".
In the context of NAPs, the terms "Metadata registry", "Metadata entry", and "Publication" are often used, which are explained in the following.
A Metadata registry is a digital recording of all metadata entries in a data portal, each describing the administration, organisation, and content of individual publications, including the published datasets and the corresponding distributions. The most visible Metadata representation is the dataset descriptions in a GUI of a NAP portal.
A Metadata entry (sometimes called metadata record or metadata set) describes the administration, organisation, and content of an individual publication, including the published dataset and the corresponding distributions.
A Publication is an abstract construct that covers a dataset published by a data publisher and which has one or multiple distributions.
mobilityDCAT-AP (as well as DCAT-AP) is expressed as an RDF schema [RDF-SCHEMA]]. An RDF schema provides a data-modelling vocabulary for RDF data. It provides mechanisms for describing groups of related resources and their relationships. This is done via a class and property system.
A Class is a group of resources. Classes are themselves resources. They are often identified by IRIs and may be described using properties.
A Property is a relation between subject resources and object resources.
The following figure shows the core elements of the DCAT-AP data model, denoting how the above-mentioned terms and relations are expressed as classes and properties. This figure also shows how NAP-related terms, such as publications, are related to this class and property structure.
In the following sections, classes and properties are grouped under headings ‘mandatory’, ‘recommended’ and ‘optional’. These terms have the following meaning, relating to the potential responsibilities of metadata senders and metadata receivers.
Such metadata senders and receivers are important actors for interoperable metadata, i.e., whenever metadata is exchanged between IT systems. This is the case when a data portal has metadata import and export functions. In this case, metadata senders and receivers are individual data portals. So, the following terms refer to the capability of a data portal to provide corresponding metadata in an export function or to read them in an import function.
Mandatory class: a receiver MUST be able to process information about instances of the class; a sender MUST provide information about instances of the class.
Recommended class: a receiver MUST be able to process information about instances of the class; a sender SHOULD provide information about instances of the class; a sender of data MUST provide information about instances of the class if such information is available.
Optional class: a receiver MUST be able to process information about instances of the class; a sender MAY provide the information but is not obliged to do so.
Mandatory property: a receiver MUST be able to process the information for that property; a sender MUST provide the information for that property.
Recommended property: a receiver MUST be able to process the information for that property; a sender SHOULD provide information for that property; a sender MUST provide information for that property if such information is available.
Optional property: a receiver MUST be able to process the information for that property; a sender MAY provide the information for that property but is not obliged to do so.
The meaning of the terms MUST, MUST NOT, SHOULD and MAY in this section and in the following sections are as defined in [RFC2119].
In the given context, the term "processing" means that receivers must accept incoming data and transparently provide these data to applications and services. It does neither imply nor prescribe what applications and services finally do with the data (parse, convert, store, make searchable, display to users, etc.).
All other classes are classified as ‘Optional’ in § 3.3 Optional Classes. A further description of the optional classes is only included as a sub-section in § 4. Application Profile Properties per Class if the Application Profile specifies mandatory or recommended properties for them.
2.1 Namespaces
The namespace for mobilityDCAT-AP is: https://w3id.org/mobilitydcat-ap
The suggested namespace prefix is: mobilitydcatap
The Application Profile reuses terms from various existing specifications, following established best practices [DWBP]. The following table indicates the full list of corresponding namespaces used in this document.
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, have a mandatory obligation, in contrast to [DCAT-AP-v2.0.1]. Thus, a complete metadata set in accordance with mobilityDCAT-AP SHOULD contain at least one instance of these four classes. See also the usage notes for properties dcat:record and dcat:distribution.
Figure 2 shows a more complex UML diagram with selected classes and properties included in mobilityDCAT-AP.
It shows the four central classes (marked in orange), as explained above, as well as some supportive classes (marked in yellow).
In this diagram, the focus is on classes and properties which have been added in mobilityDCAT-AP in comparison to [DCAT-AP-v2.0.1]. All additions are marked with a prepended “plus” sign (+), and summarised in the reference table in § A.2 Classes and properties added by mobilityDCAT-AP.
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
A complete UML diagram with all elements is not shown here, but can be reconstructed from the UML diagram on [DCAT-AP-v2.0.1].
An entity (e.g., an individual or an organisation) that is associated with Catalogues, Catalogue Records, or Datasets. If the Agent is an organisation, the use of the Organization Ontology [VOCAB-ORG] is recommended. See § 7. Agent Types, Agent Roles and Contact Information for a discussion on Agent types, roles and properties.
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.
A description of a metadata entry in the mobility data portal, referring to one dataset and its distributions published on the portal. mobilityDCAT-AP assumes that metadata records are essential in mobility data portals, so the obligation of this class is raised to “mandatory”, comparing to [DCAT-AP-v2.0.1].
A category of a dataset, i.e. a specific subject, theme, or a class about its content. mobilityDCAT-AP recommends to use the Category as the primary descriptor of a Dataset's subject, so the obligation of this class is raised to “mandatory”, comparing to [DCAT-AP-v2.0.1].
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.
A distribution describes the data formats and communication methods for a dataset. There may be one or multiple distributions for one dataset. For example, the same dataset (e.g. static parking information for truck drivers) can be provided in different ways e.g. as downloadable zip file or as XML using a SOAP web service. These are two distributions based on one dataset.
in [DCAT-AP-v2.0.1], this class has been classified as ‘Recommended’, to allow for cases that a particular Dataset does not have a Distribution, i.e. . However, for the context of mobility data portals, it can be expected that all datasets have one or more Distributions. Thus, the obligation of class Distribution is raised to mandatory, comparing to [DCAT-AP-v2.0.1].
A literal value such as a string or integer; Literals may be typed, e.g. as a date according to xsd:date. Literals that contain human-readable text have an optional language tag as defined by [BCP47].
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.
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.
An assessment procedure by an external organisation. This organisation MAY be a National Body in the context of EU Delegated Regulations. EU Delegated Regulations require Member States to set up procedures to assess the compliance of the Delegated Regulations, e.g. regarding the provisioning of data via a NAP. These assessment processes are handled by National Bodies [NAPCORE-NB] and installed individually in each Member State.
A value that allows the contents of a file to be authenticated. This class allows the results of a variety of checksum and cryptographic message digest algorithms to be represented.
An identifier in a particular context, consisting of the string that is the identifier; an optional identifier for the identifier scheme; an optional identifier for the version of the identifier scheme; an optional identifier for the agency that manages the identifier scheme
A description following the [VCARD-RDF] specification, e.g. to provide telephone number and e-mail address for a contact point. Note that the class vcard:Kind is the parent class for the four explicit types of vCards (vcard:Individual, vcard:Organization, vcard:Location, vcard:Group).
A statement of any changes in ownership and custody of a resource since its creation that are significant for its authenticity, integrity, and interpretation
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.
The administrative area of an Address of the Agent. Depending on the country, this corresponds to a province, a county, a region, or a state.
0..1
+city
locn:postName
rdfs:Literal
The city of an Address of the Agent.
0..1
+country
locn:adminUnitL1
rdfs:Literal
The country of an Address of the Agent.
0..1
+postal code
locn:postCode
rdfs:Literal
The postal code of an Address of the Agent.
0..1
+street address
locn:thoroughfare
rdfs:Literal
The street name and civic number of an Address of the Agent.
0..1
4.2 Agent
Class name
Agent
Obligation
Mandatory
URI
foaf:Agent
Usage note
An entity (e.g., an individual or an organisation) that is associated with Catalogues, Catalogue Records, or Datasets. If the Agent is an organisation, the use of the Organization Ontology [VOCAB-ORG] is recommended. See § 7. Agent Types, Agent Roles and Contact Information for a discussion on Agent types, roles and properties.
This property contains a name of the Agent. This property can be repeated for different versions of the name (e.g. the name in different languages) - see § 8. Accessibility and Multilingual Aspects.
1..n
4.2.2 Recommended property for Agent
Property
URI
Range
Usage note
Card.
type
dct:type
skos:Concept
This property refers to a type of the Agent that makes the Catalogue, Catalogue Record, Data Service, or Dataset available
0..1
4.2.3 Optional properties for Agent
Note
Property
URI
Range
Usage note
Card.
+address
locn:address
locn:Address
This property MAY be used to specify the postal address of the Agent.
This property SHOULD be used to provide the email address of the Agent, specified using fully qualified mailto: URI scheme [RFC6068]. The email SHOULD be used to establish a communication channel to the agent.
If the agent is of type person, this property SHOULD be used to specify the surname of the Agent, see section 7.
0..1
+URL
foaf:workplaceHomepage
rdfs:Resource
This property MAY be used to specify the Web site of the Agent.
0..1
4.3 +Assessment
Class name
Assessment
Obligation
Optional
URI
mobilitydcatap:Assessment
Usage note
An assessment procedure by an external organisation. This organisation MAY be a National Body in the context of EU Delegated Regulations. EU Delegated Regulations require Member States to set up procedures to assess the compliance with the applicable Delegated Regulations, e.g. regarding the provisioning of data via a NAP. These assessment processes are handled by National Bodies [NAPCORE-NB] and installed individually in each Member State.
The information is optional and needed for the documentation of the assessment procedure. It MAY be an internal information, only visible for assessment organisations or other authorised users.
Reference
4.3.1 Optional properties for Assessment
Note
Property
URI
Range
Usage note
Card.
+assessment date
dct:issued
rdfs:Literal typed as xsd:date or xsd:dateTime
This property MAY be used to describe the date of the latest assessment procedure.
0..1
+assessment result
oa:hasBody
rdfs:Resource
This property MAY be used to describe the result of the latest assessment procedure, in form of a URL linking to further details or results. Alternatively, textual information MAY be provided using the Embedded Textual Body construction of the Web Annotation Data Model [Web-Annotation-Data-Model], which allows to specify text formats and languages which might be relevant for multilingual purposes.
0..1
4.4 Catalogue
Class name
Catalogue
Obligation
Mandatory
URI
dcat:Catalog
Usage note
A concrete mobility data portal, i.e, a web portal, where mobility-related datasets and their distributions are described via metadata and discoverable for data users.
This property links the mobility data portal with a dataset that is described at the mobility data portal. This is a direct link from the mobility data portal to a dataset. However, in mobilityDCAT-AP, datasets SHOULD be linked indirectly, i.e., via the metadata record of this dataset. Thus, it is also mandatory to use the property dcat:record.
1..n
description
dct:description
rdfs:Literal
This property contains a free-text, individual name of the mobility data platform itself. This property MAY be repeated for parallel language versions of the description - see § 8. Accessibility and Multilingual Aspects.
1..n
homepage
foaf:homepage
rdfs:Resource
This property refers to a Web page that acts as the main page for the mobility data portal.
The obligation of this property is raised to “mandatory”, comparing to [DCAT-AP-v2.0.1].
1..1
publisher
dct:publisher
foaf:Agent
This property refers to an organisation, if applicable a person, which is responsible for creation and maintenance of the mobility data platform. This organisation is the direct contact for platform users, who have questions or issues about the platform and its system. This information is mandatory and should correspond to the information in the disclaimer of the platform website.
1..1
record
dcat:record
dcat:CatalogRecord
This property refers to a metadata record that is part of the mobility data portal. mobilityDCAT-AP assumes that metadata records are essential in mobility data portals, so the obligation of this property is raised to “mandatory”, comparing to [DCAT-AP-v2.0.1].
1..n
spatial / geographic
dct:spatial
dct:Location
This property refers to a country code where the data platform is hosted. For National Access Points (NAPs), this corresponds to the EC Member State or a country that installs such NAP. The property might be used for analyses about available datasets per country, or to identify country-specific metadata in case metadata are federated from multiple national portals into an international portal. It is not to be mixed up with country codes used within the dataset property dct:spatial, which might be different.
The obligation of this property is raised to “mandatory”, comparing to [DCAT-AP-v2.0.1].
1..n
title
dct:title
rdfs:Literal
This property contains a name given to the mobility data portal. This property can be repeated for parallel language versions of the name - see § 8. Accessibility and Multilingual Aspects.
1..n
4.4.2 Recommended properties for Catalogue
Property
URI
Range
Usage note
Card.
language
dct:language
dct:LinguisticSystem
This property refers to a 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 metadata is provided in multiple languages - see § 8. Accessibility and Multilingual Aspects. A controlled vocabulary § 5.2 Controlled vocabularies to be used is provided.
0..n
licence
dct:license
dct:LicenseDocument
This property refers to the licence under which the Catalogue can be used or reused.
0..1
release date
dct:issued
rdfs:Literal typed as xsd:date or xsd:dateTime
This property contains the date of formal issuance (e.g., publication) of the Catalogue.
0..1
themes
dcat:themeTaxonomy
skos:ConceptScheme
This property refers to a knowledge organization system used to classify the mobility data portal's Datasets.
0..n
update / modification date
dct:modified
rdfs:Literal typed as xsd:date or xsd:dateTime
This property contains the most recent date on which the Catalogue was modified.
0..1
4.4.3 Optional properties for Catalogue
Note
Note
Property
URI
Range
Usage note
Card.
has part
dct:hasPart
dcat:Catalog
This property refers to a related Catalogue that is part of the described mobility data portal. This property could be used to link the mobility data portal to another data portal, by e.g. harvesting metadata from this other portal into the mobility data portal.
0..n
+identifier
dct:identifier
rdfs:Literal
This property MAY contain an identifier for the mobility data portal. Allows a unique identification of the individual portal and is used for referencing, e.g., when exchanging metadata between mobility data portals.
This property SHOULD populated by the URI used within the RDF statement (via rdf:about).
This property refers to a related Catalogue in which the described mobility data portal is physically or logically included.
This property could be used to link the mobility data portal to another data portal, by e.g. harvesting metadata from the mobility data portal into this other portal.
0..1
+other identifier
adms:identifier
adms:Identifier
This property MAY be used as an additional identifier, besides dct:identifier. It MAY be referring to a dedicated, EU-wide identificator system of NAPS or other portals, to be introduced in the future.
0..1
4.5 Catalogue Record
Class name
Catalogue Record
Obligation
Mandatory
URI
dcat:CatalogRecord
Usage note
A description of a metadata entry in the mobility data portal, referring to one dataset and its distributions published on the portal. mobilityDCAT-AP assumes that metadata records are essential in mobility data portals, so the obligation of this class is raised to “mandatory”, comparing to [DCAT-AP-v2.0.1].
This property contains the date stamp (date and time) when the metadata entry was created for the first time. It SHOULD be generated by the system, whenever a platform user enters the metadata entry.
This property refers to a language used in the textual metadata describing titles, descriptions, etc. of the metadata entry. The value MAY be generated automatically by the NAP system, corresponding to the currently used language in the user interface. Some portals offer multilingual user interfaces, e.g., in the local language and additionally in English. For multiple languages - see § 8. Accessibility and Multilingual Aspects. A controlled vocabulary § 5.2 Controlled vocabularies to be used is provided.
1..n
primary topic
foaf:primaryTopic
dcat:Dataset
This property links the metadata entry to the dataset described in the entry.
1..1
update / modification date
dct:modified
rdfs:Literal typed as xsd:date or xsd:dateTime
This property contains the date stamp (date and time) when the metadata entry was last modified. It SHOULD be generated by the system, whenever a platform user updates the metadata entry. If there has been no update yet, the value from the property "creation date" SHOULD be taken.
1..1
4.5.2 Recommended properties for Catalogue Record
Note
4.5.3 Optional properties for Catalogue Record
Note
Note
Property
URI
Range
Usage note
Card.
+publisher
dct:publisher
foaf:Agent
This property refers to an entity (an organisation or a person), which is responsible for creation and maintenance of the metadata entry on the data platform. This entity is the direct contact for the data platform operators or data-searching users, who have questions or issues about the metadata entry. This information can be natively created by a data platform, then corresponding to the entity that is registered to the data platform and has the role of a metadata creator. This information can be also harvested from other portals. It should include, as a minimum, the name and email address of the entity. The information might be identical to the property “Publisher” of the corresponding dataset.
A category of a dataset, i.e. a specific subject, theme, or a class about its content.
The category is described via a categorisation scheme, i.e. a classification or a taxonomy. Such scheme lists all potential categories, see class "Category Scheme".
In mobilityDCAT-AP, this class SHOULD only be used in the context of a dataset dcat:theme. In other contexts, e.g. under [geoDCAT-AP-v2.0.0], this might also be used to describe the theme of a Catalogue or Data Service.
This property contains a preferred label of the Category. This property can be repeated for parallel language versions of the label - see § 8. Accessibility and Multilingual Aspects.
1..n
4.6.2 Optional property for Category
Note
Property
URI
Range
Usage note
Card.
+category scheme
skos:inScheme
skos:ConceptScheme
This property MAY be used to specify the Category Scheme to which the Category belongs.
A value that allows the contents of a file to be authenticated. This class allows the results of a variety of checksum and cryptographic message digest algorithms to be represented.
This property identifies the algorithm used to produce the subject Checksum. Currently, SHA-1 is the only supported algorithm. It is anticipated that other algorithms will be supported at a later time.
1..1
checksum value
spdx:checksumValue
rdfs:Literal typed as xsd:hexBinary
This property provides a lower case hexadecimal encoded digest value produced using a specific algorithm.
1..1
-->
4.9 Data Service
Class name
Data Service
Obligation
Optional
URI
dcat:DataService
Usage note
A collection of operations that provides access to one or more datasets or data processing functions.
For mobilityDCAP-AP, it was discussed if and how this class should be used. In fact, some mobility data are offered via sophisticated systems, such as APIs or broker interfaces, in contrast to simple downloadable files.
The following advice is based on the guideline provided in [DCAT-AP-v2.1.0-Guideline-Dataservices], and an analysis on how the class dcat:DataService is embedded in the [DCAT-AP-v2.0.1] UML model. Three usage options for dcat:DataService are identified:
This construct allows that class dcat:DataService describes additional information, e.g., about an end point, related to one distribution. This, in fact, MAY be useful to describe a dedicated (but optional) data service related to one distribution.
However, looking at today's set-ups of NAPs and mobility data portals, any metadata about the characteristics and mechanisms of a distribution channel MAY ALSO be sufficiently described as properties of class dcat:Distribution. In particular, information provided by property dcat:endpointDescription (mandatory to class dcat:DataService) can be equally provided by the property dcat:accessURL (mandatory to class dcat:Distribution).
This advice contradicts somewhat to the [DCAT-AP-v2.1.0-Guideline-Dataservices], stating that "Anything that has not the intend to provide a downloadable representation of a dataset is a data service.", for cases in which mobility data is offered via APIs, broker services etc. However, the usage note for the property dcat:accessURL also includes "...information about how to get the Dataset", which could allow for a link to one ore more APIs, broker services etc. This way, the class dcat:Distribution is considered sufficient for such cases.
Class dcat:DataService would then linking to one or more datasets "...that this data service can distribute". Thus, this property connects the Data Service to the Dataset.
The following figure shows how this contruct, containing above points 1. and 2., is represented in a UML diagram.
Figure 4 Excerpt of mobilityDCAT-AP UML Class Diagram with relations to class DataService
This implies a metadata entry about one Data Service. However, all analysed mobility data portals, including NAPs, store only metadata about datasets, and not about data services. Thus, such relationship is irrelevant for mobilityDCAT-AP as of today. This construct might be used in the future when such portals also explicitely list data services.
Altogether, class dcat:DataServiceMAY be used for the contruct explained above, but seems to be a rather unnecessary addition to the data model in NAPs and mobility data portals, looking at their set-ups today. It might be more relevant in the future, when data services are more explicit items to be exposed in NAPs or mobility data portals. For this reason, any properties, as associated to class dcat:DataService in [DCAT-AP-v2.0.1], are kept in mobilityDCAT-AP.
The root location or primary endpoint of the Service (an IRI).
1..n
title
dct:title
rdfs:Literal
This property contains a name given to the Data Service. This property can be repeated for parallel language versions of the name - see § 8. Accessibility and Multilingual Aspects.
1..n
4.9.2 Recommended properties for Data Service
Property
URI
Range
Usage note
Card.
endpoint description
dcat:endpointDescription
rdfs:Resource
This property contains a description of the Data Services available via the endpoints, including their operations, parameters etc. The property gives specific details of the actual endpoint instances, while dct:conformsTo is used to indicate the general standard or specification that the endpoints implement.
0..n
serves dataset
dcat:servesDataset
dcat:Dataset
This property refers to a Dataset that this Data Service can distribute.
0..n
4.9.3 Optional properties for Data Service
Property
URI
Range
Usage note
Card.
access rights
dct:accessRights
dct:RightsStatement
This property MAY include information regarding access or restrictions based on privacy, security, or other policies.
For INSPIRE metadata, this property SHOULD be used with the URIs of the "Limitations on public access" code list operated by the INSPIRE Registry [INSPIRE-LPA].
0..1
description
dct:description
rdfs:Literal
This property contains a free-text account of the Data Service. This property can be repeated for parallel language versions of the description - see § 8. Accessibility and Multilingual Aspects.
0..n
licence
dct:license
dct:LicenseDocument
This property contains the licence under which the Data Service is made available.
0..1
4.10 Dataset
Class name
Dataset
Obligation
Mandatory
URI
dcat:Dataset
Usage note
A dataset is a collection of data, published or curated by a single source, and available for access or download at the mobility data portal in one or more distributions. In the context of mobility-related data exchange, this might be, e.g., a data collection about static parking information for truck drivers, published by a road authority.
This property contains more information about the dataset as a brief, free-text description. It is used only for a brief overview, because free-text fields are unsuitable for searches, due to spelling mistakes, different wordings and other aspects. The categorisation and other aspects about the dataset are described within other properties of the dataset.
This property can be repeated for parallel language versions of the description - see § 8. Accessibility and Multilingual Aspects. The language versions should correspond to property dct:language of class Catalogue Record. I.e., if more than one language is provided as a metadata language, there should be as many language versions for the description.
1..n
dataset distribution
dcat:distribution
dcat:Distribution
This property links the dataset to an available distribution.
In mobilityDCAT-AP, it is mandatory that each dataset has at least one distribution. Thus, the obligation of this property is raised to “mandatory”, compared to [DCAT-AP-v2.0.1].
1..n
frequency
dct:accrualPeriodicity
dct:Frequency
This property describes how often the delivered content is updated. This information tells a data consumer, how often it is updated on the on the data platform, so the data consumer might align the frequency of data retrieval accordingly.
For data services, e.g., data feeds, the frequency should correspond to the technical upload / data push frequency. For static datasets, it should correspond to the expected change frequency (see property dct:modified). The frequency might be a specific time interval, or a general remark such as “updated on occurrence”. A controlled vocabulary § 5.2 Controlled vocabularies to be used is provided.
The obligation of this property is raised to “mandatory”, compared to [DCAT-AP-v2.0.1].
1..1
+mobility theme
mobilitydcatap:mobilityTheme
skos:Concept
This property refers to the mobility-related theme (i.e., a specific subject, category, or type) of the delivered content. A dataset may be associated with multiple themes. A theme is important for data seekers who are interested in a particular type of data content.
The theme is described via a controlled vocabulary in two hierarchy levels: The 1st level is a mandatory field labelled "Data content category", describing the classification of the data content on an aggregated level. The 2nd level is an optional field labelled “Data content sub category”, detailing the "Data content category" via one or several sub-categories. When entering the metadata for one dataset, the data provider would first select one or several options of a "Data content category", and then optionally details this with one or more options of corresponding “Data content sub category”. The platform must be able to handle the dependencies between these two levels, i.e., match the allowed options between the 1st and 2nd level.
This property is a sub-property of dcat:theme, which is also a further, recommended property of Dataset. To distinguish the both theme properties, it is recommended to label mobilitydcatap:mobilityTheme as "Mobility Theme", and dcat:theme as "EU Open Data Theme".
The subject of a dataset MAY also be described via a property dcat:keyword. However, the usage of "mobility theme" is preferred, to avoid ambiguity and uncontrolled theme descriptions.
1..n
spatial / geographic coverage
dct:spatial
dct:Location
This property refers to a geographic region that is covered by the delivered content.
There are different options how to describe the geographic region under the class Location, see § 4.16 Location. One of these options MUST be used, as the geographic reference is essential for data seekers.
Thus, the obligation of this property is raised to “mandatory”, compared to [DCAT-AP-v2.0.1].
1..n
title
dct:title
rdfs:Literal
This property contains a name given to the dataset in a generic term. The name should be a meaningful, unique and unambiguous label.
This property can be repeated for parallel language versions of the name - see § 8. Accessibility and Multilingual Aspects.The language versions should correspond to property dct:language of class Catalogue Record. I.e., if more than one language is provided as a metadata language, there should be as many language versions for the title.
1..n
publisher
dct:publisher
foaf:Agent
This property refers to an entity (company and person) that publishes the corresponding dataset. This entity is responsible for the provisioning of a dataset. The entity also concludes a contract, if applicable.
This information can be natively created by a data platform, then corresponding to the entity that is registered to the data platform and has the role of a data publisher. This information can be also harvested from other portals. The information might be identical to the property dct:publisher of class Catalogue Record and/or dct:rightsHolder of class Dataset.
The obligation of this property is raised to “mandatory”, compared to [DCAT-AP-v2.0.1].
To establish a contact with a company or person responsible for the datase, the recommended property dcat:contactPointSHOULD be used.
1..1
4.10.2 Recommended properties for Dataset
Note
Property
URI
Range
Usage note
Card.
+georeferencing method
mobilitydcatap:georeferencingMethod
skos:Concept
This property SHOULD be used to specify the georeferencing method used in the dataset. A controlled vocabulary § 5.2 Controlled vocabularies to be used is provided, denoting commonly used georeferencing methods for mobility data.
0..n
contact point
dcat:contactPoint
vcard:Kind
This property contains contact information that can be used for communication with a company or person responsible for the dataset. Such contact is important for any questions or issues about a dataset and its provisioning, which might raised by a platform user or a platform operator. The provided contact information, such as a personal name and email address, MAY NOT be exposed to platform users, but MAY be anonymously used via, e.g. a contact button on the GUI that triggers an email to the contact point.
0..n
keyword / tag
dcat:keyword
rdfs:Literal
This property contains 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-dependend and make data search difficult. Instead, usage of mobility-related properties with Controlled Vocabularies is recommended, in particular dcat:theme, 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.
0..n
+network coverage
mobilitydcatap:networkCoverage
skos:Concept
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 [EU-TEN-T].
This property SHOULD be used to specify the spatial reference system used in the dataset. Spatial reference systems SHOULD be specified by using the corresponding URIs from the “EPSG coordinate reference systems” register operated by OGC [OGC-EPSG]. A controlled vocabulary § 5.2 Controlled vocabularies to be used is provided.
This property refers to 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. It is also responsible for any statements about the data quality (if applicable, see property dqv:hasQualityAnnotation) and/or the relevance to legal frameworks (if applicable, see property dcatap:applicableLegislation).
This entity is the direct contact for the platform operator or data consumers, who have questions or issues about the contents of a dataset.
The Rights Holder will be in many cases identical with the Publisher information for class Dataset (see property dct:publisher) and/or for class Catalogue Record (see property dct:publisher). In this case, the contact 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 refers to the generic theme (i.e., a specific subject, category, or type) of the delivered content. A dataset may be associated with multiple themes.
The category is described via a controlled vocabulary "Data Themes" by the Publications Office of the European Union [EUV-THEMES]. In most cases, it is assumed that the relevant value from this EU vocabulary is "Transport" [EUV-THEMES-TRANSPORT]. The controlled vocabulary § 5.2 Controlled vocabularies to be used is provided.
0..n
temporal coverage
dct:temporal
dct:PeriodOfTime
This property refers to 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).
0..n
+transport mode
mobilitydcatap:transportMode
skos:Concept
This property describes the transport mode that is covered by the delivered content. Data can be valid for more than one mode, so a multiple choice should be applied.
This property MAY refer to one or several legal frameworks being relevant for the dataset, e.g., an EC Delegated Regulation which constitutes the purpose of the corresponding data platform (here called National Access Point/NAP), or some other international or national frameworks, e.g., Open Data regulations.
For European legal frameworks, it is recommended to use the European Legislation Identifier [ELI] to refer to legislation whenever possible.
This property is derived from the DCAT-AP HVD extension [DCAT-AP-HVD].
0..n
+assessment result
mobilitydcatap:assessmentResult
mobilitydcatap:Assessment
This property MAY refer to the results and outcomes from an assessment process by some organisation, e.g., a National Body in the context of EU Delegated Regulations. EU Delegated Regulations require Member States to set up procedures to assess the compliance of the Delegated Regulations, e.g. regarding the provisioning of data via a NAP. These assessment processes are handled by National Bodies [NAPCORE-NB] and installed individually in each Member State.
The property MAY point to the most recent assessment procedure, including its date, its result as a free-text and/or a link referring to an assessment report online.
The difference to the property dqv:hasQualityAnnotation is that the latter one is provided by the data provider, while the assessment results are provided by an external organisation.
0..1
has version
dct:hasVersion
dcat:Dataset
This property MAY refer to a related dataset that is a version, edition, or adaptation of the described dataset. Corresponds to the property dct:isVersionOf, with a contrary relationship. It might be used to host multiple versions of the same dataset in the data portal, also enabling a version history. Multiple versions should be differentiated via the properties owl:versionInfo and adms:versionNotes.
0..n
identifier
dct:identifier
rdfs:Literal
This property MAY contain an identifier for the dataset. Allows a unique identification of the individual dataset and is used for referencing, e.g., when exchanging metadata between mobility data portals.
This property SHOULD populated by the URI used within the RDF statement (via rdf:about).
0..1
is referenced by
dct:isReferencedBy
rdfs:Resource
This property MAY reference, cite, or otherwise point to another, related dataset. Corresponds to the property dct:relation, with a contrary relationship. It may be a link between two individual datasets that complement each other, e.g. one dataset with static parking data, and one with dynamic parking data, both covering the same parking facilities.
0..n
is version of
dct:isVersionOf
dcat:Dataset
This property MAY refer to a related dataset of which the described dataset is a version, edition, or adaptation. Corresponds to property dct:hasVersion with contrary relationship. It might be used to host multiple versions of the same dataset in the data portal, also enabling a version history. Multiple versions should be differentiated via the properties owl:versionInfo and adms:versionNotes.
0..n
+intended information service
mobilitydcatap:intendedInformationService
skos:Concept
This property MAY describe predefined information services, which the data content is intended to support.
Such services MAY be, e.g., information services for multimodal mobility, as specified by EC Delegated Regulation 2017/1926 [EC-MMTIS-DR]. Examples of such services include “location search”, which is based on a datasets with address identifiers, or “trip plan computation”, which is based on datasets about a road network. A controlled vocabulary § 5.2 Controlled vocabularies to be used is provided.
0..n
language
dct:language
dct:LinguisticSystem
This property refers to a language of content data, if this data has a natural language embedded. Such data contents include text fields, addresses etc. This property can be repeated if there are multiple languages in the Dataset - see § 8. Accessibility and Multilingual Aspects. A controlled vocabulary § 5.2 Controlled vocabularies to be used is provided.
0..n
other identifier
adms:identifier
adms:Identifier
This property MAY be used as an additional identifier, besides dct:identifier. It MAY be referring to a dedicated, EU-wide identificator system of NAP datasets, to be introduced in the future, or other identificator systems such as MAST/ADS [MAST-ADS], [DataCite], [DOI], [EZID] or [W3ID].
0..n
related resource
dct:relation
rdfs:Resource
This property MAY reference, cite, or otherwise point to another, related dataset. Corresponds to the property dct:isReferencedBy, with contrary relationship. It may be a link between two individual datasets that complement each other, e.g. one dataset with static parking data, and one with dynamic parking data, both covering the same parking facilities.
0..n
release date
dct:issued
rdfs:Literal typed as xsd:date or xsd:dateTime
This property contains the date of formal issuance (e.g., publication) of the Dataset. This is redundant to property "created" from class "Catalogue Record" and should not be used.
0..1
update / modification date
dct:modified
rdfs:Literal typed as xsd:date or xsd:dateTime
This property MAY contain the most recent date on which the content of a dataset was changed or modified. This is redundant for high-frequency data services, e.g., via a data feed service, where the change date can be derived from the time stamp within the data feed.
0..1
version
owl:versionInfo
rdfs:Literal
This property MAY contain a version number or other version designation of the dataset. The version should be updated, whenever there are changes to the dataset noted by the property dct:modified. Together with property adms:versionNotes, this MAY also enable a change history (or version history) of the corresponding dataset, which could be hosted and published on the data platform.
It is recommended to follow W3C Data on the Web Best Practices [DWBP]. Version identifiers should enable comparison of versions and distinguishing major from minor versions, such as Semantic Versioning [SEMVER].
0..1
version notes
adms:versionNotes
rdfs:Literal
This property MAY contain a textual description of the differences between this version and a previous version of the dataset, as an addition to the property owl:versionInfo. This property can be repeated for parallel language versions of the version notes - see § 8. Accessibility and Multilingual Aspects.
0..n
+quality description
dqv:hasQualityAnnotation
dqv:QualityAnnotation
This property MAY describe any quality aspects regarding the delivered content, in particular methods, metrics/indicators and results of a quality assessment in the responsibility of the Rights Holder (see property dct:rightsHolder). This information SHOULD assist data consumers in determining the value of data, before actually accessing and processing it. Thus, the information SHOULD be publicly available. Furthermore, it can be helpful for validation processes by 3rd parties, e.g., a National Body in context of EU Delegated Regulations.
Quality aspects SHOULD be noted via a free text and/or via URLs linking to further quality information. If there is absolutely no quality information, at least a note “quality information is unknown” SHOULD be given.
If existing quality frameworks have been applied in the quality assessment, e.g., the Quality Packages from the EU EIP and NAPCORE projects [EU-EIP-QP], these frameworks should be referenced.
0..n
4.11 Distribution
Class name
Distribution
Obligation
Mandatory
URI
dcat:Distribution
Usage note
A distribution describes the data formats and communication methods for a dataset. There may be one or multiple distributions for one dataset. For example, the same dataset (e.g. static parking information for truck drivers) can be provided in different ways e.g. as downloadable zip file or as XML using a SOAP web service. These are two distributions based on one dataset.
in [DCAT-AP-v2.0.1], this class has been classified as ‘Recommended’, to allow for cases that a particular Dataset does not have a Distribution, i.e. . However, for the context of mobility data portals, it can be expected that all datasets have one or more Distributions. Thus, the obligation of class Distribution is raised to mandatory, comparing to [DCAT-AP-v2.0.1].
This property contains a URL that gives access to a Distribution of the Dataset. Depending on the type of data provision, there are different options for describing the URL.
For data services, e.g., API, broker services, data feeds, etc., the URL MAY be the end point of such service. However, if some agreements between the data provider and the data user need to be established first, the access URL may link to web page, where the access is further arranged, e.g., initiating a a subscription process. For data which can be downloaded directly, the download URL should be copied from the optional property dcat:downloadURL. For other cases, where data cannot be directly accessed or downloaded via the platform, the access URL MAY be a link to an external service or a website which enables access to the data.
This way, this property is the primary key to link to a data service. There is also specific class dcat:DataService, which can be linked via property dcat:accessService. See § 4.9 Data Service for a usage note about the class Data Service.
1..1
+mobility data standard
mobilitydcatap:mobilityDataStandard
mobilitydcatap:MobilityDataStandard
This property describes the mobility data standard, as applied for the delivered content within the Distribution. A mobility data standard, e.g., DATEX II, combines syntax and semantic definitions of entities in a certain domain (e.g., for DATEX II: road traffic information), and optionally adds technical rules for data exchange. A controlled vocabulary § 5.2 Controlled vocabularies to be used is provided, listing common mobility data standards. If no established mobility data standard is applied, an information "proprietary standard" is requested.
1..1
format
dct:format
dct:MediaTypeOrExtent
This property refers to the technical syntax of the delivered content within the Distribution. It describes the base standard that specifies syntactically correct documents. On this level, only base elements of building documents properly are specified and can be proved by syntax checks. A controlled vocabulary § 5.2 Controlled vocabularies to be used is provided.
The obligation of this property is raised to “mandatory”, compared to [DCAT-AP-v2.0.1].
There is a similar property in [DCAT-AP-v2.0.1] dcat:mediaType, which is removed in mobilityDCAT-AP. The reason is the use of Controlled vocabularies: dct:format uses the EU Authority List [EUV-FT], whereas dcat:mediaType uses the IANA media types [IANA-MEDIA-TYPES]. The first one, however, is sufficient to describe the syntaxes commonly used in mobility data portals.
1..1
rights
dct:rights
dct:RightsStatement
This property links to a Rights Statement, i.e., a statement about the intellectual property rights (IPR). As a minimum, it should include an information on the type of conditions for access and usage. A concrete (standard) license can be referred via the recommended property dct:license.
The obligation of this property is raised to “mandatory”, compared to [DCAT-AP-v2.0.1].
1..1
4.11.2 Recommended properties for Distribution
Note
Note
Property
URI
Range
Usage note
Card.
+application layer protocol
mobilitydcatap: applicationLayerProtocol
skos:Concept
This property describes the transmitting channel, i.e., the Application Layer Protocol, of the distribution. A controlled vocabulary § 5.2 Controlled vocabularies to be used is provided.
0..1
description
dct:description
rdfs:Literal
This property contains a free-text account of the Distribution. This property can be repeated for parallel language versions of the description - see § 8. Accessibility and Multilingual Aspects.
0..n
licence
dct:license
dct:LicenseDocument
This property refers to the licence under which the Distribution is made available. This SHOULD be a reference to a concrete standard license. A controlled vocabulary § 5.2 Controlled vocabularies to be used is provided.
0..1
4.11.3 Optional properties for Distribution
Note
Note
Property
URI
Range
Usage note
Card.
access service
dcat:accessService
dcat:DataService
This property refers to a Data Service that gives access to the Distribution of the Dataset.
0..n
+character encoding
cnt:characterEncoding
rdfs:Literal
This property describes the technical encoding format of the delivered content within the Distribution. It SHOULD be expressed using a character set name defined in the IANA register [IANA-CHARSETS].
This property indicates for data services, e.g., data feeds, if the data interface of the data provider system functions in a push or pull mode. A controlled vocabulary § 5.2 Controlled vocabularies to be used is provided.
This property contains a URL that is a direct link to a downloadable file in a given format.
0..1
+grammar
mobilitydcatap:grammar
skos:Concept
This property describes the technical data grammar format of the delivered content within the Distribution. It describes the standard on top of the elementary syntax that describe data structures in the dataset. A controlled vocabulary § 5.2 Controlled vocabularies to be used is provided.
This is a sub-property of dct:conformsTo.
0..1
+sample
adms:sample
rdfs:Resource
This property refers to a sample Distribution of the Dataset. A data sample allows data users to investigate the data content and data structure, without subscribing to a data feed or downloading a complete data set.
This property describes the beginning and end of the time interval when a data service, e.g., a data feed, is delivered technically via the data platform. If there is no entry it means that the publication gets valid immediately and the timestamp is the same as the metadata timestamp.
0..1
title
dct:title
rdfs:Literal
This property contains a name given to the Distribution. This property can be repeated for parallel language versions of the description - see § 8. Accessibility and Multilingual Aspects.
0..n
4.12 Document
Note
Class name
Document
Obligation
Optional
URI
foaf:Document
Usage note
A textual resource intended for human consumption that contains information, e.g., a Web page about a Dataset.
An identifier in a particular context, consisting of the string that is the identifier; an optional identifier for the identifier scheme; an optional identifier for the version of the identifier scheme; an optional identifier for the agency that manages the identifier scheme
rdfs:Literal typed with the URI of one of the members of the DataCite Resource Identifier Scheme [DataCite-RIS]
This property contains a string that is an identifier in the context of the identifier scheme referenced by its data type.
0..1
4.14 Kind
Note
Class name
Kind
Obligation
Optional
URI
vcard:Kind
Usage note
A description following the [VCARD-RDF] specification, e.g. to provide telephone number and e-mail address for a contact point. Note that the class vcard:Kind is the parent class for the four explicit types of vCards (vcard:Individual, vcard:Organization, vcard:Location, vcard:Group).
This property contains a name of the Kind. This property can be repeated for different versions of the name (e.g., the name in different languages) - see § 8. Accessibility and Multilingual Aspects.
This property MAY be used to specify the affiliation of the Kind. This property can be repeated for different versions of the name (e.g. the name in different languages) - see § 8. Accessibility and Multilingual Aspects.
A legal document, e.g., a concrete license, giving official permission to do something with a resource.
It MAY be used to concretise the generic intellectual property rights (IPR) information, as provided via class dct:RightsStatement.
However, if a concrete licence is defined for the Distribution of interest, it SHOULD be provided via this class, so a data user can assess the license conditions in machine- and human-readable formats, before using the data.
This property MAY be used to contain the full text of a Licence Document, as a free text. This MAY be used when there is no standard license that can be linked via property dct:identifier. This property can be repeated for parallel language versions of the name - see § 8. Accessibility and Multilingual Aspects.
A spatial region or named place. It can be represented via a named place (controlled vocabulary) or with geographic coordinates, according to DCAT-AP guidelines [DCAT-AP-guideline-spatial].
For mobility data portals, usage of a named place is preferred. Many mobility data providers represent public authorities such as states, regions, municipalities etc, which can be easily represented via named places. In contrast, defining of coordinates per dataset might be error-prone and inconsistent. As named spaces, identifiers SHOULD be used via property dct:identifier. These are coded via controlled vocabularies such as the EU authority tables, NUTS (Nomenclature des unités territoriales statistiques) or Geonames, see § 5.2 Controlled vocabularies to be used. Alternatively, geographic clear names MAY be used via property "skos:prefLabel".
rdfs:Literal typed as gsp:wktLiteral or gsp:gmlLiteral
This property refers to the geographic bounding box of a resource.
0..1
centroid
dcat:centroid
rdfs:Literal typed as gsp:wktLiteral or gsp:gmlLiteral
This property refers to the geographic centre (centroid) of a resource.
0..1
+geographic name
skos:prefLabel
rdfs:Literal
This property contains a preferred label of the Location. This property can be repeated for parallel language versions of the label - see § 8. Accessibility and Multilingual Aspects.
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.
4.18.1 Optional properties for Mobility Data Standard
Note
Property
URI
Range
Usage note
Card.
+version
owl:versionInfo
rdfs:Literal
This property describes the version of the mobility data standard, as applied within the delivered content. A version might be, e.g., DATEX II v3.2. This information is provided in a textual format. To avoid ambiguity, only short version identifiers SHOULD be used, e.g., only "3.2", without redundant acronyms such as "v", underscores etc.
0..1
+schema
mobilitydcatap:schema
rdfs:Resource
This property describes the schema of the mobility data standard, as applied within the delivered content. There are different options how to reference the schema. It might be a reference to a portal-internal catalogue of schemas, a reference to an individual schema (that is provided by the data publisher), or a reference to an external catalogue of schemas (like a stakeholder-based DATEX II profile published on the datex2.eu page). The data platform SHOULD keep an archive of commonly used schemas. The data provider SHOULD be able to select an applicable schema from this archive, or to upload an own, individual schema. In any case, the schema should be available as a resource.
This is a sub-property of dct:conformsTo.
0..1
4.19 Period of Time
Class name
Period of time
Obligation
Recommended
URI
dct:PeriodOfTime
Usage note
An interval of time that is named or defined by its start and end dates.
This property contains the end of the Period of Time.
0..1
start date
dcat:startDate
rdfs:Literal typed as xsd:date or xsd:dateTime
This property contains the start of the Period of Time.
0..1
Note
4.19.2 Optional properties for Period of Time
Note
4.20 Provenance Statement
Note
Class name
Provenance Statement
Obligation
Optional
URI
dct:ProvenanceStatement
Usage note
A statement of any changes in ownership and custody of a resource since its creation that are significant for its authenticity, integrity, and interpretation
An annotation about any quality aspects regarding the delivered content, in particular methods, metrics/indicators and results of a quality assessment in the responsibility of the Data Owner.
There is a similar class "Quality Measurement" in [GEODCAT-AP-v2.0.0]. Both "Quality Annotation" are "Quality Measurement" are reusing the Data Quality Vocabulary [VOCAB-DQV]. Quality Measurement is referring to concrete metrics, like sub-types of spatial resolutions being used [GEODCAT-AP-v2.0.0]. At mobility data portals, however, the practice so far is to provide some free text about quality aspects. Thus, the Quality Annotation refers to an unspecified form of quality annotation, which MAY be a free text.
This property MAY be used to describe any quality aspects regarding the delivered content, in form of a URL linking to further details or results. Alternatively, textual information MAY be provided using the Embedded Textual Body construction of the Web Annotation Data Model [Web-Annotation-Data-Model], which allows to specify text formats and languages which might be relevant for multilingual purposes.
0..1
+quality annotation target
oa:hasTarget
dcat:Dataset
This property MAY be used to describe the target of the quality annotation, referring back to the dataset being described. I.e., it is the inverse property of "dqv:hasQualityAnnotation" for class Dataset.
0..1
4.22 Relationship
Note
Class name
Relationship
Obligation
Optional
URI
dcat:Relationship
Usage note
An association class for attaching additional information to a relationship between DCAT Resources
This property refers to the function of an entity or agent with respect to another entity or resource.
1..n
relation
dct:relation
rdfs:Resource
This property refers to the resource related to the source resource.
1..n
4.23 Rights Statement
Note
Class name
Rights statement
Obligation
Mandatory
URI
dct:RightsStatement
Usage note
A statement about the intellectual property rights (IPR) held in or over a resource, a legal document giving official permission to do something with a resource, or a statement about access rights.
As a minimum, it should include an information on the type of conditions for access and usage. Information about concrete licenses can be provided via class dct:LicenseDocument.
This property SHOULD be used to indicate the conditions if any contracts, licences and/or are applied for the use of the dataset. 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 § 5.2 Controlled vocabularies to be used is provided. The values can be logically mapped with the property dct:identifier from class dct:LicenseDocument.
The following is a list of requirements that were identified for the controlled vocabularies to be recommended in this Application Profile.
Controlled vocabularies SHOULD:
Be published under an open licence.
Be operated and/or maintained by an institution of the European Union, by a recognised standards organisation or another trusted organisation.
Be properly documented.
Have labels in multiple languages, ideally in all official languages of the European Union.
Contain a relatively small number of terms (e.g. 10-25) that are general enough to enable a wide range of resources to be classified.
Have terms that are identified by URIs, with each URI resolving to documentation about the term.
Have associated persistence and versioning policies.
These criteria do not intend to define a set of requirements for controlled vocabularies in general; they are only intended to be used for the selection of the controlled vocabularies that are proposed for this Application Profile.
5.2 Controlled vocabularies to be used
In the table below, some properties are listed with controlled vocabularies that MUST be used for the listed properties. The declaration of the following controlled vocabularies as mandatory ensures a minimum level of interoperability.
Compared with [DCAT-AP-v2.0.1], mobilityDCAT-AP makes use of additional controlled vocabularies. External organisations maintain some of these additional controlled vocabularies, and others are created and maintained by mobilityDCAT-AP.
Further, mobilityDCAT-AP is removing some recommended and properties from [DCAT-AP-v2.0.1], which are linked with controlled vocabularies. Thus, these controlled vocabularies are not relevant for mobilityDCAT-AP and are not listed in the following table.
This is a vocabulary created by mobilityDCAT-AP. There are two hierarchical levels: "Data content category" (mandatory) and "Data content sub-catagory” (optional), see the usage note for property mobilitydcatap:mobilityTheme.
This is a mandatory vocabulary "Data Themes" by the Publications Office of the European Union. In most cases, it is assumed that the relevant value for mobility data portals is "Transport" [EUV-THEMES-TRANSPORT], see the usage note for property dcat:theme.
This is a mandatory vocabulary "Frequency" by the Publications Office of the European Union.
The values from this vocabulary do not cover all relevant time intervals used in mobility data portals, e.g., minute-based intervals. Thus, there is a second vocabulary created by mobilityDCAT-AP (see next row), extending this taxonomy with additional missing time intervals.
This is a mandatory vocabulary "Corporate body" by the Publications Office of the European Union. It MUST be used for European institutions and a small set of international organisations. In case of other types of organisations, national, regional or local vocabularies about organisations SHOULD be used, if available.
Values from this vocabulary MUST be used as instances of class foaf:Agent, being the range of the property dct:publisher.
EU Vocabularies Continents Named Authority List [EUV-CONT], EU Vocabularies Countries Named Authority List [EUV-COUNTRIES], EU Vocabularies Places Named Authority List [EUV-PLACES], [GEONAMES], [NUTS-CODES]
The EU Vocabularies Name Authority Lists must be used for continents, countries and places that are in those lists; if a particular location is not in one of the mentioned Named Authority Lists, [GEONAMES] URIs must be used.
In addition to the Named Authority Lists or [GEONAMES], [NUTS-CODES] URIs MAY be used.
Values from the above-mentioned vocabularies MUST be used as instances of class dct:Location, being the range of the property dct:spatial.
This is an optional vocabulary created by mobilityDCAT-AP.
5.3 Other controlled vocabularies
In [DCAT-AP-v2.0.1], chapter 5.3 and 5.4, several other controlled vocabularies are recommended for consideration, including EuroVoc, CERIF standard vocabularies, the Dewey Decimal Classification and sevaral licence-related vocabularies. For the scope of mobilityDCAT-AP, these other vocabularies have been analysed. However, none of such vocabularies has been found suitable or specific to mobility data portals, so no explicit recommendation for the usage of further vocabularies is given.
Regarding license-related vocabularies, [DCAT-AP-v2.0.1] is referencing to the vocabulary by the Open Digital Rights Language (ODRL) Initiative [VOCAB-ODRL], which seems rather complex for the purpose of mobilityDCAT-AP. Further, it refers to the Open Data Rights Statement (ODRS) Vocabulary [ODRS]. This vocabulary is introducing a central class called odrs:RightsStatement, which is semantically equal to class dct:RightsStatement from [DCAT-AP-v2.0.1]; and reusing some properties from [DCAT-AP-v2.0.1], such as dct:rights. Again, no explicit recommendation for the usage of such license-related vocabularies is given.
6. Conformance
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, MUST NOT, SHOULD, and SHOULD NOT in this document
are to be interpreted as described in
BCP 14
[RFC2119] [RFC8174]
when, and only when, they appear in all capitals, as shown here.
6.1 Provider requirements
In order to conform to this Application Profile, an application that provides metadata MUST:
Provide information for the mandatory properties specified in § 4.5.1 Mandatory properties for Catalogue Record, if descriptions of Catalogue Records are provided – please note that the provision of descriptions of Catalogue Records is optional.
Provide descriptions of Data Services, if any, of Datasets in the Catalogue, including at least the mandatory properties specified in § 4.9.1 Mandatory properties for Data Service.
Provide descriptions of all organisations involved in the descriptions of Catalogue and Datasets, including at least the mandatory properties specified in § 4.2.1 Mandatory property for Agent.
Provide descriptions of all category schemes that contain the categories that are asserted in any of the descriptions of Datasets in the Catalogue, including at least the mandatory properties specified in § 4.7.1 Mandatory property for Category Scheme.
Provide descriptions of all categories involved in the descriptions of Datasets in the Catalogue, including at least the mandatory properties specified in § 4.6.1 Mandatory property for Category.
For the properties listed in the table in § 5.2 Controlled vocabularies to be used, the associated controlled vocabularies MUST be used. Additional controlled vocabularies MAY be used.
Recommended and optional classes may have mandatory properties, but those only apply if and when an instance of such a class is present in a description.
6.2 Receiver requirements
In order to conform to this Application Profile, an application that receives metadata MUST be able to:
As stated in § 2. Terminology used in the Application Profile, "processing" means that receivers must accept incoming data and transparently provide this data to applications and services. It does neither imply nor prescribe what applications and services finally do with the data (parse, convert, store, make searchable, display to users, etc.).
7. Agent Types, Agent Roles and Contact Information
This section is non-normative.
[DCAT-AP-v2.0.1] has the following note about agent roles:
The DCAT Application Profile [...] has a single property to relate an Agent (typically, an organisation) to a Dataset. The only such ‘agent role’ that can be expressed in the current version of the profile is through the property dct:publisher (http://purl.org/dc/terms/publisher), defined as “An entity responsible for making the dataset available”. A second property is available in the DCAT recommendation, dcat:contactPoint (http://www.w3.org/TR/vocab-dcat/#Property:dataset_contactPoint), defined as “Link a dataset to relevant contact information which is provided using VCard”, but this is not an agent role as the value of this property is contact data, rather than a representation of the organisation as such.
In specific cases, for example in exchanging data among domain-specific portals, it may be useful to express other, more specific agent roles. In such cases, extensions to the base profile may be defined using additional properties with more specific meanings. ...
mobilityDCAT-AP specifies this note as follows:
According to [FOAF], an Agent (via class foaf:Agent) may be of a type of a person (via sub-class foaf:Person), an organisation (via sub-class foaf:Organization), or a group (via sub-class foaf:Group).
For mobility data portals, it is expected that organisations are the main data actors, so the type organisation SHOULD be used. A person MAY be explicitly mentioned as an agent. In this case, he or she SHOULD be attributed to an organisation via the property org:memberOf, and, additionally, attributed with the personal name via properties foaf:firstName and foaf:surname.
mobilityDCAT-AP uses the class foaf:Agent in the context of describing entities:
responsible for the creation and maintenance of the data platform;
responsible for the creation and maintenance of a metadata entry;
responsible for the provisioning of a dataset; or
responsible for the content of the data.
Thus, two different agent-role properties are used: Publisher for classes Catalogue (dct:publisher), Catalogue Record (dct:publisher), and Dataset (dct:publisher); and Rights Holder for class Dataset (dct:rightsHolder). In contrast, other agent-role properties such as dct:creator are not used.
Figure 5 shows how the potential usages of foaf:Agent are represented in a UML diagram.
Figure 5 Excerpt of mobilityDCAT-AP UML Class Diagram with focus on agent-role properties
The class foaf:Agent is used to identify the entity with the above-mentioned roles. The properties under the class foaf:Agent also allow for providing (optional) contact details.
There is one further, recommended property dct:type describing the agent's type via a controlled vocabulary. This property MAY be used to determine, among others, the hierarchy of a public authority (local, regional, national, supranational). Such organisation types are often data providers at mobility data portals, so much information is seen beneficial. However, the controlled vocabulary from [ADMS-SKOS], as proposed by [DCAT-AP-v2.0.1], is not sufficient in the mobility context. Thus, further items are added by mobilityDCAT-AP to the controlled vocabulary, see § 5.2 Controlled vocabularies to be used.
In contrast, contact details with the goal to establish a direct contact between a data provider and a data user SHOULD be provided via the property dcat:contactPoint under class dcat:Dataset.
The range of dcat:contactPoint is the class vcard:Kind. A couple of properties for this class are defined, specifying contact information. Of these properties, vcard:fn and vcard:hasEmail are mandatory. The usage note of dcat:contactPoint gives more details on how to handle such contact information.
With such concept, there might be overlaps of the contact information under the properties dct:publisher and dcat:contactPoint. Depending on the portal system, the contact information can be populated to the data portal's user registry (in case, e.g., users are required to sign in before they use the data portal and/or from a dataset-specific contact information. A recommended way is to populate all information for dct:publisher automatically from the user's registry, and to allow an optional field "contact information" (name and email) when entering dataset-specific metadata, which can be freely entered be the metadata publisher. If such optional field is not entered (or not implemented), the user registry can still be retrieved.
8. Accessibility and Multilingual Aspects
This section is non-normative.
Accessibility in the context of this Application Profile is limited to information about the technical format of distributions of datasets. The properties dcat:mediaType and dct:format provide information that can be used to determine what software can be deployed to process the data. The accessibility of the data within the datasets needs to be taken care of by the software that processes the data and is outside of the scope of this Application Profile.
Multilingual aspects related to this Application Profile concern all properties whose contents are expressed as strings (i.e. rdfs:Literal) with human-readable text. Wherever such properties are used, the string values are of one of two types:
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 this Application Profile.
9. Privacy and security considerations
The mobilityDCAT-AP vocabulary supports the attribution of data and metadata to various participants such as resource creators, publishers and other parties or agents, and as such defines terms that may be related to personal information. In addition, it also supports the association of rights and licenses with catalogued Resources and Distributions. These rights and licenses could potentially include or reference sensitive information such as user and asset identifiers as described in [VOCAB-ODRL].
Implementations that produce, maintain, publish or consume such vocabulary terms must take steps to ensure security and privacy considerations are addressed at the application level.
A.2 Classes and properties added by mobilityDCAT-AP
This version of mobilityDCAT-AP extends [DCAT-AP-v2.0.1] with 2 additional classes and 48 additional properties (some of which re-used across classes). They are listed in the following table.
B. Mapping to Coordinated Metadata Catalogue (CMC)
A previous European activity to harmonise metadata at National Access Point was the Coordinated Metadata Catalogue (CMC) [EU-EIP-CMC].) This Catalogue describes a common minimum metadata set for NAP. The most recent version from 2019 contains definitions for 32 Metadata elements, including their description, types and obligation levels. These definitions are in a proprietary, human-readable format only.
The following mapping table has been prepared to show how the Metadata elements from the original Coordinated Metadata Catalogue compare to the classes and properties of mobilityDCAT-AP.
Please note that some CMC elements are mapped to 2 properties of mobilityDCAT-AP, due to semantic ambiguities of some CMC elements. When mapping such elements, the correct semantics need to be considered.
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 v1.0.1 specification. It is fullfilling all mandatory and some recommended and optional elements from mobilityDCAT-AP v1.0.1. Within the RDF/XML example file, several comments are given regarding the original RDF/XML as follows:
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 v1.0.1.
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.
E. mobilityDCAT-AP Wikipage
As an addition to this specification, a "mobilityDCAT-AP Wiki" has been published. This serves as a practical orientation for users of mobilityDCAT-AP. In particular, it guides deployers (e.g., developers and operators of NAPs and data platforms) in the implementation phasis of mobilityDCAT-AP.
This includes additional explanations and examples for specific vocabulary elements, recommendations for metadata handling and exposure on individual IT systems, as well as advice on metadata quality and validation processes.
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
F.2 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.
F.3 Summary of changes to Application Profile classes and properties
Since this is the initial release of mobilityDCAT-AP, there are no changes yet.
