dataesr/scientific-paragraphs-categorization huggingface dataset:
Internal threats to validity Query Selection The queries used in the benchmark are artificial. They have been created by the first author in such a way that they would represent typical queries. The design goal of the second query in particular was to include some kind of graph algorithm in order to evaluate the flexibility of the tools on a concrete example. We chose the calculation of connected components because it is a well-studied algorithm and was applicable for the chosen scenario. Technologies There is a difference of the used languages, runtimes and technologies because the solutions use different modelling approaches. Therefore, differences in response times may be due to the difference of the used framework instead of the difference in the used incremental tool. Clearing this effect from the measurements would necessitate re-implementing both the solutions and the underlying tools (in many cases large libraries or even database management systems) in another technology stack, an overhead which is not justified by this confounding effect.
This approach rests on the assumption that the data processed by the attribute grammar are immutable. As Reps applies this technique for parse trees, this assumption is reasonable, but it does not hold for models in general. The JastAdd tool in our comparison uses this technology. Pugh and Teitelbaum  [73]  then applied memoization to incremental computation. Memoization is applicable to any referential transparent function (such as getting references to the three topmost elements of Q1 or Q2 is) but rests on the assumption that the data structures it operates on are immutable-an assumption not met with models. Immutable data structures cannot represent cyclic data structures natively and therefore make it difficult to create analyses requiring them. In the Social Media benchmark, we have various cross-references between Users to represent their friends.
31 We therefore could not take these approaches into account. A popular approach to specify queries, especially in graph transformation, is Graph Patterns. Bergmann et al. have created IncQuery, an incremental pattern matching system for Graph Patterns  [10, 11]. This approach uses a Rete network  [32] , a static dependency graph, whose nodes are primitive filter conditions or joins of partial pattern matches. Each node represents a set of (partial) pattern matches. This approach can support mutable models because the notification API of models can be used to determine when matches must be revoked or new matches arise. In relational databases research, incrementalization manifests in the topic of incremental view maintenance  [14]. An overview on the research can be found in  [24, 39, 79].
Only the GraphBLAS solution without the performance penalty of a modelling framework was faster, but it required the developer to rephrase the problem with matrix multiplications and explicitly deal with incrementality. This is complex, errorprone and hence expensive to develop even for such simple queries. Further, it is in contrast to the implicit solutions, in particular when their front-end language matches common standards such as OCL, EOL, SQO or Java Collections queries. The performance results demonstrate how the explicitly incrementalized solutions, which use dependency structures on a much coarser granularity, save only few intermediate results and are slower on average than the implicitly incrementalized solutions. This is because every type of change requires dedicated code to update intermediate results.
Sect. 4. 4) or currently cannot (yet?) catch up with dedicated solutions where the queries have been explicitly designed for change propagation, even when being slightly bent towards the specific problem (the incremental query version of Hawk). The explicitly incrementalized durable solutions in SQL and Neo4j are more difficult to understand but are performant, making it an interesting future research topic to generalize these kind of solutions and hide their complexity behind a high-level frontend language. For relational databases, the lack of an out-of-the-box solution for incrementalization is particularly surprising, given the huge body of research in incremental view maintenance  [24, 39]. Their advantage in the scope of this benchmark would have been clear as the incremental SQL solution is much harder to understand than its batch counterpart.
However, these ideas did not yet make their way into the common or open-source database management systems. How much development effort will be necessary to implement change propagation? Of course, the development effort to implement change propagation heavily depends on the tool and how experienced the developer is with the tool. Because the solutions in this benchmark have been developed by different authors, we did not even attempt to collect data about the development effort necessary. However, the discussion in Sect. 4. 3 shows that the magnitude of development effort is quite different for the tools, in particular depending on whether the incrementalization happens implicitly or requires explicit implementation. While for JastAdd and YAMTL (in the implicitly incremental solution), no changes are necessary at all and tools like NMF or AOF only require to implement extensions (which can be shared among multiple projects, so that maybe one day comprehensive libraries exist), other tools such as in particular GraphBLAS, Neo4j and SQL require a completely different approach for supporting incremental change propagation.
4. 5. The results show that while the parallelism for GraphBLAS and Differential Dataflow does bring performance advantages, these are not present (yet?) for NMF or YAMTL. Is the tool extensible [. ]? When originally selecting the queries for the benchmark, we expected that the calculation of connected components could not be handled natively by any approach so that solutions had to prove the extensibility of the tools. However, although this strategy has worked for a number of tools, it has not worked for all of them as some tools (Differential Dataflow, JastAdd to some degree) could indeed handle also Q2 without an extension of the tool. For the database solutions, algorithms such as calculating connected components usually have to be developed from scratch, using relational algebra.
Future work We have future plans to extend the Social Media benchmark, both by covering more tools and algorithms in our experiments as well as by making the benchmark more challenging. To cover more techniques, we plan to include modelling tools such as Viatra  [85] , relational databases which support intra-query parallelism such as the DuckDB embeddable analytical database  [74] , and make use of recently developed connected components algorithms  [15]. Finally, we plan to incorporate change sequences that include deletions  [87]  which is expected to make it more challenging to perform the incremental maintenance of the queries and the connected components algorithm. -Figure  14  contains the proof for the relational algebra formula for the join of relations with a positive delta (change set).
Acknowledgements We would like to thank  Frank McSherry  for providing an initial implementation of the Differential Dataflow solution. René Schöne was supported by  German Federal Ministry of Education and Research  within the  research project  " OpenLicht". Márton Elekes 's research was funded by the  European Commission  and the  Hungarian Authorities (NKFIH)  through the  Arrowhead Tools project (EU Grant  Agreement No. 826452 ,  NKFIH  Grant  2019-2. 1. 3-NEMZECSEL-2019-00003 ) and by the  NRDI Fund  based on the charter of bolster issued by the  NRDI Office  under the auspices of the  Ministry for Innovation and Technology. Gábor Szárnyas  was partially supported by the SQIREL-GRAPHS  NWO  project.
| Data acquisition Patients were scanned at admission (DWI, 1. 5 T, General Electric scanner) as well as 2 to 5 days after stroke onset (functional scans, 3. 0 T, Siemens Skyra scanner). We here relied on diffusion weighted images (DWI) and rsfMRI data with the following parameters: DWI: echo-planar imaging, number of slices: 28; slice thickness: 5 mm; repetition time (TR): 5500 ms; echo time (TE): 99 ms; in-plane resolution: 1. 375 mm, and rsfMRI (6 mins): gradient-echo planar imaging (EPI) sequence, 150 volumes, number of slices: 42 (interleaved); slice thickness: 3. 51 mm; matrix size: 64 × 64; flip angle: 90 ; repetition time (TR): 2400 ms; in-plane resolution: 3. 437 mm.
| Preprocessing of rsfMRI data Preprocessing of the rsfMRI data was conducted using MATLAB (Version R2019b, MathWorks, Inc. , Natick, MA) and the Statistical Parametric Mapping software package (SPM12, Wellcome Trust Centre for Neuroimaging, London, UK; www. fil. ion. ucl. ac. uk/spm). After removal of the first three images ("dummy images") to ensure a steady BOLD-signal, the remaining 147 volumes were head movementcorrected through affine realignment to each scan's mean image. Diffusion-weighted images, as well as corresponding lesion masks were linearly co-registered to the same functional mean image (c. f. , lesion overlap, Figure  S1 ). All volumes were then non-linearly spatially normalized employing the "unified segmentation" option with masked lesions (i. e. , setting lesioned tissue areas to values of zero to reduce lesion-caused spatial distortions during the normalization step,  Ashburner & Friston, 2005; Brett, Leff, Rorden, & Ashburner, 2001).
| Data and code availability statement The authors agree to make the data available to any researcher for the express purposes of reproducing the here presented results and with the explicit permission for data sharing by the local institutional review board. Preprocessing of data and dFNC were computed in Matlab2019a (The Mathworks, Natick, MA) and used adjusted F I G U R E 1 Spatial maps of 49 intrinsic connectivity networks of all ischemic stroke subjects (n = 41). Networks were assigned to seven functional domains: Subcortical (SC, 3 networks, light blue), auditory (AUD, 3 networks, blue), cortical sensorimotor (SMN, 8 networks, dark blue), visual (VIS, 10 networks, yellow), cognitive control (CC, 14 networks, orange), default mode network (DMN, 9 networks, brown), cerebellar domain (CB, 3 networks, moccasin) template scripts from the GIFT toolbox (https://trendscenter.
org/ software/gift/). Additional computations were run in Python3. 7, particularly relying on the package pymc3  (Salvatier, Wiecki, & Fonnesbeck, 2016)  and rapidtide  (Erdo gan, Tong, Hocke, Lindsey, & deB Frederick, 2016). Relevant jupyter notebooks can be found here: https://github. com/AnnaBonkhoff/DFNC_AIS_recovery.
Furthermore, our dataset is comparable in size with prior dynamic functional connectivity studies in the first few days after stroke  (Hu et al. , 2018:  19 patients;  Bonkhoff, Espinoza, et al. , 2020: 31 patients; Bonkhoff, Rehme, et al. , 2020: 54 patients). Notably, one of our main findings, that is, favored transiently increased segregation in case of a high stroke severity, is well in line with previous reports of increased transition likelihood to segregated states in case of severe motor impairments  (Bonkhoff, Espinoza, et al. , 2020). Altogether, this agreement demonstrates the overall robustness of results for these kinds of dataset sizes. The reliability of dynamic analyses may be comparatively inferior to the one of static functional analyses  (Zhang, Baum, Adduru, Biswal, & Michael, 2018)  and it was suggested to increase the duration of scans beyond 10 min to allow for the exploration of all aspects of dynamic connectivity alterations  (Hutchison et al.
Multifaceted diversity We measured richness as the number of observed bird species per sampling point. We also calculated alpha diversity with the Shannon index  (Hill 1973). We determined the functional diversity by combining the relative bird abundance data with six biological traits describing habitat specialization, nest site, migratory status, diet level, body mass, and clutch size (see Table  A1. 1). These traits are generally related to species' habitat selection, resource requirements, or reproduction. For example, body mass is related with home range/territory size. Habitat specialization was counted as the number of habitat types the species is known to occupy (nesting, forage, roost, etc. ), which was obtained from https://www. iucnredlist. org/; lower value indicates higher habitat specificity.
Averaged body mass (g) was obtained from https://birdsoftheworld. org/, https://avibase. bsceoc. org, andhttps://animaldiversity. org/. Other data (e. g. ,  Wang et al. 2018)  were also considered when compiling bird trait information (see Table  A1. 1). Based on these functional traits, we computed abundanceweighted functional diversity, using the metric "FD" developed by  Petchey and Gaston (2002). First, we calculated Gower's distances between species based on a functional traits matrix, which is a measure of the similarity of species that can cope with mixed trait data  (Podani and Schmera 2006). Second, we converted the distance matrix into a dendrogram using the unweighted pair group averaging (UPGMA) clustering algorithm, as it yielded a dendrogram with the highest cophenetic correlation with our original distance matrices and has also been identified to perform best in most cases  (Podani and Schmera 2006).
To perform CCA, we used "vegan" R package  (Oksanen et al. 2013 ) in R3. 6. 2 (R Development Core Team 2019). We checked the Pearson correlation coefficient among diversity measures to see whether the standard effective size of functional diversity (sesFD) and phylogenetic diversity (sesPD) are truly independent of species richness. We then fitted Bayesian generalized additive models implemented in the R package "brms"  (Bürkner 2017 ) to analyze the habitat-diversity relationships. We developed a global model that included main effects for all local and landscape habitat attributes that were retained after VIF analysis, and included a smooth function of land cover richness, a habitat fragmentation measure, to test intermediate disturbance hypothesis. To run the GAM, we used the following formula: Diversity metrics = plant richness + plant canopy + grass height + s(land cover richness) + bare land percentage + grassland percentage + forest percentage + impervious percentage.
We considered parameters and responses ecologically meaningful if the 90% HDI did not overlap 0. Additionally, we tested spatial autocorrelation of species richness and Shannon diversity using global Moran's I (Table  A1. 2) in the "lctools" R package  (Kalogirou 2016). We further assessed spatial autocorrelation in the posterior means of the residuals of each Bayesian model by typical Q-Q plots (Fig. A1. 2). We conclude that our model outputs were robust to spatial autocorrelation effects.
DISCUSSION In the present study, we examined the overall response of bird assemblages to local and landscape-scale habitat features, and identified the key habitat attributes that drive taxonomic, functional, and phylogenetic diversity of bird communities in Inner Mongolia, using a dataset comprising a large number of sampling sites. Several past studies on biodiversity issues either concentrate on single diversity index, e. g. , species richness, or solely evaluate the local-scale habitat effects in Inner Mongolia (e. g. ,  Wen et al. 2002 , Liang et al. 2018 , but see  Liang et al. 2019). Our study advances these works by pointing to clear differences in bird composition along habitat gradients, and revealing that relationships between habitat variables and avian diversity are scale-dependent and metric-specific.
2017). In comparison to taxonomic and phylogenetic diversity, functional diversity was not significantly related to any of the local and landscape attributes. Several reasons may explain the weak and insignificant response of the FD indices. First, the data we originally collected for studying taxonomic diversity could be insufficient for capturing FD, as for most empirical datasets, a much higher sampling effort is generally required to reach an adequate precision for FD measurements than for taxonomical diversity measurements (van der Plas et al. 2017). Second, the low variation in Shannon diversity between sites may contribute to a high probability of sensitivity in functional diversity, i. e. , making FD sensitive to methodological choices such as distance measure or clustering algorithm  (Poos et al.
Processing and scientific analysis of the data taken by the ATLAS experiment requires reliable information describing the event data recorded by the detector or generated in software. ATLAS event processing applications store such descriptive metadata information in the output data files along with the event information. To better leverage the available computing resources during LHC Run3 the AT-LAS experiment has migrated its data processing and analysis software to a multi-threaded framework: AthenaMT. Therefore in-file metadata must support concurrent event processing, especially around input file boundaries. The in-file metadata handling software was originally designed for serial event processing. It grew into a rather complex system over the many years of ATLAS operation. To migrate this system to the multi-threaded environment it was necessary to adopt several pragmatic solutions, mainly because of the shortage of available person-power to work on this project in early phases of the AthenaMT development.
Introduction Modern particle physics experiments produce a variety of data required to perform physical measurements. The elementary measurement of the ATLAS detector  [1]  is an event: the detector response to a collision at its center. The event may be the physical response of the detector to a collision delivered by the Large Hadron Collider or the simulated detector Table  1. The ATLAS in-file metadata may be separated into ten categories. Each category uses one shared object to contain information. Multiple instances of such objects may and often do exist. Each category is managed by a dedicated component. Event generator and detector simulation information response to collision generated by software. To process and analyze these events a wealth of information describing the data is required.
Category The content and management of in-file metadata in the ATLAS experiment was developed organically over many years. That is, in response to the needs of the ATLAS event data model, software framework, and physics analyses. As the effort of the ATLAS collaboration to produce thread safe production software, AthenaMT  [3, 4] , resulted in mature code it became clear that the in-file metadata infrastructure required improvement. A pragmatic approach was chosen to support thread safe operation in a timely manner. The process is described in Section 3. As the reader will note in Section 2, the same information often exists in many different in-file metadata objects. While this provides convenient access, it makes the in-file metadata system difficult to maintain. The interval of validity (IOV) metadata described in Section 2.
Interval of Validity Most of the in-file metadata categories listed in Table  1  represent metadata with fixed values that are valid for a given file. The interval of validity category represents metadata with values that may change with time and are not constrained by file boundaries  [8]. A time period when a given metadata object has known and unchanging attribute values defines a single IOV for this object. An object may have any number of such intervals. IOV metadata format is used in ATLAS primarily to describe detector conditions stored in relational databases. This data is retrieved by jobs over database connections. The in-file implementation of the IOV format permits Athena to store IOV metadata also in files. This allows workflows without access to the external database to access these objects from the file instead of the database.
The expected number of events per luminosity block is read by the event processing application from the ATLAS Conditions Database. In the Athena framework there are two components which manage Luminosity Block metadata. One of these components is an Algorithm which reads the expected number of events per luminosity block from the conditions database at initialization. During event processing this algorithm simply counts events within lumi-blocks and, at the end of the job, writes the collected information into the output file metadata. Another Athena component, an AlgTool, is simply propagating luminosity block metadata from input into the output file. If a job runs over multiple input files, then their corresponding metadata information is merged by the AlgTool prior to writing to the output metadata.
File information The FileMetaData stores information as a set of key value pairs. Keys are strings and values may be integers, strings or floating point numbers. The FileMetaData object stores a summary of properties shared by all events in the file, for example: the beam energy, detector geometry used in reconstruction, or the software release used to produce the file. The file metadata is stored in a format allowing access using ROOT, without the bulk of the ATLAS production software. The summary information is built by using the event information, taking the first set of values encountered in a job. Changes in a value throughout the job are ignored. This greatly simplifies the object. The simplification is justified by the observation that in the ATLAS production workflows all the values stored in the file metadata object are constant throughout a job.
Development An in-depth review and rewrite of the ATLAS metadata content and infrastructure is well motivated but beyond the scope of this contribution. The development described here is limited to pragmatic solutions because person-power to take responsibility of the metadata system was found late in the AthenaMT development cycle. Figure  1  is a diagram of a multi-threaded job processing multiple input files. It highlights the challenge for the in-file metadata infrastructure: ensure that events from multiple input files, which are processed concurrently, have access to appropriate in-file metadata. To meet this requirement we first attempt to reduce the problem by cleaning up obsolete code and removing as many clients as reasonable. After the clean-up we reduce the dependence on thread-unsafe constructs to a necessary minimum.
Thread-unsafe constructs The most prominent construct that is dangerous in multi-threaded processing are incidents. Incidents are events managed by a service which receives notifications from an emitting client. The service then broadcasts the emitted incident to all registered listeners. Both emitters and listeners may run on multiple concurrent threads, so incidents must be handled with care. We reduced our reliance on incidents to a necessary minimum: the opening of a new file is signaled by the BeginInputFile incident, the end of an input file be the EndInputFile incident. The writing out of the metadata to the output stream is initiated on the MetaDataStop incident. In the current design the ATLAS software these incidents may be assumed to occur sequentially, as indicated by Figure  1.
IOVDbMetaDataTool uses the same lock in exclusive mode to perform any IOV metadata updates. Access locking is implemented for metadata on a per-tool basis and not for all of the metadata to avoid unnecessary serialization of longer operations like writing. During event processing, in-file IOV metadata is still read by the IOVDbSvc -although now all interactions between IOVDbSvc and the "MetaDataStore" go through the new, threadsafe API of IOVDbMetaDataTool. During the migration to AthenaMT, the role of the IOVSvc, controlling the validity of conditions data used in the event processing, was to a large extent taken over by the new condition handles and algorithms  [10]. We foresee an integration of the in-file IOV metadata handling with the new Conditions infrastructure in the near future.