WO1997010551A1

WO1997010551A1 - Answer collection and retrieval system governed by a pay-off meter

Info

Publication number: WO1997010551A1
Application number: PCT/US1996/014140
Authority: WO
Inventors: Michael T. Rossides
Original assignee: Rossides Michael T
Priority date: 1995-09-11
Filing date: 1996-09-11
Publication date: 1997-03-20
Also published as: AU7235896A

Abstract

A self-organizing data-base that charges (13) users who find data in it and pays (13) users who supply the data found has a built in feedback mechanism, called the Pay-off Meter (7, 8, 9), that tells users what data needs supplying based on the number of requests (10) for that data over time. The Pay-off Meter outputs a projected Pay-off (9) for supplying the data.

Description

Answer Collection and Retrieval System Governed by a Pay-off Meter

Cross-references

US patent #5,359,508, and continuing applications #08/327,704 and #08/389,405.,These will be called the great-grand parent, the grand parent and the parent, respectively. '

Background— Field of Invention

This invention relates to a fee supported data base system for community use.

Background-The Prior Art

The primary prior art is US patent 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. Basically, the system tells users, "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 an economic feedback loop. The loop can be built upon. Later prior art is PCT applications # US95/12630 and US96/01699. This application adds new matter including procedures for entering and displaying questions and answers, registering demand for answers, and granting property rights to users.

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 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, provided the price is the same. One key 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 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

Figure 1 shows a flow chart of the basic system.

Figures 2a shows the flow chart of the Request Mode of a lowest price locator.

Figure 2b shows the flow chart of the Supply Mode of a lowest price locator.

Figures 3 shows part of a question display menu.

Figure 5.10 shows a another view of a question display menu.

Figure 5.11 shows a question location.

Figure 5.12 shows a question location including question specifiers.

Figure 5.13 shows form linked question locations.

Figure 5.14 shows a Q+ leading to a question location.

Figure 5.15 shows three question locations with the same missing answer.

Figure 5.16 shows a question location with an actual answer.

Figure 5.17 shows multiple Q-A-locations as part of a question location.

Figure 5.18 shows a question location with a current and a past answer.

Figure 5.19 shows two links between Q-A-locations.

Figure 5.20 shows a link between Q-A-locations.

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. 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 type of answers involved and the needs of users.

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. We do not show voice input and output means, though we realize that these means are very useful. 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

In the parent, 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 I. Asimov, who told the tale of AC, a computer that answered every question (in the The .Last Question).

While a table of contents is given, the reader will find several chapters unwritten or missing. Two or more additional continuing applications are planned. 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 have yet to be written or expanded from related patent applications. Where Book II is referred to, it should be taken to mean material in related patent applications not shown here.

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 are functions that 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.

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 later 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 of between questions and answers inside AC. AC includes intemal 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 eta-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 implementations of AC, therefore this issue is discussed further in several places in the description (see Part II chapters 4 and 5).

Potential Answer: Depending on the correspondence rules of a particular AC, the system may enable users to enter answers that can be called potential answers in the sense that they may or may not be outputted in response to given questions. For example, if the questions is, What are the highlights of George Washington's career, in under 100 words?, multiple users might supply an answer but the system might only choose one. The others then would be potential answers that might be outputted if the selected answer was found lacking for some reason.

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 requestor who wants to buy the corresponding answer.

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 π 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 π in a formula may be classified differently than the answer to the question, What is the value ofπ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 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. In supply mode a user enters a question and AC then enables the user to enter a corresponding answer. If the question 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 requestor.

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 requestor or processed to yield another answer).

Payments Register: The function AC executes to register payments owed by requestors 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 requestors 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 requestors with the POE for correcting the answer. Aspects of the POM functions are discussed 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. (Note: the parent used "Demand Meter" to name the parts of the POM that keep track of demand information and calculate a "demand rate." Here we use the "demand record" to name the part where demand information is stored. The part that calculates a demand rate we now incoφorate 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. 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 like, "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 8

POE's. In given ACs, 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 requestors what answer is needed, what the value is of supplying it and how to supply it. When a requestor 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 enter 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.

AC Procedure

Figures 1 and la 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 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 requestor, 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 ED 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, two embodiments are described.

A Self-filling Telephone Directory (SFTD)

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, bl)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 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 figures 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 requestor 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 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 merchant and price (answer) into the list, inputs 55 the answer, stores 56 the answer in the list, 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.

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 the 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.

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 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 later chapters 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.

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. ACs rules determine what kind of functions and formulas AC has, so these in turn can vary. For 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. So when we say that ACs rules and formulas are variable we mean: 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.

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, an index field, 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 or 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 can 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 requestors 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 fields, 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 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. The main string might specify all these things. Standard specifiers are not mandatory.

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-stat. 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 to enter and see various kinds of information about the answer that the question represents. An illustration of a Q-display is given in figure 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, 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 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. 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-stat 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-stat of 408 words. If the answer is later changed, this A-stat 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-stat that can change with each request. Sometimes the dividing line between Q-string information and A-stat 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 choose to enter the information as Q- spec or A-stat 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-stat information to describe an answer but they do not expect other users to supply an answer that will fit the A-stat conditions. Operationally this means that AC enables users to enter Q-string information through different input forms than A-stat information. Users are expected to know the difference. AC then uses the Q-string information to create questions and uses the A-stat 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 ACs memory that users (with ACs 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 directions to the 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. And 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. Figure 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 parent application used the goofy, 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 in regards to the question. Information registered about the user's actions is stored in the Q-record, at 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. Thus 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 requestor wants the corresponding answer. When additional requestors 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 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 concemed.) 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.)

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 ACs 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.

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 that is. In accomplishing the task, it is 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 1-1. 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. 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. 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 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. There may be exceptions in the ideal world of math, but excepting these, 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 ofthe 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 ofthe 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 foπn 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 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 people 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 the next chapter, and then further in book H Before doing that we note an important consequence of the multiple answer reality.

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 requestors. 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 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. 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 based 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 also applies to questions and answers whose grammar is constrained.

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. In figure 5.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 figure 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 in AC, the process by which AC creates the question in memory and 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 figure 5.1 1 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.

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 also 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 Q-locations.

5.1 d 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-stat 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-stat 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 ACs 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. lg, how users can travel to a question by selecting it, rather than entering it. The reason we jump ahead 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 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 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 better at matching than computers, as long as the set of potential matches is small.) Digression on the Inadequacy of Best Matching Alone

The problem of matching a question against existing questions goes beyond the difficulties of machine matching. A bigger problem is the fact that innumerable similar questions can describe the "same" answer. Thus users can, and will, create a profusion of similar questions, all potential matches. But if there are hundreds or thousands or millions or billions or trillions of similar questions, how to find and show potential matches to a given question? And how to decide which potential match is the "right" match for a given question? Say Rex asks where he can find a certain T-shirt that he describes in his question. Rex can ask that the T-shirt have a certain price, that it be made in a certain country, that it be a certain percentage of cotton, that it be a certain color, that it be a certain size, that it be a certain thickness, and on and on. The possibilities are endless. And say that 10,000,000 other people in the past have asked where they can buy a certain T-shirt and that each person has described a different shirt, though we might recognize many of the shirts as similar. Now, how can AC find the "right" match for Rex's question among the 10,000,000 possible matching questions in AC? How can a human find the right match? Well, no one can, for there is no right match. The reality is a profusion of similar questions. How then to match them up? A solution to this problem is described in Book II and is previewed at the end of this section. Here, all we say is that ACs matching rules of course include defaults for limiting and selecting the matches shown to the current-Q.

5. le Showing Matching Questions

If AC finds an exact match then it tells the user. If AC cannot find an exact match it may find one or more tentative matches. These can be shown in an area on the Q-display for matching questions. If AC cannot find an exact or tentative match, it shows a "no matches" message. If AC finds an exact match, it still may show tentative matches. That is because, as noted, a user may want to see similar questions that other users have asked. AC enables users to press a scroll command 106 for scrolling through the matching questions. How much of a matching question is shown is a design decision and depends on the situation. AC can hide matching questions and enable the user to call them up by entering a command such as, Show Matches 107. While tentatively matching questions are not current-Q's, AC can append certain key A-stats to them, such as whether they have answers. These statistics come from the Q-records of the questions involved.

Match Statistics

AC can show match statistics (match stats) for the question entered. By these we mean statistics about how many tentative matches AC can find for a question. There may be a large number of such matches. For example, What's holding up traffic? might have one exact match and billions of tentative matches. (In this situation the user would usually further specify the question.) (Note: AC can show match stats for a current-Q regardless of how a user got there.)

Digression on Multiple Hits

In many conventional data base systems, there are search methods that yield "multiple hits" in cases where the search key is an exact subset of multiple targets in the data base. For example, let us pretend that a data base has the terms Yabba Dabba and Yabba Dabba Doo. Now let us pretend that the search key is Yabba. In many conventional data bases, a search would yield two hits. But in AC, the search does not yield a hit in this sense. The AC procedure is:

Enter Yabba.

Do look-up to find Yabba.

Yabba found?

If no, create Q-location for Yabba.

Look for tentative matches.

(Yabba Dabba and Yabba Dabba Doo might or might not then be tentative matches.)

The point is that AC creates a new Q-location for any new Q-string regardless if it is a subset of some other string. Little is different from Little Red is different from Little Red Schoolhouse and

Little Red Riding Hood. Thus AC treats them differently. Having said all this, we note that AC can show conventional hit statistics so that if a user enters, say, What's holding up traffic?, AC can show how many questions What's holding up traffic? is an exact subset of. Ideally, AC shows how many very similar questions there are and this is not definable in terms of subsets.

5.1 f S ho wing Other Questions

In addition to showing matching questions, or rather than showing matching questions, AC can enable the user to see other questions. AC can enable the user to press a command 108 for seeing the previous question. By previous question we mean the previous current-Q. This option is a useful skip back command. AC can keep a list of questions that the user has asked during a certain period of time. And AC can include a command 109 enabling the user to call up questions from this list, such as the last ten questions the user has entered. AC can also enable the user to maintain a list of open questions, questions that have not been answered but that the user still wants answered. The list can be kept in the user record. AC can include a command 110 enabling the user to call up this list. AC can also include a command 111 enabling a user to see linked questions of various kinds. We say various kinds because there are different kinds of links, which we will discuss later, especially in Book II.

5.1g Traveling to a Question

We use the colloquial term, "travels to" a question for the process by which a user identifies a question and AC makes the question the current-Q 112. We also use the terms "arrives at" and "goes to." As noted, the current-Q is not necessarily shown all the time. For example, when an answer that corresponds to the question is shown, the user may not see the current-Q. The current-Q may be hidden for various other reasons. Thus AC includes a command 113 for showing the current-Q if it is hidden. Before arriving at any question, a user is at no question. We call this being at the null question. The user starts his travels then by entering a question, or by calling up a question from his user record. (When we say "he," we do not only mean Rex; we mean a user in any mode.) As noted, there are two basic ways a user can travel to a question: 1. He can enter a question. AC then makes this question the current-Q. 2. He can select a question that is on screen. AC then makes this question the current-Q.

As discussed, a question on screen, other than the current-Q, may be a matching question, a question from a list of previous questions, a question from the user record, or a linked question. It may also be a comparison question, which we describe a little bit later. When we say "select" here we mean that the user designates that he wants the question to be the current-Q, that he wants to go to the question. He might designate this by selecting it and then hitting a Go 114 command, for instance. The reason we distinguish the type of selection is that the user can select a question in order to have other options apply. (As noted, some Q-display options apply not only to the current-Q.) For example, the user might select a question in order to see A-stats about it. In this case he might select it and hit a See A-stats 115 command. AC may not show all of a question on screen. Partial information can be shown and the user can select that. Likewise, AC might have buttons for designating certain kinds of questions, such as the previous current-Q and the null-Q. The user can select one of these and hit Go as well.

Surveying the Scenery

A variation on the plan above is the following. AC can enable the user to choose an option whereby the user enters a question and AC only shows matching questions. By this we mean that if the user enters a question that is new, AC still creates a Q-location for it, but does not show all the usual options. The question is still the current-Q, but it is hidden. AC shows the user tentative matching questions and options that apply to these. The reason for this travel option is that a user looking for an answer might not want to mess around with a new question that he might create. He might want to get an existing answer, or he might want to get to a question that others have asked. Thus AC can enable the user to choose an option whereby he does not see the usual options if his question is new. (Of course the user might want to see the current-Q and can enter a Show Current-Q command, in which case AC shows the usual Q-display options that apply to the current-Q.)

Tentative Current Question As a variation on the plan above, the user can ask AC to show the single best match AC can find, and the user can confirm whether this match is adequate. The difference here from showing multiple matching questions on an equal basis is that AC may show more A-stats about the "single best" match than it would ordinarily show about other match questions. AC may show A-stats as if the best match was the current-Q. It may, for example, show matches of the best match. When AC does this, we might think of the single best match as the tentative current-Q. If the user confirms the best match it becomes a real current-Q. This confirmation is another way of selecting a question on screen. If the user does not confirm the best match or does not select any other matches to go to, he can continue entering questions until he is satisfied with a match.

Seeing Matching Questions to the Current-Q

As noted in sub-section 5. Id, AC can find matches for the current-Q regardless of whether the user got there by entering the question or selecting an existing question on screen. As noted, AC can include a Show Matches command. This command, when pressed, can signify that the user wants to see best matches to the current-Q. Enabling the user to see matches to the current-Q is critical because it allows the user to see and travel to questions that are similar to a question. This applies not only to a new question that a user enters but to any question a user is at.

Travel Options

From the preceding we can see that a user can land in AC in various ways, and can continue on his travels once he lands. He can land at an entirely new question that he entered and that AC has created for him. He can land at a question that has already been created. He can land at no question, merely surveying what questions are similar to the one he entered. And he can choose to go to one of these similar questions. When at a question he can see questions similar to that question. And he can go to one of these as well. Or from where he is he can enter a new question and be taken there. Or he can ask to see some of the previous questions he has been at. And he can select one of these as well. Or he can ask to be taken back to the null question.

Come-From and Go-To Questions

A user will often go to a tentative match. When this happens, we will call the question that the user came from, the previous current-Q that is, a come-from question (come-from-Q). From the point of view of the question that becomes the previous current-Q, we call the new current-Q a go-to question (go-to-Q). For a given question, AC can register what question a user arrives from and what question a user goes to. Naturally, when a user travels from one question to another, AC can register the fact in two question records, at the origination airport and the arrival airport if you will. We call this information arrival stats and destination stats.

Pseudo Traveling Using Want-it Marks When Rex travels to a question it is often to express interest in the corresponding direct answer. AC can give Rex another way to express interest in a missing answer without having Rex actually travel to the corresponding question. As discussed above, when Rex is at a question he may see one or more matching questions. He may be interested in the answer to one or more of these. As noted, when AC shows these matches, it can also show Rex that the questions do not have actual answers. Rather than have Rex go to these questions to express interest in their answers, AC can enable him to express interest by marking the questions with a want-it mark. AC may, for instance, have a check box next to each matching question whose answer is missing. If Rex checks the box it means he wants the corresponding answer. Now AC may also enable Rex to make a price offer but that is beside the point here. The main thing is that AC can enable Rex to express interest in the answers to matching questions without traveling to those other questions. This option can be an important convenience. Not only can it save Rex time but can show AC what are good matches to a question and can help Rex pool demand on given questions. (In discussions about registering demand information, a want-it mark will be considered a kind of request, even though Rex does not go to the question that is marked.)

5.1 h Question Specifiers

As discussed in chapter 3, AC enables a user to enter standard question specifiers (Q-specs) that are a kind of Q-string information. As Q-string information, AC uses Q-specs to create Q- locations. It also uses them to find existing questions. A user can enter Q-specs along with a main string. AC can include a Q-spec button 116 that a user selects to call up a Q-spec form, enabling him to enter the Q-specs. He can also enter the Q-specs after he has entered the main string. For example, a user might enter What's holding up traffic?. There might be one exact match and 5,000, 000,000 tentative matches for this main string. And so the user might then enter certain Q-specs to further specify his question. He might enter for example: Time: 6:30 a.m. Date: 6/6/96 Place: Ten Freeway, LA. Source: California Highway Patrol

Just as a user can edit the main string, the user can edit Q-specs, changing them and then entering the new question that is created. For example, the user can change the Q-spec above concerning the source of the answer to, say, Anyone Official. Or the user might erase the Q-spec entirely, leaving it blank, and implying that the source can be anyone at all. The Q-specs may be hidden, Thus, AC can include a command 117 for calling up the current Q-specs as well as one for entering them.

Match Instructions

AC can enable a user to designate Q-specs as optional or mandatory. This means that the mandatory conditions are preferably matched over the optional ones. (This also tells potential suppliers that an answer must fit the mandatory conditions.) For example, a user might designate the time and date as mandatory and the source of the answer as optional. AC can also enable a user to rank Q-specs in order of preference, to give AC guidance in selecting matches. Now when we say "match" we mean it in the sense discussed previously of most similar matches that AC can find according to ACs intemal match rules. Thus a Q-spec or any string information might not be matched exactly. A Q-spec, for instance, of 10 cents or under, might be matched by a Q-spec of 75 cents. AC can also enable a user to designate a Q-spec to be a screen. By this we mean that the Q-spec must be matched in the sense of a true match. For example, if the Q- spec is 10 cents or under, then the matching question must also include a Q-spec that specifies a price of 10 cents or under. 7 cents will do. 11 cents will not do.

Repeat Use of Q-specs

Now a user may go to a matching Q-location that has different Q-specs than those he entered. As a convenience, AC can enable the user to have the last set of Q-specs entered kept in the background to be used for a future question entry. We will call these background Q-specs. By this we mean that the last Q-specs entered are kept temporarily in memory and hidden from view. AC can enable the user to call them up (and edit them possibly) and designate that they be used when he enters another main string. To let a user do this, AC might have, as options of the Q-specs menu, a command called Use Previous Q-specs and a command called Edit Previous Q-specs. Or, when the user calls up the Q-spec form to enter Q-specs, AC can assume that the Q-specs remain the same from the previous entry, until the user changes them. The point of these options is to save the user the time of re-entering Q-specs. As another convenience, AC can enable a user to set Q-spec defaults such that a given set of Q-specs goes along with every main string the user enters, until the user cancels the default command. A Q-specs default can be quite useful. For example, Rex might have lots of questions about the traffic jam he is in. He might want to automatically preface them all with the same time and place Q-specs.

Matching Q-specs Against A-stats

As noted in chapter 3, certain Q-specs and A-stats can be about the same kinds of information. While AC treats the information differently with respect to memory locations, it can in certain cases match Q-spec information against A-stat information. Price information is an example. A Q-spec might be 10 cents or under, and an A-stat might be 7 cents. These could be a matched.

Automatically Creating Two Questions

A useful procedure AC can include is to automatically create two questions when a user enters a set of Q-specs. In this procedure, one question is made up of just the main string, and one question is made up of the main string plus the Q-specs. In figure 5.12, we assume a user has entered, What's holding up traffic?, and has also entered a Q-spec, 6:00 a.m.. And so AC creates two locations, one for the main string 140 and one for the main string plus Q-spec 141. We also assume another user has entered the same main string but with a different Q-spec of 7:00 a.m.. And so AC creates a third Q-location 142.

Form Linking Questions

Not only can AC create these double questions but it can link them in memory, so that users arriving at the main string can then call up linked questions made up of the same main string plus different Q-specs. We call this manner of linking questions form linking. And we call the link a form link. We use this name because the Q-specs are standard and can be entered in a form. When the difference between the two questions is a matter of the Q-specs, we might call the link a Q-spec link. Form linking can be quite useful for several reasons. It can enable a user to see what similar questions other users have asked. This can help requestors find similar questions and locate similar answers. Further, it can enable users to pool requests on particular questions, especially the main string. For example, if 100 people ask Movie review of Casablanca? but they all have different Q-specs, then there will be 100 different questions and there will be less chance that there is enough demand to answer any one of them. But the main string may show enough demand to be answered.

On the supply side, a potential supplier is in a better position to decide whether it is worthwhile to provide an answer that may satisfy some fraction of all the users who have entered that main string. Moreover, a supplier may find other similar questions worth answering. For example, as seen in figure 5.13, a user might enter, Movie review of Casablanca? 150. Now we face the multiple answers problem discussed in the previous chapter. What answer is the user looking for? What answer should a user supply? One partial solution is a form linked question in which the main string is built upon with Q-specs to create a new question that differentiates the answer. Say the user wants to enter only one Q-spec, the name of the author of the answer (the review). A requestor would enter a desired author, say P. Kael 151, whereas a supplier would enter the actual author, say, G. Siskel 152 (note: we do not picture the answer having been supplied). Thus AC can have numerous questions all starting with Movie review of Casablanca? but distinguished by the names of authors. These questions are linked to the same main string.

5. li Answer Statistics as Search Parameters As discussed in chapter 3, AC collects, compiles and displays statistics (A-stats) about an answer. These are stored in the answer's Q-record and are accessed from the Q-display. A-stats can also be entered by a user along with a Q-string as additional search parameters to find a question (and perhaps an answer). When used for this purpose, we will call them search stats. AC can include a command 118 that, when pressed, calls up a form for entering search stats. We will call the combination of Q-string and search stat information a Q+. AC matches a Q+ against existing Q-string + A-stat information in AC. In other words, it matches them against existing Q-locations. For example, a user might enter the Q-string: Movie review of Casablanca? . There might be one exact match and 5,000,000 tentative matches. And so the user might then enter search stats to further specify his question. For example: Popularity: Most popular answer by sales. Length: Less than 200 words. Price: Under 50 cents

AC then shows the user the Q-locations that best match this information. AC may show just the matching Q-strings. Or AC may show the A-stats that correspond to the search stats as well. Now the A-stats that are shown may differ depending on whether a question has missing answer or an actual answer. But we do not pursue this point right now. As noted, in this section we are concerned with how users find and arrive at questions. As discussed in sections 5.2 and 5.3, a user can also find an answer with a Q+. We wait until section 5.2 to discuss how A-stats are shown when a user arrives at a question with an actual answer or answers.

Match Instructions

As with Q-specs, AC can enable a user to designate given search stats as optional or mandatory. The mandatory conditions are preferably matched over the optional ones. AC can also enable a user to rank search stats in order of preference, to give AC guidance in selecting matches. As before, when we say "match" we mean it in the sense discussed previously of the most similar matches that AC can find according to ACs internal match rules. AC can also enable a user to designate given search stats as screens. As before, by this we mean that the search stats must be matched in the sense of a true match. For example, if the search stat is 10 cents or under, then the matching A-stat must also be equal to or less than 10 cents. 11 cents will not do.

Repeat Use of Search Stats

Now when a user arrives at a Q-location, the location has no search stats. It does have A-stats, but these are not search stats; they are not used to search for a question or answer that is. As a convenience, AC can enable the user to have the last set of search stats entered kept in the background to be used for a future question entry. We will call these background search stats. By this we mean that the last search stats entered are kept temporarily in memory and hidden from view. AC can enable the user to call them up (and edit them possibly) and designate that they be used when he enters another Q-string. To let a user do this, AC can have, as options of the search stats menu, a command called Use Previous Search Stats and a command called Edit Previous Search Stats. Or, when the user calls up the form to enter search stats, AC can assume that the search stats remain the same from the previous entry, until the user changes them. The point of these options is to save the user time. As another convenience, AC can enable a user to set search stat defaults such that a given set of search stats goes along with every Q-string the user enters, until the user cancels the default command. This default option can be quite useful. For example, returning to our traffic jam, Rex might have lots of questions about the jam. He might want to automatically preface them all with, say, the same price and quality information.

Matching Q-specs. In certain cases, search stats can be matched against Q-specs.

Little Digression

There are essential aspects of answers that cannot be supplied by any individual. And there are essential aspects that have nothing to do with information in the sense of bits and bytes. This is a fascinating thing about answers. Aspects such as credibility and demand come from elsewhere. And they are crucial to the value of answers. Thus people want to know about these aspects and people ask for answers based upon them. For instance, people want credible answers. If Rex asks, How should I teach a blind person to walk across the street?, Rex will surely want to know that the technique supplied has been well tested. There are various ways of verifying answers. We do not have any perfect way. And yet the fact that an answer has been verified changes the answer (and can be reflected in A-stats). Credibility is an obvious case of an aspect of an answer that is valuable though not well understood. Let's take a less obvious example that is quite important where AC is concerned, and that is the example of demand. Say a user wants to find an actual answer in AC and finds none that he is satisfied with. He might then want to find a missing answer that is similar and that also has a high POE. He might want to find such an answer in order to pool demand with other requestors. Indeed, the intentional pooling of demand will turn out in many cases to be a critical way that the POE is raised high enough for a given answer to be supplied. And if the answer is supplied, it can be found by its demand, its popularity that is. So demand is an aspect of a missing or actual answer that we do not understand but that can be critical to choosing the answer. AC compiles statistics that enable people to differentiate answers based on many essential, though perhaps poorly understood, aspects of answers. This is a key feature of AC.

Imperfect Representation

As we have discussed, questions represent answers. The A-stats that come from the Q-record of a given Q-string are part of the representation of an answer, whether the answer is missing or present. The A-stats show us how imperfect any representation is, especially a representation that changes in time. For example, if an answer has no complaints registered against it one day and ten the next, is it a different answer? Yes, in the minds of potential buyers it is. Yet we collect demand for an answer based on who arrives at the corresponding question. Why do we collect demand information based on what questions people arrive at rather than on what questions people arrive at and on what A-stats are showing at the times of arrival? Why not? Because the A-stats change. Therefore, we cannot say what answer is represented. We cannot collect enough demand. So we compromise and use questions as the static surrogates for answers. Now it is possible to show what A-stats were showing at the times that each requestor arrived at a question and made an offer for the corresponding answer. AC can enable users to see this information. It can be important for deciding whether or not to supply an answer. Still, the problem remains; there is no perfect way to represent an answer, especially one that changes in time.

Q-Locations Created?

So does AC create a new Q-location using the A-stats that are entered along with a Q-string? No, not when A-stats are used as search parameters (search stats). Users in any mode can use A-stats as search parameters. To explain why Q-locations are not created with them, we will assume Rex is the one entering them. The same reasoning holds for users in other modes. When Rex enters A-stats along with a Q-string, the purpose is to find a question (and possibly an actual answer, if one has been supplied). Like the Q-string, A-stats describe an answer, which may be actual or missing. As discussed in chapter 3, what makes A-stat information different from Q-string information generally is that A-stat information describes aspects of an answer that are not expected to be supplied. Many important aspects of answers can be described by A-stats but cannot be supplied directly. We repeat some examples previously given because A-stats are important, and in many ways new. For example, Rex can ask for the answer to the question: Biography of Hans Bethe? Rex can specify an A-stat of: Good reviews. Sue cannot supply an answer with good reviews. Rex can specify an A-stat of: Most popular by sales. Sue cannot supply an answer with high sales. Rex can specify an A-stat of: No verified complaints. Sue cannot supply an answer with no verified complaints. Rex can specify an A-stat of: POE above $10. Sue cannot supply an answer with a given POE level. Rex can specify an A-stat of: Price under $1. Sue may be able to supply an answer at a given price. But she may not be setting prices. Price is an example of information that can be Q-string and or A-stat information. If the price is set by AC, then Sue, obviously, cannot supply an answer with a given price.

As noted, many A-stats can be phrased in terms of Q-string information. For example, Rex can specify in a Q-string that an answer is to be under a certain length. This information can also be specified as an A-stat. That does not affect the idea of A-stats. The user decides how to enter the information, as Q-string or A-stat or both. If the user decides to enter the information as an A- stat then it is understood that AC will not create a Q-location with the information. The bottom line is that Rex can enter A-stats to find a question (and corresponding answer), by matching the A-stats in the question's Q-record. If the Q-string that Rex is entering is new then AC creates a location for it. But AC does not create a new location for the Q-string + A-stats in the sense that has been previously explained: a place that AC takes users to when they enter a question, a place people select to find an answer, and a place people go to to supply an answer.

Pseudo Locations As noted, a Q-string plus search stats is called a Q+. AC can store a Q+ in memory. Further, a Q+ can have a record that contains key facts about the Q+, such as who entered it and when and how many people entered it. We call a Q+ and its record by the name pseudo location. A pseudo location is created in addition to normal Q-location, not in place of it. We use the term "pseudo" because AC does not take users to this location when it matches questions to Q- locations and when it matches Q+'s to Q-locations. Why create a pseudo location then? The main reason is that it can be used as demand information. A Q+ can be stored as a come-from-Q, a come-from-Q+ that is. In other words, it shows what search stats a user entered in order to arrive at a given question. And it can show what search stats a user entered in order to get a given answer. For example, it can be valuable to know that 25% of people who bought the answer to Biography of Hans Bethe? included a search stat of Good reviews.

AC can keep statistics about what search stats were entered by people who arrived at a question in the Q-record of that question. And AC can enable users to call these statistics up from a given Q-record. Seeing what A-stats were entered in the search of an answer can be valuable demand information for suppliers. Let's pretend an answer is a certain kind of blender and that each buyer has to fill out a questionnaire about why he bought. Now if 43% of buyers listed as a reason for buying that the blender had gotten a good review in Consumer Reports, and 71 % listed price as a reason, then that is valuable information. The same principle applies to answers. Now no one buys anything for one reason. There are multiple factors and it can be useful to see which ones a given buyer lists. Using the metaphor above, it can be useful to see the individual questionnaires, as well as the combined statistics from multiple questionnaires. Thus it can also be valuable to enable users to call up the come-from-Q+'s of a given question. That way users themselves can see the Q+'s that led people to the question. And so, as an A-stat option, AC can enable users to call up come-from-Q+'s. We picture a Q+ in figure 5.14 as a thin-line circle 160.

5.1k Entering Multiple Questions to Correspond to a Single Answer

A user may want to enter more than one question to correspond to the same answer. For example, a user who enters Who is Spiderman's alter ego? might want to enter other similar questions, such as, In Marvel Comics, who is Spiderman's alter ego? or, Who's the man behind Spiderman's mask?. (If Rex enters the additional question(s), his purpose can be to find a good matching question. He may also want to let other Rex's find his question in order to pool demand for the same answer. If Sue enters the additional question(s), her purpose can be to enable Rex's to find the answer that she puts in.) Hence, AC can enable a user to designate that the next question to be entered corresponds to the same answer that the current-Q corresponds to. AC can include a command that might be labeled Synonym Question which the user selects to designate that the next question entered is a synonym of the current-Q. As explained in Book II, AC can create a link between these questions called a synonym link. As seen in figure 5.15, it is also possible for AC to link the questions 170, 171, 172 indirectly through the actual answer or missing answer 173.

5.11 Comparison Questions AC can enable users to enter what we will call a comparison question (comp-Q). A comp-Q is shown along with the current-Q. It can become the current-Q, if the user selects it to be. AC can also enable the user to select a question on screen and designate it a comp-Q. The purpose of the comp-Q, as the name implies, is to be compared with the current-Q. For example, the current-Q might be: What's causing this traffic jam? and the comp-Q might be: What's going on, goddamnit, on the Ten?.

AC can include a comp-Q button 119 that the user selects before entering a Q-string. After pressing this button he enters a question just as he enters a question to be the new current-Q. The comp-Q is shown on screen and, as with a new current-Q, AC searches for a match. AC can then show certain key match stats and A-stats about the comp-Q, or the user can ask to see these stats. Upon seeing these, the user can then decide if he wants to make the comp-Q the current-Q. If so, he can select it and enter Go. Now if he is dissatisfied with the comp-Q, he can erase it and enter another. As with the current Q, he can edit it and hit Enter after the editing. AC can also enable him to copy the current-Q into the comp-Q area on screen and then edit the question to create the comp-Q. The comp-Q option can be quite useful for it enables a user to easily compare the key stats of two questions. AC can also enable the user to link the current-Q and the comp-Q in various ways, but we save this possibility for Book II. Now in the matter of creating a Q- location for the comp-Q, AC does so by the main rule of creation discussed above, even though the user might not go to the comp-Q. For example, if the user is a requestor and the question is new, AC still creates a location, complete with Q-record. However, what is registered in the Q- record may be different than what is registered when the user goes to the question.

5.1m Auto-Questions

AC can include a type of question that when entered causes AC to create more questions based on the information in the original question. We call questions that are created in this way auto- questions (auto-Q _). And we call a set of these questions an auto-set. A question that causes AC to create an auto-set is a seed question. For example, say a user enters, Jim's phone number?. From this AC can create numerous questions about Jim: Jim's address?, Jim's age?, Jim's job?, and so on. AC creates a Q-record for each of the auto-questions and for the auto-set altogether. Now we assume that the user has designated a land where this first question is a seed question. To enter a seed question, a user has to enter subject information into a given named field. The subject information is used to create the auto-set. This is illustrated in tables. Tables

Tables of answers can be very useful to have in AC. A table can be made up of answers entered to correspond to auto-sets. The key feature of tables in AC is a potential auto-set of questions, more conveniently thought of as a blank row. A blank row is made up of a set of blank named fields. For example:

Product Store Price

A row will have at least one subject field. In the case above, we will say that the subject field is the product field. Once the subject field is filled in, it implies — and AC creates — an auto-set of actual questions. For example, if product field is filled in:

Walkman X Store Price we have a set of questions: Where is Walkman X sold? and What is the price of Walkman X?. Of course, more than one field can be filled in, which can make for different questions. For example:

Walkman X Circuit City Price

Walkman X Luskins Price are different questions: What is the price of Walkman X at Circuit City? and, What is the price of Walkman X at Luskins?. As more fields are added to a row, more individual questions are created. For example, if we add a phone number field above, we have the questions: What is the phone number ofthe Circuit City that sells Walkman X? What is the phone number ofthe Luskins that sells Walkman X?

Questions are defined by the information in a row that is missing from blank fields and by the information that is present in filled fields. In order to enter an answer, Sue can name the table or enter a seed question. AC then presents her with a blank row that she can enter her answers into. Though questions can look like answers — because they both can have the same information — AC does not use the same table for questions and answers. AC stores questions and answers distinctly from each other.

A Multitude of Questions

A multitude of questions can be used to search a table and process the answers in a table to yield other answers. There are plain old questions, where answers are asked for and outputted by direct lookup, for example, finding the price of a given product. And there are FB-Q's, for example, finding the five lowest prices in a list of prices. Regardless of the great variety of particular questions, they all use the same named fields as are in the table. AC creates Q-locations for all these questions, using the information that is filled into the fields. The rules of creation are the same as discussed before. (The creation of FB-Q Q-locations is discussed in section 5.4.) (Note: Table structures and the meta-rules of their operation are set up by system operators. AC can also enable users to set up their own tables.) 5. In Entering and Linking Questions

AC can enable questions to be entered and linked to one another. There are two categories of links which we'll call form links and named links. A question can be linked to others by form link and by named link. Linking questions is a big topic because linking questions in certain ways can provide solutions to the problems raised in the previous chapter. As noted, Book II is devoted to the linking of questions and so we do not dwell on the topic here. The main point to make now are that questions can correspond to each other and not only to answers.

Entering Name Linked Questions

We have discussed form links above. The second type of link is what we call a named link. Here a user can enter a question and link it to an existing one with a link that is named to reflect the semantic relationship between the two different question strings. For example, a synonym link means that the user considers two linked questions to be synonyms of each other. Named links are a broader category than form links. In fact, form links can be considered special cases of named links.

Preview of What Will Be Described in Book II

As discussed above in sub-section 5. Id on the matching of questions, there can be a profusion of potential matches to a given question. How then to match a question against existing questions? The solution of Book II is a semantic-economic one, using links between questions. We preview the solution here because we refer to linked questions throughout this chapter, and it is useful to have some context as to how they are used. We use the small example of just two similar questions: 1. Daneel Olivaw's phone number? and, 2. R. Daneel Olivaw's phone number?. As noted, AC enables users to link pairs of questions by naming the semantic relationship between the questions involved. For example, a user might enter both of the questions above and link them with a synonym link. Or a user might enter one of these questions and AC might tentatively match it to the other that, say, is already in the system. The user, seeing the tentative match, can then link the two questions with a synonym link.

Assume then that both questions are in the system and are linked with a synonym link. And assume that a user arrives at Daneel Olivaw's phone number?. He can ask to see synonym questions. AC then shows him, R. Daneel Olivaw's phone number?. He can then travel to that question. At each question he travels to he can express interest in the answer. Linked questions have their own separate demand records, but of great importance, the information in the demand records can be combined. For example, say that 7 people have landed on the first question and that 5 people have landed on the second. There are 12 different arrival requests. Some of the same people who landed on the first question might also have landed on the second. And so a combined tally will not have the value of 12 requests by 12 different people. We cannot give any universal rules for how demand information is combined, but we do recognize that it can be combined in useful ways. Thus our "net" of two questions has a combined amount of demand. A person who might want to enter the answer to the first question knows that there may be extra demand from people who arrived at the second question.

Let us say then that someone enters an answer to the first question. (She might also enter the same answer to the second, but we disregard that possibility here.) Now, when someone is at the second question, which we assume has no answer, he can ask to see an answer to a synonym question. AC can then take him to the first question and show him that the first question has an answer. Or, AC might just output the answer to the first question, depending on the output rules in that situation, and on what he has asked AC to do. Now in this simple example, we have used the only two questions and so the linking is simple. What if there were thousands of potential match questions. Would we connect them all to each other directly? If we did we would not be solving our problem. We do not need to link them all directly but can do so indirectly. The links are a kind of match. We then allow users to find questions and answers by traveling along links or "jumping around" question nets. As users travel they can express demand for answers at different questions. Now this idea alone will not work for we will have networks of linked questions but with no question having more matches (no greater expression of demand) than another in general. And so we add economic signals. For example, we allow people to see which questions have more demand than others. And we allow people to specify travel destinations according to economic information, according to the most popular destinations, for example. People can then intentionally pool demand on given questions. A question may be favored for no good reason initially, but people can join in because it pays to pool efforts rather than only express interest in one's own question. If the pay-off rises high enough, an answer may be supplied. This answer can then be found through linked questions.

Another thing that can happen is that no question may have much more demand than another. Yet a supplier may enter an answer to a given question, seeing the combined demand of a "net." The answer can then be found through other, linked questions that make up that net. Of course, the situations can get more complicated than this. The use of demand information as a specifier to find a question and/or answer is just one example of the ways people can find questions and answers in a question net. The point we make here is that we do not need to find the "best" match for a given question out of a large set of potential matches. "Best match" is a mirage in most cases. If we link the questions in certain ways and allow people to find the questions through the links in certain ways, we can solve our matching problem well enough. 5.2 THE Q-A INPUT PATH, ENTERING AND STORING ANSWERS

There is one basic input path for entering and storing answers in AC. We will call it the Q-A input path. We say basic because while the details of entering answers may differ the essential idea remains: a question is identified and an answer is entered to correspond directly to that question in memory. The details of the Q-A input path will vary depending on the land of AC and on the answer involved. For example, in certain lands, AC might assume by default that Sue wants to supply an answer to the question she has entered, simply because she has selected supply mode. The particular series of steps for inputting a given answer can be called an input structure. Because answers vary greatly, input structures can vary greatly. For example, the steps for entering a phone number, an article, a blueprint, and a video tutorial will likely be different. More importantly, the rules for storing answers can vary widely regarding how the stored answers are found and sold. Thus, "basic input path" refers to numerous variations on a single theme.

5.2a The Q-A Input Path

(Entering an Answer to Correspond Directly to a Question) To enter an answer Sue must be at a question other than the null question. She may have created the question in order to enter her answer. Or she may have arrived at a question someone else has created. Once she is at a question, she selects the option AC includes for entering an answer. Once she selects this Enter Answer option, AC enables her to enter an answer. She then enters an answer, and AC stores it and links it directly to the question in memory. We might also say that AC stores the answer directly under the question. This answer is a direct answer to the question. And the question is a direct question to the answer.

Direct answer in a sense is defined by the inverse operations of finding the answer and getting the answer for output. We can think of a dictionary where words are questions and definitions are answers. A definition can be found directly under a word; it corresponds directly to the word. It is in this sense that we mean a direct linkage or direct correspondence between a question and answer. As we know from any dictionary, there can be many different definitions stored under a word. In a conventional dictionary, definitions are ordered. Like a conventional dictionary, AC can have multiple answers for a question. However, unlike a conventional dictionary, ACs rules for presenting answers can vary widely and are not usually a visual ordering, as in a conventional dictionary. (Note: we use the term "conventional" dictionary because AC can be considered, among other things, a new, unconventional dictionary.) We discuss the issue of multiple direct answers a little later below. For now our point is that an answer is stored under a question so that a user who arrives at the question can ask to get the direct answer. For example, say a question is:

What is a two word weather report for the summer in Washington, DC?

Sue arrives at this question. She then enters her answer: Hot, Swampy.

Then when Rex arrives at the question, he can get the answer: Hot, Swampy.

Let us make a few notes about terms. When we say that a question has an answer, we mean that a direct answer has been supplied and stored for that question. When we say that an answer is at a question, we mean that a direct answer has been supplied and stored for that question. When we say that an answer is missing, we mean that no direct answer has been supplied and stored for that question. When we say that a question has a missing answer, we mean that no direct answer has been supplied and stored for that question. Sometimes, we will use the terms direct actual answer, and direct missing answer. Usually it should be clear from the context whether we are referring to an actual or missing answer.

5.2 b The Q-A-Record

To store Q-info (A-stat information) about Sue's actual answer, AC creates a new record, which we call a Q-A-record. This record is a sub-record of the Q-record. We sometimes call the information in the Q-A-record by the name Q-A-info. But this name can be misleading because the Q-A-record is a subset of the Q-record. So Q-A-info is also Q-info. We use the term Q-A- info because it is simpler than saying "Q-info about an actual answer." Most all the A-stats that apply to a missing answer also apply to an actual answer. Thus much of the information registered for missing answers is registered for actual answers. For example, the Q-A-record will have a demand record pertaining to Sue's actual answer. However, numerous additional A- stats are registered about an actual answer that cannot be registered about a missing answer, such the length of the answer, the price of the answer, sales of the answer, complaints about the answer, and so on. (Sometimes we will use the term actual-answer statistics (A-A-stats) to refer to A-stats that are registered about an actual answer. Usually we let the context dictate what the A-stats are about.) There are three main purposes for storing information about an actual answer: 1. to describe the actual answer, 2. to keep track of royalties owed, and 3. to give information about potential other answers to the question.

It is because the Q-A-record is used to provide information about potential answers that the Q-A- record is a sub-record of the Q-record. We elaborate on this point later. Since one of the purposes of the Q-A-record is to store royalty information for Sue's answer, the Q-A-record includes a credit record where royalties are registered. The credit record may include citation information pertaining to answers that get a share of the royalties from Sue's answer. We discuss this point later as well. How is information registered in the Q-A-record? Most information is registered when users, especially Rex's, react to Sue's answer. How users react to her answer depends on how it is presented. And there are various way AC can present an answer. We will discuss this topic later as well. Some information is registered automatically when Sue enters her answer. Examples are Sue's ID data, the time of entry, and the length of the answer. Other information can be entered by Sue. We discuss this kind of information next.

5.2c Entering Supply Stats

Certain A-stats can be entered by Sue along with her answer to describe the answer. When A- stats are used this way, we call them supply stats. Examples of supply stats are the source of her answer, quality assertions about her answer, the price of her answer, and so on. For example, she may supply the answer to the question, Short Biography of Hans Bethe?. As supply stat information, she might enter certain keywords, such as physics great, Los Alamos, Cornell, Longest active career, etc. Keywords are a small example of supply stats, but they illustrate well that supply stats can describe various aspects particular to Sue's answer.

To enter supply stats, Sue selects a command 120 that AC includes for supply stats, and AC then presents her with a form for entering them. Or, AC automatically provides her with a supply stat form when she enters an answer. The supply stat form may be broken into many sub-forms: a form for price, a form for quality assertions, a form for keywords, and so on. AC stores the supply stats she enters in the Q-A-record for her answer and displays them when necessary. They are seen by others as A-A-stats for her answer. Depending on the rules of the land that Sue is in, she may be required to enter certain supply stats. For example, she may be required to set a price for her answer.

(Note: Price can be considered a special kind of supply stat because it can change and vary in many ways, more so than other supply stats in general. Another thing that separates price from other supply stats is that it involves transaction procedures, sales that is. Still, while price does have a special role, we put it in the category of supply stats because it does describe an actual answer, and because Sue can enter it. We explain the role of price more in chapters 6 and 7.)

Supply stats are different from other A-stats in that they can, in theory, have been asked for in a Q-string. Unlike many kinds of A-stats, they describe aspects of answers that can be supplied by a user. Sue can change supply stats. Price is the most obvious case, but other stats are changeable as well. For example, Sue may change quality assertions that she makes about her answer. In order to change the supply stats, she must identify her answer, and press the supply stat command. AC then presents her with the supply stat form which she can use to change given supply stats. 5.2d A Q-A-record Is a Subset of a Q-record

As noted above, one purpose for collecting Q-info about an actual answer is to create A-stats that describe that answer. These can enable Rex to decide whether he wants to buy the answer. They are product information. The A-stats also enable Sue to monitor her answer. Through A-stats, she sees reaction to her answer. She may then decide to change it in some way, or to change the price. While this purpose for gathering Q-A-info is obviously essential, there is another essential purpose: to provide information for helping users decide whether to enter another answer to the question (for example, an improved answer). Thus the demand information in the Q-A-record does not just apply to the actual answer. It also applies to potential answers. It applies to answers that might replace the actual answer. It applies to answers that might improve on the actual answer. It applies to answers that might be completely different from the actual answer. Demand information is not the only Q-A-info that is useful for a potential supplier to know. She must answer two key questions about a potential answer: 1. What answer should I supply? and 2. How much will I get for supplying it?

AC can provide a POE for telling her what she might get, but AC cannot tell her what answer to supply. This she needs to figure out from common sense. Seeing various A-stats about an actual answer and seeing the actual answer itself can obviously help her make guesses about these two questions. We see this principle with most any physical product, of course. The sales of a product give us the best clues about what the sales of similar products will be. And the product itself gives clues as to what an improved product should be like. Information gathered about a single actual answer is not the only information that is relevant to deciding whether to enter an another answer to the direct question. First of all, there is information that was gathered before any actual answer was supplied. Second of all, there may be multiple direct answers supplied. Q- A-info from all these is collected in the master record, the Q-record. Third of all, even when an answer is supplied to a question, AC may not initially present that answer to a user who arrives at the question, and may not initially register information in the Q-A-record. AC may only register information in the Q-record. Thus, while a Q-A-record is differentiated within its Q- record, it is just part of the combined set of information in the Q-record that enables users to evaluate potential new answers.

(Note: The exception to this rule occurs when Sue enters a question and answer and no other direct answer has been entered. Then the only information that is registered may be about that actual answer. As mentioned, what is registered depends on how AC presents the answer and how AC registers information in the Q-record and Q-A-record.) We can see why a Q-A-record is a subset of a Q-record by taking the example question: What is today's weather report?. Assume that there are 10 requests for the missing answer to this question. Now assume someone supplies an answer, and assume that there are 10 more requests from different people. And so we have a total of 20 requests for the answer, half when it was missing and half when it was present. The combined tally may help make a more accurate POE for a potential updated answer than one of the tallies alone. Demand for today's actual weather report might apply to demand for tomorrow's potential weather report. And the demand for the past 100 actual weather reports might apply to the demand for tomorrow's weather report. Each past report is a distinct answer to the direct question, while tomorrow's potential report can have a POE based on the sales of these past reports. The demand records of all the past reports are combined in the Q-record. As shown in figure 5.16, when we picture an actual answer 180 being supplied to a question 181, we show a Q-A-record 182 along with the actual answer. We also show the Q-record 183, for it is the master record. And we also show a blank box 184 signifying a missing, potential answer. A potential answer always exists. (Unfortunately, the idea that the Q-A-record is a sub-record does not come out well in the figure because the Q-A-record looks totally separate from the Q-record. Later we will introduce the idea of a Q-A-location. So the figure is a compromise.) Now it is easy to say that the Q-A-record is a subset of the Q-record, but what does that mean? How is the information used? Well, we cannot say. The best we can say here is that it is combined. The ways is can be combined and used are far too various to describe, or even know much about. There is little experience in this area.

As discussed above, the key questions that Sue wants to answer for herself are: 1) What answer should I supply? and 2) How much will I get for supplying it? (There are many other things Sue may want to find out about, such as what price she should set for her answer, but the two key questions are the ones above.) We cannot say much more than that the Q-A-record is a subset of the Q-record because we cannot say much about how the combined information will be used to make guesses about these two questions. That is because there is far too much variety in potential answers to a given question, and far too much variety in the way answers can be sold, and far too much variety in the way royalties can be shared. We will take up these issues briefly next.

5.2e The Endless Answers Problem Revisited

When we consider how AC might enable users to enter more than one direct answer to a question, we run right into the endless answers problem. Endless answers reality is another term for it. The reality is: If we take a question and supply an answer, we find that endless other answers can also satisfy the question. There are numerous sub-problems posed by this reality. We have discussed some of them in chapter 4, especially those regarding the collection of demand information. Regarding the storing of more than one direct answer, the problems posed are: a. How to present an answer for sale? and b. How to assign royalty credit when it is sold? That's because, in AC, a storage procedure for an answer is defined in terms of how the answer is found, and sold, and credited with royalties. For example, if there are 2,000 answers to the question, Movie Review of Casablanca?, how is AC to present them to Rex? And let us say that many of the answers borrow from other answers. How then is royalty credit to be split, given paraphrasing and perhaps verbatim copying? Let us give some example questions to see the problems. We will just give questions and imagine that someone has supplied an initial answer.

What is today's weather?

Now, what if someone enters an "updated" weather report that changes just a few facts? How shall we give credit to the first answer? What if the updated report is very different, a "new" weather report?

How high is Longs Peak?

Now what if someone enters a "corrected" figure? What if there is a debate on the definition of height? What if there are hundreds of measurements?

What is the price of Walkman X?

Now what if someone enters the same price as the initial price? The second price might be considered a useless repeat of the first, but then we might also call it a valuable confirmation.

What's a photo of Old Faithful?

Now let's say someone provides a second photo which many people prefer to the first photo?

Should the first photographer be paid? What if the second photo isn't that much different from the first? What if it is very different? Of course we don't know what different means in any definite sense, so that poses a problem in deciding what to do.

Short Biography of Hans Bethe?

Now what if someone enters a second biography that adds to but does not change the first? What if the new biography only differs in that it corrects some mistaken footnotes in the first biography? What if the new biography is a translation? What share of royalties should the translator get paid?

How do you get to Chicago fastest from Washington, DC, by car?

What if someone enters an answer that copies the first but changes a just a 5 mile stretch going into Chicago? What if the two answers share only one road?

These examples are a very meager selection. For most any question, one can think of a fantastic variety of different kinds of answers. We have not even discussed the difference in efforts to arrive at different answers, or ways of evaluating how much people care about the differences.

We know so little about classifying the differences between answers and so little about paying for improvements that we cannot say what are the best ways to present and give credit to answers. There are no universal rules. Yet, we can say that AC requires certain kinds of rules and functions for any scheme of enabling users to enter more than one answer to a question. Before, discussing these, we should mention that users can enter answers under different questions rather than under the same question. Using different questions is a fundamental way of differentiating answers. This does not completely solve our problem, for the basic issues remain: how to present the answers and how to credit answers. Moreover, we still need rules for how more than one answer can be supplied to a given question, because even when we use different questions, we still need to accommodate the possibility of a better answer to a given question. Generally, it will not work to reserve for eternity one answer to a given question.

5.2e Rules and Functions for Storing Multiple Answers to a Question

There are numerous ways AC can store multiple direct answers to a question. The variety comes from the various kinds of rules there can be for presenting the answers and for crediting the answers with royalties. While we cannot give any specific rules, we can say that AC requires four kinds of rules and functions. (Note: When we say rules, we mean both meta rules that users understand and internal system rules that are required for implementing the meta rules. Often we call internal rules functions because they involve sets of steps for carrying out the meta rules.)

1. A Second Rule of Creation, Creating a Q-A-record

AC creates a Q-A-record for each actual answer supplied. This rule was discussed above. We may call it the second rule of creation, in contrast with the main rule of creation, which is to create a Q-record for any new question. Thus, different actual answers to the same direct question are all stored under that question and are differentiated by their A-A-stats. (Another way of looking at the situation is that AC creates a Q-A-location for each answer. We discuss this idea later.) (Now, in certain cases, where changes are made to an answer, AC may not create an entirely new record, but that is not really to the point. We will assume that AC creates a new Q- A-record whenever Sue changes the content of an answer.)

2. Copy/Credit Rules

If Sue uses another answer in her answer, which can happen in a great variety of ways, then AC needs rules for enabling Sue to give royalty credit to that other answer. These rules are also discussed in chapter 14 on property rights. Copy/credit rules illustrate how AC operates by meta rules and internal rules. By meta rules here we mean rules that tell Sue when to give credit to other answers. By intemal rules we mean functions that AC has for enabling Sue to enter citation information and functions for automatically crediting another answer with a share of Sue's royalties, when Sue's answer is sold. For example, if Sue uses a long quote in her answer, then she may have to assign a share of her royalties to the owner of the quote. It is by ACs guidelines for the sharing of credit that Sue understands what to do. It is by ACs credit functions that the royalty payments are transacted. Copy/credit rules are the hidden regulators ofthe answers that are supplied to AC. Why is that? Because a person will enter an answer based upon how much she thinks she will make when it is sold. How much she will make depends on how much she has to pay to other answers. Thus, ACs rules for defining copying are fundamental aspects of the system. One hesitates to call them part of the system in that they are almost always meta rules. But still, they are fundamental in determining what answers get entered. When we say copy we do not mean in the narrow sense of a copyright infringement, we are thinking more in terms of patent infringement, and yet we are thinking of more. It is an area that needs exploration. We need to discover better rules for paying for improved answers, while giving enough credit to the original answers that the improvements are based on (see chapters 8 and 14). We cannot give any rules and say only that experimentation seems to be the best policy. In some cases, AC can have "what the market will bear" rules in which Sue's answer is compared to another answer. Rex can choose between two answers and explicitly pay for an improvement.

3. Challenge Rules and Functions

ACs meta rules are rules that users need to follow in order for the system to work. For example, Sue may be expected to properly cite a given answer as deserving a share of the royalties that her answer gets. The meta rules tell her when to do this. Where meta rules are concerned, there must be ways for determining whether users have violated the rules. There can obviously be disputes, for money is involved. And so, AC needs means for enabling users to alert system judges to problems. And AC needs means to allow system judges to rule on matters. AC has its traffic rules; it's right of way rules, so to speak. Instead of police roaming the streets, users themselves spot infractions. They can complain to system judges. Unlike traffic situations on the streets, evidence is available and can be evaluated. In other words, AC needs rules and functions that enable users to challenge the actions of other users. This is especially evident where users supply competing answers. These points, of course, apply to any meta rules and not just those involving the supplying of answers. The need for challenging procedures is discussed in various places.

4. Show and Sell Rules

If more than one direct answer can be supplied to a question, AC must have rules for how the answers are shown when a user arrives at a question, and rules for which answer is sold when the user requests one for output. (When we say that an answer is shown, we mean that A-A-stats for the answer are shown. When we say that an answer is sold, we mean that it is outputted.) To repeat a previous point, these rules are part of storage rules, because how an answer is shown and sold is part of how it is stored. While the name does not seem to have anything to do with storage, we will call these rules show and sell rules. The importance of show and sell rules in AC can be seen by analogy when we think of a printed product catalogue. In a catalogue for, say, office supplies we see headings for various kinds of products. Under a heading for Pens there might be descriptions of a dozen different kinds of particular pens. Obviously, it is crucial to the sales of a given kind of pen how the pens are displayed, and more important, whether they are shown at all in the catalogue. We can presume that many manufactures might want to get their pens in the catalogue but cannot because of the catalogue company's show and sell rules. AC is different than a static print catalogue of course, but the problem of presenting choices remains. While AC can show partial A-stats for more than one answer at a time, the number of answers whose A-stats can be shown at once is severely limited. Thus AC needs rules for selecting which answer(s) to show A-stats about.

AC also needs selection rules for which answer to output. (AC can output more than one answer at a time, but for simplicity, we will assume that only one answer is outputted per output request.) The user may choose the answer, or AC may choose the answer. When AC chooses the actual answer, then AC obviously needs rules for selecting the answer out of a set of possible answers. While show and sell rules mean selection rules that apply to direct answers already in AC, they can also mean rules for restricting what answers are allowed to be stored for a given question. In other words, show and sell rules can include meta rules that define a satisfactory answer to a given question. Let us discuss this point briefly because it is a basic way of handling the endless answer problem. One way to handle the endless answer problem is to narrowly restrict the meaning of questions. By tightly restricting definitions, users can have a good chance of knowing what answer to expect and what answer to supply. That does not mean that only one answer satisfies a given question, but that any answer entered has to match the conditions of the meta rules. For example, a rule in certain lands can be that an answer has to be true. Sometimes AC can judge whether a condition has been met. For example, a rule can be that an answer has to be under 100 words long. AC can judge whether this condition is met. Other times, as with a rule about the truth of an answer, AC cannot judge; and so AC enables users to file complaints about answers with a system judge. The judge may then rule that an answer is unsatisfactory and may penalize the supplier or take various other actions, such as allowing a different answer to replace the offending one.

As noted, AC can include numerous lands where different meta rules apply and where the same questions mean different things. Say questions are names. One land might then be a phone directory where each name corresponds to a phone number. Another might be an encyclopedia where each name corresponds to a subject. Another might be a geographical locator where each name corresponds to a GPS number. And so on. Now rules for defining the boundaries of answers to a given question need not be highly restrictive. But highly restrictive conditions are necessary when questions are not linked to one another. If definitions are not restricted — so that users can have a good idea of what answer to expect — then the endless answers reality will swamp the system because no one will have a good guess as to what answer to expect, or what answer to supply, to a question.

Aside: Avoiding Many Constraining Rules by Linking Questions As described in Book II, many of the problems caused by the endless answer reality can be greatly ameliorated by linking questions in certain ways. By doing this we can input and output as many answers as we want, but they will correspond indirectly to a given question. We separate the answers by giving them different question-labels but connect the question labels so that an answer can be found from more than one question. Though certain meta rules remain, they do not really limit the number and kind of answers that can be entered to correspond indirectly to a question. However, as noted, storing answers under different questions does not solve all our problems. Thus, show and sell rules apply to direct answers to linked questions.

What's Next

We will now discuss two general approaches to storing multiple answers to a question. These are just approaches, with no specific rules attached to them. One we call the unlimited answers approach. The other we call the current answer approach. In a sense they represent two poles of a spectrum of ways that multiple direct answers can be stored. One way is sort of a free for all. The other way is restrictive. In between these two approaches are countless others that vary according to the particular rules used to show and sell answers. After discussing these two approaches, we will explain a general method for making comparisons between direct answers to the same question. In all approaches, a central element is a Q-A-location, so we discuss that.

5.2 f Q-A-Location

Another way of saying that AC creates a Q-A-record is to say that AC creates a Q-A-location. By this we mean that AC creates a record and enables users to access this record (just as a Q- location means both a Q-record and that AC enables the user to access the Q-record). The term location here can be confusing though because the Q-A-location is not separate from the Q- location. A Q-A-record, as noted, is part of the Q-record. Thus a Q-A-location is part of the Q- location. Recall, a Q-location is made up of a question and a Q-record. When Q-record information is shown on the Q-display, we say that the user is at a Q-location. The Q-display shows options pertaining to that Q-location. The Q-display also includes options for accessing a given Q-A-record, and for getting the actual answer that the Q-A-record corresponds to. When the Q-display options apply to a particular Q-A-record, we say that the user is at a Q-A-location. We can also use the term current Q-A-location.

Thus the Q-A-location is both a distinct location in memory and part of the Q-location. If we think of the Q-location as a signomat, a picture on screen, we can think of the Q-A-location as a picture within a picture. We can think of the Q-A-location as an area on the signomat. When we say that AC finds or matches a Q-A-location, we mean that AC matches a Q-A-record. When we say that a user arrives at a Q-A-location, we mean that AC presents him with options for accessing the Q-A-record, and for getting the corresponding actual answer. A user does not so much go to a Q-A-location as a given Q-A-location is presented to him as part of the larger Q- location. When a user arrives at a Q-A-location he sees A-A-stats for an actual answer. He can "react" to the answer, for example by making an offer for the answer, or entering a complaint about the answer. In other words, when a user is at a Q-A-location, AC registers information in that actual answer's Q-A-record. When a user is at a Q-A-location, he is still at the Q-location, and so information is still registered in the Q-record. AC still shows options that pertain to the current-Q, and to potential answers, and to finding other Q-A-records, if any, that are at that Q- location. Thus, the term location is a bit confusing for the process by which AC creates a record for an actual answer and allows users to access that record, while the users are at a larger record, the Q-record. Still, we use the term location because it is convenient to think of a user going to a record. We can then think of the linking of records, for example the linking of Q-A-records, of Q-A-locations. We can think of a user going to a given Q-A-location to see A-A-stats about a given actual answer. How does a user arrive at a Q-A-location then? That depends on ACs show and sell rules, which we are going to discuss further below.

5.2g The Unlimited Answers Approach

When the unlimited answers approach is employed, Sue arrives at a question and enters her answer. AC creates a Q-A-record for it. The Q-A-record is differentiated from other Q-A- records by the A-A-stats for Sue's answer. We picture this in figure 5.17 where a question 185 has four actual answers 186 and Q-A-records 187. What distinguishes the unlimited answers approach are the ways users arrive at a Q-A-location, the ways an actual answer is presented, in other words. The main idea is that no location is preferred over another, at least not at the time of storage. Given ACs matching rules, and given the various search instructions entered by users, there will be Q-A-locations that are preferred, but we cannot say which ones in advance. (This is in contrast to the current answer method below where a single answer is preferred.) There are two general ways that users can arrive at Q-A-locations given the unlimited answers approach.

1. Arriving at a Question That Has No Q-A-location Showing Initially

AC can enable the user to arrive at a question and AC can show no Q-A-location initially. In other words, AC does not show any A-stats from any Q-A-record. AC instead enables the user to enter a command for scrolling through the Q-A-records at that question. Altematively, AC can enable the user to enter further search stats to specify a Q-A-location that AC can then match and present. For example, say that the question Rex arrives at is Short Bio of Bethe?. And say that there are 100 direct answers to this question. Say also that Rex enters a search stat of 5 cents. AC will then take Rex to a Q-A-location for a bio that costs 5 cents. Of course, AC may need other search stats in order to narrow down the selection to one Q-A-location. AC may will also have defaults for taking users to given Q-A-locations. For example, one default may be that AC takes the user to the more popular of two given Q-A-locations (of course, popularity can be defined in various ways, and we are just giving an example). It all depends on ACs matching rules.

2. Arriving at a Q-A-location Initially

The second way that a user can arrive at a Q-A-location is for AC to take him to the Q-A- location that best matches question or Q+ that the user has entered. In other words, AC matches questions and Q+'s against Q-A-locations and picks the best one it can find at that question. AC can present more than one match at a time. And AC enables the user to use the options for finding another Q-A-location. The only difference from above is that AC does present a Q-A- location initially. (There must be a Q-A-location at the question in order for this to happen.)

Automated Output

When Rex asks AC to pick an actual answer to output, AC chooses the best matching Q-A- location it can find. However, it may not find one because there may be no Q-A-records with adequately matching A-A-stats (see 5.3c).

5.2h The Current Answer Approach

The idea behind the current answer approach is simple: when a user arrives at a question, AC defaults to showing him A-stats about one answer out of a set of possible direct answers. We call this favored answer the current answer. The current answer is defined by meta rules which we call displacement rules. When Sue enters an answer to a question that already has a current answer, her answer is allowed to become the current answer if it meets the displacement rules. In other words, meta rules define what answers can displace the current answer. If there is no existing current answer, Sue's answer becomes the current answer. Displacement rules can vary widely. The idea is that they are designed so that a displacing answer is deemed "better" than the answer it displaces. Though better is very vague, it gets the idea across. A simple example of a displacement rule is that the current answer should be correct. If it is not correct, it can be displaced. For example, if a price is out of date, a new, correct price can become the current answer. Now AC cannot know about conditions in the real world and so Sue must say whether her answer deserves to be the current answer according to the meta rules. AC assumes she is right, while allowing others to challenge her judgement.

Sue enters a new answer by pressing a New Current Answer command that AC includes for enabling her to enter an answer. After she enters her answer, AC makes it the current answer, and the displaced answer becomes a past answer. (AC can alert the supplier of the displaced answer, who may want to challenge the displacement.) The current answer approach is an important way of restricting the answers that can be stored for a question. The approach can be used to enable a given Sue to "reserve" an inteφretation of the question for her answer, blocking out various other inteφretations. That does not mean that a single answer fits the question but that only a "better" version should fit (we have not escaped the endless answer reality, only narrowed inteφretations.) For example, assume that the current answer can only be displaced if it is found incorrect. Then, if a user desires to enter an answer to a question that already has a correct answer, the user has to enter the answer under another question. For example, if Sue intends to supply the answer to Russell Marker's phone number?, and there already is a correct phone number in AC for that question, Sue would have to enter a different question, though one that still describes her answer. She might enter, Russell E. Marker's phone number? (presuming of course that the Russell she has in mind has the middle initial of E) to store her answer under. So the first Sue who entered the phone number for Russell Marker "reserved" the meaning of Russell Marker as referring to a particular Russell Marker. The new Sue who wanted to use that question has to pick another question, Russell E. Marker. That's because her answer was no better than the first Sue's answer. We might say that they are equally valid. And so the first answer remains undisplaced. Thus, by the current answer approach:

Sue arrives at a question 190 and presses Enter Current Answer, she enters her answer 191, AC stores her answer and creates a Q-A-record 192 (a Q-A-location) for it which AC makes the Q-A-location people see when they arrive at the question. The previous current answer becomes a past answer 193, whose Q-A-record 194 remains and differentiates it from other past answers and the current answer.

Past Answers

Past answers have their own Q-A-locations, differentiated by the A-A-stats that are particular to their Q-A-records. When a user arrives at the Q-A-location for the current answer, AC can enable him to enter a See Past Answer command for seeing Q-A-locations of past answers. AC can then enable him to scroll through A-A-stats for particular past answers. Or AC may enable him to enter search stats for finding a given past answer Q-A-location. Therefore, even though a question has a current answer, users can still find past answer Q-A-locations, and can transact business there as well. How many past answers should be kept is a design decision. To limit the number kept, AC can charge Sue a storage fee for keeping her past answer or can keep only those that generate enough revenue to justify their storage.

5.2i Labeling Differences Between Two Direct Answers to the Same Question In many cases, when Sue wants to enter an answer, what she wants to do is change or improve on an existing direct answer. There can be so many ways that Sue can "change" or "improve on" an answer that these words cannot get the possibilities across. Instead let us just say that Sue's answer is different from a given answer. Now Sue may want to point out how her new answer differs from an existing answer. And AC may, in certain cases, require her to do so. (In Book II, we will discuss how AC can enable Sue to name the relationship between answers that correspond directly to different questions. Here we are not concemed with that. We are concemed with how Sue can express the relationship between two direct answers to the same question.) We give a method below that AC includes to enable Sue to express the difference between her answer and an existing answer to the same direct question. While there can be great variety in the details of this method, it is just a small variation of the basic input path. The difference is that, rather than arriving at just a Q-location, Sue arrives at a Q-A-location for the answer that she wants to compare her answer to. AC then enables her to describe the relationship between that answer and her new, different answer. Thus:

1. Sue arrives at the Q-A-location of the answer she wants to compare her answer to.

2. She presses a Change command that AC includes to enable her to signify that her new answer has a relationship with the answer at the current Q-A-location.

3. AC enables her to enter her answer. She enters her answer. AC stores it under the question she is at and creates a new Q-A-location for it.

4. AC takes her to the new Q-A-location. AC presents her with a form for entering a description of the difference between the answer she has entered and the answer at the previous Q-A-location she was at.

5. She enters a description of the difference. a. Her description can be taken from a list of standard descriptions that AC includes, for example: update, improve, add to, validate, more complete answer. b. AC can enable her to enter a description in her own words in which she compares her answer to the answer at the previous Q-A-location.

6. AC stores her comparison as an A-stat for both answers. In the new answer's Q-A-record, AC tells which answer the comparison refers to. For example AC might store, "an update of the answer with so and so A-stats." In the Q-A-record of this other answer, AC also stores the comparison and tells which the new answer is. For example, "updated by the answer with so and so A-stats."

In addition, AC can create links between two Q-A-records, as shown in figures 5.19 and 5.20. By links we mean that when a user is at one of the Q-A-locations 195, 197 he can travel on the link to the other 196, 198.

Answer History

Using the method above AC can keep a history of "changes" that have been made to an actual answer. The history is a chain of differences recorded in the Q-A-records of each answer in that chain. This is especially appropriate where the current answer approach is employed. Thus if the current answer has displaced another answer, the current answer can have an A-stat indicating what change was made. Each answer then, except the first, has a record of how it differs from the answer it has displaced. Insert/Delete Option

AC can also include a command that enables Sue to edit an existing answer. She presses this Edit Answer command, and AC enables her to edit the answer of the Q-A-location she is at. As above, AC still creates a new Q-A-record for her edited answer. In this case, AC also saves the insertions and deletions she has made, so that there is a record of the change. The record can be kept as an A-stat in the Q-A-record of her revised answer.

Alerting the Original SuppUer

When Sue wants to compare her answer to an existing answer by the method above, AC can automatically alert the supplier of that existing answer. The supplier may object to the comparison. The two suppliers may communicate about whether the comparison is appropriate. Also, Sue may want to contact the original supplier in order to get permission to make a comparison or to consult about a comparison. Of course, if Sue is the original supplier, if she is making a comparison to her own existing answer, and one to contact.

Note on Quality Control Labels

One way that any user can "change" an answer is not by changing the content of the answer but making quality comments about it. These comments can be crucial. For example, a comment might say, "Out of Date" or "Incorrect." Of course there can be far more detailed reviews of an answer. For now, the point is that answers can be substantially changed without actually changing their "content." A separate Q-A-record is not made in this case. Instead a comment is entered into the Q-A-record for the answer that is commented on. Quality control labels (comments are one kind of label) can be very important A-A-stats. Chapter 13 (when it is written up) will be devoted to them.

5.2j Brief Digression: What About the POE? If there are multiple direct answers to a question, then how is a person to evaluate the POE for a new answer to the question. For example, if the question is Movie Review of Casablanca?, and there are already several reviews supplied, how is a potential supplier to decide what the POE is for a another review? Of course, we cannot say generally. In this section what we have described are ways that AC can enable users to store multiple answers to correspond directly to a given question. The endless variety of potential answers remains. Questions do not identify single answers and so a given Q-record and Q-A-record do not apply to only one answer. The records do not even apply just to answers that can be stored for their question. They apply to a slew of "similar" answers that can be stored under a slew of "similar" questions. By the same reasoning, multiple Q-records can apply to the answer that Sue is considering entering for a given question. Thus, Q-records can be linked so that users can make guesses about the demand for a given actual answer that might satisfy Rex's who have entered different questions. In other words, multiple Q-records, especially demand records, can be combined to yield combined demand for an answer. We then have demand based on a question net, but this demand still must be collected at individual questions. When we think of question nets, which obviously have many differing questions, we can see that evaluating the demand collected in one Q-record is not necessarily the point. And whether one or more answers have already been supplied to a given question is not necessarily the point. There may be many altemative answers to consider, and they may be stored under different questions.

Why even have a demand record for a given question if it does not apply to a single answer? Well, questions are the only way we can identify answers. So we use them, while realizing their limits. Demand information stored under a given question many not apply to a single answer, but it can still help a potential supplier decide whether it is worthwhile to enter a given, actual answer. How a user evaluates the demand information depends on the situation. The altemative answers that have been supplied to the current-Q obviously are a factor to consider. So are answers that have been supplied to similar questions. There are a host of factors to consider. They not only include considerations of what a question means but also of ACs rules, like show and sell rules and copy/credit rules. A user must use common sense. But without ACs A-stats, especially demand information, common sense is blind.

5.2k Entering an Answer to Correspond Directly to Multiple Questions

As discussed in 5.1k, AC can enable users to enter more than one direct question to correspond to the same answer. We should note briefly, yet significantly, that when AC stores an answer to correspond to one of these questions, it can store the answer to correspond to the other questions as well. AC may have the user press a command for this to happen, or AC may do it automatically. We leave aside this matter until section 5.5.

5.21 Questions That Correspond to Answers with Multiple Parts AC can include a type of question that allows multiple users to contribute sub-answers (sub- A's) to make up a "larger" answer. We will call this type of question a combo-Q and this larger answer a combo-A. With combo-Q's the Q-A input path again remains essentially the same. However, AC requires procedures for putting together the sub-A's for output. In addition, AC needs to store each sub-A as a discrete entity that is tagged by Sue's ID data, so that she can be credited when her sub-answer is outputted. (Of course, AC requires royalty rules for defining how much credit each sub-answer gets.) A sub-A corresponds directly to the combo-Q in memory and is entered in the same way as a single answer: Sue enters the combo-Q and then enters the sub-A. For example, say Rex enters, What are the major steel companies in the US. ?, and designates this as a combo-Q. Then various Sues can arrive at the question and enter the names of different steel companies. Each entry is a sub-A and the full list can be outputted. The list can continue to grow and be updated. As another example, say a certain Sue enters, What's the news in Angola?, and designates it as a combo-Q. Subsequent Sues can then contribute their accounts, which can be differentiated in various ways, such as by time of entry and by author.

A combo-Q can be seen as a question where the unlimited answers approach applies and where the multiple direct answers under that question are outputted together. However, by having a special category of combo-Q's, AC can enable particular rules to apply that would not normally apply with plain old questions. The particular rules concern making it easy for people to enter answers to be combined with other answers. Such rule include copy/credit rules and presentation rules. We cannot give any particular rules but just say that when answers are to meant to be combined that different rules will apply than those for plain old questions.

Combo-Q's As Linked Questions

It is important to note that the sub-A's to a combo-Q can be differentiated by their own sub- questions. For example, the combo-Q might be: What's the news in Angola?, a sub-Q might then be: What's the situation with unexploded mines as of 6/6/96? another sub-Q might be: Dispatches by Flynn? If sub-questions are included in the scheme, a combo-Q is really a kind of name linked question where the sub-Q's are linked to the combo Q. A sub-A is then a "full" answer to its sub-Q, while it is also a sub-A to the combo-Q.

5.2m The Q-A Input Path for Linked Questions

Regardless of whether a question is linked to another or not, the basic Q-A input path applies: Sue arrives at a question, and then enters an answer, and AC stores the answer to correspond directly to the question. She may have gotten to the question by traveling through other questions, but that is beside the point. When a first question is linked to a second question and the second question has a direct answer, we call the answer an indirect answer to the first question. And we call the first question an indirect question to the answer.

5.2n Addendum: Invisible Test-Answers

As discussed in 5.1c, users may enter questions Q-locations just to test demand. We now consider a feature AC can include for enabling users to test demand for actual answers, rather than just answers represented by questions. In other words, we discuss how AC can enable Sue to create a fake Q-A-location for testing demand. Now when Sue enters an answer she creates a Q-A-location. The response of Rex's is then tested as demand information is collected at this Q- A-location. The problem is that it is only tested with one set of A-A-stats, the set a that applies to her real, actual answer. If Sue sets a price for her answer, for example, then she only sees what the demand for her answer is at that price. She may also want to see, hypothetically, who would have bought her actual answer if certain A-A-stats were different, such as product reviews and price. Thus AC can include a Test Answer command for enabling her to enter fake, hypothetical A-A-stats along with her answer to create an extra, invisible Q-A-location. When we say invisible, we mean that Rex's do not arrive at the Q-A-location, but that AC still collects certain kinds of demand information. In particular, AC registers how may times the answer would have been outputted by the MMA path (see 5.3) based on the hypothetical Q-A-location. To take a simple example, Sue can enter an answer and set a price of $5. She might also want to test demand at $2. So she presses Test Answer, and AC enables her to enter hypothetical A-A-stats to describe her answer. The A-stats can be supply stats and also A-stats that normally she cannot supply. In this example case she would enter a supply stat of $2 rather than the real, visible $5. Sue need not even have entered an actual answer. AC can enable her to enter just hypothetical A- A-stats. She can thus do market research based on a completely hypothetical actual answer that is described by the invisible, fake A-A-stats.

5.3 THE MAIN PATHS FOR OUTPUTTING ANSWERS

While there is one basic path for getting answers into AC, there are innumerable paths for getting them out and using them, especially if we consider function based questions. But here we ignore function based questions. They are discussed in the next section. Here we boil down the various ways into two basic output paths. (We might point out here that, as with the basic input path, details of the output paths can vary depending on the kind of answer.) Now when we say output path that does not necessarily mean that an answer is actually outputted. The answer may be missing. We are referring to the paths by which AC tries to get an answer to output. An attempt may or may not succeed. In other words, when we say output path we mean how Rex declares that he wants an answer and what AC does in response to that declaration.

5.3a Some Definitions

We call Rex's declaration an output request (o-request). Output requests are obviously a kind of request information. In describing the basic system of part I (chapters 1 and 2, that is) we did not worry much about differentiating request information. In this part (especially in chapter 6) we do identify many different kinds of request information and request situations. We do not simply think in terms of "requests." Request information encompasses many actions by users that do not involve a user actually asking to get a given answer. For example, when Rex arrives at a question the arrival alone is considered request information. Yet upon arriving, he may not ask to get the direct answer. He may just look at A-stats at that location. In other sections, for the sake of convenience, we sometimes us the terms "to request" and "a request" too loosely. The noun form especially is a more general term that does not always mean that the user wants to buy an answer. Because "a request" can be ambiguous, we use the term "output request" in this section to signify that Rex asks AC to output a given answer — missing or actual. And when AC attempts to output a given answer, we call that attempt an output request as well. That's because an output request implies an output attempt. As with the word request, o-request will have a noun and verb form. So, to o-request means that Rex asks to have an answer outputted, and it means that AC tries to output an answer. When a missing answer is found as a result of an o- request, we call that an o-miss. When an actual answer is found as a result of an o-request, we call that an o-hit. We must be a little careful here. An o-hit does not necessarily mean that an answer is outputted. That's because Rex may not have offered to pay enough for the answer. Either way, AC registers an o-hit.

5.3b The Human Matched Answer (HMA) Output Path

The human matched answer (HMA) output path is an awkward name. The path is so named because the user is the one who decides what answer is chosen for output. This output path is the inverse of the basic input path. Rex arrives at a question (Q-location). The Q-display presents him with options for seeing A-stats about the direct answer and with options for making and accepting price offers for the answer. He then decides whether he wants the direct answer. If he wants it he selects Get Direct Answer, the command AC includes for designating the HMA path. If no answer is there, AC registers a o-miss in the Q-record of the current-Q. If an answer is there, AC registers a o-hit. If Rex has offered to pay enough for the answer, AC outputs it. (As discussed, an A-stat may tell Rex whether the answer is in or not before he presses Get Direct Answer. Even if he knows the answer is missing he may still press the command to express his interest in buying the answer. Expressions of interest are elaborated upon in chapter 6.) Here we ignore the commercial aspects of the transaction, such as price offers. The point is that Rex decides that the information at a Q-location indicates that the direct answer will satisfy him. We might call the direct answer the directly matching answer. And thus we say that Rex has decided on the matching answer. Now, as discussed in section 5.2, a question may have multiple direct answers. In this case, AC potentially then can output multiple answers. But the simplest way is to output one. For simplicity, we assume then that AC outputs one answer per o-request (and that AC registers one o-hit per o-request). As discussed, there are a variety of ways that AC can present A-stats for actual answers. Regardless of the method used, if only one direct answer is to be outputted, we can generalize and say that Rex must be at a particular Q-A-location in order to use the HMA path. How Rex arrives at a Q-A-location is discussed in section 5.2. Get Direct Answer then applies to the answer at that Q-A-location.

Digression on Output and Charge Rules

We do not mean to short shrift the issue of how many answers Rex sees per o-request. Because there can be numerous, similar answers to a question, AC may enable Rex to see more than one answer, while only charging him for one. The output and charge rules can vary so widely that we cannot go into the possible variations. For simplicity we assume that AC outputs and charges for only one answer per o-request. The same applies to the output path below.)

5.3c The Machine Matched Answer (MM A) Output Path

The HMA output path is in contrast to the machine matched answer (MMA) output path. In the MMA path Rex determines the question and any search stats, but then leaves it up to AC to decide what answer best matches the question or Q+. The MMA path involves more output attempt possibilities than the HMA path because the direct answer to the current-Q is not the only candidate for output. The best matching answer may be at another Q-location. One of the key things that makes the MMA path different from the HMA path is that if AC finds that the best matching answer is missing, AC will look for the next best matching answer, and so on, until it finds an actual answer, or until it decides that there is no adequately matching actual answer. In the HMA path, Rex makes one choice at a Q-location (or Q-A-location). If an answer is not there, he must go to another Q-location (or Q-A-location). In the MMA path, AC may find numerous o-misses before it finds an o-hit. All the misses are best matching answers; they are matches of missing answers. Now there can be variations on this plan. AC can include defaults whereby, if the number of misses is greater than a threshold, AC will ask Rex to specify his question or Q+ better. Defaults may be helpful because missing answers will probably vastly outnumber actual answers in AC. In other words, questions will probably vastly outnumber actual answers.

A Few Definitions for Explaining the MMA Path

The source of an o-request means the question Rex is at, the current-Q, when Rex enters an o- request. Sometimes, we will also call it the primary source. A direct o-request means that the source of the o-request is a direct question to the answer that is o-requested. (In the HMA path every o-request is a direct o-request. In the MMA path, o-requests can be direct and indirect.) An indirect o-request means that the source of the o-request is a question other than a direct question to the answer that is o-requested. (Note: in section 5.2 we defined an indirect question and an indirect answer in terms of how questions are linked together. Here the term "indirect" has a broader meaning. While linked questions can be the sources of indirect o-requests, non- linked questions and FB-Q's can also be the sources of indirect o-requests.) The secondary source of an o-request is the question that is matched by an indirect o-request. In other words, when an answer is o-requested, and the direct question to that answer is not the source of the o- request, then the direct question is called a secondary source. (If there is more than one direct question to an answer, it is only the direct question that is matched that is the secondary source.) If AC finds an actual answer due to an indirect o-request, then AC registers an indirect o-hit in the Q-record of the secondary source. If AC does not find an actual answer then AC registers an indirect o-miss. We call these o-hits and o-misses "indirect" because the direct-Q was not the source of the o-request.

Sequence for the MMA Path

AC includes a command, which we call Get Best Answer, that designates the MMA path. (In certain lands, AC might default to the MMA path.) For simplicity, we assume that Rex presses Get Best Answer after he has arrived at a question. (AC may enable him to press it before he enters a question.) Search stats can be used along with the current-Q to search for an answer. Before hitting Get Best Answer, Rex can enter search stats or designate that background ones are to be used. As noted, we call the current-Q plus search stats a Q+. (Again we ignore the commercial aspects, but we note that when Rex uses Get Best Answer, he must also set a price threshold for the answer he wants to buy, unless he is restricting his search to a land where prices are uniform. In other words, Rex must make a price offer along with his o-request.) After Rex hits Get Best Answer, AC searches for the answer that best matches the current-Q or Q+. When we say AC searches for an answer, we mean that AC looks for the best matching answer whether it is missing or actual. In other words, AC searches for best matching Q-locations and Q-A-locations. If AC finds a best matching Q-location without an answer, that means AC has found a best matching missing answer. AC then registers an o-miss in the Q-record of that question and then looks for another match (if the matched question is not the current-Q, AC registers an indirect o-miss). AC keeps going until it finds an actual answer, or until it determines that there is no adequately matching actual answer. If AC finds an actual answer, it registers an o- hit in the Q-record and Q-A-record of the matching question and answer. Thus, if the matching answer is not a direct answer to the current-Q, AC registers an indirect o-hit.

The Best Matching Answer Might Not Be at the Current-Q

Though Rex is at a current-Q when he hits Get Best Answer, AC will not necessarily find that the current-Q has a best matching actual or missing answer. Even if an actual answer is there, AC may not choose it as the best available answer. Any matching answer depends on what search stats, if any, Rex has entered, and on the altemative answers that exist, and on ACs matching rules. (Off the point somewhat, we note that one important reason Rex may use the Get Best Answer command is because there is no direct answer to the current-Q.)

A Way to Pick From Among Multiple Direct Answers

As discussed, the current-Q may have multiple direct answers and no current answer. If so, Get Best Answer can be a way that Rex lets AC pick from among the direct answers to the current- Q. Thus, AC may also have a separate command, Get Best Direct Answer. This command applies in cases where there are multiple direct answers and Rex has decided that he wants one of these and not an answer at another Q-location. While Rex has picked a direct answer, we still consider this a machine matched answer.

Not Bothering to Show a Q-location

A convenient variation on the sequence of entry above is for AC to enable Rex to enter a question or Q+ and then hit Get Best Answer without seeing the Q-location AC normally would take him to. That's because Rex may not be interested in seeing anything at a Q-location. He may just want to see an answer. In this case, unseen by Rex, AC makes the new question the current-Q as if Rex had entered the question without also hitting Get Best Answer. AC registers the necessary information, as discussed in section 5.1. For example, if the question is new to the system, AC creates a Q-location for it. AC still searches for the answer that best matches the question entered. Rex will only see the answer, if any, that is found. If no answer is found, AC tells Rex and Rex can keep entering questions and Q+'s, until an answer is found. In order to designate this option, Rex might enter two commands such as Get Best Answer and See Answer Only.

5.3d Registering O-requests

Registering an O-request in the Q-record of a Direct Question

When an answer is o-requested, AC registers whether the o-request is direct or indirect. And AC registers whether the o-request is a hit or a miss. And AC registers whether the o-request comes from the HMA or the MMA path. AC registers these things in the Q-record of the direct question to the answer that is o-requested. In the case of an indirect o-request, AC also registers what the source of the o-request is. In other words, it registers the primary source of an indirect o-request in the Q-record of the secondary source. Registering the sources of o-requests can be useful information that enables users to see what questions people have asked in order to buy, or try to buy, a given answer. For example, say the source of the o-request is: Movie Review of Casablanca?. And say the answer that is o-requested is the direct answer to the question: Movie Review of Casablanca by Kael?. Then the primary source of the o-request (Movie Review of Casablanca?) is registered in the Q-record of the second question. AC can also register Q+'s as sources of o-requests.

Registering an O-request At the Source

In addition to registering an indirect o-request in the secondary source's Q-record, AC also registers the o-request, and it's result, in the Q-record of the primary source. For example, if Rex is at the question, Movie Review of Casablanca? , and presses Get Best Answer, then AC registers the o-request in the Q-record of that question and registers that the o-request is indirect, and registers that that question is the source.

Registering O-misses Due to the MMA Path The MMA path can potentially lead to a great number of o-misses per o-request, as AC tries to find the actual answer that best matches Rex's question or Q+. Before AC finds a question that has an actual answer, it may find hundreds, thousands, millions of questions that are better matches, but whose answers are missing. That can be a problem because the value of each o- request can depend on how many other o-requests have gone along with it. For example, if someone expresses interest in 200 different hypothetical shirts, that does not mean that the person wants 200 shirts. He may only have interest in one shirt. The value of each expression of interest thus can depend on how many other shirts he has expressed interest in. So what happens when there are multiple MMA o-misses? Well, as noted, AC may have default rules such that if there are too many o-misses for a given o-request, AC will ask Rex to further specify his question or Q+. That is beside the point though. 1. As discussed, AC registers each indirect o- request, including o-misses, in the Q-record of the matched questions, the secondary sources, that is. 2. Where the MMA path is concemed, for a given o-request, AC can also register with each o-miss the number of other o-misses associated with that o-request. 3. And, for a given o- hit or o-miss, AC can also register what questions AC considered better matches.

5.3e Output Path Through Linked Questions

As noted, AC can enable users to link questions. When Rex arrives at a question that is linked to others, the question may possibly have a direct answer and/or an indirect answer. A net of linked questions can potentially be vast; thus a question may have a multitude of indirect answers. Looking for an answer, Rex can travel from the current question to a linked question and keep going in this manner looking for an answer. Or, he may be tired of traveling and may just want to get an answer. Rex can choose the HMA option or the MMA option. The HMA and MMA methods remain the same, though there can be minor modifications. AC can enable Rex, for instance, to specify that an indirect answer is to be outputted. AC can enable Rex to specify what kind of indirect answer he wants. For example, he might specify an indirect answer that is linked by one or more synonym links to the current-Q. Link specifications are search stats actually, and so the essentials of output paths with linked questions are no different than with non-linked questions. Linked questions mainly offer critical improvements in the ability to find answers and collect demand for answers. These topisc are taken up in Book II.

5.4 FUNCΗON BASED QUESTIONS As noted, AC can include function based questions (FB-Q's) that call special functions for finding answers. "Function based question" is a term that refers to a wide category of questions that find answers by processing existing questions and answers in AC. This definition is inadequate. Actually, it is hard to define FB-Q's well because they cover a very broad spectrum of possible functions for finding answers. Examples will demonstrate, but a good definition is elusive. An FB-Q has two parts: 1. a designated function and 2. subject information.

To enter an FB-Q, a user designates the function and enters the subject information (though not necessarily in that order). The function uses the subject information to find an answer in AC. Certain search stats can be entered as well to screen answers but we will ignore these for they are not essential to the discussion.) In the discussion of FB-Q's we reverse the previous order of presentation. First we discuss output paths and then input paths and then the creation of Q- locations. It is easier this way because what distinguishes FB-Q's from plain old questions is how answers are gotten out of the system or used to yield other answers.

5.4a Output Paths for Function Based Questions

To repeat, FB-Q's find answers by processing questions and answers that already exist in AC. (When we say "FB-Q's find," we mean, of course, that AC finds.) An FB-Q can find an answer not only by working on the information in a Q-string and in a Q-record, but also in an answer itself, (e.g., a keyword search might find a keyword in the content of an answer.)

Three Rough Types of FB-Q's

We can roughly divide FB-Q's into three types of functions: those that search through questions and answers, those that sort answers, and those that plug answers into formulas. Actually there is no clear dividing line, and all three kinds of functions can be combined in an FB-Q. Often there is no difference between searching and sorting. Still, the general ideas of searching, sorting and plugging into formulas can help explain how AC can use FB-Q's to find and output answers. (Note: We use colloquial questions below as examples, though in actual implementation the syntax of FB-Q's may be quite constrained.)

FB-Q's That Find Answers By Searching Questions and Answers

AC can include a large range of search functions for locating an answer. The most important are keyword search functions. For example, an FB-Q might be: Find: "Deep Throat" within 10 words of "Alexander Haig "?. As noted, an FB-Q can search the content of both questions and answers. AC can also enable Rex to specify whether just questions or just answers or both are to be searched.

FB-Q's That Find Answers By Sorting Answers

AC can include a large range of functions for sorting answers to yield a resulting answer. For example, an FB-Q might be Find: Ten lowest prices of Walkman X?. If AC has a list of sellers of Walkman X and a list of their prices. AC sorts the list and outputs the resulting answer.

FB-Q's that Find Answers by Plugging Answers Into Formulas AC can include a large range of functions for plugging answers into formulas to yield resulting answers. For example, an FB-Q might be, Find: Average Temperature of Florida Cities?. The FB-Q can find the individual temperatures through their corresponding direct questions, which might be: Temperature Miami?, Temperature Daytona?, Temperature Boca Raton?, and so on. (AC might find the answers by some other indexing means, but that is beside the point here.) The FB-Q plugs the individual answers into a formula, and outputs the resulting answer.

Use-Requests

In the previous section, we discussed o-requests. Here we add another kind of request, a use- request. By this we mean that AC tries to use an answer as part of another answer or that AC tries to use an answer to plug it into a formula to yield another answer. As with o-requests, the answer may be present or missing. AC must register different kinds of uses-requests where FB- Q's are concemed. The variety of possible uses is practically infinite.

Digression on Uses of FB-Q's

Many kinds of answers can only be found by processing other answers in a list or table. Often those other answers can only be collected efficiently by members of a community rather than by a central authority. For example, usually the most efficient way for an economy to find the lowest price on a given product is through a system that allows people to feed in prices to a central list where the prices are sorted to find the lowest ones. This way is more efficient than having a central authority call all the sellers of the product in order to check prices. With a feed-in system, only the low price sellers need feed in. AC is, of course, a feed-in system. AC registers the demand for "cell" answers based on the various questions, especially FB-Q's, that can be applied to those answers. Because it can collect this demand, AC is well suited to collecting and processing answers in tables.

HMA and MMA Output Path

FB-Q's require the MMA output path unless they take the user to a question. Certain FB-Q's, such as keyword searches, can take users to questions. In these cases the user can designate the HMA output path. For example, say a direct question is, What is the movie Singing in the Rain about?. The direct answer to this question might be a description of the movie. Now, let' say that our FB-Q is Find: "movie musical" within ten words of "most popular"?. This FB-Q might find these words in the direct answer. Rather than output the answer, the FB-Q can take Rex to the direct question, What is the movie Singing in the Rain about?. , and from there Rex can decide whether or not to buy the answer. Say the keyword is simply "Singing in the Rain". This will match the direct question. It will probably also match phrases in the answer. The point is simply that AC can take Rex to a question whether the FB-Q finds the answer through the question's content, or through the answer's content, or through both. (Of course, keyword searches can find numerous matches and therefore AC can enable Rex to enter further search parameters in the form of more subject information and search stats.)

FB-Q's as Come-from-Q's

When an FB-Q takes a user to a question, the FB-Q is registered as a come-from-Q.

FB-Q's as Sources of Indirect O-requests

When an FB-Q o-requests an answer, the FB-Q is an indirect source of the o-request. That's because an FB-Q is not a direct question to the answer that it causes AC to find. For example, if the FB-Q is Find: Average temperature Florida cities?, AC o-requests the answers of various direct questions, such as Temperature Miami?, Temperature Daytona?, etc. to arrive at a resulting answer.

5.4b Function Based Questions Rarely Have Input Paths

As noted, it is hard to define FB-Q's well because they cover a very broad spectrum of possible functions for finding answers. One litmus test that helps define an FB-Q is the following: an FB-Q is a question that users usually cannot supply an answer to. That is because an FB-Q works on existing questions and answers in AC. Users cannot know the answer to an FB-Q because users do not know all the questions and answers in AC. For example, an important kind of FB-Q is a keyword search. Now, a user can have no way of supplying an answer to such an FB-Q because she has no way of knowing all the questions and answers in AC that will match the keywords. Another important kind of FB-Q is one that plugs existing answers into a formula, say a formula for finding the average temperature from a list of temperatures. Again, a user cannot supply the answer because the user does not know all the relevant answers (temperatures) in ACs list.

There are exceptions to the rule. Sometimes a user will know enough about what is in AC to give a direct answer to the FB-Q. Big exceptions are certain sorting functions where a user might know the highest or lowest value to supply to a list that AC sorts. This example was seen in chapter 2, with the lowest price locator. The user can compare the lowest price in AC against prices in the real world and might know of a lower price in the real world. Even if the user knows the answer to an FB-Q, AC will normally have the user supply the answer as a direct answer to a direct question. The FB-Q will then find the answer through the direct question. For example, AC can enable the user to enter the answer to a direct question about the price of a product. The price then goes into a list which is sorted. Despite the exceptions, FB-Q's generally cannot be answered by people and thus they do not have input paths and direct answers.

Showing Direct Questions Still, AC can show a user the direct questions that correspond to the answers that an FB-Q causes AC to find. In other words, the FB-Q is a primary source of an o-request and AC can show the secondary sources of those o-requests. AC can enable a user to ask to see these direct questions. Even without AC showing the direct questions, a user may be able to recognize which direct questions and answers are involved when an FB-Q searches for an answer. A user can choose whether or not to enter direct answers to those questions.

5.4c Creating Question Locations

Though an FB-Q has no direct answer, AC can still create a Q-record (including a demand record) for an FB-Q. Demand information (and other information) gathered in the FB-Q's Q- record is fed into the Q-records of direct questions that correspond to the answers that AC outputs or tries to output as a result of the FB-Q. Moreover, AC can show certain A-stats that apply to FB-Q's. The A-stats shown depend on the particular FB-Q. The cost of an answer, for example, is useful to see. POE information can be useful in rare, but important, cases. That's because, as mentioned, users can in certain cases know what answers will be used by the FB-Q. How much information is kept in an FB-Q's Q-record depends on the FB-Q. Demand information is normally most important, but with FB-Q's it may not be necessary to keep. It depends on the situation. For example, AC may not keep demand records of keyword search FB-Q's, but may instead simply register demand information in the Q-records of the direct questions that the keyword FB-Q's find. Let us take an FB-Q that does the following keyword search: Find: "orange" within ten words of'karpousi"? Let us assume that this question is only entered into AC once during a year. In a case such as this there may be no point in maintaining a demand record. On the other hand, it may be quite useful to keep a demand record for an FB-Q. Let us take an FB-Q that does the following sort: Find: Lowest price Walkman X, in US. ? Here, there may be hundreds of thousands of repeat requests and it can be quite useful to maintain a demand record. There are no rigid mles, for the category of FB-Q's is too wide. Decisions in this area are design decisions.

5.5 COMBINING INFORMATION IN QUESTION RECORDS

In the previous sections we saw how multiple questions can lead to the same answer being requested. When multiple questions can lead to the same answer being requested, AC needs to come up with a combined set of information to be fed into the POF. Recall, the organizing goal of the system is to come up with an estimate of total sales and royalties of an answer. If a question is a vending machine and an answer is a product, and if the product can be requested for sale through different machines, then it is obviously best to combine the sales records from each machine into a total count. In this short section we have in mind mainly the combining of information in D-records because the main goal is to create a good POE for an answer and that depends primarily on the D-records. However, other parts of Q-records can also be usefully combined. This is especially so when there are multiple direct-Q's for an answer.

Registering Indirect O-requests

As noted, an answer can be indirectly o-requested. As noted, AC registers an indirect o-request in the Q-record of the direct-Q of the answer that has been o-requested. AC also registers the source of the o-request. And so, AC registers and classifies all the indirect o-requests for an answer in the Q-record of the secondary source, the direct-Q to that answer. In this way AC combines the request information from direct-Q's and the sources of indirect o-requests.

Linking Question Records of Linked Questions

As discussed in Book II, when AC links two questions it can also link their Q-records, especially their D-records. (By linking records, we mean that information in a first record can be accessed from a second record, and vice versa.) In Book II we will discuss how AC can combine demand information of indirectly linked questions (how AC and users can evaluate demand information combined from a net of questions). For now, we just say that AC can link the Q-records of directly linked questions. This implies that AC can combine the information in Q-records of indirectly linked questions.

Common Question Record

When there are multiple direct-Q's to an answer, AC can use information from their records to create a common Q-record. The principle applies for actual answers and missing answers that have multiple direct-Q's in common. This common-Q-record can be created by feeding in information from the individual Q-records into the common record._The common record contains information from each Q-record that applies to the answer that all the questions have in common (though the individual Q-records might contain demand information about answers not in common as well). In the case of multiple direct-Q's to an actual answer, a common Q-A- record is created in addition to the common Q-record. The common Q-A record may be considered a sub-record of the common Q-record. When a user arrives at one of the individual direct-Q's, he can see A-stats based on the common record, not just on the individual Q-record.

How to Use the Combined Information?

A general, and generally unsolvable, problem is how to apply the demand information that is combined from different Q-records. This problem is an extension of the problem of how to apply the demand information of a single Q-record. That's because, as discussed several times now, there is no single answer that the information should apply to. This problem is the same, and perhaps worse, when different questions are involved in identifying "an" answer. Chapter 6: Registering Demand Information

As described in chapter 2, AC collected two kinds of demand information about an answer. One was the number of requests for the answer and the other was the times of those requests. AC can collect other useful demand information. For example, AC can ask the user how much he is willing to pay for the answer. As previously discussed, demand information is in stored a demand record (D-record) which is part of a Q-record. AC feeds the information in the D- record into the POF to yield sales forecast and POE information about an answer. In other words, the idea is to collect information that can be used to help potential suppliers answer the question, "What the hell am I going to make if I find and supply this answer?." Given the puφose of the record, it might be called the sales forecast record or the pay-off estimate record, but demand record seems more natural. Whatever the name, a fat problem remains. Future demand cannot be measured. The problems involved are worse than just those inherent in making projections. In fact, demand cannot be measured at all. And yet, in order to come up with a good guess or guesses about future sales, AC needs to gather information on what we call demand. A brief digression is in order.

6.1 A DIGRESSION ABOUT DEMAND The Meaning of Demand

Demand can refer to the idea of how many units of something are sold at a certain price over a certain period of time. For example, one can say that the demand for gasoline this year was 80 billion gallons at a price of $1 a gallon (never mind for the moment that prices fluctuate). However, demand as we normally think of it means something more general. It usually refers to how much a group of people want a product or service or piece of information. Here we get into trouble, for how much one person wants something is a psychological state and we cannot measure that. Then if we consider multiple people, we have to add up their individual desires. Of course, if we can't measure one person's desire, we certainly can't add the desires of many people. A "measure" we have of a person's demand (desire) for something is how much that person is willing to pay for the thing. But even here we are in trouble and we can see how sloppy the idea of demand is, for how do we measure how much an individual is "willing to pay" for something, say, a carton of milk, a lawnmower, a necklace, a house, a telephone number, a book? Well we cannot measure "willingness to pay" because we cannot read a person's mind. The amount a person does pay, the price at the time of purchase, does not measure how much that person is willing to pay. A person might buy a shirt at $40 but that doesn't mean that $40 is exactly what the person is willing to pay. He might have been willing to pay more. A person might pass up a shirt at $40 which he would have bought it at $35. Perhaps the highest he was willing to pay was $37.47. The seller will never know exactly. Even the buyer will never know an exact, static figure. He may be broke one day. He may be flush the next. A purchasing decision is a psychological state as well. Then we add a further complication. With most goods and services we have an open market, meaning we usually offer everyone the same price and make that price public, as opposed to having individual negotiations with every potential buyer. But an open market doesn't tell us much about the total demand for an item. If the price of a shirt is $30 in the open market, how will we know how many people would have paid more and how much each person would have paid? And how will we know how many people are willing to pay for the shirt but not as much as $30, and how will we know how much each of these people would have paid? So while we often might say that demand means how many units of something were sold at a given price, over a given period of time, that does not mean we are measuring demand. We see that there is no such thing as demand in the sense of something concrete we can measure. Then let us add yet another complication. We would like to know about the total demand of a group of people, yet different people express interest in a product at different times. Moreover, prices fluctuate. How then can we measure the total demand at a given time? And at what point in time? We cannot. There is no such thing we can measure as demand in the present. All we can do is have one set of people, those who have expressed interest at different points in the past represent a set of people in the future, quite a dicey proposition. We should not leave out one more major problem which is that alternatives change. While we collect information about an answer over a period of time, altemative answers, both missing and actual, may arrive in AC during and after that period. Say we have collected information about a given shirt. What is the relevance of the past information when new, competing shirts hit the stores? What is the relevance when new shirt designs are requested that may or may not be supplied? As with evaluating demand for any product, it can be hard to evaluate the demand for a given answer in light of new alternatives that keep popping up. Despite all these problems, we can gather information — which we call demand information — that helps us guess at what sales of something may be during a given period of the future. Our guesses, on average, will be better with this information than without.

A Few More Things to Keep In Mind About Demand Information Collected by AC

AC registers demand information when a user selects request mode (or whatever we call the means by which AC enables users to declare their desire to buy an answer). The information is collected at questions (Q-locations), for questions represent answers. Some of the information is collected automatically when the requestor enters a question and other information is registered by prompting him or enabling him to enter the information of his own accord. The correspondence between questions and answers is strange. Therefore, how demand information applies to a given answer is not clear. We recall from chapter 4 that demand information does not necessarily apply to a single answer. But we also recall that the best we can do is gather information under a question and then make assumptions about how that information applies to an answer or answers.

6.2 INTRODUCTION: DEMAND INFORMATION IN AC People can ask for all kinds of answers from a phone number, to a cure for malaria, to the contents of mayonnaise, to a blueprint of a the Great Pyramid, to a video on changing a tire. In some cases, one person may be interested in an answer, in other cases thousands of people may be interested. In some cases people will be willing to pay .1 cent, in other cases a 1 ,000,000 dollars. The range of demand possibilities is wide and demand information (D-info) can be collected all along this range. There are many kinds of D-info. Some is what we think of as "plain old information," such as the time that a request is made. But some is more than that because it involves a buying offer. If a user agrees to buy an answer at a given price this offer is D-info. And if the answer is in the system, and AC agrees to that price as well, then a sale is made. In other words, a buying offer involves more than just information. It involves a contract and possibly a transaction. Now very often an answer will be missing and no sale will be made. Whether an answer is missing or is present, the point remains that Rex intends to buy and this intention is made operational by AC. By that we mean that AC includes functions for registering Rex's offer and for executing whatever contractual obligations are involved, such as the delivery of the answer and the registering of charges and payments. So when we say D-info sometimes we have in mind plain old information, other times we have in mind more than that, for an offer and transaction operations may be involved.

We will show some of these transactional steps in this chapter even though they are operations in addition to the storing of information in the D-record. The registering of D-info involves these activities so it is appropriate to discuss some of them here. However, we omit most of the transactional steps, taking them to be understood. (We should note that AC can use information that might not be stored in the D-record to help in predicting sales. For example, complaints about an answer might help predict the sales of the answer. These are stored in the Q-record, though perhaps not in the sub-record we have called a D-record. However, if AC uses information to predict sales, we will consider that information to be D-info.) In any projection of future sales and income there are too many factors to keep track of. Formulas for projections have been known to contain thousands of variables and still fail miserably. In the next sections of this chapter we discuss several types of D-info that can be useful in forecasting the sales of an answer. The list is not, and cannot be, exhaustive. (We do not describe how the information is used by a POF.) For convenience, section 6.2 is divided into two parts. Part 6.2a describes the registering of what we might call request information, information that is registered along with a request. Part 6.2b describes the registering of price information. Both kinds of information are essential for characterizing a request but it is convenient to split the discussion into two parts because the registering of price information involves numerous sub-issues.

We note here that some of the D-info discussed can only be registered in the D-record of the current-Q. For example, when Rex makes a commitment to buy an answer, this commitment applies to a direct answer to the current-Q. In other cases, AC can register D-info in the D- records of questions that are not necessarily the current-Q. This can happen because of the MMA path, in which indirect o-requests can be registered in the D-records of questions other than the current-Q. This was discussed in section 5.3. MMA o-requests can have many of the same things registered about them as HMA o-requests. However, it is hoped that it will clear from the context of the discussion that certain kinds of information do not apply to MMA o-requests. Section 6.3 discusses the registering of buying situations. Instead of thinking of just a request plus additional information, it is better to think in terms of situations. These can be characterized by numerous factors, and we can only touch on some of the important ones. Section 6.4 briefly discusses how AC can compile demand statistics and how it can use these in characterizing a request. Section 6.5 touches on the central issue of evaluating a request in light of altemative requests. Section 6.6 touches on how time can render D-info obsolete and how AC can adjust for this problem. Section 6.7 discusses a few other considerations that might be thought of as miscellaneous points. Sections 6.8 just mentions the important possibility of investment offers.

6.2A SOME USEFUL KINDS OF DEMAND INFORMATION

1. Requests. Request is a term that covers a range of actions that Rex can take and that AC can register information about. We can distinguish between innumerable different requests based on numerous situations that Rex can be in and numerous actions that AC can allow Rex to take. We will try to classify requests in a limited number of ways, while realizing that there are other ways, and that we can never be exhaustive. Most broadly, we can divide requests into two generic kinds: arrival requests and output requests. We add information to these generic requests. The more basic of the two is the first.

1 ) Arrival requests. By arrival request we mean that Rex enters or selects a question. He thus arrives at a question, a Q-location (or a Q-A-location), that is. We call such a request an es- request for the terms Enter and Select. (We would use A-request. for Arrival, but that might be confused with Answer.) The arrival at a question is the base request that all other D-info is built on. Even output requests are built on es-requests because in order for Rex to make an output request he has to be at a question (though he may not see the information at the Q-location).

2) Output requests. By output request we mean that Rex asks AC to output an answer. We abbreviate this as o-request. In section 5.3 we described two Get Answer commands, Get Direct Answer and Get Best Answer, that cause AC to register o-requests. However, there can be many other commands, and situations, that cause AC to try to output an answer. For example, AC can include an Accept Price command which, when pressed, signifies that Rex accepts ACs price offer and that he wants an answer to be outputted. As usual, we cannot give universal rules. But basically, if Rex has agreed to pay an amount of money for an answer, AC considers that an o- request. Both es-requests and o-requests have been described in chapter 5. AC registers all the information discussed in chapter 5 about requests including: • Come-from-Q's and go-to-Q's, including Q+'s.

O-requests — o-hits and o-misses, and whether they resulted from the HMA or MMA path, and what their primary and secondary sources were.

As noted in chapter 5, in certain lands, arrival at a question implies an output request. But in most lands AC allows Rex to have more options than just buying, and therefore, Rex may have other motives when he arrives at a question. If we think of Rex as a shopper, we realize that he can have many motives and that they might change depending on what he sees at a question. Below we list some of the ways we can think of Rex's motives. These are colloquial terms though. How AC classifies a request depends on what Rex does at a question and on the situation Rex is in, and on the rules of the particular AC. a. Wants to Buy. He may want to buy the direct answer to the current-Q. b. Browsing. He might be browsing, seeing what the A-stats at the current-Q say. c. Traveling Through. He might be looking for another question that matches the current-Q or is linked to the current-Q. d. Buying Through. He might want to buy an answer that is not the direct answer to the current-Q (he can do this using the MMA path), e. Free Riding. He might want an answer but does not want to pay for it. Answers may be free to certain users (see chapter 7 on price setting) and the requests of these users can be used as D-info to indicate the demand of paying users.

Recalling the foundation task of the system — to count how many people want an answer — the most important distinction between requests is whether or not Rex has any interest in buying the direct answer to the question he is at. We can think of Rex as if he was in a consumer electronics store. He walks up to (arrives) at a sign (Q-string) that says Color TV. The sign also has a lot of other information (A-stats) describing the TV. The TV is not right there in front of him, only the description. In addition, the sign lists the names of some other TV's and directions to where their signs are. Rex can go to one of those signs as well. Now the key issue is: does Rex want to buy the TV described by the sign that he is at? AC needs means and rules that attempt to characterize Rex's intentions. We discuss some of these means and rules after we discuss price tests. That's because guessing whether someone wants to buy something is tied up with whether the person offers to pay for something. In sub-sections 2-10 below, we describe some of the additional information AC can register along with a request. As noted, some of the information described only applies to es-requests and to HMA path o-requests. It does not apply to o-requests from the MMA path. Other information applies to all requests. (The main reason some of the information described below cannot apply to MMA o-requests is that it requires a decision by Rex about a specific answer, as represented by the Q-location Rex is at. But with the MMA path AC may automatically search numerous locations without showing them to Rex. It is thus impractical for him to make a decision at each of these locations.)

2. Type of Use. An answer can be o-requested for various types of uses, in addition to straight output. For example, an answer can be used in a formula that leads to the output of a different answer. AC registers the type of use that is requested, because different prices and royalty rates can apply to different uses. This kind of information is an exception to most D-info in that it applies mainly to indirect MMA o-requests.

3. Actual Sales. Actual sales are an important type of request information. AC differentiates between requests when an answer is bought and when it is not. Further, AC keeps track of total sales which are important not only for predicting future sales but for calculating royalties. And, further, AC keeps track of refunds where buyers inform the system that an answer is inadequate and where buyers get their money back.

4. Time Information. AC registers the time of each request. This information is usually critical for calculating a POE and it is essential for numerous other puφoses. Another kind of time information AC can register is how long users will be interested in the answers they have requested. Answers are only valuable for certain periods of time. For example, AC might register dozens of requests for the score of a football game. From these requests, AC might project a large POE. However, AC does not know that few people will be interested in the score shortly after the game is over. Users must tell it in order for AC to reflect this fact in the POE. (Of course, declining demand will show up in the POE, but there will be a lag.) So AC can ask Rex to input the time period for which he is interested in an answer. Furthermore, AC can ask Rex to guess how long he thinks others will be interested in an answer. This guess can may be useful for calculating a projection of future demand. Taking our football score example, Rex can input that he is interested in the score of the game up until, say, four o'clock. And he can input that he thinks demand for the score will taper off at eight o'clock.

5. Requestor Identity. It goes without saying that AC can register who has made a request. This information is necessary for collecting and using various kinds of D-info.

6. Prospect List. AC can maintain a list of all the people who have entered or selected a question. We might call this the prospect list for the answer that corresponds to the question. If an answer is not in the system, all the people who have requested it are potential prospects. If an answer is in system, all those people who did not buy it because the price was too high are also prospects. If an answer is in system, all those people who bought it are also potential prospects, for the answer may change and these people might be interested in the new version. AC can differentiate between these three types of prospects (there are many other ways to classify prospects as well). AC can also store the price each prospect was willing to buy at or did buy at (see price tests below). AC can enable potential Sues to contact the prospects to see if they are still interested in an answer. A potential Sue can also ask the prospects if they are willing to pay more for it than they have offered. AC can also contact prospects. Before the relevant answer is in the system, AC can check to see if they are still interested in the answer. Further, AC can recontact the prospects when the answer arrives in the system or when the price declines. Rather than contact every prospect, AC might sample the prospects to check reaction.

7. Placing an Order. If an answer is not in the system, AC enables Rex "place an order" in the sense of asking to be alerted when the answer arrives. (The order may include the price that Rex is willing to pay. See price tests below.) AC registers the order and then, when the answer comes in, sends Rex a message that the answer has arrived. AC also enables Rex to cancel the order at any time, including when the answer arrives. The cancellation is also registered. Note: when an answer arrives, the price may not be acceptable to Rex. Thus, Rex may not end up buying the answer, even if he wants it.

8. Making a Commitment. Now if an answer is not in the system, AC enables Rex to commit to buying the answer for a certain period of time at a certain price. The price may be set by AC at the time of the commitment, or Rex may make an offer (see price tests below). Making a commitment is different than placing an order. In that case there is not a commitment to buy, just an expression of interest. Here Rex makes a binding commitment good for a certain period of time. AC registers the commitment and also registers when the time period expires. If the answer arrives before the time period expires, AC alerts Rex. And if the price of the answer is equal to or below what Rex has committed to, then AC can automatically charge Rex. On the other hand, the price might be higher than Rex committed to and then he has to decide whether to buy or not at that price. AC may enable Rex to retract a commitment (the retraction rules can vary widely and may, for example, involve the forfeiture of a deposit). The option to make a commitment can be quite an important feature of AC because a commitment tells a potential Sue that she can be more sure of getting a given amount of money for supplying an answer. She can say to herself, "Well, at least I know that I'll get that much money."

9. Canceling an Order or Retracting a Commitment. When we say that AC registers the cancellation of an order, that does not mean that AC deletes the original order from the D-record. The original order no longer counts in the sense of selling Rex the answer (after a cancellation, AC does not alert Rex when the answer arrives). But the original placing of the order may still be useful D-info. For example, if a person orders a certain brand of cereal in the morning but then cancels the order in the afternoon, the person's order still may represent demand for the brand. It just may be that the person, not wanting to wait, found a less preferable brand for breakfast. Taking an answer example, a person might place an order for instructions on how to change a tire. The person might later cancel the order because, before the instructions arrive, he finds someone to show him how to change the tire. Still, the person's order for the instructions may represent (correlate with) other peoples' desire for the instructions in the future. The same reasoning applies to the failure to renew a commitment when it expires, and also to the retraction of such a commitment. The original commitment can be useful D-info. Recall, the idea is to forecast the sales of an answer and that depends on the situations of individual requestors and whether their situations represent (correlate with) other peoples' situations in the future. That is a highly variable, dicey proposition. We can make no general rules. Sometimes canceled orders and commitments will give us helpful hints about future sales, other times not. Because the situations are so variable, it can help if AC gathers information on why Rex canceled an order or retracted a commitment or did not renew a commitment. Thus, when Rex does any of these things, AC can ask him the following questions and register his responses: Did you change your mind because: a. the requested answer is out of date ? b. your needs changed? c. you found a better answer elsewhere? if yes, was the answer in AC? if yes, which answer was it (identify the answer by the question you found it through, please). (Although it is not the point here, let's mention that AC enables a user to keep track of the questions he has asked. AC keeps the list in the user record, which the user can access. AC also maintains a sub-list of questions the user has asked and that have not yet been answered. A user can "clean up" this list by going through the questions and marking certain ones that he has no more interest in with a cancel mark. AC registers each mark and cancels the corresponding orders.)

10. Preventing Double Counting. One piece of information that can be useful to register is whether Rex has asked the same question previously. In many cases repeat requests lead to misleading double counting of requests. For example, Rex might ask for the final score of a football game ten times before getting an answer (because the answer has not been entered until the time of the tenth request). It can therefore be useful for AC to include steps for registering whether Rex is making a repeat request. AC can identify repeats by keeping a list of questions arrived at by the user, and then checking against this list. Altematively, AC can keep a list in a given question record of the users who have arrived at that question, and check against this list. When a repeat request is not for a new answer, we call it a false request. AC requires rules for determining whether a repeat request is a false request. There are many factors that can come into play because the answer situations and requestor situations vary widely. Whether a repeat is a false request can depend on whether an answer has changed. For example, Rex may ask, What's the weather gonna be like?, ten different times, and each time can be a tme, new request where a new answer is sought or a new answer is provided. Moreover, AC can register in the D-record whether Rex bought and received an answer and can check whether the answer has changed since Rex bought it. Whether a repeat request is a false request can depend on whether Rex expects the answer to have changed. The answer might not be changed in AC, but Rex may know that the answer should change or might be changed. Conditions in the world may change or the answer may be improvable. Therefore, AC can ask Rex whether the repeat request is for a new answer or not. Asking Rex can be important because he may know better than a machine rule whether a request constitutes double counting or not. For example, Rex might ask for a second time, What is the temperature ofthe ocean at Ocean City?. He will know whether his request is a false request or if he expects a new answer. In other words, if AC has an answer for the temperature, it may be out of date. AC will not know that it is out of date. If Rex then enters a request for the temperature, AC might treat it as a false request. But Rex can tell AC that his request is for a new answer. The point is that double counting depends on the situation and the user's common sense about the real world situation can better identify double counting than a machine rule. (Note also, if AC does not store who has arrived a given question, then AC can ask the user if the request is for a new answer or not.)

6.2B REGISTERING PRICE INFORMATION

Now it is clear that the price of an answer is critical demand information. Yet, as discussed above, it is not so clear what a price means, at least in the philosophical sense of what it means in the minds of buyers. In the practical sense of how prices are implemented in AC, the definition of price is fairly clear: the price of an answer is the amount of money the answer sells for at a given time to a given user. On the other hand, there is often no such thing as a fixed price, or even a single price for an answer. And in that sense, the meaning of price is different than what we normally think of. As explained in the next chapter on price setting, there can be a wide variety of pricing schemes. The price amount can differ from one point in time to another and from one user to another. Rather than think of a price as a price on, say, a box of cereal, we should think of price offers and acceptances of those offers. These can vary from moment to moment and from person to person (they can be fairly static as well, of course). Thus when we say "price" we often mean a price offer or a price threshold. So the term price can be a little confusing. AC registers price offer information in the D-record of a given question. Obviously, if offers and acceptances change over time, there will be various selling prices and price offers for an answer in the record. (Note, when the price of an answer is basically static and users know it in advance, then it not need be in the D-record, for it can be assumed in the POF that applies to the answer.)

As described in chapter 2, AC did not gather price information from requestors. It was assumed that the price of an answer was set and Rex could take it or leave it. Prices can be set for broad categories of answers, and thus a user can know the price in advance, as a person usually knows the charges involved when calling directory assistance or when using an online service that charges by the minute. Often though, it is impractical set a price for a category of answers. Similar type answers may have very different values and prices. For example, the phone number of the President's barber might cost 5 cents while the phone number of the President might cost $5,000. Moreover, the cost of finding an answer is often unknown in advance and so setting the price in advance is unreasonable. Then, after the answer is found, it is often impractical to set a static price because the amounts that various users are willing to pay is also unknown. Often it is not desirable the let Rex know the price(s) others have paid for an answer. If Rex knows that some people have paid, say, two cents for an answer he might not want to pay more, even though he might have originally been willing to pay more. So when Rex is at a question, AC may not show him a price for the answer.

When the price of an answer is not known in advance by Rex, it is useful to gather information on what he is willing to pay for the answer because this information can be used to arrive at a POE. (The information can be used to set the price of the answer as well.) Now since AC can't read minds, it must perform what we will call price tests. These will not reveal exactly what people are willing to pay, but they seem to be the best that can be done. There are two fundamental price tests. One test is where the system (the seller) offers a price for an answer and Rex (the buyer) can accept or reject the price. We say price when the system makes an offer, for it is an amount that Rex can accept or reject. The other is where Rex offers a price and the system can accept it, reject it, or simply register it. When Rex makes an offer, we say that AC has a price threshold in the sense that if Rex's offer is over the threshold, AC accepts Rex's price. If the answer is not in the system, AC usually does not need to accept or reject the offer but just record the offer in the D-record. In both kinds of test AC registers Rex's identity so that follow- up actions can be taken, if called for. Some of these are seen in the price testing sequences described below. (As noted, AC registers Rex's identity for other reasons as well.) The world of commerce has evolved a great variety of price offers and counter offers for sale situations. Earnest money can be pledged, time limits can be imposed, letters of intent can be written, discounts can be given, and so forth. Many of these aspects of offers can incoφorated into price offers and into price testing sequences in AC. Here we will describe mainly the basics, in which either the system makes an offer or Rex makes an offer. We will include some additions, and will discuss counter-offers, but we realize that a great number of variations are possible. Price tests must occur in a series of steps between two parties which we call price testing sequences. There are many commands AC can include for enabling Rex to make and accept price offers. The simplest are Get Answer command, which can imply the acceptance of an offer, and which can be used in conjunction with making a price offer. However, there are numerous specialized commands that AC can include that are tailored for given price testing sequences. We do not describe these in any detail, but assume that AC includes command for executing the price testing sequences described. We will describe some basic sequences, but before doing that, let us elaborate a little on the price tests themselves.

System-Offer Price Tests. To repeat from above, in a system-offer price test AC makes Rex an offer which he can accept or reject. When we say that AC makes an offer, we mean that the AC (or Sue using AC) presents a price to Rex. Rex can accept or reject or even ignore the offer. AC requires means and rules for classifying Rex's behavior. The problem is that if Rex ignores the offer, AC cannot register whether Rex rejected the price or rejected the answer for some other reason. This issue is taken up after price tests. For now we assume that AC include means for enabling Rex to explicitly reject the offer, such as a reject button. Further, AC may include defaults for assuming that Rex has rejected the price. ACs price or price threshold may be set by a price setting formula, by a system manager, or by a Sue. If Sue is setting the price, she is using AC as a medium. If AC is setting the price, it is acting as an agent for Sue. Whatever the method, we will, for convenience, say that AC has set the price. From the point of view of price testing sequences it is the same. AC registers the total number of requests along with the acceptance/rejection rate at given prices, and of course actual sales, if there are any, at given prices. AC can present different prices for an answer to different requestors, to experiment with the effect of those prices on the POE. Experimentation can be critical to doing a good job of setting the price of an answer and of estimating the income of an answer. (Note: For simplicity, we ignore the fact that AC can present more than one price to a single Rex. AC can present more than one price because AC may include price plans that allow for this. As with prices for airline flights, the price for the same flight can vary, for example, depending on when one flies. The price of an answer can vary for many reasons. We do not go into this because it is beside the main point, yet we note that AC can present more than a single price to the same person.)

Requestor-Offer Price Tests. As noted above, a Rex-offer price test means that Rex makes an offer that AC can accept or not. (In this case AC will have set a price threshold.) The basic idea behind a Rex-offer test is simply that AC can register what each Rex says he will pay. Rex's offer is not just talk. If the answer is in the system, and if the offer is accepted by AC, Rex is charged the amount offered and gets the answer. If the answer is not in the system, he can place an order at a certain price (see Placing an Order above). Further, he can commit to buying at a certain price for a certain period of time (see Future Commitments above). Apart from an actual price test, AC may also enable Rex to state his opinion of what is a reasonable price. This opinion is simply Rex's judgment and not an offer. It can be important D-info in certain cases. AC can enable Rex to both make an offer and state an opinion. AC can enable Rex to do all of the above at the same time: a. make a binding offer at a certain price in the present, b. place an order at a certain price, c. commit to paying a certain price, for a certain time period, and d. state an opinion as to a reasonable price.AC can have an offer buttons that Rex selects to enter a price offer. When he selects this, AC presents him with a price offer form.

(Brief Digression: The idea of selling an answer at a different prices to different people is well known. However, it can be taken much farther in AC than it is normally taken, because users may not be told what other users have offered and paid for given answers.)

6.2b 1 Price Testing Sequences

Price tests must occur within a sequence of steps, for they are an interaction between two parties, Rex and AC (remember, AC means AC or a Sue using AC as a medium). We will describe some basic sequences in which Rex or AC make offers. Then we will describe some counter¬ offer possibilities. Before describing any sequences, some more context is helpful.

Whether Answers Are In AC or Not

For price testing, it can matter if the answer is in AC or not. For example, take the answer to the question, What time does "The Rockford Files" start tonight?. After this answer is in the system, AC might have a price set for it. But before it is in the system, AC might ask Rex to make an offer. Different price tests can be used before and after the answer is in AC. Or, the same price test can be used before and after. There are four possibilities: Before Answer Is In After Answer Is In

1 ) AC makes offer AC makes offer

2) AC makes offer Rex makes offer

3) Rex makes offer AC makes offer

4) Rex makes offer Rex makes offer

Whether Rex Knows If the Answer Is In AC. It can also matter if the price test is done before telling Rex whether or not the answer is in the system. That's because Rex may make a lower offer if he knows that the answer is in the system. Thus we double the number of possible sequences by which price tests can be done, if we include the fact that Rex is told or not before the test whether the answer is in the system. AC can register whether the price test was done before or after the answer was in the system. AC can register whether or not Rex knew if the answer was in the system at the time of the test.

Price Setting Assumed But Not Shown. The price offers and price thresholds can be set in various ways: by the system manager, by Sue, by a price setting formula, or by some combination of these. We omit the setting of a price or threshold but assume that that step is taken at appropriate times (see Price Setting in the next chapter). Feedback is inherent in the process. Price offers and price thresholds are set and then tests are done. The test results can then lead to the setting of new prices and new thresholds. Then new tests are done. And so on.

Changing Offer Assumed But Not Shown. We assume that if AC enables Rex to make an offer that it enables him to change an offer. Of course the rules for changing offers can vary. In the case of binding commitments, Rex can usually increase his offer, but he might suffer a penalty for decreasing it. The ability to make other changes is important too, such as lowering or raising the price of a non-binding offer.

Other Omissions. In the sequences described below we avoid repeating steps previously shown; the point is to show the new steps. So we assume that a given question location has already been created complete with D-record. We also omit certain transactional steps that are taken to be understood. For example, where Rex commits to buying an answer, we do not show the system charging Rex when the answer arrives and we do not show what the system does when the commitment expires. Likewise, we do not show the canceling of orders or the expiration of commitments. The main point is to show the kind of price information AC can register. That said, it helps to remember that this information can involve transactions.

Some Price Testing Sequences

Below we describe some sequences that demonstrate the steps that AC can include for carrying out price tests and registering price information in the D-record. We illustrate enough to get the basic steps across, while we recognize that many other permutations are possible. In the sequences, when we say that Rex does something, we mean both that he does something and that AC includes functions for enabling him to do so. As mentioned, Rex is either told or not told before a price test whether or not the answer is in the system. In some of the sequences below he is told, in others not. It is of course an easy matter to do the sequences vice versa with respect to showing Rex whether the answer is in the system.

Figure 6a shows a sequence in which only AC makes an offer and in which AC does not tell Rex whether or not the answer is in the system. 1) AC presents 210 a price to Rex. 2) Rex accepts 211 or rejects 211 the offer. 3) If Rex rejects the price, AC registers 212 the rejection at that price, calculates 218 and outputs 219 the POE. 4) If Rex accepts the price, AC registers 213 the acceptance at that price, and then checks 214 to see if the answer is in the system. If the answer is not found, AC tells 215 Rex and then calculates and outputs the POE. If the answer is found, AC outputs 216 the answer, registers 217 the charge due to Rex and the royalty due to the supplier, calculates and outputs the POE. Figure 6b shows a sequence where Rex makes an offer before the answer is in the system and AC makes an offer after the answer is in. Further, before the price test, AC tells Rex whether or not the answer is in the system. 1) AC checks 220 if the answer is in the system. 2) If the answer is in, AC tells 221 Rex and presents 222 a price. 3) Rex accepts 223 or rejects 223 the price. If Rex rejects it, the system registers 224 the rejection at that price and calculates and outputs the POE. If Rex accepts the price, AC registers 225 the acceptance at that price, outputs the answer, registers charges and royalties and calculates and outputs the POE. 4) Now, if the answer is not in the system, AC tells 226 Rex that answer is not in. AC then asks 227 Rex to make an offer. Here, as shown, AC includes steps for enabling Rex to make various offers: a. AC can register 228 a non-binding offer. Here Rex expresses what he says he is willing to pay (places an order and states a price), b. AC can register 229 a binding offer to pay an amount up until a certain time. In this offer Rex not only states an amount he will pay but states a period of time his commitment is valid until, c. AC can register 230 binding offers that include a commitment of earnest money, d. AC can register 231 Rex's opinion as to a reasonable price for the answer. As usual, once AC registers Rex's offer, AC calculates and outputs the POE.

Figure 6c shows a sequence in which AC makes an offer before the answer is in, and in which Rex makes an offer after the answer is in. In this sequence Rex is not told before the price test whether the answer is in the system. The main new feature here concerns Rex's offer. AC includes steps for limiting the number of offers Rex can make. If Rex can make unlimited offers when an answer is in the system, Rex will start low and keep going up. Rex will try to discover ACs price threshold ("bottom line"). Thus, the system needs to limit the number of offers Rex can make. This concern does not apply usually when the answer is not in the system because then the answer may have no threshold attached to it. The sequence in figure 6c limits Rex to one offer. (Figure 6d shows a sequence limiting Rex to one offer per a period of time.) 1) AC checks 240 to see if the answer if found. 2) If the answer is not in the system, AC presents 241 a price to Rex. 3) Rex and accepts or rejects the price. 4) AC then registers 242, 243 whether the price is accepted or rejected and tells 244 Rex that the answer is not in the system and then calculates and outputs a POE (we note that, as usual, Rex's identity is recorded as well). 5) Now if the answer is in the system, AC checks 245 whether Rex has made a previous offer. If yes, AC tells 246 Rex that he is ineligible to make an offer and then, as usual, the system calculates and outputs a POE. In this case AC also tells whether the answer is in or not since Rex may want to supply it. 6) If Rex has not made an offer, AC asks 247 Rex to make an offer. AC then registers 248 the offer. 7) AC then accepts or rejects the offer. If the offer is rejected, AC tells 249 Rex that the offer is rejected and registers 250 that Rex has made an offer for this answer. Then, as usual, AC calculates and outputs a POE. If the offer is accepted, AC outputs 251 the answer, registers the charges and royalties due, and calculates and outputs the POE. Figure 6d shows a sequence in which only Rex makes an offer. In this sequence Rex is not told before the price test if the answer is in the system. Here steps are shown that limit Rex to making one offer per period of time. The point, as mentioned previously, is to limit the number of offers that Rex can make in order to get Rex to make a higher offer. We note that, as shown, if Rex makes an offer before the answer is in the system then this offer is not subject to a time period prohibition. Rex is free to make a different offer once the answer is in. 1) AC checks 260 whether Rex has made an offer that has been rejected. 2) If Rex has never made an offer before that has been rejected, the system asks for an offer, registers the offer and checks to see if the answer is the system. 3) If Rex has made an offer that has been rejected, AC checks 261 to see if the pre-determined time period has expired. 4) If the time period has not expired, AC tells 262 Rex that he cannot make another offer and, as usual, calculates and outputs a POE. 5) If the time period has expired, AC asks 263 Rex to make an offer. The system registers 264 the offer. AC then checks 265 to see if the answer is in the system. If the answer is not in the system, AC tells 266 Rex that the answer is not found and, as usual, calculates and outputs a POE. If the answer is in the system, AC checks 267 the price threshold and accepts or rejects the offer. If the system rejects the offer, it tells 268 Rex that the offer is rejected and sets 269 a time period for when Rex can make another offer for the answer, and, as usual, calculates and outputs a POE. If the system accepts the offer, it outputs the answer and registers charges and royalties and calculates and outputs a POE.

6.2b2 Counter-Offers AC can make counter-offers and enables Rex to make counter-offers. And, of course, AC registers these offers. We will describe the basic counter-offer situations below. Rather than repeat the sequences above, we will consider two general situations: one where Rex has rejected ACs offer and the other where AC has rejected Rex's offer. We don't go into counter-counter offers because the principles are the same, except that AC would place limits one how many rounds of offers there could be per period of time. (Note: if Sue is doing the price setting AC can leave it up to her to decide how to conduct the negotiations.)

Situation 1: AC Presents a Price and Rex Rejects It. If Rex rejects ACs price offer, Rex can make a counter-offer. In fact, Rex can make a few offers: a. He can make a counter offer good for that moment, b. He can place an order, saying in effect, call me when you've lowered the price, c. He can commit to paying a lower amount than ACs current price. These are all offers that have been discussed above. Because of their place in a price testing sequence, a negotiation, they are called counter-offers here. AC can immediately accept or reject the counter-offer. If AC rejects the counter offer, AC can call Rex back when ACs price drops. A second kind of counter offer is actually one that AC can make. As noted, AC may have a reject button that Rex can select. By pushing this button, Rex simply indicates that the price is too high, but he does not make a counter-offer. In this case, AC can make a counter-offer (a second offer) by immediately lowering its price. If AC has this procedure, it must also have rules for making Rex take a risk (or assume some cost) for rejecting ACs initial offer. Otherwise, Rex will always reject ACs initial offer. For example, AC can have a rule whereby Rex has a chance of not being entitled to buy the answer for a period of time if he rejects the initial price.

Situation 2: Rex Offers a Price and AC Rejects It. If AC rejects Rex's offer, AC can make a two basic counter-offers: a. AC can present a price above Rex's offer, b. AC can ask Rex to make a new offer. Rex can accept the new offer. He can make a new offer. He can place an order. And he can make a commitment.

Re-Contacts. Now when Rex rejects ACs price when AC rejects Rex's offer AC can register Rex's identity in order to possibly recontact him when ACs price or price threshold drops (this possibility was noted above in the discussion of the prospect list). If AC recontacts Rex then both parties are can make new offers.

Real Time Negotiations. AC can be looked at as an agent for Sue but it can also be looked at as a medium. As such, it enables Rex and Sue to engage in real time negotiations. In other words, Rex and Sue can make offers and counter-offers without significant delay. This just means that the process of offer and counter-offer is in real time. It does not change the sequence. AC may enable users to see each other or talk to each other directly. (It also means that it is Sue, and not AC, who is setting the prices and price thresholds.)

6.3 REGISTERING THE BUYING SITUATION OF A REQUEST

We retum now to the issue of characterizing requests, with respect to whether Rex wants to buy or whether he has other intentions. Let us back up for a moment and recall the prime goal of the system: to forecast sales. The central problem then is: what sales does a request foretell? ACs approach is to register various D-info in addition to the fact of the request, and use that information in a POF. The point here is that Rex's request represents a potential sale to Rex, and it also may represent (correlate with) sales to potential future buyers. The most important thing to determine then is whether Rex wants to buy the direct answer to the current-Q. Recall, the foundation task of the system is to count how many people want to buy an answer. Though other kinds of interest, such as browsing without the intention to buy, may be important to register, the intent to buy is the most important thing. Because a large percentage — no one can say what percentage — of the requests are for answers that are not in the system, AC needs to differentiate, at least on a statistical basis, between the requests of window shoppers and live prospects. And yet, we know that in many cases there will be no way to tell what Rex's intentions are, whether he wants to buy or not, at any price. AC cannot read Rex's mind. It can only characterize a request according to facts that it registers about the request. What facts then?

Now we know that the significance of a request — what sales the request foretells — depends on the circumstances that the request is made in. For example, if someone walks into Tiffany's on Fifth Avenue and asks to see a silver necklace, that request has a different significance than if the same person asks to see a diamond necklace. And that request has a different significance than if the same person walks into Schraft's and asks for a malted milk. We know there are differences even though we cannot measure them. We can however register the facts of a large number of situations and then see if the facts foretell anything on a statistical basis. More important than the type of merchandise (answer) usually is whether Rex is under an obligation to buy. If he is obliged to buy when the merchandise (answer) is in stock then that obviously has a different significance than if he is not obliged. There are innumerable many factors that involved in a buying situation. We cannot list them all, and AC cannot register them all. But AC can register certain key facts that are common to such situations. We will look at some of these facts below. Before doing so, let us discuss the general idea of a buying situation, restricted to certain kinds of information: what Rex knows when he arrives at a question, what he sees, and what he does. We will then describe some features AC can include for getting Rex to declare his buying interest. And after that, we will list key "buying situation" facts that AC can register.

The Importance of the Buying Situation

Let's pretend Rex walks into a bookstore and tells the clerk the title (Q-string) of a book he wants. The clerk takes Rex to the book. Rex doesn't look inside the book but he reads the back cover (A-stat) information which, let's say, includes a price. Rex then leaves the bookstore without the book. Now did he leave without the book because the price was too high? Or because of something he read in the back cover? Or because he was just browsing with no real intention of buying? What if the back cover has references to other similar books. And what if Rex doesn't leave but asks the clerk about one of those books? Again, why does he reject the first book? For a variety of reasons, he may not want to buy the answer that corresponds to the question he is at. His intentions cannot be captured by any set of simple rules. If Rex does not indicate why he rejects an answer, no one can tell whether it was because of the price or for some other reason. (Even when Rex does tell, he may be lying.) And things are stranger in AC than in a typical bookstore where one usually knows if a book is in stock. AC is vast Borgesian bookstore where the shelves are full of potential books with only a smattering of actual books sprinkled in. The best AC can do is register the key actions that Rex takes and the key pieces of information Rex has seen when he takes those actions (what he did and what he knew at the time). For example, in the scenario above, AC would register that Rex left without buying the book and that the price of the book was presented to Rex. Some Basic Buying Situations Rex Can Be In

We will illustrate some basic buying situations to show how the significance of Rex's request depends on Rex's situation. When we saying buying situation we mean what Rex does at a question and what he knows when he does it. The focus here is on whether Rex has any interest in buying. We limit the discussion to a small set of factors while realizing that many others may indicate buying interest and may correlate with future sales. How can AC tell if Rex has any interest in buying an answer? Sometimes it seems clear he has no interest, other times it seems clear he does, and other times it is unclear. We look first at the situations where Rex's interest in buying or not buying seems clear. Then we look at situations where his interest unclear. Note: when we say below that Rex "knows" whether the answer is in the system, we mean that AC has shown him whether the answer is in. When we say he "does not know" we mean that AC has not told him one way or the other. Now, he may have a guess based on the real world aspects of the answer but we are not referring to this guess, only to what AC has shown Rex. Note also: we use the term seems because Rex's intentions are never certain, except perhaps when he actually buys.

It Seems Clear That Rex Does Not Want to Buy

When Rex arrives at a question and: AC shows him that the answer is in the system, and AC asks him to make an offer, and He does not make an offer, Then it seems clear that he has no interest in buying the answer. (If the question is linked to another question or questions, Rex might make an offer for an indirect answer. That is another matter. But he still seems to have no interest in a direct answer to the question he is at.)

It Seems Clear That Rex Does Want to Buy. When Rex arrives at a question and: He makes any kind of binding offer, whether it is for buying the answer immediately or whether it is a future commitment, Then it seems clear that he wants to buy (at least for the period of the commitment). When Rex arrives at a question and: He knows the answer is in, and He accepts ACs price, Then it seems clear that he wants to buy (after all, he does buy). When Rex arrives at a question and: He does not know if the answer is in (he thinks it may be in), and He accepts ACs price, Then it seems clear that he wants to buy.

It Is Unclear Whether Rex Wants to Buy or Not. When Rex arrives at a question and: He knows the answer is not in, and He does not make an offer or does not respond to ACs price, Then we cannot be sure whether he is interested in buying the answer. The problem here is that if Rex knows that an answer is not in the system, he may feel no incentive to make an offer or to reject or accept a price. He may feel it is a waste of his time to even bother. Like any shopper or bidder, he might want to know that a piece of merchandise is available before he bothers with the price. When Rex arrives at a question and: He does not know whether the answer is in, and He does not make an offer or does not respond to ACs price, Then we cannot be sure whether he is interested in buying the answer. He might not want to bother making an offer or rejecting or accepting a price if he isn't sure the answer is available. When Rex arrives at a question and: He knows the answer is not in, and He makes a non-binding offer (places an order), Then we cannot be sure whether he is interested in buying the answer. In this situation, he may be lying intentionally or unintentionally, like any buyer who expresses interest in a product that may arrive at some time in the future. His only cost is the time it takes to place the order. When Rex arrives at a question and: AC presents a price for Rex to accept, and He does not respond to ACs price, Then we cannot be sure if he is rejecting the answer or the price. The problem here is that Rex may feel no incentive to explicitly reject the price and no incentive to make a counter-offer. He may just not bother expressing any interest explicitly. Like any shopper who sees an item that he wants but that he thinks is priced too high, he may just go on to the next item without saying a word. This reasoning applies whether or not the answer is in and whether or not Rex knows whether the answer is in.

Some Rules and Functions and Options for Getting Rex to Declare His Interest

Given that in a variety of basic buying situations Rex may feel no need to express his buying interest explicitly, the ideal is for AC to read Rex's mind. That ideal will have to wait. In the meantime, AC can include various functions and options for getting Rex to declare interest. Below we list some of these.

"Reject Price" Button. AC can include a button that Rex can press to signify that he is rejecting the price of an answer. (AC can include other reject buttons so Rex can express other reasons for rejecting an answer.) Browse Mode. As noted, AC can include a separate mode where users browse questions. (AC might also register when Rex is browsing a question. Though browsing is not considered a request for an answer, the number of people who browse a question and their rate of browsing can be significant D-info.) Offer Palette. AC can include a palette for making price offers. The palette can include set price levels. This allows Rex to "click on" an offer, rather than entering one manually. It is a small difference but it may be enough to overcome his laziness. Get Price Button. AC can include a button for getting the price of an answer. If Rex bothers to get the price of an answer it may mean he has some interest in buying. Minimum Bid. AC can show Rex an amount that is the minimum offer Rex can make. Otherwise Rex may intentionally make an extremely low offer that tells little about his interest in buying the answer. Price Shown Only After a Binding Offer. AC can show Rex the price only after Rex makes a binding offer. Otherwise Rex can see the price and does not have to react to it. This way, by making an offer, he must show some interest. As noted, AC can stipulate a minimum bid. Survey. AC can a conduct survey asking Rex why he rejected an answer and providing a form for Rex to check-off the appropriate reason. AC can conduct such a survey randomly and use the data to create statistics for classifying requests.

Information AC Can Register About Rex's Buying Situation

We have described some basic buying situations above. These are characterized by what Rex does at a question and what he knows when he does it. As mentioned, the details of a sales situation can vary tremendously. Even though we have given the logical outlines of offer/counter offer situations, we have not captured any extra details. These details can be critical in compiling reliable statistics. For example, the statistics would be different for an answer costing 10 cents than one costing $10. Below list some key types buying situation information. The list below is not exhaustive. Other types of information can be registered. Most is repeated from above, some is not, and some from above is omitted. In the relevant situations then, AC can register the following information about Rex and his request:

Which search stats did he use to arrive at the question? Which A-stats did he see at the question? Was the answer in the system? Did the A-stats tell him whether the answer was in the system? Was a price presented to him automatically? Did he ask for the price? Was a price presented to him? If so, what was it? Did he accept the price? Did he make a counter offer? If so, what was it? Was his counter offer accepted? Was his counter offer rejected? If so, how low was it compared to the price? Was he asked to make an offer? Did he make an offer? If so, what was it? Was his offer accepted? Was his offer rejected? If so, how low was it compared to the price threshold? Did he place an order? If so, did he state a price? If so, what was the price? Did he make a commitment? If so, did he state a price? If so, what was the price? Did he know before he arrived whether the answer was in the system? (This can be relevant because AC can enable users to screen questions based on whether they have direct answers. Also, as discussed in section 5.1, AC can enable users to see whether questions that can be selected have answers.) Did he know before he arrived what the price of the answer was? If so, what was it? Did he know before he arrived that he would have to make an offer? Did he enter a new question? If so, which one? Did he travel to a linked question? If so, which one? Did he come from a linked question? If so, which one? Did he make an indirect o-request? If so, what search stats, did he enter? (Omitted here is information about altemative answers. This kind of information can be very important. The registering of this information is discussed in Book II.)

6.4 DEMAND STATISTICS Not all D-info is stored in the D-records of individual questions. AC compiles demand statistics based on the information in large numbers of D-records. The are used in the POF as historical information. The topic of demand statistics will only be touched on briefly. Statistics for projections, like formulas for projections, can vary too much to be described. Further, as noted, an evolutionary approach is best, where the predictive value of given statistics is tested. The point here is simply that in order to come up with good POF's, AC needs to compile statistics on a great number of situations in order to compare a given situation to similar situations in the past.

Population Statistics. AC can compile what we might call population statistics. These are based on the requests of large numbers of people in a great variety of situations. AC can examine similar pattems of request information that occur in a large number of D-records, and then check to see what the sales were in these similar situations. In other words, AC can see how actual sales correlate with certain pattems of request information — e.g., AC can examine all cases where a question has a single MMA o-miss request and see what that "predicts" for sales of the corresponding answer. An MMA o-miss will likely have different predictive value than an HMA o-miss. Moreover, the value of an MMA o-miss will also depend on how many other o-misses were registered due to the o-request that was involved (see section 5.3). Likewise, an MMA o- miss that was registered along with two other MMA o-misses will have different value than an MMA o-miss that registered along with a thousand other MMA o-misses. These are tiny examples. The point is that request information can vary widely. The only way for AC to develop discount statistics to evaluate different requests is to compile sales information on large numbers of cases. The factors that can be examined will explode, but pattems should emerge.

Individual Buyer Stats. It is useful for AC to compile statistics on the buying behavior of individuals as well. Such statistics can be used to develop population based statistics. Just as in baseball we can develop statistics about the chances that any player will get a hit, we can also develop statistics for individual players. What is the individual's chance of making a hit? We can further refine those statistics by given situation, for example, what are the chances of getting a hit with runners in scoring position?. As we know from something like baseball, innumerable statistics can be developed that may help predict performance. In ACs case performance means sales. However, where an individual is concemed, AC may not be able to see what sales are in many cases because often the individual does not buy in a given situation, and may not even be able to buy because the given answer is missing. Nevertheless, AC can develop statistics based on the individual's behavior. Consider the situation where Rex arrives at a question and: AC shows him that the answer is not in the system, and he did not know before arriving whether the answer was in, and he makes no offer. Now, how does AC evaluate whether Rex has any interest in buying the answer based on his past behavior? One way is to have AC check past behavior in situations where: Rex arrives at a question, and AC shows the user that the answer is in the system, and Rex did not know before arriving whether the answer was in. AC can then see what percentage of the time he made an offer in these situations. AC can then discount the request where AC shows that the answer is missing by the same percentage. Now this is not an ideal discount factor, for many other factors can come into play. We are just giving an example. Rex's buyer stats may be stored in a record about him and then pulled, as relevant, to discount his requests for different answers. The relevant statistic depends of course on the given buying situation Rex is in.

Examples Individual Buyer Stats. We give some examples below that show how AC can use the D-info discussed above. AC can keep statistics that answer the following questions about Rex. What percentage of the time does he buy an answer that he has placed an order for? (To give an idea of the importance of these kinds of statistics, consider: If one user buys an answer 1 % of the time when he places an order, then we see that, price being equal, the value of his request is less than that of someone who buys 10% of the time he places an order.) What percentage of the time does he buys when he has made a commitment to buy? When rejects a price, what percentage of the time does he buy later for less? What percentage of the time does he buy when he knows an answer is in? What percentage of the time does he buy a linked altemative answer? What percentage of the time does he buy an answer when he doesn't if it is in? What is his ratio of requests to purchases? How does his behavior change depending on the price he is presented and the price he is offered? Answers to these kinds of questions about Rex's past behavior can enable AC to make a better guess about the value of a request by Rex. Of course, we are not even scratching the surface, just giving several examples.

6.5 INFORMATION ABOUT ALTERNATIVE ANSWERS Knowing about the alternatives to a product can be important for guessing what the sales of that product will be. In AC, the products are answers and the principle is the same. And so, in the D- record of a given question and answer, AC can register information about answers that are alternatives to that answer. When we say alternatives, we mean alternatives as represented by questions and Q-records. The answers may or may not be in the system. We mean the actual and potential answers, as represented by questions and described by the A-stats.

The alternatives to answers in AC can be harder to identify than the alternatives to physical products in the real world. That's not to say that product situations are simple, for who is to say what all the alternatives are to a given product. However, there are usually far more alternatives to a given answer than to a given physical product because answers are often easier to supply than physical products. Moreover, AC does something that is not usually done in the world of physical products; it allows individuals to request their own versions of the products they want and to state the requests for similar products in a great variety of ways — ways that may or may not even seem similar. And so there can be a sea of altemative answers, the vast majority of which are missing. In other words, we have a sea of potential alternatives. This is a fundamental problem of AC: how to evaluate D-info in light of the multitude of alternatives that the D-info can apply to, and in light of the fact that preferable answers might be supplied at any time. The problem gets worse when we consider that answers and A-stats can be easily modified and that these modifications can change demand dramatically. For example, the price of an answer be changed. Though the potential alternatives to a given answer may be very numerous in AC, that does not change the fact that it can be quite valuable to gather information about these alternatives. The D-info AC collects about alternatives can help Sue decide what to do. She may want to decide whether supplying an answer is worth her time. Or she may already have supplied an answer and wants to see how the competition is affecting the sales of her answer. Therefore, AC can enable her to: a. see what some of the potential competition is, b. see the sales and POE of alternatives that are actually in the system, c. see, perhaps, how the competition is pulling sales from her answer.

Identifying alternatives is very important because of the problem of phantom requests. Say Rex asks ten similar questions none of which has an answer in AC, and say he only wants one answer. As noted in chapter 4, asking a number of similar questions is the common way that people ask for something, especially when they are not sure of the subject they are asking about. Well, which answer does he want? We have the problem of phantom requests. Nine out of ten questions are phantom requests. Or are they? This is a big problem and we will tackle it in Book II. Actually, we wait until Book II to tackle the whole issue of gathering information on alternative answers. That's because the issue is more important with linked questions and more explicit as well since alternatives are often linked to each other.

The problem of factoring in alternatives is still important with non-linked questions. It's just harder to collect information on the alternatives. Come-from-Q's and go-to-Q's are the most natural choices to identify as alternatives. Thus these are registered in the Q-record of a given question. One way to handle the problem of factoring in alternatives is to discount the value of requests. By discounting, it is assumed that a certain percentage of times that a request is registered, there is an altemative answer that a user will prefer and find. The "discount rate" for requests can be based on large statistical samples of requestors. However, we know that some people are more prone to being window shoppers than others. Thus, such discount rates will be more accurate in general if they take into account the buying behavior of individual buyers and apply a "user discount rate" based on an individual user's buying habits. Additionally, the rate can be based on the type of answer as well. In the world or physical products we know that some products, like jewelry, are more prone to attracting window shoppers than other, like hamburgers. As noted, the relevance of discount statistics and individual buyer statistics depends on numerous factors because buying situations can depend on numerous factors, for more numerous than we can identify. Still such statistics can be helpful. 6.6 TIME EFFECTS, RE-RUNNING QUESTIONS

As things change in the real world and in AC, questions and answers change. Some answers become out of date. Others are improved. The store of questions and answers grows. As new questions and answers are entered, what then is the relevance of past D-info collected for older questions and answers? How do we apply D-info collected in the past to new questions and answers. How do we even apply it to the questions and answers that existed when it was collected? There is no good general solution to this problem. It is another problem we will take up in more detail in Book II.

We mention one approach here that AC can take. AC can "re-run" questions, particularly MMA o-requests, from the past to see which different answers AC would have o-requested in the present. By "re-run" we mean that AC identifies the sources of o-requests and simulates that the o-requests have been entered again from those sources. AC then sees which answers are o- requested. The answers that are o-requested will change over time. Thus AC can somewhat adjust the o-request tallies for answers, at least with respect to MMA o-requests. For example, if Movie Review Casablanca ? is the source of 1 ,000,000 o-requests over the past year, AC can periodically re-run those requests to see which reviews, missing and actual, AC would o-request given the present store of missing and actual reviews in the system. (How far back in time AC goes to get o-requests is an open problem. As with so many other rules, AC must experiment.) As another example, an FB-Q might be, What are the top ten companies in the US by sales?. Now these companies change over time. And so when this question is entered for the first time, AC sorts the existing companies (say they are in a table) and comes up with the top ten. Now if AC re-enters the FB-Q at a different time, AC might come up with a different top ten. AC can enable Sue to ask that AC re-run o-requests in order to test what the effect will be on an answer Sue might supply. In other words, AC can enable Sue to enter a test question, as discussed in section 5.2, and then see what the effect is of past o-requests. Sue can identify these o-requests by their primary sources, but, more likely, she can choose questions that she considers to be close alternatives to the question she plans to answer. AC can then check the D-records of these questions for MMA o-misses and o-hits. AC can then check for the primary sources of those o- misses and o-hits. And then AC can re-run those MMA o-requests to see whether Sue's new answer would be o-requested by those sources.

6.7 SOME OTHER CONSIDERATIONS Changing Answers. If an answer changes, AC may nullify old offers both by itself and by Rex. AC can then allow fresh negotiations and may alert Rex to the possibility. The rules are variable. Brief Note About Price Tests With Price Ranges. Normally a price offer is at a single price. However, AC may enable Rex to present an offer as a range, especially when an the answer requested is not yet in the system. Like a poll taker who asks people what they are willing to pay for an item, AC can ask in terms of price ranges. Moreover, AC can include a form by which Rex can check off ranges rather than enter a single figure. A more novel idea is that AC can present an offer of a price range. That is because the nature of AC is such that a user may indeed end up paying a price that is in a range. Here we have the idea of projected price (see chapter 7).

Secrecy Issue. Now if AC does not reveal its price threshold for an answer, finding that threshold can be valuable to Rex. There is more information that can interest Rex: such as whether an answer is in the system and the POE (the POE may yield clues about whether an answer is in the system and about the price threshold of an answer). In many cases it will be best for AC to disclose all this information. The price, the POE and the presence or absence of an answer can help users, apart from buying answers. For example, a user in check mode needs to see the POE's. As another example, Rex may want to screen answers according to price range. And yet oftentimes it will be useful to keep such information secret. There are no universal rules. In cases where secrecy is desired, AC can employ security methods to stop Rex from cheating. Primarily these are authentication techniques, because the key way people would cheat is to use confederates (or use the ID information of confederates). Rex can have a confederate make a lowball offer in order to learn about a price threshold. In addition to authentication methods, AC may seek suspicious correlations the behavior of users because a cheater will likely have the same person(s) cheating on a repetitive basis.

6.8 INVESTMENT OFFERS

AC can include means and rules for enabling Rex to invest in the supplying of an answer. There are difficulties here as to the rules for determining which Sue would get to use the investment funds. We are not going to delve into this issue. Suffice to say that AC can include rules for the making and accepting of investment offers. These can be of major importance. (See also Projected Price in chapter 7.)

Chapter 7: Price Setting in AC

AC sells answers and so those answers need to be priced.

A Quick Digression on the Difficulties of Pricing. Many problems of setting prices are the exact same as those of measuring demand, for "measuring" demand really means trying to find out how much people are willing to pay, in total, for something. As noted, the key problem is that we cannot read minds, for if we could, we would know how much a person was willing to pay for something. When setting a price, one can only guess. And the problem is usually more complicated than that because there are usually multiple buyers, each who may be willing to pay a different maximum price. Another complication is that the goal of setting prices is vague. There can be many goals. One is "profit maximization." Here a seller tries to make the most money. Another is "reasonable rate of return." Here a seller just tries to recoup his effort plus a profit, adjusted perhaps for the risk he has taken. Of course, deciding what a person's effort is worth is a subjective exercise, as is judging the risk taken. Another complication is that to arrive at a "fair" price we may have to judge what will be paid in total in the future. What will be paid depends on the vagaries of the future and on the price itself. Another complication is that one has to price with the competition in mind. Who the competition is may not be clear and, further, the competition may price in reaction to one's own price. Let us add yet another complication. The effect of price on units sold is highly variable. There is no universal, smooth sales curve where a given reduction in price means a given increase in units sold. Further the effect of price on total sales income can be even more variable. The problems above apply to the pricing of most goods and services and information. But information, answers, have another aspect that can further complicate the setting of prices. Unlike most goods and services, information is easily copiable. This means that an answer can be sold profitably at very different prices to different buyers. So the pricing of information can involve pricing schemes not usually seen with physical products.

Note on Definition of Price. In this section, we stick with the definition of price in the chapter 6: the amount that an answer is sold for to a given buyer at a given time. However, in this chapter, when we say a price is set, that can mean a price or price threshold. We say "price" often because it is easier than saying "price or price threshold." The problem is that sometimes the idea of a threshold does not apply, for a price may be shown to all with no secret threshold and no negotiation involved. Perhaps we should distinguish between open prices and price thresholds. Sometimes we will use the term open price, but usually, for convenience, we will stick with the term price. It is hoped that the reader will understand by the context where price thresholds are inappropriate and open prices are the only choice.

7.1 WAYS THAT PRICES CAN VARY IN AC The previous chapter showed how the concept of a single price is deceptive. In reality, an answer may have many prices. An answer may have a single price for all buyers that remains fairly static. It may have a single price for all buyers but one that fluctuates rapidly. An answer can have multiple prices according to various factors. Below we list some of the ways that prices can vary. The point is simply to show that prices can be set in AC using a great variety of schemes. Prices that vary with sales. Where the price of an answer depends on the answer's sales level. The price may rise or decline. It can also decline to zero after the answer has had a given amount of sales. Prices that vary by date. Where the price of an answer depends on the date it is sold. Prices that vary by time of day. As in peak and off-peak. Prices that vary by identity of buyer. For example, student rates. Prices that vary according to the competition's prices. For example, a meet-the-competition rule. Projected prices. Where a buyer can be rebated depending on future sales of an answer. We elaborate on this concept later, below.

Price Plans. Normally when we think of setting the price of something we think of setting one price at a given point in time. However, we can also think in terms of price plans where prices over time are set according to some formula. AC can have standard plans and can enable a supplier to pick a given plan for an answer.

Price Per Answer or Per Period of Search Time. Normally when we think of setting the price of an answer, we think of setting a price for that individual answer. However, pricing per period of search time is a popular and convenient method. In this method, the answers outputted during a period of time to a given user are credited according to the user's charges for that period. For example, if a user gets 10 answers in ten minutes and is charged $1 for those ten minutes, then each answer might get 10 cents royalty credit. How royalty credit is split among answers can vary. The price of search time can vary in some of the same ways that the price of an individual answer can vary. Pricing by search time is a price category method of setting prices (see below).

7.2 BASIC WAYS PRICES CAN BE SET Basic Ways That AC Can Assign Prices and Price Thresholds to Answers

Given the wide variety of pricing schemes, what we are mainly concemed with in this chapter is: a) Who does the price setting, and b) What AC provided information can be used to do the setting. There are three parties that AC can enable to set prices, whether before or after an answer is in the system. These apply for the changing of prices as well. (As noted, we use the term price to mean open price and price threshold.) 1. AC can have system operators set prices. 2. AC itself can set prices using price setting formulas. 3. AC can have suppliers set prices. (Note: When a secret price threshold is set, a negotiation takes place. In this case, Rex makes an offer. In a sense then, Rex partially determines the price that an answer is sold for. If his offer is above the threshold and the answer is in the system, he gets the answer. By determining how far above the threshold price he is, he is also partially setting his own price, the actual price the answer is sold for.)

Information Loop for Price Setting

Regardless of who sets the prices, the general information flow can be a feedback loop as follows: Price setter sets price — >Price test done — >Price test data sent to D-record — >D-info in D-record sent to POF — >POE calculated by POF — >POE sent to price setter for evaluation — >Price setter sets price.... This particular loop is not always mandatory, but what is mandatory is that the relevant D-info registered by AC is made available to the price setter.

Note About Setting Prices Before or After an Answer Is In the System

As seen in the previous chapter, the price of an answer can be set before or after the answer is in the system. If the price is set after, then there is no price before. A problem seems to exist as far as the POE is concemed. If there is no price then how can there be a POE? Well, the POF can include assumptions for guessing what the price will be. These can use price test and historical information. The POF can also give multiple POE's based on different prices and users can judge which price they think is most likely. Further, AC can enable users to plug their own price guesses into the POF to see different POE's.

1. System Operators Setting Prices. System operators cannot feasibly set individual prices for answers, but they can define standard price categories, such as a one cent each category, a five cent each category, a two dollar category, and so on. As noted above, a variation is charging a standard amount per period of search time. System operators can define price categories and then suppliers can choose which categories to put their answers in. (An answer may be put in more than one category at a time.) In that way, the system operators and suppliers are setting prices together. Categories may be defined not only by price but according to the content of answers. In certain cases, suppliers may be forced to put certain kinds of answers in certain categories. For example, certain phone numbers might have to cost a certain standard amount. Now when we say price categories, we do not mean just one-price-for all categories. Prices can vary in many ways. A price category is defined by known rules that determine the prices of the answers in the category. By these rules, a user knows ahead of time how much a given answer in a given category will cost for that given user. Rates can vary in standard ways based on different factors, as discussed above. Where price categories are concemed, AC can enable Rex to file a price complaint if he thinks an answer costs too much, in other words if the answer does not fit the conditions of a given price category. (Note: Rex can specify a price category when he asks a question. If the answer is missing, a supplier of the answer knows that to fit in that category, the answer must carry the specified price. Rex suggests the price of the answer, but it is Sue who decides whether to put her answer in that category.)

2. Price Setting Formulas. AC can include price setting formulas that take D-info for an answer and calculate a price from that. Thus the information in the D-record for an answer can be fed not only into the POF but also to the Price Setting Formula (PSF). Indeed, the POF can have price assumptions in it and these can be changed by the PSF. In the loop above, the PSF is the price setter. The loop shows how D-info can be crucial for setting prices and for estimating pay-offs, and further, how the results of setting prices can affect POE's, and how POE's can affect the setting of prices. Pricing is a helluva feedback situation. Because so many real world factors can affect price, PSF's have great limitations. On the other hand, because AC can accumulate a large body of experience with similar situations, its PSF's may potentially do a good job of setting prices, or at least a good job of advising users.

3. Suppliers Setting Prices. AC can enable Sue to set the price for an answer she supplies. Of course, she can also change the price of her answer. As mentioned, AC might have certain price categories and Sue can put her answer in one of these. The system can also show Sue the prices that exist for comparable answers. She can then apply her common sense. Thus the Q-display can include a price setting option that Sue can select to enter a price for her answer. This option can have a sub-menu so that Sue can select some other options for seeing information that can help her make her pricing decisions. AC can make all D-info available to Sue so she can make a better guess as to the best price to charge. For example, AC can show the rate of requests received, the times the requests were made, the variety of offers, the average offer, the range of offers, and other price test information. Sue can then apply common sense. AC can enable her to ask for help from the PSF. When she selects this option AC can also enable her to plug in various guesses about future demand for her answer and possible prices. In any case, Sue's common sense will still not be good enough to figure out the "best" price for her answer. This problem will be solved when the Vulcan mind meld is incoφorated into software, but that is another story. In addition, as a sub-option, AC can enable Sue to have AC automatically set and monitor the price of her answer. In this case, she can set the initial price and AC can take the price setting from there, using PSF's that attempt to maximize her income. In addition, as a sub- option, AC can enable her to set several different kind of alerts, alerts about the D-info concerning her answer. Like a marketing manager, she can ask AC to keep her apprised of key sales data concerning her answer. If we think of AC as a vast bazaar for answers, we can think of Sue as a peddler who rents a stall (a signomat). In order to wheel and deal properly, she obviously needs information about the sales of her product and she'd like information about the sales of the wares of other peddlers. She can ask to be alerted when the POE drops below a certain amount, when the actual sales and the actual sales rate hits certain values, and when the prices of comparable answers change by a certain amount or percentage. If she chooses to keep abreast of comparable (altemative) answers, she may need to identify them to AC (though as we will see in Book II, AC can have means for identifying comparable answers). She might ask to be alerted directly when a buyer makes an offer that is below her threshold. She may want to negotiate directly or respond with a counter offer quickly. These are just some of the key alerts possible. (We will see similar alerts in chapter 9 about the pay-off meter.)

7.3 PUBLIC AND PRIVATE DOMAIN PRICES AC likely will have mles for limiting the royalty income that an answer can generate. AC can keep track of the total royalty income of an answer and when the income exceeds a threshold, a cap, AC can make the answer royalty free. Another way AC can limit royalty income is to set a time limit during which a user can get royalties. After such a time limit, or income cap, is exceeded, we might say that the answer passes into the public domain. Once AC puts an answer in the public domain, AC might drop the price to zero or to some very small amount to compensate for overhead. Or, AC might keep the price high in order to profit for itself. For convenience in the discussion, we will assume that answers in the public domain are free or near free. Now to go into the public domain, the income cap must be reached. How is that cap set? There are no good general mles known. The solution in patent and copyright law is to not to set a cap but to set a time limit for protecting income (property rights). This seems stupid in many cases. AC can give users the choice of a time limit or a cap. The setting of income caps is an important area where mles need to be developed by experiment. Though we cannot suggest good mles for setting income caps or time limits, we will assume AC enables caps and time limits to be set by AC or Sue or a judge or Rex's, or some combination of these parties. When Sue is still due royalties for an answer, we will say that the answer is in the private domain.

"Reverting" to the Private Domain. Most answers can be changed. For example, a phone number may need correcting, a blueprint may need revising, a recipe for chocolate chip cookies may be improved. As discussed in chapter 5, changing an answer requires Sue's effort and so she needs to be compensated. Thus, if an answer that is in the public domain is changed, it "reverts" to the private domain. This way of stating the situation is a little misleading. When an answer is changed, the original version is still is a past answer that is in the public domain. It is the new version that is in the private domain. (Rex may thus choose a past answer that is in the public domain rather than a current answer that is in the private domain.)

Demand Information Still Registered and POE Still Calculated. If an answer is in the public domain, AC still registers demand information and calculates a POE. That's because the answer may be changed and consequently revert to the private domain. Since the price is zero in the public domain, the POF must have price assumptions as to what the price of the changed answer will be. There can be various changes and various prices.

7.4 PROJECTED PRICES The idea of a projected price was mentioned above. We elaborate here because the idea is new as a method of pricing answers in an answer base (data base). What is a projected price? First let us say that AC can present an initial price and a price range. The initial price is the price that Rex is obliged to pay initially to receive an answer. (If the answer is not in the system, the initial price may be what Rex commits to paying.) The actual price is the price he winds up paying over time. The price range is the range of prices he might end up paying, from the initial maximum amount to some lower minimum amount that Rex may end up paying. AC can estimate the actual price, and this estimated price is called a projected price. For example, AC might present an offer where the price range of an answer is, say, between $2 and 20 cents, and the projected price is, say, 50 cents. How can AC have these different prices? By rebating Rex based on the future sales of the answer. Let's take an illustration. Let's say that a question is, What is a list of the major hologram sellers in the US. ?. And let's say that Sue is thinking of compiling the list. And let's say she wants to be rather sure of being compensated for her time. She might want, say, $20. And so, she might set the initial price for the hologram answer high, because she think that will raise the chances that she will be paid the $20. Thus the first ten Rex's might be charged $2 each. These ten Rex's can be presented with a initial price of $2 and a projected price that is lower. Once Sue has gotten her $20, a share of any additional sales revenue from her answer can go into rebating the first ten buyers. Say that another 100 Rex's buy her answer. These Rex's can be charged less, say 40 cents each, and the first ten Rex's can be rebated an amount. Thus the actual price that the first ten Rex's pay is not definite, but depends on the total sales of the answer they have bought. Of course, many schemes are possible for rebating a buyer according to sales that occur after the buyer has bought at an initial price. The initial price can differ for different buyers and the rebates can differ for different buyers. Just as the system has a formula for calculating a POE, it can have a formula for calculating a projected price. The projection depends on ACs sales projections. Thus Rex's projected rebate is just a modified version of Sue's projected pay-off. Rex's rebate may be greater even than the initial price he paid. In other words, if the answer sells enough, Rex may get a profit from buying the answer. The minimum price he pays may be a negative price. This idea is not as crazy as it seems. Early buyers can be looked at as investors. They are the "early adopters" who pay the initial higher price, and in some sense deserve to share in the rewards of the lower price. They may share to the extent that they even profit. This is a fundamental way of paying for innovation.

Who Makes the Projected Price Offer

AC can enable Rex to make a price offer where he offers to pay a higher initial amount in retum for a share of future royalties once a cap has been reached. AC can enable him to choose from standard plans for the sharing of royalties between Rex's and a Sue. AC can also enable him to craft his own offer using a form that AC provides. Likewise, Sue can make a price offer where she offers to pay a share of future royalties in retum for a given Rex or set of Rex's paying a higher initial price. She too can choose from among standard plans AC or craft her own. Regardless of who makes the offer, Sue must agree that it applies to her answer. In other words, a projected price is another kind of price that can be set. A given Rex can then agree to pay the price or not. In order to implement a projected price, AC stores the standard or custom plan in the credit record for Sue's answer. AC then keeps track of the income generated by her answer, and when the income exceeds the specified amount, AC rebates Rex's.

Chapter 8: Registering People's Interest in Supplying Answers and Registering People's Rights to Supply Answers

Let' s assume that the POE for a given answer is $10,000 and is a good guess of what users will pay in total for the answer. The answer is a large nugget of gold then, so to speak. But is it fools gold? That depends on how much it costs to try to find. And it depends on the chances of finding it. And it also depends on whether there is competition, for if another prospector finds the nugget first, the mining trip will be a bust.

Potential Competition and the POE

So let's say a stranger offers to pay $10,000 to the first person who measures the vacant space in the Empire State Building. You see the offer and think the amount is generous. But do you do the job? Before doing anything, you want to know more. You ask the stranger, Who else knows about this? The stranger responds, A number of people. And you ask, Well, how many of them are interested in finding the answer? And she responds, / don't know. And you ask, Well, do you know if anyone is up there measuring right now? And she responds, I don't know. And you might say, Count me out. The potential competition might naturally scare you off. Your projected pay-off for providing something is drastically reduced by potential competition. A potential competitor might take all your royalties or force you to split royalties (how royalties are divided depends on the mles of the particular situation). Regardless of the royalty sharing rules, you face a risk of your income being cut, and so you must factor that risk into your estimates. Say the royalty sharing rule is that the first supplier gets all the royalties. Say you think the chances someone will beat you to the punch are 50%. In this case you think your POE is cut by 50% on an expected basis. While your POE is cut, your cost of finding an answer stays the same, and so you may (or may not) have a negative projected profit. Not only that, but other users in your position can feel the same way and so no one may find an answer for fear that someone else will do it first. In many situations, ignorance can reasonably lead all interested parties into believing that the projected profit is negative.

Presuming an opportunity is spotted in the economy by one or more people, how is the job of exploiting the opportunity assigned? What is a "rational" way to assign tasks if there is no single customer or boss to decide? Well, there is none that anyone knows of. All we can do is keep some goals in mind and choose certain methods in certain situations. There are no universals. In the economy of AC, in order to use people's resources best, we would like to reduce the duplication of efforts. That is a vague goal and yet we can't say much more for there is no general way to define tasks and duplication, no general way to define the effort required to do something. Another goal is to get the most valuable total store of answers into AC. And yet that is equally impossible to define, for what does valuable mean. While we cannot escape from vague goals, they can guide in developing measures to test assignment mles. We can sometimes see that efforts are wasted and that certain answers are more valuable than others. Hence we can develop mles and functions that reduce the duplication of efforts and increase the store of valuable answers. And we can improve these rules and functions. This is a topic we do not delve into. Assignment mles and functions are discussed below, but not measures to test them (see the preface of Part II). The key object of such mles and functions is to get answers into AC in the first place, and that depends on the pay-off equation for potential suppliers.

A Few Names for the Discussion

We will call a potential supplier a prospector. A user can be a prospector in any mode. In fact, all users are potential suppliers and thus prospectors. We will also distinguish sometimes between a prospector, which any user can be, and a live prospector, which is a user who has registered interest in supplying an answer. For convenience, we will sometimes call a live prospector by the name Fisher (after Mel Fisher, the treasure hunter who found the sunken Spanish galleon Attocha). We might think of a user in request or supply mode as Rex or Sue Fisher. We will sometimes use the term job in place of "supplying the answer."

The Prospector's Pay-off Equation

The pay-off equation for a prospector determines whether or not an answer will be provided. The basic equation, ignoring the evaluation of alternatives, is: (Projected reward) - (projected cost) = projected profit. Since uncertainty about the competition can wreak havoc with the projected reward, it can be crucial for a prospector to find out about, or nullify, the competition.

Two General Approaches

AC takes two general approaches to help a prospector evaluate the POE in light of potential competition and to help protect the prospector's future royalty income. One is to enable prospectors to communicate with each other so they can voluntarily reduce the duplication of efforts. The other is to give prospectors property rights, exclusive rights to supply answers. (AC also gives copyrights. These are discussed in chapter 14 on Property Rights.) For convenience we discuss these approaches separately, though communication goes hand in hand with property rights and property rights are a form of communication. The various methods involved in these approaches are not ideal solutions. In fact there seems to be no ideal solution where competition is concemed. There are reasons to keep competitors informed and reasons not to. There are reasons to restrict competition and reasons not to. As usual where answers are concemed, the range of situations is extremely diverse and no general mles can be prescribed. Prospector Menu

Information about people's interest in supplying an answer is A-stat information. So is information about property rights. Both kinds of information, like other A-stats, are entered at the Q-display, are stored in the question record, and can be accessed from the Q-display. Thus the Q-display can include a prospector button that can be selected and can lead to a prospector menu of options that include the ones to be discussed below. When a user is at a question then, he or she can select the prospector button to assert interest in supplying an answer and/or assert rights to supply an answer. Further, a user can see who the prospectors are for that answer and/or what kind of interest or rights each has asserted.

8.1 ENABLING PROSPECTORS TO COMMUNICATE

AC enables prospectors to communicate with other each other. By communicating, they can better assign the tasks of supplying answers. They can stay out of each other's way, and they can better evaluate when a POE will turn negative due to competition. When we say communicate with each other, we mean that they can post messages in the Q-record for all interested users to see and that they can also direct messages to the E-mailboxes of specific live prospectors. AC can enable users to post several different kinds of interest messages. These can be standard messages that are stored in the question record and displayed upon request. AC can also compile prospector statistics based on the information registered from multiple live prospects. Below we list some of the kinds of messages AC can enable users to leave.

Non-Binding Expressions of Interest. AC can enable a user to post a message expressing a non-binding interest (NBI) in supplying an answer. By "non-binding" we mean that the user states that he is interested in supplying an answer, but that the statement carries no commitment and no penalty for non-performance. As one of the options in the prospector menu then, AC can include a button the user selects to enter NBI information. When a user selects this button, AC registers that he is interested in the answer, and AC can present him with a form that asks for more information such as: When do you think you will enter the answer by? What are the chances you will enter it?How much labor do you expect it will require to find, and what kind of labor? What are you planning on charging? This information is registered in the Q-record and can be displayed upon request. AC can combine the information registered from different prospectors into collective statistics, such as the number of NBI messages registered. Another NBI message that AC can enable users to enter is one that expresses interest contingent upon the POE rising to a certain level. Thus Fisher can leave a message saying he is interested in supplying the answer once the POE rises above a certain threshold. Of course, in this case AC also registers the threshold that Fisher enters and sends him an alert message if the POE rises above the threshold. While an NBI message carries no commitment, AC can keep track of Fisher's record of following through over a series of answers, i.e. does he enter the answer, does he enter it by the time he says he will, and are his odds estimates fairly accurate?. That way people can evaluate whether a prospector is much of threat to supply an answer. AC may keep such individual prospector stats in a user's record and may attach them to an NBI message. For example, if Fisher posts an NBI message, AC can add a statistic telling the percentage of times he has supplied an answer when he has posted an NBI message.

Binding Expressions of Interest. AC can also enable a user to post a message expressing a binding interest (BI) in supplying an answer. By "binding" we mean that Fisher commits to supply an answer by a certain time. AC registers the time and checks to see if Fisher has fulfilled his commitment. AC can assess penalties if Fisher fails to fulfill the commitment. We call this type of commitment a BI message. As with an NBI message, AC can ask Fisher to enter further information, such as information about charges and labor requirements. As with an NBI message, AC can keep track of Fisher's record of following through over a series of answers.

Prospector Alerts. When Fisher is at a question, he can check the current prospector information that has been registered. Say that after seeing the currently registered competition, Fisher decides to enter an expression of interest. While he sees the currently registered competition, he might like to know about other people who express interest after he does. And so AC can enable him to ask that an alert message be sent to him each time AC registers interest by someone else. The alert can include some or all of the interest information registered.

Collaboration Offer. AC can enable Fisher to post a message asking others to collaborate in finding an answer. The message can be in a standard form, or it can be lengthy, spelling out Fisher's proposal. The terms of the collaboration may be worked out by direct communication. (We will not discuss collaboration much further though it is a very important area. We assume AC has rules for enabling cooperation and for the splitting of royalties. These mles and attendant functions can, of course, vary widely.)

Elaboration Requests, Elaboration Messages, and Elaboration Questions

Thus far we have skirted a big issue. When a user declares an interest in supplying an answer, what is the answer? This is the multiple answer problem, which we discussed in chapter 4. We will revisit it only briefly here. Since there can be multiple answers to a question, declaring interesting in an answer may tell little about one's intentions. Other prospectors can remain quite uncertain. And so, AC can enable users to send a message to a Fisher asking for clarification about what answer he intends to supply. We call this an elaboration request. Because of the multiple answer reality, this option can be critical. The elaboration request can be standard, such as: Please elaborate, or it can be lengthy, asking for various details. Fisher can respond with an elaboration message. This can be a discussion of what he plans to do. This is an A-stat, like the other prospector information, and can be accessed through the relevant Q-record. We point this out because it is in contrast to a second method of implementing an elaboration message.

The altemative way for Fisher to elaborate is by entering a new question, the question he intends to answer. We call such a question a More Specific Question. It is discussed at length in book II. For example, say Fisher expresses an interest in supplying the answer to, What is IBM's phone number? Well, which number at IBM? Clearly, clarification may be very useful. Say the question is, What is the text of Hamlet's soliloquy?. Well, which soliloquy? And in what language? Again, Fisher can say more specifically what he intends to supply. Say the question is, How do you get rid of crabgrass? Again, Fisher can get more specific. He may enter a new question such as: How do you get rid of crabgrass by obliterating all your grass? How do you get rid of crabgrass by chemical means? How do you get rid of crabgrass by the introduction of a different kind of grass?. Since the elaboration message is actually a new question, the original question is linked to the new question. (We save the mechanics of more specific questions for Book π.) The process of clarification can go back and forth with Fisher responding and prospectors asking for more elaboration. How much elaboration Fisher needs to give, and how quickly depends on the situation and the rules in that situation.

Direct Communication. AC can enable Fishers to contact each other directly. That way they can more forcefully warn each other off. They can ask each other to collaborate. And, they can ask each other to elaborate on what they are planning and doing.

Disclosure Document Option. AC can include a disclosure document option. By this we mean that Fisher can enter information that shows the progress he has made in finding an answer. AC does not store this information as the answer but does store it in the Q-record. More than one Fisher may submit a disclosure document. Of course, the information can be kept secret and can be divulged upon the permission of Fisher. Disclosure document information can be essential where it is important to demonstrate what progress has been made, and to demonstrate priority.

8.2 RESERVATION RIGHTS

Often communication is not enough to reduce duplication of efforts and insure that a prospector's POE is positive. Some prospectors who intend to supply an answer may not communicate their intentions. And even when they do, it is uncertain whether they will supply an answer and when. For any prospector then, despite communication channels, great uncertainty can remain about potential competitors. Therefore, in order to protect a person's investment in finding an answer, what are often needed are property rights, exclusive rights to supply an answer. We will call such rights reservation rights or reservations for short. A i rson who gets a reservation will be called a reserver. The general idea is that when a user is at a question, AC can enable the user to enter a command such a Reserve after which AC stores the user's ED data in the Q-record to denote that the user is the reserver of the corresponding answer. Then, for a period of time, AC allows only that user to enter the answer. AC also shows other users that the answer is reserved for that period. Reservation rights can vary widely. They need not be long-term, exclusive monopolies. They can cap the amount a supplier will make and they can be semi-exclusive. Parties may collaborate under the protection of such rights. A possibility is to allow part of the royalty income from an answer to be protected while the rest is left open to unrestricted competition. One variation is to allow another user besides the reserver to supply an answer, but to keep this second answer undisclosed until the reservation period mns out. The reserver still gets royalties for his answer provided he supplies one. The reason to allow another person to enter an answer is that the reserver may decide he cannot fulfill his commitment, or may just fail to fulfill it. In either case, the second supplier's answer can then be used.

Disputes, Judges, and Elaboration Rights

Where there are property rights there will be disputes. As disputes are inevitable, AC must have judges to assign credit. The main problem, which is discussed above, is determining what answer a person has an exclusive right to supply. What answer is Fisher claiming? It is tempting to think of reservation rights in terms of land, where a prospector stakes a claim to a piece of ground, yet the analogy is deceptive. Answer are usually unlike land. One solution, as discussed above, is an elaboration request and an elaboration message. Where reservation rights are concemed, the request can be an elaboration right in itself, the right to demand that a reserver elaborate on the answer she intends to supply. This option is usually vital to make reservation rights work. It too involves a time limit, in this case a time limit to respond. Thus AC can keep track of the time and can penalize a reserver if she does not respond in time.

The Best Laid Plans

Reservation rights are different than copyrights and patents, yet they share some similarities, for all protect the income a person gets from an answer. All protect against uncompensated copying in essence. The big difference is that reservations concern answers that are planned, answers that have not yet been supplied. So disputes can arise over copying what is not yet even found. Prospectors who would like to supply an answer naturally may be afraid of interfering with an existing reservation. Moreover, two reservations might interfere as well. For example, say that a question is, What's causing this traffic jam? Now a user reserves the answer to this question and goes off to find the answer. Let's say that a second user wants to answer the question as well. This second user is an eyewitness to the accident that has caused the jam. She might think it pointless to enter the answer though because someone else has reserved it. Yet the original reserver might not be able to find out the answer for a period of time. Further, he might come up with some other answer. And so we have a problem. One solution is to have the second prospector enter a more specific question such as, What's causing this traffic jam, according to an eyewitness?, and then enter her answer to this question. A dispute may arise later or it might not, depending on what answer the original reserver planned to enter and where he planed to get his answer from. Given these problems, AC can enable users to consult a judge who can give an opinion about a potential interference.

Completion Clock. A reservation only lasts for a certain period of time. (Time limits can, of course, vary widely.) And so AC can have a completion clock that, like a 24 second clock in basketball, keeps track of the time limit once a reservation is granted and shows how much time is left until the reservation runs out. AC can maintain a waiting list of people interested in getting a reservation. People on the waiting list can be granted the reservation should the reserver fail to do so within the time limit.

Fees and Penalties. In order to provide a greater incentive to reservers to fulfill their obligations, AC can assess fees for reservations. Likewise, AC can assess penalties should a reserver fail to fulfill his commitment.

8.3 RULES FOR ASSIGNING RESERVATIONS

Presuming a reservation can be granted for an answer, how is the right to be assigned? There are several basic selection methods which we describe below. The simplest is a first come first serve rule, where the first prospector to sign up for the reservation gets it.

Reservation Clock. If a first come first serve rule is not in effect, AC needs a reservation clock. This clock sets a period of time during which prospectors are eligible to sign up for the chance to get a reservation. AC displays the clock. The clock may be started when the first prospector signs up for a reservation to a given answer.

Alerts to Interest Parties. Once a prospector asks for a reservation, AC can send an alert to all the live prospectors for that answer. The alert shows the time on the reservation clock. Live prospectors can then respond as to whether or not they want to be part of a selection process for the reservation.

Assignment By Lot. One basic selection process is random selection. Thus AC can randomly choose a Fisher to get the reservation.

Assignment by Auction. Another basic selection process is an auction. There are different kinds oi auctions that AC can hold. The auctions may be silent or open. One kind of auction is a highest bid auction, where Fishers bid on how much they will pay for the reservation. The highest bidder wins, and AC charges him accordingly. A different kind of auction is a lowest price bid auction, where the Fisher who promises to charge the least for the answer wins. In this case, AC sets the price of the answer once it is supplied according to what the winning Fisher has pledged. A variation is a lowest cap bid auction where Fishers agree to cap the total royalty income for an answer. The Fisher that bids the lowest cap wins. In this case, should the answer be supplied, AC stops royalty payments once the cap has been reached. Another kind of auction is fastest completion bid auction, one where the Fisher who bids to do the job fastest wins. In this case, AC can keep track of whether the winning Fisher has supplied the answer within the time pledged, and can assess penalties if not. The big problem of course with all such auctions is that winning is based on one parameter, such as price. An auction where more than one parameter is involved is hard to do and requires more complicated scoring methods.

Letting Buyers Assign Rights. Typically in the economy a single buyer decides who does a job. There are various ways for a buyer to do this. But what happens when there are multiple, unrelated potential buyers? How can they collectively select who gets to do a job? Well, we have an economy where people "vote with their wallets." Collections of customers decide which company has the better product and therefore ultimately who gets to do a job in many cases. While that may be okay for products that already exist, how can unrelated potential customers collectively select who gets to produce a product that is yet unmade? How can they decide who gets a reservation right, who gets to do a new job? As yet, there is no good way in the general economy. In AC it can be arranged so that sometimes it is practical for them to see the credentials of the various candidate prospectors and vote on who should get the right. Hence AC can include procedures for enabling requestors to vote to pick which live prospector gets the reservation. The quality records of prospectors can be displayed (see chapter 13 on Quality Control). Another method is for requestors to grant reservations individually. By this we mean that a requestor can specify along with a request that he is giving a reservation right to a supplier. A requestor can name a supplier or let anyone be eligible for the reservation. He can further specify various details about the right, including whether the right is assigned on a first come first serve basis or whether it is by some other method. If by some other method, he can also specify the time on the reservation clock. AC can also enable a Fisher to poll prospects and ask them for exclusive rights. In cases where requestors grant reservation rights the problem is that different requestors can grant different rights and to different Fishers. There is no general solution to this problem. AC can include various mles for standardizing rights. Further, AC can enable a Fisher to see what kind of rights he will get given all the various ones that have been offered. There are various ways to "total up rights." Another problem arises which is that there is no way to poll future requestors and thus determine whether a Fisher will get royalties from sales to those requestors. If some requestors give reservations and others do not, who is to claim the royalties from future sales? We might assume that a reservation right includes the right to share in some or all of the future sales of an answer. But if the reservation is only conferred by certain requestors, how do we determine what share a reserver gets, especially if he is not the first the supply an answer? As with all mles about reservations, there are no universals. AC must simply include certain mles to determine the splits.

Selling Reservation Rights. A reserver can sell his reservation to another Fisher. This option can be important because it is a solution to the problem of what to do about a Fisher who is in a better position than the reserver to supply an answer. Thus AC can allow users to post messages for offering to buy and sell reservations, and can enable users to execute the transactions. These messages can be stored, as with other A-stats, in the Q-record, and can be accessed through the prospector menu.

First-to-File or First-to-Find, the Problem of Tipping One's Hand. A Fisher might not want to seek a reservation because he might not want to tip his hand about the direction of his research, about what he has found so far, about what he plans to supply. This is the problem of giving protection on a first-to-file basis or a first-to-find basis (in patent law the issue is first-to- file versus first-to-invent). Both approaches have merit. Therefore, AC might allow Fisher to take either route, giving rights to both first to file users and first to invent users. In other words, a reserver who chooses first to file would share royalties with a reserver who chooses first to invent. The key to splitting royalties is a disclosure document discussed above. If Fisher wants "first-to-find" rights, he needs to supply evidence of priority in a disclosure document.

8.4 USING PROSPECTOR INFORMATION IN THE POF

Because potential competition can be a very big factor in the POE, AC can include variables for prospector information in the POF, and can feed prospector information into the POF. AC can show two POE's, one that factors in prospector information and one that does not (as will be seen in chapter 9, AC can show various POE's). AC can use historical prospector information as well. Just as AC can collect information on buying situations, AC can collect information on potential supplier situations. We might call these prospector situation stats, which are distinguished from individual prospector stats that concern a single individual's record. For example, AC can compile statistics on the likelihood that an answer will be entered, and the likelihood of when, given various prospector situation facts, such as the number of NBI and BI messages that have been registered. As with buying situations, prospector situations can be characterized in a variety of ways. Here we have not made an attempt to list the basic situations. We have given some key pieces of prospector information that can be registered that can be used in characterizations. Other information that can be used was discussed in the chapter 6 on registering demand information. Chapter 9: The Pay-off Estimate

Preface: Elaborate upon the notions of the POF and POE: a. I-signal, esp key alerts: notifying Rex when POE rises above a threshold, notifying Sue when POE drops, so she can take action, such as lowering price, b. Multiple types of POE's for: correcting, updating, improving, referral... Key is mles defining each kind's share of the answer's income stream, c. Split out POE's based on D-info from given actual answers, d. Get just D-info processed, like trend lines, e. What-if POE's where you plug in different values for POF variables such as different price and time assumptions (of course, supplier cs. such as, ballgame ends), f. Pick-your-POF according to success in similar situations. User can pick the similar situations. Conservative to optimistic POF's. g. See sources of o-requests. h. See comparables. i. Check mode.

Chapter 10: Royalty Rules

Royalty mles are, of course, a crucial ingredient in the POF and POE. AC can allow suppliers to pick standard royalty plans or AC can determine the plans. Royalty mles can be highly variable, just as pricing plans can be highly variable. We cannot give any prescriptions about what share of income Sue should get in general, or what share AC gets, or when an answer goes into the public domain. One important twist that should be mentioned is that AC can include a royalty plan in certain cases where, based on insurance principles, a POE is not an estimate but is a guaranteed offer. For example, if ten people commit to paying $1 for an answer, AC may make a Sue a guaranteed offer of $5. In certain cases then, AC can enable Sue to choose guaranteed royalties.

Brief Note on the Importance of the Flexibility of the Royalty Rules

One of the advantages of AC is that the royalty mles and the POF are infinitely variable. Thus, the system Manager can adjust the mles to reward certain actions such as the correcting of answers and the inputting of an initial set of answers.

Chapter 14: Property Rights

Since AC collects answers by paying people royalties on the sales of those answers, AC needs to give suppliers property rights, such as copyright protection.

14a Laws of the Land

AC requires meta mles that spell out the property rights of suppliers and it needs functions that reflect those meta-rules. One critical property right is a law against uncompensated copying (a copyright, which can last for a set period of time or until a certain amount of income is paid). Another critical property right is a law against wrongfully changing an answer. Another critical property right is a law against lying about an answer. (Other key property rights were discussed in previous chapters. Chapter 7 discussed the public and private domain. Chapter 8 described reservation rights. These topics could have been discussed in this chapter as well.) We will arrive at no good definitions for these laws, because the definitions of copy/plagiarize, wrongfully change, and lie cannot be made exact. For example, taking the hypothetical poll question above, say someone does a poll and enters the answer. Then say someone else does another poll later and enters another result. Should the second result be considered a new answer? What if the second poll copied the technique of the first poll? What if the second result was not from a totally new poll but was a reinteφretation of the first result? What if the second poll answer was more accurate but combined new poll data with the first poll's data? While realizing that there are no good general mles, we can only say that AC needs to include mles for defining property rights.

14b Functions for Enforcing Property Rights To enforce property rights, AC needs four things:

1. Means for Verifying the Identity of Users. Before letting a user change an answer or any other valuable piece of information in AC, AC needs to verify the user's identity. AC can use well known authentication techniques that need no elaboration here.

2. Judges. AC needs judges who will rule on whether rights have been violated and who will settle credit disputes. AC can enable users to file complaints with judges who, as in conventional courts, can divide property and assess penalties. (AC can keep "rap sheets" on users.)

3. To Register and Display Detection Information. AC needs to display information that enables people to detect violations. Thus AC automatically time stamps answers and can display the time stamps so that people can see which of two given answers has priority. As described in chapter 5, and a little later below, AC enables Sue to enter credit information along with her answer. This information, which might also be called citation information, shows which answers deserve credit as part of her answer, and how much they deserve, in the sense of what split of royalties they deserve. AC displays citations so users can evaluate whether Sue has assigned proper credit.

4. Means for Detecting Violations. The following are functions AC can include for detecting violations, a. Alerts AC can include a function for alerting Sue any time her answer has been displaced (knocked out of the current answer position) or changed in any way. She can then file a complaint with a system judge if she feels that the change is wrong under ACs mles. (Note: AC can also alert Sue if her answer has been commented on by others. Again, she can file a complaint if she thinks her answer has been wrongly criticized. This topic will be discussed in chapter 13 on quality control labels, but that chapter is not written up yet.) b. Snitch AC can include a function that enables any user to report plagiarism, and possibly get a reward, which possibly can be paid by the offender. The snitch can report the plagiarism to Sue or to a system judge, c. Flip Flop Stopper In order to cheat, a person might have a confederate change an accurate answer to a wrong one. The person would then re-enter the answer correctly and claim royalties. AC can have a function such that if an answer reverts to a previous answer within a given period of time, royalties will be paid to the supplier of the previous answer, provided the previous answer was accurate. The time allowed for reversion can vary depending on the situation, d. Competition Tracker As will be seen in book II, AC can to some extent track which answers are taking sales away from a given answer. Sue can request this information (or AC can send it automatically). Sue can then check those competing answers to see if they contain plagiarized material.

14c Sharing Royalties As mentioned above, it can be useful for AC to enable a person to copy all or part of an existing answer. As discussed, the term copy can cover a very broad range of uses. For illustration's sake, we may imagine that Sue is trying to improve an existing answer or that she uses an existing answer within her answer. For example, Sue may elaborate on a short article or she may use a quote. And so AC has meta mles prescribing royalty sharing, and functions enabling Sue to share royalties. (We have discussed the necessity for these mles and functions in section 5.2e as well.) It is usually impractical for suppliers to engage in lengthy negotiations about the splitting of royalties. (Of course that depends mainly on the value of the answer and the size of the royalty stream.) Thus AC can have standard royalty sharing plans based on some classification of the uses of answers within other answers. In addition to standard royalty sharing plans, AC can enable users to specify that a certain percentage of royalties or certain fixed royalties are to go to another answer. For royalty sharing to be implemented in an automated way, AC must have functions that enable Sue to: a. identify the answer(s) she owes credit to, b. identify the type of credit that is involved. Further, AC needs functions that: c. transfer payments as specified by the credit information Sue has entered. AC stores Sue's credit information in the credit record for her answer. Then each time her answer is outputted, the cited answer gets a share of the royalties as specified by the credit information. When the credit information is displayed, we also call it citation information. (Note: Because it is often practical to negotiate about the splitting of royalties, AC can include functions for enabling users to buy and sell rights to use an answer. Negotiated splits are also entered as credit information so that AC can transfer payments as necessary, and so users can see who owes what to whom.)

Chapter 16: Form of the Invention

It should be apparent that AC can be adapted to the world of physical products. By this we mean that instead of describing answers (information products), questions in AC can describe physical products that people want. Thus, AC can include lands where questions refer to physical products rather than answers. Normally, a question is a description of an answer. It is a description of a description. When adapted to describing a physical product, a question is about an actual thing. But the distinction is more philosophical than real. As far the process of description goes, there is no difference between describing a T-shirt and describing a picture of a T-shirt. The main practical difference, where AC is concemed, is that the description of an actual T-shirt refers to something that cannot be entered into the system. Rather than supplying physical products to AC, suppliers input product descriptions and ordering information. The main point is that AC can collect demand information about physical products and can output POE's about physical products. The collecting of demand information is basically the same as with answers. AC can also execute transactions for the buying of actual products and can arrange the delivery of physical products. For example, AC can collect demand for a given T-shirt which is described by a question. If the POE is high enough, a supplier might decide to make the T-shirt. A supplier who has made the T-shirt can supply to AC the fact that the T-shirt has been produced and also supply ordering information. The fact that the T-shirt is available is an answer to the question describing the T-shirt. A requestor, seeing that the T-shirt is available, can order it through AC. Previous requestors may have made buying commitments before the T-shirt was produced. The terms of these commitments can be fulfilled when the T-shirt is made. The supplier may also supply a more detailed description of the T-shirt, such as a picture of the T-shirt. This additional description is then seen by prospective buyers. It is a kind of supply stat. Whether a supplier also provides a description of her actual product or not, the reality of endless answers remains. It does not matter if we are thinking of physical or information products. A question can have infinite possible answers. Thus the techniques of Book II are as applicable to physical products as they are to answers. And so, AC provides a novel system not only for organizing the getting of answers, but for the getting of physical products.

Claims

ClaimsI claim:

1. a data collection and retrieval system comprising in combination the following elements and steps:

a computer and data-base having:

-input means for inputting data-requests and data corresponding to said data-requests, along with user identification information,

—output means for outputting said corresponding data, along with projected pay-off estimates,

—memory means for storing said data-requests and corresponding data,

—processing means for comparing data-requests, finding corresponding data, registering times of inputs, calculating formulas and registering charges and payments due to users,

said computer performing the following steps upon the inputting of a data-request by a user:

a. registering said user's identification information in said data-base,

b. registering user's preference in supplying or retrieving the data corresponding to said data- request,

c. if the user prefers to supply said corresponding data, looks for said corresponding data is said corresponding data-base,

c 1. if corresponding data is found, outputting a message telling the user that the data is already in the data-base,

c2. if no corresponding data is found, allowing the user to input the data, storing the corresponding data and registering that royalties are due to the user when said data is requested, d. if the user prefers to retrieve data corresponding to said data-request,

dl . registering time and date said data-request is inputted,

d2. registering amount user is willing to pay for data corresponding to said data-request,

d3. finding data corresponding to said data-request is in the data-base,

d3a. if corresponding data is in the data-base, outputting the data, registering a charge due by said user who inputted the data-request and a royalty due to the user who supplied the data, adding one to the number of said data-requests, calculating a pay-off formula that projects the estimated royalties due to a user who inputs the correct data corresponding to said data-request, and outputting the resulting pay-off estimate,

d3b. if no corresponding data is in the data-base, checking if said data-request is stored in the data-base, d3bl . if no, storing the data-request and setting the number of said data- requests to one, and calculating said pay-off formula, d3b2. if yes, adds one to the number of said data-requests, and calculates said pay-off formula,

d3b3. outputting the resulting pay-off estimate.