dataesr/scientific-paragraphs-categorization huggingface dataset:
Project management As the analysis work progresses, data elements are treated at different phases of the critical path: these treatments are documented with associated metadata. This analytical work can be done phase by phase, but also iteratively or through phases' overlaps thanks to the versioning of intermediate analytic outputs, as described in Figure  1. A version then corresponds to a set of data elements that will evolve. For example, a Machine Learner can start working on a model with incomplete data, in order to test the first assumptions, without waiting for a complete dataset to be prepared by a Data Engineer, who is waiting for the last data extractions. In another situation, a business stakeholder may perceive a meaningful variable without knowing if this variable exists in a source.
This variable will then be added to the Databook as being perceived as useful, but not directly confirmed as treatable. These advancement tactics cannot be followed if only completed analytical treatments are documented. However, they are perfectly followed when metadata are generated as soon as the treatment anticipation occurs. These advances are synthesised by a status of each data element in terms of qualification. The most common statuses are to be started, in progress, included or excluded, and can be adjusted for multiple uses in the same project (for example, a source can be included for algorithm A and excluded from algorithm B). The statuses are essential for sticking to the design dynamic and represent the pivot between phases: they vary with the versioning (Databook is then versioned in parallel) and can be supplemented with workload estimates or difficulties anticipated.
Metadata structure synthesis In the Databook, metadata can be generated independently form the analytical critical path as it aims both the anticipation and the reduction of different uncertainties of the project. Each phase of the project represents a type of uncertainty and involves a specific skill to reduce it. This skill must also be involved in the anticipation. This documentation mechanism generates rich criteria guiding the projects decisions traced through the statuses. Therefore, this framework is a boundary object than can be successfully adapted to different points of view for all the skills' carriers engaged in the project and robust enough to maintain identity between them  (Star & Griesemer 1989). Thanks to this structure, skills' carriers participate using their documentation capacity in the main arbitrations leading to the construction of project results.
Given the diversity of possible metadata, Figure  4  reports a non-exhaustive list of the most commonly used criteria. This illustration represents the Databook modular core structure (vertical) enriched with typical metadata classified by type of uncertainty reduced for each phase of the project (horizontal). For each concrete project, this structure can be documented in the Module C, i. e. data inclusion/exclusion method. All metadata are then listed with associated modules and skills (usually, skills are represented by an individual skills' carrier) and for each criteria the status establishment method is mentioned. For instance, if the criteria 'personal data' is flagged as 'yes' for a variable, it will have to be flagged as 'excluded' in the status. This flexible mechanism linking the core structure and the metadata structure of the Databook results from an iterative confrontation between theorical and practical requirements.
Benefits perception The imagined prototype appeared in the field to be a complete, autonomous and dynamic object, logically linked to the stakeholders' documentation needs. Proposed as an Excel file with basic core and metadata structures, it was progressively filled up by the project teams on seven projects. The structure of the prototype appeared flexible enough to be adapted to meet the urgent needs and priorities of stakeholders, and if was successfully judged as operational. Besides its usability, the Databook prototype revealed its significant effectiveness in stimulating cooperation, enlightening the arbitrations made during the project, and guiding the appropriation of the results by the stakeholders. Different beneficiaries highlighted through qualitative feedback that the device was used for two main purposes: project efficiency and data documentation efficiency.
The project efficiency was improved through the facilitation of the mediation milestones (meaning shearing, progress visualisation, decisions traceability…), the knowledge capitalisation useful for further data projects and the identification of indirect usages requiring further analytical investigation. The impact on the project results quality was also highlighted by the users and by business decisionmakers: the traceability of all the analytical components of the algorithm and project decisions was perceived as a quality and solution auditability guarantee. Moreover, the recorded indirect usage ideas inspired not only further analytical iterations but also business offer and process evolution. Several data and business project team members also reported a change in posture: at the beginning of the project, they perceived filling in the Databook as an additional workload of little use, but as the project progressed, they realised that the device was indispensable and generated time savings at each iteration.
The documentation efficiency was appreciated not only by the team members but also stakeholders outside the project. For instance, data governance managers were very interested in semantic and other metadata generated during the project and the identification of referent data owners. Data protection officers kept and reused the personal data identification to control the discrimination drifts and the usage purposes. Financial managers were also very interested in the possibility to retrace the value generated by the usage and link it to the different data sources: this opened a new field for exploring patrimonial, finance and accounting concepts around data assets development. Finally, IT managers reused the Databook to size the technical resources required to explore, deploy and maintain other business applications.
Operational limitations The prototype also showed its weaknesses, the main one being its Excel format which is not very practical for several modules. Indeed, exploration report, functional results and usage roadmap modules had to be completed with more specific formats such as Data Visualisation tools or PowerPoint reports. The analytical results module was also completed outside the Excel file when it was too specific to the benchmarked algorithms. The project roadmap module was simplified as much as possible in order to be coupled with more appropriate project management formats. If the prototype was to evolve to a more sophisticated tool, it would be necessary to handle other types of formats for these modules or favour the compatibility or interoperability with other dedicated tools. The remaining modules have been adopted in Excel format and adapted to each project.
Module or metadata aborts were explained by the fact that time investment priorities were set at the small scale of each project, and rarely at the scale of a project portfolio or the company. They were also partly explained by organizational and human factors. Indeed, as a collaborative tool for a multi-skilled Data Science project team, the Databook has raised several organisational issues. When a Data Science projects remains restricted to a small team, for example with one Data Scientist and one business decision-maker, the Data Scientist is often expected to produce all the documentation alone. Moreover, documentation production can be refused by some team members who do not see its benefits for their own technical tasks. Finally, Data Science is still a young profession and stakeholders often lack acculturation and experience: the anticipation of uncertainties is clearly difficult and time-consuming without experienced skill-carriers.
Pilot evaluation Since the prototype first tests, the Databook prototype was freely accessible to several Data Science teams in a leading French Data Science company called Quinten. Its appropriation continued on Data Science projects between 2017 and 2020, i. e. more than a hundred of projects in health, perfume, insurance, banking, media and industry sectors. Several completed Databooks have been reused from one project to another, mainly for projects for one given company, using the same data sources or with similar usages and data objects. The pilot phase main qualitative feedback confirms the precedent advantages and limitations: it is summarised in the Appendices (Figure  13 ). This confrontation between theory and various fields reality still must be considered as potentially biased by the Data Science practice of one company.
Quinten is characterised by its own values, business offer and managerial practices. Most of the usages produced through the company's Artificial Intelligence projects are aimed at human users in highly regulated domains, thus transparency of the analytical work remains a priority. The following proposal is an unprecedented attempt to standardise the most useful documentation principles and functionalities. The Databook, as a flexible framework should then be tested in other contexts. 15/34 Nesvijevskaia, Anna (2021) DATABOOK: a standardised framework for dynamic documentation of algorithm design during Data Science projects, IASSIST Quarterly 45(2), pp. 1-34. DOI: https://doi. org/10. 29173/iq989.
The Databook as a standard documentation framework The Databook is founded on the principle of distinction between the realization of analytical outputs on the critical path of algorithm design and the production of the documentation. Both dynamics imply similar skills but involve them at different stages and with different purposes. The Databook as a documentation framework provides an opportunity to share the story of how data is transformed into useful information during a collaborative Data Science project. It can be used as a dynamic device for capitalising on knowledge, a material object that helps to gradually retrace the memory of the project and to give transparency to the resulting algorithmic model. The Databook guarantees and respects by design the FAIR principles by guiding the construction of Findable, Accessible, Interoperable and Reusable data and metadata, as far as the business context allows the sharing of sensible data.
Cross-skill data object qualification The Databook can be used by all project actors to qualify one given data object and determine together its further treatment. It is the most basic use, achievable independently for each Module from 1 to 6. This cross-skill use promotes convergence towards the most relevant result and stimulates the productivity of the project team. The convergence is accelerated by more convenient representations of data, such as graphs, explanations and other reports listed in Module C. The convergence is also improved by Module B, representing the collective arbitration procedure. In parallel, the dynamics of the convergence are monitored in Module A through the statuses. In this situation, the project in less piloted through iterative or overlapped phases than by the progress of the qualification of one given data object.
Skill capitalisation The Databook can also be used by one given skill carrier who wishes to gain experience on all the data objects qualified and processed during the project. In this case, his attention will only focus on the qualification criteria that confer his skills on modules 1 to 6. For example, the Databook can be used by a Strategic Manager to understand how the components of the algorithm are related to the business priorities, by a Data steward who is interested in the semantics of all elements processed during the project or by a Data Engineer to optimise the exploration pipeline. The capitalisation is also very interesting for project management. Indeed, the difficulties solved throughout the project constitute a rise in maturity: the estimation of the benefits and remaining uncertainties on the usages at the end of the project can lead to a broader roadmap than a technical deployment of the result.
Final algorithm understanding The Databook traces of all the data objects that compose the final algorithm. This trace is the documentation of the critical path: all the data elements notified as included are contained in the final versions of each intermediate output. This documentation is key for many purposes. First, it is a detailed specification for usage deployment. Then, it makes the algorithm auditable, including for external actors. And, finally, this traceability gives the possibility to propagate the value generated by the usage back on data sources: this inverse value cascade is hence an original tool for evaluating data assets from both patrimonial and operational views. All these purposes follow the same reading grid illustrated in Figure  7. For example, within the framework of an audit of the final algorithm, the investigation will consist in going back from the operational usage to the mathematical algorithm, then to the data which feeds this algorithm, then to a set of source data.
These source data will then point to key business concepts chosen in the construction of the algorithm. As the audit is interested only in used data elements included in the algorithm, his reading is focused on the diagonal in Figure  4  as soon as we consider that the final status of each type of data object is qualified by the skill carrier that produced the data object. If the auditor of the algorithm must go further to understand the design process, he may also be interested in project management metadata. This reading can be facilitated by the guide, especially by filtering the entire Databook only on elements with a status included or by zooming on more detailed project management metadata.
Conclusion The Databook emerges from the urgent documentation needs of data project stakeholders in the field and from interdisciplinary concepts inspiring the gap filling in the standard state-of-the-art Data Science process, CRISP_DM. Its structure is based on one main principle: in these exploratory algorithm design projects, each phase realization needs specific skills and all these skills are required to progressively adjust the entire process by producing dynamic documentation. Documentation is then the result of both anticipatory and informative qualification work, and the documentation process generates a faster convergence on the best project results. The Databook traces this dynamic and constitutes a boundary object for all the stakeholders. As the responsibilities and skills of a Data Scientist are still poorly and heterogeneously defined, Databook description sheds some light not only on the essential skills but also on their mobilisation mechanism.
As a prototype, it is decanted and confirmed as a very efficient Human-Data Mediation facilitator. It can still be improved in terms of ergonomics, but its simple and flexible core structure completed with free metadata structure remains compatible with classical tools and independent of the data project purpose and pace. Outside of projects, the Databook is useful for the development of a company's data assets and the governance of data quality. Besides these theorical and operational considerations, one of the main benefits of the Databook remains its contribution to algorithm transparency in business companies. This lack of transparency is too often reduced to the algorithm learning process, especially for the deep learning. However, an algorithm is much more than that: the Databook can reveal all the objects that constitute it from end to end, but also the human choices than have driven its progressive design.
Examples of Databook modules In this appendix, four illustrations of Databook modules present its typical applications in Artificial Intelligence projects. These illustrations are extracted from complete project Databooks in Excel format and anonymised. For confidentiality reasons, communication of a complete Databook prototype with qualified data objects is avoided. However, further real-world illustrations and practical details emerging from the testing phase in France can be found in Appendix 11 of the multiple-case study  (Nesvijevskaia, 2019, Appendix 11). The first illustration (see Figure  9  above) is extracted from a Databook adapted to the context of a French branch of leading insurance company which worked on the detection of contracts with noncompliance risks in order to optimise the control process.
This module aims the qualification of variables used for the detection model (Module 5). The different components of this module include (from left to right): -Technical information about the sources of variables needed by the Data Engineer: reception batch, name of the table and database join key for the table. -Semantics of the variables: code and meaning of the variable (if the name does not exist in the database, or does not make sense, it is manually added in the Databook). -Type of variable needed to choose the structuring methods (here, left unqualified). -Business priority of the exploration of each variable (exclusion of a variables by a business decision-maker, based on his perception of the compliance control process). -Flag of personal data to exclude (discussed with the DPO of the company).
-Status of the variable: the excluded variables are eliminated from the final algorithms. -"Test Forge": conclusion of a custom analytical qualification based on a mathematical method of elimination of variables with no signal or too much noise (realized by the Machine Learner). -Usage of the variable: function of the variable in the learning matrix, qualified by the Data Engineer. The columns colours represent the different skill-carriers that produced the qualification. The second illustration (see Figure  10  above) is extracted from a Databook of a health insurance churn project aiming the generation of two different algorithmic models (prescriptive profile generation and predictive scoring approach). In this project, more than 200 variables were collected and transformed into 500 new variables: these new variables are documented in Module 6.
The nomenclature of types of treatments have been defined specifically for the project context. -The status of each variable is here split into two columns, each one corresponding to one of the two algorithms (predictive and prescriptive) used in the following step. Each status is here binary, representing the inclusion (yes) or exclusion (no) of the variable for each algorithm. -The final columns correspond to two specific data treatments for the models: business rules association and mathematical quantiles generation. Each one is specifically documented in a complementary module. This module was produced entirely by the Data Scientist and controlled by the business expert. This ergonomic representation is usually completed by a planning as soon as actions are validated. It is based on the Module 6a of the Databook (Usage Roadmap): the module is a matrix structure in Excel.
The data were sampled at 1 kHz and recorded on a laptop computer. Lung function parameters were measured using spirometry (FEV1, FVC) with the Global Lung Initiative reference values  (Quanjer et al. , 2012)  and body plethysmography (TLC, RV) was performed using a Medisoft body box (MGC Diagnostics, MN, United States), in accordance with the American Thoracic Society -European Respiratory Society technical recommendations  (Graham et al. , 2019).
Statistical Analysis Data are presented as median (interquartile range: Q1, Q3). Friedman's one-way repeated-measures ANOVA on ranks with a Student-Newman-Keuls post hoc multiple comparisons procedure was used to test differences between study conditions: Baseline, NHF, and ERL. Pearson correlation was used to assess the relation between TLC, RV and corresponding BL inspiratory and expiratory CT volumes. A p < 0. 05 was considered as significant. All statistical analyses were performed with Sigmaplot V. 13 software (Systat, Berkshire, United Kingdom).
However, even with a larger caliber nasal prong and a snug fit, the generated positive pressure is on the order of 3 cmH 2 O at 25 L/min  (Pinkham and Tatkov, 2020). In this study, all patients had medium-sized nasal prongs during NHF therapy. Although upper airway pressure was not measured in this pilot study, it can be expected that the modest positive pressures generated by a flow rate of 25 L/min were insufficient to produce a measurable effect on small airway closure, gas trapping upon expiration, or lung recruitment. The reduction in respiratory rate observed in this study is in agreement with several previous studies that have described significant decreases in breathing rate and changes in the pattern of breathing during NHF  (Corley et al. , 2011; Nilius et al. , 2013). Our data show that this reduction in respiratory rate was not explained by an improvement in regional lung function in these stable COPD patients, a mechanism often proposed in the literature  (Ashraf-Kashani and Kumar, 2017; Pisani and Vega, 2017; Drake, 2018)  which has been attributed to PEP induced by NHF.
The study was approved by the Comité de Protection des Personnes, registration took place from Jan-2019 to Dec-2019. All adult participants provided written informed consent to participate in this study. Nord Ouest -approval: 2018-A00363-52. Trial registration: clinicaltrials. gov, NCT03821311. Registered 29 January 2019, clinicaltrials. gov/ct2/show/record/NCT03821311. Participant.
Acknowledgments This work was partially supported by the  European Research Council  (FP7/2007-2013) under contract LUCIFER no. 247115. We thank  M. Iannone  for his help in all the stages of the detector assembly,  A. Pelosi  for constructing the assembly line,  M. Guetti  for the assistance in the cryogenic operations,  R. Gaigher  for the mechanics of the calibration system,  M. Lindozzi  for the cryostat monitoring system,  M. Perego  for his invaluable help in many tasks, the mechanical workshop of LNGS ( E. Tatananni ,  A. Rotilio ,  A. Corsi , and  B. Romualdi ) for the continuous help in the overall set-up design. We acknowledge the  Dark Side Collaboration  for the use of the low-radon clean room. This work.
Similar to NSP1, we report the proportion of all non-structural antibodies makes a greater contribution of the SARS-CoV-2 response in children than in adults. The Principal Component Analysis of our dataset confirmed further the importance of antibodies to accessory proteins in characterising the pediatric samples. Whether these antibodies to accessory proteins play a role in the virus infectivity or in the pathogenesis of the disease and in the milder outcome of SARS-CoV-2 infection in children presents further questions for investigations. ORF3b, ORF7a and ORF6 proteins have been previously reported to play a role in cellular type-1 IFN down-regulation  [15] [16] [17]   32  , it is possible this contributes to their milder clinical presentation along with the diversified antibody landscape observed in our study.
Principal component analysis The LU for 14 antigens were log-scale transformed (the negative and zero values in the data set were replaced by 1) prior to PCA analysis. The missing values in the dataset were estimated by a probabilistic model  37. The probabilistic model is tolerant to amounts of missing values between 10% to 15% which is fit for our data. The missing data was estimated using pcaMethods (version 1. 80. 0)  38. The completed data were standardized (scaled) before input in standard PCA (using FactoMineR (version 2. 4) 39. The PCA results were extracted and visualized using factoextra (version 1. 0. 7)  40.