dataesr/scientific-paragraphs-categorization huggingface dataset:
(2016)  is used as a complementary tool to quantitatively compare the spectral content of the studied time series. The proxies used were produced within the framework of the MISTRALS/PaleoMeX research project. They are supplemented by published sequences from the near Atlantic area (northwestern Spain, inner Bay of Biscay) and time series recording possible drivers (solar variability) or major modes of climate variability (ENSO). Based on this dataset, our study aims to i) identify forcing influencing western Mediterranean climate variability over the past 8000 years, ii) investigate possible links between climate variability in this specific key region and the Atlantic or tropical areas, and iii) review elements of climatology that may explain the links we detect between the studied paleoclimatic time series.
Practical considerations We used the WAVEPAL python package (https://github. com/guillaumelenoir/WAVEPAL), which allows time-frequency analysis of irregularly sampled time series using the weighted smoothed scalogram  (Lenoir and Crucifix 2018b). The temporal resolution of the weighted smoothed scalogram, i. e. the number of time indices at which it is calculated, is equal to the length of the analyzed time series to avoid oversampling. For each time series, a polynomial trend is fitted by visual inspection. Even if the time series is not detrended, the degree of this polynomial trend is necessary to defined an orthogonal projection invariant with respect to this trend. The degrees of the polynomial trends fitted to the studied proxies are given in the Table  1. The smoothing coefficient ( = 0.
Significance testing The significance of the highlighted features in the time/frequency plane was statistically tested with hypothesis testing using the WAVEPAL and CARMA (https://github. com/brandonckelly/carma_pack) python packages. For each point of the time/frequency plane, we independently tested the nullhypothesis (2 ) that there is no periodic component in the analyzed signal for a given scale (i. e. frequency) and time index pair. To this end, the distribution of each point of the weighted smoothed scalogram was calculated under the null-hypothesis and the points of the data scalogram above the X th percentile were considered to be significant with a (100-X)% level of significance, entailing a rejection of the null-hypothesis with X% confidence  (Lenoir and Crucifix 2018b). For all analyses, the 5 and 10% confidence levels were plotted on the scalograms.
2009 (Kelly et al. , 2014) )  of the widely used first-order autoregressive process (AR1) for significance testing in spectral analysis (e. g. Torrence and Compo 1998, Schulz and Mudelsee 2002). In this article we choose to use a CARMA (1,0) process as background noise for the significance testing. Indeed, spectra of paleoclimatic time series often display a decreasing spectral amplitude with increasing frequency, which can be explained simply by a random AR(1) process  (Hasselmann 1976, Schulz and Mudelsee 2002). Assuming that the studied time series is a just trend with a CARMA(1,0) process superimposed on it (null-hypothesis), the trend is removed and the CARMA python package is used to estimates the characteristics of this noise. The WAVEPAL package is then able to analytically compute the distribution of the scalogram points and the corresponding confidence level from the previous results.
Such a method for propagating age model uncertainties has been used previously by  Anchukaitis and Tierney (2013)  to conduct an empirical orthogonal function analysis on proxies from different sequences. First, the age models of all the studied time series were recalculated from scratch with the RBACON R package for age-depth modeling using Bayesian statistics (Blaauw and Christen 2011, https://CRAN. R-project. org/package=rbacon). At the same time, 3000 alternative age models without age reversals were generated with RBACON for each time series using the same method. The most straightforward way to address the issue of age model error would have been to use these alternative age models to compute 3000 alternative weighted smoothed scalograms for each time series. This would have allowed an easy evaluation of the impact of the age model uncertainties on each point of the time/frequency plane.
Let's consider a time series call X with | > the vector of its measures and | > the vector of its sampling times. A simple visual observation reveals that the weighted smoothed scalogram of X displays a significant local maximum between , at a period around λ 89: (The WAVEPAL python package allows horizontal dashed lines to be drawn across the scalogram, which is convenient for approximating periods). In order to evaluate the consequences of age model errors on the period characterizing this maximum we use the following procedure: • A time t 89: , with < 89: < , is chosen by visual observation where the local maximum around λ 89: is particularly well marked • The program will calculate the exact period λ = >= of this local maximum for the time index = >= ∈ | > closest to 89:. • Then 3000 scalogram slices for this time index = >= will be calculated with exactly the same parameters but 3000 different time vectors | >.
Welch's Overlapped Segment Averaging method The REDFIT program  (Schulz and Mudelsee 2002)  was used to re-analyze all the paleoclimatic time series using an independent method of spectral analysis in order to check the reliability of low frequency features detected with wavelet spectral analyses. The algorithm of the REDFIT program is based on the Lomb-Scargle Fourier transform  (Lomb 1976 , Scargle 1982 ) and Welch's Overlapped Segment Averaging procedure  (Welch 1967, WOSA method). Just as for the raw wavelet scalogram, the raw auto-spectrum of a time series obtained from the Lomb-Scargle Fourier transform is not a consistent estimator of its true frequency content-it needs to be smoothed. Thus, the time series is divided into several segments with 50% overlap. A linear trend is subtracted from each segment to avoid biases at low frequencies.
Then, each segment is multiplied by a chosen taper to reduce spectral leakage. Finally, the auto-spectrum (periodogram) of the time series is calculated as the average of the Lomb-Scargle Fourier transforms of all the detrended and tapered segments  (Schulz and Stattegger 1997, Schulz and Mudelsee 2002). In practice, we used the Welch taper for most of our analyses  (Welch 1967 ). Tests realized using other available tapers in the REDFIT program gave us equivalent results. On the other hand, the number of segments is a key parameter of this method. For a time series with a given number of points, a larger number of segments will reduce the noise in the auto-spectrum but also decrease the frequency resolution, reducing at the same time the minimum frequency (i. e. the maximum period) that can be investigated.
Comparison of time series in the frequency domain To compare time series in the frequency domain, methods of cross-spectral analysis with statistical tests of significance must be used. Wavelet coherency analysis would have been ideal  (Maraun and Kurths 2004) , but this method is not implemented in the WAVEPAL python package and, to best of our knowledge, has not yet been adapted for irregularly sampled time series. We thus decided to use the program REDFIT-X for cross-spectral analysis of unevenly spaced paleoclimate time series (Björg  Ólafsdóttir et al. 2016)  which generates a coherency spectrum based on the WOSA method (see paragraph above). The coherency of two time series x and y is defined as the squared modulus of their cross-spectrum ( AB ) normalized by the product of their auto-spectrum ( AA ) and ( BB ).
This bias-corrected coherency spectrum is calculated for frequencies in the range from the fundamental frequency (E FGHI,AB ) to the average Nyquist frequency (E JBK,AB ) which are obtained from the time series with the lower resolution, thus E FGHI,AB =. !LME FGHI,A , E FGHI,B N and E FGHI,AB =. "#ME JBK,A , E JBK,B N. Finally, it is important to note that, because the REDFIT-X program is based on the WOSA method, it therefore assumes that the analyzed signals are stationary, which is obviously not the case for our selected paleoclimatic time series in light of the results of the wavelet spectral analyses (see Results and Discussion). It is thus possible that non-stationary spectral features with close periods and time ranges that are detected in different time series using wavelets may not appear in the cross-spectral analyses using REDFIT-X.
Geochemical analysis Smith et al. (  2016 ) performed calcite δ 18 O analysis using an IsoPrime isotope ratio mass spectrometer to track precipitation changes throughout the Holocene. The reliability of the two records within their overlapping period was tested by cross correlation analysis and they were then combined within a single detrended time series  (Smith et al. 2016 Supplementary information). The data for this combined and detrended time series were downloaded from the NOAA database for use in our study (https://www. ncdc. noaa. gov/paleo-search/study/20082). A monitoring study in Cueva de Asiul demonstrates that the cave's hydrological system is recharged primarily by winter rainfall and that the isotopic composition of the cave drip waters reflects the δ 18 O composition of winter rainfall from the preceding year  (Smith et al.
The chronology of the sequence is based on 10 AMS radiocarbon dates on planktonic foraminifera  (Mary et al. 2017 ). The radiocarbon reservoir age is 405yrs  (Reimer et al. 2013 ). The age model was obtained by a smooth-spline regression  (Mary et al. 2017). SST reconstructions  Mary et al. (2017)  derived SSTs from the planktonic foraminifera abundances within the >150μm sediment fraction using the Modern Analogues Technique  (Mary et al. 2017 ). The Annual SST data from the PP10-07 core were retrieved from the Pangea database to be used within our study (https://doi. pangaea. de/10. 1594/PANGAEA. 872166). This time series covers the last 10 000 yrs with a mean temporal resolution of 50 yrs (Table  1 ). Colder and warmer SST periods are recorded in the Bay of Biscay. They are related to variations in heat transport from the tropics toward Western Europe, due to changes in past dynamics of the Atlantic gyres  (Mary et al.
ENSO variability During El Niño events, high SSTs off the coast of Ecuador and northern Peru cause positive precipitation anomalies in the western Andean slope. Moy et al. (2002)  studied a 9m long core from the Laguna Pallcacocha in the southern Ecuadorian Andes in which light-colored laminae of inorganic and clastic materials related to ENSO-driven episodes of alluvial deposition are recorded. This sequence spans the entire Holocene with a very high temporal resolution allowing to obtain a continuous record of the pacific climate variability over the last 12000 yrs (NOAA database : ftp://ftp. ncdc. noaa. gov/pub/data/paleo/paleolimnology/ ecuador/pallcacocha_red_intensity. txt). The age model was obtained by combining the correlation of laminae with radiocarbon dated laminae in a neighboring core and an "event model" assuming that each single high terrigenous deposition events within the core correspond to a single ENSO event.
Discussion In this section, the frequency contents of each different paleoclimate proxy are compared to one another in order to better understand Holocene climate variability and its underlying mechanisms. Oceanic forcing? The 1500 yrs cyclic period SI, and K/Ti ratio time series from the Gulf of lion on one hand and speleothem δ 18 O and Bay of Biscay SST time series from the near Atlantic area on the other hand, display similar significant spectral features after 5000 yrs cal BP characterized by periods of respectively 1530-1590, 1100-1400, 1405 and 1380-1890 yrs (Figure  3 ). This low frequency periodicities are also significantly recorded using REDFIT program (Appendix 1). The coherency spectra of Gulf of Lion time series with Atlantic ones confirm that they are indeed significant shared spectral features, except in the case of the K/Ti ratio and the Bay of Biscay SST in which a marked but non-significant spectral peak at 1500 yrs is detected (Figure  4 ).
Acknowledgements This research was funded by  MISTRALS/PALEOMEX meta-program , the  CNRS  and the  French Museum of National History (MNHN). Paleoclimate time series were extracted from the  PANGEA  and the NOAA database and the work of the data contributors and the PANGEA and NOAA communities is gratefully acknowledged. None of the authors have conflicts of interest to declare. The crew operating the GMO2-Carnac (R/V Le Suroît retrieving core KSGC31) and  GolHo (R/V Néréis)  cruises are thanked.
Data in High Energy Physics (HEP) usually consist of complext complex data structures stored in relational databases and files with internal schema. Such architecture exhibits many shortcomings, which could be fixed by migrating into Graph Database storage. The paper describes basic principles of the Graph Database together with an overview of existing standards and implementations. The usefulness and usability are demonstrated using the concrete example of the Event Index of the ATLAS experiment at LHC in two approaches -as the full storage (all data are in the Graph Database) and meta-storage (a layer of schema-less graph-like data implemented on top of more traditional storage). The usability, the interfaces with the surrounding framework and the performance of those solutions are discussed.
HEP Storage Traditionally, several data structures are used in High Energy Physics (HEP): tuples (tables), hierarchical structures like trees, relational (SQL-like) databases or their combinations (nested tuple, trees of tuples). They can be based on a schema or without a defined schema. Many HEP data sets are graph-like without general schema. They consists of entities with relations. Such structures are not well handled by standard tree-ntuple storage and relations need to be added and interpreted outside of that storage, in the application program. Such data are also not well covered by relational (SQL) databases because users should be able to add new relations, not covered by existing schema. We don't only need the possibility of adding new data with the existing defined relations, we also need to add new relations.
By using Graph Databases, we are moving essential structure from code to data, together with a migration from an imperative to a declarative coding semantics. The new paradigm of Graph databases can be shortly described as Things don't happen, they exist. Structured data with relations then facilitates declarative analyses. The data elements appear in a context, which simplifies their understanding, analyses and processing. The difference between Relational and Graph Database is similar to the difference between Fortran and C++ or Java. On one side, we have a rigid system, which can be very optimized. On the other side, there is a flexible dynamical system, which allows expressing of complex structures. Graph Database can be considered a synthesis of the OO world and Relational databases. It supports the expression of the web of objects without fragility of the OO world by capturing only essential relations and not an object dump.
Graph Database Languages There are, in general, three methods which can be used to access a Graph Database. • Direct manipulation of vertices and edges is always available from all languages, but this doesn't use full graph expression power of more specialized approaches. • Cypher [5] (and GQL  [6] ) is a pure declarative language, inspired by SQL and OQL, but applied to schema-less databases. It comes from Neo4J  [7]  and has been accepted as an ISO/IEC standard. It is available to all languages via a JDBC-like API  [8]. Its problematic feature is that it introduces a semantic mismatch as instructions are passed as a string and not as code understandable to the enveloping environment. There is a wall between code and database, with a thin tunnel which only strings can pass. The overall framework cannot easily understand and handle the logic of the database code as it is writtent in a different language and is using a different paradigm.
The following Cypher code searches for names of all datasets with certain run number. MATCH (a:run)-[:has]->(b:dataset) WHERE a. rnumber = 98765 RETURN b. name • Gremlin  [9]  is a functional language extension motivated by Groovy  [11]  syntax, but available to all languages supporting functional programming. Gremlin is well integrated in the framework language. Gremlin can execute the same search as the Cypher example above with this code: g. V(). has('run', 'rnumber', 98765). out('has'). values('name').
ATLAS Event Index The Event Index service  [13]  of the ATLAS  [14]  experiment at the Large Hadron Collider (LHC) keeps references to all real and simulated ATLAS events. Hadoop [15] Map files and HBase  [16]  tables are used to store the Event Index data, a subset of data is also stored in an Oracle database. The system contains information about events, datasets, streams, runs and their relations. Several user interfaces are currently used to access and search the data, from the simple command line interface, through a programmable API, to sophisticated graphical web services.
ATLAS Event Index History The original Event Index stored all data in Oracle. It was too rigid, it was difficult to add columns or relations and the whole system also suffered from performance problems. In 2013 it was decided to migrated to a Hadoop [15] ecosystem, while keeping a subset of data also in Oracle. All data were now stored in a tree of HDFS Map files. Such system was flexible and fast for mass processing, but too slow for search requests. Another problem was the lack of types of the Map files (they store only strings or bytes); the type system has been created in the application layer. To solve the search performance problem, the data were partially migrated to HBase  [16]. Those HBase tables contain ad-hoc relations (references to other entries). Those relations form a poor-man graph database on top of HBase.
Several prototypes have been then developed to study the next generation Event Index, which will be fully deployed for ATLAS Run 3 at the end of 2020. Those prototypes use Graph Database more directly in different ways: • Prototype 1 stores all data directly in a JanusGraph  [17]  database over HBase storage. • Prototype 2 stores data in a HBase table with a Phoenix [18] SQL interface, graph structure is added via another auxiliary HBase table.
Prototype 1 -JanusGraph A subset of data has been fully imported into a JanusGraph  [17]  database storing data in an HBase table. Part of existing functionality has been implemented. A large part of code (handling relations and properties) has been migrated from the code to the structure of the graph. Most of the graphical interface has been implemented by a standalone JavaScript implementation. Prototype 1 uses the de-facto standard language for Graph Database access -Gremlin  [9]. Gremlin is a functional, data-flow language for traversing a property graph. Every Gremlin traversal is composed of a sequence of (potentially nested) steps. A step performs an atomic operation on the data stream. Every step is either a map-step (transforming the objects in the stream), a filter-step (removing objects from the stream), or a side-effect-step (computing statistics about the stream).
Gremlin supports transactional and non-transactional processing in a declarative or imperative manner. Gremlin can be expressed in all languages supporting function composition and nesting. Among supported languages are Java, Groovy, Scala, Python, Ruby and Go. Gremlin is generally used within the TinkerPop[10] framework and currently the leading implementation is JanusGraph. It supports several storage backends: Cassandra, HBase, Google Cloud and Oracle BerkeleyDB, several graph data analytics: Spark, Giraph and Hadoop and several search tools: Elasticsearch, Solr and Lucene. Gremlin, an API originated from Groovy language, uses functional syntax (with streams and Lambda calculus) and functional and navigational semantics. It is very intuitive, uses no special syntax and is easily integrated into existing frameworks.
Database data are simply accessed as objects with structure, relations and nested collections with links. Following examples show some capabilities of the Gremlin code: 1 # add a v e r t e x ' e x p e r i m e n t ' w i t h t h e name ' ATLAS '. h a s ( ' ename ' , 'ATLAS ' ) ) 9 # show d a t a s e t s w i t h more e v e n t s o r number o f e v e n t s i n an i n t e r v a l 10 g. V ( ). h a s ( ' r u n ' , ' number ' , 3 5 8 0 3 1 ).
11. o u t ( ) 12. h a s ( ' n e v e n t s ' , g t ( 7 1 8 0 1 3 6 ) ) 13. v a l u e s ( ' name ' , ' n e v e n t s ' ) The aim of this prototype is to use simple and flexible NoSQL storage, be compatible with other SQL databases used in ATLAS and to take advantages of Graph Database environment. This has been achieved by extending Phoenix [18] SQL interface (backed by HBase storage) with an additional pure HBase database. This way, we can keep Phoenix advantages (speed, SQL interface) for read-only data, while opening new possibilities and adaptability to changing environment. Phoenix is used for static data and HBase for dynamic data. Bulk data are stored in a pure HBase table with the Phoenix SQL API, graph structure is added via another HBase table. A subset of the Gremlin interface has been implemented for the graph part of the storage.
The graph structure is created on the top of an SQL database -a user sees just one database. Both databases share the same keys. All data of one key is represented by one Element (a generic class). The Graph HBase database is much smaller as it contains only subset of data. It can contain • Simple Tags which can be also used in a search filter. • Extensions by any object, like trigger statistics and overlap or duplicated events list. • Relations to other elements (i. e. the Graph Database). HBase can also contain elements without a Phoenix partner: Hubs. They represent virtual collections of Elements, like external tags, stream names, run numbers or project names. Hubs can be extended and searched in the same way as other elements. A schema of this prototype database is shown in Figure  1.
Web Service Generic web service graphical visualization has been implemented completely in JavaScript so it doesn't require any server-side code. It can display any Gremlin-compatible database, it works with both Prototypes. The Gremlin server delivers a JSON view of data to the Web Service. Direct API and REST web service are also available. The web service graphics uses a hierarchical zooming navigation. It can show all available data, their relations and properties and all available actions for them (see Figure  2 ).
Value-add and New Possibilities Storing HEP data in a Graph Database can make the exeriment frameworks more flexible, readable, stable and performant. A big part of the application code is absorbed in the Graph Database structure. Implementation and optimization details are delegated to a suitable database engine. The database carries information about the data structure which would otherwise have to be handled by the application code. A user can use the system via a simple graphical access web service. A JavaScript client connects directly to Gremlin server. Standards are used, so components can be replaced. For example, a prototyping work has been done using simpler Cassandra[12] database. Virtual entities can be created, including virtual collections (whiteboard functionality), either personal or official.