This paper introduces NLDS-QL1, a translator of data science questions expressed in natural language (NL) into data science queries on graph databases. Our translator is based on a simplified NL described by a grammar that specifies sentences combining keywords to refer to operations on graphs with the vocabulary of the graph schema. This paper shows NLDS-QL in action within a scenario to explore and analyse a graph base with patient diagnoses generated with the open-source Synthea.
questions, formulated by non-technical experts over data collections. Allowing their expression in natural lanThe volume of connected data, often modelled as graphs, guage (NL) would optimize data accessibility. However, has grown exponentially. The availability of these graphs this facility implies complex NL analysis, particularly data collections has been democratised through social when such questions are intended to be transformed into networks and knowledge graphs used to explore con- sophisticated workflows. Thus, to achieve our goal, we tent (e.g. scientific papers, clinical cases). Although this address the problem under a reverse-engineering strataccessibility is promising, it introduces a barrier for non- egy: we build a simplified natural language (NL) grammar experts, who have to familiarise with the nature of the and map NL data science questions to graph data science data, the way they have been represented in the database queries as those proposed by Neo4J DS templates. The and the specific query languages or user interfaces to users can then express their questions using this simpliaccess them. ifed NL with sentences that correspond to the DS Neo4J
Besides, the emergence of data science has brought a templates, seeing and assessing the results and proposing new type of ’complex’ queries embodying a data analysis new questions over an enriched vocabulary that can extend scenario. A data science query generally refers to a work- the NL query language treated by our tool. lfow of tasks including exploration, data cleaning and preparation, sampling and analysis. These workflows include visualisation and evaluation tasks that involve the calculation of scores and metrics. Implementing these workflows is a challenge even for engineers and data scientists. In most cases, users should have advanced skills in querying and analysing the data according to their needs and the type of search questions to be answered. Requiring formal and technical expertise from non-computer scientists is not obvious or reasonable.
In our work, the goal is to identify important research
a collection of data corresponding to medical follow- 1. Approaches that address NL translation on
ups, doctors (users) express the questions whose answers SPARQL for knowledge graph queries, such as [
Existing work has addressed data mining using NL, but not yet the expression of data science questions. There are diferent approaches to developing a NL interface for database queries, in general for relational systems.
Georgia Kutrika [
Given a relational database and assuming knowledge of
the schema vocabulary: 1. Analysis of the NL query
expression; 2. Disambiguation and interpretation, which
produces a set of ranked interpretations; 3. Finally, the
translation into SQL and its execution. Three
generations of NL Query to SQL Transformation systems can
be identified [
Overview of NLDS-QL expressions. The expression
of NLDS-QL questions is based on the way data science
operations are applied on graphs in Neo4J. Neo4J
de2. NL processing based like NaLIR (parser) [
ATHENA [
Query rules & vocabulary
Speech to Text cleaning
Query evaluation
exploring a medical graph new graphs that can be named and persist or not. The creation of new graphs and whether to persist them is expressed as function call commands.
Consequently, the definition of data science questions in NL include expressions for specifying the commands specified in the Neo4J template. The most simple expression for defining a graph view and estimating the memory required assuming that it is stored in Neo4J and that the graph schema with the nodes and relations is available, is defined with the following English expression: We set up an experiment to validate our approach. Therefore we use the patient part of the Synthea Generic study.
The Synthea’s Generic Graph2 models various diseases conditions that contribute to the medical history of synthetic patients 800K vertices and nearly 2000K edges.
Querying graphs is based on navigational queries, which retrieve information already "contained" in a graph. • Create and estimate memory for the graph view In the Synthea graph, it is possible to ask simple queries <subgraph-name> [named as < view name >] like : How many patients are there in the Synthea study? with the node < node name > and the relationship Which allergies are identified in the Synthea study pa< relationship name > [oriented] tients? But it is also possible to go further and ask analytical type questions that involve classification tasks
The data science operation task includes estimating such as What are the most frequently prescribed drugs the cost in memory of applying a graph data science al- for patients in the Synthea study? Answering this type gorithm on the graph, using the algorithm on the graph of query involves performing a sequence of tasks ordered view. According to specific keywords, NLDS-QL can in a pipeline, which we call a data science query. determine the type of algorithm that can be applied. Keywords like most important, most popular, most influential refer to centrality algorithms such as PageRank and Louvain and classify, communities, group can refer to clustering algorithms like Label Propagation, as illustrated by the following three questions: • 1 : Estimate the required memory for applying < DS algorithm name> on the graph view < view name > • 2 : Find the most important/most popular < node name > with < relation name > [in the graph < graph name >] with < number of iterations > maximum of iterations and with a damping factor < floating number > • 3 : Classify/Find groups/communities of < node name > within the view < view name > with relation < relation name > with < number of 2https://xilinx.github.io/graphanalytics/recom-tg3/ iterations > maximum of iterations synthea-overview.html
Use case The use case is based on the Synthea patients graph shown in Figure 2. It describes the immunisations, allergies, conditions, studies, procedures and care plans of patients. Each entity and its relations are characterised by properties that describe them. The patient graph has approximately 100 thousand nodes and 37 thousand relations stored on Neo4J.
The use case of NLDS-QL on the Synthea patients graph is based on a conversational pipeline where expert and non-expert users can ask questions to start exploring the graph (see Figure 3). The use case environment initially shows the Synthea patients graph, and users can ask for details about the description of the graph, like the number of nodes and relations. Then, the user can ask a question. The system generates one or several queries, Inmunizations Allergies
Procedures Patient_had_immunization Patient_had_allergy Patient_had_condition • Specifying a graph view from the patient graph, as Neo4J works with graph views stored in RAM when data science algorithms are applied. • Then it is possible to generate two queries that call the page rank algorithm to process the keyword "most important" with the possibility to make the view persistent and consider the constraints related to the parameters of the Pagerank algorithm.
Centrality.
Find the most popular Encounters for Medications in the graph.
MATCH (n:Encounters)[r:ENCOUNTER_FOR_MEDICATION]-() with n,count(*) as degree return id(n), degree ORDER BY (degree) DESC and then the user can either choose one or several queries to be adjusted or executed and then modified (see right side of Figure 3). For every choice, the user can evaluate the system’s performance with stars that show the Find the most important Drugs prescribed for the PATIENT degree of satisfaction. with a maximum of 25 iterations and a damping factor of
For exploring the Synthea graph, the use case proposes 0.60. a set of queries that include navigational queries of the type selection, projection, aggregation.
Selection. Find the Medications for which the DESCRIPTION is Lisinopril 10 MG Oral Tablet and the REASON of the DESCRIPTION is Hypertension.
CALL gds.graph.create( ’my_graph’, ’Medications’, {
PATIENT_HAS_MEDICATION: { orientation: ’NATURAL’ MATCH (n:Allergies) return n.DESCRIPTION MATCH (n:Patients) return n.BIRTHPLACE Projection. Which is the birthplace of the PATIENTS in the study? Selection and Projection. Find the Encounters DESCRIPTION node where the DESCRIPTION of the drugs is Amlodipine 5 MG Oral Tablet.
MATCH (n:Encounters)-[*]-> (m:Medications {
DESCRIPTION:
’Amlodipine 5 MG Oral Tablet’ }) return n.DESCRIPTION, m.DESCRIPTION Aggregation. How many patients are caucasian? })
} CALL gds.pageRank.write.estimate( ’my_graph’, { writeProperty: ’pageRank’, maxIterations: 25, dampingFactor:0.60 }) YIELD nodeCount, relationshipCount, bytesMin, bytesMax, requiredMemory CALL gds.pageRank.
stream(’my_graph’) YIELD nodeId, score RETURN gds.util.
asNode(nodeId).name AS name, score ORDER BY score DESC LIMIT 10 MATCH (n:Patients {RACE:’white’}) In this example, NSDL-QL generates the template that return count(n) includes first the graph "my_graph". Then it computes For data science queries, the use case shows NLDS-QL the estimation of required memory, number of nodes and questions that refer to centrality type operations. Note relations, minimum and maximum bytes that will yield that the translation is quite complex as it involves: the resulting graph when executing PageRank with the
NLDS-QL:> Show the Synthea graph specified parameters. Then the call to the algorithm with the result format with the top 10 nodes associating each node with its score.
Community detection. The translation also involves several operations as described in the definition of data science queries.
Get the subgroup of Patients who have TIENT_HAS_CAREPLAN in the graph with iterations 20
CALL gds.labelPropagation.
write.estimate( ’my_graph’, {
writeProperty: ’community’ }) YIELD nodeCount, relationshipCount, bytesMin, bytesMax, requiredMemory CALL gds.labelPropagation.
stream(’my_graph’, {maxIterations: 20}) YIELD nodeId, communityId RETURN communityId,
count(nodeId) AS size
ORDER BY size DESC LIMIT 5
This paper introduced NLDS-QL and showed through a use case how to map NL data science questions (using an adapted vocabulary) to Neo4J data science query templates. The use case aimed at querying and analysing a graph in the medical domain. Users with medical and non-medical backgrounds can define a sequence of natural language queries executed step by step to explore the graph, as in data science questions. Thereby users PA- can acquire an understanding of medical prescriptions max proposed to patients by classifying their treatment, their physiological characteristics to better understand how diseases are diagnosed and treated according to patients conditions. In this way, we showed the essential aspects of a data science query template expressed in NL.
The approach is flexible and can be enhanced for processing documents with richer NL vocabulary and more complex templates. The intervention of a human in handling natural language queries calls for the design of an interactive strategy based on conversation. We have started to design a more evolved conversational interface considering human in the loop and user profiling techniques.