dataesr/scientific-paragraphs-categorization huggingface dataset:
EXPERIMENTAL EVALUATION We implemented and run I-GWAS on Intel SGX using C++ and Graphene SGX  [77]. Experiments were performed on an Intel i7-8650U machine (2. 11 GHz, 16GB RAM) with Ubuntu 18. 04. We used real genomes from the phs001039. v1. p1 dbGAP dataset  [81] , which consists of 14,860 case and 13,035 control genomes. We adopt the parameters suggested in SecureGenome  [71]  for the genomic privacy protection tests to decide which SNPs might have their allele frequencies safely released (recall §2. 3). Namely, 0. 05 MAF cut-off, 10 -5 LD cut-off, 0. 1 false-positive rate and a 0. 9 detection power rate. We evaluate I-GWAS along 3 metrics: privacy, data utility (accuracy loss and release utility score) and run-time. We compare I-GWAS against DyPS  [64] , a state-of-the-art approach to dynamically release GWAS privacy-preserving results, and against ϵ-DP using Laplace mechanism for the dynamic releases of GWAS statistics.
We consider several ϵ and privacy budgets (pvb) spent over releases to evaluate trade-offs. pvb is used to keep DP properties over multiple releases. pvb starts at 1 (100% of ϵ) and each release consumes a fraction of ϵ. When pvb is exhausted, DP cannot release data with original privacy guarantees. We utilized PyDP, a Python wrapper for Google's Differential Privacy C++ library  [36]. We do not compare I-GWAS with a method based on local DP since it introduces higher perturbation than a centralized DP scheme  [20, 58]. Moreover, we identified that the system-side performance (e. g. , bandwidth, memory, and CPU consumption) of I-GWAS is very similar to that of other TEE-based solutions  [9, 12, 15, 52, 64, 68]. Additionally, I-GWAS only imposes a penalty of requiring extra genomes to protect overlapping releases (cf.
Note that we still evaluate I-GWAS along other traditional metrics mentioned before individually. Privacy and data utility. Fig. 5  illustrates the impact of privacy, i. e, preventing the release of GWAS results at some SNP positions, on data utility. In this experiment, we use all 14,860 case genomes and consider two GWASes over 10,000 SNPs and varied the fraction of overlapping genomes among studies between 1% to 50%. The vulnerable SNPs are positions that would put participating genomes at risk of being identified in a membership attack. These SNPs need to be identified and secluded from public releases. The GWAS results are only known by the I-GWAS's trusted enclave, and only the results of SNPs that can be safely exposed are publicly shared. With the dbGAP dataset that we consider, the release coverage decreases when the number of overlapping genomes increases because more SNPs are withheld by I-GWAS.
For the membership inference protection, we measured the average run-time for one analysis over the largest dataset (i. e. ,14,860 genomes and 10,000 SNPs). I-GWAS computes this verification in 12. 73 seconds. Keeping the number of SNPs and considering fewer genomes, I-GWAS takes on average 6. 45 seconds for 9,906 genomes, 4. 61 seconds for 7,430 genomes, and 2. 96 s for 4,953 genomes. Lastly, the average memory consumption of I-GWAS in the enclave was 2 MB. Hence, respecting SGX's memory limitations. Further discussion. Both I-GWAS and DP are valid approaches and can even be complementary to each other for membership protection of GWAS releases. They should be chosen according to the expectations of the federation in terms of precision of the results, foreseen number of releases and privacy-protection guarantees.
PrivSTRAT applies data perturbation considering the group stratification in a study, and PrivLMM is based on Linear Mixed Models (LLMs)  [74]. In a later study, Simmons et al. [73]  enable differentially private releases of GWAS relying on Bayesian statistics, MCM and HMM. Furthermore, Almadhoun et al. [1, 2]  have shown that the existence of dependent records in a genomic database decrease the privacy guarantees of DP mechanisms. Several works aimed at providing DP in a dynamic environment, such as DP under continual observation  [13, 30]  and for growing databases  [23]. To the best of our knowledge, these techniques have not been used under a dynamic GWAS or closely related scenario. Recently, Ayoz et al. [4]  showed that recovery and membership attacks can be launched by sequentially querying genomic data-sharing Beacons.
Alternative methods ensure that the identification power over released genomes is sufficiently low without data perturbation. For this purpose, one can use the hypothesis test with T r  [82]  or Λ  [88]  metrics. Recently, GenDPR  [65]  proposes a distributed implementation of the LR-test that only manipulates intermediary results in a TEE and does not require genomic data to be exchanged. We establish conditions for safe interdependent GWASes under continuous releases, and propose algorithms to enforce them. I-GWAS extends and combines genome-oriented privacy-preserving release algorithms with exhaustive verification methods to provide genomic privacy over continuous releases without data perturbation. Overview of federated GWAS solutions. Table  6  investigates recent federated GWAS works and their properties.
CONCLUSION We highlighted that sharing genomes and SNP positions in different GWASes requires the development of new privacy-preserving methods. In those settings, we showed that previous techniques that aim at preventing recovery and membership attacks might be ineffective. Using known statistical methods that enable safe and dynamic data releases for a single independent GWAS, we evaluated that up to 28. 6% of the processed genomic information could be recovered by an adversary in a scenario that involved two interdependent GWASes. We also identified that between 80% and 92. 3% of the SNPs might expose individuals to membership attacks. To fill this gap, we present I-GWAS, a novel framework that extends privacy-preserving algorithms to protect the genomic privacy of individuals participating in interdependent GWASes.
I-GWAS offers a linearly scalable algorithm to select which genomes and SNPs can safely participate in releases of GWAS statistics, while not allowing recovery and membership attacks even if adversaries can leverage overlapping data among releases. I-GWAS does not introduce noise and produces safe releases by slightly delaying the release of statistics until sufficiently enough additional genomes become available and withholding vulnerable SNPs. In contrast, although Differential Privacy can be adapted to support dynamic releases of overlapping studies and sometimes presents a better release utility score, it limits the number of possible releases and the accuracy of the released statistics. Future work include analyzing and improving the interplay between differential privacy and tolerable privacy budgets, and combining differential privacy with I-GWAS to improve its utility.
In particular, there is a need for more comprehensive studies that include multiple aspects of SWE when addressing the problem of the origin and evolution of solar eruptive events, as well as the impact on Earth's magnetosphere/ionosphere and other planetary systems. Moreover, SWE spans a number of well-established communities, but they have evolved independently over decades, utilising significantly different data content, storage, and handling. Efforts to support and foster scientific studies through dedicated databases (DBs), and collections of disparate resources, including models and tools, are being pursued by many institutions and organisations, including the National Aeronautics and Space Administration (NASA), the European Space Agency (ESA), and many national agencies. The USA National SWE Program Strategic Plan (started in 1995, reviewed and redefined in March 2019) has the primary goal of discovering and understanding the physical conditions and processes that produce SWE and its effects.
swpc. noaa. gov, accessed on 1 September 2021)) is more operationoriented, providing the official space weather alerts and warnings for the United States and multiple space weather monitoring datasets, as well as numerous products (tools, graphics, and subsidiary datasets) to help research scientists in both understanding and making use of the vast array of SWE information, as well as in forecasting the upcoming space activity and in modelling longer-term outlooks for future events. The ESA Space Situational Awareness (SSA) programme started in 2009 and ended in 2019; in particular, the SSA SWE segment aimed at monitoring and predicting the state of the Sun and the interplanetary and planetary environments, including Earth, which can affect infrastructures, thereby endangering human health and safety.
From 2020, the ESA's Space Safety programme has built on the work carried out by SSA. In this context, the SWE Service Network is currently focusing on the development of both key models and user-tailored services, as well as other building blocks to provide end users with reliable and timely SWE information. The online component of the SWE Services can be accessed via the SWE Portal (https://swe. ssa. esa. int, accessed on 1 September 2021). Furthermore, the strategic orientations of the Horizon 2020 Program for the last few years have specifically supported the production of SWE models and tools to improve forecasting capabilities, with an emphasis on the connection between SWE physical processes occurring sequentially or simultaneously in different domains. During FP7 and H2020 Framework Programs, the European Commission financed several projects with the aim of enhancing the efficiency of data access for heliophysics studies.
Among those, it is worth citing HELIO  [4, 5] , CASSIS  [6] , SOTERIA  [7] , HELCATS  [8] , and HESPERIA  [9]. These projects involved several partners from all over the world and explored the many aspects of building open tools for data access and exploitation and making those tools available to the extended SWE community. In the Italian context, the Italian Space Agency (ASI) has produced a SWE roadmap  [10]  for a long-term strategy to support the future scientific research of SWE and the realisation of a national scientific data centre for space weather, termed ASI SPace Weather InfraStructure (ASPIS), while strengthening synergies among the SWE/PSW Italian groups in a strong collaborative environment. Therefore, the Comprehensive spAce wEather Studies for the ASPIS prototype Realization (CAESAR) project was selected to reach such goals.
CAESAR is coordinated by the National Institute of Astrophysics (INAF) and is presented in this manuscript. CAESAR addresses scientific problems pertaining to the origin and evolution of solar eruptive events and their propagation and impacts through an unprecedented, comprehensive, multidisciplinary, and integrated approach. This encompasses the whole chain of phenomena from the Sun to Earth, as well as to other planets. In this endeavour, it is crucial to exploit a variety of products (datasets, codes, models) that will ultimately populate the ASPIS prototype. This is intended to unify multiple SWE resources in a flexible architecture to allow users to perform advanced scientific studies, both through a web interface and a dedicated application called ASPIS. py. A keyword metadata system will enhance search capabilities, especially as data volumes grow with recorded events.
CAESAR Overview The scientific targets of CAESAR are multi-faceted, and its main objectives (amongst others) include: 1. To advance our understanding of the origin and evolution of SWE phenomena; 2. To provide both new and long-standing data, codes, and models to populate the ASPIS prototype; 3. To design the architecture and realise the ASPIS prototype with findability, accessibility, interoperability, and reusability data (FAIR-data), and flexible and user-friendly infrastructure; 4. To pave the way for future reliable and advanced SWE forecasting capabilities; 5. To ensure the efficient dissemination of results and infrastructure and foster future SWE studies. In order to achieve these goals, CAESAR is organised into three nodes (NODE 1000, NODE 2000, NODE 3000), managed and coordinated by the Work Package (WP) 0.
g. , the active Sun, interplanetary space, and so on) as well as the interaction with other HL WPs. Moreover, each HL WP comprises several individual WPs, in synergy with each other, managed by a WP leader with recognised experience to address the specific tasks of each domain. Nevertheless, a strong collaboration also exist between WPs of different HL WPs and with the other two nodes. NODE 2000 is dedicated to fulfilling objective 3. listed above. In order to develop the ASPIS prototype, the NODE is organised into three HL WPs for: the database, the interface, and the metadata structure (see Figure  3 ). Each HL WP is divided into three WPs for specific activities (for instance, ASPIS design, ASPIS implementation, and product management) that have a strong synergy with each other and with those of the other HL WPs.
The coupling between solar wind and the Mercury environment (WP1520) is the subject of a study that has the following architecture. There is a model that takes the actual solar wind conditions as inputs (obtained from WP1220) and estimates the solar wind precipitation onto the surface of Mercury in these different SW scenarios. The model is an evolution of [107] and is compared with other studies, such as [108], or more recent ones  [109]. Extreme cases, such as those in  [110] , can also be used as inputs. Then, a Monte Carlo model of the exosphere of Mercury can be used  [111] , which can simulate the effect of plasma precipitation on the exosphere of Mercury. Finally, the results can be compared with actual Na exospheric observations performed with the THEMIS solar telescope [112] (the whole database for years 2009-2013 will be available).
Measuring, understanding, and characterising the SEP radiation environment inside a space habitat is mandatory for developing proper countermeasures to mitigate crew radiation risks. These measurements allow for a detailed assessment of the dose due to the solar events absorbed by the crew, and also permit a fruitful comparison with the dynamic of the outside SEP radiation field as measured by other detectors outside the space habitat and/or on satellites (as in WP1210), with the aim of building a successful 'SEP now-casting' strategy. Therefore, data from several detectors inside the International Space Station (e. g. , ALTEA, LIDAL) are being properly formatted. Radiation flux and consequent dose rates will be derived. To showcase the proposed multidisciplinary approach, well-observed "target SWE events", exhibiting strong or moderate characteristics from several perspectives, will be studied in detail.
Product specification and metadata will be flanked by the interface requirements (from WP2220 and WP2230) in the preparation of the ingestion process and of the services and tools used to access the database. The metadata database, model listings, and method listings may link and index bulk datasets and other external resources. The ASPIS application programming interface (API, developed by WP2210) will define the common set of protocols to access/submit data to the DB, allowing for both data ingestion and query. The web graphical user interface (GUI, WP2220) aims to provide easy user-friendly access to the DB. The GUI will access the DB using a set of dedicated APIs, who will act as middle-ware to the queries and provide tools (delivered by NODE1000 WPs) for a quick visualisation and analysis of the retrieved products.
A possible landing page of the Web GUI would include one or more specific panels representing the near-real-time (NRT) values of relevant ASPIS data-sets, allowing for a live monitoring of the solar-terrestrial conditions. The Web GUI will be realised to respond to the user's requests both in synchronous and asynchronous modes. While in the synchronous mode, the user can immediately access, view, and analyse the results. In the asynchronous mode the job will be run in the background and the system will send the user a message to notify the activity, with information on the job and links to retrieve the results once the computation is completed. However, users will be encouraged to implement heavy computations and advanced data handling using ASPIS. py. The ASPIS. py module (WP2230) is a library of functions in Python that provides a friendly data analysis environment to ASPIS users.
This ASPIS. py module will be available for download and installation on the users' personal computers, but could also be used in online virtualisation solutions (e. g. , server-side Python Notebooks). It will include modules to access the data in the ASPIS DB, plus the whole range of methods for visualisation and analysis, plus the models provided by NODE1000 WPs. We envisage that, similarly to other Python libraries (e. g. , Sunpy https://sunpy. org/ (accessed on 1 October 2022)  [138] ) very much appreciated by the scientific community, it will ease the access and use of the products collected in ASPIS. Indeed, it is reasonable that the ASPIS. py module will build upon and extend existing relevant Python libraries, such as Astropy (https://www. astropy. org/ (accessed on 1 October 2022) [139]) or Sunpy itself.
These projects already provide a broad ecosystem of inter-operable Python packages, markedly created to analyse data in the astrophysics and heliophysics domains, which also include models to compare and interpret the data. Astropy (and later Sunpy) has set a new standard on how to obtain and analyse data. The rapid ascent in popularity of these Python packages is probably due to the combination of support (in term of documentation and use case examples), the open-source approach, and rapid development, both professional and community-driven. Learning from these successful experiences, we will realise ASPIS. py, the Web GUI, and the DB content (the ASPIS archive as a whole) to be as easy as possible to reach, use, and maintain for both the developer and the users. Consequently, we will create a wiki-like documentation structure (realised by WP2330).
This wiki will store and present the component and interface of ASPIS to ease its running, maintenance, and further extension, and all of the documentation created by CAESAR in the development of the APIs, the Web GUI, and the ASPIS. py module. All of the functional components of the ASPIS prototype are shown in Figure  5. Referring to this high-level scheme, we can briefly explain the ASPIS architecture and the various interactions between the WPs to build the ASPIS prototype. The NODE1000 Scientific WPs provide (red arrows in Figure  5 ): metadata, data, models, and methods used to populate the ASPIS DB; information on requisites for the web GUI and ASPIS. py module functionalities; and product specification and metadata. Product metadata descriptions are based on a template (black dashed arrow in Figure  5 ) provided by WP2310.
ASPIS. py and Web GUI actions performed upon user request (query, visualisation, download, and so on) will leverage (black arrows in Figure  5 ) the ASPIS DB interface APIs to the ASPIS DB. Web GUI services might rely on ASPIS. py methods to perform their tasks. All metadata, data, models, methods, and specifications, as well as the DB structure, tool descriptions, and module documentation will be continuously fed (purple arrows in Figure  5 ) to the ASPIS Wiki. Two user categories are foreseen: researchers (advanced users), who will take full advantage of the ASPIS functionalities through both the Web application and the ASPIS. py, and general users, who are expected to mainly exploit the Web GUI functionalities.
Acknowledgments: CAESAR is supported by the  Italian Space Agency  and the  National Institute of Astrophysics  through the  ASI-INAF  n. 2020-35-HH. 0  agreement for the development of the ASPIS prototype of scientific data centre for Space Weather. N. T. acknowledges the support from  ASI  through the  ASI-Unipg  agreement  2019-2-HH. 0.
Related Work Recognition of RNA Localization Pattern In previous studies, handcrafted features to classify RNA localization patterns were developed  [4, 7, 8, 9]. Their design has been inspired by literature on spatial statistics  [10]  and adapted from analysis pipelines for fluorescence microscopy images  [11, 12]. Several packages already implement modules to perform smFISH analysis and compute these hand-crafted features  [5, 13, 14, 15]. However, these approaches require to carefully design a set of features corresponding to the concrete biological question under study. For a different study a new set of features might be necessary. Here, we aim to investigate a more general approach to build localization features. Learning Representations Neural network learn powerful representations that can often be used for transfer learning.
The idea is to pretrain a network and thereby to obtain a generic representation by solving a pretext task on a large annotated dataset, before addressing a more difficult or specific task with sometimes limited data. Often the representation optimized to solve the pretext task can also be useful for the more specific task. Such a model can then be used as a feature extractor by computing features from one of its intermediate layers. The computer vision community progressively replaces hand-crafted features  [16, 17]  by deep learning features to analyze images. For instance, convolutional neural networks pretrained on large and general classification challenges  [18, 19, 20, 21]  are used as backbone or feature extractor for more complex tasks like face recognition, detection or segmentation.
The NLP community follows this trend as well with a heavy use of word embeddings  [22, 23]  or the more recent transformers models. The same strategy has also been applied to graphs: node2vec  [24]  learns "task-independent representations" for nodes in networks. Such embeddings can be a continuous and numerical representation of a nonstructured data like a text or a graph. In spage2vec  [25] , the model learned a low dimensional embedding of local spatial gene expression (expressed as graphs). Authors then identified meaningful gene expression signatures by computing this embedding for tissue datasets. Convolutional Features Since we analyze imaging data, a first intuition would be to build a convolutional neural network to directly classify localization patterns from these fluorescent images.
Such approaches have a long tradition in the classification of subcellular protein localization patterns. Unlike RNAs, proteins are usually difficult to resolve at the single molecule level unless super-resolution microscopy was employed, which is not the case for this kind of studies. Protein localization patterns is therefore seen as a characteristic texture in the fluorescent image and thus the representation of subcellular protein localization often relies on texture and intensity features. Initial studies  [26]  computed a set of handcrafted features from the microscopy image before training a classifier. With the advent of deep learning, protein localization is now tackled with convolutional neural networks, but still framed as a texture classification problem. After crowdsourcing annotations for the Human Protein Atlas dataset  [27] , researchers trained a machine learning model (Loc-CAT) from hand-crafted features to predict subcellular localization patterns of proteins  [28].