dataesr/scientific-paragraphs-categorization huggingface dataset:
EUD applications started spreading in the Web, where large number of users joined different online communities to create and share their applications through public repositories. For instance, the aforementioned Userscripts or GreaseFork allow users to share Greasemonkey (http://www. greasespot. net/) scripts that adapt and augment the Web. Even traditional applications, such as desktop spreadsheets, began to be conceived as part of the global Web scenario with the use of online, shareable, and multiple access applications, like Google Sheets (https://docs. google. com/spreadsheets/). This application is a target not only for being considered an EUD environment, but also because it can be augmented through the mentioned techniques. EUD expanded its scope to the mobile applications field and it represented new challenges of integration with the possibility of providing both, the development process and the resultant application, with features based in diverse context types, like positioning, orientation, or noise perception level.
Nevertheless, due to recent advances in mobile Web browsers, Web applications can use the devices sensors values for adapting their behaviour, and new and interesting functionalities can be created. For instance, two of the most popular Web browsers provide each a Web API (Firefox Web API: https://developer. mozilla. org/en/docs/WebAPI, Google Chrome's Web API: https://developer. chrome. com/extensions/api other) that allow regular Web applications to access some contextual information (e. g. geolocation, proximity status, battery status, audio, video, etc. ). Moreover, the W3C is working on the standards of such APIs, for example, the ones regarding the battery (https://w3c. github. io/battery/) and the proximity (https://w3c. github. io/proximity/) sensor are currently an editor's draft, and the geolocation API (https://www.
The approach, called mobile Web augmentation (MoWA), comprises an augmentation framework and a weaver for running client-side scripts (MoWA applications) on top of existing Web pages, after a Web page was parsed and loaded into the browser. Developers instantiate the framework classes and extend them with a new kind of MoWA application, which can be finally instantiated. As shown in Figure  3 , applications are installed into the MoWA weaver, a mobile browser extension, and their underlying augmentations are triggered either because the end user manually navigated to a target page, or because it was loaded in response to a change in the context (e. g. , the user position). In both cases, the weaver runs the corresponding MoWA applications, which, in general terms, modify the UI by adding extra components.
Reusing content (from the target Web page to augment and from some external ones) and accessing the mobile sensors are possible because the framework runs under the context of a mobile browser extension, which has access to the proper low level APIs. MoWA requires some basic knowledge of JavaScript to instantiate and combine the framework features, and it offers several hot spots  [29]  that are easy to extend. Some of them address specific behaviour related to the supported context types. For instance, supporting orientation requires implementing a sensor but also a proper context type, in order to define some concrete context values of interest for the application. In this case, the context type is the PointInSpace class, which has one attribute for each axis in the tridimensional space, but other possible ContextTypes are lux, Decibel, GeoLocation, QrBasedLocation, BatteryCharge, TelephonyStatus, UserProfile, and so on.
Nevertheless, other augmentations are also possible in relation to the manipulation of style and structure of the underlying Web documents. For instance, consider visualizing an extra control on the top of any Web page for increasing and decreasing the font sizes, or for applying a new layout based on the selection of some elements listed on the page. Moreover, each augmenter, despite which context type it observes, can also have defined a reference for external content. Therefore, it is possible to conceive the same augmenter checking the current time and ordering elements (which have an associated time) to be reused in diverse contexts, as movies in a cinema Web site or guided tours listed in the web site of a city Hall. Summarizing, MoWA empowers developers with a set of software features bringing together both the mobile and the augmentation worlds and the underlying concepts for a concrete MoWA application are (i) an existing Web application to be augmented or adapted with mobile features; (ii) the specification of the context types that will be used for the mobile experience; these types are based on a particular mobile device capability, such as GPS geolocalization or light sensors; context values are made available to applications through software sensors, which either are part of the MoWA framework or can be defined by the developer; for instance, the location, as a context type, can be tracked for assisting the end user to traverse a tour's path; (iii) the association of sensors to a particular URL (through a concrete MoWA application), to be opened and augmented when interesting events are notified by those sensors; (iv) a set of augmenters that specifically implement the augmentation layer considering the underlying application domain and the observed sensors.
In the second case, another engine interprets authored applications, the ones created with MoWA authoring, that are materialized as an XML file, and specified according to the XSLTForms data model. This engine is in charge of interpreting such specification, instantiating the proper classes with the values in the data model, and then also cloning such objects in the context of the original Web page to augment. Then, in the middle, we have MoWA crowd. It is an online platform supporting crowdsourcing tasks management and a repository of MoWA artefacts, among them, a collection of applications ready to be installed and used by consumers. Concerning the source of such applications, they can be both: the ones created by developers, as discussed in  [11] , or the ones created by producers with the MoWA authoring tool.
Technical Details. Both client applications (the authoring tool and the weaver in Figure  6 ) are Firefox for Android extensions, running on version 41 of such mobile Web browser. However, they have successfully run in precedent versions, as discussed in Section 5. 2. Both applications share a common base; first, the same mobile Web browser that allows them to access the underlying capabilities of the device. For instance, it exposes multiple APIs for accessing the battery, the camera, the geolocation, the orientation, and so on. This means that developers can access values of the user's context and take advantage of them in a direct way, for example, by using the navigator. geolocation. getCurrentPosition (https:// developer. mozilla. org/en-US/docs/Web/API/Geolocation/ Using geolocation), but also by using the APIS for processing data and tracking other context types.
This way, steps « 20 » and « 21 » are different for configuring other augmenters; Figure  13  shows the configuration form for a PoiAugmenter in «  » and for a WalkingLinksAugmenter in «  ». At the end of this stage, the user can preview all the augmenters together and appreciate the layer's result, as in «  ». Below, we list all the augmenters the user adds and configures in this concrete case study: As a result of the process, a MoWA application specification is obtained, and the producer can share it with consumers. The MoWA weaver could be used for running such applications later. Let us say that the producer shares the script with Julio, his cousin, who is visiting the museum for the first time. Julio installs the authored application by using MoWA weaver and, once in the museum, he scans the first QR code he finds with the QR codes scanner provided by MoWA weaver.
Participants. We conducted the experiment with 21 experimental subjects with a very wide range of demographic characteristics. Due to the large number of participants in the session, we chose surveys as collecting data mechanism. We found that 71. 43% of the members were males, against a 28. 57% of female ones. Their ages range was homogeneous, ranging from 22 to 39 years old, with an average of 26. 9. They were of different nationalities: 14 Argentinean citizens, 3 Colombians, 2 French citizens, 2 Venezuelans, and 1 Peruvian. They were mainly ongoing students of different degree careers, representing the 52. 38% of the population, preceded by a group of the same education level but different status: 28. 58% of them already completed their studies. The remaining were, at equal frequency, people with completed high school level, uncompleted degree career, completed postdegree career, and postdegree studies in course.
Platforms. As the MoWA authoring tool was implemented as a Firefox for Android extension, it was a requisite to use any Android-based device capable of running such Web browser. Users carried their phones and installed the required software. The concrete authoring tool was successfully executed in every single device, which ranged among five different benchmarks and a total of 7 models: 8 times in a Samsung Galaxy S3 I9300, 6 in a Motorola Moto G, 2 in a LG Pro Light and a Motorola Moto E, and just once in a Blu Studio 5. 5, a Huawei G6 L33, and a Samsung Galaxy S2. Our extension successfully was run in 4 versions of the mobile browser: most of them, 14 cases (66. 67%), in the version 38. 0, 5 cases in the 39. 0, one in the 37. 0, and another one in the 41. 0. The former was the official stable version at that moment, the second was the Firefox Beta version, the third one was an old release previously installed by the user, and the latter was the Nightly version.
They were introduced to Web augmentation, mobile hypermedia applications, and in-situ development in a 30-minute talk. After that, participants were asked to complete a survey for demographic data collection. Once every participant finished the survey, a scenario was explained to them. You are about to visit the Museo de Ciencias Naturales of the Universidad Nacional de La Plata, in order to perform a special tour, that presents a set of pieces related to the Darwin's findings and descriptions made during his Voyage of the Beagle. You knew about this tour thanks to the museum's website, so you already read something about the pieces and also know they are presented in certain order. When you arrive to the museum, you observe that the pieces, not only the ones of the mentioned tour, have a QRpedia code.
g. , computer science students). When contextual information is used to support the software development process, end users can build their solutions in the same place where the needs and problems are presented. This increases the boundaries of opportunistically development a. k. a. situational applications  [44]. In this setting,  [32]  presents CASTOR, an authoring platform with a storytelling purpose. They implemented three supporting tools: a hybrid mobile application for creating stories in-situ; a Web-based client for managing the collected data, and a hybrid mobile application for consuming the narrations. The Phonegap framework supports the resultant applications, and users can share them through a repository. The authoring process is assisted through forms that allow users to select the structure of the story, define stages and context values, write the plot of the story.
There is no mention of the adopted programming technique, but the provided screenshot suggests a WYSIWYG approach. CAMUS is aimed at creating context-aware mobile or Web-based applications. Nevertheless, the authors mention that execution engines are created as native applications for different mobile devices. In the mobile field,  [33]  presents MobiDev, an Androidbased development platform for mobile application creation from mobile devices. It allows the user to create the graphical interface by writing source code, designing mock-ups with a visual editor, or drawing a sketch on paper and taking it as a picture, so the system will analyse and interpret it to generate a visual design. The approach contemplates end users with no programming skills developing applications with a basic control flow, but also developers defining a more specific behaviour through JavaScript code.
Puzzle was evaluated with 13 participants with no IT-related jobs, and they were not exposed to previous training. The authors in  [42]  propose an approach towards EUD for multidevice mashups creation with composite resources. They implemented a framework and a UI centric tool using the WYSIWYG technique. Users should select among the ✓ ✓ ✓ ✓ ✓ M M ✓ For nontechnical users ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ Users can request new requirements to the crowd ✓ M ✓ M M M M M M Users can massively share their productions ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ M Users can specify the control flow ✓ ✓ ✓ ✓ ✓ ✓ M M ✓ Additional assistance mechanisms ✓ M M ✓ ✓ M M ✓ ✓ Authoring process at client-side ✓ ✓ M M ✓ M M M ✓ Evaluation with nontechnical users ✓ ✓ M ✓ ✓ M ✓ ✓ M Evaluation without prior training ✓ ✓ M ✓ M M ✓ ✓ ✓ existing data components and UI templates in the repositories and then perform an association between data items and visual elements.
One of the domains where reuse through patterns will bring many benefits is the Real Time (RT) domain since it is a complex and evolving domain. The RT patterns help designers in developing applications that express time-constrained data and timeconstrained methods. They provide various solutions to addressing the fundamental RT scheduling, communications and synchronization problems  (Boukhelfa and Belala, 2015). Design patterns specific to the RT domain are similar to any domain specific pattern; they need a representation language that shows the specificities of the domain. They need also a design process that helps in their construction and finally an instantiation process that will guide their reuse  (Boukhelfa and Belala, 2015). Nowadays, representation of domain-specific design patterns and their reuse receives special attention from many researchers (e.
g. ,  Kim et al. , 2004; Kim, 2007). They proposed modeling languages in order to take into account pattern variability. In fact, when representing domain-specific patterns, the design language, e. g. , UML has to support not only the flexibility characteristic of patterns, but also the specificities of the domain itself  (Port, 1998). Nevertheless, in the example of realtime (RT) domain, the standard UML remains insufficient for expressing all features of RT applications. Therefore, different extensions to the UML language have been proposed to take into account RT application characteristics  (Douglass, 2004; Lanusse et al. , 1999; OMG, 2008). However, the proposed modeling languages are not suitable to patterns. That is, RT patterns must be generic designs intended to be specialized and reused by any application in RT domain.
In RT domain, we distinguish the case where applications use a lot of RT data that must be stored in a database. We call this case ''real-time domain with intensive data". Our contribution aims to guide the development of RT design patterns specific to RT domain with intensive data through the definition of unification rules that facilitate their specification. Finally, note that, even when assisting the pattern developers in expressing and building design patterns, there is no certitude that these patterns would be correctly instantiated, by application designers. Thus, an ultimate assistance in validating the pattern instantiation would be of a valuable benefit. Several researchers (e. g. ,  Kim and Carrington, 2006; Kajsa, 2013; Hammouda et al. , 2009; Koskinen et al. , 2010)  were interested in the validation of pattern instances, however their approaches are not adapted to the RT domain.
They do not take into account the UML extensions differentiating between passive resources and RT active resources and specifying RT features such as concurrency and deadline. As a consequence, there is still a need for an efficient guidance process for RT patterns reuse. In our approach, we are interested in providing assistance, not only for pattern designers to support RT design pattern representation and development, but also for application designers to instantiate RT design patterns. This assistance is provided through: (1) A UML profile intended for RT design pattern specification and reuse. This profile establishes a relation between the different systems that need similar facilities and provides a good ground to build on in order to establish a real pattern language for RT systems.
-The hhpatternClassii stereotype is used to differentiate between the instantiated pattern classes and the original classes added by the designers in an application model and to check the existence of any conflicts with pattern properties. In addition to the above stereotypes, the specification of RT design patterns needs the use of UML extensions to model RT aspects. Thus, we import from MARTE profile stereotypes which deal with quantitative and qualitative features related to behavior, communication and concurrency. From HLAM (High Level Application Modeling) subprofile, we import the following stereotypes: -The hhrtFeatureii (real-time feature) stereotype is used to model temporal features such as deadline. -The hhppUnitii (protected passive Unit) stereotype is used to model the shared data requiring the specification of concurrency policy.
The Measure class models the RT data, which are classified into either base data or derived data. Base data are issued from sensors, whereas derived data are calculated from base data. The derived data have the same characteristic of base data (timestamp, validity duration,. ). The relation between base and derived RT data is represented by an optional and reflexive association defined on the Measure class. This class is stereotyped hhppUnitii since it represents a passive resource, which needs to be set and controlled by active resources (like controller). It provides a RT service called updateValue. This operation carries the concurrency kind (writer) and the execution kind (remoteImmediate) indicating that the execution is performed immediately with the called active object (Controller).
This approach requires the definition of appropriate stereotypes for each design pattern. Thereby, the developer must know the different stereotypes related to each applied design pattern and must also understand the semantic of each stereotype meta-attributes (i. e. , tagged values). Kim and Carrington (2006)  proposed a formal approach, based on Object-Z  (Graeme, 2000) , which allows defining and reusing design patterns. They formalized the role metamodel that constitutes the modeling language used to define design patterns and consistency constraints. The role metamodel defined in Object-Z is automatically transformed to an Ecore model and then implemented using the Eclipse Modeling Framework (EMF)  (Steinberg et al. , 2008). These authors used also Object-Z to formalize the binding meta- model that maps pattern entities to application model entities and to define the constraints that must be preserved to make the pattern deployment valid.
Identification of domain functionalities The first step aims to delimit the domain boundaries and it consists in identifying the most important domain subproblems. Each sub-problem has one main functional goal to achieve, called domain functionality. The most important functionalities related to the domain are identified through the collection of information brought by experts and stakeholders. The functionalities identified in this step help the developers to determine the context of each created pattern. In RT domain with intensive data, all applications share a common behavior: they monitor and control an environment via values reported by sensors. By examining these applications, we distinguish three main domain functionalities: (i) acquisition of RT data from the environment via sensors, (ii) RT data analysis and production of results within time constraints, and (iii) sending of orders to the environment via actuators.
Identification of requirements This step consists of refinement of the domain functionalities. Each identified functionality is decomposed iteratively into functions until reaching a level at which the functions become elementary. This step identifies all the domain concepts and constraints associated to each functionality. The functional domain requirements at this step are represented as a pair hF, Efi where F is a domain functionality and Ef is an elementary function. a. The RT data acquisition functionality is decomposed into four elementary functions: Ef 1 {the sensors (e. g. , radar, camera,. ) observe physical elements in the environment, e. g. , an aircraft, a vehicle, a patient, and so on}. Ef 2 {the sensors acquire measures (e. g. , speed, temperature, pressure, pulse,. )}. Ef 3 {the active sensors transmit periodically the acquired measures to the compute unit in order to be stored in a RT database (push mechanism)}.
Ef 4 {the passive sensors are solicited periodically to transmit the acquired measures to the compute unit in order to be stored in a RT database (pull mechanism)}. Note that Ef 3 and Ef 4 are the two possible alternatives of RT data transmission. Moreover, a set of domain concepts, such as Sensor, Active Sensor, Passive Sensor, Measure, and Observed Element, are identified during the refinement step. Active Sensor and Passive Sensor are domain concepts that represent a variation of a general concept which is Sensor. These concepts will be used in the next step, which is decomposition. b. The RT data control functionality is decomposed into five elementary functions: Ef 1 {a controller monitors the state of each observed element}. Ef 2 {a controller calculates derived value (i. e. , derived data) from captured value (i.
Unification of application designs The unification rules allow the unification of the different application fragments and, then, the generation of RT design patterns. The unification consists in finding the common classes of all the applications and deriving the fundamental elements of the patterns. Then, the classes specific to the applica- tions are extracted as variable elements. The unification rules are based on semantic comparison criteria. These latter rely on linguistic relationships to define semantic equivalence and variation between class, attribute and operation names. The determination of the linguistic/semantic relations is handled through either the lexical database WordNet or the domain dictionary that we have created (cf. Fig. 3 ). Designers are asked to verify whether the names of model elements (i.
A. 2. Class diagram construction of RT controller pattern The objective of RT controller pattern is to model both the control of data acquired from the environment and the initialization of corrective action(s) in case of constraint violation. The RT data control sub-problem is decomposed into six elementary functions (cf. Section 3. 2). Table  A1  shows the concepts and domain constraints related to each identified elementary function. After the requirements identification phase, the classes belonging to each application and playing the role of Controller, Observed-Element and Surveillance Operator must be identified in order to determine the applications fragments related to RT data control functionality, as illustrated in Table  A2. The application fragments obtained after decomposition step are:      range [Minimum-Value, Maximum-value] before a deadline; otherwise the initialization of corrective actions may have no effect.