1. Introduction

2. Methodology

3. Results

3.1. A Revised Data Spaces Building Block Stack

3.1.1. Review and Comparison of Data Spaces-Related Initiatives and Blueprints

After reviewing the most prominent initiatives regarding data spaces definitions and related solutions and standards proposals, these were mapped to each other to highlight the reciprocal relationships, the respective scopes or main focuses and the progression and dependencies in the reference documents [30]. Figure 32 summarises the progression of the different initiatives and related proposed architectures developed over time.

Aspects of interoperability and data sharing (see Section 1.1) are relevant to enable effective data spaces. However, several data spaces-related conceptualisations [12,16], are focussed on data sovereignty and trust. By contrast, the institutions involved in (geo)data standardisation (e.g. Joint Research Centre - INSPIRE, Open Geospatial Consortium) or information sharing through the web (e.g. World Wide Web consortium) have been developing solutions and standards to support data interoperability for some time.

3.1.2. Identification of a Initial Baseline Suite of Building Blocks

Considering the timeline of different initiatives, as well as the participation of main actors in the data spaces conceptualisation and implementation, in thi study, the building blocks proposed by the DSSC [18] were taken as the initial baseline for data space building blocks. As a European funded project, DSSC supports the participation of other (not only) European funded activities such as Gaia-X, IDSA, BDVA (Section 3.1.1), besides building on European efforts and regulations. In addition, the project DS4SSCC considers the same building blocks as a reference for its catalogue, in which some standards are already mapped, alongside the Minimum Interoperability Mechanisms defined by OASC. The GREAT Blueprint [19] acknowledges the proposed building blocks as a reference, in addition to the mapping of building blocks and components proposed by the different initiatives. Grothe [13] also makes a mapping of the proposed blueprints and architectures over an initial version of building blocks, pointing out the main scope of the considered projects and initiatives.

The DSSC building blocks are grouped into ‘Technical’ building blocks, and ‘Governance and Business’ building blocks. Although governance and business are essential aspects and will be addressed in the near future, in this paper, the focus is on the technical building blocks, and the provision for semantic interoperability. For each building block the alternative solutions are mapped, starting from the mapping already done by the DS4SSCC, critically re-considered against these concerns and relevance of further standards and solutions, primarily coming from the OGC standards, INSPIRE and GEO references. When the direct reference to DS4SSCC remains in the Tables in Annex 1, it is because additional standards are reported by DS4SSCC, with respect to the main references considered in this paper.

3.1.3. Improved Mapping to Available Solutions through Increased Building Block Granularity

Such a mapping to current solutions highlighted the need for an increase in granularity in the proposed building blocks to allow their consistent use (Figure 4). In particular, under the ‘data exchange’ aspect, both the communication technology, such as Application Programming Interfaces (APIs), and the format to encode data should be considered, and these are two separate issues, for which different standards and solutions apply.

Similarly, usage policy specification and the control over the compliance to the terms established in the policy should be considered separately as they regard (a) the way in which to express and encode the policy terms and (b) the solutions used to read and enforce such terms.

“Data services and offerings description” is intended to describe metadata. However, these should be described for each of data, software and services. It may be noted that, in a workflow, such elements correspond to the core concepts of the W3C Provenance model: Entities, Agents and Activities. To keep these distinctions clear and provide appropriate interoperability standards for each case, additional building blocks are needed.

Figure 4. Re-factored Technical Building Blocks stack, following the mapping to solutions and their scopes.

Figure 4. Re-factored Technical Building Blocks stack, following the mapping to solutions and their scopes.

3.2. Building Blocks Integration Aligning to Agreed International Principles

International principles and recommendations for good management and sharing of data (Section 1.1) were mapped to the building blocks baseline. These principles are a major driver in the digital economy that cannot be ignored, and they have to be explicitly addressed to benefit from related resources and be adopted by a broad community. Additional changes were generated in the proposed building blocks stack in order to make it consistent with such principles, as well as able to include additional standards and components being developed and tested for data spaces developments in the green deal data spaces-related HORIZON projects, in particular USAGE (Figure 5).

Considering FAIR principles, the ‘Data Interoperability’ category was generalised to address a wider range of aspects, and the title was revised into ‘Data FAIRness’. It will be important that, for each dataset involved in a data space, all the aspects listed under the ‘Data FAIRness’ category would be properly documented into extended versions of metadata, including or linking to:

• Data Model used, which should be based on standards, typically specifying the used profile (i.e., the subset of a more comprehensive data model, if applicable) and possible extensions. using standardised documentation of them and machine-readable encodings to possibly support data validation as well. Data models and profiles should specify:

  -

  the semantic and structural description of the data,

  -

  the use of geometry and any related aspect, such as the kind of representation used (as solids, as surfaces, polygons, lines, raster), kind of geometry stored, any topology representation required, level of detail or resolution, accuracy, and so on.

• Data Exchange – Encodings, related to the syntax.
• Data description (metadata) (moved from the ‘Data value creation’ category after splitting from the related service).
• Provenance and Traceability extends the attribute ‘provenance’ or ‘lineage’ of typical "discovery" metadata allowing the visibility of underlying data supply chains critical to a suitable understanding of, and subsequent reusability of the data.
• Data Licences (moved from the ‘Data Sovereignty and Trust category’ after splitting from the related control service), indicating the conditions for use of the data and reusability of derived outputs.

The ‘Data Value Creation’ category is renamed as ‘Tools for FAIRness’ to emphasise that the contained solutions are not adding to the instrinsic value of data, but rather enabling full leveraging of this value by means of the FAIR principles’ comprehensive support.

The ‘Data exchange - communication (e.g. APIs for data exchange)’ building block (previously under ‘Data Interoperability’) has been moved to the ‘Tools for FAIRness’ category,. Moreover, a building block for ‘Data requirements specification and data validation’ was added. In fact, it is essential to agree on standardised methodologies and, possibly, supporting tools, to define exactly the data requirements, considering all the building blocks contained in the ‘Data FAIRness’ category.

Data requirements specifications connect needs of a use case and the processing required to the the datasets needed to be retrieved, or produced to order. Highly detailed definition of many aspects of such data requirements, including the needed data quality, are necessary to support evaluation, planning and any possible automation of data re-use and integration steps.

When such data requirements are defined in a machine-readable encoding, automatic data validation against them becomes possible, ensuring that data to be input into processing have the sufficient quality and characteristics, and the result of processing or analysis has, therefore, the expected reliability. They enable pipeline automation as well as the advantage given by data spaces. In addition, several aspects related to services were not placed within the building block stack, despite playing a relevant role in supporting data preparation for sharing, data use, analysis, processing and so on. Such software should exist for the whole data space in order to deliver maximum benefit. In addition, it needs to be suitable for connection to the ecosystem, as well as able for managing standardised data, or any shared data, properly. Therefore, we proposed an additional category addressing ‘Services FAIRness’ and which contains the related building blocks - both from the previous stack, such as the ‘Software descriptions (metadata)’ and new proposals, for example those to support documentation and definition of access to software and the related licences.

Figure 5. Integrated proposed building block stack aligning with principles and solutions components (USAGE D3.2).

Figure 5. Integrated proposed building block stack aligning with principles and solutions components (USAGE D3.2).

3.2.1. Building Blocks Refinement with Input from Experts and Green Deal Data Spaces Projects

Each building block proposed by USAGE (Figure 5) was critically reconsidered by the AD4GD consortium, during a hackathon in Turin, in early February 2024, capitalising on the experience gained by the consortium during the first part of the project, including the development of AD4GD use cases and supporting architecture. Moreover, experience of the consortium partners (deeply involved in OGC, FIWARE and other interoperability-related initiatives and projects) in longer term interoperability solutions and technology developments was brought to the discussion to justify the proposed changes (Figure 6).

The pillar on ‘Data Sovereignty & Trust’ only underwent minor changes. For example, one more building block, the ‘Sharing traceability’, was added to address traceability of the data. This one came from the splitting of the original DSSC ‘Provenance and Traceability’ building block in two: one about solutions helping to track the data and their use, and one about expressing provenance according to standards, i.e., the ‘Data Provenance models’, which remained within the pillar ‘Data FAIRness’.

Within the ‘Data FAIRness’ pillar, we retained unchanged the ‘Data Models’ building block, ‘Data Descriptions (metadata)’, Data Exchange (encodings) and ‘Data Licences’. In addition, ‘Data requirements schemas’ was added, as complementary to ‘Data requirements system (definition + validation)’ under ‘Tools for FAIRness’, both resulting from the split of the previous ‘Data requirements specification’. Symmetrically to ‘Data Licences’, a ‘Licences for Services’ building block was added under ‘Services FAIRness’.

Under the category ‘Tools for FAIRness’ the building blocks were added: - Vocabularies and Meaning service, i.e. services enabling semantic interoperability by defining and providing terms and mechanisms to represent and leverage "shared knowledge" in different domains; - Data transformation, i.e. any mapping tool and routines facilitating data integration and conversions.

Moreover, ‘Vocabularies’ were added as a transversal building block for both Data FAIRness and Services FAIRness categories, since they are relevant tools to support all the blocks in those categories.

Finally, we added a category, which we considered as not being entirely part of the data spaces, but rather interacting with it (possibly under the concept of ‘digital twin’), to host all computation-related building blocks, i.e.: processing, software access (previously under ‘Services FAIRness’), workflows and actuators.

We also considered adding the data space assets (contents) themselves, which were classified as requirements, metadata, provenance, semantic tagging, data (including personal data) and licences.

Figure 6. Abstract architecture diagram for the GDDS from AD4GD hackathon and discussion.

Figure 6. Abstract architecture diagram for the GDDS from AD4GD hackathon and discussion.

3.2.2. Rediscussed Building Blocks Validation

As the result of the final workshop, the panel of experts as described in Section 2.1 reported their feedback about each choice made to map the DSSC building blocks to the available standards, and components used in the projects and current pilots, through a form. These results were used as a base for a discussion to find a consensus over such a mapping and extension. It was the opportunity to clarify which components could be interpreted in different ways, if the mapping was aligned to general experience of standards and interoperable systems, as well as with the similar discussions in national and international venues, in which the panel experts are taking part.

Finally, as the DSSC blueprint evolved in parallel, and, although the study had started at the end of 2023 on the base of the DSSC Blueprint v.0.5, published in September 2023, we compared the results of the discussion with the updated DSSC Blueprint v.1.0 structure and definitions, which was published in March 2024, and applied the needed adjustments.

Figure 7 depicts the result of the DSSC data spaces building blocks extension based on the mapping done (below), compared to the DSSC Blueprint v.1.0 technical building blocks (above).

In Table 2, the definitions of each building block and the possible changes with respect to the DSSC Blueprint are reported, as well as the reasons behind them.

Figure 7. Data spaces building blocks stack, coming from the DSSC blueprint (above) and as resulting from the final comments and results of the discussion in this paper (below).

Figure 7. Data spaces building blocks stack, coming from the DSSC blueprint (above) and as resulting from the final comments and results of the discussion in this paper (below).

3.4. Measuring Standards Quality and Uptake

To further guide users and data spaces developers in the choice of suitable standards, some indications would be useful about the quality of the standards, supported technology and level of uptake (e.g. available compliant datasets, available supporting software, supported use cases in research or in operational environment and so on).

When choosing a set of technical standards from many options, with varying degrees of overlap and interdependencies, it is essential to apply a systematic approach to evaluate the quality of standards and their appropriateness for collective adoption. Standards quality is separate, but related to, uptake and maturity. All three aspects are factors in the evaluation of, and decision to reuse, specific standards. It should be noted that, whilst quality is not the ultimate arbiter of uptake, adoption by the developer community is a key enabler and driver of solutions, and is usually driven by some aspect that is perceived as providing advantages – e.g. quality of design.

Therefore, we should explore standards quality from the perspective of Data Spaces requirements, and then follow up to explore how best to allow this quality to be seen as attractive to the developer community.

It is worth noting that the ultimate goal of the data interoperability and management principles (Section 1.1) is realised through data reuse itself. The evaluation processes that trigger reuse are supported by the specific principles, but other factors also play a significant role. For data this includes design factors, such as how the data is gathered and how appropriate this is to the end use requirements. To achieve this ultimate goal, significant attention must be paid to the FAIR principle I1: “(Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation.” This has implications for the way metadata are handled: it is not possible to specify metadata standards for all possible aspects of all possible data sets. Thus, it is recommendable to provide extensible graph solutions that can adapt to the available forms of metadata, even if some aspects of the metadata need to be standardised to meet data space requirements.

This language must be expressive enough to convey, in a standardised and recognisable way, the details required for evaluation. The technical implication is that syntactical languages such as JSON, RDF serialisations, XML etc. are necessary but not sufficient – the description of the data itself must also be standardised, and in turn this means that common aspects must be standardised, as per FAIR R1.3. “(Meta)data meet domain-relevant community standards”.

For data spaces to function as intended, the interoperability of standards for data and function description thus becomes paramount. As no two datasets or functions are identical, it follows that such standards need to be composable into application-specific descriptions from standardised components. In addition, the composition process needs to be standardised, hence the concept of such components as reusable modules (see for example the OGC Location Building Blocks [66]).

Some approaches to standards assessment have been proposed in the past. The most widely-known in the European context is the ‘Common Assessment Method for Standards and Specifications’ (CAMSS) [67] provided by the European Commission. This is intended to guide public authorities in the choice of suitable standards through an online questionnaire, supporting the European Interoperability Framework recommendations. Other examples come from the Open Data Initiative [68] organisation, which made some investigations interviewing users and experts, and drafted guidelines for choosing open standards [69].

Building on these examples and on the experience matured in the field of standards development, in this Section we propose initial criteria that might be useful to present standards transparently and quantitatively (Table X), so that similar ones can be more easily compared and chosen by the users, facilitating an effective data space development. This might also support discussion and collaboration between different standardisation organisations, to complement each other or to support reciprocal compliance for the sake of mutual advantage.

In future work, we will further test and investigate these criteria, to provide a more robust and agreed reference matrix.

Table 3. Proposed criteria to describe and assess standards

Table 3. Proposed criteria to describe and assess standards

Relevance and Scope	Fit for Purpose: Ensure that the standards align with the specific needs and objectives of the domain. Adoption within a domain is an obvious indicator of quality, but should be qualified by any activities to improve such standards based on experience of usage. Scope Coverage: Evaluate whether the standards cover all necessary areas without significant gaps. Overlapping standards should be assessed to see if they offer complementary benefits or if they introduce redundancy. Alignment: have alignments between related standards in use or proposed been published and available for re-use (noting that transformations of data are a significant overhead in most re-use scenarios, availability of tested transformation mechanisms make it easier to combine different standards in practice).
Flexibility and Extensibility	Modularity: Building Block composition mechanisms must be explicit and supported by tooling to realise the principle of reuse. Such mechanisms must include explicit traceability of interoperability design, through transparent and standardised description of building block dependencies. Furthermore, such building blocks need to be composable into larger building blocks that use the same composition mechanisms, to allow the rich metadata required to evaluate and reuse resources to be assembled and understood. This has been a critical weakness of formal standardisation processes - leading to many alternative ad-hoc approaches to standardisation in application profiles, Adaptability: Standards should be flexible enough to accommodate future changes and extensions. Avoid overly rigid standards that may hinder innovation or adaptation to new requirements Special vs. General Solutions: Prefer standards that provide flexible, general solutions over those offering special case solutions, unless the special case is critical and cannot be addressed adequately by the general standard.
Interoperability and Integration	Compatibility: Standards should work well together and integrate smoothly, minimizing the need for custom adapters or significant modifications. Interdependencies: Assess the interdependencies between standards. Strongly interdependent standards should be adopted together only if they provide a cohesive, integrated solution. Transparency: Machine readable declarations of compatibility and interdependencies allows for cost-effective and scalable testing and reuse of integrated suites of standards
Simplicity and Clarity	Simplicity: Choose standards that support simplification through encapsulation – the ability to test and compose arbitrarily complex complete solutions from simple components Ease of Understanding: Standards should be clear, well-documented, and easy to understand. Complex standards can lead to misinterpretation and implementation errors. Examples: Standards should be supported by clear examples to allow practitioners to easily understand scope of standards. Examples should be tested to conform to standards, as discrepancies are common and cause significant confusion.
Support and Ecosystem	Tool Support: Consider the availability of software tools and libraries that support the standards. Robust tool support can significantly ease implementation and maintenance. Community and Vendor Support: Evaluate the level of community and vendor support. Widely adopted standards with active communities and strong vendor backing are often more reliable and future-proof.
Maturity and Stability	Proven Track Record: Mature standards that have been widely adopted and tested in various contexts are usually more reliable. Stability: Prefer standards that are stable and have a clear roadmap for updates and maintenance. Frequent changes can disrupt development and integration processes.
Compliance and Security	Regulatory Compliance: Ensure that the standards comply with relevant regulations and industry best practices. Security: Assess the security implications of the standards. They should support the implementation of secure systems and not introduce vulnerabilities.
Cost and Resource Considerations	Implementation Cost: Consider the cost of implementing and maintaining the standards, including licensing fees, if any. Resource Availability: Ensure that the necessary skills and resources are available for adopting and maintaining the standards.

When evaluating and selecting a set of standards, a structured approach will support sustainability:

• Requirements Analysis: Define the specific needs and objectives the standards must meet.
• Standards Identification: Identify potential standards and gather detailed information about each.
• Evaluation and Comparison: Apply the principles in Table X to evaluate and compare the standards. A matrix will be proposed in future work to assess each standard against these criteria.
• Integration Assessment: Examine how the standards will work together, considering interdependencies and potential conflicts.
• Pilot Implementation: Conduct a pilot implementation to test the chosen standards in a real-world scenario.
• Decision and Adoption: Based on the evaluation and pilot results, make an informed decision and proceed with the adoption of the selected standards.

By carefully considering these principles, organizations can choose a set of technical standards that are high-quality, appropriate for their needs, and conducive to building a robust, scalable, and maintainable system.

References

1. Heath, T.; Bizer, C. Linked data: Evolving the web into a global data space (Vol. 1), 3rd ed.; Morgan & Claypool Publishers, 2011. [Google Scholar]
2. Halevy, A.; Franklin, M.; Maier, D. Principles of dataspace systems. In Proceedings of the twenty-fifth ACM SIGMOD-SIGACT-SIGART symposium on Principles of database systems, June 2006; pp. 1–9. [Google Scholar]
3. Kasamani, S.B.; Lukandu, A.I.; Gregory, W. Modelling Dataspace Entity Association Using Set Theorems. Computer Technology and Application 2012, 3. [Google Scholar]
4. Zuiderwijk, A.; Janssen, M.T. Open data policies, their implementation and impact: A framework for comparison. Government information quarterly 2014, 31, 17–29. [Google Scholar] [CrossRef]
5. Braunschweig, K.; Eberius, J.; Thiele, M.; Lehner, W. The state of open data. Limits of current open data platforms 2012, 1, 72. [Google Scholar]
6. Huijboom, N.; Van den Broek, T. Open data: an international comparison of strategies. European journal of ePractice 2011, 12, 4–16. [Google Scholar]
7. Tandy, J.; van den Brink, L.; Barnaghi, P.; Homburg, T. Spatial Data on the Web Best Practices; OGC, W3C, 2023. Available online: https://www.w3.org/TR/2023/DNOTE-sdw-bp-20230919/ (accessed on 8 July 2024).
8. Abhayaratna, J.; Daemen, E.; Janowicz, K.; Parsons, E.; Smith, R.; Verschoor, F. The Responsible Use of Spatial Data; OGC, W3C, 2021. Available online: https://www.w3.org/TR/responsible-use-spatial/ (accessed on 8 July 2024).
9. Wilkinson, M.D.; Dumontier, M.; Aalbersberg, I.J.; Appleton, G.; Axton, M.; Baak, A.; Mons, B. The FAIR Guiding Principles for scientific data management and stewardship. Scientific data 2016, 3, 1–9. [Google Scholar] [CrossRef] [PubMed]
10. EU. New European Interoperability Framework – Promoting seamless services and data flows for European public administrations; ISBN 978-92-79-63756-8. [CrossRef]
11. Lin, D.; Crabtree, J.; Dillo, I.; Downs, R.R.; Edmunds, R.; Giaretta, D.; De Giusti, M.; L’Hours, H.; Hugo, W.; Jenking, R; Khodiyar, V.; Martone, M.E.; Mokrane, V.N.; Petters, J.; Sierman, B.; Sokolova, D.V.; Stockhause, M.; Westbrook, J. The TRUST Principles for digital repositories. Sci Data 2020, 7, 144. [Google Scholar] [CrossRef] [PubMed]
12. Otto, B.; Steinbuß, S.; Teuscher, A.; Lohmann, S.; et al. Reference architecture model; Version 3; International Data Spaces Association, 2019; Available online: https://internationaldataspaces.org/wp-content/uploads/IDS-Reference-Architecture-Model-3.0-2019.pdf (accessed on 8 July 2024).
13. Grothe, M. Exploring data space initiatives; Geonovum, 2023. Available online: https://www.geonovum.nl/uploads/documents/Exploring%20data%20space%20initiatives%20v0.52_EN%20publication%20version%20Geonovum.pdf (accessed on 8 July 2024).
14. Ulrich, A.; et al. Design principles for Data Spaces, Version 1.0.; OpenDEI, International Data Spaces Association, 2021. (accessed on 8 July 2024). [CrossRef]
15. Farrell, E.; Minghini, M.; Kotsev, A.; Soler-Garrido, J.; Tapsall, B.; Micheli, M.; Posada, M.; Signorelli, S.; Tartaro, A.; Bernal, J.; Vespe, M.; Di Leo, M.; Carballa-Smichowski, B.; Smith, R.; Schade, S.; Pogorzelska, K.; Gabrielli, L.; De Marchi, D. European Data Spaces: Scientific insights into data sharing and utilisation at scale, 3rd ed.; Publications Office of the European Union: Luxembourg, 2023; JRC129900. [Google Scholar] [CrossRef]
16. Gaia-X. Gaia-X - Architecture document. 2022. Available online: https://gaia-x.eu/wp-content/uploads/2022/06/Gaia-x-Architecture-Document-22.04-Release.pdf (accessed on 8 July 2024).
17. Gronlier, P.; Hierro, J.; Steinbuss, S. Technical convergence – Discussion Document; Data Spaces Business Alliance, 2023. Available online: https://data-spaces-business-alliance.eu/wp-content/uploads/dlm_uploads/Data-Spaces-Business-Alliance-Technical-Convergence-V2.pdf (accessed on 8 July 2024).
18. DSSC. Blueprint, Version 0.5; 2023. Available online: https://dssc.eu/space/BPE/179175433/Data+Spaces+Blueprint+%7C+Version+0.5+%7C+September+2023 (accessed on 8 July 2024).
19. Santoro, M.; Mazzetti., P. GREAT D3.2 Final Blueprint of the GDDS Reference Architecture. 2024. Available online: https://www.greatproject.eu/wp-content/uploads/2024/04/D3.2-Final-Blueprint-of-the-GDDS-Reference-Architecture.pdf (accessed on 8 July 2024).
20. DSSC. Blueprint, Version 1.0; 2024. Available online: https://dssc.eu/space/BVE/357073006/Data+Spaces+Blueprint+v1.0 (accessed on 8 July 2024).
21. Noardo, F.; Atkinson, R.; Simonis, I.; Villar, A.; Zaborowski, P. OGC Data Exchange Toolkit: Interoperable and Reusable 3D Data at the End of the OGC Rainbow. In Recent Advances in 3D Geoinformation Science - Proceedings of the 3D Geoinfo Conference; Kolbe, T.H., Donaubauer, A., Beil, C., Eds.; Springer Nature Switzerland, 2024; pp. 761–779. [Google Scholar]
22. Chignard, S. A brief history of open Data. ParisTech Review. 2013. Available online: http://www.paristechreview.com/2013/03/29/brief-history-open-data/ (accessed on 8 July 2024).
23. Directive 2007/2/EC of the European Parliament and of the council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE). Available online: https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://knowledge-base.inspire.ec.europa.eu/publications/directive-20072ec-european-parliament-and-council-14-march-2007-establishing-infrastructure-spatial_en&ved=2ahUKEwivsMPsuv6FAxWxg_0HHU7TBKMQjBB6BAgKEAE&usg=AOvVaw3qAi9koTOasyha4tbMdIUd (accessed on 8 July 2024).
24. Directive 2003/98/EC of the European Parliament and of the Council of 17 November 2003 on the re-use of public sector information. Available online: https://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2003:345:0090:0096:en:PDF (accessed on 8 July 2024).
25. WIS Timelines. Available online: https://community.wmo.int/en/activity-areas/wis/wis-timelines (accessed on 8 July 2024).
26. World Wide Web Consotium - W3C. Available online: https://www.w3.org (accessed on 8 May 2024).
27. Open Geospatial Consortium - OGC. Available online: https://en.wikipedia.org/wiki/Open_Geospatial_Consortium; https://www.ogc.org (accessed on 8 May 2024).
28. Group on Earth Observations. Available online: https://earthobservations.org; https://en.wikipedia.org/wiki/Group_on_Earth_Observations#:~:text=GEO%20was%20established%20formally%20in,Observation%20Summit%20in%20Washington%2C%20DC (accessed on 8 July 2024).
29. International Data Spaces Association - IDSA. Available online: https://internationaldataspaces.org (accessed on 9 May 2024).
30. USAGE Deliverable 3.2 - Data space prototype and report - first version. Available online: https://drive.google.com/file/d/1FyvNkWkAWkuKKHh-3l529VUu5LIKyu5E/view?usp=drive_link (accessed on 8 July 2024).
31. Urban Data Space for Green deal - USAGE project. funded within the HORIZON Europe programme (GA. 101059950). Available online: https://www.usage-project.eu (accessed on 9 May 2024).
32. Common European Data Spaces. Available online: https://digital-strategy.ec.europa.eu/en/policies/data-spaces (accessed on 8 July 2024).
33. International Standardisation Organisation - ISO. Available online: https://www.iso.org/home.html (accessed on 8 July 2024).
34. W3C-OGC Spatial Data on the Web Working Group Charter. Available online: https://www.w3.org/2021/10/sdw-charter.html (accessed on 8 July 2024).
35. Global Earth Observation System of Systems - GEOSS. Available online: https://old.earthobservations.org/geoss.php (accessed on 8 July 2024).
36. FAIR principles. Available online: https://www.go-fair.org/fair-principles/ (accessed on 8 July 2024).
37. GEOSS Data Management Principles. Available online: https://old.earthobservations.org/documents/dswg/201504_data_management_principles_long_final.pdf (accessed on 8 July 2024).
38. CARE principles. Available online: https://en.wikipedia.org/wiki/CARE_Principles_for_Indigenous_Data_Governance (accessed on 8 July 2024).
39. ISO 25012. Available online: https://iso25000.com/index.php/en/iso-25000-standards/iso-25012 (accessed on 8 July 2024).
40. ISO 25010. Available online: https://www.iso25000.com/index.php/en/iso-25000-standards/iso-25010 (accessed on 8 July 2024).
41. OSI model. Available online: https://en.wikipedia.org/wiki/OSI_model (accessed on 8 July 2024).
42. DSSC Glossary. Available online: https://dssc.eu/space/Glossary/55443460/DSSC+Glossary+%7C+Version+1.0+%7C+March+2023 (accessed on 8 July 2024).
43. DSSC starter Kit. Available online: https://dssc.eu/space/SK/29523973/Starter+Kit+for+Data+Space+Designers+%7C+Version+1.0+%7C+March+2023 (accessed on 8 July 2024).
44. OpenDEI project. Available online: https://www.opendei.eu (accessed on 8 July 2024).
45. Support Centre for Data Sharing deliverables. Available online: https://dssc.eu/space/DC/408059908/Support+Centre+for+Data+Sharing (accessed on 8 July 2024).
46. Data Sharing Canvas - A stepping stone towards cross-domain data sharing at scale. Available online: https://coe-dsc.nl/wp-content/uploads/2024/02/data-sharing-canvas.pdf (accessed on 8 July 2024).
47. Gaia-X. Available online: https://gaia-x.eu/ (accessed on 8 July 2024).
48. FIWARE. Available online: https://www.fiware.org/about-us/ (accessed on 8 July 2024).
49. Big Data Value Association - BDVA. Available online: https://www.bdva.eu (accessed on 8 July 2024).
50. DSSC Endorsement. Available online: https://dssc.eu/page/Endorsements (accessed on 8 July 2024).
51. Data Spaces Support Centre - DSSC. Available online: https://dssc.eu. https://www.egi.eu/project/dssc/. https://dssc.eu/space/DDP/117211137/DSSC+Delivery+Plan+-+Summary+of+assets+publication (accessed on 8 July 2024).
52. Data Space for Smart and Sustainable Cities and Communities - DS4SSCC. Available online: https://inventory.ds4sscc.eu (accessed on 8 July 2024).
53. GREAT project. Available online: https://www.greatproject.eu. https://www.epos-eu.org/great (accessed on 8 July 2024).
54. GREAT technical blueprint. Available online: https://www.greatproject.eu/wp-content/uploads/2023/10/D3.1-Initial-Blueprint-of-the-GDDS-Reference-Architecture_web.pdf (accessed on 8 July 2024).
55. A European Strategy for Data. Available online: https://digital-strategy.ec.europa.eu/en/policies/strategy-data (accessed on 8 July 2024).
56. Simpl. Available online: https://digital-strategy.ec.europa.eu/en/policies/simpl (accessed on 8 July 2024).
57. Simpl requirements. Available online: https://futurium.ec.europa.eu/en/simpl/pages/about (accessed on 8 July 2024).
58. Open and Agile Smart Cities - OASC. Available online: https://oascities.org (accessed on 8 July 2024).
59. DSSC data Sovereignty and Trust. Available online: https://dssc.eu/space/BVE/357075333/Data+Sovereignt y+and+Trust (accessed on 8 July 2024).
60. DSSC Data Exchange. Available online: https://dssc.eu/space/BVE/357075193/Data+Exchange (accessed on 8 July 2024).
61. DSSC Access and Usage Policies Enforcement. Available online: https://dssc.eu/space/BVE/357075567/Access+%26+Usage+Policies+Enforcement (accessed on 8 July 2024).
62. DSSC Identity and Attestation Management. Available online: https://dssc.eu/space/BVE/357075352/Identity+and+Attestation+Management (accessed on 8 July 2024).
63. DSSC Data Services and Offerings Descriptions. Available online: https://dssc.eu/space/BVE/357075789/Data%2C+Services+and+Offerings+Descriptions (accessed on 8 July 2024).
64. DSSC Publication and Discovery. Available online: https://dssc.eu/space/BVE/357076320/Publication+and+Discovery (accessed on 8 July 2024).
65. DSSC Value Added Services. Available online: https://dssc.eu/space/BVE/357076468/Value-Added+Services (accessed on 8 July 2024).
66. OGC Location building Blocks. Available online: https://blocks.ogc.org (accessed on 8 July 2024).
67. Common Assessment Methods Standards and Specifications - CAMSS. Available online: https://joinup.ec.europa.eu/collection/common-assessment-method-standards-and-specifications-camss (accessed on 8 July 2024).
68. The Open Data Institute - ODI. Available online: https://theodi.org/about-the-odi/our-vision/ (accessed on 8 July 2024).
69. ODI - How to choose an Open Standard. Available online: https://docs.google.com/document/d/1E5uARrZf5AJUIF_DJz-42_793EY_Dwk7n7B3bMn3x5A/edit#heading=h.xbuzggui7nk0; https://standards.theodi.org/find-existing-standards/how-to-choose-an-open-standard/ (accessed on 8 July 2024).
70. Reference Model of Open Distributed Processing (RM-ODP). Available online: https://en.wikipedia.org/wiki/RM-ODP (accessed on 19 July 2024).
71. ISO/IEC10746 Information technology - Open Distributed Processing (RM-ODP). Available online: https://committee.iso.org/sites/jtc1sc7/home/projects/flagship-standards/isoiec-10746.html (accessed on 19 July 2024).