dataesr/scientific-paragraphs-categorization huggingface dataset:
The quantification of SDF-1 signal in αSMA + cells was done with Qupath v. 0. 2. 3 105 through a custom-made script. Briefly, cell nuclei were detected on DAPI channel with the StarDist extension and a cell expansion of 1 um was applied in order to measure fluorescence in the cytoplasmic/membrane cell's area. For the nuclei segmentation with StarDist, a custom model was trained and tested using the StarDist (2D) network in ZeroCostDL4Mic 106 : a training dataset was generated by the manual annotation of nuclei in QuPath and labeled images were exported for the deep-learning training; the model's training and quality control assessment were performed with the StarDist (2D) notebook. For the detection of pixels positive for αSMA staining, a pixel classifier was created with the QuPath's function Create thresholder and the quantification of the positive area inside each segmented cell was added as a measurement parameter in the detection's results table.
scRNAseq analysis Single cells of samples from 11 patients (each one sequenced in the far tumor (D) and tumor site (T)) were sequenced with the 3' v3 chemistry and aligned using Cellranger count v. 3. 1 on human genome hg38. Only droplets with a minimum number of unique molecular identifiers (UMI) were considered as "cells"; this was done by default by the Cellranger program. Based on total cells in each patient and the distribution of each patient's cells within groups identified by UMAP, we excluded patients 3, 8, and 6 from further analyses. Thus, 52316 cells were processed. We used the Seurat v. 3R package to analyze single cell data 107. To identify cell populations or sub-populations, uniform manifold approximation and projection (UMAP) was carried out from the first principal components of the PCA based on the expression of the most variable genes, normalized using SCT transformation as suggested in Seurat documentation ("SCTransform" function 108.
Survival analysis methods We investigated the interplay between immune cytolytic activity and neutrophils infiltration on overall (OS) and disease-free survival (DFS) in the colon adenocarcinoma cohort (COAD) of The Cancer Genome Atlas (TCGA) 111 by performing a Kaplan-Meier analysis. The cytolytic activity index was quantified by computing the geometric mean of granzyme A and perforin expression 112 and samples were split according to the Maximally Selected Ranks Statistics cutoff ("maxstat", version 0. 7-25). Neutrophils relative abundance was obtained by running CIBERSORTx 112 with a validated leukocyte gene signature matrix (LM22) on RNAseq data of COAD samples. Samples were divided into two groups according to the presence or absence of Neutrophils. Similarly, CIBERSORTx-derived gene expression signature was employed to infer the GZMK high cell subtype' abundance and analyze its association with survival.
First, the single-cell raw counts matrix of CD8 + T EM population was split into two subgroups expressing "high" or "low" values of GZMK and used it to feed CIBERSORTx, building a gene signature able to discriminate the two cell sub-populations. Secondly, we collected survival tables of TCGA-COAD and TCGA-LUAD cohorts from cBioPortal 113 and ran Kaplan-Meier analysis stratifying patients with "high" and "low" infiltration of CD8 + T EM cells expressing high levels of GZMK. Survival analyses were carried out on R software version 4. 0. 5), by using "survival" (version 3-2-11) and "survminer" (version 0. 4. 9) packages.
Statistics and data visualization Results were analyzed and visualized on Prism version 9. 2. 0 (Graph-Pad). All statistical analyses were conducted using GraphPad Prism version 9. 2. 0 or R software version 4. 0. 2. Differences between two groups were calculated by two-tailed Student's t test, unless otherwise specified. For graphs with multiple comparisons being made, one-way ANOVA was performed with post hoc Sidak's test or Tukey's test for multiple comparisons, unless otherwise specified.
Acknowledgements We thank  Phil Greenberg  for critical review of the manuscript, patients involved in the study and their families and  IEO's Biobank (B4Me), Molecular Pathology Unit, Genomic Unit  (in particular  Thelma Capra  and  Lucia Massimiliano ), Flow Cytometry and  Imaging Unit at IEO  for their technical assistance. We thank  Leonardo Nezi  and  Lara Nezi  for their support and insightful discussions. This work was supported by  Associazione Italiana per la Ricerca contro il Cancro ( AIRC StartUp  Grant  21474  to TM,  AIRC IG 26406  to L. N. and  AIRC   IG 20676  to E. L. ) and  Worldwide Cancer Research  ( WWCR 22-0402  to L. N. ). CC was supported by donations from cancer survivor  Ms. Paola Merico  through  Fondazione IEO -CCM. A. M. was supported by  Fondazione IEO-CCM 's fellowship.
Data availability The transcriptomic data generated in this study have been deposited in the European Genome-Phenome Archive (EGA) under accession code Study: EGAS00001006665-Dataset: EGAD00001009634. The transcriptomic data are available under restricted access in accordance with art. 13 General Regulation on Data Protection (EU Regulation 2016/679), access can be obtained by request to EGA and approval by the competent Data Access Committee. Please contact the corresponding authors for access requests. The TCGA-COAD and TCGA-LUAD gene expression data used in this study are publicly available in the GDC Data Portal (https://portal. gdc. cancer. gov/). Survival tables of TCGA-COAD and TCGA-LUAD cohorts were downloaded from cBio-Portal (https://www. cbioportal. org/). The remaining data are available within the Article, Supplementary Information or Source Data file.
The X4-prototype setup to verify these tests is shown in Figure  1 , whereby a carbon fiber frame coupled with two brushless motor pairs of MULTISTAR 4220-880 Kv and two ESC (Electronic Speed Controller) pairs of 30 A capacity. The sampling period is 10 ms and the altitude was fixed by the operator using a Futaba 2. 4 GHz FASST radio system for transmitting the control signals. Several test cases were completed in the Quadrotor helicopter built to evaluate the efficiency of this type of robust controller with the following initial conditions (x, ẋ, y, ẏ) = (0, 0, 0, 0) and (φ, θ, ψ) = (0, 0, 0) and a path given by L x = 15 m and L y = 10 m with t f = 35 s. The second order sliding modes approach described in Section 3 is then implemented in C++ environment and run in real-time on the Pixhawk module which is embedded in the X4-prototype setup (see Figure  11 ).
One pipeline for streaming (''speed layer'') and one for batch processing (''batch layer''). An extra layer (''serving layer'') stores the output and responds to ad-hoc queries. The batch layer utilizes a distributed processing system to process all available data. As processing takes time, the batch layer can push fewer updates. Additionally, to fix errors the system needs to recompute the complete dataset. The speed layer processes the most recent data and provides a (near) realtime view of the data. In its original form, it did not aim for completeness as it tried to fill the gap caused by the batch layer's lag. However, real-time data is a requirement for today's data platforms. Finally, the serving layer stores output from the batch and speed layers. Additionally, it also responds to ad-hoc queries.
The Kappa Architecture  [13]  aims to be a simplification and evolution of the Lambda Architecture by removing the batch processing component. In the Kappa Architecture the canonical data store is an append-only immutable log. It is used instead of a relational database management system (RDBMS) or noSQL store like Apache Cassandra  [14]. From this log, data is streamed through the processing pipeline and fed into supplementary stores for serving. All data is moved through the stream processing system quickly eliminating the need for the batch layer. The Open Group Architecture Framework (TOGAF)  [4]  is a widely used framework for general enterprise architecture. It includes an approach for designing, planning, delivering, and governing an enterprise information technology architecture. It distinguishes two building block types: Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs).
ABBs are higher level architecture models. They encapsulate a set of technology, application, business and data requirements and steer the development of SBBs. Additionally, they incorporate the relationship and interoperability with other building blocks, and should be reusable. SBBs on the other hand, are lower level components and are directly guided by ABBs. As discussed in section I, public cloud providers publish low-level reference architectures for different use cases to help commercialize their services. One such provider based architecture is the Azure IoT Reference Architecture  [15]. It defines three data paths for data analytics. The hot path represents near real-time insights using stream analytics; the warm path uses fine-grain methods, but incurs a higher latency; finally the cold path represents batch processing performed at greater intervals.
Microsoft also provides more generic data processing architectures, for example in  [16]  Apache Kafka  [17]  is used as a streaming source to ingest data. In these architectures as a best practice for ingestion, data is always fed into a streaming service. For example, in the discussed Azure IoT Reference Architecture, data ingested into Azure EventHubs, which is the Azure platform equivalent of Apache Kafka. FIWARE  [18]  provides reference architectures, consisting of several building block like components that facilitate architecture building. FIWARE is a framework of open-source components for data management, for developing interoperable smart solutions. As part of the framework FIWARE provides different components such as the ''Orion context broker'' for data management, IoT agents for connecting smart devices, components for storing historical data such as ''Comet'', and also components for data analytics among many others.
Additionally to a standards-based platform, FIWARE provides a complete ecosystem as well. It was originally driven by the European Union to develop a platform for the Future Internet. Isah and Zulkernine  [19]  present a fault-tolerant and scalable data management framework for many feeds of structured and unstructured data. The presented framework consists of reusable building blocks. Additionally, the authors demonstrate the framework using a real-world data streaming case study. They rely heavily on Apache NiFi  [20]  to provide a dataflow that integrates Apache Kafka  [17]  and HDFS  [21]. Their architecture is stream processing only, and is an implementation of the Kappa architecture, although not referenced by the authors. Airbnb built the Minerva  [22] -  [24]  metric platform to standardize data analytics at scale within the company.
III. DATA ANALYTICS PLATFORM Our goal was to build a reusable, open-source, vendor agnostic and end-to-end platform for IoT data analytics using industry best practices. We designed the platform to primarily support the ingestion of high-frequency time series data. All ingested data is stored in raw format. This allows to execute new and improved versions of our data processing tasks on the complete dataset. The platform provides data exploratory tools and also capabilities to move developed data processing services into production. Data access is provided through standardized interfaces such as Amazon S3, Apache Kafka and ODBC for data warehouse access. The platform is container based. We use Docker for convenience purposes when a full virtual machine (VM) would be dedicated to a service component.
There a single shared instance of the core components serves all use cases. The platform is stream processing based for delivering ingested data to the end user. It is similar to the presented Kappa Architecture (see section II). However, we retain the capability of executing batch jobs to support existing workloads. Our platform implements the hot-warm-cold path for data presented in the Azure IoT Reference Architecture (see section II). The hot path provides a low-latency pipeline relying mainly on MQTT and Apache Kafka for ingestion; with Logstash, Elasticsearch and Kibana (the ''Elastic stack''  [34] ) for the real-time analytics stage. The warm path is used for more complex processing and delivery to the data warehouse for further analytics. The warm path also relies on Apache Kafka, however, supports non-structured data uploads using an Amazon S3 compatible interface as well.
The cold path involves the same stages as the warm path (i → ii → iii → v), and executes batch workloads using data in the data warehouse. Additionally, we provide a dedicated business intelligence stage (v) that is responsible both for visualization and data insights. Next, we are going to discuss the stages in detail. The ingestion and staging stage is responsible for accepting and storing incoming data. The platform supports both time-series and blob (unstructured) data. Currently, MQTT and native Kafka for streaming data; Amazon S3 for non-structured or blob data; and Open Database Connectivity (ODBC) for relational data are supported. In our experience MQTT is common ground for IoT devices and similarly, S3 is for blob data. For MQTT there is no restriction on the format and structuring of data, JSON payload and/ or Sparkplug-B  [39]  structuring is preferred.
We currently use Eclipse Mosquitto  [40]  as MQTT broker for ingesting data. The throughput of Mosquitto is limited by single-thread CPU performance  [41]. Currently this does not cause a bottleneck for the use cases of the platform. However, we are investigating alternative, distributed solutions such as EMQX  [42]. Additionally, the first stage of the platform acts as a staging area for all incoming data. Data here is kept in its raw source format, thus this area is effectively the data lake of the platform. The processing stage is responsible for enriching, transforming and transferring data to persistent storage and real-time analytics. For this we rely mainly on a set of services. First, we use Apache NiFi for orchestrating the dataflow between the building blocks of the architecture.
Additionally, ksqlDB and custom Kafka micro-services are responsible for additional data transformation and enrichment within Apache Kafka. Apache NiFi is responsible for ingesting data from the MQTT broker acting as the MQTT interface of the platform. NiFi is also a Kafka producer and pushes the ingested data to the desired Kafka topic. Additionally, it is a Kafka consumer, it reads data from the topic, performs simple conversions (e. g. , flattening JSON structures and type conversions) and pushes the results to the data warehouse, TimescaleDB  [36]  in our case. An example data-flow is shown in figure  2. Apache NiFi relies on the ''Zero-Leader Clustering paradigm'', this means that each node in the cluster has the same data flow and performs the same tasks on the data. The cluster automatically distributes the data between the nodes.
Pre-processing with Apache NiFi involves light transformations. With our use cases (see sections III-A and III-B) we ingest data in JSON format and use the JOLT transformer of NiFi to e. g. , convert between data types, flatten nested structures, and include additional metadata. ksqlDB allows working with Kafka based streams using an SQL-like language with the scalability of Kafka Streams. In turn Kafka Streams is a client-side Java library that abstracts the low-level Kafka APIs (Producer and Consumer). It utilizes a streaming approach: it ingests from sources, performs transformations on the ingested data, and finally forwards data to sinks. Additionally, it allows scaling by automatically handling the assignment and balancing of the workload based on the number of partitions and application instances running (via Kafka consumer groups).
However, as it is a library it does not contain a resource manager or scheduler, as the application developer should bring its own. This means that Kafka Streams applications are suited for containerization, especially deploying on Kubernetes. We perform additional stream-based transformations using ksqlDB running on a Kubernetes cluster within the platform, and support Kafka Streams-based custom micro-services as well. The Data Warehouse stage is responsible for storing and serving data. We rely on TimescaleDB  [36]  for storing timeseries data. It is an extension on top of PostgreSQL, which is in turn used for storing relational data and data warehousing functionality overall. This allows storing both relational and time-series data in a single data store. The data warehouse is based on a relational database (PostgreSQL -TimescaleDB), thus, incoming data must be transformed into this schema.
We rely on the ConvertJSONtoSQL processor of NiFi for JSON type messages, see ''5. Convert JSON To SQL'' in figure  2  for more details. We would like to note here, this is pure transformation as enrichment is done in a previous step using the JoltTransformationJSON processor, see ''4. Jolt Transform JSON'' in figure  2  for more details. The resulting data forms the base core dataset for each use case. Using this dataset we perform further near real time processing in TimescaleDB, e. g. , aggregate using different time periods; and also run offline batch workloads as needed. The Business Intelligence (BI) stage is responsible for providing dashboard and visualization capabilities. Currently, Apache Superset is extensively used on top of the data warehouse, with Grafana as second choice, and Kibana in the hot path, see figure  3  for more details.
The Reinforcement Learning Toolbox of Matlab is running on a dedicated Windows-based virtual machine (Matlab agent) due to performance considerations. The Python-based RL agent is being evaluated as an alternative to Matlab and deployed on a separated Ubuntu-based virtual machine (Python agent). These machines can directly communicate with the Hil environment through the VPN connection with ROS protocol. Lastly, the ingestion component (ROS ingestion) is running on another Linux based virtual machine. This component acts as a ROS-MQTT bridge for ingesting data from the HiL environment with ROS protocol and forwarding it to the Kafka streaming component via protocol for further analysis.
The Node exporter of Prometheus collects the most relevant metrics data from the virtual machines and makes it available at an HTTP endpoint. Prometheus scrapes the metrics from the HTTP endpoint and stores it for visualisation and later use. The Kafka cluster uses the m2. xlarge VM flavor, which contains 8 vCPUs and 16 GB of RAM. The loader cluster utilises the m2. large VM flavor, which includes 4 vCPUs and 8 GB of RAM. Both clusters are based on Ubuntu 20. 04 operating system and uses Kafka version 3. The deployment of the temporary load cluster was done via Terraform. Terraform makes the benchmark process more straightforward, easy to replicate and customizable as needed. The benchmark started with a Python script that uses Ansible as a core component to distribute the benchmark configuration and start the benchmark process on the load cluster.
This work was supported in part by the  National Research, Development and Innovation (NRDI) Office-NKFIH, Hungary , under Grant  ED_18-2-2018-0006  and Grant  SNN 129178 ; and in part by the  Ministry of Innovation and Technology NRDI Office  within the framework of the  Autonomous Systems National Laboratory Program. The work of  Róbert Lovas  was supported by the  Janos Bolyai Research Scholarship of the Hungarian Academy of Sciences.
Objective: We aimed to compare objective measures of physical activity to increase the generalizability and translation of findings of studies that use accelerometry-based data. Methods: High-resolution accelerometry data from the Baltimore Longitudinal Study on Aging were retrospectively analyzed. Data from 655 participants who used a wrist-worn ActiGraph GT9X device continuously for a week were summarized at the minute level as ActiGraph activity count, monitor-independent movement summary, Euclidean norm minus one, mean amplitude deviation, and activity intensity. We calculated these measures using open-source packages in R. Pearson correlations between activity count and each measure were quantified both marginally and conditionally on age, sex, and BMI. Each measures pair was harmonized using nonparametric regression of minute-level data.
Accelerometry Data Collection and Export Data had been collected with a triaxial accelerometer (ActiGraph GT9X Link; range: ±8 g; frequency: 80 Hz). Participants had been instructed to wear the accelerometer on their nondominant wrist for 7 days, except for periods of extended swimming or bathing. The ActiLife software (version 6. 13. 4) was used to (1) export data into GT3X file format, (2) derive and export minute-level ActiGraph activity count as CSV files, and (3) export raw acceleration data (in g) as three-dimensional time series with subsecond-level timestamps into CSV files. The ActiLife's low-frequency extension (a filtering option that decreases the lower end of the intensity threshold to increase sensitivity to low-intensity movements) was used based on recommendations and findings of greater comparability with older ActiGraph devices (model 7164)  [11].
Summary Measures of Raw Accelerometry Data Commonly used minute-level measures-monitor-independent movement summary, Euclidean norm minus one, mean amplitude deviation, and activity intensity (Multimedia Appendix 2  [4, [7] [8] [9] )-were calculated using raw accelerometry data. With R software (version 3. 6. 3; The R Project), we developed and used SummarizedActigraphy R package to compute the measures. SummarizedActigraphy is a package that provides a unified data interface to compute a range of measures; it references original software for computing monitor-independent movement summary (R package: MIMSunit  [13] , version 0. 9. 2) and calibrating data for computation of Euclidean norm minus one (R package: GGIR  [14] , version 2. 3).
Minute-Level Accelerometry Data Preprocessing We defined minute-level data flags that represented whether the device was being worn or not using the get_wear_flag method (R package: arctools  [15] ; version 1. 1. 4), which implements a wear status detection algorithm based on activity count data  [16]. A given minute was classified as nonwear if it belonged to a 90-minute interval with consecutive 0-values in activity count data; otherwise, the minute was classified as wear. A given minute was valid if no raw data-level quality control flags had been triggered within the minute and it had been classified as wear, and invalid otherwise. A valid day was defined as a day (12:00 AM to 11:59 PM) with no more than 10% (144 minutes)  [17]  invalid minutes. Only data from participants who had at least 3 valid days of data, and only data from valid days, were included in further preprocessing and analyses.
Statistical Data Analysis The mean daily sums of minute-level measures were computed for each participant and then aggregated (mean and SD; median and range) across participants. Pearson correlation coefficients for 4 pairs of measures-activity count and monitor-independent movement summary, activity count and Euclidean norm minus one, activity count and mean amplitude deviation, and activity count and activity intensity-were computed for each participant. For each pair, mean correlations and standard errors were quantified using intercept-only linear regression with participant-specific correlation as the outcome. The effects of demographic characteristics (covariates: age, BMI, and sex) on correlations were estimated using adjusted linear regression with participant-specific correlation as the outcome and α=.