dataesr/scientific-paragraphs-categorization huggingface dataset:
Code availability. The source code for ORCHIDEE-MICT version 8. 4. 2 is available online (https://forge. ipsl. jussieu. fr/orchidee/ browser/branches/ORCHIDEE-MICT/tags/ORCHIDEE_MICT_ GLUC_8. 4. 2) but its access is restricted to registered users. Requests can be sent to the corresponding author for a username and password for code access. ORCHIDEE-MICT is governed by the CeCILL license under French law and abides by the rules of distribution of free software. One can use, modify, and/or redistribute the software under the terms of the CeCILL license as circulated by CEA, CNRS, and INRIA at the following URL: http://www. cecill. info. Data availability. Primary data and scripts used in the analysis and other supplementary information that may be useful in reproducing the authors' work can be obtained by contacting the corresponding author.
At one end of the spectrum, about 50% of the protein residues tolerate more than 15 substitutions ( > ⁎ k 16). At the other end, 8 positions (3%) tolerate less than 1. 5 substitutions ( <. ⁎ k 2 5) and are identified as highly deleterious in  4. Note that this definition is much more stringent than that used for PSD95 pdz3 3 , where the highly deleterious positions represent 24% of the protein (20/83). Six of these 8 positions are detected by our infostery analysis: S70, K73, D131, E166, D179, T181 and K234. Our inability to retrieve 2 residues, S130 and G251, can be explained by the following observations: S130 is directly involved in catalysis  4  and in direct contact with the ligand (PDB code: 1M40  59  ), which is absent in our simulations; G251 is exposed to the solvent, suggesting a role in the interaction with a protein partner.
GH is a peptide hormone, folded as a four-helix bundle (184 residues), that stimulates growth by binding to two monomers of its receptor GHR (Supplementary Fig. S1c ). Systematic experimental measurements of mutational phenotypic outcomes are not available for this system. Nevertheless, one can exploit data from homologous sequence analysis across different species, and from high-throughput exome sequencing of human individuals (Exome Aggregation Consortium database  60  ) to define a set of 30 positions likely intolerant to substitutions (see Materials and Methods). Among them, 21 positions (70%) were detected by our infostery analysis (Supplementary Fig. S10 , in red, and Supplementary Table  S7 ) and most of those positions form isolated direct communication within the protein (Supplementary Fig.
ENcoM directly predicts the effects of mutations on protein dynamics and thermostability  64. Contrary to most ENM-relying methods, it accounts for the nature of amino acids, and that is why we chose it to classify our set of highly deleterious and neutral mutations in PSD95 pdz3 (Table  3 ). ENcoM performance are lower than those obtained from our infostery analysis on both the complete (All) and filtered datasets (see Table  1  for comparison). The accuracy is lower by 7-8 points and the MCC by more than 10 points. The five other tested methods analyze correlations between residues displacements or dihedral angles, some of them also accounting for residue interactions, toward identifying residues critical for protein stability and/or information transmission (allosteric communication). We used them to predict the set of 20 positions highly sensitive to mutations in PSD95 pdz3 (Table  3 ).
Discussion In this work, we have investigated the link between computationally characterized structural stability and experimentally measured mutational outcomes. We have introduced new measures and concepts to extract pertinent biological information from conformational ensembles in an automated way and have demonstrated their usefulness in predicting protein mutational landscapes. We have generated conformational ensembles for the wild-type PSD95 pdz3 -CRIPT complex and for 175 mutants. This is, to our knowledge, the first study reporting MD simulations of protein mutants at such a large scale. Our simulations revealed that the mutants adopt a global shape similar to that of the wild type, and they seem to behave the same on the time scale of a hundred of nanoseconds. This is in agreement with recently published structures of the complex  23  : the mutants H372A (PDB code: 5HFB) and G330T (PDB code: 5HEY) almost perfectly superimpose on the wild-type complex (PDB codes: 1BE9, 5HEB) with RMSD values lower than 1 Å.
In these two cases, the experimental data used to validate our predictions are noticeably different from those used for PSD95 pdz3. For TEM-1, we used deep mutational scanning data measuring the ability of the protein to target and degrade antibiotics. This phenotype implies protein stability, ability to bind to the target (antibiotic), to catalyze a chemical reaction (breaking the antibiotic) and to dissociate from the reaction products, whereas the phenotype measured for PSD95 pdz3 reflected more directly the stability of the PSD95 pdz3 -CRIPT peptide complex. It is also worth mentioning that several studies have experimentally characterized TEM-1 mutational landscape  4, 5, 70, 71  , and results reported in these studies only partially agree. For GH, we used exome sequencing data from human individuals, with the hypothesis that positions displaying no to very little variability in a large population of individuals are likely sensitive positions.
Molecular dynamics simulations. Set up of the systems. The 3D coordinates of PSD95 pdz3 in complex with its cognate ligand, a C-terminal peptide derived from CRIPT, were retrieved from the Protein Data Bank  73  (PDB code: 1BE9, residues 302 to 430, 1. 82 Å resolution  74  ). The CRIPT peptide (sequence: TKNYKQTSV, residues -8 to 0) is truncated in the PDB structure (sequence: KQTSV) and the missing residues and side chains were modeled using MODELLER 9v7  75. 175 mutations (Supplementary Table  S1 ) were applied by in silico substitutions using RosettaBackrub  76. PSD95 pdz3 domain contains 2 histidines, whose protonation states were determined so as to locally optimize the hydrogen-bond network: (i) a hydrogen was assigned to the -nitrogen of H317 and (ii) a hydrogen was assigned to the δ-nitrogen of H372.
The 3D coordinates of TEM-1 were retrieved from the PDB entry 1XPB 77 (chain A, residues 26 to 290, 1. 9 Å resolution). TEM-1 contains 6 histidines, whose protonation states were determined so as to locally optimize the hydrogen-bond network: (i) a hydrogen was assigned to the -nitrogen of H26, H112, H158 and H289 and (ii) a hydrogen was assigned to the δ-nitrogen of H96 and H153. 3D coordinates of the GH-GHR complex were retrieved from the PDB entry 1HWG  78  (191 residues for GH, chain A, 237 residues for each receptor, chains B and C, 2. 9 Å resolution). Missing residues, namely 148-153 and 191 of GH and 54-62 of GHR were modelled with MODELLER 9v7  75. All crystallographic water molecules and other non-protein molecules were removed. The 8 disulphide bonds present in the complex, namely (C53, C165) and (C182, C189) in GH, (C38, C48), (C83, C94) and (C108, C122) in GHR1 and GHR2, were kept.
The environment of the histidines was manually checked and they were consequently protonated with a hydrogen at the  nitrogen. Preparation. All crystallographic water molecules and other non-protein molecules were removed. All systems were prepared with the LEAP module of AMBER 12  79  , using the ff12SB forcefield parameter set: (i) hydrogen atoms were added, (ii) the solute was hydrated with a cuboid box of explicit TIP3P water molecules with a buffering distance up to 10 Å, (iii) Na + and Cl -counter-ions were added to reproduce physiological salt concentration (150 mM solution of potassium chloride). Minimization, heating and equilibration. The systems were minimized, thermalized and equilibrated using the SANDER module of AMBER 12. The following minimization procedure was applied: (i) 10,000 steps of minimization of the water molecules keeping protein atoms fixed, (ii) 10,000 steps of minimization keeping only protein backbone fixed to allow protein side chains to relax, (iii) 10,000 steps of minimization without any constraint on the system.
0 fs. The Particle Mesh Ewald (PME) method  82  was employed to treat long-range electrostatics. The coordinates of the system were written every ps. For each system of PSD95 pdz3 -CRIPT peptide complex, 5 replicates of 20 ns were performed, starting with different initial velocities. For TEM-1, 2 replicates of 50 ns were produced. For GH-GHR complex, 2 replicates of 100 ns were produced. See Supplementary Table  S4  for simulation details. Stability of the trajectories. Standard analyses of the MD trajectories were performed with the ptraj module of AMBER 12. The all-atom root mean square deviation (RMSD) from the initial frame, were recorded along each replicate. Based on the RMSD profiles, we performed the subsequent analyses over the last 15 ns of each replicate for PSD95 pdz3 -CRIPT peptide complex, the last 45 ns for TEM-1 and the last 70 ns for GH-GHR complex.
Experimental datasets. PSD95 pdz3 -CRIPT peptide complex. We used the matrix of 20 (amino acid types) × 83 (positions) experimental ΔE values reported in 3 as our reference for defining beneficial, neutral and deleterious mutations. These values correspond to binding affinity changes between PSD95 pdz3 and its cognate ligand, the CRIPT peptide, upon every possible single amino-acid substitution. They were indirectly estimated by measuring the frequencies of mutated alleles in a bacterial population where cells were classified based on their content of PSD95 pdz3 -CRIPT peptide complex (assessed by eGFP levels). The ΔE values range from -1. 89 kcal/ mol (highly deleterious) to 0. 34 kcal/mol (beneficial). The values reported for the wild-type amino acids are not exactly zero but vary between -0.
0 kcal/mol) found in less than 10 sequences. TEM-1. We used the experimental data reported in  4. In this experiment, the protein fitness landscape was characterized by measuring the relative abundance of each possible TEM-1 mutation in a population of cells subjected to antibiotic treatment. The authors estimated the sensitivity of every position to mutations by computing a k⁎ value that reflects the number of mutations leading to inactivation of the protein  4. They identified 8 positions as highly sensitive to mutations ( <. ⁎ k 2 5): S70, K73, S130, D131, E166, D179, T181, K234, G251. Growth hormone. As no experimental measurements of single-point mutation effects were available for GH, the set of putative sensitive positions was defined as have an evolutionary conservation value T JET > 0.
7 and less than 5 alleles bearing missense mutations reported in the Exome Aggregation Consortium (ExAC) database  60. ExAC contains exome sequencing data from more than 60 000 unrelated individuals. We identified 30 positions: A17, A24, F31, C53, F54, S55, I58, L75, L76, S79, L82, I85, W86, P89, V90, L93, L114, L117, G120, L124, L162, C165, F166, K168, D169, K172, E174, E175, L177, V180. Other tools. PyMOL 88 was used for visualization and the analyses were performed using the R software  89. ENCoM  63  was used according to the protocol reported in  64  and described in details in  90. This protocol performs in silico mutation using MODELLER  75  , infer protein motions using normal mode analysis, and predict mutational outcome by computing a ΔΔG value as a linear combination of ENCoM prediction and FOLDX  91  folding energy change.
ACKNOWLEDGMENTS We would like to thank  Elisha Moses ,  Yaron Penn , and  Menahem Segal  for their help and the invaluable discussions we had, as well as for sharing their data with us;  Hans Ekkehard Plesser  for his help and thorough reviews during the implementation and improvements of the numerical models in NEST;  Sylvie Thérond  for helping with the installation of NEST on the Turing supercomputer.
Introduction With the advent of the Big Data era during the last fifteen years, many works have tackled the challenge of dealing with large volumes of data produced at a high velocity (commonly known as the first two V's of Big Data). This has led to the emergence of new types of databases (so-called NoSQL databases  [1] ) and new processing paradigms (e. g. , MapReduce  [2] ). But volume and velocity are just one part of the new issues that we are given to face. The dramatic proliferation of data sources available on the Web poses an unprecedented challenge upon data integration, i. e. , the techniques involved in combining heterogeneous data residing in different systems and locations, into a common, consistent view. This is where we have to tackle the third and fourth V's of Big Data: Variety refers to data syntactic and semantic heterogeneity, while veracity addresses questions such as data interpretation, bias, uncertainty, provenance, and, ultimately, trust.
Despite their success in ensuring a relatively uniform access to resource descriptions, Web APIs fail in making these descriptions interoperable. Indeed, they commonly rely on service-specific data models and proprietary vocabularies that are hardly connected with other ones. More importantly, these vocabularies lack a clear semantic description that is essential to address the variety and (to a lesser extend) veracity issues. The Linked Data principles  [5]  specifically seek to address this lack. They propose to publish data (1) in a common machine-readable format (RDF, the Resource Description Framework  [6] ); (2) using shared and linked vocabularies with clearly defined semantics; (3) while linking related resources throughout datasets. Links bring about the ability to consolidate and make sense of disparate datasets, thus building a uniform distributed knowledge graph.
Similarly to Web APIs, large amounts of data about all sorts of topics are increasingly being published in compliance with the Linked Data principles. As of October 2018, over 25,000 Linked Data datasets were inventoried by LODAtlas (http://lodatlas. lri. fr/). Given the complementary goals of Web APIs and Linked Data, it is commonly admitted that cross-fertilization could stem from their mutual integration. Initiatives like Google's Knowledge Graph (https://goo. gl/BqMC21) or Facebook's Open Graph (http://ogp. me/) are continuously enriching vast knowledge graphs by gathering data from these two worlds alongside other types of data sources. Strikingly however, no standard approaches have emerged so far. Several issues can be pointed out, that explain this lack:.
Each type of Linked Data interface has its own benefits and concerns. RDF dumps allow in-house consumption but do not fit in when data change at a high pace; URI dereferencing (i. e. looking up a URI to retrieve a resource representation in a negotiated media type such as one of the RDF serialization syntaxes) provides subject-centric documents hence lacking query expressiveness. At the other end of the spectrum, SPARQL  [8] , the W3C recommendation to query RDF graphs, is more expressive but puts the query processing cost solely on the server, and studies suggest that allowing clients to run arbitrary SPARQL queries against public endpoints leads to availability issues  [9]. Besides, on-the-fly SPARQL querying of non-RDF databases proves to be challenging, as attested by the many works on SPARQL-based access to relational  [10, 11]  or NoSQL  [12, 13]  databases.
In this article, we propose to harness the Semantic Web standards to enable automatic combination of disparate resource representations coming from both Linked Data interfaces and Web APIs. Our contribution is threefold. Firstly, we define the SPARQL Micro-Service architecture aimed at querying Web APIs using SPARQL while assigning dereferenceable URIs to Web API resources (that do not have URIs beforehand). Secondly, we suggest that leveraging the micro-service architectural principles  [14]  could help to design more distributed and modular Linked Data-based applications. Thirdly, we illustrate the use of SPARQL micro-services in several real-life use cases related to the biodiversity domain. The rest of this article is organized as follows. Section 2 introduces background elements with respect to Web APIs and micro-service architectural principles.
Most Web APIs use a standard representation format such as XML and JSON, thereby ensuring a relatively uniform access to resource representations. These descriptions however often rely on proprietary vocabularies typically documented in Web pages meant for software developers but hardly machine-readable. This is a major difference with Linked Data best practices  [7]  that advocate the use of common, well adopted vocabularies whose semantics is described in machine-readable format. Some initiatives make Web APIs documentation machine-readable, such as OpenAPI (https://github. com/OAI/OpenAPI-Specification) (formerly Swagger). This description however hardly touches upon semantic concerns; it mostly consists of a syntactic description of the operations supported by the interface, and aims to automate the generation of client-side and server-side code.
Definition A SPARQL micro-service S µ is a wrapper of a service S w of a Web API, that allows querying S w using SPARQL. S µ behaves as a regular SPARQL endpoint insofar as it supports the SPARQL Query Language  [8]  (including all query forms: SELECT, ASK, CONSTRUCT, DESCRIBE) and the SPARQL Protocol  [20]. Accordingly, a client invokes S µ over HTTP/HTTPS by passing a SPARQL query Q and optional default and named graph URIs (arguments default-graph-uri and named-graph-uri). Additionally, S µ expects a possibly empty set Arg w of arguments that are specific to the service being wrapped. In turn, S µ invokes S w with the arguments in Arg w , and produces a SPARQL result set that matches Q. Figure  1  illustrates this architecture. The semantics of SPARQL micro-services differs from that of standard SPARQL endpoints in that a SPARQL micro-service is a configurable SPARQL endpoint whose arguments (Arg w ) delineate the virtual graph being queried.
Formally, each pair (S µ , Arg w ) is a standard SPARQL endpoint. As we see it, a SPARQL micro-service provides access to a small, resource-centric graph that corresponds to a small fragment of the whole dataset served by the Web API. This graph is shaped at runtime by (i) the Web API service being wrapped; (ii) the set Arg w of arguments passed to micro-service S µ ; and (iii) the types of RDF triples that S µ is designed to produce. How Arg w is passed to micro-service S µ is implementation-dependent. The implementation we describe in Section 4 passes the arguments as parameters of the HTTP query string, and we discuss several possible alternatives in Section 4. 4. Likewise, how the Web API response is transformed into a SPARQL result set matching Q is implementation-dependent. Various methods may be used at this point, involving e.
g. , different flavors of mapping, reasoning or rule processing. In the context of JSON-based Web APIs, our implementation applies a JSON-LD profile to the Web API response and executes an optional SPARQL query to yield additional triples. With regards to the micro-service architectural principles, we think of SPARQL micro-services as lightweight, independent software units being developed along with the arising of needs. A micro-service development team focuses on one Web API at a time, defines how to wrap the services of interest for clearly identified use cases, tests and deploys the micro-services. Using a container infrastructure like Docker, each micro-service is deployed within a dedicated container that can scale up or down automatically in response to changes in the workload. Example 1.
Between these two extremes lies a spectrum of intermediate approaches. A Linked Data document results from a URI dereferencing. A Triple Pattern Fragment  [23]  (TPF) results from evaluating a single triple pattern against an RDF dataset. The TPF approach succeeds in balancing the query evaluation cost between the client and the server, thereby ensuring better server availability than full-fledged SPARQL endpoints, at the cost of a loss of efficiency. SaGe  [24]  mitigates this issue with a modification of the SPARQL protocol. A SaGe server can interrupt the processing of a SPARQL query and send back to the client the current results alongside the information needed by the server to carry on processing during a subsequent invocation. We see SPARQL micro-services as an alternative Linked Data Fragment interface.
A SPARQL micro-service S µ provides access to a virtual graph that corresponds to a fragment of the dataset served by the Web API. By designing it carefully, we can ensure that S µ will yield small (typically resource-centric) virtual graphs. In this context, virtually any query can be processed at low cost. In other words, full SPARQL Query expressiveness can be supported without jeopardizing the service availability. Consequently, in Figure  3 , SPARQL micro-service results stand nearby SPARQL results since SPARQL micro-services allow requests as specific (expressive) as SPARQL, and to the right of SaGe results since they do not put any additional processing cost on the client.
Implementation To evaluate the architecture proposed in Section 3, we have developed a prototype implementation written in the PHP language and available on GitHub (https://github. com/frmichel/sparql-microservice/tree/0. 1. 0/) under the Apache 2. 0 license. This prototype targets Web APIs able to return a JSON response. This pragmatic choice stems from the fact that most modern Web APIs support JSON. Nevertheless, it would be easy to extend the prototype with respect to other formats such as XML. Also, the prototype requires that the Arg w set of arguments of a micro-service be passed as parameters on the HTTP query string (as exemplified in Section 3. 1). Thus, while the URL of a regular SPARQL endpoint is of the form "http://example. org/sparql", in our implementation a SPARQL micro-service is invoked with additional parameters, like "http://example.
5 to 1 second, as suggested by the measures we report in section 5. Therefore, whenever possible, a caching strategy should be defined with respect to the expected performance. There typically exist many syntactical variants of the same SPARQL query, hence classic HTTP cache servers set up between SPARQL clients and servers fail to reach efficient cache reuse. By contrast, Web API queries allow a lesser syntactical variability. Thus, in the context of SPARQL micro-services, enforcing a cache strategy on the Web API side should ensure better cache reuse. Our prototype enforces a simple cache strategy where each Web API response is stored in a cache database, indexed with a hash of the Web API query, and annotated with an expiration period that 13 https://github. com/frmichel/sparql-micro-service/tree/0.
The most time-consuming tasks lie in reading the Web API documentation and deciding on the mapping towards domain vocabularies. Thence, a developer defines the API query string and the arguments passed to the SPARQL micro-service. Lastly, she writes the JSON-LD profile and the optional INSERT and CONSTRUCT queries that carry out the mappings. In case a Web API requires specific actions to be taken, such as following an authentication workflow or issuing an intermediate query, the developer can customize a simple provided script (https://github. com/frmichel/sparql-micro-service/tree/0. 1. 0/src/sparqlms/manual_config_ example/service. php), allowing for more flexibility. Caching Strategy. Querying Web APIs typically takes in the order of 0. 5 to 1 s, as suggested by the measures we report in Section 5.