dataesr/scientific-paragraphs-categorization huggingface dataset:
Acknowledgements. This study was funded by the  Agence Nationale pour la Recherche (ANR)  through the  SUMER, Blanc SIMI   6-2012. All the computations presented in this paper were performed using the CIMENT infrastructure (https://ciment. ujf-grenoble. fr), which is supported by the  Rhône-Alpes region  (GRANT CPER07_13 CIRA: http://www. ci-ra. org). We greatly thank  Chris Borstad  and  Jeremy Bassis , whose comments and advice greatly improved the quality of the paper. We also thank  Doug Benn  for pointing out interesting remarks regarding calving state-of-the-art. We further thank the  CSC-IT Center for Science Ltd (Finland)  for their support in Elmer/Ice development, and  Johannes Fürst  for helpful thorough reading. Edited by:  G. H. Gudmundsson.
Therefore, it is necessary to decide the containers, information content and device management of the devices and applications beforehand. The devices offering services can be managed by Device Management Servers in OMA DM  [39]. OMA DM devices are identified by a model number, and represent services as management objects in the OMA DM data model (Device Management Tree). These service objects are just service representations which contain nodes. These nodes contain properties for the actual service which can be managed by the ACS. The calls to configure the management objects are done over SyncML. Devices offering services can be managed by Auto Configuration Servers in TR-069  [41]. TR-069 devices are identified by a serial number and a type, and represent services as service objects in the TR-069 data model.
This provides the functionality to integrate sensors into Spatial Data Infrastructures (SDI). SWE Service Model defines packages with data types and operation request and response types for common use across SWE services  [68]. Sensor Observation Service (SOS) provides standardized access to sensor observations and sensor metadata  [69]. The service acts as a mediator between a client and a sensor data archive or a real-time sensor system. The heterogeneous communication protocols and data formats of the associated sensors are hidden by the standardized interface of SOS. SOS defines O&M as its mandatory and default response format for sensor data and recommends the usage of SensorML for sensor metadata exchange. Sensor Planning Service (SPS) is a web service interface that allows clients to submit tasks to sensors for operations such as the configuration of the sampling rate or the steering of a movable sensor platform  [70].
Instead of defining the filter for forecasts in each consumer's subscription, a consumer can simply subscribe for all notifications on the weather channel. Consumers may also use filter criteria while subscribing to sensor data. Depending on the filter type used these criteria operate on single observations or on observation streams, potentially aggregating observations into higher-level information (which itself can be regarded as observation data). Sensor Instance Registry (SIR) provides functionality to collect, manages, transform and transfer sensor metadata through SensorML as well as extended discovery functionality and sensor status information. It is intended to close the gap between the SensorML based SWE world and conventional Spatial Data Infrastructures (SDIs). In the future it is expected that the functionality of the SIR interface will partly be covered by other existing SWE services (e.
g. , SOS for retrieving sensor status information and the SES for filtering sensor status updates). Sensor Observable Registry (SOR) is designed in order to support users when dealing with identifiers pointing to phenomenon observed by a sensor (observable) which is very important when searching for sensors. Usually such parameters are expressed within SensorML documents through some kind of identifier (i. e. , URIs). Figure  4  depicts two scenarios where the SWE architecture is in action: sensors without embedded IP stack, and sensors with embedded IP stack. The scenarios have been simplified in order to clarify the basic idea. More details can be found in the standards specifications and the SWE white papers. SWE is a standard M2M architecture that focuses primarily on the requirements of the scientific community dealing with remote sensor and sensor data management.
Scenario 1-Sensors without Embedded IP Stack 1. 1 Multiple sensor nodes connect to a SWE Gateway. Sensor networks that utilize various network topologies and low level communication protocols may be connected to the SWE architecture in this manner. The Gateway layers the sensor network data with Internet and Web protocols and relays it to a SES server. Initially the gateway calls the RegisterPublisher operation to add sensors to the SES. The request includes a SensorML which describes the sensor and its capabilities. 1. 2 Sensor data is published to the SES via the Gateway. Notify operation, which contains sensor data in the O&M standard, is used. 1. 3 A SOS server and a user application subscribe to sensor data using the Subscribe operation. The requests include the topic and the filtering specifications, as well as the information about the endpoint to which the filtered sensor data should be delivered.
2. 6 The response to a GetObservation request is an O&M Observation, an element in the Observation substitution group, or an ObservationCollection. These are historical sensor observations retrieved from the SOS backend. The SWE Common and O&M which are data models for exchanging heterogeneous sensor data at low and higher levels respectively allow applications and/or servers to structure, encode and transmit data in a self-describing and semantically enabled way. O&M, which is based on Martin Fowler's Observation & Measurements analysis pattern  [71] , is a dynamic model that can adapt smoothly to new requirements without necessarily needing to change implementation or the way objects interact. It is therefore, a particularly interesting solution for the description of device data across different business domains.
One of the key requirements of M2M systems is the ability to fuse, interpret or transform device data into higher level information, required by various M2M applications. A mechanism that enables such on-demand processing, using generic software that utilizes standard process descriptors, simplifies M2M application development and facilitates interoperability. The view-point of the sensor as a process or a chain of processes in the SensorML model with detailed process input, output, parameter, and method descriptions makes it a possible candidate for such a generic process descriptor. The ongoing work on SensorML 2. 0 is planning additional functionalities such as the Sensor Interface Descriptor (SID) extension. SID enables the precise description of a sensor's protocol and interface. This work may be used as a basis to develop generic device drivers carrying protocol definitions of legacy devices which in turn would allow on-the-fly, plug-and-play integration of such non-compliant devices into the standard M2M service network without the need for manual ad-hoc development for each device type  [3].
The registration information is then stored by the Network Reachability, Addressing and Repository Capability. After it Network Application receives a positive answer (003). The Network Application subscribes to the data produced by the desired sensor (Device application) (004). This data can also follow a certain criteria specified by the issue. If the issuer is authorized to subscribe to the given Device Application, the Gateway Reachability, Addressing and Reachability capability treat the request (005). Network application receives a positive response (006). Device application sends information to the Gateway (007). Then Gateway Reachability, Addressing and Repository Capability identify an event that needs to be reported to a subscriber (008). Finally, The GRAR Capability notifies the subscribers (009).
Autonomic M2M Services Autonomic computing has been inspired from biological systems including both centralized and decentralized approaches, which have been proposed to enable autonomic behavior in computer systems. The centralized approach focuses on the role of human nervous system as a controller to regulate and maintain the other systems in body  [73]. Decentralized approaches take inspiration from local and global behavior of biological cell and ant colony networks  [74]. Another area focuses on developing self-managed large scale distributed systems and databases. One such project is Oceano  [75] , a project of IBM providing a pilot prototype of a scalable, manageable infrastructure for a large scale utility power plant. OceanStore  [76] , a project of University of California Berkeley describes a global persistent data store for scaling billion of users.
IBM's SMART  [77]  offers a solution to reduce complexity and improve quality of service through the advancement of self-managing capabilities. Similarly, Microsoft's AutoAdmin  [78]  makes database system self-tuning and self-administering by enabling them to track the usage of their system and gracefully adapt to application requirements. Agent architecture has been frequently used to develop infrastructures supporting autonomic behavior based on a decentralized approach. Unity  [79]  makes use of this approach to achieve goal-driven self-assembly, self-healing and real-time self-optimization. Similarly, Autonomia  [80]  is a University of Arizona project providing the application developers with all the tools required to specify the appropriate control and management schemes to maintain any quality of service requirements.
Another area focuses on modifying control theory technique  [84]  and presents a framework to address resource management problem. A mathematical model is used for forecasting over a limited time horizon. Service Oriented Architecture has been also used to design architecture with autonomic behavior. In  [85] , autonomic web services implement the monitoring, analysis, planning and execution life cycle. The autonomic web service uses log file provided by a defective functional service to diagnose the problem and consults the policy database to apply appropriate recovery action. Infrastructures have been proposed to inject autonomic behavior in legacy and non-autonomic system, where design and code information is unavailable  [86]. Some of the identified frameworks make use of layered architecture  [87] , case based reasoning (CBR)  [88] , and a rule driven approach  [89]  to enable automaticity in existing systems.
Each domain presents one logical groups with one user account database. Each domain may present own user account policies. The device owner is usually considered to be also a user of the M2M domain and an owner of at least one XMPP user id. All devices share same user id (local-part and domain-part) with their owner. Separation of devices is done by examining the resource part of JID. A client connects to the server to send and receive messages, the servers routes messages to the others enabling client-to-client communications over multiple servers, Figure  9. The procedure for M2M client establishing connection with the XMPP server is shown in Figure  10. Discovery can be done directly using a domain part as a server address or discovering server address with SRV lookup from DNS. All clients connect to only their own server specified by JID.
The most important difference is that server to server connections are not authenticated because they happen in between different domains that do not share a common user database. XMPP servers may use XMPP Dial back (XEP-0220), to verify the domain of the connecting server. The domain administrator may require stronger identification verification by using TLS certificates and Simple Authentication and Security Layer (SASL). When M2M clients located in different domains would like to exchange messages, routing of messages will be done by the domain specific servers, see Figure  11. Then, a communication link between servers of the domains is negotiated to enable messaging between the referred M2M clients. The capability for handing presence information has been developed for XMPP. The availability of each client can be detected with the aid of presence messages.
XMPP offers mechanisms to select how, when and to whom presence information is shared to, as described in requirements listed in  [119]. For example, presence can be shared only with contacts that are in roster/address book of client sending the presence information. The related presence information (JIDs) is critical information in the system and it is stored in the roster database. Another useful feature is the publish-subscribe model (XEP0060), which can be used by XMPP entities to subscribe information of the presence of other entities, and receive notifications accordingly.
35 g H 2 O g -1 dry soil under WW (corresponding to 0. 07 MPa soil water potential; WP4-T dewpoint meter; Decagon Devices, Pullman, WA, USA) and 0. 20 g H 2 O g -1 dry soil under WD (corresponding to 0. 28 MPa soil water potential; see Supplementary Fig. S2 ). The latter has been shown to decrease leaf water potential significantly and impair plant growth  (Granier et al. , 2006). All environmental data, including daily soil water content, air temperature, and VPD air , were recorded in the course of time and are available in the PHENOPSIS database  (Fabre et al. , 2011). Near-isogenic lines (NILs) were also selected to confirm the QTLs identified from the genetic analysis. NILs were chosen from the population previously developed by introgressing genomic regions of Cvi into Ler  (Keurentjes et al.
thaliana by M. Dauzat (INRA, Montpellier, France) and K. J. Parkinson (PP System, UK) and connected to an infrared gas analyser system (CIRAS 2, PP systems, USA). The photosynthetic rate was expressed on a blade dry mass basis (A mass , nmol CO 2 g -1 s -1 ) and on a blade area basis (A area , nmol CO 2 cm -2 s -1 ). WUE (nmol CO 2 mg -1 H 2 O) was determined as the ratio between whole-plant net photosynthesis and whole-plant transpiration (A/T). Genotypic information, plant images, and phenotypic trait values are available in the PHENOPSIS database (http://bioweb. supagro. inra. fr/phenopsis/; Fabre et al. , 2011).
Acknowledgements We thank  J. Bresson ,  A. Bédiée ,  F. Bouvery ,  C. Balsera , and  G. Rolland  for their help during experiments and image analysis. We thank  J. Bresson  for useful comments on previous versions of the paper. We also thank three anonymous reviewers for helping improve the presentation of the results and the discussion. This work was supported by the  EIT Climate-KIC  project  AgWaterBreed. FV was funded by a  CIFRE grant  ( ANRT ,  French Ministry of Research)  supported by  BAYER Crop Science  (contract  0398/2009-09 42 008 ). FV, MD, CG, and DV designed and conceptualized the study. FV performed the experiments. FV and DV carried out the statistical analyses, interpreted the results, and wrote the paper.
Electron microscopy was performed on concentrated ILOV samples, which showed spherical flavivirus-like virions of approximately 40-50 nm in diameter (not shown). The complete coding sequences of LAMV-M07 and ILOV demonstrated the characteristic organization typical of flavivirus genomes, encoding a long polyprotein. The coding sequence of ILOV was 10,353 bp, encoding a 3451 amino acid polyprotein (Genbank accession KC692067). Within the complete coding sequence, ILOV and LAMV were found to share only 62. 7% pairwise identity at the nucleotide level and 64% at the amino acid level, demonstrating that they were separate virus species  (Kuno et al. , 1998; Pletnev et al. , 2011). The ORF sequence of LAMV-M07 was 10,302 bp, encoding a polyprotein of 3434 amino acids (GenBank accession KC692068).
However, in the case of ILOV, residue 110 was an arginine (R), whereas the corresponding residue in most of the other flaviviruses was a lysine (K). Similar to LAMV and LAMV_M07, four potential N-glycosylation sites were predicted in the ILOV NS1 protein, three initial ones being at the same positions (LAMV polyprotein N884, N897, N981) and the last one being 4 residues before the location of corresponding LAMV N-glycosylation site (LAMV polyprotein N 1081). No DNA sequences corresponding to the genomic RNA of LAMV prototype virus, LAMV-M07 or ILOV were detected in the infected cells using primers targeted to the NS5 gene. Novel flavivirus sequences that are related to LAMV and ILOV originating from different geographical locations are documented in public databases (Table  1 ), including Marisma mosquito virus (MMV) from Spain  (Vazquez et al.
, 2012) , Barkedji virus (BARKV) from Senegal (unpublished, GenBank accession EU078325. 1) and Israel  (Kolodziejek et al. , 2013) , Nounane virus from Cote d'Ivoire  (Junglen et al. , 2009) , Donggang virus (DONV) (unpublished, GenBank accession NC_016997), Chaoyang viruses (CHAOV) from China (GenBank accession FJ883471) and South Korea  (Lee et al. , 2013; Wang et al. , 2009)  and Nanay virus from Peru  (Evangelista et al. , 2013). The results of the phylogenetic analysis of the available complete coding sequences in public databases suggest that the MBFV-related viruses form two distinct lineages, which are phylogenetically positioned among the mosquito-borne flaviviruses. In the ORF analysis both of these lineages were positioned between the large cluster of YFV-related viruses (Edge Hill, yellow fever and the Entebbe bat virus group) and the rest of the MBFVs including dengue virus and the JEV complex.
Mosquito vector identification Sequences obtained from the cloned mosquito pool PCR products showed that the virus-positive pools contained several mosquito species. The clones sequenced from the two LAMV-M07 positive pools formed nine individual consensus sequence (GenBank accession numbers KC778408, KC778410, KC778411, KC778412). In the phylogenetic analysis, these sequences clustered together with sequences of Ochlerotatus riparius, Oc. punctor, Oc. annulipes and Oc. cantans (Supplementary Fig. 2A  and B ). The sequences of clones from the two mosquito pools positive for ILOV formed four consensus sequences (GenBank accession numbers KC778408, KC778410, KC778411, KC778412) that grouped with Oc. riparius (Supplementary Fig. 2A ) and three sequences that grouped with Anopheles sequences that were used as an outgroup for the analysis (data not shown).
Based on sequence comparisons, we were able to identify a total of eight distinct viruses as MBFV-related viruses including the tentative novel species described here, ILOV, LAMV, NOUV, BARKV, CHAOV, DONV, NANV and MMV. From the representative viruses, for which the complete genome sequences, including UTRs are currently available (LAMV, CHAOV, DONV) it can be concluded that the genome organization and conserved sequence elements in the UTRs of these viruses resemble those of mosquitoborne flaviviruses. The available sequence data suggest that the individual MBFV-related viruses originating from different geographical locations are divergent and thus may have different biological properties. The sequence analysis presented here included all MBFV-related viruses described to date. Separate analyses were performed for the available ORF data and partial NS5 data available for all MBFV-related viruses.
The results demonstrated that the phylogenetic associations of the individual viruses could change when more sequence data were included in the analysis. Previously LAMV was associated with African NOUV, in contrast to the current analysis where a group of Eurasian viruses was identified including LAMV, CHAOV, ILOV, DONV and MMV. The Eurasian group was clearly separated from viruses originating from Africa, the Middle-East or South America (NOUV, BARKV, NANV) in both ORF and NS5 gene analyses. Previously NOUV and NANV  (Evangelista et al. , 2013)  and NOUV and BARKV  (Kolodziejek et al. , 2013)  were phylogenetically associated. In the current analysis of ORF sequences available for NOUV and BARKV, these were grouped together. However, in the NS5 tree these viruses were positioned differently, NOUV associated more closely to KOKV whereas NANV was closer to the DENV group.
, 2007). The UTR sequence determination was undertaken using the 5 0 /3 0 RACE kit (Roche) and the products were T-A cloned to pGEM-T vector (Promega) and sequenced. Data were combined to derive consensus sequences using Sequencher v. 4. 8 (Gene Codes). To test whether the LAMV prototype strain and the isolates M0719 and M0724 produced DNA forms of the genomic RNA, DNA was extracted from infected C6/36 cells using TriPure Isolation reagent (Roche) and treated with RNAse A (Ambion) prior to testing in direct PCR using pan-flavivirus primers  (Scaramozzino et al. , 2001).
Sequence analysis The potential N-glycosylation sites were predicted for LAMV_ M07 and ILOV proteins using the NetNGlyc 1. 0 server (available at http://www. cbs. dtu. dk/services/NetNGlyc/). Protein sequence alignments were prepared using MUSCLE  (Edgar, 2004). Nucleotide sequences were then aligned based on the coding regions of the aligned polyprotein sequences using the program EMBOSS tranalign (available at http://emboss. bioinformatics. nl/cgi-bin/ emboss/tranalign). Alignments were submitted to the GBlocks program, which objectively eliminates poorly aligned positions and divergent regions  (Castresana, 2000). As the Barkedji virus (BARKV) sequence (EU078325. 1) was the only incomplete sequence used in the open reading frame (ORF) alignments, these were trimmed to match this sequence, lacking 19 amino acids from the beginning of the C gene.
Additional analysis was performed for partial (935 bp) NS5 gene sequences. The NS5 alignment was trimmed according to the shortest Spanish MMV isolate sequences. The ORF nucleotide sequence similarity plots were generated via the SimPlot program version 3. 5. 1  (Lole et al. , 1999)  using a sliding window of 300 bp. Synonymous site conservation was calculated as described previously  (Firth et al. , 2011). A Bayesian estimation of the phylogeny was performed using MrBayes v 3. 1. 2 (Huelsenbeck and Ronquist, 2001; Ronquist and Huelsenbeck, 2003). For all analyses, the Bayesian Markov chain Monte Carlo (MCMC) method was implemented  (Huelsenbeck and Ronquist, 2001). All parameters were estimated from the data under default priors and Markov chains were run for a minimum of 20 million generations, with the first 10% of samples discarded as burnin.
Acknowledgments Tytti Manni ,  Irja Luoto  and  Irina Suomalainen  are acknowledged for excellent technical assistance. This study was supported by grants from the  Academy of Finland ,  Boehringer Ingelheim Fonds ,  Biomedicum Helsinki Foundation ,  Emil Aaltonen foundation , and HUSLAB. AEF is supported by a grant  088789  and SC by a grant  039833  from the  Wellcome Trust. EAG is supported by grants from the  EU 7th Framework SILVER  and  PREDEMICS  grant agreement numbers  260644  and  278433.
In particular, we investigate if these populations spatially coincide, if and how the medium is structured, and if strong density and temperature gradients occur, within the limits of the spatial resolution obtained with Herschel. Methods. The SPIRE FTS fully sampled maps at different wavelengths are analysed towards the northwest (NW) and the east (E) PDRs in NGC 7023. We study the spatial and spectral energy distribution of a wealth of intermediate rotational 12 CO 4≤ J u ≤13 and 13 CO 5≤ J u ≤10 lines. A radiative transfer code is used to assess the gas kinetic temperature, density, and column density at different positions in the cloud. The dust continuum emission including Spitzer, the Photoconductor Array Camera and Spectrometer (PACS), and SPIRE photometric and the Institute for Radio Astronomy in the Millimeter Range (IRAM) telescope data is also analysed.