dataesr/scientific-paragraphs-categorization huggingface dataset:
However, those approaches do not deal with autonomic management. Recently, OCCI (Open Cloud Computing Interface) has become one of the rst standards in Cloud. The kernel of OCCI is a generic resourceoriented metamodel  (Nyrén et al. , 2011) , which lacks a rigorous and formal specication as well as the concept of (re)conguration. To tackle these issues, the authors of  (Merle et al. , 2015)  specify the OCCI Core Model with the Eclipse Modeling Framework (EMF) 3  , whereas its static semantics is rigorously dened with the Object Constraint Language (OCL) 4. A EMF-based OCCI model can ease the description of a XaaS, which is enriched with OCL constraints and thus veried by a many MDE tools. The approach, however, does not cope with autonomic decisions that have to be done in order to meet those OCL invariants.
AxiSEM and Instaseis: High-Frequency Synthetic Seismograms for Radially Symmetric Models Despite the ever increasing computational power available, the O(ω 4 ) complexity where ω is the highest resolved seismic frequency, of numerical full 3D wave propagation renders computation of synthetic seismograms with these methods impractical for high frequency ) by decomposing the 3D problem into a set of 2D problems. This decomposition also allows to store full 3D wavefields computed in 1D models permanently and extract seismograms from these databases very quickly. Synthetics as continuous data with noise as well as Green's function generated this way are available at http://instaseis. ethz. ch, (see  Ceylan et al. 2017  in this issue, for details). Here, we highlight some of the effects that can be observed in these simulations for one particular model, see Fig.
Acknowledgements We gratefully acknowledge editor  Christopher Russel  and two anonymous reviewers for constructive comments which improved the manuscript. The open source spectral-element software package SPECFEM3D_GLOBE is freely available via the Computational Infrastructure for Geodynamics (CIG; geodynamics. org)and the Mars version used in this study is available on github. com/SeismoMars/SPECFEM3D_MARS. For SPECFEM3D_GLOBE simulations computational resources were provided by the  Princeton Institute for Computational Science & Engineering (PICSciE). The AxiSEM and SES3D parts were supported by grants from the  Swiss National Science Foundation  ( SNF-ANR  project  157133  " Seismology on Mars ") and from the  Swiss National Supercomputing Centre (CSCS)  under project  ID s628.
An ever increasing number of interconnected embedded devices, or Machine-to-Machine (M2M) systems, are changing the way we live, work and play. M2M systems as a whole are typically characterized by the diversity in both the type of device and type of network access technology employed, and such systems are often still today task-specific and built for just one specific application. Smart lighting, remote monitoring and control of all kinds of consumer devices and industrial equipment, safety and security monitoring devices and smart health and fitness products, exemplify this revolution of intercommunicating machines. However, the differences in communication technologies and data formats among such devices and systems are leading to a huge complexity explosion problem and a strongly fragmented market, with no true interoperability.
INTRODUCTION Machine-to-Machine (M2M) refers to the automated exchange of information between servers, sensors, actuators, and various end devices such as mobile phones, vending machines, vehicles, and personal computers. All kinds of information exchange between various kinds of communicating machines, with limited or no human intervention, can be referred to as M2M communication. This gives rise to many obvious advantages such as real time data exchange between devices in the field, remote monitoring and operation according to real needs, immediate reactivity to business information, automatic processing of consumption statistics and operational data are made readily available. Different application domains are brought together by M2M technology. Data communication takes place via established ICT (Information and Communication Technology) infrastructure and communication media is based on both fixed and wireless (mobile) technology.
Indeed, such devices are longer restricted to communicating only with other machines in the same local system, or even in the same application domain. In essence, M2M (Machine-to-machine)  [1]  is always a mixture of various kinds of electronic devices, communication technologies and software implementations. M2M can be defined simply as machines intercommunicating without, or with limited, human intervention. M2M constitute systems that enable the wireless and wired devices, both big and small, to exchange information with other devices and actors included in the M2M ecosystem. Typically, devices such as sensors and meters are used to capture raw data which is then transferred through a network to the M2M applications. These pieces of data are then transformed into meaningful pieces of information by the background system.
Any interoperable M2M system will obviously need to support a mixture of legacy and modern technologies and protocols, which is already a tough challenge in itself. Furthermore, to have these machines really intercommunicate in a meaningful manner, it is not enough to simply enforce compatible communication protocols, as the transmitted information itself must also be processed and stored in a format that is accessible to both man and machine. Technologies used commonly in M2M include naming and identification of M2M entities, service discovery (SD), security including, e. g. , authentication and encryption techniques, service platforms, wireless radios, data formats and communication protocols. Many different technologies and standards exists, all attempting to provide a solution for one or more of these issues given rise by M2M and pervasive applications, but it quickly becomes evident that the technology to unleash the full potential of M2M is still missing  [1] ,  [2].
e. , only for as long as the subscriber is online in its current presence session. In addition, it is possible to deliver event notifications only when the subscriber is online. XMPP's pubsub offers also time-based subscriptions aka leases that enable expiring old or stale subscriptions. It also offers error message to tell the subscriber, e. g. , that the subscriber is not in the customer database or the customer's account is not paid up. This could be used in commercial deployments  [64].
C. Advanced two-factor user authentication for M2M [82] describes an authentication mechanism which defines how to transmit authentication factor information with ad-hoc commands defined in  [65]. The  [82]  gives examples to enable two-factor authentication by using mechanisms to check if used XMPP account exists and/or if user knows or have credentials of the account, if used XMPP client knows Verifier's full JID, and if user of the client, the client, or some other entity is able to access a shared secret stored inside certain device, a trusted platform module (TPM) or application and provide it to the Verifier through the Prover during a wanted time-window. The current version (0. 0. 4) of the XEP proposal  [82]  describes transmitting a random string, a Time-Based One-time Password (TOTP) or a One-time pad and using them as authentication factors.
D. An interworking mechanism for ETSI/XMPP interoperability Working with XMPP alongside the ETSI SCL platform, both of which have been discussed earlier in this paper, gives an interesting and valuable opportunity to perform experiments with and study one of the most important aspect of modern M2M systems, cross-domain interoperability and interworking capabilities. After all, in M2M world different systems should be able to communicate and cooperate with each other in a meaningful manner. In this work, a proof-of-concept interworking module has been developed with the goal of further enhancing the interoperability of modern M2M systems and the various technologies used in M2M by bringing together the XMPP domain with the ETSI SCL -based system. This is approached by connecting an experimental XMPPbased M2M domain to an up-and-running ETSI NSCL.
In concrete terms, this is done by building an interworking client that is able to talk to both the XMPP -based M2M back-end server in the experimental M2M ecosystem and an ETSI NSCL server. The ETSI NSCL implementation employed in this work is a part of the OM2M -project, which has been presented in this paper in the previous chapter. The most important part of the whole Interworking Proxy module is the Custom Interworking Logic unit, which handles all the crucial translation work of the messages and message formats from ETSI network to XMPP network and vice versa. To summarize, the ETSI-XMPP Interworking Proxy packs up two different client units in it with the Custom Interworking Logic. Clients handle the communication towards the appropriate networks and the logic unit translates the messages so that the receiving end can understand it.
The first prototype version of the IWP was designed and built to store information received from a XMPP domain via publishsubscribe mechanisms into the ETSI NSCL resource tree. The XMPP-Communication module is essentially a set of XMPPrelated functionalities built on top of an XMPP client library. The module contains all the necessary XMPP-related functionalities for actions such as opening a connection to a designated XMPP-server, providing authorization information (username, password), logging in to the server, subscribing to a designated pubsub node, listening for incoming messages, processing and storing incoming messages and sending XMPP-messages. It communicates with the XMPP Server in a standard client-server manner as specified by the XMPP standard. Additionally this client also has an interface towards the Custom Interworking Logic unit to handle the required translation of messages and resources.
For the Interworking Proxy implementation presented in this paper, the XMPP functionalities are built upon the Smack API 3. 3. 1  [97] , which is a widely used open source XMPP client library, licensed under the Apache Software License. It is a library for the Java platform, and it can be embedded into any application to create anything from full blown XMPP clients to simple XMPP interactions, such as sending simple notifications. It is a convenient and functional library for enabling communications with XMPP servers to perform instant messaging and group chat, for example. The Smack library is currently licensed under the Open Source Apache License, which means that anyone can easily include the functionalities offered by it into any non-commercial or even commercial applications. The HTTP-Communication module handles all the communication to the ETSI NSCL server via HTTP-protocol.
Any interchange of information with the ETSI NSCL is carried out through simple GET, POST, PUT and DELETE Http-calls, following the Representational state transfer (REST) model. The M2M service architecture proposed by ETSI has been discussed in more detail earlier in this paper. The ETSI module conforms to the ETSI specification and it communicates in an ETSI specified way towards the ETSI NSCL. This module also has the interfaces towards the Custom Interworking Logic unit to be able to exchange data with it. The Interworking Logic module is, as the name suggests, where most of the logic and "intelligence" of the implementation resides. In technical terms, all the other modules are allocated and employed as member objects within the Interworking Logic module and its corresponding object. It gets input and event from the Interface/EventListener module and then carries out all the necessary processing and calls the necessary methods from the XMPP-or HTTP-Communication modules.
The actual application "payloads" embedded into the ETSI specified XML-messages transmitted over HTTP/REST -calls, are encoded into the convenient Base64 -format  [98]. Base64 is a binary-to-text encoding scheme with the goal of representing any binary data in an ASCII string format by means of translating the data into a radix-64 representation. Base64 encoding schemes are commonly applied when there is a need to encode various kinds of binary data that needs to be stored and transferred with methods that have been designed to work with textual/stringtype data. The aim is to ensure that the data remains intact without modification during transport. Base64 formats are quite commonly used in a number of applications such as email and XML-based applications. In the experimental Interworking Proxy implementation, it was decided to employ the tried and true Base64 encoder from the Apache Commons Codec -library  [99] , licensed under the Apache License.
The Apache Commons Codec software library provides a time tested and reliable implementations of common encoders and decoders such as Base64, Hex, Phonetic, etc. It consists of a set of utilities and a simple framework for encoding and decoding text and binary data. In general terms, the Commons is an Apache software project which concentrates on all sorts of reusable Java components. The trials and experiments to employ the interworking implementation presented here in making resources and information from the XMPP-domain available in the ETSI NSCL have been successful. The IWP, in its current form, is indeed able to read, process and store data received via XMPP publish subscribe and package and make that information readily available using the resource tree in the NSCL, as specified by ETSI.
In particular, coarse resolution sensors, e. g. Moderate Resolution Imaging Spectroradiometer (MODIS), Advanced Very High Resolution Radiometer (AVHRR), SPOT-VEGETATION, thanks to its daily coverage and availability of historical datasets, have extensively been used for building empirical models for crop yield forecasting and assessment. These models connect satellite-derived features, for example vegetation indices (VIs) such as Normalized Difference Vegetation Index (NDVI), Enhanced Vegetation Index (EVI), Vegetation Health Index (VHI) and/or biophysical parameters such as Leaf Area Index (LAI), Fraction of Photosynthetically Active Radiation (FPAR), with reference yield data. For example,  Johnson (2016)   [5]  analyzed efficiency of multiple MODIS land products including NDVI, EVI, LAI, FPAR, and Gross Primary Production (GPP) to assess crop yield at county level in US for ten major agriculture commodities.
Winter wheat is mainly rain-fed in the region and usually planted in September-October. After dormancy during the winter, it emerges early spring reaching maturity by the end of June. Harvest of winter crops is typically undertaken in July. Reference data on crop yield and harvested area at district level were collected from the Department of Agro-Industry Development of Kirovohrad State Administration (http:// apk. kr-admin. gov. ua). The data were made available online as the harvest progressed and were based on farm surveys of all large agricultural enterprises (that account of more than 90% of all winter crops production in the region) and samples of household farms the same way as official statistics is collected  [23]. The final estimates for winter crop yields and areas were available at the end of November and were used as reference in this study.
Landsat-8/OLI and Sentinel-2A/MSI datasets Remote sensing images acquired by the Operational Land Imager (OLI) instrument aboard of Landsat-8 satellite and by the Multi-Spectral Instrument (MSI) aboard Sentinel-2A satellite were used in the study. Landsat-8/OLI captures images of the Earth's surface in 9 spectral bands at 30 m spatial resolution (15 m for panchromatic band)  [24]  while Sentinel-2A/MSI captures images of the Earth's surface in 13 spectral bands at 10 m, 20 m and 60 m spatial resolution  [25]. Overall, 51 Landsat-8 and 87 Sentinel-2A scenes were acquired over the study area from March 1, 2016 to July, 31, 2016. Landsat-8 scenes covered the following coordinates (path/row) of the World-wide Reference System (WRS-2): 178/026, 179/026, 179/027, 180/026, 180/027, and 181/026. The swath of the Landsat-8 scene is approximately 185 km × 180 km.
Sentinel-2A scenes covered the following tiles: 35UQQ, 35UQP, 36UUV, 36UUU, 36UVV, 36UVU, 36UWV, and 36UWU. The size of the Sentinle-2A tile is approximately 110 km × 110 km. The Landsat-8/OLI and Sentinel-2A/MSI scenes were atmospherically corrected for surface reflectance using the LaSRC algorithm  [26]  (Fig. 2 ) ensuring consistency between these datasets as well as with MODIS data used for building a generalized crop yield model  [10, 28]. Cloud and shadow screening for Landsat-8 and Sentinel-2A scenes was performed using the Fmask algorithm  [27]  and inversion residuals from aerosol optical thickness (AOT) estimation  [26]  (Fig. 3 ). The pixels identified as those with high aerosol content were also masked out. Images from Sentinel-2A/MSI were further converted to 30 m to match spatial resolution of Landsat-8/OLI.
Since atmospheric correction for Sentinel-2A was performed at 10 m spatial resolution for all spectral bands, conversion to 30 m was carried out by aggregation (averaging). It was found that Landsat-8/OLI and Sentinel-2A/MSI exhibit misregistration issues  [29] ; therefore additional co-registration was performed to ensure spatial consistency between the datasets  [30]. Finally, NDVI was calculated for Landsat-8 scenes using band 5 (near-infra red -NIR) and band 4 (red), and for Sentinel-2A scenes using band 8A (NIR) and band 4 (red).
Winter wheat yield mapping and assessment Peak NDVI estimated on a per-pixel basis from Landsat-8/OLI and Sentinel-2A/MSI images from March to June was selected as a primary parameter for assessing winter wheat yield. In multiple studies NDVI has been shown to be strongly correlated with yields for a variety of crop types  [5, 8, 9, 10]. Since there are no available historical data for a combination of Landsat-8 and Sentinel-2A images to correlate with yield measurements and build a crop yield model at district scale, we used a MODIS-derived winter wheat yield model that was calibrated for US and directly applied for Ukraine  [7, 10]. More specifically, the model takes advantage of daily MODIS data at Climate Modeling Grid (CMG) scale at 0. 05° resolution to capture an NDVI peak and correlate with the yield.
This slope (4. 61) is directly applied to the peak NDVI calculated from Landsat-8-Sentinel-2A images to derive a winter wheat yield map at 30 m resolution. These are used to estimate district-level yields by averaging yields at 30 m over winter crop masks (section 3. 1) for each district. In addition to the average, a standard deviation and coefficient of variation (CV), defined as a ratio between the standard deviation and the mean, is estimated as well. The estimated district-level yields are validated using independent reference data (section 2. 1) collected at district level in Kirvohradska oblast in Ukraine.
Validation metrics For comparison of satellite-derived winter crop areas and winter wheat yield with reference datasets at district level, we used the APU analysis metrics  [28] : • accuracy (A) that shows the average bias of the estimates A = 1 N ∑ i = 1 N (P i -O i ), (2) • precision (P) that shows repeatability of the estimates P = 1 N -1 ∑ i = 1 N (P i -O i -A) 2 , (3) • uncertainty (U) that is the root mean squared error U = 1 N ∑ i = 1 N (P i -O i ) 2 , (4) • relative uncertainty (rU) normalized by an average of reference values: rU( % ) = U 1 N ∑ i = 1 N O i × 100 % , (5) where P i and O i are computed (from satellites) and observed (from reference) values, respectively.
Winter crop mapping The GMM approach to winter crop mapping was applied to the peak NDVI calculated for the time period from March 1 to April 6 using a combination of Landsat-8 and Sentinel-2A, as well as using each of them separately. This was done in order to assess an added value of the combined use of these datasets. The indicated period (March 1 to April 6) was selected in such a way to capture NDVI development of winter crops and avoid confusion with early spring cereals that were planted beginning of March. The derived maps were used to calculate the area of winter crops at districts level by pixel-counting. These estimates were compared to reference values and are presented in Table  1  and Fig. 6. The derived winter crop using Landsat-8 and Sentinel-2A is illustrated in Fig. 7. Combination of Landsat-8 and Sentinel-2A allowed us to achieve R 2 = 0.
In the linear regime, the sensitivity of the deflection signal needs to be calibrated by an appropriate procedure. In the conventional procedure, a force curve is recorded in a bare region of a rigid substrate and a linear fit is done in some regime of this data to obtain a conversion factor converting the voltage measured from the sensor to deflection signal (presented in nm/V). This conversion factor is most often called deflection sensitivity, although other names are also used (e. g. InvOLS: Inverse Optical Lever Sensitivity), and it is prone to errors mainly due to contamination of the tip and/or rigid substrate, especially on biological samples (see supp. informations 3 and 4). The proposed standardized nanomechanical AFM procedure (SNAP) eliminates those errors by calculating the correct deflection sensitivity from the thermal fluctuations of the free cantilever with a known accurately and independently determined value of the spring constant (supp.
These gels were then sent to the participating labs and measured with the local AFMs. Afterwards each lab sent the measured sample to one of the other labs. In this way gels circulated all over Europe to get many data from different groups. All the results were collected and compared in Bremen. It turned out that values of elastic moduli were very different among each lab (Fig. 1A ). This prompted us to search for potential error sources causing this inhomogeneity. Why elastic moduli of gels were so different when measured in different labs? Several hypotheses that could contribute to this discrepancy were proposed: • Hypothesis 1. The force constants used in analysis (calculated from the AFM thermal spectra) were wrong; • Hypothesis 2. The different gels exhibited different elastic moduli (E) since their properties changed because of time or travel conditions; • Hypothesis 3.
The deflection sensitivity had been calibrated erroneously, which would affect the force and indentation values calculated (supp. info 2). Other possible systematic (and hence constant) error sources like problems in calibrating AFM thermal spectra (supp. info 2) or in analysing thermals (supp. info 3) and the accuracy of the fitting procedure (supp. info 7) are discussed in the supplementary information. Hypotheses 1 and 2 were quickly confuted. For hypothesis 1, we analysed our data in two ways: using the force constant from the thermal spectrum or the vibrometer determined value reported from the manufacturer. First approach corresponds to the normal way AFM experiments are done whereas the other relied on accurate knowledge of the force constant. However, there was no real improvement in the second approach: the variations in elastic moduli of different gels did not decrease.
Thus, we could conclude that the consistency of the results did not depend on the instruments or the software used for analysis. Hypothesis 2 was tested in another set of experiments where gels were measured again in Bremen with the same instrument and tip, the same deflection sensitivity and spring constant by one single user and under the same experimental and instrumental conditions (deflection sensitivity and spring constant) after circulation in several labs. Hence, these data demonstrated mechanical homogeneity and stability even after 6 months (Figure  S8  in supp. material 6). If we assume that the only (or major) error in the force constant determined by AFM thermal comes from an erroneous deflection sensitivity (Hypothesis 3), we could calculate a correction factor λ for the deflection signal, knowing a reliably calibrated force constant.