dataesr/scientific-paragraphs-categorization huggingface dataset:
• Outcome of the future users and data providers consultation 1. Building of a controlled vocabulary (variables names and categories) 2. Definition of the required metadata: analysis of standards (ISO19115, INSPIRE, DataCite, O&M, etc. ) to define the information flux to be organized between observatories and the central Theia/OZCAR IS 3. Definition of a pivot data model for exchanging the information https://github. com/theia-ozcar-is/data-model-documentation 4. Definition of the architecture of the Information System and building of a prototype web portal What has been done so far for data discovery? https://in-situ. theia-land. fr/skosmos/en/ Global change / Critical zone • Network : 21 long term in situ observatories • Open data • Thematic data pole (continental surface) • 4 Thematic data pole (5?) A common information system : Theia/OZCAR Fundings : INSU, IRD, IR OZCAR, ANR FairTOIS 25 « European Long Term Ecosystem Research » RI on the European road map since 2018.
Importantly, for the purpose of having a reference definition, software that does not generate, process or analyse results -such as word processing software, or the use of a web search -is not considered research software. Research software is also a digital research object, and provenance around software usage plays a key role in the transparency, reproducibility and reusability of scientific activities, spanning from academic to industrial research. Research software includes but is not limited to source code, binaries and web services, and covers a broad spectrum from short scripts written ad hoc by researchers to produce results for a publication, to software rigorously developed for a mission-critical process  [8]. Accordingly, research software can be distributed in many ways such as digital repositories e.
g. , Github, BitBucket, GitLab; or archives like the Software Heritage Project  [9] ; project websites, FTP folders, language specific archive networks e. g. , the Comprehensive R Archive Network (CRAN)  [10] , the Comprehensive Perl Archive Network (CPAN)  [11] , the Python Package Index (PyPI)  [12] , Maven, the Node Package Manager (NPM), and others. Traditionally, research software has been created and maintained as Free and/or Open Source Software (FOSS). However, while there is a clear overlap between the objectives of FAIR and FOSS with regard to accessibility and reusability, they are not the same (see also  [13] ). FOSS is mostly concerned with source code being open and licensed under an open license. Open source and permissive licenses are desirable for FAIR software, but although FAIR has its roots in the "FOSS-loving" research software community, they are not a requirement as such.
Findability Findability is a fundamental principle, since it is necessary to find a resource before any other consideration. The main concern of findability for research software is to ensure software can be identified unambiguously when looking for it using common search strategies. Such strategies include the use of keywords in general-purpose search engines like Google, as well as specialised registries (websites hosting software metadata) and repositories (websites hosting software source code and binaries). Findability can be improved by registering the software in a relevant registry, along with the provision of appropriate metadata, providing contextual information about the software. Registries typically render metadata in a web-findable way and can provide a DOI. Some registries and repositories allow annotating software using domain-agnostic or domain-specific controlled vocabularies, increasing findability via search engines further.
Rephrased Clearly, research software should have their own PIDs. However, it is not enough to assign a PID to a generic software, but rather needed for all their versions and specific deployments. Software versions should get assigned different PIDs as they represent specific developmental stages of the software. This is important as it will contribute to guaranteeing data provenance and reproducible research processes. Indeed, source code management systems make it easier to track software versions. For example, Git, currently the most popular technology for software source code version control, works with commit hashes (SHA1), which uniquely point to the specific snapshot of the source code. However, this identifier is not globally resolvable and GitHub (one of the most popular repositories for software source code based on Git technologies) does not make any guarantees about the accessibility or sustainability of code on the platform (persistence), and thereby the software published therein.
A common community solution to this problem is depositing software releases from GitHub to Zenodo  [24] , an open publishing platform funded by the European Commision, and developed and hosted by Centre Européen Recherche Nucléaire (CERN). Zenodo mints DOIs for each released version of the software, and also creates a concept DOI which refers to all versions of a given software  [25]. To the best of our knowledge, there is no unified mechanism to automatically assign PIDs for research software. Thus, software authors need to actively register their software, and associated versions, at least in one registry or/and repository. We suggest rephrasing this principle as "Software and its associated metadata have a global, unique and persistent identifier for each released version".
Examples include the biotoolsSchema  [26] , a formalised schema (XSD) used by the bio. tools project  [27, 28] ; the CodeMeta set of terms  [29]  and Bioschemas Tool profile  [30]. The latter two work on top of schema. org, a project aiming to make it easier to add structured markup to web pages, and help search engines to index them. Additionally, some programming languages provide a way to add metadata to software sources, i. e. , packages; and often require them to be in a specific format and/or adhere to some guidelines. For instance, R packages must include metadata in the DESCRIPTION file  [31]  while PEP 566 describes metadata for Python software packages. Regardless of the metadata description approach used, the use of controlled vocabularies provided by community-approved ontologies is recommended.
These will vary dependent on the research domain. The Software Ontology  [32]  is a resource that can be used to describe software, including types, tasks, versions, provenance and associated data. In the case of life sciences, we advise to use elements from ontologies such as EMBRACE Data and Methods ontology (EDAM)  [33]. EDAM provides unambiguously defined terms for describing the types of data and data identifiers, data formats, operations and topics commonly used in bioinformatics. In the geosciences, OntoSoft  [34, 35]  is an ontology designed to facilitate the annotation and publication of software with rich metadata. We suggest rephrasing this principle as "Software is described with rich metadata".
F3. Metadata clearly and explicitly include the identifier of the data it describes For reproducibility and reusability purposes, any person and/or system examining the metadata needs to be able to identify which version of the software is described by it. F3 extends F1's focus regarding the precise identification of versions and/or reference deployments beyond the software itself by including the metadata associated with each version and/or reference deployment of the software. This enables the exact version of a given software to be found when reusing and/or reproducing previously generated scientific results. For example, release metadata files on Zenodo should point to specific releases on software source code repositories such as GitHub, BitBucket or GitLab. We suggest rephrasing and extending this principle as "Metadata clearly and explicitly include identifiers for all the versions of the software it describes".
F4. (Meta)data are registered or indexed in a searchable resource Software and associated metadata should be registered in a suitable, searchable software registry or repository. There are chiefly three classes of registries and repositories: (i) general ones such as Zenodo, GitHub itself, and comprehensive software archives as run by the Software Heritage project  [36] , (ii) language-specific ones such as CRAN, PyPI, and (iii) domain-specific ones such as the bioinformatics-specific BioConductor  [37] , bio. tools and BioContainers  [38]  registries, the Astrophysics Source Code Library (ASCL)  [39] , swMath  [40]  for mathematical software, CLARIN  [41]  for digital humanities software source code and the different science gateways based on the HUBzero  [42]  open source software platform.
The choice of the registry/repository may be influenced by the programming language used and/or the operating system most used by the respective community. For example, most of the Python packages are registered in PyPI and/or one of the Conda  [43]  channels. R packages go to CRAN, Bioconductor. org and/or source code repositories like GitHub. Linux distributions have their own package managers with software repositories. We suggest rephrasing this principle as "Software and associated metadata are included in a searchable software registry".
Accessibility In the original FAIR Guiding Principles, accessibility translates into retrievability through a standardized communication protocol (A1) and accessibility of metadata even when the original resource is no longer accessible (A2). These principles clearly also apply to software. Interpreting accessibility also as the ability to actually use the software (access its functionality), however, we found mere retrievability not enough. In order for anyone to use any research software, a working version of the software needs to be available. This is different from just archiving source code, even in comprehensive and long-term collections like the Software Heritage archive. To use software, a working version (binary or code) has to be either downloadable and/or accessible e. g. , via a web interface, along with the required documentation and licensing information.
Accessibility requirements depend on the software type, e. g. , web-applications, command-line tools, etc. For example, software containers allow the use across different operating systems and environments, e. g. , local computers, remote servers, and high-performance computing (HPC) installations. Cloud-based servers can execute existing pieces of code as a service, as software made available through a web interface or via Jupyter Notebooks  [44]. Notebooks allow others to see the results and the narrative alongside the code used to generate them. Furthermore, even for software that can be downloaded or accessed without restrictions, being able to run it might also depend on, for example, data samples, (paid) registration, other (proprietary) software packages, or a non-free operating system like Windows or macOS.
A1. 1. The protocol is open, free, and universally implementable. Usually software (and its metadata) can be downloaded directly from the repository and/or website via standard protocols (HTTP/SSH). There is no need to rephrase this specific item as it generally applies to any digital resource exposed via the web, and thus to both data and software. A1. 2. The protocol allows for an authentication and authorization procedure, where necessary. Authentication and authorization are relevant for accessing research software source code (open and closed source), binaries and/or web applications. Collaborative development platforms like GitHub and Bit-Bucket implement mechanisms to support authentication and authorisation, and control the access to the code base. Similarly, it might be possible that users might need to register, and/or authenticate, before downloading binaries or, in the case of web applications, using the software.
A2. Metadata are accessible, even when the data are no longer available Metadata provides the context for understanding research software, and this should persist even when the software itself is no longer available. To achieve this, metadata should be available separately from research software objects, here understood as either the source code, binaries and/or web servers hosting the deployed software. For example, GitHub can host the software source code and can be connected to Zendo, FigShare, bio. tools or FAIRsharing. org [45]  for hosting additional copies of the research software metadata. Zenodo promises metadata, and a snapshot of the software release, to be available for the upcoming 20 years, even when the versioned source code on GitHub may not be accessible any more. Metadata should follow community agreements.
Interoperability The IEEE Standard Glossary of Software Engineering Terminology  [46]  defines interoperability as the "ability of two or more systems or components to exchange information and to use the information that has been exchanged". This definition is further complemented by semantic interoperability, ensuring "that these exchanges make sense -that the requester and the provider have a common understanding of the 'meanings' of the requested services and data. " [47]. When examining the FAIR data principles from a research software perspective, interoperability turns out to be the most challenging among the four high-level principles. This is not surprising given the complexity of the software interoperability challenges that form a research area of its own  [48] [49] [50] [51] [52].
I2. (Meta)data use vocabularies that follow the FAIR principles Following on from the previous interoperability principle, and considering the differences between data and software, we consider two different cases here: the software itself and the data that it operates on (i. e. inputs and outputs). In both cases, ontologies and controlled vocabularies that are themselves FAIR should be used for the formal description. FAIR software should operate on FAIR data, and not undermine the principles by, e. g. , producing outputs only in proprietary data formats. Without using FAIR vocabularies, it might become impossible to understand, for both machines and humans, what is described (software) and/or to what it refers (software metadata). Whenever possible, those descriptions should be generated, agreed and maintained by communities as a mechanism towards the sustainability of such resources, keeping metadata understandable even if the resources disappear for unforeseen reasons.
A registry of the available controlled vocabularies, data types, formats and schemas that may be used by the software can be found at FAIRsharing. org. Thus, we propose to reinterpret and extend I2 by splitting it into two sub-principles to account for such differences: • I2S. 1 "Software and its associated metadata are formally described using controlled vocabularies that follow the FAIR principles". • I2S. 2 "Software use and produce data in types and formats that are formally described using controlled vocabularies that follow the FAIR principles".
Reusability Reusability in the context of software has many dimensions. At its core, reusability aims for someone to be able to re-use software reproducibly as described by Benureau and Rougier 2018  [61]. The context of this usage can vary and should cover different scenarios: (i) reproducing the same outputs reported by the research supported by the software, (ii) (re)using the code with data other than the test one provided to obtain compatible outputs, (iii) (re)using the software for additional cases other than those stated as supported, or (iv) extending the software in order to add to its functionality. Software reusability depends to a high degree on software maintainability (see also Section Software quality: beyond FAIR), including proper documentation at various levels of detail.
Conclusions Software has become an essential constituent of scientific research. It is therefore desirable to apply the FAIR Guiding Principles, which have so far mostly been interpreted as principles for scientific data management and stewardship, also to research software. As we have discussed in this work, many of the FAIR principles can be directly applied to research software, where software and data can be treated as the same kind of digital research objects. However, when specific characteristics of software are in-volved, such as their executability, composite nature, and continuous evolution accompanied by frequent versioning, it is necessary to revise and extend the original principles. Furthermore, it can be argued that considerations about the functionality of software (as opposed to the form in which it is provided) are by definition out of the scope of FAIR, and thus need to be addressed by other guiding principles, for example based on best practices for (research) software development  [17].
This work aims to become the starting point for further community-led discussions and proposals on how to effectively apply FAIR principles to research software, and eventually the development of specific FAIR principles for research software. In addition to the work on the principles, the development of community-specific metadata schemes for software has to play an important role, as defined metadata standards are key to the successful application of many of the principles. There are groups within the wider research software community beginning to address these issues. For example, recently the Software Source Code Identification Working Group  [69]  has been initiated in the scope of the Research Data Alliance (RDA) and FORCE11 to produce an initial collection of software identification use cases and corresponding schemas as well as to give an overview of the different contexts in which software artifact identification is relevant.
Acknowledgements We are grateful to the numerous people who contributed to the discussions around FAIR research software at different occasions preceding the work on this paper. Making no claims to completeness, these include  Peter Doorn ,  Michel Dumontier ,  Chris Erdmann ,  José María Fernández ,  Rafael C. Jimenez ,  Katrin Leinweber ,  Jason Maassen ,  Mustapha Mokrane ,  Jurriaan Spaaks ,  Mark Wilkinson  and  Amrapali Zaveri. We also thank the  Japan BioHackathon  for sponsoring a FAIR software related project for the 2018 edition. Furthermore, we would like to thank  Stian Soiland-Reyes  for his valuable comments on earlier versions of this manuscript. NCH and CAG were supported by  EP/N006410/1  and  EP/S021779/1  for the  UK Software Sustainability Institute. AV, JLG, SCG and CAG were supported by  ELIXIR-EXCELERATE 676559.
In the data analysis, we computed a hunger index score by pooling subjects' separate sub-scores. The die task was administered at the end of a larger experimental session investigating subjects' risk attitudes under different energy levels. Subjects were randomly assigned to two different conditions that were run in separate sessions. Participants in the "Sated" condition (N tot = 75, 57% lean, 61% females) were provided with a standardized breakfast of about 600 cal, consisting of orange juice, detheinated tea, decaffeinated coffee and butter croissants. They also received a choice of magazines (leisure, sport, travelling, fashion, etc. ) during waiting time. Blood glucose and hunger levels were measured again thirty minutes after meal provision (time 2). Then subjects returned to their cubicle, completed their other tasks; they played the die game approximately an hour after receiving their meal.
Acknowledgements We thank  L. Charroin  for research assistance in the recruitment of participants and during the conduct of the experiments, together with  J. Bénistant ,  C. Gresset ,  T. Garcia ,  C. Rimbaud ,  C. Saucet ,  A. Solda ,  R. Suchon ,  V. Theroude  and Q. Thénevet. We thank  E. Addessi  and  J. Fooken  for helpful discussions on the experimental setup and  A. Lombardo  for developing the experimental platform. This research was supported by funding from the  European Commission  and by the  LABEX CORTEX  ( ANR-11-LABX-0042 ) of  Université de Lyon , within the  program Investissements d' Avenir  ( ANR-11-IDEX-007 ) operated by the  French National Research Agency (ANR).
, Ω meso exp,Q for which the relative mutual locations into the test specimen are not necessarily recorded. The experimental database is then constituted of the vector-valued experimental displacement fields u macro exp and u meso exp,1 ,. , u meso exp,Q , respectively, at macroscale on Ω macro exp and at mesoscale on Ω meso exp,1 ,. , Ω meso exp,Q. The experimental tensor-valued strain fields ε macro exp and ε meso exp,1 ,. , ε meso exp,Q , respectively associated to the experimental displacement fields u macro exp and u meso exp,1 ,. , u meso exp,Q , can be calculated by post-processing through interpolation techniques.
Probabilistic Model for a Robust Identification of the Hyperparameters When several non-overlapping mesoscopic domains of observation Ω meso exp,1 ,. , Ω meso exp,Q are available for experimental measurements for the same test specimen instead of a unique observation domain Ω meso exp , then the solution of the multi-objective optimization problem presented in Section 7 can yield different optimal values b meso 1 ,. , b meso Q of hyperparameter b meso when experimental data comes from one mesoscopic domain of observation to another since mesoscopic indicators J meso δ (b) and J meso (b) depend on the values of experimental displacement fields u meso exp,1 ,. , u meso exp,Q that are measured on each of them. Consequently, the optimal value b meso of hyperparameter b should be considered as uncertain and should be modeled as a vector-valued random variable B = (D, L, H) for which b meso 1 ,.
Resolution of the Single-Objective Optimization Problem at Macroscale In this paragraph, we present the results of the first single-objective optimization problem (21) at macroscale which consists in minimizing the macroscopic numerical indicator J macro (a) constructed in the macroscopic domain of observation Ω macro exp for identifying the optimal value a macro of a at macroscale. The single-objective optimization problem (21) at macroscale has been solved using the Nelder-Mead simplex algorithm. The identification results are reported in Table  1  and show that the relative error between the identified optimal value a macro = (13. 901, 3. 685) in [GPa] and the reference experimental value a macro exp = (14. 328, 3. 670) in [GPa] used for the construction of the numerically simulated "experimental" database remains small (less than 3% and 0.
717 GPa but to a gamma distribution with a very small dispersion around this value, since for the prior probabilistic model of H = (K, M) considered here, K and M cannot be deterministic variables (see  Section 9). We finally obtain the global optimal value b opt = (0. 391, 135. 328, 12. 273, 3. 717) in ([-], [µm], [GPa], [GPa]) with relative errors less than 3%, 9%, 11% and 4% for δ opt , opt , κ opt and µ opt , respectively, with respect to the reference experimental value b meso exp = (0. 40, 125, 13. 75, 3. 587) in ([-], [µm], [GPa], [GPa]) used to construct the numerically simulated "experimental" database, allowing to validate the proposed identification methodology in 2D plane stress linear elasticity for the resolution of the multi-objective optimization problem (  22 ) at mesoscale.
Resolution of the Single-Objective Optimization Problem at Macroscale In this paragraph, we present the results of the first single-objective optimization problem (21) at macroscale which consists in minimizing the macroscopic numerical indicator J macro (a) constructed in each of the Q = 3 in silico test specimens for identifying the optimal value a macro of a at macroscale. The single-objective optimization problem  (21)  at macroscale has been solved using the Nelder-Mead simplex algorithm. The identification results are reported in Table  5  and show that the relative error between the identified optimal value a macro = (138. 783, 64. 355) in [GPa] and the reference experimental value a macro exp = (138. 758, 64. 377) in [GPa] used for the construction of the numerically simulated "experimental" database remains very small (less than 0.