dataesr/scientific-paragraphs-categorization huggingface dataset:
Modern ICT solutions are capable of assisting dependent people at home and therefore able to replace the physical presence of a caregiver. However, the success of such solutions depends on an intuitive access to services. By proposing a speech-operated system and devices that facilitate this voice-based interaction, vAssist aims at a solution that corresponds to a virtual butler. The goal is to build a system with whom elderly users can interact naturally and even build up a social connection. Integrating modern language technology with a human-operated call center should allow for coping with current imperfect solutions and consequently offer the necessary reliability and user experience. vAssist is planned to be launched for German, Italian and French.
THE VASSIST PROJECT vAssist 1  is a European research project funded by the Ambient Assisted Living Joint Program 2  which aims at providing multilingual voice controlled home care and communication services for seniors who suffer from chronic diseases and/or (fine-) motor skills restrictions. The goal of the project is to develop an adaptive communication interface that allows for a simple and efficient interaction with elderly users. While vAssist's main focus lies on providing predominantly speech-based access to services, GUIs will also be available, in particular for situations in which a rather traditional interaction paradigm is more appropriate (e. g. interactions in public places). Furthermore, in order to lower potential adoption barriers as well as to reduce service-delivery costs, vAssist aims at using hardware platforms that often already exist in users' homes (e.
The Spoken Dialog System A Spoken Dialog System (SDS) is the integration of a dialog system whose core component is the Dialog Manager (DM) connected to speech input and output modalities  (Milhorat et al. , 2012). Such a software engages the user in an exchange of information in order to access back-end services, store user data in an organized and reusable way or simulate a conversational partner. A way to characterize a dialog system is with its input and output modalities available for interaction. This may include speech, text, gestures, or possibly a touch screen. In the case of speech, a further distinction can be made between command-and-control, keyword-based or natural language-based interaction. The first one may not be considered as "interacting" with an SDS since it only represents the association of well-defined spoken commands to actions to be undertaken by the system.
A keywordbased system extends those associations by the context of the interaction as maintained by the DM. The interpretation of user utterances is based on single-word pattern detection. Keywords need to be carefully selected to avoid overlaps between intents. This paradigm therefore does not allow for subtle nuances with respect to the input that can be understood. Moreover it is very sensitive to speech recognition errors. In the case of vAssist, the system  (Milhorat et al. , 2013a)  is communicating with the user via natural speech, thus it does not require the user to learn a set of available commands nor a set of keywords. Instead, the natural language understanding components  (Milhorat et al. , 2013b)  attempt to extract a meaning representation out of the word-level utterance using the external context, the internal context and some previously learned knowledge.
The obtained representation (e. g. a semantic frame) is interpreted by the DM which calls back-end services and produces outputs to the user, such as requests for more information, or the meaningful represented results of service calls. As mentioned previously, speaking to a piece of technology, using natural language, may be disturbing; even to some extend uncomfortable. However, early trials of the simulated Wizard of Ozbased system  (Schlögl et al. , 2013b ) produced encouraging feedback. The users' learning curves using the system proved to be steep. They highlighted the easiness of using the SDS (compared to a graphical interface) but pointed out the slow pace of the dialog progress. This was caused by several factors: (1) the slow communication with remote services, (2) the DM processing time and (3) the speed of the human operator (i.
The smartphone: a mobile hub vAssist offers GUI-based Android smartphone applications, such as a DailyCare and a Pillbox app. Most of the time, however, the smartphone is used as a data communication hub for vocal interaction Figure  1 : vAssist device ecosystem (i. e. VUI) or to connect to other devices such as the Ambulatory Terminal (AT). Hardware connections are established using the Bluetooth 4. 0 Low Energy standard 3  which consequently helps to improve the life span of built-in batteries. Hands free kits communicate via the standard Advanced Audio Distribution Profile (A2DP), the Hands-Free Profile (HFP) and the Headset Profile (HSP) 1. 1. The connection with vAssist remote services is maintained through Wi-Fi when the user is at home, and through a mobile data connection when he/she is out of the home.
We thus tested for the possibility of recombination within the gene families using the methods implemented in the RDP4 software suite  (Martin et al. 2010). Care must be taken, however, when assessing the impact of recombination among divergent proteins, as the recombination signal is quite error prone when proteins share less than 70% similarity, and these methods are heavily dependent on the alignment  (Martin et al. 2010). We detect some recombination events between members within the PEX and NEX gene families; however, the majority of the predictions are only marginally significant (the consensus scores are below the confidence threshold of 0. 6). In the  Domman et al. doi:10. 1093/molbev/msu227 MBE NEX1a family, the portion of the sequences most identified as recombinant is the F-box domain (supplementary fig.
2010) , and Critica v1. 05  (Badger and Olsen 1999)  with homology information derived from a BLAST search against National Center for Biotechnology Information nonredundant protein database (NCBI Resource Coordinators 2014). RNA genes were called by tRNAscan-SE  (Lowe and Eddy 1997) , RNAmmer  (Lagesen et al. 2007), and Rfam (Griffiths-Jones et al. 2005). Function prediction was performed via BLAST against the UniProt database (UniProt Consortium 2014), and domain prediction was performed via InterProScan 5  (Jones et al. 2014). Completeness estimates were performed based on the presence of single-copy marker genes (n = 54) found in 99% of all bacterial genomes. Sequences have been deposited at Genbank/EMBL/DDBJ under accession numbers PRJNA242498, PRJNA242497, PRJNA242499, and PRJNA242500.
In all cases, the Bayesian trees yielded the most support, which were calculated on the CIPRES gateway  (Miller et al. 2010)  with MrBayes as mentioned above for the species tree. For protein domain phylogenies, we extracted and aligned the domains using the hmmalign program from HMMER3 package  (Eddy 2011) , and phylogenetic trees for the domains were calculated using FastTree2  (Price et al. 2010). Reconciliations of gene trees to the species tree to infer gene gain and loss were performed in Notung v2. 6  (Stolzer et al. 2012) , and the root for the gene trees was assigned within the program to MBE achieve the lowest duplication-to-loss ratio. Phylogenetic trees were visualized using iTOL  (Letunic and Bork 2007)  or the ETE2 toolkit  (Huerta-Cepas et al. 2010). Alignment and tree files are available as supplementary material, Supplementary Material online.
Detection of Selection and Recombination Whole-protein alignments were converted to codon alignments via the Pal2Nal program  (Suyama et al. 2006). To detect the mode of selection acting on these gene families, we used CodeML from the PAML package  (Yang 2007). Only sequences that were nearly full length and not contig fusions were used for the CodeML analysis. We additionally used the modified Nei-Gojobori method for codon selection from the MEGA v5. 1  (Tamura et al. 2011)  program with 1,000 bootstraps and treating missing data with pairwise deletions. We used the RDP4 software suite  (Martin et al. 2010 ) to detect recombination events, which is an amalgamation of many individual recombination programs linked into one software architecture. We employed seven recombination detection programs that include RDP  (Martin and Rybicki 2000) , GENECONV  (Sawyer 1989) , MaxChi  (Smith 1992) , BootScan  (Martin et al.
Domain Distribution For each domain of interest, we downloaded the Pfam HMM model  (Finn et al. 2013 ) and scanned all chlamydial proteomes using the hmmscan program from the HMMER3 suite  (Eddy 2011 ). In the case of the F-box and F-box-like domains, the results were combined into a nonredundant list. The data for the other taxa were obtained through the Pfam website under the species distribution tab for each domain or clan as in the case for the F-box. The networks were created using the "arcdiagram" package in R.
A monoclonal antibody against Cya and polyclonal antibodies against CRP and IpaD were generously provided by Drs N. Guiso, A. Ullmann, and C. Parsot, respectively (Institut Pasteur, Paris). Prediction of type III secretion was performed via the Effective database  (Jehl et al. 2011 ) and the PSORTb webserver  (Yu et al. 2010 ).
Acknowledgments Thomas Penz  and  Gabriele Schwammel  are acknowledged for isolating genomic DNA. This work was supported by  Austrian Science Fund FWF  grants  Y277-B06  and  I1628-B22 ;  European Research Council ERC StG EVOCHLAMY  (281633); and  Marie Curie Initial Training Network Symbiomics. Genome sequencing was performed at the  Norwegian Sequencing Center.
The use of patterns enables designers to model their specific adaptive systems and gives them the freedom to insert additional options that have not been specified in the design. Moreover, a complete self-adaptive system is composed of the five modules of the adaptation loop. However, being scalable and extensible, our solution enables the designers to specify their own self-adaptive systems using the modules they need. They have the liberty to remove modules from the loop or add specific information to it. We prove this benefit through case studies illustrating different use of the patterns. In addition to these contributions, an extended version of the adaptation loop has been proposed by adding the Assessor module to the MAPE loop in order to enable the evaluation of its behavior. Another novelty of this work is that patterns are described using the unified modeling language (UML) models that are annotated using the MARTE (modeling and analysis of real-time and embedded systems)  [9]  profile.
The MARTE profile permits the jointly modeling of the hardware and software parts of embedded systems using a rich terminology for the specification and analysis of RTE systems. The above benefits have been illustrated through the application of our patterns to different examples of self-adaptive RTE systems. The remainder of this paper is organized as follows. Section 2 surveys relevant related works in the adaptive embedded systems field. Section 3 introduces the RTE systems domain through the description of the external adaptation approach and the presentation of an architectural view of the extended MAPE loop. The description of the five proposed patterns is then given in Section 4. In Section 5, we illustrate, through two case studies, the patterns utilization for the specification of different selfadaptive RTE systems with different patterns combination.
Details about the previously cited works may be found in  [5]. In addition to the above approaches, several projects  [24, 25]  have been realized in the literature to help guide and ease self-adaptive systems development. Researchers have equally developed middleware  [26] [27] [28] , frameworks  [29, 30] , languages  [31] , and tools  [32]  for this aim. CARISMA (contextaware reflective middleware system for mobile applications)  [27]  and MADAM (mobility and adaptation enabling middleware)  [26]  offer adaptation middleware to facilitate the development of mobile applications. CARISMA exploits the principle of reflection to enable mobile application to dynamically adapt to context changes. It also offers a conflict resolution approach that treats conflicts that may be incurred by the reflective behavior.
A software sensor is defined by a software task running concurrently on the system to measure a system property, such as CPU usage, and notify a Monitor. It is thus stereotyped as "SwSchedulableResource" and "NotificationResource. " A notification resource is a software synchronization resource used to notify events. To keep events history, the notified occurrences can be memorized in a buffer by setting the policy attribute value to "memorized". Since we are in the context of real-time and embedded systems, two basic issues have to be taken into consideration: the concurrency and the realtime features. In order to handle these issues, we annotate the active classes by the HLAM "RtUnit" stereotype  [9]  indicating that it is a real-time unit. An RtUnit is an autonomous execution resource that may own one or more schedulable resources and one or several behaviors.
(iv) The Monitor is an "RtUnit" that is associated with each ContextElement. It examines sensing data using minimum and maximum values stored in a Threshold to decide if a significant variation has occurred or a certain threshold has been exceeded. Threshold may represent either interval limits indicating a regular status or allowed variation margins to be used to decide about the variation relevance. If a variation is relevant, the Monitor generates a variation event, stereotyped as "NotificationResource. " For the sake of system stability when self-adapting, it is recommended to define an adaptation period in order to manage the adaptation mechanism occurrence. Commonly, this period is equal to a defined number Ne of application iterations  [12]. At every period, the monitoring module starts a control session and then the adaptation cycle is executed.
Adaptation cost refers to the worst case execution time (WCET) and required resources of adaptation modules. In our case, the adaptation cost is equal to the cost of deciding and acting modules which necessitate time to find the best adaptation solution and then apply the changes on the system. We suppose that the cost of the other loop modules is negligible. In order to capture the adaptation cost, we use the "ResourceUsage" stereotype which offers a set of nonfunctional properties representing consumed amounts of resources, such as the WCET taken from a computing resource, the used memory, and the consumed energy. (ii) ConfigurationManager is the generalization of adapt-ableSystem and ChangeableElement. It is an "RtUnit" responsible for the management of adaptableElements configurations.
In fact, the configuration selection is modeled by state machines composed of a set of modes and transitions between them. The triggering of an event ensures the transition from one mode to another. To model global adaptation decision, we use MARTE capabilities for reconfigurable systems modeling defined by the modal behavior model of the CommonBehavior package  [9]. A state machine, stereotyped as "ModeBehavior, " is used to model the dynamics of the adaptable system configurations. It is composed of a set of mutually exclusive modes, stereotyped as "Mode, " each characterized by a configuration, and transitions between modes, stereotyped as "ModeTransition. " As for the design of local adaptation decision, we use the MARTE extension proposed in  [43]  for the design of software fine-grain adaptation in RTE systems.
Behavioral View. The behavior of the RTE Assessor pattern is represented by Figure  12. The Assessor evaluates performance Metrics, such as adaptation cost, and analyzes a repository of AdaptationHistory to make statistics. Based on these calculations, it generates via the assess() method an assessment Report according to which it adapts the adaptation engine by acting on some Control Parameters through the adjust() method. For example, having noticed a high adaptation overhead, the Assessor augments the monitoring period or raises the analyzing thresholds in order to guarantee system stability. The Assessor is an RtUnit which may run its job either periodically, at every predefined period, or aperiodically after every adaptation loop execution. We give the designer the liberty to choose the occurrence kind of the assessment module.
Introduction Ever-increasing numbers of atmospheric observations from orbiting spacecraft, and increasingly sophisticated numerical models, have recently permitted data assimilation techniques to be applied to planets beyond Earth. A meteorological 'reanalysis' is the application of a single consistent scheme to assimilate data spanning an extended historical period. Mars is the first extraterrestrial planet for which reanalyses of the atmospheric state are now available  (Montabone et al. , 2006a; Lewis et al. , 2007; Greybush et al. , 2012; Lee et al. , 2013). The Thermal Emission Spectrometer (TES)  (Christensen, 2001)  on board NASA's Mars Global Surveyor (MGS) has produced an extensive atmospheric dataset during its scientific mapping phase between February 1999 and August 2004. The well-sampled spatial and temporal coverage given by the 2-h, sun-synchronous polar orbit has permitted the observation of Mars at local times centred around 2 AM and 2 PM (at tropical and mid-latitudes), while displacing about 30°in longitude at each new orbit, corresponding to about 12 complete orbits per mean solar day.
Thermal profiles for the atmosphere up to about 40 km altitude and infrared column dust optical depths (almost entirely limited to daytime) have been retrieved from TES absorption spectra in nadir view, among other products  (Smith, 2004). These data cover almost three complete Martian seasonal cycles, 1  from late northern summer in MY 24 to late northern spring in MY 27. 2  This dataset of global atmospheric observations is ideal for data assimilation into a global climate model. We have, therefore, used it to produce the 4-year (MY 24-27) reanalysis of the atmosphere of Mars which is described in this article. The use of this reanalysis for scientific studies has already led to several publications. In particular, here we mention those on the interannual variability in dust storms  (Montabone et al.
, 2005)  and their impact on the landing of NASA's Mars Exploration Rovers as well as ESA's Beagle 2  (Montabone et al. , 2006b) , on the interannual variability in thermal tides  (Lewis and Barker, 2005) , on a teleconnection event during the planetencircling dust storm in 2001  (MY 25, Mart ınez-Alvarado et al. , 2009) , on the radiative effects of tropical water ice clouds  (Wilson et al. , 2008) , and on Martian weather predictability  (Rogberg et al. , 2010). More recent ongoing work involves the use of the MGS/TES Mars Analysis Correction Data Assimilation (MACDA) reanalysis for the study of the solstitial pause in the intensity of high latitude baroclinic waves, studies of the Martian boundary layer, and the interannual variability in polar vortex dynamics and atmospheric angular momentum.
In Section 2, we summarize key information about the MGS/TES observations, the global climate model and the data assimilation scheme that we have used. Section 3 is devoted to the description of the MACDA MGS/TES v1. 0 dataset. In Section 4 we describe the available web interface for the dataset visualization. How to access the database and the visualization tool is detailed in Section 5. Finally, we mention future improvements of the database in Section 6.
MGS/TES Observations and Data Assimilation TES nadir retrievals of thermal profiles and total (i. e. integrated over the whole atmospheric column) dust optical depths have been analysed by assimilation into a Mars global climate model (MGCM), making use of a sequential procedure known as the Analysis Correction (AC) scheme. This is a form of successive corrections method which was originally developed for Earth data assimilation at the Meteorological Office (Met-Office) in the UK  (Lorenc et al. , 1991). Only a limited number of TES limb profiles are available  (Smith et al. , 2001) , which are not used in the current assimilation. Our reanalysis of TES retrievals, therefore, does not include observations of temperature above about 40 km altitude. TES retrievals of absorption-only column dust optical depth are in the infrared (wavelength around 1075 cm À1 , or 9.
Lack of coverage in dust optical depth observations is less critical, except for the column-integrated dust optical depth field we provide in the database, which is obviously affected. Users of the MGS/TES MACDA v1. 0 database should, therefore, refer to Figures  1  and 2 , and check the provided NetCDF file, to verify the observation coverage. This is particularly the case when dataset variables show sudden changes, which might originate from transitions to free-running GCM states. Data gaps in the NetCDF file provided as supporting information are clearly identified as zeros (white) in the number of available observations. The MGCM used to produce the dataset described in this article is an earlier version of the spectral GCM Lewis and Read (1995) and  Lewis et al. (1996 Lewis et al. ( , 1997) )  first tested the implementation of the AC data assimilation scheme in the MGCM.
It has since been adapted to assimilate TES retrievals using observations made during the less-than-ideal MGS aerobraking period between September 1997 and January 1998  (Lewis et al. , 2007). The reanalysis we present here is based on the assimilation of TES retrievals using observations made during the subsequent MGS science mapping phase. Montabone et al. (2006a)  describes both the assimilation procedure and the validation of the mapping phase reanalysis. One main difference between the reanalysis dataset described in this article and the one described in  Montabone et al. (2006a)  is that TES retrievals have since been revised. The revision has been characterized by four basic improvements: (1) surface temperature has been retrieved simultaneously with aerosol optical depth, (2) the model for the spectral dependence of dust and ice absorption has been updated, (3) the absorption from minor 'hot bands' of carbon dioxide has been treated by reading from a map instead of attempting their retrieval from each individual spectrum and (4) water ice has been restricted to form above the water condensation level instead of assuming a well-mixed profile.
Dataset Description The MGS/TES reanalysis version-1. 0 is available from 141°solar longitude 3  in MY 24 through 86°solar longitude in MY 27. The reanalysis dataset is divided into 63 data files, each one including data for 30 Martian sols. All 30-sol periods are consecutive, with no interruption. With the assistance of the BADC, the data files have been made available in CF-NetCDF format, 4  where the metadata used conform to the international 'Climate and Forecast' (CF) standard. The advantage of producing standard-compliant data files is that it promotes easy access using several types of software, data reuse, compatibility, and cross-disciplinarity. Only two variables included in the database and specifically related to the Martian calendar are not (yet) standard CF variable names. These are the 'Martian year' and the 'sol' (or Martian mean solar day).