mobilityDCAT-AP is a mobility-related extension of the DCAT application profile for data portals in Europe (DCAT-AP) [[DCAT-AP]]. It allows for a structured, interoperable and harmonised way to describe and exchange metadata about datasets and data services with a mobility relevance.
This document is a product of sub-working group 4.4 of the NAPCORE project [[NAPCORE]] consortium.
Comments and queries should be sent via the issue tracker of the dedicated GitHub repository.
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.
Version | Date | Description | Action | Change Log |
---|---|---|---|---|
1.1.0 | 17/01/2025 | Minor semantic release | Publication | § H.1 Changes since mobilityDCAT-AP 1.0.1 from 04 April 2024 |
1.0.1 | 04/04/2024 | Bug fix release | Publication | § H.2 Changes since first publication of 16 October 2023 |
1.0.0 | 16/10/2023 | Recommendation | Publication | § H.3 Starting point of mobilityDCAT-AP 1.0.0 (01 January 2023) |
0.1 | 11/05/2023 | First Public Working Draft | Creation | N/A |
This document presents version 1.1.0 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.
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.
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.
mobilityDCAT-AP designed as an extension of DCAT-AP in conformance with the guidelines for the creating of DCAT-AP extensions [[DCAT-AP-EG]]. The DCAT-AP Application Profile, upon which this document is based, is version 2.0.1. of 8 June, 2020 [[DCAT-AP-v2.0.1]]. According to the same principles, DCAT-AP is in itself an extension of DCAT.
It is important to consider this dependency on the DCAT-AP specifications when reading and implementing mobilityDCAT-AP. The corresponding specifications should be consulted to address any gaps or missing information in this document.
Comparing mobilityDCAT-AP to [[DCAT-AP-v2.0.1]], the following editions have been made:
The class and property additions aim to capture some specific characteristics and features of mobility data, when exposed on NAPs and mobility data portals.
Some of these class and property additions align with the parallel DCAT-AP extension [[GEODCAT-AP-v2.0.0]], enabling compatibility between the two extensions in terms of class and property additions.
All classes and property additions are marked with a prepended “plus” sign (+) in this document, and summarised in the reference table in .
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 (-).
Part of the following text has been reused and adapted from [[DCAT-AP-v2.0.1]].
An Application Profile is a specification that re-uses terms from one or more base standards, adding more specificity by identifying mandatory, recommended and optional elements to be used for a particular application, as well as recommendations for controlled vocabularies to be used.
A Dataset is a collection of data published or curated by a single source and available for access or download in one or more formats. In the mobility context, this might be, e.g., a data collection about static parking information for truck drivers published by a road authority.
A Data Portal is a Web-based system that contains a data catalogue with descriptions of datasets and provides services enabling the discovery and re-use of the datasets.
In the context of mobility, this might be a National Access Point addressing the EC ITS Directive [[NAPCORE-NAPs]]. Accordingly, a NAP aims to "...facilitate access, easy exchange and reuse of transport-related data, in order to help support the provision of EU-wide interoperable travel and traffic services to end users." It is realised as "...a database, data warehouse, data marketplace, repository, and register, web portal or similar...".
In the context of NAPs, the terms "Metadata registry", "Metadata entry", and "Publication" are often used, which are explained in the following.
A Metadata registry is a digital recording of all metadata entries in a data portal, each describing the administration, organisation, and content of individual publications, including the published datasets and the corresponding distributions. The most visible Metadata representation is the dataset descriptions in a GUI of a NAP portal.
A Metadata entry (sometimes called metadata record or metadata set) describes the administration, organisation, and content of an individual publication, including the published dataset and the corresponding distributions.
A Publication is an abstract construct that covers a dataset published by a data publisher and which has one or multiple distributions.
mobilityDCAT-AP (as well as DCAT-AP) is expressed as an RDF schema [[RDF-SCHEMA]]]. An RDF schema provides a data-modelling vocabulary for RDF data. It provides mechanisms for describing groups of related resources and their relationships. This is done via a class and property system.
A Class is a group of resources. Classes are themselves resources. They are often identified by IRIs and may be described using properties.
A Property is a relation between subject resources and object resources.
The following figure shows the core elements of the DCAT-AP data model, denoting how the above-mentioned terms and relations are expressed as classes and properties. This figure also shows how NAP-related terms, such as publications, are related to this class and property structure.
In the following sections, classes and properties are grouped under headings ‘mandatory’, ‘recommended’ and ‘optional’. These terms have the following meaning, relating to the potential responsibilities of metadata senders and metadata receivers.
Such metadata senders and receivers are important actors for interoperable metadata, i.e., whenever metadata is exchanged between IT systems. This is the case when a data portal has metadata import and export functions. In this case, metadata senders and receivers are individual data portals. So, the following terms refer to the capability of a data portal to provide corresponding metadata in an export function or to read them in an import function.
The meaning of the terms MUST, MUST NOT, SHOULD and MAY in this section and in the following sections are as defined in [[RFC2119]].
In the given context, the term "processing" means that receivers must accept incoming data and transparently provide these data to applications and services. It does neither imply nor prescribe what applications and services finally do with the data (parse, convert, store, make searchable, display to users, etc.).
Classes are classified as ‘Mandatory’ in if they appear as the range of one of the mandatory properties in .
All other classes are classified as ‘Optional’ in . A further description of the optional classes is only included as a sub-section in if the Application Profile specifies mandatory or recommended properties for them.
The namespace for mobilityDCAT-AP is: https://w3id.org/mobilitydcat-ap
The suggested namespace prefix is: mobilitydcatap
The Application Profile reuses terms from various existing specifications, following established best practices [[?DWBP]]. The following table indicates the full list of corresponding namespaces used in this document.
Prefix | Namespace URI | Specification |
---|---|---|
adms |
http://www.w3.org/ns/adms# |
[[VOCAB-ADMS]] |
cnt |
http://www.w3.org/2011/content# |
[[CNT]] |
dcat |
http://www.w3.org/ns/dcat# |
[[VOCAB-DCAT-2]] |
dcatap |
http://data.europa.eu/r5r/ |
[[DCAT-AP]] |
dct |
http://purl.org/dc/terms/ |
[[DCTERMS]] |
dqv |
http://www.w3.org/ns/dqv# |
[[VOCAB-DQV]] |
foaf |
http://xmlns.com/foaf/0.1/ |
[[FOAF]] |
locn |
http://www.w3.org/ns/locn# |
[[CORE-LOCATION-VOCABULARY]] |
oa |
https://www.w3.org/ns/oa# |
[[WEB-ANOTATION-ONTOLOGY]] |
org |
www.w3.org/ns/org# |
[[CORE-ORGANIZATION-ONTOLOGY]] |
owl |
http://www.w3.org/2002/07/owl# |
[[OWL-REF]] |
rdf |
http://www.w3.org/1999/02/22-rdf-syntax-ns# |
[[RDF11-CONCEPTS]] |
rdfs |
http://www.w3.org/2000/01/rdf-schema# |
[[RDF-SCHEMA]] |
skos |
http://www.w3.org/2004/02/skos/core# |
[[SKOS-REFERENCE]] |
spdx |
http://spdx.org/rdf/terms# |
[[SPDX]] |
vcard |
http://www.w3.org/2006/vcard/ns# |
[[VCARD-RDF]] |
xsd |
http://www.w3.org/2001/XMLSchema# |
[[XMLSCHEMA11-2]] |
mobilityDCAT-AP extends [[DCAT-AP-v2.0.1]] by including:
These extensions are meant to provide a DCAT-AP-conformant representation of metadata specific to mobility data.
For a first orientation in mobilityDCAT-AP, these four central classes should be considered: dcat:Catalogue
, dcat:CatalogRecord
, dcat:Dataset
and dcat:Distribution
; as well as the properties connecting these four classes.
shows an excerpt of the UML diagram of the mobilityDCAT-AP model, showing these four central classes and their connecting properties.
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
.
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 .
shows a reduced UML diagram with classes and properties that are declared mandatory in mobilityDCAT-AP.
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]].
Class name |
Usage note for the Application Profile |
URI |
Reference |
---|---|---|---|
Agent |
An entity (e.g., an individual or an organisation) that is associated with Catalogues, Catalogue Records, or Datasets. If the Agent is an organisation, the use of the Organization Ontology [[VOCAB-ORG]] is recommended. See for a discussion on Agent types, roles and properties. |
|
§ Class: foaf:Agent [[FOAF]] [[VOCAB-ORG]] |
Catalogue |
A concrete mobility data portal, i.e, a web portal, where mobility-related datasets and their distributions are described via metadata and discoverable for data users. |
|
§ 6.3 Class: Catalog [[VOCAB-DCAT-2]] |
Catalogue Record |
A description of a metadata entry in the mobility data portal, referring to one dataset and its distributions published on the portal. mobilityDCAT-AP assumes that metadata records are essential in mobility data portals, so the obligation of this class is raised to “mandatory”, comparing to [[DCAT-AP-v2.0.1]]. |
|
§ 6.5 Class: Catalog Record [[VOCAB-DCAT-2]] |
Category |
A category of a dataset, i.e. a specific subject, theme, or a class about its content. mobilityDCAT-AP recommends to use the Category as the primary descriptor of a Dataset's subject, so the obligation of this class is raised to “mandatory”, comparing to [[DCAT-AP-v2.0.1]]. |
|
§ 6.10 Class: Concept [[VOCAB-DCAT-2]] |
Dataset |
A dataset is a collection of data, published or curated by a single source, and available for access or download at the mobility data portal in one or more distributions. In the context of mobility-related data exchange, this might be, e.g., a data collection about static parking information for truck drivers, published by a road authority. |
|
§ 6.6 Class: Dataset [[VOCAB-DCAT-2]] |
Distribution |
A distribution describes the data formats and communication methods for a dataset. There may be one or multiple distributions for one dataset. For example, the same dataset (e.g. static parking information for truck drivers) can be provided in different ways e.g. as downloadable zip file or as XML using a SOAP web service. These are two distributions based on one dataset. in [[DCAT-AP-v2.0.1]], this class has been classified as ‘Recommended’, to allow for cases that a particular Dataset does not have a Distribution. 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]]. |
|
§ 6.7 Class: Distribution [[VOCAB-DCAT-2]] |
Location |
A spatial region or named place. It can be represented using a controlled vocabulary or with geographic coordinates. |
|
§ Term name: Location [[DCTERMS]] |
Literal |
A literal value such as a string or integer; Literals may be typed, e.g. as a date according to |
|
§ 3.3 Literals [[RDF11-CONCEPTS]] |
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. |
|
||
Resource |
Anything described by RDF. |
|
§ 2.1 rdfs:Resource [[RDF-SCHEMA]] |
Rights statement |
A statement about the intellectual property rights (IPR) held in or over a resource, a legal document giving official permission to do something with a resource, or a statement about access rights. |
|
§ Term name: RightsStatement [[DCTERMS]] |
Class name |
Usage note for the Application Profile |
URI |
Reference |
---|---|---|---|
Category scheme |
A categorisation scheme, i.e. a classification or a taxonomy, listing all potential categories which might be used for instances of class Category. |
|
§ 6.9 Class: Concept Scheme [[VOCAB-DCAT-2]] |
Licence Document |
A legal document giving official permission to do something with a resource. |
|
§ Term name: LicenseDocument [[DCTERMS]] |
Period of time |
An interval of time that is named or defined by its start and end dates. |
|
§ Term name: PeriodOfTime [[DCTERMS]] |
Class name |
Usage note for the Application Profile |
URI |
Reference |
---|---|---|---|
A postal address of the Agent. This class addition is analogous to a class addition by [[GEODCAT-AP-v2.0.0]]. |
|
§ Class Address [[LOCN]] |
|
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. |
|
||
Checksum |
A value that allows the contents of a file to be authenticated. This class allows the results of a variety of checksum and cryptographic message digest algorithms to be represented. |
|
§ checksum [[SPDX]] |
Data Service |
A collection of operations that provides access to one or more datasets or data processing functions. |
|
§ 6.8 Class: Data Service [[VOCAB-DCAT-2]] |
Document |
A textual resource intended for human consumption that contains information, e.g., a Web page about a Dataset. |
|
§ Class: foaf:Document [[FOAF]] |
Frequency |
A rate at which something recurs, e.g., the publication of a Dataset. |
|
§ Term name: Frequency [[DCTERMS]] |
Identifier |
An identifier in a particular context, consisting of the string that is the identifier; an optional identifier for the identifier scheme; an optional identifier for the version of the identifier scheme; an optional identifier for the agency that manages the identifier scheme |
|
§ 5.2.6 Identifier [[VOCAB-ADMS]] |
Kind |
A description following the [[VCARD-RDF]] specification, e.g. to provide telephone number and e-mail address for a contact point. Note that the class |
|
§ Kind [[VCARD-RDF]] |
Linguistic system |
A system of signs, symbols, sounds, gestures, or rules used in communication, e.g. a language. |
|
§ Term name: LinguisticSystem [[DCTERMS]]] |
A media type, e.g. the format of a computer file. |
|
§ Term name: MediaType [[DCTERMS]] |
|
Provenance Statement |
A statement of any changes in ownership and custody of a resource since its creation that are significant for its authenticity, integrity, and interpretation |
|
§ Term name: ProvenanceStatement [[DCTERMS]] |
Publisher type |
A type of organisation that acts as a publisher |
|
§ 5.3.41 dcterms:type [[VOCAB-ADMS]] |
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. |
|
§ 4.2 Class: Metric [[VOCAB-DQV]] |
|
Relationship |
An association class for attaching additional information to a relationship between DCAT Resources |
|
§ 6.12 Class: Relationship [[VOCAB-DCAT-2]] |
Role |
A role is the function of a resource or agent with respect to another resource, in the context of resource attribution or resource relationships. Note it is a subclass of |
|
§ 6.13 Class: Role [[VOCAB-DCAT-2]] |
Standard |
A standard or other specification to which a Catalogue, Catalogue Record, Data Service, Dataset, or Distribution conforms. |
|
§ Term name: Standard [[DCTERMS]] |
Status |
An indication of the maturity of a Distribution or the type of change of a Catalogue Record. |
|
§ 5.2.13 Status [[VOCAB-ADMS]] |
A quick reference table of properties per class is included in .
Class name | Address (Agent) |
---|---|
Obligation | Optional |
URI |
|
Usage note |
A postal address of the Agent. |
Reference |
§ Class Address [[LOCN]] |
Property |
URI |
Range |
Usage note |
Card. |
---|---|---|---|---|
+administrative area |
|
|
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 |
|
|
The city of an Address of the Agent. |
0..1 |
+country |
|
|
The country of an Address of the Agent. |
0..1 |
+postal code |
|
|
The postal code of an Address of the Agent. |
0..1 |
+street address |
|
|
The street name and civic number of an Address of the Agent. |
0..1 |
Class name | Agent |
---|---|
Obligation | Mandatory |
URI |
|
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 for a discussion on Agent types, roles and properties. |
Reference |
§ Class: foaf:Agent [[FOAF]] [[VOCAB-ORG]] |
Property |
URI |
Range |
Usage note |
Card. |
---|---|---|---|---|
type |
|
|
This property refers to a type of the Agent that makes the Catalogue, Catalogue Record, Data Service, or Dataset available. A controlled vocabulary is provided. |
0..1 |
Class name | Assessment |
---|---|
Obligation | Optional |
URI |
|
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 |
Property |
URI |
Range |
Usage note |
Card. |
---|---|---|---|---|
+assessment date |
|
|
This property MAY be used to describe the date of the latest assessment procedure. |
0..1 |
+assessment result |
|
|
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 |
Class name | Catalogue |
---|---|
Obligation | Mandatory |
URI |
|
Usage note |
A concrete mobility data portal, i.e, a web portal, where mobility-related datasets and their distributions are described via metadata and discoverable for data users. |
Reference |
§ 6.3 Class: Catalog [[VOCAB-DCAT-2]] |
Property |
URI |
Range |
Usage note |
Card. |
---|---|---|---|---|
dataset |
|
|
This property links the mobility data portal with a dataset that is described at the mobility data portal. This is a direct link from the mobility data portal to a dataset. However, in mobilityDCAT-AP, datasets SHOULD be linked indirectly, i.e., via the metadata record of this dataset. Thus, it is also mandatory to use the property |
1..n |
description |
|
|
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 . |
1..n |
homepage |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 The obligation of this property is raised to “mandatory”, comparing to [[DCAT-AP-v2.0.1]]. |
1..n |
title |
|
|
This property contains a name given to the mobility data portal. This property can be repeated for parallel language versions of the name - see . |
1..n |
Property |
URI |
Range |
Usage note |
Card. |
---|---|---|---|---|
language |
|
|
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 . A controlled vocabulary is provided. |
0..n |
licence |
|
|
This property refers to the licence under which the Catalogue can be used or reused. |
0..1 |
release date |
|
|
This property contains the date of formal issuance (e.g., publication) of the Catalogue. |
0..1 |
themes |
|
|
This property refers to a knowledge organization system used to classify the mobility data portal's Datasets. |
0..n |
update / modification date |
|
|
This property contains the most recent date on which the Catalogue was modified. |
0..1 |
Property |
URI |
Range |
Usage note |
Card. |
---|---|---|---|---|
has part |
|
|
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 |
|
|
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 This property is analogue to an addition by [[GEODCAT-AP-v2.0.0]]. |
0..1 |
is part of |
|
|
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 |
|
|
This property MAY be used as an additional identifier, besides |
0..1 |
Class name | Catalogue Record |
---|---|
Obligation | Mandatory |
URI |
|
Usage note |
A description of a metadata entry in the mobility data portal, referring to one dataset and its distributions published on the portal. mobilityDCAT-AP assumes that metadata records are essential in mobility data portals, so the obligation of this class is raised to “mandatory”, comparing to [[DCAT-AP-v2.0.1]]. |
Reference |
§ 6.5 Class: Catalog Record [[VOCAB-DCAT-2]] |
Property |
URI |
Range |
Usage note |
Card. |
---|---|---|---|---|
+creation date |
|
|
This property contains the date stamp (date and time) when the metadata entry was created for the first time. It SHOULD be generated by the system, whenever a platform user enters the metadata entry. This property is analogue to an addition by [[GEODCAT-AP-v2.0.0]]. |
1..1 |
language |
|
|
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 . A controlled vocabulary is provided. |
1..n |
primary topic |
|
|
This property links the metadata entry to the dataset described in the entry. |
1..1 |
update / modification date |
|
|
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 |
Property |
URI |
Range |
Usage note |
Card. |
---|---|---|---|---|
+publisher |
|
|
This property refers to an entity (an organisation or a person), which is responsible for creation and maintenance of the metadata entry on the data platform. This entity is the direct contact for the data platform operators or data-searching users, who have questions or issues about the metadata entry. This information can be natively created by a data platform, then corresponding to the entity that is registered to the data platform and has the role of a metadata creator. This information can be also harvested from other portals. It should include, as a minimum, the name and email address of the entity. The information might be identical to the property “Publisher” of the corresponding dataset. This property is analogue to an addition by [[GEODCAT-AP-v2.0.0]]. |
0..1 |
source metadata |
|
|
This property is used for metadata records that are harvested from other portals. Harvesting, i.e., the automated import of metadata information from external portals, seems to be a common case for some NAPs. With these property, a data user can see, if the metadata was harvested, and from where. The property SHOULD link to a public URL of the dataset descripton on the original data portal, from where the metadata was harvested. |
0..1 |
Class name | Category |
---|---|
Obligation | Mandatory |
URI |
|
Usage note |
A category of a dataset, i.e. a specific subject, theme, or a class about its content. The category is described via a categorisation scheme, i.e. a classification or a taxonomy. Such scheme lists all potential categories, see class "Category Scheme". In mobilityDCAT-AP, this class SHOULD only be used in the context of a dataset |
Reference |
§ 6.10 Class: Concept [[VOCAB-DCAT-2]] |
Property |
URI |
Range |
Usage note |
Card. |
---|---|---|---|---|
+category scheme |
|
|
This property MAY be used to specify the Category Scheme to which the Category belongs. This property is analogue to an addition by [[GEODCAT-AP-v2.0.0]]. |
0..1 |
Class name | Category scheme |
---|---|
Obligation | Recommended |
URI |
|
Usage note |
A categorisation scheme, i.e. a classification or a taxonomy, listing all potential categories which might be used for instances of class Category. In mobilityDCAT-AP, this scheme is expressed via a controlled vocabulary for the property |
Reference |
§ 6.9 Class: Concept Scheme [[VOCAB-DCAT-2]] |
Property |
URI |
Range |
Usage note |
Card. |
---|---|---|---|---|
title |
|
|
This property contains a name of the Category Scheme. May be repeated for different versions of the name - see . |
1..n |
Class name | Checksum |
---|---|
Obligation | Optional |
URI |
|
Usage note |
A value that allows the contents of a file to be authenticated. This class allows the results of a variety of checksum and cryptographic message digest algorithms to be represented. |
Reference |
§ checksum [[SPDX]] |
Property |
URI |
Range |
Usage note |
Card. |
---|---|---|---|---|
algorithm |
|
|
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 |
|
|
This property provides a lower case hexadecimal encoded digest value produced using a specific algorithm. |
1..1 |
Class name | Data Service |
---|---|
Obligation | Optional |
URI |
|
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 1. As a range to class dcat:Distribution via property This construct allows that class 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 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 2. As a domain to class dcat:Dataset via property Class The following figure shows how this contruct, containing above points 1. and 2., is represented in a UML diagram. ![]() 3. As a range to class dcat:CatalogueRecord via property 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 |
Reference |
§ 6.8 Class: Data Service [[VOCAB-DCAT-2]] |
Property |
URI |
Range |
Usage note |
Card. |
---|---|---|---|---|
endpoint description |
|
|
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 |
0..n |
serves dataset |
|
|
This property refers to a Dataset that this Data Service can distribute. |
0..n |
Class name | Dataset |
---|---|
Obligation | Mandatory |
URI |
|
Usage note |
A dataset is a collection of data, published or curated by a single source, and available for access or download at the mobility data portal in one or more distributions. In the context of mobility-related data exchange, this might be, e.g., a data collection about static parking information for truck drivers, published by a road authority. |
Reference |
§ 6.6 Class: Dataset [[VOCAB-DCAT-2]] |
Property |
URI |
Range |
Usage note |
Card. |
---|---|---|---|---|
description |
|
|
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 . The language versions should correspond to property |
1..n |
dataset 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 |
|
|
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 The obligation of this property is raised to “mandatory”, compared to [[DCAT-AP-v2.0.1]]. |
1..1 |
+mobility theme |
|
|
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. A corresponding controlled vocabulary is provided. This property is a sub-property of The subject of a dataset MAY also be described via a property |
1..n |
spatial / geographic coverage |
|
|
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 . One of these options MUST be used, as the geographic reference is essential for data seekers. Several options of controlled vocabularies are provided. Thus, the obligation of this property is raised to “mandatory”, compared to [[DCAT-AP-v2.0.1]]. |
1..n |
title |
|
|
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 .The language versions should correspond to property |
1..n |
publisher |
|
|
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 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 |
1..1 |
Property |
URI |
Range |
Usage note |
Card. |
---|---|---|---|---|
+georeferencing method |
|
|
This property SHOULD be used to specify the georeferencing method used in the dataset. A controlled vocabulary is provided, denoting commonly used georeferencing methods for mobility data. |
0..n |
contact point |
|
|
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 |
|
|
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 |
0..n |
+network coverage |
|
|
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]]. A controlled vocabulary is provided, denoting commonly used road and infrastructure network classes. |
0..n |
+reference system |
|
|
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 is provided. This property is analogue to an addition by [[GEODCAT-AP-v2.0.0]]. |
0..n |
+rights holder |
|
|
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 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 This property is analogue to an addition by [[GEODCAT-AP-v2.0.0]]. |
0..n |
theme / category |
|
|
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]]. A controlled vocabulary is provided. |
0..n |
temporal coverage |
|
|
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 |
|
|
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. A controlled vocabulary is provided, denoting commonly used transport modes. |
0..n |
Class name | Distribution |
---|---|
Obligation | Mandatory |
URI |
|
Usage note |
A distribution describes the data formats and communication methods for a dataset. There may be one or multiple distributions for one dataset. For example, the same dataset (e.g. static parking information for truck drivers) can be provided in different ways e.g. as downloadable zip file or as XML using a SOAP web service. These are two distributions based on one dataset. in [[DCAT-AP-v2.0.1]], this class has been classified as ‘Recommended’, to allow for cases that a particular Dataset does not have a Distribution, i.e. . However, for the context of mobility data portals, it can be expected that all datasets have one or more Distributions. Thus, the obligation of class Distribution is raised to mandatory, comparing to [[DCAT-AP-v2.0.1]]. |
Reference |
§ 6.7 Class: Distribution [[VOCAB-DCAT-2]] |
Property |
URI |
Range |
Usage note |
Card. |
---|---|---|---|---|
access URL |
|
|
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 This way, this property is the primary key to link to a data service. There is also specific class |
1..1 |
+mobility data standard |
|
|
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 is provided, listing common mobility data standards. If no established mobility data standard is applied, an information "proprietary standard" is requested. |
1..1 |
format |
|
|
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 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]] |
1..1 |
rights |
|
|
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 The obligation of this property is raised to “mandatory”, compared to [[DCAT-AP-v2.0.1]]. |
1..1 |
Property |
URI |
Range |
Usage note |
Card. |
---|---|---|---|---|
+application layer protocol |
|
|
This property describes the transmitting channel, i.e., the Application Layer Protocol, of the distribution. A controlled vocabulary is provided. |
0..1 |
description |
|
|
This property contains a free-text account of the Distribution. This property can be repeated for parallel language versions of the description - see . |
0..n |
licence |
|
|
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 is provided. |
0..1 |
Property |
URI |
Range |
Usage note |
Card. |
---|---|---|---|---|
access service |
|
|
This property refers to a Data Service that gives access to the Distribution of the Dataset. |
0..n |
+character encoding |
|
|
This property describes the technical encoding format of the delivered content within the Distribution. It SHOULD be expressed using a character set name defined in the IANA register [[IANA-CHARSETS]]. This property is analogue to an addition by [[GEODCAT-AP-v2.0.0]]. This is a sub-property of |
0..1 |
+communication method |
|
|
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 is provided. |
0..1 |
+data format notes |
|
|
This property contains any additional information about the format of the delivered content within the Distribution (see the corresponding properties |
0..1 |
download URL |
|
|
This property contains a URL that is a direct link to a downloadable file in a given format. |
0..1 |
+grammar |
|
|
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 is provided. This is a sub-property of |
0..1 |
+sample |
|
|
This property refers to a sample Distribution of the Dataset. A data sample allows data users to investigate the data content and data structure, without subscribing to a data feed or downloading a complete data set. In [[DCAT-AP-v2.0.1]], there is a property |
0..n |
+temporal coverage |
|
|
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 |
|
|
This property contains a name given to the Distribution. This property can be repeated for parallel language versions of the description - see . |
0..n |
Class name | Document |
---|---|
Obligation | Optional |
URI |
|
Usage note |
A textual resource intended for human consumption that contains information, e.g., a Web page about a Dataset. |
Reference |
§ Class: foaf:Document [[FOAF]] |
Class name | Identifier |
---|---|
Obligation | Optional |
URI |
|
Usage note |
An identifier in a particular context, consisting of the string that is the identifier; an optional identifier for the identifier scheme; an optional identifier for the version of the identifier scheme; an optional identifier for the agency that manages the identifier scheme |
Reference |
§ 5.2.6 Identifier [[VOCAB-ADMS]] |
Property |
URI |
Range |
Usage note |
Card. |
---|---|---|---|---|
notation |
|
|
This property contains a string that is an identifier in the context of the identifier scheme referenced by its data type. |
0..1 |
Class name | Kind |
---|---|
Obligation | Optional |
URI |
|
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 |
Reference |
§ Kind [[VCARD-RDF]] |
Property |
URI |
Range |
Usage note |
Card. |
---|---|---|---|---|
+URL |
|
|
This property points to a Web site of the Kind. This property is analogue to an addition by [[GEODCAT-AP-v2.0.0]]. |
0..1 |
Property |
URI |
Range |
Usage note |
Card. |
---|---|---|---|---|
+Standard licence |
|
|
This property MAY be be used to link to a concrete standard license. A controlled vocabulary is provided. |
0..1 |
Class name | Location |
---|---|
Obligation | Mandatory |
URI |
|
Usage note |
A spatial region or named place. It can be represented via a named place (controlled vocabulary) or with geographic coordinates, according to DCAT-AP guidelines [[DCAT-AP-guideline-spatial]]. For mobility data portals, usage of a named place is preferred. Many mobility data providers represent public authorities such as states, regions, municipalities etc, which can be easily represented via named places. In contrast, defining of coordinates per dataset might be error-prone and inconsistent. As named spaces, identifiers SHOULD be used via property |
Reference |
§ Term name: Location [[DCTERMS]] |
Class name | Media type |
---|---|
Obligation | Optional |
URI |
|
Usage note |
A media type, e.g. the format of a computer file. |
Reference |
§ Term name: MediaType [[DCTERMS]] |
Class name | Mobility Data Standard |
---|---|
Obligation | Mandatory |
URI |
|
Usage note |
The mobility data standard applied for the delivered content. A mobility data standard, e.g., DATEX II, combines syntax and semantic definitions of entities in a certain domain (e.g., for DATEX II: road traffic information), and optionally adds technical rules for data exchange. This is a sub-class of |
Reference |
§ Term name: Standard [[DCTERMS]] |
Property |
URI |
Range |
Usage note |
Card. |
---|---|---|---|---|
+quality annotation resource |
|
|
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 |
|
|
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 |
Class name | Relationship |
---|---|
Obligation | Optional |
URI |
|
Usage note |
An association class for attaching additional information to a relationship between DCAT Resources |
Reference |
§ 6.12 Class: Relationship [[VOCAB-DCAT-2]] |
Property |
URI |
Range |
Usage note |
Card. |
---|---|---|---|---|
had role |
|
|
This property refers to the function of an entity or agent with respect to another entity or resource. |
1..n |
relation |
|
|
This property refers to the resource related to the source resource. |
1..n |
Property |
URI |
Range |
Usage note |
Card. |
---|---|---|---|---|
+conditions for access and usage |
|
|
This property MUST 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 is provided. The values can be logically mapped with the property |
1..n |
The following is a list of requirements that were identified for the controlled vocabularies to be recommended in this Application Profile.
Controlled vocabularies SHOULD:
These criteria do not intend to define a set of requirements for controlled vocabularies in general; they are only intended to be used for the selection of the controlled vocabularies that are proposed for this Application Profile.
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.
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.
In order to conform to this Application Profile, an application that provides metadata MUST:
For the properties listed in the table in , the associated controlled vocabularies MUST be used. Additional controlled vocabularies MAY be used.
In addition to the mandatory properties, any of the recommended and optional properties defined in MAY be provided.
Recommended and optional classes may have mandatory properties, but those only apply if and when an instance of such a class is present in a description.
In order to conform to this Application Profile, an application that receives metadata MUST be able to:
As stated in , "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.).
[[DCAT-AP-v2.0.1]] has the following note about agent roles:
The DCAT Application Profile [...] has a single property to relate an Agent (typically, an organisation) to a Dataset. The only such ‘agent role’ that can be expressed in the current version of the profile is through the property dct:publisher (http://purl.org/dc/terms/publisher), defined as “An entity responsible for making the dataset available”. A second property is available in the DCAT recommendation, dcat:contactPoint (http://www.w3.org/TR/vocab-dcat/#Property:dataset_contactPoint), defined as “Link a dataset to relevant contact information which is provided using VCard”, but this is not an agent role as the value of this property is contact data, rather than a representation of the organisation as such.
In specific cases, for example in exchanging data among domain-specific portals, it may be useful to express other, more specific agent roles. In such cases, extensions to the base profile may be defined using additional properties with more specific meanings. ...
mobilityDCAT-AP specifies this note as follows:
According to [[FOAF]], an Agent (via class foaf:Agent
) may be of a type of a person (via sub-class foaf:Person
), an organisation (via sub-class foaf:Organization
), or a group (via sub-class foaf:Group
).
For mobility data portals, it is expected that organisations are the main data actors, so the type organisation SHOULD be used. A person MAY be explicitly mentioned as an agent. In this case, he or she SHOULD be attributed to an organisation via the property org:memberOf
, and, additionally, attributed with the personal name via properties foaf:firstName
and foaf:surname
.
mobilityDCAT-AP uses the class foaf:Agent
in the context of describing entities:
Thus, two different agent-role properties are used: Publisher for classes Catalogue (dct:publisher
), Catalogue Record (dct:publisher
), and Dataset (dct:publisher
); and Rights Holder for class Dataset (dct:rightsHolder
). In contrast, other agent-role properties such as dct:creator
are not used.
shows how the potential usages of foaf:Agent
are represented in a UML diagram.
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.
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.
Accessibility in the context of this Application Profile is limited to information about the technical format of distributions of datasets. The properties dcat:mediaType
and dct:format
provide information that can be used to determine what software can be deployed to process the data. The accessibility of the data within the datasets needs to be taken care of by the software that processes the data and is outside of the scope of this Application Profile.
Multilingual aspects related to this Application Profile concern all properties whose contents are expressed as strings (i.e. rdfs:Literal
) with human-readable text. Wherever such properties are used, the string values are of one of two types:
Wherever values of properties are expressed with either type of string, the property can be repeated with translations in the case of free text and with parallel versions in case of named entities. For free text, e.g. in the cases of titles, descriptions and keywords, the language tag is mandatory.
Language tags to be used with rdfs:Literal
are defined by [[BCP47]], which allows the use of the "t" extension for text transformations defined in [[RFC6497]] with the field "t0" [[CLDR]] indicating a machine translation.
A language tag will look like: "en-t-es-t0-abcd", which conveys the information that the string is in English, translated from Spanish by machine translation using a tool named "abcd".
For named entities, the language tag is optional and should only be provided if the parallel version of the name is strictly associated with a particular language. For example, the name ‘European Union’ has parallel versions in all official languages of the union, while a name like ‘W3C’ is not associated with a particular language and has no parallel versions.
For linking to different language versions of associated web pages (e.g. landing pages) or documentation, a content negotiation [[CONNEG]] mechanism may be used whereby different content is served based on the Accept-Languages indicated by the browser. Using such a mechanism, the link to the page or document can resolve to different language versions of the page or document.
All the occurrences of the property dct:language
, which can be repeated if the metadata is provided in multiple languages, must have a URI as their object, not a literal string from the [[ISO-639]] code list.
How multilingual information is handled in systems, for example in indexing and user interfaces, is outside of the scope of this Application Profile.
The mobilityDCAT-AP vocabulary supports the attribution of data and metadata to various participants such as resource creators, publishers and other parties or agents, and as such defines terms that may be related to personal information. In addition, it also supports the association of rights and licenses with catalogued Resources and Distributions. These rights and licenses could potentially include or reference sensitive information such as user and asset identifiers as described in [[VOCAB-ODRL]].
Implementations that produce, maintain, publish or consume such vocabulary terms must take steps to ensure security and privacy considerations are addressed at the application level.
This work was elaborated by the NAPCORE Sub-Working Group (SWG) 4.4 [[NAPCORE-Metadata-Working-Group]].
Editors of ReSpec documentation:
Reviewers of ReSpec documentation and contributors to preparatory activities:
Other contributors and followers:
A 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.1.0 specification. It is fullfilling all mandatory and some recommended and optional elements from mobilityDCAT-AP v1.1.0. Within the RDF/XML example file, several comments are given regarding the original RDF/XML as follows:
The above RDF/XML example population was further formatted as a TTL file. Lastly, a reduced example population is provided, only considering mandatory elements from mobilityDCAT-AP v1.1.0.
Altogether, the following files are provided as example population:
These files can be retrieved in the examples directory on the GitHub repository.
Further example populations, also looking at real-life data offerings on other NAPS, will be provided in the future.
As an addition to this specification, a "mobilityDCAT-AP Wiki" has been published. This serves as a practical orientation for users of mobilityDCAT-AP. In particular, it guides deployers (e.g., developers and operators of NAPs and data platforms) in the implementation phasis of mobilityDCAT-AP. This includes additional explanations and examples for specific vocabulary elements, recommendations for metadata handling and exposure on individual IT systems, as well as advice on metadata quality and validation processes.
The Wiki page can be retrieved in the Wiki section of the GitHub repository
Serialisation files the allow for IT implementations of mobilityDCAT-AP are available as RDF/XML, Turtle, and JSON-LD syntaxes at this Github subfolder.
A SHACL file enabling the automated validation of mobilityDCAT-AP instances and a set of shape files is available at this Github subfolder.
Further guidance can be found in the validation section of the Wikipage.
Enterprise Architect files describing the mobilityDCAT-AP data model are available at this Github subfolder.
dct:source
added under optional properties for Class Catalogue Record. This property was used at DCAT-AP v2.0.1, but removed in mobilityDCAT-AP 1.0.1. However, it is used again for harvesting use cases, see the usage note for dct:source
. See issue #57. dct:conformsTo
added under optional properties for Class Mobility Data Standard. This property describes the name of the mobility data standard. This property is used when a custom instance of class mobilitydcatap:MobilityDataStandard
is defined, see the usage note for this property. See issue #65. cnt:characterEncoding
(now linking to IANA register [[IANA-CHARSETS]]). See issue #34.dct:spatial
. See issue #58.dcatap:applicableLegislation
properties for all values used in this vocabulary. This allows for an automated tagging of EC Regulations to individual datasets. See issue #8.mobilitydcatap:MobilityDataStandard
was sometimes misspelled as mobilitydcatap:mobilityDataStandard
, corrected mobilitydcatap:mobilityDataStandard
of class dcat:Distribution
had the range skos:Concept
instead of mobilitydcatap:MobilityDataStandard
, corrected Since this is the initial release of mobilityDCAT-AP, there are no changes yet.