dataesr/scientific-paragraphs-categorization huggingface dataset:
Real-time sounding data distribution Sounding observations distributed in real time over the Global Telecommunication System (GTS) improve atmospheric analyses for initializing and verifying weather forecasts, and they improve subsequent reanalyses. Therefore, we aimed to disseminate as many of the full 1 s resolution radiosonde data from the EUREC 4 A campaign as possible over the GTS, regardless of the launch time. Radiosonde data (ascent and descent) from Atalante (114 reports during the campaign) and the BCO (60 reports in February) were sent to the GTS through a Météo-France entry point. This allowed their assimilation in numerical weather prediction (NWP) systems. Most of the Brown data were sent to the US National Centers for Environmental Prediction. From here they were ingested into US National Weather Service and Navy NWP systems, yet not European ones.
None of the data from Merian and Meteor could be transmitted to the GTS by satellite internet. However, during EUREC 4 A, 29 daily ascent soundings from Meteor were sent to the GTS via the EUMETNET Automated Shipboard Aerological Program, at around 16:30 UTC. The World Meteorological Organization (WMO) station identifiers and designators for tracking the data within the GTS are listed in Table  1  for each station. World Meteorological Organization Binary Universal Form for the Representation of Meteorological Data (BUFR) data were submitted to the GTS and exchanged among the platforms during the EUREC 4 A campaign.
Quality control and data formats The Vaisala RS41 temperature and humidity measurements are highly robust and accurate, even in cloudy environments. The humidity sensor is actively heated to prevent water condensation and frost formation on the sensor surface. The Vaisala MW41 software writes proprietary. mwx binary files which are ZIP archives that contain both the raw and the processed measurements. These data make up our Level 0 data set. We also provide Level 1 and Level 2 data, which we describe in the following. Our assignment of levels for the data sets adheres to the standards laid out in  Ciesielski et al. (2012). Sometimes the launch detection did not work properly, which resulted in differences of more than 30 m between the surface altitude and the first reported sonde altitude.
Level 1 data Level 1 data in NetCDF format are quality-controlled and averaged to 1 s resolution from the Level 0 data. Because the pressure, temperature, and humidity are measured with a different sensor (PTU) than wind and position, the data are synchronized to the PTU time. This synchronization is done by the Vaisala MW41 software, and the results are included in the Level 0 archive files. The Level 1 data were processed from these results. The Vaisala MW41 sounding system applies a radiation correction to daytime temperature measurements by subtracting increments that vary as a function of pressure and solar zenith angle. The uncertainty of the radiation correction is typically less than 0. 2 • C in the troposphere; uncertainty gradually increases in the stratosphere. The Vaisala system applies algorithms to adjust for time lags of the RS41 sensors.
At 10 hPa the response time of the temperature sensor is 2. 5 s for an ascent speed of 6 m s -1. At 18 km (75 hPa) with a temperature lapse rate of 0. 01 • C m -1 and an ascent rate varying from 3 to 9 m s -1 , the remaining uncertainty in the temperature reading due to time lag is 0. 02 • C. At lower altitudes the uncertainty is even smaller. A time-lag correction is also applied to measurements of humidity. The response time of the humidity sensor is dependent on the ambient temperature. For example, at an ascent rate of 6 m s -1 and at 1000 hPa it is < 0. 3 s for +20 • C and < 10 s for -40 • C. The remaining combined uncertainty during the sounding is 4 % relative humidity. After time-lag adjustments, the Vaisala MW41 quality control algorithm detects outliers and smooths the data to reduce noise.
Periods of super-adiabatic cooling are interpolated, and this also applies to temperature differences right above the surface. The MW41 software applies the same correction and quality control steps to the descending and ascending phases of a sounding. Descending sondes, however, can be subject to uncontrollable factors. For example, a falling device may be affected by the remaining debris of a balloon. For this reason, Vaisala does not guarantee the same abovementioned error margins for data from descending soundings. Our software  (Schulz, 2020)  reads the processed Vaisala. mwx and Meteomodem. cor files and converts them to self-describing NetCDF files. We also add the ascent or descent rate, calculated from the geopotential height and time information between consecutive measurements, to the NetCDF files.
Level 2 data To facilitate scientific analyses, Level 2 data are provided on a common altitude grid with bin sizes of 10 m, by averaging the Level 1 data. Mean temperature, wind components, position, and logarithm of pressure are directly averaged within height-centered bins. Relative humidity is calculated from the mean of the Level 1 water vapor mixing ratio, calculated from the water vapor pressure formula of  Hardy (1998) , which is also used by the Atmospheric Sounding Processing Environment (ASPEN) software  (Suhr and Martin, 2020)  for EUREC 4 A dropsonde measurements. Surface-launched soundings were not reprocessed with ASPEN, as the ASPEN manual warns against duplicating quality control procedures applied by the Vaisala MW41. In the case of missing data within a sounding, we linearly interpolate gaps of up to 50 m.
Code and data availability Raw Level 0 data consist of single files per sounding in. mwx format, which combine ascent and descent from each instrument. Quality-controlled Level 1 data consist of single files per sounding in NetCDF format, with separate files for ascent and descent. Level 2 data are stored in a single file per station and include data on a 10 m vertical resolution grid, including all available ascents and descents. Ascent and descent can be distinguished by a flag that indicates the direction. All data  (Stephan et al. , 2020)  are archived and freely available for public access at AERIS (https://doi. org/10. 25326/137). Our software, which we used to convert to NetCDF format is also publicly available  (Schulz, 2020 ; https://doi. org/10. 5281/zenodo. 3712223).
We made data at three stages publicly available. Level 0 data contain the raw. mwx binary files, which can be read and processed with the MW41 software. Level 1 data were subject to Vaisala's standard quality control algorithm, which https://doi. org/10. 5194/essd-13-491-2021 Earth Syst. Sci. Data, 13, 491-514, 2021 detects outliers in the profiles, performs a smoothing to reduce noise, and applies time-lag and radiation corrections. The Level 1 file format is NetCDF with a temporal resolution of 1 s. To facilitate scientific analyses, Level 2 data are vertically gridded by averaging Level 1 data in 10 m bins. All soundings, ascending and descending, from each platform were collected into one NetCDF file for the Level 2 data. Meteor and Brown followed nearly orthogonal sampling lines, mostly in the latitude band 12.
5-14. 5 • N, whereas Atalante and Merian sampled conditions further to the south. It was a central goal of EUREC 4 A to better understand the formation and feedbacks of different patterns of shallow cumulus clouds. We were fortunate that nature provided us with a wide variety of cloud conditions, which are reflected in the radiosonde data. The 6 weeks of sounding data at high temporal resolution should render the radiosonde data described herein useful for a large variety of scientific analyses.
, 2019). These data were successively analyzed together with the NRT SST produced by Collecte Localisation Satellites (CLS), the ship's thermosalinograph (TSG) 5 m depth temperature measurements, and ARPEGE and ECMWF forecasts in order to decide in real time the launching strategy. The NRT CLS SST is produced as a 1 d average, highresolution product, which is a simple data average of the satellite measurements taken over the previous day, and has a resolution of 0. 02 • in latitude and longitude. This product may have local gaps due to the presence of clouds or missing data. The CLS SST NRT product is derived from nighttime observations (to avoid diurnal warming of the sea surface) by MODIS on board Terra and Aqua satellites, AVHRR on board MetOp-A and MetOp-B, the VIIRS on board Suomi-NPP, AHI on board HIMAWARI-8, and ABI on board GOES-16 and GOES-17.
Acknowledgements. We acknowledge  Olivier Garrouste  and  Axel Roy  from  Météo-France  for lending the Meteomodem station and launcher and their technical assistance, and  Thierry Jimonet  and  Météo-France Guadeloupe  for their help. We would like to thank  Rudolf Krockauer  and  Tanja Kleinert (DWD), Bruce Ingleby (ECMWF) , and  Jeff Ator  ( NOAA ) for helping to track.
The Internet is becoming more centralized, more asymmetric in terms of knowledge and power distribution, more biased, less privacypreserving and less trustworthy. Blockchain technologies already enable the safe and fair exchange of digital assets in a decentralized manner; however, its application to information exchange remains largely unexplored. This article exposes our vision for a semantically-enriched blockchain software ecosystem named ONTOCHAIN, that enables the development of trustworthy distributed applications that can empower users, guarantee both their privacy and high quality of service, and ultimately support pluralism and democracy. ONTOCHAIN aims primarily to attain trustworthy service exchange and trustworthy content handling by means of advanced knowledge management mechanisms for several domains such as health, economy, public services, energy and sustainability, news, media, entertainment, Industry 4.
The exploitation of Hyperledger Fabric as SaaS by IBM 7  contributes to its adoption by a large variety of industries to deploy entreprise blockchain networks. EOSIO  [1]  offers a modular framework for creating industrial-scale permissioned or permissionless blockchains and implements a 2-layer consensus protocol which combines a Byzantine Fault Tolerant protocol and a delegated Proof-of-Stake protocol. According to its developers, EOSIOs protocol allows the chain to achieve up to 8,000 Transactions Per Second, way ahead of Hyperledger Farbic  [8] , although no scientific evaluation of EOSIOs performance have been conducted. ONTOCHAIN considers several challenges to unlock the tremendous potential of blockchain technology and make it technically, economically and legally viable in business environments for ensuring trust and accountability in information sharing and data processing.
The first set of challenges are technical ones; although several solutions partly address the topics of identity, privacypreserving data processing, trustworthy information handling and data provenance, no blockchain ecosystem supports web semantics natively and enables the development of information-centric applications like ONTOCHAIN intends to. The second set of challenges is related to the development of viable business models and incentives, i. e. , creating an environment of peers that all profit from fair data production and data usage and makes unfair or malicious behavior unprofitable. The last sets of challenges are of legal nature; sitting at the intersection of finance and data processing, ONTOCHAIN must incorporate the recent General Data Protection Regulation as well as upcoming and quickly changing regulations aimed at strengthening the privacy of citizens within the EU.
ONTOCHAIN use-cases will be built upon the different protocols shown in Figure  2. It is important to note that most of the components of the proposed architecture do not exist into any of the competitive platforms mentioned in Section 2. ONTOCHAIN Application and Core protocols will implement the interactions between different blockchain frameworks, while hiding them from the use-cases to support effortless inter-service process cooperation. Moreover, data stored at different chains, may be linked together. This linkage will be stored in new ONTOCHAIN chains. For enabling scalability, openness and high performance, we employ a modular approach. Each of the modules and functionality of each layer is built upon functionality offered by the lower layers. The functionality of the modules at each layer is described in a top-down manner below, along with the dependencies among them.
Application Protocols Layer Data Provenance: This module will provide graphical and programming interfaces for querying and presenting provenance information from ONTOCHAIN about on-chain and off-chain data. Provenance information will include the complete trail of transactions that resulted in a record. Reputation Models: This module will provide the functionality of building different decentralized reputation models over the blockchain, so that reputation feedback is genuine, credible and anonymous. This module is built upon Identity Verification mechanisms. Decentralized Oracles: This module will facilitate Smart Contracts to operate with off-chain data, although by design, Smart Contracts can only read and write data that is stored on their blockchain. To avoid centralization, some approaches (e.
Semantic agreements can be commonly agreed based blockchain-based consensus, similarly to the establishment of axiomatic statements. Moreover, new ontologies will be defined for smart contracts and decentralized services to enable service searchability and matching with service requests. This module will also include any reasoning approaches, tools and methods that can help deduce new knowledge arriving from a sensing IoT empowered environment. Multi-source Identity Verification: This module seeks to register and verify individual digital identities of physical objects via newly designed ONTOCHAIN services. For instance, various AI methods could be introduced to operate on sensing data (IoT based, sensors, cameras and similar) to assert whether an individual belongs to a specific ontological concept.
Identity Management: This module deals with technologies and solutions to address parts of the digital identity puzzle. There are two conflicting requirements that drive this development: i) ability to identify oneself in specific interactions (e. g. , withdrawing money in a bank), ii) preservation of ones privacy (e. g. , healthcare data, online buyers habits). Gateways/Bridges: This module will support connections between the ONTOCHAIN blockchain and the outside world, including other blockchains in the form of Smart Contracts, as well as several higher-level wrappers for commonly used languages (e. g. JavaScript, Java and Python). Our prototype will be implemented using the Ethereum software stack, because of its important community of adopters and developers. Data Semantics: Since ontology engineering is a complex work that usually takes many years to complete and test, this module intends to stimulate reuse of this body of generated knowledge in order to foster the use of various schemata and ontologies when describing the semantics of data.
Ontologies are core building block of the Semantic Web [https://www. w3. org/]. The W3C consortium provides mechanisms for their standardisation in order to foster their use in applications world-wide, with the potential to build various artificial agents that can cross-link the information, and perform advanced queries via SPARQL. Supporting these standards in the blockchain and providing data semantic annotation, semantics extraction, linking, inference, alignment and reasoning on top of blockchains will significantly boost the business viability of future applications involving knowledge management. Authorisation: Blockchain has stimulated the idea of self-sovereign digital identity. Various Role-Based Access Control (RBAC) systems have also existed for decades. With this module, one could easily see systems where a patient is selfidentified on blockchain, while a medical doctor gains access to the medical records based on her/his role (e.
Distributed Ledger Blockchain Consensus Engine: Consensus making mechanisms are at the core of any blockchain. ONTOCHAIN will be designed to be scalable, open, cost and energy-efficient, and when possible even as a much improved new consensus engine. Regarding openness, ONTOCHAIN does not aim for a silo blockchain ecosystem, but for an open distributed ledger that in principle can be combined with different blockchain environments. Decentralised Storage: Various decentralised repositories, such as Peer-to-Peer and Content Distribution Networks have existed for decades. With the emergence of blockchain, we have witnessed a new wave of participatory storage repositories that can help address the security and privacy needs, and may help store practically any kind of data (e. g. , StorJ). In the near future, one could imagine new storage services, that can help store private data in encrypted and decentralised way, that can help manage data replicas for reliability and Quality of Service, while balancing the trade-offs with the storage costs.
Use Cases ONTOCHAIN will enable many forthcoming applications, from B2B to C2C to G2C, in different verticals, including:  -Manufacturing Supply Chain Management Maintenance tracking -Public Sector Smart cities Traffic control A use-case scenario related to P2P e-commerce is detailed as example hereafter. In this use case, users are able to search for products/services provided by business entities based on data semantics. Users receive the matching product/service from the most reputable provider. The product/service transaction is then recorded in the blockchain as well as the changes of ownership of the product or the access provision to a service. In parallel, the product/service is removed from the inventory of the seller and an invoice is automatically issued. Finally, users may submit rating data on their past transactions.
Fig. 3  summarizes the main interactions of this application. Another use-case scenario concerns prorpietary-data trading. Individuals or data aggregators collect personal/proprietary data that are subject to privacy concerns and their handling is governed by GDPR. In this application, data is securely stored, uniquely identified and access to it is restricted to authorized entities for pre-specified handling. Data handling can be realized in secure enclaves through predetermined algorithms, also part of the smart contract, without any disclosure of the original data to any third party. The validity of the smart contract against GDPR is automatically validated and any processing activities to the data are recorded in the blockchain. Any data transformations that produce new data, are being treated as tradeable assets, while their provenance can be established based on their link to the original data (which has not been disclosed) and the processing algorithms.
The sample size, collection and inclusion were dependent on the availability of the clinical samples from clinical databanks. The speci c subtypes were selected based on the di culty to assert correct diagnosis by the gold standard pathological work ow. The rst section was stained with standard Hematoxylin-Phloxine-Saffron staining and the consecutive section was prepared for SpiderMass analysis. For histology, one veterinary pathologist (QP) Oncovet clinic read and annotated HPS canine sarcoma-stained tissues, and one human sarcoma board certi ed pathologist (Y-MR, Comprehensive Cancer Center Oscar Lambret Center) annotated the human sarcoma FFPE samples. The pathologists were in blind to any information about the acquisition from MS studies. No samples were excluded from the study. For the real-time analysis two blind samples of human sarcoma were randomly selected from the initial cohort.
SpiderMass experiments The sampling position was determined based on the histopathological annotations. The samples were randomly analyzed to avoid batch effects. The acquisition sequence was composed of 10 laser shots consecutively red between 2-4 times with a 10 s pause between each burst. Each burst results in an individual spectrum. The data was acquired in both positive and negative ion mode in sensitivity mode with 1s scan time. The mass range included m/z 50-2000. The singly charged lipid species were predominantly observed in the m/z 600-1000. The Waters Xevo Q-Tof instrument has 22000 mass resolution in sensitivity mode. The acquired spectra in the gures were scaled using MassLynx software (v4. 2 SNC966, Waters Laboratory Informatics). The canine and human sarcoma raw data les were than further subjected to the classi cation software.
MS/MS spectra were recorded after the isolation of precursor ion and they were subjected to collision-induced dissociation (CID) in the transfer cell with a transfer collision energy ranging between 25 to 40 V, depending on the selected precursor ion. The precursor ions were selected within the 1Da isolation window. The lipid annotations were performed manually through fragmentation spectra guidelines and compared to LIPIDMAPS database, Alex123 and METLIN database and literature  (52) (53) (54) (55).
Statistical analysis The "Abstract Model Builder"-AMX (Beta, version 1. 0 1972. 0, Waters) software was used to build the FFPE canine and human sarcoma classi cation model and databank based on the recorded molecular patterns. All of the imported raw positive ion mode data were subjected to PCA and LDA-based classi cation models using individual spectra (on average 3 per sample). Each burst was averaged into one spectrum. The PCA analysis was used to decrease the dimensionally of the data sets and generate a list of features showing the largest variance within the data set. Further on, the features were subjected to supervised LDA through user assigned classes (sarcoma subtypes). One third of the PCs were subjected to LDA analysis. The canine classi cation model was built using a mass range of 600-1000 m/z with a 0.
Real-time analysis To test the e ciency of our databank, we used "Abstract Model Builder Recognition" plugin of the "Abstract model builder" software. The analysis was performed in blind on two randomly selected samples not previously added in the classi cation model. The same preprocessing procedures were applied to the unclassi ed (test) specimens. The discriminating molecular patterns of the test specimen were extracted by means of the PCA-LDA projection matrix. The Mahalanobis distances are calculated from each previously assigned class average. The algorithm will classify the novel spectrum into the closest class, unless the distance is larger than a user de ned n*standard deviation of that class. In this particular experiment the outlier limit was set to 5 standard deviations. The other parameters set: 1e 3 TIC intensity threshold, 5 scans / spectrum, and 5 s timeout.
Establishing a rapid FFPE diagnostic screening MS-based platform using WALDI-MS Based on the aforementioned observations, we have created a platform for rapid lipidomic screening of FFPE tissues without depara nization and minimal sample preparation targeting applications in cancer diagnostics. The platform is operated in a two-stage work ow (Fig. 3 ). First (Fig. 3a ), a molecular database using histologically annotated samples is constructed. The FFPE blocks from tumor tissue banks are sectioned in consecutive slides. The rst section is stained and annotated by histopathology professionals; whilst the following section is analyzed by the SpiderMass system and the recorded mass spectra are subjected to data processing. First, non-supervised analysis by Principal Component Analysis (PCA) enables to check the reproducibility of the data and any potential issues associated with instrument drift or batch effects.