D2.2 User needs from a technical perspective

Towards a sustainable Open Data Ecosystem D2.2 User needs from a technical perspective This project has received funding from the European Union’s Horizon 2020 research and innovation programme under the Marie Skłodowska-Curie grant agreement No 955569. The opinions expressed in this document reflect only the author’s view and in no way reflect the European Commission’s opinions. The European Commission is not responsible for any use that may be made of the information it contains. D2.2 User needs from a technical perspective. Project Acronym ODECO Project Title Towards a sustainable Open Data ECOsystem Grant Agreement No. 955569 Start date of Project 01 - 10 - 2021 Duration of the Project 48 months Deliverable Number D2.2 Deliverable Title User needs from a technical perspective Dissemination Level Public Deliverable Leader Universidad de Zaragoza (UNIZAR) Submission Date 30-09-2023 Editor Francisco J Lopez Pellicer, UNIZAR Co-author(s) Abdul Aziz, UNIZAR Dagoberto José Herrera Murillo, UNIZAR Mohsan Ali, UAEGEAN Maria Ioanna Maratsi , UAEGEAN Document history Version # Date Description (Section, page number) Author & Organisation V0.0 29-05-2023 Creation (ALL) Francisco J Lopez Pellicer, UNIZAR V0.1 28-07-2023 First draft. First version with contributions of the ESRs. (ALL) Abdul Aziz, UNIZAR Dagoberto José Herrera Murillo, UNIZAR Mohsan Ali, UAEGEAN Maria Ioanna Maratsi, UAEGEAN Charalampos Alexopoulos, UAEGEAN Francisco J Lopez Pellicer, UNIZAR Jav ier Nogueras - Iso, UNIZAR V0.2 17-08-2023 Second draft. Restructuration after the feedback from the first peer-review. (ALL) Abdul Aziz, UNIZAR Dagoberto José Herrera Murillo, UNIZAR Mohsan Ali, UAEGEAN Maria Ioanna Maratsi, UAEGEAN Francisco J Lopez Pellicer, UNIZAR Reviewers: Joep Crompvoets, KU LEUVEN, Andrea Pollini, CAMERINO V0.3 21-09-2023 Final report. Editorial work after the feedback from the second peer-review. (ALL) Abdul Aziz, UNIZAR Dagoberto José Herrera Murillo, UNIZAR Mohsan Ali, UAEGEAN Maria Ioanna Maratsi, UAEGEAN Francisco J Lopez Pellicer, UNIZAR Reviewers: Joep Crompvoets, KU LEUVEN, Andrea Pollini, CAMERINO V0.4 23-09-2023 Final report Dagoberto José Herrera Murillo, UNIZAR Mohsan Ali, UAEGEAN Maria Ioanna Maratsi, UAEGEAN Francisco J Lopez Pellicer, UNIZAR V0.5 30-09-2023 Approval Bastiaan van Loenen, TUD V1.0 30 - 09 - 2023 Final editing Danistja van Heusden, TUD D2.2 User needs from a technical perspective. Table of Contents Abbreviations _____________________________________________________________________________________________ 4 1. Introduction _________________________________________________________________________________________ 5 1.1. Background ____________________________________________________________________________________ 5 1.2. Problem definition _____________________________________________________________________________ 5 1.3. Role of this deliverable in the ODECO project_________________________________________________ 6 1.4. Structure _______________________________________________________________________________________ 7 2. Methodology ________________________________________________________________________________________ 8 2.1. Theoretical foundations________________________________________________________________________ 8 2.2. Strategy ________________________________________________________________________________________ 9 2.3. Scope __________________________________________________________________________________________ 9 2.4. Additional definitions _________________________________________________________________________ 10 3. FAIR Principles: when User Needs meet Open Data _______________________________________________ 13 3.1. Findability _____________________________________________________________________________________ 13 3.2. Accessibility ___________________________________________________________________________________ 14 3.3. Interoperability ________________________________________________________________________________ 15 3.4. Reusability ____________________________________________________________________________________ 16 4. FAIR Principles from a technical perspective _______________________________________________________ 17 4.1. User Interfaces ________________________________________________________________________________ 17 4.2. Accessibility, interoperability, and technology _______________________________________________ 19 4.3. Accessibility, interoperability, and semantics _________________________________________________ 26 4.4. Data portals and reusability __________________________________________________________________ 30 5. Requirements assessment __________________________________________________________________________ 33 6. FAIR Data provision requirements specification ___________________________________________________ 36 6.1. Requirements for findability __________________________________________________________________ 36 6.2. Requirements for accessibility ________________________________________________________________ 37 6.3. Requirements exclusive for interoperability __________________________________________________ 37 6.4. Requirements for reusability __________________________________________________________________ 42 7. Conclusions _________________________________________________________________________________________ 43 8. Bibliography ________________________________________________________________________________________ 44 List of figures Figure 1. Scope of ODECO deliverable 2.2 ....................................................................................................................... 10 List of tables Table 1: The actors/users/stakeholders considered for user stories and requirements. ................................ 10 Table 2: Functional requirements for user interfaces and findability ..................................................................... 17 Table 3: Non-Functional requirements for user interfaces and findability .......................................................... 19 Table 4: Functional requirements for accessibility, interoperability, and technology ...................................... 22 Table 5: Non-Functional requirements for accessibility, interoperability, and technology ........................... 26 Table 6: Functional requirements for accessibility, interoperability, and semantics ......................................... 28 Table 7: Non-functional requirements for accessibility, interoperability, and semantics ............................... 29 Table 8: Functional requirements for data portals and reusability ......................................................................... 31 Table 9: Non-functional requirements for data portals and reusability................................................................ 32 Table 10: Functional requirements for findability .......................................................................................................... 36 Table 11: Non-functional requirements for findability ................................................................................................ 36 Table 12: Functional requirements for accessibility ...................................................................................................... 37 Table 13: Functional requirements for interoperability ............................................................................................... 37 Table 14: Non-functional requirements for interoperability ...................................................................................... 40 Table 15: Functional requirements for reusability .......................................................................................................... 42 D2.2 User needs from a technical perspective. 4 Abbreviations CPO Chief Privacy Officer D Deliverable ESR Early Stage Researcher FAIR Findable, Accessible, Interoperable and Reusable FAV Fully Automated Vehicles LOD Level of Detail M Milestone MQA Metadata Quality Assessment NGO Non-Governmental Organizations NPO Non-Profit Organizations OD Open Data ODE Open Data Ecosystems ODP Open Data Portals ODECO Project “Towards a sustainable Open Data ECOsystem” PBR Perspective-Based Reading WP Work Package Nr Partner Partner short name Country Beneficiary 1 Technische Universiteit Delft TU Delft Netherlands 2 Katholieke Universiteit Leuven KUL Belgium 3 Centre National de la Recherche Scientifique CNRS France 4 Universidad de Zaragoza UNIZAR Spain 5 Panepistimio Aigaiou UAEGEAN Greece 6 Aalborg Universitet AAU Denmark 7 Università degli Studi di Camerino UNICAM Italy 8 Farosnet S.A. FAROSNET S.A. Greece Partner organisations 1 7eData 7EDATA Spain 2 Digitaal Vlaanderen DV Belgium 3 City of Copenhagen COP Denmark 4 City of Rotterdam RDAM Netherlands 5 CoC Playful Minds CoC Denmark 6 Derilinx DERI Ireland 7 ESRI ESRI Netherlands 8 Maggioli S.p.A MAG Italy 9 National Centre of Geographic Information CNIG Spain 10 Open Knowledge Belgium OKB Belgium 11 SWECO SWECO Netherlands 12 The government lab GLAB United States of America 13 Agency for Data Supply and Infrastructure ADSI Denmark D2.2 User needs from a technical perspective. 5 1. Introduction 1.1. Background In the current digital landscape, the Open Data (OD) movement is experiencing rapid growth, driven by the exponential increase in data accessibility through open data portals (de Juan-Espinosa & LujánMora, 2020; Reggi & Dawes, 2022). Projections from the European Commission estimate that by 2025, the net value of the size of the European Union open data market will be almost 200 billion euros, impacting over a million employees in the open data sector (Publications Office of the European Union, 2022). The core principle of open data is to enable free and unrestricted usage, sharing, and access to data in any available format (European Comission, 2011). Governments are progressively initiating OD initiatives and setting up dedicated portals to facilitate the dissemination of open data in reusable formats. Consequently, a multitude of open data repositories, catalogues, and websites have appeared to serve this purpose. OD Portals (ODP) play a pivotal role in easing data openness. ODPs serve as online repositories featuring detailed dataset descriptions based on key attributes such as authorship, provenance, and licensing (Neumaier, Umbrich, & Polleres, 2016). These catalogues ease the exploration and administration of metadata records which provide valuable insights into datasets that may be accessible for download in various distribution formats. OD initiatives assume that publication of open data through ODPs will increase the demand for high-quality data and enhance the overall quality of the ODPs. Complementary, the publication of public sector data stands as significant drivers behind the prevailing movement to open government data via an open data portal (Carrara, Chan, Fischer, & Van-Steenbergen, 2015). Open Data Ecosystems (ODE) is an emerging concept for data sharing under public licenses in software ecosystems. However, many existing ODEs are provider-centric and often struggle to effectively align supply with demand (Van Loenen, et al., 2021). There is a widely recognized consensus that user engagement plays a pivotal role in shaping the evolution of ODE. Despite this, the current landscape stays influenced by data providers. The design and implementation of existing ODPs reflect this misalignment. Therefore, a more collaborative and user-centred approach is essential for the best use and value of OD. In this context, ODECO Task 2.2 focuses on investigating the technological requirements for the provision of Findable, Accessible, Interoperable and Reusable (FAIR) data for different categories of users (Wilkinson, Dumontier, Aalbersberg, & al., 2016). This includes identifying gaps between the needs of user groups and the current features of ODPs and define and evaluate new approaches for designing user driven user interfaces for finding data that fulfils different findability and accessibility requirements from different domains, developing ‘data integrators’, enabling the technical interoperability of OD stemming from different domains, and determining the minimum and optimal set of metadata descriptions to be adopted to allow for semantic interoperability of open data across domains and disciplines. Partner organisations will support Task 2.2 with their experience in data provision issues. 1.2. Problem definition ODECO Task 2.2 has its origins in the lack of a systematic integration of technical perspectives into understanding user needs related to open data. This deficiency hampers efficient OD discovery, use, innovation, interoperability, and reusability, compromising the adherence to FAIR principles of OD initiatives. The absence of a comprehensive approach to align user needs with technical requirements hinders the integration of diverse user groups and domains, impeding the development of a collaborative and well-integrated ODE. Addressing this gap is critical for fostering effective OD use and ensuring the successful implementation of OD initiatives to maximize their benefits across various sectors and domains. D2.2 User needs from a technical perspective. 6 Failure to address these technical aspects could undermine the success of OD initiatives and limit their impact on easing OD usage. The lack of a technical perspective on the understanding of user needs is a problem for several reasons:  Inefficient Data Discovery and Utilisation: Without a clear understanding of the technical requirements that user needs imply, data discovery and utilisation may become inefficient and timeconsuming. Users may struggle to find relevant data, leading reactions than ranges from. frustration (e.g., a non-specialist user that has not access to specialized tools for using data) to reduced productivity (e.g., a journalist that find limited the indexing capabilities of open data portals).  Missed Opportunities for Innovation in ODPs: Diverse user groups bring unique insights and requirements to data usage. These opportunities only can be understood in the context of their user needs. Ignoring these technical needs (e.g., provide guidance for connecting open data API to business data pipelines) means not only to miss opportunities for innovative solutions and novel applications of open data but also hampers the daily use of open data.  Fragmented Data Ecosystem: The absence of tailored user interfaces (e.g., a user interface adapted to Non-Profit Organizations (NPOs) and Non-Governmental Organizations (NGOs) focused on health can be different from a user interface adapted to NPOs and NGOs focused on poverty) and interoperability mechanisms based on the user needs (e.g., the interoperability needs of a government body are different from the interoperability needs of a company) inhibits data sharing and collaboration across domains, hindering the potential for cross-disciplinary insights.  Reduced Data Reusability: Technical requirements play a crucial role in ensuring data reusability. Without considering these needs, data may not be appropriately formatted or described for being reused, limiting its usefulness, and hindering its potential for reuse.  Undermining FAIR Principles: The FAIR principles focus on ease data sharing and reuse and are technology independent, but neglecting technical requirements derived from user needs undermine these principles. Data may not be as accessible or interoperable as intended, undermining the overall FAIR-ness of the data. In conclusion, the lack of a technical perspective on user needs poses significant challenges for the ODEs and the overarching goal of promoting FAIR data provision. This shortfall hinders efficient data utilisation, innovation, and collaboration, impeding the realisation of OD initiatives’ objectives and the broader benefits of OD. Addressing this problem is crucial to unlocking the full potential of open data for diverse user groups and driving meaningful advancements across various domains. 1.3. Role of this deliverable in the ODECO project In ODECO deliverable 2.2, we aim to reduce the gap between the needs of various user groups and technological solutions intended to enable them to make the best use of the data. The result is a list of user-driven technologic requirements that OD initiatives should consider. This deliverable is a logical continuation of ODECO deliverable 2.1, “Open data user needs: seven flavours” (Staso, y otros, 2023), and provides valuable input for future ODECO Task 3.2, “Closing the cycle: promoting data user’s contribution from a technical perspective”. The challenge of understanding user needs from a technical perspective in the context of FAIR data provision is considerable. The ODECO project aims to address the fundamental issue of making data Findable, Accessible, Interoperable, and Reusable for diverse user groups. However, the lack of a comprehensive understanding of user needs from a technical standpoint has far-reaching implications. This is the main reason that ESRs involved in Task 2.2 are committed in their respective Research Projects to research on the technological requirements for the provision of FAIR data:  The identification of gaps between the needs of user groups and the current features of open data platforms and the definition and evaluation of approaches for designing user driven user interfaces for finding data that fulfils different findability and accessibility requirements from different domains (ESR 2). D2.2 User needs from a technical perspective. 7  The development of data integrators to enable the technical interoperability of open data stemming from different domains (ESR 5).  The determination of a minimum set of metadata descriptions to allow semantic interoperability of open data across different domains (ESR 7).  The use of technical features in open data portals to improve data reuse (ESR 8). As a result, the main goal within ODECO of deliverable 2.2 is to identify and document technical prerequisites for FAIR data provision, originating directly from user needs. That is, this deliverable is a key block in the collective ODECO work to harness the potential of ODE. 1.4. Structure The next Section details the methodological approach adopted in Task 2.2, encompassing theoretical foundations, strategy, scope, and definitions. Section 3 clarifies the alignment of FAIR Principles with user needs and OD by exploring user needs related to findability, accessibility, interoperability, and reusability in the literature. Transitioning to a technical perspective, Section 4 outlines user requirements based on user needs in the context of user interfaces, accessibility, interoperability, and data portals. A requirement assessment ensues in Section 5, followed by a comprehensive FAIR Data provision requirements specification (Section 6). Finally, we conclude this deliverable by summarizing the insights gained for the ODECO project. D2.2 User needs from a technical perspective. 8 2. Methodology Finding the gaps that characterises the lack of a systematic integration of technical perspectives into understanding user needs related to open data is challenging. This section provides, firstly, a comprehensive foundation for our research method and approach to identify these gaps and secondly, it proposes technical requirements that may help to close the gap. It introduces Perspective-Based Reading (PBR) and how can it be useful to the elicitation of FAIR implementation recommendations . Next, this section outlines the method implemented in detail, including literature examination, requirement extraction, alignment with ODECO early-stage researchers' projects, and open data platform assessment, all aimed at user-centric, FAIR-compliant open data dissemination implementation. Additionally, it clarifies the scope of this deliverable, which focuses on technical requirements addressing open data user needs and introduces a Table defining key actors and stakeholders in the open data ecosystem for a better understanding of their roles and interests. 2.1. Theoretical foundations The methodological approach is based on Perspective-Based Reading (PBR) and its application to requirements documents (Victor, et al., 1996). The goal of PBR is to provide operational scenarios where members of a review team read a document (in this case, literature on open data) from a particular perspective (e.g., distinct types of open data users). The assumption is that the combination of different perspectives provides a better understanding of the topic, i.e., uncovers a wider range of requirements and gaps. OD user needs are often misunderstood and improperly specified due to lack of open data expertise in data publishers and bias on solving the needs of data publishers first during the requirements elicitation process of open data initiatives. To tackle these problems, we express open data user needs using user stories. A user story is a short, simple description of a feature told from the perspective of the user who wishes the capability. This approach has been proven successful in other challenging requirements elicitation and review scenarios (Femmer, Méndez Fernández, Wagner, & Eder, 2017; Villamizar, Kalinowski, Garcia, & Mendez, 2020). Discovery and reuse of OD by society maximize its usefulness. The FAIR principles describe the ideal way data should be stored and shared by data publishers to achieve this goal (Wilkinson, Dumontier, Aalbersberg, & al., 2016). FAIR stands for:  Findability is the extent to which humans and machines can easily discover (meta)data.  Accessibility is the extent to which humans and machines can fetch (meta)data successfully.  Interoperability is the extent to which different applications and systems can successfully communicate and exchange data with unambiguous, shared meaning.  Reusability is the extent to which (meta)data are well-described, rich, and appropriate so that others can reuse it. FAIR guiding principles do not dictate specific technological implementations, but provide guidance for improving Findability, Accessibility, Interoperability and Reusability of open data. However, this lack of technical specification may result in inconsistent interpretations that carry the risk of increasing the gap between user needs and open data portal features. We adhere to the vision expressed by (Jacobsen, et al., 2020) of explicit FAIR implementation considerations (i.e., FAIR technical requirements ) to operationalize the implementation of FAIR principles. Therefore, the identification of the principles implemented by the requirements will be one of the parts of the implemented methodology. D2.2 User needs from a technical perspective. 9 2.2. Strategy The first step is the examination of pertinent literature and sources gathered in the ODECO deliverable 2.1, "Open data user needs: seven flavours", for the identification of user needs that may possess a technical dimension. The identified user needs from different user types are correlated with the FAIR principles according to their content. This is a PBR activity. It is important to acknowledge that some user needs may be related with multiple FAIR principles. In such scenarios, the determination of their placement is guided either by the closest conceptual affinity or, in instances where an only source holds relevance to multiple FAIR principles, the identified need is associated to multiple principles. For example, it is quite easy from the text below to identify the following requirement that can be related to Findability: “Open data portal users demand feedback and collaboration tools, so they enable the possibility to read interesting thoughts and ideas of other users on the datasets through the comments they enter on them.” (Alexopoulos, Zuiderwijk, Charapabidis, Loukis, & Janssen, 2014) Section 3 contains a detailed report of the above examination. Next, we derive from the documentation a list of requirements that may have technical requirements in the form of user stories. This is a PBR activity but restricted to point of view and experience of the ODECO early-stage researchers in their own research projects. User stories typically follow a simple template: As a [type of user], I want [some goal] so that [some reason]. Example, in “as a visitor of the open data portal, I can access a list of old featured datasets that are no longer on the home page, so I can access datasets I remember from the past or that others mention to me” :  The type of user is a visitor of the open data portal.  The goal is to be able to access the list of old featured datasets.  The reason is to quickly access them on demand. To enrich the analysis, user stories should be rewritten in a systematic way. For each requirement, the outcome of this work should produce:  A unique ID (this can be done at a later stage).  A description of the feature, condition, capability; it should be based on the “goal.”  A description of the stakeholder who requested it; it should be based on the “type of user.”  A description of its relevance; it should be based on the “reason.” Section 4 shows the user stories and requirements identified following this procedure. Next, this list of requirements should be assessed. The discussion must answer at least the following questions: 1. Are the requirements implemented in open data platforms? 2. If they are implemented, are they implemented in a way that user needs are satisfied? 3. If the user needs are not satisfied, can we identify the root cause? Section 5 summarizes this assessment. Finally, we associate each requirement to the fulfilment of one or more of the FAIR principles outlined in the previous subsection. Section 6 presents the output of this task. 2.3. Scope User needs vary in nature and cover a wide range of related issues. Requirements derived from user needs include direct, indirect, functional, non-functional, governance and technical requirements. The D2.2 User needs from a technical perspective. 16 3.4. Reusability In the context of open data, reusability is a key aspect enabling data utilisation in more contexts and applications to promote new research, serve more purposes for society and boost innovation in products and services. Reusability allows data to serve multiple purposes beyond its original collection, enhancing analysis, meta-analysis, and research impact (ELIXIR, 2021).  Communication and Understanding End-User Needs: Users should be in touch with the data publisher and the data provider when required (Chattapadhyay, 2014; González-Zapata & Heeks, 2015; Heimstädt, Saunderson, & Heath, 2014). Establishing communication channels between data publishers and users can reduce the gap and foster a user-driven open data ecosystem. Organizational activities like events and campaigns facilitate this connection.  Skills Development: Users need to develop digital skills for effective use and analysis of open data (Erete, Ryou, Smith, Fassett, & Duda, 2016; Hou & Wang, 2017; Yoon, Copeland, & McNally, 2018; Walter, et al., 2021). Addressing the lack of skills and resources is crucial for successful use of open data in some settings, such as the educational, necessitating the use of various technological resources (Celis Vargas & Magnussen, 2022; Saddiqa, Magnussen, Larsen, & Myrup, Sept 2021; Ridgway, 2016; Van Audenhove, Van Den Broeck, & Mariën, 2020).  Privacy and Legal Aspects: Users have needs related to addressing challenges related to privacy and understanding legal aspects of licensing associated with data reusability. They are considered essential in some scenarios (Chattapadhyay, 2014; Cranefield, Robertson, & Oliver, 2014). For example, providing journalists with tools to handle identification and re-identification of personal data is crucial for enabling data reusability (Bozsik, Cheng, Kuncham, & Mitchell, 2022; Krotoski, 2012).  Data Quality and Reliability. Ensuring reliable, accurate, and consistent open data is a need vital in some reuse scenarios such as those where artificial users are involved (Janssen, Brous, Estevez, Barbosa, & Janowski, 2020; Lee, Nadri, Sanghavi, & Jeon, 2022; Schwoerer, 2022). Addressing data errors, biases, and improving data quality are clearly identified as user needs (Boyd & Crawford, 2012).  Contextualization and cultural alignment. In some scenarios, contextualization and cultural alignment are user needs. For example, integrating open data effectively into educational ecosystems requires considering as user needs cultural alignment and indigenous data infrastructure (Celis Vargas & Magnussen, 2022; Walter, et al., 2021).  Data Processing and Intermediaries: Open data, even in machine readable format, still requires additional processing and time-consuming procedures to reuse it (Wilson & Cong, 2021). User demands tools and capacity building to deal with data processing and engage with intermediaries can enhance data usability and further dissemination of resulting data products (Bezuidenhout, Leonelli, Kelly, & Rappert, 2017; Baack, Datafication and empowerment, 2015).  Transparency and Impact Assessment: Promoting transparency in data treatment and measuring the impact of data reuse are considered as user needs in some domains (Lawson, 2022; SandovalMartín & La-Rosa, 2018).  Data Visualization and Tools: Availability of tools for data visualization and processing big datasets is perceived by users as critical for efficient use of open data (Handler & Ferrer Conill, 2016; Badioze Zaman, Baharin, & Ahmad, 2021).  Engagement and Collaboration: Facilitating collaboration, public engagement, and partnerships that can lead to innovative uses of open data and broader societal benefit is considered a user need in some domains (Dander & Macgilchrist, 2022; Berntzen, Johannessen, Andersen, & Crusoe, 2019; Jarke, 2019; Handler & Ferrer Conill, 2016). D2.2 User needs from a technical perspective. 17 4. FAIR Principles from a technical perspective This Section shows the output of the process for deriving requirements from documentation by converting them into user stories, with a focus on the perspective and experiences of early-stage researchers in ODECO research projects. User stories typically consist of a template that includes the type of user, their goal, and the reason behind it. To enhance the analysis, user stories should be systematically rewritten for each requirement, resulting in a unique ID, a feature description based on the goal, a stakeholder description based on the type of user, and a relevance description based on the reason. 4.1. User Interfaces The Findability aspect of FAIR Data Provision is the primary focus. This principle of data discovery is acknowledged as the fundamental premise of data use. Data and metadata should be easy to find for both humans and computers. Rich metadata is essential to automatically discover datasets and their related services. One of the main research goals is the definition and evaluation of approaches for designing user driven user interfaces for finding data that fulfils different findability and accessibility requirements from different domains. It also addresses the identification of gaps between the needs of user groups and the current features of open data platforms. User stories Below we show a list of user stories with the purpose of facilitating the elicitation of technical requirements for the discoverability of open data domains. User stories are intended to reflect real-life situations users face when searching for data sets on open data portals for various purposes, whether their search goals are specific or exploratory. 1. As an open data portal user, I need tools that allow me to search for datasets under precise criteria so that I can identify valuable datasets to solve my information need. 2. As an open data portal user, I need tools that allow me to quickly explore the supply of datasets available in a portal so that I can identify valuable datasets for my domain and future information needs. 3. As an open data user, I need tools that allow me to quickly evaluate the result of a search so that I can more quickly find the most appropriate datasets. Requirements The functional and non-functional requirements associated with the findability dimension of the FAIR principles are shown in the Tables below. These requirements are directly derived from the available literature review and previously prepared user stories. Each requirement is accompanied by segments of stakeholders that could be particularly affected by it, as well as a brief reflection on its relevance with respect to user stories. Table 2: Functional requirements for user interfaces and findability ID Feature Stakeholder Relevance REQ-1 The ODP should provide a free text search bar to search datasets by keyword. Open data users Because it provides flexibility and precision in the search, as suggested in US-1. Keyword searches are one of the most common mechanisms in the mental model of search engine users. REQ-2 The ODP should offer a category menu to search for datasets by category. Open data users Because it provides flexibility and precision in search and navigation, as suggested in US - 1 and US - 2. D2.2 User needs from a technical perspective. 18 ID Feature Stakeholder Relevance REQ-3 The ODP should provide a map for the user to find relevant datasets associated with specific locations by drawing a bounding box. Open data users Because it provides flexibility and precision in the search, as suggested in US-1, especially in the case of users specialized in geographic or geolocated information. REQ-4 The ODP should provide a temporal filter that allows users to search for relevant datasets associated with specific periods. Temporality can be associated with the events described by the dataset itself or its creation or update date. Open data users Because it provides flexibility and precision in the search, as suggested in US-1. This functionality makes it possible to serve both users with historical interest in certain past periods and those who want the freshest and most recent data possible. REQ-5 The ODP should provide faceted filters to refine search results. Open data users Good filters provide selectivity, that is, the ability to narrow the search universe into manageable chunks. Faceted filters help to reduce information overload, as suggested in US - 3. REQ-6 The ODP should offer the user the possibility to sort the results according to different criteria (relevance, date, quality, size). Open data users Because it helps to reduce information overload, as suggested in US-3. This functionality is particularly useful for dealing with datasets with quantitative descriptors. REQ-7 The ODP should show the user lists of recommended datasets based on search history, popularity, or novelty. Open data users Because it facilitates the exploration of portal content, as suggested in US-2. Recommendations should facilitate users' ability to extract value from data and its relationships. REQ-8 The ODP should show the user a list of results identified by title and other relevant metadata elements. Open data users Because it helps to reduce information overload, as suggested in US-3. These elements should make it easier for the user to assess the potential of the resource for their information needs and speed up the overall search process. REQ-9 A user can view the full details about the metadata of a particular dataset. Open data users Metadata records should help to quickly assess the potential of the datasets found against the search criteria. D2.2 User needs from a technical perspective. 19 Table 3: Non-Functional requirements for user interfaces and findability ID Feature Stakeholder Relevance REQ-10 Dataset categories should be aligned to well-known standard vocabularies. Open data providers Because it provides flexibility and precision in the search, as suggested in US-1 and US-2. It is important to seek alignment to preexisting mental models in users, industry, and institutions. REQ-11 Dataset titles and descriptions should incorporate terms aligned to well-known standard vocabularies. Open data providers Because it provides flexibility and precision in search, as suggested in US-1. It is important to seek alignment to pre-existing mental models in users, industry, and institutions. REQ-12 Toponyms used by geographic search mechanisms must come from official and standardised sources. Open data providers Because it provides flexibility and precision in search, as suggested in US-1. It is important to seek alignment to pre-existing mental models in users, industry, and institutions. 4.2. Accessibility, interoperability, and technology In this Section, the technical (or technological) part of the interoperability term will be discussed with the help of user stories, and from these stories, functional requirements will be elicited. Furthermore, functional requirements may be related to performance, effectiveness, and efficiency aspects, which we will extract in the form of non-functional requirements. Interoperability is the "I" of FAIR. According to the Metadata Quality Assessment (MQA) methodology of the European Data Portal1, interoperability analysis is focused on analysing whether format information is available, formats can be recognized (belong to internationally accepted lists of formats), and formats are machine processable. The work on this topic could be to assess whether the data complies with the expected format, provide tools for the visualisation of data in different formats, and provide tools for data analysis, integration, transformation, data scrubbing, and data fusion (data fusion is the process of integrating multiple data sources to produce more consistent, accurate, and useful information than that provided by any individual data source). In this Section, more user stories, functional requirements, and non-functional requirements will come from the technology spectrum. Furthermore, these technical and functional requirements can help us narrow down the development of a smart data integrator that can be used to unify the datasets from different domains (e.g., governments, non-governmental organisations). Alternatively, this can lead to the development of a technology-based tool to help the users (data producers, consumers, and prosumers) in the open data ecosystem share, use, and re-use open data in the best way possible. User stories To facilitating the process of eliciting user requirements for the technical interoperability and accessibility of open data domains, a list of user stories is provided below. The motivation behind the extraction of user stories is to reveal a real-life depiction or representation of the problems that open data users are facing. What are these different open data user groups expecting and demanding from the open data ecosystem and infrastructure? How can these be fulfilled afterwards in a technical and technological way (technical interoperability in this scenario)? 1 https://data.europa.eu/mqa/methodology?locale=en D2.2 User needs from a technical perspective. 20 1. As an educational activist, I want smooth integration of open data to the education field so that open data could be useable by the students for better designing of education curriculum. 2. As an educational institute, I want open data in widely adoptable format so that schools, colleges, and universities can take benefits of the multi-format publishing. 3. As a teacher, I need to have data processing tools so that I can share authentic open data-based information or knowledge for my students. 4. As a student, I need to have access to data collections, generation tools such as sensors, devices, and environment so that I can be part of the open data ecosystem. 5. As a data intermediary, I want technological tool so that the social-technical barrier within our job could be reduced and job effectiveness and efficacy will be increased. 6. As a data intermediary, I need tool/s for my staff so that they can engage with open data in a more productive manner and readily get insights. 7. As a data intermediary, I need data augmentation tool to increase the quality of the dataset which already exists in the open data systems. 8. As a data intermediary, I need access to tools for the derivations of insights from the raw data so that to be able to deliver more insightful guidance to our customers. 9. As a data intermediary, I want to have a tool to evaluate the quality of open data so that the data curation process can be easy to implement. 10. As a publisher and OD consumer, I want data to be technically open so that data integration can be smooth and Users' access to data may be enhanced in this way, and the capacity to reuse and interchange data across multiple systems and applications can be fostered. 11. As a data intermediary, I need to have access to ensure that they have the data literacy they need to effectively analyse data, identify patterns, and communicate their results to relevant stakeholders. 12. As a data intermediary, I need to have common ground to access the domain specific knowledge so that the technical community of open data ecosystem could be enhanced. Like other communities exists in the world. 13. As a corporate user, I need to have proper profile of the dataset mentioning the quality and search options of the datasets so that they can reduce uncertainty and adoption risk of the open data. 14. As a corporate user, I want to have advanced open data searching and accessibility functionalities so that we can filter out datasets temporally, spatially, and textually to access and discover the datasets in an efficient manner to use this data further for analysis. 15. As a corporate user, I want to have a functionality which allows me to upload an updated version of an existing dataset so that other can re-use the modified version of the dataset. 16. As an artificial user, I need consistent and reliable data provision to feed into applications and algorithms to avoid the inaccurate results generated by faulty data sources or inconsistent formats. 17. As an artificial user, I need privacy and security protocols to preserve the legal and ethical usage of the open datasets. 18. As an artificial user, I need proper and continuous monitoring of my activities to make the accountability and transparency better. 19. As a data consumer, I need access to open data thorough smart phone so that I can access the open data in low-cost environment. 20. As a data consumer, I need access to mix valued datasets not just qualitative and quantitative contrary to existing situation. 21. As a data consumer, I need not only access to big data but also to be able to be searched, aggregated, and cross-referenced by any concerned side. 22. As a data consumer, I need statistics that describe the dataset volume, velocity, and veracity so that I can estimate the time, space, and computation powers to explore these datasets. 23. As a data consumer, I need access to the tools that suggest data interpretation and methodologies based on the underlying datasets so that the problem formalisation and solution are supported by the state-of-the-art at least. D2.2 User needs from a technical perspective. 21 24. As a data consumer, I need a proper statistical profile of the dataset explaining the claims about its verification from different researchers or independent entities. In this way, it would be easier to choose a dataset with better quality. 25. As a data publisher, I need a tool to verify the dataset if it contains someone's very personal or confidential data so that this data can be anonymized before publishing. 26. As a data consumer, I need to build my skillset in the field of data visualisation and build capacity regarding data issues (fragmentation, aggregated data, unreliable data, and sensitive data). 27. As a data publisher, I need to take data anonymisation into account in real-time in the data publishing phase. 28. As a data publisher, I need to automatically check the metadata suitability for the dataset in hand for publishing so that published data has a quality view. 29. As a data Publisher, I need an indigenous data infrastructure to ensure the indigenous governance to prove the priorities, values, and culture. 30. As a data publisher, I need functionality to evaluate the FAIR and CARE principles to contribute towards the improvement of data integration and the promotion of data reusability. 31. As a data consumer, I need tools to better communicate my issues and opportunities with the data providers, or producers, in a better way. 32. As a data publisher, I need functionality in the open data portals so that citizens can participate to complete missing datasets. 33. As a data consumer, I need access to variety of integrated datasets from different fields. 34. As data publisher, I need functionalities or features to reduce the complications in data formatting, sourcing, data collection, and others. 35. As a data publisher, I need support in building technical capacity to publish datasets in an efficient and effective way. 36. As a data publisher, I need real-time functionality to draw insights about the openly available datasets. 37. As a data consumer, I need functionality to access, find, and discover the dataset, but keep in mind I am having special conditions. 38. As a data consumer, I need to know about the data contextualisation, such as breaches, discrepancies, algorithmic transparency, and other errors available in the dataset. 39. As a data publisher, I need tools to improve the use and re-usability of the OGD data. 40. As a journalist, I need tool for the investigative journalism purpose. 41. As a journalist, I need to detect the low-trust dataset in the open data spaces. 42. As a journalist, I need functionalities in the tool to visualize and generate compelling stories for the public. 43. As a journalist, I need to have access to the portable open data infrastructure if I want to publish my local datasets. 44. As a data consumer, I need access to multi-format, multi-way (e.g., API and Bulk download) datasets to access and analyse in depth. 45. As a Data publisher, I need access to the data transformation tools or functionalities to provide the dataset in Level of Detail (LOD) format. 46. As a Data consumer, I need to have functionalities to explore the LOD cloud to generate insights asap from the datasets. 47. As a Data publisher, I need to have functionalities where I can publish datasets from multiple government agencies in a unified and accessible way. Requirements To elicit technical or technological requirements related to open data accessibility and interoperability, we have recorded or collected user needs from different user groups in section 3, e.g., education, NGOs, Journalism, and government. The user needs have been transformed into user stories, which are specifically related to data accessibility, interoperability, and technology. By using these user stories, user requirements have been elicited by following a structured approach such as feature (what the user D2.2 User needs from a technical perspective. 22 wants), stakeholder (to which user group that stakeholder belongs), and relevance (why the user wants this feature). For instance, if a user-story demands the functionality of data processing tools, its relevance could be explained as "the data analysis tool can help end-users engage without any coding experience or less expertise required." In this manner, user-stories are used to extract user requirements related to accessibility, interoperability, and technology. The Tables below present the user functional and non-functional requirements that need to be fulfilled for the smooth functioning of the features. Table 4: Functional requirements for accessibility, interoperability, and technology ID Feature Stakeholder Relevance REQ-13 Open data should be useable by the students Educational institutions open data could be useable by the students for better designing of education curriculum (US-1) REQ-14 Open data should be available using standard data format/serialisation Educational institutions A widely acceptable open data format can enhance the accessibility, useability, and reuseability of open data (US-2) REQ-15 Low-code data processing tools should be available. Teachers By having data analysis tool in which less coding, or expertise required, a teacher can extract information for the students (US3) REQ-16 Tool for data sharing dedicated to open data intermediaries should be available Open data intermediaries This might consist of software designed specifically for intermediaries, data-sharing networks, or collaborative platforms (US-5). REQ-17 Tools for active data analysis should be available Open data intermediaries Users need assistance with tasks like data collecting, data augmentation, contextualisation, and visualisation, all of which may be accomplished with the use of appropriate tools or platforms (US - 6). REQ-18 Data integration tools for the data intermediaries should be available Open data intermediaries Need data automation, collection, and integration solutions to make the process of data integration simpler. It is crucial for open data intermediaries to have access to technology that simplifies the process of acquiring data from a variety of sources (US-7) REQ-19 Quality enhancement tools (data augmentation tools) should be available Open data intermediaries Quality enhancement tools can be used to improve the quality of the existing open datasets. For different type of datasets, we need different tools e.g., image augmentation, text data augmentation (US-8) D2.2 User needs from a technical perspective. 23 ID Feature Stakeholder Relevance REQ-20 Tools to generate the insights from the raw data should be available Open data intermediaries access to tools for the derivations of insights from the raw data so that to be able to deliver more insightful guidance to our customers. These tools may assist users in generating meaningful and interactive visual representations of the data and in deriving insights from open data resources, which may help users better interpret and utilize the data (US-9). REQ-21 Tools to evaluate the data quality should be available Data intermediaries The availability of software tools that may assist intermediaries in evaluating and validating open data is necessary to ensure the data's high quality and dependability (US-10). REQ - 22 Datasets should be technically open Open d ata users and provider By opening the datasets, it technically means to follow the dataset standards, formats, and other protocols to enhance the data integration across different systems and to facilitate the better accessibility of the open data (US - 11). REQ-23 Advanced open data searching and accessing tools should be available Corporate users A user filters out datasets in many ways (e.g., temporally, spatially, textually, and others) to access and discover the datasets in an efficient manner to use this data for further ana lysis (US - 15). REQ-24 Users should be allowed to upload updated versions of existing datasets Corporate users A user can upload an updated version of the existing dataset. In this way, other users can use cleaned, modified, augmented, or transformed datasets for specific tasks (US-16). REQ-25 Consistent and reliable delivery of datasets should be provided to the artificial users Artificial users consistent and reliable data provision to feed into applications and algorithms to avoid the inaccurate results generated by faulty data sources or inconsistent formats (US-17). REQ-26 Access to open data through smart phone should be available Open data users Using a smart phone to access the open data, participation in the open data ecosystem can be enhanced. The smart gadgets are easily purchasable and accessible in all countries (US-20). D2.2 User needs from a technical perspective. 24 ID Feature Stakeholder Relevance REQ-27 Big data search, aggregation, and integration should be available Open data users The intensive searching, aggregation, and integration of big datasets can contribute to the sustainability and value creation of the open dataset (US-22). REQ-28 Big dataset categorisation should be available Open data users In this way, the formalisation of the working or experimental environment and the estimation of the efforts to achieve the solution will be easier (US-23). REQ-29 Data interpretation should be available Open data users Data interpretation should be accompanied by a set of suitable methodologies that could be useful for the underpinning dataset. In this way, a better solution can be found. A tool explaining or suggesting the data exploration and cleaning methodologies would be a plus (US - 24). REQ-30 Capacity-building tool for data consumers should be available Open data users In modern open data spaces, capacity-building tools in the areas of data visualisation, data fragmentation, aggregation, and detection of unreliable datasets are required (US-27). REQ-31 Anonymisation of the open dataset before publishing must be the norm Open data providers The tools developed to anonymize the dataset can help the publishers anonymize the feature or properties, which can lead to the identification or reidentification of individuals in the OD spaces (US - 28). REQ-32 Indigenous data infrastructure may be required Open data providers an indigenous data infrastructure to ensure the indigenous governance to prove the priorities, values, and culture (US30). REQ-33 A functionality to complete the missing values in the datasets with the help of citizens is needed Open data providers In this way, more complete data sets can be provided to the citizens with real values (augmentation) (US-33). REQ - 34 Making available i ntegrated datasets from diverse fields for users with diverse needs is needed Open d ata users The necessity for integration of data and accessibility feasible for user groups with varying needs (e.g., visual impairment, dyslexia, and others) is also emphasized by Ossom-Williamson et al. (OssomWilliamson, Williams, Kim, & Kindratt, 2021) (US-34). D2.2 User needs from a technical perspective. 25 ID Feature Stakeholder Relevance REQ-35 Functionalities for reducing datarelated complications should be available Open data users and providers In this way, a data producer can produce the dataset in the easiest way possible and integrate the dataset into the ecosystem in a more convenient and adaptive way for the data consumers (US35). REQ-36 Real-time integrated visualisation functionalities in open data portals are needed Open data users data that is available openly, even in machine-readable format, still requires additional processing and time-consuming procedures to understand it. A countermeasure as an intermediate step of this situation is the use of data visualisations, interactive mapping and graphs, and the provision of other intuitive media integrated in the data platform (US - 37). REQ-37 Functionalities to detect low-trust dataset are needed Open data users There can be a big matrix to decide the trustworthiness of the dataset itself, or its source should be available (US - 42). REQ-38 Tools to visualize and create compelling storytelling for complex datasets are required Open data users Journalists demands Visualisation and compelling storytelling tools for the purpose of increasing the public's participation and having a better view of the problem or news (US - 43). REQ-39 Portability of infrastructure in the open data domain is necessary Open data providers The portability of infrastructure will help transfer the knowledge of OD infrastructure to another organi s ation (US - 44). REQ-40 Provision of datasets in LOD format is demanded Open data providers Enhancing the reusability of the open data by provision of data in LOD, Helping the providers with the data publication process, Quantifying the open data deployment schema, specifying a methodology, tool, or software to publish the 1-star data as a 5-star data, LOD preparation and publishing environment (US-46) REQ-41 Functionalities to explore Linked open data cloud are needed Open data users Linked open data cloud exploration techniques: This can help the journalists to find the real-time breaking news stories by exploring the large, linked datasets (US-47). D2.2 User needs from a technical perspective. 32 ID Feature Stakeholder Relevance updates. Metadata and reuse standards like open data licenses promote data sharing and accessibility. REQ-72 ODP should recommend similar datasets based on the previous search results Open data users and providers Data portal can recommend the similar datasets based on the interests of the user and previous search of the user REQ-73 All users of Data portal should have the functional knowledge about data interpretation and data curation Open data intermediaries Software for evaluating, validating, and curating open data Table 9: Non-functional requirements for data portals and reusability ID Feature Stakeholder Relevance REQ-74 All users who want to get involved with the open data portal should know the basics of data and information. Open data users Involving end users in data gathering and somehow in decision making process make the data portal more user-driven. REQ-75 If users who want to use an open data portal and create value added value must have digital skills. Educators, students, journalists, and intermediaries. Acquiring basic understanding of technology as well as access to various data sources and tools. REQ-76 If a user wants to engage with the open data community, then an open data portal must provide a forum where users can connect with each other. Open data users and developers A common feature of data portal is to facilitate a forum where user to user communication and project collaboration is possible. REQ-77 Tech-oriented solutions or platforms to incorporate Open Data education into the curriculum should be available. Policy makers, curriculum designers, academic institutions Policy makers, curriculum designers, academic institutions or any other stakeholders involved in promoting the integration of Open Data education want Open Data to be used by all students. D2.2 User needs from a technical perspective. 33 5. Requirements assessment In the previous section, we derived a set of requirements, setting the stage for the next crucial step: assessing these requirements. This assessment will revolve around key questions: firstly, whether these requirements are currently integrated within open data platforms; secondly, if they are indeed implemented, whether they effectively meet user needs; and lastly, in cases where user needs are not met, identifying the root causes for this shortfall. The purpose of this evaluation is to assess the alignment between the derived requirements, their practical implementation, and user satisfaction levels within open data platforms. Our approach to analysing the needs of potential open data users has been technically focused. We aimed to identify and translate these needs into functional and non-functional requirements. Specifically, this work has sought to elicit the technological requirements for OD user within the FAIR data provision paradigm. The methodology outlined in section 2 has led to the identification of 77 requirements – 55 functional and 22 non-functional. These requirements span the dimensions of FAIR data principles, aligning with the research objectives of the ODECO project. Importantly, the requirements extracted from the literature to translate the FAIR principles do not contradict one another. For example, a single requirement could pertain to the accessibility or interoperability of open data, highlighting the interdependence among the FAIR dimensions. However, determining the exact adherence to one, two, or three FAIR principles can be challenging due to this interdependence. In extracting technological requirements from the identified user stories, a primary challenge was incorporating the user perspective in the elicitation process. The FAIR dimension of findability is linked to the user through interaction with user interfaces. Interoperability, accessibility, and reusability are more technically oriented and operate in the background. While user stories might offer an initial overview and intuition of what could be expected, more targeted (less general) requirements may necessitate alternative methods such as expert opinions and questionnaires. For instance, if the user desires data stream continuity, the user in this case did not specify at what level of the open data provision they want data stream continuity, either for data publication from the providers or for the usability of the datasets (e.g., API and bulk download), or even if they want continuous provision of open datasets. The first set of technical requirements are focused on findability, recognizing it as the foundation for a successful user experience within an open data portal. The volume, diversity, and complexity of modern datasets mean that efficient search and navigation tasks consume an enormous amount of energy and time on the part of users. Findability functional requirements focus on providing practical tools for users to search for relevant datasets in a multidimensional way, from simple and well-known mechanisms such as keywords to more elaborate filters involving temporal and spatial aspects. On the other hand, the findability non-functional requirements emphasize the need to use a known language in all the labelling systems of the information architecture of ODP. The identified requirements illustrate the dependence between the dimensions of the FAIR principles. Findability depends on interoperability. For instance, REQ-48 refers to the need for datasets to have schema.org tags for semantic meaning, clearly indicating the dependence between semantic interoperability and findability of data. In addition, the findability affects reusability because if data is not discovered in a timely manner, then this becomes a bottleneck for it to be reused. However, a major limitation regarding findability requirements is that they are often formulated with ODPs in mind as the main delivery mechanism. This relies on the literature assumption that users who have information needs turn to these platforms to search for data organically, which is not necessarily the case. This raises the challenge of extending findability to multiple contexts and information search platforms such as D2.2 User needs from a technical perspective. 34 search engines, social media, mobile apps, and other popular internet outlets. This reinforces the connection of findability with the principles of semantic data interoperability. In the case of accessibility, the requirements elicited focus on the ability of users (and other interested stakeholders) to access the data they found, whether that refers to direct or indirect factors which affect this procedure. Understandably, accessibility is closely related to findability, due to the latter being an absolute prerequisite for the former, however, it also gets affected to a higher or lesser degree by interoperability issues. The functional requirements regarding accessibility, include, among others, the necessity for technological tools (e.g., data analysis tools, capacity-building tools, data interpretation, and more) in order to allow for easier access to the data, the possibility to access open data(sets) through mobile devices, and real-time integrated visualizations of data in the portals. The nonfunctional requirements identified for accessibility refer to arisen issues such as the technical support needed when multiple sources are integrating data, or to keep the performance level of technological tools high. As mentioned previously, accessibility is also directly or indirectly affected by interoperability, an example being that if datasets available in the data portal are not linked to existing knowledge representation schemata (e.g., vocabularies or ontologies), which is something necessary for the semantic interoperability of data, the data might become non-findable and consequently, not accessible by the interested stakeholders. Moreover, datasets in the data portal need to be available in machinereadable and processable format to be accessible both by human and non-human agents. The rationale behind the integration of solutions which address the identified accessibility requirements is the ability for a wider share of interested stakeholders to access data, regardless of their level of expertise or means to access the data. In addition to the above-mentioned points regarding accessibility-related requirements elicited in this document, we highlight additional requirements, such as centralized data provision hubs, robust infrastructure without broken links, and access to data in efficient methods (APIs, streaming, direct download, etc.). Smooth, stable, and sustainable data access to all-inclusive stakeholders in the open data ecosystem, specifically businesses and organizations, is better at lowering the barriers to open data access, promoting inclusivity, and bridging the digital divide. As far as interoperability is concerned, the requirements identified are related mostly to the ability of the ODP to provide the users with functionalities such as improved search and results retrieval, data of improved quality and guidelines on how users can assist in this process, usage of technological means in order to achieve and smoothen data integration, enhance quality, boost discoverability and contextual search, provide data visualisation to the users, access to data, and more. In further detail, interoperability functional requirements aim to describe what the system under analysis should be capable of doing. In our case, the essence of the identified functional requirements appear to be lying around some central themes, such as data integration, data standardisation, data sharing techniques, data processing tools for analysis, visualisation and interpretation, data quality improvement techniques, improved contextual data search (semantic search, user filters, advanced search), facilitated accessibility and infrastructure for access through portable devices, or for users with specific needs, linked data technologies to facilitate data interoperability across data portals and improve knowledge representation across various domains to support reuse and increase the semantic value of data (e.g., providing clear guidelines to the user upon data upload on how to link their data to existing resources), and improved metadata. When it comes to interoperability non-functional requirements (how the system is expected to perform certain actions) regarding interoperability, technology and semantics, the prevalent themes which were identified in the analysis include the performance and scalability of OD infrastructures, the data integration from multiple sources, data integrity and reliability, the linking of data available to known knowledge representation schemata (vocabularies, ontologies) for conceptual connection to their respective domain(s), the data availability in a standardized way (e.g., following metadata standards), as well as the provision of proper thematic tags which offer semantic meaning and facilitate the interested stakeholders. The requirement details about interoperability (from D2.2 User needs from a technical perspective. 35 a technological and semantic perspective) are a higher-level description of the essential parameters constituting the functional and non-functional requirements to sum them up. However, they can understandably be fragmented into more case-specific requirements which reflect the necessities of a specific context and application domain. Since data reusability plays such a crucial part in the smooth functioning of an open data portal, it is the focus of the first set of requirements. The sheer size, variety, and complexity of today's data environments make it imperative that we find ways to make data reusable. These reusability specifications cover both practical and theoretical concerns, with the end goal of providing both end users and administrators with the resources they need to make data reuse a breeze. Basic data processing and quality control knowledge are required for portal administrators and data users to meet the functional criteria for reusability. These abilities are fundamental in making the portal's data both easily accessible and of superior quality, increasing its reusability. In addition, these requirements highlight the value of semantic annotations like Schema.org tags, which provide context and importance to data. Annotations like this are crucial since they increase data interpretability and encourage its reuse. However, the relevance of digital literacy among users is highlighted by the non-functional requirements for reusability. Everyone, from teachers to students to data nerds may find something useful in open data portals. The data provided via these platforms is only useful if users have the digital literacy to find their way around, interpret it, and put it to effective use. Additionally, open data portal participation criteria are crucial to reusability. Data must be understood, and user-driven portals work best when users actively participate in data collecting and decision-making. This collaborative approach increases the portal's content and promotes interdisciplinary problem-solving. The interplay between reusability and accessibility is also evident. Open data portals provide enterprises, institutions, and organizations the freedom and adaptability to utilize data for many reasons. This accessibility allows data exchange across governmental, business, and non-profit sectors, encouraging interdisciplinary cooperation to solve complicated problems. From the literature review on technical needs, we can see the challenge of dealing with diverse interpretations. For instance, there may be gaps in the interpretation of what FAIR principles mean for stakeholders in different contexts. For example, accessibility in FAIR refers primarily to retrievability of data and metadata, whereas in many other spaces web accessibility is better understood as the ability for diverse users to perceive, understand, navigate, interact, and contribute to content. D2.2 User needs from a technical perspective. 36 6. FAIR Data provision requirements specification In the following Section, we consolidate the work undertaken in the preceding Sections, where we systematically derived and assessed requirements based on user stories. Our focus now shifts towards aligning each of these requirements with the fundamental principles of FAIR data management outlined in the preceding subsection. This critical association process allows us to examine how each requirement contributes to the realization of the FAIR principles, thus providing a comprehensive understanding of how our efforts contribute to the overarching goal of fostering FAIR data practices within our context. 6.1. Requirements for findability Table 10: Functional requirements for findability ID Feature Stakeholder Why is related to findability REQ-48 All the comments to the comments of the open data portal users on third party datasets should have schema.org tags to provide a semantic meaning. Open data users Because with this requirement we can prioritize in searches the comments that can be more relevant to their profile. REQ-51 The data portal should provide the functionality of guiding the users through the process of linking data to existing resources to allow for semantic connection. Open data users This way new data that is added to the portal is in superior quality and ready to be discovered by other users. REQ-50 The data portal should provide the functionality of allowing the users to improve the quality of data (e.g., enrich metadata) if they discover the dataset lacks it, and there should be guidelines to the user to do it correctly. Open data users This way users can contribute to data quality and improve the status of the datasets they are interested in using, making them more usable and discoverable to other users. Table 11: Non-functional requirements for findability ID Feature Stakeholder Why is related to findability REQ-52 The data portal should provide recommendations to help the user while searching, based on semantic technologies (such as linked open vocabularies). Open data users The user can receive more accurate recommendations on finding what they are looking for instead of just inputting keywords and getting loosely relevant results. REQ-53 The data portal should provide alternative input methods for search (e.g., based on the geospatial location of the user or temporal criteria they might insert). Open data users The search function is easy for the user and returns relevant results according to the users’ geospatial in formation in a straightforward manner which does not require digital literacy skills. REQ-58 All the comments to the comments of the open data portal users on third party datasets should have schema.org tags to provide a semantic meaning. Open data users Because with this requirement we can prioritize in searches the comments that can be more relevant to the user profile. REQ-59 The datasets in the data portal should be linked to knowledge Open data users This way, the most relevant topics for choosing datasets to be used in D2.2 User needs from a technical perspective. 37 ID Feature Stakeholder Why is related to findability representation schemata (such as vocabularies and ontologies) to have connected semantic meaning. and School curriculum designer the education context can be shown according to their proximity with other linked topics. REQ-60 The datasets in the data portal should have proper thematic tags to reflect sufficiently their actual content. Open data users This way, the user can more easily discover data relevant to their profile, profession, or desired subject of search. 6.2. Requirements for accessibility Table 12: Functional requirements for accessibility ID Feature Stakeholder Why is related to accessibility REQ-55 The data portal should provide information about dataset even when these are not available anymore, the dataset metadata should still be accessible. Open data users The dataset itself might not be available anymore but the context (coming from the metadata) will still enable the user to conduct their intended study properly (it could be needed for historical or personal reasons). REQ-26 Access to open data through smart phone. Open data users Using a smart phone to access the open data, participation in the open data ecosystem can be enhanced. The smart gadgets are easily purchasable and accessible in all countries. REQ-14 Standard data format/serialisation. Educational Institutions A widely acceptable open data format can enhance the accessibility, useability, and reusability of open data. REQ-49 The datasets used in an education context should provide proper visualisations and stories related to their content. Open data users and School students The study information based on OD included in the curriculum can become more appealing and interesting. 6.3. Requirements exclusive for interoperability Table 13: Functional requirements for interoperability ID Feature Stakeholder Why is related to interoperability REQ-13 Integration of education open data educational institutions Open data integration covers the data exchange, transfer, and integration within or between different OD systems. REQ-16 Tool for data sharing dedicated to open data intermediaries Open data intermediaries Data sharing is also a subfunctionality or feature of the open data interoperability. REQ - 18 Data integration tools for the data intermediaries Open d ata intermediaries Need data automation, collection, and integration solutions to make the process of data integration simpler. It is crucial for open data D2.2 User needs from a technical perspective. 38 ID Feature Stakeholder Why is related to interoperability intermediaries to have access to technology that simplifies the process of acquiring data from a variety of sources. The integration of OD from diverse sources constitutes OD interoperability. REQ-20 Tools to generate the insights from the raw data Open data intermediaries access to tools for the derivations of insights from the raw data so that to be able to deliver more insightful guidance to our customers. These tools may assist users in generating meaningful and interactive visual representations of the data and in deriving insights from the many resources of open data, which may help users better interpret and utilize the data. This functionality requires OD interoperability. REQ-22 Technical openness of the datasets Open data users and providers By opening the datasets, it technically means to follow the dataset standards, formats, and other protocols to enhance the data integration across different systems and to facilitate the better accessibility of the open data. Technical openness contributes to the technical interoperability of open data. REQ-24 Allowing the user to upload their dataset Corporate users A user can upload an updated version of the existing dataset. In this way, other users can use cleaned, modified, augmented, or transformed datasets for specific tasks. This feature also contributes to the OD interoperability. REQ-25 Consistent and reliable delivery of datasets to the artificial users Artificial users consistent and reliable data provision to feed into applications and algorithms to avoid the inaccurate results generated by faulty data sources or inconsistent formats. This feature requires formal OD interoperability principles to be applied. REQ-27 Big data search, aggregation, and integration Open data users The intensive searching, aggregation, and integration of big datasets can contribute to the D2.2 User needs from a technical perspective. 39 ID Feature Stakeholder Why is related to interoperability sustainability and value creation of the open dataset. Aggregation and integration mean a clear connection between this feature and OD interoperability. REQ-31 anonymisation of the open dataset before publishing Open data providers The tools developed to anonymize the dataset can help the publishers anonymize the feature or properties, which can lead to the identification or reidentification of individuals in the OD spaces. This can help with the legal and organisational interoperability of the OD. REQ-39 portability of infrastructure in the open data domain Open data providers The portability of infrastructure will help transfer the knowledge of OD infrastructure to another organisation or other OD system. Common, portable, or standardized data infrastructure can help increase the interoperability of O D. REQ-40 Provision of datasets in LOD format Open data providers Enhancing the reusability of open data by providing data in LOD In return, the interoperability of the open data might be semantically increased. And it can help with the technical interoperability of the open data, such as access, integration of data through SPARQL REQ-43 Data integration from multiple sources Open data users and providers The data integration process should be transparent to avoid any discrepancies in the data. It would be useful for artificial users as well. Data integration from multiple sources increases the interoperability of the open data ecosystem. REQ - 61 The datasets in the data portal should adhere to data models and metadata standards (e.g., DCAT). Policy/Decision makers By doing so, the quality of the data is improved, so decisions based on this data are more likely to be dependable and trusted. More widely adopted dataset standards will enhance the semantic interoperability of open data. REQ-62 The datasets in the data portal should be linked to knowledge representation schemata (such as Policy/Decision makers in a company This way the interested user can see relations and conceptual connections among data, helping D2.2 User needs from a technical perspective. 40 ID Feature Stakeholder Why is related to interoperability vocabularies and ontologies) to have connected semantic meaning. them to develop better strategies. More widely adopted dataset standards will enhance the semantic interoperability of open data. REQ-48 All the comments to the comments of the open data portal users on third party datasets should have schema.org tags to provide a semantic mean ing. Open data providers By doing so, the semantic interoperability of data is improved. REQ-50 The data portal should provide the functionality of allowing the users to improve the quality of data (e.g., enrich metadata) if they discover the dataset lacks it, and there should be guidelines to the user to do it correctly. Open data providers By doing so, the semantic interoperability of data is improved, in a co-creative manner. REQ-51 The data portal should provide the functionality of guiding the users through the process of linking data to existing resources to allow for semantic connection. Open data providers By doing so, the semantic interoperability of data is improved, allowing the users to also contribute to this process. REQ-54 The data portal should provide clear guidelines on how new dataset uploaded in the portal meets community standards or domain relevant standards. Open data Contributors When a new dataset is uploaded it instantly adheres to community standards, thus improving interoperability. Table 14: Non-functional requirements for interoperability ID Feature Stakeholder Why is related to interoperability REQ-42 Functionalities to publish unified and easily accessible dataset from multiple sources. Open data providers Sometime data is produced by multiple government agencies but is not published in a uniform and easily accessible manner, to not only share the analytical findings from the government data but also the collated and sanitized data itself (US-48). REQ-46 Performance and scalability of the OD infrastructure. Open data users and providers Emerging database technologies, cloud services, and modern data collection devices are being introduced around the globe, so open data infrastructure should be scalable enough to support these technological transformations. D2.2 User needs from a technical perspective. 41 ID Feature Stakeholder Why is related to interoperability REQ-47 The manual development for each functionality or services provided by the OD portal. Open data providers Documentation is the key part of the use and re-use of the open data services, and data itself. It would be necessary to provide the end-user with documentation to understand the data and portals. REG-61 The datasets in the data portal should adhere to data models and metadata standards (e.g., DCAT). Policy/Decision makers and Open data users By doing so the data quality and semantic interoperability is improved. REQ - 63 The datasets in the data portal should be linked to knowledge representation schemata (such as vocabularies and ontologies) to have conceptual connection. O pen data users and intermediaries This way data intermediaries can more easily curate or structure data in the right context, improving semantic interoperability. REQ-66 The datasets in the data portal need to be available in machinereadable and processable format. Civil servants and Open data users The data used in the daily activities of public systems (e.g., in electronic services), can seamlessly run through different systems, thus they are more interoperable. REQ-45 Data integrity and quality. Open data users and providers The data should be accurate, dependable, and up to date. Quality assurance processes must be in place to detect and resolve any inconsistencies or errors in the data, making it more interoperable. REQ-62 The datasets in the data portal should be linked to knowledge representation schemata (such as vocabularies and ontologies) to have connected semantic meaning. Policy/Decision makers in a company This way the interested user can see relations and conceptual connections among data. REQ-65 The datasets in the data portal should be linked to the most prevalent ontologies and vocabularies of their respective domain. Professionals and Domain experts Build on the knowledge around each domain based on other, conceptually related domains, thus enabling interdomain interoperability. REQ-64 The datasets related to healthcare in the data portal should be linked to the most prevalent ontologies and vocabularies in the biomedical sector. Healthcare professionals and Open data users Helps the professional in their occupation (they can see where else their domain knowledge is useful) and improved diagnosis. REQ-67 The datasets related to law and legislation in the data portal should be linked to the most prevalent ontologies and vocabularies in the legal sector. Legal professionals and Open data Users Helps the professional compare legislations among different countries and have a faster and better overview of existing laws and practices, as well as conflicts. D2.2 User needs from a technical perspective. 48 Martin, J. A., Camaj, L., & Lanosga, G. (2022, November). Scrape, Request, Collect, Repeat: How Data Journalists Around the World Transcend Obstacles to Public Data. Journalism Practice , 1–18. doi:10.1080/17512786.2022.2142837 Meng, A. H. (2016, December). THE SOCIAL IMPACT OF OPEN GOVERNMENT DATA. Georgia Institute of Technology. Retrieved from https://repository.gatech.edu/entities/publication/02f7b7868b2d-4c9f-8e1c-2c921d471167 National Library of Medicine. (2023, 8 8). Data Interoperability. Retrieved from https://www.nnlm.gov/guides/data-glossary/data-interoperability Navalkha, C. (2021, June). Data for Housing Justice: Examining Activists’ Use of Open Government Data for Housing Justice in Boston, MA and New York, NY. Massachusetts Institute of Technology. Ph.D. dissertation, MIT. doi:https://dspace.mit.edu/handle/1721.1/138973?show=full Neumaier, S., Umbrich, J., & Polleres, A. (2016). Automated quality assessment of metadata across open data portals. Journal of Data and Information Quality (JDIQ), 8 (1), 1-29. Ocaña, M. G., Opdahl, A. L., & Dang-Nguyen, D.-T. (2021). Emerging News task: Detecting emerging events from social media and news feeds. MediaEval 2021 Workshop. 3181. CEUR. Retrieved from https://ceur-ws.org/Vol-3181/paper7.pdf Ossom-Williamson, P., Williams, I. M., Kim, K., & Kindratt, T. B. (2021, April). Reporting and Availability of COVID-19 Demographic Data by US Health Departments (April to October 2020): Observational Study. JMIR Public Health and Surveillance, 7 , e24288. doi:10.2196/24288 Paley, A., Zhao, A. L., Pack, H., Servantez, S., Adler, R. F., Sterbentz, M., . . . Hammond, K. (2021, June). From data to information: automating data science to explore the U.S. court system. The 18th International Conference on Artificial Intelligence and Law (pp. 119–128). São Paulo Brazil: ACM. doi:10.1145/3462757.3466100 Palova, D., & Vejacka, M. (2022, May). Experience with Open Data in Project Based Learning. 2022 45th Jubilee International Convention on Information, Communication and Electronic Technology (MIPRO) (pp. 689–694). Opatija: IEEE. doi:10.23919/MIPRO55190.2022.9803595 Petricek, T. (2022, September). The Gamma: Programmatic Data Exploration for Non-programmers. 2022 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC) (pp. 1–7). Roma: IEEE. doi:10.1109/VL/HCC53370.2022.9833134 Porlezza, C., & Splendore, S. (2019, October). From Open Journalism to Closed Data: Data Journalism in Italy. Digital Journalism, 7 , 1230–1252. doi:10.1080/21670811.2019.1657778 Publications Office of the European Union. (2022). The Economic Impact of Open Data Opportunities for value creation in Eruope. Publications Office. Radchenko, I., & Sakoyan, A. (2014). The View on Open Data and Data Journalism: Cases, Educational Resources and Current Trends. In D. I. Ignatov, M. Y. Khachay, A. Panchenko, N. Konstantinova, & R. E. Yavorsky (Eds.), Analysis of Images, Social Networks and Texts (Vol. 436, pp. 47–54). Cham: Springer International Publishing. doi:10.1007/978-3-319-12580-0_4 Radchenko, I., & Sakoyan, A. (2016). On Some Russian Educational Projects in Open Data and Data Journalism. In D. Mouromtsev, & M. d’Aquin (Eds.), Open Data for Education (Vol. 9500, pp. 153–165). Cham: Springer International Publishing. doi:10.1007/978-3-319-30493-9_8 Reggi, L., & Dawes, S. S. (2022). Creating Open Government Data ecosystems: Network relations among governments, user communities, NGOs and the media. Government Information Quarterly, 39 (2). Ricker, B., Cinnamon, J., & Dierwechter, Y. (2020, September). When open data and data activism meet: An analysis of civic participation in Cape Town, South Africa. The Canadian Geographer / Le Géographe canadien, 64 , 359–373. doi:10.1111/cag.12608 Ridgway, J. (2016, December). Implications of the Data Revolution for Statistics Education: The Data Revolution and Statistics Education. International Statistical Review, 84 , 528–549. doi:10.1111/insr.12110 Rind, A., Pfahler, D., Niederer, C., & Aigner, W. (2016). Exploring Media Transparency With Multiple Views. 9th Forum Media Technology 2016 , 1734. St. Pölten, Austria. Retrieved from https://ceurws.org/Vol-1734/fmt-proceedings-2016-paper8.pdf D2.2 User needs from a technical perspective. 49 Ruijer, E., Porumbescu, G., Porter, R., & Piotrowski, S. (2023, March). Social equity in the data era: A systematic literature review of data-driven public service research. Public Administration Review, 83 , 316–332. doi:10.1111/puar.13585 Saddiqa, M., Magnussen, R., Larsen, B., & Myrup, J. (Sept 2021). Digital innovation in education: Perspectives, opportunities and challenges of educational open data and sensor data., (pp. 7483). Saddiqa, M., Rasmussen, L., Magnussen, R., Larsen, B., & Pedersen, J. M. (2019, August). Bringing open data into danish schools and its potential impact on school pupils. Proceedings of the 15th International Symposium on Open Collaboration (pp. 1–10). Skövde Sweden: ACM. doi:10.1145/3306446.3340821 Safarov, I., Meijer, A., & Grimmelikhuijsen, S. (2017, May). Utilization of open government data: A systematic literature review of types, conditions, effects and users. Information Polity, 22 , 1–24. doi:10.3233/IP-160012 Sandoval-Martín, M. T., & La-Rosa, L. (2018, January). Big Data as a differentiating sociocultural element of data journalism: the perception of data journalists and experts. Communication & Society , 193–208. doi:10.15581/003.31.4.193-209 Saxena, S., & Muhammad, I. (2018, February). Barriers to use open government data in private sector and NGOs in Pakistan. Information Discovery and Delivery, 46 , 67–75. doi:10.1108/IDD-052017-0049 Schwoerer, K. (2022, December). Whose open data is it anyway? An exploratory study of open government data relevance and implications for democratic inclusion. (E. Ruijer, & S. Piotrowski, Eds.) Information Polity, 27 (4), 491–515. doi:10.3233/IP-220008 Selwyn, N., Henderson, M., & Chao, S.-H. (2017, April). The possibilities and limitations of applying ‘open data’ principles in schools. Cambridge Journal of Education, 47 (2), 167–187. doi:10.1080/0305764X.2016.1143449 Shadbolt, N., O'Hara, K., Berners-Lee, T., Gibbins, N., Glaser, H., Hall, W., & Schraefel, M. C. (2012, May). Linked Open Government Data: Lessons from Data.gov.uk. IEEE Intelligent Systems, 27 , 16–24. doi:10.1109/MIS.2012.23 Shaharudin, A., Van Loenen, B., & Janssen, M. (2023, June). Towards a Common Definition of Open Data Intermediaries. Digital Government: Research and Practice, 4 , 1–21. doi:10.1145/3585537 Shehu, V., Mijushkovic, A., & Besimi, A. (2016, August). Empowering Data Driven Journalism in Macedonia. Proceedings of the The 3rd Multidisciplinary International Social Networks Conference on SocialInformatics 2016, Data Science 2016 (pp. 1–6). Union NJ USA: ACM. doi:10.1145/2955129.2955187 Shibuya, Y., Lai, C.-M., Hamm, A., Takagi, S., & Sekimoto, Y. (2022, October). Do open data impact citizens’ behavior? Assessing face mask panic buying behaviors during the Covid-19 pandemic. Scientific Reports, 12 , 17607. doi:10.1038/s41598-022-22471-y Smith, D. A. (2016, May). Online interactive thematic mapping: Applications and techniques for socioeconomic research. Computers, Environment and Urban Systems, 57 , 106–117. doi:10.1016/j.compenvurbsys.2016.01.002 Splendore, S., Salvo, P. D., Eberwein, T., Groenhart, H., Kus, M., & Porlezza, C. (2016). Educational strategies in data journalism: A comparative study of six European countries. Journalism, 17 , 138-152. doi:10.1177/1464884915612683 Staso, D. D., López Reyes, M. E., Papageorgiou, G., Vargas, A. C., Pilshchikova, L., Santoro, C., . . . Shaharudin, A. A. (2023). Open data user needs: seven flavours. Towards a sustainable Open Data ECOsystem. Retrieved from https://odeco-research.eu/wpcontent/uploads/2023/06/ODECO-D2.1-Open-data-user-needs-seven-flavours_Final.pdf Tabary, C., Provost, A.-M., & Trottier, A. (2016, January). Data journalism’s actors, practices and skills: A case study from Quebec. Journalism, 17 , 66–84. doi:10.1177/1464884915593245 Thakuriah, P., Dirks, L., & Keita, Y. M. (2017). Digital Infomediaries and Civic Hacking in Emerging Urban Data Initiatives. In P. Thakuriah, N. Tilahun, & M. Zellner (Eds.), Seeing Cities Through Big Data (pp. 189–207). Cham: Springer International Publishing. doi:10.1007/978-3-319-40902-3_11 D2.2 User needs from a technical perspective. 50 Van Audenhove, L., Van Den Broeck, W., & Mariën, I. (2020, December). Data literacy and education: Introduction and the challenges for our field. Journal of Media Literacy Education, 12 , 1–5. doi:10.23860/JMLE-2020-12-3-1 Van Loenen, B., Zuiderwijk, A., Vancauwenberghe, G., Lopez-Pellicer, F. J., Mulder, I., Alexopoulos, C., . . . Casiano Flores, C. (2021, December). Towards value-creating and sustainable open data ecosystems: A comparative case study and a research agenda. JeDEM - eJournal of eDemocracy and Open Government, 13 , 1–27. doi:10.29379/jedem.v13i2.644 Van Schalkwyk, F., Verhulst, S. G., Magalhaes, G., Pane, J., & Walker, J. (2017). The Social Dynamics of Open Data. African Minds. doi:10.47622/978-1-928331-56-8 Victor, B. R., Green, S., Laitenberger, O., Lanubile, F., Shull, F., Sørumgård, S., & Zelkowitz, M. V. (1996). The empirical investigation of Perspective-Based Reading. Empirical Software Engineering (1), 133-164. Villamizar, H., Kalinowski, M., Garcia, A., & Mendez, D. (2020). An efficient approach for reviewing security-related aspects in agile requirements specifications of web applications . Requirements Engineering (25), 439–468. Walter, M., Lovett, R., Maher, B., Williamson, B., Prehn, J., Bodkin-Andrews, G., & Lee, V. (2021, June). Indigenous Data Sovereignty in the Era of Big Data and Open Data. Australian Journal of Social Issues, 56 , 143–156. doi:10.1002/ajs4.141 Wang, T. (2016). Why Big Data Needs Thick Data. Ethnography Matters, Medium. Wilkinson, M., Dumontier, M., Aalbersberg, I., & al., e. (2016). The FAIR Guiding Principles for scientific data management and stewardship. Scientific Data, 3 . Wilson, B. K., & Chakraborty, A. (2019). Planning Smart(er) Cities: The Promise of Civic Technology (Vol. 26). Journal of Urban Technology. doi:10.1080/10630732.2019.1631097 Wilson, B., & Cong, C. (2021, May). Beyond the supply side: Use and impact of municipal open data in the U.S. Telematics and Informatics, 58 . doi:10.1016/j.tele.2020.101526 Windhager, F., Mayr, E., Schreder, G., & Smuc, M. (2016, December). Linked Information Visualization for Linked Open Government Data. A Visual Synthetics Approach to Governmental Data and Knowledge Collections. JeDEM - eJournal of eDemocracy and Open Government, 8 , 87–116. doi:10.29379/jedem.v8i2.436 Yoon, A., Copeland, A., & McNally, P. J. (2018, January). Empowering communities with data: Role of data intermediaries for communities' data utilization. Proceedings of the Association for Information Science and Technology, 55 , 583–592. doi:10.1002/pra2.2018.14505501063 Zeleti, F. A., & Ojo, A. (2017). Capability Development in Open Data-Driven Organizations. In A. Ojo, & J. Millard (Eds.), Government 3.0 – Next Generation Government Technology Infrastructure and Services (Vol. 32, pp. 135–171). Cham: Springer International Publishing. doi:10.1007/978-3319-63743-3_6 Zhang, S. (2022, May). Teaching Spatial Literacy in an Equity-Informed Public Engagement: An Academic Library’s Case Study. Journal of Map & Geography Libraries, 18 , 131–142. doi:10.1080/15420353.2022.2147626 Zuiderwijk, A., Janssen, M., Poulis, K., & Van De Kaa, G. (2015, May). Open data for competitive advantage: insights from open data use by companies. Proceedings of the 16th Annual International Conference on Digital Government Research (pp. 79–88). Phoenix Arizona: ACM. doi:10.1145/2757401.2757411 Zuiderwijk, A., Volten, C., Kroesen, M., & Gill, M. (2018, October). Motivation Perspectives on Opening up Municipality Data: Does Municipality Size Matter? Information, 9 , 267. doi:10.3390/info9110267