dataesr/scientific-paragraphs-categorization huggingface dataset:
Levels of description Another dimension that adds to the complexity is the variety of levels at which a software project can be described, either for citation or for reference. Exact status of the source code. For the purpose of exact reproducibility, one must be able to reference any precise point in the development history of a software project, even if it is not labeled as a release; in this case, cryptographic identifiers like those used in distributed version control systems, and now generalized in Software Heritage  [9] , are necessary. For instance, the sentence "you can find at swh:1:cnt:cdf19c4487c43c76f3612557d4dc61f9131790a4; lines=146-187 of swh:1:snp:c9c31ee9a3c631472cc881788 6aaa0d3784a3782;origin=https://github. com/rdicosmo/ parmap/ the exact core mapping algorithm used in this article" makes two distinct references.
The former one points to the lines of a source file while the later one points to the software context in which this file is used. (Major) release. When a much coarser granularity is sufficient, one can designate a particular (major) release of the project. For instance: "This functionality is available in OCaml version 4" or "from CGAL version 3". Project. Sometimes one needs to cite a software project at the highest level; a typical example is a researcher, a team or an institution reporting the software projects it develops or contributes to. In this case, one must list only the project as a whole, and not all its different versions. For instance: "Inria has created OCaml and Scikit-Learn".
Coding. This seems the most obvious part, but it is actually complex, as one cannot just count the number of lines of codes written, or the number of accepted pull requests. Sometimes a long code fragment may be a straightforward reimplementation of a very well known algorithm or data structure, involving no complexity or creativity at all, while at other times a few lines of code can embody a complex and revolutionary approach (e. g. , speeding up massively the execution time). Often, a major contribution to a project is not adding code, but fixing code or removing portions of code by factoring the project and increasing its modularity and genericity. Testing and debugging. This is an essential role when developing software that is meant to be used more than once. This activity may require setting up a large database of relevant use cases and devising a rigorous testing protocol (e.
Real dependencies Fake OS dependencies induced by package granularity Fig. 1. Example of the complexity in direct and indirect dependencies for a specific python package (matplotlib). Boxes represent actual packages (libraries that need to be installed on the system), arrows indicates dependencies to other packages, labels indicates the minimal/maximal version number. In blue the Python dependencies, in red the "true" system dependencies incurred by python (e. g. , the libc or libjpeg62), in green some "fake" dependencies incurred by the package management system but which are very likely not used by python (e. g. , adduser or dpkg). nal technical documentation to drafting the user manual and tutorials. The older and bigger the software, the more difficult this authorship identification task is.
To simplify the collection of the information concerning the software projects, an internal database, called BIL ("Base d'Information des Logiciels", i. e. "database of information on software"), has been in use for several years. It allows research teams to deposit very detailed meta-data describing the software projects they are involved in. The BIL can then be used to generate automatically the list of software descriptions for the team web page, for the activity report, and also to prefill part of the forms used in the two processes described above for individual career evaluation and for technology transfer, avoiding the burden of typing in the same information over and over again.
Reproducible builds. In the early 2000's, the ground-breaking notion of functional package manager was introduced by the Nix system  [10] , using cryptographic hashes to ensure that binaries are rebuilt and executed in the exact same software environment. Similar notions provide the foundation of the Guix toolchain, which has been developed over the last decade under the umbrella of the GNU project, with key contributions from Inria  [8]. The essential property of these tools is that, given the same source files and the associated functional build recipes, one can obtain as a result of the build process the very same binary files in the same environment. Very recently, Guix has been connected with SWH to ensure long term reproducibility: when the source code (currently downloaded from the upstream distribution sites) disappears from the designated location, Guix uses transparently the SWH intrinsic identifiers to fetch the archived copy from its archive.
Functional build recipes are themselves a form of source code, and they too can be archived and given intrinsic identifiers, which will provide proper references also for software environments. Curation of software deposit in HAL for SWH. Over the past two years, Inria has fostered a collaboration between SWH and HAL, the French national open access archive, with the goal of providing an efficient process of research software deposit. Figure  2  provides a high level overview of this process: researchers submit software source code and meta-data to the HAL portal; these submissions are placed in a moderation loop where humans interact with the researchers to improve the quality of the meta-data and to avoid duplicates; once a submission is approved, it is sent to SWH via a generic deposit mechanism, based on the SWORD standard archive exchange protocol; it is then ingested in the SWH archive; finally, the unique intrinsic identifier needed for reproducibility is returned to the HAL portal, which displays it alongside the identifier for the meta-data.
A. Taxonomy of contributor roles: a proposal The need to recognise different levels and forms of contributions is not new in academia: in Computer Science and Mathematics we are quite used to separate, for example, the persons that are named as authors, and those that are only mentioned in the acknowledgements. In the specific case of software projects, the Software Credit Ontology https://dagstuhleas. github. io/ SoftwareCreditRoles/doc/index-en. html proposes a total of 23 roles, among which 13 are directly concerned with an actual contribution to a software project, under the contributor category: code reviewer; community contributor; designer; developer; documenter; idea contributor; infrastructure supporter; issue reporter; marketing and sales; model driven software engineering expert; packager; requirement elicitator; systems and network engineer.
There are indeed a wealth of different developer scoring algorithms that target GitHub contributors (see for example http://git-awards. com/, https://github. com/msparks/git-score and GitHub's own scoring using the number of commits, deletions, or additions). Unfortunately these measures are far from robust: refactoring (that may be just renaming or moving file around or even changing tabs in spaces!) can lead to huge score increases, while the actual developer contribution is marginal. And even if one could rule out irrelevant code changes, our experience at Inria is that the importance and quality of a contribution cannot be assessed by counting the number of lines of code that have been added (see our description of the coding role in Section IV-B). This is particularly the case for research software that involves significant innovations.
Recommendation #2: Putting human at the heart of the evaluation As a bottomline, we strongly suggest to refrain, for research software, from trying to generate software citation and credit metadata, and in particular the list of (main) authors, using automated tools: we need instead quality information in the scholarly world, and currently this can only be achieved with qualified human intervention. We strongly encourage the authors of research software to provide such qualitative information, for example in an AUTHORS file, and to use the aforementioned taxonomy and scale. As an illustration of this recommendation, the rich metadata collected by HAL in the deposit process are sent to SWH using the now standard CodeMeta schema  [16] , and will be soon extended with the taxonomy of Section V-A.
Recommendations Based on our experience over several decades, we have distilled the important lessons learned and are happy to provide a set of recommendations that can be summarized as follows: Recognise the diversity of contributor roles The taxonomy of contributors described in Section V-A has been extensively tested internally at Inria. We recommend that it be incorporated in the CodeMeta standard, and all the platforms and tools that support software attribution and citation. In the meanwhile, researchers can adopt it right away in the metadata they incorporate in their own source code.
Keep the human in the loop To obtain quality metadata, as seen in Section V-B, it is essential to have humans in the loop. We strongly advise against the unsupervised use of automated tools to create such metadata. While these automated tools can save a lot of time, we recommend instead the implementation of a metadata curation and moderation mechanism in all tools and platforms that are involved in the creation of metadata for research software, like Zenodo or FigShare. We also recommend that research institutions and academia in general rely on human experts to assess the qualitative contributions of research software, and refrain from adopting as evaluation criteria automated metrics that are easily biased.
Motivation: The molecular changes induced by perturbations such as drugs and ligands are highly informative of the intracellular wiring. Our capacity to generate large data-sets is increasing steadily as new experimental approaches are developed. A useful way to extract mechanistic insight from the data is by integrating them with a prior knowledge network of signalling to obtain dynamic models. Logic models scale better with network size than alternative kinetic models, while keeping the interpretation of the model simple, making them particularly suitable for large datasets.
Results: CellNOpt is a collection of Bioconductor R packages for building logic models from perturbation data and prior knowledge of signalling networks. We have recently developed new components and refined the existing ones. These updates include (i) an Integer Linear Programming (ILP) formulation which guarantees efficient optimisation for Boolean models, (ii) a probabilistic logic implementation for semi-quantitative datasets and (iii) the integration of MaBoSS, a stochastic Boolean simulator. Furthermore, we introduce Dynamic-Feeder, a tool to identify missing links not present in the prior knowledge. We have also implemented systematic post-hoc analyses to highlight the key components and parameters of our models. Finally, we provide an R-Shiny tool to run CellNOpt interactively.
CNORprob To optimise logic networks with semi-quantitative states (between 0 and 1) at quasi-steady-state, we offer the new CNORprob package. CNORprob is an R-implementation of the Matlab-based toolbox FALCON for probabilistic Boolean logic  (Landtsheer et al. , 2017). Compared to the CNORfuzzy packages which is based on fuzzy logic  (Terfve et al. 2012)  , CNORprob offers a simpler interpretation as this framework contains only one parameter per edge that has an equivalent probabilistic meaning (Text  S3 ).
Dynamic-Feeder Our knowledge of pathways is incomplete. Dynamic-Feeder is a method to identify missing links in the PKN and provides candidates to fill such gaps (Fig. S3 ). It combines data-driven network inference with a protein-protein interaction network to find missing elements. For the latter, we use primarily OmniPath  (Türei et al. 2016 ) , an integrated resource of curated pathways' databases. Dynamic-Feeder generalizes our previous tool CNORfeeder  (Eduati et al. 2012 ) to time-course data with a logic ordinary differential equations (ODE) formalism (Text S4).
Acknowledgements The work was supported by the  European Union 's  H2020 program  ( 675585   Marie-Curie ITN ''SymBioSys '');  JRC for Computational Biomedicine , which is partially funded by  Bayer ; and the  Innovative Medicines Initiative 2 Joint Undertaking  under grant agreement no. 116030  (TransQST). We thank  Christian Holland  for his assistance on setting up the ShinyCNOR tool online and  Nicolas Palacio Escat  for his help in designing Fig. 1.
Commissioning To confirm that AlignRT InBore™ system does not affect beam delivery, the widest possible treatment field (28 cm wide in the longitudinal plane) was delivered with/without the ring in place. Dose distributions were acquired with the EPID and analysed using Varian's Portal Dosimetry software v. 15. 6 (Varian, Paolo Alto, USA). Additionally, patient QA dosimetry checks were performed with/ without AlignRT InBore™ and using ArcCHECK® and SNC Patient™ v. 8. 3 (Sun Nuclear, Melbourne, USA) for a total of 11 randomly selected patients simulating breast (2 IMRT and 3 VMAT), H&N (2 VMAT) and pelvis (4 VMAT) treatment sites. A local dose distribution analysis was performed to compare acquisitions with/without the InBore™ system with 0. 1% and 0. 5% dose difference criteria with 5% threshold since ArcCHECK® and SNC patient v.
, Salem NY, USA). ARTISCAN QA software v4. 16 (AQUILAB, Loos, France) was used to determine contrast, resolution and noise in the set of images acquired with/without AlignRT InBore™. Default acquisition parameters for all available kV-CBCT protocols were considered simulating head, breast, thorax and pelvis localisations as well as low and high definition MV-CBCT. MV image quality with/without AlignRT InBore™ was also verified using the EPID QC phantom (PTW, Freiburg, Germany) and ARTISCAN QA software v4. 16. Statistical analysis was also performed using Wilcoxon nonparametric tests to investigate any significant difference on dose delivery and image quality with/without AlignRT InBore™. Finally, the sensitivity of the two anti-collision sensors installed at the rear of the Halcyon™ was also checked with/without the ring in place with a NK-500 force gauge (Zhejiang Beilong Tool Co.
Camera performance Accuracy of the InBore™ system proved to remain within 0. 1 mm when tested using the MV Cube and with known applied shifts ranging from 1 mm to 1 cm in all translational directions. Stability of the system when continuously monitoring the MV Cube for ~30 min also showed limited variability of the RTDs in time (sub-0. 3 mm and 0. 2 • ) with no visible thermal drift (cf. Fig. 4 ). Additionally, with the current AlignRT software version (v. 5. 1) the new InBore™ cameras proved to have similar performance compared to the standard ceiling-mounted cameras with a frame rate of 3-5 fps and a surface resolution of 10 pixels/vertex for breast anatomical site.
By solving the equations above simultaneously, we can obtain the MLE Θ of Θ, with components providing the MLEs λ, γ, θ of λ, γ, θ respectively. Various numerical iterative techniques can be used for estimating these parameters. In this study, we consider the iterative algorithm inherent to the NMaximize command in the symbolic computational package Mathematica. Under some regularity conditions, the asymptotic normality of the MLEs is guaranteed; the asymptotic distribution of ( Θ -Θ) is N 3 (0 3 , I(Θ) -1 ), where I(Θ) = E(J(Θ)) denotes the expectation of the information matrix: J(Θ) = {J rs (Θ)}, (r, s) ∈ {λ, γ, θ}. Thus confidence intervals or Wald test can be constructed for the parameters.
Agroecological studies on sugarcane dealing with genotype, by environment and by management interactions commonly generate complex datasets. To facilitate the use of these datasets, a relational database, named ECOFI, was designed from the analysis of the content and the structure datasets of multidisciplinary experiments with sugarcane and energy cane. The database described in this paper includes data from 58 trials carried out in 11 countries from 1986 to 2016, including 24 trials in Reunion Islands and 15 in Guadeloupe. Taking into account plots within the trials and crop cycle, it includes 725 crop cycles in total, with 60 different cultivars. The datasets contain data for crop observations (e. g. dry mass), soil (water contents), weather (all essential meteorological parameters) and management (sowing, cultivars and harvest).
BACKGROUND AND ORIGINAL PURPOSE: This article presents the result of a collaborative effort by a multidisciplinary team of computer scientists, biostatisticians, agronomists, weed experts and crop modelers who have been confronted with data and metadata management issues in agroecological research on sugarcane. Relational databases are widely used in agriculture to manage field experimental data as well as pest and weed management information  (Bechini and Stöckle 2007). The ECOFI database (experimental database on ecophysiological and environmental observations) has been developed  (Auzoux et al. , 2017)  to solve the problem of security and persistent storage of data, to standardize the annotation of heterogeneous data, to improve analysis and facilitate access to data for sugarcane modelling in Reunion and in other sugar-producing countries in Africa and Central America.
EXPERIMENTAL DATA 3. 1 EXPERIMENTAL SITE: The ECOFI database describes 63 trials carried out in 11 countries: Reunion Island (28), Guadeloupe (15), Brazil (4), Morocco (3), Australia (2), Zimbabwe (2), USA (2), South Africa (2), Ecuador (1), Senegal (1) and Mauritius (1). Each trial is associated with a localized site (latitude, longitude and altitude), country and project. The different treatments of each trial are defined in the "Plot" table and the crop cycle is defined in "Plotcycle" in case of multiple-year and multiple-variety trials.
WEATHER AND SOIL DATA: Weather and soil data are described in each site. The weather data are given at a daily time step or averaged every 10 days. Available meteorological data are: minimum, mean and maximum temperature; minimum, mean and maximum relative humidity; total and maximum wind speed; global radiation; potential evapotranspiration (Penman-Monteith); rainfall. In some case, some meteorological data are missing when not measured (in particular for relative humidity). The database made it possible to associate two set of rainfall data for a specific site (one in "Wdat" and the other in "Raindat"). The variable units are described in "Tables". Soil data are described in "Genesoil" and "Soillayer" (defining multiplied soil layers) and limited to variables used for the soil water balance assessment: soil water capacity, field capacity, wilting point, saturation, bulk density.
MANAGEMENT DATA: Management information of each trial is detailed in "Plot" (planted area of each plot, number of buds and row spacing), "Plotcycle" (crop cycle: plant or ratoon crops, irrigation management) and "Varcycle" (planted variety, starting and ending dates of the cycle). If not rainfed, the irrigation management are detailed in "Irrdata" and "Irrigation" where daily water amount at specific dates is indicated as well as the efficiency of the irrigation (taking into account water loss). In case the irricode is "NC", it means that the crop is irrigated but that the irrigation amount and frequency is not available. Two types of irrigation were used in the different trials (sprinkler or drip irrigation). In total, 60 different varieties were used in the different trials (41 sugarcane and 19 energy cane).
PLANT AND SOIL OBSERVATION: The ECOFI database provides measurements in the different trials at various levels: plot (e. g. soil water content and aboveground dry matter), plant (e. g. aboveground fresh matter per plant), stem (e. g. stem sugar content), leaf (e. g. fresh matter of leaves) or limb level (e. g. width of leaf blades). All measured plant, soil and weather variables are described in the "Variables" table with their respective unit, type and description.
ADDING NEW DATA: In the event that users would like to add observations, the new trial must be created in "Trial" with its location in the table "Site". The elementary plots within the trial are described in "plot" with potentially different planting densities and row spacing. Finally, "Plotcycle" and "Varcycle" describe the cane cycle and the variety planted. Observations can then be added to "Obsplant" and "Obssoil" after having specifying the new definitions in the metadata table "Variables", if required. The observed variables are standardized as much as possible using terminology from controlled vocabulary in order to make the data interoperable. If the information is available, the user can also associate soil and climate data with the new dataset.
DATA APPLICATION: The ECOFI database present various uses for meta-analyze and cropping system models: data exploration, data management and model calibrations. A strong point of the database in data mining is the large number of varieties included. In Figure  2  we present an example with the growth differences in dry mass between varieties obtained from the database. ECOFI could be used to further explore the effects of the interaction between climate and variety, or with management (irrigation, row spacing. ). The database has thus been used in the context of projects on sugarcane (e. g. AGMIP) or energy cane (e. g. SYPECAR). Figure  2. Growth rates in aerial dry matter (T ha -1 d -1 ) depending on the cane variety. Growth rate was calculated from the database as the aerial dry matter divided by the number of days since the beginning of the crop cycle.
Data are presented using a beanplot with median (black line), normal density (gray background) and populations (small black lines). The horizontal dashed line indicated the overall median. The number of plot cycle available for each variety with aerial dry matter is indicated. In addition, the main utility of the ECOFI database is the linked with crop models. Many operations are required to extract experimental datasets and create input files for cropping system models. Data manipulation is tedious and difficult to automate for modeling. Through simple queries, ECOFI allows the automatic creation of input files for crop models. ECOFI directly provides simulations input for the sugarcane growth model MOSICAS  (Martiné et al. , 2007). In particular it is very useful for the calibration of new varieties and has been used to calibrate energy  (Martiné et al.
ACKNOWLEDGMENTS All the partners and main contributors of the different trials present in the database are described in the "Project" table. We would like to acknowledge the project partners (in particular  South African Research Institute, Mauritius Sugarcane Industry Research Institute and eRcane institute ) as well as the PhD students who have made it possible to collect and share experimental data (in particular  C. Suguitani ,  M. Aabad ,  D. Sabatier ,  M. Gouy ).
Protocol Prior to commencing the search, a detailed protocol was agreed to determine the databases to be searched, search modalities, eligibility criteria and all methodological details. Several virtual meetings between the authors were organized and a dedicated online archive was created to share the data of the reviewed manuscripts. Preferred Reporting Items for Systematic Reviews and Meta-Analyses (PRISMA) guidelines were followed throughout the project. 10 The French Ethical Committee for the Research in Obstetrics and Gynecology reviewed the work and con rmed that the institutional review board approval was unnecessary. The case study was performed in agreement with principles of the Declaration of Helsinki and all analyzed data were anonymous and respecting to local and European privacy regulations.