Are You Using English Query?

Raise your hand if you’ve used Microsoft’s English Query feature on a project within the last six months. Hmmm ... that’s what I thought. Microsoft introduced English Query in SQL Server 6.5 Enterprise Edition, which shipped two years ago. Unfortunately, surprisingly few people have taken the time to integrate it into their user interfaces (UIs). That’s a crying shame. English Query might not be a perfect fit for all your applications’ needs, but it can add tremendous value to the user experience when it does fit!

Here’s a short paraphrased description from the English Query home page. (This is a great starter site if you’ve never used English Query. You’ll also want to browse the newsgroup postings at microsoft.public.sqlserver.mseq.) English Query consists of an authoring tool and an engine. To implement natural-language searching, you first use the authoring tool to provide domain knowledge to the engine. In other words, the authoring tool makes it easy to relate database entities to objects in the domain. For example, you might create a verb relationship between salespeople and products by stating that "salespeople sell products." English Query uses these relationships to perform true, deep natural-language parsing of users’ questions, which provides better search results than you would get by using keyword-based technology.

The engine converts English questions into standard SQL statements, then sends these statements to the database. For instance, the engine might convert "What hotels in Hawaii have scuba?" to:

select distinct dbo.HotelProperty.HotelName as "Hotel Name",   dbo.HotelProperty.USReservationPhone as "Phone",   dbo.HotelProperty.StreetAddress1 as "Street Address",   dbo.HotelProperty.CityName as "City",   dbo.HotelProperty.StateRegionName as   "State or Region" from dbo.HotelProperty, AmenityNames, Amenitieswhere   dbo.HotelProperty.StateRegionName='Hawaii' and   AmenityNames.Amenity='Scuba'   and AmenityNames.AmenityID=Amenities.AmenityID and   dbo.HotelProperty.HotelID=Amenities.Hotelid 

In other words, your users type queries in English rather than SQL. English Query translates the questions into SQL by using the domain knowledge in the English Query model. Then English Query runs the query and returns the answer. This process gets even slicker when you hook English Query up to speech-recognition software so you can speak your questions rather than type them. Structurally, English Query is nothing more than a set of simple COM objects, so it’s amazingly simple to drop English Query functionality into almost any COM-based UI you can dream up.

Why haven’t more people used English Query? To be honest, the first release of English Query wasn’t easy to use. Developers needed to spend too much time setting up the domain knowledge model before users could start asking questions. To be fair, the development time spent and the improved user interface was probably well worth the effort, but getting people to try new things can be a struggle. Things have changed!

Microsoft is touting English Query as a major component of its business intelligence and knowledge management strategy, and new English Query releases, especially Beta 1 of English Query 7.5, have made it much easier to get a simple English Query interface up and running. The UI for building the domain knowledge is greatly improved. Without too much exaggeration, it’s possible to get a simple EQ application talking to an OLAP database in less than 15 minutes. These days, you have almost no excuse for not giving it a try. Among other improvements, English Query 7.5 brings natural language to the world of business intelligence. The English Query home page even has a demo you can run and download that will translate English questions into MDX statements that can be run against the sample FoodMart OLAP database.

Properly managed, English Query can make it much easier to create powerful UIs that let us turn information into results. Check it out now or I’ll have to pester you again in a few months!