The elaboration of the Skills Data Space from a technical perspective heavily relies on the generic building blocks as being defined by the Data Spaces Support Centre (DSSC) in their blueprint. Among other things, it contains 9 technical building blocks, . This section discusses these pillars and building blocks as well as their envisioned use in the skills context. For each of the three pillars, the related requirements that were identified in interviews with key initiatives (see deliverable 3.1) are described. Then, each building block is analysed in terms of the required key elements and functions in a skills context, how it relates to other building blocks, the commonly used standards in the skills context and reference implementations or specifications that relate to this building block.
Aside from the 9 building blocks identified by the DSSC and their extensions for the skills context, we also identified additional technical building blocks for the Skills Data Space. These are discussed in the same manner in the next paragraph.
7.5.1 Data Interoperability Building Blocks #
“The objective of this building block category is to provide a framework, components and best practices that data spaces can use to ensure data interoperability.” (as defined in the DSSC blueprint)
For the applicability in the skills context, the stakeholders specifically ask for solutions that:
- Overcome the limits of the skills ontologies that are currently in use and to solve the challenge of working with multiple non-interoperable taxonomies across the EU.
- The development of semantic translators to and from the most widely adopted ontologies.
- Develop cognitive AI tools, such as NLP or other automated techniques, that allow full-text operations (this is progress beyond the state of the art which is a common global taxonomy and individual word matching when extracting information) and
- JSON-LD as the standard data format to describe skills data models and skills ontologies for support broad of semantic interoperability in the knowledge domain.
- Support the legacy formats still in use (XML, CSV and other relevant text/binary–based skills data sets such as SCORM).
- Provide digital wallet interoperability.
Table 34: Data Models & Formats # |
|
| DSSC Description | “This building block will provide guidelines and tools for data space initiatives to publish, create, and maintain shared domain specific vocabularies.” (as defined in the DSSC blueprint) |
| Key Functions for skills context | For the skills context and its specific requirements in terms of semantic interoperability, specific functions are required as extension of:
· Integration and alignment of to address overlapping or related concepts (DSSC blueprint Function 5): o Data Format Conversion, Data Structure Conversion and Taxonomy/Ontology/Learner Model Conversions: making sure different data sets are processed with similar understanding on structure and data segments. · Easy creation of standardised data models from data assets that are not compliant with standards (DSSC blueprint Function 4): o (Skills) Data Normalisation: Normalisation refers to cases where similar types of words are grouped together by meaning and expressed as one concept. Normalisation can be done by using word lists, ontologies or language modes that can be manually developed or built with AI. o Language Models: Language models do not refer to language translations, nor dictionaries. EDGE Language Models are not in common use yet, but they must be included into the blueprint for the future. Personal data will be processed in the EDGE and hence EDGE LM’s are a crucial part of the future of the personal data space building blocks. For the skills context and its specific requirements in terms of data quality, a specific function is required: o Data Quality Assurance: the personal data context asks specifically for data quality assurance. |
| Dependencies and relationships | • Data Exchange: “The Data Models & Formats building block establishes a for data model specifications and representation of data in data exchange payloads. Combined with the Data Exchange building block, this ensures full interoperability among participants.” (as defined in the DSSC blueprint)
• Access & Usage Policies and Control: (mentioned, but not further defined in the DSSC blueprint). • Data, Service and Offerings Descriptions: “The Data Models & Formats building blocks offers data models that can be used by and referenced to in the self-descriptions of the data- and data service offerings. Thereby allowing for better search and discovery of relevant data offerings. This is addressed in the building block Data, Services and Offerings descriptions.” (as defined in the DSSC blueprint). |
| Commonly Used Standards in skills context | · OSLO standard (based on RDF/OWL)
· ESCO · Xbildung · Schema.org Educational or Occupational Credential · CEDS · JSON-LD · ROME · nodefr · ISCO-08 · SKOS |
| Specs & Reference Implementations in skills context | · EQF
· ELMO |
Semantic interoperability refers to cases where machines can operate between different structures and/or vocabularies, for example between ESCO and ONET. Learning Object Metadata (LOM) and all the similar activities (e.g., IMS) and parallel variants from library/informatics side (e.g., Dublin Core, SKOS, etc) extend labour market ontologies but do not remove the fundamental challenge about contextual limits. Interoperability between ontologies is needed but that don’t still solve the use of the language: If someone can mount containers, can a person mount it into a truck, ship or into a server? Learner Modelling is an old discipline including educational sciences, social sciences, psychology and medical sciences dimensions (e.g., in Brusilovsky 2001, Adaptive Hypermedia). Turning learner model just an ontology issue would be fatal. There are numerous learner models (e.g. ELM, Europass, xAPI). All in all, semantic interoperability is a beginning. pagehave to be able to make all the data not only machine readable but machine interpretable.
Conceptual Interoperability refers to case where the meaning is made interoperable. I.e., we always know that “ability to mount the containers” are used in the right context, logistics or computing. Without Conceptual interoperability we are going to make huge errors even though the semantics could be right. There is no unified understanding of how to name or describe skills. In fact, we do not even have a unified way to define when something is a skill, hard skill, soft skill, generic skill, tool, technology, knowledge, method or otherwise a relevant topic that can describe something we intuitively think as a skill.
Today, many sectors (e.g., financial, medical and defence industries) use domain-specific or application-specific ontologies. Individual companies often have their own company-specific skills ontologies (e.g., LinkedIn and Lightcast) or Language Models (e.g., Headai). All in all, in practice there are numerous relevant contexts only inside one organization and each context might have one or more relevant ontologies, taxonomies or traditions to describe skills. When trying to use a single ontology as a glue between domains, the challenges get multiplied.
Research in the area of Large Language Models, (LLM) is ongoing and the question is if applications based on this technology can perform the semantic and conceptual interoperability tasks. There are many examples how LLM and Focused Language Models outperform people in well-defined data structure changes, and it seems to be promising. However, there is also a risk for contextual misunderstanding. The effects of LLMs must be studied, and the use of these possibilities must be enabled into Building Blocks. LLM is not a standard, but a highly relevant and interesting method to apply into context of semantic and conceptual interoperability. We have all the reasons to believe that significant share of this work is already done within single projects or mappings.
Relevant translators between CSV, XML and JSON exists and such must be integrated into Data Interoperability Building Blocks. Furthermore, there is a lot of relevant and well performing external services as well as Language Model derivatives that fit to problem, so we must enable them fitting to Building Blocks.
Table 35: Data Exchange # |
|
| DSSC Description | “This building block should provide guidelines and technical specifications about common communication protocols that all data space roles can use to transmit standardised data.” (as defined in the DSSC blueprint). |
| Key Elements & Key Functions in skills context | For the skills context and its specific requirements in terms of the human-centred approach and personal data protection, specific functions are required as extension of:
· Generic data exchange protocols (DSSC blueprint Function 2): o Safeguard for personal data. o Privacy preserving data exchange protocols. |
| Dependencies and relationships | · Data Models & Formats: “The building block Data Models and Formats describes the modelling of the knowledge and information within the considered domain by describing which information plays what role. For data exchange, these models and formats are (re)used to specify the payload of a particular API. It can be that, for specific use cases, the payload specifications are a subset of the data model or impose additional constraints.” (as defined in the DSSC blueprint).
· Data, Services and Offerings Descriptions: (mentioned, but not further defined in the DSSC blueprint). · Publication & Discovery: The data exchange protocol that is being used for a particular data set or data service offering must be referenced as part of the data provider self-description in the building block Publication and Discovery.” (as defined in the DSSC blueprint). |
| Commonly Used Standards in skills context | · eIDAS
· xAPI · cmi5 · HTTP · REST API |
| Specs & Reference Implementations in skills context | · GraphQL
· LTI · OOAPI · EduAPI |
Provenance & Traceability #
The DSSC also defines a Provenance & Traceability building block as part of their Data Interoperability building blocks. “This building block describes how the data sharing process is being monitored within a data space. Especially data spaces with highly regulated data, it is necessary to make the data sharing process observable. This can be done for legal reasons to prove that data has been processed only by authorized entities, or for business reasons to provide a marketplace and billing function through a trusted third party.” (as defined in the DSSC blueprint).
However, this building block is not yet further specified at the time of writing this deliverable. Therefore, the building block is not adopted. Envisioned functions of this building block are now incorporated in other building blocks of the skills data space blueprint.
7.5.2 Data Sovereignty & Trust Building Blocks #
“Building blocks to enable organisations to remain sovereign over their data, yet at the same time maintain trust in the data space as a whole.” (as defined in the DSSC blueprint)
Table 36: Access & Usage Policies and Control # |
|
| DSSC Description | “This building block aims at outlining the available options for achieving goal of Access and Usage Policies and Control, such as which mark-up languages can be used and whether there are any templates/models available for expressing access and usage policies.” (as defined in the DSSC blueprint). |
| Key Functions in skills context | For the skills context and its specific requirements in terms of the human-centred approach and consent, specific functions are required:
o PDI Consent
o Personal Data Access Logs |
| Dependencies and relationships | · Identity Management & Trust: “Granting access and usage is strongly correlated with identities, as a data space member makes them available to an identity. The evaluation of policy enforcement can be a proof of a credential. It might also be useful to determine verified credentials for members or applications that limit access to certain data products, i.e., only trusted applications can process a set of data products.” (as defined in the DSSC blueprint).
· Data Value Creation: “The Access & Usage Policies and Control building block represents an important prerequisite for Data Value Creation. Foremost, the accounting relies on the actual usage of data. Thus, without enforcing policies and proving this (e.g., logging), it is not possible to account data utilization on a sound data basis. Therefore, a data offering must include proper access and usage policies.” (as defined in the DSSC blueprint). · Publication & Discovery: “In the data catalogue, data definitions are redesigning, which might be needed to define the policies. Catalogue should have also data about the policies.” (as defined in the DSSC blueprint). · Business: “Data itself is not the saleable unit in data spaces, it is granting access and usage rights. Thus, this building block is a core aspect of operating the business building block. Furthermore, the design of access & usage policies is part of the definition of data products. Thus, they can build on this to define the business impact.” (as defined in the DSSC blueprint). · Governance: “Governance model and governance framework has already some initial framework for data sharing policies.” (as defined in the DSSC blueprint). · Legal: “How regulation is enforced by the legal block regarding to the use of data, especially for personal data. The regulation (DGA) also require authorisation to be obtained from right holder for exchanging data (data consumer must obtain the authorisation from the right holder). For business data this is also valid, since the contractual agreements might encompass specific usage policies. Regarding this, it is important to emphasize policy enforcement “outside” of the data space, i.e., juridical enforcement. However, the distinction/matching of legal contracts and machine-readable policies is out of scope for this building block. Neither we consider the monitoring function with the data space beyond the logging of enforcement of single transactions. Furthermore, the linkage between access and usage policies and legal contracts is of importance for this building block.” (as defined in the DSSC blueprint). · Contract Framework: “Granting access and usage will depend on the authorisations that are provided by the building blocks allowing to negotiate and sign agreements, these agreements can be contracts, licences and individual consents / authorisations for personal data.” (as defined in the DSSC blueprint). |
| Commonly Used Standards in skills context | · Kantara Consent Receipt
· ODRL · JSON-LD |
| Specs & Reference Implementations in skills context | · UMA |
Table 37: Identity Management # |
|
| DSSC Description | “The building block should create and offer guidelines and tools that enable data space initiatives to determine, establish, and manage their own standards and mechanisms for identifying, authenticating, and authorizing any entities within their data space.” (as defined in the DSSC blueprint). |
| Key Functions in skills context | For the skills context and its specific requirements in terms of the human-centred approach, specific functions are required:
o PDI Identity
|
| Dependencies and relationships | · Trust: “Highly trusted entity or system that serves as a foundational source of trust and integrity, validating and verifying the authenticity of data and ensuring the overall security of the data space ecosystem.” (as defined in the DSSC blueprint).
· Access and Usage Policy Control: “When access to data products and/or services needs to be constrained, the access control policies must mention the identities of those that can, or cannot, get such access. Similarly, when usage of data is to be controlled, the usage control policies must be able to refer to entities that are involved. This requires access to the associated identifiers (and possibly other attributes, and/or credentials), as managed and provided by this building block.” (as defined in the DSSC blueprint). · Marketplace & Usage Accounting: “As Access and Usage is the basis for access and usage of data it is also highly relevant for marketplaces and accounting. Identities are needed for searching services and products and negotiating access and usage.” (as defined in the DSSC blueprint). · Governance: “Data Space Roles are collections of rights and duties (mandates) for performing actions that are particular to these roles. Data space roles must be assigned to (identifiers for) entities that can perform such roles. This building block manages and provides such identifiers. Identity Management also requires internal as well as perhaps external governance processes. Identity Management creates transparency about the members of Data Spaces as well as their attributes and identifiers. There must be an organization for who does what regarding Identity Management in a Data Space.” (as defined in the DSSC blueprint). · Legal: “There might be regulative requirements for specific classes of identities in different domains, especially in highly regulated environments such as medical Data Spaces.” (as defined in the DSSC blueprint). |
| Commonly Used Standards in skills context | · EDC
· OEPass · DIDs · SAML 2.0 |
| Specs & Reference Implementations in skills context | · EDCI
· SOLID · eduID |
Table 38: Trust # |
|
| DSSC Description | “This building block should specify the functioning of anchors in a data space: what are they? How can they be used and how can they work together? And how do they work together with the identity management building block?” (as defined in the DSSC blueprint).
“Therefore, the purpose of this building block is to provide assurance to all participants of a data space to ensure the secure and reliable exchange of data between different entities within a data ecosystem while fostering data sovereignty” (as defined in the DSSC blueprint). |
| Key Functions in skills context | For the skills context and its specific requirements in terms of the human-centred approach and personal data protection, specific functions are required:
o Trustworthy AI assessment: apart from verifying identity, for the skills context it is important to offer functions that can assess AI algorithms used in terms of fairness and explainability. |
| Dependencies and relationships | Not specified in the DSSC blueprint |
| Commonly Used Standards in skills context | · W3C Verifiable Credentials
· DIDs · eIDAS · EV SSL |
| Specs & Reference Implementations in skills context | · EBSI |
7.5.3 Data Value Creation Building Blocks #
“Building blocks for creating value in a data spaces, e.g., by registering and discovering data offerings or services, providing marketplace functionality and enable monetization of data sharing.” (as defined in the DSSC blueprint).
Table 39: Data, Services and Offerings Descriptions # |
|
| DSSC Description | “This building block provides guidelines and tools for the conceptualisation and implementation of self-descriptions.” (as defined in the DSSC blueprint) |
| Key Functions in skills context | For the skills context and its specific requirements coming from the business model, specific functions are required:
· Offerings: o The Offerings Descriptions should encompass:
o Each data/service provider as well as orchestrator and infrastructure provider need to have its offerings listed in catalogue and/or marketplace, so all end users can find all offerings relevant to them, can order products and can start consuming it. |
| Dependencies and relationships | · Publication & Discovery: “Data, Services and Offerings descriptions building block describe the elements that will be published in the catalogue and later on discovered through the Publication and Discovery building block. As self-descriptions are mere metadata records, they require support from the Publication and Discovery building block to become operational.” (as defined in the DSSC blueprint).
· Marketplaces & Usage Accounting: “Self-descriptions are by extension, and via their “commodity” concern, related to the Marketplaces and Usage Accounting building block.” (as defined in the DSSC blueprint). · Data Models & Formats: “The metadata used by the Data, Services and Offerings descriptions building block will be following the vocabularies and models proposed by the Data Models & Formats building block.” (as defined in the DSSC blueprint). · Business: “A self-description provides business-related information (such the legal name of the organisation offering a service or data in a data space) with every service or dataset offered within the data space ecosystem.” (as defined in the DSSC blueprint). · Governance and Legal: “The regulatory compliance information can be included in self-describing data and services.” (as defined in the DSSC blueprint). |
| Commonly Used Standards in skills context
|
· CTDL
· JSON-LD |
| Specs & Reference Implementations in skills context | · DigComp |
Table 40: Publication & Discovery # |
|
| Description | “Once individual self-descriptions have been created, it should be possible to publish them in a catalogue and enable other participants of the data space to find them. This is the scope of the building block for Publication & Discovery.” (as defined in the DSSC blueprint). |
| Key Functions in skills context | For the skills context and its specific requirements in terms of the human-centred approach in general, specific functions are required:
o PDI Catalogue
o PDI Distributed data visualization
For the skills context and its specific requirements coming from the business model, specific functions are required: · Publication and discovery services: o Participant-driven search. o Potential matches. o Collaboration requests and templates. The Skills Data Space can implement this building block in a centralised or decentralised manner. However, due to the specific requirements in the skills context in terms of decentralization, we advocate for the decentral approach. |
| Dependencies and relationships | · Data Models and Formats: “The building block Data Models and Formats establishes a (common) format for data model specifications that are provided by the Vocabulary Hub. This should also align with the data model for Self-Descriptions.” (as defined in the DSSC blueprint).
· Access & usage policies and control: “The Catalogue requires control of access to the Self-Descriptions. Or, put in other words, the Catalogue has to be able to enforce access rights to the Self-Descriptions. For instance, it is assumed that only the owner of a Self-Description is allowed to modify it while other Participants are only able to read it. In addition, access control plays a more elaborate role if and when the Catalogue is required to contain Self-Descriptions that are not accessible to all Participants by default. A specific Self-Description may only be available to specific Participants under specific circumstances. In this case, a Self-Description should have information that allows the Catalogue to determine access rights of Participants to that Self-Description. This should be defined by rules or policies that determine the circumstances under which the Self-Descriptions are shared with Consumers.” (as defined in the DSSC blueprint). · Data, Services and Offerings Descriptions: “The building block Data, Services and Offerings Descriptions addresses the Self-Descriptions of data-related Products, which are stored inside the Catalogue. A Self-Description should provide Consumers with the required information to a) find best-match offerings and b) how to consume the actual resource to which the Self-Description refers. In addition, and c) the Self-Descriptions could contain information about which Participants are allowed to view (discover) the Self-Descriptions in the Catalogue (see ‘Access & usage policies and control’).” (as defined in the DSSC blueprint). · Marketplaces & Usage Accounting: “The Catalogue has a relation with the Marketplace. A marketplace in a Data Space can be considered a means to monetize resource transactions. The Marketplace contains descriptions of data, services, application services and cloud or edge infrastructure services, as well as their related offering descriptions. Within the Marketplace architecture, a shared catalogue contains the product specifications and product offerings, as well as “product orders and -instances along their lifecycle and information about actual usage of products”. The Marketplace and Catalogue should adhere to the same policies.” (as defined in the DSSC blueprint). |
| Commonly Used Standards in skills context | · JSON-LD
· DCAT v3 |
| Specs & Reference Implementations in skills context | · Formacode
· SCORM · GAIA-X · TQF |
Table 41: Marketplaces & Usage Accounting # |
|
| DSSC Description | “Data spaces can provide support the creation of multi-sided markets where participants generate (monetary) value out of sharing data. This building block describes common mechanisms for establishing marketplaces of data/services and the related usage accounting (e.g., for billing). There can be different ways of achieving this, e.g., through intermediaries or peer-to-peer.” (as defined in the DSSC blueprint). |
| Key Functions in skills context | For the skills context and its specific requirements coming from the business model, specific functions are required:
· Contract/Order: functions around the comprehensive inclusion of all contractual details. This ensures that, on one hand, the end user receives the data product they require, and on the other hand, it legally binds all data/service providers to deliver the specified data products and receive compensation for their offerings. Specific focus should lie on flexibility. · Marketplace: functions that empower participants to explore a wide array of offerings, including data products, infrastructure, potential collaborators, and various data space use cases. · Billing: functions to generate invoices for the data products provided to end users and to ensure that data/service providers, including infrastructure and governance, receive their rightful compensation. Specific focus should lie on accuracy, transparency and precision. · Aftersales: functions aimed at assisting participants in resolving issues and obtaining information regarding transactions and invoice: o Account info, o Transaction/Consumption log, o Case management, o Surveys, o Role-based reporting. |
| Dependencies and relationships | · Publication & Discovery: “the marketplace will manage the catalogue comprising Data Specifications and Data Product Offerings from multiple Providers, and based on that will perform the actions needed to allow the monetisation of those products.” (as defined in the DSSC blueprint).
· Business: “how the catalogue and the marketplace generate value according to the data driven business models of the data space. In this regard, we should consider other ways to generate value out of data, beyond monetisation, and depending also on the type of the data space (public service, research, industry, etc.)” (as defined in the DSSC blueprint). · Governance: “how the governance of the catalogue and the marketplace is linked with that of the data space” (as defined in the DSSC blueprint). · Legal: “how regulation is enforced by the legal block so operations in the federated catalogue and marketplaces are compliant by default (e.g., global privacy policy, code of conduct or terms of reference, etc.). Federated marketplaces and third parties have to adhere to these rules.” (as defined in the DSSC blueprint). |
| Commonly Used Standards in skills context | No standards found in DS4Skills inventory |
| Specs & Reference Implementations in skills context | No specifications and reference implementations found in DS4Skills inventory |
