dataesr/scientific-paragraphs-categorization huggingface dataset:
However, we observed considerable shift between different sessions, resulting from different non-stationarity sources. Figure  5  illustrates the two dimensional representation of two first runs of sessions 12-18. All these sessions were 4-class training sessions (LEFT-HAND vs. RIGHT-HAND vs. MENTAL-SUBTRACTION vs. REST) recorded during the transfer phase. We used t-SNE  (Maaten and Hinton, 2008)  to project the data points (EEG covariance of one epoch/trial) in two-dimensional space. For dimensionality reduction using t-SNE to consider the non-linear geometry of the feature space, we used the Riemannian distance as the custom distance parameter. In addition, we set the effective number of local neighbors of each point (i. e. , the Perplexity parameter) to the number of epochs extracted from each task in each run (i.
Evaluation Criteria To evaluate the user's progress, besides classification accuracy, we also used studied two additional metrics that study users' EEG changes: classDis and Test-Train Adaptation. classDis measures how distinct and stable the EEG patterns produced by the user are, independently of any classifier  (Lotte and Jeunet, 2018). For a two-class problem, classDis is defined as follows: classDis(c i , c j ) = d R (C (c i ) , C (c j ) ) 1 2 (σ c i + σ c j ) ( 12 ) where the numerator computes the distance between class means and the denominator is the summation of average squared distances around the Karcher mean of each class. For multi-class problems, the numerator of classDis computes the distance of the Karcher mean of each class C (c i ) from the Karcher mean of all the data C, as follows: classDis(c i ) = i d R (C (c i ) , C) i σ c i (13) where C (c i ) and C are the Karcher mean of each class and of all the data, respectively.
Exploratory Phase Due to the exploratory and non-systematic nature of this phase, online classification accuracies were not recorded for every run or session. The mean online accuracy for the runs where this data was recorded is reported in Figure  7A. The dashed line in this figure shows the upper-confidence limit of the chance level for α = 0. 05 and 20 trials/class  (Müller-Putz et al. , 2008). The nonsystematic ways the sessions of that phase were performed also made comparing classDis across sessions non-meaningful. We thus did not report it for that phase.
ACKNOWLEDGMENTS The authors would like to deeply thank our CYBATHLON pilot for his endless motivation and patience without which this study would not have been possible. We are also grateful to our pilot's care persons' support and kindness. The authors would also like to thank the reviewers for their thoughtful and constructive comments and efforts which certainly contributed to improve our manuscript, and notably helped us to come up with new and relevant metrics and analyses. The  European Research Council  with project  BrainConquest  (grant  ERC-2016-STG-714567 ) and the  French National Research Agency  with project  REBEL  (grant  ANR-15-CE23-0013-01 ) supported this work.
By addressing these questions, we conduct two types of research, obtaining a literature review. To perform this study, we searched in the first type for scientific databases papers hosted in Google Scholar, IEEE, ResearchGate, ACM, etc. In the second type, we browsed several whitepapers and blogs on sites related to certain researchers who have conducted studies on the same topic. DLT technology is a relatively new subject adopted by supply chains, and this novel subject has a limited number of reviews  [30]. [24, 25]  Organizes the theoretical implications of adopting Blockchain in supply chains. Scully and H¨obig (2019)  [26]  Analyzes the impact of DLT on different supply chain flows through case studies.
3-1-Traditional supply chain challenges The supply chain experiences enormous variations over time, with high demand on integrating it with IoT technology. Consequently, the current supply chain infrastructure investments surcharge the traditional systems with high loads, leading to information loss  [19]. The current supply chain infrastructure constitutes multi-centralized-based organizations where each represents an independent platform that belongs to one or more supply chains. These systems depend profoundly on standalone, often different, and centralized platforms  [16]. The group of databases involved in the production are autonomous, heterogeneous, and distributed  [32]. Therefore, the inflexibility in interchanging data among these databases is referred to as the hard-coded nature of different data form standards.
Two obvious examples are Walmart and Cisco  [33]. The collaboration would be limited due to the organizations' desire to use their platforms and control their data. They use different protocols and workarounds to enable interoperability to a particular supply chain. XML, ebXMB, and UDDI are some workarounds used to facilitate interoperability, but they are ineffective in heterogeneous databases due to different standards of databases. File transfer that uses fix format such as XQuery is the only protocol used to interchange data between organizations  [32]. The uncontrolled informational data of the centralized systems causes outsize counterfeit, huge information loss, and bad business reputation. The widespread IoT adoption is triggering profound changes in global manufacturing  [34]. Basically, the IoT systems are heterogeneous and categorized under various administrative areas  [35].
Furthermore, every Tx is stored permanently on the Blockchain ledger, while storing low-value information is futile. The inability to compact or reduce the ledger's undesired data augments the challenges. Network infrastructure is likewise a primary factor for a successful Blockchain. All nodes involved in the DLT system should be continuously connected and synchronized to maintain the P2P network. However, high network requirement is inconvenient with IoT's nature. Mainly, most of the supply chains distribute their IoT devices in different geolocations. Providing good throughput is costly and unstable, which poses security risks and/or data instability. Conjointly, Tx fees are still a significant drawback in Blockchain resulting in Tx delays in the process  [58].
e. Editable Blockchain The well-known immutability and irreversibility features of Blockchain are a two-edged sword. Although these features provide the supply chain with many benefits, they bring some drawbacks. Blockchain suffers from the inability to cope with the high incoming information of the vast IoT environment because of the components that compose its structure. The data recorded in a ledger is permanent, which reflects negatively on the ledger size and pushes all nodes to store the negligible data forever. The feasibility of having an editable Blockchain  [71]  is not available yet, as it still requires more research. Edit or remove a block(s) due to mistakes, typos, attack impacts, temporary records, or negligible data without breaking the chain enhance Blockchain adoption and scalability.
5-1-DLT-based supply chain In this part, we resume the maximum number of projects that interact with DLT and IoT technologies mentioned in previous work  [40]. Below are the supply chain projects:  Shipchain [80] is a fully integrated system of the entire supply chain that is specialized in tracking the shipments from the moment of leaving the factory to the final receiver customer's. Shipchain is running on Ethereum public blockchain using mainly smart contract techniques and side-chain. All the Records are stored on the Ethereum database, while side chain data are stored and validated on the organizations' network for cost-saving purposes. Thereby, the data is located either on Ethereum public ledger or in the side chain ledgers where no intermediary is engaged. Moreover, shipchain contains a web platform that enables shippers to connect directly to carriers without passing by the traditional brokerage models.
 Devery  [81]  is an open-source protocol based on the Blockchain Ethereum network for verification services. This protocol is used to build applications for verification purposes where sellers can allocate unique signatures to their products. The signatures are stored on the Ethereum ledger and used in verifying a product throughout the application queries. Devery protocol consists of three data structures that interact with Ethereum through DeveryRegistery. sol and DeveryTrust. sol smart contracts. The three data structures are StructApp, unique identifier, and account. StructBrand is used to register a brand public key alongside the unique identifier of an application and store the brand information. Struct Product contains the app account, brand account, and product information. The hash of the product information determines the individual identifier for each product stored on the Blockchain and allows lookup via the check (address item) method.
The API and blockchain layers are separated, and the database layer is based on MongoDB and Cassandra.  BlockGrain  [88]  is a decentralized platform using Ethereum Blockchain for the agriculture supply chain. BlockGrain is structured into three main layers: public Blockchain, Private Blockchain, and applications. The main data, smart contracts, and Tx Agri tokens are located on the public Blockchain, while buyers utilize the private Blockchain to reduce the costs of both Txs and waiting times associated with a public blockchain. The Blockchains are managed through the applications Layer of the BlockGrain Platform.  ZERO defects [89] is a DAG-based platform in order to track supply chain products. It is announced through a collaboration between Pickert (ISO certified company) and the IOTA Foundation.
The POST mechanism strengthens the security of the Blockchain. The subchains are free to choose either POS or POST or any other consensus algorithm that fits their application requirements. To create a subchain, the creator consumes WTC on the parent chain, so basic information regarding the new subchain is registered in the current parent block. The creation of a new subchain can be customized based on its nature and conditions. Subchain features mainly include WTC token, subchain token, cross subchain token Txs, smart contract, account control, data storage, etc. Waltonchain considers the IoT side tool by developing the RFID chips to integrate Blockchain better while tagging assets. But this development is limited to IoT functionality, and it does not tackle the IoT weaknesses mentioned above (computing resources and storage).
5-2-2-OriginTrail OriginTrail  [61]  is a supply chain solution that integrates different partner applications, off-chain networks, and Blockchain. It makes use of different nodes, as shown in Figure  3. Some nodes, which are not DLT-based, implement off-chain within the decentralized environment. Some other nodes are involved in the Blockchain platform. The offchain network is known by ODN (OriginTrail Decentralized Network), which is composed of data and network layers. The architecture is thus the stakeholders' applications, the non-blockchain decentralized ODN, and the Blockchain platform. OriginTrail uses the "one step down, one step up" traceability principle to define the stakeholders and their inputs. This principle allows any stakeholder from its position to track back and forward the source and the destination of a product.
Using a Blockchain platform is to store the data fingerprint, ensuring integrity and transparency of records and providing an immutable supply chain system. OriginTrail protocol uses the consensus check mechanism to validate data provided by different stakeholders. The consensus check mechanism consists of three steps: Step1: approve the stakeholder by the previous one. Step 2: verify the matching stakeholders. Step 3: verify the matching transactional data and timestamps. It uses the zero-knowledge mechanism to prove private information without revealing them. Four node types are involved in the OriginTrail structures distinguished by their roles: Data provider (DP): represented by the stakeholders, organizations, or consumers with data input to be shared with the supply chain. Data Creator (DC): it is the entry node toward the OriginTrail network.
This selection is automatically made to avoid the DC-specific selection of DH node(s). Off-chain is the most prominent invented tool of OriginTrail that is represented by the ODN network. The decentralized ODN nodes employ the Blockchain platform to ensure their immutability and data integrity. In this context, Blockchain can be a cloud-based platform that facilitates communication between the different nodes of ODN. The none DLT-based solution provides scalability for the system as it discharges nodes from the computing and power consumption tasks. However, the system is exposed to a vulnerability attack if Blockchain and ODN are disconnected or being forcibly isolated. Besides, the "one step down, one step up" traceability principle provides end-to-end traceability, but a stakeholder is limited to two strides of visibility.
5-2-4-Ambrosus Ambrosus  [95]  project is to track products throughout their circulation in the market. It is a supply chain Blockchainbased dedicated mainly to protect and control pharmaceutical products and food values. This solution is principally composed of a customized version of Ethereum-Blockchain integrated with a data storage solution named interplanetary file system "IPFS" as illustrated in Figure  5. To avoid the high cost of running the Txs on the main Ethereum platform, Ambrosus develops its independent customized version of Ethereum. Besides, Ambrosus does not rely on Ethereum storage to store the supply chain data as it is limited in capacity. It makes use of IPFS as the main storage for their large Txs to provide scalability and high throughput for the clients. Ambrosus take advantage of the Merkle tree hash cryptography in their transactional processes.
With this tree algorithm, users can quickly find their data and filter out the wrong inputs. Two types of smart contracts are introduced: the requirement smart contract to describe quality standards to be directly compared to items inside the Measurements Smart Contract. The measurement smart contract holds the list of the Merkle tree root hash, ambrosus-certified devices, and the collected attributes throughout the supply chain to note the variation of compositions' quality, if any. The Merkle tree data is uploaded periodically to the main Ethereum network to reduce network problems and improve scalability. The main structure of the Ambrosus network consists of three main layers: layer 1 contains the Ethereum blockchain and the IPFS storage. Layer 2 represents the supply chains and smart contracts, offline verification, and off-chain operations.
5-2-5-Modum Modum  [96]  is a supply chain for monitoring solutions that control the distribution of immense volumes of sensitive goods, especially pharmaceutical ones. It comprises the Ethereum blockchain network, the API applications, and a specific sensor called modum temperature logger. Modum architecture constitutes of frontend and backend phases, as illustrated in Figure  6. The backend comprises an Ethereum network, smart contracts, and a specific server connected directly to external users. The frontend comprises sensors and mobile applications connected to the HTTPS server in the backend via REST API and JSON. The SensorTag (Logger) is the top added value that is used to measure the environmental conditions of the shipments. Each logger owns a unique MAC address represented in QR code and each shipment has its unique QR named "track and trace.
" Both QR codes to be scanned by the user's mobile applications and sent to the server. In case the server is not available, data will be stored on the logger's internal memory. Once received the combination QR codes, the server broadcasts the smart contract, then store the ID of the smart contract on the sensor. Then the client scans the "track and trace" code and requests the temperature measurements from the sensor via BLE "Bluetooth low energy. " The smart contract obtains the data for verification purposes and sends back a report to the mobile client. It certifies data authenticity at every change of ownership. The evaluation results are immutably stored in a Blockchain as of proof-of-existence. In this way, open the package to verify the content become useless. The "modum temperature logger" sensor is used to track precisely the temperature of drugs periodically alongside the supply chain.
Although cloud is considered a suitable place for large ledger size, some data are meaninglessly stored, such as records related to food after consumption. Wherefore, they must be removed. The editing block of a Blockchain ledger breaks the immutability rule of the new decentralization. Nevertheless, Editing blocks is necessary in many cases. Using Chameleon Hash Function  [72]  could help compress the ledger, but it is still not applied, neither as a pilot nor in production supply chain projects. Suppose the Blockchain becomes editable in the future without risking the integrity of the data. In that case, it will ease off the supply chain from a large amount of undesired/old data, thereby compressing the ledger size as either on-cloud or on local nodes.
6-2-Off-Chain Layer The off-chain layer focuses on offloading part of the workload outside the Blockchain platform using either centralized or decentralized systems. In a supply chain, the off-chain tool is proposed within the DLT-based supply chain to reduce Blockchain's storage, save the computing effort, and speed up the Tx process. Moreover, the off-chain is proposed in the supply chain to hide precise information privately and reduce the Tx cost  [15]. Technically, Ambrosus uses the IPFS (Interplanetary File System) decentralized storage system to offload the massive data outside the Blockchain so that the cost and the ledger size are reduced. Nevertheless, IPFS is not secure since the IPFS files are accessible to anyone in the network. Also, IPFS is inflexible with corresponding data.
Another distributed scenario introduced by OriginTrail called ODN creates an independent decentralized platform to decentralize the Tx processes outside the Blockchain ledger. At the same time, ODN is managed by Blockchain smart contracts to ensure controlling the whole system's integrity. In this regard, all ODN nodes are controlled by Blockchain while offloading a large amount of data outside the DLT ledger. The creation of a decentralized mechanism outside the Blockchain, controlled by the smart contract, is attractive. However, this off-chain platform requires an additional implementation, which is problematic for the additional distributed nodes and their resources. Thus, current off-chain solutions do not help in achieving the typical supply chain. Wherefore, further off-chain enhancements are required to effectively extend its benefits of privacy enablement, high performance, and storage reduction.
The High-Luminosity LHC will open an unprecedented window on the weak-scale nature of the Universe, providing data to perform high-precision measurements of the Standard Model, as well as searches for new physics beyond the Standard Model. Such precision measurements and searches require information-rich datasets with a statistical power that matches the high luminosity provided by the upgrade of the LHC. Efficiently collecting these datasets will be a challenging task, given the harsh environment of up to 200 proton-proton interactions per LHC bunch crossing. For this purpose, CMS is designing an efficient two-level trigger system: the Level 1 Trigger (L1T), implemented in advanced hardware, and the High Level Trigger (HLT), a streamlined version of the CMS reconstruction software running on a computer farm.
The L1T will include tracking information and high-granularity calorimeter information for the first time. The current conceptual system design is expected to take full advantage of FPGA and link technologies over the coming years, providing a high-performance, low-latency computing platform for large throughput and sophisticated data correlation across diverse sources. The envisaged L1T system will closely replicate the full offline object reconstruction, to perform more sophisticated and optimized selection. The higher luminosity, event complexity and input rate of 750 kHz present an unprecedented challenge to the HLT, which aims to achieve a similar efficiency and rejection factor as today, despite the higher pileup, and a purer preselection. The introduction of a heterogenous platform combining CPUs and GPUs is described.
Introduction The High-Luminosity LHC (HL-LHC)  [1]  presents the opportunity for a very rich and ambitious physics program, exploiting an integrated luminosity of 3000-4000 fb -1. The LHC will undergo major upgrades of its components leading to an increase of the instantaneous luminosity to 5 × 10 34 cm -2 s -1 , five times the accelerator's original design value. In its "ultimate" configuration, the HL-LHC will reach a peak instantaneous luminosity of 7. 5 × 10 34 cm -2 s -1 , increasing the average number of proton-proton collisions per bunch crossing (pileup) to around 200. The ultimate performance of the HL-LHC would enable the collection of 400 to 450 fb -1 of integrated luminosity per year, potentially providing a total of 4000 fb -1 to each of the CMS and ATLAS experiments. The CMS detector requires a trigger and data acquisition system with exceptional performance to collect the required information-rich datasets with these challenging running conditions.
Along with the sub-detector upgrades  [2] , a complete replacement of the trigger, including the Level-1 (L1) and the high level trigger (HLT), and data acquisition (DAQ) system, with increased throughput, is planned. The Phase-2 1 upgrade of the trigger and DAQ system will keep a two-level strategy, while increasing the L1 maximum rate to 750 kHz to maintain the acceptance for physics. The total latency will be increased from 3. 8 µs to 12. 5 µs to allow, for the first time, the tracker and high-granularity calorimeter information to be included. Trigger data analysis will be performed through sophisticated algorithms, including widespread use of Machine-Learning in large FPGAs  [3]. Similarly to Phase-1, the Phase-2 HLT will have access to the full granularity of the detector with the target for average timing per event of 500 ms (measured on a 2018 HLT node).
The CMS detector for Phase-2 In order to fully exploit the HL-LHC running period, major consolidations and upgrades of the CMS detector are planned  [2]. Given the high particle multiplicity expected, the performance required on event object reconstruction to achieve the extraction of physics signatures relies on the implementation of higher granularity detectors along with robust readout electronics. The CMS collaboration plans to replace both the Strip and Pixel tracking detectors, with an Inner Tracker featuring small-size pixel sensors and an Outer Tracker equipped with strip and macro pixel sensors, extending their coverage to |η| = 3. 8. The Outer Tracker will implement stacked strip modules, reducing the hit multiplicity and allowing track candidates for the trigger (L1 tracks) to be reconstructed up to |η| = 2.
5 µs (to retain 20% contingency). The trigger algorithms are designed with the extensive use of tracking information to reach near offline performance. The availability of fully reconstructed tracks translates into sharper turn-on efficiency curves. Algorithm implementation in firmware relies heavily on High-Level-Synthesis, allowing for faster turn-around and the development of new approaches, such as those based on Machine-Learning techniques. With the availability of tracking and high granularity detector data, global event reconstruction algorithms such as particle-flow can be implemented. Particleflow reconstruction  [5]  has been successfully used by CMS in offline data analyses and the HLT. Additionally, the reconstructed event primary vertex from tracks is used by the PUPPI  [6]  algorithm to filter particles based on a measure of their probability of coming from pileup.