dataesr/scientific-paragraphs-categorization huggingface dataset:
Introduction Mobile crowdsourcing platforms and applications are being widely used to collect datasets in the field for both industrial and research purposes  [4, 14, 61]. By relying on a crowd of user devices, mobile crowdsourcing delivers an engaging solution to collect insightful reports from the wild. However, the design of such platforms presents some critical challenges related to the management of users, also known as workers. In particular, the privacy of the workers is often underestimated by the crowdsourcing platforms and it often fails to be addressed effectively in practice  [44]. Official approvals from Institutional Review Boards (IRB) and regulatory bodies addressing worker privacy do not only require consent from workers to collect data from their mobile devices (e. g. , app permissions, privacy policies, end-user license agreements), but suggest the use of data anonymization mechanisms to minimize the risk of privacy leaks  [30].
We evaluate the effectiveness and the impact of our anonymization scheme on these two mobile crowdsourcing systems by deploying and orchestrating a crowd of 15 emulated mobile devices. More precisely, we replay the cab mobility traces  [60]  and we show that Fougere defeats state-of-the-art privacy attacks  [28, 43, 46]  with little impact on the quality of the resulting datasets. The remainder of this article is organized as follows. Section 2 provides background knowledge on mobile crowdsourcing platforms and discusses the related work in the domain to privacy applied to the areas of mobile crowdsourcing and location-based services. Section 3 provides an overview of the privacy threats in crowdsourcing apps and platforms. Section 4 introduces our anonymization scheme and the integration of Location Privacy Protection Mechanisms (LPPMs) to increase the workers' privacy.
Background on mobile crowdsourcing and user privacy With the ubiquity of the mobile devices, both scientific and industrial communities leverage the sensors of the mobile devices to collect insightful information about the user. As depicted in Fig. 1 , mobile crowdsourcing campaigns typically consist of several stages: (i) the description of the data to be crowdsourced, (ii) the deployment and the gathering of the dataset in the wild, (iii) the aggregation and storage of datasets in the Cloud, (iv) the processing and (v) publication of the campaign results. However, along all these stages, Sensitive Personal Information (SPI) can be conveyed by the mobile app and potentially be subject to attacks from adversaries, therefore motivating the development of a better privacy support. We identify 4 categories of SPI that can be collected by crowdsourcing campaigns and might be exploited by adversaries: Identifiers group all persistent or transient identifiers that can take the form of a device ID (IMEI) or Google account ID, for example, to explicitly identify a worker from the perspective of a mobile crowdsourcing system.
Location privacy threats When studying the location privacy threats in crowdsourced datasets, we consider that the adversary can exploit two dimensions of knowledge  [77] : spatio-temporal information and context information. In the context of mobile crowdsourcing systems, spatiotemporal information refers to the capability of the adversary to access a history of crowdsourced data-i. e. , several measurements reported by a single worker. In the case of a compromised storage server (or connection to the storage server), such an assumption holds as the adversary can get access to sufficiently large volume of crowdsourced data to build some spatio-temporal knowledge. Beyond spatio-temporal information, context information refers to any additional information that an adversary can exploit. This covers embedded knowledge that is included in the crowdsourced dataset (e.
In particular, spatial-temporal clustering algorithms, like ST-DBSCAN  [7] , can be used in such a case to group the worker's traces together. In the case of dense areas, an adversary can use the speed of the workers to group the locations related to a given trajectory  [16]. However, the performance issue of such techniques must be taken into consideration  [75]. Finally, given a dataset of workers' location traces with timestamps, Mobility Markov Chain (MMC) attack  [27]  reports on the workers favorite POIs with labels, such as home, work, or shopping. Then, by correlating these POIs with a map, it can reveal SPI about her work and her home, which combined with a public phone directory can deduce her full name and leave opportunity to query social networks, etc. Most of these attacks are implemented within privacy evaluation tools  [11, 49, 64, 69].
Location Privacy Protection Mechanisms (LPPMs) LPPMs are an interesting mechanisms that can be used to limit user privacy leaks  [12]. A large body of the related work has been devoted towards the latest stages of mobile crowdsourcing campaigns by improving the privacy properties of datasets once uploaded to remote servers  [17, 42, 48, 58, 63, 73, 78]. These techniques contribute to preserving the privacy of workers while limiting the sanitization impact on the quality of the resulting dataset. In particular, Gambs et al. [26]  propose a toolkit called GEPETO to enhance the privacy of spatio-temporal datasets by applying a sanitization process. They provide a tool to sanitize spatiotemporal datasets and to measure the privacy and the utility trade-off of the resulting dataset. Ma et al. [46]  discuss some vulnerabilities found in mobility traces.
In a formally detailed approach they explain how an adversary can identify workers using complementary metadata collected while observing workers. Baik et al. [3]  propose a new algorithm to achieve guaranteed anonymity in a spatio-temporal dataset; they focus on the home identification and user tracking privacy threats. While all of these works focus on protecting the collected dataset, raw datasets stored on a remote server may be leaked through security breaches. Moreover, early stages of mobile crowdsourcing campaigns remain exposed to privacy attacks (e. g. , man-in-the-middle). This issue has been identified as an open challenge by Christin et al. [21]. Later, Christin et al. [20]  have proposed a detailed approach that requires the involvement of participants in the anonymization process.
The APISENSE platform provides a web interface to monitor and to control the crowdsourcing campaign. Through this web interface, the campaign manager (the scientist) can invite new users, update the data acquisition script and update it in realtime. The campaign manager can visualize the anonymized user data, as soon as they are uploaded to the server. Although, these received data do not contain any user identifiers, it needs to be further anonymized before starting to process the collected data.
Privacy-preserving mobile crowdsourcing platforms Mobile crowdsourcing platforms are used to collect data about the contributing users, these data include some Sensitive Personal Information (SPI), which introduce privacy issues. This is why researchers are actively working on privacy protection mechanisms for crowdsourcing platforms  [8, 29]. Table  2  summarizes the work related to the privacy of mobile crowdsourcing platforms. Anonysense. Cornelius et al. [22]  have proposed a mobile platform for opportunistic sensing called Anonysense. Because the server hosting the collected dataset can be used to trace the worker's wireless access points, they use an anonymization network to hide the worker locations and they rely on a third-party server for routing the data. Anonysense also supports reporting data with a statistical guarantee of k-anonymity.
Privacy threats in mobile crowdsourcing systems This section discusses the potential threats in mobile crowdsourcing systems along 2 axes: the system model and the sensitive personal information. Mobile crowdsourcing system model. The architecture we consider is a mobile crowdsourcing campaign that involves three components, namely, mobile devices, crowdsourcing apps, and storage servers. We consider that the mobile crowdsourcing apps can be trusted as we believe that the owner of the mobile crowdsourcing app or platform is interested in gathering insightful datasets with the consent of workers, especially if this mobile app is open sourced. However, we consider that the storage server can be compromised and reveal some sensitive personal information on behalf of the owner and the workers.
While crowdsourced datasets are expected to be anonymized prior to any online publication or reuse  [2, 12] , the potential threats we consider encompass a remote or physical access to the storage server to steal the raw crowdsourced dataset prior to the application of any anonymization technique. Another similar threat may involve a man-inthe-middle (MITM) attack to intercept the crowdsourced data while it is uploaded to the remote storage server. For example, no matter if they are deployed in the cloud or on-premise, the remote storage servers may suffer from security leaks that can be exploited by an adversary. Moreover, stakeholders who get the data before its anonymization can hold it without anonymizing it, knowing that anonymization will decrease data utility, or because they do not know exactly how to process the dataset.
We use mobility datasets that are publicly available to control the emulated devices and we collect their interactions to trace their actions a posteriori. The crowdsourced dataset collected on the remote server are evaluated by the LPM 2 toolkit  [69]  to evaluate the preservation of workers' privacy. By adopting such an empirical validation, we can evaluate real applications integrating Fougere and we can observe the impact of changing the parameters of Fougere (number of hops, LPPMs' specific parameters). In the remainder of this section, we select the legacy Mo-biPerf  [40]  mobile app as the mobile crowdsourcing app that we considered to assess Fougere. Emulating crowds of workers. The assessment of our opportunistic dissemination scheme and the associated LPPMs requires the consideration of a crowd of workers who installed a mobile crowdsourcing app that integrates Fougere.
While running an emulator on a single machine is rather resource-consuming and cannot scale, we propose to consider the deployment of a cluster of servers to host multiple Android emulators. As Android emulators do not provide any support for ad hoc communications, such as WiFi-Direct, we use AndroFleet  [51]  to control the discovery of nearby peer-to-peer devices within a cluster of emulators. In Fig. 4 , we show the integration of Fougere in the An-droFleet cluster. In particular, the AndroFleet master node takes as input an app binary (MobiPerf. apk), a mobility dataset (SfCabs. txt), and a set of interaction scenarios (Scenario. feature). It deploys the app binary and the set of interaction scenarios within each emulator and loads the mobility dataset into the Elasticsearch service. The AndroFleet master collaborates with the Discovery controller to control the virtual location of emulated devices.
Controlling crowds of workers. To assess the efficiency of Fougere using AndroFleet, the emulated devices are required to be controlled in order to update their location and eventually internal state, to reproduce the mobility of a crowd of workers. While the choice of a mobility dataset can be challenging depending on the category of mobile crowdsourcing app, we used the widely used epfl/mobility dataset that is publicly available from CRAWDAD  [60]  to emulate 15 workers who are performing network measurements with the MobiPerf mobile app. The crowdsourced dataset contains network measurements reported every 5 min by the workers moving in the San Francisco bay area.
Attacking crowdsourced datasets. To evaluate the impact of Fougere on the privacy of workers, we use the LPM 2 toolkit  [69] , which is a state-of-the-art tool for measuring location privacy. In particular, LPM 2 covers the evaluation of the LPPMs that are supported by Fougere, like the privacy filters, privacy distortions and privacy aggregation. To validate Fougere against privacy attacks, for each configuration, we run an experiment that follows these steps:  1. Run AndroFleet with MobiPerf and Fougere (incl. privacy settings), 2. Assign tasks to workers during 3 days, and wait 4 more days for the data dissemination to complete, 3. Gather the logs of data exchanges between workers to evaluate the opportunistic dissemination scheme, 4. Retrieve all the raw crowdsourced data stored on the remote server, 5.
Empirical evaluation In this section, we instantiate the above experimental protocol to assess Fougere as a practical support to improve the location privacy of workers. Experimental Setup. Thanks to the AndroFleet  [51, 52]  emulation platform, we can reproduce the execution of a deployment of 15 mobile instances emulating a one-week crowdsourcing campaign, thus proposing a realistic input dataset to evaluate Fougere. Then, we compare the behaviors of 6 configurations of the MobiPerf app: 1-Vanilla refers to the reference implementation of the Mo-biPerf Android app, as it can be downloaded from http: //www. mobiperf. com. This configuration is used to demonstrate the vulnerability of legacy mobile crowdsourcing apps with regards to potential privacy threats. It is also used as a witness to evaluate the benefits of the other configurations including Fougere; 2-Fougere with no LPPM refers to the extension of Mo-biPerf with the Fougere library.
This configuration is used to isolate the properties of our opportunistic dissemination schemes independently of the impact of LPPMs. In particular, we consider the following worker configurations for the number of required hops to disseminate the crowdsourced data and the WiFi-Direct discovery scans: None of these configurations includes a privacy filter, as these LPPMs are expected to be used to hide the living and working places of workers and the input dataset does not include this information. Furthermore, this article does not aim at evaluating the efficiency of individual LPPMs, but rather demonstrating the benefit of combining them in an open framework like Fougere.
Utility analysis. While Fougere aims at improving the location privacy of workers, the utility of the resulting dataset should not be neglected. The data utility is calculated using the similarity provided by the LPM 2 toolkit. Then, the data utility corresponds to the number of similar locations between the locations of data received on the server and the locations of the original raw data before anonymization. Fig. 8  reports on the tradeoff between utility and the anonymity of the configurations we considered. While the vanilla configuration (1) offers the highest utility with no anonymity, one can observe that the integration of Fougere seriously improves the anonymity of workers without seriously impacting the utility of the resulting dataset. As mentioned in Fig. 6 , the loss of 20% utility is mainly due to crowdsourced data in sparsely populated areas that were retained by Fougere.
Robustness analysis. Regarding the effective privacy support offered by Fougere, we used the LPM 2 toolkit to evaluate the robustness of crowdsourced datasets that are uploaded through Fougere, this metric correspond to the LPM 2 toolkit's distortion metric 6   [68] , which measures the location-privacy of the worker at each time instance. We randomly select the crowdsourced data reported by one of the workers as the adversary knowledge required by LPM 2 to apply location privacy attacks and we depict in Fig. 9  the reported robustness for 14 workers. While LPM 2 successfully defeats worker 3 (used as the adversary knowledge), the other 14 workers clearly benefit from the integration of Fougere. In particular, we can observe that the integration of LPPMs complements efficiently our opportunistic dissemination scheme by supporting workers who are not located in a dense area and by offering similar privacy guarantees.
Successfully location privacy attacks requires to combine different strategies to cope with the profile of workers. While Fougere offers the worker the possibility to manually adjust her privacy settings, one of the perspectives of this work consists in leveraging this configuration process by delivering privacy risk feedback that would guide her settings accordingly. By recommending the privacy settings of Fougere, we aim at maximizing the individual privacy of workers, while preserving the overall utility of the crowdsourced dataset (cf. Fig. 8 ). Uncertainty analysis. Finally, the uncertainty metric evaluates the uncertainty that our LPPMs introduce to the adversary when she tries to reconstruct the hidden information from the crowdsourced dataset on the server. Fig. 10  reports on the uncertainty metrics computed by LPM 2  [69].
Thus, we are not assuming that our results can be used to generalize the impact of a specific LPPM on privacy. However, we believe that this work contributes to prove that there is a clear positive impact for the privacy threats we considered. Reliability validity focuses on the possibility of replicating our experiments and results. We attempt to provide all the necessary details to replicate our study and our analysis. Furthermore, the reference implementation of Fougere, the input datasets, case studies and testing environment are made available online to leverage its reproduction by the research community. Construct validity has been covered by considering the convergent validity of privacy and utility properties. We observed that these two properties are related in practice, as the application of LPPMs tends to decrease the utility of the crowdsourced dataset.
None of these four genes have a known function and none are Spok homologs. We examined their predicted protein domains, searched the P. anserina genomes for homologs, and scanned genomic databases for similar sequences in an attempt to discern whether they may be integral to the movement of the Enterprise (Supplementary Table  3 ). Only one of the genes is a likely candidate for enacting the transposition of the Enterprise. This gene is always present as the first ORF in the Spok block, but is degraded and interrupted by multiple TEs in Wa139. The ORF possesses multiple domains which may be characteristic of specific transposons, as determined by bioinformatic analysis (see Methods): a domain of unknown function called DUF3435, a zinc finger domain, and a predicted CHROMO domain (Figure  1D ).
Kirc is wide-spread in filamentous fungi Given the fact that Enterprise is present in at least one species outside of Podospora, we queried GenBank with the sequence of Kirc using BLASTp to determine how widespread Enterprise is. We recovered a total of 481 protein hits, which were almost exclusively from within the Pezizomycotina, although putative homologs were identified from ten basidiomycete genomes as well. A phylogeny of a representative set of sequences shows that the relationships among the homologs do not follow the expected species phylogeny (Figure  2 ). Numerous species have multiple Kirc homologs in the same genome, some of which are not closely related. For example, within P. anserina, one homolog was recovered, Pa_5_10116 (see  Espagne et al. (2008)  for Podospora gene notation), which appears to be distantly related to Kirc, yet highly similar to homologs from Fusarium.
2019). It is possible that the burden imposed by the Spok block on the host is quite high, leading to selection to purge most copies in nature. To evaluate this hypothesis, we made use of backcrosses of two of the Psk strains  (Vogan, Ament-Velásquez, et al. 2019 ). The backcrossed strains Psk1xS 14 and Psk7xS 14 are isogenic with the reference strain S, except that S has no Spok block. Psk1xS 14 has the Spok block on chromosome 3 and induces killing in 90% of meioses, and Psk7xS 14 has the Spok block on the left arm of chromosome 5 and induces spore killing in 50% of meioses. We crossed strains either to themselves (no spore killing) or to strain S (spore killing) and evaluated a number of traits related to fitness. Radial growth and time to germination of spores produced by the matings showed no variation between crosses (data not shown), however significant differences were observed among the amount of spores produced by a cross (Figure  3 ).
2. 11 and Miniasm v. 0. 2  (Li 2018 (Li , 2016)). The resulting assembly was polished twice with Racon v. 1. 3. 1  (Vaser et al. 2017 ) using all MinION reads (no filtering). Further polishing was done with the filtered Illumina reads in five consecutive rounds of Pilon v. 1. 22  (Walker et al. 2014). We used BWA v. 0. 7. 17  (Li and Durbin 2010)  for short-read mapping, with PCR duplicates marked using Picard v. 2. 18. 11 (http://broadinstitute. github. io/picard/), as well as local indel re-alignment using the Genome Analysis Toolkit (GATK) v. 3. 7 (Van der  Auwera et al. 2013). We assigned the scaffolds to chromosomes based on alignments to the reference genome of the S strain  (Espagne et al. 2008 ), available at the Joint Genome Institute MycoCosm website (https://mycocosm. jgi. doe. gov/mycocosm/home) as "Podan2"  (Grigoriev et al.
Genome annotation A GitHub repository is available with Snakemake v. 5. 4. 4 (Köster and Rahmann 2012) pipelines relevant to genome annotation at https://github. com/johannessonlab/SpokBlockPaper. The TEs and other repeats in P. anserina were classified previously by  Espagne et al. (2008)  based on the original reference genome of the S strain or "Podan1", and is hereafter referred to as the "Espagne library". To explore the diversity of TEs in the newly generated Podospora genomes, we identified repeats de novo and manually compared them to the Espagne library to identify duplicates and new elements. Specifically, we ran RepeatModeler v. 1. 0. 8 (http://www. repeatmasker. org/RepeatModeler/) on the scaffolds larger than 50 kb of all available long-read assemblies (Snakemake pipeline PaTEs.
Specifically, we mapped the reads of the monokaryotic isolate Wa63-(P. anserina) to the assembly PaWa63m  (Vogan, Ament-Velásquez, et al. 2019) , of the monokaryotic isolate Wa131-(P. comata) to the assembly PcWa139m (this study), and of the dikaryotic Psk7xS 14 (P. anserina) to the assembly PaWa58m  (Vogan, Ament-Velásquez, et al. 2019). We then processed the mapped reads with Cufflinks v. 2. 2. 1  (Trapnell et al. 2010 ) to obtain the transcript models. As external evidence, we used CDS from the Podan2 annotation, protein sequences from the T strain of P. comata  (Silar et al. 2019) , and a small dataset of manually curated proteins. To aid in manual curation of selected regions (mostly the Spok block), we visually inspected the mapping of RNA-seq reads of the different datasets, along with CDS produced with TransDecoder v.
5. 5. 0  (Haas et al. 2013 ) on the Cufflinks models, as well as the output of RepeatMasker ran externally from MAKER with the PodoTE-1. 00 library. Additionally, we queried predicted gene models into the NCBI databases (NCBI Resource Coordinators 2016) to verify the annotations. The Kirc protein sequence was analyzed with HHPred  (Zimmermann et al. 2018 ) and Gremlin  (Balakrishnan et al. 2011). The Gremlin-generated alignment of Kirc homologs was used to generate region-specific sequence logos with Weblogo  (Crooks et al. 2004). The relationship of Kirc to other YRs was confirmed by comparing the sequence to the crystal structure of known YRs (CRE (PDB code 3mgv), XERD (1a0p), and FLP (1flo)) as well as the protein sequence from the transposable element Crypton-Cn1 using the software Promals3D  (Pei, Kim, and Grishin 2008).
The fraction of conservation between blocks compared to the block in Wa137 was calculated by aligning the block sequences (within the TSD) of Wa28 (Psk-2), Wa53 (Psk-1), Wa58 (Psk-7) and Wa139 with NUCmer and the BEDtools utility genomecov. The Snakemake pipelines used to produce the Circos plots (CircosBlock. smk and CircosAllBlocks. smk) are available at https://github. com/johannessonlab/SpokBlockPaper.