dataesr/scientific-paragraphs-categorization huggingface dataset:
The MIxS descriptors can be combined with any environmental package and together provide rich information on sampling context. To illustrate, Table  1  summarizes the minimum set of elements required for description of a metagenomic sample taken from an aquatic environment. It uses MIMS mandatory descrip- tors, combined with the mandatory descriptors of the Water Environment package. Similarly, a sample taken from the gut of a fish host can be described using the MIMS core descriptors, in combination with descriptors in the host-associated Environment package. The 15 different environmental packages defined by the GSC are available from the GSC website as a single bundled download  [12]  and are presented in a host of informatics tools that support data reporting and presentation, such as the submission tools of the databases of the International Nucleotide Sequence Database Collaboration  [13]  and ISAtools  [14].
It remains up to the experimentalist to choose the most appropriate package from within the checklist bundle for their study, thereby defining the list of fields that will be used to capture relevant metadata. Before embarking on a metagenomics study, we recommend that the appropriate checklist be identified, so that the appropriate metadata can be captured during the experiment, rather than retrospectively having to determine these metadata. The Marine Microbial Biodiversity Bioinformatics and Biotechnology (M2B3) data reporting and service standard  [15]  specifically addresses contextual data relating to marine microbial samples. It represents a common denominator of contextual data from data standards used in the Public Genomic Data Archives (MIxS, version 4. 0)  [12] , Pan-European Network of Oceanographic Data Archives (Common Data Index schema, version 3.
The importance of the optional MIxS and M2B3 fields for metagenomic data analysis is detailed in Table  3. We wish here to note a convention on the handling of replicate samples. Since biological replicates are separate physical entities, we recommend that multiple sample records are registered, 1 for each biological replicate, with reciprocal references represented as a sample attribute with the name "biological replicate" and attribute value provided as the accession number(s) of the related biological sample(s). In contrast, "technical replicates," for which only a single sample exists, are treated downstream in the workflow. Consistent and rich contextual data can become a powerful tool for metagenomics data analysis. Two marine studies, the TARA Oceans sequencing study (PRJEB402)  [18]  and Ocean Sampling Day (OSD; PRJEB5129)  [19]  both use the same M2B3 contextual data reporting standard, enabling comparison of data within and across studies.
For instance, data from the TARA Oceans shotgun sequencing of the prokaryotic fraction filtered from seawater (PRJEB1787)  [20]  can be compared to the shotgun data from OSD (PRJEB8682)  [21] , enabling detailed or complex queries. Specifically, a taxonomic or functional profile from the TARA Oceans sample from a depth of 5 m and salinity of 38 psu (SAMEA2591084)  [22]  can be compared to profiles of the OSD sample from a depth of 5 m (SAMEA3275502)  [23]  or the OSD sample with the same salinity of 38 psu (SAMEA3275531)  [24]. In contrast, very few conclusions can be drawn from a comparison to a sample with insufficient contextual information (SAMN00194025)  [25]. Details of the project investigators are usually recorded in the Study metadata object, and sampling contextual data are mostly captured in the Sample metadata object (Fig.
) The most common formats for sharing Study and Sample metadata are Extensible Markup Language (XML), tab-separated values, ISA-tab, or JavaScript Object Notation formats. Examples of the Study and Sample XML are available from the European Nucleotide Archive  [26, 27] , where the files are also validated against the XML schema  [28]. Regardless of the format used to supply the metadata, because they all use the same underlying standards, a simple translation between the formats enables different data to be compared. This allows scientists to use the different tools or approaches that they are most familiar with, whilst ensuring consistent delivery of the metadata.
Sequencing Once a sample is collected and its provenance recorded, it is subjected to preparation steps for nucleotide sequence analysis. This may happen immediately after sampling or in stages over many months. Processing steps cover all handling of the sample leading to the DNA isolation. Although MIxS covers some of the metadata fields for reporting the DNA extraction steps, it is extremely difficult to define a generic set of fields describing the DNA extraction method with a high granularity due to its complexity and diversity. For example, it might be relatively straightforward to identify variables for reporting isolation of DNA from a seawater sample, but that will not suit the more complex DNA isolation procedure for a sediment sample. We suggest the best practice here is to use the existing MIxS fields, such as sample material processing, nucleic acid extraction, and nucleic acid amplification, for concise description of the nucleic acid preparation.
A detailed description, or a reference to the material preparation steps recorded in a data resource that specializes in protocol capture and dissemination, such as protocols. io [29] , is important due to the significant influence this can have on the observed profile of the microbial community under investigation. Equally critical for the downstream metagenomic data analysis and interpretation is the reporting of sequencing library preparation protocols and parameters as well as sequencing machine configurations. Table  4  shows mandatory descriptors for new generation nucleotide sequencing experiments as currently captured by International Nucleotide Sequence Database Collaboration (INSDC) databases. Table  5  lists nonmandatory descriptors including MIMS sequence-related descriptors and provides our opinion on the importance of these descriptors for metagenomic data analysis.
Note that while a number of controlled vocabularies have been developed for accurate recording of sequencing experiment parameters, the evolution of these constrained vocabularies is very dynamic and driven by technological advances. Variable parameters of the library preparation and instrumentation are captured in the metadata objects Experiment and Run (see Fig. 2 ). Examples of the Experiment and Run XML are available, e. g. , from the ENA  [30, 31]. Each Experiment should refer to Study and Sample objects, to provide context for the sequencing, and is referred to from the Run objects, which point to the primary sequencing reads. The primary data (the reads) are stored in files of various formats, which can be standard (Binary Alignment/Map [BAM], Compression Reduced Alignment/Map [CRAM], or Fastq) or a platform specific, as with standard flowgram format (SFF), PacBio, Oxford Nanopore, or Complete Genomics.
Information on the read data format must be indicated in the description of sequencing. The minimum information encapsulated in read data files includes base calls with quality scores. Quality requirements on read data files are file format specific and are summarized, e. g. , in the ENA data submission documentation  [32]. A freely available diagnostic tool for the validation of CRAM and BAM files is the Picard ValidateSamFile  [33]. Validation of Fastq files is less straightforward since there is no single FASTQ specification. Recommended usage of FASTQ can be found, e. g. , in the ENA guidelines  [34]. An open resource for managing next generation sequencing datasets is the NGSUtils  [35] , which also contains tools for operations with FASTQ files. As sequencing technologies change over time, the formats and associated validation tools may well change, so a comprehensive list of formats.
Analysis Standards in metagenomics for the description of sampling and sequencing have grown out of those from more traditional genomics. While there are still some shortcomings in these standards, as highlighted in the previous sections, metadata concerning sampling and sequencing are commonly captured for metagenomics studies. Compliance is high partly due to the scientific journals requiring scientists to submit sequence data to an INSDC database prior to publication. However, there are currently no standards for reporting how metagenomics datasets have been analysed. While systematic analysis workflows, such as those offered by EMG, Integrated Microbial Genomes with Microbiomes  [36] , META-pipe  [37] , and MG-RAST, provide a standard that is documented (albeit in different ways), many published datasets are analysed by in-house bespoke pipelines.
Although many authors provide an outline in the "materials and methods" or "supplementary materials" section of their publications, it is rarely possible to reproduce the analysis from this alone, due to missing software parameters, lack of detail on software versions, and ambiguous reference databases and their associated versions. Typically, once the sequence read files have been produced, they are analysed using 1 or more workflows  [38] , with each workflow comprising different data processing or analysis components. Most workflows involve aspects such as quality control (e. g. , removing sequences that fail to meet predefined quality scores), assembly, sequence binning (e. g. , identifying 16S rRNA genes or protein coding sequences), and taxonomic classification of sequences and/or functional prediction.
However, each workflow will be tailored to how the sample has been processed and the question being addressed. For example, if a sample has been size-fractioned for viruses using a 0. 22 μm filter, there would be little point analysing the data for eukaryotic 18S rRNA as any eukaryotic organisms would have been physically removed from the sample before the DNA extraction process. Analysis workflows typically have 1 or more of the following components: (i) central algorithmic software, which may be from a thirdparty source; (ii) "glue" software that may ensure input/output formats or split/join input files for parallelization; (iii) reference datasets that are used by (i). For example, the Greengenes database of 16S rRNA genes  [39] , SILVA database of 16S/18S small subunit ribosomal RNA genes  [40] , and the National Center for Biotechnology Information nonredundant database of nonidentical protein sequences  [41] , for taxonomic or functional analysis.
However, even knowing these elements may not be sufficient for analyses to be independently recreated. For example, the algorithm may accept a set of input parameters that can be used to fine-tune an analysis, such as selecting an E-value threshold for determining the significance of a sequence match to a reference database. Other parameters may influence speed-performance, which allows the original analysis to complete in a timely fashion, but they may or may not have an effect on the results. For example, running hmmsearch from the HMMER package, changing the number of central processing units (CPUs) used will not change the results, but changing options on the heuristics such at the -F1 threshold (which controls the number of sequences passing the first heuristic state) may alter the output; both will potentially increase performance in terms of speed.
Capturing and reporting all provenance information is essential to understand exactly what analysis has been performed on the data and to ensure reproducibility  [42]. The use of publicly available analysis pipelines (such as EMG, MG-RAST, or METApipe) helps with this process since analysis is performed using predefined components, settings, and databases (or, in some cases, using user-selected components, selected from a predefined list of options). Nevertheless, capturing analysis metadata remains essential as, e. g. , MG-RAST allows the users to dynamically set E-value thresholds after the pipeline analysis has been performed. Furthermore, the tools, libraries, and reference databases used by the pipelines are regularly updated, and thus capturing analysis provenance information is vitally important and should be systematically "tagged" to the results.
To date, there is no universally endorsed "analysis standard" for describing and recreating a metagenomics analysis pipeline, and without this standard (and subsequent adoption/enforcement), it will continue to be difficult, if not impossible, to reproduce analysis workflows. However, all is not lost. "Workflows" and their definitions is an active field of computer science research, and potential solutions are already available, including Common Workflow Language, Yet Another Workflow Language, Business Process Execution Language, and Microsoft Azure's Workflow Definition Language, to name but a few. Several of the co-authors for this publication already participate in the GSC M5 consultation group, which aims to define a standard enabling the recreation and exchange of metagenomics datasets.
In the absence of a standard, we believe it is important to define some of the basic best practices, which an accepted standard would formally encapsulate. For simplicity, we will fo-cus on a single "best practice" use case: the description of the analysis of a run. Other types of analysis, such as pooling of runs or comparing results between runs, are beyond the scope of this article. A schematic overview of a best practice for analysis metadata collection is shown in Fig. 3A. An overarching set of metadata relating to analysis should encapsulate generic information such as analysis centre, name of bioinformaticians, analysis objectives, name of overall analysis (if appropriate), and the date on which the analysis was performed. It should also contain appropriate pointers to the run data, run sequence metadata, and associated sample data.
Underneath the overarching analysis metadata is a collection of analysis components that describe each stage of the analysis (Fig. 3B ). Each component can be divided into 3 sections: input(s), analysis algorithm, and output(s). The input section should describe the details of the various inputs to the analysis, which could be the raw sequence reads or the output of another analysis component, and reference databases and their provenance data, such as version, where necessary. The analysis section should contain the algorithm tool, version, all parameters used, and a basic description of the analysis. The output section should describe each output from the analysis, together with a description of contents and format. Each analysis component could then be coupled to form an analysis workflow, as shown in Fig.
3C. The workflow may be in a portable intermediate format that can be submitted to a workflow manager for execution in a specific environment. This best practice framework is merely that-a best practice, and we have not touched on the technical issues of how to capture this information or on controlled vocabularies (since these need to come from the community). Furthermore, enforcing compliance and validation against the standard will also require a community effort. Complete validation would require the standard to be machine readable and deployable, with potentially the need to have small "test" datasets and their associated results to perform regression testing of the analysis metadata. However, who is responsible for validation and what happens if something fails after publication are open questions.
Analysis Results Archiving-A Final Piece? Having an analysis provenance standard would allow metagenomics analysis results to be recreated more readily. While this is undoubtedly an important and necessary step, it has a major limitation within the community. As indicated  [43] , the fraction of money spent on informatics from an overall project budget is increasing dramatically. Metagenomics datasets tend to be large, in the order of gigabyte-terabyte (TB), and processing may take thousands of CPU hours, restricting reanalysis to only those with significant compute resources. For example, the subset of the TARA Oceans Ocean Microbiome Project (PRJEB7988)  [44]  that has been size-fractioned for prokaryotes comprises 135 samples with 248 runs containing 28. 8 billion reads. The analysis output represents about 10 TB of data, with 23.
2 billion predicted protein coding sequences. Thus, reanalysis would be costly and potentially wasteful if a particular workflow had already been run on the data. Therefore, a final step in a metagenomics analysis is the appropriate archiving of results. There is an obvious cost-benefit balance to be drawn here as storing every intermediate of a workflow would lead to an explosion of data. Clearly, key intermediates and outputs of an analysis workflow need to be determined. These key archived components will be tailored to the analysis, but should at least include operational taxonomic unit counts and assignments, functional assignment counts, and read/sequence positional information for the aforementioned assignments. Such data files are already made available from MG-RAST and EMG, and those from other sources are accepted for archiving within ENA.
If metagenomic assemblies have been performed, then these should have an appropriate structure of contigs, scaffolds, or chromosomes with an appropriate format as detailed, e. g. , in the ENA data submission documentation  [45]. Due to the overheads of producing an assembly, these should be archived, ideally with an INSDC database. The data model for metagenomics, as described in Fig. 2 , represents metagenomic analysis results in the data Analysis object with appropriate pointers to the corresponding run sequence metadata and associated sample collection contextual data. While there is an established practice to archive primary sequence data in the Run object and assemblies of the primary sequences in the Analysis object, it is not a common practice to archive results of functional and taxonomic metagenomic analysis of in-house bespoke pipelines.
It would be beneficial to the metagenomics community to include this in the best practice, and such data are accepted by ENA for archiving. The metagenomics standard environment reviewed here as well as outcomes of the GSC M5 consultation group can contribute to defining required descriptors of the Analysis object for archiving of metagenomics analysis results, which can serve as a framework for the exchange of metagenomics datasets on a routine basis, similarly as is currently done for the primary sequence data.
Future One challenge over the next several years will be the validation of compliance across the entirety of the standards and best practice that we have covered. While validation tools and recommended practices exist for parts (e. g. , contextual data descriptors using MIxS-compliant validation tools from ISA and experimental descriptors upon submission to an INSDC database), not all parts have such maturity (e. g. , analysis descriptors) and there exists no overarching validation protocol for an entire metagenomics study. The GSC is aiming to contribute in this area with the introduction of MIxS "profiles" to provide an overlay on top of MIxS environmental packages and the core MIxS fields. These profiles will enable the creation of tool suites for compliance checking. In addition (and perhaps more importantly), they will enable groups of researchers, institutes, funders, and other communities to define levels of compliance for contextual datasets.
Examples of this are the National Science Foundation National Ecological Observatory Network  [46]  and the National Science Foundation Critical Zone Observatory  [47]  networks that are working with the GSC to establish silver, gold, and platinum sets of parameters that need to be provided and validated for datasets to be compliant. A key moment in the acceptance of said new profiles will be the availability of tool support for data creators, end-users, and portals. Imagine, e. g. , a search for datasets in EMG or MG-RAST that allows restriction of the search to just platinum-level datasets. For the data consumer, this will result in better ways of telling their science story using third-party data, and for the data creator, this will provide guidance on what to create for a specific community.
In addition, funding agencies can require certain minimal compliance. A further area to be addressed is that of standards around descriptions of metagenomics analyses. The creation of a lightweight data standard for an Analysis object that allows easy transfer of analyses is a key goal of the GSC M5 initiative, but the complexity of the task and lack of dedicated resourcing has rendered progress slow; while frameworks and systems for recording analysis provenance need to be established, we have aimed to indicate in this publication a set of indications for best practice that can form the foundation for a community standard enabling the recreation and exchange of metagenomics datasets. Improving standardization will also help raise clarity in the literature around metagenomics through a tightening of language.
For example, Ultrafast Protein Classification  [48]  uses Pfam  [49]  matches as a reference library, with the results being referred to as a "Pfam hit. " However, this may not necessarily be a Pfam hit as a Pfam hit is defined as a sequence match scoring greater than the Pfam-defined threshold to the Pfam profile Hidden Markov Model (i. e. , the Pfam database method).
Conclusions In this overview of the metagenomics standard environment, we have outlined best practice for the reporting of metagenomics workflows. We have reviewed the essential steps: (i) material sampling, (ii) material sequencing, (iii) data analysis, and (iv) data archiving, and highlighted essential variable parameters and common data formats in each step. Reporting on the provenance of a sample and associated nucleotide sequence data is largely established by public sequence data repositories and is also being addressed by contextual data standardization initiatives. In contrast, a reporting standard on metagenomics data analysis is absent, yet the high complexity of metagenomics creates a pressing demand for establishing such a practice. Capturing key metadata relating to analysis would greatly improve reproducibility.
The OpenStreetMap (OSM) geographic data model has three principal object types: nodes (points), ways (polygons and polylines), and relations (logical grouping of all three object types to express real-world geographical relationships). While there has been very significant analysis of OSM over the past decade or so, very little research attention has been given to OSM relations. In this paper, we provide an exploratory overview of relations in OSM for four European cities. In this exploration, we undertake analysis of relations to assess their complexity, composition and flexibility within the OSM data model. We show that some of the patterns discovered by researchers related to OSM nodes and ways also exist in relations. We find some other interesting aspects of relations which we believe can act as a catalyst for a more sustained future research effort on relations in OSM.
Introduction The OpenStreetMap (OSM) project and database have both received increasing research attention from academics and analysts over the past number of years. The majority of geocomputational research reported has focused on the OSM database and the OSM data model. The OSM geographic data model is reasonably easy to understand. There are three principal data object types: nodes (points), ways (polygons and polylines), and relations (logical grouping of all three object types). At the time of writing in August 2017, in the global OSM database, there are over four billion nodes, over four hundred million ways, and over five million relations  [1]. Nodes and ways have been the subject of the most intense research investigation while there has been limited work reported or published on relations in OSM.