dataesr/scientific-paragraphs-categorization huggingface dataset:
c. Astronomy In astronomy, the Virtual Observatory (VO) is the vision that astronomical data sets and other resources provided by projects and data centres worldwide should work as a seamless whole. The International Virtual Observatory Alliance (IVOA) is an organization that debates and agrees the technical interoperability standards that are needed to make the VO possible. For a long time, astronomy has had an open data and data sharing policy. Usually after a 6-12 months proprietary period for observational data, astronomical data is made available by projects and data centres freely and openly to the scientific community through on-line web services (web based Graphical User Interfaces and scriptable APIs). Similarly, most of the software developed is released under open source licenses.
In general, astronomy science has no borders and astronomers share a very collaborative culture, based on the fact that all large astronomy projects (ground-and space-based) are performed under large international consortia. Since its inception, the IVOA has been science driven and this has been enhanced with the creation of the Committee for Science Priorities (CSP) which defines priority science cases to be supported by the VO framework, such as multi-wavelength science, combining data sets from multiple sources, time variability of objects, data discovery, data access, data analysis and visualization tools. The IVOA was created in 2002, very soon after the beginning of the VO development. The first VO projects obtained funding from the European Commission, and in the USA and in the UK starting in 2001.
e. Materials Science To some, like the Strange Matter Exhibit, materials science is the 'study of stuff'. As presented by Jim Warren, NIST, at the SciDataCon 2016 session on 'Building a disciplinary, world-wide data infrastructure', materials science and engineering is an interdisciplinary field focused on the discovery and design of materials to improve the performance of products that impact our everyday lives, ranging from transistors, LEDs, titanium turbine blades, to sporting goods. Materials research primarily examines the relationships between (1) the processing of a material, such as casting or polymerization; (2) the structure or morphology of a material, such as a fluid or a nanotube; and (3) the properties of a material such as reflectivity or hardness of a material. A key challenge facing materials science is to speed up the design of new materials and eliminate the slow process of unnecessary incremental repetition.
The need for accessibility of high-value data from beam lines (neutrons and photons) and supercomputers brings new research possibilities to materials scientists; and (3) The evident opportunities for long-tail big data are promising. At this stage of infrastructure building in the materials community, several lessons have become apparent. While groups are supportive of a shared infrastructure, the changes needed for establishment are difficult to achieve. The need for better tools for building and adopting the infrastructure is widely supported. Finally standards are 'risky' and hard to reach consensus. NIST, in its efforts to support the Materials Genome Initiative, is leading standards development efforts, moving carefully with the materials community to construct, adopt, and implement needed standards to drive discovery and innovation.
f. Crystallography Crystallography is the study of molecular and crystalline structure and properties. Its most useful data output is the precise description of molecular structure, which is central to much of mineralogy, chemistry, physics, mathematics, biology and materials science. This may help to explain its traditionally open culture to data sharing. The infrastructure of crystallographic data is the curated structural databases (many of which are several decades old and built by academic scientists) and journals, especially those published by the International Union of Crystallography (IUCr), which apply high standards of technical review to data sets as well as to the literature. There is currently also a growing trend to link to the raw experimental data that is stored at the originating experimental facility or in institutional repositories.
Crystallographers have a strong desire to repeat and improve previously determined structures, to ensure the highest quality of published results, and to data-mine comprehensive archives of structural models. To facilitate these objectives, there is an overwhelming need for easy information flow and cross-linking between journals and databases, as well as among the various software packages used for data processing and analysis. The databases describe a variety of types of structure, and have diverse architectures and indeed business models. However, there is a particular mechanism that allows data exchange between databases, software applications and journals. That mechanism is a data exchange protocol (CIF, the Crystallographic Information Framework) developed under the aegis of the IUCr  (Hall, Allen & Brown 1991) , again by practising academic scientists.
The result is that there are now components of the CIF ontology that cover every element of the data workflow, from capture of raw experimental data, through data reduction, processing and analysis, model building to publication and database deposition. Despite the clear advantages of a standard designed to facilitate interoperability, there was some inertia within the community to implement it in practice. An important -perhaps crucial -factor in overcoming this was the early decision of IUCr journals to mandate CIF as the submission vehicle for small-molecule structures, as well as the provision of basic tools to allow authors to obey this mandate. Practitioners within any discipline may need some such measure of compulsion to embrace any new standard. Although crystallography has developed its standard ontology framework using a particular file format, the all-important definitions of data items and their attributes are contained in extensible format-agnostic dictionaries.
Hence the approach is general, and could be adopted by any discipline  (Hall & McMahon 2016). It has already been applied in some related areas of structural science, including nuclear magnetic resonance spectroscopy, 3dimensional electron microscopy, chemical structure, materials properties and protein homology modelling. It illustrates how this implementation allows ready interoperability throughout the entire crystal structure determination workflow, from experimental apparatus through data reduction and analysis, model building, publication and database deposition.
Pelagios Commons is one such initiative, providing online resources and a community forum for open data methods for working with historical places. Many technical and technological aspects appear to be shareable, including architecture concepts. The implementation of a registry of resources is essential to enable data discovery. It can rely on generic concepts with disciplinary extensions, such as the IVOA registry, based on OAI-PMH, which has been customized by nearby disciplines, and will be used as a model by the materials science community. The IUCr maintains a machine-readable registry of CIF ontologies and intends to extend this to include other compilations of metadata describing specific types of experiment. There are technological and practical incentives, including gains in efficiency, to use generic e-infrastructures, for instance for storage, or generic building blocks, in particular for identity federation.
Conclusions Disciplines which are not strongly organized at the international level may encounter more difficulties in establishing their interoperability framework. International organizations such as GEO, CODATA and the RDA can be used to fill this gap. International discussion forums can be established as CODATA Task Groups and/or RDA Interest and Working Groups. In addition, the WDS 'community of excellence' is a host for individual data providers as regular members, but also for disciplinary networks once they are constituted, and it organizes interaction between its members. Group', to host discussions among disciplines and produce statements of lessons learnt and best practices, on organisational and sociological aspects, in particular governance, as well as on more technological topics.
This Interest Group could also organise discussions with the Groups which deal with common technological and sociological aspects of scientific data sharing, in particular around the disciplinary requirements and the relevance of the 'generic' outputs to the needs. It would also help the disciplines which already have an organisation to discuss their interoperability framework and do not see the need for a specific RDA Interest group on their own topic to engage fully in the RDA. The RDA is a unique Forum by the diversity of its members' profiles and of the disciplines represented, and likely the only place where these discussions can be organised with active participation of a variety of disciplines. The suggestion to propose such an Interest Group as a spin-off of the SciDataCon session aroused immediate interest among RDA Group Chairs.
Several of them, together with an IVOA member to represent disciplines which do not have a specific RDA Group, have now organised a so-called 'Bird-of-a-Feather' session at the RDA Barcelona Plenary in April 2017 to initiate the constitution of the Interest Group. We conclude with a specific pointer towards one possible, more technology oriented spin-off activity. The results of this exchange of information and experience between discipline representatives are perhaps not very surprising. Relatively small communities focused on well-defined scientific areas with homogeneous observational or experimental practices already have well developed data exchange frameworks. In the case of astronomy, the standard image format FITS  (Wells et al. 1981 ) has been continuously updated since its inception to become the widely adopted astronomy standard, the basic enabler of interoperability for astronomical data.
dcc. ac. uk/resources/standards and the Research Data Alliance at http://rdalliance. github. io/metadata-directory/). However, strategies for developing the necessary machine-processable concordances depend both on an awareness within the different disciplines of the need to devote resources to such activities, and an understanding of the real benefits that can follow from doing so. We believe that an interchange of experiences such as reported in this paper, and the on-going discussions in the RDA and its relevant outputs, can help to raise the necessary awareness and motivation.
Yet, the case of irregular sampling is frequently encountered in practice, for instance in astronomical observations  [2] ,  [4]. The present study explores a bootstrap solution to this problem. As in  [7] , we assume that a training data set T L of the noise is available. However, this set provides only a small number of noise samples -comparable typically to the number of data samples. In this regime, our knowledge of the statistics of the random process under H 0 remains strongly impacted by estimation noise. The working hypothesis of an available training data set is rather general, but arises in particular in the field of exoplanet detection in Radial Velocity (RV) data, where astrophysical models allow to generate time series of the noise -yet at a computational cost that makes long simulated time series out of reach.
Analytical data management applications, affected by the explosion of the amount of generated data in the context of Big Data, are shifting away their analytical databases towards a vast landscape of architectural solutions combining storage techniques, programming models, languages, and tools. To support users in the hard task of deciding which Big Data solution is the most appropriate according to their specific requirements, we propose a generic architecture to classify analytical approaches. We also establish a classification of the existing query languages, based on the facilities provided to access the Big Data architectures. Moreover, to evaluate different solutions, we propose a set of criteria of comparison, such as OLAP support, scalability, and fault tolerance support. We classify different existing Big Data analytics solutions according to our proposed generic architecture and qualitatively evaluate them in terms of the criteria of comparison.
INTRODUCTION The term Big Data has been coined for representing the challenge to support a continuous increase on the computational power that produces an overwhelming flow of data  (Kune et al. , 2016). Big Data databases have become important NoSQL data repositories (being non-relational, distributed, opensource, and horizontally scalable) in enterprises as the center for data analytics, while enterprise data warehouses (EDWs) continue to support critical business analytics. This scenario induced a paradigm shift in the large scale data processing and data mining, computing architecture, and data analysis mechanisms. This new paradigm has spurred the development of novel solutions from both industry (e. g. , analysis of web-data, clickstream) and science (e. g. , analysis of data produced by massive-scale simulations, sensor deployments, genome sequencers)  (Chen et al.
, 2014; Philip Chen and Zhang, 2014). In this sense, modern data analysis faces a confluence of growing challenges. First, data volumes are expanding dramatically, creating the need to scale out across clusters of hundreds of commodity machines. Second, different sources of data producers (i. e. , relational databases, NoSQL) make the heterogeneity a strong characteristic that has to be overcome. Fi-nally, despite these increases in scale and complexity, users still expect to be able to query data at interactive speeds. In this context, several enterprises such as Internet companies and Social Network associations have proposed their own analytical approaches, considering not only new programming models, but also medium and high-level tools, such as frameworks/systems and parallel database extensions.
This imposes the trend of the moment 'the Big Data boom': many models, frameworks, languages, and distributions are available. A non expert user who has to decide which analytical solution is the most appropriate for particular constraints in a Big Data context, is today lost, faced with a panoply of disparate and diverse solutions. Some of them, are well-known as MapReduce, but they have been overtaken by others more efficient and effective, like Spark system 1 and Nephele/PACT  (Warneke and Kao, 2009). We propose a generic architecture for analytical approaches which focuses on the data storage layer, the parallel programming model, the type of database, and the query language that can be used. These aspects represent the main features that allow to distinguish classical EDWs from analytical Big Data approaches.
We aim in this paper to clarify the concepts dealing with analytical approaches on Big Data and classify them in order to provide a global vision of the different existing flavors. Based on our proposed architecture, the contribution of this paper is threefold: (i) establish a classification of the existing query languages, based on the facilities provided to access the big data architectures; this classification allows to evaluate the level of programming expertise needed to create new queries; (ii) propose a classification of the Big Data architectures, allowing to consider the underlined framework structure to implement the data warehouse; and (iii) propose a set of criteria of comparison, such as On-Line Analytical Processing (OLAP) support, scalability, and fault tolerance support. We classify different existing Big Data analytics solutions according to our proposed generic architecture and qualitatively evaluate them in terms of the criteria of comparison, as well as in terms of type of query language and parallel programming model that they use.
We highlight their differences and underline their fair employment. We also illustrate how to use our proposed architecture in the context of several use cases. This work represents a first step towards the construction of a Decision Support System that will help non-expert users in selecting appropriate components. Section 2 presents a review of Big Data programming models. Section 3 proposes a classification of Big Data query languages. Our proposed architecture and classification for analytic approaches are presented in Section 4. In Section 5, diverse solutions for analytic Big Data are studied. Section 6 presents the related work. We finally conclude in Section 7.
BIG DATA PROGRAMMING MODELS The large-scale parallel Big Data processing scenario has brought new challenges in the programming models in order to process and analyze such huge amount of data. It is necessary a new model of cluster computing, able to adapt the constant data growing without affecting the performance, in which data-parallel computations can be executed on clusters of unreliable machines by systems that automatically provide locality-aware scheduling, fault tolerance, and load balancing. Classical parallel programming models, such as master-slave with Message Passing Interface (MPI) and multithreading with Open Multi-Processing (OpenMP), are not adequate for Big Data scenarios due to the high network bandwidth demanded to move data to processing nodes and the need to manually deal with fault tolerance and load balancing  (Chen et al.
, 2014). However, inspired on them there have been deployments of cluster computing models, which aggregate computational power, main memory, and I/O bandwidth of shared-nothing commodity machines, combined with new parallel programming models  (Leskovec et al. , 2014; Pavlo et al. , 2009). They improve the performance of NoSQL sources and reduce the performance gap to relational databases. The main difference between classical parallel models and the new ones is that, instead of moving data, the processing functions are taken to the data. The most popular model of data parallel programming in the context of Big Data is MapReduce  (Dean and Ghemawat, 2008). Along with it, Hadoop 2  is its most popular core framework implementation for carrying out analytic on Big Data. With simple distributed functions (based on Lisp primitives), the idea of this parallel programming model is to combine map and reduce operations with an associated implementation given by users and executed on a set of n nodes, each with data.
The Spark system  (Zaharia et al. , 2012; Zaharia et al. , 2010)  proposes a programming model that unlike acyclic data flows problems (such those treated with MapReduce and Nephele/PACT), it focuses on applications that reuse a working set of data across multiple parallel operations. Spark provides two main abstractions for parallel programming: Resilient Distributed Datasets (RDDs) and parallel operations on these datasets (invoked by passing a function to apply on a dataset). The RDD is a read-only collection of objects partitioned across a set of machines that can be rebuilt if a partition is lost. Therefore, users can explicitly cache a RDD in memory across machines and reuse it in multiple MapReduce-like parallel operations. RDDs do not need to be materialized at all times. Beside programming model, which allow iterative algorithms (i.
e. , cyclic data flows), Spark overcomes MapReduce and Nephele/PACT because it handles most of its operations "in memory", copying data sets from distributed physical storage into far faster logical RAM memory. By contrast, MapReduce writes and reads from hard drives. In general, the underlying system that implements the programming model, also manages the automatic scheduling, load balancing, and fault tolerance without user intervention. While programming models are most focused on supporting the implementation of complex parallel algorithms and on the efficient distribution of tasks, there exists another axis related to querying and analyzing that huge amount of data. Several languages have been proposed with the intention of improving the programming efficiency for task description and dataset analysis.
CLASSIFICATION OF QUERY LANGUAGES The wide diversification of data store interfaces has led the loss of a common programming paradigm for querying multistore and heterogeneous reposito-ries and has created the need for a new generation of special federation between Hadoop-like Big Data platforms, NoSQL data stores, and EDWs. Mostly, the idea of all query languages is to execute different queries to multiple, heterogeneous data stores through a single query engine. We classify these query languages in Procedural Languages, Language Extensions, and SQL-like Languages  (Chattopadhyay et al. , 2011). Procedural Languages are built on top of frameworks that do not provide transparent functions (e. g. , map and reduce) and cannot cover all the common operations. Therefore, programmers have to spend time on programming the basic functions, which are typically hard to maintain and reuse.
Hence, simpler procedural language have been proposed. The most popular of this kind of languages are Sawzall of Google  (Pike et al. , 2005) , PIG Latin of Yahoo!  (Olston et al. , 2008) , and more recently Jaql  (Beyer et al. , 2011). They are domain-specific, statically-typed, and script-like programming language used on top of MapReduce. These procedural languages have limited optimizations built in and are more suitable for reasonably experienced analysts, who are comfortable with a procedural programming style, but need the ability to iterate quickly over massive volumes of data. Language Extensions are proposed to provide simple operations for parallel and pipeline computations, as extensions of classical languages, usually with special purpose optimizers, to be used on top of the core frameworks.
The most representatives in this category are FlumeJava proposed by Google  (Chambers et al. , 2010)  and LINQ (Language INtegrated Query)  (Meijer et al. , 2006). FlumeJava is a Java library for developing and running data-parallel pipelines on top of MapReduce, as a regular single-process Java program. LINQ embeds a statically typed query language in a host programming language, such as C#, providing SQL-like construct and allowing a hybrid of declarative and imperative programming. In the Declarative Query Languages category, we classify those languages also built on top of the core frameworks with intermediate to advanced optimizations, which compile declarative queries into MapReduce-style jobs. The most popular focused on this use-case are HiveQL of Facebook  (Thusoo et al. , 2010) , Tenzing of Google  (Chattopadhyay et al.
GENERIC ARCHITECTURE FOR ANALYTICAL APPROACHES Basically, a Big Data analytical approach architecture is composed of four main components: Data Sources, ETL (Extract, Transform, and Load) module, Analytic Processing module, and Analytical Requests module. A generic representation of this architecture is shown in Fig. 1  and described as follows: Data Sources: They constitute the inputs of an analytical system and often consider heterogeneous (i. e. , structured, semi-structured, and unstructured) and sparse data (e. g. , measures of sensors, log files streaming, mails and documents, social media content, transactional data, XML files). ETL Module: It has as main functionality retrieving data from sources, transforming data for integration constraints, and loading data to the receiving end.