Shulou(Shulou.com)05/31 Report--

This article mainly explains "what is natural language query". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is natural language query".

Some of you may be familiar with FactEngine (www.factengine.ai). FactEngine is a program designed to revolutionize the way people think about databases and database queries.

This may seem like a bold move, but the database industry has been in trouble for some time, and it wasn't until recently that people asked for more and got it.

Since the early 1990s, I remember people trying natural language queries as a way to make it easier for ordinary people to access databases. In those days, structured query language (SQL) was all the rage, and the relational database they used has dominated the industry.

The main problem with relational databases is that SQL is tedious to write and reverse engineering is time-consuming. That is, if you have an unwritten SQL query, it's sometimes hard to figure out what it means.

For example, the above query in SQL looks like this:

SELECT [Lecturer] .FirstName, [Lecturer] .LastName, [School] .SchoolName, [Faculty] .FacultyName, [TimetableBooking] .LecturerId, [TimetableBooking] .Semester, [TimetableBooking] .WeekDay, [TimetableBooking] .PeriodNr, [TimetableBooking] .RoomRoomNr, [Lecturer] .EmailAddress, [TimetableBooking]. ClassId FROM Lecturer, School, Faculty, TimetableBooking, Room, Position Timeslot WHERE Lecturer.SchoolId = School.SchoolId AND School.FacultyId = Faculty.FacultyId AND TimetableBooking.FacultyId = Faculty.FacultyId AND TimetableBooking.RoomRoomNr = Room.RoomRoomNr AND Lecturer.PositionId = Position.PositionId AND TimetableBooking.Semester = Timeslot.Semester AND TimetableBooking.WeekDay = Timeslot.WeekDay AND TimetableBooking.PeriodNr = Timeslot.PeriodNr AND Room.RoomName = 'A1'

I know, right? What does that mean?

Therefore, for a long time, people have been looking for ways to query databases in natural language to make their lives easier.

Part of the reason for the emergence of the so-called graph database is that the query language is more naturally adapted to predicates between said entities. This focuses more on natural language. For example, if someone is a friend of someone else in our database, we might write a graphical query like *:

MATCH (p1:person)-[: FRIEND-WITH]-(p2:person) WHERE p1.name = "Jack" RETURN p2.name

I know, right? What do all dots and dashes, capital letters, colons indicate?

With FactEngine, you only need to write:

> A simple natural language query. Image by author.

The advantage of FactEngine is that using the underlying language architecture (controlled natural language), it doesn't matter whether you run on a graphical database or a relational database.

In an earlier article, I explained why any relational database can be treated as a graphical database, and all databases are multi-model bars, which they think are different. In layman's terms, it means that any database can be queried using natural language, even if they are controlled. Any database can also be queried as a graph database.

The reason is that the two main types of databases (graphical databases and relational databases) are conceptually isomorphic. From a layman's point of view, this means that they can be conceptually treated as the same.

But let's go back to natural language queries and controlled natural languages.

What is controlled natural language?

As the name implies, controlled natural language is a natural language grammar with a degree of control over what you say and how you say it. A controlled natural language elegant enough will look like vanilla natural language, because its core is, of course, natural language.

Natural language controlled by FactEngine is effective because it is isomorphic to other languages.

That is to say. You don't have to worry about whether to operate on a relational database or a dedicated graph database. All you need to know is that all databases can be treated as a graph database. This allows you to use a language on any database.

A trip to FactEngine

Natural language query used to be known as "snake oil".

The reason for this is that most attempts at natural language queries (NLQ) rely on some form of reasoning to map natural languages to query languages and database structures, rather than pure algorithmic methods that always guarantee the desired results.

The reasoning engine commonly used in NLQ relies on disambiguating sentences in natural language, just as the human brain disambiguates complex and sometimes ambiguous sentences. In this respect, the NLQ inference engine has the potential to misinterpret natural language queries in the same way as misinterpreting natural language.

Indeed, if you imagine an artificial intelligence universal technology (AGI) as smart as anyone alive, then your artificial intelligence will not provide better opportunities for ambiguity as that person does. This is the question of querying the database, where you need the exact answer to a well-structured query.

Controlled natural language provides a solution, at least until AGI can ask questions to eliminate ambiguous sentences and resolve queries on its own. Even so, even if AGI did it... Can AGI still parse queries? The answer must be some kind of structured query, or it may first be a controlled natural language query.

Therefore, to reach the level of FactEngine today, FactEngine needs an infrastructure that allows for the construction of controlled natural language queries.

My former company, Viev, worked towards this goal for 11 years in developing the Boston conceptual modeling tool, which helps users develop data models that include natural language constructs and use object role modeling as the basis for model development.

But FactEngine needs another reason. In addition to the obvious advantages of natural language concept query, it is the state of the existing technology in the market that drives the development of the market.

In terms of readability, graphic query is a jump from SQL. In order to achieve the degree that natural language query makes today's graphic query language look primitive, we need to make a breakthrough in another level.

When the author first saw the query language of database Grakn, it was the main driving force of FactEngine. A typical Grakn query is as follows:

Match $p isa person; i$ isa issue; $auth2 ($iGrainomp) isa authorship; $r isa repostitory; cr$ ($is,$r) isa contains; $m isa milestone; $cm ($iMagnedim) isa contains; $p2 isa person; $p! = $p2; $ass ($iGrainomp2 $) isa assignment; $comm isa comment; $t ($iGrainure $comm) isa thread; $p3 isa person; $p2! = $p3; $auth3 ($comm, $p3) isa authorship; $i2 isa issue; $dep ($iQuin2) isa dependency; limit 5; offset 0; get

I know, right? What does that mean?

Grakn calls this an "advanced query language". It's enough to say. The same query in FactEngine is as follows:

> Image by author.

That is, Grakn challenges other languages by derogating them to primitive languages, so it accepts the challenge to clarify the appearance of high-level query languages.

What are the benefits of natural language queries?

Controlled natural language queries provide the same utilities as comparable SQL and graphical queries, and it is the real benefit of making the software actually help you write queries in the first place.

The following is a snapshot of software that helps people write natural language queries in FactEngine:

> FactEngine assisting to write a database query. Image by author.

In the era of artificial intelligence, easy to write queries has become a hot topic. People expect to get more from their database and the accompanying query language. People do not expect to be an information technology expert to get results from the database. Providing natural language queries allows customer-oriented applications to put tools that directly query the database in the hands of the customer without having to leave the work to more technicians.

Indeed, if you look at existing SQL and graphical database technologies, it's almost designed to make life difficult and restrict access to technologically savvy people. It's a waste of time and resources. The democratization of data and technology is mainly to expand the technology market by making it easier for everyday people to use.

Another advantage is that natural language is easy to read. After writing, the natural language query can be easily shared with others, and they will know the purpose of the query immediately after reading it.

Technical

Existing query languages (such as SQL) and current graphical query languages (with the exception of FactEngine knowledge language) come from a time when everything was too difficult. The idea is that it's hard to treat the''(space) character as a character, so we'll use MATCH (p1:person)-[: FRIEND-WITH]-(p2:person) instead of WHICH Person, who is a friend of WHICH Person 2. Or, it's hard to get the computer to assign its own difference variables to the entity, so we end up with $p3 isa person. $p2 people = $p3; not people 3, not people 2.

While making things difficult and not having a computer to do the work for you may allow technical experts to continue to work, it is not entirely helpful or customer-centric. It also mocks people's perception and elegance of art.

It also takes time for the computer to do the hard work for you, so bringing the product to market will bring unskilled solutions to customers.

Therefore, FactEngine has carried out 13 years of object role modeling software research and development, and more than 30 years of object role modeling and fact-based modeling research.

Fact-based modeling believes that natural languages (including spaces and phrases) are part of the database conceptual modeling problem.

A typical object role model is as follows:

> An Object-Role Model. Image by author.

Software for object role modeling (ORM) is hard to write, which is why you don't have much ORM software on the market. Fact-based modeling (FBM) can be said to be the same.

However, once you have the right ORM / FBM software, it is possible to achieve extraordinary achievements. For example, it is easy to visualize the model as an entity relation diagram (ERD) of a relational database or an attribute graph schema (PGS) of a graphical database.

So, technically, you need an appropriate fact-based metamodel, and then you can get started. It's more involved, but it's proprietary.

Needless to say, your customers don't have to worry about whether they operate on a graphical database or a relational database, all they need to care about is being able to write queries on that database simply and easily.

Where are we

FactEngine is a new type of commercial database query language technology. For 1:1 mapping directly to SQL, this technique is quite mature and evolving. Graphical query languages, such as Neo4j, have SQL O / JDBC drivers, so proof-of-concept through SQL and graphical databases is a fait accompli.

Where are the rest of the world? Well. We know one, which is why FactEngine was born.)

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Thank you for your reading. the above is the content of "what is Natural language query". After the study of this article, I believe you have a deeper understanding of what is natural language query. The specific use of the situation also needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.