|
|
|
Distributed or remote access |
Answer collection and retrieval system governed by a pay-off meter6856986
Abstract
The invention is a set of processes for improving the methods of a self-organizing database governed by a payoff meter process. The inventive set of processes processes enable a user who is seeking an answer not in the database to make a commitment to buy the answer if it is supplied within a period of time. A second set of processes enables a user who is seeking to supply an answer, to claim exclusive rights to supply that answer for a period of time.
Claims
I claim:
1. An answer collection and retrieval method comprising the following steps performed by an online computer database:
a. initially, registering a user's identification information,
b. registering user's preference in supplying or retrieving an answer corresponding to a question,
upon the inputting of a question,
c. if the user prefers to supply said corresponding answer, looking for said corresponding answer in said database,
c1. if corresponding answer is found, outputting a message telling the user that the answer is already in the database,
c2. if no corresponding answer is found, allowing the user to input the answer, storing the corresponding answer and registering that royalties are due to the user when said answer is requested,
d. if the user prefers to retrieve an answer corresponding to said question,
d1. registering time and date said question is inputted,
d2. searching to find if an answer corresponding to said question is in the database,
d2a. if corresponding answer is in the database, outputting the answer, registering a charge due by said user who inputted the question and a royalty due to the user who supplied the answer, adding one to the tally of times said question has been asked,
d2b. invoking a pay-off formula, said formula using demand information registered about an answer, including the number of times an answer is requested via a question, and the timestamps of those requests, said formula calculating a pay-off estimate of the amount of money that a supplier of an answer will receive for supplying that answer,
d2c. outputting the pay-off estimate resulting from the pay-off formula calculation,
d2d. if no corresponding answer is in the database, checking if said question is stored in the database,
d2d1. if no, storing the question and setting to one the tally of times said question has been asked, and calculating said pay-off formula,
d2d2. if yes, adding one to the tally of times said question has been asked, and calculating said pay-off formula,
d2d3. outputting the resulting pay-off estimate.
2. The method of claim 1, said method also comprising the steps of registering and displaying that a user has requested a specified improvement to an answer.
3. The method of claim 1, said method also comprising the steps of registering the sale of an answer and the price of that sale, and using said data in said pay-off formula calculation.
4. The method of claim 1, said method also comprising the steps of registering a user's intent to buy an answer, said intent being in the form of a price offer for the answer, and using said data in said pay-off formula calculation.
5. The method of claim 1, said method also comprising the steps registering a user's intent to buy an answer, said intent being in the form of a price offer being in the form of a binding commitment for a certain period of time to buy said answer.
6. The method of claim 1, said method also comprising the step of enabling a user who inputs an answer to set the price of the answer.
7. The method of claim 1, said method also comprising the steps of registering and displaying a user's intent to supply an answer that corresponds to the question the user has entered.
8. The method of claim 1, said method also comprising the steps of registering and displaying a user's commitment to supply an answer that corresponds to the question the user has entered.
9. The method of claim 1, said method also comprising the steps of registering and displaying a user's intent to supply an answer to a corresponding question, and assigning that user the exclusive right to supply that answer for a period of time.
10. The method of claim 1, said method also comprising the steps of registering and displaying a user's intent to supply an answer to a corresponding question, and enabling that user to pay for the exclusive right to supply that answer for a period of time.
Description
STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH
Not Applicable
BACKGROUND
1. Field of the Invention
This invention relates to a fee supported data base method and system for community use.
2. Description of Related Art
The primary prior art is U.S. Pat. No. 5,359,508, which describes a new type of online data base system. The system disclosed in this patent provides an economic solution to two critical problems of online data bases: what answers (data) to collect and how to collect them. The solution of the invention is to estimate the reward for supplying a given answer, and then report this reward to users who might be in a position to supply the answer. The estimate is based on how many people request the answer. Basically, the system tells users, "Hey, enter this answer and I project you will make x amount of money." Then, if the answer is supplied and used, those who used it are charged and the supplier is paid. This sequence can be viewed as a sort of economic feedback loop, and the system can be viewed as an economy where the products are answers. The point is not to summarize the original patent, but to say that it is a pioneer type patent that takes a sharp departure from previous approaches to data base system design.
The main goal of this patent was to describe the basic loop of this answer economy. The loop can be built upon. CIP 1 added new matter in three areas. First, it described a new feature for displaying the pay-off estimates of certain kinds of answers. Second, it described the collection of more information about the demand for an answer, particularly price information. Third, it described a form of the invention in which the system does not actually collect and output answers but collects and outputs information about the answers, including reference information telling where the answers can be found.
CIP 2 added more new matter, the most important being an interface and data storage procedure that lets people "talk" to the system in natural language.
CIP 3 added new matter including procedures for entering and displaying questions and answers, for registering demand for answers, and for granting property rights to users.
CIP 3 was also a rewrite of CIP 2 in order make the reading easier and better explain how the system could be adapted to collect and sell a wide variety of answers. In the rewrite several terms were changed in the interest of clarifying concepts. For example, in CIP 2 the term data request was often used for question. And the term data was often used for answer. CIP 3 kept more to the natural terms, question and answer. While the shift is semantic, rather than essential, there are reasons for avoiding the term data. Thinking about questions and answers is more natural than thinking about data-requests and data. We know a lot about questions and answers. We know that most questions are ambiguous. We know that some answers are permanent and some are not. We know that credibility counts. We know that people make mistakes when asking questions and giving answers. We know that many questions and answers are improvable. We know that the meaning of questions is subject to interpretation. We know that certain answers are mere suggestions while others are nearly certain facts. We know a lot more than this.
It's not a surprise that we know these things because questions and answers are what we use to communicate with each other and find out about the world. And so a system that lets us use these naturally can be a boon. That is what the invention is designed to do; it is an economic system that provides answers in response to questions. Thus, the change in terminology clarifies things and signifies a break from traditional data base systems which, of course, emphasize data.
While all the key methods and functions of the U.S. Pat. No. 5,359,508, CIP 1 and CIP 2 remain in CIP 3, large parts of the CIP 2 are copied in an appendix, for legal reasons of maintaining disclosure continuity for priority purposes. Some of the "additional functions" described in CIP 2 are superseded by functions in CIP 3. Most all remain but are improved or elaborated on.
CIP 4, takes up where CIP 3 left off, mainly by continuing to describe how the system can handle natural language.
This application, CIP 5, takes up where CIP 4 left off, adding new material about how the system can handle natural language (Chapter 26). It adds material concerning quality control (Chapter 13), translation (Chapters 15 and 27) and the pay-off meter (Chapters 9 and 25).
BRIEF SUMMARY OF THE INVENTION
The invention is an online system for collecting and selling answers. The system charges users who receive answers and pays users who supply those answers. The key to the system is a feedback mechanism, called the Pay-off Meter, that tells users what the estimated royalty value is for supplying a given answer. The Pay-off Meter keeps track of the rate of requests for an answer and from this rate projects an estimate of future sales of the answer if the answer is supplied. From this estimate of sales the Pay-off Meter calculates the projected royalties the answer will generate. Usually, the more requests in a period of time the greater the projected pay-off.
One crucial feature of the system is that the projected pay-off is shown to requestors of an answer. The beauty is that, if the answer is not in the system, a requestor may have to find the answer anyway elsewhere. To collect the pay-off, a requestor then has only to "call" the system back and input the answer. A sensitive feedback loop is created such that the more an answer is requested the more likely, on average, it will be supplied by a requestor or by someone a requestor tells of the pay-off. Moreover, this pay-off is an incentive to correct or update faulty answers.
BRIEF DESCRIPTION OF DRAWINGS
FIG. 1 shows a flow chart of the basic system.
FIG. 1a further shows a flow chart of the basic system.
FIG. 2a shows the flow chart of the Request Mode of a lowest price locator.
FIG. 2b shows the flow chart of the Supply Mode of a lowest price locator.
FIG. 3 shows part of a question display menu.
FIG. 4.10 shows a another view of a question display menu.
FIG. 4.11 shows a question location.
FIG. 4.12 shows a question location and question specifiers.
FIG. 4.13 shows form linked question locations.
FIG. 4.14 shows a Q+ leading to a question location.
FIG. 4.15 shows three question locations with the same missing answer.
FIG. 4.16 shows a question location with an actual answer.
FIG. 4.17 shows multiple Q-A-locations as part of a question location.
FIG. 4.18 shows a question location with a current and a past answer.
FIG. 4.19 shows two links between Q-A-locations.
FIG. 4.20 shows a link between Q-A-locations.
FIG. 4.21 shows multiple Q-A-locations for the same actual answer.
FIG. 5a shows a flow chart of steps for gathering of information on what users are willing to pay for given answers.
FIG. 5b shows another set of steps for gathering of information on what users are willing to pay for given answers.
FIG. 5c shows another set of steps for gathering of information on what users are willing to pay for given answers.
FIG. 5d shows another set of steps for gathering of information on what users are willing to pay for given answers.
FIG. 6 shows a flow chart of steps for a multi-lingual system.
FIG. 6a shows a flow chart of steps for registering requests for answers in specific languages.
FIG. 7 shows a basic menu for a system that includes More Specific Questions.
FIG. 8 shows another basic menu for a system that includes More Specific Questions.
FIGS. 9 and 9a show how a direct answer might be relabelled.
FIGS. 10-10b show a flow chart of steps for a system with More Specific Questions.
FIGS. 11 and 11a show additional steps for getting and entering More Specific Questions.
FIGS. 12-12d show diagrams of steps for creating question and answer nets using More Specific Questions.
FIG. 13 shows diagrams of basic steps for growing question networks.
FIG. 14 shows a diagram of the probabilities associated with semantic links.
FIG. 15 shows a match path in portion of a question network.
FIG. 16 shows three questions that can be traveled to from a fourth question.
FIG. 17 shows linked match choices for a question.
FIG. 18 shows a path for finding an actual answer in a question network.
FIG. 19 shows demand information in a question network.
FIG. 20 shows a part of a menu for making links between questions.
FIG. 21 shows a question network with economic aspects illustrated.
DETAILED DESCRIPTION OF THE INVENTION
Book Form, With Missing Chapters
This application is written in the form of three books. In order to adapt the invention to handle a wide variety of questions and answers, numerous features can be added to the basic system. These are conveniently explained in chapters.
Book I concerns the basic system and features that can be added to it. Book II concerns adapting the basic system to handle natural language questions and answers. The books are incomplete though. Many chapters are left unwritten. Others that are written can be expanded. Thus, while a table of contents is given, the reader will find several chapters missing.
Future continuing applications are planned that will expand both Books I and II. It should be noted that in many instances in Book I, we say things like, "as will be seen in Book II," or "this topic will be taken up in Book II." Often, those parts of Book II have yet to be written or expanded. We make these statements in this application because we intend to fill in those parts in a future application.
Book III concerns adapting the system to handle a variety of jobs.
Table of Contents
Introduction
Part I The Basic System
Chapter 1 Definitions of Necessary Functions
Chapter 2 Procedure and Physical Elements for a Basic AC
Part II Adapting the System to Collect and Sell a Wide Range of Answers
Chapter 3 Core Design Principles
Chapter 4 Questions and Answers in the Minds of People
Chapter 5 Questions and Answers in AC Chapter 6 Registering Demand Information
Chapter 7 Price Setting
Chapter 8 Registering People's Interest in Supplying Answers and Registering People's Rights to Supply Answers
Chapter 9 The Pay-off Meter
Chapter 10 Royalty Rules
Chapter 11 User Accounts (missing)
Chapter 12 Direct Mail
Chapter 13 Quality Control of Answers Through Labeling
Chapter 14 Property Rights
Chapter 15 Multi-lingual AC
Chapter 16 Form of the Invention
Book II Enabling the System to Accommodate Natural Language
Book III Enabling the System to Handle a Wide Range of jobs
Introduction
Goal of the Invention
The goal of the invention is straight out of science fiction. It is to make a computer system that will answer any question posed to it. Of course this goal will not be reached, but why not? What's the problem? Well, there are lots of problems. But is there a main problem?
Yes. The problem is, to find answers requires labor. One may pose a question fairly easily, but someone has to expend effort to find the answer.
Now certain questions may be meaningless, such as, Do blobs have livers?. Certain questions have answers that are not very suitable to put in a computer, such as, What does a hamburger taste like?. And certain questions may be impractical to answer, such as, How many grains of sand are there exactly on the Earth?. The universe of such questions seems far vaster than the universe of questions whose answers can be found and put into a computer. That is beside the point though. There is a great universe of questions whose answers are conveyable by computer, provided people can and want to make the effort to find those answers and then enter them.
Even the labor involved in entering answers can be a crucial obstacle. For example, there currently is no good, central, international directory of phone numbers or E-mail addresses. Why not? People know their own numbers and addresses. The information is simple. Why not enter it into some central data base? The cost seems small, yet it is enough to prevent the formation of just such a central directory.
And so, we see that the main thing stopping us from having our science fiction computer is the labor required to find (and sometimes enter) the answers.
How then do we get the answers in? In general, to get people to expend their labor, we must pay. So how does the system get answers in? Well, it pays for them.
But with an infinity of questions and answers, which answers does it pay for and how does it decide how much to pay?
Which Answers? That Depends on the Questions
The system is designed to store answers that users ask for. The way people ask for answers is by posing questions. So the process begins with questions not answers. Thus the invention is not just a system that stores answers and outputs them in response to questions, it is a system that stores the questions themselves. It might be called a question base, as well as an answer base.
When we say that the process begins with questions we mean that the first step to getting an answer into the system is for a user to enter the corresponding question. For example, a user might enter What is Leona's telephone number?. If the question has not been asked before, the question is stored. Presuming Leona's number is eventually entered, it will be stored to correspond to the question.
How Much to Pay?
Still, how much should the system pay for answers that have been requested?
Well, the payment offer must be economically sensible, meaning that the income that the answer generates should equal or exceed the amount paid to get the answer. In other words, the system should not pay more for an answer than it will receive from users who find that answer.
An Agent and a Market
But the system cannot know in advance how much will be paid for an answer and so the system does not actually buy answers. It lets users who provide the answers take the risk that the answers will be bought. Then it pays these suppliers royalties on actual sales. Thus the system acts as an agent and a market, but not as a middleman who buys an answer and then resells it. How much does the system pay then? It pays a share of sales.
Now the system can also act as an owner of answers. Once the supplier of an answer is paid off, the system may take ownership. And the system may also act as a trustee, putting an answer in the public domain. The system may or may not charge for answers in the public domain.
Projecting Sales, the Critical Thing
So the key idea is to try to find out how much buyers are willing to pay, in total, for a given answer. The system must try to project the total sales of an answer in order to give the supplier a realistic idea of how much he will get for supplying the answer.
Therefore, the critical thing the invention does is estimate the sales that an answer will have. The invention does not solve this problem perfectly but well enough to serve in a broad-number of cases. (As will be seen later, because of the difficulty of estimating sales, the invention may not necessarily give a sales estimate. It may only give demand information so users can estimate the sales themselves.)
Among other things, the invention registers how many users are interested in an answer, when they are interested, how much they are willing to pay, and other demand information. Then it converts this information into a projection of total sales. From this sales estimate the system can then estimate the reward, the royalties, a person will get for finding and entering the answer into the system.
We call this estimate the Pay-off Estimate (POE) because it signifies the pay-off for supplying an answer. The POE is a projection of income though, not a guaranteed offer. The system pays royalties on the actual income generated. For example, let's assume that 40 people a week request the Smithsonian's general information number and that that telephone number is not yet in the system. From this weekly tally of requests the system might estimate that there will be 2,000 requests a year, and the system outputs a POE based on that estimate. Then let's say a user supplies the telephone number and that the actual tally of requests is 2,500. Further let's say that the system charges 10 cents for the Smithsonian's number. Then the total income is $250 for the year. The supplier would get a share of that. But if by chance the Smithsonian's number changed immediately after the supplier entered it, the supplier would probably get nothing (the payment depends on the rules that apply).
We give the name Pay-off Meter to this machine implemented process that outputs a POE. We use the term "meter" because the process is like that of any meter. For example, a meter that measures electricity usage collects information about the flow of electricity through a line. Then, using mechanical or algorithmic means, it converts this information into a number. And then it displays the number. The number provides useful feedback about the electricity usage. Likewise, the Pay-off Meter collects information about an answer, converts this information into a number and, displays the number, which provides useful feedback about the answer. In this case, the number tells the projected reward for providing the answer.
A Crucial Trick
But who should the POE be shown to? The system cannot broadcast the POE to all users because most every one would be uninterested. Who then to show it to?
Here we come to another crucial trick of the invention. The system shows the reward to the requesters themselves of the given answer. Requestors have the greatest interest in finding the answer, and are often in the best position to find it or to tell others who may be able to find it. For example, if someone asks for a phone number that is not in the system, she would see (or hear) the POE for that phone number. As mentioned, to collect the pay-off, any requestor has only to "call" the system back and enter the answer.
To see the feedback loop created, pretend one users asks, What is the melting point of silver? and is willing to pay 5 cents for the answer. The system might announce a projected pay-off of, say, 4 cents for providing the answer. Given this small pay-off prospect, the answer may not be supplied. But if fifty people have the same question, each willing to pay a nickel, then the pay-off estimate may be, say, $2.00. Given this higher pay-off prospect the answer will probably have a higher chance of being supplied. (And might also, in general, cost less per person.)
Of course, this reasoning does not hold for all answers. For example, everyone on the planet may want to know how to cure all cancers and stop all wars, but that does not mean that there is a good chance that the answers will be provided.
In general, if people are willing to pay more in total than the cost of finding and entering an answer, then there is a reasonable chance that the answer will be found and entered. That's why the system can be called a self organizing data base.
It can also be considered a self-correcting data base in the sense that users are also rewarded for correcting, updating, adding to, and otherwise improving answers that are in the system.
The system is "Governed by a Pay-off Meter" in the sense that the system's essential feedback mechanism is the part that produces a pay-off estimate, the signal that tells which answers are worth finding and entering. The term governed is used because it is reminiscent of the Watt governor, the critical feedback mechanism of the Watt steam engine.
A New Name
In U.S. Pat. No. 5,359,508, and CIP's 1 & 2 the invention was called a Self Organizing Data Base and abbreviated as SODB and sometimes SOD. While that name is still apt, from here on the invention will be named AC instead. Why? Because it's easier to say than "SODB" and because it pays tribute to Isaac Asimov, who told the tale of AC, a computer that answered every question (in the story The Last Question).
The Range of the System?
What is the range of questions and answers that AC can accommodate? No one can say because questions are general tools for probing the world, both the real world and the world of abstractions. What is the range of the real and abstract world? It is too broad to understand, no less describe. All the inventor can say is that the system can be adapted to handle most of the types of questions we ask each other.
These types include questions that call for answers that are true, answers that are guesses, answers that contain probability estimates, answers that are suggestions, answers that are opinions, answers that require audio or visual information, answers that are a few characters long, answers that are volumes long, and so on. To give just a handful of examples, questions like: What is Lincoln's Birthday?, What is the best way to make a toll-house chocolate chip cookie?, What might be the directions to the nearest 7-11?, What is the best guess as to who will win the next Presidential election?, Who is the best candidate?, Was Joan of Arc framed?, What is the text of Moby Dick?, How do you change a tire, a video tutorial please?, How do you cure leukemia?, Why is the top quark so heavy?, What's a picture of an arterial plaque?, How about an atheroma?, What is the definition of entropy?.
Variety of Possible Features
These examples can only hint at the range of questions and answers we commonly use. To handle such a range, many problems need to be overcome. There is no single solution to these problems. And so the system can include numerous features for handling the wide variety of questions and answers that we deal with.
As an analogy, we can think of the wide variety of systems that people have come up with for selling products: from vegetable stands, to vending machines, to grocery stores, to department stores, to catalogues, to movie theaters, to travel agencies, to auction houses, to brokerages, to stock markets, and on and on. All these have certain essential elements in common: a product, two parties, and a payment. There is great variety because the variety of products is great. All kinds of agreements and descriptions of the products can be added to the selling situation, for example, advertising, product guarantees, deposits, anti-theft penalties, product reviews, package labeling and more, of course.
Likewise with answers as products. Because the variety of answers is great, a system for selling the answers can include a variety of different features. And so, the invention can be seen as a basic system that can have many options added to it, depending on the particular type of answers involved and the needs of users.
Menu and Sub-Menu Approach
We will describe numerous useful features that the invention can include. After the basic system is described, we will often show these options in a menu form, though given implementations of the system may not include an actual menu. We present them this way for clarity's sake, to show what the users can do, what the invention does for users, and how it does it. Which options a designer chooses to include in an actual implementation depends on the application. The variety is simply too great to say that there is a preferred embodiment.
For convenience, we show the options as they could, in a limited way, appear on a screen display (the illustrations are crude and are meant to get the key ideas across). We do not show voice input and output means, though we realize that these means are very useful. Some of the options disclosed are not suited to voice output.
The goal then is to describe the key steps and functions that the invention can include. Numerous modifications and adaptations will be apparent to those skilled in the art without departing from the spirit and scope of the present invention.
Notes on Style
The description will include colloquial expressions that, hopefully, will make the description clearer. AC will often be referred to anthropomorphically, though it is understood that AC is a computer system that must include computer based means for executing its tasks.
Thus, when we say, for instance, that AC does something, we mean that AC includes functions for performing that something. These functions are readily implementable by persons skilled in the art. When we say that AC asks the user to do something we mean that AC prompts the user in some way to enter information. When we say AC enables the user to do something, we mean that AC includes means for enabling to the user to do that something. Again, these means are readily implementable by persons skilled in the art. When we say the user does something, we also mean that AC includes functions for enabling the user to do that something. And so on and so forth. The essential parts of these means will be described, unless those parts are obvious to persons skilled in the art. The aim, of course, is to describe what is new.
Part I
The Basic System
Chapter 1
The Necessary Functions
Below are basic explanations of the functions that the system requires. By function we mean a set of steps that the system's computing means execute. Another term we will use for a set of steps is a procedure.
The explanations below are not comprehensive. They get the main ideas across but most concern subjects that can be delved into at length. Several of the subjects will be discussed in more detail as the need arises to show how AC can be adapted to collect and sell a wide variety of answers.
Some Definitions and Comments
Question: A set of information corresponding to another set of information called the answer.
Answer: A set of information corresponding to another set of information called the question.
Rules Concerning the Correspondence Between Questions and Answers: There really is no such thing as the correspondence. When we say correspondence we may be referring to many things, most of which we don't understand well, if at all. For our purposes right now, we will be referring briefly to two senses of the word. One, there is a correspondence between questions and answers inside AC. AC includes internal rules, embodied in functions, for storing answers to correspond to questions, for finding answers in response to questions and, for outputting answers in response to questions. Two, there is a correspondence in the minds of users. For AC to succeed, users must understand what is considered a satisfactory answer to a question and what answers can replace other answers. And so AC must have external meta-rules that define what answers satisfy questions. No set of rules, internal or external, will perfectly define what answer best satisfies a question, which means that disputes can arise. These can be mediated by a System Manager. (The correspondence rules for questions and answers are fundamental in designing given implementations of AC, therefore this issue is discussed further in several places in the description (see chapters 4 and 5).
Sub-Answer: Depending on the correspondence rules of a particular AC, the system may enable users to enter answers that can be called sub-answers in the sense that they are used in combination with other answers to form another answer. For example, if the question is, Who are the major steel producers in the US.?, different users may supply the names of different steelmakers and these sub-answers can be combined into a list of steelmakers.
Request: A question entered by a requester who wants to buy the corresponding answer. (Classifying requests can be tricky, see chapter 6.)
Answer-Use: When AC uses an answer, especially when AC charges for the use.
Classifying Questions and Answers: There are potentially infinite types of answers and answer uses. Presuming AC collects different types of answers and enables different types of answer-uses, it must distinguish between them for the purpose of registering demand information and charges and royalties. For example the use of .pi. may be given a different royalty value than the use of the date of Lincoln's birth or the use of a passage from Shakespeare. Moreover, the use of a sequence of .pi. in a formula may be classified differently than the answer to the question, What is the value of .pi. to ten decimal places?. The classification possibilities are infinite.
Request Mode: The procedure AC executes to register demand information for answers, and to provide answers and/or Pay-off estimates to users. A user selects Request Mode in order to find an answer or express interest in an answer. The user enters (or selects) a question. If the question is new, AC stores it. If the question is already in the system, entering it causes AC to search for the corresponding answer. If the answer is not found, a Pay-off Estimate is outputted. If the answer is found, the answer is outputted along with the Pay-off estimate and a Charge is registered to the user. (Depending on the implementation of the system, the user may have to confirm that he wants an answer before AC outputs it.) Whether the answer is in AC or not, AC registers demand information about the answer.
Supply Mode: The procedure AC executes to allow users to enter answers. User identification data is registered along with an answer so that the user can be credited with royalties each time the answer is used. Most simply, in supply mode a user enters (or selects) a question and AC then enables the user to enter a corresponding answer. If the question itself is new to the system, AC first stores the question.
(Note: the term mode is used as a convenient way to describe separate paths of steps. It is not meant to have any special, technical connotations beyond that. The system can enable users to switch easily between modes, with a single command.)
Requestor: User who accesses request mode seeking an answer. The requestor normally owes a charge if the answer is found and outputted.
Supplier: User who accesses supply mode to enter an answer. The supplier gets paid a royalty each time the answer is used as determined by the royalty rules of AC.
User Record: The user record is where AC stores various information about a user, including at minimum, payment information. AC can store a wide variety of information about a user's use of the system.
Charge: The amount owed by a requestor who receives an answer from AC.
Charge Rules: The rules, embodied in functions, that determine the amount an answer will cost a requester.
Royalty: The amount owed to a supplier of an answer for the use of the answer.
Royalty Rules: The rules, embodied in functions, that determine the amount due to a supplier of an answer each time that answer is used (either outputted to a requester or processed to yield another answer).
Payments Register: The function AC executes to register payments owed by requesters and payments due suppliers. When an answer is outputted, AC registers who is owed a royalty and who owes a charge. The payments due depend on the charge and royalty rules of AC. The point of the register is not that it is a distinct storage entity necessarily but that the system must have steps for registering charges and royalties. Payment records can be kept in user account files and in the Demand Record for an answer, as well as in a credit record for an answer. AC also has it own account where the system's books are kept.
Pay-off Meter (POM): The POM is the function that is the heart of AC. The POM has three aspects: Demand Records, the Pay-off Formula and the Input Signal.
1) Demand Records (D-record). A D-record is kept for each answer in AC. The D-Record, as the name implies, is where AC stores demand information about the answer. The information in the D-Record can be quite varied. At the least, a D-record will store the number of requests for an answer, the times of those requests, and the actual sales, if any, of the answer. Because an answer often will not be in AC, the D-record for an answer actually corresponds to a question. The question then corresponds to the given answer. So demand information about an answer is actually stored under the question that corresponds to the answer. (If an answer answers multiple questions, there can be a different D-record for each question.) The D-record can thus be looked at as the D-record for a question. The process of collecting demand information under a question may seem straightforward. What is not necessarily straightforward, is what answer corresponds to the question.
2) The Pay-off Formula (POF). The information in the D-record for an answer is plugged into the POF for that answer. The POF calculates a Pay-off Estimate (POE) of the income a user will get for entering the answer. The POF can be highly varied.
3) Input Signal (I-Signal). The I-Signal is a name for the step(s) of outputting the POE and, if necessary, outputting instructions on how to enter an answer.
The POM works most simply when AC's answers are stored under questions and AC can find the answers by simple lookup. For example, a requestor may enter the question, What is Lincoln's date of birth?. AC will do a lookup. If the question is not in AC, AC will store it and create a D-record for it. Initially, the answer will not be in AC. Each time the question is entered, AC will register the request in the D-record for that question. AC will also register the time of each request so that the rate of requests over time can be calculated. This demand information will be fed into the POF to yield the POE. The I-Signal can output this POE to every requestor. Since answers are listed under questions, the I-Signal need not tell what answer needs inputting nor how to input it. It is assumed that requesters implicitly know that to enter an answer they simply access Supply Mode, enter the question, and then enter the answer. Once the answer is entered, AC continues to collect demand information in the D-record because the answer may need correcting or improving. The POM thus also provides requesters with the POE for correcting the answer.
Aspects of the POM functions are discussed a little more below.
Demand Record. As mentioned, the D-record for an answer is stored under the question that corresponds to that answer. However, since the correspondence between questions and answers is often unclear and unpredictable, the answer that the D-record applies to may be unclear. Thus, as mentioned, AC will include rules for dealing with the relationship between questions and answers, in order to make the demand information more reliable. We will give a short example to illustrate the trickiness of questions and answers.
Assume the question entered by a requestor is, What store has the lowest price on Sony Camcorder #1239?. Say there are 1,000 requests. Now it may be that ten stores have the same lowest price. What then is the demand for the name of a given store? That depends on how AC classifies the answer. AC will have default assumptions built into it to limit the size and number of answers outputted. For example, AC may have a rule that only the first store with the lowest price can be outputted as the answer. This store becomes the answer and all royalties go to the supplier of this store's name. Therefore, all other stores, even though they have the same lowest price are only potential answers (the first store may change its price so that another store takes its place).
On the other hand, AC can have a rule, for example, that all stores with the same price are equally part of the answer so the answer then has ten components. The demand rate for the store with the lowest price can then, for example, be divided by the number of components to arrive at a demand rate for each component.
And so the information in the D-record applies to the answers that the system outputs and charges for, but that in turn depends on the internal and external correspondence rules of the system.
These issues will be discussed in various parts of the description, especially in chapters 4 and 5 and in various chapters of Book II.
(Note: CIP 1 used the term "Demand Meter" to name the parts of the POM that keep track of demand information and calculate a "demand rate." Here we use the term demand record to name the part where demand information is stored. As for the part that calculates a demand rate, we now incorporate that into the POF.)
Pay-off Formula (POF). The POF is the function that calculates a Pay-off Estimate (POE) for a given answer. The POF projects future sales for an answer based on the demand it has had in the past. Thus two variables are critical: the number of times the answer has been requested and, the times those requests took place. Based on the rate of requests for an answer the POF estimates how many future requests the answer will have. The POF factors in the price of the answer and the royalty rate to arrive at the POE. There are, of course, many other factors that can be used as well.
Like any equation for a projection, the Pay-off formula can be infinitely diverse based on historical data and other factors. For example, the formula could include a historically based assumption of when demand for an answer would end. The POF may contain estimates based on answers that are similar to a given answer. Also, the POF must have an arbitrary value for the POE when an answer has been requested zero times or one time. This value could be an amount or simply a message, "You are the first to ask this question."
There will be multiple POF's applied to different types of answers. There may even be multiple POF's for a single answer. These could give different types of POE's, for example a conservative POE or an optimistic POE.
Not only can the POF be infinitely variable but the information it yields can be of different types. Ideally the POF would yield a reliable cash POE. But that is not always practical for given answers. And so the POF might only process information in the D-record to come up with information that can help users arrive at their own POE's. In given AC's, the POF may allow users to manipulate different factors, such as the price of an answer, in order to arrive at a POE.
I-Signal. The I-signal is the function that is the output part of the POM, the signal that tells requesters what answer is needed, what the value is of supplying it and how to supply it. When a requester requests an answer not in AC, AC outputs the POE. When a requestor requests an answer that is in AC, AC outputs the answer and the POE for correcting, updating or improving it. (The POE may be outputted only upon request rather than automatically). Usually, the answer needed is implicit from the question asked, though special input rules or restrictions may apply that the user is not aware of.
The I-Signal can include many other features for giving users POE information. For example, the I-Signal may include an alert function whereby a user can "ask" to be told if the POE for an answer rises above a threshold amount. The I-Signal can then send an alert to the user's E-mailbox if the threshold is exceeded.
Chapter 2
The Elements and Procedure for a Basic AC
AC Hardware Elements
AC is an online network of computers with terminals that feed into a central computing unit that stores and processes questions, answers and other information of the kind described above. When we say "central computing unit" we mean that users communicate with the same body of data, though that data may be physically located in different places. The terminals can be a variety of types from telephones to supercomputers. The network includes E-mailboxes for users.
AC Procedure
FIGS. 1 and 1a show the procedure that a basic AC follows, as explained below.
Start
User enters identification data, AC stores it 1.
User enter supply or request command 2, AC accesses the appropriate mode.
Request Mode
Requestor enters a question, AC
inputs 3 the question and
checks 4 if the question is already in memory,
If the question is not in memory, AC
stores 5 the question,
creates 6 a demand record for the question,
sets 7 the request tally in the demand record to one and,
registers 7 the time of the request in the demand record,
calculates 8 the POE using the POF,
outputs 9 the POE.
If the question is in memory, AC
adds 10 one to the request tally,
registers 10 the time of the request in the demand record,
checks 11 if the corresponding answer is in memory,
If the answer is in memory, AC
outputs 12 the answer,
registers 13 a payment due by the requester,
registers 13 a royalty due to the supplier,
calculates the POE using the POF,
outputs the POE.
If the answer is not in memory, AC
outputs 14 a message saying the answer is not in the system,
calculates the POE using the POF,
outputs the POE.
Supply Mode
Supplier enters a question, AC
inputs 15 the question,
checks 16 if the question is already in memory,
If the question is not in memory, AC
stores 17 the question,
creates 18 a demand record for the question,
inputs 19 the answer,
stores 20 the answer to correspond to the question,
stores 21 the supplier's ID data with the answer, in order to credit royalties.
If the question is in memory, AC
checks 22 whether the corresponding answer is in memory,
If the answer is not in memory, AC
inputs 19 the answer,
stores 20 the answer to correspond to the question,
stores 21 the supplier's ID data with the answer, in order to credit royalties.
If the answer is in memory, AC
outputs 23 a message saying the answer is already in the system,
If the supplier enters a command 24 to correct the answer, AC inputs 25 the supplier's answer,
replaces 26 the current answer with the supplier's answer,
stores 27 the supplier's ID data with the new answer, in order to credit royalties,
stores 28 the replaced answer, along with information stored specifically for that answer, in a record for past answers to the question.
This procedure is the basic loop of AC. AC can include many other useful sets of steps (functions). Before describing some of them, an embodiment is described, a self-filling telephone directory (the SFTD). Then an embodiment is described that does more than just look up answers under questions.
A Self-Filling Telephone Directory
1. The SFTD includes a list of names and corresponding telephone numbers, a computer for storing the list and functions for inputting information into the list, outputting information from the list and looking up information in the list.
2. The SFTD also has a sign-on function that allows users to identify themselves for billing and payment purposes. The SFTD stores this ID data.
3. Users access the SFTD by terminal connected to the SFTD central computer. The SFTD enables users to choose Request mode or Supply Mode.
Request Mode
4. Using the Request mode, a requestor accesses the SFTD list by entering a name (a question). The SFTD inputs the question and the does a lookup to see if it has a telephone number corresponding to the name.
5. If the SFTD has a number corresponding to the name, it outputs the number and registers the charge due by the requestor and the royalty due to the supplier. One is added to the POM tally of requests, the time of the request is registered, and a new POE is calculated and outputted along with the number.
6. If the SFTD does not have a number corresponding to the name, it:
a) it registers the time of the request,
b) it checks if the request has already been stored in the POM register,
b1) if not, it sets the request tally to 1, stores the request and defaults the POE to the message"Insufficient Data to Estimate Pay-off,"
b2) if the request is already stored, the POM advances the request tally by one and then calculates the POE using the POF,
c) outputs the POE.
Supply Mode
7. Using the Supply Mode, a supplier accesses the SFTD list by entering a name (a question). The SFTD does a lookup to see if the name is in the list.
8. If the name is not in the list, the SFTD stores it in the list and then allows the supplier to enter the number. The SFTD stores the number to correspond to the name and stores the supplier's ID data along with the number in order to credit royalties.
9. If the name is in the list, the SFTD does a lookup to see if there is a corresponding telephone number. If there is no corresponding number, the SFTD stores it in the list and then allows the supplier to enter the number and stores the Supplier's ID data along with the number in order to credit royalties.
9. If there is a corresponding number already in the list, the SFTD outputs a message, "Number is already in directory." If the number needs correcting, the supplier then enters the command, CORRECT. The SFTD then allows the supplier to enter the number. The SFTD stores the number to correspond to the question, to the name that is, and also stores the supplier's ID data with the number, in order to credit royalties. The SFTD also stores the previous number and previous supplier ID data in a record of past numbers.
A Lowest Price Locator
Let us look at another embodiment, a lowest price locator, as shown in FIGS. 2-2a.
1. A lowest price locator (LPL) is an AC that includes a central computer for storing a list of product names (questions) and merchants and prices (answers). An LPL includes a network of terminals from which users can enter questions and answers. The central computer includes functions for creating price lists, looking up answers in the list and processing answers in the list and, outputting answers from the list.
2. The LPL has a sign-on function 30 and a Request and Supply mode.
Request Mode
3. Using the Request mode, a requester enters a product name. The LPL inputs 31 the question and checks 32 to see if the question is already stored.
If the question is not stored, LPL
stores 33 it,
creates 34 a demand record for it,
sets 35 the number of requests to one,
registers 35 the time of the request,
calculates 36 the POE (which in this case would normally result in a message such as, "You are the first person to ask for a price on this product") and,
outputs 37 the POE.
If the question is stored, LPL
adds 38 one to the number of request,
registers 38 the time of the request and
checks 39 to see if the corresponding price is in memory.
If there is no price in memory, LPL outputs 40 "No Prices Found", and calculates and outputs the POE.
If there is a list of prices and merchants under the product name, LPL checks 41 for the lowest price.
If more than one merchant has the same lowest price, LPL finds 42 the merchant whose lowest price was entered first and outputs 43 that merchant's name and the price.
If there is only one lowest price, LPL outputs 43 the name of the single lowest priced merchant and the price.
LPL then registers 44 the charge owed by the requestor and the royalty owed the supplier. It then calculates and outputs the POE.
Supply Mode
4. Using Supply Mode, a supplier enters a product name (question) into the LPL. The LPL inputs 50 the question and checks 51 to see if the question is already stored.
5. If the question is not stored, LPL
stores 52 it,
creates 53 a demand record for it,
creates 54 a price list for the product,
enables the supplier to enter a mer chant and price (answer) into the list,
inputs 55 the answer,
stores 56 the answer in the list to correspond to the question,
stores 57 the time the answer is entered and
stores 58 the supplier's ID data in order to credit royalties.
6. If the question is already stored, LPL
enables the supplier to enter a merchant and price (answer) into the list,
inputs the answer,
checks 59 to see if the merchant entered matches any merchant in the list,
If the merchant does not match any merchants in the list, LPL
stores 56 the merchant and price in the list,
stores 57 the time the price is entered,
and stores 58 the supplier's ID data along with the answer in order to credit royalties.
If the merchant does match a merchant in the list, LPL
checks 60 to see if the price entered is the same as the existing price,
if the price is the same, outputs 61 a message that the price has already been entered,
if the price is different, puts the supplier's price in the list in place 62 of the price stored with the matching merchant,
stores 63 the time the price is entered,
and stores 64 the supplier's ID data along with the answer in order to credit royalties,
stores 65 the displaced price, along with other information stored specifically for that price, in a record for past prices.
The Option of Having an Answer Delivered When it Comes In
Rather than have a user constantly checking AC to find out if an answer is in the system, AC can enable the user to "place an order" in the sense that if an answer is not in the system, it can be delivered when it arrives. A simple way is sending the answer to the user's E-mailbox, though there are other places the message can be posted. However, since the requestor is paying for an answer, it is usually better to send a message alerting the user that the answer is in and asking him if he still wants it. If the requestor responds "yes" then the answer is sent and a charge and royalty are registered. As will be seen in chapter 6, a user can place various types of orders, involving various commitments.
As will be seen, many different types of messages can be sent to a user's E-mail box.
Part II
Adapting the System to Collect and Sell a Wide Range of Answers
In part II we describe ways that AC, as seen in part I, can be adapted to collect and sell a wide range of answers. Core principles that guide the design of any adaptation are laid out in chapter 3. In saying that the system is made to collect answers we do not forget questions, for no answer can be collected without a corresponding question being asked, and stored, first. Answers must correspond to questions in AC. Before discussing this issue, we discuss, in chapter 4, how questions and answers correspond to each other in the minds of people. We need to do this to see the problems involved in trying to create a workable correspondence in AC. Then in chapter 5, we describe basic ways that questions and answers can correspond to each other in AC.
In chapters 6 through 18, we elaborate on the Pay-off Meter and other functions described in Part I, showing how these functions can be adapted to suit a variety of questions and answers. We also introduce new functions, such as those for setting prices and for registering people's interest in supplying answers.
However, we wait until Book II to describe how the system can be adapted to handle the kinds of questions we normally ask each other, questions in everyday language that is. The functions described in book I are necessary for building a system that can accommodate a wide range of answers, but these functions are not sufficient for building a system that allows users to ask natural language questions.
Lands of AC
AC can be a big system with various ways of handling questions and answers. The system can have numerous sub-AC's where different rules and functions apply. We call these sub-AC's lands. For example, one land might be a lowest price locator where questions and answers are entered in a strictly defined form. Another land might be an encyclopedia where all answers are under 100 words long and cost five cents. Another land might be a photo album where all the answers are photos. The point is, AC does not necessarily have one set of rules that applies to all questions and answers in the system.
Most Rules are Inherently Variable
Throughout the description we will be discussing numerous kinds of rules that AC requires. Most of these are highly variable. For example, AC requires royalty rules, and these can, of course, vary widely. AC's rules determine what kind of functions and formulas AC has, so these in turn can vary. As another example, formulas for calculating royalties and functions for registering royalties can vary depending on the royalty rules.
Evolution of Rules and Formulas
While AC requires various kinds of rules and formulas, their specific forms cannot be given satisfactorily. Not only are the specific forms design decisions, but no designer can tell what is best in advance. He or she can only guess.
However, a system designer can set concrete goals for the rules and formulas and can conduct tests. The pay-off formula provides the best example because it has the clearest goal: to provide accurate projections of royalty income. Thus a designer can test to see how accurate a given formula is over a series of answers. There will be numerous pay-off formulas designed for different circumstances, and there will be numerous kinds of statistics that can be developed about user behavior. All these can be tested against the goal of accurate projections. Thus the formulas can evolve.
AC's matching rules are another example. AC matches questions that users enter with questions already in AC. Users confirm whether the matches are satisfactory or not. Thus, designers can strive to increase the rate of satisfactory matches.
Rules for property rights provide another key example. The goals here are vague though, and so designers must choose what to test for. Despite the vagueness, devising measures and tests is possible and thus, rules for property rights can evolve as well. In fact this testing is the only alternative concerning most rules and formulas, because situations are diverse and experience is scant.
It is also possible to do auto-variation, in the spirit of genetic algorithms, where AC itself makes variations in the formulas. Because AC can become quite large, there can be enough answers and enough time to conduct such tests.
Thus when we say that AC's rules and formulas are variable we mean it in two senses: one, designers can come up with different rules that suit different situations; and two, designers usually cannot come up with the best rules and formulas but must test their guesses and let the rules and formulas evolve.
Testing Device, a Laboratory
Not well appreciated is the great need for a device that enables people to test the effects of rules on the economy.
AC is both a device and a real economy. As such, it provides means for testing rules under real conditions in a variety of circumstances. Rules tested in AC can then be tried in the larger economy. And so AC can also be thought of as a testing apparatus, an economic laboratory.
For example, it allows us to test property rights. Property rights, including royalty rules, are feasible to test because an experimenter can see various effects of changing property rights. These effects can range from whether answers are provided or not, to the speed with which answers are provided, to the price of answers, to the number of people who have tried to supply answers, and more.
Further Notes on Style
For convenience, we will often use Rex to represent a requestor and Sue to represent a supplier.
Also for convenience, example questions are usually kept short, though in practice questions can be quite long.
When we say that AC includes a given option, we also mean that AC includes the necessary functions for carrying out the purpose of the option.
When we say "enter a command," we mean that the user activates an option. And when we say AC "includes a command," we usually mean that it includes the corresponding option.
"Question" will often be abbreviated as "Q" when it is preceded by certain names, for example, a "Current-Q."
Chapter 3
Core Design Principles
Before describing various ways questions and answers can correspond to each other in AC and various types of functions that can be added to the basic system, we will first step back and describe eight core principles that guide the design of any AC.
Principle 1
AC is a Marketplace for Answers and Potential Answers
AC is a medium that enables people to ask for and offer to pay for answers. It is a medium that enables people to supply those answers. It is a medium that enables people to find and pay for answers that have been supplied. It is a medium that pays suppliers of answers a percentage of the sales of those answers. In other words, it is a marketplace for answers.
It is more than a conventional marketplace though because it enables people to offer to pay for answers that do not yet exist in the marketplace. And it enables people to evaluate whether providing these answers will pay enough to be profitable. Thus it is also a marketplace for potential answers.
Principle 2
The Organizing Goal is to Make Good Sales Forecasts
Every AC will have the same organizing goal in the sense that the success of the system depends on the goal being achieved and in the sense that many of the system's functions are designed to achieve the goal. The goal is to give the user a good guess as to the income she will receive for supplying a given answer. Another way of putting it is that the goal is to arrive at a good guess of the total sales that an answer will have once the answer is in the system. From these sales the supplier's share (the POE) is easily calculated according to the royalty rules. The royalty rules may be complicated, but generally the calculation is simple and the real task is to come up with a good sales estimate from which the royalty estimate is taken. So the organizing goal is to arrive at good sales forecasts for answers.
Principle 3
The Foundation Task is to Count How Many People Want an Answer
The goal of good sales forecasts leads to what we might call the foundation task of the system. The foundation task is to count all the people who want to buy a given answer. (These people include those who actually do buy.) It is from this count that AC builds an estimate of the future sales of that answer.
There are, of course, many other variables that are critical to making a sales estimate. For example, the prices at which people are willing to buy are key. Nevertheless, functions for gathering information on other sales variables are not central to the design of AC. By contrast, many of the key functions and rules of AC are designed for counting how many people want given answers.
Counting how many people want an answer is tricky for many reasons and can lead to a variety of different features being included in the system. Above all, counting is tricky because identifying which answers are wanted is tricky. This trickiness will be discussed later.
For now let's point out one problem that is not about identifying answers. The problem is that people must offer to buy an answer at some particular time. Different people will make offers at different times. So when we say that AC must count how many people want an answer that is misleading, for the count can only be based on past offers; there is no such thing as counting exactly how many people want an answer in the present or future. That is just one limitation of any effort to forecast sales.
Principle 4
Questions Identify and Represent Answers
In order to count how many people want an answer, the answer must be identified. Actually, answers have to be identified for more reasons than that. Having emphasized the pay-off estimate aspect of AC, let us not forget that AC is a system where people request answers, find answers and supply answers. To do all these things the answers must be identified. The way answers are identified is with questions.
We don't normally think of questions that way. If we think about the matter at all, we think of questions as "asking" for answers. But asking for an answer means describing, identifying the answer. With questions we can ask for (identify) a great range of answers: facts, guesses, predictions, solutions, inventions, explanations, suggestions, treatises, opinions, critiques, and on and on.
Because they are how we identify answers, questions are central to how AC works:
People identify the answer they want by entering a question.
People identify the answer they have supplied by entering a question.
AC identifies where an answer is with a question. (This means that a person can find an answer by entering a corresponding question.)
And AC identifies which answers people want according to what questions people enter. (This means that AC collects information about an answer under the corresponding question.)
Of course the way humans use questions is different from the way AC uses questions, and that can be confusing. For humans, a question is a statement in human language that describes an answer. For AC, a question is a question string, a set of search parameters, and instructions for finding an answer.
Once a question is entered into AC and stored, AC creates a question record (Q-record). AC registers various information in this record that it gathers from users who enter the question. This information is about the answer that the question corresponds to. The question record can contain many sub-records, the most important of these being the demand record.
Thus the question identifies not only an answer but also information that describes the answer. In other words, AC uses a question string to create a location in memory for information about the answer.
We might say that a question represents an answer because this term gets the plan across. If no answer has been supplied, the question represents what we call a potential answer or a missing answer.
(That does not mean that there is only one possible answer. We can use the plurals, potential answers and missing answers. Singular or plural in this case is really a matter of taste, for there is no good existing term for the idea of a potential answer.)
If an answer has been supplied, we call the answer an actual answer. If there is an actual answer, the question represents that answer and any potential improvements or changes in the answer. So even if there is an actual answer, the question still represents potential answers.
(Now, if more than one answer in AC is identified directly by a question, the answers need to be distinguished. They can be distinguished by information that is distinct to each of them. Thus, each actual answer will have a separate record that includes information unique to that answer. We call such a record a Q-A record because it is identified by the question and by information about an actual answer.)
If more than one question corresponds to an answer, AC collects information in each Q-record and can combine that information.
If more than one answer corresponds to a question, the information in the Q-record can apply to the multiple answers. The principle remains; questions are used to represent answers.
In AC, as perhaps in reality, there is no such thing as an answer without a question.
Principle 5
Question String Information Can be Conveniently Split Into Two Kinds
As discussed above, a question string (Q-string) represents and describes an answer. It is what a requestor enters to describe the answer he wants, and what a supplier enters to describe the answer she provides. An example is: What's the treatment for first degree burns?
While questions are, on average, shorter than answers, they can vary considerably in length. A Q-string can be anywhere from as short as a name to as long as a book. Naturally, few questions will be that long but common questions often do involve paragraphs of description when people describe situations in detail. For example, a requestor who has just been burned might ask,
What's the treatment for a first degree burn when you've been burned with water coming out of an espresso machine and the burn is on the back of your hand and you don't have any bandages around and you're not sure how hot the water was and you see a blister starting to form and the blister is about a quarter the size of a dime and it hurts like hell and it's been five minutes since you were burned . . . .
Two Kinds of Question String Information
AC can divide question string information into two kinds called the main question string (main string) and the question specifiers (Q-specs). Q-specs are not mandatory and in certain lands of AC there may be no such thing as Q-specs, only main strings. Usually, when we say question string or question we will mean the combination of these two kinds of information. However, if there are no Q-specs, then a question simply refers to the main string.
Question Specifiers (Q-Specs)
AC can enable both requesters and suppliers to enter question specifiers. Specifiers can be thought of as standard adjectives that modify the main string and thereby further describe an answer. They are part of the overall question string but are distinguished from the main string. They are distinct entities in memory in the sense that they are part of the question string but have their own place in memory, as does the main string. There are a few reasons for separating Q-specs.
First, it is helpful to have a set of standard specifiers that can be used separately from the main string. For example, a user may enter the main string, A Biography of Hans Bethe?. The user may then specify, under 500 words. Thus the user can fiddle with the main question by adding and subtracting specifiers.
Second, specifiers contain standard information that can apply to wide ranges of main questions. For example, the length of an answer is a standard specifier. By contrast, the information in the main strings can vary tremendously.
Third, specifiers really are like adjectives. Without the subject, the main string, they are practically meaningless. A person can ask to see a sleek plane but a person cannot ask to see a sleek. Likewise, a person can ask for A Biography of Hans Bethe?, but cannot ask for under 500 words.
AC can enable users to create their own standard specifiers. Below is a partial list of the key Q-specs AC can enable users to enter:
Type of Question. AC can include certain basic types of questions. These direct AC to do different things. They are described in chapter 5.
Land of the Question. As noted, AC can have numerous sub-parts which we call lands. Each land has different characteristics in the sense that the questions and answers conform to certain rules.
Subject. An answer might be about a certain subject area and this can be specified in advance. For example, the employees of a company might ask various questions having to do with the company. All these questions can be specified by the name of the company.
Place. An answer might be about a certain "local" situation, and so a location specifier can be useful. For example, a question might be about a particular traffic jam, which can be specified by a given location. However, the idea of location is broader than just geography; it is the general idea of place.
Time. A user may specify various time aspects of an answer. For example, the time that a question is asked might matter. For instance, the time that a question about a traffic jam is entered can be key. Likewise, the time of the answer is found can be key. Obviously, time, like place, is a fundamental specifier.
Format of the Answer. A user may specify the format of an answer: text, audio, video or multi-media.
Length of the Answer. A user may specify the length of an answer by word count or by time.
Price of the Answer. A user may specify the price category of an answer.
Language of the Answer. A user may specify the original language of an answer.
The Supplier of the Answer. A user may specify the supplier of an answer.
The Source(s) of the Answer. A user may specify the source(s) of an answer.
Quality. A user may specify certain quality aspects of an answer. This is discussed in chapter 13 on quality control.
It is important to note that the main string might specify all these things. Standard specifiers are not mandatory; they are just a useful feature.
Principle 6
AC Can Collect, Process and Display Lots of Information About Answers
We don't normally think of an answer as a product, like a TV, yet in AC that is what an answer is from the point of view of requestors. We don't normally think of an answer as an investment, an income producing property, like an office building, yet in AC that is what an answer is, from the point of view of suppliers.
Thus AC collects, processes and displays all kinds of product and investment information about an answer. This includes information about demand, projected income, price, quality, property rights, supplier competition, alternative answers, and more. In each of these broad areas, AC can collect lots of specific pieces of information. For example, in the area of the quality of an answer, AC can register the primary source of the answer, probability estimates of the answer being true, reviews of the answer, and more. What and how much information is registered, processed and displayed depends on the answer and can vary.
We will call all the information that is registered question information (Q-info). And we will call the information that AC displays about the answer, answer statistics (A-stats). AC uses the Q-info to come up with A-stats. In some cases the information will be the same in the sense that AC will not process a given piece of Q-info but just display it as an A-stats. The Q-info is normally stored in the Q-record.
Now it may seem strange that the information registered is called question information when it is supposed to be about an answer. However, this term is reasonable for several reasons.
One, the information is registered under a question. Some of it is registered automatically when a user enters a question string. The rest is registered "at" the question. By that we mean that after the user enters a Q-string, AC presents the user with a display, which we call the question display (Q-display). The Q-display shows the question and includes a menu of options that the user can select from in order to enter and see various kinds of information about the answer that the question represents. This information is entered into and gotten from the Q-record. An illustration of a Q-display is given in FIG. 3 (though it should be noted that this figure is incomplete, and is intended only to show some of the key kinds of options that the Q-display includes).
Two, since the question string represents the answer, the information stored in the question record can be considered to be about the question string and about the actual answer or missing answer.
Three, it is often not clear what answer the question string refers to, or represents. And so, the Q-info might apply to many answers. Thus it really is Q-info that then corresponds in some way to one or more potential answers. As a consequence, Q-records (which contain the Q-info) can exist without ever corresponding directly to an actual answer.
Answer Statistics (A-Stats)
We call the information that AC shows about an answer by the name A-stats to get across the idea of AC processing and keeping track of a variety of useful information about an answer, the answer's "vital statistics." Not all the stats are numerical; many are qualitative. For example, AC can store and show an abstract of an answer and a sample of an answer. As another example, AC can store and show who has rights to supply an answer and for how long.
Much of the rest of this patent specification will be spent describing functions and options that AC can include for gathering, processing and displaying various kinds of Q-info and A-stats. Below we give a partial list of some of the key kinds of A-stats that AC can create from the Q-info. Many of these kinds are discussed in depth in the chapters ahead because they are subjects in and of themselves.
The POE (and related demand information).
Whether the answer is in the system or not.
Who the supplier is.
The price of the answer.
The original language of the answer.
The date and time the answer was entered.
The length of the answer.
The format of the answer (text, audio, graphics, video, multi-media).
Peoples' interest in supplying the answer.
Property rights concerning the answer.
The popularity of the answer (more demand information).
Quality information about the answer.
How users found the answer.
History of past answers.
Key words of the answer.
The Difference Between Q-Specs and A-Stats
As the list above shows, Q-specs and A-stats are categories that include some of the same kinds of information. The length, price, and format of an answer, to name a few, can all be Q-spec information and A-stats information. But that does not mean that Q-strings and A-stats are the same things. While they both describe an answer, the difference is how the information is used by AC.
AC uses the Q-string to create a memory location, a question record, where answer statistics belong. The Q-string represents the answer and that is why the A-stats are stored in the Q-record. A main string is like a baseball player's name, while a Q-spec is like the player's team, and a set of A-stats are like the player's stats. This is not a perfect example because a player's team might change, but it gets the idea across. A-stats can be used to differentiate question records and answers in memory. But they are not used to create a question that then has a question record.
At a question display, AC may show Q-specs and A-stats that have the same kind of information. For example, say a question string is: What's treatment for a first degree burn?. And say a Q-spec is under 500 words. Now, say an answer is supplied, and say it is 408 words. AC can register the length and then show the A-stats of 408 words. If the answer is later changed, this A-stats might change.
Most A-stats are created by the collective actions of users entering information and are compiled by AC. Most A-stats can change whereas Q-string information basically cannot. Whether an answer is in the system or not, the A-stats tell the current story of the answer. This story changes as new information about the answer is registered. For example, the POE is an A-stats that can change with each request.
Sometimes the dividing line between Q-string information and A-stats information is not clear. That's because both kinds of information describe an answer and can be used to differentiate an answer in memory. Whether a user chooses to enter the information as Q-spec or A-stats or both depends on the user and the choices AC gives with the particular question.
The key litmus test is this:
Users enter Q-string information in the expectation that other users can supply an answer that will match the Q-string conditions, that will fit the question.
Users enter A-stats information to describe an answer but they do not expect other users to supply an answer that will fit the A-stats conditions.
Operationally this means that AC enables users to enter Q-string information through different input forms than A-stats information. Users are expected to know the difference. AC then uses the Q-string information to create questions and Q-records. AC puts the A-stats information in the Q-records.
Principle 7
A Question is a Location Where AC and Users Do Business
A question identifies an answer but is it more than that in AC. It is a location in AC's memory that users (with AC's help, of course) create. The first time a given question string is entered into AC, it is stored.
Once that happens, all kinds of other information can be attached to the string, as described above. And so, AC creates a location made up of a Q-string and Q-record.
And once the question is stored, other users can "go to" that question, go to the location created by the question string and Q-record that is.
In other words, a question string is a location. And it is a place where users and AC interact, where users can see and find and enter information that corresponds to the string. Thus the actions of users and of AC revolve around questions. That's because questions represent answers, which is what people are looking to buy and looking to supply.
We are going to elaborate on this idea of a location. As we extend the idea we are no longer thinking just of a Q-string but of the Q-string and Q-record and Q-display. We are thinking of all the A-stats that AC might display along with the main string and of all the options that AC can present to users for entering and getting information, and for buying and supplying answers. In other words, we are thinking of a question as a location in AC where users and AC can do business.
FIG. 3 gives an illustration of the Q-display with a menu of options for: entering questions 70, selecting questions 74, entering A-stats 72, seeing A-stats 73, buying answers 75, and supplying answers 76. The figure is abbreviated for it does not show all the options the Q-display can have. And it cannot show the functions that AC executes automatically and invisibly to register information and show information.
We might think of the Q-display as a generic storefront with nothing in the window until a Q-string is put there. Once the Q-string is there, the Q-display becomes a display for a particular store--for a Q-location--that is made for selling the answer that corresponds to the Q-string. The Q-string is like a sign advertising the answer.
But the metaphor of a store falls very short because a Q-display has many more functions than any ordinary store. A Q-display with a Q-string is more a multi-purpose sign than a store. And yet it is more than that.
The CIP 3 used the made up term signomat to name the multiple functions that AC builds around a question. Why that? Well, first it is supposed to get across the idea that AC turns each question into a multi-purpose sign for an answer. Second it is supposed to get across the idea of a vending machine (it comes from the term Automat, which was the name of vending machine system for food). We can think of AC as creating a virtual vending machine around each question that is stored in the system. Unfortunately, the term signomat comes up short in getting across the third main idea, which is the idea of gathering and storing information. AC has many functions for gathering information that few, if any, machines in the real world seem to have.
We do not want to think of a user going to a Q-display, for the Q-display is a generic thing with no content. We want to think of a user going to a question located in AC and shown on a display, a display with options that enables a user to act regarding the question and the answer that the question represents. Information registered about the user's actions is stored in the Q-record, is stored at the Q-location, in other words. And information about the question and answer is pulled from the Q-record, from the Q-location, in other words.
And so we will think of a question, for now, in terms of a signomat. We can think of AC as a vast bazaar of signomats. And we can think of AC as creating signomats for new questions strings, and of AC as taking users from one signomat to another, and of users traveling to and arriving at signomats. We elaborate below.
1. A Signomat as an Interactive, Commercial Sign
The signomat's question string and A-stats describe an answer. We can think of all this displayed information as a multi-purpose sign. AC presents certain A-stats automatically, and the user can ask to see more. Thus the signomat includes option buttons for getting A-stats. The A-stats can be quite detailed, depending on the type of stat. For example, AC may gather extensive POE information for a given answer. Anyway, the point is that the signomat is an interactive sign.
It is also a commercial sign, in several senses:
a. It's a buyer ad. When a requestor enters a question, AC stores it and the question advertises that the requester wants the corresponding answer. When additional requesters enter the same question this fact is registered and reflected in the POE, and that advertises that multiple people want the answer.
b. It's a seller ad. When a person supplies an answer she supplies it to the corresponding question. Thus the signomat describes the answer that the supplier has entered.
c. It's an address sign for locating an answer. This simply means that to find an answer people enter the corresponding question. If the answer is there it will be found. This scheme seems simplistic but it is a fundamental, people friendly way of finding answers. (Even in the cases where the system processes answers to come up with other answers, a question is still an address as far as users are concerned.)
d. It's a tote board. As with a tote board at the track, AC collects information and processes it and then displays it for users to see. In the case of a tote board, of course, the subject is usually a horse race. In the case of AC, the subject is an answer. While a signomat can display a lot more information than a tote board can, the general idea is the same.
2. A Signomat as an Information Gathering Apparatus
The term "information gathering apparatus" does not tell us much because there are so many of these kinds of machines. However, there is no simple machine to compare a signomat to in regards to how AC gathers information. That is because AC collects many different types of information about a product, about user interest in the product, and about the sales of a product. In the sense of AC collecting demand information, we might look at a signomat as a polling station where users cast their votes for a particular answer. However, AC collects a lot more than polling data. As a minor example, when a user supplies an answer, AC automatically registers how long the answer is.
As noted, AC gathers some information automatically. It also presents users with option buttons for entering information, which are shown on screen. A user selects a button and then AC enables him to enter the corresponding information. AC also gathers information by prompting users.
3. A Signomat as a Vending Machine
A signomat is a vending machine in the sense that when people arrive there AC enables them to buy the answer that is stored there. Like a vending machine, it must be stocked with an answer. Thus a supplier must provide a product to the signomat.
The answer may be outputted automatically once a user arrives. Or AC can include a variety of possibilities for having the user make a price offer. The signomat may even negotiate with the user.
If a user buys, AC registers charges, just as a vending machine would. It also registers royalties (which few vending machines do).
Now people may or may not buy when they arrive at a signomat; they may see information there that gets them to decide one way or another. But the point is that people can offer to buy--press a button and agree to pay some money--at the signomat and can receive the product if it is there.
(Note: Vending machines might be linked such that a user at one vending machine can actually get an answer from another machine, but that is beside the point here.)
A Question Centered System
By now we have seen that questions play various roles: as strings of symbols, as descriptions in language, and as places of business. Questions have multiple roles because AC is a question centered system. The effort to find answers is organized economically around questions. That is AC's plan and it is fundamental.
Principle 8
Everything Depends on People Understanding Each Other Well Enough
The most important process that AC depends on is actually outside AC. It is the process by which people understand what questions mean. It is the process whereby we can ask a person a question and she has a decent chance of understanding the conditions that an answer will have to meet to satisfy us.
This correspondence process is not well understood but it is the basis of the system. So AC must be adapted to the way people understand questions.
This issue is taken up next.
Chapter 4
Problems Concerning the Correspondence Between Questions and Answers in the Minds of People
Questions and answers correspond to each other in some strange way in people's minds. The point of this chapter is to lay out some of the problems that are faced in adapting AC to the way people think about and use questions and answers.
We will not be able to illuminate these problems very well, of course, for they are large mysteries. And we do not give our solutions for them here, but save those for rest of this application, particularly chapter 5 and Book II.
Here we are concerned with meaning: What does a question refer to, correspond to? And how do people use questions to refer to, correspond to, answers?
When we say we are concerned with meaning, we are not trying to get bogged down in a philosophical swamp. We do have a fairly concrete task in mind, making AC operate successfully, fulfilling the principles of the previous chapter. In accomplishing the task, it is obviously helpful to know some of the key problems.
Problem Number One
As discussed in the previous chapter, AC is a communication system that is built around people's ability to understand each other. The whole system depends on people having a good chance of knowing what answer will satisfy someone who asks a question.
But there is a big problem with this plan because people often do not know what answer will satisfy a person asking a question. The correspondence between questions and answers is not one-to-one. The problem is that many answers can correspond to a question, and there are no clear rules as to what a satisfactory answer even is. We might call this the multiple answer reality or the endless answers problem.
Apart from the necessity of having people answer a question satisfactorily, recall that the foundation task of AC is to count how many people want a given answer. Since questions represent answers, AC bases its request count for an answer on the number of times people enter the corresponding question string. Of course, if we are not sure what answer corresponds to a string then we are going to have a problem counting based on question strings.
Problem Number Two
There is a second big problem in making a count based on questions strings. The problem is that there are multiple ways to ask for an answer. In other words, multiple questions can correspond to the same answer.
Now if people ask for the same answer with different question strings then there is obviously a problem in counting up how many people want the answer. Thus AC requires ways to match up the different questions where the same answer is involved. We might call this the endless questions problem or the matching up questions problem.
Let us look at why we have this problem then we will return to problem number one. Why are there multiple ways to ask for the same answer? Who knows. We very superficially point to four reasons below:
The Flexibility of Language
A question is a kind of description. It describes the answer a person is looking for. Language allows multiple ways to describe things including, of course, answers. Different words can refer to the same idea and word order can be changed without changing meaning. For example: What was the precipitation last night?, What was the rainfall last night? and, The rainfall last night was what? can all be considered the same question. There are practically infinite ways to pose the same question in the sense that the different question strings ask for the same answer.
The Incompleteness of Language
Usually there is no to way to describe the answer one wants with complete precision, in the sense of a unique, complete description. That just seems to be the nature of language and reality. It seems that we cannot describe any piece of reality with complete precision. For example, if we ask a question that sounds fairly precise such as, How much does John weigh in pounds?, we see that we leave out many things. To what decimal do we want to go? At what time. At what place? With what scale? And so on. We find we can keep adding details. The process never ends and so there is no unique, complete way to describe or ask for something. There are only multiple, incomplete ways.
Ignorance
We often don't know exactly the answer we are looking for so we pose questions in various ways trying to describe what we are looking for. For example, say you have just spilled very hot coffee on your hand and you feel a burn. You want to know the answer to the question, What should I do to treat my hand?, but you don't quite know how to describe the situation exactly because you don't know much about burns. You might ask, How do you deal with a first degree burn? or How can you tell how badly burned you are? or What should you do when you spill really hot coffee on your hand?. You'd probably ask all these kinds of questions and more.
You have no exact thing in mind, and yet you have the "same" answer in mind, a description of what to do about your burned hand. There is no such thing in your mind as the answer. The same answer really means similar answers, and this notion is not well understood.
Now the various questions we ask looking for an answer might not describe the same answer at all. They may be very different. We have no good theory of the relationships between questions. But we do know that in seeking an answer we may ask a variety of "related" questions, some of which, at least in our minds, describe (refer to) the "same" answer. In other words, if we are ignorant about what we want, we will not be able to describe it well, and will use various descriptions.
Multiple Paths to an Answer
We live in a clue reality, where different pieces of information might lead us to the same answer. This also means that very different questions can all lead to the same answer. For example, let us say we are looking for an actor's name. We can ask, What actor starred in The Graduate and Marathon Man?, What actor has a big nose and looks sort of like Al Pacino and is not Robert DeNiro but is considered a really good actor?, What actor has created lots of cool roles like Lenny and Ratso Rizzo?, and so on. We are looking for the same answer, the same object if you will and yet we can ask different questions. These questions are not synonyms. If we compare them they do not appear to describe the same thing. And yet they do correspond to the same thing because they describe different aspects of that thing (Dustin Hoffman in this case). This may seem to be just a philosophical point but it is important for the organization of AC because in our minds, and therefore in AC, very different questions can correspond to the same answer.
Why a Problem and What to Do?
Given that practically an infinite number of questions can correspond in our minds to the "same" answer, we have a problem because AC bases its request count for an answer on the number of times people enter the corresponding question string(s).
What do we do when different questions are entered that correspond to the same answer. And how can the system "know" that the questions correspond to the same answer? As noted, we might call this the matching up questions problem.
To deal with it, AC needs ways to combine the request counts (and other question information) of those different question strings. In the next chapter we discuss some methods for accomplishing this task, and in Book II we discuss more methods.
Back to Problem Number One
Before we need to be concerned about matching different question strings, we must be concerned about what the questions mean. Users need to know what answer to expect when they enter a question, and they need to know what answer to supply to a question. And yet the fact is that, in the minds of users, more than one answer can almost always satisfy a question. That is a fundamental fact and AC needs rules and procedures for dealing it.
Why do multiple answers correspond to a single question? Again, who knows. We very superficially point to six reasons below:
The Incompleteness of Language
Words are something we use to refer to things. As mentioned above, we cannot refer to anything with perfect precision, meaning we cannot refer to anything that is completely unique. (Depending on your point of view, there may be exceptions in the ideal world of math.) The things that we refer to actually have so many details that our language can only get us to a point where we generally agree on what is being referred to. There is no exact description, only good enough.
Words express (refer to) ideas. Ideas refer to similar patterns. But we don't know what similar means, how it works. All we know is that any idea refers to innumerable things that we call similar. For example, the word house refers to an innumerable slew of similar configurations and we can't say what that slew is. Even when we say something that seems unique, such as, that house right there, we might be referring to the house now, in the future, in the past, and there are other possibilities. When it is "clear" what a statement refers to, that is because we have unconsciously agreed with each other about the correspondence scheme in a way that we do not understand. Some questions, such as, Who was the first President of the United States of America?, do seem to have a unique, obvious answer because of the unconscious, collective rules we have agreed on. However, most questions we ask each other do not describe unique, mutually agreed upon answers. Take, for example, What's the best way to make some money? or How do you get to the nearest mailbox?. Like all descriptions, our question descriptions are incomplete.
Now a question describes an answer. And an answer itself describes something. So a question is a description of a description. That does not change the fundamental situation, which is that we cannot describe things with perfect precision.
We can think of the classic example of a map. If we ask someone, What is a map of Brooklyn?, what details should she draw in the map? Even if we describe the map we want more specifically, our description of the map we want will be incomplete. When our cartographer looks at the real world, she will reflect various details of the real world that we did not specify. The same principle holds for more conventional answers. When we describe an answer, by asking a question, someone trying to answer the question, even ourselves, will find when we look at reality (or whatever system we are looking at) that many answers might match the conditions we have set forth in the question.
The Economics of Language
Usually in our first attempt to describe something we are less precise than we could be. For example, we might ask, Where's the store? rather than, Where's the grocery store? rather than, Where's the grocery store that's within walking distance? rather than, Where's the grocery store that I can walk to in less than five minutes?. Why do we start out being less precise than we could be? Because, on average: (the cost of being less precise+the cost of correcting confusion) is less than (the cost of being more precise+the cost of correcting less confusion). In other words, it pays to be vague at first because people usually understand what we are saying even when we are vague. When they don't understand, we clarify. The cost of clarifying is less than the cost of stating more details in the first place. That is a beauty of how we use language. It also means that we naturally ask questions in a way that leaves much room for various possible answers.
The Flexibility of Language
To repeat, there are many ways of stating (making) a description. An answer is a description of something and therefore can be stated in virtually countless ways.
Ignorance
Since we are often ignorant about what we want when we ask a question, we will not ask it very precisely and so leave open many possible answers. For example, say we ask, What is the patent office's form for a continuing application? Let's say we don't know that there multiple types of continuing applications and multiple forms. And so, multiple answers are satisfactory. Even we who ask the question cannot say that one form satisfies the question better than another. As another example, say we ask, What is a durable pair of tennis shoes?. Since we do not really know what we are looking for (we are probably not experts on the durability of tennis shoes) and do not know what the possibilities are (the possible shoes), we will usually describe conditions in a vague way (durable shoes) that can be satisfied by multiple answers (the names of multiple brands of shoes).
Multiple Ways to a Goal
A question is the statement of conditions that an answer must match. Often we think of a question as stating a goal and of the answer as instructions on how to achieve that goal. In other words, a question states a problem and an answer is a solution. As we know there are usually innumerable ways to solve a problem, to get to a goal. How may ways are there to get a message from the East Coast to California, for instance? Well, there are a hell of a lot.
Different Minds
People have different minds and so the same statements, including questions, can mean different things to different people. Even when people agree that two answers satisfy a question, one answer might pop into one person's head while another answer will pop into the other person's head. These two people will not supply the same answer to the question. As an impractical definition, we might say that a question with a single answer is one in which everybody interested in the answer agrees on the best answer.
Why a Problem and What to Do?
Now if there can be multiple answers to a question then users may be confused as to what answer to expect and what answer to supply, and that will lead to the system failing--for why ask a question if one has very little chance of getting the answer one wants back, and why supply an answer if one cannot expect that it will satisfy users who ask the corresponding question?
There is never a guarantee that we will receive an answer that we are looking for or that we will supply an answer that others are looking for. But we can raise our chances. AC requires rules and procedures so that users can have a good chance of agreeing on what answers to expect and what answers to supply to given questions.
Basically there are two approaches that AC can use. One it can include rules that define what a satisfactory answer is in such a way that the possible answers are tightly constrained. The other is to include rules that allow people to enter multiple answers but to do so in a way that the answers are differentiated and labeled. We will describe such rules and procedures chapter 5, and then further in Book II.
Before doing that we note an important consequence of the multiple answer reality.
The Flip Side
The flip side of having multiple possible answers to a question is that a question does not represent one answer. Thus a person posting a question has a chance of getting an answer that satisfies him. And the person supplying the answer has a chance of supplying an answer that satisfies the requestor. Moreover, if there are multiple people asking the same question, there is a chance that different answers that will satisfy them; a single answer has a chance of satisfying a percentage of the requesters. We may guess at these chances and but we know that there is no certainty when a question does not represent a unique answer.
This also means that the information that is collected in a question record might or might not apply to the answer that is provided. Demand information, to take the most important example, then has to be discounted in some way, in the sense that it applies to only probabilistically to any answer that a supplier has in mind. Say 20 people have asked for the price of a gallon of gasoline at a certain gas station. But also say that the station has three grades of gas. How many people are asking for three prices? And how many are interested just in a single price, and which price? And so what is "the" answer? And what is the request count for "the" answer? There is no solid count; the demand record contains a count that can be used statistically in arriving at a guess about the interest in a likely answer or answers.
Demand information is only one kind of information that is collected about an answer. The same principle applies to all Q-info. What answer does the Q-info correspond to? There is no solid, single answer.
Note on Terminology
Since questions can have more than one answer, it seems that we should stay away from the term the answer. But it will be used frequently for three reasons. First, it is convenient. "The answer" is easier to say than "an undefinable, infinite set of potential answers." Second, in many contexts it is apt (for example, if there is one answer in AC to a question then that answer is the answer in AC). Third, force of habit. The reader should apply common sense when seeing the term the answer.
The term an answer can also be misleading. For example, it is misleading to say that a question describes an answer. And yet for the reasons above, we will often use the term an answer. Again, the reader should be careful.
Likewise the reader should use common sense when seeing the terms the same answer and the same question. Usually there is no such thing as the exact same thing, except where we are thinking of question strings that exactly match each other and answer strings that exactly match each other.
Chapter 5
How Questions Can Correspond to Answers in AC
5.0 Organization of This Chapter
Having discussed the correspondence between questions and answers in the minds of people, let us now discuss it in AC. Questions and answers must correspond to each other within AC in some concrete way. There are various possible ways, which we'll call correspondence paths. By these we mean how questions and answers are related to each other within AC, and how answers get in and out of the system.
To get questions and answers in and out of AC requires the actions of users, so in describing correspondence paths we also describe how users and AC interact.
The place to start is with questions, for they precede answers in AC. Questions are inputted and outputted. And they are the starting point of the input and output of answers because answers are stored to correspond to questions, and answers are outputted in response to questions.
Therefore, in section 5.1, we discuss various aspects of questions: how they are entered into the system and stored, how users can "travel" to them, what can be done "at" them, and how they can be linked to one another. In this section, we also elaborate on the idea of a question location (Q-location).
AC enables users to enter different types of questions. The way answers are inputted and outputted depends on the type of question involved. However, in terms of creating a location in memory, a question type can be thought of as a Q-spec, as described in chapter 3. We list the basic types of questions here. They will be elaborated on in this chapter.
a. Plain Old Questions. By these we mean questions that users can answer. These are the staple questions of the system. They predominate by far.
b. Combo-Questions. By these we mean questions that users answer by contributing separate answers that AC combines into a larger answer.
c. Function Based Questions. By these we mean questions that activate special search and processing functions that operate on questions and answers that are in AC. Usually users cannot supply answers to these questions. Further, these questions do not really have questions strings, they have what we call subject information.
d. Auto-Questions. By these we mean questions that are created by AC based on questions that users have entered. Users can answer auto-questions.
In section 5.2, we discuss answer input paths, how answers are gotten into AC to correspond to questions.
In section 5.3, we discuss answer output paths, how answers are gotten out of AC in response to questions.
The discussion in sections 5.2 and 5.3 applies to plain old questions, combo questions and auto questions.
We wait until section 5.4 to discuss function base d questions.
In section 5.5 we briefly discuss how to combine question information, particularly demand information, when an answer is requested from multiple questions.
The example questions in this chapter are colloquial and are suited for a system that can handle natural language. We use colloquial questions because they are easier to think about and because they prepare for Book II, where methods for handling natural language are described. Still, the discussion in this chapter applies to questions and answers whose grammar is highly constrained as well.
5.1 Creating, Finding, and Traveling to Questions
In this section we describe how AC enables users to create, find and travel to questions. AC presents options for doing these things at the Q-display. The options are presented to users in all modes. There are some differences in what happens depending on the mode the user is in. We will be discussing request and supply modes primarily (there are other modes which are described later).
In FIG. 4.10, the options are grouped in three areas: Q-info, Show and Go. They are grouped this way for illustration's sake, not because this way is best. In illustrating these options we ignore the many other options that AC presents at the Q-display, for they are not the concern of this section.
5.1a Seven Definitions
Definitions are given here of some key features and processes of AC that are discussed in this chapter. Other features and processes are defined along the way. The first three definitions below are basically repeated from chapters 1 and 3.
1. A Question
In this chapter, when we say a question we usually mean it in the sense of a Q-string that a user enters. The Q-string may be made up of a main string and question specifiers. Or, it may be just a main string. (See chapter 3.)
2. A Question Record (Q-Record)
The record AC creates to store information about a question and about the answer(s) that the question represents.
3. A Question Display (Q-Display)
The interface AC presents to users. It shows a question and numerous options and sub-options. We call these Q-display options. As illustrated in FIG. 3, these include options for:
entering questions 70, 71,
finding questions 70, 71, 72, 74,
entering information into Q-records 72, 75, 76,
getting information from Q-records 73,
finding answers 70, 71, 72, 73, 74,
buying answers 75, and
entering (supplying) answers 76.
4. The Current Question
The main subject of the Q-display is called the current question (current-Q). When we say main subject we mean that the question is normally shown on screen and that the Q-display options apply to it and its Q-record. However, AC can show more than one question at a time, and several of the Q-display options can apply to these other questions as well. Thus, when we say the current-Q we mean the question that most of the options apply to. The current-Q is not necessarily shown on screen. This is because AC may instead display other questions, or an answer, or a sub-menu for a given option. If the current-Q is hidden, it can be called up by a Show Current-Q command.
5. Being at a Question
"Being at a question" is another way of saying that the user is presented with the current-Q and/or with the options that apply to the current-Q.
6. The Null Question
The null question (null-Q) means the absence of a current-Q or of any question. The user can enter a command, which we might call Null Q, in order to clear the screen of questions. The user is then at the null-Q. When there is no current-Q, fewer options apply. Those that do apply allow the user to enter a new question. They may also enable the user to call up past questions.
7. Traveling To (Going To, Arriving At) a Question
Traveling to a question means that a user enters a question, or selects a question on screen, to be the next current-Q, and that AC then makes that entry or selection the current-Q. When we say "makes" we mean the process by which AC finds the question and presents it to the user as the main subject of the Q-display, or, if the question does not exist already in AC, the process by which AC creates the question in memory and then presents it to the user as the main subject of the Q-display.
5.1b Entering a Question
At the Q-display, AC enables a user to enter a question string.
Because the user can enter various types of information besides a Q-string, AC can have the user first press a Q-string button 100 to identify the information. Or AC can simply let the user designate a Q-string area on screen and type the question in there. Or AC can default to assuming that the user is entering a Q-string.
After the user is satisfied with the question he presses an Enter 101 button to complete the entry. (In certain lands, AC might not have the user hit Enter, but we leave this possibility aside, for it only applies in special cases.)
AC enables the user to edit the question, if he so desires, in order to make a new question. After editing, he hits Enter again.
He can clear the screen by pressing Null Q 102.
Note: For illustration purposes, as we continue this discussion, we will use certain questions, such as, What's holding up traffic?. These have no special significance.
5.1c The Main Rule of Creation
When a user enters a question AC does a look-up to see if the question is already stored. If the question is not already stored, AC stores it and creates a question record to go along with the question in memory. That is the main rule of creation.
We call a question string and its question record a question location (Q-location). In FIG. 4.11 we picture a Q-location 130 as a circle with its Q-string 131 written inside and with its Q-record 132 as a rectangle within the circle as well. The missing (potential) answer is pictured as a blank square 133 connected to the circle. As we go along, we will add to this scheme.
AC stores the new question such that it can become a current-Q. In other words, it is a location in memory not just in the sense of storage but in the sense that the user can find it, be taken to it, and in the sense that the Q-display options apply to it and its Q-record.
Technically, any information the user enters can be stored and called up. The point here is that a location is created that users find when they enter a matching question--that AC finds for them, that is, when they enter a matching question. (We discuss matching questions in 5.1d, below.)
When the Rule Applies
So the main rule of creation is that a Q-location is made for each new question entered. However, this rule is not applied in all cases. Whether it applies depends on what mode the user is in and what the user's purpose is in entering the question. The idea behind the rule is that questions are created to enable people to express interest in and to find answers.
Thus, if the user is a requestor, then the rule holds because the user's purpose is to ask for an answer. That is what request mode means.
If the user is a supplier, the rule holds when the supplier also enters an answer to go along with the question.
(Note: What is registered in the Q-record at the time of creation differs depending on the user's mode. For example, when a supplier enters a question, AC does not register demand information.)
If the user is in another mode, such as browse or check mode, the rule does not usually hold because users are not asking for or supplying answers.
A user can enter a new question for other reasons that require AC to create a Q-location. For example, a user in supply (or browse or check) mode may enter a question to test demand. In other words, a potential supplier may post a question not because she plans to supply the answer but to see if others will express interest in the answer. A potential supplier may also post a question because she intends to supply the answer in the future and wants to collect demand in the meantime, or because she wants to post a reservation message (see chapter 8). So AC can create Q-locations under more circumstances than a user being in request mode and entering a question, or a user being in supply mode and entering a question and an answer.
AC can include an option enabling a user to designate the purpose of a question.
But what if a user is in request or supply mode and is just browsing and/or checking POE's? Here we have a problem because AC cannot divine the user's intention and can only rely on the user telling it. Thus AC can have various default rules. For example, if a user is in supply mode, AC may create a question only temporarily. If the user does not then enter an answer, or does not designate some special purpose for the question, AC may erase the question. The default rules can vary.
Another important case where the main rule holds is when a user, in whatever mode, wants to enter a question in order to link it to another. Here, again, the purpose is to help people find an answer or express interest in an answer.
And as a variation on the main rule, AC may only store a question upon confirmation from the user that he wants the question to be stored.
Having said all this, it is possible, as a design decision, for the main rule of creation to always hold. AC can store all new questions and create locations for them. But it seems that better default rules can be created to fulfill the underlying idea of creating questions to enable people to express interest in and find answers.
In section 5.2 we elaborate on the notion of Q-locations.
5.1d Finding/Matching a Question
As discussed, when a question is entered, AC looks for a match. Here we elaborate on what happens.
First we must point out that in order to default to "best" matches, AC may also rely on A-stats information in the Q-records of potential matches. In other words, AC does not so much match questions as it matches Q-locations. The match seen by the user may only be a Q-string but still, AC may be using A-stats information as well to arrive at that match.
Now, AC may find no match. It may find an exact match. And it may find "best" matches which we will also call tentative matches.
Even if an exact match is found, AC still looks for tentative matches. These can be important because the user may want to see what similar questions have been asked by others. The similar questions might have answers the user is interested in. And they might have A-stats that the user is interested in.
How many matches are found is a design decision that depends on the defaults built into AC's matching rules.
(Note: In this section we are concerned with how a user finds a question with a Q-string. A user can also find an answer. We save that subject for the section 5.3.)
Rephrase Option for Finding Questions
AC can also enable a user to enter multiple versions of a question in search of a good match. Let's say the user enters, What's holding up traffic?, and AC finds no match. Therefore, he continues to rephrase the question:
What's the cause of all this traffic?
Why is the traffic all jammed up?
Traffic jam, basic info?
He can do this by erasing the current-Q, or by pressing Null Q, and then entering a new question, until he finds a good match, if one exists.
AC can also give him the option of pressing what we will call a rephrase button 103. When he presses this, it means that the next question entered is a rephrase of the current-Q. This signifies to AC that AC should use information from both Q-strings to find a good match. There may be more than two questions involved because the user can hit the rephrase button before entering a third question, and a fourth, and so on. Combined information from multiple questions may result in a more successful search.
(We will see in Book II how AC link the different phrasings with a rephrase link.)
Finding Matches to the Current-Q
We will be discussing, in 5.1g, how users can travel to a question by selecting it, rather than entering it. The reason we mention that here is to point out that AC can look for the matches to a current-Q, even though the user has gotten there by selecting it, rather than entering it.
AC may look for matches to the current-Q automatically, as it does when the user enters a question, or a user can ask to see matching questions.
As noted, the option of seeing matching question enables a user to see questions in AC that are similar to the current-Q.
Next we discuss how AC can show matches. But first we digress briefly on the subject of matching.
Digression on the Importance of "Best" (Tentative) Match Algorithms
Best match algorithms are essential to the operation of AC because, unless the grammar of the questions is highly constrained, people searching for the same answer will rarely enter the same question string. People will usually enter similar strings. Even if the grammar is highly constrained, people will still often enter similar questions, while looking for the same answer. For example, two people looking for the same phone number may enter different questions, such as: Daneel Olivaw's phone number? and R. Daneel Olivaw's phone number?.
A question that is entered into AC needs to be tentatively matched up against existing questions so that the user who entered the question has the option of finding and selecting a match. A user might not select any match. But, if there was no option of selecting matching questions, then users would not be able to see what similar questions other users have asked, and so there would be little accumulation of demand on questions--little accumulation of demand for answers, that is.
AC must do the tentative matching, of course, because users do not know what potential matches exist in AC.
Let's consider one more example. Assume that What's holding up traffic? has been asked in several languages and is translated into a common language. Yet this is a false assumption, for there is no single question in different languages that means What's holding up traffic?. There are similar questions. As noted in chapter 4, there is no single Q-string for any question. When we think of a question in different languages this fact is exposed.
If we are to match, say, two synonymous questions that have been stated in different languages, we need best match algorithms, for if we translate one question into the language of the other, the two Q-strings in the same language will rarely be exact matches.
Many techniques are known for enabling computers to find text matches. We do not go into them. We do note that while these techniques are essential, they are all deficient because no one knows how to program a computer to do a good job of recognizing similar things.
(We should note that people are often unable to decide what the best match is for a question because people do not know what best match means. Still, people are much better at matching than computers, as long as the set of potential matches is small.)
|
