dataesr/scientific-paragraphs-categorization huggingface dataset:
QUANTIFICATION AND STATISTICAL ANALYSIS Visualisation and quantification of fluorescently labelled products Reaction products were resolved on 12% denaturing polyacrylamide 8 M urea gels. Labelled oligonucleotides were detected with Typhoon FLA 9500 (GE Healthcare) and quantified with ImageQuant TL 8. 1 software (GE Healthcare) as published previously. 2  The different products (obtained by RNase HII or Fen1 cleavage, extension by Pol or ligation by Lig1) were quantified as the intensity of the corresponding band as a percentage of total lane intensity. In RER reconstitution, the starting substrate consists of double-stranded DNA containing a matched rA/dT or mismatched rA/dC base pair. The top oligonucleotide strand (87-nt) that harbors the rAMP is dual-labelled with a Cy5 (green label) and a 6-FAM dye (red label) at the 3' and 5' ends, respectively.
• An open-source software implementation of the above architecture for the Ethereum framework, alongside key modules for the Tezos framework. This software is shown to function standalone and as part of an already established workflow. The present paper is structured as follows. Section II is devoted to state-of-the-art concepts and tools for fingerprinting, applicative blockchains, and their joint usage. Section III advances the methodological pillars of our solution before combining them into a novel architecture. In on their physical or network location, nor based on asset ownership. This notion is often summarized by "never trust, always verify"  [25]. Section IV, we detail the software implementations of the architectural components while end-to-end proof-of-concept implementations are instantiated for two use cases in Section V.
A. FINGERPRINTING-BASED VISUAL CONTENT TRACKING As previously mentioned, visual content protection can take different approaches. Although the workflow we will present could benefit from data encryption at the level of the data storage or hidden signatures without any extra drawbacks, it focuses on content tracking. Indeed, in the process of turning multimedia content into a web3 assets, said content naturally becomes accessible and hence vulnerable to copying or abusive usage. As such, the first step it to enable the tracking of content by identifying it. Cryptographic hashing functions  [39]  might seem like a natural solution to identify content through fixed-length digests and consequently allow one to look for copies throughout a data storage in an efficient manner. Yet, multimedia content scarcely remains strictly similar when being processed.
1) Smart Contracts The fundamental brick of application-oriented blockchains is the Smart Contract  [56] , an automated piece of code written in blockchain-specific language (e. g. , Solidity for Ethereum or Michelson for Tezos) which runs as programmed, with no possibility of change or influence from any central authority or unauthorized party. Smart Contracts provide tamperproof, zero-trust features, and complete data integrity but suffer from low processing capabilities and lack of maintenance which bars them from competing with their web2 counterparts  [57]. Furthermore, blockchain programming languages do not support as many features as off chain ones (e. g. , Python or Java), limiting the complexity of the data formats and of the operations that can be included in a Smart Contract. Specifically, all operations in blockchains (transactions, Smart Contract deployments, etc.
In practice, these issues materialise in the risk of unmodifiable mistakes happening (bolstered by code being public and hence targetable), the lack of general-purpose libraries, the absence of support, or the constrained number of local variables, for instance. As such, it is not only best practice but mandatory to keep Smart Contracts simple and intuitive to avoid them becoming prohibitively expensive or significant liabilities. Our study deals with the secure storage of these Smart Contracts, and although the specific strategy is novel, we do not add any novel aspect to data storage. Numerous studies have brought out unique features, including repair groups  [60]  and large-scale computability  [61].
Marketplace-agnostic royalty modules also exist and can be added to our token before being distributed, e. g. , the EIP2981  [84]  standard on Ethereum or a Royalty Managing Token Level Smart Contract (RM-TLSC) brought forth in  [70]. The former relies on Intellectual Property (IP) and royalty metadata being appended to the token which can then be enforced by sellers whilst the latter sets the token in a separate Smart Contract which enforces a set of rules. Figure  3  shows simplified schemas of the initial distribution lifecycle of assets implementing both solutions. The issues and limitations covered hereabove invite one to consider applying advanced visual content protection techniques to these assets. Unfortunately, blockchains cannot support the required computational load used to support the fingerprinting methods presented in Section II.
The proof of concept for the on chain -off chain connection we use in our workflow was brought forth in  [89] , in which the authors advance a lightweight framework for document tracking. This idea was extended in  [90]  to include a blockchain shadow database to track original inputs, which we also make the best of later in this paper (c. f. , Section III). Other combined uses of multimedia technologies and blockchains have notably been studied for IoT  [91]  and cloud computing  [92].
At this point of the process, we have an immutable trace of semantic data processing which establishes a precedent for the original piece of content. To enable the further use of the assets with contingent state-of-the-art solutions (as dictated by our DC4), we create a standardized token (as presented in Section II. B. 2) which includes links to the data storage entries. This is the first block of the right side of Figure  4. This token can either represent the original asset or a related asset, e. g. , an asset representing exploitation rights or IPRs. We then protect these tokens with state-of-the-art solutions (as presented Section II. B. 3) and hand them to a Token Broker for distribution. These steps are illustrated in the second and third blocks of the right column of Figure  4 , respectively.
B. ARCHITECTURE DESCRIPTION The advanced architecture, illustrated in Figure  5 , answers the five requirements discussed hereabove and ensures the seamless processing of data between on and off chain technological bricks. Specifically: We will elaborate on each one of these elements in the following sections. The operating workflow of the architecture is performed in two steps: • • The initial setup of the database and blockchain Smart Contracts is accomplished by a qualified blockchain expert. • Once setup, an unqualified operator can use the architecture, only ever needing to interact with the App. The process starts with visual content being fed to the App and fingerprinted. The generated fingerprints are then checked for near copies in the off chain database. This copy detection process, illustrated in Figure  6 , can lead to three results: • The input is detected as a copy of existing content (i.
e. , the fingerprint is identical to an entry of the database), the operator is informed as such and the process stops. • The input is detected as a near copy of one of the entries according to the designating threshold (cf. Section 4). The operator is informed as such and the process stops. • The content is not detected as a copy or near-copy of any existing entry. The content can be added to the database. If the input is considered original in semantic terms (according to the matching criterion of the fingerprinting method), it can be initialized on the blockchain, specifically in the Smart Contract's storage. This storage serves as a pseudo database that shadows the off chain database. This tamperproof (because on chain), redundant database allows the Smart Contract to serve as an arbiter, ensuring the database has not been tampered with.
Once the App has received the confirmation of this operation, it adds the original input in the off chain database. These operations are illustrated in the complete architecture shown in Figure  5. Upon its arrival into the on chain database, the entry is minted as a Non-Fungible Token according to the Token Prototype, optionally protected with complementary solutions, and sent to a Token Broker. This token could also be sent to a designated wallet as per the use case. As mentioned, the database only holds the fingerprints of the recorded content. Although it would be possible to hold the content itself in the database and fingerprint it upon retrieval, a lighter database which does not hold any content directly allows for faster processing and less potential privacy concerns. The database is only required to pass given fingerprints to the App on request.
The Smart Contract is used on two occasions: to provide information to the App during the greenlight function to cross-check the database entries (explained in the next two paragraphs) and to process a new entry that is admissible in the database. The former does not require input data whilst the latter requires a hash and an optional string of general information which is recorded with the entry, which are mapped to a Boolean indicating their existence. The App interacts with both databases and it is also the only point of contact for the operator. As such, the visual interface can be designed to make the process intuitive and easy to be operated. In the context of an academic study, we did not develop any graphical interface and interacted with the App using a command prompt. The App is given a multimedia file (whose format is dictated by the fingerprint in context) and an optional threshold (that defaults to a recorded value) as input parameters and begins by establishing a connection with the Smart Contract.
The greenlight function is immediately called, prior to any operation. This function returns True, allowing the process to continue, if and only if the off chain and on chain databases match. It does so by retrieving the size of the map of hashes and using compare function of the Smart Contract. As such, the App ensures each entry of the database appears on chain and that no other entries do. This process is expedited by the fact that the database contains fingerprints that need not be reprocessed systematically. This process is shown in Figure  7. The greenlight function returning False immediately interrupts the process and informs the operator that the databases have been tampered with. Assuming this important control passed, the App calculates the input file's fingerprint and compares it to all the entries in the off chain database.
Because of the previous greenlight check, this processing can be performed completely off chain, which enables the computational efficiency of this workflow. As explained in Section III. B, three results can be given to the operator: copy, near copy, or no copy. In the latter case, the operator may prompt the App to add the input to the database. If this is done, the App transactions the Smart Contract via the deployer wallet to add the hash of the new fingerprint to the Smart Contract and the off chain database. Note that the fingerprint is hashed before being stored in the Smart Contract because of format and storage concerns in blockchain environments (e. g. , matrices are not supported). If the fingerprint in context happens to output short identifiers (e. g. , the International Standard Content Code  [92]  considers four different 72-bit strings) the hashing step may be skipped as it is not essential to the proper functioning of the code, although it adds a layer of privacy to the information.
These successive states are illustrated through a sequence diagram in Figure  8. In this paper, we also introduce the possibility of simultaneously accommodating multiple databases and tokens. Indeed, use cases might require the categorization of content according to format, origin, etc. Given the lightweight approach of the databases, a single database can support multiple types of inputs on the simple condition that it can filter out specific sets to send to the App. This concern is rendered quasi trivial by modern data storage technologies. A single Token Contract can be used if an appropriate mixed standard exists (e. g. , ERC1155  [68] ). The only required adaptations for the App and Smart Contract are separate variables representing the distinct databases. The flexibility of the architecture enables its scalability: it can be expanded to a wide realm of use cases whilst only being minimally impacted in terms of computational requirements and hence gas cost.
Token management (Token Prototype, Token Contract, Token protection Module, Token Broker) We now present the various complementary aspects related to the token lifecycle: creation, definition, protection, and distribution. During the initial setup, a Token Contract is deployed on the blockchain. This Token Contract follows a standard as explained in Section II (e. g. , ERC721). Note that the Token Contracts need not be deployed on the same blockchain the Smart Contract is deployed on. The tokens can be minted by multiple standards on any (or multiple) blockchain(s). Once deployed across blockchains, the Token Contracts can be called individually to create blockchain-specific assets on demand or simultaneously to create equivalent assets on different blockchains. The presence or absence of advanced features of the standards in the Token Contracts is imposed by the specifics of a given use case.
The only hard requirement is the presence of a mint function, which will be called by the App to generate tokens. This function is called once the transaction that adds a new entry to the Smart Contract is executed and confirmed. To uniformly identify the assets we create, we use a systematic way to generate them. To do so, we take inspiration from code Prototyping  [94] , a form of instancebased programming that establishes the reuse of existing objects, sometimes across different platforms of programming languages. Prototypes are dictionaries of variables and functions that enable to translate code from an environment to another in a systematic fashion. For instance,  [95]  uses a prototype to generate Smart Contracts from MPEG-21 standard CEL/MCO IPR specifications  [96]. Figure  9  illustrates a basic example of prototyping by standardizing all but one characteristics of a set of houses.
In our case, we do not need complex indexing functions, but the simple formatting of input variables to be passed to various Token Contract constructors. This way, the traces of the near-duplication detection are ensured to be uniform across assets and platforms. The design of the creation process of the assets and of the architecture is also adaptable to the simultaneous use of multiple token standards. In fact, the only added cost in this expansion comes in the initial deployment of Token Contracts. In use, the App will only call the relevant Token Contract(s) upon the addition of a new entry to the database. The gas cost of the initial deployment evolves linearly with regards to the number of Token Contracts to deploy. Unfortunately, no state-of-the-art mechanism can curb these costs at the time of writing.
IV. Implementation details In this section, we focus on the technical details of the methodological bricks of the architecture. Whilst some are standard and can be used throughout the interfaces provided by their creators, some are not and require a level of detail to understand how and why they were built as such. Hereafter we shall go over both, referring to the standard tools we used and detailing those that are not. More space shall be allotted to methodological bricks who innovate with regards to current day standards and those with a more significant role in the architecture. Specifically, we first go in depth on the Smart Contract and illustrate its functioning through an example developed for the Tezos infrastructure because of the simplicity of the sandbox environment and the visualisation tools provided by Tezos' SmartPy  [99]  (legacy code can be run on  [100] ).
A. THE SMART CONTRACT Before we move on to complete implementations in Section V, we show the basics of the Smart Contract's format and use with Tezos's SmartPy  [99] [100] and a generic test scenario executed in a sandbox environment. The familiar syntax of the language should enable readers unfamiliar with on chain development to understand the role of the Smart Contract. Please note that Tezos development is based on meta-programming: as such, the code we write is not a Smart Contract but serves to construct the actual Smart Contract that will run on the blockchain [101]. The settings used in this section are summarized in Table  I. The Smart Contract implements five functions. Three of these functions are of get type and allow to communicate information about the on chain storage to the App.
They return the size of the map, the information associated with a hash, and the Boolean associated with a hash, respectively. The latter serves as the comparison function that is called by the App during the greenlight function. The other two functions manage database entries, respectively providing the addition and deletion of entries. The addition function verifies prior inexistence of the entry in the database, maps the new entry, and returns a Boolean upon processing. The deletion function checks for the existence of the entry and adjusts the size of the map if needed before returning a Boolean. Please note that within this proof-of-concept, the burning (or deletion) of the token that was created alongside the inclusion of the entry in the database does not occur. The addition and deletion functions can only be called by the address that deployed the Smart Contract.
If a use case requires multiple addresses to call the Smart Contract, an allowlist can replace the "only deployer" approach. If multiple databases and Token Contracts were required, the Smart Contract would simply bear a new map of entries for each one. The functions would then use an extra input parameter that would specify the map the App wishes to access and modify. Figure  11  shows an implementation of this Smart Contract on SmartPy. As one can notice, the functions are straightforward and lightweight, as required by blockchain development. We voluntarily did not include the constructor of the Smart Contract as to focus on the functions explained hereabove.
C. OFF CHAIN ELEMENTS As explained in Section III, the database simply holds fingerprints where the App can retrieve them. In fact, lightweight implementations can satisfy themselves of local file storage thanks to redundancy and greenlight checks brought by the blockchain and the App, respectively. In fact, we did as such for the implementations in Section V. Although a more complex Token Prototype can be necessary in use cases where multiple blockchains need to host various tokens simultaneously, it remains a simple element in single platform uses. For instance, simple lines of code serving to unify the format of software can be used. In our case, the Token Prototype would be merged into the App in the architecture presented in Figure  3. For instance, using the ERC721 standard, we can pass on the deployer wallet information alongside the fingerprint hash.
This hash is recorded in the URI of the token, which stores its metadata. In Section V, we opted to populate said URI with the hashed fingerprint of the original input. This data could be made more thorough, but its specifics, once again, depend on the use case. If this architecture were used to certify content before it is sold as original, one could imagine additional information being present in the token to ensure the good standing of the content the token represents. Such additional information may relate to the transaction number of the initial admission of the entry in the database, the address of the Smart Contract where the fingerprint is recorded, the threshold used during the authentication process, or the electronic signature of the issuing body operating the database. Providing a unique, one-size-fits-all solution for any of the flexible bricks would simply hamper the wide spectrum of potential applications of this workflow.
Finally, we decided to build the App using Python and the web3py [107] library to interact with the blockchain. Any programming language able to interact with databases and blockchains can be used to a similar avail. The complete App we used is available at [109] and was only modified to accommodate various fingerprints tailored to the various use cases. For testing purposes, we allowed the near-copy threshold to be set during initialization, but it would remain fixed for complete implementations.
• We begin by giving an exact copy of one of the original room visits as an input. This file in already stored as is, and our comparison is insensitive to metadata. As expected, a correlation of 1 is found with one of the entries, and the process is rightfully interrupted. • Then, we feed the App a sequence of images completely unrelated to any one of the entries. The App does not find any of the semantic content in the database in the input and indicates as such to the operator which can decide whether to add this input to the database. If they do, the Smart Contract is called, the database is updated, and an NFT is minted, as explained in Section III. The outputs of the App for both instances are shown in Figure  14. In the second image, the operator has prompted the addition of the input in the database, leading to the transactions, of which we show an exploration in the bottom images.
After these transactions, if one were to offer the latter file as input once more, the App would answer as in the first image as this input would be recorded as is in the database. • Finally, in an effort to illustrate the ambiguous, nearcopy case, we offer a cropped, increased luminosity version of Room 1 to the App. Figure  15  shows the before and after alteration of a sample image of the sequence, as well as the App's response to the input. As dictated by the fingerprinting method's performances, the App computes a 0. 78 correlation between the input and one of the entries in the database (the original entry for Room1). This value (quite comfortably) passing the decided threshold, the input is detected as a near copy. This supports the efficiency of the fingerprinting method, which provides strong detection to the semantic content.
The App verifies the unicity of the fingerprint in the Smart Contract storage and informs the operator that the entry is a near-copy of a recorded entry. As such, it is not added to the according to the rules of the use case. If we had decided on a stricter threshold of 0. 8, this input would have been considered new and could have been added to the database. Yet, a museum finding both images of Figure  15  in their records would be surprised, as both show the same painting in the same circumstances. This illustrates the careful consideration that should be applied to threshold selection. If the museum wanted to incorporate new rooms into their virtual visit, they would simply offer a multimedia representation as an input to the workflow, which would confirm its unicity before adding it. Upon addition, the App requests the creation of ERC721 NFTs using the Token Prototype and sends the tokens to the operating wallet of the architecture for extra protection steps to be taken before distribution.