dataesr/scientific-paragraphs-categorization huggingface dataset:
Multispectral imaging and quantitative evaluation Fluorescent whole slide image scanning was performed at 20x magnification using the PhenoImager HT instrument (Akoya Biosciences). Whole slide images were used to select fields of view (FOV) that cover all tumor areas excluding necrosis and artifacts (i. e. tissue folding, disruption, hemorrhages etc. ) for subsequent targeted scanning of image stacks at 40x magnification across the visible spectrum (440-780 nm). For each tumor, 19-151 FOV were scanned. Spectral libraries were generated using single-stained scans of tonsil tissue for each reagent, and multispectral color deconvolution was performed with the inForm image analysis software (inForm v2. 6, Akoya Biosciences). Quantitative evaluation of CD3, CD4, CD8, CD68, and PD-1 expression in immune cells was performed on a total of 1122 FOV using an automated analysis algorithm (inForm) and R packages phenoptr (R package version 0.
3. 2, https://akoyabio. github. io/phenoptr/) and phenoptrReports (https://github. com/ akoyabio/phenoptrReports/). Visual quality control of all analyzed FOV was performed by reviewing all composite images in the context of the quantitative output. GFAP and CD34 were used to provide orientation and biological context. PD-L1 was assessed semiquantitatively by visual inspection and grading into positive (> 30% stained tumor cells) and negative tumors.
Multicolor fluorescence in situ hybridization (FISH) analysis To determine the karyotype of LN-229 glioblastoma cells, 24-color FISH  [14]  was performed on metaphase chromosome preparations using the 24XCyte Human Multicolor FISH Probe Kit (MetaSystems, Altlussheim, Germany), which contains probes for all human chromosomes labeled with specific fluorochrome combinations, according to the manufacturer's protocol. Fluorescent images were captured with a Leica DCX epifluorescence microscope (Leica Microsystems) coupled to a chargecoupled device camera (Teledyne Photometrics, Tucson, AZ, U. S. A. ) and equipped with appropriate filter sets to allow specific detection of each fluorochrome used. Multicolor FISH data were processed using the Leica CW4000 software (Leica Microsystems).
5% (m/v) crystal violet (Sigma-Aldrich, St. Louis, MO, USA) for 30 min. Subsequently, culture plates were carefully immersed in water to remove the fixation and staining mixture, and dried overnight at room temperature before staining was documented. For quantification of the crystal violet staining intensity, grayscale images acquired using the Fusion FX7 gel documentation system (Vilber) were analyzed using Fiji/ ImageJ software (version 1. 52n, https://imagej. nih. gov/ ij/).
Taken together, seven different rare POLE and two different rare POLD1 variants, heterozygous and predicted to be deleterious, were detected in WES datasets of leukocyte DNA of a total of 11 glioma patients from 10 of 61 (16%) tumor families, including the glioma patients from family Fam011 (Fig. 1a-j , Additional file 2: Fig. S1 , Table  1 ). The CADD score of all variants was ≥ 20, indicating that they are considered to be among the top 1% most deleterious variants in the human genome (Table  1 ). All variants were previously described in the germline of patients with colorectal cancer, breast cancer, ovarian cancer, endometrial cancer, cervical cancer, melanoma or other tumors (Table  1 ). Three POLE variants affected amino acids located within known functional protein domains of POLE, two within the exonuclease domain, i.
(b) Graph showing the COSMIC database SBS signatures of somatic mutations of 14 gliomas from 10 patients with rare POLE/POLD1 germline variants, highlighting the contribution of POLE/POLD1 pathogenic variant and POLD1 pathogenic variant and MMR deficiency-associated signatures SBS10 and SBS20, MMR deficiency-associated signatures SBS6, SBS15, SBS21, and SBS26, and temozolomide treatment-associated signature SBS11. (c) Hematoxylin and eosin stained sections of four gliomas from patients with rare POLE germline variants showing enlarged nuclei (WI70-III. 1 and WI207-III. 1) or multinucleated cells (WI127-III. 2 and WI104-III. 1). Scale bar, 60 μm. A2/3/4, astrocytoma CNS WHO grade 2/3/4; CNS, central nervous system; GB4, glioblastoma CNS WHO grade 4; GS4, gliosarcoma CNS WHO grade 4; M, spinal metastasis; MMR, mismatch repair; O2, oligodendroglioma CNS WHO grade 2; P, primary tumor; R, recurrent tumor; WHO, World Health Organization POLD1-mutated gliomas, including the spinal metastases of patients Fam011-III.
Depending on the cause of hypermutation, e. g. defective polymerase proofreading, MMR defects, or drug treatment, the signature of somatic mutations, i. e. their substitution class and nucleotide context, may differ  [47, 48]. Tumors with pathogenic POLE or POLD1 variants, particularly in the exonuclease domain, exhibit characteristic mutational signatures, i. e. COSMIC database signatures SBS10, SBS14, and SBS20  [47, 49]. While mutational signature SBS14 was previously detected in a hypermutated oligodendroglioma of a patient with de novo POLE exonuclease variant p. (L424V)  [9] , mutational signatures SBS10 or SBS20 were found in six of 14 (43%) gliomas, two of which were hypermutated, from patients with rare POLE/POLD1 variants here, providing evidence for defective polymerase proofreading in these tumors.
Acknowledgements The authors wish to thank the patients and their families for participating in this study, as well as  Veronika Rückoldt  and the  Cell Sorting Core Facility, Hannover Medical School, Germany  for excellent technical assistance. This study includes thesis work (Dr. rer. nat. ) of CAMW. Weber et al. Acta Neuropathologica Communications (2023) 11:184 comparable ethical standards. All patients gave their informed consent to participate in this study.
Homozygous POLD1 germline variant identified in an oligodendroglioma patient without family history of cancer CRC [30] 22. 1 N B T DC 0. 008146 rs3218775 c. 2546G>A p. (R849H) POLD1 19:50918229 WII-40-II. 1 Given are all identified rare (minor allele frequency, MAF ≤ 0. 01), non-silent (i. e. splice site, frameshift, in-frame indels, stop gained/lost and non-synonymous missense) variants predicted to be deleterious by at least one prediction tool, i. e. MutationTaster, SIFT, PolyPhen-2 or PROVEAN, in the POLE or POLD1 gene. NCBI reference sequence NM_006231. 4 (POLE) and NM_002691. 4 (POLD1). B, benign; BC, breast cancer; CC, cervical cancer; CRC, colorectal cancer; D, damaging; DC, disease causing; Del, deleterious; EC, endometrial cancer; Mel, melanoma; N, neutral; OC, ovarian cancer; PoD, possibly damaging; PTC, papillary thyroid cancer; PrD, probably damaging; T, tolerated a SNP database ID (https://www.
ncbi. nlm. nih. gov/SNP/) b According to the Genome Aggregation Database (gnomAD) browser v2. 1. 1, controls, non-Finnish European population (https://gnomad. broadinstitute. org) c According to MutationTaster (https://www. mutationtaster. org) d According to SIFT (https://sift. bii. a-star. edu. sg) e According to PolyPhen-2 (http://genetics. bwh. harvard. edu/pph2/) f According to PROVEAN (https://www. jcvi. org/research/provean) g According to CADD (https://cadd. gs. washington. edu) h Only tumor DNA of the patient was analyzed (non-neoplastic DNA was not available).
Because we use the log discharge, small changes in summer flow have an impact more comparable to that of bigger changes in winter. We modeled the remaining errors (z WT t ) using a white noise process. Lastly, module 3 corresponds to the estimate of unknown temperatures. As our model is fully hierarchical, this module depends upon and integrates with modules 1 and 2. Consequently, the model propagates all uncertainties when estimating unknown WT based on covariates. In Bayesian software such BUGS, JAGS, STAN or NIMBLE (  [33]  and references therein), this is performed simultaneously to the fit. AT and Q time series just have to include hindcasting and/or forecasting parts if any. Module 1 also decomposes these 'extra' data while module 2 produces the WT estimates. This process is often referred to as deriving posterior predictive distributions.
Then we computed a Bayesian p-value giving the probability that χ 2 (WT rep |θ) > χ 2 (WT obs |θ). Bayesian p-values close to 0. 5 suggest congruency between the model and the data. Very high or very low (about 0. 95 or 0. 05) values provide serious inconsistency warnings. Secondly, we also compared the fitting performances of models M 1 and M 2 using the Deviance Information Criterion (DIC,  [34] ). DIC allows the comparison of goodness of fit while penalizing complexity in a way very similar to that of the Akaike Information Criterion. The smaller the DIC the better. A five points reduction is usually considered as indicative of a significant improvement. Lastly, we checked the predictive performances of the models. For this we used cross a validation approach. Specifically, we used 2/3 of historical data as training set and forecast the last third.
We used the Root Mean Square Error (RMSE) of the estimates to compare performances. Bayesian computations details. We implemented models M 1 and M 2 in JAGS  [35]  through R  [36, 37]. This software approximates the parameters posterior distributions using Monte Carlo Markov Chains (MCMC) algorithms. Specifically, we ran three MCMC in parallel for each model fit. We kept 10000 draws for each one after both a thinning of 25 and an initial burning period of 10000 draws. All diagnostics suggested the MCMC converged successfully. Priors used were all uninformative relative to the data (see S1 Table in S1 File). The code developed together with one of the data-sets are available on GitHub (https:// github. com/GuillaumeBal/2023. bayes. stream. temperature). Readers can change the input data file with their own and run the model.
com/), 9 km away from the water temperature measurement station. Q records come from 8 km upstream of the Moulin des Princes station where a flow measuring station is operated by the French hydrological services (https://hydro. eaufrance. fr). The three time series are 13 years long (1995 to 2007) and 9. 6% data are missing on average. This river is part of a larger research observatory where diadromous fish population are extensively monitored and studied (ORE DiaPFC). The Rough River (also called the Srahrevagh River) is a tributary of the Srahmore River in the Burrishoole Catchment. The Srahmore flows into Lough Feeagh which is connected to the saline coastal lagoon Lough Furnace. The entire system discharges into Clew Bay on the Atlantic Ocean (1. Data cover the period 2002-2016. Daily WT was measured using a StowAway TidbiT temperature data logger from Onset (TB132-05+37).
Air temperature data was recorded at the Newport (Furnace) manual weather station (jointly run by Met E ´ireann and the Marine Institute, station 833). Maximum and minimum temperatures are recorded using mercury thermometers, and average daily temperature is taken as the average of these two readings. Data were downloaded from www. met. ie, licensed under a Creative Commons Attribution 4. 0 International (CC-By 4. 0) License. Some more details about the catchments are provided in Table  1. Raw time series are shown within the supporting information file (S1 Fig in  S1 File). Forecasting under climate change. We used full joint posteriors from model M 1 and M 2 to project WT temperature from AT warming projections. In particular, we picked a range of AT warming of 0 to 5˚C according to the latest IPCC estimates  [46] , excluding the most extreme warming scenario.
The Bayesian framework allows for a full propagation of uncertainties while doing so. A probabilistic rational can then be used for management decision. The code is available on https://github. com/GuillaumeBal/2023. bayes. stream. temperature so readers can perform their own fits. Providing correctly formatted data (locally observed WT, AT and optionally Q data) and the specification a few model options is all that is required to run both models M 1 and M 2.
srv/eng/catalog. search#/metadata/ie. marine. data: dataset. 5122. In case of the Scorff river, data are accessible free of charge as well. Water temperature are accessible through a DOI too. Flow data are hosted onto the French hydrology services database and are downloadable at https://hydro. eaufrance. fr/stationhydro/J510221001/series. In case of the air temperature time series, a data sharing agreement with the French Weather Services is necessary for gratuitous access by scientists. Please go to https://donneespubliques. meteofrance. fr/?fond=dossier&id_dossier=1 for details.
Overview The first software forge, called SourceForge, was launched in 1999, and was designed to help open-source software developers build their software collaboratively and distribute it to their users. Since then, software forges have become vital tools for all software developers. They feature collaborative development tools (for monitoring code modifications, and managing user tickets, contributions and projects) and they industrialise the process of creating software from their source codes (compilation, automated tests, quality assurance and distribution of deliverables) and communications tools such as forums. Software forges also act as social networks for developers. Whenever developers want to encourage people to use and make contributions to software, they need to come to a decision about which forge to choose based on the target audience and network.
These commercial forges include GitHub (owned by Microsoft), which is the most widely used, followed by BitBucket (owned by Atlassian) and GitLab (owned by GitLab Inc. ). Some forges, be they community-based or commercial, such as GitLab, can be self-hosted by Higher Education and Research Institutions, some of which have their own public forge. This report lists 73 of these types of forge as well as the forges for internal use only. These self-hosted forges are often easy to install, ranging from a simple executable for solutions such as Gogs, Gitea and Forgejo to a preconfigured software package integrated into Linux distribution for GitLab, for example. GitLab is basically a commercial forge  (gitlab. com)  based on open-source forge software that can be installed on premise. GitLab Inc.
The simplest solution is when their institution has its own forge, particularly if no interaction is needed outside the institution. When wider interaction is required, communities developing research software often look to online commercial forges. This is reflected by the winners of the first french open science open-source research software award laureates, with 9 projects being hosted on GitHub and one project on SourceForge. The social network effect of "people go where most people are" and the international scope of the projects were the reasons for their selection. However, it really should be noted that commercial forges can suddenly disappear, as was the case with the Google forge, Google Code, which ceased operation after nine years presence in just a matter of months. The same thing happened with the Gitorious hosting solution.
In addition, these forges have terms and conditions of use which each member must agree to as an individual, rather than on behalf of their institution. Self-hosted forges are one way of mitigating this kind of problem. However, it may be the case that the solution selected is no longer being maintained, or no longer developed under an open-source licence. This is what happened with the SourceForge code, and it was maintained in a community version under the name "GForge", which has itself changed licences to enable it to be maintained in a community version under the name "Fu-sionForge", to now end up now with an unmaintained software (the latest version of the software dates back to 2018). Therefore, decisions around self-hosting and which forge to use are important. Of the 73 forges listed, 64 are GitLab platforms (the other forges use FusionForge, Gitea, Gogs, Redmine, Trac or Tuleap).
| Introduction This report looks at the software forges used in higher education and research institutions in France (Enseignement Supérieur et Recherche, ESR). It focuses in particular on software engineering practices and needs, in order to get the best value from the software created through Open Science. This document aims to provide an initial overview of the software forges used in that context, and to identify the ways of raising the profile of software created via Open Science. Software forges are mainly designed to manage software-engineering artefacts (such as the source code), the binary files and even the documentation over the entire life cycle. Forges can also be used to collaboratively draft scientific papers or documentation, or even write web pages with the help of tools for processing poorly structured text files (for example, markdown and asciidoc).
| About the importance of forges If you are developing software, you need to ensure that good practice is implemented. Irrespective of the characteristics of the software being developed, it is always easier to start by implementing good practice rather than trying to bring it in at a later stage. In any case, the quality of the software will be all the better for it. For example, an important aspect, as we will see later, is managing changes to the source code. These need to be automatically tracked with a version management system, such as Git, Mercurial or Subversion, for instance. Many web platforms, often referred to as software forges, such as Bit-Bucket, Gitea, GitHub, GitLab, Gogs or ForgeJo, simplify the process of implementing this good practice and help with developing better-quality software and with setting up contributor and user communities.
Enabling and encouraging collaborative work Forges aim at enhancing collaboration around software, particularly by collecting the dysfunctions and use cases not covered by the software, but also to contribute to codes. Anyone can contribute to codes by sending a patch, a file containing changes to correct or improve the project, or by making a pull request (PR) or a merge request (MR), depending on the platform. It is also a way of saving a copy of the software on shared infrastructure, which can be archived by Software Heritage when the software has a public source code. Forges enable software developers to carefully manage these collaborations by choosing which collaborators are authorized to make contributions through a rights management system. Examples of highly successful open-source research software underline the view that making it as easy as possible to make contributions is a major factor in helping communities of contributors to emerge.
Looking beyond the source code Although forges were originally designed to manage the life cycle of software, they are now used more broadly: For publishing and maintaining websites Using tools such as GitHub/Git-Lab/SourceHut pages; For drafting scientific papers By using document composition tools, such as LaTeX, or possibly using a semi-structured language such as markdown, asciidoc or reStructuredText, which are easier to read as a source; Sharing data and models Closely managing contributions and publishing content online helps to create communities around data and model sharing (see the HTR United community, for example). All of the comments on the software are also valuable for these uses.
Evolution of the target audience for forges Twenty years ago, forges were platforms where software users and developers interacted. Taking the open-source version of the sourceforge. net forge (such as the GForge forge, in particular) as a basis, they featured two important features for users -downloads of the different versions of the software and forums or mailing lists for requesting assistance and interacting with the development team. Managing the software's source code was just one of many features. There was a clear separation between the members of the development team, who had editing rights over the source code, and the other users. Software and development approaches have evolved. Some software are provided as services, which means they no longer need to be downloaded. Libraries are distributed through package managers (such as maven, pip and npm), which work in tandem with dependency management tools.
Mutual assistance sites like StackOverflow have become alternative sources of information for official software forums. The arrival of GitHub in 2007 meant the profile of forges rose, and source codes took centre stage, as they became the first thing that people wanted to see when starting a project. All discussions were context-specific, based on issues raised and contributions made. Source codes provide scope to create a project fork, so they have become a common good which can be modified and distributed by everyone, thereby encouraging people to make contributions. At the same time, we have seen the emergence of online development environments, with continuous integration and deployment becoming mainstream. The people using forges are becoming more specialist, as people already need to be well versed in developing in order to use them, while forums that are used to ask questions which can be answered by the community are disappearing.
Major use of commercial forges The The main benefit of turning to these solutions for an open-source Higher Education and Research project is making code or documentation contributions easier by adopting a "developer social network" model. In fact, for many developers who have an account on these platforms, contributing to a public project on these forges is very straightforward. This is why community structures such as Eclipse have decided to introduce these commercial forges, while also maintaining their own forges. However, commercial forges are not sustainable solutions for hosting research software. For instance, in August 2022, GitLab made plans to automatically archive projects that have been inactive for a year  (Sharwood, 2022) , although some mature software may have a slower development cycle and extended periods of inactivity, without having their usability called into question.
In the past, commercial forges like Google Code  (Staff, 2015)  and even community services like Gitorious (Degeler, 2015) have been closed, and hundreds of thousands of projects were deleted from BitBucket following its decisions to stop hosting projects using the Mercurial version control system (Chan, 2020). These closures have led to the disappearance of modification histories and forum exchanges, which are important assets. Therefore the terms and conditions of use for commercial forges may cause problems here. Finally, commercial forges are not necessarily able to meet the needs of the entire project life cycle. Commercial forges for private projects must be used in compliance with European Union data protection regulations which call for servers to be hosted in European Union territory and not to be subject to non-European-Union legislation (such as CLOUD Act and FISA 702).
Using open-source community forges There are many open-source community forges such as the Free Software Foundation (FSF) and its GNU project, Apache, Eclipse, OW2 and many others that, in addition to their own projects, host open-source projects from the research world. They enable projects to be launched by giving them support beyond just getting them started. When they are stakeholders for these projects, they can ensure the long term viability of software production. These communities may also position themselves individually towards open science; see OW2's position, for example. However, these forges host mature professional projects which are intended for wide usage. These communities determine which projects they would like to host and support, based on their own criteria. It may be the subject area for the project, its level of maturity, its development or governance processes or its positioning in the financial world or society.