EOSC Concepts Comparison EOSC Glossary Jesse Oikarinen (CSC)

EOSC Concepts Comparison The aim of the EOSC glossary Create common understanding of key concepts and their definitions Concepts comparison task Identifying and highlighting any terminological issue emerging from EOSCpilot deliverables produced so far Are we meaning the same things with concepts? Are we using the same terminology? Are we using contradictory definitions? Are we understanding things differently?

Preliminary analysis of the EOSC concept definitions D2.2. Draft Governance Framework For the European Open Science Cloud D3.1. Policy Landscape Review D5.1. Initial EOSC Service Architecture D5.2. EOSC Service Portfolio D6.3. 1st Report on Data Interoperability: Findability and Interoperability 52 definitions were identified and divided into different clusters: Stakeholders, users, actors Resources and services System architecture and structure Processes and procedures Other concepts

The 4 main findings In most cases (35/52) there are no contradictory definitions in the deliverables Keep in mind the narrow scope of the analysis How to make sure the terms are well defined? A process needed In some cases (10/52) the definitions of the same concepts differ in different deliverables in their scope making some of the used definitions broader and more informative. In a minority of cases (4/52) different terms and concepts are used to refer to the same thing. In a minority of cases (3/52) concepts are being used without defining them.

Mostly no contradictory terms in use… yet Some examples: (D.5.2.) EOSC Client: EOSC Client is the role of the actors that exploit the facilities offered by the EOSC system as a mean to support their working activities. Major client sub-roles are envisaged: scientist and research manager/Admin. (D5.1.) EOSC Node: EOSC Nodes are the “organisational pieces” of the EOSC System called to contribute to the provisioning of one or more EOSC Services. Because of this, EOSC Nodes are: (a) the “places” where EOSC Services and/or EOSC Service Component reside; (b) operated by an EOSC Service Provider and/or and EOSC Supplier. (D5.2.) EOSC Technical Committee: A team of experts responsible for assigning and monitoring service quality within EOSC. This will come in two types: those quality measures that are generic across all (or, at least, many) EOSC services, and those that are scientific discipline specific.

Same concepts, differing definitions Some examples: (D5.1.) Data (Service) Supplier: Any EOSC Supplier making available its own data (by means of a Service) to enable an EOSC Service Provider to operate an EOSC Service. (D5.2) Data (Service) Supplier: will make available their own data to EOSC to enact an EOSC Service. (D5.1.) EOSC Compatible Service: Any service worth having in an Service Catalogue without being an EOSC Service. Compatibility implies only that such services can coexist with the EOSC Services within the catalogue context. Because of the inclusive willingness of the catalogue, no technical requirement is currently envisaged aiming at guaranteeing that these services can technically coexist / interoperate with EOSC services in application scenarios. (D5.2.) EOSC Compatible Service: EOSC Compatible in this model indicates that the service meets the requirements to be in the EOSC portfolio.

Different terms referring to the same thing Example: (D5.1.) EOSC Principles of Engagement (PoE): Policies, processes, and roles governing the behaviour and the duties of EOSC Users when using EOSC Services. (D.5.2.) Rules of Engagement: Rules of Engagement (RoE) will be designed within the EOSC governance that apply to providers of services. These RoE make sure that for every service in the EOSC Portfolio at least: conditions for access to the service are clear and transparent; the provider of the service is clear and well-described, including formal contact information; functional specifications of the service are described according to standards, including available user- and expert support; the service level is defined and described according to standards; descriptions are available in English. (D3.1.) Principles of Engagement (RoE or PoE) constitute a series of core principles in relation to the services and data provided through EOSC and which are binding for EOSC users and service providers. EOSC policies provide a broader framework within which the PoE operate, while PoE provide specific guidelines that can then be translated into specific institutional policies.

Different terms referring to the same thing #2 Example: (D5.1.) EOSC System Manager: This is a comprehensive umbrella role for all the actors that manage and operate EOSC and its services. (D.5.2.) EOSC Manager: a wide comprehensive umbrella role for all the actors that manage and operate EOSC and its services. They will use services to efficiently and effectively perform their Service Catalogue and Service Portfolio Management tasks using the EOSC Service Management System’s services.

Concepts/terms not defined Some examples: (D5.2.) EOSC Certification: not defined (D5.2.) EOSC Stakeholder: not defined

Next steps? Work continues - all deliverables should be analyzed Process to make clearly defined concepts Should also make sure that they are in line with EC definitions

Jesse Oikarinen (CSC) jesse.oikarinen@csc.fi www.eoscpilot.eu The European Open Science Cloud for Research pilot project is funded by the European Commission, DG Research & Innovation under contract no. 739563