dataesr/scientific-paragraphs-categorization huggingface dataset:
Aiming to a more decentralized design, we integrated blockchain with IPFS (Inter-Planetary File System), a peer-to-peer version-controlled protocol and filesystem, run by multiple nodes, storing files submitted to it  [35]. It combines distributed Hash Tables, Block Exchanges, and Merkle Trees. Using middleware, users are able to upload content to IPFS and place its unique hash code (address of the file) to the smart contracts running on Quorum blockchain. If we use a central database for storage, we benefit from the high throughput but this centralization does not coincide with the decentralized nature which blockchain advocates can lead to a Single Point of Failure (SPOF) of the whole application. Facing the aforementioned drawback, IPFS being a peer-to-peer (p2p) file sharing system and blockchain's complementary component, settled exceptionally the SPOF problem, furnishing low latency and data distribution.
Offchain Data Storage Interacting with IPFS The integration of IPFS as a distributed off-chain data storage for blockchain solutions has already been applied in several works. In the field of healthcare, Kumar et al. [16]  propose the use of the IPFS as a means to preserve the security of sensitive data, by avoiding the use of a single centralized database that stores the entire information. Ali et al. [33]  combined blockchain with the IPFS to develop a decentralized effortlessly privacy-preserving IoT-data storage solution. Additionally, Zou et al. [34]  propose a blockchain-based incentive anonymous reporting system that uses IPFS as an off-chain storage solution to achieve security, high-throughput, high-capacity storage, and high concurrent access, while at the same time preserving user anonymity.
Implementation and Integration Details 4. 2. 1. Blockchain Framework After deployment to the blockchain, smart contracts' code is final and cannot be modified. Thus, it is of vital important to trace any bugs during the design and implementation process and through many iterations and testing end up to final smart contracts which will be deployed to the blockchain and cannot be altered. The different smart contracts are written in the programming language Solidity (http://solidity. readthedocs. io, accessed on 2 September 2021), so it is feasible to migrate from Quorum permissioned blockchain framework to public blockchain frameworks (e. g. , Public Ethereum Network), since Solidity is the common programming language to Ethereum-based blockchain frameworks. We employed and experimented with different blockchain technologies and implementations featuring main differences, for example in access rights and permissions, before concluding to the use of the Alastria blockchain platform.
trufflesuite. com/, accessed on 2 September 2021). It is a development environment and testing framework using the Ethereum Virtual Machine (EVM). Before we deploy the smart contracts to the blockchain network, we extensively tested them on the private blockchain previously presented. Additionally, before being deployed on a larger Quorum Network, we used a Quorum test network consisting of seven nodes (https://github. com/jpmorganchase/quorum-examples/ tree/master/examples/7nodes, accessed on 2 September 2021). 4. ALASTRIA: It is a public-permissioned network, sharing some of the properties of both types of networks public-permissionless and a private consortium, while trying to overcome scalability problems of traditional blockchain platforms related to their consensus mechanisms. There are a lot of efforts being made to solve or alleviate blockchain's scalability problem, but as of today, the problem still exists and permissioned networks demonstrate significant better performance than publicpermissionless.
On the other hand, the high transaction cost in public blockchains such as Bitcoin and blockchain and the fact that all nodes store every transaction and smart contract constitute a restriction for certain types of applications. Alastria (https://github. com/alastria/alastria-platform/blob/master/en/Alastria-Core-Technical-Platform. md#alastria-core-technical-platform, accessed on 2 September 2021) is a Public-Permissioned network compatible with regulation, while implementations are based on Quorum. Each participant node has to be identified before it can participate in the network, while there is no cryptocurrency embedded as in the case of Bitcoin or Ethereum.
M-Sec Token A custom token was created specifically for research purposes. It is actually a cryptocurrency in the form of a smart contract running on Quorum blockchain. It follows the ERC223 (https://github. com/ethereum/EIPs/issues/223, accessed on 2 September 2021) token standard. Preliminary implementations followed the ERC20 token standard, but ERC223 is a superset of the previous standard offering security improvements and more usability and backwards compatibility with any services and functionalities designed and developed for ERC20. As fully compliant with ERC223, it implements a set of functions and events, such as name(), transfer(), totalSupply() and Transfer event, which is emitted to the blockchain when an amount of Tokens is transferred from a user to another. This Token has different applications for the end-users of the Blockchain Marketplace.
If the user has sufficient funds and the information is correct, then the transaction will be successfully completed. Upon success, the event Transfer is emitted to the network informing the users who watch the smart contracts that this transaction took place. Regarding the sensor type, the possible values are described in Table  1  that follows. This smart contract constitutes an extension of the Sensor Smart Contract oriented to better handle datasets provided by smart cities. Among others, this smart contract was used to integrate the data and datasets from Santander Open Data Platform (www. datos. santander. es, accessed on 2 September 2021). Different datasets are provided about transport, urban planning and infrastructure, culture and leisure, environment, science and technology, society, well-being, and more.
The bridge system implements a flow, transmitting data from SOXFire to the Blockchain Marketplace. The data format used is shown in the following Table  2. In addition, having SOXFire managing and handling all topics could require big computation cost as well as fast and reliable connection. In addition, there is a possibility that the server becomes at some random point temporarily unavailable for technical reasons. In this case, the Blockchain Marketplace would attempt to communicate with SOXFire servers, but would have experienced unexpected latency or in the worst case would be temporarily impossible. To this direction, the bridge system is able to act as a Proxy and manage some of the connections with SOXFire servers. And, all of the data can be fetched to the local storage, using a combination of traditional databases and IPFS.
So, in the end, the Blockchain Marketplace will be able to retrieve all the requested data and serve them to the end users. Additionally, the bridge system has a searching function optimized for SOXFire. If a client has the meta-information of a topic, he is able to subscribe to the topic once. This means the clients would have to execute programming commands to retrieve the desired meta-information from SOXFire. Instead, the bridge system executes these commands, by using dedicated HTTP requests, and returns the parsed result to the client program. Moreover, the bridge system can search and subscribe by prefix matching. When clients want to receive data from the SOXFire server, they subscribe by providing the topic name. This command is the same as in the case of the bridge system. However, if a client wants to subscribe to some topics, the client has to repeat this operation.
Integrating Identity Management with Blockchain Marketplace The Security Manager tool provides an extra layer of safety in the authentication process of the application, while at the same time ensuring controllable user anonymity within the app. It operates as a standalone service that retains all the sensitive data that each user provides upon registration and connects them with the anonymous identity keys that define each user within the Marketplace. This tool is responsible for the processes of user registration, authentication, and management. The Security Manager can therefore be presented as a lightweight, yet secure, alternative to a Know Your Customer (KYC) authentication service  [15] , since it acts as a validator of a user's identity and as a bridge between the user's real identity that contains sensitive-data and the public and private keys constitute a user's identity within the Marketplace.
Upon authentication, the Security Manager service exposes only the public and the private key of the authenticated user to the Marketplace application, therefore preserving the sensitive-user data and allowing for anonymous, yet validated, browsing of the users within the app and transactions within the blockchain network. At the same time, it is important to stress that the existence of two distinct environments, the one of the Security Manager and the other of the Marketplace, with two distinct types of data storage, traditional databases for the Security Manager and immutable distributed storage solutions for the Marketplace, protect the rights of each user to their personal data, including this of the erasure of data that contradicts with the nature of blockchain. The Security Manager tool is integrated with the Marketplace by using OAuth 2.
0, OpenID and Keycloak. OAuth 2. 0 is an authorization framework that lets an authenticated user grant access to third parties via tokens. A token is usually limited to some scopes with a limited lifetime. Therefore, it is a safe alternative to the user's credentials. OpenID Connect (OIDC) is built on top of OAuth 2. 0 to add an identity management layer to the protocol. Hence, it allows clients to verify the end user's identity and access basic profile information via a standard OAuth 2. 0 flow. Finally, Keycloak is used within the Marketplace app to bridge it with the Security Manager tool since it can federate existing external user databases. Keycloak supports LDAP and Active Directory, as user storage providers. When a user logs in, Keycloak will look into its internal user store to find the user.
The mounted wavefront and laser damage threshold of the high-power BT mirrors and their effect on focus quality The single-pass peak-to-valley (PV) reflected wavefront error (RWE) of the 440 mm × 290 mm × 75 mm dielectrically coated AOI = 45 • transport mirrors was specified to be less than 95 nm (0. 117 waves @ 810 nm)  for 90% of the full aperture, which is 396 mm × 261 mm. Given the 210 mm × 210 mm super-Gaussian rectangular beam size of HAPLS (1/1000 of the maximum intensity points), this leaves plenty of margin for mounting, alignment and potential increased coating stress issues. Power and astigmatism of the RWE may be compensated by an adequate alignment of the focusing parabola in the target chamber. From the measured surface deformations we calculated with the Zygo AMETEK MetroPro software the RWE at use angle and subtracted power and astigmatism.
To assess whether the 10 times higher LDT shown in Figure  17  is a sufficiently high margin to avoid catastrophic damage of the BT and focusing optics when building a non-relay imaged BT system, we have developed in close cooperation with LightTrans International in Jena, Germany, a Virtu-alLab Fusion  [35, 36]  model to calculate the full-bandwidth diffraction propagation of HAPLS to each experimental hall. Because a solid understanding and potential control of the phase-to-amplitude modulations is of vital importance for a below optical damage threshold operation of the BT system, we have benchmarked this code against the physical optics propagation of Zemax OpticStudio and against an in-house developed Efficient Matrix Approach (EMA)-based code, as described by Shakir et al. [37]. While VirtualLab Fusion may model the full-bandwidth diffraction propagation and has the capability to also include spatiotemporal coupling, Zemax and our in-house code may currently only propagate a monochromatic beam.
Consequently, a so-called K photon is generated  [42, 43]. The easiest transition to detect is the Kα emission line, meaning that the electron goes from the L-shell to the K-shell. In the context of the BT commissioning, two X-ray diagnostics were set up in the P3 interaction chamber. First, an imaging crystal was installed to monitor the generation of Kα lines on a copper target. With this setup, the X-ray emission area is resolved in two dimensions along the target surface with 8 µm spatial resolution. The recorded data provides information on the laser energy deposition inside the target. Owing to the good collection efficiency of the X-ray imager, this diagnostic allows the collection of single-shot data even at low laser energies. Figure  44  shows a typical X-ray Cu Kα image recorded in a single laser shot at 110 mJ.
Acknowledgements The authors acknowledge support from the project  Advanced Research Using High-Intensity Laser-Produced Photons  and  Particles (ADONIS)  ( CZ. 02. 1. 01/0. 0/0. 0/16_019/0000789 ) and by the project  High Field Initiative (HiFI)  ( CZ. 02. 1. 01/0. 0/0. 0/15_003/0000449 ),both from  European Regional Development Fund. The authors are very grateful for the help and dedicated support from the entire  ELI-Beamlines  staff. In particular, we are grateful to the following teams who contributed substantially to the commissioning: Department of  Laser Systems  ( J. Cupal ,  L. Koubíková ,  D. Kramer ,  J. Naylon , B. Rus),  Department of Technology Infrastructure and Instrumentation Services (P. Bakule, B. Plötzeneder) , the safety team (V. Olšovcová),  Department of Construction and Design Support  ( M.
Eligibility of the investigational centres and NGS platform A first pre-selection was carried out and targeted the investigator centres that were the reference centres of the NET-SARC network, located in metropolitan France and geographically covering the territory. The centres were subsequently selected on the basis of a feasibility survey (e. g. Availability of a technical platform for the preparation and dispatch of samples, human and logistics resources; Recruitment capacity …) and previous experience gained (e. g. Data entry deadlines, data quality …). The biopathological platform (Institut Bergonié, Bordeaux) is labelled by the French National Cancer Institute (INCa), and ensures the qualification of samples, the extraction of nucleic acids and their quantification, and the shipping of nucleic acids to the Centre National de Recherche en Génétique Humaine (CNRGH-CEA), which is in charge of performing the sequencing.
Cost-effectiveness A micro-costing study will be conducted, in collaboration with the national network Inserm-RECaP of Research in Clinical Epidemiology and in Public Health, to estimate the real cost of NGS. Micro-costing studies collect detailed data on resources utilized (consumables, technician time, devices …) and the value of those resources. The French National Health Insurance reimburses the vast majority of other resources involved in the care of participants in this trial. These costs will be extracted from the French National Health Insurance data. To do so, with the authorization of participants, we will gather their unique Health Insurance identification number. This number will enable us to merge the MULTISARC data with the National Health Insurance data of each included participant.
Data management Study data will be entered by the investigator or delegate using the electronic case report form developed via Ennov Clinical (version ≥7) software by the Data Manager of the study. Ennov Clinical software has been developed to meet the regulatory requirements. The Ennov Clinical software complies with the FDA requirements regarding IT systems used in clinical trial ("Guidance for Computerized systems Used in Clinical Trials") as well as electronic signature ("21CFR part 11") and various international norms. The Ennov company ensures the storage and maintenance of the database.
Sequencing DATA Sequencing data will be uploaded by the Centre National de Recherche en Génétique Humaine (CNRGH) on a secured server (CEA-TGCC, Bruyères Le Chätel), for quality control analysis and temporary storage. The bioinformatics unit located at Institut Bergonié will then electronically transfer the sequencing data via Secure FTP in order to analyze them on their computing cluster (HTC server). The biological and clinical interpretation report (MTB report) will be produced through GenVarXplorer software (GVX). A pseudonymised. pdf copy of the biological report and of the MTB report will be electronically and securely transmitted via the case report form (CRF) to the investigation centres. The sequencing data will be stored temporarily on the Institut Bergonié's Data server (data replicated in 2 IT rooms for safety reasons).
Consent The consent of participants is obtained by signing an informed consent form. This paper form is given to the participant by the investigating physician during the consultation to present the MULTISARC trial. The signature takes place after oral information by the investigator, combined with the reading of the information notice detailing the study, and in particular the processing of personal data. A system of checkboxes allows participants to clearly understand the scope of the agreement they give for the processing of their data and for the secondary use of data and samples. Participants included in the MULTISARC trial, randomized in Arm NGS and for which NGS molecular profile has shown at least one genomic alteration that can be targeted by a therapy available in one of the MULTISARC sub-trials, will be invited to participate in this sub-trial.
Acknowledgments The authors would like to thank the pharmaceutical companies  Novartis ,  Astra Zeneca ,  Pfizer  and  Taiho Oncology  for their collaboration and the supply of the molecules, as well as the various committees that contributed to the progress of the program. We would also like to thank all those who have been involved:  Vincent Berger ,  Christine Betard ,  Vincent Biscaras ,  Helene Blons ,  Emmanuelle Chollet ,  Fatoumata Collombet ,  Isabelle Dages ,  Nicolas Degand ,  Claudia Detoma ,  Anne-Claire Du Cleuziou ,  Flore Geillon ,  Carine Gionnet ,  Jean-Christophe Hébert ,  Christine Lagorce ,  Isabelle Laudier ,  Francois Le Loarer ,  Frédérique Lesaulnier ,  Laure Masson ,  Patricia Rigoux ,  Richard Salives. INSERM ,  Unité ACTION U1218, Bordeaux, France. 2 University of Bordeaux, Inserm, Bordeaux Population Health Research Center, UMR 1219 ,  CIC-EC 1401/EUCLID Clinical Trials Platform, Bordeaux, France.
The number of submissions to diagnostic databases of pathogenic variants, such as ClinVar  17  , has become a good surrogate for the prevalence of rare disorders. When submissions to ClinVar of disease genes with pathogenic mutations are plotted in decreasing order, most of the supported syndromes are on the left, indicating relatively high prevalence (Figure  1 ). For instance, Cornelia de Lange syndrome (CdLS), which has been modeled by multiple tools  5, 12  , is caused by mutations in NIPBL, SMC1A, or HDAC8, as well as other genes, and has been linked to hundreds of reported mutations. However, more than half of the genes in ClinVar have fewer than ten submissions each (Figure  1 ). As a result, most phenotypes have not been modeled because sufficient data are lacking. Thus, the need to train on large numbers of photographs is a major limitation for the identification of ultra-rare syndromes.
Results The feature encoder of GestaltMatcher computes a Facial Phenotypic Descriptor (FPD) for each portrait image (Figure  2a ). Each FPD can be thought of as one coordinate in the CFPS (Figure  2b ). The distances between the FPDs in the CFPS form the basis for syndrome classification, delineation of novel phenotypes, and patient clustering. The performance for all three of these use cases depends on the composition of the training set and the gallery. All benchmarking results described in this section, as well as those available through the web service, are based on data from Face2Gene (F2G). The F2G dataset was used to construct a CFPS consisting of 26,065 images from 17,502 subjects who had been diagnosed with a total of 1,115 different syndromes, each supported by at least two cases.
We divided the dataset into two categories, the rare dataset consisting of 816 ultra-rare and novel syndromes, representing syndromes that we aim to identify, and the frequent set, consisting of 299 syndromes already identified by DeepGestalt. The latter set of known syndromes was also used to train the encoder. Each category was further split into a gallery (90% of each syndrome) and a test set (the remaining 10% of each syndrome) (see the Online methods for details). Since F2G data cannot be shared, we compiled the GestaltMatcher database (GMDB), consisting of 4,306 images from 3,693 subjects with 257 different syndromes. This second data set is based on 902 publications, and further cases for which we obtained consent for sharing. All findings described in this section that are based on the F2G data can be reproduced qualitatively on the GMDB data and are listed in the Supplemental Material.
The same trend of improvement by fine-tuning on a diverse but smaller set of syndromic photos is also seen on the public GMDB dataset (Enc-GMDB vs Enc-F2G in Supplementary Table  1 ). These results suggest that an encoder that is fine-tuned on as many syndromic faces as possible, such as DeepGestalt, is a better fit for the task of syndrome classification than one trained only on healthy faces. Moreover, DeepGestalt's FPD provides a better generalization or clustering than the FPD encoded by CASIA for rare syndromes that it had not previously seen.
Syndromic diversity improves the performance on novel disorders Earlier definitions of the FPD were mainly based on training a network with a small selection of common and highly characteristic syndromes  5, 9. In principle, we could train GestaltMatcher's encoder on all 1,115 different syndromes in our dataset. However, most of the facial phenotypes that have recently been linked to a gene are either ultrarare or less distinctive, and using a very unbalanced training set with many ultra-rare disorders linked to only few cases may add noise without substantial additional benefit. We therefore analyzed the influence of the number of syndromes on the encoder's fine-tuning by incrementally increasing their number starting with the most frequent ones. Due to the imbalance among the disorders added each time, the improvement could be affected by the additional number of training subjects.
Therefore, we used the same number of subjects for each syndrome. In this section, the test set consists only of disorders from the rare set that the encoder has not seen. The training procedure and averaging of the readout is described in detail in the Online methods. When we increase the number of training syndromes, the accuracy increases (Figure  3 ). In general, the performance is also higher when more individuals per syndrome are used for training. Particularly when more than 50 syndromes are used, the curve for training with 20 subjects/syndrome is above the curve for 10 subjects/syndrome, and so on. The same trend is also shown in the public GMDB dataset (Supplementary Figures  2  and 3 ). Moreover, double the number of syndromes is better than double the number of subjects in most of the combinations (Supplementary Figure  4 ).