dataesr/scientific-paragraphs-categorization huggingface dataset:
Back Close Full   geographical data and systems. Scenarios builder applications refer to (e. g. Felpeto et al. , 405 2007; Gehl et al. , 2013). 406 407 Fig. 2. Scope of the WebGIS developed within this study with respect to other relevant geographical data and systems. Scenarios builder applications refer to (e. g. Felpeto et al. , 2007; Gehl et al. , 2013)   the GIS Data DBMS, refers to the privileges granted on the GIS layers contained in the GIS 435 Repository. For example, the rules that define the privileges of each user to visualize the data 436 are stored in the GIS data DBMS. 437 Fig. 6. Scheme of the WebGIS Architecture. The system is divided in several components: one WEB server that manages the exchanges of information through the Web, one AAA server (Authentication Authorization & Audit), which provides security services ensuring that each user receives the relevant privileges for each status of the volcano (here: inactive, moderate activity, eruption).
The GIS publisher is the component that finally supplies the data. It includes a wrapper that ensures that the requests are managed according to the rules provided by the AAA Server. Finally, the GIS database and the rules are stored respectively in the GIS and AAA repository. The Applications DBMS (DBMS: data-base management system) refers to the privileges granted to the various components of the system. Conversely, the GIS Data DBMS, refers to the privileges granted on the GIS layers contained in the GIS Repository. For example, the rules that define the privileges of each user to visualize the data are stored in the GIS data DBMS. Introduction.
Back Close Full    The users can search the GIS database using the meta information stored along with the geographical data -screen bottom three panels. The selected GIS layers can be saved as independent scenarios and later retrieved from the server, as well as user's vector features (polygons, lines and points) can be added to the visualization area, saved on the server for further use and shared with the other WebGIS users. (B) Shows the server GIS Layers Manager component. This module allows the management of all the GIS data contained in the database, including the promotion/demotion of the "validation level" associated with each GIS layer. In the left side the system shows all the management modules that allow the management and configuration of the whole system, including the switch from one Alert Level to another.
Acknowledgements. This study was undertaken within the  MIAVITA  project, which is financed by the  European Commission  under the 7th  Framework Programme for Research and Technological Development, Area "Environment", Activity 6. 1  " Climate Change, Pollution and Risks ". We thank a group of experts who participated to the design of the WebGIS. Particular thanks to  A. Salvati ,  A. Canestro ,  F. Doumaz ,  C. Christiani ,  V. Bosi ,  L. Colini ,  J. Loiseau ,  B. Faria ,  J. Berger ,  A. Daag ,  R. Solidum  and  C. Bignami  for their most active participation.
Acknowledgments This work was partially funded by  FONDECYT  grants  11075028 ,  1085188 ,  1114153 , and  1110674 ,  CONICYT ANILLO  grant  ACT-88 ,  Basal  project  CMM  ( Universidad de Chile ), the  Millenium Institute on Complex Systems  ( Universidad de Chile ) and the  Fundação para a Ciência e a Tecnologia , under the project  PEst-OE/MAT/UI0152.
Problems Each platform uses different tools, programming languages, user interface declarations and memory management. If a developer wants to create an application for every platform, he will have to buy one PC and one Mac. Then, he will have to follow different formations, one by platform. Finally, he will have to buy at least one phone for each kind of platform and sometimes even multiple phones for one platform, like for the Android case. Most of those constraints must be respected. For example, we are not going to change the development environments. Indeed, these tools are very efficient (debug, device monitoring. ), so the implementation of a new environment is useless. The application design and implementation steps are the two critical phases to create a cross-platform application.
Indeed, even if an application must run the same functions on every platform, it is impossible to design it once and run it everywhere. Depending of the host, the application behaviors can be different too. To demonstrate the importance of these two steps in the application creation process, we have developed a basic third-party application for iOS and Android. This application is made up of a tab bar with two tabs. On each tab, there are basic views (buttons, text fields) with the target platform look. Each button launches a functionality like the creation of a database, the capture of a picture, the navigation in photo album, the opening of a web page. From one tab, users can open a web site. They can also open a new page to manage the camera or a database. On the camera management page, users can launch the camera and take a picture or navigate through the photo album.
On the database management page, they can create or remove a database. Finally, from another tab, they can send a text to another view. The implementation for the two platforms of this basic application is already complicated for a developer. He must navigate between different concept. For example the developer can use a navigationController on iOS whereas this object doesn't exist on Android. Then, on Android, to launch certain actions, we must used intent process (navigation between views, hardware access. ) whereas on iOS, this notion is missing. For a mobile developer, it is very difficult to change its thinking manner, according to the platform, during the implementation process. Therefore, we have to hide the uncommon notion between target platforms.
Related work The solutions which enable the implementation of cross-platform applications, can be classified in three categories: the cross-compilers, the solutions based on the model-driven engineering and finally the interpreters of source code. MoSync 1  , Corona 2  , Neomades 3  and XMLVM  [2]  are based on cross-compilers. These solutions aim the crossplatform application creation through a common language. Then, the instructions written with this common language are translated in native language. In this case, the reused code is complete but the mapping between the application language and the native target language is very difficult to achieve. That's why, in the most cases, the cross-compiler only manages few platforms and is limited to common elements from each platform. One other part of existing solutions is based on model-driven engineering.
To one side, UsiXML  [3]  and Jelly[4] allow users to produce user interface for multiple platforms. On the other hand, MobiA modeler  [5]  and AppliDE  [6]  (that is integrated in CAPucine  [7] ) allow users to produce a complete application and even a context-aware application. To create context-aware application, CAPucine's designers allow users to separate their applications in modules. Some of them will be integrated in the application at the transformation whereas the others will be loaded at the execution according to the context. To resume, with these solutions users can define theirs applications from models. Then, these models are transformed into source code for each target platform. But like cross-compilers, the translation between models and native source code is difficult to achieve if the developers want to manage any native component.
Finally, there are the solutions based on web technologies. PhoneGap 7 , QuickConnectFamily 8 , Rhomobile 9 allow to load, on the device, web applications (similar to websites) able to access the device hardware. Another solutions allow the execution on multiple platforms of widgets ("small" applications for mobile devices) from a crossplatform engine as xFace  [9]  or Opera 10. In  [10] , xFace's designers explain how xFace is ported on many platforms. They defined a porting layer which is the combination of several components (e. g. file systems, graphics) common to each platform. This separation simplify the mapping between the engine and the target OS. Furthermore, in  [11] , the authors allow the automatic generation of widgets with a new language: Widget Markup Language. As for Titanium mobile 11 and Flex linked to Flash builder 12 , they enable the use of web languages like any programmatic language in order to implement cross-platform application.
Component layer During the first step, we will consider the component developers' point of view. The goal is to implement a set of components which perform one or several functions on any mobile platform. These components must be able to access any hardware native functions like camera, GPS and any native software like buttons, text fields, map, etc. First of all, we define a component. It consists of one public interface that represents its functions and its internal process that is hidden to user. In addition our components should be integrated on different platforms. Therefore, each targeted platform will have a particular native implementation (like Objective-C for iOS, etc. ) by component. Using native languages gives the best possible efficiency and a full access to each platform. The public interface is common to all its implementations.
First implementation In this section, we followed the three steps previously presented. We began by the implementation of a number components (for iOS and Android). Then, we defined two possible instructions with our universal language. These two instructions enable to use component methods in a mobile native project. Finally, we developed a prototype of our cross-compiler which is able to translate the two possible instructions in native code for an Android project. The implementation for a iOS project is in progress. Here, we present only one component which enables to get information on the device like its UUID and its level of battery. Before using it, the users must initialize the component with a TAG. This TAG will be used in the log files. This component has a native interface on each target platform [Figures  2, 3 ] which are gathered together in a common interface [Figure  4 ].
Of course, only the common interface will be visible whereas all the native code (interfaces or implementations) will be hidden to users. We want to hide the native code to facilitate and unify the use of components. The common interface is deliberately vague, the main goal of this interface is to inform users on the component's possibilities independently of a platform. This interface is coming with another one which contains the details on the implementations for the different target platform [Figure  5 ]. To summarize, the first interface enables users to understand the component whereas the second will be used by our tools to handle the components. <target name="Android" nameExecutable="DeviceManager. jar"/> <target name="iOS" nameExecutable="DeviceManager. framework"/> </platforms> <configurations> <configuration name="initWithTag" description="init the tag used in log files"> <parameters name ="tag" type="String" io="in" description="Tag used in log files"/> </configuration> </configurations> <methods> <method name="getUUID" description="Get the device's UUID"> <parameters type="String" io="out" description="UUID of the device" /> <!--Others parameters can be dependant of the platform --> </method> <method name="getBatteryLevel" description="Get the device's battery level"> <parameters type="String" io="out" description="Battery level of the device" /> </method> </methods> </Component> description="Get the device's UUID"> <iOS className="DeviceInfoManager"> <parameters type="NSString*" io="out" description="UUID of the device" /> </iOS> <android className="DeviceInfoManager" packageName="fr.
Therefore, the result of the method described in the annotation (getUUID) will be assign to the variable 'UUID'. Finally, we have developed a compiler which is able to translate our instructions in native codes. For now, only the method annotation needs translation [Figure  6 ]. The var annotation only allows to declare the variables used in For example, in the android and iOS interfaces of our component [Figure  2 , 3], the method 'getUUID' has a parameter on Android whereas on iOS the method doesn't have parameter. To summarize, the users can write the same instructions to integrate a component in any application running on any platform. Then, it is our cross-compiler that will manage the code integration and, therefore, hide the component access and the component implementation details.
Moreover, the Web is the world's largest source of information. The Web is very rich with distributed and heterogeneous data (e. g. , semi-structured/unstructured data, chat logs, e-mails, images, videos, feedback and surveys). Other valuable data types include relational databases (deep Web), HTML/XML documents, spreadsheet files, RSS feeds, on-line transaction records, external data feeds, sensor and streaming data. We term such data complex data. Data may be qualified as complex if they are: diversely structured, represented in various formats and models, originating from several different sources, described through different perspectives and/or changing in terms of definition or value over time  (Darmont et al. , 2005). One of major problematic issues that we address in this paper is to warehouse complex data into a unified storage to be later analyzed for decision-support purposes.
Therefore, "real-time" or "near real-time" data should be integrated to minimize latency delays between BI systems and business operations for better decision making. Since traditional data integration systems are passive in nature, data integra-tion tasks conform to a static scheduling plan, whereas real-time and near real-time processing require more active ETL processes. Therefore, today's DW/BI applications must react in an intelligent, i. e. , active and autonomous way, to encountered changes in the data integration environment, especially data sources. In this paper, we propose an approach for integrating complex Web data in near real-time, actively and autonomously. We indeed provide a generic metadatabased, service-oriented and event-driven approach for integrating Web data. The main contributions of our approach follow.
Firstly, the complexity of Web data is handled using our metadata-based and service-oriented features of our approach. For instance, heterogeneous Web data are unified and integrated into a common repository by exploiting the XML language. The XML language bears several interesting features for representing, exchanging and storing Web data. Moreover, data distribution and interoperability are tackled using Web services. Beside exchanging data among different applications and platforms, Web services provide transparent access to a variety of relevant data sources as if they were a single source. Additionally, Web data are integrated into a unified repository of AXML documents. AXML documents are XML documents where some of the data are given explicitly, while other parts are given implicitly by embedding calls to Web services  (Abiteboul et al.
, 2008a; Phan et al. , 2012). The AXML technology is mainly used in peer-to-peer mediation, but we reuse it in data warehousing. Secondly, our service-oriented feature ensures integrating data in near real-time using a bi-directional strategy, i. e. , forward integration (push) and backward integration (pull). Beside employing integration services to carry out traditional ETL tasks, some management services (i. e. , change detection services) are employed to track data changes and push them to integration services. Indeed, integration services (change consumers) subscribe to change detection services (change providers) to be notified with only relevant near real-time changes. Moreover, by integrating data into an AXML repository, not only data are warehoused, but also functions (or services) for integrating data on-the-fly.
In a pull strategy, embedded AXML services are invoked implicitly or explicitly to enrich and refresh the repository with data in near real-time. Thirdly, we provide an event-driven approach for integrating data actively and autonomously. The simple idea of this approach is to warehouse all logged events that describe integration activities into an XMLbased event repository. Then, the warehoused events are mined and analyzed to maintain, automate and reactivate data integration tasks. Therefore, we propose an efficient incremental algorithm for mining association rules from logged events in XML format  (Salem et al. , 2011). A novel compressed tree structure, namely FXT (Frequency XML-based Tree), which contains most critical information about logged events is proposed. An FXT is built with a single-pass over logged event and enables transaction insertion alongside transaction deletion.
Both frequent events and association rules are discovered from FXT using XQuery. Furthermore, active rules are incorporated to reactive data integration tasks. Such rules are defined either explicitly by the user or implicitly by querying frequent events and association rules from the FXT. Finally, to validate our approach for managing Web data integration, we develop a high-level software framework using open-source tools. The framework prototype is implemented as Web application. The rest of this paper is organized as follows. In section 2, we review the state of the art of data integration, Web warehousing, real-time/active warehousing, and AXML and active rules for XML. Section 3 introduces our generic framework for complex Web data integration. The role of active metadata in data integration is presented in section 4.
Virtual data integration In a virtual view approach, data are accessed from the sources on demand when a user submits a query to the information system. Examples of integration systems that use the virtual view approach are federated database systems and mediated systems. A Federated Database System (FDBS) is a collection of autonomous database components that cooperate for sharing data  (Sheth and Larson, 1990). Mediated systems integrate data from heterogeneous data sources by providing a virtual view of all data sources, e. g. , as in the TSIM-MIS  (Chawathe et al. , 1994)  and Ariadne  (Knoblock et al. , 2001)  projects. They handle not only operational databases, but also legacy systems, web sources, etc. Mediated systems provide the single mediated schema to the user, and users pose their queries w.
Mechanisms that incrementally improve semantic relationships between data sources over time are also provided in PAYGO. XML and Web services are also employed for integrating Web data in federated systems  (Zhu et al. , 2004) , and in peer-to-peer (P2P) and mediated systems, e. g. , in the AXML project  (Abiteboul et al. , 2002 (Abiteboul et al. , , 2008a)). Vidal et al. (2008)  propose a framework for generating AXML Web services for materializing the dynamic content of Web sites whose primary goal is publishing and integrating data stored in multiple data sources. In this framework, the dynamic content of a Web page is defined as a (virtual) view, and the view is specified with the help of a set of correspondence assertions, which specify the semantic mapping between the XML view schema and the base sources schema.
Furthermore, mashup-based data integration provides a programmatic, data-flow-like and service-oriented approach for Web data integration  (Lorenzo et al. , 2009). In addition to the fact that mashup tools are mainly designed for handling Web data, such tools are mostly simple and do not develop advanced programmatic data integration, e. g. , to analyze large sets of Web data. Therefore,  Thor and Rahm (2011)  present an advanced script language that provides operators for data integration tasks such as query generation and entity matching. This language is presented in CloudFuice, which fol-lows a mashup-like specification of advanced dataflows for data integration in the cloud.
Beside relational data warehousing approaches, there are a variety of approaches proposed for XML data warehousing. The main purpose of such approaches is to enable a native XML storage of the warehouse, and allow querying it with XML query languages, mainly XQuery. Several researchers address the problem of designing and building XML warehouses. For instance, the snowflake schema is adapted with explicit dimension hierarchies  (Pokorný, 2002). Mahboubi et al. (2008)  also propose an architecture model to translate the classical constellation schema into XML. Hümmer et al. (2003)  propose a family of XML-based templates called XCube to store, exchange and query data warehouse cubes. Rusu et al. (2005)  propose an XQuery-based methodology for building a data warehouse of XML documents. It transfers data from an underlying XML database into an XML data warehouse.
Active XML and Active Rules for XML Active XML is considered as a useful paradigm for distributed data management on the Web. AXML documents are XML documents with embedded calls to Web services. When one of these calls is invoked, its result is returned to enrich the original document  (Abiteboul et al. , 2008a). There are several issues studied in P2P architectures, such as distribution, replication of dynamic XML data, semantics of documents and queries, confluence of computations, terminations and lazy query evaluation. Several performance and security issues for Active XML are addressed  (Milo et al. , 2003) , e. g. , the problem of guiding the materialization process. Ruberg and Mattoso (2008)  handle materialization performance issues, when the result of some service calls can be used as input of other calls.
Another issue is continuous XML queries, which are evaluated incrementally as soon as there are new data items in any of their input streams  (Abiteboul et al. , 2008b). Active rules are widely known in active databases  (Paton, 1999). They follow the Event-Condition-Action (ECA) paradigm, which describes actions to be taken upon encountering an event in a particular database state. These rules are then associated with objects, making them responsive to a variety of events. Active rules are also proposed for XML. Bonifati et al. (2002b)  propose an active extension of the Lorel and XSLT languages, for using active rules on the implementations of e-services. Bailey et al. (2002)  investigate ECA rules in the context of XML data. Rekouts (2005) also describes a general form of active rules for XML based on XQuery and previously defined update languages.
Furthermore,  Naeem et al. (2008)  discuss an eventbased near real-time ETL for transferring and transforming data from operational databases to a data warehouse. The authors propose an event-driven and nearreal time architecture for ETL that uses a Database Queues (DBQ), works on a push technology principle and supports content enrichment. A detailed state of the art study of near real-time ETL is discussed by  Vassiliadis and Simitsis (2009). The authors also detail the infrastructure of near real-time ETL presenting alternative topologies, issues related to parallelism and partitioning techniques, and issues concerning the communication of the different parts of the architecture. Finally, several technological issues and considerations when building real-time data warehouses are discussed by industrial communities  (Oracle, 2010; Brobst and Ballinger, 2003).