dataesr/scientific-paragraphs-categorization huggingface dataset:
Genomic Data The two mosquito genomes were sequenced with Illumina NGS technology (Illumina HiSeq2000). The A. albopictus strain originated from La Reunion Island, Indian Ocean. Genomic DNA was prepared from four female individuals of generation F5 bred in an insectarium. Sequencing generated 440. 2 million 100-bp paired-end reads (ProfilXpert platform, Lyon, France). A total sample of 4,243,902 single-end reads was also generated (R1's were used). Aedes aegypti female genomic reads (SRR871496; strain Liverpool; 213. 4 million 100-bp paired-end reads; ~16. 4Â coverage, Virginia Tech) were downloaded from the short-read archive collection (http://www. ncbi. nlm. nih. gov/sra, last accessed April 13, 2015); only the first read of each pair was used for analysis.
Read Preprocessing According to quality statistics, all reads were trimmed to 82 bp, keeping the nucleotides 10 through 91 in both A. albopictus and A. aegypti species. Then, sequences were filtered using FASTX-toolkit (http://hannonlab. cshl. edu/fastx_ toolkit/, last accessed April 13, 2015) with a minimum 20 average Phred score on 90% of the reads. Finally, reads from mitochondrial DNA were removed from the data with Bowtie 2 software (version 2. 1. 0) under default parameters to map reads to the whole mitochondrial genome sequence for each Aedes species available through the NCBI website (http:// www. ncbi. nlm. nih. gov/, last accessed April 13, 2015).
The subset sample of 4,243,902 reads (0. 3Â) was used to assemble TEs and repeats for A. albopictus, consisting of 2 samples of 0. 1Â genomic coverage for assembly and a third sample of 0. 1Â for the quantification step. This sample size was chosen after a preliminary analysis showed that 0. 1Â per Trinity run maximizes the assembly N50 for this genome (supplementary fig. S2 , Supplementary Material online). We suggest that this will balance finding as many repeats as possible with limiting the assembly of nonrepeated DNA (noise). For A. aegypti, coverage was also set to 0. 1Â, using reads taken from the full sequencing experiment based on a genome size of 1. 3 Gbp, according to the whole-genome assembly size and mean genome size estimations  (Nene et al. 2007 ; Gregory, T. R. (2015); Animal Genome Size Database.
TE Family Recovery and Quantification To cluster dnaPipeTE contigs into TE families, we used the cd-hit-est program from the CD-HIT suite (version 4. 6. 1) (Li and Godzik 2006)  with local alignment and the greedy algorithm. We set the clustering parameters to group pairs of sequences with at least 80% of the shortest sequence aligned, with a minimum of 80% identity in the longest sequence (parameters -aS 0,8 -c 0,8 -G 0 -g 1). This method results in better performance than grouping contigs per Trinity gene or by RM annotation. In the first case, contigs from one Trinity gene could be joined when they shared a conserved fragment (such as a protein domain), even if they did not actually belong to the same TE family. In the second case, RM annotations include only the closest sequences known, and one sequence could easily match to multiple TE families.
dnaPipeTE Comparison with RepeatExplorer Compared with dnaPipeTE, RE requires only one sample for assembly and annotation. We thus ran it using the "BLAT" sample generated by dnaPipeTE for the A. albopictus data set, on which an estimation of repeated content and a quantification of the main repeat families is performed. Computations were performed online with the "clustering" tool of the RE Galaxy server (http://repeatexplorer. umbr. cas. cz/, last accessed April 13, 2015) with the following parameters: 44 bp (55% of the read length) minimum overlap for clustering, 0. 01% cluster threshold for detailed analysis, 40 bp minimal overlap for read assembly and RepeatMasking against the "all" database. Computation time, contig number, N50, proportion of repeats in the sample, and percentage of annotation of the repeated content were calculated for comparison.
Efficiency of dnaPipeTE We report here the results obtained for D. melanogaster (fig. 3 ). Details and results from other species are presented in supplementary figures S1 and S3, Supplementary Material online. In D. melanogaster, as well as the other fully annotated genome tested, dnaPipeTE estimations for the different families of TEs are accurate when only a small subset sample of NGS sequencing reads was used as input (three samples of 0. 25Â coverage). The relative proportion of each TE order is respected in dnaPipeTE estimations. In D. (http://repeatmasker. org/genomicDatasets/ RMGenomicDatasets. html, last accessed April 13, 2015) were performed. These comparisons showed that dnaPipeTE provides a good estimate of the recent TE age distribution. As with other de novo TE assemblers, dnaPipeTE is limited in its ability to detect old TE families with degraded and divergent copies.
Comparison between dnaPipeTE and RepeatExplorer Our pipeline dnaPipeTE operates on the same principles as RE to estimate, assemble, and annotate the repeatome of a species from a sample of reads. Therefore, it was expected that similar estimates of global repeated content in A. albopictus would be obtained by RE and dnaPipeTE (table 2). However, dnaPipeTE, in addition to being much faster, was also able to FIG. 4. -Relative genome proportions of the main repeat classes found in Aedes albopictus using dnaPipeTE, from a nucleotide BLAST of 1,414,634 reads (0. 1Â) against the repeat assemblies performed with a total of 2,829,268 reads (0. 2Â). annotate a larger fraction of TEs and to compute larger contigs. However, RE seems to more sensitively estimate the proportion of low complexity and tandem repeat sequences (data not shown).
org/genomicDatasets/ RMGenomicDatasets. html, last accessed April 13, 2015). In both mosquito species, DNA-based transposons (Class II) are poorly represented compared with their relative genome proportion. However, this result might be explained by the removal of A. aegypti TE references from the library to avoid any bias toward this species in the annotation, which might have removed elements specific to the Aedes genus. Another explanation is that DNA transposons could belong to families with very few copies and/or result from an old invasion of the genome. Thus, our methodology, which is weaker beyond 15% divergence and for elements with few copies, could have missed old Class II elements. Ultimately, this could mean either that members of Class II are the first TEs to have invaded Aedes genomes or that Class I TEs are undergoing a new expansion wave.
albopictus  (McLain et al. 1987; Black and Rai 1988). dnaPipeTE: A Novel Tool for TE Comparative Studies Preliminary work on the A. albopictus repeatome led us to develop our own pipeline in order to address specific unmet needs. As the A. albopictus genome is especially large, we were interested in solutions using low coverage sequencing to find and quantify TEs and interspersed repeats. The most advanced software for this task previously available was RE (Novak et al. 2010), which allows the simultaneous location, quantification, and annotation of repeats from unassembled sequencing reads. However, we felt that some points could be improved by using NGS-specific tools. By using Trinity as a TE assembler on small genomic data sets, dnaPipeTE can recover larger TE contigs and can improve this step by performing multiple iterations with additional independent samples.
Thus it do does not require specific hardware equipment and can be deployed on commodity hardware at a low cost ownership. Creating or updating applications does not require deep technical knowledge. Tornado embeds a proprietary NoSQL bitemporal and column-oriented database management system (2TDBMS) that is continuously fed with data by external data sources. In order to cope with real-time constraints the query processing engine uses different types of continuous queries. Analysts with limited technical skills can create new analyses, tailor their dashboards and see the results of their modifications immediately on production data. Thus these applications evolve as user's needs evolve to meet the business evolution. As Tornado combines both real-time monitoring and BI functionalities, it enables analysts to consider operational data in the past, present, or future using the same tool.
A. Architecture Tornado is based on a service oriented, event-driven implementation using Java TM language. It is structured into three loosely coupled functional layers: Absorption Layer, Logic Layer and User Interface Layer. Absorption Layer: Tornado uses unobtrusive, agentless technology to collect, process and analyse real-time data as well as historical data. It is based on the Apache Camel engine that offers a wide range of possibilities to pull data from various types of sources. Logic Layer: The logic layer embeds a 2TDBMS specifically designed and optimized for Tornado. The power of that DBMS is its ability to handle both real-time streams and historical data and provide an unique interface to access to them. User interface layer: The user interface layer allows any web browsers using Adobe Flash technology to display information and from the logic layer.
B. Bi-temporal and Column-oriented Features The underlying DBMS is bitemporal, i. e it supports two orthogonal time dimensions: the transaction time  [6] , or system time, (tt) and the valid time  [7] , or application time. The support of transaction time enables to maintain a history of all modifications that occurred in the DB. The support of the valid time enables to maintain the history of data as it evolves in the modeled reality. The DBMS has the particularity of being column-oriented  [8] ,  [9]  which means that each attribute is stored in a separate column and its values are stored successively on disk. This contrasts with the row-oriented DBMS where attributes of the same tuples are stored consecutively. There are two reasons behind choosing a column-oriented database management system rather than a row oriented one.
First, column stores outperform row oriented database system on analytical workloads such as those found in business intelligence and decision support application  [10]. Secondly, the column oriented approach enables creation/suppression of columns with limited performance impacts, simplifying the data model update. Tornado stores data in an append-only mode. Each attribute is timestamped with two temporal attributes: 1) a valid time interval, provided by the application, that indicates the time during which the attribute's values are valid, 2) a transaction time, implicitly provided by the system during the transaction commit, that indicates when attribute's values are inserted into the DB. The query engine integrated in the logical layer is optimized for three classes of temporal queries: 1) Time Travel: Time travel is a feature that enables to build a view of a subpart of the database at a particular state considering a valid time and a transaction time instant.
It consists of all valid and accessible data at that state. As an example, a user might be interested in all unpaid orders in September 2nd 2014 midnight as database is currently recorded. 2) Temporal Aggregation: Tornado enables to compute aggregation functions over valid time while the transaction time is fixed to an instant. We consider two cases: aggregations over an instant and over a temporal range. In the first case, termed also Instantaneous Aggregation  [11] , we aggregate all valid tuples at an instant, e. g what is the number of payments with status='in process' in September 2nd 2014? In the second case, we aggregate all tuples associated to a time range using a temporal predicate. If we consider Kaufmann and al's classification of time ranges in temporal aggregations in  [12]  which uses the window concepts from data streams systems  [13] , Tornado supports three types of time ranges : 1) Tumbling Window, i.
C. Temporal Query Engine Tornado uses a dashboard as an user interface primitive allowing the analysts to visualize analyses and to navigate in time to understand how they evolve. A dashboard is composed of one or several graphical elements (diagrams, charts, datagrids,. ) termed pagelets. Each graphical element displays data returned by underlying queries. The use of an interactive GUI requires short response time from the database system to avoid any unpleasant display lags. In order to display a complete dashboard, the update time of associated queries must respect these performance constraints, despite their complexity and the growth of the DB size. In our case, all queries are completely specified once dashboards are created or modified. Our strategy consists in computing all defined analyses as data is collected by Tornado and storing results in the DB for a future use.
Thus in Tornado an analytical query, e. g as TPC-H ones, is executed as: 1) Persisted Continuous Queries: For each analysis, one query is implemented and is binded to a rhythm. We define a rhythm as a partition of the valid time domain into contiguous and equal-length time intervals, and a new attribute is added to the data model. For each interval of that rhythm Tornado executes the query on data associated to it considering their most recent state according to the transaction time. The result is valid on the computation interval and is stored in its dedicated attribute in the database for future uses. This type of queries are continuously executed by Tornado's query engine as data is available, i. e either collected by the system from external sources or produced by another analyses. 2) On-demand Queries: This type of queries is executed as long as it is necessary to refresh the pagelet it is bind to.
At the rate of 250 payments/minute, the total size of data stored in the DB is 1. 7GB/day: 0. 2GB/day is the data collected by Tornado and the rest are the results of the persisted continuous queries We assume that the application has reached the real-time step at the beginning of the the demonstration. The visitor of the demonstration will have the opportunity to understand Tornado through predefined queries. Then she will be invited to design its own pagelet and then explore analyses. In the second part, we design a pagelet that displays, e. g the number of new payments up to each day for the last 5 days computed every hour. The design of a pagelet is in two steps: 1) implementing analyses 2) designing the pagelet's GUI. 1) Defining Analyses: We implement, using the GUI, all continuous queries that we will need for our pagelet.
IV. CONCLUSION We have introduced Tornado, a platform embedding a column-store bi-temporal database system, devoted to historical and real-time bi-temporal data. Its main feature is to bring on manager's desktop precise and relevant indicators on its business. Tornado relies on two kind of technique: first, the data are summarized with relatively simple continuous queries and second, more elaborated queries providing key indicators to managers. We plan to conduct experiments of Tornado with the TCP-BiH benchmark  [15] , which is a bi-temporal extension of the TPC-H benchmark. We are also working on multi-query optimization techniques, and also incremental pre-computation mechanism introduced in  [16].
Introduction Formalizing knowledge has always presented an existential obsession and an important challenge for humans. The proposed solutions in the literature are mainly organized around databases, data warehouses and more recently ontologies. Ontologies are often defined as an explicit specification of a conceptualization of a domain  [1]. They make possible for a community to reach a consensus and to bridge the gap of the vocabulary heterogeneity and semantic ambiguities. Thanks to their advantages, ontologies are used in a large range of fields such as: semantic web  [2] , business decision support  [3] , image interpretation  [4] , peer-to-peer networks  [5] , etc. A counterpart of this popularity, is the constant augmentation of available ontologies. For example, the number of ontologies on the BioPortal increased of 67% in 2013 1.
). Thus, Djedidi et al. [12]  have proposed an approach of OWL ontologies evolution based on pattern conception. They have studied both the atomic and composite changes and have used the Pellet reasoner  [21]  to detect the inconsistencies. A deeper study of the composite changes is introduced by Javed et al. [22]. It has presented resolution strategies for several composite changes and has described a layered change log for the explicit operational representation of ontology changes. The change log is formalized using a graph-based approach and implemented by OWLAPI  6. To identify ontologies inconsistencies, Gueffaz et al. [23]  have proposed CLOCk (Change Log Ontology Checker) approach which use model checking. A transformation of the OWL ontologies into a specific language NuSMV 7  is needed.
Algebraic approaches are divided into two categories: the Single PushOut, SPO  [29]  and the Double PushOut, DPO  [30]. The DP O approach consists of two pushouts and requires an additional condition called the "dangling -Strategies proposed to the ontologist to resolve inconsistencies. -Global evolution process for KAON ontologies. -Saving the evolved version and traceability of the evolution process. -The set of consistency constraints heavily depend on the KAON language. Klein, 2004 [11]  OWL OntoView, PROMPTdiff -Identification and resolve of the inconsistencies. -Change management approach for distributed ontologies. -Identification of the difference between ontology versions. -Saving the traceability of the ontology changes. -A deeper study of the complex ontology changes. -Formalization of the change log using a graphbased approach.
EventCCAlps ontology In this section, we present the EventCCAlps OWL ontology used as a use-case study to describe and validate our research work. The ontology is developed in the frame of the European project CCAlps which aims at helping the collaboration between Creative Companies in Alpine space. It links companies and partners for the organization of events. The Figure  7  presents an extract from the EventCCAlps ontology represented with typed graph attributed formalism. Note that the ontology was converted into AGG graphs using our software OWLToGGX 8. The 8 http://mariem-mahfoudh. info/ksem2013/ Figure shows then, some entities which describe the organized events. An event can be a "Conference", a "Meeting" or a "BestComp". It starts at one day/time and finishes at another day/time, may be described by "Tag" and can receive "Particular" and "Company" participants.
To further evaluate the performance of our approach, we are currently working on evaluating the influence of the size of LHS on larger ontologies. In the near future, we are planning to develop a plugin for the Protege 10 editor which will present the different ontology changes. Indeed, the internal graph transformation engine of the AGG tool can be used by a Java API and thus, be integrated into other custom applications. Then, we intend to benefit from the formal operations of graph theory and category theory to study, without using Ontology Changes Djedidi et al. [12]  Proposed formalism AddObjectP roperty(OP, C1, C2) The change is composed of three basic changes: 1. AddObjectP roperty-(OP ), 2. AddDomain(OP, C1) 3. AddRange(OP, C2). -The change is formalized by one rewriting rule. -The rule forbids the data redundancy.
, 2014)  and the LDEOv2013 (Lamont-Doherty Earth Observatory version 2013,  Takahashi et al. , 2014a)  databases. Although pCO 2 data are thus available in nearly all ocean basins for several decades, observations from ships or fixed sensors can necessarily only cover a tiny fraction of Figures the spatio-temporal pCO 2 field of the global surface ocean. Therefore, to obtain continuous sea-air CO 2 flux fields over larger areas or the entire ocean, interpolation methods are needed to estimate values in all the periods and areas not directly observed. Various methods have been proposed to interpolate pCO 2 data in space and time (Appendix A). They span a wide range of approaches, in particular with respect to the information sources tapped and assumptions imposed. Due to that, some methods are able to reproduce the signals in the data more closely while others are able to bridge the data-void areas/periods more effectively (Fig.
Spatial gap filling Most methods do not cover the entire ocean surface (see Fig. A6 ). In particular, coastal areas or the Arctic are excluded in many methods. Some methods depending on satellite-derived Chlorophyll a input data exclude some high-latitude areas during the dark season. OceanFlux-SI misses all locations/months where the satellite-derived SST input data are invalid. UEx-MLR has occasional invalid pixels due to numerical reasons. These invalid pixels would pose severe problems to the ensemble analysis because (1) spatial averages (Sect. 3. 3) would not extend over the same area, causing spurious differences between the methods, and (2) the calculated sea-air CO 2 fluxes (Sect. 3. 6) would miss parts of the ocean. Restricting the comparison to the common ocean surface would only partially solve (1) and not solve (2).
Diagnostics As a 1st order performance diagnostic, we compare the mapping results to the monthly observed values in the SOCATv2 gridded product  (Sabine et al. , 2013; Bakker et al. , 2014). In these comparisons, the averages over biomes or biomes/years are taken only over those pixels/months that are covered by data (and with at least 400 m water depth to avoid coastal data; these coastal data may otherwise dominate the diagnostics as the methods do not take the special environment along the coasts into account) 2. We consider time series of such selective averages of the pCO 2 maps themselves as well as of their difference to the data. As an overall measure of the mismatch between a given mapping product and the data with respect to interannual variations in a given biome, we use the amplitude M iav (temporal standard deviation 3 ) of the average difference between map and data (averages over biomes and years, again restricted to data-covered open-ocean pixels/months).
It is difficult to decide which R iav values can be regarded as sufficient for IAV to be represented in a given map. For this paper, we present all IAV results that manage to stay below 75 %. This is an ample threshold, but in the light of possible ambiguities in the R iav calculation we preferred it over a stricter selection. To nevertheless make the likely range more visible, we de-weight results with higher R iav by smaller line thickness in all IAV plots. To verify the robustness of the selection criterion, IAV mismatch diagnostics have also been calculated from the LDEOv2013 database  (Takahashi et al. , 2014a ) (monthly binned), which is used as data source by some mapping methods. LDEOv2013 shares large parts of data points with SOCATv2. Mismatch values are slightly different depending on database, but qualitatively consistent.
Most strikingly, in the data-poor periods up to 1988 and from 2009 onwards (see data density in Fig. A5  panel "Biome 6"), regression and interpolation methods (as far as they cover these periods) strongly differ in the whole-biome average (panel a), while they closely agree at the data-covered pixels (panel b). This illustrates that the statistical interpolation methods solely rely on the pCO 2 data constraint while regression methods bridge data gaps as their variability originates from the driver data that are available throughout time. In the more data-rich periods  (about 1992-2008  in this biome), interpolation and regression methods do agree in many features even in the whole-biome average (panel a). Due to the complementary origin of the variability in these method classes (Fig. 1 ), this agreement confirms that, at least in this biome, (1) sufficient interannual information is contained in the available pCO 2 observations (in the more densely sampled period), and (  2  available data points are fit well, the extrapolation to data-void areas can be wrong ("over-fitting", see more discussion in Sect.