dataesr/scientific-paragraphs-categorization huggingface dataset:
Acknowledgments We thank  Fernando Govantes's laboratory (Fernando Govantes Centro Andaluz de Biología del Desarrollo, Universidad Pablo de Olavide/Consejo Superior de Investigaciones Científicas / Junta de Andalucía, Sevilla, Spain ) for giving the Pseudomonas sp. ADP bacterial strain. The authors thank their financial support ( Ville de la Roche sur Yon, Conseil Général de Vendée, conseil régional des Pays de la Loire  and the  French Ministry of Research).
GO enrichment analysis was performed using the WEB-based GEne SeT AnaLysis Toolkit (WEBGESTALT; http://bioinfo. vanderbilt. edu/ webgestalt/analysis. php)  (43). HuGene 1. 0 ST Probe IDs of significantly regulated candidates in specific groups according to expression and localization were used for GO enrichment analysis using the following parameters: Organism: hsapiens, Id Type: affy hugene 1 0 st v1, Ref Set: affy hugene 1 0 st v1, Statistic: Hypergeometric, Significance Level: Top10, MTC: BH, Minimum: 2. Microarray data were submitted to the Gene Expression Omnibus [identifier GSE49029].
Motif enrichment analysis in subgroups To identify potential short regulatory motifs in the UTRs of the subgroups we used the DREME tool  (44)  of the MEME suite (45) version 4. 8. 1. , which was downloaded from the meme home page [http://meme. nbcr. net/meme/] and installed locally on the UNIX operating system. Briefly, DREME (Discriminative Regular Expression Motif Elicitation) finds short motifs that are enriched in a set of DNA sequences in comparison to a reference set  (44). The statistics of the DREME program relies on the Fisher Exact Test. We used the complete human 5 -UTR or the complete 3 -UTR set as reference sets for the specific 3 -or 5 -UTR subgroups, respectively.
Estimation of UTR length and UTR specific conservation score We obtained the sequences of all human 5 -and 3 -UTRs of each transcript with the Biomart tool  (46)  of the EN-SEMBL project (www. ensembl. org). Length was calculated for each UTR of each transcript using an in-house developed software tool. We only considered UTRs with a length of at least 30 nt for further analysis. For calculation of average evolutionary conservation score, we first obtained the basewise conservation score for the complete human genome from USCS (http://hgdownload. soe. ucsc. edu/goldenPath/hg19/phyloP46way/) that is based on algorithms that use multiple species comparisons  (47, 48). We then mapped the genome-and basewise conservation score onto the 3´-UTR and 5´-UTR positions of each transcript with a memory-optimized in-house software tool based on the c++ programming language using the c++ standard template library.
Boxplots were generated and statistical analysis was performed using the open source statistical package R (version 2. 15. 3) obtained from (http://www. r-project. org) with the Rcmdr package (http://socserv. mcmaster. ca/jfox/Misc/ Rcmdr/). Statistical analysis is based on a linear ANOVA model. Post hoc analysis was performed with the 'Tukey Contrasts--Multiple Comparisons of Means' and the adjusted P-values are reported for the post hoc multiple comparisons.
The production of huge amount of data and the emergence of cloud computing have introduced new requirements for data management. Many applications need to interact with several heterogeneous data stores depending on the type of data they have to manage: traditional data types, documents, graph data from social networks, simple key-value data, etc. Interacting with heterogeneous data models via different APIs, multidata store applications imposes challenging tasks to their developers. Indeed, programmers have to be familiar with different APIs. In addition, developers need to master and deal with the complex processes of cloud discovery, and application deployment and execution. Moreover, the execution of join queries over heterogeneous data models cannot, currently, be achieved in a declarative way as it is used to be with mono-data store application, and therefore requires extra implementation effort.
It is based on the 3-Vs model where the three Vs refer to volume, velocity and variety properties  (McAfee and Brynjolfsson, 2012). Volume means the process of large amounts of information. Velocity signifies the increasing rate at which data flows. Finally, variety refers to the diversity of data sources. Against this background, the challenges of big data management result from the expansion of the 3Vs properties. In our work we focus mainly on the variety property and more precisely on multi-data store applications in the cloud. In order to satisfy different storage requirements, cloud applications usually need to access and interact with different relational and NoSQL data stores having heterogeneous APIs. The heterogeneity of the data stores induces several problems when developing, deploying and migrating multi-data store applications.
Below, we list the main 4 problems which we are tackling in this paper. Pb 1. Heavy workload on the application developer: Nowadays data stores have different and heterogeneous APIs. Developers of multi-data store applications need to be familiar with all these APIs when coding their applications. Pb 2. No declarative way for executing join queries: Due to the heterogeneity of the data models, there is currently no declarative way to define and execute complex queries over several data stores. That means developers have to cope themselves with the implementation of such complex queries. Pb 3. Code adaptation: When migrating applications from one cloud environment to another, application developers have to re-adapt the application source code in order to interact with new data stores. Developers have potentially to learn and master new APIs.
Pb 4. Tedious and non-standard processes of discovery and deployment: Once an application is developed or migrated, developers have to deploy it into a cloud provider. Discovering the most suitable cloud environment providing the required data stores and deploying the application on it is a tedious and meticulous providerspecific process. In our work, we are are coping with these problems in order to support the developer during a multiple data stores based application life cycle. In a previous work, we proposed ODBAPI (OPEN-PaaS-DataBase API) a streamlined and a unified RESTbased API  (Sellami et al. , 2014)  for executing CRUD operations on relational and NoSQL data stores. The highlights of ODBAPI are twofold: (i) decoupling cloud applications from data stores in order to facilitate the migration process, and (ii) easing the developers task by lightening the burden of managing different APIs.
MOTIVATION Our work is done in the context of the OpenPaaS project 2  aiming at developing a PaaS technology dedicated to enterprise collaborative applications de-ployed on hybrid clouds (private/public). It is a platform that allows to design and deploy applications based on proven technologies provided by partners such as collaborative messaging system, integration and workflow technologies that will be extended in order to address Cloud Computing requirements. Target applications of OpenPaaS are applications that use multiple data stores that corresponds to what is popularly referred to as the polyglot persistence. For instance, an application can interact with three heterogeneous data stores at the same time: a relational data store, a document data store that is CouchDB, and a key value data store which is Riak.
But, this example exposes some limits. Linking an application with multiple data stores is very complex due to the different APIs, data models, query languages and consistency models. If the application needs to query data coming from different data sources (e. g joining data, aggregating data, etc. ), it can not do it declaratively unless some kinds of mediation have been done before. Finally, the different data stores may use different transaction and consistency models (for example classical ACID and eventual consistency). It is not easy for developers to understand these models and to maintain its properties while coding their application. Moreover, it is more complicated when it comes to execute complex queries and especially join queries. But first, the developer has to discover all data stores capabilities of the available cloud providers in order to elect the most suitable cloud provider to his application requirements to deploy it.
OVERVIEW OF OUR APPROACH The lion's share of the contribution of our work is dedicated to application developers. Indeed, we attempt to simplify the developer task during the life cycle of an application (i. e. development, discovery and deployment, and execution) using multiple and heterogeneous data stores in its source code. The developer has (i) to write the source code of his application using various APIs, (ii) to discover data stores of each cloud provider in order (iii) to deploy his application, and (iv) to execute queries. Hence, for the purpose of simplifying the developers task and getting them rid of all their onerous responsibilities, we propose our solution that is based on three points: (i) using a unique API enabling the CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience coding and the execution of multiple data store based application, (ii) enabling join queries execution over heterogeneous data stores, and (iii) ensuring a neutral application deployment in a cloud provider that is already automatically discovered.
In Fig 1 , we showcase an overview of our solution including the different steps of the application life cycle. Indeed, we depict the following four steps: • Development Step: The first step is the application development. For this purpose, we propose to use a unique API enabling the interaction with relational and NoSQL data stores. In a previous work  (Sellami et al. , 2014) , we defined a generic resources model defining the different concept used in each type of data store. These resources are managed by ODBAPI a streamlined and a unified REST API enabling to execute CRUD operations on different NoSQL and relational databases. ODBAPI decouples cloud applications from data stores alleviating therefore their migration. Moreover it relieves developers task by removing the burden of managing different APIs.
This manifest contains the endpoint of the ODBAPI server or/and the data stores endpoints that the application requires. We propose to deploy an application by any deployment API (e. g. COAPS API  (Sellami and et al. , 2013) , roboconf API 3  , etc. ). In our work, we are building on the COAPS API that is proposed in our team and allows human and/or software agents to provision and manage PaaS applications. This API provides a unique layer to interact with any cloud provider based on manifests. We model the deployment manifest based on the manifest of COAPS API and we enrich it with information about data stores to support ODBAPI-based application. • Execution Step: The fourth step is the application execution. In this step, an application can execute two types of queries. On the one hand, it can execute CRUD queries; hence it interacts directly with the target data store based on its execution manifest.
This is done through the operation electCP that takes as inputs the the data structure distance and the threshold and returns the identifier of the elected cloud provider if any. This identifier is the smallest value bounded between 0 and the threshold. In algorithm 2, we present in more details the operation queryDataStoresRepository that returns a super-set of the result from the data stores repository. In fact, for each cloud provider it extracts all data stores corresponding to the data types of the abstract application manifest. If there are no corresponding data stores, the cloud provider is rejected (lines 10- Algorithm 2: The queryDataStoresRepository algorithm. 1: input AAM: the abstract application manifest 2: output OM: the offer manifest 3: length ← 0 4: for each node N in AAM do 5: if (content-type == "database") then 6: T [length] ← getType(N) 7: length ← length + 1 8: end if 9: end for 10: for each Cloud Provider CP in the data stores directory do 11: for i=0 to length do 12: if (CP contains T[i]) then 13: Add all names of this type to the tree of the current CP 14: else 15: Reject the current CP 16: end if 17: end for 18: end for 19: return the resulted trees as the OM 18).
IMPLEMENTATION AND VALIDATION In this section, we present the tool implementing the matching module. Hence, in order to show the feasibility of this module, we propose to discover data stores of cloud foundry and open shift as cloud providers to deploy an ODBAPI-based application. This application is intended to handle the administration of relational and NoSQL data stores in a cloud provider. To do so, we propose to implement the manifests modeling with XML. We give in this section the example of the abstract application manifest (see Listing 1). Indeed, the developer provides user1 as a login and pswd as a password. Then, he describes the environment that he requires in order to deploy his ODBAPI based application. Indeed, he chooses as name for the environment ODBAPIEnv and for the environment template ODBAPIEnvTemp.
Indeed, the application programmer describes his requirements in the abstract application manifest and he uploads it through the interface that we illustrate in Fig. 7. Once this manifest is uploaded, this tool executes the manifest based matching algorithm to elect the appropriate cloud provider that supports the ODBAPI client requirements and returns the user the deployment manifest. Based on the deployment manifest, we deploy the ODBAPI client by the mean of COAPS API. In our work, we deploy an ODBAPI-based client intended to handle the administration of relational and NoSQL data stores in a cloud provider. In Fig. 8 , we show an overview of the databases created in each data store in the Cloud Foundry. Indeed, there is a MySQL database called world and it contains three entity sets: city, country, and countrylanguage.
RELATED WORK In our previous work  (Sellami and Defude, 2013) , we focused on existing solutions of the state-of-theart supporting multiple data stores based applications in the cloud environment. More precisely, (i) we described different scenarios related to the way applications use data stores, (ii) we defined the data requirements of applications in cloud environment, and (iii) we analyzed and classified existing works on cloud data management, focusing on multiple data stores requirements. As a result, we pointed out six requirements of using multiple data stores in a cloud environment. One of these requirements consists in choosing a data store based on a data requirements. We present three sub-requirements: defining application needs and requirements towards data, defining data store capabilities, and defining application needs and data stores capabilities matching.
Moreover, they propose a novel SLA monitoring framework to facilitate compliance checking of Service Level Objectives by a trusted third part. Although  Ghosh et al. try  to enrich the SLA parameters to support the Storage-as-a-Service, this is still inadequate for our purpose in this paper. In (Ruiz-Alvarez and Humphrey, 2011), (Ruiz-Alvarez and Humphrey, 2012), Ruiz-Alvarez et al. propose an automated approach to selecting the PaaS storage service according an application requirements. For this purpose, they define a XML schema based on a machine readable description of the capabilities of each storage system. The goal of this XML schema is twofold: (i) expressing the storage needs of consumers using high-level concepts, and (ii) enabling the matching between consumers requirements and data storage systems offerings.
CONCLUSIONS AND FUTURE WORK In this paper, we proposed a manifest-based solution for data stores discovery and automatic application deployment. Indeed, once the developer has completed the development of his application, we provided him the possibility to express his application requirements in terms of data stores in the abstract application manifest. Then, he sends it to the discovery module. This module interacts with the data stores directory to discover the capabilities of data stores of each cloud provider and constructs the offer manifest. Based on that, this module implements the matching algorithm in order to elect the adequate cloud provider to the application requirements. This algorithm takes as input the abstract application manifest and offer manifest, and returns the deployment manifest of the application.
Once it is done, we deploy the application using the COAPS API that takes as input the deployment manifest. Currently, we are working on applying our solution to other qualitatively and quantitatively various scenarios in the OpenPaaS project. This allows us to identify possible discrepancies and make our work more reliable for real use. Our second perspective is to implement virtual data stores in order to execute join queries across NoSQL and relational data stores and to introduce more elaborate query processing optimization techniques.
Genome-wide analysis The published datasets for Nelf-E, Spt5, and input reads in HeLa-S3 were obtained from  43  under the accession number GSE60586. CTCF ChIP-seq and its associated input in HeLa-S3 were obtained from the ENCODE/Broad 44 under the accession number GSM733785. TSS annotation was acquired from Ensembl GRCh37 release 75. All sequences were mapped using Bowtie2 45 version 2. 1. 0 against the human genome (GRCh37 hg19 from Ensembl). Only uniquely mapped reads were kept and up to 2 mismatches were allowed. Mapped reads were then de-duplicated using Picard to remove PCR-duplicates. Peaks were called with MACS  46  version 2. 1. 0. 20150731 using ChIP and input samples and a q-value threshold of 0. 01. The CTCF peaks from each replicate were intersected and only the common peaks were kept.
In case of multifocal or multicentric carcinomas, the tumor with the highest pathologic size and/or highest histological grade was included in the study. Automated IHC (Benchmark XT Ventana, Roche Diagnostics) was performed using antibodies against ERα (Estrogen Receptor alpha, clone C311, Santa Cruz), PR (Progesterone Receptor, clone 1E2, Ventana), HER2 (Human Epidermal Growth Factor Receptor 2 clone 4B5, Ventana), Ki-67 (clone MIB1, Dako), CK5/6 (Cytokeratin 5/6, clone D5/16B4, Dako), EGFR (Epidermal Growth Factor Receptor Type 1 clone 31G7, Invitrogen) and IGF1R (Insulin-like Growth Factor type 1-Receptor clone G11, Ventana). IHC protocols are detailed in Additional file 1: Table  S1. Scoring of the immunohistochemical staining was performed by the five independent pathologists. ER, PR and Ki-67 were assessed based on the number of positive nuclei among 500 counted cells (manual image analysis involving the use of the image J software, Research Service Branch, National Institute of Health, Bethesda, Maryland, USA).
Statistical analysis The Statview (Statview 5 SAS Institute Inc. ) and R (R 3. 1. 1 GUI 1. 65) softwares were used for statistical analyses. Results are given as median and range unless otherwise indicated. Non-parametric tests were used after checking for normality and independence of the data by Kolmogorov-Smirnov test and graphic assessment. The correlation between IGF1R expression and categorical variables (age groups, histological grade, clinical stage, nodal stage, hormone receptor status, and immunophenotype) was analyzed using the Pearson chi-square test or the Fisher exact test. Correlations between numeric variables were determined by Spearman's test. The Kaplan-Meier non-parametric method was used for univariate survival analysis and the log-rank test was used to assess differences among groups.
Acknowledgements The authors thank  Dr Claire Hanzenne ,  Dr Ingrid Bemelmans ,  Dr Catherine Ibisch ,  Dr Floriane Morio , and  Dr Clotilde de Brito , who helped in the collection of clinical and follow-up data of the dogs. We are deeply indebted to  Pr Laura Pena  ( Veterinary School, University of Madrid, Spain ) and  Pr Adelina Gama  ( University of Vila Real, Portugal ) for their expertise in canine mammary carcinomas and their involvement in the classification, grading, and determination of immunophenotypes. The authors also thank the veterinary pathologists ( Dr Jean-Loïc Le Net ,  Dr Virginie Théau ,  Dr Pierre Lagourette ,  Dr Olivier Albaric  and  Dr Sophie Labrut ) who performed the initial diagnoses, as well as the technicians in histopathology ( Mr. Bernard Fernandez ,  Mrs Florence Lezin , and  Catherine Guéreaud ).
1% Tween 20 (TBST), 10% non fat dry milk, for 1 h at room temperature. Then, membranes were incubated overnight at 4°C with an antilipid A goat primary antibody (NB-600-1505 Novus France, Interchim, Montluçon France) using a dilution of 1/400 in 1% non fat milk TBST. A second incubation was done with an antigoat immunoglobulin horseradish peroxydase coupled secondary antibody at a dilution of 1/ 5000 for 1 h at room temperature. After several washes, dots were detected using western blotting detection reagents (ECL, Amersham). Relative intensity of each spot was scanned and quantified using Image J software. Controls without afterglow exposure were done in the same conditions. The relative lipid A content (vacuum-treated and vacuum + afterglow exposed) was evaluated vs a dot-blot calibration curve of different lipid A concentrations ranging from 0.
Adenoviral vector preparation and MSCs transduction MSCs were seeded at 70% of confluence in complete medium. Medium was then removed, and cells were infected at a multiplicity of infection (MOI) of 30 in DMEM lg and 2% FBS in half of total volume for 2 h. After that, medium was completed with 10% FBS in DMEM lg. Expression of IGF-I or green fluorescent protein (GFP) was evaluated at 3 days after transduction by radio-immunoassay (Supplementary Data; Supplementary Data are available online at www. liebertpub. com/scd) or by direct observation under fluorescence microscopy. Otherwise stated, in different experimental protocols, cells were also used at 3 days after adenoviral infection.
Other experimental groups consisted of animals treated with/without AdGFP-MSCs plus recombinant IGF-I (rIGF-I) (kindly provided by Dr. P. Fortes): 1 mg/100 g body weight, in two divided doses. The latter was subcutaneously applied daily from day 1 to 14. In vivo tracking of MSCs was performed as previously described  [18]. In brief, MSCs were stained with CMDil for histological analysis and DiR (Molecular Probes, Invitrogen) for fluorescence imaging (FI). MSCs (5 • 10 5 ) were intravenously injected into mice previously treated with TAA for 6 weeks. FI was performed using the Xenogen In Vivo Imaging System (IVIS; Caliper Life Sciences). Mice injected with CMDiI-DiR-labeled MSCs were analyzed at 1-14 days after MSC injection. Images represent the radiant efficiency and were analyzed with IVIS Living Image (Caliper Life Sciences) software.
3B ). Moreover, a-SMA mRNA expression levels were further reduced in HSCs when they were treated with AdIGF-I-MSC supernatant (Fig. 3B ). As expected, a similar pattern of changes in  mRNA expression levels was found for TGF-b1 and COL1A2 genes (Fig. 3B ). These results were confirmed at the protein level for active TGF-b1 and a-SMA (Fig. 3C ). A similar pattern was observed when TGF-b1 protein expression levels were analyzed in serum by ELISA (not shown; 33. 75 -2. 28 vs. 25. 14 -3. 29 vs. 20. 21 -1. 25; saline vs. AdGFP-MSCs vs. AdIGF-I-MSCs; P < 0. 05, saline vs. AdIGF-I-MSCs). These data suggest that AdIGF-I-MSCs treatment further reduces the activation of HSCs when compared with AdGFP-MSCs condition, thus resulting in the amelioration of liver fibrosis.
Acknowledgments The authors thank  Rodolfo Goya  ( UNLP, CONICET ) for kindly providing them with Ad-IGF-I and Ad-GFP. They also thank  Mariano Marrodan  and  Marcela Giovenco  for experimental help, and  Soledad Arregui ,  Vanina Ferreira , and  Guillermo Gaston  for technical assistance. This work was supported by grants from  Austral University  (for J. B. I04-12; for M. G. G. T13-12 ; for J. B. A. 17-09; and for G. M. T13-11 ) and from 800  FIORE ET AL.