Problems, Needs, and Recommendations
Semantic Layer
S1 — Lack of common definitions
| Problem | Needs | Recommendations |
|---|---|---|
| There is a generalised lack of common explicit definitions about the terms used by user communities. | Need for harmonisation across disciplines. | Communities should generate clear, precise definitions for concepts, metadata, and data schemas. Definitions must be public, PID‑referenced, and shared in EOSC. |
S2 — Lack of shared semantic artefacts
| Problem | Needs | Recommendations |
|---|---|---|
| Common semantic artefacts (ontologies, schemas) are often missing across communities. | Need for principled approaches and tools for ontology and metadata schema creation, maintenance, governance, and use. | Semantic artefacts should be openly licensed and accessible. |
S3 — Lack of reference repositories for semantic artefacts
| Problem | Needs | Recommendations |
|---|---|---|
| There is a generalised lack of common reference repositories or registries of semantic artefacts. | Need to harmonise data of the same type. | Every semantic artefact in EOSC must include sufficient documentation, examples, and conceptual diagrams. |
S4 — Poor documentation and fragmented metadata schemas
| Problem | Needs | Recommendations |
|---|---|---|
| Data collections are poorly documented; no common metadata schema across communities. | EOSC should support a repository of semantic artefacts and a governance framework. | Propose a minimum metadata model (DCAT‑AP, DDI 4 Core, DataCite, OpenAIRE). Extend to software, workflows, protocols, hardware. Provide federation/harvesting building blocks. |
S5 — Lack of semantic expertise in communities
| Problem | Needs | Recommendations |
|---|---|---|
| Some communities lack semantic expertise and skills. | Capacity building and training. | Develop training, guidance, and community support structures to improve semantic literacy. |
Technical Layer
T1 — Fragmented authentication and authorisation
| Problem | Needs | Recommendations |
|---|---|---|
| Authentication and authorisation must often be repeated for each community or service. | Seamless authentication and rights acquisition for EOSC services. | Use open specifications to ensure technical interoperability when establishing EOSC services. |
T2 — Heterogeneous data formats
| Problem | Needs | Recommendations |
|---|---|---|
| Research data exists in many formats (CSV, JSON, XML, NetCDF, FITS, etc.). | A trusted, sustainable cross‑community framework; a minimum metadata application profile for EOSC. | Define a common security and privacy framework and establish trustworthy data‑exchange processes. |
T3 — Difficulty finding data at different granularities
| Problem | Needs | Recommendations |
|---|---|---|
| Coarse‑grained or fine‑grained data from other communities may be difficult to find. | Discovery mechanisms supporting multiple levels of granularity. | Provide clear, understandable SLAs for all EOSC resource providers. |
T4 — PID fragmentation and inconsistency
| Problem | Needs | Recommendations |
|---|---|---|
| Multiple PID providers with different policies; some PIDs not resolvable; duplicates exist. | A common, well‑understood PID policy across communities. | EOSC must enable easy access to heterogeneous data formats and provide tools to overcome differences. Provide coarse‑ and fine‑grained search tools. Establish a clear EOSC PID policy accommodating diverse practices. |