Formalization process can combat spamming
Formalization is the process of making explicit the entire deductive structure of an argument / proof, in such a way that a computer could easily* check that it follows. (*: “easily”, according to the de Bruijn criterion, means that the proof checker is small. ) Note: “deductive” does not imply “undefeasible”. It can be use in combating spamming. Formalization is in many ways analogous to programming: design is important, bugs, etc. Automatic programming holds the promise for automatic formalization.
Formalization relates strongly to context. We must formalize the application in a way that covers all circumstances.
Spam filters offer a good example. An oft-used method discriminates spam from genuine messages by looking at the words in the message—for example, by differentiating on a lexical level. This simple formalization works in most cases, but the difference between a semantic and lexical level causes the filters to let some spam through. On the other hand, these filters also remove some genuine messages. Developers have attempted to use similar methods when screening pornographic content, both in text and pictures, but here the formalization problems are even greater.
Those of us who have followed the Great Robot Race have been impressed by how computers can steer cars through the Mojave Desert using GPS, 3D mapping systems, laser guidance, and video cameras. The vehicles follow dirt roads, avoid obstacles, go through tunnels, navigate narrow corners, and pass other cars as if they were controlled by a human driver.
Does this imply that we will have automatic cars on the road in a few years? The central issue here is not how much intelligence we can build into the cars, but how we can formalize driving. Although driving can be relaxing at times—letting us listen to music, look at the countryside, and have a conversation—some situations demand we use all our sensory organs and brain capacity to make the right decisions. For example, we might unexpectedly see something on the road ahead. Must we brake and veer, or can we just continue going forward?
If a robot must make these decisions, the tasks must be formalized. For example, the decision program will need to distinguish between a rock (brake or veer), a small snowdrift (go ahead), or a cardboard box (empty: go ahead; full: brake or veer). It must be able to interpret the intentions of fellow drivers as well.
Clearly, the other alternative—to formalize the road to a higher level, seems more promising. This can be done by putting virtual rails in the road, physical cables that gadgets in the cars can follow. Alternatively, we could use detailed GPS waypoints to determine the route, as in the Great Robot Race. The system can use laser-guided vision, sensors, and video cameras to control the distance to nearby cars. Such an automatic system could reduce the driver’s workload, but exceptions would still pose problems.
The examples we have today of computer-controlled trains illustrate the formalization issue. These trains run in an environment where exceptions are reduced to a minimum by, for example, building systems that make it impossible for people to gain access to the tracks. We should be able to find similar applications for robot trucks that can run on enclosed company roads.
The formalization includes two kinds of operation sequences in graphic systems. which are used as the formal specifications of graphics systems and display devices. In order to generate a graphics system using a display device, the concept of functionality-preserving transformation of operation sequences in terms of various types of commutations among primitive operations was introduced. A type of transformation, which is called extraction, plays a central role in the generation algorithm.