dataesr/scientific-paragraphs-categorization huggingface dataset:
Computational modelling of the p. Gly445_Leu453del AMHR2 intracellular domain For the WT AMHR2 kinase domain, a previous model (referred as WT) based on the crystallographic structure of the human activin type II B receptor (PDB code 2qlu), which shares ~35% sequence identity with AMHR2, was used (for more details see  Belville et al. , 2009). The 3D-model bearing the p. Gly445_Leu453del deletion (referred as DEL) was generated on the basis of the WT model, using the Modeler V9. 2 package  (Sali and Blundell, 1993)  and evaluated by Errat  (Colovos and Yeates, 1993). The three-dimensional models generated were submitted to a 100 ns molecular dynamics simulation. Both systems were set up following the same protocol and using the xleap program. The system was embedded in a cubic box with edges at 15 A ˚from the protein and sodium ions were added to neutralize the simulation cell (4 and 6 for WT and DEL models, respectively).
The protein was described by the ff14sb forcefield  (Maier et al. , 2015)  water molecules with the TIP3P  (Jorgensen et al. , 1983)  one and the ions94. lib library was used for the sodium cations. Nonbonded interactions were calculated with a cutoff of 10 A ˚, whereas long range electrostatic interactions were calculated with the Ewald Particle Mesh method  (Essmann et al. , 1995). A time step of 1 fs was used to integrate the equation of motion with a Langevin integrator  (Schneider and Stoll, 1978; Bru ¨nger et al. , 1984). Constant temperature and pressure were achieved by coupling the systems to a Monte Carlo barostat at 1. 01325 bar. Bonds involving hydrogen atoms were constrained using the SHAKE algorithm  (Ryckaert et al. , 1977). The simulations were performed with OpenMM 7. 0  (Eastman and Pande, 2015)  following a standard protocol included into OMMProtocol application (https://github.
Statistical analysis Sample sizes for physiological and neuroanatomical studies and gene expression analyses were estimated based on prior experience and those represented in the extant literature. Typically, mice taken from at least two different litters for each group were used. No stringent randomization method was used to assign subjects in the experimental groups or to process data. Quantitative RT-PCR gene expression data were analyzed using SDS 2. 4. 1 and Data Assist 3. 0. 1 software (Applied Biosystems, Carlsbad, CA). All other analyses were performed using Prism 5 (GraphPad Software). Data sets were assessed for normality (Shapiro-Wilk test) and variance. Where.
Acknowledgements We thank  M Tardivel  and  A Bongiovanni  (microscopy core facility),  M-H Gevaert  (histology core facility),  D Taillieu  and  J Devassine  (animal core facility) and the  BICeL core facility  of the  Lille University School of Medicine  for expert technical assistance. This work was supported by: the  Institut National de la Santeet de la Recherche Medicale (INSERM) ,  France  [grant number  U1172 ];  Agence Nationale de la Recherche (ANR) ,  France  [ ANR-14-CE12-0015-01  RoSes and GnRH to PG]; the  Centre Hospitalier Regional Universitaire ,  CHU de Lille, France (Bonus H  to PG and Ph. D. fellowship to NEHM); the  European Research Council (ERC)  under the European Union's  Horizon 2020 research and innovation program  ( ERC-2016-CoG  to PG grant n˚725149/REPRODAMH);  Horizon   2020 Marie Sklodowska-Curie actions -European Research Fellowship  ( H2020-MSCA-IF-2017 ) to MI; the  Spanish Ministerio de Ciencia e Innovacion  (grants  CTQ2017-87889-P  and  CTQ2017-83745-P  to LM, LAC and J-DM); the  Generalitat de Catalunya  (grant  2017SGR1323  to LAC and  J-DM ).
Pyrosequencing and taxonomic assignment Total genomic DNA extraction of soil samples was performed using Ultraclean Water DNA Kit (MoBio Laboratories, Inc. ) according to the manufacturer's protocol. The extracted DNA was purified using the Power Clean DNA Clean-Up Kit (Mo Bio laboratories). The quality and concentration of the purified DNA was determined by spectrophotometer analysis and 1. 5% agarose gel electrophoresis. DNA samples were stored at À20 C for sequencing. The V4 region of the bacteria 16S rRNA was amplified using region-specific primers for paired-ends sequencing on Illumina MiSeq platform (BGI, Wuhan, China). The sequences displaying more than 97% identity with each other were grouped into one operational taxonomic unit (OTU) using software QIIME (version 1. 9. 0, USA) based on greengene database.
Metagenome predictions from 16S data Sequencing data of 16S rRNA were used to predict metagenome of microbes by PICRUSt (phylogenetic investigation of communities by reconstruction of unobserved states), which uses an extended ancestral-state reconstruction algorithm to predict which gene families are present and then combines gene families to estimate the composite metagenome  (Langille et al. , 2013). The resulting sequences were assembled and annotated based on KEGG database and 3. 2G metabolic related genes were obtained from the samples. All the analysis were made by PICRUSt 1. 1. 1 script (http://picrust. github. io/picrust/). The figures were made by STAMP v2. 1. 3.
Statistical analysis The student's T test (p < 0. 01) of sulfonamides removal ratio were conducted using SPSS version 21. In the statistical analysis between relative abundance of bacterial taxa and predicted functional gene in community before and after sulfonamides pressure, significant difference were identified with a confidence interval of 95%. Principle component analysis (PCA) of microbial taxonomy and predicted KEGG pathways were conducted by Canoco version 4. 5 to evaluate the diversity of microbial community structure and function. Redundancy analysis (RDA) was also conducted to reveal the influence of environmental factors on microbial community alternation.
Acknowledgments This project was supported by the  Dunea drinking water company, Topsector Water TKI Water Technology Program of the Dutch Ministry of Economic Affairs , the  Netherlands  (No. 2013TUD001 ), the  Major Science and Technology Program for Water Pollution Control and Treatment of China  (Grant No. 2017ZX07602-003 ,  2012ZX07204-003 ), and the  Key Program of National Natural Science Foundation of China  (Grant No. 41230640 ), all of which are greatly appreciated. Thank the  China Scholarship Council  for supporting our work (201506190085).
They differ from first-generation sensor networks, not only in their goal to support concurrent people-centric and opportunistic sensing applications in urban environments, but also in their hardware and software heterogeneity, high volatility, and very large scale. CarTel  [12] , MetroSense  [13] , MobiScopes  [14] , SenseWeb  [15] , Urbanet  [16]  and Urban Atmospheres  [17]  are examples of such systems. To report information from a given region using these systems, applications run sensing tasks on the mobile devices that are located in this region and that have chosen to participate to the sensing process. Mobile devices report sensor data through opportunistic network connections, such as those they establish with third-party access points existing in their radio range. For instance in CarTel, a network node is a mobile device coupled to a set of sensors.
Each node gathers and processes sensor data locally before delivering them to a central portal on the Internet, where the data are stored in a database for further analysis and visualization. Mobile devices opportunistically communicate, using their wireless interface (e. g. Wi-Fi, Bluetooth), with other CarTel mobile devices and with Internet access points found in urban areas. The portal and the mobile nodes use a delay-tolerant network stack, called CafNet, to communicate. CarTel applications run on the portal, and submit SQL queries to a delay-tolerant continuous query processor called ICEDB. This query processor maintains a list of queries submitted by the applications, and pushes them to remote nodes using CafNet. It receives results from remote nodes, and puts them into a relational database.
These solutions respectively present the network 1) as a distributed sensor database that can be queried via a SQL-like language, 2) as a single virtual name space that applications use to access individual resources offered by nodes, and 3) as a client-service model where services migrate to different network nodes to maintain a semantically correct and continuous interaction with clients. The above-mentioned works have drawbacks regarding the opportunistic protocol they implement, as well as Web-based approach they propose. Indeed like CafNet  [21] , opportunistic protocols used in these works often rely on a simple epidemic (nodes exchange with the other nodes they encounter all the messages they have). Yet, such an epidemic approach is known to not be the more efficient one, especially when there is a lot of data to exchange; more sophisticated and efficient opportunistic protocols have indeed been proposed to address the issues of the epidemic routing protocol  [22].
Finally, as WoT applications can be partially or fully developed in Javascript, a part of the application can be executed on the client side, thus allowing to be compliant with REST optional "code-on-demand" constraint, and to reduce the computation load on the physical objects. Like most of the disruption-tolerant communication systems, our system implements a multiple copy forwarding strategy. It can thus take advantage of these message transmission models to increase the message delivery probability and to reduce the response time in a WoT context. For instance, several sensors can simultaneously be invoked using a multicast transmission model without naming them explicitly. All the responses returned by these sensors will be transmitted to the client. The system we have developed allows to invoke services using the HTTP and CoAP application-level protocols.
Contribution of the Web of Things The Web of Things allows to control and to communicate with physical objects through the logical software entities that represent them in the Web, and via Web standards and protocols. These logical software entities allow 1) to describe the objects, 2) to syntactically and semantically describe functionalities (i. e. the Web services) providing access to hardware capabilities of the physical objects, 3) to establish communications with the physical objects, by eventually adapting the Web protocols and standards to the proprietary protocols and data formats used by the objects, 4) to provide environment to deliver and to run WoT applications. Thanks to these logical software entities, physical objects can be combined together using Web mashup techniques so as to create complex cyber-physical systems that can be, for instance, designed for the smart agriculture.
Various contextual properties can be taken into account, such as the location of the object, its processing and memory capacities and its power budget. Functionalities are exposed as REST services by the WoT module, and therefore can be invoked remotely by WoT applications (WoTApps) or by other avatars for collaboration purposes. The WoT application container deploys and manages the life-cycle of WoTApps. WoTApps can fully run server-side (i. e. on the avatar), be distributed and executed both on the avatar and in a Web browser, or be exclusively run in a Web browser. Finally, avatars implement a collaboration module relying on an agent-based approach. This module aims at endowing an autonomous behavior to the avatar and physical object, so that they can discover the functionalities they can partially achieve and that require the help of other avatars to be performed.
After discovering the missing functionality in another avatar, they can enroll this avatar to provide the functionality. The main differences between the proposition of the W3C for the WoT, called Servient  [36] , and the avatar-based model reside in the ability of avatars to tolerate the connectivity disruptions, to dynamically adapt their behavior and the functionalities they provide to their running context, to automatically deploy new functionalities inferred on the basis of the semantic description of more elementary ones, and to collaborate with other avatars. Indeed like avatars, servients implement a legacy communication module that makes it possible to communicate with physical objects using proprietary protocols, a protocol binding module that allows to use several types of applicative protocols (MQTT, HTTP, CoAP) to communicate with the servients, a model of resources and of description of objects, and a runtime environment to run WoTApps.
Avatar runtime environment In order to configure themselves automatically, avatars rely on a set of semantic and code repositories as represented on Figure  5. These repositories contain device setups, semantic descriptions of capabilities and functionalities of avatars and semantic descriptions of execution contexts. The code repositories provide independent syntactic descriptions of REST interfaces of functionalities, and specific implementations of capabilities, functionalities and WoTApps. Most of capabilities are device dependent, which is not the case of the functionalities. The implementations of functionalities can still differ for non functional purposes such as quality of service requirements. Avatars download pieces of code from the code repositories and deploy them locally, doing so they instantiate new capabilities and functionalities, and infer new high-level ones progressively.
Technical Implementation The ASAWoO runtime environment is developed in Java and is based on the OSGi Apache Felix platform 2. It is designed as a set of services that are deployed using bundles (i. e. a JAR augmented with metadata), and that manage the life-cycle of avatars. An avatar (i. e. the different modules and managers forming the avatar's architecture) is also implemented as a set of OSGi services. Configuration files and the pieces of code of capabilities, functionalities and WoTApps are also deployed using bundles. Code repositories are implemented by OSGi Bundle Repositories (OBR), which can be either local on remote. An OBR offers a customizable dependency management that has been tuned to take into account functionalities and capabilities requirements. The semantic reasoner module depends on Apache Jena 3  inference engine and queries Fuseki SPARQL endpoints.
In the current implementation, the Vert. x 4 stack is used to serve WoTApps and to expose functionalities as REST services over HTTP. Vert. x handler mechanism also helps in managing asynchronous calls to functionalites. The opportunistic communication module implementation based on C3PO has already been thoroughly covered in subsection 3. 1. 2 and in  [31]. ASAWoO source code which is distributed under the CeCILL license (compatible with GNU GPLv2), is available in GIT repository  5  and users and developers documentation can be accessed on ASAWoO website 6.
Presentation of the experiment environment Montoldre experimental farm is a large plot of agricultural land dedicated to the experimentation of agricultural techniques, especially fertilizer spreading techniques. The area shown on the satellite view Figure  6  is composed of a dozen fields (in red) maintained by a handful of agricultural vehicles. The application considered in this first experiment consisted in collecting environmental data (humidity and temperature) measured by sensors. This experiment was ran in the early stages of ASAWoO development. Even though the whole middleware was not complete at that time, the opportunistic communication module was operational. Hardened sensors that can be exposed to bad weather conditions were also not ready to use for this experiment. Consequently, we used tiny single-board computers (RaspberryPi's) equipped with Wi-Fi antennas that produce data exactly as the sensors would have done.
As these devices are not hardened, they were placed in farm buildings, as shown in Figure  7. These experimental conditions may appear as degraded, but those are not in reality because the communication behavior of sensors has been reproduced as accurately as possible. This experiment allowed us to validate the RESTful opportunistic communication support presented in Section 3. Three instances of ASAWoO runtime have been deployed on RaspberryPi's equipped with 5dB Wi-Fi antennas. The first one, identified as RASP00, acted as a base station located in IRSTEA office at the limit of Wi-Fi communication range from the tractors' warehouse. The two other RaspberryPi's (RASP01 and RASP02) were equipped with an external battery pack and a GPS module. The kits were embedded on two tractors. GPS antennas were placed on the tractors' roofs and the battery power cords were plugged into the tractors' cigarette lighters to power up/on the Raspberry and recharge.
Two other self-powered RaspberryPi's with smaller range acting as sensors have been deployed in farm buildings located on tractors paths. Locations of the five nodes are shown on the map Figure  7. The embedded system deployed on sensors was restricted to ASAWoO communication module since the whole middleware stack was not required. During this experiment, the sensors produced data every 30 minutes. During the 4 months of experimentation, over 30 trips have been monitored. Mobility traces of RASP01 and RASP02 (i. e. tractors) have been stored in log files, as well as the contacts and exchanges between tractors and the base station). Logs were compiled and sent to the base station when entering its radio range. A ssh tunnel between the base station at IRSTEA and our lab has been established in order to access the logs, update the code if necessary, and remotely monitor the experiment throughout its progress.
Evaluation of the Web of Things approach The experiment described in the previous section focused on the validation of ASAWoO opportunistic communication capabilities whereas the Web of Things aspect could not be tested at that time. WoT modules were nonetheless still validated in the later stages of ASAWoO development in another experiment which will be shortly presented in this subsection. During the Montoldre experiment ASAWoO middleware mainly consisted of the avatar core, the functionalities management and registry features (i. e. functionalities were advertised as RESTful services) plus the opportunistic communication module. The second experiment was run in Bordeaux, France. It introduced the device manager and the semantic reasoning features to instantiate capabilities, simple and composite functionalities, as well as the WoT Application module.
Unlike the farm experiment which spanned over 4 months, this one lasted only one day. Since the communication module had already been validated in the long-run experiment, the goal was to validate ASAWoO final stage, particularly the WoT related modules (e. g. WoTApp manager, automatic instantiation of functionalities from device configurations and semantic repositories,. ). This experiment was based on the same data collection WoTApp and the same hardware kits. Although the RaspberryPi-based kits (with GPS module and Wi-Fi interface) have been reused, this time the data mule was a robot, the Jackal all-terrain mobile platform 8 , on which was deployed an instance of ASAWoO hosting its own avatar. Figure  10  shows a picture of the robot and the packaged base station kit on the experimentation field.
In addition to its navigation capabilities, a camera was mounted on the platform. A ROS 9 bridge interoperability module was developed for ASAWoO to expose these capabilities, which in turn enabled higher level functionalities such as person detection and video surveillance. The video surveillance and the navigation functionalities were then combined to provide a patrol functionality. The scenario written for this experiment consisted in making the robot patrol from sensor to sensor to collect data as long as it did not encounter a person. If the video surveillance functionality was to trigger an alarm, the reasoning module will give priority to the patrol functionality and use the navigation functionality to go back to a rallying point. This scenario is illustrated on ASAWoO code repository homepage 10.
Acknowledgments: The experiment presented in this article would not have been possible without the helpful support provided by  IRSTEA from Montoldre and Clermont-Ferrand. We would also like to thank other partners for their valuable contributions to the  ASAWoO  project: TWEAK team from  Lyon 1 university LIRIS lab  (http://liris. cnrs. fr/),COSY team from  Valence-Grenoble LCIS lab  (http://lcis. grenoble-inp. fr/), and  Generation Robots  (https://generationrobots. com/).
Introduction Quantitative modeling in systems biology allows scientists to produce formal models of biological systems and then to implement them on computers  [1, 2]. With such computational models, scientists can perform in silico experiments which have the advantage of being less costly in time and resources than the traditional wet-lab experiments. However, the stumbling block of in silico approaches is that they are built from the available knowledge: not all is known about everything. Nevertheless, an impressive and ever increasing amount of biological knowledge is already available in the scientific literature, databases and knowledge bases such as KEGG  [3]  and Reactome  [4]. In addition to the difficulty of integrating an increasing body of knowledge comes the inherent complexity of biological systems themselves  [5] [6] [7] [8] [9] [10] : this is where computational tools can help owing to their integrative power  [11] [12] [13] [14] [15] [16] [17] [18].
Implementation In the present work, k is not the time, it only represents the iterations performed during a run. Although quantifying time through k is possible, here the goal is to visualize sequences of events linked by causal connections without time quantification. To do so, k 0 = 1 and k end = 50. The initial state e ij (k 0 ) of each edge e ij is assumed to be equal to the initial state x i (k 0 ) of its source node x i : e ij (k 0 ) = x i (k 0 ). To illustrate the proposed logic-based modeling approach, it is implemented on a toy network using R  [96]. The code is freely available on GitHub at https://github. com/arnaudporet/smoosim.
The World Urban Database and Access Portal Tools (WUDAPT) project has grown out of the need for better information on the form and function of cities globally. Cities are described using Local Climate Zones (LCZ), which are associated with a range of key urban climate model parameters and thus can serve as inputs to high resolution urban climate models. We refer to this as level 0 data for each city. The LCZ level 0 product is produced using freely available Landsat imagery, crowdsourced training areas from the community, and the open source SAGA software. This paper outlines the protocol by which LCZ maps generated by different members of the community are produced and evaluated. In particular, the quality assessment comprises cross-validation, review, and cross-comparison with other data sets.
Introduction The World Urban Database and Access Portal Tools (WUDAPT) project has grown out of the need for better information on the form and function of cities globally  (Mills et al. , 2015). Developed as a bottomup initiative from members of the urban climate community, cities are being classified using the Local Climate Zone (LCZ) scheme developed by  Stewart and Oke (2012). Consisting of 10 urban classes and 7 natural classes (see Fig. 1b ), the LCZ classification provides a rich source of information about urban areas that is consistent and comparable across cities. Although data sets of urban or built-up areas exist, they either lack detail beyond urban/non-urban classes, e. g. the Global Human Settlement Layer (GHSL) produced by the JRC  (Pesaresi et al. , 2013)  and the Global Urban Footprint (GUF+) product of DLR  (Esch et al.