dataesr/scientific-paragraphs-categorization huggingface dataset:
For the seasonal cycle, we compared modelled GPP seasonality to both MODIS-GPP and GOME-2 SIF data. ORCHIDEE-GM v3. 1 captures the seasonal variation of productivity in most regions where grassland is the dominant ecosystem (coverage > 50 %), as shown by the high r seasonal between GPP model and MODIS-GPP (Fig. S6a ) or SIF data (Fig. S6b ). However, the model does not capture the seasonal amplitude of grassland productivity in some arid/semi-arid regions (e. g. southwestern United States and central Australia; Fig. S6a  and b ). In arid/semi-arid regions, grass productivity is triggered by discrete precipitation events and depends on the timing and magnitude of these pulses  (Sala et al. , 1982; Schwinning and Sala, 2004; Huxman et al. , 2004). These precipitation pulses are infrequent, discrete, and not represented in a global climate re-analysis dataset such as CRU+NCEP used in our simulation.
Data availability The ORCHIDEE model used as a starting point in this study is ORCHIDEE rev2425. The source code can be obtained at http://forge. ipsl. jussieu. fr/orchidee/browser/trunk# ORCHIDEE. A detailed documentation and the forcing data needed to drive ORCHIDEE can be found at http://forge. ipsl. jussieu. fr/orchidee/wiki/Documentation and http://forge. ipsl. jussieu. fr/orchidee/wiki/Forcings. ORCHIDEE-GM v3. 1 is derived from rev2425 with the modifications presented in Sect. 2. 1 and the previous studies  (Chang et al. , 2013 (Chang et al. , , 2015a, b), b) , the source code of which can be obtained upon request (http://labex. ipsl. fr/orchidee/index. php/contact). CRU-NCEPv4 climate forcing is available at http://dods. extra. cea. fr/data/p529viov/cruncep/readme. htm. The EC-JRC-MARS database (European Commision -Joint Research Center -Monitoring Agricultural ResourceS) can be accessed at https://ec.
europa. eu/jrc/en/mars. The data on ruminant numbers come from several sources: for the period 1961-2012, data were derived from FAO-STAT (2014) (http://faostat3. fao. org/); for the period 1901-1960, data were available from the HYDE database at http://themasites. pbl. nl/tridion/en/themasites/hyde/ landusedata/livestock/index-2. html and derived from literature estimates by  Mitchell (1993 Mitchell ( , 1998a, b), b). The Köppen climate zones are classified based on  Peel et al. (2007)  using climate data from WorldClim  (Hijmans et al. , 2005;  available at http://www. worldclim. org/). The Supplement related to this article is available online at doi:10. 5194/bg-13-3757-2016-supplement.
Acknowledgements. We thank the editor and the two anonymous referees for their valuable review comments, which helped to greatly improve the paper. We gratefully acknowledge funding from the  European Union Seventh Framework Programme   FP7/2007-2013  under grant no. 603864  (HELIX). Philippe Ciais  and  Shushi Peng  acknowledge support from the  ERC Synergy  grant  ERC-2013-SyG-610028 IMBALANCE-P. Matteo Campioli  is a postdoctoral fellow at the  Research Foundation -Flanders (FWO). Chao Yue  is supported by the  European Commissionfunded  project  LUC4C  (grant no. 603542 ). Tao Wang is funded by  European Union   FP7-ENV  project  PAGE21  (grant no. 282700 ). We thank those who developed the  EC-JRC-MARS dataset ( © European Union ,  2011-2014 ) created by  MeteoConsult based on ECWMF (European Centre for Medium Range Weather Forecasts ) model outputs and a reanalysis of  ERA-Interim.
Moreover, current systems don't support "follow-me" scenarios, where traveling patients might require treatment away from their usual residence, potentially relying on new practitioners and CDOs (see Figure  1 ). Single provider clouds can't meet these challenges. First, data processing has strict requirements in terms of location awareness. In addition, single-provider availability guarantees might not be sufficient in medical environments. Quality of service (QoS) is also impacted by latency, increasing with distance between service users (such as patients and doctors) and the datacenter. Finally, cloud providers must be trustworthy given the privacy issues related to medical data. To overcome such limitations, healthcare services should rely on multiple cloud providers. A multiprovider approach brings both benefits, in terms of geolocation, availability, and QoS; and challenges, such as the need for consistent quality of protection (QoP) across providers.
3 Deployed services usually leverage a three-tier application structure with SQL/ NoSQL databases, application servers, and frontends on top of infrastructure abstractions (virtual machines [VMs], object/block storage, and virtual networking) supported by the cloud provider. Given the heterogeneity of actors and applications, each tier is usually split into cooperating subcomponents (microservices) and services, following the serviceoriented architecture (SOA) approach. We consider a simpler scenario in which patients move among locations and thus need to perform telemedicine operations (such as remote treatment, periodic self-treatment and monitoring, and (EHR) access) using mobile devices, while CDO services are geographically fixed in the CDOs' private clouds. The application orchestration logic can retrieve the actual geolocations of the services and patients through the front-end application and device capabilities (such as GPS).
CLOUD 4ELE storage) but also for high-level services, such as database management systems as a service (DBMSaaS) or load balancer as a service (LBaaS), offloading operational complexity from developers. However, the use of these complementary services creates a de facto lock-in that introduces a strict dependency between cloud customer and provider. In addition, similar services might encourage customers to remain inside the provider realm since transferring data inside the same provider region is free or inexpensive. Therefore, interoperability at the IaaS level can hide the complexity of compatibility layers on different providers. However, the orchestration logic could effectively deploy multiprovider applications, since all requirements can be handled with a precise knowledge of subcomponent interactions, which is possible at the application orchestration level.
Nested virtualization is a system architecture in which the guest operating system virtualizes a nested guest. 6 This extra level of virtualization can be executed through nested hardware-assisted full virtualization  6  or paravirtualization over hardwareassisted virtualization. 5 Performance has always been an impeding factor for massive adoption of such techniques. However, some recent work shows more acceptable overhead. 5, 6 ontainers are user-space environments on an operating system providing isolation between them and host resources. 7 Resource isolation is achieved using new kernel functionalities (for example, cgroups and Linux namespaces). However, containers still suffer from major isolation concerns due to Linux kernel sharing and achieve weaker isolation than VMs. Recent work has also shown that overlay containers don't significantly degrade performance.
Experimental Results We built a proof-of-concept prototype of the basic overlay template cloud based on OpenStack and Mesos (see Figure  3 ). We leveraged Xen, Linux Containers (LXC), and the Kernel-based Virtual Machine (KVM) as basic virtualization technologies. The management layer is based on OpenStack, which supports those virtualization technologies Open-Stack is integrated with an overlay OpenDaylight as the SDN controller. We realized a first implementation of Mantus and Stratopause in a simpler scenario, where a developer can trigger deployment of Orbits on a select number of providers without considering the patient's location; instead, the focus is on enriching security services and deploying a uniform infrastructure layer. The Mantus orchestration workflow proceeds as follows. In the first step, service definition, Mantus uses a code description to automate infrastructure resource provisioning and configuration, which provides benefits in terms of reproducibility and maintenance.
Figures  5a  and 5b  compare nested virtualized execution environments (VM plus containers), single-layer VMs, and a bare-metal system. Degradations are concentrated in the nested KVM setting, where overhead  often exceeds 50 percent compared to the baseline. LXC performs quite well and can be considered a viable solution to introduce a user-controlled virtualization layer. As Figures  5c  and 5d  show, we tested the scalability of nested execution environments when increasing load in a WordPress application. A WordPress application, like many healthcare applications,  3  relies on a Web front end, a server-side application logic, and access to a database, and could be used as a generic and representative benchmark. From the perspective of both throughput and elapsed time, Xen and LXC perform well, keeping overhead below 20 percent.
Moreover, these methods are application dependent, i. e. require a specific programming language and/or implement one plugin for each application which is not ideal for complex task involving several applications. Conversely, screen recording while users carry their task  [7]  provides a lot of information, but requires to carefully watch and manually annotate the video, which is tedious and not precise enough for studying low-level interactive phenomena (e. g. , duration of scrolling actions). We propose the InspectorWidget, an opensource application to track and analyze users' behaviors in any closed application by combining computer vision based analysis of video-recording with low-level interaction collection. InspectorWidget has four key features. 1) It works with all applications, in particular closed applications where the source code is not available, or applications that do not offer plugins support.
Design Goals: Observing Applications' Usage To better understand users' need and practices, we conducted an informative study with 4 experts. We interviewed two HCI researchers, one usability consultant and one software developer to cover different class of users. Based on these interviews, we present five design goals and discuss related works according to these design goals (tables 1 and 2 summarize these goals and compare existing systems). Collect diverse data. Understanding subtle interactions generally requires to study both users' actions (e. g. mouse, key events) and the semantics of the interface (e. g. menu, buttons). It is thus necessary to collect diverse data such as: • keylogging or macro recording, for low-level interactions such as mouse or keyboard events;  • widgets and states changes logging, for applications implementing accessibility Application Programming Interfaces (APIs) that are specific to operating systems; or applications providing their own information (e.
g. Document Object Model (DOM)). • screencasting, to get a video record of the interface. AppMonitor  [5]  combines the two first methods to monitor Microsoft Word and Adobe Reader. However, it requires two different implementations as the "accessibility monitor" differs between these two applications. The Autodesk Screencast based on the Chronicle project  [10]  is a powerful tool combining the three methods but it is limited to Autodesk applications only. Screen capture software such as ScreenFlow record both video and key events, events can be overlaid on the video but not exported as raw data.      Delta [12]   Morae 3. 3 [3]                     Patina [13]    Prefab [9]        Chronicle/Screencast [10]        Sikuli [8]           Waken [6]    InspectorWidget []                    Automate diverse annotations.
Example scenario Suzanne is a HCI researcher interested in color selection and wants to know which color tool (colorwheel, spectrum, etc. ) users prefer when selecting colors. She installs Inspector-Widget on the computers of 2 designers using respectively Photoshop and PowerPoint and starts the record mode. At the end of the day, she retrieves the recordings. Suzanne then uses Inspec-torWidget to record herself selecting the different tools on her own computer in both Photoshop and Powerpoint and uses that recording to program the annotations she wants to perform with InspectorWidget. To achieve this, she first draws a bounding box around each tab of each color picker windows when selected. She then uses visual programming to program InspectorWidget that automatically annotates users' recordings to find the exact time a specific color tool was used.
Concept Analyzing user's behaviors with closed applications using InspectorWidget follows a five-step workflow: 1) record activity, 2) browse and 3) program annotations, 4) automate annotations and 5) analyze the results (figure  1 ). Record activity. First, the experimenter records the screen and logs events to track users activity. Screen recording and interaction events logging are usually separated into two tools, making the observation process cumbersome and the collected data harder to synchronize. We solve this problem by proposing a cross-platform desktop tool that both records the content displayed on screen(s) and logs low-level interaction events (mouse and keyboard). Browse and Program annotations. The experimenter then programs annotations. In practice, she browses a recording to find a time frame where the system was in a specific state she is interested in (figure  2 ).
These graphical widgets are always displayed in the color tool window (E) and can be tracked using visual programming (figure  3 ) to retrieve the size and location of the window even if it has been moved or resized. Note that browsing the video to locate the time where the interface is a in specific state (e. g. the color picker is displayed) might be a difficult task because the experimenter does not know exactly when the interface was in this state, or because it is possible that the interface was never in this state. For this reason, the experimenter sets the interface in the correct states on her own computer and then records it. She can also program the annotations and use these as an input for InspectorWidget to annotate all users' recordings. Automate annotations. Once all annotations have been programmed, the experimenter clicks on "automatic annotation" to instruct InspectorWidget to start the automatic annotation process, using computer vision and the recorded low-level and programmed annotations as inputs (see below for implementation details).
Implementation InspectorWidget is composed of a cross-platform desktop application for recording, a dedicated server for automating annotations, and a web-based application for browsing the recordings, programming annotations and analyzing the results. InspectorWidget is released as an opensource project under a GPLv3 license, available on github  1. Recording (standalone application). Our tool extends application obs-studio  [2]  with a plugin for logging input events (mouse and keyboard) using the libuiohook  [1]  library. It supports recording multiple screens and cameras, all mouse and key events, and audio. Browse recordings, program annotations. Browsing recordings and programming annotations is achieved through a dedicated web-based application, based on the amalia javascript video player  [11]  for browsing and enriching the video with annotation, and based on Google Blockly (inspired by Scratch  [14] ) for programming the annotations.
Acknowledgments The authors would like to thank  Nicolas Riche  for bridging their collaboration. This work has been partly funded by the  Walloon Region of Belgium through GREENTIC  grant  1317970  for project SONIXTRIP. The authors would like to thank the  SONIXTRIP  project partners for their feedback while developing InspectorWidget:  Dame Blanche  postproduction studios,  Océ Software Laboratories and IRiSib Laras lab.
Introduction EVALITA  1  is the evaluation campaign of Natural Language Processing and Speech Tools for the Italian language. The aim of the campaign is to improve and support the development and dissemination of resources and technologies for Italian. Indeed, many shared tasks, covering the analysis of both written and spoken language at various levels of processing, have been proposed within EVALITA since its first edition in 2007. EVALITA is an initiative of the Italian Association for Computational Linguistics 2  (AILC) and it is endorsed by the Italian Association of Speech Science 3  (AISV) and by the NLP Special Interest Group of the Italian Association for Artificial Intelligence 4  (AI*IA). Following the success of the four previous editions, we organised EVALITA 2016 around a set of six shared tasks and an application challenge.
Making Cross-task Shared Data As an innovation at this year's edition, we aimed at creating datasets that would be shared across tasks so as to provide the community with multi-layered annotated data to test end-to-end systems. In this sense, we encouraged task organisers to annotate the same instances, each task with their respective layer. The involved tasks were: SENTIPOLC, PoSTWITA, NEEL-it and FactA. The testsets for all four tasks comprise exactly the same 301 tweets, although Sentipolc has a larger testset of 2000 tweets, and FactA has an additional nonsocial media testset of 597 newswire sentences. Moreover, the training sets of PoSTWITA and NEEL-it are almost entirely subsets of SENTIPOLC. 989 tweets from the 1000 that make NEEL-it's training set are in SENTIPOLC, and 6412 of PoSTWITA (out of 6419) also are included in the SENTIPOLC training set.
Raising Interest and Collecting Suggestions on the EVALITA Evaluation Campaign 1 Introduction EVALITA is a periodic evaluation campaign of Natural Language Processing (NLP) and speech tools for the Italian language that has been organized around a set of shared tasks since 2007  1. Examples of tasks organized in the past EVALITA campaigns are: Named Entities Recognition (NER), Automatic Speech Recognition (ASR), and Sentiment Analysis  (Attardi et al. , 2015). At the end of the evaluation, a final workshop is organized so to disseminate the results providing participants and organizers with the opportunity to discuss emerging and traditional issues in NLP and Speech technologies for Italian. Over four editions  (i. e. 2007, 2009, 2011 and 2014) , EVALITA organized more than 30 tasks receiving almost 150 submissions from 90 different organizations: among them 31 (34.
At the same time, the need for a greater internationalization of the campaign, looking for tasks linked to the ones proposed outside Italy, was highlighted. Panelists also wished for an effort in future campaigns towards the development of shared datasets. Being the manual annotation of data a cost-consuming activity, the monetary contribution of the Italian Association for Computational Linguistics 9 (AILC) was solicited. The chairs of EVALITA 2016 10 introduced in the organization of the new campaign novel elements, aimed at addressing most of the issues raised by both the questionnaires and the panel  (Basile et al. , 2016b). EVALITA 2016 has an application-oriented task (i. e. , QA4FAQ) in which representatives of three companies 11 are involved as organizers  (Caputo et al. , 2016). Another industrial company 12 is part of the organization of another task, i.
I will also go into the many problems in this subfield of profiling; for example the unreliability of the gold standard data, the shaky scientific basis of the personality typologies proposed, and the low accuracies achieved for many traits in many corpora. In addition, as is the case for the larger field of profiling, we are lacking sufficiently large balanced corpora for studying the interaction with topic and register, and the interactions between profile dimensions such as age and gender with personality. As a first step toward a multilingual shared task on personality profiling, I will describe joint work with Ben Verhoeven and Barbara Plank on collecting and annotating the TwiSty corpus  (Verhoeven et al. , 2016). TwiSty (http://www. clips. ua. ac. be/datasets/twisty-corpus) contains personality (MBTI) and gender annotations for a total of 18,168 authors spanning six languages: Spanish, Portuguese, French, Dutch, Italian, German.
Introduction In the last five years ASR technology has achieved remarkable results, thanks to increased training data, computational resources, and the use of deep neural networks  (DNNs, (LeCun et al. , 2015) ). However, the performance of connectionist ASR degrades when testing conditions are different from training conditions (e. g. , acoustic environments are different)  (Huang et al. , 2014). This is usually referred to as the training-testing mismatch problem. This problem is partly masked by multi-condition training  (Seltzer et al. , 2013)  that consists in using very large training datasets (up to thousands of hours) of transcribed speech to cover as many sources of variability as possible (e. g. , speaker's gender, age and accent, different acoustic environments). One of the two main goals of the ArtiPhon task at Evalita 2016 was to evaluate phone recognition systems in mismatched speaking styles.
Between training and testing data the speaking style was the condition that differed. More specifically, while the training dataset consists of read speech where the speaker was required to keep a constant speech rate, testing data range from slow and hyper-articulated speech to fast and hypo-articulated speech. Training and testing data are from the same speaker. The second goal of the ArtiPhon task was to investigate whether the use of speech production knowledge, in the form of measured articulatory movements, could help in building ASR systems that are more robust to the effects of the mismatch problem. The use of speech production knowledge, i. e. , knowledge about how the vocal tract behaves when it produces speech sounds, is motivated by the fact that complex phenomena observed in speech, for which a simple purely acoustic description has still to be found, can be easily and compactly described in speech production-based representations.
Data The training and testing datasets used for the ArtiPhon task were selected from voice cnz of the Italian MSPKA corpus (http://www. mspkacorpus. it/) (Canevari et al. , 2015) , which was collected in 2015 at the Istituto Italiano di Tecnologia (IIT). The training dataset corresponds to the 666utterance session 1 of MPSKA, where the speaker was required to keep a constant speech rate. The testing dataset was a 40-utterance subset selected from session 2 of MPSKA. Session 2 of MPSKA contains a continuum of ten descending articulation degrees, from hyper-articulated to hypo-articulated speech. Details on the procedure used to elicit this continuum are provided in  (Canevari et al. , 2015). Articulatory data consist of trajectories of 7 vocal tract articulators and recorded with the NDI (Northern Digital Instruments, Canada) wave speech electromagnetic articulography system at 400 Hz.
Sub-tasks In Artiphon sub-tasks are phone recognition tasks. The participants were asked to:  train phone recognition systems on the training dataset and then run them on the test dataset;  (optional) use articulatory data to build "articulatory" phone recognition systems. Articulatory data were also provided in the test dataset thus three different scenarios were possible:  Scenario 1. Articulatory data not available  Scenario 2. Articulatory data available at both training and testing.  Scenario 3. Articulatory data available only at training. Note that only scenarios 1 and 3 are realistic ASR scenarios as during testing articulatory data are very difficult to access. Participants could build purely acoustic and articulatory phone recognition systems starting from the Matlab toolbox developed at IIT, available at https://github.