Natural Language Query Translation via Syntactic Dependency Graphs

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current natural language query interfaces struggle to accurately translate complex queries, especially those involving cyclical dependencies and path queries, in graph databases, and lack transparency in the translation process, making it difficult for users to adjust queries effectively.

Innovation Solution

A system that uses natural language processing techniques to tokenize queries, map tokens to logical data model concepts, and generate a query graph, allowing for accurate translation of complex queries by employing direct, indirect, and fuzzy matching methods, and providing insights into the translation process.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If natural language query interfaces are used to simplify database querying for non-technical users, then ease of operation is improved, but translation accuracy deteriorates due to ambiguity and complexity in mapping natural language to declarative query languages

Engineering Contradiction:
Improveease of queryingVSAvoidtranslation accuracy
Core Design Contradiction:
Ease of operationVSMeasurement precision

Solution Approach 1:

The patent introduces an intermediary natural language processing system that acts as a mediator between the user's natural language query and the database's declarative query language. This intermediary translates natural language tokens into database-specific tokens through multiple processing stages including tokenization, semantic analysis, and query generation, thereby resolving the contradiction by providing accurate translation without requiring users to learn complex query languages

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent segments the natural language query into individual tokens and processes each token separately through the translation system. By dividing the query into discrete units (subjects, predicates, objects, modifiers) and translating them individually using mapping rules and semantic analysis, the system maintains translation accuracy while handling the complexity of natural language ambiguity

Inventive Principle:
Principle #1Segmentation

2Adaptability or versatility

If existing natural language query approaches are applied to graph databases, then adaptability is improved, but manufacturing precision deteriorates because existing approaches cannot handle complex path and reachability queries

Engineering Contradiction:
Improvedatabase compatibilityVSAvoidquery translation precision
Core Design Contradiction:
Adaptability or versatilityVSManufacturing precision

Solution Approach 1:

The patent implements dynamic query generation that adapts to the specific database type (relational or graph) by selecting appropriate translation rules and query templates. For graph databases, the system dynamically generates path and reachability queries based on the detected graph structure and relationships, while for relational databases it uses traditional SQL generation, thereby achieving both adaptability and precision

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent changes the parameters of the translation process based on the target database type. When detecting a graph database, the system switches to graph-specific translation parameters including path query generation, relationship traversal, and reachability analysis, whereas relational databases use traditional SQL parameters. This parameter switching enables precise translation for each database type while maintaining overall system adaptability

Inventive Principle:
Principle #35Parameter changes

3Adaptability or versatility

If complex path and reachability queries in graph databases are supported, then adaptability is improved, but device complexity increases due to the need for specialized translation mechanisms

Engineering Contradiction:
Improvegraph query capabilityVSAvoidtranslation system complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent creates a universal natural language processing system that handles multiple database types (relational and graph) and multiple query types (simple retrieval, path queries, reachability queries) through a single unified architecture. The system uses a common tokenization and semantic analysis framework that adapts to different database types, avoiding the need for separate complex translation systems for each query type and thereby reducing overall device complexity

Inventive Principle:
Principle #6Universality (Multi-functionality)

4Ease of operation

If transparency in the translation process is provided, then ease of operation is improved by allowing user adjustments, but loss of information increases due to the need to expose internal translation details

Engineering Contradiction:
Improveuser controlVSAvoidtranslation process information
Core Design Contradiction:
Ease of operationVSLoss of information

Solution Approach 1:

The patent implements a feedback mechanism that provides users with information about the translation process in a controlled manner. The system exposes key translation decisions and generated queries to users for review and adjustment, allowing them to correct misunderstandings or refine their queries. This feedback loop enables user control without requiring the system to expose all internal processing details, thereby balancing transparency with information preservation

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS11816102B2Natural language query translation based on query graphs
Publication Date: 2023.11.14 ORACLE INT CORP
  • US11816102B2 patent drawing
  • US11816102B2 patent drawing
  • US11816102B2 patent drawing

AI summary

Techniques described herein allow for accurate translation of natural language (NL) queries to declarative language. A syntactic dependency parsing tree is generated for an NL query, which is used to map tokens in the query to logical data model concepts. Relationship-type mappings are completed based on relationship constraints. Final mappings are identified for any relationship tokens that are associated with multiple candidate mappings by identifying which candidate mappings have the lowest cost metrics. An NL query-specific query graph is generated based on the mapping data for the NL query and the logical data model. The query graph represents an NL query-specific version of the logical data model where grammatical dependencies between NL query words are translated to the query graph. A query graph is annotated with information, from the mapping data, that is not represented paths in the query graph. The query graph is used generate a computer-executable translation of the NL query.