dataesr/scientific-paragraphs-categorization huggingface dataset:
Implementation COPO is primarily a Python application. At the time of writing, COPO runs on a Python 3. 5. 2 interpreter with Django 2. 0. 2 as the web framework. Python was chosen as it is a well used and documented language with an active development community. This ensures there are mature libraries for common tasks (such as web development, data loading or ingestion, visualisation, tabular data manipulation, statistical analysis, natural language processing, etc. ), as well as cutting edge libraries for modern data science (such as Pandas, scikit-learn, TensorFlow and Numpy/SciPy). Python integrates easily into system-level scripting and is therefore suitable for "glue" projects where many components need to interoperate, such as web service platforms. The Django web framework was chosen to handle the server side duties of COPO, as it is a tried and tested off-the-shelf solution used by many web services across the international academic, commercial and industrial sectors.
JSON is a common data representation format for many public APIs due to its simplicity and readability. Libraries for manipulating JSON exist for most if not all commonly used programming languages 26. Both Postgres 9. 6 and MongoDB 3. 4 databases are used for backend storage: Postgres for structured data such as housekeeping tasks related to Django (user accounts, sessions etc); and MongoDB to store the COPO JSON data objects and metadata. MongoDB is a NoSQL database, i. e. the schema does not need to be predefined, facilitating the support of highly heterogeneous metadata without the need for complex schema design. Data files (e. g. raw sequence data, images, PDFs) uploaded to COPO are held on an Isilon storage array -a robust, scale out network-attached storage (NAS) solution for high-volume storage, backup and archiving of unstructured data  27.
COPO currently benefits from a shared access to over 3. 4 petabytes of storage space on this platform, which provides it with the scope to manage the large volume of data brokered through the system. iRODS 4. 1. 11 28 is a framework for abstracting and federating data storage or repositories in a way that promotes data virtualisation, data discovery, data policy automation and secure collaboration across sites. The use of iRODS is being tested in COPO in order to provide a storage solution that is agnostic of any specific hardware resource architecture. The user interface (UI) components of COPO have been developed primarily using the Javascript jQuery 2. 1. 4 library and the Bootstrap 3 framework. Additional javascript UI libraries used include DataTables 1. 10. 18 for displaying and paginating lists of data, Semantic UI 2.
4. 0 for UI controls such as buttons and sliders, Handsontable 7. 1. 0 for displaying spreadsheet type data, and Fuel UX 3. 12. 0 for creating the COPO wizards. Operation COPO has been dockerized therefore a standard development implementation can be easily built and run. Download the latest version from https://github. com/collaborative-open-plant-omics/COPO/releases and follow the instructions in the README. md file. Minimum requirements vary depending on the work the COPO instance will be running, but for development, we recommend at least 2GB of RAM and 2 CPU cores. The installation method has been tested on Ubuntu 18. 04 and OSX 10. 14. We recommend using Firefox.
Phenomics data. Collection and deposition of phenotypic experiments is partially supported. The MIAPPE (Minimal Information About Plant Phenotyping Experiments) schema is implemented to collect the required metadata for such experiments. At the time of writing, there is currently no formal repository into which of these data can be deposited. However, the EMBL-EBI have recently announced their BioImaging repository  33  , which is able to accept any image-based phenotyping datasets. Submission will be supported in an upcoming COPO version. Agriculture data. The CG Core metadata schema 34 is implemented in COPO as a pilot for agricultural data annotation for the 15 Consultative Group on International Agricultural Research (CGIAR) agricultural research for development centers. A more generalised version of this implementation will soon be more widely available for other entities wanting to describe agricultural data.
CG Core is a minimum metadata specification based on the Dublin Core standard to collect descriptive metadata on agronomic, plant breeding, socioeconomic, genomic, and other agricultural information products. Each of the 15 centres store their datasets and publications on centre-specific publicly accessible digital repositories based on one of three repository software implementations, i. e. DataVerse, dSpace or CKAN (see below). The CG Core schema allows consistent description of these data assets for easier discovery and access. We describe this in more detail in the Use Case section. Other scholarly data types. COPO can be used to annotate other information types such as images, presentations, figures, text documents, and PDFs. The Dublin Core metadata specification 35 is also employed for these, and submission is supported to institutional instances of Dataverse 36 , DSpace 37 or CKAN 38 , all of which are free, open-source, off-the-shelf repository applications.
Deployment architecture The COPO infrastructure is currently housed within the CyVerse UK virtual infrastructure 42 , supported by the Earlham Institute (EI) National Capability in e-Infrastructure (EI NCG NC3)  43. COPO uses the Docker 44 containerisation software to house the service deployments, i. e. MongoDB, iRODS, the Django web application and the project website. These Docker containers are managed using Docker Swarm technology to ease orchestration, deployment, and load-balancing challenges (see Figure  3 ). A default swarm configuration is supplied with COPO, but deployment will need certain properties set by a system administrator, i. e. COPO has a central management node that handles the configuration and setup of the swarm, where system administrators need to supply storage volumes, secret keys, and service definitions for swarm worker nodes.
Once the required sample objects have been created, the user uploads their sequence data. COPO will compress (gzip) data files if this has not already been done. The user can then choose a number of files to describe simultaneously in a "bundle", whereby bundled files are labelled with the same metadata. For example, if there are 50 samples and 50 corresponding files in a bundle, the user only has to go through the description wizard once. Users can also work with unbundled datasets which is useful if the metadata is heterogeneous, e. g. if each data file being submitted is from a different organism or sequenced using different sequencing technologies. The metadata fields which are displayed in the wizard are constructed in line with the schema of the target repository for which the submission is intended.
In doing so, the burden of managing metadata revisions, as well as the minimum set of requirements, from different repositories is removed from the researcher and offloaded to COPO. Once the metadata description wizard is complete, the user can then view the metadata for all the files and change any values which are not common in a spreadsheet-like tabular user interface. In the wizard the user also defines which corresponding files each sample object relates to. This is a time-consuming task for researchers as care has to be taken to ensure samples are exactly matched to output files, and COPO aims to reduce errors by making simple sanity checks on sample attribution to data files (number of samples per file, duplicated samples, R1 and R2 files for paired end sequencing experiments, etc).
Upon completion, the user is taken to the submission page, where they are shown a progress indicator. During the submission process, the required metadata (in this case ENA submission, study, experiment, run and, as required, analysis XMLs) is produced, the datafiles are physically transferred to the ENA servers, the metadata is validated, and the submission completed (see Figure  4 ). To our knowledge, COPO is one of the first web-based service implementations of the new EMBL-EBI ENA command line validation client  46. The validation process is very resource intensive and the public COPO instance uses the CyVerse UK HPC cloud environment 42 to undertake validation. COPO supports the ENA embargo process whereby researchers can upload data and metadata but not yet make the data public, typically waiting for a publication to be submitted.
In any case, ENA accessions for the submission are stored in COPO and are available to the user to publish, and for others to search once public. An example COPO-submitted ENA project can be found under the accession PRJEB30905. Use Case -Submission of CGIAR data to custom data repositories Digital repositories used by CGIAR centres are hosted locally in some cases, and centralised in others, depending on the repository platform and the centre. Metadata for information resources (typically datasets and publications) are entered by the different data curators and information specialists in each centre. The objective of the CG Core metadata schema is to harmonise descriptions of agricultural resources across the CGIAR centres through a minimum metadata set to maximise discoverability and interoperability.
COPO provides a unique entry point to the different systems to guarantee that the metadata are captured in a unified way across the different centre repositories. COPO user interfaces are generated based on the CG Core specification, with the advantage of providing data validation checks while the metadata are entered by the end user. COPO captures the full metadata set of the CG Core, although some data repositories only accept a subset of it. By retaining this metadata alongside links to these repositories, COPO improves the provenance of these records despite the full CG Core metadata not being supported by institutional repositories themselves. This is a by-product of repositories effectively being legacy systems, where either the repository wants to remain general to reduce metadata requirement overload, or highly specific but not able to future-proof any and all possible metadata specifications arising from a community.
Managing this extra metadata becomes important for specific internal reporting, where metadata needs to be recorded in a harmonised way, i. e. donor information. Thus in future, as COPO is not intended to be a repository in its own right, we will also submit these additional metadata fragments to a public repository, e. g. Zenodo 47 , to mint DOIs for the metadata and support data citation (where data is published with a unique identifier, a short publication is written to describe that dataset, and a DOI is minted to allow citation of that dataset to demonstrate use). The full metadata information can then be used by GARDIAN 48 , the CGIAR metadata harvester and aggregator that allows users to discover datasets and publications using rich queries. The integration of COPO and GARDIAN aims to improve user experience to search across the CGIAR information products (see Figure  5 ), based on the implementation of core ontologies to describe those products  4.
Both technical solutions and coordinated community efforts will be required to manage future datasets and the legacy data that resides in individual group workstations and databases which are no longer actively maintained or curated. The open source movement in the life sciences is a powerful force, with tools and algorithms developed continuously and released via websites such as Github and Bitbucket. Funders are particularly interested in the impact of algorithms, software tools, and databases to further bioscience. These, including web-based systems, can be submitted as first-class research outputs in many grant reporting platforms, e. g. the United Kingdom Research and Innovation (UKRI) ResearchFish 51 system. However, data citation is still a novel concept, and the cost of curation is perceived to be high relative to the cost of producing datasets, particularly raw data generation such as nucleic acid (genome, transcriptome, etc) sequencing.
Easing the "FAIRification" of data and enabling the tracking of its impacts can be invaluable for their predestined communities. Further work will enable a rich set of search APIs within COPO to allow users to more accurately track where their data has been used. The correct ontologies and terms to use to annotate data might not be immediately obvious to researchers, nor where the data should be deposited. FAIRsharing 56 works to fill this gap by providing concrete guidance and tools to enable discovery and use of the appropriate terminology, metadata and data standards. It can also help users determine repositories that implement those standards and which journal and funder policies recommend them. However, individual researchers must still search for and assimilate this information. Finding the relevant standards and repositories is only the first step, and institutions may employ dedicated research data managers to help researchers take the next step of annotating data using community standards.
Data management employment positions are rare and very specialised to a given domain of knowledge. Therefore, there remains a professional chasm between researchers who know they need to manage their research data, the tools that are available to allow them to do it, and the people with the epistemological expertise to assist them  57. Data brokering systems can help greatly to bridge this gap and help researchers realise the practical aspects of sharing FAIR data. Many years of experience developing the ISA framework and related semantic architectures has shown us that standards-driven annotation and data reformatting for brokering purposes needs to be "made invisible" to users in order to promote uptake. This idea can be brought into line with recent thinking around how to rework the Hierarchy of Needs to something more like a "Hierarchy of Changes"  58.
COPO is firmly at the "Make it normative" stage, i. e. COPO has been designed with usability in mind, and we have used numerous focus groups to gain feedback on features and the main metadata wizards within the system. We have also presented COPO at events organised by large public data repository managers such as the EMBL-EBI ENA to ensure COPO complements and exploits the submission tools provided by such resources. Normalising semantic metadata attribution at the researcher and data manager level in COPO means that we now need to consider the "Make it rewarding" and "Make it required" stages. Rewards and incentives for good behaviour help reinforce learning and behavioural change in humans. However, the incentive and reward structures are not yet in place for data (as opposed to journal) publication  57.
Therefore, to make research data truly FAIR, the scientific community needs to address how sharing and reuse of information outputs is both valued and how it adds value to research in a particular domain. Crop breeding, for example, is an area where standardisation efforts and FAIR data have huge potential to modernise and revolutionise research and applied technological solutions for food security  59, 60. These changes are fundamental to allow the application of modern data integration and interrogation approaches and tools to help unlock the value of knowledge held in disparate research groups, institutions, and communities.
Conclusions COPO is a semantic metadata annotation and data brokering platform, initially designed to ease data curation and submission to public repositories for plant scientists. However, as it allows for the flexible selection, constraint, and use of any public or user-specified ontology, COPO is applicable to any domain of knowledge, and has already been customised for agricultural data assets through work with the CGIAR System for international agricultural research for development. As well as a free-to-use central production installation running at the Earlham Institute, COPO is open source under the MIT licence, and therefore freely usable by any institution for their own research data management needs. The tool is packaged in Docker containers for both easy testing and deployment in production.
COPO aims to address both the "first mile" and "last mile" of data management to make research outputs FAIR: the former, where users are able to address the final stages of preparing data for publication, is an often-overlooked resource-intensive part of the publication cycle; and the latter, where research objects are sufficiently described and made freely available for others through public or institutional repositories. community (as well as be a test for how well COPO works on the discoverability side of FAIR. ) However, I could not find any search function in COPO for published datasets. COPO has been in production for several years. Please provide some statistics on usage and adoption of COPO. Mandatory changes: It needs to be made very clear that COPO is helping only with data submission by giving researchers appropriate tools for metadata population and curation.
the rationale for developing the new software tool clearly explained? YesIs the description of the software tool technically sound? YesAre sufficient details of the code, methods and analysis (if applicable) provided to allow replication of the software development and its use by others? YesIs sufficient information provided to allow interpretation of the expected output datasets and any results generated using the tool? PartlyAre the conclusions about the tool and its performance adequately supported by the findings presented in the article? Yes No competing interests were disclosed. Competing Interests:Reviewer Expertise: Plant Genome Evolution, Comparative Genomics, Cyberinfrastructure for Life Science Research.
Davey RP Administration, Resources, Supervision, Validation, Writing -Original Draft Preparation, Writing -Review & Editing No competing interests were disclosed. The initial  COPO  project was funded by a  BBSRC Biological and Bioinformatics Resources (BBR)  grant ( BB/L024055/1 , Grant information:  BB/L024101/1 ,  BB/L024071/1 ) and is now funded by the  BBSRC Core Strategic Programme  grant awarded to  Earlham Institute  ( BBS/E/T/000PR9817 ). COPO is hosted within the CyVerse UK academic cloud, funded by  BBSRC  ( BB/M018431/1 ,  BB/R000662/1 ), and run within  EI's National Capability in e-Infrastructure  ( BBS/E/T/000PR9814 ). In addition to the  BBSRC COPO  grant, SAS, PRS, ABG and DJ were funded by  BBSRC  ( BB/L005069/1 ),  Wellcome Trust  ( 212930/Z/18/Z ,  208381/A/17/Z ),  European Union  ( H2020-EU.
3. 1, 634107 ,  H2020-EU. 1. 4. 1. 3 , 654241 ,  H2020-EU. 1. 4. 1. 1 , 676559 ),  IMI  ( 116060 ) and  NIH  ( U54 AI117925 ,  1U24AI117966-01 ,  1OT3OD025459-01 ,  1OT3OD025467-01 ,  1OT3OD025462-01 ). SAS is also funded by the  Oxford e-Research Centre, Department of Engineering Science of the University of Oxford. The computational hardware that underpins this capability is supported by a  BBSRC   Core Capability Grant  to EI, and managed by the  Norwich Biosciences Institutes Partnership (NBIP) Computing Infrastructure for Science (CiS)  group at the  Norwich Research Park. The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript.
The Ontology Lookup Service: more data and better tools for controlled vocabulary queries. Nucleic Acids Res. 2008; 36(Web Server issue): W372-W376. 35. DCMI: Dublin Core. Reference Source 36. The Dataverse Project -Dataverse. org. Reference Source 37. DSpace -A Turnkey Institutional Repository Application. Duraspace. org. Reference Source 38. ckan: ckan. Reference Source 39. figshare -credit for all your research. Reference Source 40. Reed RB: figshare for Institutions. J Med Libr Assoc. 2016; 104(4): 376-378. Publisher Full Text | Free Full Text 41. Harvard Dataverse. Reference Source 42. CyVerse UK -CyberInfrastructure for life science. Reference Source 43. National Capability in e-Infrastructure. Earlham Institute. 2018. Reference Source 44. What is a Container? | Docker. Docker. PubMed Abstract | Publisher Full Text | Free Full Text 32.
González-Beltrán A, Maguire E, Sansone SA, et al. : linkedISA: semantic representation of ISA-Tab experimental metadata. BMC Bioinformatics. 2014; 15(Suppl 14): S4. PubMed Abstract | Publisher Full Text | Free Full Text 33. BioImage Archive -a new hub for biological images. Reference Source 34. AgriculturalSemantics: AgriculturalSemantics/cg-core. GitHub. Reference Source PubMed Abstract | Publisher Full Text | Free Full Text 30. The ISA-JSON format. Reference Source 31. Sansone SA, Rocca-Serra P, Field D, et al. : Toward interoperable bioscience data. Nat Genet. 2012; 44(2): 121-126. Reference Source 45. Federhen S: The NCBI Taxonomy database. Nucleic Acids Res. 2012; 40(Database issue): D136-D143. PubMed Abstract | Publisher Full Text | Free Full Text 46. European Nucleotide Archive: webin-cli.
GitHub. Reference Source 47. Zenodo -Research. Shared. Reference Source 48. GARDIAN. Reference Source 49. Hannay T: Stop the deluge of science research. The Guardian. 2014. Reference Source 50. Mazzocchi F: Could Big Data Be the End of Theory in Science? A Few Remarks on the Epistemology of Data-Driven Science. EMBO Rep. 2015; 16(10): 1250-5. PubMed Abstract | Publisher Full Text | Free Full Text 51. Researchfish: Research Impact Assessment Platform. researchfish. Reference Source 52. Six.
The behaviour of hydrogen isotopes in ITER monoblocks was studied using the code FESTIM (Finite Element Simulation of Tritium In Materials) which is introduced in this publication. FESTIM has been validated by reproducing experimental data and the Method of Manufactured Solutions was used for analytical verification. Following relevant plasma scenarios, both transient heat transfer and hydrogen isotopes (HIs) diffusion have been simulated in order to assess HIs retention in monoblocks. Relevant materials properties have been used. Each plasma cycle is composed of a current ramp up, a current plateau, a current ramp down and a resting phase before the following shot. 100 cycles are simulated. The total HIs inventory in the tokamak during resting phases reaches × 1. 8 10 mg 3 whereas during the implantation phases it keeps increasing as a power law of time.
PFCs could then be unable to exhaust heat from the plasma and could even be damaged by local melting. In the present work, a code named "Finite Element Simulation of Tritium In Materials" (FESTIM) based on Macroscopic Rate Equations (MRE) has been developed. This tool is built upon the previous work made on MHIMS by Hodille et al. [7]. As in previous studies  [8, 9] , this new code relies on FEniCS  [10]  and Finite Element Methods. FESTIM is able to simulate the diffusion and trapping of HIs as well as heat transfer in 1/2/3D multi-material domains, which allows to simulate laboratories experiments as well as PFCs in realistic tokamak environment. Section 2 describes the physical model chosen for the tool. We will then detail in Section 3 both the experimental validation and analytical verification of the code.
1 is = S r f x (1 )• • ( ), ext r being the reflection coefficient (i. e. the proportion of particles which are reflected from the surface to the plasma), φ the incident ion flux in m •s 2 1 and f(x) a Gaussian distribution with R p its mean value and gma its width. The parameters of f (x) are determined with the software SRIM  [18]. This phase lasts t imp and the temperature is = T T imp. The second phase is the resting period where the source is turned off (i. e. = S 0 ext ) for a time t rest at = T T rest. Finally, the last period is the TPD where temperature is increased linearly with a given heating ramp β. In order to fit the experimental results, three traps are needed: two intrinsic traps and one extrinsic trap to account for the creation of ioninduced defects during the implantation.