dataesr/scientific-paragraphs-categorization huggingface dataset:
Introduction Databases which store and manage long-term scientific information related to life science are used to store huge amount of quantitative attributes. This is specially true for medical databases  1, 2. One major downside of these data is that information on multiple occurrences of an illness in the same individual cannot be connected  1, 3, 4. Modern database management systems fall into two broad classes: Relational Database Management System (RDBMS) and Not Only Structured Query Language (NoSQL)  5, 6. The objects in the relational database are grouped based on their type, format and number of identical attributes. The data tables in the relational databases are normalized. Join operations are used in the relational databases when combining information based on a matching value for a primary key and foreign key across multiple data tables.
REVISED The introduction of a new entity attribute requires the introduction of additional data tables or modification of the existing data tables. In the NoSQL databases, the development such as creating simple query is more complex because there is no standard query language and there are limits to the operations (for example, there is no join operation in MongoDB)  7. The primary goal of our developed method was to store and manage each data in a single data table while the data handling processes can be completed by SQL commands. Our method may be useful in an environment where the schema is constantly changing as a result of adding new devices or tools that generates new types of attributes. This solution contributes to the interoperability between the relational and NoSQL systems where converting application usage is unnecessary.
Methods The technical environment is Oracle Application Express (Apex) 5. 0 cloud-based technology. Workstation: OS (which is indifferent) + internet browser (Chrome). Firstly, we demonstrate an example for a simplified relational database (Figure  1 ). Following this, the presented data tables have been modified step by step. At the end of these steps, each data from the presented database will be stored in a single data table using JT logic. The database designing rules we applied can be summed up as follows:.
Rule 2: Defining basic relationships The first step is the technical data storage. In Figure  2 , basic relationships will be defined which describe the names of the attributes (can be interpreted as columns in the usual relational databases), type of relationships (belonging to the structure) and virtual data tables (can be interpreted as "belonging to the data table" in the usual relational databases). The Name is defined as an entity and an attribute at the same time as the code 1 appears in both columns in the ID and in the Attribute as well. Following this two entities are defined: the "Belonging to the virtual data table ".
Rule 5: Defining data tables The attributes are assigned to each virtual data table using a previously introduced attribute called "belonging to the virtual data table". In the usual relational databases, the entities are grouped by different data tables. For the same purpose, we introduced "virtual data tables" in our single big data table. The code 2 in the Attribute column identifies the belonging to the table. The different entities that belong to the same data table have to own the same value in the Tvalue column (Figure  5 ). From this example, the following context can be read out: The entities identified with 1001 and 1002 ID values belong to the same virtual data table. With these steps the developer can design one data table to store each entity, attribute and value in a relational database.
Obviously, the user doesn't see these virtual tables. These appear for the user in a form as usual data tables in the Oracle Apex platform. Only the names of the attributes appear for the user instead of their codes. A query can be created in the same way like in any relational database. In the background: the attribute of the given virtual data table is queried. This attribute is array-type and means increasing number of TSequence. The user can see only the names of the TSequence and TValue (Name of the attributes) like in the following example (Figure  6 ). Oracle Apex automatically supply each record with row IDs. The above described method can be applied manually. For the automatic conversion (for primarily non cloud-based applications) we created a Java code below 7:.
Results The resulting table structure is called JT structure (Figure  7 ). The result from automatic conversion is a physical data table which uses 6 columns. In cloud, Oracle Apex automatically add row IDs and we introduced "belonging to the virtual data table" attribute instead of Group IDs. In cloud we prefer to use only 4 columns to store each data in a database. The JT logic-based databases can be defined using primitive relation scheme known as a three-tuple according to Paredaens (1989) 9 concept: PRS = (ω,δ, dom) where ω is a finite set of attributes, in our case, it is the set of entities from the ATTRIBUTES virtual data table. δ is a finite set of entities, in our case, it is a set of virtual records. dom : ω → δ is a function that associates each attribute to an entity; it can be interpreted as a predefined set of attributes called "1:N registry hive".
A relation scheme (or briefly a relation) is a three-tuple RS=(PRS,M,SC) where PRS is a primitive relation scheme; M is the meaning of the relation. This is an informal component of the definition, since it refers to the real world and since we will describe it using a natural language. SC is a set of relation constraints. From the JT physical data table, the following definitions can be read out: • Virtual record is set of the physical records which have the same ID value. • Virtual data table is set of the virtual records which have the same value of the "belonging to the virtual data table" attribute  6. Thesis: In the JT structure, each attribute needs only one index for indexing in the database.
Proof using mathematical induction: It is obvious the statement is true for the case of one record stored in a data table (according to the RDBMS structure where the developers use more indexes to indexing more attributes). In this case the data table appears as shown in Figure  8. Index= attribute (num) + value (varchar 2) In view of entity, an ID (numerical) index is also used in JT logicbased systems. This ID does not depend (no transitive dependency) on any attribute. Thus, the entities of the virtual data tables meet the criteria of the third normal form (Figure  9 ). The modes of the expansion of a data table are: -input new entity (Figure  10 ); -input new attribute (Figure  11 ); -input new virtual data table (Figure  12 ). The indexing is correct in case of n+1 record expansion also.
With JT logic the user is able to use only one physical data table to define each virtual data table in a database. Therefore, since after or during the development process. Our solution provides three time saving benefits. Firstly it improves the query time over large amounts of data. Secondly it reduces development time for integrating data from various sources. Finally it removes the need for adding or modifying data tables with the addition of new attributes. With JT logic, one physical data storage is ensured in SQL database systems for the storage and management of long term scientific information (Dataset 1). For the unique identification more attributes (columns) are applied in rational databases. In practice, attributes within a type are defined in same data table. Introducing new entity attributes requires the modification of the existing data tables and applications that use these data tables.
In JT logic based databases, records with the same ID values identify one entity called virtual record. Virtual records with the same value of the "belonging to the virtual data table" attribute form a data table called virtual data table. only one index is required to index each attribute, the statement of the thesis is true in every case of the JT logic-based data table according to the principle of mathematical induction below. Thesis: For n=1 ergo; 1 + 2 +. + n = n * (n + 1)/2 substituting one into the equation we get : 1 = 1 * (1 + 1)/2 result of the operation is 1=1, that is, the induction base is true. Using proof by induction we can now show that this is true for the following equation: n = k where k is a optional but fixed natural number. Therefore, we know that the following operation is true: 1 + 2 +.
+ k = k * (k + 1)/2 Finally using n=k+1 we can prove our assumption to be true: 1 + 2 +. + k + (k + 1) = (k + 1) * (k + 2)/2 The above induction proof shows: 1 + 2 +. + k + (k + 1) = k * (k + 1)/2 + (k + 1) Conducting the mathematical operations we obtain the following: 1 + 2 +. k + (k + 1) = (k * ((k + 1)/2) + 2 * (k + 1))/2 = (k * k + k + 2k + 2)/2 = (k * k + 3k + 3)/2 Conducting the mathematical operations on the other side we obtain the same: (k+1) * (k+2)/2 = (k * k+2k+k+2)/2 = (k+k+3k+2)/2 Thus, the induction step is true. Given that both the induction base and the induction step are true, the original statement is therefore true. In the present study, we explained the JT data storage logic. In our other study we focused on the query tests. Our previous results  8  show that from 18000 records the relational model generates slow (more than 1 second) queries in Oracle Apex cloud-based environment while JT logic based databases can remain with the one second time frame.
Is the rationale for developing the new method (or application) clearly explained? Yes Is the description of the method technically sound? Yes In this paper authors introduce a new logic called Joker Tao (JT) which provides universal data storage for cloud-based databases. However, the paper is very poorly written. Firstly, the proposed logic is not presented detailed enough for the reader to understand and validate the method. Authors should research how relational model is presented and based on rigorous relational calculus and algebra. Based on this research, this paper should be rewritten based on rigorous mathematical foundation and give clear examples. Secondly, one table based example is far from convincing and provided Java-program is unnecessary. Length of the paper should be greatly increased to contain detailed description of JT method and give examples.
Competing Interests: 2 Reviewer 2 No competing interests were disclosed. I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard. Version Report 06 April 2016 https://doi. org/10. 5256/f1000research. 8995. r13081 © 2016 Lindström J. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.
1 Reviewer 1 Are sufficient details provided to allow replication of the method development and its use by others? YesIf any results are presented, are all the source data underlying the results available to ensure full reproducibility? YesAre the conclusions about the method and its performance adequately supported by the findings presented in the article? Yes Competing Interests: No competing interests were disclosed. I confirm that I have read this submission and believe that I have an appropriatelevel of expertise to state that I do not consider it to be of an acceptable scientific standard, for reasons outlined above. Version Report 25 February 2016 https://doi. org/10. 5256/f1000research. 8321. r12373.
Introduction High throughput sequencing is now becoming routine for many biological assays including transcriptome analysis through RNAsequencing (RNA-seq), or transcription factor (TF) binding sites identification through chromatin immuno-precipitation followed by sequencing (ChIP-seq). Additionally, collaborative projects such as Bgee  (Bastian et al. ) , ENCODE  (Bernstein et al. , 2012)  and Roadmap Epigenomics  (Kundaje et al. , 2015)  have generated genome-wide datasets across hundreds of cell types or tissues. Despite this large data being freely available in the public domain, the lack of computational tools accessible to experimental scientists with no or elementary computational skills prohibits the use of this data to its full potential for discovery. Though genome browsers, including summary tracks provided by many consortia, are extremely useful to study a few genes, promoters or single nucleotide polymorphisms, they lack the genome-wide overview.
Only a few public resources such as the CODEX database (S anchez-  Castillo et al. , 2015a)  and the BLUEPRINT GenomeStats tool  (Zerbino et al. , 2014)  allow a genome-wide comparison with the user data. We therefore developed Heat*seq, a free, open source, web application providing fast and interactive comparison against high throughput sequencing experiments in the public domain. Users can upload a processed text file containing either gene expression value (Fragments Per Kilobase of transcript per Million (FPKM) or Tags Per Million (TPM)), peak coordinates or peak coordinates and corresponding expression value for CAGE(Cap Analysis of Gene Expression). The application provides clustered correlation heatmaps, summarising global similarities between all samples in the dataset and the user sample.
Data collection We collected gene expression data (RNA-seq), TF ChIP-seq data and CAGE data (over 4000 individual experiments) from Bgee  (Bastian et al. , 2008) , Blueprint epigenome  (Pradel et al. , 2015) , CODEX (S anchez-  Castillo et al. , 2015b) , ENCODE  (Bernstein et al. , 2012) , FANTOM5  (Forrest et al. , 2014) , FlyBase  (Attrill et al. , 2016) , GTEx  (Lonsdale et al. , 2013) , modENCODE  (Celniker et al. , 2009)  and Roadmap Epigenomics  (Bernstein et al. , 2010) , in human, mouse and drosophila. Data formatting was done using R (R scripts available on GitHub). The source for each dataset is listed in Supplementary Table  S1. Heatmaps represent Pearson's correlation values between experiments calculated using a Gene x Experiment numeric matrix with gene expression values for expression data (log scaled), a Genomic regions Â Experiments binary matrix indicating presence or absence of a peak for TF ChIP-seq data and a Genomic regions Â Experiments numeric matrix of expression values for CAGE data (log scaled).
Application description Heat*seq tool supports three data types: HeatRNAseq, HeatChIPseq and HeatCAGEseq. Data upload, correlation calculation and heatmap generation takes about a minute. Importantly, users can interactively sub select relevant experiments using the metadata information (e. g. cell type, TF name). The interactive heatmap also allows selecting different clustering methods as well as zooming in and out on the heatmap. The high resolution figures and tables can be downloaded in multiple formats. Thus, Heat*seq provides global overview of relationships between public experiments and the user data. Four user scenarios are discussed below.
Cell context identification An oestrogen receptor (ER) alpha ChIP-seq in MCF7 cells  (Zhuang et al. , 2015)  comparison to the ENCODE TFBS dataset by sub-selecting ENCODE ER ChIP-seq experiments revealed that the binding pattern of ERa in MCF7 cells was more similar to its binding pattern in T-47D cells than in ECC-1 cells (Fig. 1A ). MCF7 and T-47D were derived from mammary tumours while ECC-1 is an endometrial cell line.
Public data assessment Heat*seq can be used to assess data in the public domain, highlighted by two examples below amongst others: A MYC ChIP-seq in H1-hESC cells does not cluster with other ENCODE MYC ChIP-seq experiments (Fig. 1C ), including H1-hESC sample from a different experimental group  (Devailly et al. , 2015). Two out of seven erythroblast RNA-seq samples from the Blueprint Epigenome consortium are more correlated with endothelial cells than with the rest of the erythroblast samples (Fig. 1D ).
This publication presents the RPC-based bundle adjustment implemented in the freeware open-source photogrammetric tool Apero/MicMac. The bundle adjustment model is based on some polynomial correction functions, enriched with a physical constraint that introduces the notion of a global sensor rotation into the model. The devised algorithms are evaluated against two datasets consisting of two stereo and a triplet pair of the Pleiades images. Two sets of correction functions and a number of GCPs configurations are examined. The obtained geo-referencing accuracy falls below the size of 1GSD.
EXPERIMENTS The orientation refinement is tested on two datasets acquired with the Pleiades satellites. The first dataset -Limoge -is composed of four images, i. The GCPs on the Limoge dataset were obtained by triangulation on aerial images with a ground sampling distance (GSD) of 0. 3m (cf. Fig. 2 ). The estimated planimetric point accuracy is about 0. 5 GSD, and the altitude accuracy is about 1. 0 GSD. The testing scenarios differ in terms of the number/distribution of the employed GCPs (1-6 denoted with letters A-E; cf. Fig. 5 ) and the degree of the deforming polynomial (0 and 1 st degree denoted with the respective numbers and placed after the letters indicating the GCPs scenario, e. g. A1 for degree 1 in GCP scenario A). Scenarios X include no GCPs in the processing. The total number of the control points equals 36.
The GCPs on the Oregon dataset were obtained from a 2x2m Li-DAR point cloud data available from the OpenTopography 1  platform (cf. Fig. 3 ). Due to the problematic accurate point identification in both the satellite images and the point clouds, the evaluation proceeds solely on the Z-coordinates of control points. In analogy to the Limoge data, the testing scenarios differ in GCPs number/distribution (1-6 GCPs, cf. 6), and the degree of the deforming polynomial. The naming convention of particular scenarios follows that of the Limoge dataset, too. The total number of the control points equals 19. Taking the physical viewpoint, the 0-degree polynomial absorbs the in-track and across-track errors hence it models an image by two parameters and the authors refer to it as the shift model. The extra four parameters furnished by the 1 st -degree polynom absorb the surplus gyro drift, radial ephemeris error and leftover interior orientation errors.
It is referred to as the drift model  (Grodecki and Dial, 2003). The employed weighting parameters were: pdsrot = 0. 02, pds last = 1e -15, pds nul = 0, s • t = 20 and remained unchanged throughout the processing. In the X scenarios, the pds N b for the condition equations on all tie points was set to 1000, and for scenarios A -E it was equal to 10. Bundle adjustment on both datasets was carried out in the UTM projection system.
e. the shift model with the total of 6 GCPs. As a general note, the drift model delivers better accuracies with the increased number of GCPs. Tab. 1 and Fig. 4  report on the remaining transverse parallax between images of across-track stereo pair, when 4 GCPs are employed, in the shift (D0) and drift (D1) models. In either case the parallaxes place below the BA standard deviation (σ0), nonetheless, the reduced figures in the drift model indicate it is a more suitable choice for the given dataset. The visible sinusoidal pattern is possibly due to the sensor's small frequency vibrations, or the limited approximating capabilities of RPCs. µP x 2 σP x 2 [pix] [pix] D0 0. 00 0. 06 D1 0. 02 0. 03 Table  1 : Limoge; µP x 2 , σP x 2 -the mean and standard deviation of the residual parallax computed for across-track stereo pair.
Results on Oregon As in the previous case, the Oregon dataset was tested with two sets of correction parameters -the shift and the drift, the results of which are shown in Tab. 3 and Fig. 6. Here, unlike in the Limoge dataset where 4 images were acquired from two different orbits, the triplet stereo locates on a single orbit and it manifests in a very good relative orientation, still before the BA (the points' reprojection error of 0. 5pix). Inclusion of one GCP in the shift model enhances the Z-accuracy on CPs to ≈1GSD, reaching the best result when 3 GCPs are used. With 4 and 6 GCPs the Z-accuracy slightly deteriorates. The viable explanation for this happening is the hampered identification of corresponding points in the Pleiades images and the LiDAR point cloud data. For the #GCP/CP σ0 µ gt ∆X µ gt ∆Y µ gt ∆Z µ cp ∆X µ cp ∆Y σ cp ∆Z [pix] [m] [m] [m] [m] [m] [m] - 0/.
Tests on weighting parameters Fig. 8  presents the variation of accuracy as a function of the weighting parameters pdsrot, and pds last. In the performed tests, the pds null was set to 0 thus excluding the constraint on small formations. The datasets manifest most optimal results for low pds last weight, turning it into a soft constraint. The pdsrot weight is more conservative, however, our experiences prove that if no control information is included in the bundle solution, its value should tend again toward a softer constraint.
CONCLUSIONS This work presents the RPC-based bundle adjustment (BA) implemented in the free open-source software Apero/MicMac. The adjustment model estimates the parameters of some polynomial correction functions, constraining their estimation by the global sensor rotation. Two datasets consisting of 4 and 3 Pleiades images were used as the real cases to evaluate both, the metric capabilities of the imagery, and the devised algorithms themselves. A number GCPs configurations scenarios were arranged to examine the behavior of the BA. For each scenario two sets of correction parameters were taken into account -considering only a shift error in the RPCs, and a shift plus a drift. It has been shown that as long as the acquisitions took place from the same orbit (Oregon), the shift parameters were sufficient to refine the geolocalization of the data.
e. along ( B /H = 0. 15 and B /H = 0. 3) and across-track ( B /H = 0. 2) stereo pairs; the second dataset -Oregon -is a along-track image triplet ( B /H = 0. 1). Both datasets capture a scene occupied by urban and rural landscapes. Evaluation of the results is based on (a) σ0 -bundle adjustment (BA) standard deviation, (b) µ cp ∆X,∆Y,∆Z -mean discrepancies between BA-estimated and true values of the check points (CPs), (c) P x2 -the residual transverse parallax computed on the total image (cf. Subsection 2. 2).
ACKNOWLEDGEMENTS The authors would like to thank  CNES  for funding this project through the  TOSCA program. We thank  Gregoire Maillet  and  Benjamin Ferrand  from the  Institut National de l'Information Géographique et Forestiére (IGN)  for sharing the Limoge dataset. The numerical computations were performed on the S-CAPAD cluster processing facility at the  Institute de Physique du Globe de Paris.
The proliferation of DNA data is revolutionizing all fields of systematic research. DNA barcode sequences, now available for millions of specimens and several hundred thousand species, are increasingly used in algorithmic species delimitations. This is complicated by occasional incongruences between species and gene genealogies, as indicated by situations where conspecific individuals do not form a monophyletic cluster in a gene tree. In two previous reviews, nonmonophyly has been reported as being common in mitochondrial DNA gene trees. We developed a novel web service "Monophylizer" to detect non-monophyly in phylogenetic trees and used it to ascertain the incidence of species nonmonophyly in COI (a. k. a. cox1) barcode sequence data from 4977 species and 41,583 specimens of European Lepidoptera, the largest data set of DNA barcodes analyzed from this regard.