dataesr/scientific-paragraphs-categorization huggingface dataset:
##reference_ac=assembly_accession The NCBI page on the Genome Assembly Model states  (NCBI, 2002) : "The assembly accession starts with a three letter prefix, GCA for GenBank assemblies […]. This is followed by an underscore and 9 digits. A version is then added to the accession. For example, the assembly accession for the GenBank version of the public human reference assembly (GRCh38. p11) is GCA_000001405. 26". Note these accessions are shared by all INSDC archives. Example: Reference genome assembly for barley (Hordeum vulgare) cultivar Morex version 2.
Contig field format The individual sequence(s) of the reference genome assembly are described in more detail in the #contig field(s). ##contig=<ID=ctg1, length=sequence_length, assembly=gca_accession, md5=md5_hash, species=NCBI Taxon ID> Each contig entry contains at least the attribute ID, and typically also include length, assembly, md5 and species. The ID is the identifier of the sequence contig used in the reference genome assembly. Length contains the base pair length of the sequence contig in the reference genome assembly. The assembly is the accession number of the reference genome. If the md5 parameter is given, please note that the individual sequence contigs MD5 checksum is expected, not the MD5 sum of the complete reference genome assembly. The species is the taxonomic name of the species of the reference genome assembly.
, 2015)  records) on the sample material is provided under the DOI  (Alercia et al. , 2018). If there are additional IDs like project or database IDs, they can be provided alongside the DOI as "ext_ID". They are strongly recommended if no DOI is available. If the material is held by a FAO-WIEWS recognised institution, the external ID consists of the FAO-WIEWS instcode, the genus and the accession number (see example 2). If the database is not registered with FAO-WIEWS, the DNS of the holding institution or laboratory, the database identifier, the identifier scheme and the identifier value should be provided (see example 3). For multiple external IDs the field should be used multiple times (delimited by commas). By default, the registry in the "ext_ID" field should follow the specification in Identifier.
Technologies such as containers or the provision of the entire data set and the analytical computing pipeline in a cloud environment could be a further step towards overcoming such problems  (Grüning et al. , 2018). The BioSamples database at EMBL-EBI stores samples metadata and allows their pre-registration; it provides unique, stable identifiers for each sample. BioSamples connects to other archives, enabling consistent tracking through time and assays of the samples and derived data. There are several ways in which the recommendations published here can find acceptance in the larger plant science community, each with its advantages and disadvantages  (Sielemann et al. , 2020). By working with BioSamples, Ensembl plants and EVA, we are introducing these ideas to the plant science community at a key point during the data submission process.
This will not change how smaller project or organism-based databases or variation data providers will operate, but hopefully can stimulate discussions about a higher level of FAIR for variation data. One approach to enforcing these recommendations on a larger scale would be to contact the major publishers with a critical mass of supporters and ask them to consider these recommendations as a prerequisite for submitting new manuscripts. In addition, one could also approach various communities of plant scientists who would commit to following these recommendations without further outside influence, similar to the adaptation of the FAIR principles. Both options are very time-consuming and labour-intensive, although the second option has tended to prevail in the past. Especially with regard to the reusability of the data and the possibilities to combine it with new questions, it offers the greatest incentive to be positive about such a broad introduction.
, 2021). It is relatively obvious that the timing of interaction with public repositories varies greatly depending on the purpose (registration of datasets, retrieval of identifiers, or updating of datasets) and is recommended to occur at the earliest possible date in order to use the persistent identifiers of the datasets in the further course of the analyses and thus avoid errors due to the use of short-lived internal identifiers. This approach to data management facilitates the submission of data for publication or at the end of the research project. Here, the situation often arises that the data steward, under time pressure, fails to submit the necessary (meta-)information to the public repositories. The submitted dataset therefore only consists of very generic and not meaningful metadata  (Toczydlowski et al.
, 2021). Such behaviour is the lesser evil compared to not publishing the dataset but can hinder its interoperability and reusability. During the peer review process, large and complex datasets often cannot be checked in depth by the reviewers. A wider use of automatic validations or checklists (such as those supported by BioSamples) that the metadata adhere to would enable reviewers and users to identify well-annotated datasets suitable for re-use. The FAIRness of datasets improves when the metadata fields defined here are collected and submitted. Indeed, findability is increased by the recommended persistent identifiers, which allow search engines to use this information to find linked datasets. For example, plant material and sample identifications, as recommended here, are used as germplasm filters in the FAIDARE search portal, allowing discovery of genotyping and phenotyping data containing the same plant material.
The accessibility of datasets remains unchanged, but interoperability is significantly improved. Indeed, the improved identification of common IDs for plant material through the use of the BioSamples infrastructure makes it possible to link and integrate distributed and heterogeneous datasets. Thanks to this facilitated interoperability, reusability through new analyses is also improved. For the stepwise FAIRification of a plant variant dataset, a recipe has been provided in the FAIR Cookbook that implements the recommendations presented here (https://w3id. org/faircookbook/FCB061). Adoption of these guidelines and best practices will help make plant genotyping data FAIR and provide new opportunities to advance our understanding of relationships between genotypic and phenotypic data.
Micha M. Bayer Information & Computational Sciences (ICS) group, James Hutton Institute, Dundee, UK In this opinion article, Beier and co-authors review the current procedures for submitting genotypic variation data to public archives and make a number of recommendations to improve the standardisation of submitted data in order to advance the FAIR principles in this area. They show with specific examples how metadata in VCF files could be improved and suggest additional fields that should be included in VCF-based data submissions. This is a very useful paper that should help stimulate further discussion and progress in this area. The presentation is systematic, clear, and thorough. I have a number of suggestions for improvement that should be implemented before indexing, but otherwise, I am very happy to recommend indexing.
3 revision and to provide some examples of how they could be used. How do they fit into the existing framework of data in EVA and ENSEMBL? ○ P. 7, section "Sample field format": Please include some detail on what the "registry" entailsis there a standardised way of creating/naming/referring to registries? ○ P. 9, bottom: Please provide a reference and/or URL for ELIXIR in the text here.
Finally, it should be noted that in future versions of VCF (v4. 4 and later) there will be efforts to overcome these shortcomings of the specifications to better represent structural variants in all their complexity (see the following pull requests on github: https://github. com/samtools/hts-specs/pull/465, https://github. com/samtools/hts-specs/pull/553). "Bioinformaticians who have directly performed the genotyping analyses and thus the creation of the VCF files will consider it a comparatively simple task to enter metadata directly into the file. " It would be helpful to specify what tools can be used (and how) to add metadata to VCF headers and how this can be done with minimal risk of getting ○ things wrong (e. g. mislabelling samples). Is manual editing of a header and replacing it with bcftools the best we have, or are there tools out there that can achieve this in a more foolproof/refined fashion? To our knowledge, there is no tool that could do this.
One possibility would be that read mapping tools are able to provide metadata on samples and write this data directly into the mapping files. To ensure that the metadata is not lost in the downstream analysis and calculation of all subsequent tools, these metadata fields would need to be known and would not be allowed to be overwritten/edited. In hindsight, this may be too ambitious to implement at this stage and it may make more sense to develop a tool capable of adding this metadata to the final VCF file before submission to public archives. We would like to highlight the role of VCF as a data exchange format in particular, this means that VCFs are in general the result of an analysis pipeline or exported resultset from a database (such as EMBL EVA). Manual maintenance of exchange formats, like JSON or XML-based formats can certainly not be excluded, but should rather be the exception.
From our point of view this would mean VCF-generating pipelines should implement necessary components for the user-friendly, correct registration of metadata. We have added a paragraph in the text highlighting the need for appropriate supporting tools or APIs for the validation of VCFs and in particular the VCF metadata. It would be beneficial to mention the ##META header lines for defining phenotype metadata that were introduced in the VCF v4. 3 revision and to provide some examples of how they could be used. How do they fit into the existing framework of data in EVA and ENSEMBL?.
○ The ##META meta-information of the VCF 4. 3 is used to define sample descriptors and not phenotypes in the sense of MIAPPE. They might be used for some of the elements listed in BioSamples checklists, such as the MIAPPE list used by the BioSamples Validator. But our approach was to include only the minimal identification metadata in the VCF (DOIs, ID lists) and rely on BioSamples for a detailed description of the sample. Regarding the ##META field: There is currently a discussion in the VCF community to remove this field completely from the specification (https://github. com/samtools/hts-specs/issues/558#issuecomment-829421610), and basically the trend is more moving towards outsourcing metadata to FAIR archives (like BioSamples). P. 7, section "Sample field format": Please include some detail on what the "registry" entails -is there a standardised way of creating/naming/referring to registries? ○ Thanks, we clarified this point in the paper.
○ Genotyping of large panels of genotypes or pan-genome projects depend on a wellstructured implementation of the necessary data handling processes according to the research data life cycle to allow quality and efficiency of resources as well as to ensure the long-term assured re-usability of the data. The use of process-oriented database-based solutions starting with material and sample description, the assignment of PUIDs for sequences and material, the machine-readable data processing in sequence laboratories and the ingestion into file storage systems, their registration in in-house databases and their final publication in central repositories, such as EMBL-EBI EVA, is an important task for medium to large institutions. The definition of clear specifications for data exchange formats and APIs provides the necessary framework to allow sufficient freedom for technologies.
1. Why is gVCF excluded? Are there reasons that prevent the direct transfer of this VCF standard to gVCF? 2. The introduction mentions a few variant calling databases. What about 1001 genomes GMI-MPI vcf (https://1001genomes. org/data-center. html)? Several variant datasets for Arabidopsis thaliana are also hosted on https://jbrowse. arabidopsis. org/. It is only for Arabidopsis but considering the importance of this model it should be mentioned that genomic variation data is often hosted on organism-specific databases (which is in itself a problem of format unification). GVM, for example, does not host Arabidopsis VCFs presumably because they are found in their own database.
11. It would be good to mentioned other examples of VCF containing databases besides EVA and GVM. Even though they are the main ones, one of the biggest issues with metainformation is that you have "straggler" databases in niche fields/organisms that do not adhere to the format. 12. With respect to the tools automatically changing information about variant positions: Can this be monitored in any way? It is not reasonable to expect, e. g. EVA to check this and presumably it is databases that would need to enforce these standards. Would a list of common programs that change this help to avoid issues? 13. Additional meta-information fields: a) "findability and interoperability": To reiterate a comment above -reusability (at least, if not also accessibility) would be enhanced by these metadata standards.
19. The authors focus on plant VCF and EVA. However, considering these standards are sorely needed in other areas/databases and that VCF formatting should be fairly universal, the authors might want to consider a broader application of these standards. This could be 20. discussed. There is mention of individual components but a more direct discussion would be beneficial. We added explicit FAIR principles discussion in the discussion to clearly state the improved Findability, Reusability and Interoperability. 2. Why is gVCF excluded? Are there reasons that prevent the direct transfer of this VCF standard to gVCF? We added some remarks, showing these recommendations can be directly transferred to gVCF. There is nothing that would exclude the use of our recommendations with gVCF. 3. The introduction mentions a few variant calling databases.
What about 1001 genomes GMI-MPI vcf (https://1001genomes. org/data-center. html)? Several variant datasets for Arabidopsis thaliana are also hosted on https://jbrowse. arabidopsis. org/. It is only for Arabidopsis but considering the importance of this model it should be mentioned that genomic variation data is often hosted on organism-specific databases (which is in itself a problem of format unification). GVM, for example, does not host Arabidopsis VCFs presumably because they are found in their own database. We added some remarks regarding this in the manuscript. 4. The introduction assumes that the reference genome sequence is supported by Ensembl, but what to do if it is not available? In the case where the reference genome sequence is not yet in Ensembl the VCF cannot be displayed (within Ensembl).
However in such cases Ensembl would try to prioritize adding the missing genome if it is in the public archives. This should not be confused with EVAs requirement of needing a genome assembly supported by INSDC. 5. Considering that phenotype standards are the only provided example, it does not seem like the most useful comparison. The data type/collection/prevalence etc. is very different to VCF. More examples would be needed to emphasize shared elements of various standards (for example, SAM/BAM flags). It is true that MIAPPE, and thus the phenotyping standard, was not intended to characterize genotyping analyses or VCF files. It has been used to enable interoperability with genotyping dataset through shared objects and IDs. It is also true that in order to create a VCF file, there must be one or more mapping files (SAM/BAM) that record the differences and similarities between the genotypes under study and the reference genome assembly.
Since there are a large number of different workflows to create a VCF file, our intention was to make the final result FAIR and not necessarily cover all intermediate steps with our suggestions. What all genotyping experiments have in common is that samples are obtained from physical material that is currently poorly described. It is precisely this point that is better addressed and makes it possible to link different experiments and analyses based on the material used with the recommendations presented here. MIAPPE offers a well-designed framework for this and is also ideally suited for the plant domain. 6. One statement about VCFs should be checked: "one or more data lines". It does not make much sense to share such a file, but the VCF file could be empty i. e. no lines with data. We agree that sharing such a file would not make much sense, still it would be a perfectly valid VCF file according to the specifications.
This wording is taken directly from the specifications. 7. "well-formed" could be explained in more detail. We have adjusted the text to make this clearer. 8. It might be better to use bioinformatics_source to include a complete description of the data processing in the VCF file. Otherwise, there is the risk that data sets cannot be re-used due to broken links. Some data sets might be the result of unpublished protocols hence it will be impossible to link to a publication. For example, the data set and the workflow might be part of the same paper. This is a valid concern, but we cannot see that embedded documentation will ensure a sustainable, comprehensive and FAIR documentation of a workflow that enables a reprocessing in 10 years. For example, used software needs to be referred to using PUIDs or links.
9. RefSeq instead of GenBank might be preferentially entered by some groups so this needs to be screened/specified. Again, what happens if the reference genome sequence is not publicly available (yet)? Fig. 2  nicely points out that we must also consider a not-yetpublished reference used by a lab to adhere to this standard by registering their reference. It would be good to mention this in the description of the respective field as well. The complete described pipeline builds upon deposition of genotyping information at EVA, which needs a published genome assembly accession number. That is one of the reasons Fig. 2  also tries to highlight that the genome assembly needs to be deposited and an accession number received before being able to proceed to the next step. We updated the text to make this more clear.
org/faircookbook/FCB061. 11. "genome" should be replaced by "genome sequence" at several places in manuscript. This is about different assembly version of the same accession so the genome remains the same, but the quality of the representation improves. Indeed, a good catch. We updated the manuscript to be more precise. 12. It would be good to mentioned other examples of VCF containing databases besides EVA and GVM. Even though they are the main ones, one of the biggest issues with metainformation is that you have "straggler" databases in niche fields/organisms that do not adhere to the format. In this paper, we focused on the use case of EMBL-EBI submissions and their use of VCF in collaboration with BioSamples and EVA. We are not aiming at an extensive review of all possible VCF submissions and publishers.
We added some remarks in the discussion regarding adoption of the metadata recommendations in the broader community. 13. With respect to the tools automatically changing information about variant positions: Can this be monitored in any way? It is not reasonable to expect, e. g. EVA to check this and presumably it is databases that would need to enforce these standards. Would a list of common programs that change this help to avoid issues? We are not aware of any programs that change the position or other characteristics of variants, but programs such as PLINK are known to define the variant within a genotyping study with the major allele as the reference and the minor allele as the alternative, regardless of the base present in the reference genome assembly. However, PLINK has an option to use the reference allele, and EVA often asks to correct this at the time of submission.
EVA also consistently validates each VCF file that is submitted to the archive. Validation compares the reference allele to the reference genome sequence, most likely detecting misplaced variants. It is technically possible for misplaced variants to still match the reference, but in practice this method will detect most of these errors. A list of common programs that work in a similar way to PLINK would be very welcome. However, we do not believe that this would completely avoid this problem, since such a list is not easy to maintain (based on new versions, programs, workflows) and could lull the user into a false sense of security if other programs were used. We would therefore rather urge caution and diligence when using programs that interact with VCF files. 14. Additional meta-information fields: a) "findability and interoperability": To reiterate a comment above -reusability (at least, if not also accessibility) would be enhanced by these metadata standards.
The impact/implications to VCF FAIR would fit the narrative in here and in the conclusion. b) "metainformation lines": Indeed, and some some suggestions, e. g. from the barley example are needed. a) We added reusability in the listing and expanded on the FAIRness of data in the discussion part. b) Information, such as further metadata about the person who analysed the data or collected the plant material and the prevailing environmental conditions (e. g. contact information, tools used, temperature or humidity), would be examples of additional metainformation fields that were not explicitly recommended by us, but in some scenarios make sense to include additionally. 15. "genotypic and other data from plants": What are these other data? Please specify if this would be phenotypic. Since the sample description would be uniform, this could be applied to all kinds of different data.
This includes phenotypic data but also other -omics layers, like transcriptomic data, metabolomic data and so forth. 16. "Analytical results should be linked out to the respective sample(s) and defined in the context of the study being reported. ". this could be a bit more specific. We have updated the text to be more precise. 17. It does not become clear how the paragraph about BioSample database at EMBL-EBI contributes to the conclusion. Currently, it is only about phenotypic data and a connection to VCF would be helpful. We have updated the wording to clarify that the plant metadata stored at BioSamples does not necessarily have to be of phenotypic origin. 18. Re-use is a very important aspect of missing/insufficient metadata consequences. It could be emphasised more as a major benefit of adopting this type of VCF standardisation.
We agree with this statement and have added this throughout the manuscript. 19. More specific portals for adoption would be beneficial to mention in the conclusionshould all databases adopt these guidelines, should journals make sure the data referenced in the paper adheres to them, etc. ? Enforcement is a major hurdle of adopting metadata (and data) standards that adhere to FAIR (see our paper,  Sielemann, Hafner & Pucker, 2020). We agree with the concerns raised in Sielemann, Hafner & Pucker, 2020, and one of the solutions they offer is improvement of metadata standard which is what this paper tries to accomplish.