dataesr/scientific-paragraphs-categorization huggingface dataset:
Population The data used in this study were part of the Digi-NewB observational cohort 1 that aims to establish a physiological perinatal database. The Digi-NewB cohort prospectively included newborn infants hospitalized between 2016 and 2019 in the neonatal units of six university hospitals in France (Rennes, Angers, Nantes, Brest, Tours and Poitiers). In this study, we prospectively enrolled a subgroup of the Digi-NewB cohort, consisting of preterm infants admitted to our neonatal referral center from October 2016 to December 2018. Only preterm infants born before 32 weeks' gestation were included in our study because this preterm subgroup has a higher risk of developing cerebral complications related to preterm birth, such as leukomalacia and ventricular hemorrhage. Thus, based on the Digi-NewB protocol design, a brain MRI scan was systematically performed at term-equivalent age for this sub-group only.
Magnetic Resonance Imaging Acquisition All MRI scans were performed on two clinical devices, both Siemens 1. 5T Magnetom Aera scanners (Siemens, Erlangen, Germany). Examinations were performed without sedation during the infants' natural sleep. The MRI protocol included morphological, diffusion-weighted, and ASL cerebral perfusion sequences. Morphological sequences were 3D T1-weighted images acquired in a sagittal plane. Diffusion-weighted sequences 1 https://clinicaltrials. gov/ct2/show/NCT02863978 were single-shot EPI (echo planar imaging) spin-echo sequences. The diffusion acquisition consisted of 12 gradient direction images at b = 1,000 s/mm 2  and one b0 image. The two EPI diffusion sequences were acquired with opposite phase-encoding directions: we acquired first a conventional diffusion-weighted sequence combining the 12 b = 1,000 s/mm 2 images and a b0 image with an antero-posterior phase-encoding direction, then we acquired a second b0 image with a posteroanterior phaseencoding direction.
Data Processing We adapted our previously developed pipeline  (Proisy et al. , 2019) , initially designed for neonates, to handle our preterm morphological and perfusion data. As for the diffusion data, we implemented a specific in-house pipeline based on the Anima software 2. These tools were used to quantify cerebral volumes, estimate scalar diffusion parameters and compute average CBF values over a set of regions of interest (ROIs). The anatomical processing of our neonate images included brain extraction, tissue segmentation and extraction of ROIs. Our ROIs were derived from a custom anatomical atlas that we built from ALBERTs data  (Gousias et al. , 2012). The processing of diffusion images led to quantitative scalar diffusion parameters maps for each subject. The processing of perfusion ASL images led to a quantitative CBF map for each subject.
Brain extraction For each subject, the first step of anatomical processing was brain extraction. The custom atlas built from ALBERTs data was registered onto our subject via an affine transformation followed by a diffeomorphism transformation to perform brain extraction 4 Aavailable at https://github. com/Inria-Visages/Anima-Scripts-Public -RRID:SCR_017017 using the whole-brain mask. Henceforth, we will only consider the extracted brain of our subjects (Figure  2A ).
To perform MRI quantitative parameters analysis, we calculated our different ROIs: the overall brain (C), the overall GM (D), and WM (E), the eight anatomical regions (F). Panels (G,H) correspond to the regional GM ROIs and the regional WM ROIs, respectively. volumes and corpus callosum volume were also determined using the initial ALBERTs segmentation, to perform the morphological and diffusion data analyses, respectively. For each subject, we used the same registration process as described in our previous study  (Proisy et al. , 2019)  to obtain the corresponding individual regional segmentations for each preterm infant.
Diffusion Data Processing Diffusion data processing was performed using Anima 6. Data were prepared to reduce Eddy Current and distortion artifacts which impair scalar diffusion parameter quantification accuracy. To correct distortion artifacts, we used the two acquired EPI sequences with opposite phase-encoding directions: the first and second b0 images were respectively acquired with anteroposterior phase-encoding direction and with posteroanterior phase-encoding direction. The EPI distortion correction was performed using a block matching method that we developed previously  (Hédouin et al. , 2017). We then performed rigid registration to correct inter-volume motion. For each subject, we next estimated diffusion tensor mapping and extracted the four scalar parameters (FA, MD, AD, and RD).
Arterial Spin Labeling Perfusion Data Processing Perfusion data processing was performed using an in-house pipeline adapted to our preterm population, running on MATLAB software (version R2018b) and the SPM toolbox (version 8). Unlike adults, neonates experience huge variations in hematocrit levels, and T1 blood values are directly related to hematocrit levels. Therefore, the preprocessing pipeline was adapted to replace the set T1 blood value usually used for the adult population with a specific T1 value calculated for each subject to improve the accuracy of MRI-derived perfusion measurements  (Hales et al. , 2016). We also used the GM/WM tissue segmentation maps that we previously reconstructed from MANTiS instead of those used in our previous study  (Proisy et al. , 2019). As MANTiS was specifically developed for neonates, its tissue maps were more accurate for our preterm population.
Effects of explanatory variables on quantitative imaging parameters To assess the potential linear effects of explanatory variables on the quantitative parameters extracted from the brain MRI (absolute and relative volumes, diffusion parameters, and CBF), we built multiple linear regression models. Explanatory variables included age on MRI, sex, and the MRI scanner used to assess potential effects on quantitative MRI parameters. We also included, as explanatory variables, all demographics data in which the distribution between extremely and very preterm infants was significantly different in the global population and in the subgroups for diffusion and perfusion analyses, respectively. • Model used for morphometric analysis: Volume = β 0 + β 1 × Birth weight + β 2 × Age at MRI + β 3 × sex + β 4 scanner + β5 × Maternal high blood pressure + β6 × Chorioamnionitis + β7 × Postnatal steroids + β8 × Neonatal infection + β9 × Bronchopulmonary dysplasia + β10 × Patent ductus arteriosus + ε • Model used for diffusion data analysis: Scalar diffusion parameters = β 0 + β 1 × Birth weight + β 2 × Age at MRI + β 3 × Sex + β 4 × Scanner + β 5 × Maternal high blood pressure + β 6 × Maternofetal infection + β 7 × Chorioamnionitis + β 8 × Postnatal steroids + β 9 × Neonatal infection + β 10 × Bronchopulmonary dysplasia + β 11 × Patent ductus arteriosus + ε • Model used for ASL perfusion data analysis: CBF = β 0 + β 1 × Birth weight + β 2 × Age at MRI + β 3 × Sex + β 4 × Scanner + β 5 × Maternal high blood pressure + β 6 × Maternofetal infection + β 7 × Postnatal steroids + β 8 × Neonatal infection + β 9 × Bronchopulmonary dysplasia + β 10 × Patent ductus arteriosus + β 11 × WM lesions + ε Frontiers in Neuroscience | www.
Population We enrolled 34 preterm infants in the study: 13 extremely preterm infants born before 28 weeks' gestation and 21 very preterm infants born between 28 and 32 weeks' gestation. Each included preterm infant underwent morphological sequences. Table  2  summarizes group characteristics for the morphological analysis. Thirty-one of the 34 infants included underwent diffusionweighted sequences. Of them, eight were excluded by the quality check due to motion artifacts and a further two infants were excluded from data analysis because reliable quantification of the scalar diffusion parameters could not be undertaken due to major distortions remaining after data processing. Finally, statistical analysis was performed on 21 subjects including 10 extremely preterm and 11 very preterm infants.
FUNDING Results incorporated in this publication received funding from the  European Union 's  Horizon 2020 Research and Innovation Program  under grant agreement no. 689260  ( Digi-NewB  project). This work was supported by the  Société Française de Radiologie, Paris, France  ( 2018 Research Grant ), and the  Agence Nationale de la Recherche, France  (Project:  ANR-15-CE23-009 , MAIA, Program: Appel à projets génériques 2015).
DATA AVAILABILITY STATEMENT The datasets presented in this article are not available in open access due to privacy restrictions. Indeed, the datasets consist in MRI scans acquired in preterm infants, and we did not obtain parental consent to make them publicly available. However, they consented for access to be granted to the journal reviewers to pseudonymized collected data so that they be examined and that the conclusions of the article be evaluated before its publication. Requests to access the datasets should be directed to MD, marine. dubois@chu-rennes. fr.
Introduction The motivation of GREW is to have an effective tool to design rule-based transformations of linguistic structures. When designing GREW, our goal was to be able to manipulate at least syntactic and semantic representations of natural language (one of the first application of GREW was the modeling of a syntax-semantics interface). In a naive view, we can say that syntactic structures are trees and semantic ones are graphs. Then, if we want to work with both kinds of structures in a common framework, we can use the fact that a tree can be considered as a graph and hence consider that all structures are graphs. 1 ow, if we consider all structures as graphs, how to describe rule-based transformation on these structures? In practice, these transformations can of course be computed with some programs but when it becomes complex and implies many rules, it is difficult to maintain and to debug.
Graphs and graph rewriting The book  (Bonfante et al. , 2018)  gives a complete description of the graphs and graph rewriting system used in GREW. We give here a short description on the main aspects. In our framework, a graph is defined by a set of nodes labelled by non-recursive feature structure and a set of labelled edges (note that edges encode relations and hence, we do not consider multiple edges with the same label on the same pair of nodes). In addition to the usual graph mathematical definition of graphs, we also add a notion of order on nodes. For each graph, a sub-part of the nodes are ordered. The subset of ordered nodes can contains all the nodes (for instance in dependency structures like in Figure  1 ); it can be empty (for instance in semantic graphs like AMR structures shown in Section 4.
To iterate the application of a rule, one has to use more complex strategies. The strategy Onf(noun) 2  iterates the application of the strategy noun on the input graph. With the same input graph (of Figure  1 ), the application of GREW with the strategy Onf(noun) produces a graph where the two nouns have the new tag NOUN. Note that Onf(. ) always outputs exactly one graph. With the strategy Onf(prep) for instance, the rewriting process will output one graph, identical to the input graph, obtained after 0 application of the prep rule. In previous examples, we considered rules separately, but in a global transformation all the previous rules must be used in the same global transformation. A solution to use several rules in the The package name POS can be used as a strategy name for rewriting.
Depedit can be used as a separate tool or as a Python library. It is specifically designed to manipulate only dependency trees. Contrary to GREW, it does not proposed a notion of strategies and does not handle not confluent rewriting processing. Moreover, the notion of rules is also more restricted: there are no NAP and it is not possible to express additional contraints on morphological features like the one we used in Section 4. 1: M. Number <> N. Number.
Tools for corpora querying A large number of online query tools are available online. Some of them have a more restrictive query language like SETS 10  or Kontext 11. In these two tool, there is no notion of NAP and the kind of contraints that can be expressed is limited. The PML Tree Query 12  and INESS 13  offers a query language with the same expressive power as the one proposed in GREW. An advantage of GREW is that it is interfaced in the larger annotation tool ARBORATORGREW 14. With ARBORATOR-GREW, the user may query on his own treebank and then have access to a manual editing mode on the query output or to automatic updating through GREW rules.
Conclusion GREW was used in many tasks of corpus conversion. It is used for instance for conversion between UD and SUD  (Gerdes et al. , 2018 (Gerdes et al. , , 2019)) : all UD corpora are converted into SUD with it. GREW is implemented in Ocaml and is quite efficient: for instance the conversion of UD 2. 7 (1. 48M sentences, 26. 5M tokens) into SUD uses 100 rules and takes 5,500 seconds on a labtop (around 267 graphs rewritten by second). GREW is available as a command line program or through a Python library. Installation proce-dures and usage documentation are given on the GREW website: https://grew. fr. A web-based interface for the usage of the rewriting part of the software will be provided soon. In this article, examples are given on dependency syntax and on semantic representations like AMR.
Introduction Quality requirements (QRs) are different from functional requirements (FRs) in the sense that they describe non-functional aspects (e. g. , maintainability, reliability, performance, security) of a system  (Wagner 2013; Wiegers and Beatty 2013). QRs are important because even if the promised functionality is delivered, the system will not be regarded as good by users if it does not have, for example, sufficient performance or usability. Agile software development (ASD) is aimed at continuously delivering valuable software to customers. The quality aspects of software are integral to fulfilling customer needs and delivering the promised value. Moreover, considering QRs too late in the development process produces bottlenecks and necessitates further work  (Schön et al. 2017). It has been found that adopting agile methods often leads to neglecting QRs when the focus is mostly on delivering working functionality to the customer as quickly as possible  (Cao and Ramesh 2008; Ramesh et al.
By differences in context, we mean differences in the characteristics of the setting in which software development occurs, such as company size, organizational model, or type of customers. These characteristics are listed as contextual elements in Table  1. By QR management strategy, we mean a plan containing different practices to handle QRs; by management practices, we mean the activities that are carried out to handle QRs in order to realize the plan (Merriam-Webster 2019). The following three research questions were formulated to determine why practitioners manage QRs as they do, what challenges they face in doing so, and how the contextual elements of the companies are connected with these practices and challenges: & RQ1: What strategies and practices are used to manage QRs in ASD? & RQ2: What challenges are associated with the QR management strategies and practices in ASD? & RQ3: How does context affect QR management strategies, practices, and challenges in ASD? In this paper, we report on the findings from 36 interviews we conducted with practitioners from four ASD companies.
In a more recent empirical study,  Alsaqaf et al. (2019)  explored the challenges of engineering QRs in ASD. They revealed the challenges practitioners face when engineering QRs, the mechanisms behind these challenges, and the practices applied to mitigate them. Their research questions were very similar to ours; their focus was on largescale distributed agile projects in the Netherlands. One of our studied companies also applies distributed agile development in large-scale systems. This gave us the opportunity to compare our findings to those of Alsaqaf et al. Additionally, we included small-to-medium size enterprises (SMEs) in our study, which allowed us to compare practices and challenges at different scales of software development. Alsaqaf et al. (2019)  also discussed the possibility of traceability between QR management challenges and context.
What is relevant for our study is that  Kalenda et al. (2018)  determined, from the literature as well as from their empirical results, that when scaling ASD, there is the risk of a loss of quality in code and of an accumulation of technical debt shortly after the transition to scaled agile processes, if the processes are not managed properly. Additionally,  Kasauli et al. (2017)  also studied requirements engineering challenges in large-scale ASD. They also found that communication and knowledge management are important in such development, and they additionally emphasized the importance of bridging the gap between customers and developers. In addition to the mentioned studies on QRs in ASD, we found in our own recent systematic mapping study (SMS) on QR management in agile and rapid software development some proposals for QR management  (Behutiye et al.
Company C Company C is a global company with several business lines in which development is distributed to many locations across the globe. Several coordinated agile teams develop large systems with complex dependencies. Thus, we can consider development in Company C as very large-scale ASD. Due to the size of the company, there is a need for some hierarchy in the decision making and coordination of development done by several teams. Thus, we classify the company as an organization with a hierarchical organization model in the context table  (Table 1 ). All the different business lines have a global process description to follow; however, their practices are not identical. Some business lines focus more on software products; while in others, hardware is tightly coupled with the software. The number of employees also varies greatly between business lines.
Data collection procedure Data was collected incrementally through semi-structured interviews by the first two authors. The third author participated in one interview to ensure that the interviews flowed well and for the purpose of researcher triangulation. Interviews were conducted in two rounds. The first round consisted of two sets of interviews. The first set, the initial interviews, were conducted with 13 interviewees in 12 interviews (one interview had two interviewees, see Table  2  in Section 3. 2. 1): three interviewees from Company A, four from Company B, four from Company C, and two from Company D. Based on the initial analysis of these interviews, we identified the need to have complementary interviews at Company C to get a more detailed view of their QR management practices. Company C is much larger than the other companies, and some of the interviewees came from different business lines with slightly different practices.
The purpose of this question was to understand how the interviewees perceived QRs and to make sure they understood what we meant by QRs. The rest of the interview questions were defined and structured around different activities of RE according to CMMI for development, version 1. 3 (CMMI Product Team 2010). We acknowledge that there are varying views on whether CMMI and ASD work together; however, we used CMMI as a comprehensive checklist, not as a maturity or capability model. With the help of CMMI, we sought to ensure that we covered all the different aspects of RE. We asked questions related to how QRs are elicited, how they are prioritized, how they are documented and validated, and so on. In addition, questions were asked about whether the interviewees saw any connection between QRs and other areas related to software development, such as planning and risk management.
Analysis procedure The coding of interview transcripts was completed with NVivo qualitative data analysis software (NVivo 2018). The challenges and practices were coded in a deductive  (Miles and Huberman 1994 ) manner with a start scheme that was devised a priori by two researchers according to the main topics in the interview questions (ways of working, QR understanding, QR elicitation, QR communication, QR documentation, specifying QRs, QR prioritization, QR validation, and related challenges). The concrete practices and challenges emerged during the analysis of the data. Fig. 2  shows a snapshot of coding in NVivo. On the left-hand side, next to the blue bubbles, are the codes of which elicitation is highlighted, and on the right-hand side there are excerpts of interviews coded as relevant for elicitation of QRs.
Identifying the Fig. 2  NVivo used in coding interview transcripts according to themes in interview questions connection of the practices and challenges to context was achieved in an inductive way through thematic analysis  (Cruzes and Dybå 2011). Contextual elements were identified from the interviews and the pre-questionnaire (the contextual elements are presented in Table  1 ). Figure  3  shows an example of how we coded parts of interviews related to practices and challenges in the elicitation and analysis of QRs. We coded the practices as shown by text with blue underlining in the yellow boxes and matched them to the activities discussed. Fig. 3  also shows the "together with the client" and "limited access to user scenarios" codes with red underlining. As these were both related to the same concept of access or limited access to users, we classified them under the same theme.
Theoretical model This section presents the results and analysis from our multiple case study in the form of a theoretical model of QR management challenges and practices in ASD. The model was designed to systemize the findings obtained from the present study. For this purpose, we used the methodology proposed by  Sjøberg et al. (2008) , which was developed to generate theories that can explain or predict phenomena occurring in software engineering. Our model can be used as the basis for explaining the relationship between contextual elements and QR management challenges, and it can thus be used to predict the challenges that companies can face in certain contexts. Further research may consolidate the findings of the present study, yield new findings, or refute some of our propositions. According to  Sjøberg et al.
The arrows in Fig. 4  represent propositions and will be presented in Section 4. 4. 2. & Software system: This class represents the scope of the study. In our case, we are interested in a specific type of system, i. e. , software systems developed using ASD (agile-developed software system). A specific agile-developed software system should satisfy certain QRs that correspond to a QR type. The software system is involved in a software product (e. g. , an embedded system, a software tool) that has a certain type (e. g. , large with complex dependencies), a maturity level (e. g. , a long-lived mature product, a new product) and a customization degree. & Technology: This class represents the focus of the study. Following  Sjøberg et al. (2008) , this archetype class must be interpreted in a broad sense, and the focus of the study can range from a process model, method, or technique to a tool or language.