dataesr/scientific-paragraphs-categorization huggingface dataset:
General overview HybridMR is composed of reliable cluster nodes and volatile desktop PCs, which are simple but effective. MR applications can be run in this hybrid environment to analyze and process large amounts of datasets. The architecture of HybridMR is shown in Figure  1. In this figure, the system is designed with a hierarchical architecture. The top layer is the user layer, the middle layer is the service layer, and the bottom layer is the resource layer. Four different service components are implemented in service layer, namely, data storage service, metadata service, data scheduler service, and MR task scheduler service. Resource layer contains two types of resource: the first is reliable cluster nodes (cluster workers) and the second is large number of unreliable volunteer nodes (desktop workers), which join the system in a voluntary way.
Platform description The prototype system of HybridMR is implemented by Java. In order to evaluate the performance, we performed our experiments in the campus local area network environment, and Hadoop-0. 21. 0 is used for comparison. Both HybridMR and Hadoop ran on Ubuntu Linux system 13. 10 (Canonical Ltd. , London, UK). In order to evaluate NPBFS algorithm, the parameters are set to (2) We used 24 cluster nodes, and each node is configured with AMD (AMD, Sunnyvale, CA, USA) Opteron 8378 quad-core 2. 4 GHz CPU, 8 GB memory, and 1 Gbps ethernet. The average disk read/write speed reaches 88 MB/s. (3) In the students' laboratory, we used 72 desktop PCs, configured with Intel (Intel, Santa Clara, CA, USA) core 2 duo E6300 1. 86 GHz CPU, 1 GB memory, and 100 Mbps ethernet for each. The average disk read/write speed is around 69 MB/s.
ACKNOWLEDGEMENTS This work is supported by the  French Agence Nationale de la Recherche  through the  MapReduce grant  under contract  ANR-10-SEGI-001-01  and  INRIA ARC BitDew. This work is also supported by the  '100 Talents Project' of Computer Network Information Center of Chinese Academy of Sciences  under grant number  1101002001 , the  Natural Science Foundation of Hunan Province  under grant number  2015JJ3071 , and the  Scientific Research Fund of Hunan Provincial Education Department  under grant number  12C0121. Some experiments presented in this paper were carried out using the grid'5000 experimental testbed, being developed under the  INRIA   ALADDIN development action  with support from  CNRS ,  RENATER , and several universities as well as other funding bodies (see https://www.
IV. EVENT SELECTION The data used for this analysis were collected using a combination of a single-muon trigger and an asymmetric dimuon trigger. The transverse momentum (p T ) threshold for the single-muon trigger is 36 GeV, while the dimuon trigger thresholds for the highest p T (leading) and the second-highest p T (subleading) muons are 18 and 8 GeV, respectively  [57]. Muons are reconstructed by combining tracks in the inner detector (ID) with those in the muon spectrometer (MS)  [58]  and are selected if they satisfy the following criteria: each muon must have a p T > 16 GeV, jηj < 2. 5, projected longitudinal impact parameter jz 0 sin θj < 0. 4 mm, the ratio of the transverse impact parameter d 0 to its estimated uncertainty σ d 0 such that jd 0 j=σ d 0 < 3, and a track isolation requirement.
ACKNOWLEDGMENTS We thank  CERN  for the very successful operation of the LHC, as well as the support staff from our institutions without whom ATLAS could not be operated efficiently. We acknowledge the support of  ANPCyT , Argentina; YerPhI, Armenia;  ARC, Australia ;  BMWFW  and  FWF , Austria; ANAS, Azerbaijan; SSTC, Belarus;  CNPq  and  FAPESP, Brazil ;  NSERC ,  NRC  and  CFI ,  Canada ; CERN; CONICYT, Chile; CAS,  MOST  and  NSFC , China; COLCIENCIAS, Colombia; MSMT CR, MPO CR and VSC CR, Czech Republic; DNRF,  DNSRC  and  Lundbeck Foundation , Denmark; EPLANET,  ERC  and  NSRF ,  European Union ;  IN2P3-CNRS ,  CEA-DSM/IRFU , France; GNSF, Georgia; BMBF,  DFG ,  HGF ,  MPG  and  AvH Foundation, Germany ;  GSRT  and  NSRF, Greece ;  RGC, Hong Kong SAR, China ;  ISF, MINERVA, GIF, I-CORE and Benoziyo Center, Israel ;  INFN, Italy ;  MEXT  and  JSPS, Japan ; CNRST, Morocco; FOM and  NWO, Netherlands ;  BRF  and  RCN, Norway ;  MNiSW  and  NCN , Poland; GRICES and FCT, Portugal; MNE/IFA, Romania;  MES of Russia  and  NRC KI , Russian Federation; JINR; MSTD, Serbia; MSSR, Slovakia; ARRS and MIZŠ, Slovenia; DST/NRF, South Africa; MINECO, Spain; SRC and Wallenberg Foundation, Sweden ;  SER ,  SNSF  and  Cantons of Bern and Geneva, Switzerland ;  NSC, Taiwan ;  TAEK, Turkey ;  STFC , the  Royal Society and Leverhulme Trust ,  United Kingdom ; and the  DOE  and  NSF ,  United States of America.
The cores were prepared for measurement using standard dendrochronological procedures  (Zielski and Krąpiec 2004). The sanded core samples were then scanned at a resolution of 1200 dpi using a standard scanner (Epson Perfection V700 Photo). Basic tree-ring parameters were obtained from the measurement of ring widths to the nearest 0. 01 mm using CooRecorder software and the related CDendro programme (http://www. cybis. se). Checks on cross-matching were carried out using COFECHA (Grissino-Mayer 2001). In addition, each sample was analysed by means of the skeleton plot method  (Schweingruber 1996). Both the skeleton plot method and the results from the COFECHA programme were used to evaluate and detect narrow and wide rings. Having checked the cross-matching, 28 samples were taken for study of climate-growth relationships.
De-trending of the chronology was done with the dplR software  (Bunn 2008 ) using the spline-smoothing option, which reflects trends in the chronology better than the other options. The 'n-year spline' was fixed at 2/3 the wavelength of the n years  (Cook et al. 1990). A residual version of the chronology was built with pre-whitening, performed by fitting an autoregressive model to the data with AIC model selection  (Bunn 2008). To investigate climate/growth relationships for the reference chronology, the R package treeclim was applied (Zang and Biondi 2015) using a bootstrap procedure to estimate the degree of error. Climate data from October (previous year) to September (current year) served as independent variables, and the residual chronology for the site was used as dependent variables.
The trees examined in the earlywood vessel study were chosen randomly, were growing close together in a mixed pine-oak forest and were aged from 17 to 62 years. The level of damage between and within the trees (crown, lower and top branches) differed by phenophase (Fig. 1S ). As discussed below (see Discussion), this was a tree-related factor. The cores (15-20 μm thick) were prepared using a Zeiss Hyrax S30 sledge microtome. Microscopic specimens were stained with safranin and mounted with a Heft Histokitt. Microscopic photographs were taken using a Moticam 580 camera and related software (Moticam Images Plus 2. 0). The number and surface of earlywood xylem cells were measured with ImageJ (http://imagej. nih. gov/ij/), the Java-based image analysis programme, which showed a core width of 4 mm.
Acknowledgments This research is linked to activities conducted within the  COST FP1106 network. Open Access This article is distributed under the terms of the Creative Comm ons Attribution 4. 0 International License (http:// creativecommons. org/licenses/by/4. 0/),which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.
Images were captured using an upright microscope (Olympus BX43) with a color camera (Olympus SC100). For GFP analyses, cells were plated in coverslips, fixed with paraformaldehyde (PFA) (4%) for 10 minutes and cell nuclei were visualized by incubation with 1:50,000 dilution of Hoechst 33342 (Invitrogen). Images were sequentially captured at 20× magnification (UPLFL objective, 1. 3 NA; Olympus) using a monochrome charge-coupled camera (ORCA ER; Hamamatsu), an inverted microscope (IX81; Olympus), and Slidebook software (v5. 0, Intelligent Imaging). Images were pseudo-colored, overlaid, merged using Photoshop (Adobe), and quantified using Image J.
To confirm the importance of NS expression for MDA-MB-231 growth, two different shRNAs were stably-expressed by puromycin selection, and resulted in NS knockdown >75% in MDA-MB-231 cells (Figure  1G ). NS knockdown but not expression of Scr shRNA control, prevented MDA-MB-231 colony growth in methylcellulose but not in two-dimensional adherent culture (Figure  1H  and I ). Interestingly, Kaplan-Meier analyses of a large tumor microarray database revealed that higher FAK, NS, and B23 mRNA levels were associated with decreased patient survival over 10 years (Additional file 2: Figure  S2 ). As FAK inhibition can impact NS levels in tumors, our results support the notion that FAK and NS may be part of a signaling axis promoting breast carcinoma tumor progression.
Acknowledgements We thank  Frederic Lessard  and  Gerardo Ferbeyre  ( Université de Montréal ) for providing plasmid for human nucleostemin and anti-nucleostemin shRNA. We also thank  Leonardo Karam Teixeira  and  Steven Reed  ( Scripps ) for the nucleolar isolation protocol. Design elements used in Figure 4A were from  Servier Medical Art. Support was provided by  National Institutes of Health  grant  CA102310  and  CA180769  to  D Schlaepfer. I Tancioni  was supported by a grant from  Susan G Komen for the Cure  ( KG111237 ). C Lawson  was supported in part by an  Ovarian Cancer Research Fund  fellowship (258835). C Jean  was supported in part by an  American Heart Association  fellowship ( 12POST11760014 ). NLG Miller was supported by a  National Research Service Award  ( 1F32CA159558 ).
Introduction A major trend in cloud computing and data management is the understanding that there is "no one size fits all" solution. Thus, there has been a blooming of different cloud data management infrastructures, referred to as NoSQL  [18] , specialized for different kinds of data and tasks and able to perform orders of magnitude better than traditional relational DBMS. Examples of new data management technologies include: graph databases (e. g. Sparksee  [16] , Neo4j), key-value data stores (e. g. HBase, Cassandra, HyperTable), array data stores (e. g. SciDB), analytical cloud databases (e. g. Greenplum and Vertica), analytical cloud frameworks (e. g. Hadoop Map-Reduce, Cloudera Impala), document databases (e. g. MongoDB, CouchBase), and data stream management systems (e. g. StreamCloud  [7, 8] , Storm).
This has resulted in a rich offering of services that can be used to build cloud data-intensive applications that can scale and exhibit high performance. However, this has also led to a wide diversification of DBMS interfaces and the loss of a common programming paradigm. This makes it very hard for a user to integrate her data sitting in specialized data stores, e. g. relational, documents and graph databases. For example, consider a user who, given a relational data store with authors, a document store with reviews, and a graph database with author friendships, wants to find out about conflicts of interests in the reviewing of some papers. The main solution today would be to write a program (e. g. in Java) that accesses the three data stores through their APIs and integrates the data (in memory).
This solution is obviously labor-intensive, complex and not easily extensible (e. g. to deal with a new data store). The CoherentPaaS project  [3]  addresses this problem, by providing a rich Platform as a Service (PaaS) with different "one size" systems optimized for particular tasks, data and workloads. However, unlike in the current cloud landscape, it provides a common programming model and language to query multiple data stores. The platform is designed to allow different subsets of enterprise data to be materialized within different data models, so that each subset is handled in the most efficient way according to its most common data access patterns. On the other hand, an application can still access a data store directly, without using our query engine. This constitutes a multidatastore system with high levels of heterogeneity and local autonomy.
In this paper, we focus on the problem of querying heterogeneous cloud data stores (in readonly mode) with a common language. The problem of accessing heterogeneous data sources, i. e. managed by different data management systems such as relational DBMS or XML DBMS, has long been studied in the context of multidatabase systems  [19]  (also called data integration systems in the context of the web  [5] ). However, the state-of-the-art solutions for multidatabase systems (see Section 2) do not directly apply to solve our problem. First, our common language is not for querying data sources on the web, which could be in very high numbers. A query should be on a few cloud data stores (perhaps less than 10) and the user needs to have access rights to each data store. Second, the data stores may have very different languages, ranging from very simple get/put in keyvalue stores, to full SQL or SPARQL languages.
And no single language can capture all the others efficiently, e. g. SQL cannot express graph path traversal (of course, we can represent a graph with two relations Edges and Nodes, but this requires translating path traversals into expensive joins). Even a graph query language, which is very general, cannot capture an array data model easily. Third, NoSQL databases can be without schema, which makes it (almost) impossible to derive a global schema. Finally, and very important, what the user needs is the ability to express powerful queries to exploit the full power of the different data store languages, e. g. directly express a path traversal in a graph database. For this, we need a new query language. We can translate these observations into five main requirements for our common language: 1.
To integrate fully-functional queries against different NoSQL and SQL databases using each database's native query mechanism; 2. To allow nested queries to be arbitrarily chained together in sequences, so the result of one query (for one database) may be used as the input of another (for another database); 3. To be schema independent, so that databases without or with different schemas can be easily integrated; 4. To allow data-metadata transformations, e. g. to convert attributes or relations into data and vice versa  [22] ; 5. To be easily optimizable so that efficient query optimization, introduced in stateof-the-art multidatabase systems, can be reused (e. g. exploiting bind joins  [9]  or shipping the smallest intermediate results). In this paper, we present the design of a Cloud multidatastore query language (CloudMdsQL), and its query engine, which addresses these requirements.
While the latter four have already been identified as requirements and introduced in multidatabase mediator/wrapper architectures, CloudMdsQL contributes to satisfying also the first one. The language is capable of querying multiple heterogeneous databases (e. g. relational and NoSQL) within a single query containing nested subqueries, each of which refers to a particular data store and may contain embedded invocations to the data store's native query interface. The design of the query engine takes advantage of the fact that it operates in a cloud platform. Unlike the traditional mediator/wrapper architectural model where mediator and wrappers are centralized, we propose a fully distributed architecture that yields important optimization opportunities, e. g. minimizing data transfers between nodes.
This allows us to reuse query decomposition and optimization techniques from distributed query processing  [19]. Thus, the major innovation is that a CloudMdsQL query can exploit the full power of local data stores, by simply allowing some local data store native queries (e. g. a breadth-first search query against a graph database) to be called as functions, and at the same time be optimized based on a simple cost model, e. g. by pushing down select predicates, using bind join, performing join ordering, or planning intermediate data shipping. The rest of this paper is organized as follows. Section 2 discusses related work in more details. Section 3 introduces CloudMdsQL's basic concepts, including its data model and language constructs. Section 4 presents the architecture of the query engine and its main components.
Related Work Accessing heterogeneous data sources has been addressed by multidatabase systems  [19]  and data integration systems for the Web  [5]. The typical solution is to provide a common data model and query language to transparently access data sources, thus hiding data source heterogeneity and distribution. The dominant state-of-the-art architectural model is the mediator/wrapper architecture. In this architecture, each data source has an associated wrapper that exports information about the source schema and data, and mapping functions that give the translation between source data and schemas and the mediator's data and schema. The mediator centralizes the information provided by the wrappers in a unified view (called mediated schema) of all available data, transforms queries expressed in a common language into queries for the data sources using the wrappers, and integrates the queries' results.
The mediator/wrapper architecture has several advantages. First, the specialized components of the architecture allow the various concerns of different kinds of users to be handled separately. Second, mediators typically specialize in a related set of data sources with "similar" data, and thus export schemas and semantics related to a particular domain. The specialization of the components leads to a flexible and extensible distributed system. In particular, it allows seamless integration of different data stored in very different data sources, ranging from full-fledged relational databases to simple files. The authors of  [20]  propose distributed mediator architecture with a flexible interface between mediators and data sources that efficiently handles different query languages and different data source functionality.
As a particular case, XML can represent relational tables, but at the expense of more complex parsing. XQuery is now a complete query language for XML, including update capabilities, but more complex than SQL. As a generalization for Web linked data, there is also current work based on RDF/SPARQL  [10]. There is still much debate on rela-tional versus XML, but in the cloud, relational-like data sources, e. g. NoSQL keyvalue stores such as Google Bigtable and Hadoop Hbase, are becoming very popular, thus making a relational-like model attractive. The main requirements for a common query language (and data model) are support for nested queries, schema independence and data-metadata transformation  [22]. Nested queries allow queries to be arbitrarily chained together in sequences, so the result of one query (for one data store) may be used as the input of another (for another data store).
Schema independence allows the user to formulate queries that are robust in front of schema evolution. Data-metadata transformation is important to deal with heterogeneous schemas by transforming data into metadata and conversely, e. g. data into attribute or relation names, attribute names into relation names, relation names into data. These requirements are not supported by query languages designed for centralized databases, e. g. SQL and XQuery. Therefore, federated query languages need major extensions of their centralized counterpart. We now discuss briefly two kinds of such extensions of major interest: relational languages and functional SQL-like languages. In  [22] , the authors propose an extended relational model for data and metadata integration, the Federated Relational Data Model, with a relational algebra, Federated Interoperable Relational Algebra (FIRA) and an SQL-like query language that is equivalent to FIRA, Federated Interoperable Structured Query Language (FISQL).
FIRA and FISQL support the requirements discussed above, and the equivalence between FISQL and FIRA provides the basis for distributed query optimization. FISQL and FIRA appear as the best extensions of SQL-like languages for data and metadata integration. In particular, it allows nested queries. But as with SQL, it is not possible to express some complex control on how queries are nested, e. g. using programming language statements such as IF THEN ELSE, or WHILE. Note that, to express control over multiple SQL statements, SQL developers typically rely on an imperative language such as Java in the client layer or a stored procedure dialect such as PLSQL in the database layer. Another major limitation of the relational language approach is that it does not allow exploiting the full power of the local data source repositories.
For instance, mapping an SQL-like query to a graph database query will not exploit the graph DBMS capabilities, e. g. generating a breadth-first search query. Database programming languages (DBPLs) have been proposed to solve the infamous impedance mismatch between programming language and query language. In particular, functional DBPLs such as FAD  [4]  can represent all query building blocks as functions and function results can be used as input to subsequent functions, thus making it easy to deal with nested queries with complex control. The first SQL-like functional DBPL is Functional SQL  [21]. More recently, FunSQL  [1]  has been proposed for the cloud, to allow shipping the code of an application to its data. Another popular functional DBPL is LINQ  [17] , whose goal is to reconcile object-oriented programming, with relations and XML.
LINQ allows any. NET programming language to manipulate general query operators (as functions) with two domain-specific APIs that work over XML (XLinq) and relational data (DLinq) respectively. The operators over relational data provide a simple object-relational mapping that makes it easy to specify wrappers to the underlying RDBMS. Recently, multistore systems have been introduced to provide integrated access to a number of RDBMS and NoSQL data stores through a common query engine. The BigIntegrator system  [24]  integrates data from cloud-based NoSQL, such as Google's Bigtable, and relational databases. The system relies on mapping a limited set of relational operations to native queries expressed in GQL (Google Bigtable query language). With GQL, the task is achievable because it represents a subset of SQL.
However, unlike CloudMdsQL, it only works for Bigtable-like systems and cannot integrate data from other families of NoSQL systems, e. g. document or graph databases. Estocada  [2]  is a self-tuning multistore platform that uses view-based rewriting for providing access to datasets in native format while automatically placing fragments of the datasets across heterogeneous stores. Since these approaches do not directly support native queries, they do not preserve the expressivity of an arbitrary data store's query language. Tightly-coupled multistore systems have been introduced with the goal of integrating Hadoop MapReduce for big data analysis with traditional RDMS with NoSQL data stores. Major multistore products such as IBM BigInsights, Microsoft HDInsight, Oracle Bigdata Appliance, typically rely on database connectors (e.