...
Definitions which contain terms/keywords that are themselves defined in the glossary should be marked in italics. If you have any questions please contact Matthew Viljoen
| Term or Acronym | Definition |
|---|
EOSC-related | FitSM-related | | Notes |
|---|
| Authentication and Authorisation Infrastructure (AAI) | A service (or distributed set of services) which enables users to be identified and to access protected information, other services or functionality. |
TRUE | FALSE |
|
| Authentication and Authorisation for Research and Collaboration (AARC) | A series of EC-funded projects which use AAI to bring researcher collaborations closer together. |
FALSE | FALSE | Accessibility of informationActivity | Set of actions carried out within a process | FALSE | TRUE | Property of information being accessible and usable by an authorized party | FALSE | TRUE | | AARC Engagement Group for Infrastructure (AEGIS) | Body which brings together representatives from research and e-infrastructures, operators of AAI services and the AARC team to bridge communication gaps and make the most of common synergies. |
FALSE | FALSE |
|
| API | Application Programming Interface |
TRUE | FALSE | Assessment | Set of actions to evaluate the capability level of a process or the overall maturity level of a management system | FALSE | TRUE | Availability | Ability of a service or service component to fulfil its intended function at a specific time or over a specific period of time | FALSE | TRUE | Capability level | Achieved level of effectiveness of an individual process or general aspect of management | FALSE | TRUE | | Capacity | Maximum extent to which a certain element of the infrastructure (such as a configuration item) can be used | FALSE | TRUE | Note: This might mean the total disk capacity or network bandwidth. It could also be the maximum transaction throughput of a system. |
Capacity Management (CAPM) | SMS process which ensures sufficient capacities are provided to meet agreed service capacity and performance requirements. | FALSE | TRUE | Community Catalogue Operator | An organisation operating an EOSC-compliant community catalogue and responsible for the onboarding and validating selected resources from that community catalogue into the EOSC Exchange. | TRUE | FALSE | Change | Alteration (such as addition, removal, modification, replacement) of a configuration item (CI) | FALSE | TRUE | Change Advisory Board (CAB) | A group of people within CHM who reviews, evaluates and approves changes within an IT environment. | FALSE | TRUE | Change Management (CHM) | SMS process which ensures changes to configuration items are planned, approved, implemented and reviewed in a controlled manner to avoid adverse impact of changes to services or the customers receiving services | FALSE | TRUE | | Classification | Assignment of items to defined groups based on common attributes, relations or other criteria | FALSE | TRUE | Note 1: Items that are subject to classification may include documents, records (such as incident records or change records), services, configuration items (CIs), etc. Defined groups may include categories (such as incident categories or change categories) or priority levels.
Note 2: The act of classification often comprises the application of more than one classification scheme. For instance, an incident record might be assigned to a technical incident category such as ‘software related’, ‘network related’, etc., and also to a priority level like ‘low priority’, ‘medium priority’, etc. The assignment of various incidents, service requests, changes and problems to an affected CI is also a classification.
Note 3: Besides the presentation and analysis of relationships, classification is often used as input for controlling the workflow of a process, e.g. by assigning a priority level to an incident. |
| Closure | Final activity in a workflow of a process to indicate no further action is required for a specific case | FALSE | TRUE | Note: Cases that are subject to closure may include incidents, problems, service requests or changes. The activity of closure puts the connected record (such as the incident record, problem record, service request record or change record) in its final status, usually called ‘closed’. |
Catalogue Operator Representative (COR) | An individual responsible for recording information about a Community Catalogue and onboarding and maintaining that catalogue into the EOSC Exchange. | TRUE | FALSE | Community Catalogue | A Community catalogue complying with EOSC-Exchange community resource catalogue inclusion criteria and including several resources. It is an external catalogue that can be onboarded into the EOSC Exchange by a Catalogue Operator Representative on behalf of the Community Catalogue Operator. | TRUE | FALSE | Competence | Sum of knowledge, skills and experience that an individual or group needs to effectively take on a specific role. | FALSE | TRUE | Confidentiality of information | Property of information not being accessible to unauthorised parties | FALSE | TRUE | | Configuration | State of a specified set of attributes, relationships and other relevant properties of one or more configuration items (CIs) | FALSE | TRUE | Note: The documented configuration of a number of CIs at a given point in time is called a configuration baseline, which is usually taken prior to the deployment of one or more changes to these CIs in the live environment. |
| Configuration item (CI) | Element that contributes to the delivery of one or more services or service components, therefore requiring control of its configuration | FALSE | TRUE | Note 1: CIs can vary widely, from technical components (e.g. computer hardware, network components, software) to non-technical items such as documents (e.g. service level agreements, manuals, license documentation).
Note 2: The data necessary for effective control of a CI is stored in a CI record. In addition to attributes of the CI, the CI record likely includes information on relationships it has with other CIs, service components and services. CI records are stored in a configuration management database (CMDB). |
Configuration Management (CONFM) | SMS process which provides and maintains a logical model of all configuration items and their relationships and dependencies | FALSE | TRUE | | Configuration management database (CMDB) | Store for data about configuration items (CIs) | FALSE | TRUE | Note: A CMDB is not necessarily a single database covering all configuration items (CIs). It may rather be composed of multiple physical data stores. |
| Conformity | Extent to which requirements are met in some context | FALSE | TRUE | Note: In the context of FitSM, the term compliance is generally used as a synonym for conformity. However, sometimes conformity is used in the context of adherence to internal regulations and requirements as defined by policies, processes and procedures, while compliance is used in the context of adherence to external requirements, such as laws, standards and contracts. |
Continual Service Improvement Management (CSI) | SMS process which identifies, prioritizes, plans, implements and reviews improvements to services and service management | FALSE | TRUE | | Continuity | Property of a service to maintain all or parts of its functionality, even in exceptional circumstances | FALSE | TRUE | Note: Exceptional circumstances include emergencies, crises or disasters which affect the ability to provide services over extended periods of time. |
| Customer | Organisation or part of an organisation that commissions a service provider in order to receive one or more services | FALSE | TRUE | Note: A customer usually represents a number of users. |
Customer Relationship Management (CRM) | SMS process which establishes and maintains a good relationship with customers receiving services | FALSE | TRUE | Data Source | A service that links to collections of research products (see Research Product) as well as services that provide data in response to queries. | TRUE | FALSE | | Document | Information and its supporting medium | FALSE | TRUE | Note: Examples of documents include policies, plans, process descriptions, procedures, service level agreements, contracts or records of activities performed. |
European Commission (EC) | The executive branch of the European Union | FALSE | FALSE | | Effectiveness | Extent to which goals and expectations are met | FALSE | TRUE | Note: In a management system, effectiveness is mostly measured against the defined goals of the processes that are subject to this system. |
| Efficiency | Degree of ability to meet goals and expectations with minimum consumption of resources | FALSE | TRUE | Note 1: In a management system, efficiency is mostly considered in the context of the processes that are subject to this system.
Note 2: Resources may be human, technical, informational or financial. |
European Open Science Cloud (EOSC) | European Open Science Cloud. An envisioned federation of research (data) infrastructures that will create a web of FAIR data and services for science. EOSC will be a key enabler for Open Science and will support researchers in sharing and exploiting research products (e.g as data, publications, and code) through value-added horizontal (i.e. cross-disciplinary) and thematic (i.e. discipline-specific) services. EOSC was developed in an initial implementation phase from 2016-2020 under Horizon 2020 and will be expanded in a second implementation phase via the EOSC Partnership from 2021-2027 under Horizon Europe. | TRUE | FALSE | EOSC Association | An international non-profit organisation (AISBL) based in Brussels to represent the interest of the EOSC stakeholder community. The association is a partner with the European Commission in the EOSC Partnership and has developed and will continuously update a Strategic Research and Innovation Agenda (SRIA) to advise the European Commission on the development and implementation of EOSC. | TRUE | FALSE | EOSC Interoperability Advisory Board (EIAB) | Responsible for overseeing the EOSC Interoperability Framework; endorses/deprecates guidelines based on the recommendations of the EIAC. A temporary project-based composition has been established during the EOSC Future project, consisting of the Technical Coordination Board. | TRUE | FALSE | EOSC Interoperability Area Chairs (EIAC) | Responsible for performing the initial assessment of the proposed guidelines; makes recommendations to the EIAB as regards candidates for inclusion in the EOSC Interoperability Framework. A temporary project-based composition has been established during the EOSC Future project, consisting of the task leads of the Architecture and Interoperability work package. | TRUE | FALSE | EOSC Interoperability Guideline Provider | Responsible for contributing and maintaining Interoperability Guidelines to the EOSC-IF Registry. | TRUE | FALSE | EOSC Observatory | An interactive dashboard to facilitate the monitoring of (1) EOSC readiness by European Member States and Associated Countries (2) indicators for the EOSC Partnership (3) contributions to the EOSC Partnership and EOSC ecosystem (4) national policies on Open Science and EOSC. The observatory will publicly present results of the monitoring and provide an overview of the implementation of EOSC. | TRUE | FALSE | EOSC Onboarding Strategy Group | Catalogue Operator Representatives for Community Catalogue from the INFRAEOSC-04-2018 (thematic projects), INFRAEOSC-05-2018-2019 (regional projects), and INFRAEOSC-07-2020 (horizontal projects) to ensure implementation/alignment of onboarding of Community catalogues; representatives of the EOSC Portal Onboarding Team (EPOT); operations and maintainer of the EOSC Profiles to ensure implementation according to decisions made within the E-OSG are considered by the EOSC Provider’s Portal developers. Other Provider Representatives interested in onboarding resources to the EOSC Resource Catalogue and EOSC Marketplace. | TRUE | FALSE | EOSC Marketplace | A web-based interface to search, discover, access, order and use the resources available through the EOSC Exchange, exploiting a range of filtering options, leveraging the relationships available through the Interoperability Framework, and taking advantage of integrations with EOSC Core Services and among other compatible services in the EOSC Exchange. | TRUE | FALSE | EOSC Partnership | A Co-programmed European Partnership between the EOSC Association and European Commission to implement EOSC under Horizon Europe. The partnership is governed by the tripartite EOSC Partnership Board consisting of representatives from the EOSC Association, EOSC Steering Board, and European Commission. The European Commission will fund €490 million in project and procurement calls in the Work Programmes for EOSC under Horizon Europe. The EOSC Association will collectively via its members contribute in-kind activities to EOSC totalling at least €500 million for the duration of Horizon Europe. | TRUE | FALSE | EOSC Platform | The EOSC Platform delivers the EOSC Core and EOSC Federation services as an integrated operational environment that enables EOSC research communities to take advantage of this suite of services. Exploiting EOSC Platform capabilities, research communities can add value to their own services in the Exchange and make them more useful and attractive to a wider range of science users. Furthermore, the EOSC Platform, with its extensible architecture, facilitates the addition of new capabilities (Core or Exchange - e.g. horizontal services such as the data transfer) to satisfy emerging user’s requirements. The EOSC Platform currently consists of services such as the comprehensive Resource Catalogues, the Marketplace, the EOSC Infrastructure Proxy for the EOSC Core services, the EOSC AAI Federation, the Helpdesk, the Monitoring, the Accounting, the Order Management, the Execution Framework and the EOSC Interoperability Framework registry. | TRUE | FALSE | EOSC Portal | Gateway to research-enabling resources including research publications, data, software, and value-added services to support their research. Includes the EOSC Marketplace as well as Knowledge Hub, EOSC Observatory and other resources. | TRUE | FALSE | EOSC Profile | Metadata schema for the description of services, research products or other research artefacts that their providers choose to share with the EOSC user community through the EOSC Exchange, as well as for describing the organisations offering to provide these resources to EOSC. EOSC Profiles are specified by the EOSC Profile Interoperability Guideline, which defines the entities for which Profiles have been defined and their logical relationships as part of a larger data model. | TRUE | FALSE | EOSC Service Catalogue | A catalogue containing all the Services onboarded in EOSC, together with their Providers. | TRUE | FALSE | EOSC Research Product Catalogue | A catalogue containing all the Research Products (datasets, software, etc.) onboarded in EOSC, together with their context in the scholarly communication infrastructure, e.g. creators, organisations, funders, projects. | TRUE | FALSE | EOSC Resource Catalogue | A catalogue of all EOSC Resources, the result of integrating the EOSC Service Catalogue and the EOSC Research Product Catalogue. | TRUE | FALSE | EOSC Steering Board | An expert group consisting of representatives of European Member States and Associated Countries that advises the European Commission in the development and implementation of EOSC. The board is also one of the three bodies in the tripartite EOSC Partnership Board that governs the EOSC Partnership. | TRUE | FALSE | EOSC Core | The components of EOSC that together deliver the essential operations of EOSC, including resource onboarding, discovery, ordering, use, monitoring, accounting and support, including the federated delivery of consistent services across a distributed "system of systems". | TRUE | FALSE | EOSC Interoperability Guideline | Version-controlled document that describes standards to enable interoperability and explain how Providers can make their resources compatible with them. They outline the high-level protocols (such as REST) and low-level protocols (such as OAI-PMH), data models (e.g. DCAT model), and schemas (e.g. DCAT JSON schema) that need to be implemented or customized to ensure compatibility with each guideline. Guidelines specify the essential technical requirements and configurations that providers should follow in order to make their services compatible with the interoperability guidelines. EOSC Interoperability Guidelines pass a validation process, after which they are onboarded (registered) into the EOSC IF registry. | TRUE | FALSE |
|
| Community Catalogue Operator | An organisation operating an EOSC-compliant community catalogue and responsible for the onboarding and validating selected resources from that community catalogue into the EOSC Exchange. |
|
| Catalogue Operator Representative (COR) | An individual responsible for recording information about a Community Catalogue and onboarding and maintaining that catalogue into the EOSC Exchange. |
|
| Community Catalogue | A Community catalogue complying with EOSC-Exchange community resource catalogue inclusion criteria and including several resources. It is an external catalogue that can be onboarded into the EOSC Exchange by a Catalogue Operator Representative on behalf of the Community Catalogue Operator. |
|
| Data Source | A service that links to collections of research products (see Research Product) as well as services that provide data in response to queries. |
|
| European Commission (EC) | The executive branch of the European Union |
|
| European Open Science Cloud (EOSC) | European Open Science Cloud. An envisioned federation of research (data) infrastructures that will create a web of FAIR data and services for science. EOSC will be a key enabler for Open Science and will support researchers in sharing and exploiting research products (e.g as data, publications, and code) through value-added horizontal (i.e. cross-disciplinary) and thematic (i.e. discipline-specific) services. EOSC was developed in an initial implementation phase from 2016-2020 under Horizon 2020 and will be expanded in a second implementation phase via the EOSC Partnership from 2021-2027 under Horizon Europe. |
|
| EOSC Association | An international non-profit organisation (AISBL) based in Brussels to represent the interest of the EOSC stakeholder community. The association is a partner with the European Commission in the EOSC Partnership and has developed and will continuously update a Strategic Research and Innovation Agenda (SRIA) to advise the European Commission on the development and implementation of EOSC. |
|
| EOSC Interoperability Advisory Board (EIAB) | Responsible for overseeing the EOSC Interoperability Framework; endorses/deprecates guidelines based on the recommendations of the EIAC. A temporary project-based composition has been established during the EOSC Future project, consisting of the Technical Coordination Board. |
|
| EOSC Interoperability Area Chairs (EIAC) | Responsible for performing the initial assessment of the proposed guidelines; makes recommendations to the EIAB as regards candidates for inclusion in the EOSC Interoperability Framework. A temporary project-based composition has been established during the EOSC Future project, consisting of the task leads of the Architecture and Interoperability work package. |
|
| EOSC Interoperability Guideline Provider | Responsible for contributing and maintaining Interoperability Guidelines to the EOSC-IF Registry. |
|
| EOSC Observatory | An interactive dashboard to facilitate the monitoring of (1) EOSC readiness by European Member States and Associated Countries (2) indicators for the EOSC Partnership (3) contributions to the EOSC Partnership and EOSC ecosystem (4) national policies on Open Science and EOSC. The observatory will publicly present results of the monitoring and provide an overview of the implementation of EOSC. |
|
| EOSC Onboarding Strategy Group | Catalogue Operator Representatives for Community Catalogue from the INFRAEOSC-04-2018 (thematic projects), INFRAEOSC-05-2018-2019 (regional projects), and INFRAEOSC-07-2020 (horizontal projects) to ensure implementation/alignment of onboarding of Community catalogues; representatives of the EOSC Portal Onboarding Team (EPOT); operations and maintainer of the EOSC Profiles to ensure implementation according to decisions made within the E-OSG are considered by the EOSC Provider’s Portal developers. Other Provider Representatives interested in onboarding resources to the EOSC Resource Catalogue and EOSC Marketplace. |
|
| EOSC Marketplace | A web-based interface to search, discover, access, order and use the resources available through the EOSC Exchange, exploiting a range of filtering options, leveraging the relationships available through the Interoperability Framework, and taking advantage of integrations with EOSC Core Services and among other compatible services in the EOSC Exchange. |
|
| EOSC Partnership | A Co-programmed European Partnership between the EOSC Association and European Commission to implement EOSC under Horizon Europe. The partnership is governed by the tripartite EOSC Partnership Board consisting of representatives from the EOSC Association, EOSC Steering Board, and European Commission. The European Commission will fund €490 million in project and procurement calls in the Work Programmes for EOSC under Horizon Europe. The EOSC Association will collectively via its members contribute in-kind activities to EOSC totalling at least €500 million for the duration of Horizon Europe. |
|
| EOSC Platform | The EOSC Platform delivers the EOSC Core and EOSC Federation services as an integrated operational environment that enables EOSC research communities to take advantage of this suite of services. Exploiting EOSC Platform capabilities, research communities can add value to their own services in the Exchange and make them more useful and attractive to a wider range of science users. Furthermore, the EOSC Platform, with its extensible architecture, facilitates the addition of new capabilities (Core or Exchange - e.g. horizontal services such as the data transfer) to satisfy emerging user’s requirements. The EOSC Platform currently consists of services such as the comprehensive Resource Catalogues, the Marketplace, the EOSC Infrastructure Proxy for the EOSC Core services, the EOSC AAI Federation, the Helpdesk, the Monitoring, the Accounting, the Order Management, the Execution Framework and the EOSC Interoperability Framework registry. |
|
| EOSC Portal | Gateway to research-enabling resources including research publications, data, software, and value-added services to support their research. Includes the EOSC Marketplace as well as Knowledge Hub, EOSC Observatory and other resources. |
|
| EOSC Profile | Metadata schema for the description of services, research products or other research artefacts that their providers choose to share with the EOSC user community through the EOSC Exchange, as well as for describing the organisations offering to provide these resources to EOSC. EOSC Profiles are specified by the EOSC Profile Interoperability Guideline, which defines the entities for which Profiles have been defined and their logical relationships as part of a larger data model. |
|
| EOSC Service Catalogue | A catalogue containing all the Services onboarded in EOSC, together with their Providers. |
|
| EOSC Research Product Catalogue | A catalogue containing all the Research Products (datasets, software, etc.) onboarded in EOSC, together with their context in the scholarly communication infrastructure, e.g. creators, organisations, funders, projects. |
|
| EOSC Resource Catalogue | A catalogue of all EOSC Resources, the result of integrating the EOSC Service Catalogue and the EOSC Research Product Catalogue. |
|
| EOSC Steering Board | An expert group consisting of representatives of European Member States and Associated Countries that advises the European Commission in the development and implementation of EOSC. The board is also one of the three bodies in the tripartite EOSC Partnership Board that governs the EOSC Partnership. |
|
| EOSC Core | The components of EOSC that together deliver the essential operations of EOSC, including resource onboarding, discovery, ordering, use, monitoring, accounting and support, including the federated delivery of consistent services across a distributed "system of systems". |
|
| EOSC Interoperability Guideline | Version-controlled document that describes standards to enable interoperability and explain how Providers can make their resources compatible with them. They outline the high-level protocols (such as REST) and low-level protocols (such as OAI-PMH), data models (e.g. DCAT model), and schemas (e.g. DCAT JSON schema) that need to be implemented or customized to ensure compatibility with each guideline. Guidelines specify the essential technical requirements and configurations that providers should follow in order to make their services compatible with the interoperability guidelines. EOSC Interoperability Guidelines pass a validation process, after which they are onboarded (registered) into the EOSC IF registry. |
|
| EOSC Core Interoperability Guideline | EOSC Interoperability guideline to enable compatibility with specific EOSC Core services, including EOSC monitoring, EOSC accounting, and EOSC helpdesk. |
|
| EOSC Exchange | The collection of resources and organisations onboarded to the EOSC Platform, visible in the EOSC Resource Catalogue and EOSC Marketplace, and findable accessible and usable by EOSC Users. |
|
| EOSC Exchange Interoperability Guideline | EOSC-Exchange Interoperability Guidelines facilitate interoperation of services and resources within thematic areas. As such they are defined, proposed, and maintained by EOSC providers. Specifically, horizontal Interoperability Guidelines facilitate interoperation of services and resources across communities and infrastructures, and can communicate the interoperability capabilities and boundaries of frameworks utilised by communities. |
|
| EOSC-Interoperability Framework | The collection of EOSC Interoperability Guidelines onboarded to the EOSC Platform, visible in the EOSC IF Registry, which can be used to enable interoperability between individual EOSC Resources and EOSC Core services as well as interoperability between EOSC Resources (e.g. enabling data transfer, orchestration, etc.). The Framework includes the governance processes for reviewing, approving and accepting new Interoperability Guidelines into the IF Registry. |
|
| EOSC-Interoperability Framework Registry | A database of submitted and approved EOSC Interoperability Guidelines, based on an agreed profile of attributes. |
|
| EOSC Portal Onboarding Team (EPOT) | Collaborative team which manages and operates the EOSC Onboarding and Audit processes to populate the EOSC-Exchange, using the EOSC Profiles and assessing the compliance of resources with the EOSC Portal inclusion criteria derived from the EOSC Rules of Participation. |
|
| FAIR | Findable, Accessible, Interoperable, Reusable. Four guiding principles for research data management and stewardship that consist of metadata protocols for making digital research objects (e.g. publications, data, and code) machine-actionable (i.e. the capacity of computational systems to find, access, interoperate, and reuse data with none or minimal human intervention). |
|
| Federated Identity Management for Research (FIM4R) | Federated Identity Management for Research. A collection of research communities working to enable federated identity management for their infrastructures. |
|
| Horizontal Service | A service that may be used by multiple communities, rather than one that is focussed on one particular community. The following characteristics have been agreed within the EOSC-Future project to define a horizontal service: |
|
| Hosting Legal Entity (HLE) | An institution registered as an EOSC resource provider, that is a legal entity and agrees to be accountable for resources onboarded to EOSC. Resources may be onboarded by a resource provider which is not a legal entity, but only if the Hosting Legal Entity field includes one legal entity already registered as resource provider, if this has been agreed in advance with them |
|
| Inclusion Criteria | A set of defined requirements with which providers, catalogue operators and resources need to comply in order to be onboarded into EOSC |
|
| Infrastructure and value-added services | Generic capabilities that users/customers or thematic services can use to perform/ease compute and data intensive steps. Example services within this group: IaaS clouds; HTC clusters; Container execution sites; Orchestrators; Schedulers; File transfer; Data replication |
|
| Indicators of Compromise (IoC) | A piece of digital forensics which indicates a potential breach of a host system or network |
|
| Lead provider | Resource Organisation (Resource profile/ERP.BAI.3) that manages or delivers the resource, or that coordinates the Resource delivery in a federated scenario. |
|
| Open Researcher and Contributor ID (ORCID) | Non-proprietary alphanumeric code to uniquely identify authors and contributors of scholarly communication |
|
| Persistent Identifier (PID) | Long-lasting reference to a document, file, web page, or other object |
|
| Provider | An organisation operating a resource, whether operating a service or providing access to research artefacts for use or access by users not affiliated with the organisation itself. |
|
| REsearch and Education Identity FEDerationS (REFEDS) | A group which articulates the mutual needs of research and education identity federations worldwide. |
|
| Research Product | A scientific or research output (classified as publication (literature), research data, research software, and "other kinds of products"), accessible or linked from an EOSC Data Source (e.g. repository, scientific database, publisher archive aggregator, CRIS system), whose metadata might be "harvested from" the linking EOSC Data Source using a defined protocol (e.g. OAI-PMH). |
|
| Resource | Services, catalogues, research products, training resources, interoperability guidelines and other assets. In the context of EOSC, these are understand to be both digital and produced or operated by or of potential use to scientists and researchers. Services include data sources, computational resources and data storage resources. |
|
| Rules of Participation (RoP) | The standards and conduct required of EOSC participants. EOSC participants agree to adhere to the RoP. |
|
| SCI | Security for Collaboration among Infrastructure. A collaborative activity of security representatives from large-scale distributed academic computing infrastructures managing cross-infrastructure operational security risks and building trust and developing policy standards |
|
| Service Portfolio Management (SPM) | SMS process which defines and maintains the service portfolio |
|
| Security Incident Response Trust framework for Federated Identity (SIRTFI) | REFEDS working group which enables the coordination of incident response across federated organisations. |
|
| Software Quality Assurance (SQA) | A process which works in parallel with software development to ensure that the software meets the required quality. |
|
| SQA as a Service (SQAaaS) | The provision of services which provide SQA. |
|
| Supplier and Federation member Relationship Management (SFRM) | SMS process which establishes and maintains a healthy relationship with suppliers and federation members supporting the service provider in delivering services to customers, and monitor their performance |
|
| Technical Coordination Board (TCB) | Technical Coordination Board of the EOSC-Future project. Entity which oversees the technical direction of the project, represents technical stakeholders and ensures technical alignment with other initiatives. |
|
| Thematic services | Scientific services (incl. data) that provide discipline-specific capabilities for researchers. (e.g. browsing and download data and apps, workflow development, execution, online analytics, result visualisation, sharing of result data, publications, applications) |
|
| Training resource | Any resource – including print and non-print materials and online/open-access resources – which supports and enhances, directly or indirectly, learning and teaching. If a training resource is used in a training environment, for training activities that are part of a training plan and involve instructors, facilitators and students, then we speak of training materials. |
|
| Technology Readiness Level (TRL) | An indication of the maturity of a service. | Within EOSC-Future the three most relevant levels are: TRL 7 (Beta). EC definition: "System prototype demonstration in operational environment". EOSC-Future assessment criteria:
· Resource has passed through the development and is an advanced stage of pre-production: the software is stable, reliable and has been deployed in an operational environment
· Functionality as required by the target users is documented, understood, validated with target sample users and accepted by them. Internal documentation exists regarding preliminary validation tests.
· An assessment has been made of the required load of the system once the transition into production is complete and a plan has been made to serve this load. This assessment has been documented.
· An SLA is optional.
TRL8 (Production). EC definition: "System complete and qualified". EOSC-Future assessment criteria:
· There are users who are making real use of the resource and rely on it for their work.
· Resource documentation for end-users exists and is made available.
· An Acceptable Use Policy/Terms of Use/SLA/SLS is in place
· Evidence that the Resource is being delivered in a way consistent with user expectations
· Provision is made for user support, with response to incident and problem management
TRL9 (Production). EC definition: "Actual system proven in operational environment". EOSC-Future assessment criteria:
· All requirements of TRL 8 are met.
· Customer feedback is gathered and documented. The Resource has been in a production state and relied upon by users for at least 1 year and evidence is provided to show this.
· There are quantitative outputs as a direct result of resource usage.
Further details can be found at https://eosc-portal.eu/providers-documentation/eosc-provider-portal-resource-maturity-classification
See also ec.europa.eu/research/participants/data/ref/h2020/other/wp/2016-2017/annexes/h2020-wp1617-annex-ga_en.pdf page 29 |
| Wise Information Security for E-infrastructures (WISE) | Community which enhances best practice in information security for IT infrastructures for research. |
|
| WP | Work package |
EOSC Core Interoperability Guideline | EOSC Interoperability guideline to enable compatibility with specific EOSC Core services, including EOSC monitoring, EOSC accounting, and EOSC helpdesk. | TRUE | FALSE | EOSC Exchange | The collection of resources and organisations onboarded to the EOSC Platform, visible in the EOSC Resource Catalogue and EOSC Marketplace, and findable accessible and usable by EOSC Users. | TRUE | FALSE | EOSC Exchange Interoperability Guideline | EOSC-Exchange Interoperability Guidelines facilitate interoperation of services and resources within thematic areas. As such they are defined, proposed, and maintained by EOSC providers. Specifically, horizontal Interoperability Guidelines facilitate interoperation of services and resources across communities and infrastructures, and can communicate the interoperability capabilities and boundaries of frameworks utilised by communities. | TRUE | FALSE | EOSC-Interoperability Framework | The collection of EOSC Interoperability Guidelines onboarded to the EOSC Platform, visible in the EOSC IF Registry, which can be used to enable interoperability between individual EOSC Resources and EOSC Core services as well as interoperability between EOSC Resources (e.g. enabling data transfer, orchestration, etc.). The Framework includes the governance processes for reviewing, approving and accepting new Interoperability Guidelines into the IF Registry. | TRUE | FALSE | EOSC-Interoperability Framework Registry | A database of submitted and approved EOSC Interoperability Guidelines, based on an agreed profile of attributes. | TRUE | FALSE | EOSC Portal Onboarding Team (EPOT) | Collaborative team which manages and operates the EOSC Onboarding and Audit processes to populate the EOSC-Exchange, using the EOSC Profiles and assessing the compliance of resources with the EOSC Portal inclusion criteria derived from the EOSC Rules of Participation. | TRUE | FALSE | | Escalation | Change of responsibility for a case (such as an incident, service request, problem or change) or activity to another individual or group | FALSE | TRUE | Note: There are two basic types of escalation: Hierarchical escalation transfers responsibility (temporarily) to someone with a higher level of authority. Functional escalation transfers responsibility to someone with a different set of competencies or privileges required to handle the case or activity. |
FAIR | Findable, Accessible, Interoperable, Reusable. Four guiding principles for research data management and stewardship that consist of metadata protocols for making digital research objects (e.g. publications, data, and code) machine-actionable (i.e. the capacity of computational systems to find, access, interoperate, and reuse data with none or minimal human intervention). | FALSE | FALSE | Federation | Situation in which multiple parties, the federation members, jointly contribute to the delivery of services to customers without being organised in a strict hierarchical setup or supply chain. | FALSE | TRUE | | Federation member | Individual, organisation or body that works together with other federation members in a federation to provide one or more services | FALSE | TRUE | Note: Often, federation members will not be bound together by strict contractual agreements. |
Federator | Body that acts to coordinate a set of federation members | FALSE | TRUE | Federated Identity Management for Research (FIM4R) | Federated Identity Management for Research. A collection of research communities working to enable federated identity management for their infrastructures. | FALSE | FALSE | Horizontal Service | A service that may be used by multiple communities, rather than one that is focussed on one particular community. The following characteristics have been agreed within the EOSC-Future project to define a horizontal service: | TRUE | FALSE | Hosting Legal Entity (HLE) | An institution registered as an EOSC resource provider, that is a legal entity and agrees to be accountable for resources onboarded to EOSC. Resources may be onboarded by a resource provider which is not a legal entity, but only if the Hosting Legal Entity field includes one legal entity already registered as resource provider, if this has been agreed in advance with them | TRUE | FALSE | | Improvement | Action or set of actions carried out to increase the level of conformity, effectiveness or efficiency of a management system, process or activity, or to increase the quality or performance of a service or service component | FALSE | TRUE | Note: An improvement is usually implemented after an opportunity for improvement has been identified, for instance during a service review, audit or management review. |
Incident | Unplanned disruption of operation in a service or service component, or degradation of service quality versus the expected or agreed service level or operational level according to service level agreements (SLAs), operational level agreements (OLAs) and underpinning agreements (UAs). | FALSE | TRUE | Incident and Service Request Management (ISRM) | SMS process which restores normal / agreed service operation within the agreed time after the occurrence of an incident, and to respond to user service requests | FALSE | TRUE | Inclusion Criteria | A set of defined requirements with which providers, catalogue operators and resources need to comply in order to be onboarded into EOSC | TRUE | FALSE | Information security | Preservation of confidentiality, integrity and accessibility of information | FALSE | TRUE | Information security control | Means of controlling or treating one or more risks to information security | FALSE | TRUE | | Information security event | Occurrence or previously unknown situation indicating a possible breach of information security | FALSE | TRUE | Note: An occurrence or situation is considered a potential breach of information security if it may lead to a negative impact on the confidentiality, integrity and / or accessibility of one or more information assets. |
Information security incident | Single information security event or a series of information security events with a significant probability of having a negative impact on the delivery of services to customers, and therefore on the customers’ business operations | FALSE | TRUE | Information Security Management (ISM) | SMS process which manages information security effectively through all activities performed to deliver and manage services, so that the confidentiality, integrity and accessibility of relevant information are preserved | FALSE | TRUE | Infrastructure and value-added services | Generic capabilities that users/customers or thematic services can use to perform/ease compute and data intensive steps. Example services within this group: IaaS clouds; HTC clusters; Container execution sites; Orchestrators; Schedulers; File transfer; Data replication | FALSE | FALSE | Integrity of information | Property of information not being subject to unauthorized modification, duplication or deletion | FALSE | TRUE | Indicators of Compromise (IoC) | A piece of digital forensics which indicates a potential breach of a host system or network | FALSE | FALSE | IT service | Service that is enabled by the use of information technology (IT) | FALSE | TRUE | | IT service management (ITSM) | Entirety of activities performed by an IT service provider to plan, deliver, operate and control IT services offered to customers | FALSE | TRUE | Note: The activities carried out in the ITSM context should be directed by policies and structured and organised by processes and supporting procedures. |
| Key performance indicator (KPI) | Metric that is used to track the performance, effectiveness or efficiency of a service or process | FALSE | TRUE | Note: KPIs are generally important metrics that will be aligned to critical success factors and important goals. KPIs are therefore a subset of all possible metrics, intended to allow for monitoring a service or process. |
Known error | Problem which has not (yet) been corrected, but for which there is a documented workaround or temporary fix to prevent (excessive) negative impact on services | FALSE | TRUE | Lead provider | Resource Organisation (Resource profile/ERP.BAI.3) that manages or delivers the resource, or that coordinates the Resource delivery in a federated scenario. | FALSE | FALSE | | Management review | Periodic evaluation of the suitability, maturity and efficiency of the entire management system by its accountable owner(s), from which opportunities for improvement are identified and follow-up actions are determined | FALSE | TRUE | Note: The accountable owner of a management system is usually a top management representative of the organisation operating the management system. In a federation, the accountable owner is usually one person nominated by top management representatives of all organisations (i.e. federation members) involved. |
| Management system | Entirety of policies, processes, procedures and related resources and capabilities aiming at effectively performing management tasks in a given context and for a given subject | FALSE | TRUE | Note 1: A management system is generally intangible. It is based on the idea of a systematic, structured and process-oriented way of managing.
Note 2: While documentation (such as process definitions, procedures and records) and tools (such as workflow support and monitoring tools) can be parts of a management system, management system considerations are not limited to the questions of documentation and tool support.
Note 3: With respect to (IT) service management and the FitSM standard series, the idea of a service management system (SMS) is a central concept, where the context of the management system is the organisational context of the service provider, and the subject is to plan, deliver, operate and control (IT) services. |
Maturity level | Achieved overall effectiveness of a service management system, based on the combination of the capability levels of its processes and general aspects of management | FALSE | TRUE | | Nonconformity | Case or situation where a requirement is not fulfilled | FALSE | TRUE | Note: This may also be referred to as noncompliance. |
Operational level agreement (OLA) | Documented agreement between a service provider and another part of the service provider’s organisation or a federation member to provide a service component or subsidiary service needed to allow provision of services to customers | FALSE | TRUE | | Operational target | Reference / target value for a parameter used to measure the performance of a service component, listed in an operational level agreement (OLA) or underpinning agreement (UA) related to this service component | FALSE | TRUE | Note: Typical operational targets might include availability or allowed resolution times for incidents. |
Open Researcher and Contributor ID (ORCID) | Non-proprietary alphanumeric code to uniquely identify authors and contributors of scholarly communication | FALSE | FALSE | Persistent Identifier (PID) | Long-lasting reference to a document, file, web page, or other object | FALSE | FALSE | | Policy | Documented set of intentions, expectations, goals, rules and requirements, often formally expressed by top management representatives in an organisation or federation | FALSE | TRUE | Note: Policies are then realised in processes, which are in turn made up of activities that people carry out according to defined procedures. |
| Post implementation review (PIR) | Review after the implementation of a change that determines if the change was successful | FALSE | TRUE | Note: Depending on the specific type and complexity of the change, the post implementation review may vary widely in its depth. |
| Priority | Relative importance of a target, object or activity | FALSE | TRUE | Note: Often incidents, service requests, problems and changes are given a priority. In the case of incidents and problems, priority is usually based on the specific impact and urgency of the situation. |
Problem | Underlying cause of one or more incidents that requires further investigation to prevent incidents from recurring or reduce the negative impact on services | FALSE | TRUE | Problem Management (PM) | SMS process which investigate the root causes of (recurring) incidents in order to avoid future recurrence of incidents by resolving the underlying cause, or to ensure workarounds / temporary fixes are available | FALSE | TRUE | Procedure | Specified set of steps or instructions to be carried out by an individual or group to perform one or more activities of a process | FALSE | TRUE | | Process | Structured set of activities, with clearly defined responsibilities, that bring about a specific objective or set of results from a set of defined inputs | FALSE | TRUE | Note: Generally, a process consists of a number of activities used to manage services, if the process is part of a service management system (SMS). |
Provider | An organisation operating a resource, whether operating a service or providing access to research artefacts for use or access by users not affiliated with the organisation itself. | TRUE | FALSE | Record | Documentation of an event or of the results of performing a process or activity | FALSE | TRUE | REsearch and Education Identity FEDerationS (REFEDS) | A group which articulates the mutual needs of research and education identity federations worldwide. | FALSE | FALSE | Release | Set of one or more changes to configuration items (CIs) that are grouped together and deployed as a logical unit | FALSE | TRUE | Release and Deployment Management (RDM) | SMS process which bundles changes of one or more configuration items to releases, so that these changes can be tested and deployed to the live environment together | FALSE | TRUE | Request for change (RFC) | Documented proposal for a change to be made to one or more configuration items (CIs) | FALSE | TRUE | Research Product | A scientific or research output (classified as publication (literature), research data, research software, and "other kinds of products"), accessible or linked from an EOSC Data Source (e.g. repository, scientific database, publisher archive aggregator, CRIS system), whose metadata might be "harvested from" the linking EOSC Data Source using a defined protocol (e.g. OAI-PMH). | TRUE | FALSE | Resource | Services, catalogues, research products, training resources, interoperability guidelines and other assets. In the context of EOSC, these are understand to be both digital and produced or operated by or of potential use to scientists and researchers. Services include data sources, computational resources and data storage resources. | TRUE | FALSE | | Risk | Possible negative occurrence that would have a negative impact on the service provider’s ability to deliver agreed services to customers, or that would decrease the value generated through some service | FALSE | TRUE | Note: Risk is made up of the probability of the threat entailed, the vulnerability to that threat of some asset, and the impact the threat would have, if it occurred. |
| Role | Set of responsibilities and connected behaviours or actions collected into a logical unit that can be assigned to an individual or group | FALSE | TRUE | Note: An individual may take over multiple roles. |
Rules of Participation (RoP) | The standards and conduct required of EOSC participants. EOSC participants agree to adhere to the RoP. | TRUE | FALSE | SCI | Security for Collaboration among Infrastructure. A collaborative activity of security representatives from large-scale distributed academic computing infrastructures managing cross-infrastructure operational security risks and building trust and developing policy standards | FALSE | FALSE | SDTP | Service Design and Transition Package. Plans for the design and transition of a specific new or changed service. | FALSE | TRUE | | Service | Digital system that allows a user either to interact with the system, entering data or other inputs, executing instructions through commands or other interfaces, or to issue machine-to-machine commands using a protocol such as an API that allows information or data to be supplied to the system, and that allows results to be received by the user through graphical interfaces and/or production of output data files. | TRUE | TRUE | Note: In the context of the FitSM standard series, when referring to services, usually IT services are meant. |
| Service acceptance criteria (SAC) | Criteria that must be fulfilled by the time a new or changed service is deployed and made available to customers / users | FALSE | TRUE | Note: SAC are defined when a new or changed service is designed, and they may be updated or refined during the development or transition phase. They may cover functional and non-functional aspects of the specific service to be deployed. SAC are part of the service design and transition package (SDTP). |
Service Availability and Continuity Management (SACM) | SMS process which ensures sufficient capacities are provided to meet agreed service capacity and performance requirements | FALSE | TRUE | | Service catalogue | The general description at IT SMS level according to the FitSM Family of standards (FitSM-0) it is a customer-facing list of all live services offered along with relevant information about these services | FALSE | TRUE | Note: The service catalogue can be regarded as a filtered version of and customers’ view on the service portfolio.
Note: The service catalogue is part of the IT SMS of EOSC and must not be confused with the community resource catalogues that can be onboarded to EOSC-Exchange. |
| Service component | Logical part of a service that provides a function enabling or enhancing a service | FALSE | TRUE | Note 1: A service is usually composed of several service components.
Note 2: A service component is usually built from one or more configuration items (CIs).
Note 3: Although a service component underlies one or more services, it usually does not create value for a customer alone and is therefore not a service by itself. |
| Service design and transition package (SDTP) | Entirety of plans for the design and transition of a specific new or changed service | FALSE | TRUE | Note: An SDTP should be produced for every new or changed service. It may consist of a number of documented plans and other relevant information, available in different formats, including a list of requirements and service acceptance criteria (SAC), a project plan, communication and training plans, technical plans and specifications, resource plans, development and deployment schedules / timetables, etc. |
Service level agreement (SLA) | Documented agreement between a customer and service provider that specifies the service to be provided and the service targets that define how it will be provided | FALSE | TRUE | Service Level Management (SLM) | SMS process which maintains the service catalogue, defines agrees and monitors SLAs, OLAs and UAs with suppliers | FALSE | TRUE | | Service management | Entirety of activities performed by a service provider to plan, deliver, operate and control services offered to customers | FALSE | TRUE | Note 1: The activities carried out in the service management context should be directed by policies and structured and organised by processes and supporting procedures.
Note 2: In the context of the FitSM standard series, when referring to service management, usually IT service management is meant. |
Service management plan | Overall plan for implementing and operating a service management system (SMS) | FALSE | TRUE | | Service management system (SMS) | Overall management system that controls and supports management of services within an organisation or federation | FALSE | TRUE | Note: The SMS can be regarded as the entirety of interconnected policies, processes, procedures, roles, agreements, plans, related resources and other elements needed and used by a service provider to effectively manage the delivery of services to customers. |
| Service portfolio | Internal list that details all the services offered by a service provider, including those in preparation, live and discontinued | FALSE | TRUE | Note: For each service, the service portfolio may include information such as its value proposition, target customer base, service description, relevant technical specifications, cost and price, risks to the service provider, service level packages offered, etc. |
Service Portfolio Management (SPM) | SMS process which defines and maintains the service portfolio | FALSE | FALSE | Service provider | Organisation or federation (or part of an organisation or federation) that manages and delivers a service or services to customers | FALSE | TRUE | Service report | Report that details the performance of a service versus the service targets defined in service level agreements (SLAs) – often based on key performance indicators (KPIs). | FALSE | TRUE | Service Reporting Management (SRM) | SMS process which specifies all service reports and ensures they are produced according to specifications in a timely manner to support decision-making | FALSE | TRUE | | Service request | User request for information, advice, access to a service or a pre-approved change | FALSE | TRUE | Note: Service requests are often handled by the same process and tools as incidents. |
Service review | Periodic evaluation of the quality and performance of a service together with the customer or under consideration of customer feedback, from which opportunities for improvement are identified, follow-up actions to increase the value of the service are determined | FALSE | TRUE | | Service target | Reference / target values for a parameter used to measure the performance of a service, listed in a service level agreement (SLA) related to this service | FALSE | TRUE | Note: Typical service targets might include availability or resolution time for incidents. |
Security Incident Response Trust framework for Federated Identity (SIRTFI) | REFEDS working group which enables the coordination of incident response across federated organisations. | FALSE | FALSE | Software Quality Assurance (SQA) | A process which works in parallel with software development to ensure that the software meets the required quality. | FALSE | FALSE | SQA as a Service (SQAaaS) | The provision of services which provide SQA. | FALSE | FALSE | Supplier | External organisation that provides a (supporting) service or service component(s) to the service provider, which they need to provide services to their customers / users | FALSE | TRUE | Supplier and Federation member Relationship Management (SFRM) | SMS process which establishes and maintains a healthy relationship with suppliers and federation members supporting the service provider in delivering services to customers, and monitor their performance | FALSE | FALSE | Technical Coordination Board (TCB) | Technical Coordination Board of the EOSC-Future project. Entity which oversees the technical direction of the project, represents technical stakeholders and ensures technical alignment with other initiatives. | TRUE | FALSE | Thematic services | Scientific services (incl. data) that provide discipline-specific capabilities for researchers. (e.g. browsing and download data and apps, workflow development, execution, online analytics, result visualisation, sharing of result data, publications, applications) | FALSE | FALSE | Top management | Senior management within an organisation who has authority to set policies and exercise overall control of the organisation | FALSE | TRUE | Training resource | Any resource – including print and non-print materials and online/open-access resources – which supports and enhances, directly or indirectly, learning and teaching. If a training resource is used in a training environment, for training activities that are part of a training plan and involve instructors, facilitators and students, then we speak of training materials. | TRUE | FALSE | | Technology Readiness Level (TRL) | An indication of the maturity of a service. | TRUE | FALSE | Within EOSC-Future the three most relevant levels are: TRL 7 (Beta). EC definition: "System prototype demonstration in operational environment". EOSC-Future assessment criteria:
· Resource has passed through the development and is an advanced stage of pre-production: the software is stable, reliable and has been deployed in an operational environment
· Functionality as required by the target users is documented, understood, validated with target sample users and accepted by them. Internal documentation exists regarding preliminary validation tests.
· An assessment has been made of the required load of the system once the transition into production is complete and a plan has been made to serve this load. This assessment has been documented.
· An SLA is optional.
TRL8 (Production). EC definition: "System complete and qualified". EOSC-Future assessment criteria:
· There are users who are making real use of the resource and rely on it for their work.
· Resource documentation for end-users exists and is made available.
· An Acceptable Use Policy/Terms of Use/SLA/SLS is in place
· Evidence that the Resource is being delivered in a way consistent with user expectations
· Provision is made for user support, with response to incident and problem management
TRL9 (Production). EC definition: "Actual system proven in operational environment". EOSC-Future assessment criteria:
· All requirements of TRL 8 are met.
· Customer feedback is gathered and documented. The Resource has been in a production state and relied upon by users for at least 1 year and evidence is provided to show this.
· There are quantitative outputs as a direct result of resource usage.
Further details can be found at https://eosc-portal.eu/providers-documentation/eosc-provider-portal-resource-maturity-classification
See also ec.europa.eu/research/participants/data/ref/h2020/other/wp/2016-2017/annexes/h2020-wp1617-annex-ga_en.pdf page 29 |
Underpinning agreement (UA) | Documented agreement between a service provider and an external supplier that specifies the underpinning service(s) or service component(s) to be provided by the supplier, together with the related service targets | FALSE | TRUE | Underpinning contract (UC) | See: Underpinning agreement (UA) | FALSE | TRUE | User | Individual that primarily benefits from and uses a service | FALSE | TRUE | | Value | Benefit to a customer and their users delivered by a service | FALSE | TRUE | Note: Value should be considered as a composition of the utility (fitness for purpose) and warranty (fitness for use, covering sufficient availability / continuity, capacity / performance and information security) connected to a service. |
Wise Information Security for E-infrastructures (WISE) | Community which enhances best practice in information security for IT infrastructures for research. | FALSE | FALSE | | Workaround | Means of circumventing or mitigating the symptoms of a known error that helps to resolve incidents caused by this known error, while the underlying root cause is not permanently eliminated | FALSE | TRUE | Note 1: Workarounds are often applied in a situation, when the actual root cause of (recurring) incidents cannot be resolved due to lack of resources or ability.
Note 2: A workaround may consist of a set of actions to be carried out by either the provider or the user of the service. |
WP | Work package. | FALSE | FALSE