dataesr/scientific-paragraphs-categorization huggingface dataset:
Tip 2: Understand the phases of the project Systems biology projects, like all large projects, have distinct phases, (Figure  1 ). From the perspectives of both data and sample management (generation, distribution, use, and storage of both) and team communication (project portals, document sharing, file archives, listservs, online meeting hosting, and/or a realtime experimental dashboard), it is important to be prepared and adaptable. The DMCIT must participate in experimental planning, analysis and publication discussions. Otherwise, unexpected 'new' datasets, data production delays, SOP alterations, or the need for accession numbers or data digital object identifiers (D. O. I's) for a dataset to cite in a paper, can catch the DMCIT by surprise, affect progress, and cause anxiety. The MaHPIC had a leadership and research team that was understanding of the project's data needs and ensured the DMCIT had both an adequate budget and a 'seat at the table' for project-wide discussions and decisions.
It is important to consult experts within and beyond the project, especially those with experience integrating data like yours. Gather their dos and don'ts and incorporate them into your decision making. As an example from the MaHPIC, information on the daily routine care of animals (e. g. , technician access, diet, medications), and the timing of such, provided understanding of possible physiological or metabolic observations. Leadership's strategic decision to support collecting this data and the team's support in overcoming the technical hurdles to do so, repeatedly benefited downstream analyses. 'Ephemera' collection and integration eventually became standard practice and part of new staff training. But, How do you discover and account for as many sources of data and metadata as possible? It is wise to adopt a motto of 'Investigate everywhere, trust nothing, test everything'.
Tip 4: Manage data stewardship, inside and outside the project The DMCIT may need to train the project in best practices for data stewardship. It is vital to instill and foster a sense of scientific duty related to making data FAIR (Tips 8 and 9). Successful efforts will promote efficient production, validation, and analysis of data. Engagement begins with full immersion in the data generation process, including documentation of the provenance of all samples, files, results, and analyses, as well as the gathering of metadata and SOPs. You may be tasked with quality control of results to ensure the proper format, content, and integrity of results for downstream consumption. Maintaining provenance is essential. Validation of results places the DMCIT on the front lines of ensuring the integrity of the data and potentially as the last line of defense if you are also tasked with deposition to public repositories.
It is important to know when instruments were calibrated or software programs updated. If these points seem overreaching, consider an early 'signal' detected in the MaHPIC project data that was traced back to an instrument repair as opposed to biology, underscoring the importance of recording such analytical metadata. The eventual resolution of this signal reinforced the need to collect and understand the impact of these types of information. In another scenario, two 'versions' of a dataset were being analyzed (same results, but different formal sample naming/IDs) resulting from one group utilizing the official validated project repository and one group utilizing 'back channels. ' Such well-intentioned efforts could prove costly, requiring time and resources to identify the problem and ensure that only validated data is being analyzed within and ultimately outside the project.
Ideally, a DMCIT will assume the role of 'honest broker', releasing data internally to the project and externally to the community. This requires policies aligned with funding requirements to be created, agreed to, and followed by all. Data sharing, with trusted provenance and high standards of accuracy, like the results they produce, will be recognized and rewarded through re-use and data citations. New programs should consider creating a project charter and set of data sharing principles (Tip 6). In the MaHPIC, group leadership decisions made early in the project were faithfully implemented, and extra attention was then needed to best ensure they were enforced in the face of any transitions of people joining or leaving the project. The DMCIT quickly recognized the need for formal rules and leadership supported the implementation and training.
People A DMCIT needs the 'right' people. It will need programmers and database administrators, perhaps software engineers. It will need members who can understand the biology and scientific project goals and who can liaise between those building the cyberinfrastructure and those using it. Bioinformaticians, adept at the keyboard and bench, may be available. If not, recruit staff to ensure that all required skills are present and promote project-wide training to fill gaps. If the project does not have an official project manager the DMCIT may need someone with experience to organize and oversee communication and related needs. The DMCIT should be known for two things: 1) coordination of policies and SOPs to facilitate communication and the flow of data between institutions and larger community and 2) the cyberinfrastructure and tools they provide to implement those policies and needs (Figure  2 ).
Hardware, cyber connections, and security Needs will vary but servers and storage will likely be needed. Hardware may need to be redundant to provide enhanced data security (FIPS) and (FISMA) and guard against data analysis and access downtime. Infrastructure to support relational databases as well as fast and slow data storage may be needed. Periodic vulnerability scans and system adjustments to address emerging security issues may be required. Secure data access agreements between institutions to support encrypted data transfer may be required. Persons involved in data transfer within and between institutions should coordinate to understand these needs early. Within the MaHPIC, human data were de-identified, transferred securely and released in accordance with IRB protocols. Huge files (up to 700 GB) were moved between institutions and daily ' dumps' of a Laboratory Information Management System (LIMS) were transferred, formatted, and provided to animal technicians and veterinarians and compiled in a project database and dashboard.
Software Use existing software for data management, code versioning, data analysis, communications, etc. ,  (Taschuk and Wilson, 2017)  to avoid 're-inventing the wheel'. This will allow you to innovate when needed. When innovation is needed, determine project requirements and build a prototype first, allowing the intended users to review before progressing too far into development. The earlier the DMCIT provides value the sooner they will have the opportunity to innovate. Within the MaHPIC, software support needs ranged from collaborative writing, team chat, online meetings, data storage and retrieval (including text documents like Institutional Animal Care and Use Committee and IRB approvals and funder progress reports), to SOP documentation and code. Collaborative writing and data storage within subgroups were without specific policies other than ensuring that data security and back-up plans were in place.
Larger team writing efforts and data storage were restricted to agreed platforms that could accommodate large numbers of simultaneous writers. If possible, leverage existing life science cyberinfrastructures. Several mature cloud-based platforms for data storage, management, and even analysis are available. Amazon Web Services is one. CyVerse  (Merchant, et al. , 2016)  is a National Science Foundation-funded national cyberinfrastructure project with freely available resources and training from web-based data management and analysis, to fully customizable APIs. SAGE bionetworks provides an open science platform including Synapse to help researchers collaboratively aggregate, organize and share their data.
File formats and data storage The nearly universal data and metadata format within the MaHPIC was the tab-delimited file. Notable exceptions included RNA-Seq and proteomics files, flow cytometry, and some blood chemistry. Templates were created for each data type, versioned, and linked to SOPs and data dictionaries. All data files for were validated and shared internally via an iRODS (iRODS-Consortium, 2019) file repository. This open source solution was chosen because it provided data access via dozens of mechanisms, thus suiting a diverse user audience.
Sample tracking Sample tracking can be challenging, especially for a large multi-institutional project like the MaHPIC. A LIMS will generate a barcode and record sample creation and its relationship to an experimental subject and condition. A barcode reader can log a sample's movements in and out of an institution or laboratory. However, unless all players are linked to the LIMS these movements are only known to the owner of the scanner until the DMCIT is informed of sample movement through other means. This system worked fine for the MaHPIC from the perspective of the data, but it was less than ideal for live status updates with respect to the physical movement of samples and their associated data through the project. The MaHPIC utilized a custom project dashboard to meet this need but this did not provide multi-institutional sample tracking in real time.
Automation It is critical to automate the flow of data or redundant time-consuming activities wherever possible. Automation (checked often for correct functionality) facilitates focus elsewhere. Work with data producers to eliminate manual data entry wherever possible. The MaHPIC automated transfer of clinical data from an analysis instrument to computer, saving hours of technician time previously used for manual double data entry (error checking). Carefully consider all data being collected and how you can leverage institutional resources to automate.
It will range from data production and analysis SOPs, meeting minutes, data sharing guidelines, dataset READMEs that detail nuances of the files, team rosters and contact information, MOUs, MTAs, etc. You will need a systematic approach to manage your team's documentation infrastructure and it must be accessible across institutions and by team members with different skillsets. This is a vital part of a cyberinfrastructure. Do not rely on email for document storage or a record of project activities. Consider a content management system (CMS) for storage, and a plan for document organization. Access to some files may be restricted to your leadership and administrators, so permissions will be an issue. For SOPs consider a 'wiki' approach but discuss who will be able to create and edit the content.
Select a collaborative writing platform that will provide your team with the flexibility to simultaneously edit documents. You will need to budget for these services, which means planning for them before experiments begin. The ease of usability of your documentation platform(s) will directly affect if and how they are used, and this can be a major factor in team efficiency and morale. Tip 8: Integrate the data to facilitate use, discovery, and public deposition Individual datasets will likely become part of larger analyses. Within the MaHPIC, a discrete dataset was usually a specific data type (RNA-seq, immune profiles, metabolomics, etc. ) from a specific experiment designed to investigate specific hypotheses. Each dataset was useful on its own, but when combined for mathematical modeling at the experimental level, including leveraging clinical metadata they provided an unprecedented level of molecular detail about host-pathogen interactions resulting from Plasmodium infections  (Cordy, et al.
, 2019 , Gardinassi, et al. , 2018 , Joyner, et al. , 2019 , Tang, et al. , 2018 , Tang, et al. , 2017). This was possible because of the integration of the datasets within and across experiments made possible by FAIR data practices (Tips 4 and 9). Integration can have varied definitions. It may mean the formatting, organization, and storage of results to facilitate their analysis in parallel. Simply designing folder and file names to allow humans and algorithms to identify where they 'fit' in the grand scheme is a good start. Structured README files and supplementary documents that detail accessory facts about datasets, which versions of software and reference genomes were used, what other datasets are available or being produced, etc. will also be helpful. Organized and annotated datasets will facilitate their analysis and rudimentary automated processing of their contents.
Integration can also take the form of a relational database. How data are processed and stored for later consumption will be critical. If similar data types are to be compared across experiments, it will be important to know if normalization, standardization, batch effect correction, etc. were conducted to allow ' apples to apples' comparisons. Some consumers will need 'raw' results, preferring to process data themselves. Data producers and consumers must know and agree what 'raw' means. Provenance, validation, and metadata will play key roles. For example, if comparing transcript abundances, protein levels, and metabolites between samples, it is critical that electronic results are associated with the physical samples from which they were derived and that there is sufficient information to distinguish technological artifact from biological reality.
The MaHPIC supported data integration through a novel database schema entitled Scientific Knowledge from Data, SKED  (Trippe, et al. , 2017a) , which uses ' data primitives' to enable the programmatic creation of custom datasets and analyses that can be applied over diverse data types  (Trippe, et al. , 2017b). Unless you are reading this in the future when data integration is a solved issue, you will have additional challenges and opportunities to consider as you prepare to publicly deposit project data. The integrated datasets you produced will likely have to be separated, like slices of a pie, and deposited in repositories that specialize in specific data types (if they exist). For example, NCBI's SRA  (Leinonen, et al. , 2011)  for RNA-seq, EBI's MetaboLights  (Haug, et al. , 2013)  for Mass Spec, ImmPort  (Bhattacharya, et al.
, 2014)  for immunology data, etc. Repositories have unique criteria. Some require only minimal free-text metadata forms and will simply host files. Others have optional batch submissions, and programmatic transfer of data and metadata, and require integration of metadata into domain-specific controlled vocabularies and ontologies. READMEs, supporting documentation, and carefully planned and collected metadata are all important for data deposition and re-use. Many journals require data be public before publication, or even manuscript review. Understanding repository requirements early, and agreement from your funder as to what data will be made public, when, and where, is important. Repositories do not exist for all data types, e. g. , MaHPIC's animal clinical data. It may be difficult for future consumers to recreate the larger experimental picture, i.
e. , the 'whole pie' that produced a 'slice'. Consider providing a persistent website with a list of all public datasets and experimental descriptions, associated publications, and explanations of your project and its products. See MaHPIC's manifest of publicly available datasets (PlasmoDB-MaHPIC). Ontologies are important for public data deposition and integration, but availability and comprehensiveness vary. In genomics, they are mature, with years of community input, and include a core set of terms to describe a 'study  ', ' experiment', 'gene', etc. Other fields are less developed, the rules are few, and the guideposts shift as communities discuss, test, and refine core concepts. You may have to accommodate needs across this spectrum. This can be a challenge, but can provide an opportunity to take a leadership role, in partnership with ontologists and your data producers, shaping minimum data and metadata standards within a community.
Investment up front will pay dividends in the future as the data can be more easily identified, reused, and integrated  (Kazic, 2015). Tip 9: Make a strong and sustained debut by publishing and depositing project data Project datasets will outlive the project. Sustained presentation of project results from the perspective of the 'whole pie' will foster their discoverability and reuse. Building on Tip 8, make sure you know your funder's repository requirements, work to understand repository standards early, and proactively contact repository staff with questions. Repository staff may be receptive to an alignment of goals. Those supporting emerging data types may want to increase their visibility and you may be able to help. They may be willing to assist your project with training in metadata collection, dataset organization, and the submission process.
Tip 10: Be flexible and grow with the project Likely you will need to adapt to emerging challenges and opportunities. Staff changes, new technologies, and discoveries may necessitate swift changes. An adage recently expressed by funding officials to describe MaHPIC research and its complexity is, "Build the car while you are driving it. "; i. e. , keep moving with confidence at a fast pace despite lacking all pieces of the research puzzle. This mindset has been particularly useful for the MaHPIC, as a large fast-paced demanding systems biology consortium. Momentum has been critical, as well as delivering timely results and meeting project milestones, plus providing publicly available data for outside analysis. Build your project culture, communication, documentation, data flow, analysis, etc.
with these considerations in mind. The MaHPIC DMCIT was well-supported by the consortium's leadership and anticipated many challenges and opportunities. Still, in hindsight, what would we do differently, or better? Naturally, each new endeavor will bring new unknowns. For sure, we would aim to meet with each data producer early on and ask them to fully describe their experimental and analysis pipelines to ascertain every point where automation could make their life easier and reduce errors (Tip 3). As an example, during such discussions with MaHPIC members, we realized that some investigators were scaling data production and analyses using standardized methods developed for much smaller projects. Specifically, one group was using an instrument that only produced a PDF data file. The data from printed PDFs were being manually entered into spread sheets.
The DMCIT wrote a custom program to parse the printstream from the application and populate the database, removing considerable manual effort and preventing potential error. As ' creatures of habit', if left alone, we can remain unaware of potential solutions with potentially transformative effects. Exploring ways to increase efficiency, reduce error, and increase provenance is clearly useful early and often. Time spent assessing and transforming manual data steps may reward an entire project by reducing errors, increasing provenance, and creating more time for the science. Finally, the time lapse between the planning and execution of a wet-lab experiment, the generation of in silico results, the writing of a paper and dissemination of the data, can be long. From the beginning, think about and enable the future! In an idealized scenario, project data would be curated in perpetuity and all SOPs, READMEs, and project metadata would be machine accessible, semantically annotated and selfdescribing to maximize their future utility.
Acknowledgements We give our heartfelt thanks to the  MaHPIC consortium  for growing with us during this project and for sharing their needs and gratitude over the years. Membership in the  MaHPIC Consortium (MaHPIC ,  2019 ) over the 2012-2017 five-year period of  NIAID  support has included:  Dave C Anderson ,  Dalia Arafat ,  Sophia Banton ,  John W Barnwell ,  Steven E Bosinger ,  Patrick Breen ,  Robert Bridger ,  Cristiana Brito ,  Jung-Ting Chien ,  Julia Crutchfield ,  Megan Bass DeBarry ,  Christopher Duncan ,  Valerie Flint ,  Luis L Fonseca ,  Patricio Gallardo ,  AnaPatricia Garcia ,  Luiz G Gardinassi ,  Swetha Garimalla ,  Diego Giraldo ,  Anuj Gupta ,  Trenton Hoffman ,  Chris Ibegbu ,  Jianlin Jiang ,  Xuntian Jiang ,  Dean P Jones ,  Manoj Khadka ,  Amy Kong ,  Rachel Kutner ,  Miriam Lachs ,  Tracey J Lamb ,  Stacey A Lapp ,  Kevin J Lee ,  Frances Eun-Hyung Lee ,  Noah Legall ,  Shuzhao Li ,  Loukia Lili-Williams ,  Tim Morris ,  Douglas P Nace ,  Gregg Orloff ,  Dan Ory ,  Mariko S Peterson ,  Jan Pohl ,  Sarah T Pruett ,  Zhen Qi ,  Matthew Reed ,  Jorge L Salinas ,  Celia L Saney ,  Ignacio Sanz ,  Maren R Smith ,  Stephanie Soderberg ,  Andrew Spruill ,  Hannah Stealey ,  Amy K Stout ,  Olga Stuchlik ,  Mark P Styczynski ,  JoAnn Sullivan ,  Yan Tang ,  Gregory K Tharp ,  Rabindra Tirouvanziam ,  ViLinh Tran ,  Christopher Tseng ,  Karan Uppal ,  Eberhard O Voit ,  Douglas Walker ,  Susanne Warrenfeltz ,  Brent Weatherly ,  Lance Wells ,  Tyrone Williams ,  Zerotti Woods ,  Weiwei Yin , as well as the authors of this manuscript.
Data Accessibility Statement Data referred to in this manuscript are organized and accessible at the National Institutes of Health, Bioinformatics Resource Center, PlasmoDB  (Aurrecoechea, et al. , 2009)  that is part of EuPathDB  (Aurrecoechea, et al. , 2017 ) via a permanent central organizing site (PlasmoDB-MaHPIC) that contains the datasets with DOIs or links to the data in recognized archival databases, e. g. NCBI.
We chose to work with Mantle Cell Lymphomas (MCL) because several studies have reported elevated HML-2 expression in blood cancer patients and leukemia cell lines  [12, 31]. We used three MCL cell lines expressing the potential TAA: JVM2, Granta519 (G519) and REC1. The first two lines are from early stage cases of MCL and the latter is from a late (indolent) stage. We also compare the general pattern of HML-2 provirus expression to other studies of cell-associated HML-2 expression and some whole transcriptome datasets from the same cell lines available from NCBI's SRA (Short Read Archive). Studies of putative virion-associated HML-2 expression  [32, 33]  are excluded because such expression differs markedly from cell-associated expression in the source cells  [34].
Env-encoding proviruses make up 10% of total HML-2 transcription The eight Env-encoding proviruses made up 2% of the total HML-2 transcripts in REC1 and between 5 and 21% of the total transcripts in JVM2 and G519 (normalised using RPKM values -Reads Per Kilobase of transcript per Million mapped reads, Table  2 ). They also accounted for 13-14% of the (normalised) HML-2 reads from Illumina whole transcriptome RNA-Seq datasets of JVM2 and G519 cell lines downloaded from the SRA (Additional file 2), although the total number of reads  mapping to HML-2 in each was much lower (only 1500-8000) than in our enrichment. We find high relative expression across cancers of some Env-encoding proviruses (Fig. 4 ). Provirus 12q14. 1 is highly expressed in a single lymph metastasis and the tandemly repeated provirus 7p22.
1). This finding is supported by an examination of the long reads that map reliably or which contain unique SNPs (Table  3 ), although the numbers here are low. The reason for this difference is that our eight Env-encoding proviruses differ from each other by only 1. 5% on average at the nucleotide level. Many short reads therefore map equally well to multiple proviruses (illustrated in Additional file 4), and are randomly allocated to these by the default settings in the Bowtie2 program used in our analysis. Such reads contrast with those that map to a single provirus best (= uniquely mapping reads). No long reads map equally well to more than one provirus, but their high error rate leads to the same effect. This artefact can be removed by excluding long reads with low mapping quality (although this leaves us with only a few mapped reads).