dataesr/scientific-paragraphs-categorization huggingface dataset:
Genetic mapping of disease loci At the beginning of this study, genetic mapping of disease loci was performed in 15 multiplex and/or consanguineous families using Affymetrix GeneChip Human Mapping 250K NspI microarray. Multipoint linkage analysis of SNP data was performed using the Alohomora 4 and Merlin software. 5 In these families, genetic mapping was followed by either Sanger sequencing when a highly candidate gene was located within one of the disease loci (n=7) or by WES (n=8, figure  1 ).
Bioinformatics analysis Reads were aligned to the human reference genome sequence (UCSC hg19, NCBI build 37. 3) via the BWA programme. 7 Variants were selected using the SAMtools 8 and then annotated using Annovar softwares. 9 Variants in coding regions (including nonsynonymous and nonsense variants), intron-exon junctions (≤10 bp) or short coding insertions or deletions were selected when the minor allele frequency was less or equal to 0. 005 (using 1000G, ExAC, TopMed and GnomAD). Prediction of pathogenicity of missense variants was performed using Polyphen-2 (with score ≥0. 5 10 ) or Sift softwares (with score ≤0. 05 11 ), splice variants using Human splicing finder  12  and Clinvar (NCBI).
CLINICAL DATA A total of 315 AMC families were included in this study from 2011 to 2019 (figures 1 and 2 and online supplemental table S1). AMC was sporadic in 226 families and familial (with at least two affected individuals) in 89 families (figure  2 ). In patients with sporadic AMC (n=226), 45 of them were born to consanguineous parents, 151 to non-consanguineous parents and unknown in 30 families. In familial AMC (n=89), parents were consanguineous in 30 families, non-consanguineous in 54 and unknown in 5 (figure  2 ). AMC was detected during pregnancy in 251 out of 315 families (80%), after birth in 62 families (20%) and not reported in 2 families (online supplemental table S1). During pregnancy, AMC was detected through ultrasound examination of the first trimester in 86 families (34%), second trimester in 103 families (41%) and third trimester in 27 families (11%).
Developmental defects parents. When a highly candidate AMC gene was identified within a disease locus, direct Sanger sequencing of the gene was performed. Otherwise, WES was performed in the index patient. ] [15] [16] [17] [18]  Then, targeted exome sequencing of genes known to be frequently involved in AMC or new candidate genes was performed in 210 index patients (figure  1 ). The first panel included 67 genes and then moved to 84. The genetic cause was identified in only 68 affected individuals (32%) suggesting that other genes responsible for syndromic or non-syndromic AMC were not included in the panels, or novel genes not yet identified as responsible for AMC. In the patients with undiagnosed AMC, the phenotype was first re-evaluated based on the clinical data or muscle biopsy and led to other investigations including CMA, SMN1, MTM1 (MIM: 300415) or NIPBL (MIM: 608667) analysis which allowed the identification of the disease causing gene defect in four patients (see online supplemental table  S1 ).
Acknowledgements We thank all families for partaking in this study. We thank the  French Society of Foetal Pathology (SoFFoet)  for referring clinical data and tissues of fetal patients. We thank  D. Gaillard  ( CHU de Reims ),  F. Girard  ( CHU de Strasbourg ),  F. Giuliano  ( CHU de Nice ),  M. Lebrun  ( CHU de Saint Etienne ),  A. Masurel  ( CHU de Dijon ),  M. Mathieu  ( CHR Amiens ),  N. Monnier  ( CHU Grenoble ),  M. J. Perez  ( CHRU de Montpellier ) and  J. Roume  ( CH Poissy ) for contribution and/or analysis of patient samples.
Mining of public databases and phylogenetic reconstructions suggest an ancient association of oomycetes and giant viruses of amoeba, including faustoviruses, African swine fever virus (ASFV) and pandoraviruses, and that a single viral insertion occurred early in the evolutionary history of oomycetes prior to the Phytophthora-Pythium radiation, estimated at ∼80 million years ago. Functional annotation reveals that the viral insertions are located in a gene sparse region of the Phytophthora genome, characterized by a plethora of transposable elements (TEs), effectors and other genes potentially involved in virulence. Transcription of viral genes was investigated through analysis of RNA-Seq data and qPCR experiments. We show that most viral genes are not expressed, and that a variety of mechanisms, including deletions, TEs insertions and RNA interference may contribute to transcriptional repression.
Sequence Manipulation and Phylogenetic Analyses The P. parasitica strain INRA-310 infected region was previously described on a single contig under the accession KI669605. 1  (Sharma et al. , 2014). This contig, designed contig 2. 45, was used for subsequent searches. Predicted genes were ascribed to Phytophthora or GV genomes by best hit Blastp analyses against NR at GenBank, excluding Phytophthora sequences from the dataset, and by Blastp and tBlastn searches against the homemade database containing the GV genomes and their corresponding predicted proteins. Viral candidate sequences were retrieved in the oomycete genomes publicly available after tBlastn searches in the whole-genome contig subset of GenBank using default parameters. Conserved domains and putative functions of predicted proteins were searched using Blastp analyses on various databases, including PFAM  (Mistry et al.
, 2020) , Interpro  (Blum et al. , 2020) , SMART  (Letunic et al. , 2020) , and Superfamily  (Pandurangan et al. , 2019). Transposable elements (TEs) were searched by BlastN searches against the RepBase database using the Censor tool  (Bao et al. , 2015). A tRNA search was conducted using both tRNAscan-SE  (Lowe and Chan, 2016)  and Aragorn  (Laslett and Canback, 2004). Sequences were aligned by using MUSCLE software  (Edgar, 2004). Date of viral integration was estimated using the TimeTree tool  (Kumar et al. , 2017) , based on different molecular clock methods  (Matari and Blair, 2014). Phylogenetic trees were built by using the maximum likelihood method, which was carried out with the FastTree program  (Price et al. , 2010) , with 1000 bootstrap replications, using JTT template substitution (standard default).
Expression Analyses Expression of viral genes was assessed according two strategies. First, we estimated the total amount of reads matching each ORF of the contig in Blastn searches against RNA-Seq data available at GenBank (Accessions SRX1124837-SRX1124840, SRX1124842-SRX1124845, SRX1124847-SRX1124868, SRX27 27839-SRX2727852, SRX4902085-SRX4902107). In parallel, genes of interest were analyzed by qRT-PCR. For the RT-PCR, genomic DNA was extracted from 10 day-old cultures conducted on V8 medium as previously described  (Panabières and Le Berre, 1999). RNA was extracted by using the RNeasy Mini Kit (QIAGEN, Germany). After the addition of RNAse, the DNA was digested by TURBO DNase (Invitrogen Thermo Fisher Scientific, Lithuania) at 37 • C, three times in 30 min. Real-time RT-PCR was performed using two-step, one-step experiments.
All assays were performed in triplicate and included negative controls (DNA/RNA-free PCR mix). A gene of P. parasitica strain INRA 310 encoding for the 40S ribosomal protein S3A (WS21, Genbank accession number: XM_008905737. 1), known to be transcribed in all tested conditions, was used as an internal control  (Yan and Liou, 2006).
Sanger Sequencing The PCR amplicon generated from purified cDNA of P. parasitica was sequenced on the Applied Biosystems 3130xl Genetic Analyzer (Thermo Fisher Scientific, France) using the BigDye Terminator DNA Sequencing Kit (Perkin-Elmer) according to the manufacturer's instructions. The sequence was assembled using ChromasPro 2. 0. 0 software and compared to the NCBI database by Blastn analysis.
Integration of GV Sequences in Oomycete Genomes In the ∼550-kb contig from P. parasitica INRA-310 (contig 2. 45, GenBank accession KI669605) 17 predicted genes matched with GV. When excluding the hits from Phytophthora, a total of 12 had GV hits as the best match  (Sharma et al. , 2014). This finding predated the achievement of several genome sequencing projects and the availability of an increasing number of complete genomes of oomycetes, including tens of Phytophthora genomes. Similarly, an invaluable number of studies on GV was conducted that totally modified our view of the viral world, expanding the phylogenetic tree of GV to thousands of members  (Schulz et al. , 2020). Therefore, we first performed a new gene calling step, prior to conducting sequential best Blast hit searches against public databases, excluding P.
parasitica, then Phytophthora, and finally oomycetes from the datasets. Gene calling revealed 7 additional ORFs of 180-1,005 nucleotides (60-335 codons) that were added to the ORFs already predicted in the contig, so that a total of 126 putative proteins were used as queries in the best Blast hit search, among which 15 appeared to better match GV sequences (Supplementary Table  2 ). These sequences mostly corresponded to partial protein sequences when compared to the best viral homologs, and notably encoded RNA polymerases I and II, the major capsid protein, and a DEAD helicase (Supplementary Table  2 ). We noted that the RNA polymerase II was represented by several ORFs, indicating a likely duplication or several transfer events (Supplementary Figure  1 ). The other viral sequences did not display any domain enabling functional annotation.
No tRNA or ribosomal RNA genes were found across this contig. Some viral candidate sequences were found to best match with oomycete sequences from Phytophthora cactorum or even Pythium oligandrum, whose genomes were released in public databases after the publication of the initial work  (Armitage et al. , 2018; Yang et al. , 2018; Faure et al. , 2020). This suggests a possible viral invasion of oomycete genomes having occurred before the Phytophthora-Pythium speciation. Alternatively, this might indicate that invasion events by GV occurred several times during oomycete evolution. Sequential best Blast hit searches did not reveal evidence of viral signatures that would be shared by all oomycetes. The viral candidates were therefore searched in oomycete genomes through tBlastn searches against the contig sequences hosted at the NCBI GenBank whole genome shotgun database.
The Viral Locus Retained a Discrete Transcriptional Activity To evaluate the potential impact of the viral sequences on P. parasitica biology, we intended to assess the expression of viral candidates in a variety of physiological situations. To this end, we first collected RNA-Seq data generated on P. parasitica that are publicly available. We mined libraries prepared from various pre-infection stages of P. parasitica, including libraries enriched in small RNAs. Overall, the contig was transcriptionally silent, although ∼20 ORFs organized into 10 short loci were expressed to various extent, as estimated by the total number of reads obtained in Blastn searches (Supplementary Table  3 ). Genes displaying some expression levels encoded CRNs, as well as proteases and hypothetical proteins, and a predicted tyrosine recombinase (PPTG_14945), possibly reflecting the activity of a TE.
DATA AVAILABILITY STATEMENT The datasets presented in this study can be found in online repositories. The names of the repository/repositories and accession number(s) can be found below: NCBI GenBank, accession no: NW_008634126. 1, SRX1124837-SRX1124840, SRX1124842-SRX1124845, SRX1124847-SRX1124868, SRX27, 27839-SRX2727852, and SRX4902085-SRX4902107.
The ENACT project indicates that there are many feature and functionality gaps in both the applications and enablers present in this environment and aims to close some of the significant gaps. The ENACT project has been funded by the European Commission under its H2020 program. The project consortium consists of twelve member organisations spread across the EU as a whole. The funding has allowed the research and development of three toolkits covering trustworthiness, continuous development and agile operation. The emphasis of the toolkits is to build applications quickly and maintain those applications as the application target's circumstances change. The development of the toolkits has benefitted from the research excellence that has pervaded all stages of the project. Proof of concept use cases will support the development and testing of the toolkits.
Privacy-Related Risk Knowledge Base In this section we briefly describe the knowledge base created in ENACT and PDP4E projects. This knowledge base is the baseline for the recommendations provided in the risk management enabler, as well as the main database for the Automated Vulnerability Detector described in Section 3. 2. The proposed knowledge base is founded on the LINDDUN methodology to frame privacy-related threats, as well as on STRIDE to cover security issues. We use the threat trees proposed in LINDDUN as the starting point to populate our knowledge base. We connect the content of our knowledge base to public content in the Common Weaknesses Enumeration (CWE) list. Besides, we also leverage information from the Common Attack Pattern Enumeration and Classification (CAPEC) dictionary, through their link from CWE.
For instance, "Information disclosure of a process" may be labelled with "Confidentiality" label or vulnerability named "Data is not encrypted" may be labelled as "Encryption". The actual mapping between cases and labels has been implemented in the PDP4E project. The second link corresponds to a manual exercise to connect the STRIDE vulnerabilities with CWE items. When the link is established, our enabler uses the url stored 4. www. enforcementtracker. com in the database for each CWE item and scans online information to automatically detect mitigation actions and add them as controls in the Control relation. We also follow links to the CAPEC database related to attack patterns related with that vulnerability and store the information in the Threat relation and potential connected mitigation actions in the Control relation.
Practical Implementation Aspects All the contributions presented in this chapter have been implemented in the latest version of the ENACT Risk Management enabler in collaboration with the PDP4E project. In particular, the enabler includes the extended version of the OWASP Risk Rating methodology presented in Section 3. 3. Specifically, the questions suggested for impact analysis have been added to the enabler. Besides, the mapping between LINDDUN threat categories and GDPR data processing principles and DS rights have been embedded in the enabler. The enabler has a GDPRbased dashboard that allows to understand the overall level of risk for each principle and DS rights, based on the status of each risk detected in the enabler. Finally, the knowledge base described in 3. 5 has been also embedded in the enabler, this enables not only the automated detection of vulnerabilities, but also benefiting from open databases such as CWE or CAPEC.
The modification actions (CRUD -create, read, update, delete) are implemented on top of standard APIs and libraries. The model itself is spread across the following three repositories. MongoDB database is installed locally, along with a DivEnact instance, and serves to store information about templates and variants unique to each application system. There is a centralised repository in CouchDB for storing various ENACT artefacts, including deployment models used by DivEnact. In particular, the CouchDB database stores previously designed GENESIS deployment models that are to be enacted on lowlevel IoT devices as part of the "last mile deployment". Azure IoT Hub Cloud portal keeps track of registered devices in the fleet and existing deployments. The information obtained from the hub reflects the current state of all the devices through continuously updated digital twins, as well as deployments applied to these devices (i.
e. , software modules currently deployed and running on each device). The DivEnact graphical user interface remains the main point of interaction with the user. The main functionality is structured across several functions, i. e. , the editing and maintenance of templates, variants, deployment models, devices and the assignment. The back end of the DivEnact tool is implemented in Node. js. It receives RESTful requests originating from the user's graphical interface and manipulates the data model accordingly. It also interacts with the Azure IoT Hub API to update some information about the devices in the fleet and trigger deployments. The back end also implements the actual diversification functionality (described in the next subsections) by receiving the input model from the user and passing it to the underlying Python script.
Programming faults are also not dealt with. Because GENESIS is oblivious to the inner working of the components it deploys, all replicas are similar and fail in a similar manner. For instance, if a defect in the code lead to a fault of one replica (say because of invalid user input), then all replicas will exhibit this fault. Only diversification techniques  [5]  could help having replicas whose behaviours differ from one another, and that exhibit different failure profiles. Improving availability from a pure deployment perspective, as GENESIS provides, is bound to stateless components that can be easily replicated. Replicating a component that persists state requires some modification of its code. Either we separate its state from its application logic (using a local database, for instance) and we ensure that all replica can access this single data source.
Alternatively, each replicas also have its own local copy but we must now define a strategy to ensure the correct and timely synchronization of the multiple copies of the state, and possible conflicts. Modern database engines offer such mechanisms and would need to be integrated with GeneSIS in an ad-hoc manner. Edge platforms however often only pass data further on to Cloud services, and are thus likely to be stateless, or can simply leverage a local database as a cache, a strategy that the GeneSIS availability mechanisms handles. Finally, on an Edge platform there are resources that cannot be replicated and that would require further investigation. A serial link for instance cannot be shared between replicas and, in this case, dedicated, application-specific logic must be in place to ensure consistent behaviour between all the replicas.
This means that the DevOps team can quickly develop the business logic of the SIS based on the SMOOL platform, including necessary security mechanisms. DevOps teams can define SMOOL clients that leverage built-in security properties to check and enforce security concepts on messages requiring security controls. The SMOOL's default security enforcement can be done with the SMOOL clients built-in security metadata checker to verify messages exchanged 11. https://github. com/TelluIoT/ThingML among them. In cases where a deeper control is needed, a specialised security metadata checker can be included in SMOOL clients, with additional privileges to watch and process the security metadata in messages exchanged, in the same way it is done with business logic concepts such as sensed temperature or gas values.
This provides a fine-grained control on critical messages that may have a significant security impact in the IoT system such as orders to actuators. More precisely, a client code can conduct security checks based on policies to be fulfilled by ontology concepts by using any of these options: (i) the default security metadata checker (for minimal configuration), (ii) a custom security metadata checker implemented in the development phase (for full control of security), and (iii) a custom security metadata checker for integration with external security services. Whatever security options, GENESIS provides support for easily configuring the security mechanisms and how they should be integrated and deployed with the SIS. Thanks to ThingML, GENESIS provides advanced support for the three options.
We elaborate more on the two kinds of DevSecOps support in the following paragraphs. First, GENESIS supports for evolving SIS with updated security mechanisms according to a new development cycle. In this line of adaptation, the SIS in operation is evolving with new business logic components or even new physical devices being added resulting in the need for enhancing security mechanisms accordingly. We demonstrate this support using a smart home simulation called HomeIO. 13  More details on the deployment demo using the HomeIO simulation can be found in this video. 14 In the smart home system, there are IoT applications (e. g. , UserCom-fortApp) that get access to sensors' data (e. g. , temperature) from the smart home to make decisions and send commands to control the actuators, e. g. , window blinds.
g. , window blinds. In particular, it maximizes the exploitation of daylights and regulates the in-door temperature whilst minimizing the energy consumption. If the room is bright because of daylight, it will switch off the LED-lights, and vice versa. On the other hand, if the room temperature is high, the application may need to close the window blinds to  13. https://realgames. co/home-io/ 14. https://youtu. be/yQ9XYWu-EZM prevent sunlight heating the room. The EnergyEfficiency application interacts with the smart home devices via the SMOOL platform. There are two notable security mechanisms associated in this first version of the smart home. The first one is a secure API gateway (Express Gateway 15 ) that allows secure remote API access to the EnergyEfficiency application. The second one is a SecurityEnforcer by default of the SMOOL middleware that enforcing the security check for the data passing through, e.
To enable such DevSecOps adaptation support, GENESIS not only provides the modelling language embedded in a web UI for specifying the components of such IoT platforms, but also the reconfiguration and rebuild of these components (for integrating new security mechanisms with the IoT platform) before deployment (for adaptation or for a new development cycle). For example, in the SMOOL platform, each SMOOL producer or consumer is associated with a security checker for checking the security key of sensor data or actuation commands. GENESIS allows updating the configuration of the security checker (e. g. , by injecting new configuration to overwrite the default one), and automatically rebuilding the SMOOL producer or consumer including the reconfigured security checker. By doing so, GENESIS enables the DevOps team to make reconfiguration or redevelopment and redeployment easily for the evolution of SMOOL producers or consumers including security checkers.
Smart Home use Case Description The experimentation is built upon the widely spread three-layer IoT architecture  [17]. The first layer (Perception Layer) at the edge of the infrastructure consists of 57 IoT devices providing up to 319 parameters including 249 sensor/actuator whose values/states are updated on a regular basis on a centralized time series database (Synology DS418 Network Attached Storage (NAS) + InfluxDB  [23] ). IoT devices part of this infrastructure layer are mainly consumer electronics devices (e. g. , Netatmo devices, Neato vacuum cleaner, LG TV, etc. ), complemented with custom IoT devices based on Arduino Uno/Nano and Raspberry Pi equipped with sensors and actuators targeting specific purposes. The second layer (Network layer) enables data transmission and processing, throughout the different IoT wireless communication protocols (Wifi, ZWave  [38] , etc.