U.S. patent application number 12/581859 was filed with the patent office on 2010-04-22 for method of computing a cooperative answer to a zero-result query through a high latency api.
Invention is credited to Francisco Corella, Karen Pomian Lewison.
Application Number | 20100100563 12/581859 |
Document ID | / |
Family ID | 42109474 |
Filed Date | 2010-04-22 |
United States Patent
Application |
20100100563 |
Kind Code |
A1 |
Corella; Francisco ; et
al. |
April 22, 2010 |
METHOD OF COMPUTING A COOPERATIVE ANSWER TO A ZERO-RESULT QUERY
THROUGH A HIGH LATENCY API
Abstract
An information retrieval system including a user operated
computer having a display and a storage facility, a search back-end
containing an index into a collection of documents, the index
defining results sets of queries relative to the collection of
documents, and a search application stored in the storage facility
which is executable by the computer to perform a method of
providing a cooperative answer to a query submitted by the user,
the submitted query having an empty result set, the cooperative
answer comprising subqueries of the submitted query and, for each
subquery, cardinality information indicative of whether the
subquery has an empty result set. The method includes making an
initial set of requests to the search back-end, a request
specifying a query and calling for a response that provides
cardinality information indicative of whether the subquery has an
empty result set, the response being said to be positive if the
result set is non-empty and negative if the result set is empty,
the requests in the initial set of requests being made in parallel
and specifying queries that are subqueries of the submitted query.
When a positive response to a request is received, the method
includes displaying the query specified by the request together
with cardinality information provided by the response which enables
the user to determine that the result set of the specified query is
not empty, the specified query and the cardinality information
being part of the cooperative answer. When a negative response to a
request is received, the method includes making a subsequent set of
requests to the search back-end, the requests being made in
parallel and specifying queries that are subqueries of the query
specified by the request for which the negative response is
received.
Inventors: |
Corella; Francisco; (San
Diego, CA) ; Lewison; Karen Pomian; (San Diego,
CA) |
Correspondence
Address: |
DICKE, BILLIG & CZAJA
FIFTH STREET TOWERS, 100 SOUTH FIFTH STREET, SUITE 2250
MINNEAPOLIS
MN
55402
US
|
Family ID: |
42109474 |
Appl. No.: |
12/581859 |
Filed: |
October 19, 2009 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61106570 |
Oct 18, 2008 |
|
|
|
61201855 |
Dec 16, 2008 |
|
|
|
Current U.S.
Class: |
707/770 ;
707/E17.014 |
Current CPC
Class: |
G06F 16/951 20190101;
G06F 16/334 20190101; G06Q 30/0256 20130101 |
Class at
Publication: |
707/770 ;
707/E17.014 |
International
Class: |
G06F 17/30 20060101
G06F017/30 |
Claims
1. An information retrieval system comprising: a computer operated
by a user, the computer having a display and a storage facility; a
search back-end containing an index into a collection of documents,
the index defining results sets of queries relative to the
collection of documents; and a search application stored in the
storage facility which is executable by the computer to perform a
method of providing a cooperative answer to a query submitted by
the user, the submitted query having an empty result set, the
cooperative answer comprising subqueries of the submitted query
and, for each subquery, cardinality information indicative of
whether the subquery has an empty result set, the method
comprising: making an initial set of requests to the search
back-end, a request specifying a query and calling for a response
that provides cardinality information indicative of whether the
subquery has an empty result set, the response being said to be
positive if the result set is non-empty and negative if the result
set is empty, the requests in the initial set of requests being
made in parallel and specifying queries that are subqueries of the
submitted query; when a positive response to a request is received,
displaying the query specified by the request together with
cardinality information provided by the response which enables the
user to determine that the result set of the specified query is not
empty, the specified query and the cardinality information being
part of the cooperative answer; and when a negative response to a
request is received, making a subsequent set of requests to the
search back-end, the requests being made in parallel and specifying
queries that are subqueries of the query specified by the request
for which the negative response is received.
2. The system of claim 1, wherein the computer is connected to the
search back-end via a network and the search application uses a
network interface exposed by the search back-end to make requests
to the search back-end and obtain responses.
3. The system of claim 2 wherein the network interface comprises an
HTTP-based interface.
4. The system of claim 3, wherein the network is the Internet.
5. The system of claim 4, wherein the collection of documents
comprises a collection of files reachable on the World Wide
Web.
6. A method of providing a cooperative answer to a query submitted
by a user to an information retrieval system, the submitted query
having an empty result set, the cooperative answer comprising
subqueries of the submitted query and, for each subquery,
cardinality information indicative of whether the subquery has an
empty result set, the information retrieval system comprising a
computer operated by the user, the computer having a display, the
method comprising: making an initial set of requests to a search
back-end, each request specifying a query and calling for a
response that provides cardinality information indicative of
whether the subquery has an empty result set, the response being
said to be positive if the result set is non-empty, and the
response being said to be negative and the query said to have
failed and to be a failing query if the result set is empty, the
requests in the initial set of requests being made in parallel and
specifying queries that are subqueries of the submitted query; when
a positive response to a request is received, displaying the query
specified by the request together with cardinality information
provided by the response which enables the user to determine that
the result set of the specified query is not empty, the specified
query and the cardinality information being part of the cooperative
answer; and when a negative response to a request is received,
making a subsequent set of requests to the search back-end, the
requests being made in parallel and specifying queries that are
subqueries of the query specified by the request for which the
negative response is received.
7. The method of claim 6, wherein the submitted query is a
conjunctive query and the queries specified by the initial set of
requests are children of the submitted query in a conjunction graph
of the submitted query.
8. The method of claim 7, wherein the queries specified by the
subsequent set of requests made when the response is a negative
response, which is a response to a request that specifies a failing
query, are those nodes of a conjunction graph of the submitted
query that are children of the failing query and whose parents have
all failed.
9. The method of claim 8, further comprising: creating an empty
list of zero-result queries before making the initial set of
requests; when a negative response is received, the negative
response being a response to a request that specifies a failing
query, removing from the list of zero-result queries every query
subsumed by the failing query, then adding the failing query to the
list; and when there are no pending requests and all requests in
initial and subsequent sets of requests having been fulfilled,
displaying the zero-result queries contained in the list together
with cardinality information that enables the user to determine
that every such displayed query has an empty result set, the
queries thus displayed and the cardinality information being part
of the cooperative answer.
10. The method of claim 9, wherein, when a positive response to a
request is received, the cardinality information provided by the
response and displayed together with the query specified by the
request is an estimate of the number of results in the result set
of the query.
11. A method of providing a cooperative answer to a Boolean query
submitted by a user to an information retrieval system, the
submitted query having an empty result set, the cooperative answer
comprising subqueries of a negation normal form of the submitted
query and, for each subquery, cardinality information indicative of
whether the subquery has an empty result set, the system comprising
a computer operated by the user, the computer having a display, the
method comprising: making an initial set of requests to a search
back-end, a request specifying a query and calling for a response
that provides cardinality information indicative of whether the
subquery has an empty result set, the response being said to be
positive if the result set is non-empty and negative if the result
set is empty, the requests in the initial set of requests being
made in parallel and specifying queries that are subqueries of a
negation normal form of the submitted query; when a positive
response to a request is received, displaying the query specified
by the request together with cardinality information provided by
the response which enables the user to determine that the result
set of the specified query is not empty, the specified query and
the cardinality information being part of the cooperative answer;
and when a negative response to a request is received, making a
subsequent set of requests to the search back-end, the requests
being made in parallel and specifying queries that are subqueries
of the query specified by the request for which the negative
response is received.
12. The method of claim 11, wherein the specified queries of the
initial set of requests are those nodes of a conjunction graph of a
negation normal form of the submitted query that are children of
nodes that are roots of the graph.
13. The method of claim 12, wherein the specified queries of the
subsequent set of requests made when the response is a negative
response, which is a response to a request that specifies a failing
query, are those nodes of a conjunction graph of a negation normal
form of the submitted query that are children of the failing query
and whose parents have all failed.
14. The method of claim 13, further comprising: creating an empty
list of zero-result queries before making the initial set of
requests; when a negative response is received, the negative
response being a response to a request that specifies a failing
query, removing from the list of zero-result queries every query
subsumed by the failing query, then adding the failing query to the
list; and when there are no pending requests and all requests in
initial and subsequent sets of requests having been fulfilled,
displaying the zero-result queries contained in the list together
with cardinality information that enables the user to determine
that every such displayed query has an empty result set, the
queries thus displayed and the cardinality information being part
of the cooperative answer.
15. The method of claim 14, wherein, when a positive response to a
request is received, the cardinality information provided by the
response and displayed together with the query specified by the
request is an estimate of the number of results in the result set
of the query.
16. A computer readable storage medium storing computer executable
instructions for controlling a computing device to perform a method
of providing a cooperative answer to a query submitted by a user
via a computing device to a search back-end containing an index
into a collection of documents and defining result sets of queries
relative to the collection of documents, the method comprising:
making an initial set of requests to the search back-end, a request
specifying a query and calling for a response that provides
cardinality information indicative of whether the subquery has an
empty result set, the response being said to be positive if the
result set is non-empty and negative if the result set is empty,
the requests in the initial set of requests being made in parallel
and specifying queries that are subqueries of the submitted query;
when a positive response to a request is received, displaying the
query specified by the request together with cardinality
information provided by the response which enables the user to
determine that the result set of the specified query is not empty,
the specified query and the cardinality information being part of
the cooperative answer; and when a negative response to a request
is received, making a subsequent set of requests to the search
back-end, the requests being made in parallel and specifying
queries that are subqueries of the query specified by the request
for which the negative response is received.
17. The computer readable storage medium of claim 16, wherein the
computing device is connected to the search back-end via a network
and the search application uses a network interface exposed by the
search back-end to make requests to the search back-end and obtain
responses.
18. The computer readable storage medium of claim 17, wherein the
network interface comprises an HTTP-based interface.
19. The computer readable storage medium of claim 18, wherein the
network is the Internet.
20. The computer readable storage medium of claim 19, wherein the
collection of documents comprises a collection of files reachable
on the World Wide Web.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] The subject matter of this application is related to the
subject matter of U.S. Provisional Patent Applications No.
61/106,570, filed on Oct. 18, 2008, and No. 61/201,855, filed on
Dec. 16, 2008, priority to which is claimed under 35 U.S.C.
.sctn.119(e) and which are incorporated herein by reference.
[0002] The subject matter of this application is also related to
the subject matter of a companion Non-Provisional patent
application entitled "Facilitating Browsing of Result Sets", by F.
Corella and K. P. Lewison, filed simultaneously with this
application and incorporated herein by reference.
BACKGROUND
[0003] In information retrieval, when a query submitted by a user
fails (i.e. the query has an empty result set), it is beneficial to
provide to the user a so-called cooperative response, or
cooperative answer, to the query that provides additional
information other than the fact that there are no results. Many
kinds of cooperative answers, applicable to many kinds of
information retrieval systems, have been proposed in the academic
literature. For example, one approach proposed one type of
cooperative answer to conjunctive queries, and another, broader
type of cooperative answer to Boolean queries, applicable in the
context of a bibliographic information retrieval system.
[0004] Today, all Web search engines accept conjunctive queries,
and some accept Boolean queries, such that the cooperative answers
proposed in the above-referenced approach are applicable in the
context of Web search. A cooperative answer according to this
approach consists of a collection of subqueries of the failed query
submitted by the user, a subquery being a query obtained by
removing syntactic elements from the submitted query, the
subqueries in the collection being more general than the submitted
query. The collection of subqueries comprises subqueries that fail
like the submitted query (even though they are more general and
thus less likely to fail than the submitted query), and subqueries
that succeed (i.e. that have a non-empty result set). The
subqueries that succeed are useful as possible follow-up queries.
The subqueries that fail are useful because they avoid the repeated
failures that would occur if the user submitted those subqueries,
and because each of them is, in some sense, an explanation of the
failure.
[0005] Recently, an important computational architecture has
emerged for Web search engines. In this architecture, the search
engine is split into two independent components, a front-end that
runs on a client machine operated by a user and a back-end that
runs on one or more server machines, the front-end being connected
to the back-end via the Internet and accessing the back-end through
an HTTP-based network interface called a Web application
programming interface (Web API). The front-end provides a user
interface, while the back-end provides a search index. In
operation, the user submits a query through the user interface on
the client machine, and the client machine forwards the query to
the back-end which computes a result set using the index. The
back-end provides pages of the result set of the query to the
front-end, and the front-end displays those pages to the user.
[0006] Many search back-ends are available on the Web today,
including back-ends provided by the companies that own the most
popular search engines, Google, Yahoo, and Bing, those back-ends
using the same indices that are used in those popular search
engines. Many hundreds of search front-ends have been developed,
resulting in the many hundreds of search engines that are available
on the Web today.
[0007] This split search engine architecture has important
advantages, but also has a disadvantage when it comes to providing
cooperative answers. A Web API, because it is accessed via the
Internet, has a high latency, usually of a few hundred
milliseconds. Such a high latency makes it impractical to compute a
cooperative answer by any of the methods that have been proposed so
far, all of which assume that the cooperative answer is computed on
the same machine where result sets are computed. A cooperative
answer consists of many subqueries, and its computation requires
interrogating the back-end through the API about those subqueries
and many more subqueries that do not end up in the cooperative
answer. Computing a cooperative answer by traditional methods can
easily take 30 seconds or more, which is unacceptable to the user
in a modern computing environment.
SUMMARY
[0008] In one embodiment, an information retrieval system is
provided which includes a user operated computer having a display
and a storage facility, a search back-end containing an index into
a collection of documents, the index defining results sets of
queries relative to the collection of documents, and a search
application stored in the storage facility which is executable by
the computer to perform a method of providing a cooperative answer
to a query submitted by the user, the submitted query having an
empty result set, the cooperative answer comprising subqueries of
the submitted query and, for each subquery, cardinality information
indicative of whether the subquery has an empty result set. The
method includes making an initial set of requests to the search
back-end, a request specifying a query and calling for a response
that provides cardinality information indicative of whether the
subquery has an empty result set, the response being said to be
positive if the result set is non-empty and negative if the result
set is empty, the requests in the initial set of requests being
made in parallel and specifying queries that are subqueries of the
submitted query. When a positive response to a request is received,
the method includes displaying the query specified by the request
together with cardinality information provided by the response
which enables the user to determine that the result set of the
specified query is not empty, the specified query and the
cardinality information being part of the cooperative answer. When
a negative response to a request is received, the method includes
making a subsequent set of requests to the search back-end, the
requests being made in parallel and specifying queries that are
subqueries of the query specified by the request for which the
negative response is received.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] The accompanying drawings are included to provide a further
understanding of embodiments and are incorporated in and constitute
a part of this specification. The drawings illustrate embodiments
and together with the description serve to explain principles of
embodiments. Other embodiments and many of the intended advantages
of embodiments will be readily appreciated as they become better
understood by reference to the following detailed description. The
elements of the drawings are not necessarily to scale relative to
each other. Reference numerals consist of a concatenation of a one-
or two-digit number referring to a figure, followed by a two-digit
number that locates the referenced part within the figure. A
reference numeral pertaining introduced in a figure may be used in
other figures to refer to the same part or a similar part.
[0010] FIG. 1 is a block diagram generally illustrating an example
of an information retrieval system for providing cooperative
answers to zero-result queries through a high-latency API according
to embodiments described herein.
[0011] FIG. 2 is a block diagram illustrating user-interface
elements presented on a display according to one embodiment.
[0012] FIG. 3 is an example of a cooperative answer displayed in a
left panel according to one embodiment.
[0013] FIG. 4 is an example of a cooperative answer to a query that
uses a site restriction according to one embodiment.
[0014] FIG. 5 is an example of a cooperative answer comprised of
queries with associated checkboxes according to one embodiment.
[0015] FIG. 6 is an illustration of the concept of a conjunction
graph of a conjunctive query.
[0016] FIG. 7 is an illustration of the concept of a conjunction
graph of a conjunctive query in which conjunction operators are
omitted.
[0017] FIG. 8 is an illustration of the concept of a conjunction
graph of a Boolean query in negation normal form.
[0018] FIG. 9 is a flow diagram illustrating a process followed by
a search application to initiate a computation of a cooperative
answer to a conjunctive query.
[0019] FIG. 10 is a flow diagram illustrating a process followed by
a search application, while computing a cooperative answer to a
conjunctive query, when a response is received from a back-end.
[0020] FIG. 11 is a flow diagram illustrating a process followed by
a search application to initiate a computation of a cooperative
answer to a Boolean query in negation normal form.
[0021] FIG. 12 is a flow diagram illustrating a process followed by
a search application while computing a cooperative answer to a
Boolean query in negation normal form when a response is received
from a back-end.
DETAILED DESCRIPTION
[0022] In the following Detailed Description, reference is made to
the accompanying drawings, which form a part hereof, and in which
is shown by way of illustration specific embodiments in which the
invention may be practiced. It is to be understood that other
embodiments may be utilized and structural or logical changes may
be made without departing from the scope of the present invention.
The following detailed description, therefore, is not to be taken
in a limiting sense. It is to be understood that the features of
the various exemplary embodiments described herein may be combined
with each other, unless specifically noted otherwise.
[0023] FIG. 1 is a block diagram generally illustrating an example
of an information retrieval system 100 for providing cooperative
answers, or cooperative responses to zero-result queries through a
high-latency API, using a method of computing cooperative answers,
or cooperative responses, according to one embodiment, that makes
it practical to provide such answers in spite of the high latency
of the API.
[0024] The word "response" has several meanings in the context of a
search. It can, for example, refer to a page of results presented
to the user after the user submits a query, to a page of results
and other information returned from a search back-end in response
to a request made by a front-end, to a cooperative response that
consists of a set of subqueries. To avoid confusion, the term
"cooperative answer" is hereafter used in lieu of the term
"cooperative response"
[0025] System 100 includes a computer 110 operated by a user 120, a
network 130, and a search back-end 140 that hosts an index 150 into
a collection of documents. Computer 110 is equipped with a display
112, a keyboard 114, and a mouse 116, and includes a storage
facility 160. An executable program, called a search application
162, is stored in storage facility 160 and runs on computer
110.
[0026] Given a query, index 150 defines the result set of the
query, each result in the result set being a data item providing
information about a document that matches the query, including a
link to the document. In one embodiment the collection of documents
is a collection of files reachable on the World Wide Web. In one
embodiment, the collection of documents comprises a collection of
documents on an intranet.
[0027] Search back-end 140 is connected to the network 130 and
exposes a network interface 142 that computer 110 uses to
communicate with search back-end 140. Network interface 142 is a
logical specification of messages that can be sent to and received
from search back-end 140. For illustrative purposes, network
interface 142 is shown in FIG. 1 as what appears to be a physical
component.
[0028] The latency of network interface 142, relative to computer
110, is the time it takes for computer 110 to receive a response to
a request made through network interface 142, including any delay
due to network 130. In one embodiment, where the network 130 is the
Internet and the collection of documents indexed by the index 150
of search back-end 140 is a substantial portion of the set of files
reachable on the World Wide Web, the latency is typically a few
hundred milliseconds, such latency being considered a high latency.
Methods according to the present embodiments are especially
beneficial in such high latency architectures.
[0029] In one embodiment, network interface 142 exposed by search
back-end 140 uses Hypertext Transfer Protocol (HTTP) messages, such
an interface being called an HTTP-based interface. In one such
embodiment, network 130 is the Internet; the HTTP-based interface
is then called a Web interface, or a Web Application Programming
Interface (Web API). In one embodiment, network 30 is an
intranet.
[0030] In one embodiment, where network 130 is the Internet,
storage facility 160 contains a Web browser program 168 that runs
on computer 110, and search application 162 is downloaded by a Web
browser 168 from a Web site 170 connected to the Internet. In one
embodiment, search application 162 runs on computer 110 by being
interpreted by a browser extension (also known as a browser
plug-in) 180.
[0031] In one embodiment, the browser plug-in 180 is supplied by
Adobe Systems, Inc. and called Flash Player.RTM., and search
application 162 is built on a programming platform also supplied by
Adobe Systems, Inc. and called Flex.RTM.. In such an embodiment,
search application 162 comprises project code written in MXML and
ActionScript and compiled by a platform compiler, and platform code
supplied by Adobe Systems, Inc., some of which is linked with the
project code. The project code is an event-driven program,
comprising routines that are invoked when events take place. Such a
routine is called an "event listener" or "event handler", and is
said to "handle" or "react to" the event upon which it is
invoked.
[0032] Search application 162 uses display 112, keyboard 114, and
mouse 116 of computer 110 to interact with user 120. Keyboard 114
is used to enter text into input fields of display 112. Mouse 116
is used for performing user-interface procedures, such as clicking
on a button.
[0033] Search application 162 uses network interface 142 to fetch
data from search back-end 140, including data such as:
[0034] (1) an estimate of the number of results in the result set
of a query, called a "cardinality estimate" for the query; and
[0035] (2) a page of the result set of a query, pages being
numbered, each page containing a fixed number of consecutive
results (e.g. page 1 containing results 1 through 10, page 2
containing results 11 through 20, etc.).
[0036] In one embodiment, search application 162 fetches such
information by making a request to search back-end 140 via network
130. The request conforms to network interface 142 and specifies
the query, as well as a desired range of results from the result
set of the query. The request elicits a response that fulfills the
request. The response also conforms to the network interface. The
response contains the cardinality estimate and, if the result set
is not empty, the page of results. The cardinality estimate is
accurate as to whether the result set is empty or not (i.e. if the
estimate is zero the result set is empty and if the estimate is not
zero the result set is not empty). A response with a zero estimate
is said to be negative response, while a response with a non-zero
estimate is said to be a positive response.
[0037] FIG. 2 illustrates an example of display 112 being used by
search application 162 to present user-interface elements to user
120, according to one embodiment. The user-interface elements
include an input field 210, called a "query box" or "search box",
where user 120 can enter a query, a search button 220 that user 120
can click to submit the query, and three panels, a left panel 230,
a center panel 240 and a right panel 250. In one embodiment, these
user-interface elements are presented inside a window 260 opened by
Web browser 168 on display 112. In one embodiment, right panel 250
is used to display advertisements.
[0038] In one embodiment, left panel 230 contains a set of queries
whose result sets can be browsed simultaneously in center panel
240, as disclosed in the above-referenced companion patent
application. When user 120 submits a query, the submitted query and
additional queries are placed in left panel 230. If the submitted
query has an empty result set and satisfies conditions described in
the above-referenced companion application (i.e. does not consist
of a single search term and is not overly complex), the additional
queries placed in left panel 230 are subqueries of the submitted
query that constitute a cooperative answer to the query.
[0039] FIG. 3 shows an example of a cooperative answer displayed in
left panel 230, according to one embodiment. Left panel 230
contains a query 310 submitted by user 120 that has an empty result
set, viz. the query "smoothie asdf qwer xyz13924". Left panel 230
also contains five subqueries of the query 310 that together
constitute a cooperative answer to the query 310. The subqueries
have fewer search terms than the query. They are therefore more
general than the query, and have result sets that are supersets of
the result set of the query.
[0040] The cooperative answer lists three subqueries that have
non-empty result sets, subqueries 320, 330, and 340, followed by
two subqueries that have empty result sets, subqueries 350 and 360.
Queries that have a non-empty result set are said to succeed and
are called "succeeding subqueries". Queries that have empty result
sets are said to fail and are called "failing queries" or
"zero-result queries".
[0041] Succeeding subqueries are included in the cooperative answer
because they are useful as possible follow-up queries. A succeeding
subquery is included in the cooperative answer only if there is no
succeeding subquery that is more specific (i.e. that has more
search terms). For example, the succeeding subquery "smoothie" is
not included because the succeeding subquery 320 "smoothie asdf"
and the subquery 330 "smoothie qwer" are more specific succeeding
subqueries.
[0042] Failing subqueries are also useful because they help user
120 avoid repeated failures. For example, after the failure of the
query 310 "smoothie asdf qwer xyz13924", user 120 may try "smoothie
asdf qwer", which also fails. This is avoided by the letting user
120 know that this query, included in the response as subquery 350,
also fails even though it is more general than the submitted query
310. A failing subquery is included in the cooperative answer only
if there is no failing subquery that is more general (i.e. that has
fewer search terms). For example, the failing subquery "smoothie
xyz13924" is not included because the failing subquery 360
"xyz13924" is more general.
[0043] Another reason why failing subqueries are useful is that
they can be viewed as explanations of the failure of the submitted
query. For example, the query 310 can be viewed as failing for two
independent reasons: because there are no Web pages containing the
words "smoothie", "asdf" and "query", and because there are no Web
pages containing the word "xyz13924".
[0044] A contrived example was used in FIG. 3 because few queries
that target the Web at large and consist of a combination of a few
dictionary words have empty result sets. Empty result sets,
however, occur more frequently when queries target a subset of the
Web, such as a particular Web site. In one embodiment, a query can
be made to target a site by using a site restriction, which is a
search term consisting of the operator "site:" immediately followed
by the DNS domain of the site.
[0045] FIG. 4 shows an example of a cooperative answer to a query
that uses a site restriction, according to one embodiment. The
query 410 "smoothie banana durian site:myrecipes.com" has an empty
result set. The subqueries 420, 430, and 440 of the query 410
constitute a cooperative answer to the query 410. The subquery 420
informs user 120 that results for "smoothie banana query" can be
found outside the targeted site, while the subquery 430 informs
user 120 that results for "smoothie banana" can be found in the
site; both are possible follow-up queries. The subquery 440 informs
user 120 that the word "durian" does not appear at all in the
targeted site.
[0046] In one embodiment, a query can be made to target a
particular site without using a site restriction, by specifying the
DNS domain of the site in a separate input box.
[0047] FIG. 5 shows the same query 410 and the same cooperative
answer comprising subqueries 420, 430, 440, according to one
embodiment, where every query in left panel 230 has an associated
checkbox, as described in the above-referenced companion patent
application. FIG. 5 shows the state of panel 230 immediately after
user 120 has submitted the query 410. The queries 410, 420, 430,
and 440 will be deleted from left panel 230 when user 120 submits a
subsequent query, unless user 120 removes a checkmark from a
checkbox in order to retain the associated query. Queries 510 and
520 illustrate unrelated queries that were added earlier to left
panel 230 and have been retained.
[0048] In one embodiment, a query is a Boolean expression
consisting of the Boolean operators AND, OR, and NOT, and of search
terms, with spaces used to separate syntactic elements and
parentheses used for grouping, such a query being called a Boolean
query. A search term can be a word or a phrase surrounded by double
quotes. In one embodiment, a search term can be a colon expression,
which begins with an operator consisting of a keyword followed by a
colon. An example of a colon expression is the site restriction
used above in the example of FIG. 4, which uses the operator
"site:" consisting of the keyword "site" followed by a colon.
[0049] A Boolean query is said to be a conjunction, or a
conjunctive query, if its operator with broadest scope, called the
top-level operator, is the conjunction operator AND. It is said to
be a disjunction, or a disjunctive query, if its top-level operator
is the disjunction operator OR. It is said to be a negation if its
top-level operator is the negation operator NOT. Since AND and OR
are associative operators, parentheses can be omitted without
ambiguity around an inner conjunction that is an operand of an
outer conjunction, and around an inner disjunction that is an
operand of an outer disjunction.
[0050] The conjuncts of a conjunctive query can be defined as
follows: remove all unnecessary parentheses, then consider the
sequence of top-level AND operators as an n-ary conjunction; the
conjuncts are then the operands of the n-ary conjunction. Consider
for example the expression "asdf AND (qwer AND (xyz OR (abc AND
def)))". It has an unnecessary pair of parentheses. After removing
the unnecessary parentheses it becomes "asdf AND qwer AND (xyz OR
(abc AND def))". This can be viewed as a ternary conjunction with
operands "asdf", "qwer" and "xyz OR (abc AND def)". Those three
operands are the conjuncts of the conjunction.
[0051] The disjuncts of a disjunctive query are defined in the same
way as the conjuncts of a conjunctive query, mutatis mutandis.
[0052] Given a conjunctive query, a "conjunctive subquery" of the
query is obtained by removing one or more conjuncts from the query,
an "immediate conjunctive subquery" being obtained by removing
exactly one conjunct. For example, "asdf AND poiu" is an immediate
conjunctive subquery of "asdf AND qwer AND poiu", obtained by
removing the middle conjunct "qwer"; and "poiu" is a conjunctive
subquery obtained by removing the first two conjuncts.
[0053] It should be observed that, whereas in the phrase
"conjunctive query" the word "conjunctive" refers to the contents
of the query, in the phrase "conjunctive subquery" the word
"conjunctive" refers to how the subquery is derived from a query
that contains it. Thus, a conjunctive subquery is not necessarily a
conjunctive query. For example, "poiu" is a conjunctive subquery of
"asdf AND qwer AND poiu" but it is not a conjunctive query (i.e. it
is not a conjunction), since it consists of a single search
term.
[0054] A conjunctive query defines a graph whose nodes are the
query and its conjunctive subqueries. There is an edge between a
first node and a second node if the second node is an immediate
conjunctive subquery of the first node; the first node is then said
to be a parent of the second node, and the second node a child of
the first node.
[0055] As an example, FIG. 6 shows the conjunction graph 600 of the
query "asdf AND qwer AND (xyz OR (abc AND def))". The top node 610
is the query itself. Nodes 620, 630, and 640 are the immediate
conjunctive subqueries of the query, each obtained by removing one
of the conjuncts of the query. Nodes 650, 660, and 670 are
conjunctive subqueries of the query obtained by removing two
conjuncts. Nodes 650, 660, and 670 are also the conjuncts of the
conjunctive query. The lines in the Figure represent the edges of
the graph. There is an edge 680, for example, between node 640 and
node 660, because the query 660 "(xyz OR (abc AND def)" is an
immediate conjunctive subquery of the query 640 "qwer AND (xyz OR
(abc AND def))". Node 660 is a child of node 640, and node 640 is a
parent of node 660.
[0056] In one embodiment, the conjunction operator can be omitted,
so that juxtaposition is interpreted as conjunction. For example,
the query "asdf qwer poiu" is a conjunctive query with implicit
conjunction operators, logically equivalent to the query "asdf AND
qwer AND poiu" where the conjunction operators are explicit. In one
embodiment, no explicit Boolean operators are recognized by the
parser, and therefore every query consists either of one search
term, or of a sequence of search terms interpreted as a
conjunction. FIG. 7 shows the conjunction graph 700 of the
conjunctive query "asdf qwer poiu" with implicit conjunction
operators.
[0057] A Boolean expression, and in particular a Boolean query, is
said to be in negation normal form if it contains no negated
conjunctions or disjunctions (i.e. if the negation operator NOT
only occurs in the query applied to atomic Boolean expressions).
Every Boolean expression can be put in negation normal form using
De Morgan's laws.
[0058] The concept of a "conjunction graph" can be extended to
apply to a query in negation normal form, as follows. If the query
is a single search term or a negation, the graph has a single node,
which is the query itself. If the query is a conjunction, the
conjunction graph is as defined before. If the query is a
disjunction, the nodes of the graph are the disjuncts of the
disjunction, as well as the conjunctive subqueries of any disjuncts
that are conjunctions. It should be noted that a node can be a
conjunctive subquery of multiple disjuncts. The edges of the graph
and the concepts of "parent" and "child" are defined as before. A
root is a node that has no parents. If the query is a search term,
a negation, or a conjunction, it has a single root; but if it is a
disjunction, each disjunct is a root.
[0059] The conjunction graph of a disjunction is a subgraph of the
conjunction graph of the conjunction obtained by combining the
conjuncts of all the disjuncts, which will be referred to as the
extended conjunction graph of the query.
[0060] As an example, FIG. 8 shows the conjunction graph and the
extended conjunction graph of the Boolean query: [0061] (asdf AND
qwer AND (xyz OR (abc AND def))) OR [0062] (asdf AND (NOT poiu) AND
(xyz OR (abc AND def))), which is in negation normal form. Dashed
rounded boxes indicate nodes that are part of the extended graph
but not of the non-extended graph. The query has two disjuncts,
which are the roots 810 and 820 of the non-extended graph. Nodes
such as node 830 which are not part of the non-extended conjunction
graph are deemed not to be of interest to user 120 and are excluded
from a cooperative answer to the query.
[0063] In one embodiment, when search application 162 provides a
cooperative answer to a Boolean query having an empty result set,
the cooperative answer consists of the most general nodes in the
conjunction graph of the negation normal form of the query that
have an empty result set, and the most specific nodes in the same
graph that have a non-empty result set. As a special case, if the
query is a conjunctive query, the cooperative answer consists of
the most general conjunctive subqueries of the query that have an
empty result set, and the most specific ones that have a non-empty
result set.
[0064] FIGS. 9 and 10 illustrate two processes used by search
application 162 to perform a method of providing a cooperative
answer to a conjunctive query submitted by user 120 that has an
empty result set. To compute the cooperative answer, search
application 162 makes requests to search back-end 140 through the
network interface 142. Each request specifies a query that is a
conjunctive subquery of the submitted query, and produces a
response that includes a cardinality estimate for the specified
query.
[0065] Search application 162 makes sets of requests in parallel. A
set of requests is made in parallel, by definition, if each request
is made without waiting for responses to previous requests to be
received. By making use of parallel requests, the present
implementation is able to reduce the delay that would be caused by
multiple serial interactions with the network interface. In one
embodiment, where the latency of network interface 142 with respect
to the computer 110, including the latency due to network 130, is a
few hundred milliseconds, experiments show that the present
implementation is able to provide a cooperative answer in only a
few seconds for queries that necessitate interactions with network
interface 142 that would take 30 seconds or more if done
serially.
[0066] Search application 162 uses a first counter to keep track of
the number of requests that have been made since the beginning of
the computation, and a second counter to keep track of the number
of responses that have been received. The first counter is called
the "counter of requests made" and the second counter is called the
"counter of responses received. The value of the first counter
minus the value of the second counter is equal to the number of
pending requests. The computation ends when the number of pending
requests is equal to zero. The two counters are kept in the storage
facility 160.
[0067] Search application 162 constructs in storage facility 160 a
list of zero-result queries that it uses to collect failing
conjunctive subqueries of the submitted query during the
computation. At the end of the computation, the list of zero-result
queries contains the most general failing conjunctive subqueries of
the submitted query.
[0068] In the descriptions of FIGS. 9 and 10, the meaning of the
terms "parent" and "child" is relative to the conjunction graph of
the submitted query.
[0069] FIG. 9 is a flow diagram generally illustrating one
embodiment of a process 900 employed by search application 162 to
initiate the computation of a cooperative answer to a conjunctive
query submitted by user 120. At 910, search application 162 creates
an empty list of zero-result queries and proceeds to 920.
[0070] At 920, search application 162 initializes the counter of
responses received, setting the value of the counter to zero, and
then proceeds to 930. At 930, search application 162 makes an
initial set of requests to search back-end 140, the initial set of
requests consisting of requests specifying queries that are
children of the submitted query, one such request for each child,
and initializes the counter of requests made to the number of such
requests.
[0071] FIG. 10 is a flow diagram generally illustrating one
embodiment of a process 1000 employed by search application 162
when a response is received, the response fulfilling a request. At
1010, search application 162 increments the counter of responses
received and proceeds to 1020. At 1020, search application 162
checks if the cardinality estimate contained in the response is
zero. If so, search application 162 proceeds to 1030. Otherwise,
search application 162 proceeds to 1050.
[0072] At 1030, search application 162 removes from the list of
zero-result queries any query subsumed by the query specified by
the fulfilled request. A query in the list is subsumed by the
specified query if the specified query is a conjunctive subquery of
the query in the list, and therefore is more general than the query
in the list. Search application 162 then proceeds to 1040.
[0073] At 1040, search application 162 makes a subsequent set of
requests and increments accordingly the counter of requests made,
the requests specifying queries that are children of the query
specified by the fulfilled request, the set consisting of one such
request for each child whose parents have all failed. Search
application 162 then proceeds to 1060.
[0074] In one embodiment, search application 162 tests whether the
parents of a node have all failed by keeping a count of the number
of times that a request specifying the node has been fulfilled and
checking whether the count is equal to the number of parents of the
node. In another embodiment, search application 162 tests such
condition by remembering what nodes have failed.
[0075] At 1050, search application 162 displays the query specified
by the fulfilled request, together with the cardinality estimate
contained in the response, in the left panel 230, and then proceeds
to 1060. At 1060, search application 162 checks whether the number
of requests made equals the number of responses received according
to the respective counters. If so, search application 162 proceeds
to 1070. Otherwise, the process 1000 terminates. At 1070, search
application 162 displays in the left panel 230 the queries
contained in the list of zero-result queries, each with a
cardinality estimate of zero.
[0076] FIGS. 11 and 12 are flow diagrams generally illustrating two
processes used by search application 162 to perform a method of
providing a cooperative answer to a Boolean query submitted by user
120 that has an empty result set. The method is an extension of the
method of providing a cooperative answer to a conjunctive query
illustrated by FIGS. 9 and 10. As before, search application 162
makes sets of requests to search back-end 140 in parallel, uses a
counter of requests made and a counter of responses received, and
builds a list of zero-result queries.
[0077] FIG. 11 is a flow diagram generally illustrating one
embodiment of a process 1100 employed by search application 162 to
initiate the computation of a cooperative response to the Boolean
query submitted by user 120. At 1110, search application 162 puts
the Boolean query in negation normal form and proceeds to 1120.
[0078] At 1120, search application 162 creates an empty list of
zero-result queries, and then proceeds to 1130. At 1130, search
application 162 initializes the counter of responses received,
setting the value of the counter to zero, and then proceeds to
1140. At 1140, search application 162 makes an initial set of
requests to search back-end 140, consisting of requests specifying
queries that are children of the roots of the conjunction graph of
the negation normal form of the submitted query, one such request
for each child, and initializes the counter of requests made to the
number of such requests.
[0079] FIG. 12 is a flow diagram generally illustrating one
embodiment of a process 1200 employed by search application 162
when a response is received, the response fulfilling a request. The
description of the process is not repeated here because as it is
substantially similar to the description of corresponding portions
of process 1000, except at 1240, which differs from 1040.
[0080] At 1240, search application 162 makes a subsequent set of
requests and increments accordingly the counter of requests made,
the requests specifying queries that are children of the query
specified by the fulfilled request, the set consisting of one such
request for each child whose parents in the conjunction graph of
the negation normal form have all failed.
[0081] In one embodiment, search application 162 tests whether the
parents of a node have all failed by remembering what nodes have
failed. It is noted that when enumerating the parents to check if
they have all failed, care must be taken to avoid the error of
including parents of the node in the extended graph that are not
parents of the node in the non-extended graph.
[0082] In summary, the embodiments described enable the computation
of cooperative answers through any high-latency API in a much
shorter period of time than is possible with traditional methods.
One important case of a high-latency API is a Web API. Embodiments
that utilize a Web API make it practical to provide cooperative
answers in a split search engine architecture. However, in a
addition to Web APIs, the teachings of the present embodiments may
be applied to anytype of high-latency API, such as network
interfaces based on protocols other than HTTP (e.g. LDAP, and
interfaces that are not necessarily accessed across a network, such
as database interfaces). Furthermore, although time savings
provided by the present embodiments increase with the API latency,
time savings can be realized for any latency and, thus, the
benefits of the present embodiments can be realized in embodiments
that utilize any API.
[0083] According to one embodiment, the teachings of the browsing
techniques described by the companion application cross-referenced
above so that result sets of the queries that comprise a
cooperative answer can be browsed simultaneously, or in an
interleaved fashion.
[0084] Although specific embodiments have been illustrated and
described herein, it will be appreciated by those of ordinary skill
in the art that a variety of alternate and/or equivalent
implementations may be substituted for the specific embodiments
shown and described without departing from the scope of the present
invention. This application is intended to cover any adaptations or
variations of the specific embodiments discussed herein.
* * * * *