dataesr/scientific-paragraphs-categorization huggingface dataset:
Sm. TRPMPZQ variants in S. mansoni field samples Variants identification in exome-sequenced data from natural S. mansoni parasites We utilized exome sequence data from S. mansoni from Africa, South America and the middle East to investigate variation in Sm. TRPMPZQ. African miracidia were from the Schistosomiasis collection at the Natural History Museum (SCAN)  (73) , Brazilian miracidia and Omani cercariae and adult worms were collected previously. We have previously described methods and generation of exome sequence from S. mansoni samples  (51, 52). Data were analyzed the same way as described in Chevalier et al. (52). Code is available in Jupyter notebook and scripts associated (https://github. com/fdchevalier/PZQ-R_field). Sanger re-sequencing to confirm the presence of the Sm. TRPMPZQ field variants distribution, we used one-way ANOVA or a pairwise comparison Welsh t-test.
Acknowledgments: We thank the  Vivarium of the Southwest National Primate Research Center (SNPRC)  for providing rodent care. This research was supported by a  Cowles  fellowship (WLC) from  Texas Biomedical Research Institute  ( 13-1328. 021 ),and  NIH   R01AI133749  (TJCA) and was conducted in facilities constructed with support from  Research Facilities Improvement Program  grant  C06 RR013556  from the  National Center for Research Resources. SNPRC research at  Texas Biomedical Research Institute  is supported by grant  P51 OD011133  from the  570 Office of Research Infrastructure Programs ,  NIH. Miracidia samples for sequence analysis were provided by  Schistosomiasis Collection at the Natural History Museum (SCAN)  funded by the  Wellcome Trust  (grant  104958/Z/14/Z ) and curated Muriel.
Data and materials availability: Sequence data is available from: PRJNA699326, PRJNA701978, PRJNA704646 Sequence data from field collected S. mansoni is available from: PRJNA439266, PRJNA560070, PRJNA560069, PRJNAXXXXXX Code is available from: https://github. com/fdchevalier/PZQ-R_DNA, https://github. com/fdchevalier/PZQ-R_RNA, https://github. com/fdchevalier/PZQ-R_field.
Methods Data set. Governmental indicators regarding the healthcare system in France (ER consultation, hospitalizations, CCRU admission and deaths, PCR) were downloaded on 25 February 2021 from the French Public Health website https://www. data. gouv. fr/ fr/pages/donnees-coronavirus. Hospitalization, CCRU admission, and death indicators correspond to the new number of cases by day. ER consultation ratio corresponds to the ratio of consultation with a medical diagnosis of COVID-19 over the general consultations at the ER in hospitals. A number of detected new viral infections (positive and negative) based on nucleic acid are also downloaded from the French Public Health website. We report the raw number as well as the rate of a daily positive diagnosis. An online survey was conducted in the French population between 8 April and 10 January 2021 and aimed at characterizing chemosensory disorders in people with and without COVID-19, as well as their consequences on quality of life.
Statistics. Phasing study: data were analyzed using R software (4. 0) and its standard packages (maps, ggplot, etc. ). In order to account for weekend reporting effects and random fluctuation, we computed a rolling average over 7 days, for each indicator. Each indicator displaying its annual maximum during the spring lockdown, we computed the number of days between the day before the start of this first lockdown (17th march) and the annual maximum of the indicator (its peak). We considered the number of days computed as the delay between the peak of the indicator and the peak of circulation of the virus. Then, we phased all indicators (i. e. , 1-google loss of smell; 2-google loss of taste; 3-report of change in smell; ER consultation, hospitalization, CCRU admission, COVID deaths) to represent virus circulation on specific days (Fig.
1 ). We also define a composite indicator by computing the mean of all indicators and compute its rolling slope on 7 days. All indicators were weighted equally. Virologic tests based on PCR were not available nationally during the first lockdown; we did not include them in this first analysis. Local study: pandemic indicator data at the departmental level were downloaded from the French public health database (Supplementary Data 2). For each indicator, we computed a rolling average over 7 days at the department level. For each indicator, we report the date of the maximal value from 1 October to 28 November. Curfew dates by the department were found on the official government website https://www. gouvernement. fr/ info-coronavirus. Curfew was declared on the whole Paris region (Ile-de-France) and major metropolises and later on specific departments.
Results To monitor the circulation of the SARS-CoV-2, we collected surveillance indicator data from independent sources: (1) governmental statistics (https://geodes. santepubliquefrance. fr) healthcare system data compiled by the French health ministry: ER ratio of consultation for COVID-19, daily number of hospitalization for COVID-19, daily number of admission in CCRU for COVID-19, daily number of deaths for COVID-19, and (2) population-based tools that monitor chemosensory changes (smell and taste change linked to COVID-19 were followed by one crowd-sourced survey (https://project. crnl. fr/odorat-info/) and independently by following the search requests of French residents compiled by Google trends loss of taste (perte gout); loss of smell (perte odorat) https://trends. google. com/). For each indicator, we computed the delay between the day of the highest value (date of the peak) and the maximum level of SARS-CoV-2 circulation in France (17th March 1,5-7 ).
Data availability Online queries were downloaded from Google Trends (https://trends. google. com/), using the R library gtrendsR. We searched separately for the popularity of the terms: loss of smell (perte odorat) and loss of taste (perte gout), using default selection of All categories and Web search, within the timeframe of 1 March 2020 to 10 January 2021. Data of the online survey conducted in French population between 8 April and 10 January 2021 are available in the supplementary Data 2 (sheet: survey_QUALITYofLIFE). The Governmental indicators regarding the healthcare system in France (ER consultation, hospitalizations, CCRU admission and deaths, PCR) were downloaded on 25 February 2021 and are available on https://www. data. gouv. fr/fr/pages/donnees-coronavirus and https://geodes. santepubliquefrance.
Introduction Data has become a crucial resource in many scientific fields, and materials science is no exception. Experimental data has long been meticulously curated in handbooks and databases, with the first edition of Landolt-Börnstein 1 being published in 1883. Nowadays, various commercial and non-commercial experimental databases, such as the Inorganic Crystal Structure Database (ICSD)  2  , are widely used throughout the field. High-throughput electronic structure calculations, themselves enabled by algorithmic improvements and growing computational resources, have significantly increased the availability of useful data from computational simulations of materials. Since the pioneering work of Ceder et al. 3  , a large number of high-throughput first-principles studies have been reported in the literature (for a review, see Ref.
4), with results typically collated in databases. This explosion in the amount of available data has kick-started a new paradigm of data-driven materials science  5  , creating opportunities for concurrent, automated materials design, boosted by databases that can be queried by humans and machines via an application programming interface (API)  [6] [7] [8] [9]. As materials databases differ in fidelity and focus across material classes and properties, it is extremely beneficial to be able to liberate and unify data from multiple sources. However, retrieving data from multiple databases is difficult as each database has its own specialized, and sometimes esoteric, API that governs data access patterns, querying and the representation of the underlying data. Moreover, as the APIs of individual databases inevitably evolve, existing clients must also evolve; a significant maintenance effort is required to translate the responses from the new API to the representation of the client.
Motivated by these considerations, providers of several materials databases united to design and implement an API specification that enables seamless access and interoperability across materials databases. The effort started at the workshop "Open Databases Integration for Materials Design", held at the Lorentz Center in Leiden, Netherlands in October 2016, and continued at followup workshops held at CECAM in Lausanne, Switzerland in June 2018, June 2019, and June 2020. The result is the OPTIMADE specification (v1. 0) 10 ; OPTIMADE defines a RESTful API that is queried with URLs, with responses adhering to the JSON:API specification  11. Specification development adheres to Semantic Versioning  12  to avoid surprises and enable backwards-compatibility where possible, without impeding further development.
By extracting the technical and scientific commonalities from existing APIs, the OPTIMADE API has been designed so that it can be implemented across a broad range of materials domains, database back-ends and sizes. In this paper, we first review the query format of existing databases to motivate the design and construction of the OPTIMADE API specification. We then illustrate the use of the API with a set of worked examples; databases that already fully support the OPTIMADE API are enumerated alongside their results for representative queries in Table  1. We further highlight libraries that could accelerate uptake and assist materials data curators to support the OPTIMADE API format. Finally, we discuss future prospects and ongoing development of the OPTIMADE API.
Current generation of materials database APIs Materials databases are a veritable treasure trove of information, but they only become useful once a human, or machine, can access them. In this section we review the current range of APIs used by various databases to enable access to an example compound, SiO 2 , which serves to highlight the variation of APIs that a user must navigate in order to make use of multiple materials databases. We then demonstrate the universal nature of the OPTIMADE API that permits seamless access to all materials databases that support it. We first compare and contrast the APIs that must be used to request records on an exemplar system, SiO 2 , from three different databases: AFLOW, the Materials Project, and the Crystallographic Open Database (COD). All three queried databases support requests using a representational state transfer through a web service (RESTful), at the following URLs: Note that the Materials Project requires the user to supply an API key (http://materialsproject.
org/API/aflux/?compound(SiO2) which returns no response; http://aflow. org/API/aflux/?compound(O2Si1) now lists the elements in alphabetical order as required by AFLOW, and includes the "1" after element symbols, so that "SiO2" becomes "O2Si1". This returns entries where the unit cell is SiO 2 , but does not return Si 2 O 4 or simulation cells containing more formula units. The exemplar http://aflow. org/API/aflux/?species(Si,O),nspecies(2) returns all entries with at least one Si and an O, so while the response includes the SiO 2 phases of interest, it may also contain other stoichiometries. The distinctions between the request format for each database require the user to become an expert in many different APIs. This again emphasises the need for a single well-designed and standardized API to access all materials databases, which is the aim of the OPTIMADE API.
The OPTIMADE API The OPTIMADE API provides a holistic standard for serving and accessing the information in compatible materials databases. To retrieve information about materials from a particular database, the user submits a request via a URL. Each database provider will have published a base URL that serves the OPTIMADE API, for example https://example. com/optimade/. The same URL path, across different OPTIMADE API implementations, allows uniform access to the underlying databases. Both human-readable and machine-readable versions of the OPTIMADE API specification are available online with releases archived at Zenodo 10. The specification is also registered as an API standard on FAIRsharing. org  13.
Instead of enforcing an exhaustive set of property definitions, individual OPTIMADE implementations can describe the data they serve via /info endpoints for each entry type. These introspective endpoints allow clients to adapt to the particular implementation for an underlying database, and allow providers to disseminate properties beyond the simple structural and chemical information standardized by the specification. To avoid naming collisions, each provider-specific property name must be prefixed by a provider-specific token, itself bookended by underscores (_). The property custom_property from an example provider with assigned prefix exmpl would be expressed as _exmpl_custom_property: e. g. , _tcod_a for the lattice constant, a, in TCOD, or _aflow_spacegroup_relax for the space group of the relaxed structure in AFLOW.
Implementation discovery The list of implementations confirmed and tested in this paper to support the OPTIMADE API is shown in Table  1. They are all publicly accessible, providing users with open access to large international repositories of computational and experimental materials science data. The OPTIMADE consortium provides an open, federated list of implementations (https://providers. optimade. org). It is considered to be a catalogue of currently available and/or known public OPTIMADE implementations. New implementations are welcome and can register themselves via a pull request on GitHub (https://github. com/Materials-Consortia/providers). The requirements for appearing in the above providers list are very loose. Some databases listed in the catalogue are signalling the intent of future implementations, while others only have partial implementations of the OPTIMADE API, including JARVIS (https://jarvis.
nist. gov/optimade)  14 and MatCloud (https://matcloud. com. cn)  15. Some software frameworks, such as AiiDA  [16] [17] [18]  , also enable users to access their personal data through an OPTIMADE API, and therefore have a dedicated provider-specific ID, but no single official OPTIMADE implementation base URL. The OPTIMADE API also specifies an endpoint for semi-automated cross-provider discovery. The /links endpoint serves links resources that may refer to either provider internal (child, root) or external (external, providers) resources based on the link_type attribute. To avoid being overly restrictive, it is at the provider's discretion whether they serve a list of known providers; however, this provides a mechanism for scalable and decentralised discovery of new implementations beyond the federated provider list.
19, 20   0,192 62,293 382,554 Crystallography Open Database (COD)  21, 22  416,314 3,896 32,420 Theoretical Crystallography Open Database (TCOD)  23  2,631 296 660 Materials Cloud  9, 16, 17  886,518 801,382 103,075 Materials Project  [24] [25] [26] [27]  27,309 3,545 10,501 Novel Materials Discovery Laboratory (NOMAD)  28, 29  3,359,594 532,123 1,611,302 Open Database of Xtals (odbx)  30  55 54 0 Open Materials Database (omdb)  31  58,718 690 7,428 Open Quantum Materials Database (OQMD)  32  153,113 11,011 70,252 Provider N 1 N 2 N 3 AFLOW Table  1. Materials databases with active OPTIMADE API implementations and the number of entries they return for the filters presented in this paper. The OPTIMADE website provides an up-to-date record of the implementation status of the databases (https://www.
optimade. org/providers-dashboard/). AFLOW, Materials Project, odbx, omdb, and OQMD comprise computational materials data generated using database-specific workflows  20, 24, [30] [31] [32]. For the purposes of this table, Materials Cloud results were aggregated across all provided sub-databases. COD and TCOD comprise experimental and theoretical crystal structure data extracted from the literature. Materials Cloud comprises materials data from computational workflows; sub-databases group data by research project and can be contributed by users  9. NOMAD aggregates computational data from multiple sources including from several of the repositories listed here.
Worked example To illustrate the effective use of the OPTIMADE API we now provide a worked example of querying structures. We explore materials containing Group 14 elements (the carbon family), starting with a general search before drilling down to specific materials. The Group 14 elements are of particular interest as their atomic orbitals regularly hybridise, enabling a variety of bonding with differing geometries. The hybridised orbitals enable these elements to form the backbone of a wide range of compounds, both inorganic and organic, that underpin plastics, drugs, and semiconductors. Group 14 therefore forms both a diverse and important family of compounds that heavily populates databases, so are an ideal case study to demonstrate the OPTIMADE API.
Common features of the response Whilst our previous exploration of the Group 14 compounds considered only SiO 2 , the flexibility of the OPTIMADE API allows us to start with a search over all materials in Group 14, comprising carbon (C), silicon (Si), germanium (Ge), tin (Sn), and lead (Pb). We start with a simple API call that searches for all materials that contain at least one element in Group 14: /v1/structures?filter=elements HAS ANY "C", "Si", "Ge", "Sn", "Pb" This string can be appended to the base URL of any of the available implementations, to gather results in a standardised form. The base URL can be found on the providers dashboard (https://www. optimade. org/providers-dashboard). As an example, this query is run through the Theoretical Crystallography Open Database (TCOD)  23  with the following URL: https://www.
crystallography. net/tcod/optimade/v1/structures?filter=elements HAS ANY "C", "Si", "Ge", "Sn", "Pb" The JSON response is summarized in Boxes 1 through 5, where some lines have been omitted for brevity; the full response is given in Supplementary File 1. The first tranche of the JSON response comprises the "data" field that contains a list of entries returned for the query; a truncated version of this field is shown in Box 1, displaying a few salient properties of just one of the ten entries from the full response. The response for a particular material entry comprises multiple sections: attributes Box 1 shows the physical properties of the material comprising both mandatory information such as elements and lattice_vectors, as well as optional, additional database-specific information prefixed with the database name (e.
g. , _tcod_, here used to provide lattice parameters). This ensures that all databases return the most important and common information in a standardized format, as well as allowing them to include additional database-specific data. Importantly, the OPTIMADE specification provides a standardized way for database implementations to be self-documenting, via introspective /info endpoints. We see in the elements section that here we have returned a material comprising the element of interest, Sn, as well as O and Ta. "representation": "/structures?filter=elements HAS ANY \"C\",\"Si\",\"Ge\",\"Sn\",\"Pb\"" with parameter page_offset=10 to allow the user to select which page to enter, and the parameter page_limit=10 to control the number of materials returned per individual request. The most useful way to explore an OPTIMADE database is to apply a filter; the specification mandates that several relevant properties must be queryable.
For example, we can perform a more focused search for materials comprising at least one element in Group 14, and a maximum of two elements (a binary material), with the filter This query returns 296 materials from the TCOD database, with the response summarized in Box 6, where some lines have been omitted for brevity and the full response is given in the Supplementary File 2. The number of matching entries (N 2 ) across all implementations for this filter are shown in Table  1. We can now see that the first structure, and indeed all structures, returned are comprised of at least one element in Group 14, here Ge, and a maximum of one other element (a binary material), here O. Additional filters can be chained to further refine the materials returned, or to construct more complex queries. For example, ternary structures that contain at least one of the elements C, Si, Ge, or Sn, but do not contain Pb (e.
Related libraries The wider usage of the OPTIMADE API is a key goal for the consortium; to this end, several open source libraries have been developed to help users of the OPTIMADE API (either implementation developers, or client end-users), of which three are introduced below. The first two libraries offer tools that aid the implementation of the API for materials database developers, with the first also containing tools to construct and validate queries, while the third library is intended for end users of OPTIMADE-compliant APIs. optimade-python-tools optimade-python-tools is an open source Python package available on GitHub (https://github. com/Materials-Consortia/optimadepython-tools). The package contains a complete set of tools for implementing an OPTIMADE-compliant API, as well as several utilities that can be used by client code.
The package is listed on the Python Package Index (PyPI) as optimade (https://pypi. org/project/optimade). Current (v0. 14) functionality of the package includes: • pydantic (https://github. com/samuelcolvin/pydantic) data and validation models for all objects defined in the OPTIMADE specification that can be used in server or client code; • an extensible reference server implementation leveraging pydantic and FastAPI (https://github. com/tiangolo/fastapi). This reference server forms the basis of the OPTIMADE implementations for the Materials Project 24 , NOMAD  29  , Materials Cloud  9  and odbx (https://odbx. science) providers. These tools are also used to generate a machine-readable OpenAPI version  34  of the OPTIMADE specification; • a validator for OPTIMADE implementations, available standalone with a command line interface (CLI) or as a GitHub action (https://github.
com/Materials-Consortia/optimade-validator-action). This validator is run against the federated list of OPTIMADE providers every day, with a live dashboard indicating compliance with the specification at https://www. optimade. org/providers-dashboard/, the source code for which can be found on GitHub (https://github. com/Materials-Consortia/providers-dashboard); • a Python parser for the OPTIMADE filter language written with the Lark parsing library (https://github. com/larkparser/lark); • filter transformers from the abstract syntax tree to queries to popular database back-ends. Currently, the supported backends are MongoDB (via pymongo) (https://github. com/mongodb) and Elasticsearch (https://github. com/elastic/elasticsearch); • adapter classes to interface with other popular libraries, namely pymatgen  26  , ASE  35  , AiiDA  [16] [17] [18]  and JARVIS  14  as well as converting OPTIMADE structures to the CIF  33  , XYZ, and more domain standardised file formats.