dataesr/scientific-paragraphs-categorization huggingface dataset:
Conclusions and Future Work We have presented our techniques to reconcile a schema matching network through crowdsourcing. The algorithms take the correspondences generated by automatic schema matchers as input and they generate validation questions. The crowd workers respond to these questions by indicating whether a particular attribute correspondence should be accepted or rejects. We can express various natural expectations about the network in the form of integrity constraints. We demonstrated that these constraints can be exploited in various ways: they enable to improve the worker assessment methods, they can be used to reduce the necessary validation efforts. Moreover they are also usful for spam detection. We demonstrated these desirable properties through our experiments on real datasets, with the help of a simulated crowd population.
Acknowledgement. This research has received funding from the  NisB project -European Union's Seventh Framework Programme  (grant agreement number  256955 ) and the  PlanetData project -Network of Excellence  (grant agreement number  257641 ). The work of  Zoltán Miklós  was partially supported by the project  Aresos , financed by  CNRS  through the mastodons programme. The authors thank for anonymous referees for their helpful suggestions.
There is a multitude of mobile OS: iOS android, Windows Phone 8 and each OS provides its own standards and tools. This heterogeneity in the mobile domain forces developers to implement an application for each mobile platform. To achieve that, developers need to master several languages (Java, Objective-C…). They also need to have several devices at their disposal (PC, Mac, many smartphones …). Then, after applications distributions, developers have to maintain several source codes. In this study, we tackle this problematic. Our goal is to soften the differences between each OS in order to simplify the development of cross-platform third-party applications. To achieve that, we have defined a framework called COMMON (Component Oriented programming for Mobile Multi OsiNtegration). This framework allows the integration of cross-platform components in any application (iOS android).
To run our components on any OS, we provide an implementation for each platform. However, to make their integrations easier, we also provide a common public interface of each component, which is platform-independent. Besides, we provide a common language, also platform-independent, allowing the integration and use of any component in any native application (iOS android). This language is based on annotations. Finally, we have implemented a cross-compiler, which translates the source code written with our language to native source code: Objective-C for iOS, Java for Android,… In this study, we have shown that our solution offers performance and memory consumption closed to native applications. Finally, with COMMON, mobile developers implement less lines of source code than with a native application.
Current Situation Each platform uses different tools, programming languages, user interface declarations and memory management. If a developer wants to create an application that works on all platforms, he should buy one PC with Windows 8 and one Mac. Then, he will have to follow different trainings, one per platform. Finally, he will have to buy at least one phone for each kind of platform and sometimes even multiple phones for one platform, the same as in the case of Android. 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 on the host, the application behaviors can be different too. To demonstrate the importance of these two steps, we have developed a basic application for iOS and Android.
This application consists in only one view. On this view, we have added a button "close the application". When the user clicks on this button, the application displays a popup that contains the message "The application will be closed" and a button "OK". When the user clicks on the button "OK" the application is closed. We have analysed the source code and found multiple differences. First, the source code is implemented in two different development environments: Xcode for iOS and Eclipse for Android. Second, the user interface is implemented in two different manners. In iOS, we use interface Builder. This editor allows us to choose the graphical elements and to drag and drop them on a view. Whereas on Android, we define the user interface from XML files. It is also possible to use the same process as on iOS (drag and drop) with the graphical layout proposed by eclipse but developers rarely use this tool.
Indeed, it is easier to implement the views in XML than with the graphical layout because this tool does not provide a simple mechanism to take into account the screen heterogeneity of the Android devices. Third, the languages to implement the application behaviours are different: Objective-C for iOS and Java for Android as shown in Fig. 1  and 2. Fourth, the links between the source code and the user interface are different for each platform. For example, to link an action to the button "close the application", on iOS, we must use Interface Builder and link an IBAction on the "press button" event whereas on Android, we must get an element reference from the XML file and then add a listener to it. Fifth, when we want to create a popup on iOS, we must provide a delegate to the popup in order to get the click events on its buttons.
This is the case of MoSync, (http://www. mosync. com/) Corona (http://www. anscamobile. com/) and Neomades (http://neomades. com/). This limitation is even more present when the common development language is based on a usual mobile SDK (e. g. android SDK or iOS SDK). In this principle, XMLVM  (Puder and Yoon, 2010)  enables the implementation of an application for Android, iOS and Palm Pre from Android source code. One other part of existing solutions is based on model-driven engineering. With these kinds of solutions, developers can define theirs applications from models once for several target platforms. Then, these models will be translated into source code for each target platform. But like cross-compilers, the translation between models and native source code is difficult to achieve, especially, if the solution providers want to manage any native component.
JCS Today, web languages are accessible to everyone, that's why several solutions based on it have emerged. Multiple strategies were defined for mobile web applications. One of them allows uploading, on the device, of web applications, which can be compared with mobile websites being able to access the device hardware. PhoneGap (http://phonegap. com) QuickConnectFamily (http://www. quickconnectfamily. org/) Rhodes (http://www. rhomobile. com/) follow this strategy. Several of these solutions are presented in  Allen et al. (2010). Another mobile web development branch is based on widgets (Duarte and Afonso, 2011): "Small"applications for mobile devices. These widgets are implemented with web languages and run through a cross-platform widget engine such as xFace  (Jiang et al. , 2010)  or Opera (http://dev.
opera. com/addons/widgets/). Pan et al. (2010) , the xFace designers introduced a lightweight engine of widgets running on several platforms. To port this engine on many platforms, they define a porting layer, which is the combination of several components (e. g. , file systems, graphics) common to each platform. This separation facilitate the mapping between the engine and the target OS. Finally, there are solutions, which are using the web languages like any programmatic language in order to allow the implementation of an application with mobile specificities. Titanium mobile (http://www. appcelerator. com) and Flex linked to Flash builder (http://www. adobe. com/products/flashbuilder. html) are based on this strategy. In the section 6, we compare our approach with Titanium mobile. This solution probably provides the most mature framework.
). However, this kind of solutions does not work if the device is disconnected. A possible perspective is to implement hybrid components with another existing solution (e. g. , javaScript linked with PhoneGap or Titanium mobile). In this case, the component could work on the cloud or on any device (iOS android. ). If the connection to the network is good, the component will run on the cloud, else it will run on the device. The above solutions cited propose some interesting directions to consider, however up to now no tool could respond to all our needs. The most contributions are limited to most common hardware features for a basic use. Besides, the user experience provided is not acceptable for our needs and applications obviously have less interesting performances than native implementation.
COMMON FRAMEWORK Mobile developers will integrate cross-platform components in their applications, thanks to a language based on annotations. Indeed, we provide a set of crossplatform components that are application-independent. A valid component must be reusable in several applications. Besides, our components are platformindependent. To do that, we have defined the structure of our components as shown in Fig. 3. A component has one implementation per target platform: Implemented with the iOS SDK, then with the Android SDK and so on. By providing native implementations, our components are able to use any hardware or software element of any platform. Therefore, our components, graphics or running in background, will be perfectly integrated in a native application without altering the host application.
Finally, we have defined a cross-compiler that translates all instructions written with our language to native language (for Android, iOS,). To achieve that, the translation process is based on the complement interface of each component. Indeed, mobile developers specify the use of a method with our common language and the complement interface contains all the methods of a component in XML. This is a light process with some simple rules. First, our compiler parses all the complement interfaces of our components. Then, it parses the developer's project; it gets all instructions written from our annotations. Of course, it checks the validity of each instruction (existing methods, good input parameters. ). Thus, if the source code is correct, the cross-compiler only translates the XML representation method to a native call with the parameter defined by mobile developers.
All the instructions written with our language will be the same for each target platform. We unify the integration of our components. Finally, our cross-compiler transforms all annotations in native languages. At the end of the process, our framework provides complete native applications for iOS android and so on. In this study, we differentiate two kinds of developers: Mobile developers and component developers. The first one uses our solution to implement mobile applications. They will integrate our components. Whereas, the second one implements components which will be used by mobile developers. The mobile developers do not implement components. In the next section, we are going to present our solution to implement a concrete application. We are going to focus to component implementation by component developers and integration by mobile developers.
COMMON FRAMEWORK IN SITUATION To validate our solution, we have chosen to develop a utility application called LocaPlace. This application is a concrete application with a professional style and an advanced user experience. The goal is to provide a deployable application for mobile users. Thus, we will be able to generalize our approach for all possible applications. The user interface and the navigation between views have been developed in native languages whereas most of the other features were integrated with our common language based on annotations. The instructions written with our language allow the use of six different crossplatform components. In this section, we present the Locaplace application, then the required functionalities, which are provided by our framework. Finally, we present the integration process of a cross-platform component, which is representative of our components.
After displaying the information, users can find an itinerary from their location to the place. In this application, the developer needs six application-independent services: • Auto-completion from an array • Auto-completion from a database with several columns selected • Sending of Http Requests to Google Web Services • XML Parser for the responses of Google Web Services • Getting information about the device such as location service and network information • QR-Code Scanner To make these services available to mobile developers, we provide a set of components in our framework. Among them, we have six cross-platform components that implement the required services. In the next parts of this section, we focus on another component: HttpRequestManager. We are going to present its native, common and complement interfaces in 5.
Indeed, our components can have several internal methods, which are hidden to users. Unlike this interface, the complement interface shown in Fig. 9  is entirely dependent from all supported target platforms. It gets component native function signatures presented in Fig. 6  and 7  to translate them into XML. For example, in Fig. 9 , we show the representation of the "sendHttpRequest" method signature on Android and iOS in XML. Our compiler, as presented in section 5. 3, uses this interface to translate annotations in native language. We have presented here the necessary tasks to implement and transform a native component into crossplatform component in our solution. Finally, we provide to mobile developers an executable file and a common public interface, which is independent from the platform.
, 2010; Allen et al. , 2010)  and it is the most mature solution in the market. With Titanium mobile, the application developers write their entire application in JavaScript. Then, the applications are embedded on the phone with an engine, which is able to interpret JavaScript and the Titanium APIs. By choosing Titanium mobile, we can compare our solution with web-applications. However, the Titanium mobile version is not reliable. Depending on the device on which the application is deployed, the application can stop its execution on certain views in a random way. Analysing the logs, bugs are not coming from the provided application but from Titanium SDK itself. Today, such application cannot be subject to a widespread deployement for the general public. In the next subsections, we have first calculated the lines of code saved using our approach, compared to the native application.
Lines of Code Saved We have compared the number of lines of code written in the native version and in the version with our framework, see Table  2. For this evaluation, we do not consider the Titanium mobile version because it is unusable. We are not able to determine the number of lines of code that need to be written to make it usable. To calculate the line numbers of each application version, we have used the "metrics" plugin installed in eclipse (Metrics plugin website: http://metrics. sourceforge. ne). Using our approach, the developer writes two thousand lines of code less than by using the native SDK. Besides, the parts, which are not implemented, are often the most complex ones (parsing, scanning, sending of http request…). With our approach, the developer only needs to implement the application views and the navigation between them.
This good coefficient is due to the low-level of the task. Indeed, in this task, we executed sql requests to sqlite database. We can think that Titanium mobile delegates these actions to the native SDK. In these conditions, we can consider that it is a similar approach with ours and therefore, the solution is able to provide good results. Unlike the low-level tasks, the others are much slower. In the worst case, Titanium mobile is 11. 22 times less efficient than our approach (itinerary computation). Here, the process is entirely executed from JavaScript source code. This means that the execution of a web language (like JavaScript) has an additional cost that is not insignificant. PhoneGap, another popular web-based solution, provides the same ratio in terms of execution time as Titanium mobile  (Corral et al.
JCS Finally, as shown in Fig. 14 , with our approach, the application uses the same ratio of RAM as the native version (to around 70% until 80%). The loading of components (jar files) has no influence on the RAM consumption. Whereas, with the Titanium mobile version, the application uses all the time to 95% until 99% of the available RAM on the device. This consumption may have a cost in energy consumption and probably the application often stops its execution because it has no more available RAM. Nowadays, we can read many discussions about Web-apps versus native applications  (Mikkonen and Taivalsaari, 2013; Corral et al. , 2011; Charland and Leroux, 2011). But as shown with the results, Table  5 , we can conclude that the use of web languages to implement mobile application has a non-negligible cost in terms of performances and consumes more RAM than our application.
CONCLUSION The development of mobile cross-platform applications is very hard to accomplish due to the OS heterogeneity. Indeed, mobile developers must provide one version per target platform. Each version will be implemented with different standards, programming languages. These differences have a significant cost for the developer. That's why, in this study, we propose a new approach which soften the differences between each OS. Our framework, called COMMON for Component Oriented programming for Mobile Multi OsiNtegration, allows developers of mobile cross-platform applications to integrate crossplatform components, with platform-independent a language, in any native application. COMMON is based on a set of cross-platform components. Components have one implementation per target platform.
In term of development tasks, the developer has saved 28% of code lines for our sample application. The evaluation has also shown results closed to native application. Indeed, our solution provides execution times similar to native applications. We observe the same result in term of used RAM, or application weight. We can conclude that our solution does not bring an additional cost to mobile applications. Furthermore, we have also compared our approach with Titanium mobile. We obtained better results than Titanium mobile on all evaluation criterias and especially, we do not limit the use of native elements (software or hardware) contrary to Titanium mobile. Using our solution, developers can implement the user interface and its behaviour in native languages. This flexibility allows them to implement any application withoutany limitations.
The objective of this work is thus twofold: to show the persistence of the flow Downloaded by [Universidad Nacional del Litoral], [Mariana Morell] at 09:31 17 December 2014 pattern developed at the diffluence despite recent morphological changes experienced by the site, and to test a simple solution to the chronic sedimentation problem seen at the access channel mouth. Knowledge gained during the execution of the study helped to refine and validate a computer code developed to process field data captured with two acoustic Doppler current profilers (ADCP). Both, field and numerical results show that the two branches of the diffluence act like true river bends, and consequently are prone to developing secondary currents. Field data show this is indeed the case along the right branch, which was the only systematically measured branch.
It remains to extract the results from the open-source Telemac system (Telemac-Mascaret Modelling System 2014), following the field data treatment, in order to assess the predictive code capability to reproduce the observed secondary currents. The following section describes the study site and the collected data, including a brief description of the in-house software developed to treat the field data. Then, a description on how and why the right downstream branch of the diffluence acts as a river bend is presented. Finally, a qualitative comparison between simulated results and observed cross-flow data is given next, to close with the proposed engineering solution to the access channel sedimentation problem.
Velocity measurements Data captured with ADCP are routinely used to study 3D flows, and the trend is to repeat transects along linear routes to resolve weak cross-stream velocities  (Dinehart & Burau 2005). In this work, two different ADCP has been systematically used in the study site; a 1000 kHz RiverSurveyor manufactured by Sontek and a 1200 kHz Workhorse Río Grande manufactured by Teledyne RD Instruments (TRDI). The proprietary software packages RiverSurveyor and ViewADP for the Sontek ADCP, and WinRiver II for the TRDI ADCP were used for data acquisition and integration with positional information from satellite data. However, and due to an ongoing effort to develop a set of in-house routines to process the field data, the present work restricts the analysis regarding the 3D structure of the flow velocity to data captured with the Sontek ADCP, whereas flow discharge data analysis is limited to the TRDI ADCP measurements.
A full description of the in-house codes is beyond the scope of this work. Water velocity and bathymetry data were collected using one of the ADCP in parallel with a differential Global Positioning System (dGPS) receiver with Real-Time Kinematic (RTK) technology. The RTK system, sampling at the rate of two positional points per second, provided accuracies of ± 0. 02 m in planar and ± 0. 04 m in vertical direction. A second serial port to connect a digital 210 Hz Raytheon single beam echo sounder was attached to the on-board computer during the surveys. The down-looking ADCP was mounted on the side of a fibreglass-hull vessel of 6. 4 m in length, when a combined bathymetry and flow velocity field survey were carried out using the moving boat methodology  (Muste et al. 2004 ). For most of the field works, the Sontek ADCP was set to a cell size and sampling interval (or ensemble) of 0.
Nevertheless, in order to verify if the adopted cross-section orientations were supposedly perpendicular to the primary flow direction, two floats made with a 1. 8 m long and 5 cm-diameter PVC tube and equipped with Blue-tooth GPS (Garmin 10X) were used to identify depth averaged particle paths at the sharp turn of the navigation channel inlet. Data from the GPS were logged at 2 s interval onto a portable computer (with enhanced Blue-tooth communication of up to 100 m reach) by using standard navigation software. The floats were released just 100-150 m upstream of the Colastiné River's outlet on 18 March 2009, prior to the field survey with the TRDI ADCP.
Digital bed elevation model -DEM The ADCP internal compass and tilt sensor (roll/pitch) referred water velocities components in terms of East-North-Up (ENU) coordinates. The collected bed elevation data in ENU coordinates, corrected by the magnetic declination bias, were later converted to Transverse Mercator (TM) coordinates with the formulas given by Snyder (1929), with the new World Geodetic as the reference system (WGS 84). For Argentina's Gauss-Krüger (TM) coordinates, the origin is the intersection of the South Pole with the central meridian of each band, and with a northing of zero. This procedure was packed in a module, part of a bundled software written in fortran 95 to merge field data with point and polyline data from complementary sources (river banks elevations, borderlines around inner islands, etc.