dataesr/scientific-paragraphs-categorization huggingface dataset:
A2 "OceanFlux-SI" (ESA STSE OceanFlux greenhouse gases) Method description: The in-situ pCO 2 data within SOCAT are first corrected to a common satellite derived temperature dataset using an isochemical temperature dependence. This creates an in-situ dataset with a common SST reference. Each in-situ datapoint is then corrected to the year 2010 by assuming a trend of 1. 5 µatm yr -1. Introduction.
Back Close Full The data are then binned into a monthly 1 • × 1 • format. These monthly binned data are kriged to produce a spatially complete dataset  (Goddijn-Murphy et al. , 2015). We finally generate an interannual time series by (1) cyclically using this climatological dataset over time, (2) adding a prescribed trend of 1. 5 µatm yr -1 in pCO 2 , and (3) correcting the pCO 2 values according to the difference between the climatological SST and the actual satellite-derived SST at each time and location  (Shutler et al. , 2015). Main intention/focus: Produce a spatially complete monthly climatology of pCO 2 data for 2010 that uses a consistent temperature dataset which is valid at a consistent depth in the water. Contact: Jamie Shutler.
A8 "UNSW-SOMLO" (Self-organizing multiple-linear output) Method description: In this approach we couple a neural network clustering algorithm with a multiple linear regression (MLR) to diagnose monthly ocean surface pCO 2 distributions from 1998 through to 2011. The algorithm first captures larger-scale ocean dynamics by a data-based clustering of the grid cells into "biogeochemical fingerprints" using a self-organizing map (SOM). The SOM approach utilizes the SOCATv2 gridded pCO 2 product along with co-located SST, SSS, Chl a, MLD, and geographical information (n vector) to iteratively cluster the dataset into a set of 196 neurons (the spatial domains of which we refer to as biogeochemical fingerprints). Within each neuron, MLRs are then derived between pCO 2 and the optimal set of sea-surface temperature/salinity/Chl a, MLD, and atmospheric xCO 2.
A10 "CARBONES-NN" Method description: CARBONES-NN is a neural network framework developed within the EU-FP7 project CARBONES (http://www. carbones. eu/wcmqs/) that maps surface ocean pCO 2 observations to first-order explanatory variables. As explanatory variables, it uses observations from satellites (Surface Chlorophyll climatology from Sea-WiFS), model outputs (SST, SSS, MLD) from the MERCATOR ocean reanalysis, previous step pCO 2 estimates (recursive approach) and latitude as a proxy for atmospheric conditions. A two-step neural network approach is applied based on a Multi Layer Perceptron network coupled with a variational data assimilation scheme. A first calibration step adjusts the seasonal component of pCO previously gridded at monthly temporal and 2 • × 2 • spatial resolutions. Note that most of the coastal ocean pCO 2 data have been filtered out.
The physical part of OTTM calculates the evolution of tracers in the global ocean  (Valsala et al. , 2008). The biological model is adapted from  McKinley et al. (2004). The export production in the surface euphotic zone (0-140 m) is calculated using prescribed monthly climatological phosphate and light, scaled by a spatially varying "α" parameter which accounts for maximum export rate and for those processes which are not accounted for by the phosphate and light limitation model. The surface ocean chemistry model is taken from OCMIP-II abiotic model  (Orr et al. , 1999). The physical-biogeochemical model is used to simulate the surface ocean pCO   ) , to deliver a uniformly quality-controlled surface ocean CO 2 database. We cordially thank SOLAS (in particular Emilie Brevière) for kindly supporting the SOCOM kick-off meeting in Beijing (June 2013), and NIES (in particular Shin-ichiro Nakaoka and Yukihiro Nojiri) for kindly organizing and supporting the SOCOM progress meeting in Tsukuba (February 2015).
Information content about various modes of variability as implemented by the individual mapping methods. Modes labelled as "EST. " (= estimated) are considered to reflect databased information, as they either are directly estimated by time-dependent adjustments, or are regressed against drivers through multiple adjustable degrees of freedom. The trend is considered estimated if the interannual degrees of freedom allow a data-based trend to establish or if pCO 2 is explicitly regressed against a rising term (time or atmospheric CO 2 ).
Acknowledgements. We would like to thank all colleagues and funding agencies involved in the collection, quality control, and synthetization of pCO 2 data, which are the basis of all mapping products. The  Surface Ocean CO 2 Atlas (SOCAT)  is an international effort, supported by the  International Ocean Carbon Coordination Project (IOCCP) , the  Surface Ocean Lower Atmosphere Study (SOLAS) , and the  Integrated Marine Biogeochemistry and BGD.
Technical advances in machine and system virtualization are creating opportunities for remote learning to provide significantly better support for active education approaches. Students now, in general, have personal computers that are powerful enough to support virtualization of operating systems and networks. As a consequence, it is now possible to provide remote learners with a common, standard, virtual laboratory and learning environment, independent of the different types of physical machines on which they work. This greatly enhances the opportunity for producing re-usable teaching materials that are actually re-used. However, configuring and installing such virtual laboratories is technically challenging for teachers and students. We report on our experience of building a virtual machine (VM) laboratory for a MOOC on relational databases.
Introduction Teaching Computer Science requires significant practical experimentation by the students, yet -contrary to other disciplines like physics, electronics or life sciences -specialised hardware devices are not generally required. This is fortunate in the context of distance learning, as lack of accessibility to dedicated hardware is not necessarily a major problem. Even so, remote CS laboratories are non-trivial to develop due to the heterogeneity of the equipment, and the diversity of competences of remote learners, After teaching an introductory Relational Databases Course for more than a decade, we have delivered the first edition of a similar course in the form of a MOOC. In addition, a laboratory environment based on Virtual Machine (VM) technology was developed to allow distant learners to practice on concrete Relational Database tools.
Scalability of existing approaches In the following, we compare the different laboratory environments with respect to the criteria identified, above, when deployed for a typical computing laboratory session, such as for our relational databases course. In table 1, we annotate positive aspects as '+', and negative aspects as '-'. Where there is no clear positive or negative tendency we note this as '+-'. It should be noted that our evaluation is based on the assumption that our primary goal is to achieve a laboratory environment that is scalable. So, for example, a traditional laboratory may be easy to configure for a small number of students but configuration will usually pose significant problems for a large number of students.
The MOOC laboratory The first edition of our MOOC on Relational Databases was hosted by Telecom SudParis (TSP) from September to November 2014 1 This course, taught in French, reused existing content and tools of a course that had already been taught for a decade to 2nd year students in the engineering curriculum. The course has gathered a peak of 1950 registered participants (including 180 students from our own institute), from around 20 countries (mostly Francophone) with 75% from France and around 15% in Africa. The MOOC was delivered on our own local installation of Moodle  (Dougiamas and Taylor, 2003) , mixing the typical resources: videos, PDF files, quizzes and links to download supporting tools for exercises and labs.
Exercises and lab tools For the needs of the course, our intention was to let participants experiment with the following tools: 1) A standalone SQL queries tutor environment available for the Safari or Chrome Web browser. This tutor environment helps students compose queries in the SQL language in a Web form. Helper widgets offer an easy access to keywords of the language or names of database artefacts extracted from the schema of the example databases (names of tables or columns). This Javascript application 2 relies on the embedded SQLite database manager, but which is only available in the WebKit engine integrated in the aforementioned Web browsers. Thus, even if it doesn't require us to install a real RDBMS to operate, it may impose an inconvenience on the user by requiring the use of a particular Web browser.
2) An alternative version of the SQL queries tutor application, with a similar interface to the standalone variant mentioned above, but implemented in the form of an HTML + Javascript and PHP application (plugged on a RDBMS). This tool has been developed over a number of years at our institute, and used to be operated on a server hosted by the IT services. Contrary to the previous approach, the main advantage of this variant is the compatibility with any Web browser, but in turn it requires a working Web server and RDBMS, which may be hard to install locally. 3) A professional grade Relational Database Management System (RDMBS), namely PostgreSQL 3 , already populated with example databases, on to which queries will be performed. 4) The phpPgAdmin application 4 , a database query and management tool adapted to Postgresql, requiring a local Web server with PHP.
5. Costwith the use of free software, no extra fees should be required to participate in the MOOC. Also, given that the MOOC resources will be released under a Creative Commons open license, the accompanying tools should be available, to the maximum extent possible for every potential need of reuse or adaptation of the MOOC; 6. Real-time support -Our design recommends real-time support, but we have yet to incorporate this functionality in our system prototype, which isn't obvious given that the VMs may be used offline. This requires further research into the use of intelligent tutoring and help systems. 7. Feedback -Our design recommends monitoring and gathering of data (on-line and off-line), but we have yet to incorporate this functionality in our system prototype. Using a cloud-based VM is very likely to impact on the type of feedback that could be generated (and the confidentiality of the data); however, using a local VM offers many opportunities for automated gathering of big data to help in profiling of individual students, as well as the whole class.
Making the VM as a Vagrant box We have chosen to experiment with Vagrant  (Hashimoto, 2013)  and VirtualBox  (Watson, 2008)  to build, distribute and finally run the Vitual Machine. Vagrant mainly provides scriptability for the generation of the box and VirtualBox ensures it is portable on most operating systems. In the following, we will refer to the VM, using the Vagrant jargon which refers to a VM image as a box. Figure  1  illustrates the process of building a box with Vagrant. The following sequence is followed during the build: 1. When the vagrant up command is executed, Vagrant loads a Vagrantfile which contains a number of Vagrant. configure blocks that are used to configure the scripts and resources to be used in the build. 2. In our configuration, these resources are fetched from the Debian packages archive and the Git repository for the laboratory applications.
3. The output of the configuration process is the Vagrant box that can be re-used by any Vagrant environment. Figure  1  -Initial provisioning to build the VM/box The OS we have selected for running inside the VM is the Debian (8. 0 aka jessie) Linux distribution, known for its stability and packaging system. The box contains a minimal Debian system which executes (in the background) PostgreSQL, Apache + mod_php, ph-pPgAdmin, and a few in-house applications of our own. Example databases are already populated in the PostgreSQL RDBMS. The VMs are intended to be run headless for the moment, keeping their size to the minimum, even though we also provide a script to install and configure a desktop environment based on XFCE4. The exercises of the MOOC section on PHP + SQL programming can be performed using a subfolder of the shared /vagrant/ folder (a standard feature offered by Vagrant).
Student feedback and evaluation Although this paper is focused on our VM architecture as a proof of concept, we have collected some relevant data with regards to our initial experimentation. It should be noted that ongoing and future use of the VM architecture will focus more on the nonfunctional requirements, and the means by which we can improve the architecture in order to facilitate the collection and analysis of usage data. It is too early in our research to fully validate all of our requirements, but our initial evaluation demonstrates that the system functions as required in the majority of cases. The total number of learners involved 6  in the MOOC was more than 1900. We did not have a means to count the number of VM downloads, but estimate -based on informal student feedback and analysis of the forum discussions -that between 5% and 10% of the learners installed and used the VM laboratory.
From these downloads we estimate that 30% were Windows users. From an estimated total of 40, around half of them reported issues. Further analysis showed that these issues were related to 4 distinct problems. Approximately 75% of the learners who reported problems required assistance in resolving them. We With regards to the option of installing Post-greSQL, approximately 10% of the learners made this choice. We are investigating the reason behind this decision, as it may signify that they had experienced (as yet unreported) problems with the other options. Overall, our initial validation of the system has demonstrated the feasibility of the approach, the correct functioning of the system for a significant majority of users, and the need for more rich data collection mechanisms. In the next version and deployment of the system, we plan to gather the usage data in an automated fashion, with focus on problem identification and resolution techniques.
The query is easy to formulate because Alice's data is stored locally and is not subject to privacy problems. However, the same computation in the context of cloud computing requires to encrypt the database. Then, Alice has to decrypt the database at her side to perform the query and encrypt the result once again, which is obviously not efficient. The second illustration shows how the composition of encryption with fragmentation can improve the query efficiency. The database is fragmented so that no privacy concerns can be violated: many queries can thus operate without any decryption overhead. However, in this case the formulation of queries is far more difficult and error-prone. Currently, compositions of privacy-ensuring strategies are programmed using traditional programming means (languages or frameworks) that do not provide any correctness guarantees.
This state-of-affairs is, however, clearly unsatisfying, leads to numerous privacy violations in the real world, and incurs steep costs for individuals as for the society as a whole. In this paper, we introduce the following contributions: • A motivation for the need of dedicated means for the correct composition of different privacyenforcing strategies, in particular, strategies based on encryption, fragmentation and client Alice 1. meetings? side computation. (Sec. 2) • A language for the declarative definition of a range of (composed) strategies for the enforcement of privacy-centric properties based on encryption and fragmentation algorithms. The language comes equipped with a set of laws that ensure a number of properties ensuring privacy-properties. (Sec. 3) • An implementation of the language in Scala that harnesses advanced typing properties in order to support the enforcement of privacy properties.
Each technique has pros and cons but, in general, they are limited, and do not offer as many guarantees as policy enforcement. For instance, data encryption fits for storage protection but not for computations and differential privacy is useful for statistical databases only. The main advantage is that they are applicable to real world problems. This article handles the privacy concern in unsupervised clouds. We show that even if each technique taking by itself is limited, the composition of such techniques is much more effective and enables the development of expressive privacy-preserving cloud applications. In the remainder of this article, we will focus on the composition of three classes of techniques: encryption, fragmentation and client-side computations.
Encryption, Fragmentation and Client-Side Computations Encryption Encryption  [Sal03]  is the process of encoding information before it is outsourced in such a way that only authorized parties can read it. Historically, encryption is the first approach to the protection of private databases in the Cloud. Using, for instance, a symmetric encryption algorithm, a client encrypts its data before outsourcing it in the cloud. All queries can then simply be executed by first returning the necessary data from the database to the client in its encrypted state, be decrypted by her, and execute the query at her side. This approach is, however, far too expensive to be practical. One solution to this problem are recent encryption schemes, so called homomorphic ones, that execute query directly on encrypted data.
Composition of Privacy-Enforcement Techniques The application Figure  1b  shows a common case in which a composition of techniques is required to obtain efficient and private application in the cloud. The application is the cloud version of the local the one (Fig. 1a ) and requires a composition of encryption, fragmentation and client-side computation. To distribute this agenda application in a privacy-preserving manner, the programmer adopts the two privacy constraints {date, address} and {name} introduced in Sec. 2. 1. A programmer then has to choose a configuration for the application that satisfies the privacy constraints. First, she may, e. g. , fragment the database in two. The first fragment contains the dates. The second contains the names and addresses. Now, the {date, address} constraint is safe unless the two fragments are joined.
Language-Support to the Rescue The above examples, as well as the large majority of real Cloud applications, require several privacy techniques to be composed. In this case, errors easily slip in. For instance, trying to encrypt twice the same column in a database does not make sense. Similarly, trying to sum values encrypted with a symmetric scheme is not reasonable. To help programmers composing privacy techniques, we propose a functional language that focuses on privacy protection and query computation. As input, we have a privacy relation and apply privacy/query functions in turn to reduce the number of components in the relation. Together with the language, a set of algebraic laws specifies how to transform a local program to a privacy-preserving distributed Cloud application. We are convinced that this formalization constitutes an appropriate abstraction to help programmers reason on query and privacy techniques composition.
Language Description Our language is based on database queries obeying relational algebra properties. A relation (i. e. , a table) is a set of tuples. For instance, an agenda stores a meeting as a triple (date, name, address) representing the meeting date, the name of the contact and the meeting location. Our language offers four query functions: • A selection σ filters tuples of a relation. For instance, lastW eekAtDesk = σ (today-date<8)∧(address=desk) keeps meetings whose date is at most a week old and has desk as meeting venue. • A projection π keeps a subset of the columns of a relation. For instance days = π date keeps only the date of meetings. • A grouping definition group groups together tuples of a relation. For instance, byDay = group date creates a group of tuples for each date.
Implementation The functional DSL for the composition of privacy-aware query-based applications introduced above permits the definition of Functional Programming (FP)-like equivalence laws and the transformation of a privacy-preserving local application into a privacy-preserving cloud application. In this section, we present our Scala-based [OSV08, CB14] framework 1  , a prototype that makes it possible to program sophisticated privacy-aware cloud applications. In particular, our implementation satisfies the laws introduced previously and harnesses Scala's type system to make application conditions explicit that are required by the laws.
From Theory to Practice One of the main differences between the DSL and the actual implementation is that we distinguish functions that compute queries from functions that change the shape of the database. In the previous section, the language uses the pointwise application of one function to the result of another, which successively reduces the database until the result is obtained. This abstraction helps reasoning on the query design. However, it misses practicality for real world programming since we do not want to reduce our database and lose components. In practice, two different levels of computation are more useful: one that uses database components to compute queries, and another one that modifies the database shape and applies protection. The programs in Fig. 3  query the number of meetings per day at the desk last week, for a local (a) and a cloud (b) application.
The local application only uses functions to query the database (σ, π, group and count). In contrast, the cloud application also composes functions for protection (crypt and fragV). The Guardian Monad. In functional programming, functions with side effects such as protection functions are performed in a monad  [Wad92a] , a pattern that makes it easy to chain function calls. In particular, FP deals with side effects using a state monad  [Wad92b]  that attaches state information to function calls. For this reason, our framework provides a state monad suitable for our purposes. Our state monad, called guardian, is defined based on the following requirements: • The state is the database. • Query functions only access the components of the database. The application of a query function returns some result that can be used as input for a second query, without modifying the database.
For instance, the selection in figure  3a  accesses the content of the database and returns the result in r1 (line 4). Values in r1 are then used for the projection (l. 5) and so on, until the count operation (l. 7). At the end of the program (l. 9), the q variable gets the result of the query. But, the database remains the same as in input. 1 for { 2 _ <-configure [Date ,Name , Addr ] 3 q <-query (db => { 4 val r1 = σ (db) ( lastweek 5 ∧ atdesk ) 6 val r2 = π (r1) ( date ) 7 val r3 = group (r2) ( date ) 8 val r4 = count (r3 ); r4 9 }) 10 } yield q (a) Local Application 1 for { 2 _ <-configure [Date ,Name , Addr ] 3 _ <-crypt (_2 ) ( HEq (_)) 4 _ <-fragV (_1 ) ( Site1 (_), Site2 (_)) 5 qL <-queryL ( fragL => { 6 val r1 = σ ( fragL ) (σ lif t lastweek ) 7 val r2 = π (r1) (π lif t date ) 8 val r3 = group (r2) ( date ); r3 9 }) 10 qR <-queryR ( fragR => { 11 val r1 = σ ( fragR ) (σ lif t atdesk ) 12 val r2 = π (r1) (id ); r2 13 }) 14 } yield count ( gather (qL , qR )) (b) Cloud Application • Protection functions only modify the shape of a database.