dataesr/scientific-paragraphs-categorization huggingface dataset:
In addition, having all old data sets converted into the new format will ensure the long-term usability of the old data sets with the new Run 3 analysis framework. Documentation and software availability constitute the other key elements of the ALICE data preservation strategy allowing the future collaborators, the wider scientific community, and the public to analyze data for educational purposes and for eventual reassessment of the published results. ALICE has already put in place procedures including the use of Docker containers and the software deployment on CVMFS for the software continuous integration and the release validations. Such procedures are also the bases of the Data and Analysis Preservation for the members of the ALICE collaboration, while the wider scientific community and the public cannot benefit from these procedures having no access to CVMFS.
DP technologies and projects Although HEP has a long tradition of common software development, in particular for data access, simulation and analysis (e. g. HIGZ  [28] , PAW suite  [25, 97] , ROOT  [24] , GEANT3  [98] ), the computing systems and the data structures are largely experiment specific. This variety is of course related to an efficient experiment running and originates mainly from the objective of obtaining promptly physics results, within the resources allocated to each experiment. This objective is not always compatible with a common approach that may involve extra resources not freely available during the data taking. However, this approach induces a fragility towards a long term data preservation, since some systems are "custom made" and difficult to maintain in the longer term.
Designed as a secure environment, experimental teams retain full control of their information and data. CAP enables users to apply the appropriate access restrictions so that users are always in control of when and if their work is shared or published. Concrete use cases are: -Community analysis information hub: Bring together information from various tools and databases. Search, compare, retrieve and share information. -Validation and reuse: Instantiate preserved analyses and computational workflows on compute clouds to allow their validation or execution with new sets of parameters to test new hypotheses. -Streamlined handover and onboarding: A person having done an analysis is leaving the collaboration and has to hand over the know-how to other collaboration members. A newcomer would like to join a group and requires information on past analyses.
REANA supports several such DAG standards (CWL, Snakemake, Fig. 10  Example of Higgs-to-four-leptons analysis of CMS open data running on the REANA reproducible analysis platform. The analysis consists of four steps and is expressed in the Snakemake workflow specification language. The specification of the collision data analysis step is illustrated in the picture Yadage), parses the workflow specification described by the user and dispatches its computational steps to various supported compute backends (Kubernetes, HTCondor, Slurm). The reproducibility of computations is assisted by means of using software containers (Docker, Singularity) that fully encapsulate the original computational environments of each analysis step. The REANA approach was successfully tested in several data production and data analysis scenarios.
For example, REANA was used for ATLAS reinterpretation searches for new physics or CMS reconstruction and jet energy corrections [103]. In the CERN Open Data portal, REANA is used both on the "data production" side to ensure the correctness of preserved data sets' provenance information [100] as well as on the "data analysis" side by running several data analysis examples such as CMS open data Higgs-to-four-lepton example analysis (see Fig. 10 ). REANA promotes early adoption of computational reproducibility principles by researchers. The integration with source code management platforms such as GitLab 22 allows researchers to develop and run either full data analysis tasks on REANA or at least test the correctness of analysis workflow after each code change. If an analysis is developed in this "continuous integration" manner [103], the preservation 22 https://about.
gitlab. com/. of knowledge associated with the data analysis as well as the future deposit of analysis assets into digital repositories are largely facilitated. REANA therefore complements the data preservation repositories by promoting active "preproducibility" of data analyses during the active analysis phase rather than only relying on passive data deposition and subsequent "reproducibility" once the analysis is completed  [104]. REANA was developed with particle physics use cases in mind, but the platform profits from synergies with general reproducible data analysis patterns in other scientific disciplines, such as astronomy, bioinformatics and life sciences [105].
ARCHIVER The project ARCHIVER [106,107] develops innovative services for Long Term Digital Preservation of scientific datasets using the Pre-Commercial Procurement instrument funded by the European Commission. R&D was performed competitively by commercial suppliers, across different implementation phases. The services were developed by Arkivum and Libova co-designed with input from research clusters members: CERN, PIC/IFAE and DESY are members of the ESCAPE cluster, 23 DESY is also a partner in the 23 https://projectescape. eu/.
123 ExPaNDs  24  cluster, while EMBL-EBI is a member of EOSC-Life. These research performing organizations deployed use cases from Astrophysics, High-Energy Physics, Life Sciences and Photon-Neutron Sciences. The use-cases driving the ARCHIVER consortium's need for research and development of innovative data preservation services extended the preservation ecosystems of research organizations to create more dynamic solutions to be deployed primarily by using a hybrid model, on-premise or exclusively in cloud environments, operated by European SMEs that were enhanced and assessed against best practices such of CoreTrustSeal  25 and DPC-RAM,  26  so that datasets remain FAIR (Findable, Accessible, Interoperable, Reusable) for decade timescales or more. The services resulting from the ARCHIVER R&D are addressing the gaps that put data at long-term risk as they prevent the construction and operation of sustainable Trusted Digital Repository services, affecting organizations both large and small who are tasked with being custodians of valuable research artifacts.
CERNVM CERNVM provides a portable platform to develop and execute HEP experiment applications  [108]. The CERNVM platform consists of a virtual appliance with a minimal operating system (OS) and a distributed file system (CVMFS) that provides a global shared area for scientific applications and conditions data  [109]. Both the appliance and the distributed file system distribute data processing environments to the heterogeneous, distributed computing infrastructure used by running experiments. The CERNVM technology is designed to take software preservation aspects into account and to allow for an easy transition from an actively maintained experiment software stack to the preservation phase  [110]. The CERNVM appliance provides both an image for a full virtual machine (VM) for use with hardware virtualization technology such as KVM and Amazon EC2 as well as a container image for use with container tools such as Docker and Kubernetes.
Full VMs give access to hardware emulation technology, so that software stacks compiled for deprecated CPU architectures can run on contemporary hardware, albeit at a significant performance cost (often ×10 and more slower). Container virtualization has a negligible performance overhead; it relies, however, on a stable interface from the Linux kernel to user-land applications. Retrofitting the CERNVM technology to software stacks from the LEP experiments, the approach has shown to bridge more that 20 years. A CERNVM environment with a CMS software stack from 2011 to process LHC run 1 data was created with minimal effort, since the CVMFS and CERNVM infrastructure has been in use from the start by LHC experiments. Key in the CERNVM approach is the split between the minimal appliance (the OS platform) and the experiment software directory tree provided by the CVMFS network file system.
The naïve use of virtualization technology, in contrast, which bundles OS and application software in a single VM or container image, is easily susceptible to container management problems. Due to the complexity and variety of experiment application software, the naïve approach results either in huge images (e. g. , 100GB+ for all ATLAS releases) that are difficult to distribute or in a proliferation of special purpose containers that are difficult to book-keep. Software stacks provided through CVMFS, on the other hand, are well-maintained by the experiments' software librarians and the necessary binaries for any given task are loaded ondemand at runtime. As CVMFS is a versioning file system, software stacks installed on CVMFS are automatically preserved remain available for future use. Several lessons were learned from exercising CERNVM and CVMFS for the preservation of LEP and LHC experiment applications: 1.
It is important to distinguish between scientific applications (e. g. , event generators, detector simulation, histogramming tools) and system applications (e. g. , web clients, data access software). In contrast to scientific applications, system applications generally do not freeze well. This is due to the fact that system applications often interact with the outside world or at least the (virtualized) hardware. For instance, web clients may unsuccessfully try to connect with an outdated SSL protocol to HTTPS servers. Hard disk utilities may be subject to integer overflows on today's volume sizes. 2. As a result, it is important to identify network dependencies of data processing workflows before freezing. There may be dependencies, for instance, to online databases (such as conditions databases), grid configuration, or data access servers.
CERNLIB The management of the retired external software packages poses a problem for the rapidly developing but not optimally managed physics-related software. One of the approaches that could be used to maintain the external software packages is to create a digital archive/library implemented on top of the popular software versioning platforms as GitHub or GitLab  [111]. CERNLIB is one of the key software components that have been extensively re-used by many collaborations and still plays an key role for the preservation activities e. g. for LEPbut also HERA-era experiments. The CERNLIB libraries and tools have since their inception been migrated to a large set of platforms and also several code management systemsstill preserving most of the original functionality and development(commit) history.
The CERNLIB contains multiple software sub-libraries, many of which are actually independent software packages. Logically CERNLIB is split into a set of sub-packages mathlib, a library with mathematical routines packlib, general purpose library kernlib, general purpose library geant, a version of the Geant3  [98]  simulation toolkit. mclib, which contains a set of most used MC event generators. graflib, a library with interfaces to graphical routines pawlib, Physics Analysis Workstation Each sub-package is split into smaller sub-sub-subpackages, very often with their own requirements and compilation options. Depending on the host system, the CERNLIB might require the following software -C preprocessor, C99 and Fortran77 compilers sed and zip utilities -CMake and any build system -for sc CMake builds -Imake and make -for sc Imake builds -BLAS with Lapack compiled with the same Fortran compiler (optionally) -Freetype libraries and headers -X11 libraries and headers of version R6.
6+ -Motif libraries and headers -OpenSSL libraries (and headers for CMake builds) The community of users may soon be facing the challenges of a forced migration (caused by hardware and OS obsolescence) and consequently validation on recent 64-bit platforms. Since such a validation poses significant technical and personnel effort, the idea to consolidate the validation activities on a single, community maintained software base with a small set of actively validated platforms emerged at a recent DPHEP community workshop. The effort in a consolidated, up-to-date issue tracking and, as much as possible, automated build and validation pipeline would then allow to exploit the small remaining expert effort for the benefit all remaining CERNLIB deployments and prepare for a period in which expertise in CERNLIB internals is rare or not anymore readily available.
After the end of active development of the CERNLIB in 2007, it was widely used by many collaborations and individuals. The intensive usage of CERNLIB on the constantly updated operating systems resulted in a development of large number of code patches. In the end of 2010 most of these patches were consolidated and used to create Debian packages for CERNLIB. Those patches, as well as patches from the DESY theory group, Fedora and Debian projects became the starting point for the updates of CERNLIB in 2022. All the updates were implemented in the newly created CERN-LIB git repository hosted by CERN and later extended by various improvements by the CERNLIB/DPHEP initiative. The repository is a merger of previously separate repositories with CERNLIB sub-libraries and contains all the development history of CERNLIB since 1990s.
The code is also supplemented with a continuous integration system (CI) that performs builds of CERNLIB on selected platforms, namely older Scientific Linux 4, 5, 6; CentOS 7, 8, 9; Alma 8, 9; Fedora 35; in 32-and 64-bit variations, as well as Ubuntu 18, 20, 22; in 64-bit. 28  While some of the images used in CI are stock images from the vendors, the older Scientific Linux 4, 5, and 6 container images are maintained under the DPHEP cover. While CERNLIB contains codes written in Fortran and C, there are little worries about future ability to compile the updated CERNLIB code. However, the native CERNLIB build system, Imake [112], is relatively outdated and can potentially disappear in the nearest future. Therefore, while the Imake scripts are still maintained in the CERNLIB, significant efforts were put recently into a re-implementation of the build system of CERNLIB in CMake  [113].
CMake is an open-source, free cross-platform build tool with a history for more than 20 years. As of 2022 CMake is de-facto the standard for software written in C/C++/Fortran. With the CMake-based build system it became possible to perform checks of CERNLIB code with many more compilers on multiple historical and modern platforms. This approach is a carbon copy of the techniques used to port the JADE software, see Sect. 4. 1. As a result, the updated CERNLIB version can be compiled on RHEL4+ i686, x86_64, ppc64 systems and modern 64bit MacOSX using GNU 3+, CLang, Intel and NVidia compiler collections. However, only certain combinations of the compilers and systems are fully backed by the DPHEP and included in the CI. The CERNLIB code including all the above improvements is available in GitLab at CERN  29  and should serve as a dropin replacement for the CERNLIB 2006.
Sequencing For the preparation of libraries targeting HTO and gene expression sequencing, we utilized the NextSeq 500/550 High Output Kit v2. 5 (75 cycles, Illumina) following the manufacturer's recommendations. The library pool consisted of 8% HTO libraries and 92% gene expression libraries, and it was loaded onto the Flow Cell at a concentration of 1. 8 pM. Subsequently, the libraries were sequenced on a Next Seq 500 system with the following parameters: 28 cycles for read 1, 8 cycles for index i7, and 91 cycles for read 2. This sequencing setup aimed to achieve an average sequencing depth of 32 million reads for HTO libraries and 368 million reads for gene expression libraries. The sequencing data underwent analysis using the Cell Ranger Pipeline, specifically version 6. 0. 2, for various steps including quality control, sample demultiplexing using mkfastq, barcode processing, alignment, and single cell 3' gene counting through cellranger count.
Demultiplexing of samples was carried out with bcl2fastq, utilizing the 8-bp sample index, 10-bp UMI tags, and the 16-bp GemCode barcode. The alignment of the cDNA sequences presents in the 91-bp-long read 2 was performed using cell Ranger versions 3. 0. 0 and 3. 1. 0. UMI quantification, GEM-Code, and cell barcode filtering, based on Hamming distance error detection as described by  Zheng et al. , 2017 [39] , were executed. Only confidently mapped transcriptome reads, excluding PCR duplicates, with valid barcodes and UMIs, were utilized to generate an unfiltered data matrix. Barcodes exceeding 10% of the 99th percentile of expected cell recovery (default = 3000) in total UMI counts were considered to contain cells and were selected to create a filtered gene-barcode matrix for subsequent analysis.
Normalization and Correlation of Gene Expression Levels Normalization was performed individually for each sample using the "log-normalization" method applied to the Seurat object. To assess the correlation between the various samples, an initial Seurat filter was employed to retain genes detected in at least three cells and to include cells with a minimum of 200 UMI. Subsequently, the gene expression correlations across different samples were calculated by determining the average expression of genes shared by all samples. 2. 3. 3. PCA and tSNE Analysis for Cell Clustering and Classification, and Data Visualization Secondary analysis was conducted using the Cell Ranger count and aggr pipelines. Prior to cell clustering, Principal Component Analysis (PCA) was applied to the genebarcode matrix, which had been normalized, log-transformed, centered, and scaled, to reduce the dimensionality of the feature (gene) space.
The implementation of the IRLBA algorithm in Python was employed for this purpose, resulting in a projection of each cell onto the first N principal components. No filtering was performed on "low-quality" genes and cells as previously described, and the Seurat package utilized this projection in the subsequent PCA analysis. Following PCA, t-distributed Stochastic Neighbor Embedding (t-SNE) was utilized to visualize the cells in a 2-D space. Clustering was then performed to group cells with similar expression profiles based on their projection in the PCA space. Two clustering methods were employed: graph-based and k-means. Cell Ranger also generated a table indicating the genes that exhibited differential expression in each cluster compared to all other clusters. The classification of PBMCs was inferred from the annotation of cluster-specific genes, relying on the expression of well-known markers of immune cell types (marker-based classification).
For comprehensive visualization of the entire dataset and interactive exploration of significant genes, cell types, and substructure within cell clusters, Loupe Cell Browser (v5. 0) was employed  [31]. To process multiplexed samples, the HTO data are processed using the "cite-seq count, v1. 4. 3" tool available at https://hoohm. github. io/CITE-seq-Count/ (accessed on 5 January 2022) and https://zenodo. org/record/2590196 (accessed on 5 January 2022). The resulting data are then read using the Seurat "Read10X" tool, accessible at https: //satijalab. org/seurat/articles/hashing_vignette. html (accessed on 5 January 2022). Only the cell barcodes that are common between the HTO data obtained from cite-seq count and the mRNA data obtained from cellranger are retained. These barcodes correspond to the cells detected by cellranger that also have an assigned HTO.
However, interactions between extracellular molecules and membrane proteins can potentially impact various metabolic pathways. It raises concerns about whether such interactions could alter the transcriptome of leukemia cells. To address this, we examined the expression of the B2M protein in the two acute myeloid leukemia (AML) samples sequenced using single cell RNA-seq. The results of this analysis revealed high expression of the B2M protein in both AML samples, indicating that the process of leukemogenesis did not affect the expression of this cellular target (data not shown). With the confirmation of our HTO target, we proceeded to sequence the two AML samples using both techniques. We utilized 10X Genomics scRNA-seq technology to sequence a total of 4390 cells from the UPN23 Single Cell RNA-sequencing (UPN23 SC) sample and 16,645 cells from the UPN29 SC sample, each sequenced individually.
Furthermore, we observed consistency between the two approaches in terms of the percentages of mitochondrial genes in each patient (Figure  1c ). Based on this quality control analysis, we found consistency in the sequencing results obtained from both approaches. After applying cell filtering, we identified approximately 2579 cells in UPN23 SC compared to 3176 cells in UPN23 SC-m. Similarly, we detected approximately 14,722 cells in UPN29 SC and 6347 cells in UPN29 SC-m (Figure  1d, e ). Subsequently, we performed clustering analysis on the cells from each sample using Seurat software. In UPN23 SC, we identified 12 distinct clusters labeled as clusters 0-11, whereas in UPN23 SC-m, we observed 11 clusters labeled as clusters 0-10 (Supplementary data S1a,b). As for the UPN29 sample, we discovered 16 clusters labeled as clusters 0-15 in UPN29 SC, and 13 clusters labeled as clusters 0-12 in UPN29 SC-m (Supplementary data S1c,d).
Gene Expression Levels Correlate between scRNA-seq and Cell Hashing To complement our initial analysis, we investigated the correlation between the average gene expression in samples sequenced individually and those sequenced using the cell hashing technique. As depicted in Figure  1f -g, the expression levels of genes in both the UPN23 and UPN29 samples exhibited a strong correlation when comparing the two approaches (R = 0. 996, p < 2. 2 × 10 -16 for UPN23 and R = 0. 998, p < 2. 2 × 10 -16 for UPN29). After applying cell filtering, we identified approximately 2579 cells in UPN23 SC compared to 3176 cells in UPN23 SC-m. Similarly, we detected approximately 14,722 cells in UPN29 SC and 6347 cells in UPN29 SC-m (Figure  1d, e ). Subsequently, we performed clustering analysis on the cells from each sample using Seurat software.
However, these algorithms have proven insufficient. The performance of machine learning algorithms depends on access to large amounts of data for training. In traditional machine learning, training is centrally held by one organization that has access to the whole training dataset. In practice, data are often distributed across multiple parties, and sharing it for training purposes is not simple due to privacy policies and regulations like the General Data Protection Regulation  [2]. These regulations impose strict rules about how data can be shared and processed between organizations. Due to these factors, federated learning (FL) has become a hot research topic on machine learning since its emergence on 2016  [3]. This promising technique allows multiple parties to jointly train a global model by only exchanging updates about local models and without the need to share their private datasets.
This offers a promising solution to mitigate the potential privacy leakage of sensitive information about individuals. Recent works have demonstrated that FL may not always provide privacy and robustness guarantees  [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14]. While the private data never leaves their owner, the exchanged models are prone to memorization of the private training dataset. Some sensitive information may be inferred from the shared information using some well-known attacks like gradient inversion, reconstruction attacks, membership inference, and property inference attacks. One way to mitigate this type of attacks is to use privacy preserving techniques like differential privacy (DP) and homomorphic encryption (HE). Differential privacy offers a way to disrupt data while preserving the statistical properties of the data.