dataesr/scientific-paragraphs-categorization huggingface dataset:
A. EXPERIMENTAL SETUP For TEMP  [1]  and PM25  [2]  datasets, the sensing value of temperature ( • C)/PM2. 5 (air quality index) are located on each participant's mobile sensor in varying time slots (sensing cycle) and at different subareas. In details, the TEMP dataset contains the temperature readings in 57 cells (Subareas) and each sensing cycle lasts for 30 minutes. The PM25 dataset includes the PM2. 5 air quality values on 36 stations (Subareas) with the same sensing cycle. In order to simulate the settings of the centralized computing patterns, we aggregate the collected sensing data from each participant. In details, we follow the aforementioned three phases to set the appropriate value of four key factors: the Number of Participants (m), the Number of Subareas that each participant covers in each sensing cycle, the Size of Windows (w) and the Size of Latent Space (l).
C. EXPERIMENTAL RESULTS In this section, we report the performance of EdgeSense and other three baselines on TEMP and PM25 datasets. Specifically, we use the Absolute Error, which is the averaged element-wise difference We observe that the error is around 0. 2 to 0. 45 with varying maximum number of subareas from 1 to 5. It is noteworthy that EdgeSense can compete to STCS under these settings. Second, we also compare EdgeSense with baseline algorithms by varying the number of participants in the secure P2P network. In Fig. 4 (a), the maximum number of subareas is 1. Then we increase it from 1 to 4 in the increment of 1 in Figs. EdgeSense and STCS, the error decreases when the number of participants increases for both of these two algorithms. This demonstrates that the larger group of participants can improve the performance of the matrix recovery, where intuitively the participants can cover more subareas and sensing cycles.
Similar to the previous setting, EdgeSense can approximate the performance of STCS as well. Further, we alter the values of two aforementioned key factors, such as Size of Windows and Size of Latent Space, to observe the variation of the error. Fig. 5  shows that the error decreases when the window size increases from 20 to 50. Note that for each size of latent space in Figs. 5(b), (c ) and (d), the decreasing trends of the error are almost the same and the performance of EdgeSense still can compete with STCS. Fig. 6  exhibits that the error increases when the size of the latent space increases from 2 to 10. Thus, for TEMP datasets, the small size of latent space can better approximate the original data matrix when it is low-rank. Thus the performance of EdgeSense is still competitive to STCS, as shown in Figs.
2) PM25 DATASETS We conduct experiments with similar settings as TEMP datasets. Since the performances of RPCA and TSVD are still not as good as the other two algorithms, we only present the comparison between the proposed EdgeSense and STCS here. Specifically, in Table  1 , we list the Absolute Error of these two algorithms with varying number of participants (m) and the window size (w). When the number of participants increases, the error is decreasing intuitively. On the contrary, the error increases with increased size of the window. However, EdgeSense performs comparably to STCS, sometimes even better (e. g. , for m = 20). In Table  2 , we show the performance with varying size of latent space and the number of subareas covered by each participant. The results reveal that the number of subareas does not affect the error significantly, while with the larger latent space the error is smaller with PM25 datasets.
3) SUMMARY With two real-world datasets, we compared the proposed EdgeSense with the baseline algorithms STCS, RPCA and TSVD. For both of the datasets, EdgeSense significantly outperforms RPCA and TSVD in most cases. Moreover, compared to the algorithm STCS, EdgeSense also presents its competitiveness, with a low approximation error (0. 2 • in city-wide temperature and 10 units of PM2. 5 index in urban air quality). Even in some settings, the EdgeSense has a lower approximation error than STCS, which demonstrates the superiority of EdgeSense.
,t -R * a,t /(|S| • |T |) between the recovered matrix ( R) and the original data matrix (R * ), as the indicator of the performance. 1) TEMP DATASETS First, we present a comparison of algorithms with the settings of the maximum number of subareas (covered by each participant) ranging from 1 to 5 in Fig. 3. Due to the overall better performances of EdgeSense and STCS, we present the entire comparison in (a) and only compare EdgeSense with STCS in other three settings (the same in Figures 4, 5 and 6 as well). Specifically, in Fig. 3(a), 10 participants are involved. Then we vary the number of participants from 10 to 40 in the increment of 10 in Figs. 3(b), (c) and (d).
Haoyi Xiong  (xhycccThis work was supported in part by the  National Key R&D Program of China  under Grant  2016YFB0800602 , in part by the  National Natural Science Foundation of China (NSFC)  under Grant  61502048 , in part by the  Shandong Provincial Key R&D Program of China  under Grant  2018CXGC0701 , and in part by the  Missouri S&T Smart CPS   Startup Grant.
Quantification of cell numbers, performed using Imaris software on confocal images from the macula, revealed that 7m8 infected 10,310 RGC's, not certified by peer review) is the author/funder. All rights reserved. No reuse allowed without permission. The copyright holder for this preprint (which was this version posted November 20, 2019. ; https://doi. org/10. 1101/847459 doi: bioRxiv preprint while NHP#9 infected 4,296. In contrast, NHP#9 infected 2202 cones, compared to 1019 cones infected by 7m8 (Figure  5G, H ). qRT-PCR, performed using the ∆∆CT method, revealed an 11. 71  (10. 37 -13. 22 ) fold increase of GFP expression in foveal cones relative to 7m8. The top-ranking variant from the GFP barcode screen, Loopswap variant ~583-LQRGVRIPSVLEVNGQ (designated NHP#26), was also tested for validation despite the limitation that reduced production of this vector enabled only a low dose.
Deep sequencing of AAV libraries from rounds of selection A ~75-85 base pair region containing the 7mer insertion or Loop Swap mutation sites (semi-random mutations at surface exposed regions, for a description of Loop Swap library construction see (  13 ) ) was PCR amplified from harvested DNA. Primers included Illumina adapter sequences containing unique barcodes to allow for multiplexing of amplicons from multiple rounds of selection (Supplemental Table  2 ). PCR amplicons were purified and sequenced with a 100-cycle single-read run on an Illumina HiSeq 2500. Custom Python code was written for analysis. First, the DNA sequences encoding amino acid insertions, found between constant linker DNA sequences were identified. Then, DNA sequences were translated into amino acid sequences. The number of reads for each amino acid insertion sequence was then counted, across the AAV library and across rounds of selection.
Deep sequencing of GFP-barcode libraries Barcodes were PCR amplified directly from DNA which was harvested from primate retinal tissue. Samples were collected from areas across the retina, and from ONL or RPE. Primers amplified a ~50 bp region surrounding the GFP barcode and contained Illumina adapter sequences and secondary barcodes to allow for multiplexing of multiple samples (Supplemental Table  2 ). PCR amplicons were purified and sequenced with a 100-cycle single-read run on a MiSeq. Read counts were normalized by total number of reads in the run. Analysis of barcode abundance was performed using custom code written in Python, followed by creation of plots in Pandas. Barcodes were identified as variable DNA sequences found between constant sequences in the expression cassette, which surrounded the barcode.
Discussion This study reveals that, beyond the expected signaling at the plasma-membrane, a signaling path might also operate from Ras to RalB, via RGL2 and other RalGEFs, at endomembranes. A detailed spatial quantification of this intracellular signaling was possible by exploiting the novel "Endomapper" method to evaluate protein localizations at endomembrane compartments. The main advantage of Endomapper over the existing methods is that it quantifies the localization of a protein of interest at specific compartments with respect to randomly generated pseudo-compartments, correcting for co-localization occurring by chance and thus allowing robust statistics even on not obvious images. Moreover, the analysis task is fully automated by the use of a biologist-friendly free-access plugin with the ImageJ software.
A 1. 67 μm-wide band from the cell periphery was segmented to measure the FRET ratio at the cell edges. To measure FRET in endomembrane compartments, the endomembrane compartments were first segmented using co-transfected specific markers (RFP-Rab5A, mCherry-Rab11, and mCherry-LC3), then FRET ratio were measured in these regions. Image processing with endomapper plugin. The Endomapper method was developed to be used with ImageJ software  46  (https://imagej. nih. gov/ij/). The plugin can be downloaded from: https://github. com/mfor-manu9/Endomapper. git The execution of Endomapper plugin pops up a window that asks user to enter some parameters such as pixel size, approximate size of endomembrane compartments, numbers of randomized compartments, input and out folder path. The input image for Endomapper is a dual channel image in which one channel corresponds to protein of interest and the other channel to endomembrane compartments.
Acknowledgements We thank the Cell and  Tissue Imaging  ( PICT-IBiSA ) platform,  Institut Curie , member of the  French National Research Infrastructure France-BioImaging  ( ANR10-INBS-04 ). We are very grateful to  Sabine Bardin  and  Bruno Goud  for kindly providing us with Rab5,  Rab6 , and Rab11 plasmids. This work was supported by  Fondation ARC pour la Recherche sur le Cancer  ( PJA 20151203371 ),  Institut national de la Santé et de la Recherche médicale (INSERM ITMO Plan Cancer   2014-2018 ,  PC201530 ), and  Association Christelle Bouillot.
g. , from Spark in our prototype, collecting the records read and written, bytes read and written, bytes spilled to disk, fetch wait time, etc. ; (iii) OS-level metrics such as CPU, IO, and network usage. This trace data is written to a database as being collected (step 5). B. In-situ modeling: If the job is seen the first time, trace collection will be run for a period of time (e. g. , 10 minutes). Then in-situ modeling is activated (step 6). It takes as input (i) the traces for the new job, and (ii) a global deep learning model, Λ = (Λ 1 , Λ 2 ), trained offline using all past jobs (to be detailed shortly). In-situ modeling performs two tasks: (1) It transforms the new traces into a numerical vector and runs it through the encoding model Λ 1 to derive a formal description (encoding) of the current job, denoted by W.
DEMONSTRATION Our demo showcases UDAO developed on top of Apache Spark, such that the user can understand i) the difficulty of manual parameter tuning, and the effect of these parameters on user objectives as indicated by the automatically learned models; ii) the tradeoffs between user objectives, and how a system recommended configuration explores these tradeoffs; iii) end-to-end benefits that UDAO can provide over manual performance tuning; iv) comparative analysis between our techniques and alternative techniques. Specifically, our demonstration has the following modules: 1. Benchmarks. We developed two benchmarks based on the needs specified by two cloud service providers. (a) Big-Bench (TPCx-BB) for batch analytics includes 30 workloads, which can be divided into 14 SQL tasks, 11 SQL with UDFs and 5 ML workloads.
Overview of Middleware Approaches for IoT Several studies on middleware approaches for IoT have been proposed like the classifications presented in  [92, 93]. A specific study is presented by Razzaque et al. in  [94]. In this paper, authors have analyzed in depth several existing solutions and have presented a recent overview of the different kinds of middleware architecture. Thanks to this study, we have identified the different types of middleware (see Fig. 1 ) for intelligent environments that have been classified as follows: Application-specific, Agent-based, VM-based, tuple-spaces, databaseoriented, Service-oriented architecture and Message-oriented Middleware.
Database-Oriented: This middleware approach considers the whole sensor network as a distributed and virtual database. It uses SQL like queries to collect data over the network. GSN  [4]  is a database-oriented middleware that has been integrated into other projects such as OpenIoT  [68]. While this approach offers good programming abstraction and proper data management support, the remaining IoT requirements are not necessarily addressed like scalability, real-time and spontaneous interactions. Moreover, its centralized nature makes it difficult to handle dynamic and heterogeneity characteristics of the IoT network. The architectures as mentioned above have been used in many specific IoT projects and research area. However, the important use of Service Oriented Architecture (SOA) and Message Oriented Middleware (MoM) solutions is remarkable in IoT projects in the past decade.
e. , the service interface is independent of the implementation). Service providers describe their services (sensors characteristics) and expose them to consumers. Web Services Description Language (WSDL) is the standard used for such a description  [38]. A state of the art of SOA-based middleware solutions for wireless sensor network can be found in  [81]. It refers to SStreaMWare, USEME, SensorWeb 2. 0, OASiS, B-VIS, MiSense, SOMDM (SI), SOA-MM as middleware proposals for wireless sensor networks. Their main features are supporting real-time monitoring, management of heterogeneous devices, data collection and filtering. However, the survey demonstrates that none of these solutions covers all the requirements of the management of sensors network in intelligent environments. More recent approaches have tried to enhance the SOA features and adapted it to IoT.
Privacy & security Medical applications are mainly installed at hospitals and retirement homes to prevent, detect diseases or even monitor patients health condition. AAL applications are mainly installed at a patient's home to monitor and follow his/her health and activity at home. In this context, middleware solutions have been proposed to fulfill the requirement of IoT and healthcare domains. -Middleware for Medical applications: In this strand we find the Sphere project  [120]  that follows a clustered-sensor approach. It aims to build a generic platform that fuses corresponding sensor data to generate rich datasets that support the detection and management of various health conditions. LinkSmart  [85]  within the REACTION European project is another SOA-based middleware with the aim of monitoring and managing the diabetes of patients as well as their therapy in operational healthcare environments.
Discussion Middleware proposals based on Application-specific, Agent-based, VM-based, tuple-spaces and database-oriented, have tried to tackle the requirements of manageability and heterogeneity of IoT environments. These approaches have been used in specific IoT applications, and their limitations stated in each case make them not so popular in this environment. Moreover, it is clear that the most used approach in the IoT world is SOA-based architecture, in particular, most healthcare solutions rely on SOA-based middleware. However, we recognized that even if SOA presents a good solution for IoT healthcare applications, it can not meet all IoT requirements especially related to heterogeneity, scalability, real-time processing and flexibility. From the other side, we recognized that although a few recent studies have considered the MoM approach, it has been recognized as a flexible and suitable communication model in IoT.
The Web Ontology Language (OWL) built upon a W3C XML standard is a Semantic Web language designed to represent rich and complex knowledge about things, groups of things, and relations between things. It can easily be integrated with many programming languages like Java through APIs (Jena or OWL-API). Ontologies in IoT have an essential role in representing sensors networks (physical aspect and infrastructure) and also in describing complex domain knowledge and concepts. Furthermore, the main advantage of using ontologies is the possibility to generate OWL representations which provide the opportunity to exchange formal messages at the technical layer in OWL format. Describing data in a formal language such as OWL guarantees the reliability of information and improves the interoperability of the system.
It is a hierarchical system approach where sensors collect data from the real world and send it to clusterhead-node. In Bandadouche et al. in  [15] , authors present the limitation of SSN in describing the communication process of a wireless sensor network. They propose a new ontology design pattern Stimulus-WSNnode-Communication, an extension of SSN, that addresses the communication limitation by integrating new concepts that describe the communication process of a wireless sensor network. Another extension for SSN based on fuzzy logic is proposed in  [14]  to support fault tolerance and for large-scale Wireless Sensor Network. It is a service-oriented approach to build diagnosis and test services for wireless sensors. Authors in  [96]  present another SSN extension ontology for WSN, and it is presented as an alignment of many ontologies SSN, SWRLTO, TAO, and DOLCE.
In the same context, authors in  [70]  proposed an ontology to describe the patients vital signs. The ontology aims to create a profile for each patient containing the several medical control information. Moreover, authors in  [23]  present an example of food ontology for diabetes control. The HL7 Security and Privacy Ontology is another example that serves to name, define, formally describe, and interrelate key concepts within the scope of Healthcare Information Technology. Kim et al. [69]  proposed an Ontology-driven Interactive Healthcare with Wearable Sensors (OdIH WS) to achieve customized healthcare service. It aims to acquire context information at real-time using ontological methods by integrating external data such as a meteorological website in order to prevent disease. ContoExam  [20]  is an ontology developed to address the interoperability problem of sensor networks in the context of e-health domain applications.
It contains specific expressions and specifications for medical use as examination vocabulary and expressions. -Ontologies for AAL applications: In this context, Activities for Daily Living (ADL) is a contemporary topic. Researchers are working in improving the quality of life of elderly at home by providing monitoring systems. In this strand, Ontologies-based solutions have been proposed to describe human activities and behavior like in  [76]. These ontologies propose a description of a set of actions and activities of daily life where the activity is inferred from several actions  [26, 27]. For example, going to the kitchen, taking a cup, and adding water are single actions and drinking is an activity. The CoDAMoS  [37]  ontology focuses on modeling roles, hardware, and software services around four main core entities: user, environment, platform, and service.
OpenIoT aims to propose on-demand access to cloud-based IoT services for Internet-connected objects. Trying to use sensing as a service, OpenIoT architecture embeds the CUPUS middleware as a cloud-Based publish/subscribe processing engine and relies on SSN for sensors description. The observed data is stored as linked data and processed based on SPARQL queries which are continuously executed as data arrive. It can be viewed as a federation of several middleware projects interconnected with each other targeting applications for smart cities or campus and agriculture domain. OpenIoT could have been a good candidate to target IoT health applications, but its complexity due to the variety of middleware solutions under use can be a major drawback for the programmer. The aforementioned middleware projects seek to tackle general IoT requirements without taking into account specific IoT application domains.
CHOReOS  [53]  enables large scale choreographies or compositions of adaptable, QoS-aware, and heterogeneous services in IoT. It provides a scalable probabilistic thing-based service registration and discovery to address scalability, interoperability, mobility, and adaptability. It uses ontologies for semantic enrichment over the architecture. The semantic thing based service compositions are transparently and automatically executable with no involvement from end-users, which is highly desirable in IoT, especially in M2M communications. [17]. Beside a MOM communication model, authors rely on ontology as semantic description processing module whose purpose is to generate a semantic database that provides the basis to decide whether a WSN node needs to be reconfigured or not.
We have studied these solutions and classified them in Table  2  taking into consideration how the semantic description in each solution is addressed. -AllJoyn Lambda  [112]  relies on Bus-D architecture and offers an open source framework for the management of IoT environments. It can be seen as a software solution integrating AllJoyn in the Lambda architecture used for Big Data storage and analytics. This proposal offers a graphical user interface (GUI) for devices discovery and management, secure data transport between communication technologies (Wi-Fi, Bluetooth, etc. ), interoperability between different OS and notifications interface that sends/receives human readable messages. A simple smart home case study has been tested using this approach. It consists on turning on/off devices at home.
Semantic descriptions have not been considered in this approach. -Kaa 9  is a server-endpoints platform with the aim to create IoT applications including applications for healthcare, agriculture and smart city. It has been promoted as compatible virtually with any type of connected devices, sensors, and gateways. However, Kaa requires the integration of a specific microchip in the hardware of the IoT device which can be problematic for commercial sensors. -Mango 10  is a modular web-application framework. The main functionalities offered by this proposal are data collection, real time data monitoring, high performance database, logic and automation, security, cross platform, graphic dashboard and internal performance monitoring. It is based on a list of middleware and on an application that is compiled into a single HTTP server object.
But there is no full description including sensors, sensor data and domain. Moreover, the semantic description in SOA architectures has been proposed in order to describe services which refer to sensors specifications in IoT systems. For example, XML schema has been proposed in SM4ALL  [25]  for sensors description and used as a contract for applications service description. Other semantic description techniques can also be noticed like model driven architecture for devices description in  [62]  and Linksmart 16. Lately, ontologies have gained sufficient importance for knowledge and sensors description as it is presented in SOPRANO  [105] , Sensei  [91]  OpenIoT, SMArc, UBIWARE and OM2M. Another important aspect of this comparison study is the lack of messages and domain description in these propositions, we can see that two ontologybased solutions OM2M and XGSN/OpenIoT have considered OWL format for exchanging messages.