dataesr/scientific-paragraphs-categorization huggingface dataset:
The circadian core genes are shown by black squares. b The P20393 protein (REV-ErbA-alpha gene) (red square), suggested to be involved in the disruption of clock genes  [27] , can be seen 3 steps away from the O00327(ARNTL/BMAL1) and Q99743(NPAS2) core clock genes (black squares). Node colour: protein, blue. Edges: PPI association, red; sequence similarity relationship, grey view, a representation that is now near-ubiquitously for modelling complex biological data. This study shows how a combination of a powerful query language (to narrow down the search space) with network visualisation can help data exploration and hypothesis generation. The use of graph database approaches has some similarities with previous systems for logic-based modelling of integrated datasets  [29, 30]. As we have illustrated in this work, graph databases offer many features that make them a particularly attractive option for a research-based setting, in particular in cases where it might be necessary to dynamically develop and interactively mine heterogeneous and not uniformly inter-related data.
However, we would like to stress that in our opinion graph databases are best thought of as a complement to relational database technologies. There will clearly be cases where a relational database solution will be preferable, especially when data are dense and naturally fit the tabular representation where relational databases would offer much better processing performance. Another important consideration is the place of Neo4j in a wider family of NoSQL and especially graph databases. The concept of graph databases is still relatively novel and therefore currently there are multiple alternative systems under active development. However, one standard -Resource Description Framework (RDF) and its enabling technologies (triple stores and SPARQL query language) have gained particular prominence due to their importance for Semantic Web and Internet-powered federated data solutions.
For this reason we would like to further elaborate on the differences between these two standards and specifically the roles they could potentially play in management of large biomedical datasets. Neo4j database belongs to the family of "Property graph" databases, which in contrast to RDF have conceptually distinct property elements that can be attached to both nodes and edges. In some respects, this syntax may be more familiar to users of objectoriented languages, as in contrast to RDF, there is neither a global uniqueness constraint nor specifically required format for node identifiers. In combination, these features make graph query syntax more compact and easier to read. Given that the Neo4j database is inherently a "closed world" solution, it is possible to collect the entirety of meta-data about the types and number of different entities and relationships between them, which can then inform further exploration.
As SPARQL and RDF are primarily designed to operate in an "open world" setting of the Semantic Web, creating such summaries may not always be possible or can be very computationally intensive. However, we would like to acknowledge that the RDF formalism does have its undisputed advantages in facilitating integration and exchange of distributed data and issues like lack of properties on edges can be addressed by leveraging more advanced features like reification or named graphs. In our view, the matter of preferences between the properties databases like Neo4j or RDF triple stores comes down to whether a particular application case can actually benefit from the extra features available via Semantic Web technologies. As adopting such technologies will inevitably come with considerable costs in terms of technical overhead and increased complexity, property databases may be preferable when speedy and flexible development of a single non-federated resource is the ultimate requirement.
The lack of schema in Neo4j may also be somewhat of a double-edge sword: although it does offer much flexibility, it also removes the interoperability standard from the data, which may make sharing and management of large distributed projects datasets more challenging. One solution to this would be to re-introduce some consistent semantics by binding critical attribute names and/or values of nodes and edges to a consensus controlled vocabulary. In a biomedical domain, this controlled vocabulary will likely come in the form of a suitable ontology. The ontologies could then provide a de-facto data modelling standard and many key concepts in the biomedical domain have already been modelled by projects like SNOMED  [31] , MeSH  [32] , GO  [33]  and OBI  [34] , with several hundred of other more specialized ontologies available from the OBO foundry  [35]  and NCBO Bioportal  [36]  repositories.
Although at present the availability of advanced ontology-based features, like reasoning and data validation, varies in different graph databases, some notable solutions do offer examples of very close integration -e. g. the already-mentioned graph databases based on the resource description framework (RDF)  [37]. We have explored here the utility of a graph database in providing a powerful yet flexible solution for disease network representations and for exploratory data mining and analysis to support hypothesis generation on disease mechanisms. Our study suggests that the Neo4j system offers a level of performance and an appropriate query and visualisation interface to effectively mine and manipulate these data. In particular, we have found the Cypher graph query language to be of great utility, because, as illustrated by our sample queries, it enabled us to generate a representative selection of common biologically-motivated queries with minimal efforts.
Acknowledgements Authors would like to thank the team of the  CNRS/IN2P3 Computing Centre ,  Mr. B. Guillon ,  Mr. J. Bussery ,  Dr. G. Marchetti  and  Dr. G. Rahal  for their support on deploying the Neo4j graph database presented here to a server and making it accessible. Authors would like also to thank  Mr. R. Henkel  ( University of Rostock, Germany ) for his valuable comments on the Neo4j aspects and  Dr. C. Marshall  ( BioSciConsulting, Belgium ) for his valuable advice on the licenses of the interrogated databases. Authors are also grateful to reviewers for their valuable comments on the manuscript. Authors would like to acknowledge for access to the Neo4j framework and for data resources within the databases interrogated: DisGeNET 2. 1,  DrugBank ,  Human Protein Atlas, IntAct, Reactome, UniProt.
Funding The research leading to these results has received support from the  Innovative Medicines Initiative Joint Undertaking  under grant agreement no. IMI 115010 , ( U-BIOPRED ) and  IMI   115446  (eTRIKS) resources of which are composed of financial contribution from the  European Union 's  Seventh Framework Programme  ( FP7/2007-2013 ) and EFPIA companies. AL and CJR acknowledge support from the  BBSRC  through their strategic funding of  Rothamsted Research.
Availability of data and materials The framework, described above, was developed predominantly in (eclipse), using the Neo4j 2. 3. 1 functionality. The queries described here can be explored at the following url: https://diseaseknowledgebase. etriks. org/protein/ browser/. The framework is freely available for non-commercial purposes and the java code used to parse the data and populate the graph database is available at https://github. com/ibalaur/ProteinFramework. git. For further details please contact ibalaur@eisbm. org.
Working in partnership with a university research laboratory, Spécinov developed 11 years ago this tour management application named Biotour, used by SARIA Industries for his rendering activity in 20 sites in France. This activity involves the collection, transport and treatment of animal waste. The software is designed to calculate the best collection routes to optimize the human and material resources. This application was developed in VB and C# on. NET platform and used Microsoft MapPoint  (Microsoft, 1999)  for his cartographic rendering. But since MapPoint announce the end of his support, the sustainability of Biotour is threatened. Moreover, MapPoint was not built to manage multiple data layers and as important volumes of business data. So there were stability issues which stop the application or slowing it.
In fact, MapPoint was the right choice 11 years ago due to the offline solution which is a key point for this application. So, today, the goal is to build a replacement solution which is offline and with a limited cost. The chosen solution will have to implement the same functionality as MapPoint, to display data with the same rendering and to be more stable. To build the alternative solution we have to find the two main features of a mapping solution: a GIS platform and a data provider. In the MapPoint solution, both are integrated. The present work is divided into 8 sections. We present the data provider OpenStreetMap in section 2. Section 3 introduces the GIS platform DotSpatial. The application architecture is given in section 4. Section 5 details the management of data layers in the solution both concerning the cartographic layers and the business layers.
In section 6 we describe the management of interactions. Afterwards, section 7 shows the work done on integration and optimization. We conclude with the results and the feedback of this new solution in section 8. 2 OpenStreetMap: THE DATA PROVIDER  OpenStreetMap (OpenStreetMap, 2004 ) is a crowdsourcing project to create a free map of the world. This project was launched 11 years ago and provide now a high-quality world map coverage  (Girres, 2010)   (Haklay, 2010). OpenStreetMap data are under Open Database License (ODbL). This license agreement intended to allow users to freely share, modify, and use this dataset while maintaining this same freedom for others, provided that the original source and author(s) are credited. The main advantage of OpenStreetMap data is that they are free and can be downloaded for an offline use.
Indeed, there are no many data providers that allow to download data for an offline use. In our study case we need France cartographic data, there are only two data providers for an offline use, OpenStreetMap and IGN (French National Geographical Institute). However, the reference pricing of IGN for the France data is €160,000, so the cost constraint is important. Therefore, OpenStreetMap was chosen as the data provider of the application. For our use with the GIS platform which has been chosen, OpenStreetMap data will not be used in their default format but in the shapefile format. It is possible to convert OpenStreetMap data default format, osm, in a format compatible with GIS platform with some tools. But, for simplicity reasons, we get OpenStreetMap data directly in shapefile format from Geofabrik  (Geofabrik, 2007)  server.
DotSpatial: THE GIS PLATFORM DotSpatial is an open source GIS library written for. NET 4 which has been developed by members from the Geospatial Software Lab at Idaho State University, Idaho Falls, Idaho, USA (Idaho State University, 2015), as well as an international open source community  (Ames, 2007). It allows developers to add spatial data, analysis and mapping functionality into their applications, it provides a map control for. NET and several GIS capabilities. The DotSpatial architecture follows two paradigms. The first is a separation of the user interface and business logic. The second is to use a larger number of modules to increase code reusability, and allow access to certain parts of the library without requiring a whole. So, DotSpatial is divided into 17 DLL and just some of them are used to build a GIS platform needed by the business application  (Cao, 2012).
The reasons for choosing this library has been its ability to manage large volumes of data, its flexibility and mainly the size of the community mobilized around this project. This open source alternative for GIS allows the development of specific software  (Sameen, 2014) ;  (Wang, 2014). The Biotour application being developed in Visual Basic. NET, the choice is made to develop a C# interface library that will access the DotSpatial library. It creates an abstraction layer between the business application and the library that allows to manage all function calls in the interface library and to work at a higher level. For example, when loading the cartographic background, DotSpatial called a function from the interface library which then uses the DotSpatial library to perform this action.
APPLICATION ARCHITECTURE As can be seen from the architecture presented above, the DotSpatial library uses several elements. First, to display the cartographic background, a. dspx file (XML) is used. This file contains the description of layers to import and the symbology to apply to them. This file is editable through a symbology editor included with the library. The cartographic data from OpenStreetMap are stored in shapefiles, they each contain a data layer (roads, natural features, places. ) for a defined area. Once the data from shapefiles were loaded, the symbology defined in the dspx file is applied and the basemap is displayed in the map control. Then, business data like the Biotour network and the customer location points are displayed on additional data layers created from the data stored in the SQL Server database.
MANAGEMENT OF DATA LAYERS DotSpatial allows, like any GIS solution, to manage the data in a system of map layers. Among the layers used in the map controls, some are part of the basemap and are static layers. Other layers are business layers on which the user will be able to act (selection, drawing, additional data display, etc. ). The map data layers are loaded from shapefiles while business data layers are loaded from the existing SQL Server database of Biotour. Next, when we look at the representation of data on a map, the notion of map projection comes in. In all online mapping services, such as Google Maps or Bing Maps, the projection used is the Web Mercator projection, this projection is also used by MapPoint. Because of the constraint to remain as close as possible of MapPoint rendering, this projection is used in the new solution.
However, coordinates of basemap data are not projected in Web Mercator but are in WGS84 format (a standard for use in cartography, geodesy, and navigation including by GPS), so a projection of this data is required. These projections are made when the dspx file containing the legend is loaded. About coordinates of business data present in the database, they are also in WGS84 format. So, conversion functions for switching from one projection to another have been implemented to project coordinates from WGS84 to Web Mercator and vice versa.
Business Layers Data of these layers are loaded from the existing database of the application. No changes of the data structure are required to build a map layer from an existing table. A map object is built from a business object by assigning his coordinates to the map object and all others properties to the metadata of the map object. Then all built map objects are assigned to a layer that can be displayed with the appropriate symbology. Inversely, to get a business object from a selected map object, coordinates and all metadata of the selected object are used to build a business object that can be used in a business process. In the same way as for data of cartographic layers, metadata attached is used to manage the symbology assigned to each entity. For example, the items loaded in the pick-up points data layer will contain in metadata the period from which the pickup point is waiting for, to have a differentiated display of points according to this criterion.
CONCLUSIONS To conclude, an innovative alternative mapping solution which is offline and open source was built. It has much more flexibility than MapPoint and others existing online mapping solutions. In each screen of Biotour, the implemented solution allows the user to see only layers that he needs to see. Further, unlike MapPoint, data of the basemap can be daily updated from OpenStreetMap to always having quality data ensuring two features completeness and correctness. Finally, the new solution is much more stable than MapPoint so the user experience is improved. A key point is that the project takes place in the case of a real business application, with customer constraints. The flexibility of the new solution allowed to implement customer needs that can't be implemented before with MapPoint, so the interest of the map in the application is reinforcing.
Big data stream analytics platforms not only need to support performance-dictated elasticity benefiting for instance from Cloud environments. They should also support analytics that can evolve dynamically from the application viewpoint, given data nature can change so the necessary treatments on them. The benefit is that this can avoid to undeploy the current analytics, modify it off-line, redeploy the new version, and resume the analysis, missing data that arrived in the meantime. We also believe that such evolution should better be driven by autonomic behaviors whenever possible. We argue that a software component based technology, as the one we have developed so far, GCM/ProActive, can be a good fit to these needs. Using it, we present our solution, still under development, named GCMstreaming, which to our knowledge seems to be quite original.
We argue in this paper that a fully flexible technology, encompassing both the programming and supporting runtime levels, is needed; flexible in terms of 1) the functional viewpoint, i. e. what the analytics aims to deliver as "business" outcome, and 2) the non-functional (quality of service, like e. g. response time) viewpoint as a secondary and more classical objective. In this paper we expose our arguments why an approach originating from software component based technologies can be a real asset towards this goal. Started years ago, in the context of HPC on cluster then on grid computing, now on cloud platforms, we developed a programming library named Grid Component Model (GCM for short) implemented by leveraging the ProActive parallel and distributed open source technology  [1]. GCM permits to define software components, well-delimited hierarchical and autonomous software entities that feature parallelism, distribution, and also a clear support for autonomic computing thanks to a well-defined separation of the functional and the non-functional aspects a programmer has to handle.
II. REQUIREMENTS ANALYSIS AND STATE OF THE ART Stream processing can rely on various approaches, but the one which seems the most appropriate is based upon Stream Processing Engines as opposed to database management systems and rule engines  [2]. We do not want to rely on an approach that translates an abstract expression of the analytics into an internal representation that ends up being a very optimized data flow fine-grained parallel program (as in Stratosphere, Spark). Instead, we wish to allow the programmer to express the stream processing program accompanied with the adaption rules to permit this program to dynamically evolve. To ease that dual level of expressiveness, we believe it is preferable to adopt a runtime representation of the computation that is very close to the abstract view of the stream processing application.
III. BACKGROUND ON GCM A. Functional layer GCM (Grid Component Model)  [1]  is a hierarchical component-oriented model for building parallel and distributed software. It is a framework that uses autonomous components  [5],  [6]  [11],  [5]  [6],  [7] ,  [8] ,  [9]  [3],  [12] ,  [10]  as the building block for building applications, each of which communicates and sends messages (in the form of remote method or service calls) to each other to accomplish the execution of the defined tasks. By autonomous, we mean that the GCM programming model enforces to define loosely coupled components that do not share memory nor control, and thus can be considered as independent entities. The core of a component is made of a ProActive multi-active object. Each call may produce a reply, in this case the reply is transparently awaited and handled by the caller through a mechanism known as a future.
B. Data stream operator types The predefined components to be customized, subsequently instantiated and bound at runtime, are as follows: • InTap to read data from an external source transforming it into tuples that can be pushed to the next component through its client interface. Examples of this kind of operation could be a file or console reader, database queries, Tweet fetcher or streamers for other APIs. • Operator to represent an operation. It acts as an intermediate process in a data flow graph, taking tuples from its server interface processing tuples and transforming them and forwarding the result to the next component. Typical processing steps include text normalizing, filtering (whether the tuple holds a certain property or not), reducing (as a group or sort operation), buffering, under some typical window behavior (tumbling, sliding windows).
• OutTap to write tuples in an external system or file, like a file writer, writing to console or a database, exposing only a server interface from tuples are received. • Operator(s) with a map-reduce flavor. This is a composite component that contains by default a master and one slave. The master receives the tuples, distribute them in a balanced way to workers that apply the map function. In the first flavor the reduce operation simply aggregates map results, in this case, map workers are directly bound to an internal gathercast interface acting as server so to push results to the next operator forward. In the second (refer to Figure  3 ), map results are sent back as (future) return values to the master that applies the reduction to obtain new tuples pushed forward in the graph. A So, a last useful operator is Aggregator.
But the primitive component has just one such interface to implement. We put in the membrane an interceptor as a non functional Router component: it intercepts the received messages (i. e. calls of the receive method) before they are served by the primitive component (by the content) as they were all received through a unique server interface. To this aim, we redirect all of the server interfaces to this unique internal interface of type InStream. The interceptor adds an information of the source origin of each message (like source id), so that messages be then easily classified by the functional implementation of the receive method (e. g. aggregate one received tuples list received from source 1 with one received from source 2, to form a single aggregated new one, and again). A stream application (as sketched by figure  5 ), as any other GCM application, can be designed in a declarative way thanks to the use of the specific XML-based GCM Architecture Description Language.
For instance, a more optimized Text Normalizer component could replace the current one. All these sorts of reconfiguration actions are expressed using the GCM API, or GCM-script higher level operations, and orchestrated from either the outside or the inside (autonomic part) of components. More drastic modification of the analytics, i. e. of its architecture itself, can be achieved as easily. It is just a matter of adding the necessary new components, and bind them accordingly within the composite graph. The necessary components can be mapped to run on existing GCM/ProActive nodes (JVMs), or can also be started on newly acquired hosts of the computing platform. Acquisition of additional hosts can be anticipated, and is delegated to the ProActive underlying middleware which is in charge of launching ProActive nodes using for instance the ProActive multi-IaaS deployment technology.