dataesr/scientific-paragraphs-categorization huggingface dataset:
For each and any fingerprint, a different matching rule is devised so as to ensure the check of any potential suspect video sequence against a (massive) prerecorded database. Hence, the complexity of visual fingerprinting applications is given both by the fingerprinting computation and by its matching. In the present paper, the focus is set on the way in which such a visual fingerprinting application can be coupled to Blockchain, while ensuring an end-to-end lightweight implementation, demonstrated by a deployment on an embedded platform. Consequently, we will not design a new fingerprinting method, but will integrate an existing one, based on DWT coefficients  [9]  and designed for tracking camcorder video sequences.
The corresponding code (written in Python, in our example) is paired with the transactional Smart contract, and it is executed under its control. The connector serves as an entry and exit point for both on-chain and off-chain entities. Firstly, it is a tool that scans the Blockchain state, block generation and transaction made in order to notify the off-chain entity whenever an action or intervention is requested. Secondly, it collects the required data (block ID, transaction ID, needed action, parameters,. ) and passes them to the external (Python) script. From the external script point of view, this data is the invoker of the entry parameters and the execution. The script decodes the entry parameters, parses them, executes the requested operations and encodes the results. The encoded result is sent back to the connector that will first check the authenticity and integrity and then transfer it to the on-chain entity.
Hardware/Software Experimental Platform To validate the efficiency of the proposed solution, a multiplatform deployment was considered to jointly offer the user the simplicity of graphic user interfaces and the size and low-energy consumption of an embedded platform. The hardware part consists of a PC (acting as an interface) and a Raspberry Pi (acting as the computing device). The PC has the following characteristics: CPU of 64-bit 6core Intel Xeon E5-1650, 3500 MHz, GPU of (2x) AMD FirePro W2100-2GB DDR3, RAM: 32 GB, 2133MHz, with dual Ubuntu/Windows OS. The Raspberry Pi has the following configuration: CPU of 64-bit quad-core ARM Cortex-A53, 1200 MHz, GPU: Multimedia VideoCore IV, 400 MHz, RAM 1 GB SDRAM LPDDR2, 900 MHz, operated by Raspbian Buster Lite (ver. Sept. 2019), kernel version 4.
19. The task allocation on these two computing devices is illustrated in Figure  4. The PC acts just as a kind of interface and it is in charge with the ingestion of the visual documents. The rest of the computing tasks are performed on the Raspberry Pi (both fingerprinting processing and on-chain/off-chain processing). On the Raspberry Pi, the document fingerprint is first extracted by a devoted software. Then, the on-chain/off-chain load balancing module is invoked. This module starts by an on-chain task, namely performing the first part of the Smart contract (parameters such as sender and fingerprint). Then, the off-chain part is invoked, and the Python script checks the fingerprint's existence in the database and, if not present, adds it to the database. Finally, the on-chain part executes the last part of the Smart contract.
On-Chain/Off-Chain Load Balancing Code The software implementation is illustrated by the execution sequence (cf. Figure  5 ) as well as by some excerpts from the code executed on the Raspberry Pi. The complete software implementation is made available as open source under Apache license. We assume that the query fingerprint is already extracted (off-chain) and the user verifies whether it is present in the blockchain or not. While the sequence diagram in Figure  5  shows the life-cycle of the fingerprinting application, it can be considered as a generic workflow for our on-chain/off-chain load balancing. When the user wants to check the uniqueness of a digital document, the fingerprint computation is launched through the graphic interface. Then, a transaction to the Smart contract address precising the entry point and passing the fingerprint as an argument is made.
As soon as the Smart contract is triggered, it blocks the access of other users to avoid conflicts and avoid any potential security issues. When the block containing that transaction is processed and validated (e. g. , by the miner or baker), the user receives the transaction receipt containing its details and the connector receives a notification event that is subscribed to. The connector fetches the user's request and forwards it to the Python script where the document fingerprint is compared with all previous fingerprints processed by the system, and then returns the matching process results to the connector. At this stage, the connector uses a moderator account to make a transaction to the Smart contract with the results. The Smart contract authorizes the moderator transaction, allowing the user to access again and notify the user via an Event.
This process is illustrated here-after through 4 code samples, labeled by (a)-(d). (a) On-chain: user initializes a Tezos node and transfers the operation fees from its address to the Smart contract address (with the required arguments) # User: connect to tezos blockchain $. /tezos-init-sandbox-client. sh #User: call the 'left' smart contract entry point by making a #transaction to the smart contract address with the required fees $ tezos-client transfer $PRICE from $CLIENT_ADDRESS to $SMART_CON TRACT_ADDRESS -arg "Left (Pair "$DOCUMENT_NAME" "$DOCUMENT_FINGERPR INT")" -burn-cap 20 (b) On-chain: user inquires the Blockchain status #> if the transaction passes successfully: # > the smart contract lock further access to that entry point # > a blockchain scanner notifies the related python virtual environment (c) Off-chain: fingerprinting matching in the Python virtual environment >>> if (isValidFingerprint(documentFingerprint)): exists = matchFingerprintWithDatabase(documentFingerprint) >>> if(exists): documentName = getDocumentByFingerprint(documentFingerprint) transfer(from=ADMIN_ADDRESS, to=SMART_CONTRACT_ADDRESS, args=["Right", True, documentName]) >>>else: addDocument(documentName, documentFingerprint) transfer(from=ADMIN_ADDRESS, to=SMART_CONTRACT_ADDRESS, args=["Right", False, documentName, documentFingerprint]) (d) On-chain: user gets the updated Blockchain #> if the transaction passes successfully: # > the smart contract entry point is again available # > a blockchain scanner notifies the client about the results.
Fingerprinting Method and Database In our study, we consider the camcorder fingerprinting method advanced in  [9]. For scanned visual documents, the modules related to inter-frame synchronization are disabled. The fingerprinting method is based on the 2D-DWT (2D Discrete Wavelet Transform) and on a mathematical decision rule for the detection of replicas. The fingerprint per se is represented by a set of 2D-DWT coefficients of the query image. A previous in-depth statistical investigation on the 2D-DWT coefficients demonstrated not only the stationarity of such coefficients but also the stationarity of their modifications under computer-simulated near-duplicated modifications. Through its accurate representation of visual content, the wavelet transform grants the fingerprints the uniqueness property and limits the occurrences of false alarms (i.
e. , fingerprints extracted from different video content have to be different). The fingerprint matching is carried out, based on a repeated Rho test on correlation, which allows the detection of replicas, hence ensuring the robustness property (i. e. , fingerprints extracted from an original video sequence and its replicas should be similar in the sense of the considered similarity metric). To evaluate the method performances, we created a 11,557 digital document database. The digital documents are JPEG images obtained from 25 PhD theses defended in France in various research fields (physics, biology, philosophy,. ) accessible on  [33]. To illustrate the process, some samples are shown in Figure  6 ; it can be noticed that the database features a very heterogeneous visual content, mixing text, numerical values, scientific graphical signs, graphical representations, and images.
The database also features heterogeneity in terms of layout, font size, and language. We also created a set of test images (attacked images). Each test image is composed of two parts extracted from two database images with different ratios ([50% image1, 50% image2], [67% image1, 33% image2], [75% image1, 25% image2]) as illustrated in Figure  7. The resulting testing corpus is composed of 4 × 11,557 = 46,228 visual documents.
These results demonstrate that the main limitation derives from the reduced computing resources: for more than 9 nodes, the maximal time imposed by the blockchain for performing basic operations cannot be met on a Raspberry Pi 3. The Raspberry Pi stops as illustrated in Figure  9. In the sequel, we deployed 5 Tezos nodes, so as to reach a trade-off between functional and non-functional needs. Table  1  presents the execution time of the fingerprinting system (fingerprint extraction, matching algorithm, eventually the adding of new fingerprinting to the database) on a computer and on a Raspberry Pi, as a function of the visual document database size. By analyzing the results presented in Table  1 , firstly, it can be noticed that the Raspberry Pi cannot process databases larger than 1000 documents (with 5 Tezos nodes running).
When the database contains only one document, the execution time on Raspberry Pi is 37. 7 times larger than the one on the PC. However, for databases containing between 10 and 1000 documents, the ratios of the Raspberry Pi execution time to the PC execution time vary between 7. 5 and 9. 8, with an average value of 9. 13. For the two processing structures, these values also show the different weights of the initialization operations in the overall processing time. The values reported in Table  1  are obtained as average values over 10 experiments. The underlying 95% confidence limits can be computed with relative errors lower than 10% for the case of a single visual document in the database and with relative errors lower than 2. 5% for the rest of the cases. This difference can be explained by the fact that in the case of a single document in the visual database, the random effect of the initialization conditions is higher than in the other cases.
September 2019). Moreover, in Figure  10 , the database is graphically represented near a Raspberry Pi; yet, no particular constraint is applied to its storage in the Blockchain. As a final remark, note that the applicative area of our solution is not restricted to fingerprinting. The solution for on-chain/off-chain load balancing can be mutatis-mutandi applied to any type of application, with limited impact in the codes of the modules presented in Figure  3:  • the Smart contract code is slightly modified so as to cope with the new applicative logic (yet the functions related to the on-chain/off-chain balancing are unchanged); • the Secure REST Connector is not expected to suffer any modification; • of course, the off-chain code will be completely changed so as to correspond to the new application.
To the best of our knowledge, only six B. glycinifermentans sp. genome sequences are available in the public database. Here, we performed genome sequencing and comparative genomics analysis of B. glycinifermentans strain JRCGR-1. Cluster analysis of strain JRCGR-1 genes showed that 92. 6% of genes were present in the orthogroups and 7. 4% genes were not assigned to any group. The pangenome size was calculated at 8329 genes and presented an open genome characteristic. Phylogeny based on the pan and core genome demonstrated that all the B. glycinifermentans strains belong to the same clade. The strain JRCGR-1, ANI, TETRA and DDH values were in the range of 96. 1-99. 04%, 0. 996-997, 73. 5-84. 7%, respectively. The strain JRCGR genome exhibits a high level of synteny with multiple locations in B.
glycinifermentans sp. from Pakistan. We previously published a draft genome sequence of B. glycinifermentans strain JRCGR-1 (Assembly number, VHPY00000000)  [9]. Including strain JRCGR-1, only six B. glycinifermentans genome sequences are available in the NCBI database; three complete genome sequences and three draft genomes genome sequences In the current study, we systematically used several methods to comprehensively analyze and compare the genomic features of strain JRCGR-1 and its closely related species. First, we analyzed the evolutionary relationship of this strain with its closely related Bacillus sp. based on 16sRNA, ANI, AAI, TETRA and codon usage. Second, we analyse the pangenome, orthology and synteny analyses. Third, we performed functional annotation of core, accessory and unique genes.
The quality of the reads was elevated using FastQC v0. 10. 1 (http://www. bioinformatics. babraham. ac. uk/projects/fastqc/). The quality of the reads was improved by trimming using Sickle and the DNA short reads were assembled using SPAdes (v3. 12. 0). Finally, 83 scaffolds and 84 contigs were generated for strain JRCGR-1. The quality of contigs or scaffolds were tested by QUAST 5. 02. [10]  and the gene annotation was performed using Prokka v. 1. 13 [11]. tRNA genes were identi ed by tRNAscan-SE  [12]. RNAmmerr and Barrnap v0. 4. 2 were used to nd out RNA genes  [13]. We also assemble and annotated the Plasmid of strain JRCGR-1 using plasmidSPAdes  [14]  and Prokka (version v. 1. 13) software  [11] , respectively.
Bacillus species in this study At the time of writing of this paper, three whole-genome sequences were available in the GenBank and two draft genome sequence was available in the NCBI database. To study the phylogenetic origin of strain JRCGR-1, we used three complete genome sequences of B. glycinifermentans sp. three closely   S1 ). 16s rRNA sequencing and phylogenetic analysis B. glycinifermentans JRCGR-1 partial 16S ribosomal RNA gene sequence was retrieved from the draft genome and blast against the NCBI nucleotide database. These sequences were aligned using muscle function in the MEGA X software  [4]  and the evolutionary history was inferred using the UPGMA method  [15]. The optimal tree with the sum of branch length = 1. 41530778 is shown with optimal tree. The evolutionary distances were calculated by the Maximum Composite Likelihood method  [16]  and are in the units of the number of base substitutions per site.
Multilocus Sequence Analysis (MLSA) The gene sequences of gyrA, gyrB, rpoB and aptD retreated from the complete genome sequence of B. glycinifermentans JRCGR-1. These sequences were separately BLAST against the GenBank database (until November 2019), to nd out the homologues with the highest sequence identity. The tree was generated from gyrA, gyrB, rpoB and aptD gene sequences. The UPGMA method was used to inferred evolutionary history  [15]. The sum of branch length = 0. 06553352 is shown with optimal tree. Poisson correction method was used to calculate the evolutionary distances  [17]  and its unit was in amino acid substitutions per site. Five amino sequences were used for the analysis and each sequence pair (pairwise deletion option), all ambiguous positions were removed. A total of 473 positions were in the nal dataset.
MEGA X  [4]  software was used for evolutionary analyses and Figtree 1. 4. 3 was used to visualized trees. (http://tree. bio. ed. ac. uk/software/ gtree/) Species identi cation using whole-genome phylogenetic analysis To nd out the phylogenetic origin with respect to other Bacillus sp. , the whole genome sequences of seventeen publicly published Bacillus sp. presenting sequence identity similarity with B. glycinifermentans JRCGR-1 were used for comparative genomics. These Bacillus sp. included, B. glycinifermentans, B. licheniformis, B. paralicheniformis, B. sonorensis and two outgroup Bacillus sp. (B. velezensis and B. subtilis) were included in the study (Table  S1 ). CompareM v0. 0. 24 software toolkit was to nd out pairwise genome statistics (e. g. , amino acid identity (AAI)) and statistics for individual genomes (e.
g. , codon usage,) (https://github. com/dparks1134/CompareM). DIAMOND-0. 814 software was used for similarity search (https://github. com/bbuch nk/diamond) and Prodiagal-2. 6. 3 (https://github. com/hyattpd/Prodigal) was used for gene calling over the genome. For taxonomic classi cation, the query (B. glycinifermentans JRCGR-1) genome was compared to the target genomes (selected 19 Bacillus sp. given in Table  S1 ) using CompareM v0. 0. 24 software and the putative homologs were identi ed. Genome-to-Genome Distance Calculator (GGDC)(calculated by formula 3) was used to calculate the in silico DDH (DNA-DNA hybridization) values  [18]. We used Jspecies software  [19]  to compute the tetranucleotide signatures (TETRA) and the average nucleotide identity (ANI) values. For ANI, we used NUCmer (ANIm)  [20]  algorithms.
General genome analyses The pan-genome and core genome were identi ed from orthologous gene clusters; OrthoFinder  [22]  output le was converted to PanGP  [23]  format for pan-genome analysis. We also constructed a phylogenetic tree using core and pan genes with Bacterial Pan Genome Analysis (BPGA) software  [24]. Figtree 1. 4. 3 was used to visualize the Newick les. (http://tree. bio. ed. ac. uk/software/ gtree/).
1, KBN06P03352 and JRCGR-1, sequence identity with any species contained in the database was above 97%, suggesting that strain JRCGR-1 could represent as B. glycinifermentans sp. [27]. To further con rm the results of the 16S rRNA gene sequence analysis, we analyzed four housekeeping genes of B. glycinifermentans sp. : gyrA (Fig. 1B ), gyrB (Fig. 1C ), rpoB (Fig. 1D ), and aptD (Fig. 1E ). Each one of these genes was BLAST against the GenBank protein database (NCBI)  [28]. The nding reveals that all the housekeeping genes of strain JRCGR-1 presented higher similarities (≥97%) with other B. glycinifermentans strains in the GenBank database. These results con rm that JRCGR-1 is classi ed as a B. glycinifermentans sp.
In the context of a contagious disease, the outcome of a primary case can in addition generate secondary occurrences of the pathology in a close spatial and temporal neighborhood; this can result in local overdispersion and in higher spatial and temporal dependencies due to direct and/or indirect transmission. In consequence, we test models including a Negative Binomial distribution (instead of the usual Poisson distribution) to deal with local overdispersion. We also use a specific spatio-temporal link in order to better model the stronger spatial and temporal dependencies due to the transmission of the disease. We have proposed and tested 60 Bayesian hierarchical models on 400 simulated datasets and bovine tuberculosis real data. This analysis shows the relevance of the CAR (Conditional AutoRegressive) processes to deal with the structure of the risk.
As disease mapping is a spatiotemporal smoothing method, naturally data must be spatially and temporally dependant. As this approach is applied on non-contagious pathologies, the spatial and temporal correlations are classically due to the structure of unknown environmental cofactors. They may also be linked to the repartition and structure of the population. Disease mapping methodology is based on Bayesian inference, which aims to estimate parameters using the realization of events and some assumptions concerning the studied phenomenon. These assumptions can include some covariates and processes which handle the structure of the risk, according to the specific knowledge of the epidemiologists, in order to fit the model to the problem. The Bayesian framework particularly suits disease mapping issues as it models limited data; indeed for each period and each area, a single value is recorded.
As a conclusion, there is a lack of statistical methods to evaluate the risk at the scale of a country in the context of contagious diseases whose incidence is low. The aim of our study is to propose a generic disease mapping method dedicated to rare infectious diseases, i. e. , diseases for which the outcome of a case involves the likely occurrence (https://agriculture. gouv. fr/mots-cles/dgal%20-% 20bsa. sdspr. dgal@agriculture. gouv. fr@) and cannot be provided by the authors. Moreover legal restrictions exist in France for this kind of data: when a disease case occurs in a geographical unit with few population (as observed in our dataset), anonymized data does not guaranty that the identity of the case cannot be discovered. Thus the real dataset cannot be provided. of other cases in their (spatial and temporal) neighborhood and for which the number of cases remains quite low.
In this context, data are generally locally overdispersed and strongly spatially and temporally structured. We test flexible distributions at the first level to handle local overdispersion. We also consider lots of deterministic functions and random processes to model the spatial (and enventually temporal) dependencies. Relevant methodological choices would provide efficient disease mapping models to describe data concerning rare infectious pathologies. Thus we test a wide range of models in order to determine which ones are the most adapted to handle contagion. We first recall the structure of the Bayesian hierarchical models used in the context of disease mapping and explains our methodological choices. Then we describe the contagious framework of our study, in particular our bovine tuberculosis data and the way we simulated other datasets, congruent with an infectious pathology.
More precisely, if we compare the distribution of cases with the quantiles of a Poisson distribution, we easily notice Simulated data. In addition of the analysis of real data, we test our method on simulated datasets in order to check their ability to describe the real risk for a pathology of interest, and to draw robust conclusions from our study. Deterministic building of the true risk. We firstly set a uniform disease risk among the territory. In order to model basic contagious processes, we simulated in each dataset 3 circular disease outbreaks. More precisely, they were defined as 3 hotspots around which the risk exponentially decreases. The radius (around 100km) has been chosen congruently with bovine tuberculosis outbreaks which concern 3 (Dordogne) to dozens hexagons (Southwest). These 3 outbreaks (Fig  3 ), common to all the datasets, showed different characteristics, in order to simulate different basic scenarios: • the first one (O1) was constant over time in risk intensity and moved from Northwest to the Southeast at a speed of about 100km per year in order to cover a large range of the country, see S2A Fig; • the second one (O2) was constant over time in location (Northeast of the country) and risk intensity, see S2B Fig; • the third one (O3) was constant over time in location (Southwest) while its risk intensity increased geometrically from 2001 (no outbreak) to 2005 (a maximum extend similar to O1 and O2) then decreased geometrically from 2006 to 2010, leading to a growing and then decreasing circular outbreak, see S2C Fig.
The risk values were then standardized, so their global product was 1. The outbreaks have been designed to test the detection ability of the models in 3 basic situations: stationarity, move, grow and decrease. Simulation of the cases. Cases were finally simulated using population data, the global incidence of the bovine tuberculosis we used as example and resulting risk values. We distinguish 4 scenarios including or not local overdispersion (CO versus NO): (COLR). Constant Overdispersion and Large differences in Risk levels; (COSR). Constant Overdispersion and Slight differences in Risk levels; (NOLR). No Overdispersion and Large differences in Risk levels; (NOSR). No Overdispersion and Slight differences in Risk levels. For each scenario we simulated 100 datasets using Poisson distribution when there is no overdispersion (NOLR, NOSR) and Negative Binomial distributions in case of overdispersion (COLR, COSR).