dataesr/scientific-paragraphs-categorization huggingface dataset:
The W3C-PROV standard for provenance There already exists a standard model for capturing and reporting on provenance chains, called W3C-PROV  [9]  (hereafter referred to as PROV). The standard defines an ontology capable of describing provenance for any given entity and is well suited to describing the provenance of data. The core of the model is composed of 'Entities', 'Agents' and 'Activities', with well-defined edges linking these objects. A key strength of this model, besides its ubiquity and high level of generalisability, is that it supports serialisation in formats that are both machine and human readable. This means that provenance capture and propagation can be automated programmatically, and manual scrutiny is possible using tools provided by the PROV developers. A number of other disciplines and datasets already make use of PROV either directly (e.
g. DBPedia  [10]  and OECD Linked data  [11] ) or using domain specific extensions (e. g. SEIS-PROV for seismology  [12] ). As of 2013, over 60 datasets or frameworks implemented the PROV model. Indeed recently, the F-UJI tool  [13]  developed under the FAIRsFAIR  [14]  project assumes the use of a machine-readable version of PROV (or PAV  [15]  which is just a specialisation of PROV) when assessing a datasets compliance to FAIR principles, and the DARE  [16]  platform provides support for automating the output of PROV formatted provenance. The adoption of this standard in the fusion community would significantly improve the trust and reliability attributed to its research, as well as fostering a culture of best practice, as the PROV model is designed such that the granularity of provenance description can be iteratively refined.
Fusionprov-a demonstration and exploration of applying PROV to fusion data As part of the efforts to explore and summarise the state of provenance capture and report in fusion, the FAIR4Fusion project has developed a tool, fusionprov that generates provenance reports from existing fusion data. It supports both MAST/MAST-U data and IDSs. The tool provides an interface that takes a given dataset or signal and using its own awareness of the ontology and locations of data as defined for both MAST/-U and IMAS data, retrieves the relevant information and builds a W3C-PROV compliant provenance document for the input signal or IDS, by calling the prov python package, provided by the PROV developers. fusionprov is itself a python package, registered with the Python Package Index and can be installed using python's package manager, pip.
A significant caveat for this tool is that for MAST/-U data and IDSs, the tool can only retrieve the data it needs within a carefully curated environment. In practice, this means that the user will need to be running the tool from one of a very limited number of locations, as the data access server utilises an IP-whitelisting security mechanism. This is one of the most notable findings of the provenance element of the FAIR4Fusion project, that while data is in some cases ostensibly 'open', the tools used to retrieve the data fall short of the standards necessary to describe the data as truly 'findable' or 'accessible'. If data is to be presented as open, it needs to be retrievable from a publicly facing server, with a welldocumented and well-maintained suite of access APIs.
Demonstrator Within the course of the FAIR4Fusion project two demonstrators addressing different aspects of the use cases that were collected during the initial phases of the project were implemented and assessed. For technical testing purposes a database with low resolution, but representative data in the IDS-summary format was set up and used for assessing the demonstrators. An example of searchable variables from the test-database can be seen in figure  6 , where the output of a process identifying flattops and visualizing plasma characteristics (confinement factor H 98 , confinement time τ E plasma current I p , magnetic field B T , and heating powers (total, NBI, ICRH and ohmic power) P tot , P NBI , P ICRH and P Ohm is shown as functions on time. An identified flattop is shown by the light green area in the top subplot.
Demonstrator I The main goal of Demonstrator I was to provide reference implementation of the Blueprint in the following areas: integration of Demonstrator I with IMAS framework, remote access to experimental data using Uniform Data Access layer (UDA) of IMAS, proof of concept for Jupyter Notebook based development and direct data access from Python scripts, integration with AAI platform, and Docker based deployment. Because the IMAS platform defines a placeholder for metadata-the Summary IDS-it was a natural choice to base data ingestion on these structures. In addition to that, FAIR4Fusion project defined one more IDS-Dataset Fairfor storing metadata describing the source of the information in greater detail. Based on these two sources of information, Demonstrator I collect, transforms, stores and then presents data to final users.
Due to the fact both IDSes-Summary and Dataset Fair-provide distilled information extracted from experimental data, it is possible to run uniform comparison of data coming from different sources. Demonstrator I was able to extract this information from both local and remote data sources. Local data access was based on MDSPlus format, while remote access was realised using UDA services. As the development has been based on IMAS framework, data access itself is very similar to the way regular developers access IDS based data. Thanks to its modular approach, it is possible to extend Demonstrator I's data source list by implementing custom plugins. It means that IMAS is not a limitation here, it rather serves as a reference, and different data sources are possible. Remote data access was realised using UDA technology.
UDA allows the use of remote data (stored in IMAS based format) directly from the code. From a developer's perspective, there is not much difference between direct access to local and remote data. Thanks to this approach, it was possible to provide users of Demonstrator I with a Jupyter Notebook based solution where not only Summary or Dataset Fair data are available, but the whole content of the pulse file that was stored inside Catalog QT 2. Jupyter Notebook provided as part of FAIR4Fusion based solution can be either incorporated into Catalog QT 2 or can serve as a separate application. In both cases it provides a Python based template for accessing remote data via UDA. One of the limitations, when it comes to accessing remote data, was authentication and authorization. There is no single, unified, way of accessing information regarding experimental data.
Inside Demonstrator I we have applied an AAI solution for user authentication and authorization. It was successfully integrated with eduTEAMS Identity Provider. This way, it was possible to share Catalog QT 2 with any participant of eduTEAMS initiative. Authentication and authorization mechanisms were developed using a well-established software component-Keycloak. It is an Open Source identity platform that provides support for several authorization services. Demonstrator I provides not only backend services (ingestion of data, storage, IMAS integration) it also provides frontend services (figure  7 ). There are different ways of accessing data stored inside Catalog QT 2. ReactJS based frontend is the most obvious way of accessing data stored inside Catalog QT 2. It provides users with a user friendly, GUI based approach executed directly inside the browser.
However, it is not the only way data can be retrieved from Catalog QT 2. Users can also use CLI based client and Web Service client. Catalog QT 2 backend is a Web Service based solution with well-defined API documented using a tool called Swagger-de facto standard for Web Services documentation. This way, it is possible to integrate Catalog QT 2 into a custom pipeline where searching for suitable data is one of the steps of computations. Demonstrator I was designed in a modular, extensible way, to some extent based on micro services. Each and every component can be installed separately. Communication between components is realised using Web Services. However, it is also possible to use Docker based installation that binds all components together using a docker-compose based approach. Different elements are combined into a single service.
Docker based solution uses IMAS Docker-a Docker image that provides a minimal working IMAS environment. It consists of elements that are essential for running IMAS enabled codes. It is worth noting that IMAS Docker was initially developed for a different purpose, but its modular nature allowed it to be used as it was inside Demonstrator I and benefit from its ability to operate on IMAS based data. Demonstrator I, as a reference implementation, proves that components used inside the implementation (Docker, IMAS, UDA, Jupyter Notebook) can be successfully linked together while at the same time they can serve different roles in a different environment. Thanks to applying modularity it was possible not only to extract experimental data but also present it in user friendly and appealing form.
Demonstrator II Demonstrator II is focused on exploring alternative and additional technologies that will be required or may improve usability of the Fusion Open Data Framework once it is released. Since Demonstrator II is not tied to a concrete set of technologies, but rather its idea encourages to explore new possibilities, the implementation has been started from scratch based on generic and popular solutions. The implementation comprises a backend that executes computational experiments and a frontend for visualising shots and experiment results. The backend explores the integration of the following elements: • Containerization technologies, especially in the context of FAIR sharing of complete computational experiments besides experiment data. • Cloud computing for distributed execution of computational experiments.
In particular, using concepts and software from R&D work on workflows to orchestrate the execution of computational experiments defined as pipelines of containerized tools. • Interoperability between alternative representations for metadata and summary IDS, achieved via transformers available for inclusion in pipelines. • Following FAIR and open science principles by maintaining metadata about the provenance of the shots processed, as well as links between data, experiments that process them, and publications that describe these experiments • Integrating the management of data, container, and computational resources with Keycloak, so that role-based access encompasses all elements of the backend. Containerization is a highly flexible way to publish specific, reproducible execution environments and deploy software on modern computational infrastructures.
For modelling and simulation data outside of the analysis done at the experiments, there is no common storage system and a long term storage facility for simulation data need to be installed to support the modelling community. In both cases the provenance capture of the data will need to be structured and the Fair for Fusion project have been proposing and supporting extension to the IMAS data definitions to facilitate that, that are now included in the IMAS data dictionary. The proposed infrastructure can be scaled from a system supported in a single lab, to serving a national level structure or as presented here the EU fusion community and beyond.
In section 2, we describe the standard NMA model as a logistic regression model and the proposed PL-NMA model. Section 3 presents a simulation study exploring the performance of our method in terms of bias and precision in comparison to existing NMA approaches for rare events under different scenarios. Finally, in Section 4 we apply the different models in two exemplar NMA datasets, and in Section 5 we discuss the strengths and limitations of our PL-NMA model.
e. 1-2% and 0. 5-1%). For the scenarios involving multi-arm studies (17-32), we generated studies with 100 to 200 participants per arm and both homogeneous and heterogeneous samples. Finally, in Scenarios 21-24 and 29-32 we considered a mix of extremely low with higher baseline risks. Table  1  provides a summary of the different scenarios. Our simulation did not investigate the impact of studies with zero events in all treatment arms. Table  2  shows that across all scenarios the majority of the 1000 simulated datasets included only a handful of studies reporting only zero events. The latter implies that any impact of such studies on the final results cannot be captured through the present simulation study.
Evaluated models and estimands In each scenario, we generated 1000 datasets and we compared the following models: • Common-and random-effects IV-NMA model with 0. 5 correction for studies with at least one zero event arm • Common-effect MH-NMA and NCH-NMA without 0. 5 correction for studies with zero event arms. • Common-and random-effects PL-NMA model. • Common effect logistic regression NMA model with standard (unpenalized) likelihood. • Random-effects logistic regression NMA model using MLE with both fixed and random intercept(s); • Common-and random-effects Bayesian NMA with exact binomial likelihood and noninformative priors to the treatment effects, ' ( ~ (0, 100  3  ), and heterogeneity, Q 3 ~{ +(0,4)  26. The random-effects model is the Bayesian equivalent of the frequentist BN-NMA model.
Estimands and performance measures The estimands of interest are the -1 "#. /s between treatments = 2, … , and treatment 1. The performance of the models was investigated in terms of the mean bias defined as the mean difference between the estimated and the true "#. /s averaged over simulated datasets and estimands for each NMA method: the true estimands are all positive so averaging over estimands makes sense. We further calculated the mean coverage in each scenario defined as the percent of the corresponding 95% confidence (or credible) intervals that included the corresponding true "#. /. Finally, the methods were compared in terms of the mean squared error (MSE) and mean length of confidence (or credible) intervals averaged across multiple contrasts and simulated datasets. The simulations were conducted using R version 4.
This model had some convergence issues but failures were very rare across the 1000 datasets of each scenario. An increase in convergence failures was observed in the scenarios with 8 treatments in the network (Supplementary Table  1 ) The Bayesian commoneffect model had better performance than the respective random-effects model, but there are many scenarios where results from both models are suffering from an important amount of bias. In all scenarios, the results were not affected materially for any of the models when the datamechanism involved heterogeneity. Full results are available in the Supplementary Tables  2  and 3  and are consistent with the results that we obtained for each contrast separately (Supplementary Figures  1 2 3 4 ). In terms of estimation of the heterogeneity, the Bayesian random-effects model appeared to have the worst performance; in all scenarios it substantially overestimated Q (heterogeneity results available only in the Supplementary Table  4 ).
04 to -0. 09. Finally, since there is no clear correspondence between Q and l we calculated for l the number of cases for which l > 1 across all datasets and all heterogeneous scenarios. For scenarios with higher control group risks (scenarios 4,8, 22, 24, 30, 32) we observed that l was greater than one in 20% to 40% of the simulated datasets. However, this frequency was reduced as the event risks were becoming lower and 0 for scenario 16. In terms of coverage probability, the PL-NMA models did not perform very well when the Waldtype confidence intervals were used (Figure  2 ). The coverage probability was increased, though, by using profile likelihood confidence intervals and in most scenarios, it was above the nominal level of 95%. MH-NMA and NCH-NMA models had similarly good performance in terms of coverage probability close to the nominal level, but it should be noted that the performance of NCH model was again decreased for the scenarios with higher event risks (scenarios 3, 4, 7, 8).
Safety of inhaled medications for patients with chronic obstructive pulmonary disease We compared the results across the different models using a network that evaluates the safety of inhaled medications for patients with chronic obstructive pulmonary disease  32. The network consists of 41 studies and the outcome of interest is mortality. This is supposed to be a rare outcome as from 52462 patients in total only 2408 (4. 6%) experienced the event of interest. In total, 13 out of 41 studies reported less than 5 events and 20 out of 99 arms had 0 events. The network diagram of this dataset is depicted in Erreur ! Source du renvoi introuvable. We analyzed the data using the PL-NMA model both with Wald and profile likelihood CIs, the MΗ-NMA model, the NCΗ-NMA model, the BN-NMA model, and finally both the common and random-effects Bayesian models.
Safety of different drug classes for chronic plaque psoriasis The second example is a network that evaluates the safety of different interventions for chronic plaque psoriasis  34. The dataset consists of 43 studies that involve 5 drug classes and placebo. Here, we compared again the different NMA methods but in a more extreme situation where the event risks in the studies range between 0 and 1%. The outcome of interest is the number of malignancies that occurred after using the drugs. The mean sample size per study arm is 226 patients. Out of the 43 studies in this network, 29 (69%) are studies with zero events in all treatment groups. All other methods than the PL-NMA and BN-NMA with random intercepts.
The European Plate Observing System EPOS is the single coordinated framework for solid Earth science data, products and services on a European level. As one of the science domain structures within EPOS, EPOS Seismology brings together the three large European infrastructures in seismology: ORFEUS for seismic waveform data & related products, EMSC for parametric earthquake information, and EFEHR for seismic hazard and risk information. Across these three pillars, EPOS Seismology provides services to store, discover and access seismological data and products from raw waveforms to elaborated hazard and risk assessment. ORFEUS, EMSC and EFEHR are community initiatives / infrastructures that each have their own history, structure, membership, governance and established mode of work (including data sharing and distribution practices), developed in parts over decades.
Among those issues is also the 'timeliness' of data and products: while a number of services offer almost-real-time access to newly available information at least in theory, this comes with various downstream implications that are currently actively discussed. We also cover the envisaged role of EPOS Seismology in supporting international multi-disciplinary activities that require and benefit from harmonized, open, and interoperable data, products, services and facilities from the waveform, catalogue and hazard / risk domains of seismology.
Finally, based on the obtained CRT, the user will have the opportunity to formulate his/her qualitative diagnosis to support his/her SC improvement step. Figure  1  summarizes the DSS steps and the following sub-section will give more information about how technically this DSS runs to get such a result. The services' components include some important contributions through specific algorithms allowing to gather and exploit the useful knowledge for an automatic generation of the CRT. This is one of the main contributions of the proposal. - The database components are in the core of the device as it includes some usual database for the storage of the collected information, but also because it includes a specific database called "Generic Reality Tree". This is another major contribution of the proposal.
Let's start by presenting the Generic Reality Tree database. This database is a knowledge base which represents all the possible connections which can exist in a Make-To-Stock environment between symptoms, facts and conflicts. This knowledge base has been established conceptually by the "web of conflicts" proposed by  [18]  and recently enriched by  [19]  based on a review of both practices and literature. In this paper we did not try to challenge the content of this knowledge base but only tried to instantiate it practically through our DSS. However, we must give some insights regarding the content of this database to well understand how the DSS runs. Basically, the Generic Reality Tree database makes the link between the current major conflicts which can exist in a production environment (e.
g. , buy in volume vs buy only what's needed; run larger batches vs run smaller batches; authorize overtime vs do not authorize overtime, etc. ) and the undesirable effects, called symptoms (e. g. , too much inventory, bad quality of service, machines / tools which are not used by shopfloor, etc. ). In  [19] , the authors suggest to represent this knowledge base through a logic graph. Practically, the Generic Reality Tree database is the pivot of the DSS as it will be used to select the questions that the system must ask to confirm or infirm the existence of this or that symptom. Basically, the DSS will travel across the graph to automatically ask additional questions in order to close potential options or at the opposite, confirm some other ones. The final CRT that the DSS will build up will be composed of all validated symptoms, facts and conflicts for the studied system as well as all the validated connections.
The diagnosis will be based on this mapping of the current situation. Fig. 2. Functional architecture of the DSS Obviously, the knowledge base is not enough to get such a result. Some valueadded services are needed to exploit properly the knowledge of the Generic Reality Tree on one hand, and the knowledge given by the user about the studied system on the other hand. In our proposal, four main algorithms have been developed and implemented as shown on Figure  2. Practically, these algorithms manage the following issues: -Algorithm 1 is about generating the first set of potential symptoms and conflicts that the studied system should occur based on the key features of the system indicated by the user and of course, the Generic Reality Tree database. -Algorithm 2 is about travelling across the knowledge base function of the answers given by the user to both confirm / reject potentialities and ask for new questions able to open on new set of potentialities according to previous ones.
The proposed Fourier-based method is optimised, tested, and validated on simulated datasets and scenarios combining synchronous and asynchronous spindle error motions and roundness deviations. The given results are accurate at the sub-nanometre level (<0. 5 nm) and the effectiveness of the Fourier-based method for ultra-high accuracy applications is proven. Further, Monte Carlo simulations, performed to investigate the influence of artefact indexing errors on measurement uncertainties, confirmed the numerical investigation. Finally, an experiment was conducted on spherical material standards made of ceramic using a high-precision roundness measurement machine. The given results are more accurate (at nanometre level) than those of the 'classical' multistep methods.