dataesr/scientific-paragraphs-categorization huggingface dataset:
CMIP was designed to be used on Open Systems Interconnection (OSI) and it extends the capability of SNMP. Nevertheless CMIP has not been widely adopted because of slowness in the process of its standardization. Network Configuration Protocol (NETCONF) NETCONF has been introduced to improve SNMP. It introduces new features in network management such as multiple configuration data stores  (candidate, running, startup) , distinction between configuration and state data. NETCONF uses Extensible Markup Language (XML) based data encoding for both the configuration data and the protocol messages. NETCONF uses the YANG model which is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol  (Bjorklund, 2010). RESTCONF RESTCONF protocol has been designed with the goal of extending NETCONF protocol in order to enable possibility of performing network management operations through web applications.
Network devices are considered as simple packet routing devices (data plan) and the control logic is implemented at the controller (control plane). Southbound interface is the relay between programmable switches and the software controller. Several southbound API has been proposed in literature  (Sezer et al. , 2013) , notably: OpenFlow, ForCES, PCEP, etc. Openflow is considered as the most common southbound SDN interfaces  (Lara et al. , 2013). Openflow exists in several software releases  (Shalimov et al. , 2013) : NOX, POX, Beacon, Floodlight, MuL, Maestro, Ryu, etc. Northbound interface enables communication among the higher-level components. In fact, northbound interface allows exchange of information between network and application running on top of it. De Gante et al. (  2014 ) proposed a centralized architecture for the management of wireless sensor networks.
Machine learning based frameworks for management of IoT low power networks Nowadays, IoT networks generate a huge amount of data due to the dynamic nature of these networks and/or the number of resource-constrained devices. In order to leverage the benefits of those data, machine learning techniques have been used in order to help in taking decision of network management  (Aboubakar, 2020a,b; Alsheikh et al. , 2014; Kumar et al. , 2019; Wang et al. , 2017). Machine Learning (ML) refers to the process that gives a computer the ability to mimic the human brain in order to perform complex tasks based on their knowledge. It has been useful for IoT network management because it provides predictive mechanisms that help taking decision such as routing table reconfiguration, network scheduling, parameter adaptation according to the current states of the network.
In general, ML techniques can be divided into supervised learning, unsupervised learning and reinforcement learning. Supervised Learning is a ML method which provides a way to predict the outcome of unseen values by using classification or regression with pre-labelled data. It is based on two steps namely training (phase which involves dataset training and designing of classification model) and testing (which involves classification of unseen value). The common supervised learning algorithms used for IoT network management include: Support Vector Machine (SVM), regression tree, neural network, Convolutional neural network (CNN), Deep Belief Network (DBN) and Recurrent Neural Network (RNN). Unlike supervised learning, unsupervised learning is not based on pre-labeled. It uses instead unlabeled dataset to perform classification of data into cluster by discovering common pattern within those unlabeled dataset.
The format applies a hierarchical data storage concept consisting of a root node (node 0), a sample (node 1), a sequence (node 2), a record (node 3) and a curve (node 4). The curve level holds information on the technical component (e. g. , photomultiplier, thermocouple). A finite number of curves represent a record (e. g. , an optically stimulated luminescence curve). Records are part of a sequence measured for a particular sample. This design concept allows the user to retain information on a technical component level from the measurement process. The additional storage of related metadata fosters future data mining projects on large datasets. The XML-based format is less memory efficient than binary formats, however, in focus is data exchange, preservation and hence XLUM long-term format stability by design.
Good examples for aggregated luminescence data are repositories such as  Lancaster et al. (2015)  or  Codilean et al. (2018). Such archives are excellent places to find locations of dating studies, but it is not easy to spatially link different ages without accessing the original studies with primary data. Original, minimally processed luminescence data (see Fig. 1 ), i. e. measured luminescence, is hardly ever published along with a study. However, sharing of unprocessed luminescence data, accessible to others after the completion of a dating study, is desirable for several reasons: 1. Luminescence ages are end-members of long measurement series involving various protocols, tests, and analysis steps with potentially different hardware and software tools. Once aggregated, it is challenging for others to re-validate published luminescence dates beyond plausibility checks.
Shared raw data will potentially lead to better reproducibility and data quality. 2. Access to luminescence data on a single curve level supports the application of advanced analysis tools employing hierarchical Bayesian models such as the R package 'BayLum'  (Philippe et al. , 2019)  or the model 'baSAR'  (Combès et al. , 2015; Mercier et al. , 2016). Other work has shown examples of how to study sediment pathways by tracing the bleaching histories of sediment grains  (Chamberlain and Wallinga, 2019). If such data are never shared, their full potential remains untapped. 3. Recently,  Balco (2020)  advocated for a transparent and open middle-layer concept, disconnecting measured quantities from processed ages to account for changed, perhaps improved calculation procedures. His proposal was specified to cosmogenic-nuclide exposure dating, but the general idea appears valid for other dating techniques, such as luminescence dating.
, 2011) , to physicists focusing on luminescence models, or to data scientists trying to develop new approaches to enable exploratory luminescence data analysis to constrain physical parameters of OSL curves (e. g. ,  Burow et al. , 2016) , or seeking training datasets to test machine learning approaches (e. g. ,  Kröninger et al. , 2019). 5. Broadly shared and accessible through a standard format, luminescence curve data will help establish a comprehensive repository for luminescence data, enabling studies and meta-studies not covered by the above mentioned examples. Data sharing requests can only be reasonably accommodated if luminescence data can be easily exchanged, sufficiently archived, and analysed independently of proprietary software or file formats. We argue that one particular reason hampering the exchange and reuse of luminescence data is the absence of a suitable data format supporting long-term data preservation and fostering data exchange.
tif, *. spe) appear to be common, however, they lack the metadata required for luminescence data analysis. final TL curves while data is imported in a programme. (B) in the approach suggested here, the luminescence signal and the temperature, are recorded by two independent technical components, e. g. , a PMT (1) and a temperature sensor (2) monitoring the heating process. While importing, the resulting TL curve (3) becomes a match of both recorded signals on the time domain. Such import routine is, e. g. , available in the R package 'Luminescence'  (Kreutzer et al. , 2012). -The format should preserve physical quantities (measured, modelled), while, and their description remains equally readable to humans and machines. -Data should be stored structured on a technical component/sensor level (e.
g. , photomultiplier, thermo-couple) without limiting the data or forcing data reduction. -The format shall enable self-contained storage of data from technical components. -The format is self-explanatory, i. e. , it can be generally understood without format documentation. -Backwards compatibility shall be maintained for future versions (newer format versions may carry additional attributes but remain readable to existing tools). -The format provides a neutral format open and "non-proprietary" with specifications defined by the scientific community not by equipment manufacturers. -The format application is permitted in closed and open software tools through suitable license conditions. -Standard software solutions to process measurement data, e. g. , MS Excel TM , R, Python, LibreOffice, Matlab TM , GNU Octave are to be supported.
Format description In the following, we outline the conceptual structure of the XLUM format. To minimise verbosity, we only focus on key design concepts. For full details, we refer to our reference document on GitHub TM (https://xlum. r-luminescence. org, last accessed: 2022-06-30). The GitHub TM repository also contains a formal format description following the XML Schema Definition (XSD) for automated validation. XLUM defines a substructure, which can be part of a file or any other XML structure (W3C XML Core Working Group, 2008) that acts as a container or constitutes a file of its own, for instance, with the file extension *. xlum. Although the XLUM format does not enforce a specific file extension. The two key features of the XLUM format are (1) information nesting, with measurement data only stored in the lowest node, (2) support of data sharing by design.
For instance, for measurement over 100 channels with a photomultiplier tube x = y = 1 and t 1 ,. , t 100. In contrast, for a measurement with a camera with a lateral resolution of 512 × 512 pixels, x, y ∈ 1,. , 512, where t 1 ,. , t 100 remains the same. The dimensional information is stored in the node attributes xValues, yValues, and tValues. All quantities, except for t are dimensionless (i. e. , they have no default unit). However, the attributes xUnit, yUnit, and tUnit allow setting SI units. For more attributes and their meaning, we may refer to the detailed format description (https://github. com/R-Lum/xlum_specification, last accessed: 2022-07-04).
> 32: 0. 9 0. 8 2 0. 7 4 0. 6 7 0. 6 1 0. 5 5 0. 5 0 0. 4 5 0. 4 1 0. UTF-8 and must not be changed. In a nutshell, it tells programs for file parsing the character encoding and ensures that characters are interpreted correctly. Lines 2-5 Start of the XLUM record, with mandatory entries, e. g. , for the namespace (xmlns::. ) and the used format version (here: 1. 0), and metadata related to the data itself, e. g. , author and license. Those attributes apply to all child nodes and clarify the data sharing rights in simple and unequivocal terms. In the example, we have applied the Creative Commons (CC) Licence CC-BY 1. This licence allows unrestricted data reuse, mixing, and sharing with the requirement to credit the data creators. Lines 6-7 The <sample/> node allows providing information about the sample, e.
g. , mineral, latitude. Those data are helpful for explorative data analysis with data from different geographical origins. Lines 8-9 The <sequence/> node, with general information that remains unchanged for a sequence, e. g. , position for referring to a position in the equipment. Lines 17-23 The 2 nd <curve/> node with values measured with a PMT during heating (component). Here attributes for detectionWindow and filter are set. However, those attributes can be set to NA, if information is not available or not applicable. Lines 25-35 The 2 nd record in the sequence with one file with GSL measured with a PMT. While the record may contain information about the stimulation power or settings of the heating during stimulation, that information was not recorded for our example. Lines 35-37 The closing tags for the nodes <sequence/>, <sample/> and <xlum/>.
Format support in R and Python Beyond a community-tailored open data solution for storage and sharing, an open exchange format expands the availability of luminescence data beyond the target community. This enables experts from other disciplines to work with luminescence data. Data analytics is a field in the hemisphere of Artificial Intelligence, Machine Learning, and Data Science. Here, two programming languages have gained significant popularity R (R Core Team, 2022) and Python TM (Python Software Foundation, 2022). To foster the distribution and usage of XLUM, we developed two prototype interfaces, one for R, and one for Python TM.
Programming environment R We realised support for the XLUM format for the statistical programming language R (R Core Team, 2022) through a new package called 'xlum'  (Kreutzer and Burow, 2022). The package has reached a stable development status with a test coverage of nearly 100 %, i. e. , package functionalities are continuously tested in unit tests (cf. Kreutzer et al. , 2017 , for more details) on different operating systems. Within the R environment, data elements can be accessed through base R functionality and data types (e. g. , list; see documentation of the package 'xlum' and 'xml2'). In 'xlum', all file interactions (functions read_xlum(), write_xlum(), validate_xlum()) are realised through the R package 'xml2'  (Wickham et al. , 2021)    in Fig. 4. First, a format blueprint is derived from a prototype shipped with the package 'xlum'.
The prototype is then expanded and filled with data. Before export, the file is validated (validate_xlum()) against an XSD schema to ensure that the produced XLUM file follows the correct format specification. Both, the prototype and the XSD are copies of files available as part of the XLUM file format definition. Other than basic import and export functionality to and from R of data shared as *. xlum files, the package 'xlum' supports the conversion of various file formats (e. g. , *. binx, *. xsyg) to the here proposed XLUM format using R functions commencing with convert_ (e. g. , convert_binx2xlum(), see Fig. 5 ). Internally, the conversion uses the R package 'Luminescence'  (Kreutzer et al. , 2012 (Kreutzer et al. , , 2022a) )  to create R specific object structures (S4-class objects) tailored to luminescence data called RLum-objects (cf.
Kreutzer et al. , 2017 , their Fig. 2 ), and convert these structures using convert_rlum2xlum(). To date, this conversion is not always lossless, i. e. , not all metadata are transferred to the XLUM format. The support will improve with the maturity of XLUM. For instance, the conversion of a *. binx file requires the following R code lines:     Our contribution aims to standardise luminescence data exchange and enable long-term data preservation by introducing a unified data format. Still, our initiative should not be interpreted as an attempt to abolish other existing formats. While XLUM is highly flexible, and broad support beyond the presented first implementation in R and Python is likely, all other formats have their justification. In particular, if considered as actual primary data, conversion to XLUM involves data coercion to some extent.
However, format support through other software and equipment manufacturers is desirable in the long run, making luminescence data more findable and accessible. XLUM promotes the implementation of the FAIR data sharing guidelines. Nonetheless, it does not enforce them, and our contribution should not be understood as a claim on how and if data should be shared. Instead, here we refer readers to the guidelines of their institutes or funding bodies. For XLUM, we have chosen an XML-derived format structure. Mills et al. (2015)  discuss potential adverse effects on the availability of primary data in the field of biology if investigators of long-term studies are obliged to share their data. Although XLUM is merely a data format, setting no sharing rules and our comparison with a different discipline quickly wears off.
The fear of study authors that others may use their hard work to publish more quickly might be one of the reasons for the "upon reasonable request" data availability statements (Sec. 1). In the case of luminescence studies, long-term studies running over many years are scarce (e. g. ,  Guérin and Visocekas, 2015,   Last, a significant obstacle to our initiative towards success is the question of broad community acceptance of the new format. Reasonable predictions are difficult to make. We tried to improve the chance of success of our initiative by implementing the first support in the programming language R and Python and by keeping all documents open-access. Furthermore, with the publication of the manuscript after peer-review, the XLUM format will be supported by LexStudio2, the software running lexsyg luminescence readers and could be supported by/adopted by other luminescence and dosimetry manufacturers.
Hereafter, we highlight features of a new XML-based file format, XLUM, developed for long-term preservation and exchange of luminescence data. The remainder provides examples and illustrates a reference implementation in R and Python, showing how existing data can be converted effortlessly into the new XLUM format. The discussion addresses potential shortcomings and challenges and canvasses future directions. We consider our contribution as an initial definition, and the format blueprint is open to discussion within the luminescence community. The XLUM file format is published and fully detailed on a GitHub TM repository and archived on Zenodo (European Organization For Nuclear Research and OpenAIRE, 2013) (Kreutzer et al. , 2022b). The chosen open-source MIT licence (https: //opensource. org/licenses/MIT, last accessed: 2022-05-2) allows reuse in open-access and closed-source software projects.
https://doi. org/10. 5194/gchron-2022-27 Discussions Preprint. Discussion started: 22 December 2022 c Author(s) 2022. CC BY 4. 0 License. insists on mandatory attributes, a few accepting the non-empty string NA for not available/not applicable. The first upper four nodes structure the data and provide metadata to describe the dataset. The lowest node (<curve/>) contains the raw (or minimal processed) measurement data. Listing 1. 'Basic hierarchical structure of the XLUM format following the XML scheme in version 1. 0 with UTF-8 encoding. The three dots (. ) indicate node attributes. ' 1: <? xml v e r s i o n = ' 1. 0 ' e n c o d i n g = ' u t f -8 ' > 2: <xlum. > 3: <sample. > 4: < s e q u e n c e. > 5: < r e c o r d. > 6: < c u r v e. e q u e n c e > 11: < / sample > 12: < / xlum> 1. <xlum/> is the root node.
https://doi. org/10. 5194/gchron-2022-27 Discussions Preprint. Discussion started: 22 December 2022 c Author(s) 2022. CC BY 4. 0 License. Line 10 The first record in the dataset, here of type TL. Lines 11-16 The complete entry for data as recorded by the thermocouple, i. e. , the sensor monitoring the temperature of the period of 10 s (tValues, tUnit) recorded in K (vUnit). The data (temperature values) are the content of the <curve/> node in line 15. For the other two curves, the measured values are listed in line 22 (PMT TL curve), and line 32 (count values GSL).
interfacing the XML parser library libxml2 (https://gitlab. gnome. org/GNOME/ libxml2, last accessed: 2022-07-05). The generation of XLUM files (function: write_xlum()) follows the workflow outlined https://doi. org/10. 5194/gchron-2022-27 Discussions Preprint. Discussion started: 22 December 2022 c Author(s) 2022. CC BY 4. 0 License.
6. 2 2 PythonSimilar to R, Python is an interpreted language. It is beginner-friendly and viral outside of traditional software development and computer science. A major advantage is the large and active open source community maintaining a wide variety of packages (e. g. , 'pandas', 'matplotlib', 'plotly') supporting data analysis workflows. For analysing luminescence data with Python, we provide a work-in-progress version of a package called 'xlum-python' on GitHub TM (https://github. com/ SteveGrehl/xlum-python, last accessed: 2022-07-01). The package allows loading XLUM files with Python and conversion into pandas DataFrame objects (two-dimensional tabular data). This format is a starting point for further analysis, such as conversion to CSV files, export to Microsoft Excel TM or graphical output.
for an excellent example of such a study), and single datasets, even such as from a whole stratigraphic section as typical in palaeoenvironmental results studies, are of limited use to others. The true benefit of data sharing lies within many accessible and findable single datasets meaningfully linked through metadata, altogether forming large datasets. Because of its component focussed design with a minimum number of required metadata, XLUM does the groundwork for datasets aligned in luminescence-based chronologies across different sites in data mining projects concerned with luminescence model development and validation or in any explorative data analysis study.
Cardiac neural network dynamics-opportunities and challenges The fundamental investigations into the cardiac neural control hierarchy were reviewed by Gurel et al. They discuss the use of computational methods to investigate how information is processed while closed-loop control is in operation and to guide better experimental design. The large cardio-neural datasets produced by these experimental designs necessitate sophisticated signal processing and time series analysis techniques, as well as the usual large-scale computational challenges related to data sharing and reproducibility. These difficulties offer excellent chances for developing and approving cutting-edge methods to improve the understanding of the mechanisms underlying cardiac pathologies needed for clinical application. An open-source hypoxia/hyperoxia exposure chamber Hillman et al.
5, 6 revious work of the TREAT Registry Taskforce has been to develop a core dataset, consisting of domains and domain items with corresponding measurement instruments, to be captured in AE research registries, to harmonize data collection. 7, 8 The aim of developing this core dataset was to increase the interoperability, direct comparability and pooling of data, and to reduce heterogeneity in data collection across country borders. The TREAT core dataset is aligned with the Harmonizing Outcome Measures for Eczema (HOME) recommendations (www. homef orecz ema. org). The HOME initiative developed a consensus-based core outcome set for clinical trials and is developing one for clinical practice. Heterogeneity of outcomes used in disease registries has been demonstrated to hinder comparing results and pooling of data between centres and countries.
A need to harmonize outcomes has been identified within similar collaborative initiatives for other diseases, Objectives: We aimed to give an overview of the status and characteristics of the eight established TREAT registries, and to perform a mapping exercise to examine the degree of overlap and pooling ability between the national registry datasets. This will allow us to determine which research questions can be answered in the future by pooling data. Methods: All eight registries were asked to share their dataset and information on the current status and characteristics. The overlap between the core dataset and each registry dataset was identified (according to the domains, domain items and measurement instruments of the TREAT core dataset).