dataesr/scientific-paragraphs-categorization huggingface dataset:
Evaluation The 2019 TNLS county-level statistics of five provinces (Inner Mongolia, Heilongjiang, Sichuan, Yunnan, and Shaanxi) were used as evaluation datasets for the optimized LULC area share to prove the effectiveness of the proposed map optimization method. The five provinces selected for validation purposes are situated on both sides of the Hu line  (Hu 1935 ), a demarcation line in China that reflects spatial differences in the natural environment and socioeconomic development in China. These provinces boast rich, topographic variations and diverse LULC types, indicating that the validation results more accurately reflect the performance of the optimization method across different ecological and environmental conditions. Based on the mapping and optimized results of the 2019 LULC map, the land area for each LULC class was obtained for each county in the five provinces.
Annual LULC changes in China during 2016-2022 The LULC maps from 2016 to 2022 were produced using the proposed update methodology that involved utilizing Landsat images coupled with the advanced change detection methods of CCDC and LandTrendr and the random forest classification algorithm. These maps were updated based on the original CLUD-A dataset that provided the foundation for this study. The latest map for 2022, which shows the current LULC patterns, is presented in Figure  4 , and the maps for 2016-2021 are illustrated in Figure  S1. Moreover, the original CLUD-A dataset  was merged with the updated maps to create the updated  CLUD-A (1980 CLUD-A ( -2022)). To confirm the consistency of the updated maps with the original CLUD-A dataset and the reasonableness of the LULC changes, the annual area changes for various LULC types between 2010 and 2022 were analyzed, and the results were compared to those of the CLCD and ESA CCI LC (Figure  5 ).
Notably, the area changes in Figure  5  may differ from the reported results owing to differences in the classification systems. Because the updated CLUD-A was completed between 2016 and 2022, the red dashed vertical lines in Figure  5  were used to compare the changes that occurred before and after 2015. The updated CLUD-A displayed smooth changes in different LULC types compared to the original dataset, with no unreasonably abrupt changes observed. Moreover, the annual area change trend of the updated CLUD-A was similar to that of the CLCD and ESA CCI LC, demonstrating the potential of the LULC updating method. Furthermore, the analysis revealed that cropland and grassland areas in China have continuously decreased since 2015, with decline rates of 1. 94% (3. 31 million ha) and 1. 08% (3.
LULC map update performance To obtain the annual accuracy of the updated LULC maps, annual validation samples were generated based on the migration results from the FAST dataset. The annual sample size is shown in Figure  6. The FAST dataset was collected primarily in 2014 and 2015, resulting in a larger sample size for these two years. Because the LULC maps for 2016-2022 were obtained based on the 2015 CLUDs product, the classification results for 2010-2015 of CLUD-A were included when calculating the annual accuracy to reflect the continuity of the classification results. Figure  6  shows that the overall accuracy of the updated CLUD-A maps remains stable after 2015, indicating a high level of consistency and continuity with the original product. This accuracy stability highlights the robustness of the methodology, ensuring that the results are reliable and consistent for practical temporal analysis and monitoring of LULC changes.
Discussion This study aimed to develop LULC map updating and optimization methods using Landsat imagery and land survey statistics. The results show that the proposed method provides an efficient and reliable framework for updating the maps of existing LULC products. Additionally, considering the generalizability of the CCDC, LandTrendr, and random forest algorithms in this method and the high global coverage of Landsat imagery, our method can potentially be extended to other 30m LULC products. For products with coarse spatial resolution, such as the 500-m MCD12Q1 dataset, matching 500-m MODIS imagery should be used in the updating framework. However, for 10-m products, such as ESA WorldCover, the change detection results should be given more attention, considering the time-series fitting difficulties due to the shortage of Sentinel imagery before 2017.
Conclusions This study presents a comprehensive framework for updating and optimizing LULC products using a combination of continuous LULC monitoring and national land survey statistics. The proposed method involves integrating change detection results from CCDC and LandTrendr, which are used as the foundation for potential change areas. Subsequently, a sample migration method and a random forest classifier were used to update the LULC product of CLUD-A from 1980-2015 to 1980-2022. The updated maps show smooth changes compared to the original dataset, indicating the effectiveness of the proposed approach. Additionally, this study introduced a statistics space allocation-based map optimization method using the IDW algorithm and minimum cross-entropy formulation based on SNLS and TNLS statistics.
Computational reproducibility is a simple premise in theory, but is difficult to achieve in practice. Building upon past efforts and proposals to maximize reproducibility and rigor in bioinformatics, we present a framework called the five pillars of reproducible computational research. These include (1) literate programming, (2) code version control and sharing, (3) compute environment control, (4) persistent data sharing and (5) documentation. These practices will ensure that computational research work can be reproduced quickly and easily, long into the future. This guide is designed for bioinformatics data analysts and bioinformaticians in training, but should be relevant to other domains of study.
A similar survey of R scripts in the Harvard Dataverse repository found slightly better results, with 26% of scripts completing without errors  [8]. The ramifications of irreproducible and unreliable research includes misleading the community, wasting research funds, slowing scientific progress, eroding public confidence in science and tarnishing the reputation of associated institutions and colleagues. In clinical research, irreproducible bioinformatics has the potential to place patient safety at risk. For example, in 2006 an article entitled "Genomic signatures to guide the use of chemotherapeutics" generated a great deal of interest as it was an early application of high throughput transcriptomics in the prediction of individual patient responses to different chemotherapies  [9]. After observing some unusual features of the patient group, Baggerly and Coombes attempted reproduction of some of the key findings  [10].
Without the help of scripted workflows to guide the re-analysis, the team used forensic bioinformatic techniques to piece together how the dataset was originally analyzed. Their investigations found a litany of issues. Firstly, the labeling of patients in the test set as "responders" or "non-responders" had been reversed in the original analysis. Secondly, some of the patients were included more than once (some up to four times) in the analysis, likely to cause major distortions in results. Confusingly, some of the reused data has inconsistent grouping; ie: some of the samples are labeled both sensitive and resistant. Additional errors include two cases where results (charts) were ascribed to the wrong drug. Baggerly and Coombes highlight that such mistakes can inadvertently occur when conducting unscripted data analysis such as using spreadsheets, and these problems can be obscured by a lack of documentation.
End-to-end automated process To ensure reproducibility of bioinformatics workflows, they need to be formalized in code wherever possible, from inspecting the raw data to generating the outputs that form the conclusions of the study. Automated processes remove the need for manual steps, which are time-consuming and prone to errors. Without an end-to-end automated process, most of the other best practices described here are not possible. Scripted workflows, although not always free of errors, enable better auditing and easier reproduction which would be difficult for graphical tools like spreadsheets or web tools. Indeed, spreadsheets are prone to data entry, manipulation and formula errors  [30] , leading to problems like inadvertent conversion of gene names to dates in databases and supplementary Excel files  [31] [32] [33].
Some web tools facilitate reproducibility by providing code (e. g. : Degust  [38] ) or by allowing apps to be executed locally (e. g. : ShinyGO  [39] ). To facilitate an end-to-end automated process, code and data need to be "linked," which means the code is aware of the location of the data and how to get it automatically  [14]. The code should be able to fetch the data from a publicly accessible location and conduct the downstream processing and analysis without having to acquire the data some other way. A caveat for end-to-end automation is that sometimes manual data cleaning is unavoidable. In those cases, retaining raw and cleaned data along with a cleaning protocol is recommended. Then the computational workflow can begin with the cleaned dataset. Another issue is that perfect reproducibility isn't possible in cases where some element of randomness is required by the underlying algorithms.
This can be coded in standard open source languages like R/R Markdown, Python/Jupyter notebook or the Unix Shell. These approaches work equally well on personal computers, cloud servers and high performance clusters. Using free and open source software ensures that the research is accessible to the greatest audience  [44] , as opposed to proprietary software like SPSS, STATA and MatLab which are cost inhibitory. Free and open source software also enjoy relatively larger libraries of add-on packages contributed by the scientific community. Projects involving computationally intensive tasks would benefit from a build/workflow automation solution. Guides for selecting and using such systems have been already reviewed by others  [45, 46]. But it is worth mentioning some of the most used solutions in bioinformatics, which include snakemake  [47, 48] , targets  [49] , CWL  [50] , WDL  [51]  and nextflow  [52].
Literate programming Literate programming combines "chunks" of analytical code with human readable text  [53]. After compilation, the resulting output document contains the code together with computational results such as figures and tables along with contextualizing explanations and narratives. The Sweave project, conceived in 2001, was designed to give LaTeX documents embedded R code chunks and was envisaged as a way to generate R documentation materials and generate statistical analysis reports  [54]. Around 2015, R Markdown emerged as a more popular alternative, as formatting content is simpler with Markdown as compared to LaTeX, saving time. An example R Markdown script and output report is given in Figure  2. Around the same time, Project Jupyter was developed to provide a "notebook" type interface, incorporating R, Python, Julia and other computer language chunks into documents  [56] [57] [58].
A noteworthy attempt to use literate programming in Jupyter notebooks to aim for reproducibility has been the analysis of RNA-seq samples from patients infected by the Zika virus  [59]. In this work, authors provided alongside the traditional research paper a Jupyter notebook that performed and documented the entire analysis procedure. The MyST (short for Markedly Structured Text notebook) is built on top of Jupyter notebooks or Markdown documents and has some notable advantages around flexibility of content that make it an attractive choice for executable article authoring  [27]. In 2022, the company behind RStudio (Posit) released Quarto, the conceptual successor of R Markdown, but with enhanced support for other computer languages like Python, Julia, and Observable JavaScript  [60]. Whether R Markdown, Jupyter or other system, literate programming offers some substantial benefits over alternative approaches:.
 Flexible output formats. These include PDF, DOC/DOCX and HTML, the latter having some notable benefits including better usability for mobile devices like phones and tablets, and the ability to support richer content such as interactive charts and dynamic tables (searchable, filterable, sortable). Outputs include HTML documents, but also slideshows and even ebooks. Quarto and R Markdown have the ability to automatically generate a bibliography in many different journal styles  [62]. Further, dozens of journal-style Markdown document templates are freely available, and integrate with MyST notebook system or the rticles R package  [63]. These features make literate programming a useful tool for science communication in a range of situations. Whether this is sharing a data analysis report, giving a presentation at a meeting, writing a research article or self-publishing an ebook, literate programming provides the ability to construct transparent data narratives with clear provenance in a conveniently shareable form.
Literate programming also works neatly with the concept of the "executable paper," the idea that the data analysis underlying an entire study can be reproduced with one or a few commands  [64, 65, 66]. A typical genomics/bioinformatics study could involve one large literate script, or be broken down into smaller scripts, where each one contains the code for generating a part of the article. A multi-script approach would benefit from a master script that executes each component. This further makes the job of reproducibility easier. While it is common to run literate programs on a PC with graphical interfaces such as RStudio, they can also be executed in "headless" mode on high performance computing clusters or cloud servers using command-line interfaces to take advantage of greater computational resources.
Distributed Version Control Systems (DVCS) involve a central web-accessible server hosting a repository, and each team member possesses a mirror copy on their local system (Figure  3 ). Having a central, publicly available node assists in disseminating changes within teams and releasing code to consumers. There are many such DVCSs (Subversion, Git, mercurial, etc), but git has emerged as the most popular solution due to its many powerful features, speed/efficiency and large community and ecosystem. Although DVCSs come from the world of software engineering, data analysts can significantly benefit from their use in the life sciences  [71] [72] [73]. Below we outline some of these advantages.  Keeps a complete history of all code changes over time. We always know which version of the script is the most up to date.
 Helps collaboration and project management. Using a centralized code hosting platform such as "GitHub" or "BitBucket" can help manage contributions from team members who may be working asynchronously in different time zones and on different servers. It also makes the user's work searchable, which is convenient when code snippets from a project need to be reused for a new project.  Helps resolve issues. These centralized platforms also enable discussions of code issues such as bugs and feature requests. In bioinformatics teams, issues can be used to track the progress of a project through its milestones and allow team members to raise potential issues with the code. This also allows the scientific community to raise an issue with the software maintainers. For example, this feature is used extensively during the peer review process for the Journal of Open-Source Software  [74].
 Protects against code loss. Computers sometimes fail and we sometimes delete or overwrite important files. If code is lost and unrecoverable it can be a significant cost to replace. Although DVCSs are not a back-up solution, they do add a layer of protection to the code. Preserving a copy of the repository on each team members' computer in addition to the central repository means the code can be easily recovered if any one of those computers fails. Although DVCSs assist with code sharing, they are not considered a longterm archiving solution, as recalled by the complete shutdown of the Google Code platform in 2015 and the end of Mercurial support by the Bitbucket platform in 2020. The code needs to be deposited to a long-term repository. Zenodo and Figshare are often used to store the content of a repository but do not retain the history of the development of the source code.
Software Heritage  [75, 76]  is the universal software archive whose mission is to collect, preserve and share source code. Software Heritage provides an intrinsic persistent identifier called SWHID that allows to cite the archived source code in the respective journal article/preprint  [77]. Archiving source code in Software Heritage can be performed manually or automatically using a webhook within continuous integration. git is typically used at the command line, however it is also incorporated into integrated development environments commonly used in bioinformatics including RStudio, JupyterLab  [78, 79]  and VS Code  [80, 81]. There are also several git clients with graphical interfaces which better allow inspection of code changes (e. g. :  [82, 83] ).
For example, the most popular containerization system, Docker  [91] , makes it possible to run Windows and Linux/Unix containers on any computer with Docker installed, with the promise of reproducibility. While there are several alternatives such as Podman  [92]  or Apptainer/Singularity  [93] , Docker remains the most widely used containerization system (according to GitHub stars as of August 2023). Docker has a large community of users, extensive documentation and a vast collection of prebuilt container images in the DockerHub registry. Docker can fetch images from DockerHub and run them on the host system with just a couple of commands, and typically within a few minutes. This accelerates the installation procedure dramatically which is a known bottleneck for bioinformatic reproducibility  [28, 94, 95].
In bioinformatics, containers are already extensively used. For example, BioContainers is a registry for sharing bioinformatics software containers  [96]. Containers are equally useful to data analysts by encapsulating the environment in which analytical scripts are executed. Another potential solution to this problem is to use a package/environment management system such as Conda or Guix. These allow users to create, manage, and deploy software packages, dependencies, and environments across different computing platforms  [97]. Conda was initially developed to solve the problem of package dependency management in Python, but it now supports many other programming languages, including R, C/C++, Java, and others. Conda allows researchers to create isolated environments with specific versions of packages, so users can have different versions of R or Python in different environments on the same host system.
Conda environments have limitations around portability and consistency, as such environments are tied to specific operating systems and hardware architecture. Guix is described as a "functional package manager" and has the unique benefit of giving bit-for-bit build reproducibility and verifiability  [85, 98]. This is a notable advantage, as Docker images are not verifiable nor guaranteed to build reproducibly in the future due to link decay. Moreover, Guix can build and output environments as Docker-compatible images which solves the provenance problem of such environments  [99]. These features are being used in the bioinformatics sphere to create highly reproducible pipelines that work equally well on personal as well as shared high performance computers  [98, 100]. Guix is among the best solutions for the "ten-year challenge" of code reproducibility  [101].
Although Guix has some exciting functionality, there remains a relative lack of step-by-step guides and tutorials, illustrated by the complete absence of published Guix protocols in protocols. io, as compared to 13 and 12 related to "Conda" and "Docker" respectively (as at 30th May 2023). Lastly, it's worth mentioning that the Guix project uses Software Heritage as a fallback system to provide a package source code if the download from its original location failed. We It is not sufficient to simply use these tools, they need to be shared as part of the publication process. Conda environments are described by a file called environment. yml which acts like a recipe for how to make the environment. Similarly, Guix environments rely on two files: channels. scm and manifest. scm. Docker images are built using a Dockerfile instruction set.
These are small files which are easily shared in the project code repository. To enable rapid reproduction, making Docker images available is recommended. As these are often very large they cannot be shared in the code repository; rather they are commonly deposited to a Docker image registry such as DockerHub. One must keep in mind that availability of images is dependent on the commercial viability of Docker Inc, so it isn't guaranteed to survive the 10-year challenge. To ensure long-term availability, it would be advised to deposit images to the BioContainers registry  [96] , as it is community driven and supported by consortia such as Elixir and Global Alliance for Genomics and Health that will underpin its longevity. Still, these are not considered permanent archival services, so it is advised to deposit the image used in an article to a suitable persistent long-term archive (discussed below).
Persistent data sharing Without repository exists, then a general-purpose repository such as Dryad, FigShare, or Zenodo should be considered. Researchers should be aware, however, that these repositories are often not moderated, and that it is their responsibility to provide sufficient metadata. To this aim, general recommendations have been proposed to enhance data reuse in ecology, but which can also be applied to other disciplines  [128]. Key recommendations include: 1. Depositing data to a specialized repository if possible, otherwise, a general-purpose repository. 6. Provide detailed metadata; e. g. : sample descriptions that match the article; describe the columns in tabular data (i. e. : data dictionary). Once the quality of the data set has been established researchers may consider depositing it to a data repository early, before publicization, as it has some advantages.
Researchers should consider depositing their thorough laboratory/in silico protocols as separate outputs to relevant repositories such as protocols. io, RIO Journal or Zenodo, minting a Digital Object Identifier (DOI) that can be cited in the article. This is particularly helpful when there are strict word limits on articles. The article should have clear links to supporting materials including datasets, software code and other resources like computational environments. The code repository should have a detailed README file which plays a critical role in reproducibility. It should outline the purpose of the code/software/overall project and how it relates to the article. For example, some articles may rely on more than one repository for various parts of the research project, so these need to be explained.