dataesr/scientific-paragraphs-categorization huggingface dataset:
At the end of the optimization step, the preliminary plan is transformed into the plan on Figure  4  that is passed to the query execution controller of node 3. Each join operation in the QEP is supplemented with the identifier of the node that is in charge of executing it. The enumeration of the nodes is according to the indexes of the collocated data stores as we named them, i. e. node 1 is collocated with DB1, etc. The join between scientists and publications is marked with the label bind, which means that a bind join method will be performed. The QEP is executed by performing the following steps, including the sequence of queries executed against the three data stores: 1. The Derby wrapper at node 1 sends the following SQL statement to retrieve data from the scientists table in the Derby database DB1, retrieves the corresponding intermediate relation, and transfers it to the operator engine of node 2 :.
2. The MongoDB wrapper at node 2 prepares a native query to send to the MongoDB database DB2 to retrieve those tuples from publications that match the bind join criteria. It takes into account the bind join condition derived from the already retrieved data from DB1 and generates a MongoDB query whose SQL equivalent would be the following: Upon receiving the result dataset (a MongoDB document collection), the wrapper converts each document to a tuple, according to the signature of the named table expression pubs_revs, and then pipelines the tuples to the operator engine, which per-Name Patrick Boyan forms the actual join operation using the already retrieved result set from step 1. The result of the bind join is the contents of the following intermediate relation: Since this relation will be consumed by only one operator, the operator engine does not need to store it in the table storage; therefore the tuples are simply pipelined as input to the operation described in step 4.
7. Finally, the root join operation is performed, taking as input the pipelined tuples of the intermediate relation from step 5 and matching them to the one from step 6, to produce the final result: This use case example demonstrates that the proposed query engine achieves its objectives by fulfilling the five requirements as follows: 1. It preserves the expressivity of the local query languages by embedding native queries, as it was demonstrated with the named table expression friendships. 2. It allows nested queries to be chained and nesting is allowed in both SQL and native expressions, as it was demonstrated in two scenarios. First, the subquery against the MongoDB database DB2 uses as input the result from the subquery to the relational database DB1. Second, the subquery against the Sparksee graph database DB3 iterates through data retrieved from the other two databases.
3. The proper functioning of the query engine does not depend on the data stores' schemas; it simply converts the data retrieved from data stores to match the ad-hoc schema defined by the named table expressions' signatures. 4. It allows data-metadata transformations as it was demonstrated with the named table expression friendships: metadata (the length of a path in the graph database) is converted to data (the level of friendship). It also allows data to be synthesized as with the Python table expression friendship_levels. 5. It allows for optimizing the query execution by rewriting subqueries according to the bind join condition and the pushed down selections and planning for optimal join execution order and intermediate data transfer.
Experimental Validation The goal of our experimental validation is to show the ability of the query engine to optimize CloudMdsQL queries, as optimizability is one of the objectives of the query language. Notice that our experiments are not intended for benchmarking the query engine; their purpose is to illustrate the impact of each optimization technique on the overall efficiency of the query execution. To achieve this, we have implemented the first prototype of our query engine, aiming at implementing all the proposed optimization techniques, while giving less importance to the efficiency of the operator engine. In this section, we first describe the current implementation of the query engine prototype. Then, we introduce the datasets, based on the use case example in Section 7. Finally, we present our experimental results.
Prototype For the current implementation of the query engine, we modified the open source Derby database to accept CloudMdsQL queries and transform the corresponding execution plan into Derby SQL operations. We developed the query planner and the query execution controller and linked them to the Derby core, which we use as the operator engine. The main reasons to choose Derby database to implement the operator engine are because Derby: • Allows extending the set of SQL operations by means of CREATE FUNCTION statements. This type of statements creates an alias, which an optional set of parameters, to invoke a specific Java component as part of an execution plan. • Has all the relational algebra operations fully implemented and tested. • Has a complete implementation of the JDBC API. • Allows extending the set of SQL types by means of CREATE TYPE statements.
The rest of the query engine components are developed as follows: • The query planner is implemented in C++ and uses the Boost. Spirit framework for parsing context-free grammars, following the recursive descent approach. • The wrappers are Java classes implementing a common interface used by the operator engine to interact with them. We use three data stores -Sparksee (a graph database with Python API), Derby (a relational database accessed through its Java Database Connectivity (JDBC) driver) and MongoDB (a document database with a Java API). To be able to embed subqueries against these data stores, we developed wrappers for each of them as follows: • The wrapper for Sparksee accepts as raw text the Python code that needs to be executed against the graph database using its Python client API in the environment of a Python interpreter embedded within the wrapper.
• The wrapper for Derby executes SQL statements against the relational database using its JDBC driver. It exports an explain() function that the query planner invokes to get an estimation of the cost of a subquery. It can also be queried by the query planner about the existence of certain indexes on table columns and their types. The query planner may then cache this metadata information in the catalog. • The wrapper for MongoDB is implemented as a wrapper to an SQL compatible data store, i. e. it performs native MongoDB query invocations according to their SQL equivalent. The wrapper maintains the catalog information by running probing queries such as db. collection. count() to keep actual database statistics, e. g. cardinalities of document collections. Similarly to the Derby wrapper, it also provides information about available indexes on document attributes.
Datasets We performed our experimental evaluation in the context of the use case example, presented in Section 7. For this purpose, we generated data to populate the Derby table scientists, the MongoDB document collections publications and reviews, and the Sparksee graph database with scientists and friendship relationships between them. All data is uniformly distributed and consistent. The datasets have the following characteristics: • This data is generated to assure that for each publication, 2 out of 4 reviewers are friends or friend-of-friends to the author. • The catalog contains sufficient information, collected through the Derby and Mon-goDB wrappers, about the above specified cardinalities and selectivities. It also contains information about the presence of indexes on the attributes scientists.
Experiments We loaded the generated datasets in 4 data stores, each running on a separate node in a cluster, as follows: Apache Derby at node 1 stores the scientists table, MongoDB at node 2 and node 3 stores respectively the publications and reviews document collections, and the Sparksee graph database at node 4. The data store identifiers that we use within our queries are respectively DB1, DB2, DB3, and DB4. Each node in the cluster runs on a quad-core CPU at 2. 4GHz, 32 GB main memory, 1. 5Gbps HDD throughput, and the network bandwidth is 1Gbps. To demonstrate in detail all the optimization techniques and their impact on the query execution, we prepared 5 different queries. For each of them, we chose 3 alternative QEPs to run and compare their execution times, with different join orders, intermediate data transfer, and subquery rewritings.
The alternative query plans are: QEP 31 : ((σ(Sr) ⧒ @3 R) ⧒ @3 P) ⨝ @3 σ(Sa) QEP 32 : ((σ(Sa) ⧒ @2 P) ⧒ @3 R) ⨝ @3 σ(Sr) QEP 33 : (σ(Sa) ⧒ @2 P) ⨝ @3 (σ(Sr) ⧒ @3 R) Query 4 includes the friendships subquery against the graph database and focuses on the involvement of native named table expressions, using join iteration, and the usage of expensive native operations, such as breadth-first search. As the QEPs correspond to the ones for Query 3, the execution times depend on the join orders, but also on the number of distinct values of the relation to be joined with the friendships expression, which determines how many times breadth-first search is invoked. The alternative query plans are: QEP 41 : (((σ(Sr) ⧒ @3 R) ⧒ @3 P) ⨝ @3 F) ⨝ @3 σ(Sa) QEP 42 : (((σ(Sa) ⧒ @2 P) ⧒ @3 R) ⨝ @3 F) ⨝ @3 σ(Sr) QEP 43 : ((σ(Sa) ⧒ @2 P) ⨝ @3 (σ(Sr) ⧒ @3 R)) ⨝ @3 F Query 5 resembles Query 4, but uses the friends native subquery that invokes another native operation that yields many output tuples for a single input tuple.
The architecture of CloudMdsQL query engine is fully distributed, so that query engine nodes can directly communicate with each other, by exchanging code (query plans) and data. Thus, the query engine does not follow the traditional mediator/wrapper architectural model where mediator and wrappers are centralized. This distributed architecture yields important optimization opportunities, e. g. minimizing data transfers by moving the smallest intermediate data for subsequent processing by one particular node. The wrappers are designed to be transparent, making the heterogeneity explicit in the query in favor of preserving the expressivity of local data stores' query languages. CloudMdsQL sticks to the relational data model, because of its intuitive data representation, wide acceptance and ability to integrate datasets by applying joins, unions and other relational algebra operations.
To validate the common query language concepts, we presented the way Cloud-MdsQL query engine, implemented according to the specified design, achieves its objectives. In our validation setup, we integrated three database management systems -Sparksee (a graph database with Python API), Derby (a relational database accessed through its JDBC driver) and MongoDB (a document database with a Java API). By executing representative CloudMdsQL queries and revealing what the query engine does to process them, we showed that the common query language satisfies the five important requirements for a cloud multidatabase query language. In particular, it allows nested queries to be chained and nesting is allowed in both SQL and native expressions. Furthermore, it allows for optimizing the query execution by rewriting queries according to bind joins and pushed down selections, planning optimal join execution orders, and performing optimal shipping of intermediate data.
reviewer: 'Martin', date: '2012-11-18', review: '…text…'}, {pub_id:5, reviewer: 'Rui', date: '2013-02-28', review: '…text…'}, {pub_id:5, reviewer: 'Ricardo', date: '2013-02-24', review: '…text…'}, {pub_id:8, reviewer: 'Rui', date: '2012-12-02', review: '…text…'}, {pub_id:9, reviewer: 'Patrick', date: '2013-01-19', review: '…text…'} ) DB3 is a graph database (e. g. Sparksee) representing a social network with nodes representing persons and 'friend-of' links between them:.
from steps 1 and 2, the wrapper prepares another MongoDB query for DB2 that, taking into account the pushed down selection, retrieves reviews made in 2013. The generated native query (preceded by its SQL equivalent) and the result intermediate relation are as follows: The intermediate relations from steps 2 and 3 are joined by the operator engine at node 2 to result in another intermediate relation, which is transferred to the operator engine of node 3 to be pipelined to the next join operator: The query engine sends to the wrapper of DB3 the Python code to be executed against the graph database. It also provides an entry point to the intermediate data, represented by the special Python object CloudMdsQL. The wrapper of DB3 has preliminarily initialized the object graph, needed to reference the database's graph data.
The Python code of the named table expression friendships iterates through a projection on the join attribute columns of tuples pipelined from the intermediate relation of step 4. For each tuple it tests if there exists a path with maximal length maxlevel=2 between the author and reviewer in the graph database. The produced tuples are as follows:As the above tuples are generated by the Python expression friendships, they are immediately joined with their corresponding tuples of the relation from step 4 to produce the next intermediate relation: Independently from all of the above steps, the operator engine at node 3 executes the Python code of the expression friendship_levels, instantiated with parameter value maxlevel=2 to produce the relation:.
The Python code of the named table expression friendships iterates through a projection on the join attribute columns of tuples pipelined from the intermediate relation of step 4. For each tuple it tests if there exists a path with maximal length maxlevel=2 between the author and reviewer in the graph database. The produced tuples are as follows:As the above tuples are generated by the Python expression friendships, they are immediately joined with their corresponding tuples of the relation from step 4 to produce the next intermediate relation: Independently from all of the above steps, the operator engine at node 3 executes the Python code of the expression friendship_levels, instantiated with parameter value maxlevel=2 to produce the relation: Level Friendship 1 friend 2 friend-of-friend SELECT pub_id, reviewer FROM reviews WHERE date BETWEEN '2013-01-01' AND '2013-12-31' db.
Genotyping Microarrays in Illumina Infinium and Affymetrix were used for the meta-analysis of the three GWAS. Detailed information on the arrays was given in the previous report  [14]. In the replication study, Taqman assays were performed for genotyping case subjects, and genotype data for controls were extracted from array data of Illumina Infinium HumanHap610-Quad or HumanHap550 (Table  1 ). Association data for 2,822 patients with ACPA-positive RA and 16,891 controls were obtained from the RA meta-analysis. We applied the same quality-control criteria as the RA meta-analysis including call rate, minor allele frequency, and Hardy-Weinberg disequilibrium: these details were presented in the previous manuscript  [14].
Imputation Imputed genotype data of ACPA-negative RA patients was extracted from the RA meta-analysis in a Japanese population. Briefly, MACH version 1. 0. 16 software was used for imputation of genotype data obtained by the GWAS of RA with the Hapmap phase II East Asian panel (JPT and CHB) as reference. As the meta-analysis in the current study included three different GWAS, the imputation was performed separately for data from each GWAS using the same reference panel. A total of 1,948,138 single nucleotide polymorphisms (SNPs) with minor allele frequency >1% and imputation score (Rsq) >0. 5 were used for the analysis. Thirteen regions associated with ACPA-negative RA in a European population SNPs in the 13 regions that were reported to be associated with ACPA-negative RA in a European population were extracted from the GWAS meta-analysis.
Correlation analysis Effect sizes (ORs) of risk alleles in the 21 SNPs were compared between ACPA-positive and -negative RA by calculating the Spearman correlation coefficient in the GWAS meta-analysis and the replication study. Correlation of effect sizes for non-HLA SNPs in GWAS meta-analysis was analyzed between ACPA-positive and -negative RA, -negative RF-positive or -negative RF-negative RA by Spearman's correlation coefficient for SNPs pruned by r 2 <0. 3 by PLINK with intervals of P-values. Data for r 2 was obtained in the Hapmap phase II JPT data. HLA was defined from 25 Mbp to 35 Mbp on chromosome 6 based on NCBI build 36.
Results The overall strategies of our study are demonstrated in Additional file 1. First, a total of 670 patients with ACPAnegative RA from three independent cohorts (GARNET Consortium detailed in Methods) and 16,891 controls were genome-scanned with different SNP typing platforms (Table  1 ) and the data were imputed separately using the same Hapmap phase II East Asian panel as reference and corrected in order to fit meta-analysis as detailed in Methods. The QQ plot of the GWAS meta-analysis did not show evidence of population stratification (lambda = 0. 98, Additional file 2). Thus, we did not apply genomic control to our GWAS results. The result of the GWAS metaanalysis is shown in Figure  1  and no markers, including the HLA locus, reached the GWAS significant level. However, when we focused on our results in the GWAS meta-analysis of the genes that had been reported to be associated with ACPA-negative RA in the previous studies, four out of the 13 genes had SNPs with suggestive association (P <0.
Acknowledgements The authors acknowledge the essential role of the GARNET consortium in developing the study. In this study, the following GARNET members are included: CGM of  RIKEN, University of Tokyo , the  BioBank Japan Project, Kyoto University  and IORRA. We would like to thank all the doctors and staffs who participated in sample collection for the RIKEN cohort and the  BioBank Japan Project. We thank  K Kobayashi  and  M Kitazato  for their technical assistance. We thank  M Kokubo  for DNA extraction, GWAS genotyping and secretarial assistance. We would also like to thank  H Yoshifuji ,  N Yukawa ,  D Kawabata ,  T Nojima , and  T Usui  for collecting DNA samples. We thank  Y Katagiri  for her technical efforts. We also appreciate the contribution of  E Inoue  and other members of the  Institute of Rheumatology, Tokyo Women's Medical University , for their efforts on the IORRA cohort.
Statistical analysis Calculations were made using GraphPad Prism and Instat version 4. 0 for Windows (GraphPad Software, San Diego, CA, USA) was used for statistical analysis. Results for each IOL and the control model were the mean ± SD of at least 5 experiments run in duplicate. The Wilcoxon Rank Sum test was applied to assess the comparisons between cell counting and density for each IOL and the control model, using in all cases the same level of significance (p < 0. 05).
Discussion The present study shows that in our experimental conditions a 360°sharp optic edge acts as an effective barrier to LEC migration. Similarly, Kurosaka and colleagues  [15]  found in another in vitro study that an acrylic sharp-edge IOL and a PMMA IOL with similar edge design inhibited LEC migration more effectively than silicone and PMMA rounded-edge IOLs. This is consistent with the clinical evidence reported  [2, 8, 9]. Specifically, Nixon and Woodcock found in a comparative study between eyes implanted with continuous-edge and interrupted edge IOLs that the mean EPCO (software for the Evaluation of Posterior Capsule Opacification) score was significantly higher for eyes with the interrupted-edge IOL compared to the 360°squareedge (0. 39 vs. 0. 08, p = 0. 012)  [2]. On the contrary, other authors showed similar incidence of PCO in eyes implanted with interrupted square-edge IOLs, in comparison with 360°square-edge IOLs  [24].
Production of recombinant antigens from RRV and CHIKV Serum samples were tested for the presence of immunoglobulin G class antibodies (IgGs) against RRV by indirect ELISA using recombinant antigens from RRV. Given that CHIKV has circulated in the PICTs since 2011 and is antigenically related to RRV, recombinant antigens from CHIKV were also used to test serum samples. Recombinant antigens were produced in Drosophila S2 cells using the Drosophila S2 expression system (Life Technologies, USA). The synthetic genes (GeneCust, Luxembourg) encoding the soluble ectodomain of the envelope E2 glycoprotein (sE2) from RRV strain QML 1 (GenBank accession no. GQ433354) or CHIKV La Reunion strain 06-49 (GenBank accession no. AM258994) were cloned into the shuttle vector pMT/BiP/His A in which the SNAPtag sequence (Covalys Biosciences AG, Switzerland) had been initially inserted as a stabilizing protein.
Discussion Arboviruses are emerging pathogens in Oceania  8, 32  and, except for DENV, few data are available about their circulation, incidence and prevalence in the region. In particular, the spread of RRV in the Pacific region is unknown. In the present study, sample collection was conducted in FP from July 2011 to early October 2013. Even if the first CHIKV outbreak in FP was recorded in October 2014, CHIKV had begun circulating in other PICTs from 2011. 8 onsequently, a previous silent circulation of CHIKV in FP cannot be excluded. To insure that the detection of RRV IgGs was not due to cross-reaction of RRV recombinant antigens with CHIKV antibodies resulting from a non-detected previous infection, all sera were tested for the presence of CHIKV IgGs, in addition to RRV IgGs. The low rate of immunization against CHIKV measured among blood donors (3.
Acknowledgments We are grateful to  Jerome Viallon  from the  Institut Louis Malarde, French Polynesia , for technical support, and to  Philippe Buchy  from the  Institut Pasteur in Cambodia , for providing CHIKV positive control serum. This study was supported by the ''Contrat de projets 2012-2014'' (Convention No. 7331/MSS/DSP, 08/31/2012 ). Conflict of interest statement: None of the authors have any conflict of interest (financial or personal) in this study. Ethical approval statement: This study was approved by the  Ethics Committee of French Polynesia  under reference n860/CEPF ( 06/27/2013 ).
Patterns of gene expression in response to collagen modification by CML-, CEL-, MG-, H1-, and pentosidine-rich collagen The reconstructed skins were separated into dermal and epidermal layers, each of which was used for quantitation by qPCR of an array of genes pertinent to skin aging and remodeling. The data in Figure  3  are expressed as a ratio between AGE-modified collagen and the corresponding control. In the epidermal cells (Fig. 3A ), CEL increased type 7 collagen (Col7A1), b1 integrin (ITGB1), and a6 integrin (ITGA6), while CML only increased COL7A1 significantly. No significant alterations were observed with MG-H1 and pentosidine-rich collagen. In the dermal cells (Fig. 3B ) CML increased significantly MMPs, TIMP1, FGF7 (KGF), IL6, and MCP1 ( p < 0. 05) and seemed to upregulate the majority of genes studied.
The composite plates were fixed on a Newmark X-Y displacement system that assures the displacement in plan with ±10 µm precision and rotation with ±2″. That assures the scanning of 60 × 60 mm 2 with 1 mm steps in both directions. Electromagnetic inspection was made with sensors with MM lenses, the frequency control is 105 MHz and the distance from the bottom of the sensor, represented by the circular aperture to the surface to be inspected, is 75 µm. Once the level of noise was estimated, the optimal signal processing method is started. The scanning, the measurements, the acquisition and the processing of data were commanded by a PC using programs developed in Matlab 2011b. The performances of the sensor with MM were verified using the same mock-up used in  [49]. The signal are generated and processed by the 4395A Agilent Impedance/Spectrum/Analyzer coupled through IEEE 488 interfaces with a PC which controls the displacement system.