dataesr/scientific-paragraphs-categorization huggingface dataset:
The ECOFAIRE methodology ECOFAIRE presentation. The French ECOFAIRE program was organized and conducted by SEM Pays de Loire in collaboration with the environmental consulting firm EVEA between 2006 and 2008  [4]. This program aims to "promote and facilitate the development of environmentally friendly products". A collaborative study was conducted with companies, industrial designers and engineers. The methodological tool ECOFAIRE is part of this research work. It is composed of two introductory sheets followed by 18 others, to be used in five chronological stages: "Scope and stakes", "Initial environmental assessment", "Solution search", "Evaluation of solutions", "Results and communication". Non-expert users are targeted here, whether they belong to industry or academia. On this paper, 9 analysis approaches are used.
Data collection and analysis We collected primary and secondary data in order to use triangulation techniques  (Eisenhardt, 1989; Gibbert et al. , 2008; Lincoln and Guba, 1985). We collected primary data through 18 semi-structured interviews (interview length ranged from 40 to 135 min, with an average of 83 min) with key QR managers and industry experts. The QR managers have been working for the airline during more than 70% of the time span of our case study and were actively involved in the development of the alliances and the elaboration of the network of new routes. Regarding the industry experts (such as journalists, consultants or researchers), they have been working in the airline industry for more than 15 years and have thus followed the development of QR over the years. We clearly noted that these interviews would remain confidential and anonymous  (Gioia et al.
, 2013) , and at the request of the interviewees, most interviews were not tape-recorded (but notes were taken manually). To ensure the interviewee's confidentiality, we use a generic position ("QR manager") to identify him or her in the quotations. To collect secondary data on QR's strategy, we performed a keyword search in Factiva, which yielded more than 10,000 articles. We then reviewed the titles and abstracts of those articles. After removing duplicates, i. e. , when the same article appeared in different news outlets, we ultimately obtained 230 relevant articles. We paid particular attention to statements by the CEO and management team concerning QR's strategy. We cross-checked the elements of QR's strategy against its corporate website, press releases, internal documents, and other sources.
We also used the IATA World Air Transport Statistics (WATS) and the annual Airline Business 4  alliance survey to collect data on QR's traffic, employees, destinations, and alliances. Both data sources are frequently used in strategy research on the airline industry  (Gimeno, 2004; Lazzarini, 2007; Wassmer and Dussauge, 2012). In Table  2 , we provide a summary of the data collected and detail their respective use for the analysis as suggested by  Ravasi and Philips (2011).
[Insert Table 2 about here] We first classified our data in different categories and organized and coded all 230 articles into a multidimensional table across all years and various categories, including strategy, organization, resources, and alliances. We then introduced the other relevant data elements (e. g. , interview extracts, internal documents, traffic, and fleet data). This process yielded an extensive multidimensional chronology that allowed us to identify transition points in the strategy  (Dumez and Jeunemaître, 2006; Lehiany and Chiambaretto, 2014). As we modeled different phases in the firm's evolution, we adopted the approach by  Lavie and Singh (2012)  to identify key transition points in the internationalization and alliance strategy to isolate time segments. We identified three distinct phases during the period from 1993 to 2010, each characterized by a major transition point in the firm's history: CEO generally has a strong impact on the strategy implemented by the firm  (Zajac, 1990; Shen & Cannella, 2002) , we have decided to divide this long phase into two sub-phases, Phase 1a (the initial birth from 1993 to 1996) and Phase 1b (the relaunch from 1997 to 2002), 20 for the description of the case and the analysis of its alliance activity.
As a result, he was perceived as a valuable external member of the group, even though he clearly communicated the fact that he was not a student, but a visiting research fellow. Social connections and acceptance as a useful contributor to the group proved priceless when he reached out to all students participating in the Facebook group in the spring and fall of 2016 for interviews directed at exploring their ethical perceptions of digital files sharing practices. The response was very positive and nearly all contacted students agreed to participate. But then, logistics of in-person data collection-time constraints and scheduling problems both on the side of the students and the author-reduced the overall number of filled in survey questionnaires. About 200 students enroll in the Harvard LL.
M. program each year, out of which 50 and 59 were interviewed in the spring and fall, respectively, through one-to-one meetings. 8 All data were collected in one-on-one meetings in the vicinity of the Harvard campus, in a consistent setting. This approach was chosen to ensure that the respondents were limited to LL. M. students, and also to increase the level of engagement with the study (online questionnaires are notorious for obtaining negligent and un-reflexive responses). All 109 respondents were first reminded of the purpose of the research, given all relevant details regarding the measures taken to ensure their anonymity and privacy, and provided informed consent forms. They then filled a questionnaire presented in an anonymous window on the researcher's computer. The survey consisted of 3 sections.
Interviewees were identified through double-checked personal referral and were duly briefed about the aims, scope, and process of the investigation. They were initially contacted by e-mail and after confirming availability for the research they were recontacted, this time through mobile phone call. Further contacts were established through WhatsApp or Skype messaging facilities. Anonymity was demanded by all participants and was guaranteed through the form of a print-out signed non-disclosure agreement entitled 'Statement of Ethical Conduct Under Commitment of Honor'. All interviews were face-to-face conducted in Portuguese language and were audiorecorded in the interviewer's smart phone device. They took place in the capital town of Maputo, between the 17 th and the 23 rd of May, 2018, at the preferred location of each interviewee, either the interviewee professional or business office or the interviewer hotel room.
Smart contracts have been argued to be a means of building trust between parties by providing a self-executing equivalent of legal contracts. And yet, code does not always perform what it was originally intended to do, which resulted in losses of millions of dollars. Static verification of smart contracts is thus a pressing need. This paper presents an approach to verifying smart contracts written in Solidity by automatically translating Solidity into Java and using KeY, a deductive Java verification tool. In particular, we solve the problem of rolling back the effects of aborted transactions by exploiting KeY's native support of JavaCard transactions. We apply our approach to a smart contract which automates a casino system, and discuss how the approach addresses a number of known shortcomings of smart contract development in Solidity.
Introduction Blockchain is a distributed ledger running in a decentralised manner on a network of devices that allows for the exchange of data in a trusted manner. Such values may be stored and modified without the need for a centralised trusted authority; trust is established through distributed collaboration following specific protocols. Cryptocurrencies, particularly Bitcoin  [15] , was the first proposed application of blockchain. A smart contract platform built on top of blockchain, as proposed and built by Ethereum  7  , enables for blockchain to be used for many other applications besides cryptocurrencies. Smart contracts are software programs that are openly stored on the blockchain (they can be read and used by anyone), and -as everything else on blockchains -are permanent and cannot be altered.
By targeting Java, our translation can exploit the similarities between the contract-oriented and the object-oriented paradigms, and make use of existing verification tools. We use the deductive source code verifier KeY  [2]  to verify the translated program since it is among the most powerful verification tools for object-oriented languages, and specifically, it has native verification support for transactions and their abortion, allowing to model the rolling back of program effects. We apply our approach to a case study consisting of a Casino smart contract. The paper is organised as follows. Section 2 gives some background on smart contracts and the deductive verification tool KeY. In Section 3 we present our Solidity to Java translation. Section 4 is concerned with the verification of the translated Java programs using KeY.
Deductive verification with KeY We use the KeY system  [2]  to verify the Java programs (obtained from the original Solidity contracts) to be correct with respect to their specification. The Java Modeling Language (JML)  [12] , is used to write class invariants and method specifications. JML specifications are embedded into Java source code as Java comments. Any comment starting with //@ or /*@ marks the start of a JML specification. Consequently, public class Account { /*@ public invariant accountNr >= 0 && (\forall Account a; a != this; a. accountNr != this. accountNr); *@/ private /*@ spec_public @*/ int accountNr; //@ public invariant balance >= 0; private /*@ spec_public @*/ int balance; /*@ public normal_behaviour @ requires amount >= 0 && to != this; @ requires this. balance >= amount; @ assignable this.
Multiple requires and ensures clauses are conjunctively combined, and many method specifications can be connected using also. Complementary to normal_behavior there are exceptional_behavior specifications stating which exceptions are thrown under which conditions as well as assertions about the post state. For convenience, JML defines a few defaults. For instance, by default all fields, parameters and return values of reference type are not null. Further, there is an implicit pre-and postcondition \invariant_for(this) for each method specification stating that the method has to preserve the invariant of the this object. To verify that a Java program satisfies its JML specification, KeY translates Java and JML into a program logic called Java Dynamic Logic  [2]. The formula is then proven using a sequent calculus and symbolic execution.
Symbolic execution is seamlessly integrated as sequent calculus rules. KeY supports modular reasoning by using a method specification to symbolically execute a method invocation statement, instead of inlining the method's body. A program in KeY is thus proven to be correct by verifying one method at a time. The use of method specifications makes the approach modular. Finally, in the context of the current work, it is important to note that KeY not only supports full sequential Java, but also JavaCard, a Java derivative which features a transaction mechanism including rollback of interrupted transactions  [2]. The fact that KeY natively supports transaction verification enables us to deal with rollback, which is the mechanism used by the EVM to deal with failure in transactions.
Through this class, the functionality of the payable annotation, is also handled, transferring the requested amount from the caller to the callee. (ii) Built-in datatypes become public Java classes. To address challenge 4, the functionality of the Solidity datatypes not available in Java has been replicated in Java interfaces and classes. We end up having multiple classes implementing an interface to support different ways of data handling, e. g. , should an over-or underflow trigger an exception (used when we want to verify the absence of over-or underflows), or should it replicate the semantics of Solidity bounded integers (used in the rare cases when the smart contract may use over-and underflow in its functionality). For instance, the interface Uint256 comes with the Uint256int and Uint256BigInteger classes to model Solidity's datatype uint256 (see Section 4 for more details).
To handle failing transactions, Java exceptions are used (since catching exceptions is not possible in Solidity yet, there is no contract code in catch). Upon catching an exception, we use the JavaCard transaction rollback mechanism (supported by KeY) to undo the effects of the transaction so far (see the JCSystem. * calls appearing in lines 4, 6 and 9 in Listing 1. 3). (v) Fallback function. If a Solidity contract has a fallback function defined, then it is translated as described above. If not, we emulate the Solidity compiler and define an empty payable fallback method. (vi) Function calls. Function calls are handled differently depending on whether they are internal or external, as determined at translation time. External calls performed as A. f(); (or using the Solidity call mechanism) are translated as calls to A.
Due to the not yet implemented support for immutability in KeY, we are currently not able to prove the correctness of our accessible clauses, but can make use of them when proving. Support for Solidity's state rollback. To provide support for the Solidity's rollback in case of exceptions, the translation makes use of JavaCard's transaction mechanism with explicit commit and abort calls. Note again that KeY supports verification of code using revertible JavaCard transactions  [2]. In order to model unexpected failures (by external events and not visible by program semantics), we generalise the JML specifications of the methods such that they allow normal as well as exceptional termination. For these methods a wrapper method call_m(. ) is created (see Section 3) which wraps the call to m(. ) using JavaCard transactions.
Solidity joins C's and Java's approach by silently overflowing. This easily leads to mistakes, as programmers often use natural or whole numbers as internal mental models. Our approach models overflow and underflow semantics faithfully and proves a program correct only if the overflow was intended and/or does not invalidate the property to be proven. KeY for Java provides also a second sound (but incomplete) approach to the same problem by enforcing to prove that no overflow happens.
Related Work Although the need for formal verification, particularly compile-time static analysis techniques, for smart contracts has been highlighted various times e. g. [3, 7] , actual work in the domain is still sparse. Most work on static analysis techniques for smart contracts falls in one of two categories -either Lint-like syntactic analysis of code to find potential vulnerabilities like Solcheck (https://git. io/fxXeu) and Solium (https://git. io/fxXec), or semantics-based static analysis specialised to identify commonly encountered problems with smart contracts (e. g. gas leaks, reentrancy problems). Of the latter type, one finds approaches designed for different types of vulnerabilities. Fröwis et al. [8]  address smart contract control-flow mutability which is typically not desirable.
OYENTE  [13]  is a tool which can perform reentrancy detection and other analysis using symbolic execution. Mythril  [14]  uses concolic analysis, taint analysis and control-flow analysis for identifying security vulnerability, while SmartCheck (https://tool. smartdec. net) uses both Lint-like and semantic analysis to identify various vulnerabilities. Bhargavan et al. [5]  transform Solidity into F* on which they perform analysis to identify vulnerable patterns. The other approaches perform their analysis at the EVM bytecode level, mainly because the control-flow analysis used typically does not use the program structure. This enables the analysis of any smart contract deployed on the Ethereum blockchain. It is worth noting that the semantics of Solidity are only informally described in the language documentation, and effectively pragmatically decided based on what the compiler does.
Conclusions We have presented a translation-based verifier of smart contracts using the deductive verification tool KeY. Our approach is one of the first to go beyond verifying standard sanity checks (e. g. there are no integer over-and underflows) and enable verification of business-logic and thus contract-specific specifications (e. g. when a player guesses a number, the casino contract will pay her 1. 8 times the bet they placed). We implemented the translation in a tool and illustrated its use on a simple casino smart contract. Although our results indicate that our approach is promising, our contribution uncovered new unexpected questions and challenges. The first question is how the approach fares with real-life contracts. What is promising is that the size and complexity of smart contracts is trivial compared to typical software systems and matches well with our case study.
Data Analysis Data collected in the two focus groups were exported in spreadsheets and analyzed considering the theoretical background presented in Section 1. Therefore, responses were compiled and frequency of ranking positions of each barrier was analyzed. To reach a final ranking of barriers, scores were calculated based on the frequency of each barrier on each position of the rank. Therefore, every time a barrier was ranked first, it was assigned 10 points; every time it was ranked second, it was assigned 9 points, and so on. This also helped balance the scores by not neglecting barriers ranked in the last positions, since they were also assigned scores, although to a lesser degree. Finally, scores were calculated, and barriers were ranked from highest (most impactful) to lowest. The rankings were used to analyze data and propose findings, which are presented and discussed in Section 3.
Acknowledgements The authors thank the  Brazilian National Council for Scientific and Technological Development (CNPq -Conselho Nacional de Desenvolvimento Científico e Tecnológico)  (Process n. 205844/2015-6), the  Research Council of the State of Rio Grande do Sul  ( FAPERGS, Fundação de Amparo à Pesquisa do estado do Rio Grande do Sul)  (process n. 17/2551-0001 ) and the  Research Coordination of the Brazilian Ministry of Education (CAPES) , and the  French Ministry of Education  for the financial support received to conduct this research.
DEFINITION OF A WORKING MODEL FOR A QUALITY OF EXPERIENCE ASSESSMENT IN AN OBJECT-BASED MEDIA ECO-SYSTEM In the course of the ORPHEUS project, user requests for OBA broadcasting were collected. For this purpose, in-house workshops with creative and technical staff were conducted, to find out what kind of features and requirements are to be considered as necessary or desirable for NGA production and distribution. At the German public broadcaster BR  3  , there was a two-day workshop on June 1 and 2, 2016, with 70 participants on the first day and 36 participants on the second day, in order to form 6 small groups for design thinking sprints. The registration and participation was open to all BR staff. Design thinking  [24]  is a wide-spread bottom-up methodology for creating and developing software and services involving users at the very initial stage.
5. Neutral studio loudspeakers were used in this scenario to be independent from specific preferences or aversions of loudspeaker "sounds" and brands. The tube radio seen in the picture was for decoration only. No additional EQing or other sound processing was used in the reproduction via headphones or loudspeakers. The output of the OBA stream was directly generated by the MPEG-H decoder and renderer that has been implemented into the ORPHEUS app on the iOS devices. In both scenarios 12-inch iPad Pro devices with a German language surface and additional instructions on what-to-do and howto-use were used. The iOS app is installed in a presentation mode and receives the pilot productions as MPEG-H stream.
Some of the positive comments: "With this setting I can understand what I usually would barely hear. " (m,  28)  "This setting helps you to understand the speaker better. I think that's great. " (m, 48) "I think this setting is very good because you can get more of the atmosphere. " (m, 54) PAPERS Fig. 12. Two pages of the user interface of the ORPHEUS app. Left side: transport wheel with chapter markers. Right side: transcript of the spoken word.
Summary of the JOSEPHS Evaluation The majority of the participants listen to music or spoken word programs casually or in a mobile situation. Streaming services, such as Spotify, are the most popular audio apps among the participants. Most of the participants rated binaural sound as better and more natural than mono or stereo. Most of participants find the possibility to change the fore-to-background balance or "turn up/down the volume of specific sounds, e. g. , the announcer" useful. A majority of participants enjoyed the five-channel surround sound loudspeaker reproduction in the living room setup. About half of the participants would use the transcript. The transcript is regarded mainly useful for repeating something, for people with hearing impairments, for language learning, and translation.
In addition to the usual features of a mobile radio application, this one offers several features: 1. Navigating between the chapters of a program 2. Displaying a text transcript of the program 3. Adjusting the "audio clarity" (fore-/background balance) 4. Interacting with the content (moving sound sources or changing the listening perspective) 5. Choosing the program language 6. Setting the rendering format (mono, stereo, or binaural) 7. Adapting the duration of the program. " For each feature, as well as for the iOS app as a whole, the participants were asked to rate on a 0-10 scale how much they agreed with the following statements: • This app/feature seems easy to use • This app/feature seems useful • This app/feature seems innovative • It is likely that I will use this app/feature in the future.
Test of the ORPHEUS iOS App After they filled the first questionnaire, the participants were asked to test the ORPHEUS iOS app. This test occurred several days after the initial questionnaire in order to reduce the fatigue of the participants and so that their answers would be more consistent. In order to test the app, the participants were instructed to perform six tasks, with each task focusing on specific features: • Chapter navigation -To test this feature the participants were asked to select the program named "Experience Object-Based Audio" and jump from chapter to chapter. • Text transcript -The participants were instructed to select the "Art of Foley" program and activate the text transcript feature. • Audio clarity -The participants were asked to select the "Live Football" program and listen to the effect of changing the fore-to-background balance.
Definition of a weak signal As posited by  Ansoff (1975) , a weak signal is a "datum," often with an insignificant appearance and submerged in myriad other data, the interpretation of which can warn that an event (perhaps not yet initiated) is about to occur and is likely to have significant consequences in terms of risks or opportunities. It has an anticipatory feature  (Lesca 2003)   Lesca et. al. 2009 , Sherkock, 2011). Lately, efforts at using new technologies are helping to deal with large data sources on the web to identify weak signals  (Buitrago-Uitrago, 2014 , Casagrande, 2012) , and to limit the information overload  (Lau et al. , 2012). One should not use anticipation and prediction interchangeably. Prediction is mainly the calculation of the trends in the quantitative database collected over a period.