dataesr/scientific-paragraphs-categorization huggingface dataset:
data developed by the merger of two similar efforts, one in the EU and one in the US. • The Directory at the Digital Curation Centre (DCC; http://www. dcc. ac. uk) is a good resource for developing data management plans. JavaScript Object Notation and RDF. A common representation is ISA-TAB, a tab-delimited format, which is supported by a number of tools (http://isa-tools. org). Collaborative Open Plant Omics (COPO). (http://copo-project. org) is a UK-funded project to aid deposit of researcher data • The Metadata Standards Directory Working Group into appropriate repositories along with the recommended (http://rd-alliance. github. io/metadata-directory), a sec- metadata and the discovery and retrieval of public data for tion of the Research Data Alliance (RDA; https://www. rd- reuse. The project has been underway for 3 years and its alliance.
org), now maintains a listing of metadata data submission portal is in beta testing. The portal will standards and their extensions. support a number of public repositories and will interact • The Ag Data Commons (https://data. nal. usda. gov) is with European Nucleotide Archive (ENA), the European an agriculture-specific registry of databases, data sets member of the International Nucleotide Sequence Database and tools with USDA funding support. Its metadata are Collaboration (INSDC). interoperable with the World Wide Web Consortium (W3C) Data Catalog vocabulary (https://www. w3. org/ TR/vocab-dcat/) and the open government Project Open Data v1. 1 standard (https://project-open-data. cio. gov/ v1. 1/schema/). • Research Data Management Service Group at Cornell University (https://data. research.
• Data Management Planning Tool (DMPTool; https://dmp tool. org) was developed for writing required data management plans by the California Digital Library and the Data Observation Network for Earth (https://www. data one. org) project. • REgistry of Research Data REpositories (Re3Data; http://www. re3data. org) is a database of available repositories for research • The Agriculture Network Information Collaborative alliance includes a working group that coordinates data management plan guidance across its member libraries. The RDA. (https://www. rd-alliance. org) was started in 2013 by the European Commission (EC), the NSF, the National Institute of Standards and Technology and the Australian Government's Department of Innovation to encourage and enable open sharing of research data in all scientific disciplines and the humanities.
Several RDA working groups are focused on metadata. The RDA Metadata Standards Directory and the Metadata Catalog of metadata standards that have been submitted to the RDA is in progress and can be seen at http://rd-alliance. github. io/metadata-directory. ISA -Investigation, Study, Assay. (http://isa-tools. org/) (49) approach to metadata is structured with three elements: the Investigation-the research context; a Study-a unit of research; and an Assay-an analytical measurement. These data can be provided in a number of formats, tabular, transPLANT. ( http://www. transplantdb. eu) is a consortium of 11 European partners (http://www. transplantdb. eu/ partners) gathered to address the challenges of working with plant genomes and to develop a transnational infrastructure for plant genomic science.
The Monarch Initiative. (https://monarchinitiative. org) integrates genotype and phenotype data from multiple species and sources. The resulting integrated knowledge graph, analytic tools and web services enable researchers to explore relationships between phenotypes and genotypes across species. Standardized metadata and formal ontologies are used to better enable data sharing, reproducibility and integration. Computer-readable data is shared using the Biolink API (https://github. com/biolink; https://api. monarchinitiative. org/api). Monarch also uses Phenopackets (https://github. com/phenopackets) for standardized data exchange of phenotype data. Genomic Standards Consortium. (http://gensc. org) is an interna- tional consortium for developing metadata standards for describing genome data.
The consortium includes repre- sentatives from many of the groups above and INSDC databases. Genomes Online Database. (GOLD, https://gold. jgi. doe. gov; 54) is an example of extensive use of a metadata standard to enable finding data sets. GOLD holds Minimum Information about any(x) Sequence (http://gensc. org/mixs/) metadata to enable fine-grained searching of sequence data. The sequence data itself is maintained elsewhere, typically in an INSDC.
Select one or more database schemas and APIs that are well supported by the development community. Communitysupported generic relational schemas (e. g. Chado) should be used where possible to reduce duplication of effort. Such schemas capture the majority of use cases related to common genetic and genomic data types. They also shorten the time necessary to optimize data storage and exchange. Current efforts in the community are focused on APIs that support the best data storage mechanism for the data (optimized relational schemas, NoSQL solutions and/or data warehousing) to facilitate access. In these cases, web services are developed to expose and share this data. (Table7; requirements 4, 5, 6 and 7) Provide explicit licensing information that specify down- load and reuse policies. No license is legally the same as applying the most restrictive license possible.
Therefore, individuals and databases that want to make data available for reuse should formally apply the least restrictive license that makes sense for their data. The most frequently used licenses for data come from the Open Data Commons (https://opendatacommons. org/) and the Creative Common (https://creativecommons. org/share-your-work/licensing- types-examples/). GGB databases should have practices and policies that encompass the following: • Exporting license and conditions (metadata) with the data, • Requiring data submitters to agree to licensing and reuse policies, • Recommending open access licenses or placing data in the public domain, • Ensuring that curators identify licenses for data sets that they gather, • Helping data submitters communicate with their institu- tion about whether they can offer specific licenses given intellectual property rules (Table 7; requirements 6, 13 and 14).
Work with your IT department to access high speed Internet. This often involves moving your database outside a firewall. If appropriate, collaborate with other databases to create transfer links on Advanced Layer 2 Service (AL2S) to speed transfer. AL2S, as part of Internet 2, provides research and education organizations with access to effective and efficient wide area 100 gigabit Ethernet technology (https://www. internet2. edu/products-services/ advanced-networking/layer-2-services/#service-overview). (Not specific to any individual requirement, but necessary for success of most of them. ) Capture usage metrics, including requests through APIs. Some methods for tracking site usage (e. g. Google analytics) are driven primarily by mechanisms involving webpage loads and require additional tooling to be able to handle tracking of web services calls, so development of both useful metrics and methods of capturing them are needed.
Ensure that continuous updates and efforts toward integrat- ing with existing web services and ontologies are followed. This requires continuous development and interaction with the community of developers working on these APIs. (Not specific to any individual requirement, but necessary for success of most of them. ) Communication Overview Improved communication between people working at GGB database is critical to successfully implementing the rec- ommendations made in this paper. In addition, improved communication with people in the research community, funding agencies and journals is critical to the maintenance and reuse of research data. There are four main types of communication that personnel at GGB databases should consider: (i) commu- nication across GGB databases, (ii) communication with experimental data generators and researchers, (iii) com- munication with funding agencies and (iv) communication with journals.
Acknowledgements This work has been partially supported by the  French Agence Nationale de la Recherche  through the  BRUTUS  project under Contract  ANR-14-CE28-0015. The last author was partially supported by the  Fundamental Theory and Cutting Edge Technology Research Program of Institute of Information Engineering, CAS  (Grant No. Y7Z0341103 ),  Youth Innovation Promotion Association CAS  and the  National Natural Science Foundation of China  (Grants No. 61472415 ,  61732021  and  61772519 ).
Conditions data infrastructure for both ATLAS and CMS have to deal with the management of several terabytes of data. Distributed computing access to this data requires particular care and attention to manage request-rates of up to several tens of kHz. Thanks to the large overlap in use cases and requirements, ATLAS and CMS have worked towards a common solution for conditions data management with the aim of using this design for data-taking in Run 3. In the meantime other experiments, including NA62, have expressed an interest in this crossexperiment initiative. For experiments with a smaller payload volume and complexity, there is particular interest in having simple payload storage. The conditions data management model is implemented in a small set of relational database tables. A prototype access toolkit consisting of an intermediate web server has been implemented, using standard technologies available in the Java community.
Access is provided through a set of REST services for which the API has been described in a generic way using standard Open API specifications, implemented in Swagger. Such a solution allows the automatic generation of client code and server stubs and further allows changes in the backend technology transparently. An important advantage of using a REST API for conditions access is the possibility of caching identical URLs, addressing one of the biggest challenges that large distributed computing solutions impose on conditions data access, avoiding direct DB access by means of standard web proxy solutions.
Conditions in HEP experiments In the context of the HEP Software Foundation community white paper, a cross-experiment working group of experts in conditions data met to discuss best practices in conditions data management. This short paper represents a concise summary of the recommendations of that working group, which will be documented in more detail elsewhere. Broadly speaking, conditions data is defined as the non-event data required by data-processing software to correctly simulate, digitise or reconstruct the raw detector event data. The non-event data required to maintain, operate and optimise detectors can be broken down into the following categories: (i) Configuration (ii) Detector Control System (DCS), from Process Visualization and Control System (PVSS) (iii) Monitoring (iv) Calibrations, alignments Conditions data thus largely consists of (iv), together with the subset of (i) and (ii) that are required for data processing.
Workflows Given the definition of conditions data, the workflows that need to be supported are predominantly those of offline data processing. However, both CMS and ATLAS high level (software) triggers use the same software framework as offline data reconstruction and must also be supported, as must any workflow that requires conditions data. A non-exhaustive list of important workflows follows: (i) Subsystem calibration: conditions determination and testing (including the ability to access a copy of the conditions stored locally); uploading conditions to the production database. (ii) Prompt data processing, with conditions updates adhering to strict protocols (iii) Offline data processing, including Monte Carlo simulation, using pre-determined conditions.
Data volumes, read and write rates Conditions data tend to scale in a controlled way during the lifetime of an experiment, typically producing data volumes of gigabyte to terabyte scale. It is worth noting that on ATLAS, where the same database instance was used for conditions data as well as the DCS and trigger data, the DCS and trigger data dominated the offline and online database instances, respectively. It is therefore strongly recommended by this working group to factorise conditions data from other use cases, even where these are related. Typically write-rates for conditions data must support of the order of 1 Hz (to ensure good support for several independent systems writing conditions data every minute), with the majority of conditions data being updated much less frequently than this.
Conditions Database Archetype The archetypal solution to a conditions database management system (CDMS) is shown in figure  1. The conditions data payloads are stored in a master database and are accessed using a client-server design through a REST interface, achieving a high degree of separation between client and server. This allows for simple clients which all of the experiments found to be very desirable. Due to the read-rate requirements, caching is also extremely important and good experience was seen when using web-proxy caches, e. g. the Squid cache shown here. Some key design principles are detailed in the following.
Database backend One of the key features of the design is that it is agnostic to particular choices of database backend. This was also one of the key features of COOL  [1] , but due to the lack of caching in COOL, the queries themselves had to become more complicated. Thus on ATLAS, which uses an Oracle back-end, a significant amount of Oracle DBA effort was required to tune the queries and make them performant. It is therefore important to realise that real flexibility with respect to choices in database backends only comes when the system as a whole is simplified.
Client-side requirements The client layer should be as simple as possible and should be as agnostic of the rest of the architecture as it is possible to be in order to improve maintainability. The database insertion tools in particular benefit from adopting a simple e. g. REST interface. The client layer needs to take care of payload deserialisation, as the remaining architectural components will deal with serialised objects. Experience also shows that clients should be able to manage multiple proxies and servers to provide robustness against server failures.
Caching layer CMS and ATLAS require an intermediate layer between the client and server to provide caching capabilities. Considering the distributed use case, where thousands of jobs start at the same time and require the same conditions data, this is a clear requirement and one that can be well met using web-proxy technologies. An alternative solution would be to use a distributed filesystem with good caching capabilities, and the ALICE experiment is gaining experience using CVMFS. The simplicity of this solution makes it very attractive and it has thus been adopted as a strategy by the NA62 experiment. This in turn suggests that, as a design requirement, it should be possible to represent a conditions database on a filesystem. The primary challenge is to make the filesystem mapping use the CVMFS caching layers efficiently.
Data Model The data model for conditions data management is an area where the experiments have converged on something like a best practice shown in figure  2. A global tag is the top-level configuration (version) of all conditions data needed for a particular data processing use case. For a given system and a given interval of validity, a global tag will resolve to one, and only one, conditions data payload. The Global Tag resolves to a particular system Tag via the Global Tag Map table. A system Tag consists of many intervals of validity (IOV) or entries in the IOV table. Finally, each entry in the IOV table maps to a payload via its unique hash key in the Payload table. A relational database is a good choice for this design. This design has several key features. Firstly, conditions data payloads are uniquely identified by a hash which is the sole reference to any given conditions data payload.
The payload data has been separated from the data management metadata and could in principle be placed in a separate storage system. This could also be important for data preservation, as the entire metadata component will occupy a trivial data volume and could exist in e. g. an SQLite file, while the payload storage could be handled separately. Secondly, IOVs are resolved independently of payloads and are also cacheable. Efficient caching is a key design requirement for any conditions database that must support high rate data access.
Nevertheless, there are still open questions that need to be addressed. The functionality to produce a filesystem-based replica of a conditions database, that can be accessed transparently to the client, needs to be prototyped. The NA62 experiment will look at this problem in reverse, moving from a filesystem-based approach to a relational database, requiring a suitable filesystem layout. Meanwhile, on a time-scale of Run 3, the large data rates will force LHCb and ALICE to only reconstruct data online. While they will potentially be more exposed to data quality losses, their offline conditions data access requirements are greatly reduced.
Conclusion Following a decade of experience with the LHC experiments, conditions data management is an important component of HEP software and one that is often considered relatively late in the software design cycle. While the data volumes are easily accommodated by several database technologies, the workflows can be demanding. In particular, access rates at the level of tens of kHz is critical (and non-trivial) to support, and the importance of a caching system like Frontier [3] or CVMFS  [4] , in particular for CMS and ATLAS, cannot be overstated. Several experiments have converged on similar solutions for solving conditions data management problems, based on the good performance of the CMS approach. All of the experiments want a high degree of separation between the client and server side of the problem, with a client that is relatively simple (in contrast to the original COOL solution).
An intermediate layer with caching capability is needed to support high rate requests and webproxies have performed very well. REST interfaces and industry standard components, together with a relational data model to represent the global tag concept, can support the wide variety of workflows used in HEP while being sufficiently modular to evolve easily. For purely offline workflows, CVMFS is attractive and could be produced from the master database. This would resemble the git-based approach used by LHCb, where the IOV structure is encapsulated by a simple file. Analysis conditions data management could also benefit from using these solutions.
Rather, it depends on the context, and becomes increasingly difficult as the code ages. erefore, to be and remain re-runnable on other researchers' computers, a re-runnable code should describe-with enough details to be recreated-an execution environment in which it is executable. As shown by  (Collberg & Proebsting, 2016) , this is far from being either obvious or easy. In our case, the R 0 version of our tiny walker seems to imply that any version of Python would be fine. is not the case: it uses the print instruction and the xrange operator, both specific to Python 2. e print instruction, available in Python 2 (a version still widely used; support is scheduled to stop in 2020), has been deprecated in Python 3 (first released in 2008, almost a decade ago) in favor or a print function, while the xrange operator has been replaced by the range operator in Python 3.
For instance, the R 2 program will not produce the same results all the time. It will, because it is repeatable, produce the same results over repeated executions. But it will not necessarily do so over different execution environments. e cause is to be found in a change that occurred in the pseudorandom number generator between Python 3. 2 and Python 3. 3. Executed with Python 2. 7 to 3. 2, the code will produce the sequence -1, 0, 1, 0, -1, -2, -1, 0, -1, -2. But with Python 3. 3 to 3. 6, it will produce  0, 1, 2, 1, 0. With future versions of the language, it may change still. For the R 3  version, we abandon the use of the random. choice function in favor of the random. uniform function, whose behavior is consistent across versions 2. 7 to 3. 6 of Python. Because any dependency of a program-to the most basic one, the language itself-can change its behavior from one version to another, executability (R 1 ) and determinism (R 2 ) are necessary but not sufficient for reproducibility.
e exact execution environment used to produce the results must also be specified-rather than the broadest set of environments where the code can be effectively run. In other words, assertions such as "the results were obtained with CPython 3. 6. 1" are more valuable, in a scientific context, than "the program works with Python 3. x and above". With the increasing complexity of computational stacks, retrieving and deciding what is pertinent (CPU architecture? operating system version? endianness?) might be non-trivial. A good rule of thumb is to include more information than necessary rather than not enough, and some rather than none. Recording the execution environment is only the first step. e R 2 program uses a random seed but does not keep a trace of it except in the code. Should the code change a er the production of the results, someone provided with the last version of the code will not be able to know which seed was used to produce the results, and would need to iterate through all possible random seeds, an impossible task in practice 3.
Another good practice is to make the code self-verifiable. In R 3 , a short unit test is provided, that allows the code to verify its own reproducibility. Should this test fail, then there is li le hope of reproducing the results. Of course, passing the test does not guarantee anything. It is obvious that reproducibility implies availability. As shown in  (Collberg & Proebsting, 2016) , code is o en unavailable, or only available upon request. While the la er may seem sufficient, changes in email address, changes in career, retirement, a busy inbox or poor archiving practices can make a code just as unreachable. Code and input data and result data should be available with the published article, as supplementary data, or through a DOI link to a scientific repository such as Figshare, Zenodo 4  or a domain specific database, such as ModelDB for computational neuroscience.
e codes presented in this article are available in the GitHub repository github. com/rougier/random-walk and at doi. org/10. 5281/zenodo. 848217. To recap, reproducibility implies re-runnability and repeatability and availability, yet imposes additional conditions. Dependencies and platforms must be described as precisely and as specifically as possible. Parameters values and inputs should accompany the result files. e data and scripts behind the graphs must be published. Unit tests are a good way to embed self-diagnostics of reproducibility in the code. Reproducibility is hard, yet tremendously necessary.
With documentation explaining which script or configuration file corresponds to which experiment, reproducing the different figures becomes straightforward. # Copyright (c) 2017 Nicolas P. Rougier and Fabien C. Y. Benureau # Release under the BSD 2-clause license # Tested with CPython 3. 6. 2 / macOS 10. 12. 6 / 64 bits architecture import sys, subprocess, datetime, random def generate_walk(count, x0=0, step=1, seed=0): """ Random walk count: number of steps x0 : initial position (default 0) step : step size (default 1) seed : seed for the initialization of the random generator (default 0) """ random. seed(seed) x = x0 walk = [] for i in range(count): if random. uniform(-1, +1) > 0: x += 1 else: x -= 1 walk. append(x) return walk def generate_results(count, x0=0, step=1, seed=0): """Compute a walk and return it alongside its context""" Documentation is one of the most potent tools for reusability.