dataesr/scientific-paragraphs-categorization huggingface dataset:
Transmission Electronic Microscopy Chromatin samples were prepared from 80 million E14Tg2a ES cells and centrifugated through a sucrose gradient, as described above for MNase ChIP-seq. We examined subnucleosomal particles collected from fractions 5, 6, 11 and 12 of the sucrose gradient and particles further purified from a pool of fractions 5-6 by immunoprecipitation with the antibody targeting the 20 C-terminal amino-acids of Oct4, as described above. We analysed half of each replicate sample of Oct4-immunopurified particles by EM as shown in ED Fig. 10a , b, and we processed the other half as a ChIP-seq sample, which was used for the V-plot shown in Fig. 4c , and for the WT1 lane of the density graphs shown in Fig. 4d  and Extended Data Fig. 5  and 8. Aliquots of sucrose gradient fractions were dialyzed overnight into TEAP10 buffer (10 mM Triethanolamine-HCl (pH 7.
We measured particles having an elliptical shape along the major axis, as this likely represents the front view of the nucleosomal particles. We built the boxplot shown in Extended data Fig. 10b  with the sizes of 92, 102, 97, 71 and 100 particles from one sample of sucrose gradient fraction 6, two independent samples of Oct4-immunopurified particles (Oct4 (5-6) R1 and R2), one sample of fraction.
Lists of ES cell enhancers We first mapped the distribution of cis-regulatory elements onto the ES cell genome using DNaseI-seq data (GSM1014187), resulting in the identification of 139,454 DNasehypersensitive (DHS) regions, as previously described  23. Gene promoters were filtered out using RefSeq coordinates of TSSs, and putative enhancers were identified based on the cooccurring binding of pluripotency-associated TFs Oct4 (GSM1082340), Sox2 (GSM1082341) and Nanog (GSM1082342), as well as of the mediator (GSM560347)  4, 45   shown in Extended Data Fig. 1. We developed the exPATT. R tool to detect Oct4 DNA binding motifs and change the genomic coordinates of each enhancer to have the Oct4 motif at its centre. The exPATT. R R script filters genomic regions, recorded in an input BED file, that match a given DNA pattern (Oct4 consensus motif in this study) depicted as a position weight matrix (PWM).
These pattern matrices were matched in genomic region using the PWM-related functions of the Bioconductor package Biostrings 47 with a minimum score of 80% of the highest possible score. Then, genomic regions with at least one pattern hit were filtered. The output of this script was a new BEDGRAPH file with filtered DNA regions of 2 kb centred around the pattern. All BED file input and output operations were performed using the rtracklayer package. Then, we used bedtools to select enhancers bearing a single central Oct4 motif per enhancer (n = 1,302, Extended Data Fig. 9 ).
Lists of 501 Mel cell enhancers Our extensive analysis of the distribution of 50-80 bp subnucleosomes in mouse ES cells revealed their accumulation at enhancers, promoters and CTCF-binding sites (this study). Based on the hypothesis that subnucleosomal particles are conserved in human cells, we mapped cis-regulatory elements in human 501 Mel cells using the histone H3 ChIP-seq dataset obtained from 50-80 bp subnucleosomes purified from these cells. We used MACS2 to call 91,205 peaks from this dataset. We next focused our analysis on putative enhancer elements located in intergenic regions. We filtered out all regions of the human genome located within 3 kb of gene TSSs or 10 kb of gene end coordinates. We also set up a strategy to remove CTCF-bound loci from this list of peaks. Since the CTCF ChIP-seq distribution has not been defined in 501 Mel cells, we took advantage of the observation that CTCF binding to mammalian genomes is relatively independent of cell type  48, 49.
List of CTCF binding sites ES cell genomic CTCF binding sites were identified based on the ChIP-seq signal of several CTCF datasets (GSM723015, GSM1828650, GSM288351 and GSM560352) at DNase-hypersensitive (DHS) regions, as described above for enhancers. All loci proximal (< 2 kb) to gene promoters and putative enhancers were removed. We used a subset (n = 9,850) of these CTCF-positive regions to generate the V-plots shown in Extended data Fig. 6  and 7.
List of promoters We rank-ordered gene promoters transcribed in mouse ES cells according to the distance between the two divergent TSSs located on the plus strand and the minus strand, using 5' ends of Start-RNA reads (GSE43390), as described  50. ES cell Start-RNA reads datasets were first aligned to mm9 using Bowtie 1. 3. 0. Only the reads mapping to a single position with a maximum of two mismatches were conserved. We derived the reference promoter list from Refseq annotation. We defined promoter windows as ± 1000 bases around the TSS position. We discarded windows with more than one TSS on the plus strand. We also removed the promoters associated with less than five overlapping Start-RNA reads. We calculated the coverage using a bin of one base. We selected the first six bases of the 5-prime reads as the signal to adjust the position of the TSS on the plus strand.
We used a Python script to find the nearest local maximum upstream of the Refseq annotation, which we defined as the TSS position in this study. Next, we determined the location of the antisense Start-RNA signal on the minus strand in the region located upstream of the plus strand TSS. As above, we selected the first six bases of the 5-prime reads to define the position of the antisense TSS. We then designated the coordinate of the antisense TSS as the location having maximum Start-RNA expression on the minus strand, upstream of the sense TSS. We next sorted the promoters according to the distance between sense and antisense TSS coordinates. In this study, we focused our analysis on the 1,000 TSSs with the smallest distance between sense and antisense TSSs. The nucleosomal and subnucleosomal organization of the other groups of TSSs is similar and will be presented in detail in a separate publication.
MNase ChIP-seq and MNase-seq analysis Quality controls, mapping and post-mapping process The processes described below were done using Snakemake  51  , Conda and in-house python scripts. We controlled the quality of sequencing data with FastQC (fastqc=0. 11. 9, default parameters)  52  and fastqScreen (fastq-screen=0. 14. 0) using bowtie2 as default aligner  53. Depending on their quality, sequencing files were trimmed with fastp (fastp=0. (deeptools=3. 5. 0)  56.
IGV visualizations and 2D histograms (V-plots). Peaks and normalized coverage profiles were visualized as IGV (Integrative Genomics Viewer) screen-shots, heatmaps, and 2D graphs (V-plots). We converted BAM files containing paired-end mapped reads to BED files containing DNA fragments using Bedtools bamtobed (bedtools=2. 29. 2)  57. These DNA fragments were visualized as a heatmap with seqMINER software and as a 2D graph (V-plots) using a homemade script. In the plot, the yaxis corresponds to DNA fragment size in bp and the x-axis to the relative position of DNA centre fragments on the genome. Each dot corresponds to the coordinates of a DNA fragment midpoint, and colour intensity reflects the number of fragments at that position. When comparing several samples, we chose the colour intensity manually, and a ratio was applied to reduce the number of fragments to the same level in each sample.
TF motif detection in DNA fragments purified from the top gradient fractions. We used MACS2 callpeak (macs2 2. 2. 7. 1) to identify the genomic regions enriched in histone-free DNA fragments sequenced from the top gradient fractions (DNA purified from pools of sucrose gradient 2-3-4). We set the minimal size for a peak to 40 bp. Then, motifs were detected with HOMER findMotifsGenome. pl for mouse genome (homer 4. 11). For Extended Data Fig. 7h , we selected 32 TF motifs with a significant p-value (p < 10 -50 ) in the samples prepared from ES cells expressing wild-type Brg1 (control samples). We noticed that the number of CTCF motifs detected was unaffected by depletion of Brg1, in agreement with previous observations based on ATAC-seq experiments  58. We thus choose to normalise the data according to the number of CTCF motifs detected in each sample.
Detection of TF motifs at enhancers. We performed motifs analysis with Meme (v5. 3. 0)  59. Detection of Oct4 motifs was carried out with Fimo over selected lists of enhancers, using two distinct p-values (0. 001 and 0. 01) to allow different levels of stringency in the motif sequence matching. The Oct4 motif matrix (MA0142. 1) came from the Jaspar database  60. We used Centrimo to define Oct4, Sox2, Nanog and Klf4 motif enrichment profiles at ES cell enhancers of clusters 1 and 2 (Extended Data Fig. 3b, c ). For Centrimo analysis of putative enhancers in human 501 Mel cells, we selected the DNA binding motifs of SOX10, MITF and TFAP2A, which were shown to be enriched at enhancers  41.
combination of filtering steps led to a list of 14,502 putative 501 Mel cell enhancers. K-means clustering of these 14,502 elements using the H3 ChIP-seq datasets from sucrose gradientpurified 50-80 bp subnucleosomes and from the fraction containing canonical nucleosomes allowed us to isolate the five clusters of putative 501 Mel cell enhancers shown in Extended data Fig. 10c-e.
' 2019. Broad Institute, GitHub Repository. http://broadinstitute. github. io/picard/; Broad Institute). Samtools was used to remove marked duplicates, unmapped, and reads involving a mapping quality below 30. The RPKM normalized genomic coverage was calculated with Deeptools for MNase data with a bin size of one base and centred on the fragment centre for a fragment size of 10 to 500 bp. Chromosomes M, Y and X were not used for the normalization. The effective mouse genome size was set to 2,652,783,500 bp.
46To avoid potential interferences with CTCF-bound regions in our nucleosomal organization analysis, we removed from these putative enhancers those bound by CTCF, using ES cell datasets GSM723015 and GSM1828650. 19,365loci displaying high ChIP-seq signal for Oct4, Sox2, Nanog, and the Mediator, but negative for CTCF, were identified as putative enhancer elements. We then used the histone H3 MNase ChIP-seq datasets generated in this study to analyse nucleosomal and subnucleosomal organization at these putative enhancers. One of these H3 MNase ChIP-seq datasets was converted into a BED file and further subdivided into >180 bp: 51,518,836 fragments. Next, in each BED file, DNA fragments were reduced in length to 10 bp, centred at the level of fragment midpoint. Using seqMINER46, fragment densities from these modified BED files were collected in a -1500/+1500 bp window around the centre of each enhancer (defined in this study as the centre of the DHS peak) and subjected to several rounds of k-means clustering.
Acknowledgements: We thank  A. Goldar ,  A. Leforestier ,  J. M. Victor ,  S. Khochbin ,  K. Yen ,  S. Mahony ,  I. Davidson  for discussions,  E. Nora  and  B. Bruneau  for the E14Tg2a-Tir1 cell line, and  C. Mann  for reading the manuscript. This work was supported by grants from the  INCA  ( 2017-1-PL BIO-02-CEA-1 ),  Investissement d'Avenir ANR (Revive Labex   ANR-10-LABX-73 ),  ANR  ( ANR-17-CE12-0001-01 ),  PRC/PICS07434  and  Fondation ARC  pour la recherche sur le cancer www. fondation-arc. org.
A toolchain is presented to support the implementation, which consists of a set of enabling software corresponding to the functional modules of the framework. Different manufacturing system architectures are first designed by industrial system engineers supported by the application ontology semantic-driven tradespace framework stored in a graph database. They are then analyzed through Discrete Event Simulations and 3D simulations. The simulation results are presented through a web-based portal to show the key performance values of each architecture. This study serves as a part of the proofof-concept of the recently proposed Cognitive Digital Twin concept.
Semantic-driven tradespace framework The architecture of the proposed tradespace framework for aircraft manufacturing system design is demonstrated in Figure  1. It follows the three-layer model of the MfM methodology proposed by  Mas et al (2018) , including data layer, ontology layer and service layer. The data layer consists of all available data sources such as databases from the legacy software and commercial software applications, clouds and data lakes, among others. These data sources provide data, information and knowledge to the Ontology layer for knowledge capturing and instantiating. There exist sufficient studies in the information technology field regarding database management technologies. Therefore, this paper focuses mainly on the Ontology layer and the Service layer. As shown in Figure  1 , the ontology layer is the core of the framework.
This module takes input from the databases of the Data layer as the main source for documented knowledge about existing products and relevant assembly systems. Expert knowledge can be captured as complementary through interviewing and surveying with domain experts. Another knowledge source is the public knowledge from academic publications and industrial communities. The captured knowledge is then formalized and aligned with chosen top-level, domain and sub-domain ontologies. During the development of a new assembly system, the Requirement Management module will define the industrial requirements for the new system and provide relevant information to the ontology for creating a requirement model. Similarly, the Architecture Definition Module will define the primary architecture model and behavior model for the new system.
This module also enables extracting information from the System Integration Module to automatically generate different types of system architecture models which can be then be transferred back to the graph database. A more specific example will be introduced in the case study. • Verification Module: The Verification Module is located at the Service layer and interacts with the System Integration Module. Its main function is to verify and evaluate alternative solutions of the manufacturing system design. It includes different types of simulations such as Discrete Event Simulation (DES), 3D simulation and ergonomic simulation. Relevant information of each alternative solution, such as operation sequence, operation duration, labor and equipment cost etc. , can be extracted from the application ontology using certain middleware.
According to predefined performance indicators, the simulation results will be obtained and fed to the Visualization Module and presented to the decision-makers. More technical details will be introduced in the case study. • Visualization Module: The Visualization Module is located at the top of the Service layer and takes input from the Verification Module. Its main function is to provide an interactive user interface to show industrial engineers the summarized information about the simulation results corresponding to different performance indicators. The formats can be different depending on the needs of users, such as pictures or videos of 3D simulation results, GANTT diagram, automation ratio, and lead-time of a process etc.
-4) Code generation: it enables to describe the model transformation from KARMA models to other data or models  (Guo et al, 2020 ). -5) Architecture driven: it enables to describe the model transformation among KARMA models. • The DES engine of the Verification Module is developed based on an opensource Python library SimPy  (Zinoviev, 2018). It supports to simulate the lead-time of a process that consists of numerous interconnected operations with a start and an end joint forming a Directed Acyclic Graph (DAG). The DES component can also be integrated into visualization, such as a dedicated dashboard, providing API for common data exchange formats,such as CSV and JSON. The 3D simulation is enabled by the software Visual Components 6. It supports simulating manufacturing processes with various resources, such as industrial robots and human resources, in a highly visual environment to gather various statistics such as lead times and utilization levels.
Visual Components platform provides Python and. NET APIs that enable extending the standard functionalities and integration with other parts of the toolchain. • The Visualization Module is developed to present the simulation results, metrics and performances that summarize a designed assembly system. It aims to visualize different design options concerning multidisciplinary requirements and metrics. The tools used to build the visualization module with an public access for validation are briefly introduced as follows: -Streamlit 7  is an open-source app framework for Machine Learning and Data Science teams. In this work, it is used to build the frontend of visualization module interacting with the backend, where the data transition and simulations are executed. -Docker is one of the containerization technologies  (Merkel et al, 2014).
A Docker container packages an application with all of its dependencies and the processes executing in it are isolated from the host machine. In this work, it serves for an easier deployment of the web application with an isolated environment in a cloud service. -Google Cloud Platform (GCP) offers both Infrastructure-as-a-Service (IaaS), platform-as-a-service (PaaS) and software-as-a-service (SaaS)  (Challita et al, 2018). One of the PaaS is Google App Engine (GAE) that provides a scalable hosting for web applications. With the support of Docker to package the application, the Google Cloud SDK then enables the deployment of a web application from local machine direct into GAE.
Architecture model ontology The architecture model ontology is developed following the MBSE methodology. More specifically, the GOPPRRE ontology  (Lu et al, 2021)  is used together with the KARMA modelling language  (Lu et al, 2020). Meta-models from UPDM and SysML specifications for formalizing the mission view, operation scenarios and diagrams for formalizing the functional views, logic views and physical structure of the assembly processes are developed by using KARMA language. An example is shown in   Using the MetaGraph software, the models can be transformed into OWL models. As shown in Figure  10 , once the architecture models are developed with KARMA, all the architecture models are generated into OWL format ontology which is defined based on the GOPPRRE ontology  (Lu et al, 2021).
Assembly process design The developed application ontology is imported into a graph database, Neo4j in this case, which is hosted on a Microsoft Azure cloud server to enable remote access by different partners. Neo4j provides a Neosemantics 9 plugin which enables the use of RDF in Neo4j graph database. It allows importing semantic-driven tradespace framework Fig. 11  Overview of the ontology integration approach and exporting ontologies in various formats, such as OWL, RDF, XML and Turtle etc. Once imported to Neo4j, different querying and reasoning can be executed based on tailored query conditions and reasoning rules. The source Cypher code for importing and editing the application ontology in Neo4j is available on GitHub 8 with detailed instructions. Some essential knowledge about the targeted assembly process has been stored in the ontology which can be reused to support system architects to create new solutions.
These relationships can be expressed with triples. For example: -OrbitalJointProcess -hasSubProcess → LowerOrbitalJointProcess; -OrbitalJointProcess -hasEssentialOperation → Set up working environment; -LowerOrbitalJointProcess -hasOptionalOperation → Riveting buttstraps and stabiliser manual ; -Set up working environment requiresResource → Station platform. The captured knowledge, such as the structure of an assembly process, essential and optional operations, available options for a certain operation etc. , can be retrieved using the graph query language Cypher 10  provided by Neo4j. The retrieved knowledge can be used to accelerate the design of new assembly solutions. Figure  13  illustrates one assembly process design option that the engineer has modeled using MetaGraph software, which is corresponding to Solution 2 in Figure  5.
The data is exported from MetaGraph to Neo4j using the architecture model ontology. The blue points on the left represent the different models that can be created as design options; the gray points represent the operations included in the model, among which the above two rows represent the two manual quarter-orbital level processes and the ones on the bottom correspond to the automatic half-orbital level process; the green points in the middle are the resources required by the operations; and the lines between points represent their relationships. All the points and lines have their own semantic-driven tradespace framework properties inherited from the application ontology, such as operation duration, resource cost, required resource quantity etc. The data of the models generated by the engineer are stored in the Neo4j database and can be retrieved and exported in different formats, such as JSON, RDF and Turtle etc.
Requirement definition and validation The requirements of this case study are defined by requirement engineers using the aforementioned OntReq requirement management system. Historical requirement documents are imported and redefined to create new requirement items for the target assembly system design. Based on the Requirement ontology, corresponding requirement individuals are generated and added to the ontology which can be exported in an OWL file. The obtained requirement ontology, which contains the industrial requirement items with relations to the target industrial system, is then integrated with the other ontologies to form the final application ontology. These requirement items and relevant information will be extracted and validated through the DES simulations in the verification module.
During the requirement validation phase, the extracted industrial requirements are transformed into quantifiable parameters which can be validated based on a set of metrics generated by simulations. The dataset containing these industrial requirements are then mapped to a dataset with process and architecture information for simulations. An example is shown in Figure  14. The process and architecture information is represented in an intermediate DataFrame format, which describes operation information, operation relations, operation type, resource, resource cost rate, operation-resource relation, etc. This format conforms to the models for simulations and hence can be fed directly to simulation engines. It is worth noting that the simulation dataset shown in Figure  14  represents only one design solution.
When more solutions are included, they will all be mapped to the same industrial requirement dataset making it possible to compare different solutions and perform trade-offs. Fig. 14  An example of mapping requirement dataset to process and architecture information dataset A more specific example of the requirement validation process is shown in Figure  15. Three requirement items are created in the OntReq RMS with relevant properties, such as hasText, hasMetric and hasStatus etc. In the description of an item, the value of a certain property can be identified that the metric points to, e. g. RC STATION40. The status open indicates that this requirement has not been validated. Each of the requirement item is represented by an individual generated in the requirement ontology and can be integrated into the final application ontology.