A sensor is simply a predicate that expects certain preconditions to be fulfilled before that predicate gets called (these preconditions are called the
). The invocation preconditions are defined as a Boolean combo of
restrictions.
There is an API for declaring and defining sensors.
The key point is that if a sensor is called and the preconditions on the arguments aren't satisfied, Ergo and Flora-2 will delay the call until the conditions are satisfied (rather than issuing an error right away). This makes the use of sensors safer, since one doesn't need to worry about the exact place where to put a sensor in a rule body. At some point it may become impossible to satisfy the invocation pattern (eg, at the end of the clause evaluation, but it can be determined earlier as well). If this happens, the predicate is called anyway and its implementation must decide what to do in this case (eg, ignore the call or issue a warning or an error).
That's it. If you have a more specific question, I'd be happy to answer. There is no book on that, but the concept was discussed (under different names) in the academic deductive database literature in about 1990-2005 or so.
Ergo/Flora-2 sensors is a practical realization of some of these ideas.
There is are examples of correct and incorrect uses of sensors in the Flora-2 testsuite, in flora2-testsuite/general_tests/ (sensortest.flr and sensortest_err.flr + sensortest_declarations.flr), which can be downloaded from Flora-2's source code repository on Sourceforge.
The intended use of sensors is for invoking non-declarative external components (eg, accessing a Web site). There is a related declarative mechanism of delay-quantifiers (wish and must) for delaying calls to declarative predicates.
--michael