2025-12-12

Present: Mona Lehtinen/NatLibFin, Ulriika Vihervalli/CSC, Elina Mäntylä/UTU, Jessica Parland-von Essen/CSC, Riitta Koikkalainen/NatLibFin, Niina Nurmi/HU. Katja Fält/TUNI, Liisa Marjamaa-Mankinen/CSC, Lassi Lager/CSC

Apologies: 

Agenda:

  1. Gravity call, ideas and discussion 
  2. Workshop takeaways
  3. Next steps
    • next meeting 9th January

Workshop takeaways

Summary of comments on describing a data source

1. Category: Source Material

  • Issue: The current form only allows selecting one type of material, but there is a need to list multiple types of materials related to the same dataset.
  • Suggestion: Enable the selection of multiple material types for a single dataset.

2. Access URL

  • Issue: The field implies the need for a secure connection, but for Laji.fi, the content is only available at laji.fi (no secure connection required).
  • Suggestion: Clarify that the Access URL can be a standard link to the public content (e.g., laji.fi).

3. Download URL

  • Issue: The current form lacks an option to provide an API for downloading collections.
  • Suggestion: Add an option to include an API endpoint as a download method.

4. Access Rights

  • Issue: The current options do not account for licenses that vary depending on the content.
  • Suggestion: Include an option like "License varies based on content" to accommodate different licensing scenarios.

5. Access Type

  • Issue: The access type depends on how the dataset is intended to be used (e.g., government use) and its sensitivity level.
  • Suggestion: Allow for flexible or multiple selections to reflect different use cases and sensitivity levels.

6. Other Identifiers

  • Issue: The service uses internal identifiers for different records.
  • Suggestion: Ensure the form supports the inclusion of internal or system-specific identifiers.

7. Bibliographic Citation

  • Issue: Uncertainty about whether to include a link to citation guidelines.
  • Suggestion: Provide a link or reference to citation instructions directly in the form or help text.

8. General Feedback on Descriptions

  • Accuracy Level: Emphasize setting an adequate level of accuracy for descriptions to avoid making the task overly time-consuming.
  • Subject Headings: Encourage the use of subject headings instead of keywords where possible.
  • Guidance for Descriptions: Add brief instructions or examples of what constitutes a "good" dataset description (e.g., clarity, relevance, completeness).
  • Purpose of the Form: The current form could also serve for importing 'data source' information with minor adjustments.
  • New Category Needed: Introduce a new category specifically for 'data source' information.

9. Overlap with Justus Infrastructure

  • Question: Is there overlap or redundancy with the development of the Justus infrastructure service?
  • Suggestion: Assess whether the form and its categories align with or complement the Justus infrastructure to avoid duplication.

Key Takeaways

  • The form needs more flexibility in fields like material types, access rights, and download options.
  • Clarity and guidance (e.g., examples, instructions) would improve the quality and usability of descriptions.
  • Consider integration or alignment with related infrastructures like Justus to streamline processes.

Summary of Feedback on Service Description Form

  1. Clarity of "Service Type" The field "service_type" was unclear, especially when the service in question is a metadata catalog. A more precise definition or examples would help users categorize their services correctly.
  1. Ease of Use and Suggested Improvements
    • The form is generally easy to fill out, but some minor tweaks could improve usability:
      • Adding support for three-letter language codes.
      • Including more URL-type fields to accommodate different types of links.
    • As more examples of service descriptions become available, it will likely become easier for users to understand what constitutes a useful service in this context and how to describe it effectively.
  1. PID Requirement
    • A PID (Persistent Identifier) is currently mandatory to describe a service. This is problematic if a service does not have one, as it prevents users from completing the description.
  1. Challenges with "Link to Service"
    • The field "link_to_service webpage/GUI" can be tricky if the GUI and GDPR information are located on separate pages. This makes it unclear which link should be provided.

Key Takeaways

  • The form is user-friendly but needs clarifications and additional fields (e.g., language codes, URLs).
  • PID requirement is a blocker for services without one.
  • Guidance on what constitutes a "service" and how to describe it would be helpful.
  • Linking to services can be ambiguous if relevant information (e.g., GUI and GDPR) is spread across multiple pages.

2025-11-28

Present: Niina Nurmi/HU, Mona Lehtinen/NatLibFin, Lassi Lager/CSC, Ulriika Vihervalli/CSC, Elina Mäntylä/UTU, Riitta Koikkalainen/NatLibFin, Tomi Rosti/UEF, Liisa Marjamaa-Mankkinen/CSC, Jessica Parland-von Essen/CSC, Anne-Marie Tuikka/TurUni

Apologies: 

Agenda: Services and research data sources

  • CSC has not done data source description testing yet
  • HU has done data source descriptions but this has not been published, has to go through an internal process - but test had a positive response. Also work remains to be done, e.g. how to get DOIs for dynamic datasets, too? This has been solved as follows for the Now fossil database:  https://zenodo.org/records/4268068 - HU likely has a lot of datasets, and onboarding these would boost their visibility
  • NatLibFin has a wealth of cultural heritage data but it is not ready for onboarding pilots; Finto description has been drafted
  • HU's pilot on qvain for OASIS data (https://www.oasisnorth.org/): access URL/download URL fields unclear; subject headings and keyword fields also in an illogical order; access type options need also be reviewed in light of federation efforts; also who wishes to be credited under "actor" needs discussion with dataset owners
  • NatLibFin pilot for Finto: research_domain awkward, as well as service_type; target_customer - a broad range selected; also 3-letter language codes preferable (https://iso639-3.sil.org/code_tables/639/data) to 2-letter (ISO 639-1 code - current EEN use: https://github.com/EOSC-Lot-1/een-resource-catalogue-docs/blob/eosc/vocabularies/LANGUAGE.json); overall impression still was that the description process was straightforward and clear; Melinda and Finna will also be described, providing further testing of the template. Datasets from NatLibFin is yet to be confirmed
  • Will Skosmos become a software that also needs to be described?
  • Workshop on 4th Dec - request for those who've done piloting to give brief 3min accounts; father feedback in person
  • No meeting next Friday

2025-11-21

Present: Ulriika Vihervalli/CSC, Jessica Parland-von Essen/CSC, Katja Fält/TUNI, Lassi Lager/CSC, Tuomas Alaterä/TUNI, Liisa Marjamaa-Mankinen/CSC, Riitta Koikkalainen/NatLibFin, Tomi Rosti/UEF, Haresh Kumar/Vaasa

Apologies: Niina Nurmi/HU, Alan Spouza/HU, Anne-Maria Tuikka/TurkuUni, Mona Lehtinen/NatLibFin

Agenda:

  1. Data source descriptions in https://qvain.fairdata.fi/ -
    • definitions between service and data sources are not clear in EOSC discussions
    • TUNI tested CIVIT datasets - overall worked generally well, but not all categories were clear/options were at times awkward fits for dataset being described (e.g. in use category). Needs for qvain to be developed further, 
    • CSC also has done a template for planning service catalog metadata; vocabulary metadata most challenging, also differences between M and O in EOSC data model and national data model; further challenges include "resource_provider" with Y-tunnus (not internationally interoperable) - a resource provider is nor in the EEN data model
    • ACTION: for members to test the service descriptions using the template + Jessica will email instructions
    • ACTION (continued) for all: and add new services! https://wiki.eduuni.fi/x/cYRxJ

2025-11-14

Present: Ulriika Vihervalli/CSC, Jessica Parland-von Essen/CSC, Elina Mäntylä/UTU, Mona Lehtinen/NatLibFin, Niina Nurmi/HU,, Katja Fält/TUNI, Tomi Rosti/UEF, Riitta Koikkalainen/NatLibFin, Allan Souza/HU, Johanna Laiho-Kauranne/CSC, Lassi Lager/CSC

Apologies: 

Agenda:

  1. Overview of national services listings
    • EOSC definitions on data sources and services are not clear, EOSC Handbook definitions also have limitations
    • the WG needs to test these definitions on a case-by-case basis
    • https://digi.kansalliskirjasto.fi/etusivu - is this a source or a service? if only data retrieval, then a source, but if additional tools (e.g. visualisation tools) are available then it is a service - would this help make a distinction?
    • SmartSMEAR, is this a data source or a service? 
    • another example: Finto - service or data source? Included FintoAI, so this is starting to look like a service
    • research.csc.fi service catalogue has different roles as a filter; but the development of the catalogue on the node side is upcoming.
    • we need to work on these definitions to also figure out what is listed in the node service catalogue
    • Polish node has done some categorisation between Service and data source: https://eosc.pl/search/service?q=*&standard=true&exact=false&radioValueAuthor=A&radioValueExact=A&radioValueTitle=A&radioValueKeyword=A - may be worthwhile for EOSC FI to connect with them to discuss their approach
    • Current criteria for inclusion in EOSC FI catalogue: mature service, available and useful for RDM professionals in Finland, Haka federated
    • there is also a question of how researches approach "services", from their perspective some of the services listed are data sources
    • ACTION for all: try and describe your data source in https://qvain.fairdata.fi/ - to see what questions/problems arise (no need to publish, but as a draft)
    • Do we need to comply with the EOSC handbook requirements, e.g. a database should have a sustainability plan for 10(!) years? +machine-actionable metadata (page 34. Cp. 5, subcp. 5.2.2.2) - ACTION: Jessica will raise this question with the Handbook group
    • ACTION for all: check internally that data source/service owners are happy to be potentially be included in catalogue and who should be given credit
    • ACTION for all: and add new services! https://wiki.eduuni.fi/x/cYRxJw
  2. Workshop 4.12.
    • present current status and plans for service onboarding
    • reach out to new organisations in the workshop

2025-11-07

Present: Ulriika Vihervalli/CSC, Jessica Parland-von Essen/CSC, Anne-Marie Tuikka/Turku, Elina Mäntylä/UTU, Mona Lehtinen/NatLibFin, Niina Nurmi/HU, Marita Kari/TSV, Katja Fält/TUNI, Liisa Marjamaa-Mankinen/CSC, Lassi Lager/CSC

Apologies: Allan Souza, Johanna Laiho-Kauranne, Riitta Koikkalainen (NatLibFi)

Agenda:

  1. Reporting from the EOSC Symposium (all who went or have heard something ...) Presentations
    • federation has clearly become more concrete, MoU signing is a landmark
    • interest on the ground related to themes of how the EOSC FI node pilot was run and organised, as well as concrete ways EOSC FI benefits researchers
    • further feedback: we need to work on being a truly national node so that we can reach researchers across Finland, not only those with pre-existing links to services. A good way would be to prioritise onboarding Finnish services across stakeholders, but good also for us to remember CSC services are Finnish higher education owned national services 
    • other themes were data sovereignty, how is this defined and how does it inform federation within EOSC; also EOSC skill training → peer support and training is scalable. "EOSC Academy" is also currently being developed. Jessica to discuss with CSC competence centre + Auli Harju/HAMK. Would be good to establish a national approach before EOSC Winter School (late Jan 2026).
  2. Workshop on 4 December, what should our goal be?
    • 10min overview of EOSC and EOSC FI node
    • try to attract new members to improve national scope
    • ideas/suggestions can be put onto the channel at chat.csc.fi
  3. Proposal to pilot onboarding services to the EOSC Finland candidate node catalog
    • Policy regarding access and use during piloting phase
    • proposal for us to push ahead with onboarding pilots - at this stage we can have a national approach, as we wait for EOSC level definitions of related processes. Likely we will be aligned, as our piloting will be informed by core OS principles
    • unlikely for there to be policies that would prevent nodes from determining own processes, as nodes are not homogeneous (as seen at symposium)
    • how do we ensure transparency during this process?
    • we should write a proposal for the kind of services we want to onboard - e.g., we want services that are open/available for Finnish researchers, we want services that are mature, and a FitSM service description. Members to list suggestions here.
    • copy definitions from Handbook on tool, dataset, data source, service etc. Need clarity between what is a service and what is a data source.
      • Service: "Services that provide management, processing, and storage capabilities for research data. These may include DMPs, data cleaning, transformation, analytics, and computational power to support large-scale studies."
    • once Federation Handbook 2.0 is released, the group will take a look at the new definitions 

ACTIONS:

2025-10-31

Present: Ulriika Vihervalli/CSC, Jessica Parland-von Essen/CSC, Tuomas Alaterä/TUNI, Allan Souza/HU, Anne-Marie Tuikka/Turku, Elina Mäntylä/UTU, Lassi Lager/CSC , Liisa Marjamaa-Mankinen/CSC, Mona Lehtinen/NatLibFin, Niina Nurmi/HU, Tomi Rosti/UEF

Apologies: Riitta Koikkalainen, NatLibFi

Agenda: Workshopping around definitions and requirements

Four themes to discuss (we will proceed together one theme at the time)

  1. add themes, facts or definitions that are clear or given (warning)  
  2. add questions or issues (question) 

NB: thinking in the national context!

https://app.conceptboard.com/board/7of6-r93m-ni63-o0kc-cn82

Topics discussed

  • Jessica introduced the concept board, to map out what we know of EOSC FI node and what we do not
  • Rules of Participation: Open Science, FAIR principles, legal and ethical compliance, reference architectures(?). Is the expectation for stakeholders to engage in development and implementation? This remains an open 
  • Onboarding: for now, up to infrastructures to decide if they offer their services to unaffiliated researchers/users. Likely the wish of EOSC-A for us to allow use by these users, too, but this is a question of finances at infrastructure level. Onboarding means you have HAKA and/or MyAccessID + metadata in national catalogue (etsin.fi or equivalent). Do we need a contract for onboarding? There needs to be some kind of a vetting process. Needs to be an approval process or agreement/contract. Managing a contract will discourage uptake, however. We can refer to the requirements from the handbook. If members have suggestions for services for piloted onboarding, please bring them to the group; Jessica and Lassi will brainstorm service catalogue pilots for next meeting
  • Federation: HAKA+SSO, how does this work for members? Removing HAKA would be a major issue for researchers/RPOs, so we are looking to add MyAccessID (and not to remove HAKA). A starting point can be that HAKA is the national level federation, before MyAccessID is widely adopted.
  • Services and resources: data mgmt competence centre → would courses be uploaded via CSC or via the competence centre? There are training resources in EU Node (https://openplato.eu/eosceunode) - Jessica will discuss further with our DMCT. Node service catalogue - LUMI owned by a consortium so it's not a CSC service per se, but LAIF has launched a set of services, we could include these. Branding for EOSC FI, currently looks like CSC exclusively, this needs to be addressed but likely further down the line, as services need recognition to get funding and demonstrate impact. National node is discipline agnostic - how are discipline needs addressed in the service catalogue?

2025-10-24

Present: Marita Kari, TSV; Riitta Koikkalainen, Kansalliskirjasto; Mona Lehtinen, Kansalliskirjasto, Niina Nurmi, Helsingin yliopisto, Haresh Kumar/Vaasan yliopisto, Liisa Marjamaa-Mankinen/CSC

Apologies: Ulriika Vihervalli

Minutes:

Jessica presented (link to the presentation) the results of the Menti survey from the previous meeting and the working group's tasks - and the group engaged in discussion.

Topics discussed:

Federation and IDs used for different tiers of services, HAKA or EU identification

Data Quality

References:

EOSC Federation Handbook https://doi.org/10.5281/zenodo.14999577
EOSC Rules of Participation https://data.europa.eu/doi/10.2777/30541
CSC Terms of use https://research.csc.fi/terms-of-use/ 
CSC Free-of-charge use https://research.csc.fi/free-of-charge-use/ 

Andrew Treloar, Charles Joseph Woodford: Global Open Research Commons: Creating an International Model for Improved Interoperability and Collaboration. Data Science Journal, 23(1).  https://doi.org/10.5334/dsj-2024-056 

Making the Global Open Research Commons Truly Global: A report from the Lorentz Workshop, July 21-25 2025. https://doi.org/10.5281/zenodo.17230153


Possible things to discuss and solve:

EOSC Node service catalogue:

Onboarding, criteria? 

  • access: with Haka (not SSO requirement yet?)

Which kind of services are useful to include in catalogue and how should they be described in a ?

  • National federation = Haka
  • EOSC Federation = MyAccessID

Are we able to test with some services?


Workshop for larger group of people? One possibility: Time slot reserved in AVOTT winter days on 4 Dec 14.30–15.30

Target state regarding federation?



  • No labels