dataesr/scientific-paragraphs-categorization huggingface dataset:
Bacterial distribution data Bacterial distributions in this study consisted of 2D point patterns (the x and y coordinates of individual cells) measured in images of soil thin sections (Fig. 1 ). We used 752 new or previously measured bacterial distributions taken from 94 soil thin sections sampled at different depths from a Scottish sandy loam (723 images,  [30] [31] [32] [33] ) and 2 soil thin sections of surface soil (20 cm below surface) a French sandy loam (29 images; Table  1 ). The Scottish samples were taken from topsoil (0-30 cm, sandy loam: 71% sand, 19% silt, 10% clay, pH H2O 6. 2, 1. 9% C and 0. 07% N) and subsoil (30-80 cm, sandy loam: 72% sand, 17% silt, 11% clay, pH H2O : 6. 5, 0. 68% C and 0. 02% N) of an arable soil. The French samples were taken from topsoil of an arable soil (0-30, loam: 47.
Discussion The distribution of bacteria in soils Unsurprisingly, the bacterial distributions measured in the 744 soil thin sections studied showed a high degree of aggregation at all depths, although aggregation was more frequent in the surface strata than in the subsoil. This corroborates similar observations by  [30]  on a sample of this dataset. We also found that bacterial distributions were isotropic at the millimetre scale. Although this was based on a limited number of observed distributions and would need to be confirmed on a larger dataset, such an observation is not surprising as the vertical gradients observed in soils generally occur at larger scales  [45, 46]. Log Gaussian Cox Processes (LGCP) were used to characterise the bacterial distributions and construct 3D distributions from these observations.
The second property is that, given the high variability in the number of neighbours around bacterial cells in our dataset (Table  1 ) and in our simulations (Fig  2  and 3 ), the density of interactions is highly variable in space, even at very fine scales, with some cells interacting with few others and other cells interacting with many more. For example, some filamentous bacteria or bacteria in colonies or biofilms are likely to have completely different interaction environments to those of isolated individual bacterial cells. Such localized ''pockets of interactions'' might have important consequences for ecosystem processes and microbial community evolutionary dynamics  [47]. The third property to emerge from this analysis, an obvious corollary of low levels of cell-to-cell interactions, is that the number of different species an individual cell interacts with is also limited.
ACKNOWLEDGMENTS This work was supported in part by  Gilead Sciences  (Grant  E1473. 0001 ). The sponsor was not involved in the study design, in the analysis of data, in the writing of the manuscript, and in the decision to submit. The authors thank the  ROCHE Foundation for Anemia Research (ROFAR)  for continuous support. They also thank  Guillaume Bonnot ,  Gaëtan Herbet ,  Florence Persat , and  Xavier Sansico  for animal studies or galactomannan dosages (IP2M, France).
The libNeuroML API provides a Python object model with a direct mapping to all NeuroML concepts defined by the NeuroML Schema, which facilitates reading and writing the XML equivalents. In addition, it offers a memory-efficient, array-based internal representation, which is useful for handling large-scale connectomics data. The libNeuroML API also includes support for performing common operations that are required when working with NeuroML documents. Access to the LEMS data model is provided by the PyLEMS API, which provides a Python implementation of the LEMS language, including the ability to simulate most models expressed in LEMS. Together, libNeuroML and PyLEMS provide a comprehensive solution for interacting with NeuroML models in a Python environment.
, 2012). One potential limitation of such a declarative model description language is that the commonly used format for serializing such models, XML, can be difficult to read and write and may be overly verbose, especially for large, complex models. There can be difficulties too when a model includes novel mechanisms that were not considered during the design of the description language or when constructing large, repetitive models, which can be expressed more tersely in a procedural language by means of recursions or loops. Here we describe libNeuroML and PyLEMS, which address these issues for the NeuroML and LEMS languages, respectively. A wide range of models, from point neurons to morphologically detailed, conductance based cell and network models, can be created, parsed, and saved using the libNeuroML API.
PyLEMS is a Python API for creating and working with models and model components specified directly in LEMS. While there are a number of Python applications for reading, modifying and writing XML such as lxml (http://lxml. de)-the advantage of libNeuroML and PyLEMS over these more generic tools is that they contain sub-tools and optimizations specific to the modeling of neural systems. Here we present a brief overview of the current state of NeuroML and LEMS, describe the motivation for developing procedural APIs for these languages, outline the design considerations for libNeuroML and PyLEMS, and provide a number of examples of the usage of these libraries. libNeuroML and PyLEMS allow a user to enjoy the benefits provided by the domain-specificity and rigor of NeuroML and LEMS, while facilitating the use of the Python programming language for procedural model descriptions.
libNeuroML AND PyLEMS To facilitate procedural model description development for the NeuroML and LEMS languages we have developed libNeuroML and PyLEMS. These Python modules can be imported into a Python script to allow loading of XML files in their respective formats, parsing and editing of the models using APIs which closely follow the structure of the XML languages, and saving in valid XML. libNeuroML, which parses and saves NeuroML v2, has added functionality to use optimized representations of large models, both internally and as serialization formats. PyLEMS has the additional ability to simulate the dynamical behavior of LEMS models. Figure  3  shows examples of XML from NeuroML and LEMS and the Python code that can be used to create the equivalent entities. More detailed overviews of the APIs for libNeuroML and PyLEMS are shown in Figures  4, 5 , respectively.
DESIGN GOALS SHARED BY BOTH libNeuroML AND PyLEMS Python naming conventions and adherence to Python PEP8 style guide libNeuroML and PyLEMS strongly adhere to naming conventions that are widely used in the Python community and codified in the PEP8 Style Guide for Python Code (http://www. python. org/dev/peps/pep-0008/). In the case of libNeuroML, this adherence to convention is enforced by automated conversion from NeuroML to Python naming conventions, which occurs during the automatic generation of the libNeuroML object model from the corresponding NeuroML Schema (see below). NeuroML elements have their names modified in the libNeuroML object model to use standard Python naming conventions; for instance, izhikevichCell (element) and q10Settings (attribute) in NeuroML become IzhikevichCell (class) and q10_settings (field), respectively in libNeuroML.
Automated XML validation libNeuroML provides a validation utility to ensure that NeuroML documents are well-formed (following the basic syntactic rules of XML) and valid (following the structure defined in the NeuroML Schema). A similar utility exists in PyLEMS for validating against the LEMS Schema. Note that while the NeuroML ComponentType definitions as well as XML generated by PyLEMS are valid according to this Schema, PyLEMS is flexible enough to parse invalid LEMS files (e. g. , with reordered elements) as long as they follow the correct containment rules for LEMS elements. Ease of installation libNeuroML and PyLEMS utilize the standard distutils (http:// docs. python. org/2/library/distutils. html) tool for packaging Python programs, making installation standard and simple. Both APIs require the lxml (http://lxml.
de) Python package. Additionally, libNeuroML requires numpy (http://www. numpy. org), jsonpickle (https://pypi. python. org/pypi/jsonpickle), mongodb (http://docs. mongodb. org/ecosystem/drivers/python), and PyTables (http://www. pytables. org) packages. Both APIs are currently tested and stable for Python versions 2. 6 and 2. 7. All of these packages can be obtained from the Python Package Index (https://pypi. python. org/pypi). The full source code for the libraries can be obtained from https://github. com/ NeuralEnsemble/libNeuroML and https://github. com/LEMS/ pylems.
Auto-generation from NeuroML Schema In libNeuroML every element (such as cell, network or pulseGenerator, see Figure  1A ) in the NeuroML Schema corresponds to a concrete class and therefore can be instantiated as an object by calling neuroml. <NameOfClass>(). This is is possible because the libNeuroML core object model is auto-generated from a NeuroML Schema file via the generateDS tool (https:// bitbucket. org/dkuhlman/generateds), where the generated object model defines all necessary type interfaces. Therefore, libNeu-roML provides a complete and direct mapping between the NeuroML Schema and its internal Python object model with several advantages: 1. Maintainability. libNeuroML can be rapidly updated to reflect the latest NeuroML Schema with little or no knowledge of implementation or architecture.
This allows libNeuroML to be a core part of the regular NeuroML release process. New versions of the NeuroML Schema will always be released along with a libNeuroML version which reflects those Schema changes. 2. Backward-support. This feature allows users to create a Python API for handling NeuroML even if they are working with older versions of the NeuroML representation format, including versions that existed before libNeuroML. However, the user must auto-generate this libNeuroML version via the generateDS tool as described in libNeuroML documentation. method names automatically are converted to Python naming conventions. One notable disadvantage of an auto-generated API is that it contains syntax which is less usable than it might be for a "hand-written" API. However, we have contributed updates to the generateDS tool to increase usability and readability of the API, and these will continue to be improved.
Serialization and database support This section describes the different serialization formats provided by libNeuroML. In this section the term NeuroML specifically refers to the XML-based file format rather than NeuroML as a model description language. libNeuroML supports serialization of models into four different storage formats: NeuroML (XML), JavaScript Object Notation (JSON) (http://www. json. org), HDF5 (http://www. hdfgroup. org/HDF5), and SWC  (Cannon et al. , 1999). Of these four serialization formats, two (NeuroML and JSON) are lossless, which is to say that they preserve all of the NeuroML model data, and the other two (HDF5 and SWC) are lossy and are only able to serialize a subset of the data, namely the morphological structure of detailed neuronal reconstructions. In the case of SWC however, the format is only suited to serializing a small subset of morphological data and is intrinsically unable to serialize complex models, due to the nature of the SWC format as described below.
NeuroML (XML). The de-facto libNeuroML serialization output is the standard XML-based format in which NeuroML models are written. Small to medium-sized NeuroML models generally should be written in this format, as these documents can be edited with standard text editors and validated against the NeuroML Schema independently of libNeuroML. The XML serialization is the format most widely supported by NeuroML compliant software tools (http://www. neuroml. org/ tool_support. php). It is recommended that unless there is a clear reason to do otherwise, users should use XML serialization until they encounter performance bottlenecks. NeuroML serialization, though the slowest and least concise, permits the use of NeuroML-compliant tools (such as morphology viewers) and the ability to easily track changes across file versions.
JSON. JSON is an open, text-based format for human-readable data interchange. Any file serialized by libNeuroML to JSON format can be loaded by libNeuroML without any loss of information and thus can be re-serialized as NeuroML. The jsonpickle (https://github. com/jsonpickle/jsonpickle) module is used to serialize NeuroML documents in JSON format. There are three primary advantages of JSON serialization: 1. Some users report that JSON is easier to read and understand than XML. 2. Many tools exist to facilitate the use of JSON in situations where data is transmitted over networks. This is particularly true for web-based applications since a number of such tools and frameworks are optimized for working with JSON. 3. When used in conjunction with the libNeuroML arraymorph module, large-scale morphological reconstructions require substantially less space on disk when stored as JSON-serialized documents.
SWC. SWC is a tree-based representation used for storing morphological reconstructions of neurons, and it is the data storage format of the NeuroMorpho. org database of reconstructed neurons  (Ascoli et al. , 2007). In SWC, each node contains diameter and position information, and the conical frustum between two nodes is treated as a segment of morphology. This allows, for instance, reconstructions of dendritic arborizations of theoretically-unlimited complexity. libNeuroML can import the Morphology component of a cell in SWC format. However, any other NeuroML component data such as information about the distribution of channels or synapses with regard to the morphology would be lost when serializing in this format.
OPTIMIZED INTERNAL REPRESENTATION (ARRAYMORPH) The arraymorph module of libNeuroML provides highly optimized representations of neuronal morphologies to increase read/write speed and reduce memory footprint. Neuronal morphologies are instantiated as a non-NeuroML ArrayMorphology type, which inherits from the standard NeuroML Morphology type but uses Numpy (http://www. numpy. org/) arrays to represent morphologies in a way that is transparent to the user and is highly-influenced by the SWC format. With the arraymorph module, it remains possible to manipulate NeuroML segment objects, and all helper methods and properties continue to work as with the standard NeuroML Morphology type. However, low-level access to the arrays is also possible, although the user must understand the internal details of implementation.
Simulation of LEMS models When defining a new language like LEMS, which aims to encapsulate a broad range of dynamical model descriptions, it is imperative to execute the models and test the results against expected behavior. This has been a core principle for the develoment of jLEMS (https://github. com/LEMS/jLEMS), a Java based reference implementation of LEMS developed in parallel with LEMS. A feature of LEMS is not considered stable by the design team unless an example can be executed with jLEMS. Like jLEMS, PyLEMS is not only an API for the language, but also can be used to simulate the dynamical behavior of the models it parses. While both jLEMS and PyLEMS feature only simple numerical integration techniques (forward Euler and additionally, in the case of jLEMS, Runge Kutta fourth-order), both implementations are required to produce the same model behavior for a given model specification.
TESTING, VALIDATION, AND CONTINUOUS INTEGRATION libNeuroML development follows modern software development practices, including a stable release cycle, version control, testing, and continuous integration. Each libNeuroML stable release is part of the official NeuroML release cycle. The git (http://git-scm. com) source code management system is used to provide version control management and is used in conjunction with GitHub (https://github. com) to provide issue tracking functionality as well as a central repository for developers. The package is tested using a variety of unit and integration tests, and the Travis-CI (https://travis-ci. org) continuous integration platform is used to confirm that libNeuroML is correctly installing and that all tests are passed every time a change is applied to the software and pushed to GitHub.
Network example libNeuroML can simplify the process of describing a model of a spiking neural network in NeuroML. All of the cell, synapse and channel models in NeuroML are available for use in networks, and the structure of a network can be generated in a procedural way, using all the capabilities of Python to encode the connectivity. Figure  7  shows a network of two randomly connected populations of integrate and fire neurons, one of which receives current injections of random magnitude. The structure of the network can be saved in XML format (or JSON format as outlined previously), but an important point is that many of the diverse network connectivity options available can not be described efficiently in NeuroML, and a Python script using libNeuroML provides a compact, cross-platform encoding of the network.
While the XML in the example in Figure  7  is roughly the same length as the associated Python script, generally this will not be the case for larger networks. Also, the XML represents only one instance of a network that can be generated by the script. Modifying the script to specify the random seed will ensure reproducibility of the network connectivity, and so the lib-NeuroML version of the network can be distributed instead of the potentially very large XML or JSON serialization. PyNN  (Davison et al. , 2009)  is an API in Python that also offers the advantage of compact, procedural network descriptions. Currently, the cell models that can be defined in PyNN scripts are limited to a set of commonly-used point neuron models on simulators with PyNN backends. As outlined in the Discussion section of this article, we are actively working toward greater compatibility between PyNN and network descriptions in libNeuroML.
Multicompartmental cells Aside from the ability to load and parse NeuroML documents containing morphological reconstructions of neurons, libNeuroML allows for the modification and analysis of these morphologies, as well as the generation of completely synthetic morphologies. Listing 1 shows an example of a script in lib-NeuroML which loads a morphology file from an XML representation, extracts the morphology and calculates the total volume and area of the segments in the cell. In this listing, volume and area methods do not have trailing parentheses because they are Python getter methods modified by the Python @property decorator. This demonstrates how helper methods can be used for operations that will commonly be required on those classes (e. g. , getting the surface area or volume of the conical frustum).
OpenWorm and neuroConstruct The OpenWorm project (http://www. openworm. org) is an international collaboration with the aim of creating a physically-and biologically-detailed computer model of a behaving multicellular organism, the nematode Caenorhabditis elegans. The nervous system of this worm contains only 302 neurons, making it a very interesting model organism in experimental and computational neuroscience. The morphology of each of these neurons (as well as all other cells of the adult hermaphrodite) has been reconstructed in 3D at the VirtualWorm project (http://caltech. wormbase. org/virtualworm) and released into the public domain in Blender (http://www. blender. org) format, which is used for the creation of 3D applications. These have been converted to NeuroML format for the OpenWorm project and made available at https://github.
com/openworm/CElegansNeuroML. Data on the connectivity between individual cells is available in a spreadsheet (CElegansNeuronTables. xls) in that repository and includes the numbers of known chemical or electrical connections between neurons of a particular type. We have developed a libNeuroML-based Python script to analyze the integrity of this data that loads each neuron morphology, generates connections based the connectivity data, and saves the network file to NeuroML. When generating connections for each pair of cells where there exist N connections, the script chooses a variable number (100-5000 depending on number of segments in the cells) of random points on the presynaptic and postsynaptic cells and chooses the N closest pairs of points for the connections. The generated network file can be loaded into neuroConstruct  (Gleeson et al.
PyLEMS EXAMPLE The NeuroML v2 ComponentType definitions specified in LEMS for multiple commonly-used cell, synapse and ion channel types (Figure  2 ) can be loaded by PyLEMS. Another important feature of using LEMS as the basis for NeuroML v2 model types is that a modeler can define a new model type in LEMS if that model is not already present in the core definitions, significantly increasing the extensibility of the NeuroML language. PyLEMS allows these new models to be created using Python and saved in a valid, standard format. Figure  9  shows the code required to define a Hindmarsh and Rose spiking cell model  (Hindmarsh and Rose, 1984)  and the behavior of one state variable when simulated with PyLEMS. More details on the implementation of this model can be found on the Open Source Brain website (http://www.
SUMMARY OF ADVANTAGES NeuroML is a model description language which can represent biological concepts such as cells, ion channels and networks in a declarative format, while the corresponding mathematical and structural definitions of these elements can be defined in LEMS. The libraries described here, libNeuroML and PyLEMS, together provide a flexible toolkit for utilizing and extending the NeuroML language with Python. They complement the declarative model specification benefits of the XML forms of these languages by offering APIs which can be used for procedural model development. While the libNeuroML API provides a Python object model which has a type interface defined by the NeuroML Schema, it also offers a memory-efficient array-based internal representation for morphological neuron reconstructions and allows export of NeuroML models into different formats.
lib-NeuroML also provides a range of helper methods that provide several common operations required when interacting with models expressed in NeuroML. In the same way that libNeuroML  provides access via Python to NeuroML, access to the LEMS language is provided by PyLEMS. While Python interfaces exist for many neuronal simulators, giving access to their native object model (e. g. ,  NEURON Carnevale and Hines, 2006)  or allowing new neuron models to be specified (e. g. , Brian  Goodman and Brette, 2008) , this is the first effort at a comprehensive Python suite allowing standards based specification of neuronal model elements from ion channels and synapses to complex networks of cells in 3D, accompanied by programmatic access to underlying model definitions. Another advantage of these Python APIs is that they provide a way to add functionality that is not provided in the declarative representation.
INTERACTION WITH PyNN AND OTHER INITIATIVES A complementary initiative to create a Python API for simulatorindependent model specification is PyNN. This API has traditionally concentrated on allowing scripts for large-scale network models with point neurons to be written once and used across multiple simulators with Python interfaces which support these types of model, such as NEST  (Gewaltig and Diesmann, 2007) , NEURON  (Hines and Carnevale, 1997; Carnevale and Hines, 2006; Hines et al. , 2009)  and Brian  (Goodman and Brette, 2008). While the focus of NeuroML v1. x was on multicompartmental, conductance-based cell models, the wider scope of NeuroML v2 has led to increased overlap with PyNN. There are LEMS definitions for the dynamical behavior of the standard PyNN neuron models and corresponding NeuroML elements for these (e.