dataesr/scientific-paragraphs-categorization huggingface dataset:
To characterize sensitive skin in the Indian population, the characteristics of the subjects with "sensitive" or "very sensitive" skin (the "sensitive skin" group) were compared with those of the subjects having "not very sensitive" or "not sensitive at all" skin ("non-sensitive skin" group). Quantitative variables were compared between groups with Student's t-test (when there were two groups to compare) or ANOVA (when there were more than two groups to compare). When the conditions for the application of these tests were not met, the Wilcoxon and Kruskal-Wallis non-parametric tests were performed. Categorical variables were compared with an appropriate test, with Fisher's test used if the conditions were not completely met. Statistical analyses were performed with SAS software version 8. 2 (SAS Institute).
Histopathological Analyses For basic histopathological investigations, brain sections were stained with the DNA fluorochrome 4,6-diamidino-2-phenylindole (Dapi, Sigma-Aldrich) for the measurement of thickness of specific brain layers. For skeleton analysis, the procedure adapted from Wallin et al. [51]  involves the complete skinning of fresh eviscerated rat embryos following a 24 h-immersion in 95% ethanol. Skeletons were stained for 48 h with 1% Alcian blue dye, diluted in an ethanol/acetic acid mix, specific for cartilage staining. Skeletons were then macerated in 2% KOH until bones are visible and stained for 24 h with 0. 12% Alizarin red dye diluted in KOH, specific for bone staining. Specimen were finally cleared and hardened in glycerol/ethanol baths and stored in 87% glycerol. Detailed observations and measurements were performed by means of the Cell ® software (Olympus).
Real-time PCR was carried out by means of a Step One Plus Real-Time PCR System (Applied Biosystems). Incubations were performed in a 96-well plate at 95 • C for 10 min for enzyme activation, followed by 40 cycles of PCR: Denaturation (95 • C for 15 s), and annealing/extending (60 • C for 2 min). Data analysis was performed with the software provided by the manufacturer (Step One Plus). In situ hybridization: The in situ detection of let-7a, miR-34a and miR-23a was performed on paraffin embedded sections from normal and methyl donor deficient brain tissues by locked nucleic acid (LNA)-oligo in situ hybridization, as previously described by Kloosterman et al. [52]. Briefly, the slides were deparaffinized in xylene, rehydrated in decreasing concentrations of ethanol, and treated with proteinase-k for nucleic acid release.
INTRODUCTION Universally applied Codd's (relational) model for a Database (Management) System (DBS),  [1]  &  [2]  has two constructs: a stored relation and a view. Both are named finite relations with atomic attributes only, in 1st Normal Form (1NF) thus. A Stored Relation, (SR), called also a base one, or simply relation or a (relational) table, has stored (base) attributes (columns) only. Clients or applications provided the stored tuples. The SR definition (scheme) does not allow calculating any of these. A view, also called Inherited Relation (IR), has only the inherited attributes. These get values basically only calculated on-the-fly from SRs or from other views through a statement of some data definition language (DDL), usually an SQL Select query, stored within the view scheme. In 1992, we proposed an additional construct,  [11].
It was also a 1NF relation, but mixing the stored and the inherited attributes. Examples showed the construct attractive. No further work followed however, to the best of our knowledge. Below, we refine our proposal specifically for SQL DBs. We call our construct Stored and Inherited Relation, (SIR), Figure  1. For every SIR R, we suppose every stored attribute (SA) of R defined as usual for an SR. We define the inherited attributes (IAs) basically as usual for a view, through some relational or value expression we refer to as to Inheritance Expression (IE). For every SIR R, a single Create Table R defines both the SAs and the IE. The IAs of a SIR may model properties inconvenient as SAs. First, supposing the SR formed from the SAs within the SIR normalized, the latter choice could also adversely impact this normalization.
Next, it could imply impractically frequent updates. By addressing SAs and IAs in the same SIR, an SQL query may furthermore totally or partly avoid the logical navigation, otherwise necessary for every equivalent query to the scheme with normalized SRs only. We recall that such navigation occurs when a query has to refer to attributes in several relations with, usually, equijoin clauses among those relations then. Next, one can define IAs within a SIR through value expressions, letting for SQL queries to the SIR free of these expressions. Altogether, SQL queries to a DB with SIRs should end up usually less procedural (simpler, more usable…) than their equivalents to a DB with normalized SRs only, by the basic measure of the number of characters per query. On the other hand, one may observe that for every SIR R, there is always at least one view that one can name view R, defining mathematically the same SQL relation and for every SA in SIR R with unambiguous proper name, having an IA bearing, at least, the same proper name.
We intend SIR R in this context to be a single construct replacing both: CE-view R and SR R. The intended result is an SQL relation equivalent to CE-view R, with also the same full source name of every attribute, assuming R_B the source name for every SA in SIR R, as we just did. The only intended difference between SIR R and CE-view R is that as a DB relation, Figure  1 , SIR R has R_B as the base, i. e. , every attribute R_B. A of view R is materialized back in SIR R into the SA of SR R. Accordingly, we define SIR R through Create Table R of SR R, expanded with the definitions of every IA inherited in view R from R1…Rk. The resulting order of the SAs and IAs in SIR R should be that of the corresponding IAs in CE-view R. In practice, one way to proceed is to write down, after the declaration: 'Create   R  for SR R.
Then, add to the list of attributes every IA intended for view R where it would be inherited from R1. Rk. The resulting order of the attributes should be the one of view R. Finally, one inserts From… clauses intended for view R after the last attribute of the list. Observe that the result, no matter which way constructed, conforms to our generic requirement on the primary key of every SIR R. Also, observe that our rule for default source naming of SAs in SIR R, keeps all the clauses From… within view R referring there to R_B, valid for SIR R as well. Instead of standalone SR R_B, they simply refer to the base of SIR R, equal to the former as an SQL relation and with respect to the full attribute naming. While this is the primary rationale for our specific to SIRs naming rule, one can figure out also a less obvious one.
SIR R becomes consequently more advantageous than SR R and CE-view R for the avoidance of the logical navigation or of selected value expressions. In fact, we qualify of explicit, every IE with the above sub-list. We denote it as E or E R for SIR R. The refinements we hinted to, define implicit IEs. These are defined differently and introduced in next subsection. Observe that every E R defines the SQL projection of CE-view R on all and only IA that are also IAs in SIR R. Observe finally, that while these IAs are always contiguous in E R , they may be separated by SAs in Create Table R, as at Figure  2 , we recall. Ex. 1. Recall the 'biblical' Supplier-Part DB, often named S-P in short, modelling some suppliers, parts and supplies. A supply contains some quantity of a part shipped by some supplier.
CITY, PNAME, COLOR, WEIGHT, P. CITY From (SP_B Left Join S On SP_B. S# = S. S#) Left Join P On SP_B. P# = P. P#), Primary Key (S#, P#)); Figure  3  shows S-P2 scheme. Figure  4  shows the content of SIR SP that would result for the sample data of S-P1. Every SA is in plain text and every IA in Italics. We suppose the SAs schemes in S-P2. SP these of S-P1. SP, hence of SP_B for CE-view SP. These SAs and their tuples form also the base SP_B of S-P2. SP. The (underlined) key of S-P2. SP is also that of S-P1. SP. Its definition in Create Table SP in (2) above follows entire E SP , as required for every Create Table R for SIR R. E SP is the string: 'SNAME…P. P#' that happens to be contiguous one. It is the same substring in (1) hence in CE-view SP, as well as defining the SQL projection there on the enumerated IAs.
These are also all and only IAs in  (2). As only a substring, it is strictly less procedural than  (1). More precisely, one saves the string 'Create View SP As (Select SP_B. *,'. This makes Create View SP scheme about 25% more procedural than E SP. The remaining part of (  2 ) is exactly as procedural as Create Table  SP_B. It is simply the same indeed, except for the name SP_B of course. In both statements (1) and (  2 ) above, the already reminded SQL ordering makes all the SAs preceding all the IAs. It is our subjective choice. The rationale is that keeping the IAs inheriting from SP_B together, minimizes, in SQL, the procedurality of view SP, through SP_B. *. Note nevertheless that many consider '*' less safe for Create View than the list of attributes it represents. The latter choice would make the procedurality gain provided by SIR SB even greater.
Same would happen if an IA dispersed the SAs within Create Table SP and in in CE-view SP thus. The list of IAs contiguous in E SP would then consist of the same IAs, but non-contiguous in Create Table  SP. The same From clause of (2) would follow both lists. Finally, for S-P2, the query Select * From SP; would output the attribute order at Observe also that in (1), any prefix SP_B, in joins refers to SR SP that is one of the source relations of view SP. In (2) in contrast, it refers to the SP base SP_B, hence to a part of SP itself. We qualify below every join in some SIR R referring similarly to a part of R, of recursive. Actually, a recursive join may be a θ -join, as one may easily find out. Recursive joins are basically not permitted for SQL views, we recall. The example suggests them in contrast typical for IEs.
Also, most often, for any view scheme, the Select expression either enumerates every IA in Select list or, if some IAs form all the attributes of some relation X and are inherited with the same names and values, then Select may contain the notorious less procedural generic SQL construct X. * instead. As already stated, in both cases, first, every E R is a proper substring of Create View R, although perhaps distributed within the latter. Consequently, declaring an E R instead of such a CE-view R, is always less procedural. Using SIRs brings thus this advantage to every DB using such CE-views at present. The rare and only exception are the CE-views with entire Select list reduced to '*'. Such Select list is inapplicable to an IE. It would redefine IAs defined as the SAs forming the base of the SIR.
This, as attribute WEIGHT_KG, placed as the successor of WEIGHT in P. 1. Suppose MS Access as the kernel dialect. E P is the only option, e. g. , (12) E P = Round (WEIGHT*0. 454,3) AS WEIGHT_KG From P; The Select list of E P , i. e. , WEIGHT_KG scheme, should be in Create Table P immediately after SA WEIGHT scheme. From P clause in  (12)  should follow SA CITY. As claimed in the Introduction, again E P would be less procedural than any CE-view P or QE-view P or any other equivalent view with WEIGHT_KG. 2. Suppose now S-P2 on SQL Server. WEIGHT_KG could be a VA. Rule 3 allows declaring WEIGHT_KG as: (13) WEIGHT_KG As Round (WEIGHT * 0. 454,3) ; For SIR SQL of S-P2, i. e. , using here SQL Server SQL as the kernel, this declaration constitutes I P. Through Rule 3, Create Table P with  (13)  would mean that of SQL Server creating SR P with SAs as at Figure  3  and with VA WEIGHT_KG defined by  (13).
DDL Statements for SIR Model We already discussed Create Table for SIRs extensively. We now focus on the other SQL DDL statement for SIRs. We continue supposing every such statement backward compatible with some (kernel) dialect. E. g. , for MySQL SQL, we suppose Create View for SIRs being simply the MySQL Create View, except that among source relations could be a SIR. Similarly for SQL Server etc. The other SQL DDL statements we consider for SIRs are all the popular ones, i. e. , Alter The IE-clause may be in one of the following forms, differing only by the Select list of IAs and of SA. If A1,…,An are the IAs, the list (A1,…,An) means that all these IAs follow all the SAs and, perhaps, VAs, of the SIR. The latter remain in the order of Create For Drop Table  R , we simply consider it applying to every SIR R as well.
Likewise, SQL Error Code tests for the Commit or Rollback are necessary after each SQL statement within. All this leads to several SQL statements (how many?). The result is altogether clearly several times more procedural than is  (18). @ Similar savings occur for any equivalent view SP. It is also so for SIR SP variant  (6)  and QE-view SP  (7). Finally, SA name change, SA addition or deletion leads to similar advantages of SIRs. E. g. , work out the shortening of SP_B. QTY to Q, (i) for S-P2. SP and CE-view SP and (ii) for SP variant  (6)  and its QE-view SP. Our above examples obviously generalize to every SIR. It should be clear thus that to alter any SR R to SIR R, should be always substantially less procedural than renaming every SR R to R_B and creating CE-view R or QE-view R. Obviously, choosing another renaming and creating a view equivalent to CE-view R or QEview R accordingly, does not change this conclusion.
Data Manipulation for SIRs As for DDL, we presume for every DBS supporting SIRs that the syntax of every DML statement (query) for SIRs is backward compatible with the kernel SQL dialect. The only operational difference is that a name in the statement may refer to a SIR or its base. With respect to query semantics then, we consider for every query Q referring to any SIR R that the outcome of Q is that of Q addressing CE-view R instead. If Q refers to R_B, the outcome is that of R_B being the stand-alone SR for CE-view R. Every update query Q addressing SIR R is accordingly valid (executable) only if CE-view R is updatable by Q. In practice, the validity of equivalent Q's may depend on the kernel DBS, [D4]. The constraint may impair even Q updating SAs of R only. Q may refer then to R_B, being valid iff valid for R_B as the stand-alone SR for CE-view R.
Suppose also that DBA creates SIR P with IAs WEIGHT_KG and WEIGHT_T, upfront defined as in (  13 ) and  (14). BPS forwards Create Table P at SIR-layer as is to the kernel DBS. The result is SR P with VAs. (3) Suppose that the kernel dialect does not support VAs. Create  BPS should be implemented in some host language, obviously calling the Embedded SQL of the kernel. This implementation is a future work. In the meantime,  [13]  simulates BPS for our example SIRs on MS Access as the kernel. For each SIR, a stored MS Access table is its base. The MS Access stored queries simulate the CE-views. The client may appreciate advantages of SIRs, through queries to CE-views. One may also update these views, e. g. , to experiment with every manipulation of SP or P we have discussed. As easy bonus, one may simulate the QBE interface to SIRs, the generation of forms, graphics, etc.
Additional clauses could decrease the procedurality further. One possibility is lifting the restriction we have illustrated in Example 4. Next, the relational design rules for SIRs we have mentioned appear a promising goal. Also, BPS could perhaps create more efficient CE-views,  [7] ,  [8] ,  [14] ,  [21]. Finally, most of major DBSs are now interoperable,  [10]. Multidatabase SIRs, i. e. , with IEs inheriting from several DBs, appear attractive as well.
Ethical approval for study This study was conducted in accordance with the Declaration of Helsinki  [31] , the Guidelines for Good Epidemiology Practices  [32]  and local regulatory requirements. Before subjects were enrolled the protocol and study documents were approved by the Medical Research and Ethics Committee of the Ministry of Health, Malaysia (study approval: (39)KKM/NIHSEC/P16-1334). Institutional approval was obtained from each Hospital Director and relevant Head of Department before data collection commenced.
Data collection and laboratory analysis Following enrolment, a standardized questionnaire was administered by study staff which collected socio-demographic information, reported dengue histories of subjects and household contacts, other risk factor data (e. g. , household and neighbourhood vector control practices; time spent outdoors) and flavivirus vaccination history. Final discharge diagnoses, made by attending physicians based on routine clinical practice, were retrieved from electronic medical records upon discharge, verified by the investigator and recorded. For suspected cases, during routine blood sampling in the wards, an additional aliquot of 5 mL venous blood was collected. Blood was kept at room temperature for 30-60 min (or refrigerated at 2-8 °C for 24 h) before centrifugation.
Statistical analysis We compared socio-demographic characteristics of VCD cases and controls enrolled for both designs. Univariate logistic regression models were used to estimate associations between confirmed dengue and risk factors using the CC (in which only subjects with at least 1 matched control was included, by conditional logistic regression) and TN study designs. Variables with a P-value <0. 2 on univariate analysis were included in a final multivariable model and were backward-selected to retain in the model at a P-value of <0. 05. Dengue discharge diagnoses were compared with WHO 2009 case definitions, including severity assessment, as derived from subjects' clinical data  [4]. The sensitivity and specificity of each diagnostic test used in routine practice were calculated using RT-PCR and/or NS1 Ag ELISA positive test results as the reference standard, with confidence intervals computed using the normal approximation method.
Acknowledgments Dr Azmillah Rosman  was the site PI, responsible for subject recruitment, at  Hospital Selayang. Study sub-investigators:  Ker Hong Bee ,  Cheng Joo Thye ,  Arvinder Singh HS ,  Haema Shunmugarajo ,  Wan Jazilah Wan Ismail ,  Marina Md Sham ,  Lau Ing Soo ,  Lee Yoong Wah ,  Annie Liau Fui Vun ,  Jamaluddin Hj. Mohamed ,  Amita Vivehanantham ,  Nor Arisah Misnan , Sharimila a/p  Shanmugam ,  Mohd Aizuddin Abdul Rahman. Study coordinators:  Lina Hashim ,  Nur Fatin Zulaikha Kharudin ,  Hasni Adha Ibrahim ,  Nur Azwin Ismail , Anusha d/o  T Ganesapillai ,  Citra d/o Palanisamy. Laboratory  staff from the  Department of Medical Microbiology, UMMC. The following team contributed to data collection, management and coordination:  Karina Abalos ,  Emily De Jesus ,  Yong-Ho Oh ,  Saranyaporn Phrutisunakon ,  Céline Zocchetti.
Statistical Analysis Data were analyzed using the one-way ANOVA in SPSS (IBM, version 22) with protein source (SBM, WHEY, YMP) and protein dose (Low, Medium, High) as main effects. The effect of protein source and dose on the production of various analytes was established separately for each time point (4, 8, and 24 h). ANOVA P-values lower than 0. 05 were considered significant. Tukey's post hoc test was then used to compare differences between the mean values. Pearson correlation coefficients between the fermentation parameters were calculated using the SPSS software.
6, 7. 1, and 11. 6 % of total protein, respectively. Yeast-derived microbial protein had the lowest content of Ile and Leu (3. 9 and 6. 2%, respectively) and SBM the lowest content of Val (4. 6%) (calculated from data in Table  1 ). Due to the different amino acid composition of the protein sources, a similar concentration of BCVFA produced during fermentation would not indicate an equal percentage of protein degraded for different protein supplements. Therefore, the percentage of protein degraded was calculated for each supplement from the extent of BCAA conversion to the corresponding BCVFA by considering the initial content of Val, Ile, and Leu in the supplement. There are reports indicating that fermentation by rumen bacteria is stimulated by the addition of BCAA and BCVFA  (26) (27) (28) (29).
Confocal Microscopy and 3D measurements For quantifications, images were acquired using a LSM800 airy-scan or a LSM 780 confocal microscope and ZEN software (Zeiss). The objective used was a 63x APO oil immersive: an 8x digital zoom was added. Each wavelength was acquired separately with a 350nm z-step width to achieve appropriate reconstruction resolution. For nucleus shape, Image J plugin 3D viewer was used to generate and export an isosurface of the DAPI threshold signal. The surface was then analyzed using MATLAB (Mathworks). It was imported as a mesh and smoothened using the read_vertices_and_faces_from_obj_file script (http://www. alecjacobson. com/weblog/?p=917, Alec Jacobson) and the N_SmoothMesh script (Export Voxel Data, Cyprian Lewandowski, MATLAB file exchange). The main curvatures of the surfaces were calculated using the patchcurvature script (Dirk-Jan Kroon, MATLAB file exchange) and corresponding areas then measured.
Chromatin image analysis Images were acquired using a LSM 780 confocal microscope and ZEN software (Zeiss). The objective used was a 63x oil immersive (model): an 8x digital zoom was added. Single planar slices were manually selected, post-acquisition, to maximize deformation in a 2D plane. The contour of the H3K9me3 signal was manually drawn on Image J in order to obtain precise line scans. Curvature values were obtained based on an automated shape detection, to improve spatial resolution compared with manual detection. Linescan values and polygon vertices were extracted from Image J and analyzed with MATLAB. Straight views of the line selection were obtained with Image J straighten function. All data are plotted with Prism software (GraphPad Software, Inc).
Transcriptomic analysis RNA quantification and quality control was performed using the HT RNA Pico sensitivity LabChip Kit and the Caliper LabChip Microfluidics System (Perkin Elmer). For each sample, 3 ng of total RNA was amplified, labeled, and fragmented using GeneChip WT Pico (ThermoFisher Scientific). Each sample was hybridized onto Human Clariom D (ThermoFisher Scientific), washed, and stained with the Affymetrix® Fluidics Station 450. Array scanning was performed with the Affymetrix® GeneChip Scanner 3000 7G using the Command Console software (ThermoFisher Scientific) and then analyzed using the Affymetrix® rma-sketch routine. Differential expression between condition were analysed using the limma routine implemented in the limma R library  (Smyth, 2004).
ACKNOWLEDGEMENTS We thank  Matthieu Piel ,  David Pellman ,  Gérard Socié  and  Kevin Chalut  for interesting discussions and critical reading of the manuscript. This work was funded by grants from the  Agence Nationale pour la Recherche  ( ANR-14-CE11-0012 ,  ANR-10-IHUB-0002 ), from the  European Research Council  ( ERC CoG 771599 ), from the  Emergence program of the Ville de Paris , from the  "Coups d'Elan" prize of the Bettencourt-Schueller foundation , and the Schlumberger foundation for education and research. SB received PhD fellowships from the  IRTELIS program  of the CEA and from the  Fondation pour la Recherche Medicale  (grant  FDT20170437071 ). We thank the  Technological Core Facility (Plateforme Technologique de l'IRSL) of the Institut de Recherche Saint Louis, Université de Paris  for technical support.