dataesr/scientific-paragraphs-categorization huggingface dataset:
Generalization and 3D Visualizations 3D visualization of geographic data is not just a nice way to present the information but can be very useful for professional practitioners, for instance for flood management (Figure  8 ). And even in 3D abstraction and generalization is required to enhance visualization and user experience. Though 3D generalization  (Meng & Forberg, 2007 ) is a real issue, as as can be seen in Figure  8  where some 3D buildings should be simplified, it is not the only issue. The flood management use case requires the visualization of 2D vector layers on top of (or below) the 3D data, and the oblique view requires some generalization of such data, particularly when 2D features are far from the camera. We plan to use CartAGen to generate multiple representation databases that could be used to improve such 3D oblique generalization.
If we look at very successful open source platforms (QGIS) or libraries (PyTorch for deep learning for example), their success is mainly based on the quality of the documentation, with many tutorials to help developers getting started with the platform/library. All things considered, if we want students and researchers in map generalization to use this open platform, the documentation should be our main focus. We also plan to provide completely automated workflows based on CollaGen and/or the ScaleMaster2. 0 to demonstrate how building blocks can work together, because this is where CartAGen goes way beyond the commercial software. Finally, the main missing requirement for an open platform is the lack of interoperability with web services techniques, such as WebGen, and we would like to develop this capability for CartAGen.
Commercial apps frequently have their source code and resources shrunk and obfuscated by tools, such as ProGuard. For this reason AcDetect does not inspect the apps compiled source code for elements created at runtime, as well as for input type and important for accessibility assignments, for the privacy leak in the decompiled source code of the app. Resource XML files are also obfuscated in this process, in a more limited way. According to the ProGuard documentation  8  , if the attribute of an element includes a numeric value, then an obfuscation step will be applied on the attribute. Since android:inputType and importantForAccessibility attributes do not include any numeric value, AcDetect is not affected by the ProGuard obfuscation.
Evaluation Motivation: We aim to evaluate that how effective AcDetect is in finding app vulnerable to leak through the accessibility services. Approach: For this evaluation we re-use the previously evaluated dataset of top 50 Finance and Social apps. We used AcDetect to automatically detect vulnerabilities on all 100 apps and manually discarded vulnerabilities found outside of the apps main login screen, as they could not be accessed during exploration without an app account, and compere these results against the manual evaluation. We consider the results of our manual analysis as ground truth -as all vulnerabilities were concretely exploited. Results: Figure  2  shows the evaluation of AcDetect as a confusion matrix, considering all 100 apps Finance and Social categories on the Google Play Store.
We then extended AndroGuard  [7]  to identify where apps declare the permission and we identified that only 1,247 apps (44. 2 %) declare it the application level. This implies that 55. 8 % of the accessibility apps do not notify the users about their accessibility service use and, while these apps are not necessarily malicious, the lack of notification does not allow the user to observe it. To assess which other information are gathered by apps which use accessibility, we analyzed the permissions requested by the accessibility apps in addition to the accessibility service. Table  3  reports on the top 15 permissions that we observed in our data set. According to official documentation 13 , 6 permissions out of top 15 permissions requested alongside the accessibility service have dangerous protection level, which again emphasizes the potential threats.
For example, the INTERNET permission allows a malicious app to send any sensitive data captured with accessibility service to the Internet. An additional threat caused by the combination of Internet and Accessibility permissions are app updates. Since users were not properly notified on both permissions -as they are not categorized as dangerous -an app which currently does not leak data may be automatically updated to leak this information, without any user notification. In addition to a Google Play Store notification, apps can provide a description about how they use the accessibility service. This service description is displayed to the user, when it enables or disables the service through Android settings menu, as illustrated in Figure  4. This attribute is, however, optional and can be omitted.
The Technique In Android development, all the views need to be bound to a layout, either at compile or at runtime. Additionally, all views which are referenced from source code require an android:id attribute. This identifier is unique for each view in the whole project. The binding between a layout and a UI element can occur in three locations: -XML layout file: The developer defines an editable text field by creating a tag EditText. The declared text field can be retrieved from the source code by querying the id of that view; -Java source file: The developer can define an editable text field by creating an instance of an EditText class and programmatically binding the object to a layout; -Annotation libraries: The developer can annotate their source code and use libraries, such as Butterknife  14  , to bind the view and the layout during runtime.
AcFix is developed as an extension to Spoon  [22]   15  , a tool that parses Java source files and builds an Abstract Syntax Tree (AST) with analysis and transformation API. AcFix uses this AST to analyze the app source code and to detect the sensitive user input fields which can be eavesdropped through the accessibility ser-vice, supporting the detection of both statically and dynamically created objects. AcFix works as follows: 1. It generates the project's source code AST using Spoon; 2. It uses the AST to process all layout files and Java classes in order to find all the password text fields, covering all three forms of bindings.
Evaluation Motivation: We previously identified that many popular apps are vulnerable to eavesdropping through the accessibility service and proposed a tool (AcFix) to assist developers in automatically fixing this issue. We want to evaluate the effectiveness of such automated fixes, as well as the developers acceptance of them. Approach: AcFix needs to be applied on the source code of the projects, thus, we could not apply it on the same dataset used to evaluate AcDetect. We instead targeted open source Android projects. We crawled the F-Droid 16 app repository and located 40 apps vulner-16 https://f-droid. org/en. html able to the accessibility leak. We then applied AcFix on each project and manually evaluated its results. We issued a request to the maintainers of each project to merge the changes automatically made by AcFix into the apps main repositories.
The level of data privacy is not our concern here but the way that we can extend our tools. In the following, we provide a generic approach, which can be used to extend AcDetect, AcFix and AcGuard to cover other user inputs: AcDetect Extension: In current state of AcDetect, the target UI layout is password EditText. Assuming the generic UI layout type is L, AcDetect can be extended to identify apps with accessibility vulnerability through L. First, it extracts the resources of the app. Then, it parses the resource files and finds all elements with type L. Afterwards, it checks the impor-tantForAccessibility and marks the element vulnerable accordingly. AcFix Extension: AcFix can also be extended to fix the vulnerability in the source code of the projects. It inspects both resource and source files and finds all defined variables with type L.
Threats to Validity The presented approach and experimental evaluation raise several limitations and threats to validity. Regarding external validity, we have applied AcFix on 40 open source projects and we received 28 positive responses. We have not received any negative response from others yet, but to increase the confidence in AcFix, a larger dataset of apps should be used. Additionally, for the AcDetect evaluation, we selected 100 popular apps for our analysis, while this may not be representative of the app store as a whole, these apps possess access to critical information and, being developed and maintained by large companies, tend to adhere to upto-date security practices of the industry. In our user study for AcGuard, we gathered data from 50 users. The majority of these are 18-30 years old university students, which is not representative for the overall Android user population.
A study with users from more diverse age and background, as well as users with currently use and those who do not accessibility services, may lead to different results. Users whom the Android accessibility service primarily aims at may have different opinions from those observed in our study. Finally, the password input setting which displays the last typed character of a password is configurable. Changing this setting prevents accessibility services from accessing the password; however, it also impacts the user experience. Regarding internal validity, dynamically created widgets in apps (false negatives) or widgets whose accessibility is defined in the source code (false positives) are not detected by AcDetect since it analyses only the embedded resource files. This problem is specially common on web apps whose content is dynamically generated by a Web view.
Developer Support Acar et al. [1]  investigated the impact of information sources used by developers on the security of their code. They conducted a lab study where 54 Android developers were asked to write privacy and security relevant source code under time and information access constraints. They found that developers who were allowed to use only Stack Overflow produced a significantly less secure code than those accessing books or Android official documentation. Nguyen et al. [20]  developed the FixDroid tool to support developers in writing secure code. FixDroid highlights security and privacy related code problems, provides an explanation to developers, and suggests quick fix options. Regarding users' perception, previous studies  [9]  have demonstrated that users are unaware of security implications in Android applications.
Conclusion and Consequences In this paper, we have demonstrated how to exploit the accessibility service in order to capture sensitive user information. We then have proposed a family of solutions to tackle these privacy leaks from different stakeholder perspectives. From the developer's perspective, we presented AcFix, to automatically detect and fix the issue on source code. AcFix correctly applied changes to all projects and 70 % of its changes were merged back to the main app repository by their developers. From an app store perspective, we developed AcDetect, to identify vulnerabilities when no source code is available. We applied the tool on top apps in Google Play Store with access to highly sensitive information and correctly identified 93 % of the vulnerabilities, with only 5 % false positives.
Background: The interplay between metabolic processes and signalling pathways remains poorly understood. Global, detailed and comprehensive reconstructions of human metabolism and signalling pathways exist in the form of molecular maps, but they have never been integrated together. We aim at filling in this gap by integrating of both signalling and metabolic pathways allowing a visual exploration of multi-level omics data and study of cross-regulatory circuits between these processes in health and in disease. Results: We combined two comprehensive manually curated network maps. Atlas of Cancer Signalling Network (ACSN), containing mechanisms frequently implicated in cancer; and ReconMap 2. 0, a comprehensive reconstruction of human metabolic network. We linked ACSN and ReconMap 2. 0 maps via common players and represented the two maps as interconnected layers using the NaviCell platform for maps exploration (https://navicell.
curie. fr/pages/maps_ ReconMap%202. html). In addition, proteins catalysing metabolic reactions in ReconMap 2. 0 were not previously visually represented on the map canvas. This precluded visualisation of omics data in the context of ReconMap 2. 0. We suggested a solution for displaying protein nodes on the ReconMap 2. 0 map in the vicinity of the corresponding reaction or process nodes. This permits multi-omics data visualisation in the context of both map layers. Exploration and shuttling between the two map layers is possible using Google Maps-like features of NaviCell. The integrated networks ACSN-ReconMap 2. 0 are accessible online and allows data visualisation through various modes such as markers, heat maps, bar-plots, glyphs and map staining. The integrated networks were applied for comparison of immunoreactive and proliferative ovarian cancer subtypes using transcriptomic, copy number and mutation multiomics data.
A certain number of metabolic and signalling processes specifically deregulated in each of the ovarian cancer sub-types were identified. Conclusions: As knowledge evolves and new omics data becomes more heterogeneous, gathering together existing domains of biology under common platforms is essential. We believe that an integrated ACSN-ReconMap 2. 0 networks will help in understanding various disease mechanisms and discovery of new interactions at the intersection of cell signalling and metabolism. In addition, the successful integration of metabolic and signalling networks allows broader systems biology approach application for data interpretation and retrieval of intervention points to tackle simultaneously the key players coordinating signalling and metabolism in human diseases.
Users can map and visualise different types of "omics" data on the Navi-Cell maps  [4, 5]. The manually curated genome-scale reconstruction Recon2. 04 is a representation of the human metabolism. It accounts for 1733 enzyme-encoding genes associated to 7440 reactions which are distributed in 100 subsystems, referring to metabolic pathways. Furthermore, Recon2. 04 accounts with 2626 unique metabolites distributed over eight cellular compartments  [2]. Subsequently, to visualise the resource, a comprehensive metabolic map termed ReconMap 2. 0 was generated from the Recon2. 04 resource  [1]. In the ReconMap 2. 0 reactions (hyper-edges) were manually laid out using the biochemical network editor CellDesigner  [6]. ReconMap 2. 0 is currently distributed in a Systems Biology Graphical Notation (SBGN) compliant format and its content is also accessible via a web interface (https://vmh.
uni. lu/#reconmap). All major human metabolic pathways are considered and represented as a seamless network where different pathways are interconnected via common molecules. There are 96 subsystems on the ReconMap 2. 0, each of them representing a specific metabolic pathway (See Table  1  for terms definition). By integrating these resources together, it will be possible to elucidate the crosstalk between metabolic and signalling networks. In addition, the integrated networks, provided in a common graphical language and available in standard exchange formats, makes them accessible for multiple systems biology tools. It opens an opportunity to model coordination between signalling pathways and metabolism using various systems biology approaches. Among others, there are several methods for multi-level omics data analysis in the context of the biological network maps that allow defining "hot" areas in molecular mechanisms and point to key regulators in physiological or in pathological situations  [7] [8] [9]  and beyond.
The integrated networks can be provided as interconnected layers supported by Navi-Cell platform for navigation and data integration. The suggested methodology is applied for ACSN and ReconMap 2. 0 resources integration. However, this is a generic method applicable for integration of different types of networks prepared in CellDesigner SBML format (Fig. 1 ). In the following sections of the paper, we explain the challenges and describe how each step mentioned in the workflow was addressed. The workflow in the Section 2 includes the following major steps (see Table  1  for terms definition): -Identification of common proteins between ACSN and ReconMap 2. 0 networks -Finding metabolic and molecular processes crosstalk between ACSN and ReconMap 2. 0 -Displaying protein nodes on the ReconMap 2.
Materials and methods Step-by-step procedure for network integration Identification of common proteins between ACSN and ReconMap 2. 0 networks ACSN and ReconMap 2. 0 maps contain information on proteins implicated in the regulation of reactions. First, the systematic use of the common identifiers as standard protein names (HUGO) for all proteins in both resources was verified and inconsistencies corrected. Thus, the proteins found in both resources ACSN and Recon-Map 2. 0, were compared, quantified and visualised. We detected 252 proteins in common between the two networks (Additional file 1). Displaying protein nodes on the ReconMap 2. 0 map ACSN and ReconMap 2. 0 are both used as visual objects for exploration of processes as well as for data integration and visualisation in the context of the maps.
After identification of the cross-talks between the two resources, it is important to ensure that all components of the maps are represented in a visual manner suitable for meaningful visualisation of omics data. Due to the different nature of the networks, protein nodes are explicitly visualised on the ACSN map. However, in the ReconMap 2. 0 the Standard Names (Identifiers) of proteins regulating metabolic reactions are included into the reaction annotations, but not represented visually on the map canvas. This precludes visualisation of omics data in the context of ReconMap 2. 0 map. We developed a procedure for displaying the protein nodes on the ReconMap 2. 0 map in the vicinity of the corresponding reaction edges, that now permits a multi-omics data visualisation in the context of both ACSN and ReconMap 2.
-Conversion of BiNoM Reaction Format into a CellDesigner map Using a custom python script, information stored in the BiNoM Reaction Format is transformed into a XML file following the SBML format. This file will contain each protein names, IDs, alias IDs, coordinates and type. As for now, only the manipulation of simple proteins is available. -Merging of the ReconMap 2. 0 and Proteins maps using BiNoM merging function. Once the file containing proteins to add to the metabolic map is obtained, as they both are in the same SBML format, it is possible to merge them by using a function of the BiNoM plugin. This function allows transforming two or more separated maps into one unique map. This final merged map will be transformed into the NaviCell environment using the NaviCell Factory package (https://github.
Thanks to this method, 1. 550 proteins were allocated in the ReconMap 2. 0 canvas associated to more than 7. 500 aliases. The algorithm for assigning proteins' coordinates is robust and its computation time is also scalable as the generation of the 7. 500 allocation points is resolved in a matter of seconds. ACSN and ReconMap 2. 0 merging Once the protein positions file has been generated, it was converted to a Cell-Designer  [10, 11]  XML format through a custom python script (https://github. com/sysbio-curie/CellDesigner_net works_map_integration_procedure). This script allows to obtain a file in XML format following the standard of Cell-Designer's SBML. This 'map' contains only proteins in the positions they should belong on the final metabolic map. This file was then merged with the ReconMap 2.
Map entity annotation with NaviCell format The annotation panel followed the NaviCell annotation format of each entity and reaction of the maps includes sections 'Identifiers' , 'Maps_Modules' , 'References' and 'Confidence' as detailed in  [3]. 'Identifiers' section provides standard identifiers and links to the corresponding entity descriptions in HGNC, UniProt, Entrez, SBO, GeneCards and cross-references in REACTOME, KEGG, Wiki Pathways and other databases. 'Maps_Modules' section includes tags of modules in ACSN and metabolic pathways in RecoMap 2, in which the entity is implicated. 'References' section contains links to related publications. Each entity annotation is represented as a post with extended information on the entity.
Generation of NaviCell map with NaviCell factory NaviCell Factory (https://github. com/sysbio-curie/NaviCell) is a package allowing to convert a CellDesigner map annotated in the NaviCell format into NaviCell Google Maps-based environment. This result in a set of HTML pages with integrated JavaScript code that can be launched in a web browser for online use. HUGO identifiers in the annotation form allow using NaviCell tool for visualisation of omics data  [5]. The detailed guidelines for the usage of NaviCell factory, embedded in the BiNoM Cytoscape plugin, is Fig. 2  Illustration of the three steps for automated proteins addition in the vicinity of a reaction. The first step is to generate a Voronoi cell for each entity in the map. The second step is to generate several randomly assigned points in the Voronoi cell of reactions catalysed by proteins.
Results Finding metabolic and molecular processes crosstalk between ACSN and ReconMap 2. 0 ACSN and ReconMap 2. 0 networks have a particular hierarchical structure. ACSN is divided into functional modules, whereas ReconMap 2. 0 is divided into subsystems. Each of these structures are a subset of processes from the global network, implicated in regulation and execution of a specific molecular or metabolic pathway respectively (See Table  1  for terms definition). To address the question which metabolic processes are connected to which signalling mechanisms, the enrichment analysis of ACSN modules and Recon 2. 0 subsystems was performed using the 252 common proteins (Additional file 1). The composition of ACSN modules and ReconMap 2. 0 subsystems are provided as gene sets in Additional files 3 and 4 in Gene Matrix Transposed (GMT) file format and the enrichment was calculated using a hypergeometric test on the union of proteins of both maps (Additional file 5).
The analysis demonstrated that proteins shared between the two maps are implicated in 22 modules of ACSN and in 51 subsystems of ReconMap 2. 0 (Fig. 3  and Additional file 6). Majority of proteins on both resources are participating in catalysis of biochemical or metabolic reactions. The information for the protein-reaction association is encoded in the network structure and in the annotations on the CellDesigner XML files. Information for reactions in each ACSN module and ReconMap 2. 0 subsystem was retrieved and quantified. The number of reactions in ReconMap 2. 0 subsystems regulated by proteins from ACSN modules is shown in Additional file 7. Since ACSN is the resource focused on processes implicated in cancer; as expected, the ACSN modules containing mechanisms related to Mitochondria metabolism and Apoptosis have many shared proteins with Recon-Map 2.