The fragmentation of data sources and data catalogues in the transportation domain is currently limiting the possibility of combining multi-source data for the definition of innovative data-driven mobility scenarios. In the European context, the implementation of National Access Points by Member States is promoting the publication of transportation data, but the adoption of not standardised, proprietary and not machine-readable metadata profiles currently prevents data sources to be easily found across National Access Points and to be interconnected this way. This paper describes the eforts towards the development of a napDCAT-AP specification for the harmonisation of metadata in transportation data catalogues. Starting from the analysis of the European recommendations for the interoperability of data catalogues, a roadmap for the design, implementation and publication of napDCAT-AP is described reporting guidelines and best practices. A consolidated list of requirements, collected from experts and transportation stakeholders, is discussed as the first step towards napDCAT-AP.
The establishment of National Access Points (NAPs) for the publication of transportation data,
as requested by various EU legal frameworks fostering Intelligent Transportation Systems
(ITS), e.g., the EU Regulation 2017/1926 [
The Coordinated Metadata Catalogue (CMC), defined under the former EU EIP project 2, represented a first elaboration towards NAP metadata harmonisation in the transportation domain. However, DCAT-AP is a well-established metadata specification in the domain of European Open Data portals3, relying on standardised RDF vocabularies to support semantic interoperability [3]. The definition of napDCAT-AP would like to bridge the gap between metadata initiatives considering specific requirements of the transportation domain, and the set of recommendations and best practices for metadata in data catalogues. We describe two contributions towards the definition of napDCAT-AP: (i) the definition of a roadmap with guidelines and best-practices to design, implement and publish a DCAT-AP extension; (ii) the elicitation of requirements towards the definition of a DCAT-AP extension for the transportation domain.
The paper is organised as follows: Section 2 reports the methodology followed and the related work analysed, Section 3 describes the defined roadmap identifying guidelines and best practices to extend DCAT-AP, Section 4 presents the elicited set of requirements, Section 5 draws the conclusions and discusses the next steps.
In the definition of metadata specifications, Semantic Web technologies ofer a valid solution to encode semantics in an interoperable machine-readable format. An RDF representation, adopting a standardised set of vocabularies, could support better data searchability and exchange across transportation data catalogues. The objective for napDCAT-AP is to extend the DCATAP profile for the transportation domain, supporting domain-specific metadata, such as the ones related to transportation modes and network coverage. This information is currently not covered by DCAT-AP.
To support the definition of a roadmap towards napDCAT-AP the following inputs were considered: (i) documents from the literature describing DCAT-AP and its extensions, (ii) artefacts published online for DCAT-AP and its extensions, and (iii) interviews with DCAT-AP and SEMIC experts4.
The elicitation of requirements for a transportation metadata specification was based on a literature review and inputs from the stakeholders. The references analysed include previous research, policy documents, and project documentation. Relevant references were collected, 1National Access Point Coordination Organization for Europe, http://napcore.eu/ 2https://www.its-platform.eu/achievement/monitoring-harmonisation-of-naps/ 3https://joinup.ec.europa.eu/solution/dcat-application-profile-data-portals-europe/about 4https://joinup.ec.europa.eu/collection/semantic-interoperability-community-semic and then structurally analysed to identify its relevance and contribution towards napDCAT-AP. Furthermore, as described in Section 4, we involved various stakeholders (NAPCORE partners, NAP representatives, metadata experts), to collect insights and requirements from diferent perspectives in the NAP context.
This section, further describes the performed literature review and introduces DCAT-AP and its extensions.
In the literature review, we analysed fity diferent resources reporting contributions from diferent perspectives. The analysed resources can be grouped into 6 categories: open data literature, European legislature (Public Sector Information Directive, Open Data Directive, INSPIRE Directives, Data Governance Act, EU strategy), metadata standards and interoperability, DCAT-AP materials (documentation, training webinars, and extensions), EU EIP metadata documents (Coordinated Metadata Catalogue specification, deliverables, initial napDCAT-AP proposal), project results (in particular, the SPRINT5 and LOD6 projects).
The resources providing relevant inputs for our work were mainly related to three phases of the metadata specification, namely the planning, implementation and maintenance. In particular, we analysed the following contents to support the definition of the roadmap and the elicitation of requirements: (i) FAIR principles for data sharing, (ii) guidelines for the definition and usage of metadata, (iii) (transportation) data catalogues and metadata currently adopted, (iv) data sources to be described for the transportation domain, (v) guidelines on how to build metadata specifications extending standardised vocabularies, (vi) challenges and requirements in the definition of metadata specifications (also considering other domains), (vii) tools and existing vocabularies (in particular DCAT-AP and its extensions), and (viii) mappings between (meta)data concepts in diferent specifications.
A detailed description of the analysed literature is available in the dedicated NAPCORE report [4].
This section discusses DCAT-AP and its available extensions. The Data Catalog Vocabulary (DCAT)7 is an RDF vocabulary designed to describe data catalogues using a standardized set of classes and properties to model data sources. Using DCAT, publishers increase interoperability and discoverability enabling the possibility for applications to easily consume metadata from multiple catalogues.
DCAT Application Profile (DCAT-AP) [ 5] specifies, considering DCAT as the base vocabulary, a profile for data portals in Europe to favour the aggregation, exchange, search and automated processing of metadata. DCAT-AP defines cardinalities and obligations (mandatory, 5Semantics for PerfoRmant and scalable INteroperability of multimodal Transport (SPRINT) project, http:// sprint-transport.eu/ 6LOD-RoadTran18 project, http://cef.uv.es/lodroadtran18/ 7DCAT Version 2, W3C Recommendation (2020), https://www.w3.org/TR/vocab-dcat-2/ recommended, and optional) for DCAT elements to be provided. Moreover, it provides recommendations for controlled vocabularies8 and additional properties that can be used for metadata. The intended DCAT-AP scope is cross-border and cross-domain. For this reason, applications within a national domain, or applications in a specific domain may have diferent requirements and therefore may want to define extensions to the basic profile.
The maintenance and development of the DCAT-AP specification is carried out by a dedicated Working Group composed of more than fity experts from fourteen countries. The participation is open and regular seminars are hold for dissemination and discussion about future directions. All the material about DCAT-AP is openly available online: • the process and methodology for the definition of the model [ 6]; • the released specifications and the associated artifacts [ 5]; • the change and release management policy [7].
The DCAT-AP repository is also used to collect and track issues reported by members of the working group but also by external users.
Diferent extensions of DCAT and/or DCAT-AP have been defined to support specific national requirements for catalogues. Examples of how these extensions adapt DCAT-AP to their specific requirements are: (i) extension of controlled vocabularies to be used as recommended values for metadata properties, (ii) definition of additional metadata properties (e.g., to describe the quality process, legal details to access a resource), and (iii) changes in cardinalities and obligations for metadata properties.
Several extensions that provide domain-tailored profiles have been realised. GeoDCATAP [8] is the recommended DCAT-AP extension for metadata describing geospatial datasets and data services. The objective of GeoDCAT-AP is not to replace existing recommendations for datasets in this domain, but to specify canonical mappings enabling the representation of metadata in compliance with DCAT-AP. The binding with DCAT-AP entities enables owners of geospatial information to increase the interoperability of metadata through the RDF format. GeoDCAT-AP describes mappings to DCAT-AP for the union of metadata defined by ISO 19115 (geographic information metadata) and the INSPIRE Directive (2007/2/CE). The GeoDCAT-AP extension includes additional properties with respect to the DCAT-AP standard model and a set of transformation guidelines.
StatDCAT-AP [9] is a DCAT-AP extension supporting the definition of metadata for statistical datasets and enhancing the interoperability of statistical data sources in open data catalogues adopting DCAT-AP. StatDCAT-AP supports the description of statistical datasets in multiple formats. StatDCAT-AP provides a specification that is fully compliant with DCAT-AP and defines a small number of additions to model relevant metadata for the statistical datasets. In particular, StatDCAT-AP allows describing the multidimensional structure of statistical datasets representing the numerical variables (or measurements) on diferent dimensions, e.g., geographic, temporal or specific dimensions.
TransportDCAT-AP [10] is a profile of the DCAT-AP ontology focused on the public transport domain. The profile takes into account the geospatial nature of public transport data by defining 8https://op.europa.eu/en/web/eu-vocabularies/controlled-vocabularies the set of metadata related to this type of information as mandatory. In addition, a specific set of admissible keywords is defined to standardise the range of metadata properties (i.e., the values that can be associated with a property) and to enable domain-related queries, e.g., considering specific transportation modes. Despite having similar objectives with respect to napDCAT-AP, the extension is currently not actively maintained and does not have broad adoption in existing transportation data catalogues.
The first contribution of this paper is the definition of a roadmap for the design, implementation and publication of napDCAT-AP. A report of best practices for DCAT-AP extensions is not publicly available, however, they are partially documented by existing extensions. The guidelines and best practices identified in this section were extracted from the analysed DCAT-AP extensions and considering the additional inputs collected through interviews with experts. The roadmap towards the publication of napDCAT-AP is represented in Fig. 1 and is composed of five steps described in the following paragraphs: definition of requirements, definition of the domain model, RDF implementation, documentation and guidelines, hosting and publication.
The first phase of the roadmap is related to the definition of requirements for the DCAT-AP extension. A collection of use cases and functionalities, which should be supported by the extension, must be identified involving the relevant stakeholders and used to elicit a set of requirements. This phase should take into account also existing projects and initiatives for metadata to support their re-use in the design and implementation phase. In the context of napDCAT-AP, the analysis of existing metadata specifications focused on the Coordinated Metadata Catalogue (widely adopted by European NAPs) and the existing DCAT-AP extensions, described in Section 2. The outcome of the analysis and the requirements collected from the stakeholders are described in Section 4.
The second step of the roadmap concerns the definition of the conceptual model considering the elicited requirements. The report [6] describes a methodology for the development of conceptual models and vocabularies fostering semantic interoperability between information systems. This work is an elaboration of the standardisation process and methodology of the World Wide Web Consortium (W3C). The process involves setting up a Working Group and submitting drafts of the specification for internal and external public review. The methodology focuses on the identification of elements to be covered. Relevant steps to be performed are: (i) analyse the domain and the use cases addressed by the model to be developed, (ii) reach a consensus by developing semantic agreements among diferent stakeholders, (iii) define and implement a structured and clear model, and (iv) publish the model for public revision.
Additional best practices, identified for the definition of the domain model for a DCAT-AP extension, are: • to identify and prioritise potential new metadata elements considering the contribution that they could generate regarding data discovery; • to consider existing data portals, for example, if similar properties defining specific value sets are commonly used, and if it is worth considering them to ensure the adoption of a reasonably generic vocabulary and the definition of mappings; • to support a harmonised evolution of DCAT, DCAT-AP and the related extensions (a collaboration of actors involved in the respective Working Groups is encouraged); • to define a conceptual model that can be supported by UML-based tools relying on a standardised graphical notation and enabling an initial RDF export of the modelled extension (see next step).
The third step of the roadmap is related to the implementation of the defined conceptual model in RDF. This step should identify and/or define the set of RDF classes and properties to encode the domain model. Moreover, controlled vocabularies may be specified or designed to define constraints on the set of admissible values for specific properties. Finally, this phase identifies cardinality and produces diferent RDF serialization of the modelled vocabularies.
A public document identifies the guidelines that must be followed for the extension of DCATAP9. The rationale of the defined guidelines is to allow the extensibility of the application profile while preserving interoperability in a wider European and cross-domain environment. The general criteria for any extension is to respect the minimum conformance requirements of DCAT-AP, thus allowing interoperability of metadata represented using the extended profile with metadata adopting DCAT-AP. The rules reported in the document detail how to apply the general criteria during the implementation process.
Best practices for the identification and implementation of classes and properties are: (i) consider the vocabularies reused by DCAT and DCAT-AP as preferred sources to identify new metadata elements; (ii) additional metadata terms should be selected from existing wellknown and well-maintained vocabularies; (iii) the reuse of other DCAT-AP extensions, e.g., GeoDCAT-AP for geospatial metadata, should be recommended.
Best practices for the identification and implementation of controlled vocabularies are: (i) the usage of controlled vocabularies fulfilling the requirements listed in the DCAT-AP specification, preferably the EU Vocabularies maintained by the Publications Ofice, should be encouraged by specifying a range of admissible values for metadata properties; (ii) there can be more than one controlled vocabulary for each property, but it is preferable to avoid this design decision to facilitate the implementation of the specification by portal designers; (iii) the definition of new controlled vocabularies should preferably be based on the SKOS vocabulary [11]; (iv) to restrict the range of a metadata property it is preferable to define a specific sub-property, to enlarge the range of a metadata property a mapping mechanism should be defined to guarantee interoperability. 9How to extend DCAT-AP, https://joinup.ec.europa.eu/release/dcat-ap-how-extend-dcat-ap Figure 1: Roadmap towards napDCAT-AP
The fourth step of the roadmap concerns the definition of the documentation and additional artifacts supporting the publication of the DCAT-AP extension.
The release of a DCAT-AP extension should provide: HTML (and, optionally, PDF) documentation, RDF serialisations (RDF/XML, Turtle, JSON-LD, etc.), SVG UML diagram providing a graphical representation. It is important to describe for each distribution of the DCAT-AP extension what is directly encoded/represented (e.g., in the diagram) and what is documented elsewhere. A license for the publication of the DCAT-AP extension should be identified and documented in the diferent distributions. An open license for the extension is preferable to promote its adoption by a large number of stakeholders.
The documentation of a DCAT-AP extension should deal with several aspects: (i) a clear description of uses cases, which are addressed by the specific extension, (ii) a description of the terminology used, (iii) the definition of the relevant class and properties, (iv) the definition of mandatory/recommended/optional constraints, (v) the identification of controlled vocabularies to be used, (vi) a changelog considering the diferent versions of the extension.
In addition to the documentation, the following additional artefacts are recommended to support the publication of a DCAT-AP extension: • the provision of guidelines and conventions for the format of identifiers that should be used as value for specific metadata properties; • the definition and description of a governance process for the proposal, revision and acceptance of modifications (cf., for example the one defined for DCAT-AP [ 7]); • the specification of canonical mappings with respect to other relevant metadata standards in the considered domain; • the definition of implementation guidelines (cf., for example the one defined for DCATAP10 providing also compatible tools for the harvesting, validation, and export of metadata compliant with the specification); • the production of SPARQL queries and/or shapes adopting the Shapes Constraint Language (SHACL)11 that serialise the constraints defined in the documentation of the DCAT-AP extension (e.g., the cardinality constraints) to support the automated execution of quality checking procedures.
Best practices were identified for the hosting and publication of the napDCAT-AP extension. Similar recommendations also apply to controlled vocabularies defined for the extension. The identified best practices are: 10https://joinup.ec.europa.eu/collection/semantic-interoperability-community-semic/solution/ dcat-application-profile-implementation-guidelines/about 11SHACL, https://www.w3.org/TR/shacl/ • A public repository (e.g., on GitHub) should be set up to collect and host all the artifacts composing the release of the DCAT-AP extension; • The repository should support a mechanism for the maintenance of the extension: versioning, hosting of working draft for future releases, collection and tracking of issues; • A long-term hosting solution should be guaranteed and a permanent identifier (e.g., W3ID12 or data.europa.eu13) should be assigned to the DCAT-AP extension to enable the possibility of changing the hosting solution while preserving the same identifier; • The hosting solution should provide access to the extension in diferent formats (extension distributions) and may implement a content-negotiation mechanism to serve them according to the request made by the user; • The hosting solution should support a URI strategy to access both the latest release and the previously published versions of the extension; • The indexing of the DCAT-AP extension in the Linked Open Vocabularies (LOV) portal14 is recommended to improve its discoverability.
This section presents an overview of the requirements elicited for napDCAT-AP that are the results of execution of the first step of the defined roadmap. As already discussed, the requirements collection phase considered inputs from literature review, experts’ interviews and direct user needs collection. The direct collection of requirements was performed involving NAPCORE partners that represent relevant NAP stakeholders from diferent European countries, and the organisations responsible for adopting and implementing the defined napDCAT-AP specification within NAP. Each stakeholder filled a template to formally assess and structure requirements considering diferent perspectives: • NAP developer : stakeholder responsible of setting up the metadata layer in a NAP. To support interoperability, napDCAT-AP should be the baseline model for the metadata layer of NAPs . • NAP metadata provider: persons involved in inserting metadata into a NAP, e.g., via a GUI. In many cases, the metadata provider is the same as the content data provider. This person might look for aspects of, e.g., clarity and eficiency when entering metadata. • NAP metadata user: persons (or machines when using APIs) who read or seek metadata from a NAP. This actor might look for aspects of, e.g., expressiveness or usefulness when consuming metadata. 12W3ID, https://w3id.org/ 13data.europa.eu, https://data.europa.eu/URI.html 14Linked Open Vocabularies, https://lov.linkeddata.es/ • Metadata standard experts: Lastly, as we build upon existing frameworks of other metadata specifications, we need to consider the experiences and expectations of experts from such other metadata specifications. This is particularly true for DCAT-AP, which explicitly provides guidelines and requirements for the extensions of DCAT-AP. The aspects considered here mainly focus on interoperability issues.
The requirements were further revised and harmonised into a consolidated list of forty requirements, divided into the following categories: General (8), Existing Vocabularies (5), Content (22), Implementation (5).
The General requirements, state high-level requirements for a new metadata specification, including the following aspects: expressiveness, richness, adequate description of the real data, easy access to the real data, context-sensitivity, modularity, detailed structure and categories, strong typing and ruling, persistent identifiers (for data, datasets and metadata). Furthermore, they specify functionalities to be fulfilled by the napDCAT-AP specification: (i) to make NAP datasets and their distributions discoverable, searchable and re-usable for national and international data consumers; (ii) to ensure a common understanding of the metadata content (shared semantic); (iii) to serve as a baseline for the development of a metadata database in an individual NAP, (iv) to allow for (automatic) aggregation and exchange of machine-readable metadata. The remaining general requirements impose further technical and organisational prerequisites for napDCAT-AP.
The Existing Vocabularies requirements, identify a set of existing metadata specifications that should be considered in the development of napDCAT-AP: DCAT-AP, DCAT-AP extensions (in particular, geoDCAT-AP for geospatial data), Coordinated Metadata Catalogue, existing controlled vocabularies (or code lists) adopted in operational NAPs. This would foster interoperability and acceptance with existing metadata domains and legacy systems.
The majority of the requirements, reported in Table 1, is about the Content, i.e., information items which are seen as necessary to be covered by the napDCAT-AP specification.
Metadata Content Regulation Temporal Geographic Georeferencing Transportation Responsibilities Usage Access Data Samples date/time for creation/modification of the metadata, the metadata language, the responsible for creation and maintenance of the metadata, conditions of usage of the metadata name, description, type of resource, dataset type category, service type category, language type(s) of Delegated Regulation (DR) covered temporal validity of the information area covered, regions in which data are valid and details on the transport network considered location referencing methods and coordinate reference system (CRS) used within the data transportation system information (transportation modes and operators) publisher(s) and owner(s) of the data license, contract or any other condition to use the data encoding, syntax, grammar and data model data samples Quality Version update rate, the quality criteria of the data, the history and status of procedures to assess the compliance of the Delegated Regulations regarding the provisioning of data via a NAP changelog and information about the version
Requirements about Implementation demand the adoption of best practices for the napDCATAP development: define artefacts to facilitate the validation of metadata, provide usage rules together with metadata definitions (explanations of the semantics of each metadata element, advices on how to relate these elements into NAP processes, etc.), provide guidelines on how to make NAP-specific metadata interoperable with other data portals (e.g., outside the mobility domain), identify guidelines for a quality assurance process to check the quality of metadata collected on a NAP. Finally, napDCAT-AP should diferentiate between essential metadata elements, which are relevant to any NAP (i.e., a minimum set of metadata for European NAPs), and further metadata element defined in the specification.
This report presented the outcomes of the analysis of diferent inputs for the definition of guidelines and best practices to extend DCAT-AP. These results have been used to define the roadmap for the definition of napDCAT-AP as a planned extension of DCAT-AP for National Access Points and, more in general, for the transportation domain. The roadmap highlighted the steps to be performed and their dependencies. Moreover, for each step a set of guidelines and best practices is reported considering the performed analysis. The elicited list of requirements, collected by involving relevant transportation stakeholders, describes the expected technical, organisational and functional features that should guide the development of napDCAT-AP.
The presented roadmap and the requirements will guide the next steps of a dedicated working group within the NAPCORE project, which currently works towards the publication of napDCATAP. As future work, we will investigate automatic approaches for the harmonisation of NAP metadata based on the defined napDCAT-AP specification [ 2].
The presented research was partially supported by the NAPCORE project, co-funded by the European Commission’s Directorate General for Transport and Mobility under Grant Agreement no. MOVE/B4/SUB/2020-123/SI2.85223. EU-wide multimodal travel information services, 2017. URL: http://data.europa.eu/eli/reg_ del/2017/1926/oj/eng, legislative Body: MOVE, COM. [2] A. Carenini, et al., SPRINT project Deliverable D2.3 – Requirements for an IF architectural design F-REL, 2020. URL: http://sprint-transport.eu/. [3] F. Barthelemy, et al., Towards a standard-based open data ecosystem: analysis of DCAT-AP use at national and European level, Electronic Government, an International Journal 18 (2022) 137–180. doi:1 0 . 1 5 0 4 / E G . 2 0 2 2 . 1 2 1 8 5 6 , publisher: Inderscience Publishers. [4] P. Bureš, P. Lubrich, et al., NAPCORE project, Report SubWG 4.4 Work Item 2.1 – Requirements Analysis for a new Metadata Specification, 2022. [5] B. Van Nufelen, DCAT Application Profile for data portals in Europe (DCAT-AP) v2.0.1, Technical Report, SEMIC, 2020. URL: https://joinup.ec. europa.eu/collection/semantic-interoperability-community-semic/solution/ dcat-application-profile-data-portals-europe/release/201-0. [6] ISA Programme, Process and Methodology for Developing Semantic Agreements, 2013.
URL: https://joinup.ec.europa.eu/collection/semantic-interoperability-community-semic/ document/process-and-methodology-developing-semantic-agreements. [7] ISA Programme, Change and Release Management Policy DCAT-AP, 2017. URL: https://joinup.ec.europa.eu/collection/semantic-interoperability-community-semic/ solution/dcat-application-profile-data-portals-europe/document/ change-and-release-management-policy-dcat-ap. [8] GeoDCAT-AP, 2020. URL: https://semiceu.github.io/GeoDCAT-AP/releases/2.0.0/, Version 2.0.0. [9] StatDCAT-AP, 2019. URL: https://joinup.ec.europa.eu/ collection/semantic-interoperability-community-semic/solution/ statdcat-application-profile-data-portals-europe/release/101, Version 1.0.1. [10] D. Chaves, J. A. Rojas, P. Colpaert, J. Chamorro, O. Corcho, A common metadata model for representing public transport at European level, 2015. URL: https://github.com/cef-oasis/ DCAT-AP/tree/master/TransportDCAT-AP. [11] A. Miles, S. Bechhofer, SKOS simple knowledge organization system reference, W3C recommendation, W3C, 2009. URL: http://www.w3.org/TR/skos-reference, [Accessed June 2022].