dataesr/scientific-paragraphs-categorization huggingface dataset:
The remaining initiatives could then be grouped as belonging to four fields: general-purpose; clinical; imaging; and "omics", e. g. , genomics, metabolomics, and proteomics. 'Inactive' means that a solution cannot be used anymore. For instance, the associated website or links are expired, the solution was only temporary, or it was a service that has been officially closed. 'Too customizable' refers to solutions that are not data sharing infrastructures by themselves, but rather software or platforms used to build very customizable data sharing solutions through an extensive amount of development. Although they can be interesting to use for an institution, they offer so many possibilities that it is not possible to define a specific use case, specific capacities, or FAIR implementation. Therefore, we considered their inclusion irrelevant, as they could not be compared to the other solutions.
Then a DAC is set up by the BRICS' instance B2SHARE -for institutions  [23, 24]  x x x B2SHARE -repository  [23, 25]  x x x x BBMRI-ERIC  [6, 26]  x x a BRICS  [27, 28]  x x b x x COMPARE Data Hub  [29]  x x x x x CyVerse Data Store  [30, 31]  x x x x x CyVerse instance  [30, 32]  x x x DataFed  [33, 34]  x x x Dataverse  [35] [36] [37]  x x x Dataverse Harvard  [35] [36] [37] [38]  x x x x dbGaP  [39, 40]  x x c x DECIPHER  [41, 42]  x x x x Digital Commons  [43] [44] [45]  x x x Dryad  [46, 47]  x x x e!DAL  [48] [49] [50]  x x EGA  [40, 51]  x x x FAIRDOM SEEK  [52, 53]  x x x FAIRDOMHub  [53, 54]  x x x x figshare -for institutions  [55, 56]  x x x x figshare -repository  [55, 57]  x x x GDC  [58, 59]  x x x x GNPS  [60, 61]  x x x x IDA  [62, 63]  x x x x Mendeley Data Repository  [64, 65]  x x x Menoci  [66, 67]  x x x x x MetaboLights  [68, 69]  x x x NIAID ImmPort  [40, 70]  x x x x NMDR  [71, 72]  x x d x Open Science Framework  [47, 73]  x x x x x OpenNeuro  [74, 75]  x x e x Project Datasphere  [47, 76]  x x x x Vivli  [77, 78]  x x x x XNAT Central  [79, 80]  x x x XNAT for data sharing  [81] [82] [83]  x x x x Zenodo  [44, 45, 47, 84]  x x x.
Zenodo The cell color indicates the level of fulfillment of the associated criterion. 1. FAIR criteria: Red: none of the subcriteria where fulfilled. Orange: less than the majority of subcriteria and subsubcriteria were fulfilled. Yellow: more than the majority of subcriteria and subsubcriteria were fulfilled. Green: all subcriteria were fulfilled. The choice between orange and yellow was discussed between all authors when necessary. 2. Ease of use and implementation: from red to green, a solution is less time consuming and more straightforward 1 3 whereas some did not cite the FAIR principles, but implemented features that, in practice, allow to respect these principles. The FAIR principles contain four main criteria, which can all be subdivided further. To facilitate reading, we gave one grade for each main criteria, based on the number of sub criteria fulfilled.
Findability Findability was almost always satisfied (see Table  2 ). Digital Object Identifier (DOI) implementation is becoming increasingly popular, and most solutions have a search tool allowing to easily browse the data and metadata. A DOI is a very relevant item for Findability, because it references a dataset in a unique manner, while also making it searchable through any web browser. Moreover, all the solutions presented here were selected after verifying that public data were in practice findable by anyone on any web browser, since we excluded 'private' solutions during the selection process (see Fig. 1 ). Some solutions, such as CyVerse Data Store  [31] , DataFed  [33, 34] , IDA  [62, 63] , and XNAT for data sharing  [81] , need an account to be explored but they all have a free and open process.
Reusability Reusability was satisfied most of the time (see Table  2 ). Many solutions implement popular metadata standards such as Dublin Core or DataCite, enabling metadata to be both rich and adapted. However, the main drawback of these general metadata standards is that most solutions only require a few fields to be filled, leading to datasets described with minimal information: title, author, contact, and a small description. XNAT Central is a good illustration of this situation, since it is an open, non-curated repository. It contains non-standardized and poorly described datasets, which prevents data from being Reusable. Some solutions like EGA, GDC, and Dryad, however, implement a review process upon data submission, to ensure compliance with standards.
Examples In this section, we present in more details two solutions that illustrate the previously identified categories: Vivli for the online platforms, which are implemented as a single instance and Dataverse for the software instances, which are distributed across institutions (see Section 3. 1). These solutions were chosen because they present enough differences to be representative of the landscape of available solutions. They also provide a large amount of relevant up-to-date documentation and are well-implemented in their respective communities.
Dataverse Dataverse is an open-source web application to share, preserve, cite, and explore research data  [36]. The underlying software must be installed and configured by the institution. It then constitutes a Dataverse repository which can host multiple virtual archives called Dataverse collections, which contain datasets, which consists of files and metadata. figshare  [56]  and B2SHARE for institutions  [23, 24]  as well as CyVerse  [30, 32] , Digital Commons  [43] , and XNAT for data sharing  [81]  also provide similar institutional repositories, with variability regarding maintenance, storage, and cost. Researchers of the institution can create 1 3 Dataverse collections to deposit data featured in a project or in a published article. The FAIR principles are explicitly mentioned as the first feature of the software  [85] , and Dataverse is cited as a viable tool for data sharing in the article that introduces the FAIR principles  [11].
Findability The structure of the Dataverse instances systematically guarantees Findability. Dataverse uses DOIs as well as Universal Numeric Fingerprint (UNF) which are globally unique and persistent identifiers (F1: first criterion of the Findability criteria). These identifiers are registered in the metadata, which cannot be separated from the data themselves, as they are bundled together in a single entity called dataset (F3). These datasets are contained in collections and can be searched and accessed through the Dataverse instance (F4). The search tool itself can be easily integrated into an institutional website. It is, however, the choice of the said institution to make the Dataverse instance searchable for everyone or to remain private. Accessibility Like for the search tool, the rest of the Dataverse infrastructure can be integrated in a website.
This allows all interactions (e. g. , data access, submission, requests) to take place in a single interface, and guarantees that the data owner can be contacted. The retrieval of (meta)data from a Dataverse collection or dataset depends on the level of protection the data owner has chosen. If the data are in open access, one can simply download the data in a few clicks. If the access to data is controlled, it is necessary to authenticate oneself (A1. 2) and submit an access request, through the Dataverse interface. The data owner can then choose to allow access, or not, to its data. In every case, this is a free, open and universally implementable protocol (A1. 1). Once again, it is possible for the owner to make the data totally private, or hidden, to all users. It is not mentioned that metadata remain accessible "even when the data are no longer available" (A2).
Interoperability The evaluation of the interoperability was more delicate. As Dataverse is not a specialized software, it does not provide community guidelines, nor curation of data, even though it advises to follow vocabularies and good practices. It is the responsibility of the institution to make sure the uploaded data are interoperable. Nonetheless, Dataverse provides tools that help facing these challenges, such as customizable metadata schemas, and some community schemas and ontologies: Data Documentation Initiative (DDI) for social and health sciences, DATS for life sciences and The Gene Ontology for molecular biology and genetics. Moreover, metadata can contain references to other data (I3), such as a scientific publication, or any website. Reusability Dataverse implements rich metadata schemas, such as Schema.
org, DataCite, and DublinCore. License and terms of use are available in the metadata (R1. 1), and detailed provenance can be provided (R1. 2). Once again, some metadata fields are mandatory, but it is the responsibility of the researcher to fill the additional fields necessary to make its data Reusable. Dataverse provides the infrastructure for it but cannot guarantee it. NB: for software instances, it is always the responsibility of the institution to decide the level of findability and accessibility. This evaluation of the FAIR criteria is solely based on the possibilities offered by the software, not on the practical choices made by the users. However, Dataverse does not explicitly mention the sharing of IPD. Nonetheless, all data are stored on-premises by the managing institution and Dataverse collections can contain metadata alone when the data files are too sensitive to be shared.
This is a way to ensure the Findability of the data while respecting data sharing legislation. Additionally, it is not a specialized repository which means that every file format is accepted. However, only a few can be previewed, e. g. , images, PDF, text, video, tabular data, and other basic formats. To better understand the concrete implementation of Dataverse, one can browse one of the 93 installations  [86]  at time of writing (12 December 2022) or try to use Dataverse Harvard  [38]  for free which is a public instance of the software.
Vivli Vivli  [77, 78]  is an online repository hosting anonymized clinical data. Anyone can search for clinical studies on Vivli. However, access and upload of data are controlled by various protocols and agreements. These protocols are similar to the ones implemented by EGA  [51] , dbGaP  [39] , and GDC  [58, 59]  for individually identifiable data, although to some extent only, since the data on Vivli are systematically anonymized. Moreover, Vivli offers help for the anonymization of datasets before submission, ensuring the sharing of IPD in a secure manner. At time of writing, 12 December 2022, Vivli hosts 6907 studies and 621 data requests have been submitted.
Findability Vivli implements automatic DOI attribution (FAIR criterion F1 ) and open visualization of the studies through a search tool (F4). A study contains data files, metadata, and a description of the aim of the study. It is registered on ClinicalTrials. gov. The DOI is linked to the study, which cannot be separated from the metadata and the actual datafiles (F3). Accessibility The access protocol, although time consuming, is very clear and open (A1. 1). Anyone can submit an access request, after creation of a free account, to allow for authentication (A1. 2). The request is approved or refused by Vivli within 3 business days (A1. 2). Some data can also be public, depending on the choices made by the data contributor. Additionally, metadata are always public and available, even if there are no data files uploaded, although it is not explicitly mentioned what would happen if datafiles were deleted (A2).
Interoperability and reusability Vivli encourages researchers to use rich metadata, dictionaries, and ontologies (e. g. , the Cochrane ontology) (I1, I2, R1. 3). It also reviews all uploaded data, which improves Interoperability and Reusability. When requesting data from a study, it is necessary to sign a Data Use Agreement (DUA), with clear terms of use and license (R1. 1). All studies are richly described, give provenance information (R1. 2), and additional information are available on ClinicalTrials. gov.
4. 2). Dataverse is also an interesting alternative for institutions that would like to retain complete control over their data and have enough customizability and flexibility to adapt to different data types (see Section 3. 4. 1). Institutions and researchers face sharing challenges that call for many important considerations, especially regarding sensitive data, e. g. , the hosting location, the choice of sharing anonymized or raw data, the cost of the solution, and its adaptability. In all likelihood, the best solution will not be perfect in all regards, but it will be the best compromise for all these issues.
Alternative strategies An interesting strategy would be to use a combination of specialized repositories with more general and well implemented platforms. For instance, research data could be uploaded to several specialized repositories (e. g. , Open-Neuro, MetaboLights, and IDA), while metadata are being displayed on a general-purpose platform (e. g. , Dataverse, or figshare) with persistent identifiers linking back to the specialized repositories. The former ensures Interoperability and Reusability, while the latter implements Findability and Accessibility. Some potentially relevant solutions that were excluded from the analysis due to their lack of data hosting functionalities, could also be used to build a FAIR data infrastructure. Such a solution is ClinicalTrials. gov  [87]. It is a central resource in health science (with more than 400,000 registered research studies), provided by the U.
Conclusion In the vast and complex landscape of health science data sharing, with a significant and moving regulatory requirements, it is important to understand and characterize stakeholders' requirements and needs before investing time and efforts in one or several solutions. In this study, we compared 35 solutions regarding their implementation of the FAIR principles, their ease of use and implementation, and we richly described their functionality. Vivli and Dataverse were identified as the two most all-round solutions for sharing health science data in a FAIR way. Even though the FAIR principles are being increasingly implemented, this article shows that a lot of work still needs to be done to reach standards and formats that would make health science research data FAIR. Fostering data sharing practices, for instance by showing to researchers the selfbenefits of sharing, is also necessary in order to improve the uptake on FAIR solutions and develop reliable, wellimplemented communities.
We argue that the soundness arguments for our new rules are no more complex than the former lifting-based arguments, and less error-prone. iii) A more pleasant framework for proofs. The generalisation of our logic to a higher-order language, and the generic recursive definition mechanism, provide a convenient language for the user to structure proofs in an abstract and modular way. As a second, distinct contribution, we extended SQUIRREL to make it consistent with our higher-order semantics, and to implement our new proof rules. We use this implementation to verify that all past case studies carried in the former meta-logic can be adapted to our new system, without any significant burden on the user. We also showcase the added expressivity on new case studies. First, taking advantage of the usual benefits of a higherorder language, we show that generic cryptographic reasoning techniques can be expressed in our system, in the form of a hybrid proof argument.
In EasyCrypt, protocols are encoded as programs -i. e. modules and functors, whose parameters encode oracles. Security properties are written as relational properties over pairs of programs. Contrary to SQUIRREL, probabilistic reasoning is exposed to the user. This framework is very precise and expressive, but that comes at a cost: writing EasyCrypt proofs tends to be long and arduous. One reason is that, to instantiate a lemma, the user must often manually define the programs it is being applied to. The hybrid argument formalisation in EasyCrypt is ∼650 lines, contains ∼15 different modules, and applying it usually requires to write additional modules -which is markedly more work than in SQUIRREL. Although comparing the same developments in different tool is a hazardous task, we believe this illustrates the fact that our new logic provides an appealing trade-off between expressivity and usability.
Timing: Can vary from 1 h to overnight Acquired images need to be translated into datasets that allow quantitative analysis of measured parameters. For this, automatic high-content image analysis is performed. Here, Perkin Elmer's High-Content Imaging and Analysis software Harmonyâ is used. A script is written from pre-programmed blocks that are available in the software. Alternatively, other similar software such as CellProfiler (open-access) can also be used. The most important point for the precise analysis of the parameters measured is the segmentation of cellular and subcellular parameters. For this purpose, the fluorescent signal of the staining is used. An example of the analysis building blocks is depicted in Figure  4  and associated images are shown in Figure  5. Analysis workflow: 18.
ACKNOWLEDGMENTS We acknowledge C. B. 's lab members for fruitful discussions. We thank  N Aulner ,  A Danckaert , and the  Photonic BioImaging (PBI) UTechS at Institut Pasteur  for support. This research was funded by the  Institut Pasteur ,  DARRI-Institut Carnot-Microbe et sante  ´(grant number  INNOV-SP10-19 ) to P. E. ; the  Agence National de Recherche  (grant number  ANR-10-LABX-62-IBEID  to C. B. and  ANR-21-CE15-0038-01  to P. E. ), the  Fondation de la RechercheMedicale (FRM)  (grant number  EQU201903007847 ) to C. B. , and the  Region Ile-de-France  (program DIM1Health) to PBI (part of  FranceBioImaging ,  ANR-10-INSB-04-01 ). M. D. was supported by the  Ecole Doctorale FIRE -'Programme Bettencourt. 'Figures were created using BioRender.
INTRODUCTION Property graphs have come of age. The property graph data model is widely used in social and transportation networks, biological networks, finance, cyber security, logistics, and planning domains to represent interconnected multi-labeled data enhanced with properties given by key/value pairs  [47]. Its maturity is reflected in the ongoing efforts by ISO (International Organization for Standardization) 1 to create a standard Graph Query Language GQL, which is expected to appear in 2024  [1, 17]. Despite the maturity of commercial and open-source property graph databases, their schema support is limited. Schemas are a fundamental building block for many data systems. They provide structure to data in a formal language, and are used in different scenarios. In the schema-first scenario, dominating in production settings of stable systems, the schema is provided during the setup and plays a prescriptive role, limiting data modifications.
In the flexible schema scenario, suitable for rapid application development and data integration, schema information comes together with data and plays a descriptive role, telling users and systems what to expect in the data. In the partial schema scenario, applicable at advanced development stages, the user wants to enforce a prescriptive schema over stable parts of the data and maintain a descriptive schema depicting the whole data including its evolving parts. A recent survey of graph processing users  [45]  revealed that schema compliance is a highly desirable feature that is lacking in property graph database systems. Our inspection of eleven property graph engines reveals a fragmented landscape, where no system offers comprehensive support for schemas, which should allow the user to impose structure on nodes, edges, and properties of the underlying graph instances, as well as enforce constraints.
This calls for a unified property graph schema language. Our goal is to support the endeavours surrounding the GQL standard and accelerate the development of a future standardized property graph schema language by presenting a concrete proposal. Our proposal, called PG-Schema, consolidates and extends discussions arising out of the Property Graph Schema Working Group of the Linked Data Benchmark Council  [25]. This model 1  of providing recommendations to standards committees has proven successful, as evidenced by G-CORE  [4]  and PG-Keys  [5]  influencing GQL  2. To illustrate the key features required of schemas for property graphs, we now provide a concrete example of a schema in fraud detection, a common application of graph databases  [22] , and show how the schema can be used in interactive graph exploration, which in itself is a common functionality provided by graph databases  [23, 24, 38, 39, 48].
Andrea proceeds with Customer. (3) Based on the schema information, the graph explorer dynamically constructs a Customer search form. It contains separate search fields for the known properties of Customer nodes: in our example id and name (inherited from Person). Based on the data type constraints in the schema, the id field accepts only integers as input. Andrea uses the name field to search for customers of interest and obtains a visual representation of the customer nodes in response. (4) To inspect potential fraudulent behavior, Andrea needs to understand the connections between customers. Exploiting the schema, the graph explorer leverages the edge type constraints to enumerate and propose specific types of connections. For instance, knowing that Customers use CreditCards and Transactions charge CreditCards, it identifies structural connection patterns, written here in Cypher/GQL style, (5) Andrea selects the first pattern, which aims to identify shared credit cards that were used by two customers.
Based on the schema knowledge, the application constructs and executes an efficient query that quickly identifies all shared credit cards usages between customers. (6)  The graph explorer visualizes the results of the connection search. Upon further investigation, Andrea confirms suspicious cross-customer usage of the same credit card and classifies the cases as fraudulent behavior. As illustrated by this sample session, the graph explorer would not have been able to effectively guide Andrea through the exploration without concrete schema information. The suggestion of property-specific search restrictions is made possible by content types. The schema-assisted query formulation leverages node and edge types. Going beyond our example, it is easy to see how other type and constraint information may help: for instance, key constraints could indicate preferred search fields; more general participation constraints may improve the schema-assisted query formulation process; orthogonal tooling for schema generation might give graph explorers a standardized path to approximate schema information in case it has not been provided by the graph database authors.
No existing graph database system nor currently envisioned standard covers this arsenal of features; nor do they provide full schema validation support. Our PG-Schema proposal provides both existing systems (reviewed in Section 5) and forthcoming standards with these features, responding to users' demands. We give a detailed description of PG-Schema in Section 4. As a sample, consider the graph type definition in Figure  2 , representing part of the schema diagram of Figure  1. The graph type fraudGraphType specifies node types (e. g. , personType, customerType), and edge types (e. g. , activityType) using the ASCII-art notation of Cypher  [21] , also adopted by GQL. Properties are declared in curly braces {. }. For example, the first statement defines a node type personType with label Person and a property with key name of type STRING; and the last statement defines an edge type activityType, whose label is either deposits or withdraws, which connects nodes of types transactionType and accountType.