Internally, the entire process of drafting a specification is repetitive, because it usually takes numerous iterations to find the flaws and iron them out. The preliminary brainstorming takes place during the sketching phase. Here, ideas are collected and described informally. Then, a rationalization phase can take place, to check for consistency—internally and with existing requirements. Each of the valid options can then be formalized as necessary by converting the sketch into a computer-friendly specification using a KR formalism. Another round of rationalization may optionally take place, because the choice of KR can affect the compliance of the model with requirements. We can repeat the process until we're happy with the results, and are ready to start the implementation.
Generally, drafting a few options first is a good idea. These can be complete models, including ideas for inputs and outputs as well as the overall concept, or just ideas for one specific aspect. Initially, these ideas can remain vague—mainly because considering everything in detail is wasteful, but we should feel free to refine each sketch at this stage if it helps.
Role of Sketching
Gathering ideas for sketches will become much easier as our experience grows, although initially inspiration can be harder to find. The following sources can help us get started, or find better approaches:
Creating sketches can take time, because there are many things to consider. It can sometimes be best to leave the problem aside for some time, which provides extra clarity when returning to it later.
During the sketching phase, drafts, partial insights, and rough thoughts have been collected. From these, complete models can be formed. This can be achieved by combining our partial ideas if necessary (for instance, one possible input with this output). Now each part is ready to be formally specified. If this is the first model, we'll probably have to start from scratch; otherwise, we may reuse our previous work.
A complete formal model is a draft specification of the task that could become officially accepted. It consists of documented decisions about the KR and data formats of the inputs, outputs, and context. If it does become accepted, we can and should refine the documentation and polish it up; it will come in handy later.
Knowledge Representation and Data Structures
This phase involves selecting a KR language that is complete enough to represent the environment, flexible enough to extend, and efficient enough to manipulate.
However, this is only part of the formalization, because low-level C++ representations need to be considered, too. This problem falls into the category of data structure design. The data can be expressed with basic types int, float, bool, char; compound ones such as std::vector, std::map, std::list; and optionally exotic ones such as boost::any—see Table 9.1.
Being simpler and limited in number, the outputs are often much simpler to formalize before the inputs. Despite their simplicity, the outputs offer great clarity to the problem. When formalizing the outputs first, we can assume all the inputs are valid and the AI is perfect.
By formalizing the inputs next, the rest of the specification quickly falls into place. Admittedly, the inputs are probably the trickiest aspect of the formalization process—and the primary cause of failure in the latter stages. Additional time and care is required for the inputs.
Finally, the supporting variables from the context can be modeled. These also implicitly affect the behavior of both inputs and outputs. However, the context is often defined abstractly rather than explicitly; this is often enough to complete the formalization, and allow the problem to be solved.
The rationalizing stage involves consciously checking the options to see whether they fit with the requirements. Admittedly, we may constantly have the requirements in the back of our mind anyway, ruling out options as they come up. However, this generally limits our creativity of brainstorming and causes potentially great ideas to be discarded prematurely. Keeping this phase separate allows the sketching to completely fulfill its potential.
While rationalizing, we need to check a few things for each model, each of which is almost equally important:
Once answered, each of these questions will either validate the specification, or not. In the latter case, the problem must be investigated further; if the cause is identified, the next design iteration can resolve it. Although keep in mind that imperfection is okay! The ideal model can be almost impossible to achieve, so don't hesitate to move on when our design is satisfactory; we will benefit more from the experience in the latter stages.