dataesr/scientific-paragraphs-categorization huggingface dataset:
Challenges: Data Interoperability in Groundwater Data Networks Data access is a key issue faced by all groundwater data users, including modelers, particularly those carrying out integrated studies using multiple data sources. Barriers to data access involve data availability, fragmentation, and heterogeneity: i. e. not all data are available online, and groundwater data are divided unevenly amongst multiple providers, such that the structure and content of the data is quite heterogeneous. This leads to problems in its usage, because data are hard to find, and once found are difficult to exploit due to the immense work required to re-format the data into a common usable structure. Figure 26. 5 illustrates an example of heterogeneity in the lithology descriptions of water well databases from two adjacent Canadian provinces: note the differences in language (French/ English), structure (one field/many fields), and content (sand/fine and medium sand).
However, they can also refer to scientific knowledge in general, distinct from data, that is to the components of a scientific conceptual model. This includes definitions for the types of entities in the model, and expressions of underlying theories that drive the model. • The pragmatics level includes standard tools and methods, so that data are collected and processed using common scientific protocols. As an example, the heterogeneous rock type descriptions from Fig. 26. 5 can be resolved via transformations of the data at each level: a query in a web browser, for example wells possessing certain rock types, is translated into requests to WFS web services layered over each database (systems); the web services return water well records, by transforming the structure of the databases into standard GWML (syntax, schema), which uses one field to hold rock types, and the content of this field is populated with the rock types in the logs transformed into a standard English vocabulary (semantics).
It also integrates the standardized data, retrieved from potentially multiple sources, into a single unified result, and returns this result to the requester in a choice of several possible file formats such as GML, KML, shape file, ESRI GeoDatabase, or PDF. Significantly, the middle tier is presented online as three web services (WFS, WMS, SOS), which effectively serve as a central data pipeline. Requests for data can thus be made in two ways: through a web portal which issues requests to the data pipeline; or the web portal can by bypassed completely and requests can be sent directly to the data pipeline, for example from an online modeling application. The GIN architecture has proven to be efficient and effective, returning moderate amounts of data relatively quickly (e. g. hundreds of wells in several seconds), which is adequate for typical usage.
HIS is by far the most de-centralized architecture examined herein, as its data holdings, transformations, catalog and portals are all distributed. Data distribution is achieved, at the moment, using custom "WaterOneFlow" web-services layered over 70 data sources. Data transformation takes place at each data source as an integral component of the web services, and is minimized as standard database structures are encouraged. For data discovery, transformation includes the semantic level, as time series parameters are mapped to a common vocabulary, enabling specific types of data to be identified within the network. However, data retrieval occurs only up to the structure level, as parameters are not mapped to a standard, but served 'as is' from the sources; moreover, data from multiple sources are not integrated into a unified file, but served individually.
Crucially, some of greatest headaches in preparing and ingesting input data for the AWRA system will be solved using this approach. The GeoFabric will provide a resolution of identity between the spatial network, the jurisdictional agencies that collect the data, and the AWRIS data warehouse. AWRIS itself will handle the ingestion, consolidation and semantic matching between the diverse sources, as well as proving a trusted data source complete with metadata, and a convenient web services interface supplying data in standardised formats such as WaterML2. AWRA is a significant national integrated modeling application that has many data management challenges. The current system makes use of many semiautomated steps for the discovery, access, integration and use of data. We have learned that: • Integrated modeling systems cannot be developed in isolation from the data availability and management needed to support them • Models need to be managed and governed similarly to data • Management of data needs to be approached from a dataset by dataset perspective • A web-based data network would significantly ease the burden of the data management challenge for integrated modeling studies like AWRA.
We expect that cloudcomputing technology will become an important enabler for delivery of integrated groundwater data in data networks. Open standards (data and services) are likely to become more common-place with some good current examples being GWML, WaterML2. 0 and the underlying GML and XML formats. Finally, linked data implementations will continue to evolve and grow. Linked data is a term which refers to a set of standards and approaches for publishing and connecting data on the web  (Bizer et al. 2009 ). Linked data is made available on the web in a standard format, usually RDF, which enables links to other datasets, or contextual data including metadata. Because linked data methods use the standard web-based linking approach of Universal Resource Identifiers (URI's), it becomes very easy to discover new data and information on the web.
As a result, linked data methods are migrating from the research community and starting to become mainstream, albeit with varying levels of conformance to core linked data principles  (Hogan et al. 2012). Examples are appearing in a number of countries, such as the UK location program (http://data. gov. uk/location), in which the identity of features and their corresponding properties can be easily determined. Two related issues remain a challenge for linked data -these are particularly evident in the water domain. The first is the massive volume of data stored in legacy databases: because linked data approaches, at the moment, almost universally deploy RDF as a format, it still remains a research objective how best to layer linked data methods over non-RDF databases  (Marjit et al. 2013).
Instead, there is a trade-off between fitting different datasets that may or may not inform parameters important for prediction, and the prediction of interest. Therefore, it is recognized that multiple alternative models may be required to provide better predictions for when there is more than one prediction of interest  (Moore and Doherty 2005). Where the uncertainty in predictions is too great, models can be used to optimize data collection to cost-effectively reduce the uncertainty associated with a given prediction. For example, existing models can be used to estimate the effect of establishing a new monitoring borehole at particular locations  (Dausman et al. 2010) , though results may be affected by the existing assumptions in the models used  (Fienen et al. 2011). New data collection often consists of extensions of existing head and flux monitoring networks, but can also encompass estimates of model parameters obtained from dedicated tests, such as from soil properties of geological drilling logs, lab tests and from measuring the response in groundwater level during aquifer tests  (Illman et al.
Acknowledgments I wish to thank and acknowledge my colleagues who have contributed to the  UNESCO International Hydrological Program 's  GRAPHIC (Groundwater Resources Assessments under the Pressures of Humanity and Climate change)  Project since 2004. In particular,  Makoto Taniguchi ,  Henk Kooi ,  Jason Gurdak ,  Diana Allen ,  Holger Treidel  and  Alice Aureli , who co-authored Green et al. (2011) contributed substantially to the basis for this chapter, and the authors of Taylor et al. (2013) provided updates and additional insights on key issues related to groundwater and climate change. I also thank  Prof. Tony Jakeman  and co-editors of this book for inviting me to write this chapter, particularly  Dr. Randall Hunt  for his thoughtful editing and help integrating it with other chapters.
Acknowledgements The authors wish to thank the  Belgian Federal Science Policy Programme BELSPO  for the financial support provided for the  FRAC-WECO research project , and the  European Commission  for the financial support provided for the  BRIDGE-WFD research  project. The chapter has been prepared with the financial support of  BRGM research program 30 (Environmental and Risk economics ). Open Access This chapter is distributed under the terms of the Creative Commons Attribution-Noncommercial 2. 5 License (http://creativecommons. org/licenses/by-nc/2. 5/) which permits any noncommercial use, distribution, and reproduction in any medium, provided the original author(s) and source are credited. The images or other third party material in this chapter are included in the work's Creative Commons license, unless indicated otherwise in the credit line; if such material is not included in the work's Creative Commons license and the respective action is not permitted by statutory regulation, users will need to obtain permission from the license holder to duplicate, adapt or reproduce the material.
Acknowledgments Research for this study was carried out in the framework of the ' Groundwater Arena ' project, funded by the  French National Research Agency  ( CEP S 11/09 ), and the  Sirma  collaborative agreement. Open Access This chapter is distributed under the terms of the Creative Commons Attribution-Noncommercial 2. 5 License (http://creativecommons. org/licenses/by-nc/2. 5/) which permits any noncommercial use, distribution, and reproduction in any medium, provided the original author(s) and source are credited. The images or other third party material in this chapter are included in the work's Creative Commons license, unless indicated otherwise in the credit line; if such material is not included in the work's Creative Commons license and the respective action is not permitted by statutory regulation, users will need to obtain permission from the license holder to duplicate, adapt or reproduce the material.
Acknowledgments Sections of this chapter were initially completed as part of a doctoral thesis by  Suzanne A Pierce  with funding from The  Jackson School of Geosciences, The University of Texas at Austin  and the  STAR Fellows program  of the  U. S. Environmental Protection Agency  (Agreement number  FP91632001-0 ). The authors would like to thank the editors,  Muhammed Arshad  and  Dr. Anthony Jakeman  for their patience and constructive comments throughout the editorial process. Open Access This chapter is distributed under the terms of the Creative Commons Attribution-Noncommercial 2. 5 License (http://creativecommons. org/licenses/by-nc/2. 5/) which permits any noncommercial use, distribution, and reproduction in any medium, provided the original author(s) and source are credited. The images or other third party material in this chapter are included in the work's Creative Commons license, unless indicated otherwise in the credit line; if such material is not included in the work's Creative Commons license and the respective action is not permitted by statutory regulation, users will need to obtain permission from the license holder to duplicate, adapt or reproduce the material.
2016 ). E is part of the larger O  (Balat et al. 2009)  project. O provides a comprehensive set of tools and libraries for developing Web applications in OC , including the compiler _ _  (Vouillon and Balat 2014) , a Web server, and libraries for concurrency  (Vouillon 2008) , HTML manipulation (TyXML 2017) and database interaction  (Scherer and Vouillon 2010) , O libraries take deep advantage of the OC type system to provide guarantees about various aspects of client-and server-side Web programming, e. g. , this paper shows examples in which we produce HTML whose validity is guaranteed by the type system (TyXML 2017). These guarantees are complementary to the ones that E provides on client-server communication. Our language primitives coupled with preexisting OC libraries (such as the ones provided by O ) have allowed us to build a comprehensive tierless Web framework.
For instance, in the case of E , RPCs, a functional reactive library for Web programming, and a GUI toolkit (Ocsigen Toolkit 2017) have all been implemented as libraries. Explicit communication. E is using manual annotations to determine whether a piece of code is to be executed server-or client-side  (Balat 2013; Balat et al. 2012). This design decision stems from our belief that the programmer must be well aware of where the code is to be executed, to avoid unnecessary remote interaction. Explicit annotations also prevent ambiguities in the semantics, allow for more exibility, and enable the programmer to reason about where the program is executed and the resulting trade-o s. Programmers can thus ensure that some data stays on the client or on the server, and choose how much communication takes place.
2. 2. What matters here is that we end up with a function that we can call like any other; calling it executes the remote procedure call. We now use the RPC API with the counter widget de ned in Section 3. 1. We assume the existence of a save_counter function, which saves the counter in a database, and of the counter function de ned previously. We then proceed to de ne save_counter_rpc (i. e. , the server-side RPC interface for save_counter), and inject it into a fragment f. This fragment is subsequently used as the userprovided callback for counter. This way, each time the counter is incremented, its new value is saved server-side. val % server save_counter : int -> unit val % server counter : ( int -> unit ) fragment -> Html. t let % server save_counter_rpc : ( int , unit ) Rpc. t = Rpc.
The create function starts by creating an untyped broadcast endpoint. We then use Event. iter to serialize and then send each occurrence of the provided event. We now need to create a converter for BroadcastEvent. t. We need to transmit two values: the URL of the broadcast endpoint, so that the client can subscribe, and the deserialization part of the provided converter, so that the client can decode the broadcasted messages. raw_conv provides a converter for a pair of a URL and a fragment. In addition to receiving this information, the client deserializer creates a new event stream and subscribes to the broadcast endpoint. We connect the broadcast output to the event stream by passing along all the (deserialized) messages. As we can see in this example, we can use converters explicitly to setup very sophisticated communication schemes in a safe and typed manner.
Heterogeneous implementations Shared sections make it possible to write code for the client and the server at the same time. This provides a convenient way of writing terse shared implementations, without duplicating logic and code. This does not necessarily entail that everything is shared. In particular, base primitives might di er between client and server, though the overall logic is the same. Just as we can implement heterogeneous datatypes with di erent client-and server-side representations, we can also provide interfaces common to the client and the server, with di erent client-and server-side implementations. We consider the case of database access. We rst assume the existence of a server function get_age of type string -> int that performs a database query and returns the age of a person.
As an example, we present a shared (association) table API for storing data of interest on both the server and the client. We use strings as keys. The type of tables ( a, b)table contains two type variables a and b, corresponding to the server-and client-side contents respectively. For the sake of simplicity, we assume that the type variables a and b must be instantiated such that there exists an appropriate converter. The API in Figure  14  provides add and find operations, as is typical for association tables, which are available on both sides. Our goal is to have a table API well-adapted for E 's clientserver style of programming. On the server, the table is to be used while serving a request, e. g. , for locally caching data obtained from complex database queries. It is frequently the case that the client needs access to the same data; in that case, it is desirable that we avoid performing multiple RPCs.
Global overview Before detailing each part of the implementation, we give a global overview of the E compilation pipeline. A schema is shown in Figure  17. We modi ed the OC typechecker to handle E constructs. Our modi ed typechecker is presented in Section 4. 2. Once the E code has been typechecked, we use it to generate two OC les, the client part and the server part, through the slicing method presented in Section 4. 3. The slicing relies on inserting primitives that implement the communication mechanism of E (as described in Section 3. 1. 1); we present the semantics of said primitives in Section 4. 4. After slicing, the two generated les are pure OC code and can be compiled with the regular OC compiler. The client code is nally translated to J S using the _ _ compiler.
Tierless languages and libraries Several other languages share with E the characteristic of mixing client and server code in an almost transparent way. In this section, we attempt to create a taxonomy of tierless programming languages. We rst give a high-level comparison of the various trade-o s involved. Inference of code location. In E , code location is speci ed through manual annotations. In several other approaches, code location is inferred based on known elements (database access is on the server, dynamic DOM interaction is done on the client, etc). Such inference can be done either in a type-directed manner  (Cooper et al. 2006)  or via a global control ow analysis  (Chong et al. 2007; Opa 2017; Philips et al. 2014). Another approach is to operate code slicing at runtime. This is mostly used by J S based systems.
Furthermore, contrary to E , several primitives such as RPC are hardcoded in the language, which makes it less easy to extend with libraries providing new client-server behaviors. H  (Boudol et al. 2012; Serrano and Queinnec 2010 ) is a dialect of Scheme for programming Web applications. Its successor, H. js  (Serrano and Prunet 2016) , takes the same concepts and brings them to J S. It uses location annotations similarly to E and provide facilities to write complex client-server applications. However, as a Scheme-based language, it does not provide static typing. Slicing is performed at runtime. In particular, contrary to E , H does not statically enforce the separation of client and server universes (such as using database code inside the client). L  (Cooper et al. 2006 ) is an experimental functional language for client-server Web programming with a syntax close to J S and an ML-like type system.
Its type system is extended with a notion of e ects, allowing a clean integration of database queries in the language. It does not provide any mechanism to separate client and server code, so they are shared by default, but it uses e ects to avoid erroneous uses of client code in server contexts (and conversely). Compared to E , compilation is not completely available and L does not provide an e cient communication mechanism. H  (Ekblad and Claessen 2014 ) is an extension of H similar to E. Instead of using syntactic annotations, it embeds client and server code into monads. This approach works well in the H ecosystem. However H makes the strong assumption that there exists a universe containing both client and server types, shared by the client and the server. E , on the contrary, does not make this assumption, so the monadic bind operator for client fragments, of type ( a -> { b })-> { a } -> { b }, makes no sense: a would be a type both on the server and on the client, which is not generally true.
This includes 78 (out of 86) instances for which the optimal solution has been previously unknown. Our framework won the category STPRBH in the challenge. The program is made available online under http://homepage. univie. ac. at/markus. sinnl/program-codes/stprbh/. Outline of the Paper. Our paper is structured as follows: In Section 2, a short review of layered graphs is followed by the presentation of our generic new model together with valid inequalities. Section 3 contains a description of our solution framework, including a preprocessing phase and primal heuristics. Computational results are presented in Section 4. Section 5 concludes the work with a short summary and a discussion of future work. It points out a broader potential of the proposed "thinning out" approach for modeling hop-or diameter-constrained trees.
Numerical Setup of the OC Model In the current work, a 2D orthogonal cutting model was developed by using the commercial software Abaqus/Explicit code (Version 6. 11, Dassault Simulia, Paris, France). To simulate the hybrid cutting operation, the machining process was specified as shown schematically in Figure  1. The basic geometries of the tool-workpiece couple and boundary condition are illustrated in Figure  1. The established orthogonal cutting (OC) model is comprised of four basic phases, i. e. , the tool part, Ti part, interface part, and CFRP part with total dimensions of 2 mm ˆ1 mm (L ˆH) for the workpiece material. The cutting tool was modeled as a rigid body and imposed by a cutting velocity on its reference node toward the horizontal direction (i. e. , negative X-axis) to finalize the cutting simulation.
1983)  for the acquisition and reduction of data obtained with a scanning Fabry-Perot interferometer (CIGALE is the name of our survey too). For each typical observation we obtain the following informations. (i) one wavelength calibration cube (neon lamp), from which we derive a phase map giving the wavelength origin at each pixel. Instrumental profile and flat-field are also obtained from this series of calibration rings. (ii) one science cube of the observed field around the Hα. From the calibration phase map we can compute a wavelength-calibrated cube that contains one spectrum for each of the 256 × 256 pixels. The instrumental profile is determined by observing the narrow emission line of a Neon lamp at λ 6598. 95 Å. The instrumental profile fits the classical Airy function characteristic of the instrumental response of the Fabry-Perot interferometer and will be used to determine the deconvolved line width of the profiles.
08 from individual extragalactic H II regions while this ratio can reach 0. 2 when considering integrated spectroscopy, more representative of the DIG. Combined with the filter transmission these translate into 3 and 7. 5 per cent [N II] possible contamination of the Hα emission for H II regions and DIG, respectively. The SHASSA web site 1  makes available continuum subtracted, intensity-calibrated data. The LMC is covered by a single SHASSA field we retrieved from the web site. For direct comparison, each night sky lines corrected Hα monochromatic image is re-binned and regrided to the SHASSA image (48 arcsec) resolution. For each individual field, the equivalent area of SHASSA data is then extracted and aligned to match our field. The images are then compared directly, pixel per pixel, to give a plot of SHASSA values, previously converted in erg cm -2 s -1 , versus counts per re-binned pixel of our survey (Fig.