dataesr/scientific-paragraphs-categorization huggingface dataset:
Our paper is organized as follows. In Section 2, naRyQ is first briefly recall and then we present our definition of its coherence. In Section 3, its evolution activity is detailed. Section 4 present the implementation of our evolution approach, called DynarOnto, and its evaluation. The presentation of DynarOnto is illustrated in Section 4 through an ONDINE system's use case, the annotation of experimental data in the domain of matter transfer. Finally, we conclude in Section 5.
, Buche, P. , Dervaux, S. , Touhami, R. , Dibie, J. (  2016 ). Ontology evolution for an experimental data integration system. International Journal of Metadata, Semantics and Ontologies, 11 (4), 231-242. , DOI : 10. 1504/IJMSO. 2016. 10004259 dependent concepts and the SKOS representation of its terminological component are presented below. A full list of CC-constraints defined for naRyQ can be found in  Touhami (2015).
DynarOnto The ontology evolution activity presented above is implemented as a Protégé plug-in (Protégé is a free open source ontology editor available at http:// protege. stanford. edu/) called DynarOnto. It aims to implement the ONDINE evolution subsystem and assists domain experts in the naRyQ evolution activity. Fifteen kits of changes that was identified as the most usefull by the domain experts on the sixty three ones were implemented in DynarOnto. This section deals with the presentation of DynarOnto and its illustration through a use case in ONDINE system: the annotation of experimental data which needs an OTR evolution. We first briefly present the annotation subsystem of ONDINE, then DynarOnto through a use case and finally the evaluation of DynarOnto.
The use case Let us focus on the fourth step, the table annotation, of @Web annotation module from Figure  5  and consider the TRANSMAT OTR from Figure  3  and the data table from Figure  6. The domain expert have to select the relevant n-ary relation concept(s) of TRANSMAT to semantically annotate the data table. To do so, he/she is guided by the experimental result(s) of the target nary relation concept(s). Two experimental results can be identified in the data table of Figure  6   O2 permeability that is its experimental result. The domain expert can select this n-ary relation concept to annotate the data table. Let us notice that the data table of Figure  6  does not necessarily contain all the arguments of the n-ary relation concept to be annotated with it. In our case, there are three missing arguments in the data table of Figure  6  which only contains the temperature (the first column T( • C)), the relative humidity (the second column RH %) and O2 permeability (the fourth column).
Annotation of a data table through the use case After the update step of the TRANSMAT OTR presented in the previous section, the data table of  module to annotate this data table, that are O2 permeability Relation and CO2 permeability Relation. The signature of both n-ary relation concepts (i. e. their set of arguments) are visualized in a table, one signature per row. This will guide the domain expert in his/her annotation task, allowing him/her not to forget to fulfill arguments of the selected n-ary relation concepts which guarantee the validity and reusability of data. Figure  9  shows the original data table and its annotation using @Web. Let us notice that the missing arguments packaging and thickness in the original data table have been manually extracted from the corresponding scientific textual document by the domain expert in order to complement the data table annotation.
g. the particular amino acid at a certain point in a protein sequence or the presence or absence of a post-translational modification like phosphorylation. The various notions of 'site graph' in the line of work on the definition of the rule-based modelling language Kappa in terms of graph rewriting  [4, 6, 7]  correspond to more constrained variants of this general definition. The principal present novelty is to avoid hard-wiring the various kinds of nodes that can exist-agents, sites, &c. -and their hierarchical structure. Instead, it proposes a homogeneous space of nodes with a structure S that can capture arbitrary relationships between nodes. Our particular choice of meta-model, made in section 2. 3, assigns a DAG structure to S so that it does indeed correspond to a (generalized) notion of hierarchical organization.
Acknowledgement. This work was sponsored by the  Defense Advanced Research Projects Agency (DARPA)  and the  U. S. Army Research Office  under grant numbers  W911NF-14-1-0367  and  W911NF-15-1-0544. The views, opinions, and/or findings contained in this report are those of the authors and should not be interpreted as representing the official views or policies, either expressed or implied, of the  Defense Advanced Research Projects Agency  or the  Department of Defense.
Thus, for any point at any instant, the temperature can be expressed as T = N i α i ϕ(x, t), where the set of POD modes ϕ i (x, t) constitutes the reduced basis. The number of modes N should be small, let us say less than ten, and the different families of processes should be created to achieve this goal. Optimizing the selection of families of welding processes is the subject of current research. The material volume must be large enough to capture the strong thermal gradients around the heat source. These thermal snapshots can be computed using the Smart-GFEM. However, we use the commercial code SYSWELD because all the metallurgical models are already included, which are not yet available in our Smart-GFEM implementation. Then, a set of elasto-plastic problems are solved in the material local volume imposing homogeneous essential boundary conditions.
Data Forty four metazoan species pairs were analysed (S1 Table ). Each pair consisted of a focal species, in which at least four diploid individuals were available, and a closely-related outgroup species. The data set was based on two recent transcriptome-based population genomic reports  [35, 38]. Five species were newly sequenced in this study (one individual each). The sample covered eight metazoan phyla: 18 pairs of vertebrates (of which twelve mammals), eleven arthropods (of which eight insects), five molluscs, four echinoderms, two tunicates, one annelid, one nematode, one nemertian and one cnidarian. Focal species sample size varied from four to eleven individuals, and was seven or more in 26 species. Ten of the twelve mammalian species had a sample size of four  [38]. The number of analysed coding sequences varied between 295 (Black and white ruffed lemur Varecia variegata variegata) and 7951 (small skipper Thymelicus sylvestris), the median being 1900.
Effect of sample size Our dataset is heterogeneous across species in terms of number of analyzed individuals. We investigated the influence of sample size on our results in two ways. We first re-conducted the above analyses using only the 25 species for which at least eight individuals were available. Similar to the full dataset analysis, we found a significantly negative relationship between d N /d S and log-transformed π S , and between ω na and log-transformed π S. No significant correlation, however, was detected between α and π S with the large sample-size dataset, and ω a was negatively related to π S (Table  1 , analysis B)-an intriguing result that contradicts the N e hypothesis. It should be noted that taxon sampling is more evenly balanced amongst animal phyla in this 25 species data set, which includes only two mammalian species, than in the complete data set, which includes twelve mammals.
Data sets The data set was built based on two recent population genomic studies of, respectively, 16 mammalian  [38]  and 76 metazoan  [35]  species. In these two contributions, two to eleven individuals per species were sampled from distinct populations and subjected to massive mRNA sequencing. From this sample we identified 35 focal species for which (i) at least four individuals had been sequenced, (ii) a closely-related outgroup was available, and (iii) at least 100 synonymous SNPs and 100 non-synonymous SNPs had been called. We added nine outgroup species (one individual each), of which four were already published  [21, 62, 63]  and five were newly sequenced here, increasing the total sample size to 44 species pairs (species list and SRA IDs in S1 Table ). Not all these species pairs are fully independent from each other: when four individuals or more were available in each of two closely species, two species pairs were defined, hereafter referred to as "mirror species pairs", each species serving as outgroup to the other one.
In each focal species, the synonymous, P S , and the non-synonymous, P N , unfolded SFS were built by computing the observed frequency of derived alleles, and summing counts across genes. An unfolded SFS is a vector of 2n-1 entries corresponding to the counts of SNPs at which the absolute frequency of the derived allele is 1, 2,. , 2n-1, respectively, where n is the sample number of diploid individuals. SNP orientation was deduced from the outgroup state. SNPs for which the outgroup was polymorphic or distinct from any of the focal species alleles were discarded, as well as tri-allelic and tetra-allelic SNPs. For each species pair, the data set consisted of 4n data points: D N , D S , and the 2n-1 entries of each of P N and P S. Capital letters are used here to denote counts, lower case d N , d S , p N and p S being used for rates-i.
This version, which was called [-A], has one less degree of freedom than the classical. Comparing the two versions is a way to test whether the divergence pattern is appropriately predicted by polymorphism data and the model, or if an extra parameter is needed. Models were compared using likelihood-ratio tests (LRT) when nested, and Akaike's Information Criterion (AIC) otherwise. Integrals in eqs (  3 ), (  7 ), (  9 ) and (  15 ) were calculated numerically. The likelihood was maximized using the Newton-Raphson method. Confidence intervals around estimates of α were defined as values of α for which the log-likelihood was within two units of its maximum. A C+ + program implementing these methods was written based on the Bio++ libraries  [68]. Source code and Linux executable files are available upon request.
• We provide a methodology for deploying these networks. • We contribute with open-source software to perform pre-deployment range tests, manage the network, and store/display sensor measurements and network statistics. • We describe a complete turn-key solution for precision agriculture applications, built entirely from commercial off-the-shelf proven technology. The remainder of this article is organized as follows. Section 2 provides the necessary background on how peach growth is affected by frost events, and the major impact frost has on the economy. Section 3 surveys low-power wireless technology used in environmental sensing applications, with a particular focus on SmartMesh IP. Section 4 introduces the hardware deployed in the PEACH project, and the initial range testing procedure used.
Low-power Wireless Technology The goal of the PEACH project is to retrieve data from different types of sensors deployed densely across a peach orchard. Because heavy machinery is used throughout the field, using wires to interconnect the sensors is not an option. We instead use low-power wireless mesh networks. Our requirement is that the security and reliability of those wireless networks must be equivalent to that of a wired network. Our target battery lifetime for the devices is "at least a year", the natural grow cycle of peaches. This project is not a low-power wireless project, i. e. we need a technical solution that "just works". While very interesting research can be done with academic projects  [7, 8]  (there are many in the research field of low-power wireless), we need a product that is thoroughly tested, proven and commercially available off-the-shelf.
Three types of statistics are generated: internal counters of the mote (e. g. packet counters), the list of neighbors the mote is communicating with, and the list of neighbors the mote can hear but is not communicating with. A mote generates a complete set of health reports every 15 min. They are the base for assessing the performance of the network, as done in Section 7. A SmartMesh IP network is fully synchronized, and time is split up into timeslots. A schedule orchestrates all communication in a SmartMesh IP network and indicates what to do in each timeslot: transmit, listen or sleep. How the schedule is built and maintained allows a clear trade-off between the amount of data generated by the sensors, the communication latency, and the power consumption of the motes. The "Dust Networks SmartMesh Power and Performance Estimator" is a tool provided by Dust Networks 2  that allows one to estimate the power consumption and latency of a SmartMesh IP network, given the topology and amount of data generated.
All the boards deployed during Phase 1 run the default SmartMesh IP firmware. Each board automatically joins the network and sends a temperature reading every 30 s to the manager, using its built-in temperature sensor. In Phase 2, we will reprogram the motes with custom firmware, using the "DustCloud" development environment provided by Linear Technology 7. 6 http://metronomesystems. com/ 7 http://www. dustcloud. org/.
Low-power Wireless Manager Fig. 4 (a) shows the SmartMesh IP manager used in the PEACH project. It is composed of an LTP5902-IPR SmartMesh IP manager chip, a 2 dBi external antenna and USB connectivity, in the form-factor of a USB pen drive. USB connectivity is used to connect the DC2274 to a computer. The computer can run a program to configure the DC2274, send commands and configurations to the motes, and retrieve sensor measurements. The DC2274 is a standalone device, i. e. the computer does not play any active role in operating/managing the network, it just serves as an interface between the SmartMesh IP network and the Internet. The DC2274 is an off-the-shelf commercially available board.
Hardware Integration The PEACH network is deployed in an orchard for 2 years, and will be exposed to direct sunlight, freezing temperatures, dust and rain. All motes and manager are therefore protected by an enclosure with Internal Protection 65 (IP65) rating  8. Fig. 5 (a) shows the manager enclosure with the lid open. It contains the DC2274 board, a Raspberry Pi single-board computer running the solmanager software (see Section 6. 2), and the power adapter for that board. The DC2274 is powered through USB. A watertight pass-through opening in the manager enclosure is used to pass power and Ethernet cables. Fig. 5 (b) shows a mote in its enclosure. The mote is powered by a pair of Energizer L-91 AA batteries with a charge of 2821 mAh  9. The mote, antenna and battery are glued in place using silicone.
One transmitter mote (marked "TX") is configured in radiotest mode to transmit 40-byte packets every 10 ms, round-robin on 4 frequencies evenly spaced in the 2. 4 GHz frequency band 11. We use multiple frequencies since SmartMesh IP uses channel hopping. A receiver mote (marked "RX") is connected to a laptop computer running the RangeTest application. This application, through the serial API of the mote, has the mote listen for 4 s on each of the 4 frequencies, and counts the number of received packets. During that 4 s listening window, the 10 As an online addition to this article, the source code of the RangeTest application is available under an open-source BSD license at https://github. com/realms-team/rangetest. 11 We use frequencies 2. 405 GHz, 2. 425 GHz, 2. 445 GHz and 2. 465 GHz RangeTest application expects to receive 100 packets; receiving fewer packets indicates a less-than-perfect wireless link.
Long-range motes are attached to existing poles (Fig. 10(a) ). Dedicated poles are placed in the orchard (Fig. 10(b) ). Deployment itself is straightforward and fast. We switch on the mote to be deployed, close the lid, screw it on its pole, and verify that it has joined the network and that we can "ping" it over the SmartMesh IP network. The entire PEACH deployment took less than 4 hours; most of the time spent moving from location to location and securing the mote enclosures to the poles. A SOL Registry contains the list of SOL types currently used, and their format. This includes data generated by the motes, health reports or network events. Each SOL object can be represented either in a compact binary form, or in a more easily parseable JSON format. The SOL registry is publicly maintained and can be easily augmented with new types of sensor data 13.
solserver The solserver application runs on a server in the Inria-Paris research center. The application listens for incoming SOL objects. When those objects are received from a properly authorized solmanager application, the solserver converts them from their binary representation to their JSON representation, and writes them into a database 14. A dashboard allows a user to visualize key information 15. Fig. 12  shows an example dashboard with 7 days worth of data, including the temperature (the day/night temperature swing is clearly visible, the last day being cold), the number of discovered neighbors, and the charge consumed by the devices.
Performance Results All motes in the network produce a complete health report every 15 min. On top of this, the SmartMesh IP manager provides a complete CLI (Command Line Interface) on one of its serial ports for an operator to type commands and retrieve information about the network. We base the analysis in this section on the data retrieved from the health reports and the CLI of the SmartMesh IP manager. We divide the performance results in the performance of the overall network (Section 7. 1) and the performance of the motes (Section 7. 2).
Performance of the Network Table  1  summarizes the network performance after 5 days and 6 hours of operation. After approx. 24 hours of operation, a SmartMesh IP network reaches "steady state", so we expect the numbers presented in this 14 We use an influxdb (https://influxdata. com/) database. 15 The dashboard is publicly available on the PEACH project website (http://www. savethepeaches. com/). reliability 100% (Arrived/Lost: 243089/0) stability 93% (Transmit/Fails: 1462435/96923) latency 800 ms Table  1. Key network performance indicators. section to be representative of the lifetime of the network. The network reliability indicates the portion of the packets generated by the motes that reach their final destination, in our case the SmartMesh IP manager. A packet is said "lost" when it never reaches its destination.
The motes in the PEACH deployment have generated 243,089 packets, all were successfully received by the SmartMesh IP manager, possibly after multiple hops, yielding 100% reliability. The wireless medium is unreliable in nature, and it is common that a link-layer frame sent by mote A is not received by mote B, forcing A to re-transmit. The network stability represents the average PDR over the link. The motes in the PEACH deployment have sent 1,462,435 data-link frames, 96,923 unsuccessfully (i. e. no link-layer acknowledgment was received), yielding a network stability of 93%. This number is very high, indicating that the nodes are deployed close enough in an environment with little external interference and multi-path fading. A SmartMesh IP network is fully synchronized. A mote generating a data packet adds a timestamp to its data so that what is written in the database is the time the sensor is sampled (not the time it reaches the database).
Ongoing Work and Roadmap Today, we are only 5 months into the 2-year PEACH project. While the choices for the base networking technology are validated by the work presented in this article, a lot still needs to be done. The first step is to add additional sensors to the motes, including relative air humidity, soil moisture, soil temperature and soil conductivity. This might include adding NeoMotes to the deployment. One aspect of the PEACH project that is missing so far is the data analysis. We plan to apply machine learning techniques, in particular ensemble regression-tree, on the large-scale sensor measurement dataset. This will require us to augment the sensor measurements with features that could help predict frost events. We plan to connect an anemometer to the deployment, and to conduct partial flooding of the orchard to quantify the impact of flooding on the intensity of frost events.
Data on primary ciliary dyskinesia (PCD) epidemiology is scarce and published studies are characterised by low numbers. In the framework of the European Union project BESTCILIA we aimed to combine all available datasets in a retrospective international PCD cohort (iPCD Cohort). We identified eligible datasets by performing a systematic review of published studies containing clinical information on PCD, and by contacting members of past and current European Respiratory Society Task Forces on PCD. We compared the contents of the datasets, clarified definitions and pooled them in a standardised format. As of April 2016 the iPCD Cohort includes data on 3013 patients from 18 countries. It includes data on diagnostic evaluations, symptoms, lung function, growth and treatments. Longitudinal data are currently available for 542 patients.
The extent of clinical details per patient varies between centres. More than 50% of patients have a definite PCD diagnosis based on recent guidelines. Children aged 10-19 years are the largest age group, followed by younger children (⩽9 years) and young adults (20-29 years). This is the largest observational PCD dataset available to date. It will allow us to answer pertinent questions on clinical phenotype, disease severity, prognosis and effect of treatments, and to investigate genotype-phenotype correlations.
This European network, under the framework of the European Union's Seventh Framework Programme (EU FP7) project BESTCILIA (Better Experimental Screening and Treatment for Primary Ciliary Dyskinesia), joined forces with the North American Genetic Disorders of Mucociliary clearance Consortium. Two work packages of BESTCILIA aimed to improve the availability of international datasets for PCD patients: 1) by setting up a prospective international PCD registry  [26] , to allow standardised data collection in the future, and 2) by identifying and combining available data on PCD in a retrospective international cohort study. This article describes the aims and methods of the international PCD cohort (iPCD Cohort) and outlines how the data can be accessed for future research.
Aims of the iPCD Cohort The iPCD Cohort assembles available datasets with clinical and diagnostic data from PCD patients worldwide to answer pertinent questions on clinical phenotype, disease severity, prognosis and effect of treatments in patients with this rare multiorgan disease. This combined international dataset allows investigation of PCD epidemiology in a large international study population in order to: 1) describe the spectrum of clinical phenotypes and disease severity in PCD patients by age, sex and time period of diagnosis; 2) describe short-term and long-term prognosis of PCD, looking at important outcomes such as growth, lung function and respiratory failure, bacterial colonisation, hearing loss, fertility, and mortality; and 3) identify predictors of long-term outcomes such as age at diagnosis, clinical phenotype, ultrastructural defects, genotype and clinical care.
Systematic literature search In order to identify published data and eligible datasets we performed a systematic literature search for studies describing clinical manifestations in patients with PCD  [12]. We searched the online databases PubMed, Embase and Scopus for studies published since 1980, without restrictions on language or study design, including studies containing information on clinical manifestations of 10 or more PCD patients. We also checked the reference lists of articles to find additional studies. We identified 52 different studies and invited all corresponding authors to participate in the iPCD Cohort.