Using Formal Logic and Software Autonomy
I invite you to take part in an exercise of imagination. Picture a day in your life with its regular activities such as parking your car in the usual lot, programming the washing machine to do your sensitive laundry or booking seats on a plane and rooms in a hotel for your perfect vacation. Think of all the time and energy invested in these routine tasks, and diverted from enjoying the company of your family, stealing an extra hour of sleep in the morning or indulging yourself with a good e-book. Now envision the same day where all these burdensome responsibilities are taken over by a silent, effective, invisible tool and performed to your expectations with a minimum amount of involvement from your part. If you are enjoying that perspective you should be interested in what follows, for I strive to help turn this possibility into a reality.
When confronted with a problem, one is motivated by a goal and, at the same time, constrained by routine. It is the daunting task of making trip reservations that gets in the way of what a vacation is supposed to be, namely fun and relaxation. To the same extent, the creative endeavour of putting together a set of lecture slides is sabotaged by cumbersome operations such as tweaking font faces and image contrast. The invisible tool mentioned before is aimed specifically at stripping the goal unrelated, routine side out of such challenges, allowing one to concentrate on the creative aspects. To achieve that, the appropriate approach is twofold. On the one hand, the tool, which is ultimately a software instrument, must understand the definition of the routine task it is supposed to perform automatically. This way, even non programming experts would be capable of communicating their problems to the tool. By storing user input inside an ontology, which represents a language for defining concepts, similar to the natural one, the translation between high level descriptions and machine language is performed automatically and transparently relative to the user. On the other hand, an engine that processes the ontology must be fitted inside the tool to work out the plan to perform the required task. The engine must also be capable of adapting the solution strategy in case the user changes his/her mind about the specifics of the task at hand.
The invisible tool solves two problems. The straightforward one consists in sparing the user from routine tasks. The hidden problem relates to simplicity, in the sense that all the software running in the background is based on a unitary architecture, allowing it to communicate smoothly with other software. Another advantage of structural simplicity is that one single tool may solve a wide range of problems, without extensive reconfiguration. These two issues are my main motivators in the years to come, so that one day my implementation of the invisible tool may turn the suggested exercise of imagination into the practical realisation of a life liberated from routine.
For more information on Research degrees in the School of Engineering and Applied Science please click here