Patent Application
20190236217
Typical database management systems (DBMS) consist of an integrated set of computer software that allows users to interact with one or more databases and to access the data contained in the database(s). A DBMS allows entry, storage, and retrieval of large quantities of information and, coupled with data analytics software, provides a user means to manage how that information is organized and presented. Various presentation formats, such as dashboards, can help a business user visualize changing business conditions in the form of visual reports to make decisions based on real-time data. Dashboards help users identify trends, regroup data by varying parameters, sort out quantities, and measure the impact of their activities. To build a dashboard, a user of a typical DBMS has to know the data and its parameters (dimensions and measures, for example) in order to properly query the data and get the best, most applicable results.
Querying complex data from a database to focus results on a specific answer can be difficult and time consuming if queries are not already set up and stored for the data, often by a database administrator with the ability to write complex queries. Learning curves for working with specific data can also be quite long until a user feels comfortable navigating the data. In addition, various databases may use a wide range of query languages that each require significant training, user effort, or processing power to parse query inputs and produce useful results.
The accompanying drawings are incorporated herein and form a part of the specification.
In the drawings, like reference numbers generally indicate identical or similar elements. Additionally, generally, the left-most digit(s) of a reference number identifies the drawing in which the reference number first appears.
Natural Language Query (NLQ) allows a user to ask questions about data in a database, and get answers efficiently and easily from a database, without needing to know specific measures, dimensions, filters, and similar data parameters before querying the data. The initial querying and subsequent use of the data can be approached conversationally, that is, in the language that a user would normally use to talk to another human being.
Conversations and stories are how people naturally communicate and interface with each other. Framing experiences as conversation will result in greater productivity and higher engagement. It will also reduce the learning curve and other challenges of using a new tool for the business user by making the method of querying data as simple and natural as a conversation. NLQ enables business users to ask a question about a dataset in the context of a visual view of the data, such as a dashboard or app, without knowing the details about the data structure that went into building the view. Multiple users can converse about the data without being experts, or even knowledgeable, about the specific database contents as long as the users know the general business context of the database.
In addition to allowing a user freedom to ask questions of the database in natural language, further efficiencies can be made by predicting what the user might want to know, presenting options to the user based on a past or current query, pre-entering the query into a query box as the user types it, suggesting the next word, or autocorrecting any error that the user is suspected to have made while entering the query.
Disclosed herein are methods, systems, and computer program products that enable a user to ask questions about data in a database using natural language and receive quick answers in a “conversational” graphical user interface (GUI) without needing to manipulate, or even to know the details of, measures, dimensions, filters, etc. of the data in advance. By way of non-limiting examples, the answers can be displayed in a dashboard, opened in an explorer view, shared with collaborators, or further queried or manipulated using natural language in other applications that are configured to use natural language query (NLQ) within the data analytics system. The natural language is parsed using templates, in one embodiment, and features are available to provide feedback to the user for invalid or unrelated queries that cannot be parsed for any number of reasons, as exemplified herein. As in a conversation between two parties, the methods, systems, and computer products allow, as a key feature, the user to have a back-and-forth conversation with the database to further focus the user's query results on exactly what the user seeks to know, while greatly simplifying the querying process for the user.
“NLQ,” or “natural language query,” as used herein, refers to interrogating a database about specific content, where the query consists only of standard terms in the user's natural language, without any special syntax or format. A query can be built using terms in any form, including a statement (or full sentence), a question, or a list of keywords. A processing engine processes the terms in the query input text. While typical natural language query approaches include complex analysis and phrase recognition using heavy parsers with probability models, embodiments disclosed herein describe a simplified approach that depends on categorizing and mapping grammar, and working with a smaller subset of data for higher performance efficiency and better accuracy. For example, in this method, an off-the-shelf parser does not have to be trained.
“Template,” as referred to herein, is a software representation of a lookup tree for determining analytics queries. In the exemplary embodiment, a template consists of a list of predefined natural language queries in English form that would closely match a human user's predicted questions about data in a database. Each natural language query is mapped to a predefined Analytics Query Language (AQL) query. Once a user's question is matched to a natural language query in the template, the corresponding AQL query will be able to load input data, operate on it, and output the results data. Such a template allows an NLQ application to more efficiently parse a user's query because, regardless of the exact words or ordering of words that the user inputs, a template can help ensure that the query is of proper format and content in relation to the database being queried. A query is simply made up of statements, where each statement has an input, an operation, and an output. It is to be appreciated that the novel method described herein may use templates written in other query languages, such as standard SQL (structured query language) and Datalog.
The “NLQ input,” as referred to herein, can be, for example, a GUI box with a cursor for free-form typing of text, a drop-down menu from which a text item can be selected with a click of a mouse, or other user-selectable input. The exemplary embodiment is described herein as a free-form text box for typing from a cursor, with alternative selectable text to fill in the free-form text box. When the cursor is inside the NLQ input box, the method will accept a user's typing of “Enter” on a keyboard or other similar computing device input, for example, at any time to submit the text as a query. Once the query is matched to the template and after the user submits it, the method will answer the query by providing relevant query results, if available from the current database. The method 100 is not limited to this example embodiment.
It is to be appreciated that not all steps depicted in method 100 may be needed to perform the disclosure provided herein. Further, some of the steps may be performed simultaneously, or in a different order than shown in
Natural Language Query (NLQ) architecture allows NLQ to be used in various models of a data analytics application, such as, for example, Explorer, App Runtime, and Builder applications of a customer relationship management (OM) analytics platform, using common natural language processing (NLP) in a novel way. A person of ordinary skill in the art will appreciate that this method can be used on other data analytics platforms and in a wide variety of other applications that query databases.
The foundation of NLQ analysis is the same across all applications that use natural language and is built upon the analysis structure 200 depicted in
To simplify query generation, embodiments disclosed herein are built upon a novel use of templates to provide efficient parsing of an NLQ input from the user, using a lexicon based upon the metadata in the database and grammar as predicted from a typical user of the known data. The purpose of the NLQ input in a GUI is to accept a user's free-form text typing of natural language, where the user provides the scope of the query by the keywords entered, and then to match a user's intended query to a pre-determined template. The pre-determined template allows the GUI to guide the user with hints and suggestions for words to include in the query that would yield the most applicable and useful query results, bounded by the supported template and relevant to the loaded database. The template provides only the grammar needed and uses a lexicon that is smaller than typically used by natural language parsers, reducing the complexity necessary to complete the parsing function.
Any complexity in the template “lookup,” or input matching, function is further hidden from the user. When the user types an input, one or more predefined natural language queries may be suggested to the user and easily run, despite any complexities in the underlying data. For instance, although a query may require complex software code to manipulate data for specific query results, that complexity will be hidden in one template sentence or phrase. Similarly, although a query may require a complex lookup to parse a complex user input, the user will not sense that complexity. The templates themselves are not difficult to retrieve or use: they can be packaged with an application for use with specific databases, or they can be called up as standalone items from anywhere, for example, a local server or Cloud storage, with a new database load. Because the templates work in the background, their access is seamless to the user. However, templates can be easily updated if a user so chooses to change their content.
As illustrated in
Note that the user does not have to form the query as a question to get results that are responsive to the query. For example, the words “what is the” can be built into the lookup tree to handle the introductory words in an NLQ input, as shown in TL2306, but if they are not included in the NLQ input, the software can assume them and still reach other paths such as TL1305 and TL3307. In another embodiment, the software may also accept “show me,” “list,” “find,” “tell me,” or similar variations, as introductory phrases, for example. Nor does the user have to order the words in precisely the same way for each query, as the template can predict variations in word order. For sure, the placeholder node {{measure}} 301 in TL1305 refers to the same generic node as {{measure}} 312 in TL3307. The user can also word a query in variable ways to get the same results returned, and a template can predict those variations, such as “breakdown 313 of {{measure}} 301 by {{dimension}} 302,” as illustrated in TL1305. Breakdown 313 would be a predictably standard word that users would input when querying a database in natural language.
A user may also ask questions of higher complexity about the data, for instance, including two dimensions 311 and 314 by which to query the database, as exemplified in TL4308. For example, TL4308 would build the query, “Breakdown of sales amount by month and by state,” so that a user could find out that there were $1,472,922 in sales in February, 2016 in Arizona, for example, when the query generates an answer. A person of ordinary skill in the art would appreciate the sheer number of variations in how data from even a single database could be represented using this method.
Embodiments disclosed herein perform two exemplary features of query generation using template lookups: “typeahead” and “autocomplete.” These features aid the user in constructing a query quickly, as the method guides the user in not only what to build but how to build it in effective predetermined ways, and constructing the query easily, as the method supports a powerful user interface that is simple and straightforward. A person of ordinary skill in the art would appreciate the challenges in sparing a user the architectural complexities inherent in querying a large database while providing the user a powerful interface that is surprisingly very simple to use with a basic GUI that is easily integrated onto a variety of platforms and is transportable across applications.
“Typeahead” refers to first matching what the user types in the NLQ input to words in a predetermined template, predicting the user's next typed words in the NLQ input based on the matches, and displaying suggestions of those words as phrases below the NLQ input ahead of what the user physically types. “Typeahead” thus helps the user to complete the user's query. The user is intended to see these suggestions as the possible, and the most applicable, next words to type in the query input. The user may ignore the text and type different word(s), or the user may begin to type the suggested word(s) from a sample query. As the user types and the query becomes more specific, the suggested phrase adapts accordingly to the prediction of the user's query. The suggested sample queries come from the associated template that is loaded with the database. If the user begins to type a suggested word as displayed in the typeahead text, the “autocomplete” feature will complete the word and the next possible typeahead word(s) will be shown below the NLQ input, thus further decreasing the effort that the user must expend.
Because the NLQ input is an open text input field, the user can type in whatever text is desired, even if the query would not result in an answer. The user has control to submit a query at any time from the NLQ input, but relevant results will only be returned once enough of the query has been matched to a query in the template for a loaded database or dataset. “Enough” of the query to facilitate a lookup in the template would be, for example, entry of a measure and a filter criterion into the NLQ input. Because relevant filter criteria may change based on the specific data measure being queried, and a user may not have enough knowledge of the appropriate filter to type, the method will provide suggestions as previously discussed. Even with the additional guidance, certain situations will not result in query results, but will instead provide an error state that may be displayed to the user in various ways depending on the platform or application. The method provides this free-form NLQ input with error-checking capability and an overall state-checking capability, for example, so that a user can know why query results are not provided as requested. Example error states are invalid query, empty state, no dataset, or autocorrected query. These error states allow a user to be informed of and to fix a query quickly.
In one embodiment, if the user types a word or phrase into the NLQ input that is not in the template, that is, is not relevant to the database, such as “Hello world,” the method identifies the query as invalid. The method will thus return an error message below the NLQ input space, for example, indicating to the user “Could not find an answer to your question. Please try with a different query.” The method will alternatively provide a suggested query from the template that is relevant to the current database, such as “Ask questions such as ‘What are my top 5 opportunities?’” Thus, a user will be guided toward a relevant query, saving time and confusion. The user can then replace the query with the suggestion or a similarly relevant query without spending time to remedially learn about the database contents outside of the application space. Once a new relevant query is submitted, the error message will go away.
A similar query suggestion from the template is displayed, for example, when the user first accesses the NLQ input functionality in an application, that is, for an initial, or empty, state of the NLQ input. The NLQ input will be disabled if there is no dataset or database, and thus no template, loaded in the current application, and the exemplary embodiment of the method will indicate such to the user. Lastly, the method allows a user to submit a query with a misspelled word, and the method will attempt to match the misspelled word, returning results for the closest match in the template and indicating to the user that the substitution of the autocorrected word was performed to provide the query results. For example, if the user enters “Show oportunties by segment,” with “opportunities” spelled incorrectly, the template will be able to match the typed word to the dimension “opportunities” in the template, so that relevant results may be returned. The method will indicate to the user “Showing results for opportunities” instead of “oportunties.”
In another embodiment, the method allows a user to define the user's own scope filters. For example, the user may want to know something specific about the data for which a metadata lookup term is not included in a standard template for the specific database. The method allows a user to create and save unique scope filter entities that will be used with the template when that particular user logs in to an application and queries that database.
Computer System Implementation
Various embodiments may be implemented using one or more well-known computer systems, such as computer system 500 shown in
Computer system 500 may include one or more processors (also called central processing units, or CPUs), such as a processor 504. Processor 504 may be connected to a communication infrastructure or bus 506.
Computer system 500 may also include user input/output device(s) 503, such as monitors, keyboards, pointing devices, etc., which may communicate with communication infrastructure 506 through user input/output interface(s) 502.
One or more of processors 504 may be a graphics processing unit (GPU). In an embodiment, a GPU may be a processor that is a specialized electronic circuit designed to process mathematically intensive applications. The GPU may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images, videos, etc.
Computer system 500 may also include a main or primary memory 508, such as random access memory (RAM). Main memory 508 may include one or more levels of cache. Main memory 508 may have stored therein control logic (i.e., computer software) and/or data.
Computer system 500 may also include one or more secondary storage devices or memory 510. Secondary memory 510 may include, for example, a hard disk drive 512 or a removable storage device or drive 514. Removable storage drive 514 may be a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup device, or any other storage device/drive.
Removable storage drive 514 may interact with a removable storage unit 518. Removable storage unit 518 may include a computer usable or readable storage device having stored thereon computer software (control logic) or data. Removable storage unit 518 may be a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, or any other computer data storage device. Removable storage chive 514 may read from or write to removable storage unit 518.
Secondary memory 510 may include other means, devices, components, instrumentalities, or other approaches for allowing computer programs or other instructions or data to be accessed by computer system 500. Such means, devices, components, instrumentalities, or other approaches may include, for example, a removable storage unit 522 and an interface 520. Examples of the removable storage unit 522 and the interface 520 may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, or any other removable storage unit and associated interface.
Computer system 500 may further include a communication or network interface 524. Communication interface 524 may enable computer system 500 to communicate and interact with any combination of external devices, external networks, external entities, etc. (individually and collectively referenced by reference number 528). For example, communication interface 524 may allow computer system 500 to communicate with external or remote devices 528 over communications path 526, which may be wired or wireless (or a combination thereof), and which may include any combination of LANs, WANs, the :Internet, etc. Control logic or data may be transmitted to and from computer system 500 via communication path 526.
Computer system 500 may also be any of a personal digital assistant (PDA), desktop workstation, laptop or notebook computer, netbook, tablet, smart phone, smart watch or other wearable, appliance, part of the Internet-of-Things, or embedded system, to name a few non-limiting examples, or any combination thereof.
Computer system 500 may be a client or server, accessing or hosting any applications or data through any delivery paradigm, including but not limited to remote or distributed cloud computing solutions; local or on-premises software (“on-premise” cloud-based solutions); “as a service” models (e.g., content as a service (CaaS), digital content as a service (DCaaS), software as a service (SaaS), managed software as a service (MSaaS), platform as a service (PaaS), desktop as a service (DaaS), framework as a service (FaaS), backend as a service (BaaS), mobile backend as a service (MBaaS), infrastructure as a service (IaaS), etc.); or a hybrid model including any combination of the foregoing examples or other services or delivery paradigms.
Any applicable data structures, file formats, and schemas in computer system 1400 may be derived from standards including but not limited to JavaScript Object Notation (JSON), Extensible Markup Language (XML), Yet Another Markup Language (YAML), Extensible Hypertext Markup Language (XHTML), Wireless Markup Language (WML), MessagePack, XML User Interface Language (XUL), or any other functionally similar representations alone or in combination. Alternatively, proprietary data structures, formats or schemas may be used, either exclusively or in combination with known or open standards.
In some embodiments, a tangible, non-transitory apparatus or article of manufacture comprising a tangible, non-transitory computer useable or readable medium having control logic (software) stored thereon may also be referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer system 500, main memory 508, secondary memory 510, and removable storage units 518 and 522, as well as tangible articles of manufacture embodying any combination of the foregoing. Such control logic, when executed by one or more data processing devices (such as computer system 500), may cause such data processing devices to operate as described herein.
Based on the teachings contained in this disclosure, it will be apparent to persons skilled in the relevant art(s) how to make and use embodiments of this disclosure using data processing devices, computer systems, or computer architectures other than that shown in
It is to be appreciated that the Detailed Description section, and not any other section, is intended to be used to interpret the claims. Other sections can set forth one or more but not all exemplary embodiments as contemplated by the inventor(s), and thus, are not intended to limit this disclosure or the appended claims in any way.
While this disclosure describes exemplary embodiments for exemplary fields and applications, it should be understood that the disclosure is not limited thereto. Other embodiments and modifications thereto are possible, and are within the scope and spirit of this disclosure. For example, and without limiting the generality of this paragraph, embodiments are not limited to the software, hardware, firmware, or entities illustrated in the figures or described herein. Further, embodiments (whether or not explicitly described herein) have significant utility to fields and applications beyond the examples described herein.
Embodiments have been described herein with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined as long as the specified functions and relationships (or equivalents thereof) are appropriately performed. Also, alternative embodiments can perform functional blocks, steps, operations, methods, etc. using orderings different than those described herein.
References herein to “one embodiment,” “an embodiment,” “an exemplary embodiment,” or similar phrases, indicate that the embodiment described can include a particular feature, structure, or characteristic, but every embodiment cannot necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it would be within the knowledge of persons skilled in the relevant art(s) to incorporate such feature, structure, or characteristic into other embodiments whether or not explicitly mentioned or described herein. Additionally, some embodiments can be described using the expression “coupled” and “connected,” along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, some embodiments can be described using the terms “connected” or “coupled” to indicate that two or more elements are in direct physical or electrical contact with each other. The term “coupled,” however, can also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.
The breadth and scope of this disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
This application is related to U.S. patent application Ser. No. ______, concurrently filed herewith, entitled “Actionable Answer Card in Natural Language Query” (Atty. Dkt. No. 3462.0900000), the entirety of which is hereby incorporated by reference.
