dataesr/scientific-paragraphs-categorization huggingface dataset:
Loss of imprinting methylation correlates with aberrations in parental allelespecific expression in KSR-iPSCs We next examined whether ICR hypomethylation disrupts the normal allele-specific expression of imprinted genes by analysing our RNA-seq datasets taking advantage of the strain-specific SNPs. From a list of known murine imprinted genes  (Tucci et al. , 2019)  with stable imprinting in BL6 x CAST reciprocal crosses, we shortlisted 17 imprinted genes (13 paternally and 4 maternally expressed) transcribed from a single allele in MEFs (ratio: > 90%:10%), expressed in all iPSC replicates (Log2 RPKM > 1) and with sufficient allelic resolution (normalized cumulative SNP-specific read counts > 5) in at least two of the three replicates (Fig. 3A ; Table  S4 ). Consistent with the widespread hypomethylation defects in KSR-iPSCs and TX 2i ESCs (Fig.
Biallelic expression was detected in all iPSC lines for which unmethylated reads were found in the two parental alleles. Monoallelic expression was seen for M FBS1 iPSCs and MEFs, which exhibit normal methylation patterns at the Dlk1-Dio3 ICR. For the hypermethylated M FBS5 this could not be assessed as Meg3 was not expressed (Fig. S5A ). We also tested how the diversity of methylation outlines translate into differences in overall Meg3 levels measured by RT-qPCR. Although overall Meg3 levels were consistently higher in KSR versus FBS medium, the levels correlated with the number of unmethylated reads seen for each cell line (Fig. 5B ; Fig. S5B ). Our data shows that the Dlk1-Dio3 cluster is highly sensitive to reprogramming conditions and sex of donor cell. This imprinted locus was previously observed to acquire de novo methylation in both mouse and human iPSCs  (Bar et al.
DISCUSSION In this study, we thoroughly analysed the fidelity of genomic imprinting in mouse iPSCs. By using an established secondary reprogramming system  (Abad et al. ,   Our systematic analysis provides an explanation for the contrasting results from previous studies  (Stadtfeld et al. , 2010; Sun et al. , 2012; Takikawa et al. , 2013; Yagi et al. , 2019) , when sex of the donor cell (when given) and reprogramming culture conditions are considered (Table  S1 ). This knowledge is important to devise future strategies to create iPSCs devoid of imprinting abnormalities. The allele-specific IMPLICON creates a final dataset reflecting the original methylated/unmethylated DNA molecules with nucleotide and allelic resolution  (Klobucar et al. , 2020). This technique allowed us to investigate, for the first time, the heterogeneity of epigenetic states at imprinted regions within iPSC clonal lines.
Libraries were verified by running 1:30 dilutions on an Agilent bioanalyzer and then sequenced using the Illumina MiSeq platform to generate paired-end 250bp reads using 10% PhIX spikein as the libraries are of low complexity. IMPLICON bioinformatics analysis was also performed as described  (Klobucar et al. , 2020) , following the step-by-step guide of data processing analysis in https://github. com/FelixKrueger/IMPLICON. Briefly, data was processed using standard Illumina base-calling pipelines. As the first step in the processing, the first 8 bp of Read 2 were removed and written into the readID of both reads as an in-line barcode, or Unique Molecular Identifier (UMI). This UMI was then later used during the deduplication step with "deduplicate bismark --barcode mapped_file. bam". Raw sequence reads were then trimmed to remove both poor quality calls and adapters using Trim Galore v0.
5. 0 (www. bioinformatics. babraham. ac. uk/projects/trim_galore/, Cutadapt version 1. 15, parameters: --paired). Trimmed reads were aligned to the mouse reference genome in paired-end mode. Alignments were carried out with Bismark v0. 20. 0. CpG methylation calls were extracted from the mapping output using the Bismark methylation extractor. Deduplication was then carried out with deduplicate_bismark, using the --barcode option to take UMIs into account (see above). The data was aligned to a hybrid genome of BL6/CAST (the genome was prepared with the SNPsplit package -v0. 3. 4, https://github. com/FelixKrueger/SNPsplit). Following alignment and deduplication, reads were split allele-specifically with SNPsplit. Aligned read (. bam) files were imported into Seqmonk software (http://www. bioinformatics.
babraham. ac. uk/projects/seqmonk) for all downstream analysis. Probes were made for each CpG contained within the amplicon and quantified using the DNA methylation pipeline or total read count options. Downstream analysis was performed using Excel and GraphPad. From the raw data deposited in GEO under the accession number GSE148067, the reads mapped to the following murine (mm10) genomic coordinates were excluded for consideration in this article for one of the following reasons:.
RNA-seq Quality of Dnase I-treated total RNA from biological triplicates of female MEFs, F KSR2, F KSR4, M KSR3, M KSR5 iPSCs and TX 2i ESCs was checked by 2100 Agilent Bioanalyser. Samples with RIN score above 9 were processed. RNA (1μg) was used to generate strand specific polyA 250-300 bp insert cDNA libraries using the bespoke sequencing pipeline at Sanger Institute. Libraries were sequenced with Illumina HiSeq platform using single-end 50bp mode. RNA-seq raw FastQ data were trimmed with Trim Galore (version 0. 6. 1, default parameters) and mapped to the mouse GRCm38 genome assembly using Hisat2 version 2. 1. 0. Differentially expressed genes between female and male KSR-iPSCs were determined using both EdgeR (p-value of 0. 05 with multiple testing correction) and intensity difference filter (p-value < 0.
05 with multiple testing correction), with the intersection between the two lists giving the high confidence differentially expressed genes. Clustering analysis in Fig. S1B  used a Pearson correlation to calculate a distance matrix between all datasets which was then used to construct a neighbour joining tree. Allele-specific alignments were performed by mapping to both CAST_EiJ and C57Bl/6 (GRCm38) genomes, keeping reads that were specific for either genome and excluding those containing conflicting SNP information. Aligned read (bam) files were imported into Seqmonk software (http://www. bioinformatics. babraham. ac. uk/ projects/seqmonk) for all downstream analysis using standard parameters. Data was quantified at the mRNA level using strand-specific quantification of mRNA probes using the RNA-seq quantification pipeline in Seqmonk.
ACKNOWLEDGMENTS We would like to thank  Sérgio de Almeida ,  Miguel Casanova  and  Inês Milagre  for critical reading of the manuscript and the members of the S. T. d. R. 's team for helpful discussions. We also thank  Tânia Carvalho  and  Pedro Ruivo  for their help in histological analysis,  David Oxley  and  Judith Webster  at  Babraham Institute  for LC-MS measurements,  Bethan Hussey  at  Sanger Sequencing  and  Kristina Tabbada  at  Babraham Institute  for assistance with high-throughput sequencing. Work in S. T. d. R. 's team was supported by  Fundação para a Ciência e Tecnologia (FCT) Ministério da Ciência, Tecnologia e Ensino Superior (MCTES) ,  Portugal  [ PTDC/BEX-BCM/2612/2014 ,  PTDC/BIA-MOL/29320/2017  IC&DT]; S. T. d. R. has a CEECUIND/01234/207 assistant research contract and A.
Presentation of MAFIO This presentation follows the ODD (Overview, Design Concepts, Details) protocol for describing agentbased models  (Grimm et al. , 2006 (Grimm et al. , , 2010)). MAFIO is written in the Python 3. 6 programming language and makes use of the PCRaster module  (Karssenberg et al. , 2010)  for handling spatial inputs and outputs. Given that it can be coupled with any robust hydrological model that provides the necessary outputs, the following presentation of MAFIO is provided in a generic form, with Section 4 outlining the specific interfacing with EcH2O-iso.
Sub-models MAFIO consists of the Defecation Sub-model and several small-scale behaviour sub-models (Figure  4 ). The required parameters and their initial values based on daily simulation of E. coli from sheep and cattle are given in Table  4. In the following equations, a sub-script [LS] denotes that the value of the variable or parameter varies based on the livestock type. Meanwhile, a sub-script [xy] indicates an attribute or derived variable of the spatial grid whose value varies depending on the cell.
Introduction Contemporary empirical research critically relies on computational workflows to make sense of the ever increasing amounts of data collected. Few research papers in the biomedical sciences stand a chance of being published without evidence in the form of data to support or refute their hypotheses. The complexity of computational analysis workflows and the tools used therein varies greatly among disciplines and can range from calculating simple univariate statistics in a point-and-click user interface to a full-fledged analysis pipeline involving high-performance-computing (HPC) resources, command scripts and large databases. Reproducibility of analysis results is crucial to build trust in the presented work and to allow for the dissemination and re-use of workflow components or implementation ideas.
Efforts should be made to properly separate research data from both the definition of the required computing environment and the analysis code since the latter two can still be shared publicly and thus scrutinised by peer reviewers even without access to the raw data. Furthermore, upon obtaining access to the source data via a well-defined process, the results may still be reproduced. Solutions to aid with reproducibility may be platform based -e. g. Gigantum  [Gigantum Funding Team et al. , 2018]  -, specific to a particular programming language -e. g. Drake  [Landau, 2018]  -or cover different aspects of reproducibility -e. g. Conda for reproducible environments  [Anaconda Inc. , nd]  or Jupyter notebooks for literate programming  [Knuth, 1984, Jupyter Team, nd]. The number of different technologies and platforms is increasing so quickly that it can be a daunting task just to pick the set of tools and platforms to begin with.
Fortunately, although open-source software and open data can be important ingredients in reproducible research, these are not mandatory. Indeed, being open is not the same thing as being reproducible -even though openness facilitates external reproducibility. In some specific contexts, for instance in transcriptomics data (which have a long tradition of openness through the Gene Expression Omnibus data archive), part of the data can be shared publicly. In such cases, the data should be provided in a non-proprietary and non-binary format to ensure cross-platform readability and posterity on a persistent archive. In most cases, however, data can only be shared privately or not shared at all. This is due to study participant consent which usually restrains further re-use of health data due to their particular personal and sensitive nature.
g. patient data), thus eliciting caution when it comes to sharing data (and sometimes code). The importance of writing a data management plan (DMP) for a robust and reproducible research project cannot be underestimated, regardless of whether or not supplying one is a funder requirement. DMPs are used to plan how existing and new datasets and code will be synthesised, created, stored, preserved and shared during and after the project, taking into account any ethical or legal considerations and detailing quality assurance measures. DMPs should aim to cover the entire project lifecycle and be considered as 'living documents' to be revisited and reworked as necessary. Key benefits of creating, maintaining and adhering to a DMP are: i) to pre-empt any data-related predicaments before they occur, ii) to factor into the budget any data-related costs prior to the project's inception, iii) to increase the efficiency of research, iv) to guarantee the reusability of the data, and v) to support reproducibility.
Simple (informal) forms of version control are important for all data files, and version control systems should be applied to source code in particular (see Section 3). An additional and critical area of RDM is data documentation, or metadata that describes a dataset fully and comprehensively. The Biological and Biomedical community use a plethora of standardised metadata vocabulary, from taxonomic ontologies (e. g. vertebrate taxonomy ontology  [Midford et al. , 2013] ), to vocabularies on general and specific methods (e. g. Minimum Information for Biological and Biomedical Investigations (MIBBI,  Taylor et al. [2008] ), BioAssay Ontology  (BAO, Abeyruwan et al. [2014] )) and more -see the Ontology Lookup Service  [EMBL-EBI, nd]. The consequent use of vocabularies not only helps humans to better interpret data and its context, but also enables analysis software to be more interoperable, with implications for the reproducibility and reusability of datasets and tools.
In contrast, without clear documentation, dataset or analysis workflow reuse can be difficult and reproducibility unlikely, and worryingly, the risks of misinterpretation or misuse of data can be high. Data documentation should be a continuous process, from the point of data collection to data sharing and/or archiving, and essentially involves providing all the necessary information to permit comprehension by others, data discovery, data reuse and research reproducibility. Some tools exist to facilitate this process. For example, LabKey, an open-source specimen and data management platform, uses standardised metadata vocabulary oriented towards immunological research. The platform has some internal analysis and collaborative features such as specimen-sharing and secure data sharing capabilities, suitable for many types of biomedical data  [Nelson et al.
, 2011] , and is extensible through the addition of contributed specific data type modules. Another tool, which focuses on data management and submission to repositories is COPO (Collaborative Open Plant Omics), a metadata data annotation and data brokering platform  [Etuk et al. , 2019] , especially for sequence data management and submission to the EMBL-EBI. While this documentation remains a time-consuming task, both platforms have error-checking and batch-processing features in place, thus saving some time and effort for the researcher. Another RDM feature which some see as labour-intensive at first (yet has long-term benefits for the data producers and users) is the creation of a Readme file (or series of Readme files for complex multi-file datasets) that is deposited together with the data.
For datasets, clear advice on producing Readme files is provided by Cornell University  [Research Data Management Service Group, Cornell University, nd]. Practicing the aforementioned elements of RDM are important regardless of whether or not the data can be shared with others (i. e. , enabling the data creators, and not just others external to a project, to access and understand the data in future years). In addition to these elements, there are two critical procedures to follow in order to share data well and to preserve it to enable future access: choose a trusted data repository (e. g. one that has CoreTrustSeal certification  [Core Trust Seal, nd] , and adhere to the FAIR principles (see below). There are a large number of repositories available for data. These can be discipline-specific (domain) repositories, institutional repositories or general purpose repositories (see  re3data.
org [re3data. org, nd]  for a registry of research data repositories  [Pample et al. , 2013] ). It is important that the chosen repository meets certain standards; for example, one that provides persistent identifiers (e. g. DOIs) for datasets, collects comprehensive and machine-readable metadata (e. g ˙licensing information), offers long-term data preservation (see Section 6), and provides a service that performs checks on the metadata and data. Trustworthy discipline-specific repositories, followed by institutional repositories, are preferable over general purpose repositories due to the additional curation and standards checks that these provide  [OpenAIRE, nd]. The FAIR principles and research data repositories are inherently linked. Making data FAIR -Findable, Accessible, Interoperable, Reusable  [Wilkinson et al.
, 2016]  -involves making it available in a trusted data repository, with comprehensive metadata, in open (non-proprietary) formats, with a permanent identifier (DOI), and with a clear and machine readable license. As we shall see below, however, not all data can be shared in a repository or made available as open data: data that is restricted can still be made FAIR but there are a number of ethical considerations that need to be acknowledged when applying the FAIR principles (e. g. see  Boeckhout et al. [2018]  for a critical appraisal of the FAIR principles, with particular reference to genomic data). There are several good sources of information about the FAIR data movement  [Collins et al. , 2018 , Sansone et al. , 2019] ; as well as related initiatives that aim to support researchers (e.
This enables users to 'time-travel' between different snapshots of the files in the repository. Modern version control systems come in two flavours: i) "centralised version control systems" (CVCS) such as Subversion [The Apache Software Foundation, nd], and ii) the more recent "distributed version control systems" (DVCS) such as Mercurial  [Mercurial community, nd]  or Git  [Git community, nd]. In centralised systems, a single central copy of the repository is stored on a server and provides access to users. In distributed systems, users clone a copy of the repository locally, including the full history of the project. We particularly focus on Git in the remainder of this section, due to its widespread popularity within the Biostatistics field.
Git Git is extremely reliable and well-supported due to extensive use by the open source community and large software companies. The community support is exceptional and there are several popular hosting services for Git repositories (e. g. GitHub, GitLab and Bitbucket). These hosting services facilitate online collaboration, allowing easy access and interaction with the 'master copy' of a project, with additional features such as issue tracking and task management tools. However, it should be noted that none of these Git hosting services are directly suited for long-term storage and archiving of source code. Specifically, they do not guarantee long-term availability nor citeability. Instead, dedicated archiving services such as Zenodo provide tight integration with these Git hosting services (see Section 6).
Version control and reproducibility Version control is not synonymous with reproducibility and having one does not guarantee the other. Rather, version control is a tool that can help make science more reproducible. A basic way it does so is facilitating code sharing through a well-established online community, for example code being made publicly available on GitHub. Transparent access to all the project code gives computational details that are required for reproducing results, such as parameter values and the source code of functions including those within wrapper functions. Potential drawbacks of using Git for version control are that it is not designed to easily compare or merge changes made to binary files (e. g. Microsoft Word documents) and there are size limits on files that can be uploaded to Git hosting services.
Workflow Automation Even small real-word analyses often require a multitude of outputs such as intermediate data sets, whether it is for the production of single figures and tables, or entire reports. The task of manually running all code and compilations in the correct sequence, whilst respecting their potential inter-dependencies, can quickly become challenging. "Unfortunately, it is very easy for a programmer to forget which files depend on which others, which files have been modified recently, and the exact sequence of operations needed to make or exercise a new version of the program. [. ] recompiling everything in sight just to be safe is very wasteful. " -S. I. Feldman  [Feldman, 1979a]  These early words used by Feldman, the developer of the ubiquitous build automation tool make (Free Software Foundation, 2016) still hold true today.
The ubiquitous: bash Anyone who has worked with a Unix terminal will have come across the widely used default login shell bash (Free Software Foundation, 2019). Putting bash in context with workflow engines, a simple bash shell script can be seen as a formalised workflow description and the executing shell (usually bash) as the corresponding workflow engine. Since bash is a scripting language itself, this is a highly generic way of describing workflows allowing one to 'glue' together any program that can be run in a Unix shell. In fact, many of the more advanced workflow engines can be seen as wrappers around executing shell scripts (for example make and snakemake). The generality of shell scripting comes at the cost of having to manually implement routines for recurring tasks in standard analysis workflows, such as caching intermediate results and checking the existence of required outputs.
Orange circles represent data sources from a repository, where the data is openly accessible and citable, complies with format requirements and contains the minimum required metadata, and where the dataset license is legally adhered to during the process of data reuse. The blue circle represents all files necessary for the reproducibility of a research project, available at an online location such as a Git repository that is easily downloadable by the researcher. The repository includes scripts that retrieve and prepare the data, perform simulations and/or analysis, and create the figures used in the publication. Lastly, all results are integrated in the manuscript, which recompiles itself in the same run instant. This entire workflow is governed through a workflow engine script, a Makefile (e.
g. a Snakefile in case of snakemake), which not only compiles and runs all executing scripts and outputs in the correct order, but also prepares the environments and dependencies before running the scripts. The black lines between the shapes in the green box represent the schematics of the Makefile. This analysis could be executed on a local machine or an HPC (green box). Once the Git repository is downloaded, the entire workflow should build the manuscript with one simple command: 'snakemake'. While a simple top-level shell script is the easiest way of defining a fairly simple workflow that does not require any of the more advanced features discussed below, shell scripting alone is not suitable as a workflow engine lingua franca for a wider range of projects.
Caching computationally intensive steps: make Historically, make had its origins as a build system for compiling source code from statically compiled programming languages. Whilst its original aim was to help develop and maintain programmes, today it can also be used to automate the updating of any kind of inter-dependent files, which makes it relevant in the discussion of workflow engines here. Make also solves the issues of file or library inter-dependency and command sequencing. By tracking which files have been updated and those which have not, make can drastically speed up code compilation and development. (Re-)compilation of a large program can be a computationally intensive task. Additionally, it may rely on external dependencies such as operating system libraries. When changing a subset of files, it is hard to manually keep track of which files need to be updated and which can remain unchanged.