dataesr/scientific-paragraphs-categorization huggingface dataset:
The key approach is to query the vast data resources from their native data models and specialised storage engines. In this paper, we propose a Web-based query federation mechanism -called PolyWeb -that unifies query answering over multiple native data models (CSV, RDB, and RDF). We demonstrate PolyWeb on a cancer genomics use-case where it is often the case that a description of biological and chemical entities (e. g. , gene, disease, drug, pathways) span across multiple data models. In order to assess the benefits and limitations of evaluating queries over native data models, we evaluate PolyWeb with state-of-the-art query federation engine in terms of result completeness, source selection, and overall query execution time.
I. INTRODUCTION The database experts have predicted the demise of "One Size Fits All" approach used in the data retrieval and management solutions  [1]. This prediction is now evident, as in the last couple of years several data models (e. g. , text, CSV, Graph, JSON, RDB, RDF, XML) and storage engines are proliferating with overlapping requirements, use-cases, and user-bases. This is particularly true in complex domains like healthcare and life sciences (HCLS) where the organisations are facing a major shift in the data retrieval requirements; a simultaneous use of different data storage engines, data models, and supporting querying mechanism is needed to retrieve data from different interacting facilities (clinical measurement, medical history, laboratory test, demographics, etc. )  [2].
On the same challenge of combining and querying data from several repositories, the central idea of Linked Data is to publish and link wide variety of independent Web data silos in a manner that is queryable as one connected set of datasets supporting advanced Web uses, organisations, and scientific discoveries. The Linked Open Data (LOD) Cloud as well as enterprise applications of Linked Data have shown success in connecting and querying resources across disparate data platforms  [3]. Additionally, there is a wider availability of open-source and commercial tools that allow curating, publishing, aggregating, storing, and querying the Linked Data. The standard (typical) Linked Data approach to query independent data silos is to convert all the underlying native data models into the RDF data model and devise querying mechanism through which these independent data silos can be queried in unison.
The early demonstrators of PolyStore have shown promising outcomes in federating queries across disparate data models used in the Multiparameter Intelligent Monitoring in Intensive Care II Databases (MIMIC II)  [6]. In this paper, we present a semantic approach -called PolyWeb -to federate query over the Web polystores containing cancer and biomedical datasets. We devise a query federation approach for Web polystores that focuses on source selection and join over disparate native data models. It is an open research problem to perform join across data sources 2 using different data models. Further, it is important to understand the gain and loss of querying data sources in their native format compared to the conventional approach of querying curated data sources -from several heterogeneous sources -using a common data model; we compare PolyWeb against the state-of-theart SPARQL query federation engines.
II. MOTIVATING SCENARIO -CANCER GENOMICS The Next Generation Sequencing (NGS) technologies are producing a massive amount of sequencing datasets. As said, there will be a top-up of approximately 40 petabytes of genomics information every year from a wide variety of data sources (hosting different databases, data formats, etc. ) published by human genome research centres worldwide. Often, these datasets are published from isolated and different sequencing facilities. Consequently, the process of sharing and aggregating multi-site sequencing datasets are thwarted by issues such as the need to discover relevant data from different sources, built scalable repositories, the automation of data linkage, the volume of data and efficient querying mechanism. PolyWeb is motivated by the needs of the BIOOPENER project  3  which is aiming to link cancer and biomedical datasets providing interlinking and querying mechanisms to understand cancer progression from normal to diseased tissue with pathway components, which in turn helped to map mutations, associated phenotypes, and diseased pathways  [7].
In cancer genomics, discoveries of biological and chemical entities (gene, pathway, drug, diseases, etc. ) are available in several overlapping data sources containing complex genomic features, studies, and associations of such features. In order to understand the tumorigenesis, it is often the case that several genetic features, diseases, medical history, etc. are studied together. Considering the exponential growth and variety of genomics and biomedical datasets, it is impractical to assume that all these isolated and disparate datasets will be available in a single data model. In order to tap the vast knowledge locked in these disparate datasets, it's now important to exploit them in native formats. The example SPARQL query shown in Figure  1  retrieves association of a gene (MYH7) with a primary site (where tumour progression starts), disease, copy number variation (CNV), CNV location (start, end), CNV segment mean, and reported samples of patients.
The CNV information gives insight into the structural variation of a gene which helps analyse the progression of cancer tumour, ultimately impacting on the prognosis and treatment of disease. The Figure  2  shows an unoptimised query plan which includes type of databases/models (e. g. , CSV, RDB, RDF) that can satisfy individual triples from three data sources. In our prior work we have developed a SPARQL federation engine -called SAFE  [8]  -that federates queries over genomics and clinical trial repositories represented in RDF model. Similarly, in our previous work, we have evaluated a wide variety of proposals (FedX, LHD, SPLENDID, FedSearch, GRANATUM, Avalanche, DAW, ANAPSID, ADERIS, DARQ, LDQPS, SI-HJoin, WoDQA and Atlas) on how to execute SPARQL queries in federated settings  [9]  @cosmic -rdf @tcga-rdb @cnvd -csv @cosmic -rdf @tcga -rdb @cnvd -csv @cosmic -rdf @tcga -rdb @cnvd -csv @cosmic -rdf @tcga -rdb @cnvd-csv @cosmic -rdf @tcga -rdb @cnvd -csv @cosmic -rdf @cnvd -csv @cnvd -csv @cosmic -rdf @tcga -rdb 2.
III. RELATED WORK The relational database and semantic Web research initiatives have offered several federation systems that can unify query answering across disparate databases. We now discuss related literature in these two broad areas. Relational Databases: The relational database approaches to query federation are mainly focused around the closedworld enterprise settings which require predefined number of data sources, schema, and datasets to process queries across different business units within or between organizations. Some early  [10]  and more recent query federation approaches  [11]  target the challenge of distributed query processing and transactions, performance, and replica management. Several early data mediators  [12]  and middle ware systems  [13]  -primarily based on the Global as View (GAV) and Local as View (LAV) approaches  [14]  -developed in the last three decades had the similar motivation.
However, the GAV and/or LAV based approaches function on costly assumptions, i. e. , availability of global schema, availability of complete data sources, and their mappings; which are reasonable in a closed-world enterprise setting, but impractical to assume in a Web like open scenario. Recently the database community is exploring a new perspective -called Polystore  [5]  -to unify queries over multiple data models. Similarly, other domains such as the streaming and sensors data processing  [15] , enterprise analytics  [16] , social media  [17] ), etc. have taken initiatives to query over multiple data stores which natively support different data models. Semantic Technologies: Many query federation engines have been proposed for a Web like scenario using SPARQL  [9]. Such engines accept an input query, decompose it into sub-queries, decide relevance of individual data sources for sub-queries, forward sub-queries to individual endpoints accordingly and merge the final results for the query.
Initiatives such as the Ontology-Based Data Access (OBDA) exploits ontologies specifically for accessing relational databases (RDB)  [18] ,  [19] ; such initiatives are complementary to our PolyWeb proposal of querying different data models. The challenges of federating a given query over multiple data models are different in a Web like scenario. Often the datasets are selected from a large pool of prospective data sources and there is no control -unlike enterprises where data resources are controlled -on the availability of complete schemas and datasets. It's important to note that, the database research is investigating the normal federation approach (using single RDB data model) vs. Polystore based federation implemented using database technologies  [5] ,  [20]. Similarly, in this paper we are investigating normal federation (using single RDF data model) vs.
In our work, a mapping definition provides an RDF view of non-RDF data such that non-RDF data can be queried with SPARQL. PolyWeb has a very simple data-free  4  indexing mechanism, the index stores minimal information about given datasets. In case of RDF datasets, it stores only predicate IRIs (Internationalized Resource Identifier) obtained from individual dataset; otherwise, it exploits the mapping definitions to associate predicate IRIs to non-RDF datasets. PolyWeb uses an index of the predicates and an index of the mapping definitions for all datasets. Thanks to the mapping definitions, it is possible to identify non-RDF data sources that can return results from a SPARQL query. The input SPARQL query is broken down into BGPs (Basic Graph Pattern 5 ). Each BGP is decomposed into triple patterns from which we get either a bound predicate (i.
). b) Query Optimisation, Planning and Execution: Poly-Web creates a federated query plan against the relevant data sources and executes that plan to get results from multiple data models and merges them into a single result set. In PolyWeb, we devised a query optimisation method -called predicate-based join group (PJG) -that reduces the cost of federated query processing by minimising the number of joins -a key factor that influences the evaluation of a given querybetween intermediate results and hence the network data flow. PJG creates a set of unique triple patterns against a group of datasets and data sources. PJG helps in reducing the number of remote requests and the amount of data transferred on the network, which ultimately impact on query performances  [9]. In case of our motivational scenario with total 9 unoptimised joins (Figure  2 ), EEG creates a set of unique triple patterns against a group of datasets which generates six (6) extended exclusive groups (see Figure  4 ).
Since a two given extended exclusive groups does not contain any common triple pattern, a simple implementation of nested loop bind is achieved by first materializing the left argument and binding the results of left argument with the right argument based on a set of identified join variables. As PolyWeb federates over different data models, the query execution component uses different transformations between queries and result sets. In our implementation, we have the following translation (i) SPARQL to SQL : If an argument of the query plan needs to execute over RDB dataset, then the argument (sub-query) is translated in the SQL format. The transformation between SQL and SPARQL queries is a non-trivial task, due to the difference in semantics between them. The SQL result set obtained from RDB sources are transformed back to the standard SPARQL result format; (ii) SPARQL to SQL (CSV sources): In case of a CSV data source the SPARQL query is translated to the SQL format used by Apache Drill 6.
V. EVALUATION This section highlights the results of our evaluation comparing PolyWeb with state-of-the-art SPARQL query federation engine for a variety of queries and datasets based on a series of metrics. Note that the experimental material discussed in the following section and an implementation of PolyWeb are available online  7. We have selected three datasets for experimental evaluation (i) COSMIC-CNV; (ii) TCGA-OV-CNV; and (iii) CNVD-CNV, provided by COSMIC 8  , TCGA  9 and CNVD 10  data providers. All these datasets are part of the studies conducted within the BIOOPENER project. These datasets are available in different data models, e. g. , COSMIC-CNV is available in the RDF format, TCGA-OV-CNV is available in RDB format (relational model) and CNVD-CNV is represented using the CSV format.
In order to compare Poly-Web with the single data model query federation approaches (such as Fedx), these three datasets are converted into the RDF format. Table  I  gives an overview of the experimental datasets, for instance, COSMIC-CNV consists of 37 million triples (6. 54 GB size in RDF format); with equivalent 27 million database records (3. 2 GB size in raw format). The Type column represents the raw data format with number of records (rows) specified in column 9. The last column (RDFisation Time) represents the cost associated with the conversion of raw data to RDF. One of the main aims of PolyWeb is to avoid and/or reduce this data conversion cost. For each query type we measured (i) the average source selection time; and (ii) the average query execution time to compare the performance of PolyWeb and FedX.
In terms of future work, there are a number of possible routes to explore with respect to improving the performance of PolyWeb: (i) we plan to devise a mechanism to probe non-RDF datasets at run-time in the presence of unbound predicates; and (ii) the transformation between query results (non-RDF and RDF datasets) is a non-trivial task and we plan to optimize such transformations in a more declarative fashion. We plan to include a dynamic cost model that will further prune the predicate-based join groups.
[24]dataset is loaded into Apache Drill and relational dataset into MySQL database. All experiments are carried out on a local network, so that network cost remains negligible. The machines used for experiments have a 2. 60 GHz Core i7 processor, 8 GB of RAM and 500 GB hard disk running a 64-bit Windows 7 OS. A total of 5 queries are designed to evaluate and compare the query federation performance of PolyWeb against the FedX engine. The queries are of varying complexity and have varying type of characteristics as noted in TableIIwhere we summarise characteristics of these queries following similar dimensions to that used in the Berlin SPARQL benchmark[24].
[24]dataset is loaded into Apache Drill and relational dataset into MySQL database. All experiments are carried out on a local network, so that network cost remains negligible. The machines used for experiments have a 2. 60 GHz Core i7 processor, 8 GB of RAM and 500 GB hard disk running a 64-bit Windows 7 OS. A total of 5 queries are designed to evaluate and compare the query federation performance of PolyWeb against the FedX engine. The queries are of varying complexity and have varying type of characteristics as noted in TableIIwhere we summarise characteristics of these queries following similar dimensions to that used in the Berlin SPARQL benchmark[24]. TABLE I OVERVIEW OF EXPERIMENTAL DATASETS Datasets № trip RDF Data Type Type Data № record RDFisation Time COSMIC-CNV 37 M 6. 54 GB RDF 3.
2 GB 29 M 3 Hours TCGA-OV-CNV 10 M 494 MB RDB 212 MB 2. 6 M 2 Minutes CNVD-CNV 1. 7 M 128 MB TSV 34 MB 0. 2 M 3 Seconds Total 49 M 7 GB - 3. 5 GB 32 M 3 Hours Each RDF dataset was loaded into a different Virtuoso (Open Source v. 7. 2. 4. 2) SPARQL endpoint on separate phys- ical machines.
This paper describes our open-source software for predicting the intention of a user physically interacting with the humanoid robot iCub. Our goal is to allow the robot to infer the intention of the human partner during collaboration, by predicting the future intended trajectory: this capability is critical to design anticipatory behaviors that are crucial in human-robot collaborative scenarios, such as in co-manipulation, cooperative assembly or transportation. We propose an approach to endow the iCub with basic capabilities of intention recognition, based on Probabilistic Movement Primitives (ProMPs), a versatile method for representing, generalizing, and reproducing complex motor skills. The robot learns a set of motion primitives from several demonstrations, provided by the human via physical interaction.
). Thus, the ProMPs method is more suitable for our applications. In this paper, we present our approach to the problem of predicting the intention during human-robot physical interaction and collaboration, based on Probabilistic Movement Primitives (ProMPs)  [20] , and we present the associated open-source software code that implements the method for the iCub. To illustrate the technique, the exemplifying problem we tackle in this paper is to allow the robot to finish a movement initiated by the user that physically guides the robot arm. From the first observations of the joint movement, supposedly belonging to a movement primitive of some task, the robot must recognize which kind of task the human is doing, predict the "future" trajectory and complete the movement autonomously when the human releases the grasp on the robot.
Both kinematics (e. g. , Cartesian positions) and dynamics (e. g. , wrenches) information are collected. The N trajectories constitute the base for learning the primitive, that is learning the parameters ω of the trajectory distribution. We call this learned distribution the prior distribution. If multiple tasks are to be considered, then the process is replicated such that In the paper, we describe both the theoretical framework and the software that is used to perform this prediction. The software is currently implemented in Matlab and C++; it is open-source, available on github: https://github. com/inria-larsen/icubLearningTrajectories and it has been tested both with a simulated iCub in Gazebo and the real iCub. In simulation, physical guidance is provided by the Geomagic Touch 6  ; on the real robot, the human operator simply grabs the robot's forearm.
To summarize, the contributions of this paper are: • the description of a theoretical framework based on ProMPs for predicting the human desired trajectory and goal during physical human-robot interaction, providing the following features: recognition of the current task, estimation of the task duration, prediction of the future trajectory; • an experimental study about how multimodal information can be used to improve the estimation of the duration/speed of an initiated trajectory; • the open-source software to realize an intention recognition application with the iCub robot, both in simulation and on the real robot. The paper is organized as follows. In Section 2 we review the literature about intentions in Human-Robot Interaction (HRI), probabilistic models for motion primitives and their related software.
In Section 3 we describe the theoretical tools that we use to formalize the problem of predicting the intention of the human during interaction. Particularly, we describe the ProMPs and their use for predicting the evolution of a trajectory given early observations. In Section 4 we overview the software organization and the interconnection between our software and the iCub's main software, both for the real and simulated robot. The following sections are devoted to presenting our software and its use for predicting intention. We choose to present three examples of increasing complexity, with the simulated and real robot. We provide and explain in detail a software example for a 1-DOF trajectory in Section 5. In Sections 6 and 7 we present the intention recognition application with the simulated and real iCub, respectively.
This last difference can be critical for our applications with the humanoid robot iCub, since uncertainties are unavoidable and disturbances may happen frequently and de-stabilize the robot movement (for example, an unexpected collision during the movement). Thus, the ProMPs method is more accurate for our software. [49],  [50]  and  [25]  compared ProMPs and DMPs for learning primitives and specifically interaction primitives. With the DMP model, at the end of the movement, only a dynamic attractor is activated. Thus, it always reach a stable goal. The properties allowed by both methods are temporal scaling of the movement, learning from a single demonstration, and generalizing to new final position. With ProMPs, we have in addition the ability to do inference (thanks to the distribution), to force the robot to pass by several initial via-points (the early observations), to know the correlation between the input of the model, and to co-activate some ProMPs.
Related open-source software One of the goals of this paper is to introduce an open-source software for the iCub (but potentially for any other robot), where the ProMP method is used to recognize human intention during collaboration, so that the robot can execute initiated actions autonomously. This is not the first open-source implementation for representing movement primitives: however, it has a novel application and a rationale that makes it easy to use with the iCub robot. In Table  1  we report on the main software libraries that one can use to learn movement primitives. Some have been also used to realize learning applications with iCub, e. g. ,  [61, 22]  or to recognize human intention. However, the software we propose here is different: it provides an implementation of ProMPs used explicitly for intention recognition and prediction of intended trajectories.
7 In Section 3. 5 we explain how to recognize, from the early observations, to which of many known skills (modeled by ProMPs) the current trajectory belongs. In all these sections we tried to present the theoretical aspects related to the use of ProMPs for the intention recognition application. Practical examples of these theoretical problems are presented and explained later in sections 5 -7. Section 5 explains how to use our software, introduced in Section 4, for learning one ProMP for a simple set of 1-DOF trajectories. Section 6 presents an example with the simulated iCub in Gazebo, while Section 7 presents an example with the real iCub.
Notation To facilitate understanding of the theoretical framework, we first introduce the notations we use in this section and throughout the remainder of the paper. Trajectories: • X(t) ∈ R 3 , X(t) = [x(t), y(t), z(t)] : the x/y/z-axis Cartesian coordinate of the robot's end-effector. • F (t) ∈ R 6 , F (t) = [f x , f y , f z , m x , m y , m z ] : the wrench contact forces, i. e. the external forces and moments measured by the robot at the contact level (end-effector). • ξ(t) ∈ R D : the generic vector containing the current value or state of the trajectories at time t. It can be mono-dimensional (e. g. ξ(t) = [z(t)]), or multi-dimensional (e. g. Python Sarcos  [18]  Dynamical Systems approach to Learn Robot Motions GMM, SEDS  [70]  Matlab iCub  [17] ,  [71]  Function Approximation, DMP, and Black-Box Optimization (dmpbbo) DMP  [72]  Python or C++ iCub  [61, 22]  Learning Motor Skills from Partially Observed Movements Executed at Different Speeds ProMP  [73]  Matlab or Python -  [49]  icubLearningTrajectories ProMP  [74]  Matlab and C++ iCub -Table  1 : Open-source software libraries implementing Movement Primitives and their application to different known robots.