dataesr/scientific-paragraphs-categorization huggingface dataset:
Bytecode transformation is used in several applications. In  [17] , the authors developed an algorithm to ensure portable thread migration in Java. This algorithm is based on bytecode transformation. Bytecode is transformed in order to enable programs to save and restore their execution state after migration through the network. Another purpose for bytecode transformation is presented in  [3]  where a framework based on bytecode transformation is developed in order to enable Java applications to perform CPU management Transforming a program may occur at runtime. The update is then said to be dynamic (Dynamic Software Update: DSU). In  [14]   [16] , the authors presented a system to perform dynamic software update: while the Java Card virtual machine is executing the program, the bytecode is updated.
In  [7]  , a tool is developed in order to perform runtime bytecode update for Smalltalk. This large interest of bytecode transformation and its use in many applications lead to the question of its correctness. In fact, a transformation may introduce an error which may alter the bytecode in a different way from that is expected by the programmer. In addition, some applications where the update occurs are critical, such as in Java Card. In these applications where security issues are involved the update must pass certification procedure for example Common Criteria  [1]. For a certain certification level one has to provide a formal proof of the security mechanism implemented. A formal way to reason about transformations and verify their validity is then necessary. In this work, we present a first step for a general framework for reasoning about bytecode transformation.
Overview of EmbedDSU EmbedDSU  [14]  [15]  [16] , is a software-based DSU technique for Java based smart cards which relies on the Java virtual machine. It is based on the modification of an embedded virtual machine. EmbedDSU is divided in two parts: off-card and on-card: • In off-card, in order to apply the update only to the parts of the application that are really affected by the update, a module called DIFF generator determines the syntactic changes between versions of classes. The changes are expressed using a Domain Specific Language (DSL). Then, the DIFF file result is transfered to the card and used to perform the update. • The on-card part is divided into two layers: 1) Application Layer: The binary DIFF file is uploaded into the card. After a signature check with the wrapper, the binary DIFF is interpreted and the resulting instructions are transferred to the Patcher in order to perform the update.
EmbedDSU updates three principal parts: • The bytecode: The process updates first the bytecode of the updated class and the meta data associated with it: constant pool, fields table, methods table. • The heap: The process updates the instances of the updated class in the heap, obtains new references for modified objects and updates instances using these references. • The frames: The process updates in each frame in the thread stack the references of updated objects to point to new instances. This paper addresses the first part: bytecode update at the method level. The types of updates that may occur are: adding, modifying or suppressing bytecode instructions, changing the signatures of a method or modifying local variables. These updates are contained in the DIFF file (also called patch) which indicates exactly which is the update and where it occurs in the bytecode.
This work is on-going. Our aim immediately is to complete the implementation by extending the language to other instructions in bytecode and to the other possible transformations for methods (adding arguments for example). On the other side, we aim to complete the work concerning behavioral aspects by defining algorithms to take into account deleting instructions in predicate transformation and to choose a configuration of existing tools for specification and reasoning. The verification presented is implemented using the functional language Ocaml. We aim to use mathematical reasoning to prove its correctness. In the longer term, we wish to use a proof assistant to reason about bytecode transformation.
Forests are thought to play an important role in the regional dynamics of the West African monsoon, through their capacity to extract water from a permanent and deep groundwater table to the atmosphere even during the dry season. It should be the case for riparian forests too, as these streambank forests are key landscape elements in Sudanian West Africa. The interplay of riparian forest and groundwater in the local hydrodynamics was investigated, by quantifying their contribution to the water balance. Field observations from a comprehensively instrumented hillslope in northern Benin were used. Particular attention was paid to measurements of actual evapotranspiration, soil water and deep groundwater levels. A vertical 2-D hydrological modelling approach using the Hydrus software was used as a testing tool to understand the interactions between the riparian area and the groundwater.
Acknowledgements. This research was funded by  IRD  and  INSU  in the framework of the  AMMA program. Based on a French initiative, AMMA was developed by an international scientific group and funded by a large number of agencies, especially from  Africa ,  European Community, France, UK  and  USA. More information on the scientific coordination and funding is available on the AMMA International web-site: http://www. amma-international. org. The AMMA-CATCH observing system has been funded since 2001 by  IRD, INSU  and the  French Ministry of Research : http://www. amma-catch. org/ in cooperation with  Direction Générale de l'Eau (DG-Eau) of Benin. The article processing charges have been funded by  INSU-CNRS. The authors wish to particularly thank the researchers and students who helped them throughout the different steps of this work:  T.
We propose an algorithm to simultaneously reconstruct all gene organizations along a species phylogeny, minimizing the number of gains and breakages of adjacencies that link consecutive genes on chromosomes. We build upon the dynamic programming principle proposed by Bérard et al. [13]  and extend it to consider as input reconciliations containing lateral gene transfer produced by Szöllősi et al. [14]. We implement our algorithm naming the resulting software DeCoLT, in reference to DeCo  [13]  (Detection of Coevolution) with Lateral Transfers. We examine two datasets of gene trees from a single set of cyanobacteria species. The first set of gene trees is computed from sequence alignements only  [15] , and the second one is computed by a species tree aware method  [16]. Our method and the efficiency of the computation is based on the hypothesis that adjacencies evolve independently from each other.
While extant genomes consist either of a single or a relatively small number of linear or circular chromosomes, this hypothesis implies that reconstructed ancestral genomes may in theory exhibit more complex arrangements. For example an ancestral gene may be involved in more than two adjacencies, or a large number may have only a single adjacent gene. In the cyanobacteria dataset, extant genomes are all circular, and the ancestral genomes inferred by DeCoLT are also close to being circular with only a few deviations. Most deviations result from the absence of signal to reconstruct genomes in deep ancestors, but some are caused by errors in gene trees, leading to errors in ancestral gene contents. We observe that ancestral genome organizations computed from gene trees that are based on both the species tree and the sequence are closer to being circular than those computed from gene trees based on sequence alone.
Complexity Let m be the number of gene trees, n be the maximum number of genes in a gene tree, and s be the number of species. There are s -1 time slices, so every branch of a gene tree may be subdivided as many as s -1 ≤ n times, which gives at most n 2 events (most of them are NoEvent events) in a given tree. The number of equivalence classes is O(m 2 ), and hence there are O(m 2 n 4 ) comparisons computed during the initial construction of dynamic programming matrix M. In practice, the number of equivalence classes is much smaller, closer to m than O(m 2 ), and the majority of the O (n 2 ) events each tree are NoEvent events. On the cyanobacteria dataset of (m =) 1099 families from (n =) 36 genomes, our implementation, DeCoLT, of this algorithm constructed the adjacencies in under 3 hours on a standard desktop computer.
Cyanobacteria ancestral genomes The algorithm has been implemented and run on two datasets. They both have the same species tree (depicted in Figure  3 ), on the same set of 36 extant genomes from cyanobacteria and the same extant adjacencies. They differ by their set of gene trees. One of them is the sequence trees, which are maximum likelihood trees constructed from a model of sequence evolution using multiple alignments of protein sequences of extant genes from each family, taken from  [11]. The other is the ALE trees, which are maximum likelihood trees constructed from a model of sequence evolution in conjunction with a birth and death branching model to account for origination, duplication, transfer and loss, taken from  [16]. As transfers are very likely to involve lineages outside any given phylogeny  [14] , reconciled trees have nodes leaving the species tree (SpeciationOut) and nodes transferring to the species tree (Transfer).
Note that the reconciliations may contain "speciation outside" nodes, which mean diversification of a gene outside the species tree, and our algorithm do not handle these nodes for the moment. In order to handle these datasets we simply removed these nodes, which has the effect of cutting some trees into pieces. For both datasets, ancestral adjacencies were computed using DeCoLT. The degree of each ancestral gene (the number of adjacencies it belongs to) was computed, and we then plotted the proportion of ancestral genes having degree k for k between 0 and 6 (Figure  4 ). There are almost no genes with degree larger than 2 in either dataset. The proportion of genes with degree 2 increases from 17% for sequence trees to 31% for ALE trees. This means that we: (i) accurately reconstruct ancestral adjacencies because they all have a circular structure; and (ii) the quality of gene trees nearly doubles the resolution of ancestral genomes.
Acknowledgements The authors would like to thank  Sèverine Bérard  and  Thomas Bigot  for advice on the implementation aspects of DeCoLT. MP is funded by a  Marie Curie Fellowship  from the  Alain Bensoussan program  of  ERCIM  and and GS is funded by the  Marie Curie Fellowship 253642 "Geneforest", and the Albert Szent-Györgyi Scholarship   A1-SZGYA-FOK-13-0005. This work is funded by the  Agence Nationale pour la Recherche ,  Ancestrome  project  ANR-10-BINF-01-01. This article has been published as part of  BMC Bioinformatics Volume 14 Supplement 15 , 2013: Proceedings from the  Eleventh Annual Research in Computational Molecular Biology (RECOMB) Satellite Workshop on Comparative Genomics. The full contents of the supplement are available online at http://www. biomedcentral. com/bmcbioinformatics/supplements/ 14/S15.
Comparing, classifying and modelling protein structural interactions can enrich our understanding of many biomolecular processes. This contribution describes Kbdock (http://kbdock. loria. fr/), a database system that combines the Pfam domain classification with coordinate data from the PDB to analyse and model 3D domain-domain interactions (DDIs). Kbdock can be queried using Pfam domain identifiers, protein sequences or 3D protein structures. For a given query domain or pair of domains, Kbdock retrieves and displays a non-redundant list of homologous DDIs or domain-peptide interactions in a common coordinate frame. Kbdock may also be used to search for and visualize interactions involving different, but structurally similar, Pfam families. Thus, structural DDI templates may be proposed even when there is little or no sequence similarity to the query domains.
INTRODUCTION Many biological processes involve protein-protein interactions (PPIs). Thus, comparing and classifying PPIs can enrich our understanding of biology. To date, some 90 000 protein structures have been deposited in the Protein Data Bank (PDB)  (1). However, recent analyses have shown that only about half of the expected number of human PPIs have so far been detected experimentally  (2) , and that only a small fraction of these have a 3D structure in the PDB  (3). Nonetheless, there is a growing appreciation that template-based approaches are becoming increasingly useful for proteome-scale modelling of PPI networks  (4). Furthermore, recent results from the CAPRI blind docking experiment and other studies have shown that using structural homology can significantly improve the quality of protein docking predictions  (5, 6).
There is, therefore, a need for user-friendly resources that can help to navigate networks of protein structure interactions and to propose templates for homology docking. Here we present a major update to our Kbdock database system  (7). Briefly, Kbdock combines sequence alignments from Pfam  (8)  with coordinate data from the PDB to classify the spatial arrangements of domaindomain interactions (DDIs) by Pfam family. The main feature that distinguishes Kbdock from other structural PPI or DDI databases [e. g. SCOPPI  (9) , SCOWLP  (10) , PiSite  (11) , 3DID  (12) , GWIDD  (13) , IBIS  (14) , ProtCID  (15) , InterEvol  (16) , PrePPI  (17)  and Interactome3D  (18) ] is that it uses a spatial clustering algorithm to define domain family binding sites (DFBSs). When all of the members of a Pfam domain family are superposed in a common coordinate frame, each DFBS describes the approximate spatial location of a cluster of binding sites without needing to enumerate individual domains or interaction residues.
The current Kbdock database is built from the June 2013 snapshot of the PDB and the latest version of Pfam (release 27. 0). It collects and classifies hetero and homo DDIs, as well as all domain-peptide interactions (DPIs). Overall, the new database contains 288 309 domain structures belonging to 6516 Pfam entries and involving 239 494 DDIs and 11 852 various DPIs. Compared with the original version of Kbdock, which was built in 2009 and which stored only hetero DDIs, these figures correspond to an increase of 50% over the previous number of structures and interactions. Kbdock has an easy-to-use web interface, and all queries may be expressed using Pfam IDs or by providing the PDB codes or amino acid sequences of the domains of interest. The user may also provide a pair of query domains that are presumed to interact to search for similar DDIs or to define structural templates for docking.
The results of queries against the database may be visualized in a common coordinate frame using the Jmol plug-in, and relationships between DDIs may be navigated visually using a Cytoscape plugin  (20). The user may download the coordinate files of the superposed DDIs and a multiple sequence alignment in which the interaction residues are annotated. Thus, Kbdock provides a powerful and user-friendly interface to explore and visualize known DDIs and DPIs and to find knowledge-based templates with which to model unsolved protein complexes.
Defining Pfam domain family binding sites The Kbdock database is populated using a series of inhouse scripts that (i) extract the protein chains for a PDB file, (ii) feed the chain sequences to PfamScan  (21)  to identify annotated Pfam domain and peptide families, (iii) cut each chain into separate domains and peptides, (iv) count the number of atomic contacts between each pair of domains or a domain and a peptide, (v) filter out identical copies of the same interaction using a sequencebased within-PDB filter and (vi) calculate the interface surface area of all domain-domain contacts using DSSP  (22). We use the same criteria as Stein et al. (12)  to define a DDI or a DPI (i. e. essentially 5 or more contacts are required for a physical interaction). We then classify each DDI as 'intra' or 'inter' and 'homo' or 'hetero' according to whether the interaction is within one chain or across two chains, and whether the interaction involves the same or different chains, respectively.
If an inter-chain hetero DDI has multiple crystal contacts, we assume that the biological interface is the one with the largest interface area  (23, 24). We retain all distinct inter-chain homo interactions because in this case it can be less clear how to identify a biologically relevant interaction  (15). Next, we annotate every interface residue as 'core' or 'rim' depending on their solvent accessibility  (25). For every Pfam domain having structures found by the aforementioned protocol, the domain sequences are aligned using HMMER  (26). This multiple sequence alignment is used to place all of the domains and their DDI partners in a common coordinate frame using the ProFit program (http://bioinf. org. uk). For each superposed DDI, a binding site 'centre residue' is calculated by selecting the core and rim residues that contact the partner domain and by selecting the C a atom that is nearest to a weighted average of the core (75%) and rim (25%) C a coordinates.
Sorting the rows of this matrix by Kpax similarity score then gives a ranked list of Pfam family neighbours for each Pfam family, from which the top 1000 family neighbours for each Pfam are stored in the Kbdock database. Thus, when searching for DDIs that involve a given query domain, or when navigating related interactions, the 2013 version of Kbdock can rapidly retrieve similar DDIs using its pre-calculated neighbour lists. We recently compared the performance of Kpax with the widely used TM-align  (28)  protein structure alignment program, and with the fast Yakusa (29) structure aligner and database search program. When searching the CATH database (version 3. 4, 11 330 domains at the 35% sequence identity level) using 213 different CATH domains as queries, we found that Kpax was faster and considerably more accurate than Yakusa, and that it gave almost the same high level of recall and precision as TMalign (Kpax gave an aggregate area under the curve of 0.
Kbdock database implementation and web interface A full description of the relational data model and schema diagram is provided under the Kbdock home page. The physical database is implemented using the MySQL database engine (http://www. mysql. com). Operations such as parsing and processing the data are implemented in the C and Prolog programming languages. Binding site direction vectors are clustered using R scripts (http:// www. r-project. org/). The public Kbdock website and database files are available at http://kbdock. loria. fr/. The Kbdock web interface is written mainly in the PHP scripting language (http://php. net). Some queries are processed using Prolog and Linux shell scripts. The Jmol plug-in is used for 3D visualization (http://www. jmol. org), whereas the Cytoscape plugin (http://cytoscapeweb.
Kbdock database content Table  1  summarizes the total numbers of non-redundant DDIs and DPIs stored in Kbdock. As noted in Methods, Kbdock retains only one 'biological' interaction for each pair of inter-chain hetero DFBSs, whereas it stores all distinct pairs of DBFSs for inter-chain homo interactions. This contributes to the relatively large number of stored inter-chain homo DDIs. It is also worth noting that Kbdock follows the Pfam convention of distinguishing between 'annotated' and 'unannotated' DPIs. The final three columns of Table  1  show that, after spatial clustering by DBFSs, the PDB contains only a few thousand binding sites and interaction types when considered at the domain family level. A more detailed break down is provided on the Kbdock website.
Analysing DDIs and DPIs by Pfam family To analyse the binding sites of a given Pfam family, the user may use the Kbdock 'Search' page to enter a Pfam identifier (e. g. Kunitz_legume), a Pfam accession number (e. g. PF00197), a keyword (e. g. inhibitor), an amino acid sequence or a PDB file of a protein structure. If a sequence or a structure is entered, the PfamScan utility is used to determine the Pfam accession number. Otherwise, the accession number is found directly from the Kbdock database. Kbdock then retrieves a non-redundant list of DDIs involving the query domain, grouped by their binding site. Figure  1  shows the hetero interactions found when Kbdock is queried using the Kunitz_legume protease inhibitor domain (PF00197). The Jmol plugin shows the retrieved DDIs in the coordinate frame of the query domain.
The query domain is shown in grey and interacting residues are shown as wire sticks. The user may choose to view the DDIs together or individually. An annotated Pfam consensus alignment of the retrieved domains is also provided, in which each sequence is colour-coded according to the core, rim and centre residue assignments. Links to download the multiple sequence alignment and the superposed PDB files as a single compressed file are also available. In a similar way, the user may analyse DPIs involving a given domain family. For example, Figure  2  shows examples of the DPIs belonging to three selected domain families. This figure was generated using VMD for clarity, whereas all graphics on the Kbdock web pages are drawn using Jmol for better portability. However, VMD scripts are provided, which can render each Jmol scene locally in high resolution.
Retrieving docking templates To find docking templates, the user enters two PDB codes or uploads two PDB files and he then specifies which pair of Pfam domains in those structures should be used as queries. If Kbdock finds one or more FH DDI templates for the query domains, it shows the superposed query and FH template(s) using Jmol along with colour-coded sequence alignments of the query and template domains showing the core, rim and centre binding site residues (similar to Figure  1 ). As before, the user may download the query and template structures in the superposed orientations. If no FH DDIs exist in the database, Kbdock will output a non-redundant list of SH templates with annotated sequence alignments along with a Jmol view of the superpositions. It is also possible to use Pfam structural neighbours to find FH templates.
To give a particular example, let us suppose we wish to model the complex between a glutamine-dependent amido transferase (GATase) and the cyclase domain of an imidazole glycerol phosphate (ImGP) synthase. The delivery of an amino group by the GATase to the cyclase site at the N-terminal region of the TIM barrel synthase is one of the steps in histidine biosynthesis  (33). The structure of a GATase/ImGP cyclase complex and the structures of the unbound domains have already been solved for the bacterial thermophile Thermatoga maritima (34). Hence, modelling this complex from the unbound domains should be trivially easy for any homology modelling protocol. Part A of Figure  3  shows VMD views of the FH template (PDB code 1GPW) that was retrieved when querying Kbdock using the GATase (PDB code 1K9V) and an ImGP synthase structure (PDB code 1THF) that belong to the GATase (PF00117) and His_biosynth (PF00977) Pfam families, respectively.