dataesr/scientific-paragraphs-categorization huggingface dataset:
Acknowledgements We are grateful to the  Royal Society  for sponsoring this event and in particular to  Mr. Ryan Ahmed ,  Mrs. Jennifer Howes  and  Judy Wilkins  from  DeVere Venues  for their great help in organising this conference. We are also grateful to the  Royal Society for Industry award  granted to A. H. and in particular to scheme manager  Mr. Ben Cunningham  for all his help and support. AH also thanks the  BBSRC  for support ( BB/L026287/1 ). We are also grateful to our Evotec colleagues  Dr. Gabriele Hansen  and  Dr. Florence Eustache  for all their assistance, guidance and for the design of the conference material.
Introduction The long-term preservation of digital data and resources has been an ongoing topic within the ITindustry and archiving community i. It is not only an IT challenge but also a challenge to both Social and Human Sciences, and academics in general, in terms of changing research and training habits in the scholarly world of the humanities. This short article focuses mainly on the former issue but will offer conclusive remarks, from a Swiss perspective, on the latter aforementioned issue. While the Open Archival Information System (OAIS) reference model offers a very reasonable framework for the long-term archiving of digital data such as digitized motion picture, images, sound or text documents, the archiving of highly structured digital data, such as databases, still raises a lot of problems.
The flattening of databases into XML text files has been successfully used to archive the contents of relational database management systems (RDBMS) ii iii iv. However this method reduces accessibility since the XML files usually have to be read back into a RDBMS. In addition to this process, the logic of the application has to be reconstructed in order to regain the full usability of the data. Currently, the best method for maintaining the sustainability, functionality and usability of structured data is to migrate data repositories and their software environments (user interfaces, analytical tools and so forth) to new technologies, thus ensuring their ongoing functional accessibility v. The replacement of obsolete hardware and software infrastructure is an ongoing and labor-intensive process that requires continuous financial effort V.
Furthermore, given that online research data is often being constantly modified to reflect new insights and is thus changing dynamically, referencing it (for citations as an example) is not straightforward. Since research is not a standardized process, different research projects tend to make use of projectspecific solutions and technologies. This variety of technical solutions and methods therefore leads to generic problems with respect to the interoperability and longevity of research data. Despite these difficulties, the use of digital research data, including databases, has become common in the humanities. Simultaneously, the terms used to describe the complexity of digital resources that are used and produced by the humanist researchers may be misleading: not only with respect to collections of digital objects such as digitized manuscripts; collections of digitized photographs; and metadata related to it, but also the enrichment of such sources with elements such as annotations and semantic rich links, amongst others, all of which form a base of research data in the humanities.
As long as project funding is available, many of these digital sources are accessible to the research community online. However, once the funding ceases, most of these sources will remain accessible only as long as the supporting hardware and software can be kept in working order. After a certain amount of time -measurable in years -there is a danger that most of these research databases might be abandoned due to lack of maintenance. Thus, most of the digital resources and results created within research projects will have a relatively short lifespan and will no longer be available to the research community; the citation of the affected digital objects will become impossible. However, these digital sources can provide a valuable reference base for future projects but only if the maintenance thereof is ensured through continuous funding.
The proposed DASCH is based on the following premises: A) Preserving software in a usable and working condition remains a difficult task, as illustrated at the recent meeting 'Preserving. exe: Toward a National Strategy for Preserving Software' held by the American Library of Congress vii. It would therefore be too difficult and costly to maintain a multitude of different systems for a long time. B) Emulation of obsolete hard-and soft-ware as proposed by R. A. Lorie (Lorie, 2001) is also not an easy approach, having its share of problems  (Luan et al. , 2010). Instead, with respect to DASCH, we propose that only a minimal number of centralized service locations should be operated: where the different digital sources or databases will be integrated through an importation and translation process.
As a result, ideally only one type of technological infrastructure has to be maintained. DASCH as defined by the call for proposals addresses the following: • The first phase focuses on the adoption of existing data resources of research projects that have reached the end of their funding. In the second phase, the goal is for researchers of ongoing or future research projects to be guided through the creation and use of digital sources in order to facilitate the accessibility of the data once funding has ended. DASCH facilitates the exchange between platforms and infrastructures by implementing interfaces for the import, export and querying of information (data restricted by means of legal constraints, such as copyright issues and/or protection of personal rights, are mapped in a sophisticated access right system).
The adopted digital sources must be accessible through a flexible and extendable user interface that allows for search and analysis. We are currently supporting a RESTful (Representational State Transfer, a standard for scalable web services) web-service and a Linked Open Data SPARQL-Endpoint in order to integrate the data into other research projects and/or databases. DASCH should encourage new collaborative research models in order to allow for the optimal use of digital sources. It should also be able to facilitate efficient training modules and support for all the new research projects funded by the Swiss National Science Foundation. In order to prepare for the interrelation of Swiss digital Humanities research to international research, international contacts are a key focus for this center.
Given the nature of research in the humanities, the data sources DASCH has to deal with are heterogeneous and consist mainly of qualitative data (which is possibly linked to digitized objects). The experience thus far, with respect to the integration of approximately fifteen projects of different sizes and complexities, has shown that anything from simple spreadsheets to complex, undocumented relational databases with more than a hundred tables can be expected. The SALSAH-platform viii was chosen as base for the consolidation of different data sources. The repository of SALSAH is based on semantic web technologies (RDF, RDFS and OWL), and it has a modular, layered architecture and is thus well suited to the emulation of the basic functionality of RDBMS's, simple databases such as MS-Access, and other databases such as FileMaker.
DISTARENT also uses P2P technology to maintain redundant multiple backups of the data within the network. • Within the DASCH project, SALSAH will be extended to support open data-standards  [11]  for access and linked data  [12]. However, open access may be restricted by legal reasons (such as copyright and privacy laws). SALSAH includes fine-grained identity and rights management. • SALSAH will be continuously enhanced according to the needs of the researchers using the platform. It is planned for SALSAH to migrate to open source by the end of 2015. The main tasks of DASCH will be threefold: 1. Maintaining the technological infrastructure and adapting it to the needs of researchers and changing technology. This task will be handled in Basel during the pilot phase but since SALSAH will become an open source project, other institutions and individuals may contribute to its base.
Unfortunately, most of the work that discusses cooperation in software engineering such as  [6]  and  [7]  focus-es only on the design stage of software development lifecycle and do not address the RE upstream phase. Very little works have focused on the cooperation in RE. The fact that RE is important should have led to more interest in cooperation in this phase. Different kinds of solutions have been proposed to support the RE process: goal oriented approaches such as i*  [8]  deal with actor dependencies, goals and intentions, viewpoint oriented approaches such as PREview  [9]  deal with the perception of actors, and scenario oriented approaches such as CREWS  [10]  describe functional behaviors by means of scenarios. This variety of solutions makes cooperation among organizations stakeholders in this phase a difficult activity due to the heterogeneity between these models.
RefRepository (Fig. 5 ) contains a set of elements. Each element is either a concept or an attribute and it belongs to a model. Each element is included in a correspondence where each one has a set of Naming Conventions and a set of questions that will be used in the semi-automatic translation. The evaluation of our work can be achieved by applying several case studies in order to verify the soundness of the translation process we propose. In this paper, we present one of these case studies to illustrate the translation process: a requirements specification for a software bugs management system. We uses i*, PREview and CREWS to represent requirements models. For the sake of space we only represent i* model (cf. Annex), the translation between i* and PREview and the results of translation between the three models.
Recall that an original source model of i* is composed of 20 instances of concepts. The 5 concepts in i* that are not translated are: Tasks (ReportBugTask, FixBugTask, ManageBugsTask), SoftGoal (ImmediateReporting), Resource (BugResource). The Source concept (SoftwareSource) is not translated correctly to i* model. The translation from an i* source model to PREview is performed in the same way with the same correspondences as illustrated in Table  2. The overall translation of i* model (20 instances) are translated automatically to 11 instances of PREview concepts, and semi-automatically to one instance; that leads to a total of 12 instances if the semi-automatic translation is well performed. Knowing that an original source model of PREview is composed of 13 instances, the Resource and the SoftGoal of i* model are not translated correctly to PREview concepts.
HiC-Pro is an optimized and flexible pipeline for processing Hi-C data from raw reads to normalized contact maps. HiC-Pro maps reads, detects valid ligation products, performs quality controls and generates intra-and inter-chromosomal contact maps. It includes a fast implementation of the iterative correction method and is based on a memory-efficient data format for Hi-C contact maps. In addition, HiC-Pro can use phased genotype data to build allele-specific contact maps. We applied HiC-Pro to different Hi-C datasets, demonstrating its ability to easily process large data in a reasonable time.
The overall strategy to process Hi-C data is converging among recent studies  [9] , but there remains a lack of stable, flexible and efficient bioinformatics workflows to process such data. Solutions such as the HOMER  [10] , HICUP  [11] , HiC-inspector  [12] , HiCdat  [13]  and HiCbox  [14]  pipelines are already available for Hi-C data processing. HOMER offers several functions to analyze Hi-C data but does not perform the mapping of reads nor the correction of systematic biases. HiCdat, HiCinspector and HiCbox do not allow chimeric reads to be rescued during the mapping of reads. HICUP provides a complete pipeline until the detection of valid interaction products. Using HICUP together with the SNPsplit program  [15]  allows the extraction of allele-specific interaction products whereas all other solutions do not allow allele-specific analysis.
The HiCdat and HiCbox packages offer a means of correcting contact maps for systematic biases. Finally, none of these software were designed to process very large amounts of data in a parallel mode. The hiclib package is currently the most commonly used solution for Hi-C data processing. However, hiclib is a Python library that requires programming skills, such as knowledge of Python and advanced Linux command line, and cannot be used in a single command-line manner. In addition, parallelization is not straightforward and it has limitations with regard to the analysis and normalization of very high-resolution data (Table  1 ). Here, we present HiC-Pro, an easy-to-use and complete pipeline to process Hi-C data from raw sequencing reads to normalized contact maps. HiC-Pro allows the processing of data from Hi-C protocols based on restriction enzyme or nuclease digestion such as DNase Hi-C  [4]  or Micro-C  [16].
HiC-Pro results and performance We processed Hi-C data from two public datasets: IMR90 human cell lines from Dixon et al. [6]  (IMR90) and from Rao et al. [7]  (IMR90_CCL186). The latter is currently one of the biggest datasets available, used to generate up to 5-kb contact maps. For each dataset, we ran HiC-Pro and generated normalized contact maps at 20 kb, 40 kb, 150 kb, 500 kb and 1 Mb resolution. Normalized contact maps at 5 kb were only generated for the IMR90_CCL186 dataset. The datasets were either used in their original form or split into chunks containing 10 or 20 million read pairs. Using HiC-Pro, the processing of the Dixon's dataset (397. 2 million read pairs split into 84 read chunks) was completed in 2 hours using 168 CPUs (Table  2 ). Each chunk was mapped on the human genome using four CPUs (two for each mate) and 7 GB of RAM Processing the 84 chunks in parallel allows extraction of the list of valid interactions in less than 30 minutes.
All chunks were then merged to generate and normalize the genome-wide contact map. In order to compare our results with the hiclib library, we ran HiC-Pro on the same dataset, and without initial read splitting, using eight CPUs. HiC-Pro performed the complete analysis in less than 15 hours compared with 28 hours for the hiclib pipeline. The main difference in speed is explained by our two-step mapping strategy compared with the iterative mapping strategy of hiclib, which aligned the 35 base pair (bp) reads in four steps. Optimization of the binning process and implementation of the normalization algorithm led to a three-fold decrease in time to generate and normalize the genomewide contact map. The IMR90 sample from the Rao dataset (1. 5 billion read pairs split into 160 read chunks) was processed in parallel using 320 CPUs to generate up to 5-kb contact maps in 12 hours, demonstrating the ability of HiC-Pro to analyze very large amounts of data in a reasonable time.
At a 5-kb resolution, we observe the presence of chromatin loops as described by Rao et al. [7]  (Figure  S1  in Additional file 1). The merged list of valid interactions was generated in less than 7. 5 hours. Normalization of the genome-wide contact map at 1 Mb, 500 kb, 150 kb, 40 kb, 20 kb and 5 kb was performed in less than 4 hours. Details about the results and the implementation of the different solutions are available in Additional file 1. Finally, we compared the Hi-C processing results of hiclib and HiC-Pro on the IMR90 dataset. Although the processing and filtering steps of the two pipelines are not exactly the same, we observed a good concordance in the results (Fig. 1 ). Using default parameters, HiC-Pro is less stringent than hiclib and used more valid interactions to HOMER  [10]  offers several programs to analysis Hi-C data from aligned reads.
a HiC-inpector  [12] , HiCdat  [13]  and HiC-Box  [14]  do not allow chimeric reads to be rescued during the mapping. HICUP  [11]  provides a complete pipeline until the detection of valid interaction products. It can be used together with the SNPsplit software  [15]  to extract allele-specific mapped reads. The hiclib Python library  [17]  can be applied for all analysis steps but requires good programming skills and cannot be used in a single command-line manner. None of these software enable very large amounts of data to be processed easily in a parallel mode. Note that HOMER, hiclib and HiCdat also offer additional functions for downstream analysis. In the case of HiC-Pro, the downstream analysis is supported by the HiTC BioConductor package  [28]  build the contact maps. The two sets of normalized contact maps generated at different resolutions are highly similar (Fig.
Implementation of the iterative correction algorithm We provide an implementation of the iterative correction procedure which emphasizes ease of use, performance, memory-efficiency and maintainability. We obtain higher or similar performance on a single core compared with the original ICE implementation from the hiclib library (Table  2 ) and from the HiCorrector package  [20]  (Table  3 ). The HiCorrector package provides a parallel version of the iterative correction for dense matrices. We therefore compared the performance of HiCorrector with the HiC-Pro normalization at different Hi-C resolutions (Table  3 ). All algorithms were terminated after 20 iterations for the purpose of performance comparison, as each iteration requires nearly the same running time. Choosing dense or sparse matrix-based implementation is dependent on the Hi-C data resolution and on the depth of coverage.
Although our implementation can be run in either sparse or dense mode, the available data published at resolutions of 5-40 kb are currently characterized by a high degree of sparsity. At each level of Hi-C contact map resolution, we compared our dense or sparse implementation with the parallel and/or sequential version of HiCorrector. Our results demonstrate that using a compressed sparse row matrix structure is more efficient on high resolution contact maps (<40 kb) than using parallel computing on dense matrices. As expected for low resolution contact maps (1 Mb, 500 kb), using a dense matrix implementation is more efficient in time, although the gain, in practice, remains negligible. The code for the normalization is available as a standalone package (https://github. com/hiclib/iced) as well as being included in HiC-Pro.
Allele-specific contact maps We used HiC-Pro to generate allele-specific contact maps for the human GM12878 cell line. Differences in paternal and maternal X chromosome organization were recently described, with the presence of mega-domains on the inactive X chromosome, which are not seen in the active X chromosome  [7, 21, 22]. We used HiC-Pro to generate the maternal and paternal chromosome X contact maps of the GM12878 cell line using the Hi-C dataset published by Selvaraj et al. [23]. Phasing data were gathered from the Illumina Platinum Genomes Project  [24]. Only good quality heterozygous phased  single-nucleotide polymorphisms (SNPs) were selected. The final list contained 2,239,492 SNPs. We then masked the human genome hg19 by replacing the SNP position by an 'N' using the BEDTools utilities  [25]  and generated the new bowtie2 indexes.
Intra-and inter-chromosomal contacts are calculated as a fraction of filtered valid interactions. b Boxplots of the Spearman correlation coefficients of intra-and inter-chromosomal maps generated at different resolutions by both pipelines. c Chromosome 6 contact maps generated by hiclib (top) and HiC-Pro (bottom) at different resolutions. The chromatin interaction data generated by the two pipelines are highly similar HiC-Pro is based on a fast implementation of the iterative correction algorithm. We therefore compare our method with the MES (Memory-Efficient Sequential) and MEP (Memory-Efficient Parallel) algorithms of the HiCorrector software  [20]  for Hi-C data normalization (hours:minutes:seconds). All algorithms were terminated after 20 iterations (see Additional file 1 for details).
In theory, a genome-wide interaction matrix is of size O(N 2 ), where N is the number of genomic bins. Therefore, applying a balancing algorithm on such a matrix can be difficult in practice, as it requires a significant amount of memory and computational time. The degree of sparsity of the Hi-C data is dependent on the bin size and on the sequencing depth of coverage. Even for extremely large sequencing coverage, the interaction frequency between intra-chromosomal loci is expected to decrease as the genomic distance between them increases. High-resolution data are therefore usually associated with a high level of sparsity. Exploiting matrix sparsity in the implementation can improve the performance of the balancing algorithm for high-resolution data. HiC-Pro proposes a fast sparse-based implementation of the iterative correction method  [17] , allowing normalization of genome-wide high-resolution contact matrices in a short time and with reasonable memory requirements.
A B Fig. 2  Allele-specific analysis. a Allele-specific analysis of the GM12878 cell line. Phasing data were gathered from the Illumina Platinum Genomes Project. In total, 2,239,492 high quality SNPs from GM12878 data were used to distinguish both alleles. Around 6 % of the read pairs were assigned to each parental allele and used to build the allele-specific contact maps. b Intra-chromosomal contact maps of inactive and active X chromosome of the GM12878 cell line at 500-kb resolution. The inactive copy of chromosome X is partitioned into two mega-domains which are not seen in the active X chromosome. The boundary between the two mega-domains lies near the DXZ4 micro-satellite.
In this way, HiC-Pro can also be used to complement other methods, for instance, by running the workflow from already aligned files, or by simply normalizing published raw contact maps. The main steps of the pipeline are implemented in Python and C++ programming languages and are based on efficient data structures, such as compressed sparse row matrices for contact count data. Using an adequate data structure allows the data processing to be sped up as well circumvents memory limitations. In this way, HiC-Pro allows a genome-wide iterative correction to be run at very high resolution and in a short time. Our normalization implementation exploits numpy's dense array format and fast operations, scipy's sparse matrices representation and Cython to combine C and Python to reach the performance of C executables with the ease of use and maintainability of the Python language.
Contact map storage Genome-wide contact maps are generated for resolutions defined by the user. A contact map is defined as a matrix of contact counts and a description of the associated genomic bins and is usually stored as a matrix, divided into bins of equal size. The bin size represents the resolution at which the data will be analyzed. For instance, a human 20 kb genome-wide map is represented by a square matrix of 150,000 rows and columns, which can be difficult to manage in practice. To address this issue, we propose a standard contact map format based on two main observations. Contact maps at high resolution are (i) usually sparse and (ii) expected to be symmetric. Storing the non-null contacts from half of the matrix is therefore enough to summarize all the contact frequencies. Using this format leads to a 10-150-fold reduction in disk space use compared with the dense format (Table  4 ).