dataesr/scientific-paragraphs-categorization huggingface dataset:
They have been used in various approaches, for example in protein superimposition  (24, 25) , and for the analysis  (26, 27)  or prediction  (28, 29)  of protein binding sites. PB assignment was done with a slightly modified Python PBxplore tool (https:// github. com/pierrepo/PBxplore). The equivalent number of PBs (N eq ) is a statistical measurement similar to an entropy and represents the average number of PBs a given residue takes  (23). N eq is calculated as follows: Neq ¼ exp À X 16 X¼1 f x ln f x ! Where f x is the observed frequency of PB x. A N eq value of 1 indicates that only one type of PB is observed, while a value of 16 is equivalent to a random distribution. The 3D structure representation is generated using PyMOL software (http://www. pymol. org).
68%), whereas the classical a helix is seen only 11. 18%, which is low (the average frequency of a helix in proteins is 30%). PTMs in structural data are not precisely recorded, making their identification difficult (see 'Material and Methods' section). Discordance between UniProt position and PDB residue numbering is observed in 51% of PTM-SD entries. The atom coordinates, backbone atoms included, of 27% of PTM-SD entries are recorded in the HETATM PDB records, which are usually reserved for molecules that are not part of a biological polymer (as prosthetic groups, inhibitor, solvent molecules and ions). As far as, in PTM-SD, 38% of entries described in PDB files have a different three-letter code known for the 20 classical amino acids; e. g. threonine known as THR is named TPO in case of phosphorylation, or lysine known as LYS is defined as M3L in case of trimethylation.
General search The data can be explored using two search modes: (i) the simple mode (Figure  2A ) and (ii) the advanced mode (Figure  2B ). The first one allows searching the PTMs by PDB id(s), and by UniProt accession number(s) and then filtering according to the classic PTM annotation (21 different kinds of PTMs are proposed at this level), and specific organisms; both short name and more common one are given, e. g. ACAGO (Tarantula spider). Multiple choices can be done, and all criteria can be combined to complete more complex queries. The advanced mode adds more precise criteria. A dedicated research can be done with selecting specific amino acid types, secondary structures, SCOP class classification  (30) , protein length, as well as number of PTMs observed in PDB chain. Additionally two detailed annotations are provided, which came directly from the PDB MODRES records and dbPTM fields.
Details The results are given in the table, for each line, the organism, the UniProt AC, the PDB and chain identifiers. Additionally, the specific annotation found in MODRES PDB record and the dbPTM annotation(s) with their corresponding position are provided, as they can differ. For instance, the methylation observed on residue 4 in the histone demethylase ceKDM7A [PDB code 3N9L chain B,  (31) ] is defined in the MODRES PDB record as 'N-TRIMETHYLLYSINE'. At the corresponding position in the protein sequence (Lysine 5 in P08898), four different annotations are found in dbPTM: N6-methyllysine, N6, N6-dimethyllysine, N6,N6,N6-trimethyllysine and N6-acetyllysine. The SCOP class of the PDB chain, the amino acid corresponding to the PTM site position in the protein sequence and the assignments of PBs and secondary structure in the vicinity of the PTM site are also given.
The PTM site is colored in purple to locate it easily. For each entry, cross-links to PDB and UniProt Web sites are provided. Finally, a 'details' link for each entry is provided. By clicking on it, users will be redirected to a dedicated webpage (Figure  2D ) where all PTMs annotations found in dbPTM related for this specific position are available. Related PTM-SD entries are given for other positions on the protein chains and for the same UniProt AC. Sometimes, a huge number can be found, like the glycosylation observed on position 150 in the chain A of the human dipeptidyl peptidase IV [PDB code 1TK3  (32) ], which has six related PTM-SD entries on the same chain and 667 on the same UniProt AC. In the same, below the various information, the visitor can find useful aligned information, which allows the analyses of PTMs in the sequence and structural context simultaneously.
An alignment between the sequence from protein structure and the sequence from UniProt was performed by ClustalW 2. 0. 12  (33)  and symbols for similarity/identity of positions are showed. A sequence representing the extracted information from PDB records is also aligned emphasizing discrepancies, missing residues, inserted residues and residues for which all the atoms are defined in HETATM records. Additionally, sequences of secondary structure and PBs assignments are also aligned. On the current 'details' page, the selected PTM position is highlighted in purple, whereas the other PTM sites found in the PDB chain are colored in yellow. The PTM position found in other PDB chain are highlighted in green. To help the visitor to explore the 3D structure, the PyMOL script used to compute the PTM gallery is also provided.
PTM-SD tools/specific dataset creation After selecting entries from the results table, the visitor has access to three tools (namely 'Statistics', 'Neq' and 'Clustering') developed to make a quick analysis of the PTMs selection and to facilitate the creation of specific PTMs dataset (Figure  2E ). For instance, with the simple and advanced search, it is easy to define a set of protein structures. By using the 'Statistics' tool, the visitor can analyze the distribution of a PTM with regards to an organism, e. g. 'Methylation' is found in structures from 24 organisms, with Chlamydomonas reinhardtii being the most important one (33. 91%). Similarly, the visitor can look at an organism and see which PTMs are found, e. g. three different PTMs are observed in rabbit proteins (Methylation, Phosphorylation and N-linked Glycosylation).
By selecting 'Methylation' and 'Rabbit', 67 entries are found. The 'Statistics' tool shows that in fact these entries correspond to one annotation of methylation found in one UniProt AC, but solved in 35 PDB id codes and 67 PDB id chains. This methylation does not belong to only one local conformation, as showed by the 'Neq' tool, which is an entropy index based on the PB assignment at the vicinity of the PTMs site. At one position, if all the PBs are identical, Neq equals to 1, whereas if the 16 are seen equivalently, Neq equals to 16. For this PTM site, Neq equals to 1. 79, underlining differences between local conformations; surprisingly, it is before the PTM that Neq equals to 1. At last, by using 'Clustering' tool, the visitor has the possibility to compute dendogram and histogram of pair-wise sequence identity between selected proteins.
He could also reduce redundancy in his selected entries, thereby creating a nonredundant selection. For instance, the 'Hydroxylation' represents 34 UniProt AC for 64 PDB id codes, 165 PDB id chains and 314 PTM-SD entries. The use of a 30% threshold leads to deselect entries from the results table (Figure  2E ). The related PTM-SD data and the list of PDB ids can be downloaded at the 'create your dataset' section (Figure  2F ). These data could be of great interests for studying sequence-structure-function relationships at the light of PTMs. For example, users interested in studying the impact of phosphorylation in protein structure could easily browse the database and get access to all the phosphorylated residues solved in structure and experimentally annotated. By using the 'Neq tool' they could have a quick first analysis of the local conformation observed at the neighboring phosphorylation site.
This type of analysis could be easily done again withmore precise criteria, as specific organisms or specific modified amino acids. Then by using the 'Clustering tool' they could create, and later download, a nonredundant data set, which will be the base of work for extraction of structural descriptors needed in a classic phosphorylation prediction protocols. Similarly, users motivated by comparative modeling could use the database to select protein structures associated with specific experimentally annotated PTMs. By using the extracted data from PDB, and the clean sequence given for Modeller software, which are available in 'detail page' of each entry, they have the necessary data to compute protein model containing PTMs. Implementation PTM-SD is developed and maintained using MySQL. All data extraction, treatment and update are carried out with Python scripts.
The front-end interface was developed in HTML/PHP and animated using JavaScript/jQuery. The interactive graphics and flowcharts are generated using the JavaScript charting library Highcharts 3. 0 (www. high charts. com). The clustering is computed using 'hclust' and 'cutree' functions of the R statistical software, version 2. 15 (http://cran. r-project. org/). All gallery illustrations were rendered using the molecular visualization software PyMOL 1. 5. Update PTM-SD is regularly updated in two steps. The structural data are updated weekly, immediately after the PDB updates, and the annotations data are updated each month.
Discussion Structural data are limited in PTMs databases, e. g. in dbPTM  (14) , Phospho3D  (16)  or PTMcode  (15). It mainly corresponds to secondary structure or solvent accessibility predictions. The available 3D representation of proteins is present only for visualization purposes. It facilitates the investigation of structural characteristics surrounding the PTM sites regardless to the real presence of the annotated PTMs. Other databases give access to the structure of the modification itself, but out of the protein fold context, e. g. RESID  (35) , BCSDB/Glycoscience  (36)  or GlycomeDB  (37). Some databases provide cross-linking or id mapping from the PDB where annotated PTMs are resolved; however, they are specific to one PTM type of organism, e. g. Glycan Fragment DB  (38) , O-GLYCBASE  (39)  and ProGlycProt  (40).
PTM-SD is the only structural database that is generic to numerous PTMs in PDB structures and also underlines the complex case of many PTMs, i. e. structure discrepancies or multiple PTMs annotation. It was designed as an easy-to-use tool to meet the needs of different scientific communities: for biologists interested by PTM data for specific proteins, or organisms, and for bioinformatician searching for structural criteria to take into account in structural studies or in modeling/prediction protocols. Our extensive analyses of structural data had revealed that (i) the number of PTMs in protein structures is not negligible, (ii) some PTMs are heterogeneous and difficult to access properly in the PDB files because they are not really protein materials, (iii) the annotation of the same modification can be different and (iv) more surprisingly, a PTM can be crystallized in the structure while annotated as a different type of PTM in other databases.
Related PTM-SD entries found in same PDB chain and same UniProt AC are accessible through cross-link. Image gallery was done, thanks to PyMOL software, and below alignment section, done thanks to Clustal W, allows direct observation of the sequence/structure relationship surrounding PTM sites. On this page, scripts for PyMOL software and template sequence for Modeller comparative software are provided. (E) From the complete set of selected entries, it is possible to look at the distribution of organisms, proteins, PDB ids/chains and PTM types. Neq entropy index quantifies the local structural divergences between the PTMs. From this step, the visitor can reduce the protein redundancy into his selected entries. (F) At last he can download the list of PDB chain and the PTM-SD data related to his selection.
Acknowledgements We thank  Stephane Te  ´letchea for his helpful comments on the manuscript. Funding P. C. acknowledges grant from  Ministry of Research (France). This work was supported by grants from the  Ministry of Research (France) ;  University Paris Diderot ,  Sorbonne Paris Cite(France) ; the  National Institute for Blood Transfusion (INTS, France) ; the  Institute for Health and Medical Research (INSERM, France) ; and  'Investissements d'avenir', Laboratory of Excellence GR-Ex (France)  to P. C. , J. R. and A. G. B. ; by  ANR NaturaDyRe (France ,  ANR-2010-CD2I-014-04 ) to J. R. Funding for open access charge:  Institute for Health and Medical Research (INSERM, France).
In this paper, we explore different techniques to synthesize modular invariants for synchronous code encoded as Horn clauses. Modular invariants are a set of formulas that characterizes the validity of predicates. They are very useful for different aspects of analysis, synthesis, testing and program transformation. We describe two techniques to generate modular invariants for code written in the synchronous dataflow language Lustre. The first technique directly encodes the synchronous code in a modular fashion. While in the second technique, we synthesize modular invariants starting from a monolithic invariant. Both techniques, take advantage of analysis techniques based on propertydirected reachability. We also describe a technique to minimize the synthesized invariants.
Introduction In this paper, we present an algorithm for synthesizing modular invariants for synchronous programs. Modular invariants are useful for different aspects of analysis, synthesis, testing and program transformation. For instance, embedded systems often contains complex modal behavior that describe how the system interacts with its environment. Such modal behaviors are usually described via hierarchical state machines (HSM). The latter are used in model-based development notations such as Simulink and SCADE -the de-facto standard for software development in avionics and many other industries. For the purpose of safety analysis, Simulink/SCADE models are compiled to a lower level modeling language, usually a synchronous dataflow language such as Lustre  [4]. Preserving the original (hierarchical and modular) structure of the model is paramount to the success of the analysis process.
We sketch a direction for minimization based on a CEGAR-like  [5]  technique. In summary, this paper makes the following contributions: • Two techniques to generate modular invariants for synchronous code. One based on a modular compilation of Lustre code into Horn clauses, and a second one based on extracting modular invariants from monolithic invariants. • An implementation of these techniques that targets programs written in the synchronous dataflow language Lustre. • A sketch of a technique to minimize invariants using CEGAR-type approach. The rest of the paper is organized as follows. In the next section, we introduce synchronous languages in general and the synchronous dataflow language Lustre. In Section 3, we describe the first technique a procedure to compile in a modular fashion Lustre code into Horn clauses.
Preliminaries Synchronous languages are a class of languages proposed for the design of so called "reactive systems" -systems that maintain a permanent interaction with physical environment. Such languages are based on the theory of synchronous time, in which the system and its environment are considered to both view time with some "abstract" universal clock. In order to simplify reasoning about such systems, outputs are usually considered to be calculated instantly  [2]. Examples of such languages include Esterel  [3] , Signal  [1]  and Lustre  [4]. In this paper, we will concentrate on the latter. Lustre combines each data stream with an associated clock as a mean to discretize time. The overall system is considered to have a universal clock that represents the smallest time span the system is able to distinguish, with additional, coarser-grained, user-defined clocks.
Therefore the overall system may have different subsections that react to inputs at different frequencies. At each clock tick, the system is considered to evaluate all streams, so all values are considered stable for any actual time spent in the instant between ticks. A stream position can be used to indicate a specific value of a stream in a given instant, indexed by its clock tick. A stream at position 0 is in its initial configuration. Positions prior to this have no defined stream value. A Lustre program defines a set of equations of the form: y 1 ,. , y n = f (x 1 ,. , x m , u 1 ,. , u o ) where y i are output or local variables and u i are input variables. Variables in Lustre are used to represent individual streams and they are typed, with basic types including streams of Real numbers, Integers, and Booleans.
Lustre programs and subprograms are expressed in terms of Nodes. Nodes directly model subsystems in a modular fashion, with an externally visible set of inputs and outputs. A node can be seen as a mapping of a finite set of input streams (in the form of a tuple) to a finite set of output streams (also expressed as a tuple). The top node is the main node of the program, the one that interface with the environment of the program and never be called by another node. At each instant t, the node takes in the values of its input streams and returns the values of its output streams. Operationally, a node has a cyclic behavior: at each cycle t, it takes as input the value of each input stream at position or instant t, and returns the value of each output stream at instant t. This computation is assumed to be immediate in the computation model.
Lustre nodes have a limited form of memory in that, when computing the output values they can also look at input and output values from previous instants, up to a finite limit statically determined by the program itself. Figure  1  describes a simple Lustre program: a node that every four computation steps activates its output signal, starting at the third step. The reset input reinitializes this counter. Typically, the body of a Lustre node consists in a set of definitions, stream equations of the form x = t (as seen in Figure  1 ) where x is a variable denoting an output or a locally defined stream and t is an expression, in a certain stream algebra, whose variables name input, output, or local streams. More generally, x can be a tuple of stream variables and t an expression evaluating to a tuple of the same type.
Most of Lustre's operators are point-wise lifting to streams of the usual operators over stream values. For example, let x = [x 0 , x 1 ,. ] and y = [y 0 , y 1 ,. ] be two integer streams. Then, x + y denotes the stream [x 0 + y 0 ; x 1 + y 1 ,. ]; an integer constant c, denotes the constant integer stream [c, c,. ]. Two important additional operators are a unary shift-right operator pre ("previous"), and a binary initialization operator → ("followed by"). The first is defined as pre(x) = [u, x 0 , x 1 ,. ] with the value u left unspecified. The second is defined as x → y = [x 0 , y 1 , y 2 ,. ]. Syntactical restrictions on the equations in a Lustre program guarantee that all its streams are well defined: e. g. forbidding recursive definitions hence avoiding algebraic loops.
Modular synthesis In the last section we gave an informal overview of the synchrounous dataflow language Lustre. A formal semantics of Lustre is described in  [4]. In this section, we describe our technique to generate modular Horn clauses starting from Lustre code. A Lustre program L is a collection of nodes [N 0 , N 1 ,. , N m ] where N 0 is the top node, i. e. , the main function. Each node is represented by the following tuple: N i = (I i , O i , L i , Init i , Trans i ) where I i , O i and L i are set of input, output and local variables. Init i and Trans i represents the set of formulas for the initial states and the transition relation respectively, and they are defined as follows: i∈N v i = ρ(s i ) where • v i ∈ O i ∪ L i and s i is the expression such that Vars(s i ) ⊆ O i ∪ I i ∪ L i.
We now describe the compiler lus2horn : L → H, which given a Lustre program L = [N 0 , N 1 ,. , N m ] generates a set of Horn clauses H that are semantically equivalent to L. The current compiler only handles a simplified version of the Lustre v4 language without the constructs to manipulate clocks, or complex data structure. The following steps describe the various stages of lus2horn: Normalization: In the first phase the compiler lus2horn transforms the equations of the Lustre node to extract the stateful computations that appear inside expressions. Stateful computation can either be the explicit use of a pre construct or the call to another node which may be stateful. The extraction is made through a linear traversal of the node's equations, introducing new equations for stateful computation 1.
Similarly the Horn rule encoding the initial state is defined as follows: (ii) (rule (⇒ φ (Init i ) (I N i I i O i State i ))) Given a Horn clause H of the form (rule ⇒ Body B), where Body is a conjunction of expression and B is a predicate, a model π : B → F is a mapping from B to a set of formulas F such that it makes every rule H valid. In other words, π represents the set of invariants for the Horn clause H. Let (Main I N 0 O N 0 State N 0 ) be the predicate encoding the collecting semantics of the main node N 0 of the Lustre program L = [N 0 , N 1 ,. , N m ]. Each node N i being defined by the two Horn clauses I N i and T N i. The semantics of the whole Lustre program is inductively encoded as follows: (iii) (rule (⇒ (I N 0 I N 0 O N 0 State N 0 ) (Main I N 0 O N 0 State N 0 )) (iv) (rule (⇒ (and (T N 0 I N 0 O N 0 State N 0 State N 0 ) (Main I N 0 O N 0 State N 0 )) (Main I N 0 O N 0 State N 0 )) (iii) characterizes the set of initial states while (iv) defines the induction step.
Let P L be the expression representing the safety property for the Lustre program L = [N 0 , N 1 ,. , N m ]. As specified above, P L is a predicate defined over the signature of the main node N 0. Let P H be its equivalent in Horn clauses format, i. e. P H = φ (P L ). Then, we encode the checking of the property P H on the Horn encoding as defined above in the following manner: (v) (rule ⇒ (and (Main I N 0 O N 0 State N 0 ) (not P H )) Error) 2 By construction, circular definition of nodes are forbidden in Lustre: this recursive definition is well-founded. where Error is the predicate marking the error state. Such state is reachable if and only if the property is not valid. If its unreachable then the property is valid. Tools like Z3  [9]  are able to give a certificate for (un)reachability.
A certificate of reachability is in a nutshell a proof of unsatisfiability. In this case the certificate is presented as a trace. A certificate for un-reachability is in a nutshell a model for the recursive predicates. The following theorem establishes a correspondence relation between Lustre program and the compiled Horn clauses H using the function lus2horn. Theorem 1. The semantics of the Lustre program L = [N 0 ,. , N m ] and the semantics of its Horn clauses encoding H = lus2horn(L) are in strong bisimulation. Proof: A classical strong bisimulation proof only sketched here: the two set of initial states coincide while each transition that could be performed on one side is computable on the other: (i) for every execution of L there is a derivation of H, and (ii) for every derivation of H there is an equivalent execution of L.
Example As an example of the compilation process lus2horn, we will consider a simple Lustre program that compares two implementations of a 2-bit counter: a low-level Boolean implementation and a higherlevel implementation using integers. The left hand side of Figure  2  illustrate the Lustre code. The greycounter node internally repeats the sequence ab = {00, 01, 11, 10, 00,. } indefinitely, while the integercounter node repeats the sequence time = {0, 1, 2, 3, 0,. }. In both cases the counter returns a boolean value that is true if and only if the counter is in its third step or input variable reset is true. The top node test is an example of a synchronous observer. So we wish to verify the safety property that both implementations have the same observable behavior, i. e. that the stream OK is always true.