dataesr/scientific-paragraphs-categorization huggingface dataset:
2016)  or complete. Thus, even in the manual check, which we used as a gold standard, the standards of data provision were set very low. Indeed, while we could not quantify the fraction of reported findings for which raw data had been shared, providing the data underlying all results was surely rather exception than norm. Similarly, standards of machine-readability and documentation in our Open Data sample clearly fell short of multiple FAIR criteria for most datasets, even though this was not systematically assessed. Thus, Open Data sharing rates reported here will not be comparable with those detected applying more stringent criteria of completeness and reusability, which would be recommendable to do as Open Data sharing becomes more common and standardized. For the detection of Open Code, one obstacle is that the standardization of Open Code statements is still lower than for Open Data (e.
Outlook How Open Data is deposited and linked will change over time, with new data repositories emerging and changing file formats. Thus, the algorithm needs to be adapted in the future to keep up with these developments. One possibility would be to update all repositories listed in e. g. re3data. org and FAIRsharing. org automatically to keep the algorithm up to date regarding available repositories. However, ODDPub was developed given the current landscape of Open Data, in which solutions for reusable Open Data sharing and standardized, automated detection of the datasets are already present, but have not yet been universally adopted. These include in particular (i) sharing of datasets through repositories rather than as supplementary materials, leading to both easier findability and citation as independent research outputs (ii) adoption of the Joint Declaration of Data Citation Principles  (Martone 2014) , leading to datasets being cited in the reference list (iii) the inclusion of data availability statements in journal articles, which can clarify, which of the cited datasets are primary data, created or collected by the authors Another relevant point concerning the citation of datasets in the future is the distinction between citations of newly generated datasets and of re-used datasets.
Acknowledgements We thank  Meggie Danziger ,  Maxim Benz ,  Claudia Kirchert  and especially  Yasmin Aktas  for their help with the manual screening of publications. Additionally, we thank  Lisa Liebenau ,  Florian Beng  and  Clemens Blümel  for the helpful discussions in the early conceptual phase of this project. Finally, we thank  Benjamin Gregory Carlisle  and  Ulrich Dirnagl  for their helpful comments on our manuscript.
Data Accessibility Statement The ODDPub algorithm is available as R package on GitHub (https://doi. org/10. 5281/zenodo. 4071699, RRID:SCR_018385) under the MIT license. A dataset containing information on the publications used in the training and validation datasets, including the publication DOIs, the results of the manual screening and the extracted Open Data statements can be found under https://doi. org/10. 17605/OSF. IO/YV5RX.
This lysosome-driven ER redistribution is not only important in ER reshaping, but also facilitate to maintain the continuity of ER in developing axons. A recent study has shown that defects in ER-endosome contacts are associated with HSPs  (26). In developing RGCs, KD/MD mutants of VAPA, which are incapable of binding to lysosomes, led to persistent ER fragmentation and axonal growth defects, suggesting an important role of lysosomes in maintaining ER continuity during neuronal development. Therefore, this leads to intriguing perspectives in the context of disorders that are primarily linked to ER network defects  (2, 27). In the future, it will be interesting to study how the lysosome-driven ER dynamics could contribute to the axonal growth and neuronal development. For (D-F), data were collected from 175 events of lysosome-coupled ER motions and 306 events of ER only motions in 39 cells from 3 independent experiments.
Growing tip and three-way junction analysis Growing tips and three-way junctions were determined from customer-built algorism. The input to the program is a skeletonized binary image of ER. The skeleton was created in ImageJ by applying a threshold to create a binary image, followed by the built-in 'skeletonize' function to reduce the width of ER tubules to 1 pixel. This results in a network graph of the ER, with connections, nodes, and end points. These three features were labelled using MATLAB's connected components functions. The length of connections was also calculated by fitting splines to the binary tubules and recording the length of the spline. The analysis occurs across a time series of the ER network, allowing results to be drawn about the distribution of tubule length over time, for example.
Single particle tracking COS-7 cells expressing EGFP-VAPA (ER marker) and stained with SiR-Lysosome (lysosome marker) were imaged by SIM every 1. 5 s (including imaging exposure time of SiR-Lysosome channel) for 12. 5 min (500 frames). EGFP-VAPA and SiR-Lysosome channels were imaged before and after the recording of lysosome motions, which recorded the morphology of ER. Tracking of lysosome motions was performed by TrackMate  (33)  in Fiji, which plots the trajectories (2094 tracks) of lysosome motions in 500 frames. Data from SPT allowed us to reconstruct the lysosome motion density. The high-density regions were extracted from the trajectories using a procedure derived from (34): the number of points falling into square bins of width ∆x = 480 nm was counted to construct the density map. From this map, high-density regions, called seeds, were defined as the fraction with 5% higher-density bins.
These partially hand-drawn segmentation maps then served as targets, i. e. ground truths, in the supervised training of the segmentation network. To make it feasible for the network to learn to segment the ER images from the relatively small training dataset, a few means of data augmentation were used. Firstly, each segmentation training pair was randomly cropped many times, which shifts the structures from frame to frame and brings the image size down to a manageable size for a graphics card (256x256 pixels). This provides a few hundred subimages of different regions of the segmentation examples. Those subimages were then randomly flipped (horizontally and vertically) and rotated (by 90 or 180 degrees) to obtain more training data. Other ways to augment data could have been to randomly change brightness or synthetically add noise to images, but this was not found to be necessary.
Training was done in batches of 5 images (each being 256x256 pixels) with a learning rate of 0. 001 using the Adam optimisation method for a total of 40 epochs. The learning rate was halved after every 10 epochs. The network was conFigd to have 4 blocks, of the RCAB, which amounts to 40 convolution layers each having 64 filters with a 3x3 kernel size, constituting a total of about 1. 3 million trainable parameters. The trained network outputs binary segmentation maps that can then easily be skeletonised by a standard thinning algorithm  (46). The implementation has been made with the machine learning library Pytorch. The code as well as training and test data for segmenting endoplasmic reticulum images is freely available at https://github. com/charlesnchr/ERNet.
This is achieved during model training by minimising an appropriate loss function, typically the mean squared error defined over the dataset as Rather than having the model perform restoration via regression followed by thresholding by intensity values to produce binary segmentation maps, the model is directly optimised to output segmentation maps by modifying it to perform classification. A common choice of loss function for classification models is the cross-entropy loss given by where  and  are iterators over a total of  unique classes, and  ; ,  () is a function equal to 1 if the target class for the pixel at (, ) of the  th image is , and otherwise it is equal to 0. With the model set up for classification, the network (⋅) now returns scores for each class for a given input image, from which class probabilities are estimated by applying the softmax function, i.
Acknowledgements We thank  Dr Ana Isabel Fernández Villegas ,  Lucia Wunderlich  and  Wei Li  for helping with the cell culture. We thank  Dr Edward Ward  for helping with the image processing. This research was funded by  Infinitus (China) Company Ltd ; C. F. K. acknowledges funding from the  Wellcome Trust , the  UK Medical Research Council (MRC) , and  Alzheimer Research UK (ARUK). E. A. is supported by the  UK Dementia Research Institute  which receives its funding from  UK DRI Ltd , funded by the  UK Medical Research Council, Alzheimer's Society and Alzheimer's Research UK. W. N. and L. C. K. acknowledges funding from the  Netherlands Organization for Scientific Research (NWO)  and the  European Research Council (ERC) , respectively.
Since the network is capable of restoration, it is not necessary to 1 𝑁 ∑ ( 1 ∑ ∑[𝐹(Θ; 𝐼 𝑖 𝐿 ) 𝑥,𝑦 -𝐼 𝑖; 𝑥,𝑦 𝐻 ] 2 𝐻 𝑊 ) 𝑁 explicitly remove noise (denoise) images prior to inputting them to the model. However, to , alleviate the complexity of training the network, raw images were first denoised using the 𝑊𝐻 𝑦=1 𝑥=1 𝑖=1 denoising method ND-SAFIR (45) which includes a noise parameter estimation of Poisson- where Θ represents the trainable parameters of the network referred to as 𝐹(⋅), while 𝐷 is the Gaussian noise that is typical for optical microscopy. training dataset of size 𝑁 written as {𝐼 𝑖 𝐿 , 𝐼 𝑖 𝐻 } 𝑖=1 𝑁 consisting of low-quality input images and high- quality target images with pixel size 𝐻 × 𝑊.
The abundance of interconnected data has fueled the design and implementation of graph generators reproducing real-world linking properties, or gauging the effectiveness of graph algorithms, techniques and applications manipulating these data. We consider graph generation across multiple subfields, such as Semantic Web, graph databases, social networks, and community detection, along with general graphs. Despite the disparate requirements of modern graph generators throughout these communities, we analyze them under a common umbrella, reaching out the functionalities, the practical usage, and their supported operations. We argue that this classification is serving the need of providing scientists, researchers and practitioners with the right data generator at hand for their work. This survey provides a comprehensive overview of the state-of-the-art graph generators by focusing on those that are pertinent and suitable for several data-intensive tasks.
2016]. In this survey, we provide a detailed overview of the state-of-the-art modern graph generators by focusing on those that are pertinent and suitable for data-intensive tasks and benchmarking context. Our aim is to cover a wide range of currently popular areas of graph data processing. In particular, we consider graph generation in the areas of Semantic Web, graph databases, social networks, and community detection, along with general graphs. Despite the disparate requirements of modern graph generators throughout these communities, we analyze them under a common umbrella, reaching out the functionalities, the practical usage, and the supported operations of graph generators. The reasons for this scope and classification are as follows: (1) Despite the differences of the covered areas, the requirements for modern graph data generators can be similar in particular cases.
In particular, we cover Semantic Web, graph databases, social networks, and community detection, along with general graphs. However, the literature is still lacking a comprehensive study of graph generators for many of the specific subfields mentioned above. A limited subset of graph database generators, parallel and distributed graph processing generators, along with a few of the Semantic Web data generators presented in our survey have been discussed in a related book chapter  [Bonifati et al. 2018a ] while cross-comparing them with respect to input, output, supported workload, data model and query language, along with the distinguished chokepoints. However, the provided classification is inherently database-oriented. In our work, we provide a more comprehensive and broader classification that serves the purpose of letting any researcher or practitioner interested in data generation to be able to make a better choice of the desired graph generator based on its functional and goal-driven features (such as the application domain, the supported operations, and the key configuration options).
Moreover, in contrast with  [Bonifati et al. 2018a ], our work encompasses graph generators of several diverse communities, not limiting its scope to a few generators of the database and graph processing communities. Graph generators matching graph patterns used in data mining have been studied in  [Chakrabarti and Faloutsos 2006] , focusing on mostly occurring patterns, such as power laws, size of graph diameters, and community structure. The considered graph generators are compared in terms of graph type, degree distributions, exponentiality, diameter, and community effects. We refer the reader to this survey for taxonomies involving these properties, whereas we provide here a functionality-driven taxonomy across all the categories of graph generators that we consider. We also point out that this survey is outdated as it does not consider the generators that appeared in the last decade.
Classification At first we classify the generators on the basis of the respective application domains or user communities. In particular we distinguish (1) general graphs, (2) Semantic Web, (3) graph databases, (4) social networks, and (5) community detection. The selected classes are not rigorously defined (e. g. , they are not disjoint as we will show later), but they correspond to the currently most active research areas. Thus we believe that they form a natural first acquaintance for the reader. In Table  I  we overview the key characteristics of the data generators clustered according to the respective application domains. 3 In particular, we show: -Characteristics of the domain: -its type (column "Type"), i. e. , fixed, specified using a schema, or extracted from input data, and -the particular target domain, or, in case of a generic tool, the chosen sample domain (column "Target/sample").
Number of Generators, Size and Output Format of the Data. As we can see, the biggest set of available generators can be found in the Semantic Web application domain, probably due to its recent popularity and a number of research groups dealing with this topic. None of these generators is natively implemented in a distributed manner and thus primarily generating output at the Big Data scale. On the other hand, the Linked Open Data (LOD) is expected to be large in general; however, this is the case of the whole LOD Cloud 4  , but not necessarily of the particular data sets forming it. The second large group of generators also corresponds to a popular application domain -social networks. In this case the size of the output graph is important if we require realistic features of the result. However, surprisingly many of the proposals do not provide an implementation at all and amongst the others there is a high percentage of those that are not highly scalable.
In case of the other application-specific domains the amount of generators is relatively small. As we will show in Section 2. 2, the situation is not so critical. Some of the application-specific generators can be re-used also in other application domains or the general graph generators can be used. Considering the output format of the data, as expected, the generators produce data in a standard format (e. g. , RDF) or in a reasonable graph-related form (e. g. , edge list). Domain. If we consider the features of the particular domain of the generators, in most cases it is expectably fixed, i. e. , it is pre-defined (describing, e. g. , a social network) and cannot be modified. It is the simplest option, but it does mean that the generator is simple too -it can still focus on other complex aspects of the output.
In some cases this aspect is more flexible -either query templates are used or the operations are generated, e. g. , in order to access most of the data in the generated graph. On the other hand, update operations are provided only in a small amount of cases. As we will discuss in Section 4. 6, the more general problem of evolving graphs is still an open issue. Configuration. A natural feature of the generators is to provide as realistic graphs as possible. Hence, most of them focus not only on the structure of the output graph, but also the properties. For the purpose of generating graphs with near real-world characteristics various distributions are used, such as power-law, Zipfian etc. Especially interesting are distributions extracted from real-wold data (such as, e. g. , Facebook in case of the social network domain).
Overlapping As we have mentioned, the basic classification of the generators that we have used in this paper is relatively vaguely based on the current application domains or research areas. In addition, some of the generators are either general, and thus can be used universally, or have features applicable in more than one domain/research area. So the classes we use can overlap, as depicted in Table  II. For example, many general or domain-agnostic graph generators, such as the preferential attachment  [Barabasi and Albert 1999]  or R-MAT, are typically used to test graph analytics frameworks when large real graphs are not available. Similarly, some social network graph generators such as LDBC SNB, S3G2 or LinkBench, can be used to test graph databases. In the case of the first two, even though they are designed not to be specific to any type of technology, the graph databases are their main target.
Additionally, they also provide serializers for RDF, thus they can also be used to test RDF systems. In the case of LinkBench, nothing prevents the user to load the generated graph in a (graph) database (e. g. , Facebook uses MySQL in  [Armstrong et al. 2013] ) to test a workload similar to Facebook and extend and complement it with more graph queries like those in LDBC SNB. Generators for community detection aim, in general, at creating graphs with a more realistic structure (graphs with communities of nodes where the density of edges is larger internally than externally). Even though these generators are, in general, used to test community detection algorithms (they generate also the expected communities in the graph), some studies also use them for general graph purposes or to test graph analytics algorithms besides community detection.
The generator has the following parameters: the number of nodes, the number of edges, and maximum weight of an edge. It outputs a list of tuples containing identifiers of vertices of an edge (with the direction from the first one to the second one) and weights (positive integers with a uniform random distribution) assigned to the edges of the multigraph. The algorithm of the generator is based on R-MAT. GraphGen. For the purpose of testing the scalability of an indexing technique called FG-index  [Cheng et al. 2007 ] on the size of the database of graphs, their average size and average density, the authors have also implemented a synthetic generator called GraphGen 5. It relies on data generation code for associations and sequential patterns provided by IBM 6. GraphGen yields a collection of undirected, labeled and connected graphs.
Semantic Web With the dawn of the concept of Linked Data it is a natural development that there would emerge respective benchmarks involving both synthetic data and data sets with real-world characteristics. The used data sets correspond to RDF representation of relational-like data  [Guo et al. 2005; Bizer and Schultz 2009] , social network-like data  [Schmidt et al. 2010] , or specific and significantly more complex data structures such as biological data  [Wu et al. 2014b]. In this section, we provide an overview of benchmarking systems involving a kind of graph-based RDF data generator or data modifier. LUBM. The use-case driven Lehigh University Benchmark (LUBM) 7 considers the university domain. The ontology defines 43 classes and 32 properties  [Guo et al. 2005 ]. In addition, 14 test queries are provided in the LUBM benchmark.
In particular, the benchmark focuses on extensional queries, i. e. , queries which target the particular data instances of the ontology, as an opposite to intentional queries, i. e. , queries which target properties and classes of the ontology. The Univ-Bench Artificial (UBA) data generator features repeatable and random data generation (exploiting classical linear congruential generator, LCG, of numbers). In particular, the data which is produced by the generator are assigned zero-based indexes (i. e. , University0, University1 etc. ), thus they are reproducible at any time with the same indexes. The generator naturally allows to specify a seed for random number generation, along with the starting index and the desired number of universities. An extension of LUBM, the Lehigh BibTeX Benchmark (LBBM)  [Wang et al.
2005 ], enables generating synthetic data for different ontologies. The data generation process is managed through two main phases: (1) the property-discovery phase, and (2) the data generation phase. LBBM provides a probabilistic model that can emulate the discovered properties of the data of a particular domain and generate synthetic data exhibiting similar properties. Synthetic data are generated using a Monte Carlo algorithm. The approach is demonstrated on the Lehigh University BibTeX ontology which consists of 28 classes along with 80 properties. The LUBM benchmark includes 12 test queries that were designed for the benchmark data. Another extension of LUBM, the University Ontology Benchmark (UOBM) 8 , focuses on two aspects: (1) usage of all constructs of OWL Lite and OWL DL  [W3C 2004 ] and (2) lack of necessary links between the generated data which thus form isolated graphs  [Ma et al.
The data are extracted from IMDb 10. The data generator corresponds to a data modifier which simulates differences between the data. In particular it involves data value differences (such as typographical errors or usage of different standard formats, e. g. , for names), 7 http://swat. cse. lehigh. edu/projects/lubm/ 8 https://www. cs. ox. ac. uk/isg/tools/UOBMGenerator/ 9 http://www. ics. forth. gr/isl/BenchmarksTutorial/ 10 http://www. imdb. com/ structural heterogeneity (represented by different levels of depth for properties, diverse aggregation criteria for properties, or missing values specification) and logical heterogeneity (such as, e. g. , instantiation on disjoint classes or various subclasses of the same superclass). BSBM. The Berlin SPARQL Benchmark (BSBM) 11 , is centered around an ecommerce application domain with object types such as Customer, Vendor, Product and Offer in addition to the relationship among them  [Bizer and Schultz 2009].
The benchmark provides a workload that has 12 queries with 2 types of query workloads (i. e. , 2 sequences of the 12 queries) emulating the navigation pattern and search of a consumer seeking a product. The data generator is capable of producing arbitrarily scalable datasets by controlling the number of products (n) as a scale factor. The scale factor also impacts other data characteristics, such as, e. g. , the depth of type hierarchy of products, branching factor, the number of product features, etc. BSBM can output two representations, i. e. an RDF representation along with a relational representation. Thus, BSBM also defines an SQL  [ISO 2008 ] representation of the queries. This allows comparison of SPARQL  [Prud'hommeaux and Seaborne 2008]  results to be compared against the performance of traditional RDBMSs.