The Future of Query in an AI World (Part 2)

by

Back in December I gave you Murph’s definition of ‘query’, “a request for information from any set of data, information source or database.” Long before we had computers on our wrists (like an Apple Watch), or in our pocket (like your smart phone), or on every desk, people had to really work for any query that came to their mind. 

When I was growing up people only carried 3 or 4 things in their wallets, depending on their age. If you were 16 and above, you had hopefully gotten your Drivers License. About the same time, you got your ‘hand written’ Social Security card (I printed my own name on my card) and in fact I still have it.  Older people may have gotten their Medicare card in the 1960s. But almost everyone, from about the 4th grade up had gone and gotten their local Library card, because therein lay the wealth of knowledge of the world. 

If you could afford one, then your family might have purchased an encyclopedia set, perhaps two volumes at a time over a couple of years. I was one of those luck people, and the World Book Encyclopedia opened my eyes to much of the world I hadn't yet seen. Today, people turn to Wikipedia on the Internet for such summary information, and Google to access the graphic images related thereto. 

But back then, if you wanted an in-depth answer to your query you took yourself down to the Library for hours-on-end, perhaps even days-on-end, to do the research to answer the complexity of your query. Sometimes the local library wasn’t enough, you had to request a ‘special book’ which different libraries ‘lent’ to each other to fulfill an inquisitive mind.

But the library wasn’t a straight forward source of query either. To do your research and find the right book(s) you had to understand the library’s own ‘query language’. That language took the form of the Dewey-decimal system of numbering. It was an ‘indexing system’ in which small cards were used to record the name of the book, the author of the book, and the numeric location of the book within the libraries shelves. Once you knew the number and the layout of the library, you could trace the book’s location.

In a lot of ways, the library was laid out like a big ‘database’.  If you think of the library’s areas as the tables in a database, and you consider the stacks (sections of shelving) like the configuration of the data within the table, and the shelves in the stacks like the rows of data, then the book represents the specific data element in the database. To get you to that data element, the book, quickly the library developed an ‘index system’ just like most databases of today.

Of course, you might not have been intending to read the entire book, you just needed a few specific pieces of critical information.  Now each book becomes a database.  The book may be divided into sections (like tables in a database) and chapters (the configuration of specific data), and paragraphs, sentences and words. Good thing there is a Table of Contents, but more importantly, the Index to help you find what you are looking for quickly. After all, you wouldn’t want to read 300 pages to find the one sentence you need containing the information you want… “what a waste of time to read a book, right?”

As we can see the key to query whether in a book, a library or a modern database is understanding two things ‘the language of the system’ and ‘the indexing of the data.’

From a computer programming and use standpoint, query has taken the same approach until recently.  Computers have, like the library used a language all their own, in fact several different languages. Many references will tell you that the first such language was Fortran, invented in 1957 by mathematicians and engineers working for IBM; however, Plankalkul was developed nearly 15 years earlier but wasn’t implemented until 1998.

Other early computer languages included Autocode, COBOL, Flow-matic, and LISP. The BASIC computer language didn’t come along until 1963 and until recently BASIC in the form of ‘Visual BASIC’ and ‘Visual BASIC.NET’ were the most widely known computer languages.  During the 1980’s languages like C and C++ were developed. For you QuickBooks Desktop users you are probably aware that much of the ‘code’ in QuickBooks still hangs on from the original versions written in C and C++.

If you want to get the data out of a computer, and to understand it, you must know the language. For years all queries of information were written in the form of computer language-based commands. What that meant is that only programmers could write the query to provide you with information you needed.

But rarely were ‘people’ ever allowed to talk to programmers, typically if you had a query you had to go through a ‘System Analyst’ who would sit down and ask you a set of questions to ensure that you really needed what you wanted to know, and if you were certain what you wanted to know was in fact the information you needed or wanted. 

In other words, these System Analysts were there to make you feel totally stupid that you had asked for a query to be performed in the first place. After all, computers had better things to do then answer the questions of ‘mere humans.’ And more importantly, programmers had better things to do than write queries to get information out of a computer, they were busy teaching it new things to do.

When it got to be ‘such a pain’ to get a query of your data, typically management would decide we will hire some more programmers whose job it is only meet query results. Before long, those programmers asked themselves, how can we ‘automate’ the fulfillment of query requests? Soon thereafter programmers began developing computer interfaces that allowed users to select from a variety of parameters and options. Those choices triggered the underlying stored procedures and code to call the query within the computer.

With so many repetitive requests, all the various options were soon stored in lists, and customized queries became standardized reports. Now users could simply select the report they needed within the interface and problem solved, it was easier than using your library card.

There was just one problem. What if your query didn’t fit any of the standardized reports? What if you needed more, or less; something very specific. Even worse what if you wanted something that nobody had every requested before?  Now you were right back where you started, needing a programmer to write a query.

Fortunately, you were not the only person needing custom information. So many users wanted more, and didn’t want to wait around for a programmer, that ‘other programmers’ began developing custom reporting engines.  These engines gave you a way to quickly design your own queries in relatively simplistic steps so that you didn’t have to learn the ‘special languages’ and ‘indexing’ to find your data and produce your report.  Unfortunately, they still had a learning curve that many users simply refused to learn. There was another problem too, many times you had to have a different custom reporting engine for each program you needed data from.

About then, the world of the internet came upon us. Slow at first, then accelerating at almost alarming pace.  Before long it seemed that almost every piece of information no the planet, from the news from China to the stock prices in the last 30-seconds were at reach, if you only knew where to look, and how to get the information.

In other words, we were right back in the library again. But this time instead of a building with a limited number of volumes, we had a whole ‘world wide web’ if we understood ‘the language’ and the ‘indexing’ to find everything on the web.  When you think about it, the URL (name) is just an IP address, as are computers on the web, and all of that is just a fancy form of the ‘Dewey-decimal’ system.

This is where a new form of query arrives on the scene, a form of query that allows users to make use of some common language commands typed into a box to find the data almost magically.  Query by example was maximized by the ‘Google’ search engine to help you find almost anything, anywhere on the internet. All the underlying artificial intelligence is doing the ‘dirty work’ for you of applying the correct language and indexing to get you where you want to be, or at least to a list of choices from which you can choose.

Google is easy to use, just type your query into the box. Type ‘Sunflowers’ in the box and you get ‘Helianthus’ (the genus name of the 70 species of plants collectively known as sunflowers) brought to you by Wikipedia. You get “How to Plant, Grow and Care for Sunflowers” from the Almanac, and you get the advertisements “Sunflower seeds”, “Live Sunflowers”, “Floral shops with Sunflowers”, etc.

But now, type “My best revenue sources last fiscal quarter” in a Google search box and see what you get.  When I did this, I got “JPMorgan Chase’s First Quarter of 2018” and “Delta Airlines Revenue Grown Accelerates” and “Apple Recorded More than Half of Total Smartphone Sales”.  There was absolutely nothing about ‘my best revenue’, that’s because my own financial information is locked away in my own QuickBooks file, hidden (as I want it to be) from public view, so Google isn’t supposed to be able to access it.

So why, with all this artificial intelligence, and machine learning, can’t the simplicity of a Google-like search do the same thing for ‘my own data’ that the Google search engine does for the world wide web?  It can, the future of query has arrived, join me tomorrow to read all about it.