=Paper=
{{Paper
|id=Vol-3235/paper22
|storemode=property
|title=Towards napDCAT-AP: Roadmap and Requirements for a Transportation Metadata Specification
|pdfUrl=https://ceur-ws.org/Vol-3235/paper22.pdf
|volume=Vol-3235
|authors=Mario Scrocca,Antonia Azzini,Petr Bureš,Marco Comerio,Peter Lubrich
|dblpUrl=https://dblp.org/rec/conf/i-semantics/ScroccaABCL22
}}
==Towards napDCAT-AP: Roadmap and Requirements for a Transportation Metadata Specification==
https://ceur-ws.org/Vol-3235/paper22.pdf
Towards napDCAT-AP: Roadmap and Requirements
for a Transportation Metadata Specification
Mario Scrocca1,∗ , Antonia Azzini1 , Petr Bureš2 , Marco Comerio1 and Peter Lubrich3
1
Cefriel – Politecnico di Milano, Milan, Italy
2
Czech Technical University in Prague, Prague, Czech Republic
3
Federal Highway Research Institute (BASt), Bergisch Gladbach, Germany
Abstract
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 efforts 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.
Keywords
Metadata Harmonisation, Metadata Profile, Data Catalogues, National Access Points
1. Introduction
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 [1], presents challenges and opportunities for transport
stakeholders. Each European Member State is required to set up a NAP that allows accessing
static data (e.g., timetables, network topology, list of services offered at a station / airport) and
dynamic data (e.g., delays, cancellations) related to different transportation modes. Even though
the role of the NAP as a data catalogue is clearly specified in the regulation, each member state
is then free to implement it according to its design. Such principle led to the appearance of
different metadata and data vocabularies, and the need of cooperation to ensure interoperability
between different NAPs [2]. The adoption of heterogeneous metadata descriptions is reflected in
SEMANTICS 2022 EU: 18th International Conference on Semantic Systems, September 13-15, 2022, Vienna, Austria
∗
Corresponding author.
Envelope-Open mario.scrocca@cefriel.com (M. Scrocca); antonia.azzini@cefriel.com (A. Azzini); petr.bures@cvut.cz (P. Bureš);
marco.comerio@cefriel.com (M. Comerio); lubrich@bast.de (P. Lubrich)
Orcid 0000-0002-8235-7331 (M. Scrocca); 0000-0002-9066-1229 (A. Azzini); 0000-0002-3797-0970 (P. Bureš);
0000-0003-3494-9516 (M. Comerio); 0000-0002-0023-1234 (P. Lubrich)
© 2022 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
Workshop
Proceedings
http://ceur-ws.org
ISSN 1613-0073
CEUR Workshop Proceedings (CEUR-WS.org)
the availability of different web services and interfaces offering limited search capabilities for the
users and ITS service providers. The NAPCORE project1 has the goal of facilitating the mobility
data exchange in Europe by coordinating all the NAPs on an organizational and technical
level. In particular, the objective is to foster interoperability of mobility data by promoting
the harmonisation of metadata and data formats across NAPs. In this paper, we discuss the
ongoing efforts towards the design, implementation and publication of a napDCAT-AP metadata
specification to improve the accessibility and exchange of transportation datasets.
The Coordinated Metadata Catalogue (CMC), defined under the former EU EIP project2 ,
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.
2. Preliminaries
In the definition of metadata specifications, Semantic Web technologies offer 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 DCAT-
AP 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,
1
National Access Point Coordination Organization for Europe, http://napcore.eu/
2
https://www.its-platform.eu/achievement/monitoring-harmonisation-of-naps/
3
https://joinup.ec.europa.eu/solution/dcat-application-profile-data-portals-europe/about
4
https://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 different
perspectives in the NAP context.
This section, further describes the performed literature review and introduces DCAT-AP and
its extensions.
2.1. Literature Review
In the literature review, we analysed fifty different resources reporting contributions from
different 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 different specifications.
A detailed description of the analysed literature is available in the dedicated NAPCORE
report [4].
2.2. DCAT-AP and DCAT-AP extensions
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 voca-
bulary, 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,
5
Semantics for PerfoRmant and scalable INteroperability of multimodal Transport (SPRINT) project, http://
sprint-transport.eu/
6
LOD-RoadTran18 project, http://cef.uv.es/lodroadtran18/
7
DCAT 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 recom-
mendations 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 different 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 fifty 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.
Different 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. GeoDCAT-
AP [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 different 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
8
https://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.
3. A roadmap towards napDCAT-AP
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 guide-
lines 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.
3.1. STEP 1: definition of requirements for napDCAT-AP
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.
3.2. STEP 2: definition of the napDCAT-AP domain model
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 different 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).
3.3. STEP 3: RDF implementation of napDCAT-AP
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 different RDF serialization of the modelled vocabularies.
A public document identifies the guidelines that must be followed for the extension of DCAT-
AP9 . 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 well-
known 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 Office, 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.
9
How to extend DCAT-AP, https://joinup.ec.europa.eu/release/dcat-ap-how-extend-dcat-ap
Figure 1: Roadmap towards napDCAT-AP
3.4. STEP 4: documentation and guidelines for 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) docu-
mentation, 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 different 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 different 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 DCAT-
AP10 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 Lan-
guage (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.
3.5. STEP 5: hosting and publication of napDCAT-AP
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:
10
https://joinup.ec.europa.eu/collection/semantic-interoperability-community-semic/solution/
dcat-application-profile-implementation-guidelines/about
11
SHACL, 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: ver-
sioning, 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 different formats (exten-
sion 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.
4. Definition of requirements for napDCAT-AP
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 require-
ments 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 different 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 different 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 efficiency 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.
12
W3ID, https://w3id.org/
13
data.europa.eu, https://data.europa.eu/URI.html
14
Linked Open Vocabularies, https://lov.linkeddata.es/
• Metadata standard experts: Lastly, as we build upon existing frameworks of other meta-
data 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 require-
ments, 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 interna-
tional 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 interop-
erability 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 date/time for creation/modification of the metadata, the metadata lan-
guage, the responsible for creation and maintenance of the metadata,
conditions of usage of the metadata
Content name, description, type of resource, dataset type category, service type
category, language
Regulation type(s) of Delegated Regulation (DR) covered
Temporal temporal validity of the information
Geographic area covered, regions in which data are valid and details on the transport
network considered
Georeferencing location referencing methods and coordinate reference system (CRS)
used within the data
Transportation transportation system information (transportation modes and operators)
Responsibilities publisher(s) and owner(s) of the data
Usage license, contract or any other condition to use the data
Access encoding, syntax, grammar and data model
Data Samples data samples
Quality update rate, the quality criteria of the data, the history and status of pro-
cedures to assess the compliance of the Delegated Regulations regarding
the provisioning of data via a NAP
Version changelog and information about the version
Table 1: Content requirements for napDCAT-AP.
Requirements about Implementation demand the adoption of best practices for the napDCAT-
AP 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 differentiate 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.
5. Conclusions
This report presented the outcomes of the analysis of different 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 napDCAT-
AP. As future work, we will investigate automatic approaches for the harmonisation of NAP
metadata based on the defined napDCAT-AP specification [2].
Acknowledgments
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.
References
[1] Commission Delegated Regulation (EU) 2017/1926 of 31 May 2017 supplementing Directive
2010/40/EU of the European Parliament and of the Council with regard to the provision of
EU-wide multimodal travel information services, 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 – Require-
ments Analysis for a new Metadata Specification, 2022.
[5] B. Van Nuffelen, 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].