dataesr/scientific-paragraphs-categorization huggingface dataset:
CMIP6 forcing datasets used by EC-Earth3 and EC-Earth3-Veg for DECK (diagnostic, evaluation, and characterization of klima) and historical experiments. All datasets are available from https://esgf-node. llnl. gov/search/input4mips/ (last access: 18 March 2022). A more detailed description of the CMIP6 forcing datasets is available at http://goo. gl/r8up31 (last access: 18 March 2022).
Acknowledgements. This paper and the development of EC-Earth3 would not have been possible without the member institutions of the  EC-Earth consortium  and their sustained support of the development and application to CMIP6. Those members are the following:  Agencia Estatal de Meteorología (AEMET, Spain) ;  Institute of Atmospheric Sciences and Climate of the Consiglio Nazionale delle Ricerche, ISAC-CNR (Italy) ;  Danmarks Meteorologiske Institut, DMI (Denmark) ;  Finnish Meteorological Institute, FMI (Finland) ; the  Portuguese Institute for Sea and Atmosphere, IPMA  (Porhttps://doi. org/10. 5194/gmd-15-2973-2022 Geosci. Model Dev. , 15, 2973-3020, 2022.
(2017) and relative change in cloud droplet number concentration Land use v2. 1 (h)istoric and (f)uture Hurtt et al. (2019a, b, 2020) Used only in combina- tion with dynamic veg- etation model Nitrogen deposition v2. 0 http://blogs. reading. ac. uk/ccmi/ Used only in combina- forcing-databases-in-support-of-cmip6/ (last tion with dynamic veg- access: 18 March 2022; Hegglin et al. , 2021) etation model.
An automated composer would not only save valuable research time, but also reduce errors. • Exhaustive exploration of data-analytical possibilities. Given the abundance of bioinformatics tools available today, it is impossible for a human to consider all possible combinations that could be relevant for their problem. Indeed, scientists often resort to the tools and workflows with which they are familiar, at the risk of missing better suited or more effective pipelines for their problem. Assisted or even automated workflow composition would systematically and comprehensively explore the workflows that are possible with the available tools, and could also rank the possible workflows based on specific user requirements, such as runtime, compute requirements, underlying database usage, etc. This would enable new scientific findings by discovering well or better performing workflows that researchers would not have thought of themselves.
Examples of semantic domain models Three important, contemporary and active semantic domain modelling platforms are EDAM/bio. tools, OntoSoft and SADI. [53]  EDAM and bio. tools The EDAM ontology of bioinformatics terms  14  and the bio. tools registry  54, 17  have become the primary resources for semantic software annotation in the European life sciences community. EDAM provides a controlled vocabulary for the annotation of computational tools with relevant bioinformatics topics, performed operations, as well as type and format of the input and output data. The bio. tools registry uses EDAM for the fine-grained semantic description of tools and their functionality according to a pragmatic model defined in the biotoolsSchema. 55 The annotations facilitate the discovery of individual tools, and the assessment of their (inter) operability such as their combination into workflows.
OntoSoft The OntoSoft ontology  20, 21  has been designed as an ontology for scientific software metadata. OntoSoft allows for the description of software. This includes understanding how to access and update that software, how to execute it, how to use it, and information on who supports the software. The OntoSoft ontology is the basis for the design of the user interface in the OntoSoft portal, the organization of the underlying knowledge base, and the integration with other software repositories. Although OntoSoft is currently focused on earth sciences applications, providing geoscientists in the NSF EarthCube project 61 with an intelligent system to share and reuse code, its principles are equally applicable in other domains. OntoSoft-VFF (Ontology for Software Version, Function and Functionality)  62  extends OntoSoft.
SADI registries SADI (Semantic Automated Discovery and Integration)  64  is a framework for creating Semantic Web Services and a design pattern for the formal description of the service interfaces. Services are described by an ontology that defines I/O class names, predicates and service names with a unique URL. The ontology specifies an explicit relationship (semantic predicate) describing the functionality of a service between the I/O, for example "getDrugNamebyDocument". 65  The service descriptions are collected in a SADI registry. From there, SADI Services can be readily discovered and composed into workflows, as all services consume and generate RDF (syntactic interoperability) and thus the output of one SADI service can be directly consumed by any other SADI service. Through the provisioning of Semantic Web services on top of relational databases for semantic querying, SADI facilitates both data-as-a-service and algorithms-as-a-service.
Scope In the case of bio. tools, the EDAM ontology and the biotoolsSchema provide a technical basis and general direction for the annotation of bioinformatics tools in the registry. However, they leave room for interpretation, calling for clarification. What kinds of tools are in scope, and what exactly should be included in their annotation? Content: The bio. tools Curators Guide  46  defines the scope of relevant tools as "application software with well-defined data processing functions (inputs, outputs and operations)". This clearly includes, for example, command-line tools for sequence alignment, or web services for database searches. For other workflow building blocks this is less clear. On the one hand, workflows often require the inclusion of "shims", 68,69 small formatting or conversion tasks between the actual data processing steps.
They are often not considered tools in their own right, but are indispensable for interoperability. Automated workflow composers as well as human workflow developers would hence benefit from their availability in the registry, and it would prevent a lot of reinvented wheels. While these are strong arguments for the inclusion of shims in bio. tools, there is also a certain risk of fragmentation and overloading the registry with trivial functionality that needs to be managed. On the other hand, workflows can also be considered tools that can be used in (other) workflows. From the perspective of a tools registry it is desirable to include them as "black boxes" providing certain functionality as a service. The inner workings can be visible in a workflow repository like the WorkflowHub, similar to the source code of other computational tools being available in a repository like GitHub.
Currently tool annotation in bio. tools mostly focuses on the annotation of payload input (for pragmatic reasons such as conciseness and limitation of complexity), but for full automated workflow construction information about the parameters to be configured would also be required. • The biotoolsSchema readily distinguishes between the type (kind of content, domain perspective) and the format (representation, technical perspective) of input and output data. For example, an "RNA sequence" is a type, and "FASTA" is one of the possible formats in which it can be represented. This distinction is however not always easy to make. The IUPAC International Chemical Identifier (InChI),  71  for example, is classified as a format in EDAM, but it could also be viewed as a type of data. The domain ontology should have clear criteria for the classification of such formats, and ideally make sure that all formats included are connected to at least one type of data (and vice versa) to enable meaningful tool annotation.
• Composite data formats contain different parts, where a specific tool might only use one or some of them. For example, RetroPath 2. 0 72 works with InChI identifiers that are available from one column of a CSV file. Currently it is not clear how these would be modeled in the ontology and annotated in the registry in the best way. Possible solutions might include a combination of reusing approaches such as the structured metadata for CSV and other tabular data  73  and providing corresponding, ideally automatically generated, shim libraries. Clearly, the domain ontology needs to provide a vocabulary that supports the required annotations and the desired level of granularity. As the needs change, also the ontology has to evolve. EDAM is indeed continually evolving based on input from the bioinformatics and, in particular, the bio.
Incentives The success of registries like bio. tools depends on community contributions, which is predicated upon the motivation of tool users and developers. There are several incentives for potential contributors. For example, for tool developers, rich annotation of their software will increase its findability and comprehension, and thus its potential to be (re-)used individually or within a workflow. This in turn can improve the impact and eventual citations of the software. Improved tooling (intuitive user interface, annotation help, very-well defined metadata schemas) that integrates well with the tool development infrastructure can help to lower the threshold to tool registration and annotation. Registering tools in a community is also in line with recent practice guides like the "Four simple recommendations to encourage best practices in research software"  78  and the "Five Recommendations for FAIR Research Software",  53  which are increasingly attracting the attention of organizations and project-funding agencies.
Workflow INstance Generation and Selection (WINGS) WINGS 6,39,87 is a semantic workflow system that assists scientists with the design of computational experiments. A unique feature of WINGS is its high-level semantic workflow representations that are automatically configured and customized into executable workflow instances. Therefore, WINGS employs workflow reasoning algorithms that use constraint-based planning. The constraints can reference both workflow constituents (steps, data, parameters) and metadata of input datasets, and are used to customize a workflow to a given dataset. For example, a constraint could require that the alignment step and the assembly step in a bioinformatics pipeline are done with the same reference genome. Such constraints capture domain expertise about workflows (as purpose-specific combinations of tools) that goes beyond what the metadata of the individual tools can express.
It includes the available input data (type and format), the desired output data (type and format), and possibly additional constraints (such as tools to use or to avoid). For example, a proteomics workflow might be specified (using EDAM terms) as taking "Mass spectrum" in "Thermo RAW" format as input, producing an "Amino acid index" in any format (see here), and using a "Retention time prediction" operation in the analysis. When applied to bio. tools, APE finds several workflows that meet this specification. The exploration algorithm in APE is a variant of LTL-guided program synthesis, implemented as bounded search through iterative deepening. 90, 91 The domain model (ontology and tool annotations as provided by EDAM and bio. tools) and workflow specification are encoded as a SAT instance (a propositional Boolean formula in conjunctive normal form), and given to a SAT solver to find a satisfying assignment of variables.
Technical Parameters Technical parameters of individual tools and their combinations are relevant to their operation in the context of a composite workflow. These include a whole range of properties, as indicated in Table  1. It is worth noting here that several of these properties (for static analysis at design time of the workflow) are in fact based on prior dynamic analysis of individual tools or other workflows on different levels of abstraction. This underscores the relevance of systematic dynamic analysis of scientific tools and workflows, discussed further below. For use in (automated) workflow composition, we assume the availability of such information in a tool registry like bio. tools, as additional metadata in the tool annotations. Ideally, such metadata would also be collected "by stealth" through the major community platforms, and provided to tool registries in a standard format.
Benchmarking When done systematically, the dynamic analysis of computational tools and workflows is also known as benchmarking. 59 n the scientific workflow development life cycle (Figure  1 ) benchmarking helps to determine which workflow versions or instances will be put into production for large-scale use by third parties. It assumes that the workflows are executable and validated. Generally, benchmarking can be performed with regard to scientific (e. g. analysis quality), technical (e. g. runtime performance, robustness) and usability (e. g. ease of reuse) aspects. Ideally, benchmarking uses publicly available (gold, silver, or artificial/synthetic) reference datasets. Benchmarking can be performed in a single lab (often done for benchmarking on specific aspects) or by a community of researchers (advantageous to avoid bias, often done for common and shared challenges).
Is the topic of the opinion article discussed accurately in the context of the current literature?YesAre all factual statements correct and adequately supported by citations? YesAre arguments sufficiently supported by evidence from the published literature? Yes Are the conclusions drawn balanced and justified on the basis of the presented arguments? Yes Competing Interests: No competing interests were disclosed. Reviewer Expertise: scientific workflows, distributed computing, modeling and simulation of distributed systems, parallel computing I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard. Reviewer Report 19 October 2021 https://doi. org/10. 5256/f1000research. 57615. r94267 © 2021 Alper P.
Acknowledgments In early March 2020, just in time before the Covid-19 pandemic disrupted life as we knew it, 36 researchers from 10 different countries and specializations ranging from biomedicine to computer science met at the  Lorentz Center in Leiden (Netherlands)  for a weeklong workshop on automated composition of workflows in the life sciences. They worked towards a common level of understanding and joint research agenda that is summarized by this paper. We compliment all participants for their valuable contributions during the workshop keynotes, technical talks, breakout discussions and hackathons. In particular, we thank  Jennifer Harrow ,  Rohola Hosseini ,  Rajaram Kaliyaperumal ,  Mateusz Kuzak ,  Melchior du Lac ,  David Lähnemann ,  Miriam Paya Milans  and  Marco Roos  for their input to the discussions and collaborative notes that laid the foundations for this manuscript.
Stian Soiland-Reyes was supported by  BioExcel-2 Centre of Excellence , funded by  European Commission   Horizon 2020 programme  under European Commission contract  H2020-INFRAEDI-02-2018 823830. Carole Goble  was supported by  EOSC-Life , funded by  European Commission   Horizon 2020 programme  under grant agreement  H2020-INFRAEOSC-2018-2 824087. We gratefully acknowledge the financial support from the  Lorentz Center, ELIXIR , and the  Leiden University Medical Center (LUMC)  that made the workshop possible. The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript.
○ Is the topic of the opinion article discussed accurately in the context of the current literature?YesAre all factual statements correct and adequately supported by citations? YesAre arguments sufficiently supported by evidence from the published literature? Yes Are the conclusions drawn balanced and justified on the basis of the presented arguments? Yes Competing Interests: No competing interests were disclosed. Reviewer Expertise: scientific workflows, distributed computing, modeling and simulation of distributed systems, parallel computing I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard. Reviewer Report 19 October 2021 https://doi. org/10. 5256/f1000research. 57615. r94267 © 2021 Alper P.
Proc. First Adv. Knowl. Technol. Workshop Semantic Web Serv. AKT-SWS04 KMi. 2004. Reviewer Report 05 November 2021 https://doi. org/10. 5256/f1000research. 57615. r96797 70. Samtools. Last accessed 2020/09/03. Reference Source 71. Heller SR, McNaught A, Pletnev I, et al. : InChI, the IUPAC International Chemical Identifier. J. Cheminformatics. 2015; 7: 23. Publisher Full Text 72. Duigou T: RetroPath2. 0 -a retrosynthesis workflow with tutorial and example data. Reference Source Open.
All items had five options and were designed and field-tested by DEMRE (Departamento de Evaluación, Medición y Registro Educacional), the Chilean state institution in charge of developing and administering national university admission exams. All participants signed a written informed consent stating that their responses could be used for research purposes. A second data set, obtained from a previous systematic research synthesis  (Authors, 2021, under review) , was also used. Data consisted of 421 items (108 five-option and 313 four-option items) from 13 item sets (four for five-option and nine for four-option items), obtained from 11 studies. Studies were identified during the selection process of the systematic research synthesis and were included because they provided not only answer keys' distribution but also test-takers responses to multiple-choice items for each option position separately, making it possible to identify the different types of distractors.
Test developers might thus be highly interested in the results presented here because they provide, to the best of our knowledge, the first evidence supporting the claim that options are generated in order of plausibility. Future studies might analyze in much more depth the creation process of single items to explore this. Finally, there are some limitations to be mentioned. First, most of the results presented in this article were based on data gathered from five-option items. A large sample of four-option items and three-option items should be analyzed to determine whether (and how) the number of options modulates the distribution bias of distractors. More generally, items with a different set of traits (such as items with ordered numbers as options or with algebraic expressions as options) should be studied to confirm whether this position bias is present in all kinds of multiple-choice items or not.
Open Dream Kit OpenDreamKit is a project that brings together a range of projects and associated software to create and strengthen virtual research environments. The most widely-used research environment is the Jupyter Notebook from which computational research and data processing can be directed. The OpenDreamKit project provides interfaces to well-established research codes and tools so that they can be used seamlessly and combined from within a Jupyter Notebook. OpenDreamKit also supports open source research codes directly by investing into structural improvements and new features to not only connect all of these tools, but also enrich them and make them more sustainable.
Acknowledgement. I thank Krzysztof Burnecki for the kind invitation to write this article. I am indebted to Philippe Moireau, Amina Benaceur, Didier Lucor and Anne Sergent for providing the illustrations displayed in Section 3, and for our exchanges on the corresponding advances. The promotion of Digital Twins also owes thanks to my colleagues from the EU-MATHS-IN Industrial Core Team, with special thanks to Dirk Hartman, Zoltán Horváth, Wil Schilders, Cor van Kruijsdijk and Hubert Tardieu. In this regard, Section 1 presents several collective statements. see  [31] ).
2018. Table  1  -Overview of some industrial accidents for the period 1970 -2018 (Extract from the databases Aria -eMars and Zema). As it stands, it is difficult to reach a conclusion on the effectiveness of the EU Seveso Directives on the incidence of accidents. Indeed, enforced rules compel companies to analyze and consider critically the safety level of their plants and that is an added value of Seveso Directives. The stepwise increase in comprehensiveness of the Directives is due to the evolution in insight of factors of influence, sometimes becoming clear only after a disastrous accident, and further to approaches that promise improvement, such as the safety management system. That despite the improvements still accidents happen is due to a number of factors, such as present methods do not guarantee perfect hazard identification and skip turn-arounds and other abnormal situations.
-Materials and methods In order to meet the objectives of the critical comparison of the implementation of the EU Council Seveso directives in the four countries concerned, official documents available to the public both at European and national level were examined. The Aria, e-Mars and Zema databases made it possible to inventory the main industrial accidents during the period 1970 -2018. The three EU Seveso Directives were consulted in the Official Journals of the European Community (OJEC). The evaluation reports on the practical implementation, compiled from each report required and submitted by the Member States and drawn up by the EU Council during the period 1988 -2017, were studied. The content and quality of these reports showed the gradual improvement of implementation over time. The crucial issue of control and inspection practices of Seveso establishments was first reviewed by examining the specific inspection procedures implemented in each Member State concerned.
Regarding the implementation of the Seveso directive, the federal state is responsible for establishing respectively updating the necessary legal framework, maintaining databases for Seveso establishments and reported major accidents and giving reports to the European Commission. The authorities for the administrative and practical execution of the statutory provisions of the directive (respectively the German Major Accident Ordinance) and the approval procedure for Installations subject to approval are established in the countries. Here usually upper and lower countries' authorities are assigned with the duties of the competent authorities compliant with the Seveso directive (respectively the Major Accident Ordinance). Responsible and authorized for administrative measures and practically conducting the inspections of Seveso establishments are usually the trade supervisory authorities (with specific sections for occupational safety and immission control) or state departments for environment or environmental protection and occupational safety.
TABLES Table  1  -Overview of some industrial accidents for the period 1970 -2018 (Extract from the databases Aria -eMars and Zema). Table  2  -Inventory of the national laws and decrees transposing the EU Seveso regulations. Table  3  -Main competent and implementing authorities responsible for the application of the EU Seveso I -II and III directives. Table  4  -Evolution of the number of upper-tier Seveso establishments  (2005 -2014). Table  5  -Some potential values of the total number of Seveso establishments (year 2004). Table  6  -Brief overview of the LUP practices in 1999 (adapted from  Christou et al. , 1999). Table  7  -Hazard/risk assessment methods used in LUP (reference year 2004) (adapted from  Basta and Struckl, 2004). Table  8  -Territorial categories and Italian urban planning.