dataesr/scientific-paragraphs-categorization huggingface dataset:
At the same time, the first probabilistic hazard calculations were developed at CEA [e. g. ,  Goula, 1980]. In the 1990s, BRGM performed probabilistic seismic hazard calculations for France based on the seismogenic source model produced by the EPAS working group. Current official French zoning relies on hazard computations from Geoter  [Martin et al. , 2002]. Over time, PSHA studies have been performed at IRSN, CEA, and EDF for regulatory purposes and research. The academic world had little involvement in PSHA, but this is changing. Thanks to the various actions in RESIF, estimation of probabilistic seismic hazard in France will integrate the vision of the academic community in the future. PSHA estimates have varied among studies along the years. Datasets constantly grow, input models improve, and present levels are more accurate than previous decades; however, the uncertainties are still large, as the estimation of earthquake occurrence probabilities and associated ground motions remain particularly challenging in a low-to-moderate country like France.
The best way to move forward is to be transparent on the uncertainties and to include in the process the researchers working on the fields that feed the input models (e. g. , geologists, paleoseismologists, geodesists, statistical seismologists, etc. ). There is no academic or public institution officially in charge of leading PSHA in France (such as INGV in Italy or ETH in Switzerland), so there is presently no authoritative institution in charge of delivering seismic hazard estimates, nor authoritative datasets (e. g. , earthquake catalogs, seismogenic source models, fault models) ready for SHA. In the future, the RESIF consortium might endorse this responsibility. Furthermore, new datasets should be incorporated in the inputs necessary for hazard assessment, such as the strain rates estimated from GPS measurements, with ongoing research to understand how they can be used to constrain earthquake recurrence models.
Acknowledgments The constitution of Figures 4 and5 was made possible by a number of authors who kindly sent us numeric files in order to include the exact, original PGA values and ranges (Pascal Dominique,  Agathe Roullé ,  Ramon Secanell ,  Stéphane Drouet ). We thank them warmly. We are also grateful to  Christophe Martin , two anonymous reviewers, and the editor  Frédéric Masson  for thorough and detailed reviews.
Context. The sample of Solar system objects has dramatically increased over the last decade. The number of measured properties (e. g. , diameter, taxonomy, rotation period, thermal inertia, etc. ) has expanded even more quickly. However, this wealth of information is spread over a myriad of studies, with different designations reported per object. Aims. We provide a solution to the identification of Solar system objects based on any of their multiple names or designations. We also compile and rationalize their properties to provide an easy access to them. We aim to continuously update the database as new measurements become available. Methods. We built a Web Service, SsODNet, which offers four access points, each corresponding to an identified necessity in the community: name resolution (quaero), compilation of a large corpus of properties (dataCloud), determination of the best estimate among compiled values (ssoCard), and a statistical description of the population (ssoBFT).
To achieve this goal, once a week we gather all the available planetary object designations from the Minor Planet Center  (Marsden 1980)  for asteroids and dwarf planets, the IMCCE's CometPro Database  (Rocher & Cavelier 1996)  for comets, the Extrasolar Planets Encyclopaedia (Exoplanet-Team 2021) for exoplanets, and CelesTrak  (Kelso 2021)  for spacecrafts and debris. These designations are then stored and indexed in a dedicated database. We use the NoSQL database Elasticsearch 13 to manage the millions of designations. It is a full-text search engine based on 13 https://www. elastic. co/ the Apache Lucene library 14. Each object is defined by a set of fields (document) defining its Id, name, aliases, parent, type, and so on. Documents are stored in an Elasticsearch index as JSONformat data.
In particular, some size-limited sample may be extremely valuable, such as results on a single target obtained during a spacecraft rendezvous for example. Therefore, the goal of compiling every estimate should not be overlooked by the community. SsODNet. dataCloud compiles in a single database as many estimates as possible for a variety of SSO properties. Such a centralization of data may appear anachronistic in the current landscape of connections to remote databases, such as what is regularly done in the VO  (Bayo et al. 2008). It is, however, required here. First, the remote databases do not exist. Second, owing to the issue of SSO naming, on-the-fly cross-matches between resources would be slow upon query. We chose to place the workload on the server side, in an asynchronous process, to provide a fast service to users.
Method The design of the dataCloud is very simple: the parameters are grouped by collection of properties in SQL tables, such as diameter and albedo (as they are seldom derived independently), mass, thermal inertia, taxonomy, astrometry (the MPCAT-OBS database, MPC 2021), and so on. There are a few exceptions to this general scheme. The osculating elements of asteroids from the Minor Planet Center (MPC,  Marsden 1980 ) and the Lowell observatory  (Bowell et al. 1994) , as well as those of comets from the IMCCE  (Rocher & Cavelier 1996) , are stored in separated tables. The Appendix A provides the list of collections composing the dataCloud ecosystem. Each entry of tables corresponds to a single determination of a parameter for a given target. Parameters are stored with their uncertainties, the method used to obtain them (see Appendix B), a selection flag (used to discriminate among estimates; see Sect.
4), and the bibliographic reference of the source of data. A given SSO, or bibliographic reference, may be repeated multiple times: some studies include many objects and the same SSO may have been analyzed in multiple studies. Figure  2  shows the distribution over time of the publications (currently 3007) used to build the dataCloud database. For convenience, a file compiling all the bibliographic references in bibtex format is available 17. A key aspect of the collections is the unique identifier assigned to each SSO, built upon their name and used to identify them across tables. At every update of the database, the name of each SSO (as published by authors) is tested with SsODNet. quaero and updated upon ingestion. Hence, all properties are linked together using the most up-to-date designation.
2020). We refer to Table  C. 4 for a full listing of the order of preference. The average spin coordinates are computed using Eq. (  1 ). However, as several ambiguous spin solutions may co-exist for a given SSO, we identify which estimates correspond to which spin solution using K-Means clustering  (Lloyd 1982) , as provided by the scikit-learn 21 python package  (Pedregosa et al. 2011). We consider that up to four distinct spin solutions can be present, such as for (20) Massalia (Fig. 7 ). Spin coordinates must be within 30 • of the average to be include in a cluster. We set default uncertainties of 30 • on spin coordinates whenever they have not been specified by the respective authors. We used a similar approach, based on K-Means clustering, for the rotation periods. In this case, the threshold to belong to a solution was set to 0.
Web-service interface We provide a Web-service interface, built upon XML and SOAP technology, that allows for a full interaction with SsODNet through several methods: (i) resolver: to identify SSO (high level API), (ii) datacloud: to retrieve all known values of SSO properties, (iii) ssocard: to retrieve the best estimates of SSO properties. The user can simply post a request to the method end-points to gather corresponding data, using a data transfer program such as wget or curl. More advanced users can implement the SOAP Web service to ensure an application-toapplication communication between SsODNet and a software or a public Web page. Data exploration is accessible via the command line interface of rocks in a straightforward, uniform syntax:.
$ rocks [command|parameter] [asteroid_identifier] Here, the parameter can be any key from the ssoCard or dataCloud catalogs, while the asteroid_identifier is any identifier that can be resolved by quaero. The result of the query is printed in the console. Commands such as id and info serve to identify an asteroid and to print the asteroid's ssoCard. $ rocks id "1975 XP" (234) Barbara $ rocks taxonomy Barbara L $ rocks diameter barbara 46. 3 +-5. 0 km $ rocks albedo 234 0. 187 +-0. 2839 An overview of all compiled literature values is printed when requesting the plural of the parameters. This is possible for all parameters which have dataCloud entries, such as albedo, mass, taxonomy, etc. Data processing is facilitated for python scripts using the rocks package. The main entry point is the rocks.
Rock class, where each instance reflects a unique asteroid. The asteroid parameters are accessible as class attributes via the dot notation, which again leads to an intuitive syntax: >>> import rocks >>> vesta = rocks. Rock(4) >>> vesta. albedo. value 0. 38 >>> vesta. albedo. error. min_ -0. 04 >>> vesta. albedo. error. max_ 0. 04 >>> vesta. albedo. description 'Geometrical albedo in V band' The asynchronous interaction with the locally cached data and the remote SsODNet repositories allow for a fast analysis process without the use of resource-intensive multiprocessing or multi-threading strategies. To provide an estimate of the execution times, we identified all asteroids in the SDSS Moving Object Catalog DR1 28  and retrieved their ssoCard. The catalog contains observations of 10,585 unique minor bodies, largely referred to by designations that are no longer the main identifier of the object.
Using a combination of quaero queries and a local asteroid name-number-designation index, rocks identifies all objects within 2. 5 s. The ssoCards are retrieved within 320 s from SsODNet, about 30 ms per asteroid. rocks then performs data validation and deserialization (i. e. , converting the JSON server response into a python object) within 120 s, that is, about 11 ms per asteroid. A second execution of the analysis script would benefit from the locally cached ssoCards, rendering any request to SsODNet obsolete. To install rocks, we can use the python package index (PyPI) under the package name space-rocks. The online documentation 29  provides a guide on getting started and tutorials to achieve more advanced data processing results. We note that rocks is actively developed and maintained by the authors of this work.
Future developments We foresee several lines of development for the SsODNet service: data compilation and curation, expansion of the set of parameters and types of SSOs, and development of the interface. Data compilation. First and foremost, we will continue to compile data into the dataCloud, aiming for completeness with respect to the listed parameters. Indeed, it is the building block of the ssoCard and the ssoBFT, which are automatically generated from the entries in the dataCloud. On the other hand, quaero has been working and been updated weekly for several years, following the growing list of SSOs listed by the MPC. Thus, a continuous scientific monitoring of publications is required for the service. We welcome any feedback, especially on data sources that may be missing or erroneous entries.
While we conducted multiple checks on the data included in SsODNet, some typographical errors may lurk in the unprecedented size of the data compilation. We will happily include sources that are not included in the current release of the service and correct entries. Furthermore, SsODNet can be used by any group or researcher to publish regularly updated data. A simple file (VOTable, csv,. ), with sufficient metadata at a static url can be used as a source, without requiring a server or a database with a web service. Set of parameters. The set of parameters currently available in SsODNet is already broad, covering dynamical, surface, and physical properties (Table  A. 1). There are, however, other parameters of interest that will be added to the dataCloud (and, hence, ssoCard and ssoBFT), such as the source region probabilities for near-Earth objects  (Granvik et al.
2017)  and their minimal orbital intersection distance with planets (MOID, Marsden 1993), activity for asteroids and Centaurs  (Hsieh & Jewitt 2006; Jewitt 2009) , and radar albedos  (Neeley et al. 2014). Additional computed parameters can also be added in ssoCard, such as surface gravity or escape velocity. Types of SSOs. The present release of SsODNet focuses on asteroids because they are the prime targets of study of the authors. The service was nevertheless designed to cope with all classes of SSOs: comets, planets, satellites, and interstellar objects. For instance, quaero already deals with the designation of all these categories. We thus welcome partnership with everyone willing to contribute to build this community database. Beside the collection and curation of data, a set of parameters relevant for these celestial bodies must be defined (e.
Conclusions We present a new Web Service, SsODNet, which provides a convenient solution to the issues of SSO identification and the compilation of properties. It consists of a suite of applications, each with its own programming interface: quaero for name resolution, dataCloud compiling SSO properties, ssoCard providing the set of best estimates for each SSO, and ssoBFT compiling the latter for all SSOS. These entry points deliver JSON as native outputs. We have released a python interface for these services: rocks, available in the python package index (PyPI). SsODNet is fully operational. The name resolver quaero is updated weekly to follow SSO discoveries. We plan on monthly updates for the others applications, following compilation of data from continuous monitoring of new publications.
0) 27 inclination double Inclination to ecliptic (deg) (J2000. 0) 28 mag_H1 double Constant term of magnitude to compute the total magnitude 29 mag_R1 double Coefficient of log(r) to compute the total magnitude 30 mag_D1 double Coefficient of log(Delta) to compute the total magnitude 31 mag_H2 double Constant term of magnitude to compute the nuclear magnitude 32 mag_R2 double Coefficient of log(r) to compute the nuclear magnitude 33 mag_D2 double Coefficient of log(Delta) to compute the nuclear magnitude 34 selection int Selection flag (Section 4) 35 iddataset int Bibliographic unique reference Fields follow the original COMETPRO data (Rocher & Cavelier 1996). Table A. 5: # Field Type Description 1 num 2 name 3 density 4 err_density_up 5 err_density_down double Lower uncertainty on the density (kg•m -3 ) int SSO IAU number varchar SSO name double Density in kg•m -3 double Upper uncertainty on the density (kg•m -3 ) 6 method varchar Description of the method (Table B.
0) 23 vgs_y double y component of spacecraft geocentric position vector (au) (EQJ2000. 0) 24 vgs_z double z component of spacecraft geocentric position vector (au) (EQJ2000. 0) 25 iddataset int Bibliographic unique reference MPC Web site: https://minorplanetcenter. net/iau/info/OpticalObs. html.
It is often challenging to present the available evidence in a timely and comprehensible manner. We aimed to visualize the evolution of evidence about antidepressants for depression by conducting cumulative network meta-analyses (NMAs) and to examine whether it could have helped the selection of optimal drugs. We built a Shiny web application that performs and presents cumulative NMAs based on R netmeta. We used a comprehensive dataset of double-blind randomized controlled trials of 21 antidepressants in the acute treatment of major depression. The primary outcomes were efficacy (treatment response) and acceptability (all-cause discontinuation), and treatment effects were summarized via odds ratios. We evaluated the confidence in evidence using the CINeMA (Confidence in Network Meta-Analysis) framework for a series of consecutive NMAs.
6] [7] [8] [9]  The powerful graphing package ggplot2 greatly facilitates data visualization. 10 The CINeMA software, using the netmeta package and other self-programmed routines facilitates and simplifies the evaluation of the credibility in NMA results. 11 Finally, the shiny package in R makes it possible to build web applications that can take advantage of all R packages and display results interactively. 12 Making good use of these techniques can enhance visualization of the NMA output. In this article, we present a case where visualization of the NMA results via a Shiny application can provide insight to the evolution of evidence in terms of structure, results, and credibility. We conducted a series of cumulative NMAs at several consecutive time points over the past 40 years. More specifically, we aim to: (a) visualize the evolution of evidence and the level of the confidence regarding the effects of antidepressants using plots which integrate efficacy, acceptability, and confidence in the evidence; (b) examine whether visualization could have facilitated the selection of optimal drugs in earlier years.
| Study selection We used aggregated study-level data identified and collected by GRISELDA (Group of Researchers Investigating Specific Efficacy of individual Drugs for Acute depression). 3 A detailed description of the methods can be found in the protocol. 3, 14 Briefly, published and unpublished double-blind RCTs of the acute phase treatment of adult patients (≥18 years old) with a primary diagnosis of major depression were included. The eligible drugs were: agomelatine, amitriptyline, bupropion, citalopram, clomipramine, desvenlafaxine, duloxetine, escitalopram, fluoxetine, fluvoxamine, levomilnacipran, milnacipran, mirtazapine, nefazodone, paroxetine, reboxetine, sertraline, trazodone, venlafaxine, vilazodone, and vortioxetine. Only study arms with drugs administered at doses within approved ranges by drug regulatory agencies were included in the analysis.
| Data extraction In this study we used two primary outcomes, efficacy (measured as the response rate, that is, the proportion of patients who showed a reduction of at least 50% on validated depression severity scales compared to baseline at a time point as close to 8 weeks as possible between 4 and 12 weeks) and acceptability (measured as the proportion of patients who withdrew early due to any reasons). Since we aimed to show the evidence evolution, we conducted NMAs at different time periods. Different NMAs included RCTs conducted during different periods, thus we extracted the completion year of each trial. Publication date was used if the trial's completion year could not be identified; and if both were unavailable, the date of approval by drug agencies was used. The dataset also comprises risk of bias assessments for each included RCT, based on the Cochrane Collaboration risk of bias tool.
| Data analysis We programmed a Shiny application that performs NMAs and presents the results interactively. The web app is accessible at https://cinema. ispm. unibe. ch/ shinies/GRISELDA/, and several exemplar screen shots from the app are provided in the Appendix. We used the netmeta 1. 1-0 package in R (version 3. 6. 0) to conduct NMA, and to produce the network diagrams, league tables, and forest plots. We used ggplot2 package to draw two-dimensional plots combining both efficacy and acceptability. In the web app, NMAs can be performed under different conditions. Users can decide whether they want to see the results of an analysis from: (a) both placebocontrolled trials and head-to-head trials, or head-to-head trials only; (b) RCTs completed at any particular time period; and (c) both published and unpublished studies, or published studies only.
For each NMA, a randomeffects model was used to synthesize odds ratios (ORs) for both efficacy and acceptability. The transitivity assumption of the entire dataset was previously deemed plausible in the most recent analysis. 3 We examined the comparison-adjusted funnel plot to see if there were significant differences between precise and imprecise trials. In the Results section of this article, we show a series of consecutively conducted NMAs (at 1990, 1995, 2000,  2005, 2010, and 2016, respectively) in order to demonstrate the evolution of evidence, and each analysis includes RCTs completed up to 1 year before that date. 7] [18] [19] [20]  We also assessed the confidence in the evidence for these NMAs, using the CINeMA (Confidence in Network Meta-Analysis) framework  [21] [22] [23] [24] [25]  through the dedicated software.
11 The confidence in each NMA OR AB between two given drugs A and B was evaluated for six domains: within-trial bias, reporting bias, indirectness, imprecision, heterogeneity, and incoherence. The software required some input in each domain in order to recommend whether there were "major concerns," "some concerns," or "no concerns" for that particular domain. After judgements for all six domains, we summarized the overall confidence in evidence for each NMA OR AB into high, moderate, low and very low. For each drug, we calculated the percentage of the four levels based on all comparisons including that drug, combining both efficacy and acceptability. We therefore produced a level of confidence for the evidence provided for every single drug. More details on CINeMA can be found in References 21-25, and we also provide details of our considerations for assessment in the Appendix.
| Included studies and characteristics of the network The dataset includes 190 head-to-head trials (179 trials with 33 428 patients for efficacy, and 174 trials with 31 596 patients for acceptability, respectively) and 460 placebo-controlled trials; only the results from the former are presented below. The study selection process (PRISMA flowchart), the references, characteristics and risk of bias assessment for all the included studies are in the Appendix (eFigure 1, eTables 1 and 2). Figure  1  shows the network diagrams for efficacy from 1990 to 2016. The network diagrams for acceptability are shown in the Appendix (eFigure 2).
Other than the figures displayed in this article, users can also explore the analyses which involve placebocontrolled trials in the web app. The comparison-adjusted funnel plots including placebo-controlled trials for the whole dataset indicate statistically significant asymmetry (P-value for Egger's test is. 0025 in both efficacy and acceptability). However, since the plots are not extremely asymmetrical, the small P-value may due to the large number of RCTs. If changing the analysis to pooling more recent studies (eg, after 1990), the test of asymmetry becomes insignificant. It suggests that the small-study effect may exist in old RCTs. The two-dimensional plots imply that the differences between active drugs are smaller at any time point when placebo-controlled trials are included. This phenomenon has been extensively discussed and possible explanations were given in a previous study.
Several studies adopted a two-dimensional graph to combine the efficacy and acceptability ORs for each drug. 3, 27 In addition to these conventional two-dimensional graphs, we presented the certainty of evidence for each drug by illustrating the composition of four-level confidence in a small pie chart. It allows us to easily see that even though some drugs showed good efficacy and acceptability, if the evidence appeared to have low certainty, the recommendation of those drugs should be made with caution. As NMA is a method to synthesize massive data but yet produce a large amount of results, it is imperative to find a way to display their results more efficiently for physicians to comprehend. A powerful R package Shiny makes it easy to build interactive web apps straight from R. Within the Shiny application that we have developed, users can change some parameters and view the results of their own interest and to answer their own clinical questions.