dataesr/scientific-paragraphs-categorization huggingface dataset:
Examples: Reference to a journal publication: Van der Geer, J. , Hanraads, J. A. J. , Lupton, R. A. , 2010. The art of writing a scientific article. J. Sci. Commun. 163, [51] [52] [53] [54] [55] [56] [57] [58] [59]   Coon, E. , Berndt, M. , Jan, A. , Svyatsky, D. , Atchley, A. , Kikinzon, E. , Harp, D. , Manzini, G. , Shelef, E. , Lipnikov, K. , Garimella, R. , Xu, C. , Moulton, D. , Karra, S. , Painter, S. , Jafarov, E. , & Molins, S. , 2020. Advanced Terrestrial Simulator (ATS) v0. 88 (Version 0. 88). Zenodo. https://doi. org/10. 5281/ zenodo. 3727209.
EPJ Web of Conferences 182, 02052 (2018) https://doi. org/10. 1051/epjconf/201818202052 ICNFP 2017 EPJ Web of Conferences full 2015-2016 data (36. 1 fb -1 ) are obtained for t tH (γγ) and t tH (ZZ * → 4 ) only combining t tH and tH production modes. Overall, consistency with the Standard Model expectation is observed.
EPJ Web of Conferences 182, 02052 (2018) https://doi. org/10. 1051/epjconf/201818202052 ICNFP 2017 ICNFP 2017 Events 600 700 500 ATLAS Preliminary -1 = 13 TeV, 13. 2 fb s Single Lepton 4 b ≥ 6 j, ≥ Pre-fit Data H t t + light t t 1c ≥ + t t 1b ≥ + t t + V t t 400 t Uncertainty Non-t 300 t t H (norm. ) 200 100 Data / Pred. -0. 5 0 1 1. 5 2 0 1 - 0. 8 - 0. 6 - 0. 4 - 0. 2 0 0. 2 0. 4 0. 6 0. 8 1 Classification BDT output (b) BDT classification (a) BDT reco.
The maximum life of a patent is 20 years, and the patent may be valid for only specific geographical areas. Patent protection is costly and depends on the geographical area that needs to be covered. Licensing of patents may reimburse some of the costs involved. However, in some cases, applying for a patent may not be advisable because trade secrets can be better protected by confidentiality. In the field of informatics and big data, protection issues are complicated  16. Databases of AMR gene variants are almost impossible to protect by IP. Although considerable investments have been made to establish the data sets  17  , many of these databases are freely available online for academic use (for example, the Comprehensive Antibiotic Resistance Database)  18. Of note, ongoing, large European Union-sponsored programmes are striving to generate high-quality, open access databases, with a focus on AST relating to the use of bacterial genome databases  [19] [20] [21].
It remains to be seen whether the quality and curation of the databases will remain unaffected upon termination of such (grant-funded) programmes. Management of IP and databases can pose barriers to the development of new AST systems; IP can be secured and not actively used by larger companies, thereby blocking further development, and databases need constant and costly curation, which may present a barrier from a financial point of view. However, proper IP and data management provides competitive advantages when developed into commercially available AST tools.
In addition, more specific attributes of the causative microorganism, for example, the presence of antibiotic-resistant populations  61  or whether an organism was recovered through surveillance culture or from a diagnostic specimen  64  , could be recorded. Therefore, the smart antibiogram should be developed to use a whole range of search parameters and patient demographics in its calculations. This will facilitate the automatic fine tuning of smart antibiogram algorithms and increase their value in predicting the correct empiric antibiotic therapy for individual microorganisms detected in different clinical specimens at different times on different wards and from different populations. For that, statistical approaches must be developed that would help predict correct antibiotic treatment on the basis of prior experience and the use of intelligent databases.
Acknowledgements This publication was made possible by a grant from the  Joint Programming Initiative on Antimicrobial Resistance (JPIAMR) , which was awarded to the  Antimicrobial Resistance Rapid Diagnostic Tests (AMR-RDT) Working Group  ( JPIAMRWG-020 ). The authors thank  M. Kaul ,  J. Tenllado ,  M. Finocchio  and  C. Sprugnoli  ( bioMérieux, France and USA ) for insightful comments on quality systems, legal and registration aspects and intellectual property management.
A joint trust and risk model is introduced for federated cloud services. The model is based on cloud service providers' performance history. It addresses provider and consumer concerns by relying on trusted third parties to collect soft and hard trust data elements, allowing for continuous risk monitoring in the cloud. The negative and positive tendencies in performance are differentiated and the freshness of the historic data is considered in the model. It addresses aleatory uncertainty through probability distributions and static stochastic simulation. An analytical insight into the model is also provided through the numerical analysis by Monte-Carlo simulation.
The outsourcing model of CSM presents economic and technological advantages. However, it also impacts on data governance, as risks and compliance management are delegated to third parties. The security practices of these third parties may not be visible to cloud customers (CCs), raising the question about the accountability of service providers when processing data in highly dynamic and heterogeneous environments. Accountability regards the data stewardship regime in which organisations that are entrusted with personal and business confidential data are responsible and liable for processing, sharing, storing and using the data according to the contractual and legal constraints from the time it is collected until when the data is destroyed  [47]. CCs need to trust that their CSP secure the CC data, and to provide the quality of service (QoS) and grade of service (GoS), i.
e. , service level objectives (SLO) agreed in service level agreements (SLA). Hence, both CC and CSP take risk. The risk taken by CCs is that their operations may be hampered due to service outages, security or privacy breaches. The risk for CSPs is two folded: They may not be able to fulfil SLOs agreed in an SLA, and therefore face penalties and loose reputation. Secondly, a CSP may also be a CC for the services provided by the other clouds in a CSM, and therefore CSPs are also subject to the risks similar to the ones taken by CCs. There are various models developed to analyse and to assess the risks and the trustworthiness of information systems and services. We provide a short survey on them in Section "Related work and definitions". To the best of our knowledge, there is not a quantitative risk and trust model which is based on the CSP performance data and can be used for internal and external CSM.
In this paper, we introduce a new quantitative and stochastic scheme called joint risk and trust model (JRTM) for CSMs. JRTM is based on the definitions made by "Accountability for Cloud and Other Future Internet Services" (A4Cloud), which was a large European Union Framework Seven Project with partners from academia (i. e. , law, data science and computer science departments) and industry. A4Cloud contacted with many stakeholders including users and organizations, such as, Cloud Security Alliance to determine and to verify the risk and trust parameters and their inter-relations. JRTM is a product of the A4Cloud Project and provides a quantitative scale to analyse the risk and trust jointly. JRTM is based on a stochastic process, and therefore addresses uncertainty. It uses observations that we call evidence to assess the risk and to build trust for a CSP.
These observations are in abstract level such that the details about threats, vulnerabilities, CSP architectures and security schemes are not needed for the risk assessment. Hence, JRTM is low cost, scalable and practical. JRTM depends on historic data collected by a trust as a service (TaaS) provider, a trusted third party, who makes recommendations about the trustworthiness of a CSM. TaaS approach helps overcoming barriers due to the lack of transparency. The level of risks acceptable for a CSM is defined by the TaaS Provider and CC together. CC also provides several parameters that influence the effects of the historic data to the results of the model based on the freshness and the tendency of the data (i. e. , if it changes in negative or positive direction). Both risk and trust have been extensively studied in various contexts for hundreds of years.
It is different from JRTM because it is a qualitative scheme, and it does not use performance data related to CSPs but the information about how CSPs implement the security measures. A risk is the product of a threat, a vulnerability and the consequences (i. e. , the impact of an incident)  [17, 20, 32] , and cloud computing is subject to a long list of threats  [14]  and vulnerabilities  [9]. A CC has a special challenge in risk assessment for the cloud when compared to conventional information technology (i. e. , other than cloud) customers. CSPs usually keep the locations, architecture and details about the security of their server farms and data centers confidential from CCs. Therefore, it is more difficult to a CC to assess all the threats and vulnerabilities. Additionally, CSPs have to prioritize the issues to solve when risks are realized.
In  [49] , the CC trust to a CSP is related to the following parameters: Data location: CCs know where their data are actually located. Investigation: CCs can investigate the status and location of their data. Data segregation: Data of each CCs are separated from the others. Availability: CCs can access services and their data pervasively at any time. Privileged CC access: The privileged CCs, such as system administrators, are trustworthy. Backup and recovery: CSP has mechanisms and capacity to recover from catastrophic failures and not susceptible for disasters. Regulatory compliance: CSP complies with security regulations, certified for them and open for audits. Long-term viability: CSP has been performing the required standards for a long time. The authors in  [49]  statistically analyze the results of a questionnaire answered by 72 CCs to investigate the perception of the CCs on the importance of the parameters above.
e. reduces or limits the impact (corrective control). Personal data: Personal data relate to an individual who can be identified. The identification of the individual does not need to be directly. For example, there can be many people, whose name are John and were born on a certain date, but there may be only one John with that birth date and working in a certain company. Personally identifiable information (PII): PII are data that identify a person, such as social security number. Data subject: A data subject is an individual or organization who is the subject of personal data. Data controller: A data controller is an institution, organizational entity or person who alone or jointly with others determine the purposes and means of the processing of data. Incident: An incident is an event that results in a security, privacy or service violation/outage; e.
g. , respectively confidential data leakages after an attack, personal data collection without appropriate consent from the data subjects, or data cannot be recovered after a hardware failure. Event: An event is something that creates a vulnerability which may be exploited by a threat to compromise someone's asset(s). It is important not to confuse event with incident; For instance, losing an access badge is a security event. If an outsider uses the lost badge to enter a building without authorization, then it is an incident. Security incident: A security incident can be defined as a single attack or a group of attacks that can be distinguished from other attacks by the method of attack, identity of attackers, victims, sites, objectives or timing, etc. It results in the violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.
Privacy Incident: A privacy incident can be an intentional or unintentional violation of the consent obtained by the data controller from the data subjects, or a violation of the applicable data protection regulatory framework. A privacy incident can be the result of a security or service incident. For example, a data controller uses data for purposes not originally declared; an attacker gains access to personally identifiable information (PII); personal data is transferred to third parties without consent. Service Incident -A service incident is an event that violates the terms of service, service level agreement, or contracts between the CC and the CSP. It may be the result of failure (e. g. power outage, natural disaster, hardware failure, or human errors), attacks, or intervention of third parties (governmental agencies or law enforcement) preventing customers to use the services as established via contracts, resulting in service outages.
Please note that we count the incidents caused by denial of service (DoS) attacks as security incidents, because their results are service outages. A risk is a combination of the probability/likelihood of an incident and its impact/consequences. Since a risk is realized when threats exploit vulnerabilities, the probability of an incident is related to the existence of threats and vulnerabilities, as well as, the capabilities and willingness of the threats to exploit the vulnerabilities. On the other hand, the consequences depend on the assets owned by the subject, and it's security policy. In JRTM, the probability is based on the historic data related to the CSP performance, and the consequences are represented by means of the maximum incident probability acceptable by the CC, i. e. , thresholds.
If the impact on a data subject is high (i. e. , the value of the assets are high), lower thresholds are set. JRTM is designed as a risk assessment tool for TaaS providers. A TaaS provider can be an organization like Cloud Security Alliance (CSA) or a certification agency in which all kinds of cloud ecosystem stakeholders are represented. Please note again that, JRTM alone is not for composing/configuring CSM or selecting a CSM. It assess if the risks related to a CSM are below the acceptable risk level for a CC. However, JRTM can also be used together with a service composition or selection tool. We explain how to do this in the next Section.
The probability that a TaaS provider makes use of controls to compromise the security or the performance of a cloud is lower. The TaaS provider does not need to share all the technical data with every CC. Therefore, CSP can protect both commercially and security wise sensitive data. CCs do not need to monitor or to control CSP for every cloud service. Instead, they take a recommendation from a third party who is an expert on this topic. When TaaS providers are organizations accepted by the cloud industry, they may act also as a quality assurance mechanism. Therefore, accredited certification third parties can naturally become also a TaaS provider. The TaaS provider approach assumes that accurate event and incident data can be collected by the TaaS providers. One may argue that this is not a realistic assumption because CSPs would not share this information with the TaaS providers.
e. , privacy event durations. Let's assume that the worst case for the privacy events occurs, which is 2 16 privacy events in the last period. Then, we do not expect larger than 128 KB of data per CSP per period. If the periods are one day and there are 2 10 CSPs registered in the TaaS Provider's database, the size of the data that the TaaS Provider needs to collect and store is around 128 MB, which is not much. Even if the number of CSPs in the database increases in the order of magnitude, the size of the data collected daily by the TaaS Provider stays around several GB. As implied by the evidence collected, JRTM distinguishes three types of risks: security, privacy and service. Privacy has a difference from the other two. It is very likely that a privacy event is not detected when it is initiated.
Secondly, it does not need to assess all threats and vulnerabilities. For a TaaS provider or CC, it is not practical to list all threats and vulnerabilities because it is not likely that CSP will share all the details about their physical architecture, platforms and security systems with public, their CC or even with TaaS providers. JRTM predicts the expected number of events by using the data about the past events as shown in Eqs. (2), (  3 ) and (  4 ). The periodical data related to risks r ε , r Φ , and r ρ are weighted based on their freshness as given by (  2 ), (  3 ) and (4), where the Period i is the latest period, and r ε(i) , r Φ(i) and r ρ(i) are the current risk assessments for security, privacy and service respectively. The parameter ω in (2), (  3 ) and (  4 ) is the weight parameter, and can be given any value between 0 and 1 including 0 and 1 (i.
In Fig. 9 , the likelihood for privacy, security and service risks are given for 44 CSPs registered in Security Trust and Assurance Registry (STAR)  [15]  by Cloud Security Alliance (CSA). Almost 300 CSP provided information about how they implemented controls for the security, privacy and service assurance in the STAR. The likelihood value is the result of Cloud Adopted Risk Assessment Model (CARAM)  [11] , which aggregates the ENISA likelihood assessment  [18]  for cloud risks into three domains (i. e. , security, privacy and service) and applies to CSPs based on the data in STAR. The scale used for likelihood is between 0 and 9. CARAM results are not based on the historic data but vulnerabilities and threats assessed by ENISA and the controls implemented by the CSPs. However, we can observe that privacy risk is higher than security and service risks, which are close to each other, almost for every CSP.
In the present study the terms "high resolution" and "fine-scale" aim to describe observations and mechanisms, respectively. During the OSCAHR cruise, novel platforms for coupling physical-biological-biogeochemical observations and sampling the ocean surface layer at a high spatial and temporal resolution were coupled with real-time analyses of satellite ocean color imagery and altimetry. In this article, we first describe the hydrological structure and dynamics of the studied feature based on satellite data and continuous sea surface measurements. Then we address the corresponding phytoplankton community structure and distribution based on analyses performed at the single-cell level and at high spatiotemporal resolution in an autonomous way. Moreover, we also present the fine-scale vertical variability of the phytoplankton community structure in various stations within and outside the studied structure, resulting in a three-dimensional dataset for the investigation of the physical driving mechanisms acting on the phytoplankton community structure.
OSCAHR outlines The OSCAHR cruise was carried out between 29 October 2015 and 6 November 2015 in the western Ligurian subbasin onboard R/V Téthys II  (Doglioli, 2015). A first leg sampled the coastal waters, and a second one was dedicated to offshore waters in a > 1000 m water column area. The present study focuses on the second leg held from 3 November to 6 November (Fig. 1 ). The cruise strategy used an adaptive approach based on the near-real-time analysis of both satellite and numerical modeling data to identify dynamical features of interest and to follow their evolution. Several satellite datasets were exploited during the campaign to guide the cruise using the SPASSO software package (Software Package for an Adaptative Satellite-based Sampling for Ocean campaigns, http://www. mio. univ-amu.
Data were collected using the CellQuest software (BD Biosciences ® ). The analysis and identification of ultraphytoplankton groups were performed a posteriori us- ing SUMMIT v4. 3 software (Beckman Coulter). For each sample the runtime of the flow cytometer was set at 5 min. The sample flow rate was about 100 mm -3 min -1 (corresponding to the "Hi" flow rate of the flow cytometer). Various ultraphytoplankton groups were optically resolved without any staining on the basis of their light scatter and fluorescence properties (defined below in Sect. 3). Separation of picoeukaryotes and nanophytoplankton was performed by adding 2 µm yellow-green fluorescent cytometry microspheres (Fluoresbrite YG 2 µm, Polyscience Inc. ) to the samples. Trucount ™ calibration beads (Becton Dickinson Biosciences) were also added to the samples as an internal standard both to monitor the instrument stability and to determine the volume analyzed by the instrument.
Underway surface measurements The in situ velocity of the currents was measured by a hull-mounted RDI Ocean Sentinel 75 kHz ADCP (acoustic Doppler current-meter profiler). The configuration used during the whole cruise was 60 cells, 8 m depth beams, and 1 min averaged. The depth range extended from 18. 5 to 562. 5 m. The onboard surface-water flow-through system pumped seawater at 2 m in depth with a flow rate carefully maintained at 60 dm 3 min -1. The TSG, a SeaBird SBE21, ac-quired sea surface temperature (SST) and salinity (SSS) data every minute during the whole cruise. A Turner Designs fluorometer (10-AU-005-CE) recorded simultaneously sea surface fluorescence. In order to validate the salinity measurements computed from conductimetry, discrete salinity samples were performed on a daily basis before, during and after the campaign.
The for-ward scatter (FWS) signal was collected onto two photodiodes to recover left and right signals of the pulse shape. Each particle passes at a speed of 2 m s -1 along the laser beam width (5 µm) with a data recording frequency of 4 MHz, generating optical pulse shapes used as a diagnostic tool to discriminate phytoplankton groups. Two distinct protocols were run sequentially every 20 min, the first one targeted autotrophic picophytoplankton with FLR trigger level fixed at 5 mV, sample flow rate at 5. 0 mm 3 s -1 for 3 min, resulting in ∼ 0. 5 cm 3 analyzed samples. Two main groups, Prochlorococcus and Synechococcus, were optimally resolved and adequately counted using this first protocol. Synechococcus are easily detectable by flow cytometry due to the bright orange fluorescence emitted by phycoerythrin during the excitation by the blue 488 nm laser beam of the flow cytometer.
As some samples were also analyzed on a FACSCalibur equipped with a 633 nm laser beam, it was possible to measure the red fluorescence induced by PC and thus calculate the ratio PC/PE. It occurred that the Synechococcus population observed in type 2 waters (stations 6 and 7) had a higher PC : PE ratio (about 0. 33, data not shown) compared to other stations (< 0. 27, data not shown). The ratio PC : PE varies as a response to photoacclimation, as well as to chromatic adaptation  (Dubinsky and Stambler, 2009; Stambler, 2014). These Synechococcus populations were retrieved in the northern corners of our study area (Fig. 7c ), characterized by warmer SST (> 18. 5 • C) and lower SSS values  (< 38. 24)  than type 1 warm boundary waters. Besides their apparently different physical properties, type 1 and 2 waters remained relatively close in terms of TSG fluorescence and phytoplankton abundances (Fig.
, 2010). Data availability. Standardized, validated and interoperable OSC-AHR metadata and data are available through the SeaDataNet Pan-European infrastructure for ocean and marine data management. The detailed metadata (based upon the ISO19139 standards) created by  Doglioli et al. (2018)  are available through the Common Data Index (CDI) service. These metadata are tied to the OSCAHR flow cytometry dataset after adopting and creating a flow cytometry common vocabulary. The data can be requested and downloaded.