dataesr/scientific-paragraphs-categorization huggingface dataset:
A particular advantage of the overall approach compared to systems like Frama-C or VCC is that all these semantic theories are conservative extensions of HOL, hence no axiom-generators are used that produce the "background theory" and the verification conditions passed to automated provers. Isabelle/C provides a general infrastructure for semantic annotations specific for back-ends, i. e. modules that generate from the C source a set of definitions and derive automatically theorems over them. Last but not least, navigation features of annotations make the logical context explicit in which theorems and proofs are interpreted. The heart of Isabelle/C, the new C. command, is shown in Figure  1. Analogously to the existing ML. command, it allows for editing C sources inside the. brackets, where C code is parsed on the fly in a "continuous check, continuous build" manner.
The context definition includes the sections imports and keywords. For example our context definition states that C_Command is the name of the sub-document depending on C_Eval which transitively includes the parser sources as (ML files) sub-documents, as well as the C environment and the infrastructure for defining C level annotations. Keywords like C or C_file must be declared before use. For this work, it is vital that predefined commands allow for the dynamic creation of user-defined commands similarly to the definition of new functions in a shell interpreter. Semantically, commands are transition functions σ → σ where σ represents the system state called logical context. The logical context in interactive provers contains -among many other things -the declarations of types, constant symbols as well as the database with the definitions and established theorems.
Some Basics of PIDE Programming ML val pos = @{here}; val markup = Position. here pos; writeln ("And a link to the declaration\ \ of 'here' is " ^markup) A basic data-structure relevant for PIDE is positions; beyond the usual line and column information they can represent ranges, list of continuous ranges, and the name of the atomic sub-document in which they are contained. It is straightforward to use the antiquotation @{here} to infer from the system lexer the actual position of the antiquotation in the global document. The system converts the position to a markup representation (a string representation) and sends the result via writeln to the interface. In return, the PIDE output window shows the little house-like symbol ∧ , which is actually hyperlinked to the position of @{here}. The ML structures Markup and Properties represent the basic libraries for annotation data which is part of the protocol sent from Isabelle to the front-end.
The C11 Parser Generation Process and Architecture Isabelle uses basically two parsing technologies: 1. Earley parsing  [9]  intensively used for mixfix-syntax denoting λ -terms in mathematical notation, 2. combinator parsing  [11]  typically used for high-level command syntax. Both technologies offer the dynamic extensibility necessary for Isabelle as an interactive platform geared towards incremental development and sophisticated mathematical notations. However, since it is our goal to support programming languages in a fast parse-check-eval cycle inside an IDE, we opt for a Lex and Yacc deterministic grammar approach. It turns out the resulting automata based parser performs well enough for our purpose; the gain in performance is discussed in the next section. In the following, we describe a novel technique for the construction and integration of this type of parser into the Isabelle platform.
Since it is mostly relevant for integrators copying our process to similar languages such as JavaScript or Rust 3  , users of the Isabelle/C platform may skip this section: for them, the take-home message is that the overall generation process takes about 1 hour, the compilation of the generated files takes 15s, and that the generated files should be fairly portable to future Isabelle versions. We base our work on the C11 parsing library http://hackage. haskell. org/package/language-c implemented in Haskell by Huber, Chakravarty, Coutts and Felgenhauer; we particularly focus on its opensource Haskell Yacc grammar as our starting point. We would like to emphasize that this is somewhat arbitrary, our build process can be easily adapted to more recent versions when available. The diagram in Figure  2  presents the architecture of Isabelle/C.
Generating the AST In the following, we refer to languages by L , I. The notation AST L I refers to abstract syntaxes for language L implemented in language I. For example, we refer by AST C11  ML to an AST implementation of C11 implemented in SML. Indices will be dropped when no confusion arises, or to highlight the fact that our approach is sufficiently generic. For our case, we exploit that from a given Haskell source AST HS , Haskabelle generates to a maximum extent an Isabelle/HOL theory. Via the Isabelle code generator, an AST ML can be obtained from a constructive AST HOL representation. However, the process is challenging for technical reasons in practice due to the enormous size of AST C11 (several hundreds of constructors), and due to certain type declarations not initially supported by Haskabelle (we have to implement here the necessary features).
A Validation via the seL4 Test Suite The AutoCorres environment contains a C99 parser developed by Michael Norrish  [14]. Besides a parser test-suite, there is the entire seL4 codebase (written in C99) which has been used for the code verification part of the seL4 project. While the parser in itself represents a component belonging to the trusted base of the environment, it is arguably the most tested parser for a semantically well-understood translation in a proof environment today. It is therefore a valuable reference for a comparison test, especially since AST C99 and AST C11 are available in the same implementation language. From AST C11  HOL to AST C99 HOL we construct an abstraction function C ↓. A detailed description of C ↓ is out of the scope of this paper; we would like to mention that it was 4 man-months of work due to the richness of AST C11.
In contrast, PARSE report intends to maximize markup reporting, irrespective of a final parsing success or failure, and reports are provided in parallel during its (monadic) parsing activity. Thus, in the former scenario, the full micro-kernel written in 26 kLoC can be parsed in 0. 1s. In the latter, all reports we have thought helpful to implement are totally rendered before 20s. Applying C ↓ takes 0. 02 seconds, so our PARSE report gives an average of 2s for a 2-3 kLoC source. By interweaving a source with proofs referring to the code elements, the responsiveness of PIDE should therefore be largely sufficient.
Thus, having pre-and post-conditions locally in the source close to its point of relevance increases its maintainability. It became therefore common practice to design languages with annotations, i. e. structured comments inside a programming source. Examples are ACSL standardized by ANSI/ISO (see https://frama-c. com/download/acsl. pdf) or UML/OCL  [6]  for static analysis tools. Isabelle/C supports both the inject-into-proof style and annotate-the-source style in its document model; while the former is kind of the default, we address in this section the necessary technical infrastructure for the latter. To which part of the AST does the annotation refer? To i ? a*i ? The assignment? The loop? Some verification tools use prefix annotations (as in Why3 for procedure contracts), others even a kind of parenthesis of the form: /*@ annotation_begin */.
The annotation command highlight is a predefined Isabelle/C ML-library function that is interpreted as C annotation. Its code is implicitly parameterized by the syntactical context, represented by stack_top whose type is a subset of AST C11 , and the lexical environment env containing the lexical class of identifiers, scopes, positions and serials for markup. The navigation string before highlight particularly influences which stack_top value gets ultimately selected. The third screenshot in Figure  3  demonstrates the influence of the static environment: an Isabelle/C predefined command setup allows for "recursively" calling the C environment itself. This results in the export of definitions in the surrounding logical context, where the propagation effect may be controlled with options like C_starting_env.
Defining Annotation Commands Extending the default configuration of commands, text and code antiquotations from the Isabelle platform to Isabelle/C is straightforward. For example, the central Isabelle command definition: Outer_Syntax. command: K cmd -> (σ -> σ ) parser -> unit establishes the dynamic binding between a command keyword K cmd = definition|lemma|. and a parser, whose value is a system transition. 10 The parser type stems from the aforementioned parser combinator library: 'a parser = Token. T list -> 'a * Token. T list.
The Case of AutoCorres The AutoCorres environment consists of a C99 parser, compiling to a deepish embedding of a generic imperative core programming language, over a refined machine word oriented memory model, and a translator of this presentation into a shallow language based on another Monad for non-deterministic computations. This translator has been described in  [10, 23]  in detail. However, the original use of AutoCorres implies a number of protocol rules to follow, and is only loosely integrated into the Isabelle document model, which complicates the workflow substantially. Note that the integration of AutoCorres crucially depends on the conversion AST C11 ⇒ AST C99 of C ↓ discussed in subsection 4. 3. In particular, for the overall seL4 annotations INVARIANT, INV, FNSPEC, RELSPEC, MODIFIES, DONT_TRANSLATE, AUXUPD, GHOSTUPD, SPEC, END-SPEC, CALLS, and OWNED_BY, we have extended our implementation of C ↓ in such a way that the conversion places the information at the right position in the target AST.
Conclusions We presented Isabelle/C a novel, generic front-end for a deep integration of C11 code into the Isabelle/PIDE framework. Based on open-source Lex and Yacc style grammars, we presented a build process that constructs key components for this front-end: the lexer, the parser, and a framework for user-defined annotations including user-defined annotation commands. While the generation process is relatively long, the generated complete library can be loaded in a few seconds constructing an environment similar to the usual ML environment for Isabelle itself. 20 kLoC large C sources can be parsed and decorated in PIDE within seconds. Our framework allows for the deep integration of the C source into a global document model in which literate programming style documentation, modelling as well as static program analysis and verification co-exist.
As antibodies are a very important tool for diagnosis, therapy, and experimental biology, a large number of antibody structures and sequences have become available in recent years. Therefore, tools that allow the analysis, comparison, and visualization of this large amount of antibody data are crucially needed. We developed the antibody high-density alignment visualization and analysis (Yvis) platform to provide an innovative, robust and high-density data visualization of antibody sequence alignments, called Collier de Diamants. The Yvis platform also provides an integrated structural database, which is updated weekly, and many different search and filter options. This platform can help to formulate hypotheses concerning the key residues in antibody structures or interactions to improve the understanding of antibody properties.
INTRODUCTION Antibodies or immunoglobulins are vertebrate immune system proteins that are produced by B cells and can bind to antigens with high specificity and affinity. For this reason, antibodies are an important tool in diagnosis, therapy and experimental biology  (1). To elucidate the antibody characteristics, large numbers of antibody structures and sequences have been generated in the last years. The number of antibodies or antibody fragment structures deposited in Protein Data Bank (PDB)  (2)  has increased exponentially  (3) , leading to the development of databases of antibody structures  (4) (5) (6) (7). Moreover, many antibody sequences have been obtained by high-throughput sequencing of the B-cell receptor repertoire  (8, 9). This extraordinary and still increasing number of antibody structures and sequences demands integrative data organiza-tion and tools for their analysis, comparison and visualization.
One of the major bottlenecks in this field is the concomitant visualization of a large amount of antibody data. AbYsis (4) and IMGT/3Dstructure-DB (5) allow antibody visualization, but only a limited number of sequences can be analysed at a time. Indeed, abYsis presents a classical multiple sequence alignment (MSA) that displays a limited number of sequences and positions each time. IMGT/3Dstructure-DB display only one antibody sequence using the IMGT/Collier des Perles representation  (10)  that allows sequence analysis related to the antibody structure. To fill this gap, we developed the an-tibodY high-density alignment visualization and analysis (Yvis) platform that includes: (i) an updated weekly and curated antibody structure database (Yvis database) and (ii) integrated antibody analysis resources, such as an antibody high-density alignment visualization called Collier de Diamants, and multiple filter options to analyse data from user files or from the Yvis database.
Yvis database: an updated weekly and curated repository of data on antibody PDB structures The Yvis database is an updated weekly collection of data on antibody PDB structures (in complex with an antigen or not), such as PDB and chain identification, antibody and protein antigen-producing organisms or type (hapten, carbohydrate or nucleic acid), gapped sequences of antibody chains, germline information (assigned V and J genes with their identity values), and antigen-antibody putative contacts. The Yvis script, developed in Python, extracts a list of antibody PDB structures from SAbDab  (7)  that is updated weekly. The following data are extracted from this list, processed, and stored in the Yvis database: (i) PDB and chain identifications, (ii) names of the organisms producing antibody and antigen (when applicable) and (iii) antigen molecule description.
When the SAbDab list does not contain the antibody-or antigen-producing organism name, Yvis script extracts this information from the corresponding PDB structure file, acquiring the ORGAN-ISM SCIENTIFIC value from SOURCE record after retrieving the molecule Id from COMPND record. After data extraction, Yvis script checks whether the organism names match the UniProt Taxonomy  (11) , and correct them if required (Supplementary Table  S1 ). Data are manually curated, if the standard name is not found automatically. These standard names facilitate the Yvis database search, reducing the diversity of organism names, for instance by eliminating all synonyms. The Yvis script submits antibody chain sequences to IMGT/DomainGapAlign (5) to obtain gapped sequences and germline information. Then, it processes the result page and extracts the gapped sequence of the variable domain of each chain, following the IMGT numbering  (12).
Moreover, the script extracts and stores the V and J germline genes assigned to the chain sequence, and their identity values. Finally, to obtain information on the putative antibodyantigen contacts, the Yvis script downloads the PDB structure files and extracts the antibody chain amino acids that potentially interact with a peptide or protein antigen using the Biopython PDB module  (13). Then, the distance between each ␣-carbon of the antibody and antigen amino acids is calculated. If the distance between two ␣-carbons is not higher than 8 Å, the position that contains the amino acid is marked as making a putative contact. This distance is used because it allows including putative direct interactions between antigen and antibody and also water-mediated interactions  (14).
Yvis resources: integrated tools for high-density antibody data visualization and analysis The Yvis platform integrates resources that allow the analysis of antibody variable domains that have been uploaded as user sequences or selected from the Yvis database. This platform is a web-based application that process sequences in a server or in a user's internet browser, depending on the analysed data. The server-side application was developed using PHP and Mysql, and the client-side using the JavaScript and D3. js framework. The Yvis Platform offers input and search versatility. With the Yvis platform, users can analyse antibody structures stored in the Yvis database or uploaded by them. Different search options (Figure  1A ) are available to select, from the database, a set of antibody structures to be analysed.
It is possible to show all antibody chains stored in the Yvis database, or to specify a list of PDB identifiers, or a pair of PDB:chain identifiers. Moreover, users can choose to show free or complexed antibodies, and in the latter case, they can indicate the antigen type (hapten, carbohydrate, nucleic acid or protein). For protein antigens, they can indicate the producing organism. Users can also select antibodies with assigned germline V or J genes, or produced by user-selected organisms. In addition, users can search antibodies by using keywords contained in the literature related to PDB structures. After defining the PDB structure search criteria, the user can apply additional filters to avoid sequence redun-dancy, such as: (i) to choose only one representative chain of each type (heavy or light) in each PDB structure; (ii) to specify an identity threshold that ensures that none of the filtered sequences has an identity value higher than the userspecified value.
This approach was based on Cd-hit  (15). Because of the time requested to analyse and group all sequences, the identity filter is not used by default. All these filters can be combined. Users can also analyse antibody sequences obtained from an IMGT/DomainGapAlign (5) results file, an IMGT/HighV-QUEST (  16 ) gapped amino acid results file, or a FASTA file containing gapped, or ungapped chain sequences or even CDR sequences (Figure  1A , User Input file). When a user submits an IMGT results file, the Yvis platform will process it in the user's browser. Moreover, when a user submits ungapped sequences in a FASTA file, the Yvis platform will number them using ANARCI  (17)  in the Yvis server. Independently of the chosen input data (Yvis database or user's data), the Yvis platform will generate an initial set of antibody sequences that can be visualized with the Collier de Diamants representation.
In this manner, positions that are involved in antibody-antigen interactions in the majority of the analysed sequences can be easily detected. However, it is only possible to show this attribute for chains from the Yvis database obtained from an antibody in complex with a protein or peptide antigen in the corresponding PDB structure. The Yvis platform also allows comparing the MSA with a user-defined sequence (Figure  1B  (II)): a target sequence, a germline gene sequence, or a consensus sequence. When the user inserts a sequence to be compared with the MSA, the Yvis displays, in the centre of each pie chart that represents a position, a small inner circle coloured according to the amino acid class of the input sequence that corresponds to that position (same colour code used for the pie chart).
This representation facilitates the comparison of the user's sequence with the MSA by just checking whether the colour of the small circle is the same as the one of the larger pie chart sector for that position. In addition to the pie chart representation, Yvis makes available a detailed bar chart for each position, showing the number of each amino acid in the corresponding position. Additional filter options can be used to select antibody subsets. After having selected the initial set of antibodies from the Yvis database or after uploading antibody sequences, the user can use filters to select sequence subsets and to restrict the analysis to specific chain types, antibodyproducing organisms, antigen type or producing organisms, antigen molecule description, and germline information (right side of Figure  1B ).
A continuously updated source of antibody structure information The Yvis database is updated weekly and currently includes data on 3423 antibody structures (from 22 different antibody-producing organisms) in complex with protein antigens (from 155 different antigen-producing organisms) or non-protein antigens (184 structures with haptens, 22 with nucleic acids, and 106 with carbohydrates), as well as 1,136 structures of antibodies in free form. Most of the antibodies in the database are of human (1444) and mouse (1362) origin. The organism-producing names are in the standard format defined by UniProt Taxonomy  (11) , allowing the user to search or filter the database content easily. To achieve that, we automatically modified the antigen-producing organism name of 389 structures, and manually changed the antibody-producing organism name of 58 structures and the antigen-producing organism name of 77 structures.
In this database, users can select a set of antibodies, searching mainly by antibody-producing organisms, antigen types, antigen producing-organisms, or assigned germline genes. Moreover, users can restrict the set to be analysed by excluding engineered chains, multiple antibodies in the same structure, and sequences with identity above the user-defined cut-off. These combinations of different search criteria and constraints are not available in other antibody structure databases, such as abYsis (4), IMGT/3Dstructure-DB  (5)  and SAbDab  (7).
Case studies demonstrate the Yvis platform versatility and easy high-density data visualization to help hypothesis formulation To test the Yvis platform, we carried out three case studies using anti-HIV antibodies. In the first study, we selected anti-HIV gp120 antibodies available in the PDB, through a search of the Yvis database after choosing the HIV antigenproducing organism and the option that forces the result to contain only one chain of each type from each PDB file. After this search, to restrict the analysis to only anti-gp120 antibodies, we used the antigen molecule description filter and limited the analysis to the heavy chains. The alignment presented by Collier de Diamants of the 124 identified sequences (Supplementary Figure  S1 ) allowed the easy visualization of known anti-HIV neutralizing antibody characteristics, such as a long CDRH3  (19) , and of some conserved positions (e.
g. 8, 22, 119 and 121). Moreover, it highlighted that many of the analysed chains could make contact with the antigen via CDR2 and framework region 3 (positions from 57 to 69). This is a known characteristic of some anti-HIV CD4-binding-site antibodies  (20). Nevertheless, this is not a very common characteristic of antibody heavy chains. In the second case study, we downloaded a FASTA file of transcript sequences of an HIV-infected donor  (19)  from the Sequence Read Archive (21) using the SRR1767440 access number. Then, we submitted the FASTA sequence to IMGT/HighV-QUEST  (16) , and then uploaded the results file containing the amino acid information for 478 047 heavy chain sequences to the Yvis platform. The platform excluded sequences with ambiguous amino acids, leaving 330 800 sequences (Supplementary Figure  S2 ).