1: \chapter{Future Developments and Applications}\label{future_chapter}
2:
3: \section{Introduction}
4:
5: The preceding chapters have described the SP theory as it has been developed to date and some of its potential applications. In this chapter, I will describe what further developments of the theory seem to be needed, how the theory may be embodied in an `SP machine', and ways in which the theory and the machine may be applied in the future.
6:
7: In looking into the future for these ideas, it is tempting to be drawn into science fiction and to imagine how an SP system might mend your socks, make you cups of tea and be your tennis partner as well. Although this might be entertaining, I shall stick to the more humdrum possibilities that seem to me to be reasonable and feasible.
8:
9: \section{Development of the theory}\label{development_of_theory}
10:
11: In the last few years, many of the issues that have arisen in the development of the SP theory have been resolved and the framework has become relatively stable and mature. However, there are certain areas where further development seems to be needed. Two of them have been described in previous chapters:
12:
13: \begin{itemize}
14:
15: \item In Section \ref{alternative_method_for_unordered_patterns}, it was suggested that there might be a case for generalising the SP concept of multiple alignment to include multiple alignments containing two or more patterns from New. This should be useful for applications like medical diagnosis where New information may need to be treated as an unordered set of patterns or as an unordered or partially-ordered set of symbols (see Section \ref{ordering_of_symptoms}).
16:
17: \item A programme of work is needed to overcome weaknesses in the SP70 model (Section \ref{learning_discussion}). It is anticipated that most of the current deficiencies can be remedied by some reorganisation of the model within the overall framework that has been developed.
18:
19: \end{itemize}
20:
21: \noindent Other planned developments are discussed in the subsections that follow.
22:
23: \subsection{Patterns in two dimensions}\label{2d_patterns_section}
24:
25: \index{perception!vision|(}
26:
27: The main focus so far in the development of the SP theory has been on one-dimensional patterns and on the modelling of those kinds of knowledge that map straightforwardly on to 1-D patterns---such as natural language and grammatical rules for describing the structure of natural language. Relatively little has been said about possible applications of the theory to the description and processing of forms of knowledge that have a two-dimensional structure such as maps, diagrams and pictures (which will be referred to as `images').
28:
29: In conventional computing, there is of course a well-developed tradition of vector graphics and related techniques for describing 2-D images with 1-D mathematical notations. Since it is envisaged that mathematical structures and processes may be modelled in the SP system (Chapter \ref{maths_logic_chapter}), this is a possible way forward, within the SP system, for the representation and processing of images.
30:
31: However, as previously noted (Section \ref{representation_of_knowledge}), it is envisaged that the concept of {\em pattern} in the SP theory may be generalised to include patterns in two dimensions (and possibly more)---and this may provide a more direct approach to the modelling of images, with potential advantages over one that mimics established techniques (see Section \ref{maps_diagrams_pictures_films}, below).
32:
33: \subsubsection{Matching, multiple alignment, learning and display}\label{matching_ma_learning_display}
34:
35: There is, of course, no intrinsic difficulty in representing 2-D patterns in a successor to SP61 or SP70. All that is required is arrays of symbols in two dimensions instead of one. The immediate difficulty lies in developing a process for matching 2-D patterns with the same kind of flexibility as the matching process for 1-D patterns described in Appendix \ref{matching_appendix}. This would, in effect, be a 2-D analogue of dynamic programming with the same advantages as the current process: that it can be scaled up without excessive demands on processing time or memory; the ability to deliver two or more alternative matches for a pair of patterns; and scope for varying the `depth' of searching according to need. Although the development of such a matching process presents a significant challenge, there seems no reason in principle why existing techniques should not be generalised in this way.
36:
37: Assuming that a 2-D analogue of dynamic programming could be developed, this would need to be incorporated within a process for building SP-style multiple alignments with 2-D patterns. The learning processes in SP70, or an improved successor to that program, would need to be generalised for 2-D patterns.
38:
39: Apart from these problems, there is a cosmetic-cum-practical problem of displaying alignments of two or more 2-D patterns effectively. Alignments of that kind may be viewed from different angles using `virtual reality' graphical software---but some other technique would be needed to show these kinds of multiple alignments clearly on the printed page.
40:
41: \subsubsection{Representation of two-dimensional patterns without encoding}\label{2d_patterns_no_encoding}
42:
43: As was described in Section \ref{raw_and_encoded_information}, analogue information may be digitised `directly', by representing the amplitude of the analogue signal by the density of `0's and `1's. Using this scheme, a 2-D image that we would recognise as a white triangle surrounded by black, may be represented digitally by a triangular area of `1's surrounded by an area of `0's.
44:
45: A `raw' image like the one just described contains significant amounts of redundancy. This may be reduced by the matching and unification of patterns (or individual symbols) and by the use of identifying `codes' as described in Sections \ref{ic_repetition_of_patterns} and \ref{techniques_for_ic}. When learning processes like those described in Chapter \ref{learning_chapter} have been further developed and then generalised for patterns in two dimensions, the SP system should be able to compress any raw digitised image, as tentatively sketched in the subsections that follow.
46:
47: \subsubsection{First stage of encoding: marking boundaries}\label{2d_patterns_boundaries}
48:
49: In the original digitised image of a triangle, the most obvious form of redundancy is that represented by the repetition of symbols in each of the uniform areas, one inside the triangle and the other surrounding it. These areas may be compressed by the unification of repeating symbols and by the use of ID-symbols.
50:
51: In one-dimensional patterns, ID-symbols have a dual r{\^o}le: marking the left and right boundaries of the pattern and identifying each pattern uniquely amongst the other patterns in Old. With 2-D patterns, it seems necessary to provide ID-symbols to fulfil these two r{\^o}les but, with respect to the marking of boundaries, the entire outline of the pattern needs to be marked, not simply the left and right ends of the pattern.
52:
53: Figure \ref{2d_image_1} shows a simple scheme for representing a white triangle. Here, `TRIANGLE' is an ID-symbol that may serve to distinguish the figure from others, `*' is an ID-symbol that serves as an anchor point for positioning the figure in relation to other figures and the `b' symbols are ID-symbols marking the boundary of the figure (also, if you wish, mnemonic for a `black' line around the figure).
54:
55: \begin{figure}[!hbt]
56: \centering
57: \includegraphics[width=0.9\textwidth]{13_Future/ID-symbols1a.ps}
58: \caption{A possible scheme for a first-stage encoding of a white triangle in black surroundings. The meanings of the symbols are explained in the text.}
59: \label{2d_image_1}
60: \end{figure}
61:
62: Inside the triangle in Figure \ref{2d_image_1} is the pattern `$<$ X 1 $<$ X $>$ $>$' and outside the triangle is the pattern `$<$ Y 0 $<$ Y $>$ $>$'. The first of these patterns is intended as a schematic encoding of the repeating `1's inside the original `raw' triangle, and the second pattern is intended as a similar encoding of the repeating `0's that surround the triangle. Each pattern is a recursive structure modelled on the recursive pattern described in Section \ref{unary_numbers_and_sp}. However, neither pattern is entirely accurate in this application because it needs to be generalised for two dimensions. How that generalisation may be done is a matter for future investigation.
63:
64: \subsubsection{Further encoding}\label{encoding_2d_patterns_compressed}
65:
66: The encoding shown in Figure \ref{2d_image_1} has removed much of the redundancy from the original `raw' data but some still remains. The straight lines marking the three sides of the triangle each contain redundancy in the form of repeating instances of `b' and the uniform trajectory from one `b' to the next. By contrast, the angles at each corner of the triangle, where a line in one orientation joins a line at another orientation, are places where there is non-redundant information that largely defines the nature of a triangle ({\em cf.} Attneave's \citeyearpar{attneave_1954} example showing how the form of a sleeping cat can be captured quite effectively with a few lines and angles).
67:
68: Figure \ref{2d_image_2} shows how the residual redundancy in Figure \ref{2d_image_1} may be reduced. Instead of marking each side by a succession of `b' symbols, we may suppose that the system has recognised the recursive nature of each line and has created an encoding that is something like `$<$ Z b $<$ Z $>$ $>$', comparable with the recursive patterns in the body of the triangle and in the surrounding area. For each of the three corners of the triangle, we may suppose that the system has created three new ID-symbols, one for the top corner and one for each of the left and right lower corners. In the figure, the symbol `TRIANGLE' serves to distinguish the pattern from other patterns in the system and `*' serves as an anchor point, as before.
69:
70: \begin{figure}[!hbt]
71: \centering
72: \includegraphics[width=0.9\textwidth]{13_Future/ID-symbols3a.ps}
73: \caption{A possible further encoding of a white triangle in a black surround. The interpretation of the figure is discussed in the text.}
74: \label{2d_image_2}
75: \end{figure}
76:
77: An encoded representation like the one in Figure \ref{2d_image_2} has three interesting features:
78:
79: \begin{itemize}
80:
81: \item It goes some way to capturing John Locke's idea of an abstract, generalised concept of a triangle.\footnote{``For abstract ideas are not so obvious or easy to children... For, when we nicely reflect upon them, we shall find that general ideas are fictions and contrivances of the mind, that carry difficulty with them... For example, does it not require some pains and skill to form the general idea of a triangle... for it must be neither oblique nor rectangle, neither equilateral, equicrural [i.e., isosceles], nor scalenon; but all and none of these at once.'' John Locke, {\em Essay Concerning Human Understanding}, 1690, Book IV, Chapter 7, Section 9.}. Given an appropriate process for building 2-D multiple alignments, the representation in Figure \ref{2d_image_2} should serve for the recognition or construction of equilateral triangles of any size, not just the specific triangle shown in Figure \ref{2d_image_1}. With some further generalisation of the concept of `angle', a representation like this should serve for the recognition or construction of a range of triangles with a variety of angles at the corners.
82:
83: \item Because the representation is compatible with triangles of many different sizes, it provides a possible solution to the problem of size constancy in perception, mentioned in Sections \ref{perceptual_constancies} and \ref{constancies_neural}.
84:
85: \item The representation in Figure \ref{2d_image_2} does not encode the {\em absolute} sizes of the sides of the triangle but it does, in effect, encode the {\em relative} sizes of the sides of the triangle---via the positions of the symbols marking each angle and, perhaps, via the sizes of the angles encoded within those symbols. Encoding of relative sizes is sufficient for many purposes and it accords with a range of evidence showing that human perception is geared to relative judgements rather than absolute ones. This kind of system can make absolute judgments if a suitable reference is provided.
86:
87: \end{itemize}
88:
89: \subsubsection{Hierarchical encoding of two dimensional patterns}\label{encoding_2d_patterns_hierarchical}
90:
91: While it is true that we can recognise a triangle as a triangle regardless of its size or shape, it is also true that we can distinguish one triangle from another by size, shape, colour or other attributes. There seems no reason in principle why the recognition of images at two or more levels of abstraction should not be achieved in the SP system in much the same way as for 1-D patterns, as illustrated in Section \ref{class_part_inheritance}.
92:
93: The modelling of class hierarchies and part-whole hierarchies within the SP system is achieved quite simply by the provision of C-symbols in some patterns that serve as references to corresponding ID-symbols in other patterns. Figure \ref{2d_image_3} shows a schematic example of a pattern constructed as an assemblage of references to `lower' level patterns---a relationship that may be repeated recursively through any number of levels. When these ideas are more fully worked out, there will, no doubt, be a need for additional information to specify sizes, colours and textures of component patterns and, perhaps, relationships such as overlap between patterns.
94:
95: \begin{figure}[!hbt]
96: \centering
97: \includegraphics[width=0.9\textwidth]{13_Future/ID-symbols4.ps}
98: \caption{A 2-D picture constructed as an assemblage of references to `lower' level patterns.}
99: \label{2d_image_3}
100: \end{figure}
101:
102: \index{perception!vision|)}
103:
104: \subsection{Developing the theory with patterns with three or more dimensions?}
105:
106: Since we regularly deal with objects and spaces in three dimensions, it might seem natural to model these things in the SP system with patterns in three dimensions---and likewise for concepts with higher dimensions. Although this may seem the logical way to go, my current thinking is that this would probably be a mistake. Apart from the difficulty of imagining or representing alignments amongst patterns of that kind, there are two main reasons for caution in this area:
107:
108: \begin{itemize}
109:
110: \item There may be no particular need to develop the theory in this way. Patterns in one or two dimensions may serve well enough to represent concepts with three or more dimensions. There is a long tradition of representing buildings and other engineering artefacts with two-dimensional plans and elevations. To model concepts in four or more dimensions, there seems little prospect of improving on established mathematical techniques.
111:
112: \item As we saw in Chapter \ref{neural_chapter}, there are reasons to think that arrays of neurons in one or two dimensions may provide the basis for our many kinds of knowledge:
113:
114: \begin{itemize}
115:
116: \item Although the human brain is clearly a three-dimensional structure, there is a distinct tendency for it to be organised into layers of cells such as those found in the cortex and in the lateral geniculate body. Although these are often folded into three dimensions, they are topologically equivalent to two-dimensional sheets. As was suggested in Chapter \ref{neural_chapter}, these sheets of neurons would provide a natural home for SP patterns.
117:
118: \item In a similar way, there is a clear tendency for sensory neurons to be organised as arrays with two dimensions in the retina and in the skin or with a predominant single dimension in the case of cochlea. It seems possible that structures for the storage and retrieval of knowledge evolved from sensory structures and this might explain the similarities in their organisation. It is true that there is a temporal dimension to vision as well as the two dimensions of each momentary image but there seems no reason why these three dimensions should not be represented in two dimensions like a succession of images in a cinema film or video tape---but with high levels of encoding and compression. Similar principles may apply to hearing.
119:
120: \end{itemize}
121:
122: \end{itemize}
123:
124: \subsection{Theoretical aspects of searching and constraints}\label{searching_and_constraints_theory}
125:
126: \index{constraint|(}
127:
128: Other aspects of the SP theory that need further exploration and development are methods for searching the space of alternative multiple alignments, the kinds of constraint that may be applied to the search, and inter-dependencies between the two. It is not entirely clear at present whether these issues are purely theoretical or whether they are at least partly concerned with the ways in which the SP theory may be implemented in a working system (next section). Insofar as the distinction is sound, it seems likely that the issues straddle both areas.
129:
130: In the context of the SP system, any generalised theory of searching would need to say something useful about building multiple alignments with 2-D patterns (Section \ref{2d_patterns_section}, above) and it should also throw light on ways in which parallel processing may be applied (Section \ref{searching_and_constraints_machine}, below).
131:
132: It seems likely that, at some stage, the searching and matching processes will need to be generalised so that 1-D pattern can be matched in both possible directions and 2-D patterns can be matched in several possible orientations (see Section \ref{syntax_semantics_learning}).
133:
134: With regard to constraints, an area that needs particular attention is the kinds of constraints that are embodied in classical systems for logic and mathematics. This is needed to improve our understanding of the ways in which those classical systems may (or may not) be understood within the SP theory. And it will also be needed in the design of a working system, as discussed in the following section.%
135: \index{constraint|)}
136:
137: \subsection{Recency in learning}\label{recency_section}
138:
139: When we learn from experience, it seems that recency of events is a factor in our thinking as well as frequency. If we are asked to guess who will score the most goals in a football match then, other things being equal, we are likely to choose the player with the best scoring record. But if that player had, in {\em recent} matches, failed to live up to his usual form, then we might choose a different player.
140:
141: As the SP system is developed more fully for learning, there will be a need to take account of the effect of recency in learning. Of course, frequency and recency are linked because any measure of frequency must be relative to a particular `window' or time frame in which frequencies are measured, and those windows can vary in size and also in recency. These ideas will need to be more fully worked out in successors to the SP70 model.
142:
143: \section{Development of an `SP' machine\index{SP machine}}
144:
145: The SP theory provides an interpretation for computation in existing systems (Chapter \ref{computing_chapter}) but it also suggests new designs for computers, with potential advantages over the von Neumann model that has dominated the digital scene for so long. This section sketches some ideas for the development of an `SP' computer (or `SP' computer) that should, if required, be able to function like a conventional computer but which should in addition have strengths in artificial intelligence that are missing from the current generation of digital computers.
146:
147: The `high level' design of the SP machine would be a realisation of the SP theory as it has been developed and expressed in software models. Although further developments in the theory are still needed (as described in Section \ref{development_of_theory}), the concepts embodied in the SP61 model have a range of potential applications and could provide a basis for a preliminary version of the SP machine.
148:
149: A key feature of the proposed new machine is that it would incorporate high levels of parallel processing. This is because artificial intelligence applications are intrinsically `hungry' for computer power and because the SP theory offers opportunities to by-pass the `busy bee' style of conventional computing to achieve good results in a reasonable time by the application of parallel processing. Notice that the computational demands of artificial intelligence applications are intrinsic to those applications and not a consequence of their interpretation in terms of the SP theory.
150:
151: \subsection{Implementation aspects of searching and constraints}\label{searching_and_constraints_machine}
152:
153: The central process in the SP61 and SP70 models is the building of multiple alignments---and the core operation here is the process of searching for full matches and good partial matches between patterns, as described in Appendix \ref{matching_appendix}.
154:
155: Finding good matches between patterns presents opportunities to apply parallel processing. This is because the process of `broadcasting' symbols from one pattern to make yes/no matches with symbols in other patterns (Section \ref{matching_one_pattern_with_another}) is an intrinsically parallel operation that could be done as a single step in an appropriate parallel environment (in contrast to the sequence of operations required on an ordinary digital computer). There is also scope for matching sequences of two or more symbols against each other in parallel and this may have a place in the proposed new machine.
156:
157: \subsubsection{Heuristic constraints}
158: \index{constraint|(}
159:
160: Notwithstanding these opportunities for doing several things at the same time, it seems necessary to do some things in sequence. As we saw in Section \ref{matching_searching_and_constraints}, the constraints that are applied in heuristic search methods such as hill climbing or genetic algorithms are applied in a succession of stages, with a progressive narrowing of the search space at each stage. Although searching within each stage may be done in parallel, there seems no escape from the need for the stages of metrics-guided search to succeed each other in sequence.
161:
162: In general, there is a need to explore a variety of methods for matching patterns in parallel, including the kinds of heuristic constraints that are needed to ensure that the process is tractable.
163:
164: \subsubsection{Absolute constraints}
165:
166: Apart from heuristic constraints, the SP machine should also support the application of absolute constraints. It should, for example, be possible to specify the maximum size of any sequence of unmatched symbols in a multiple alignment---including zero if `exact' matching of patterns is required. As in SP61 and SP70, it should be possible to enforce the rule that left and right brackets should be matched in such a way that they are always `balanced'.
167:
168: As with heuristic constraints, there is a need to explore how parallelism can be applied to best effect in the matching of patterns and to combine this efficiently with the application of constraints. As a general rule, constraints of any kind should speed up processing by reducing the size of the search space. But care is needed to avoid inefficiencies in the way constraints are combined with searching, as seems to be the case with the `brackets' constraint in SP61 and SP70 (Section \ref{angle_brackets_constraint}).%
169: \index{constraint|)}
170:
171: \subsection{Technological options}
172:
173: The SP machine does not necessarily have to be developed in silicon. One futuristic possibility is to exploit the potential of organic molecules such as DNA or proteins---in solution---to achieve the effect of high-parallel pattern matching. This kind of `molecular computation'\index{computing!molecular} is already the subject of much research \citep[see, for example,][]{adleman_1994, adleman_1998} and techniques of that kind could, conceivably, form the basis of a high-parallel SP machine.
174:
175: Another possibility is to use light for the kind of high-speed, high-parallel pattern matching that is needed at the heart of the SP machine.\index{computing!optical} Apart from its speed, an attraction of light in this connection is that light rays can cross each other without interfering with each other, eliminating the need to segregate one stream of signals from another \citep[see, for example,][]{cho_colomb_1998, louri_hatch_1994}.
176:
177: In the field of optical and opto-electronic computing as it has developed to date, there is an apparent tendency for researchers to assume that the design of optical computers should imitate the design of the current generation of electronic computers and to concentrate on building optical versions of logic gates \citep[see, for example,][]{lee_dickson_2003, singh_roy_2003}. The SP theory provides an alternative approach to the development of optical computers, an approach which is founded on pattern matching and may by-pass many of the intricacies of computer design, as currently conceived.
178:
179: On relatively short time scales, a silicon version of the SP machine would probably be the easiest option and it may be developed in one or more of three main ways:
180:
181: \begin{itemize}
182:
183: \item It should be feasible to design new hardware for the kind of high-parallel pattern matching that is needed.
184:
185: \item Given that high-parallel machines are already in existence (in both `single instruction, multiple data' (SIMD) and `multiple instructions, multiple data' (MIMD) designs), an alternative strategy is to create the SP machine as a software virtual machine running on one of these platforms.
186:
187: \item Systems like Google already provide high-parallel pattern matching of a kind that may be adapted for use within a software implementation of the SP machine.
188:
189: \end{itemize}
190:
191: To some extent, the second and third options defeat the object of the exercise because the von Neumann architecture and much of its associated complexity would remain embedded in the system. However, these methods of developing the SP machine would probably be relatively cheap, they would probably yield useful insights into ways in which parallelism may be applied, and they should yield a version of the machine that could be used in practical applications.
192:
193: \subsection{Other developments}\label{sp_machine_other_developments}
194:
195: Other aspects of the SP machine that would need to be developed include:
196:
197: \begin{itemize}
198:
199: \item {\em Styles of Computation}. It should be possible to modify the operations of the machine to suite the needs of particular applications. For example, it should be possible to control the `depth' of searching as described in Section \ref{searching_and_constraints_in_sp61}. There may also be switches and parameters to control which constraints are in force and how they are applied (Section \ref{searching_and_constraints_machine}).
200:
201: \item {\em Mathematics}. Although the system can, in principle, do arithmetic and other kinds of mathematics (Chapters \ref{computing_chapter} and \ref{maths_logic_chapter}), its current strengths lie in `symbolic' and non-mathematical kinds of computation. To do arithmetic, the system would need to be equipped with an appropriate set of patterns and the kinds of constraint mentioned in Section \ref{searching_and_constraints_theory} would also need to be developed. Pending these developments, there may be a case for exploiting existing technologies within the SP machine, in much the same way that `maths co-processors' are provided in conventional computers.
202:
203: \item {\em User Interface}. A graphical user interface is needed to display data and results and to facilitate browsing and searching within that information. Since multiple alignments can grow very large, there is a need to be able to zoom in or out and to scroll through a multiple alignment (horizontally and vertically). It should be possible to see the unified version of any multiple alignment when required and, when viewing a unified version of a multiple alignment, it would probably be useful if ID-symbols could be concealed from view or revealed, according to need. Some kind of graphical control panel or dialogue box is needed so that switches and other parameters can easily be set.
204:
205: \end{itemize}
206:
207: \section{Applications of the SP theory and machine}\label{sp_future_applications}
208:
209: Given the broad scope of the SP theory, its potential applications are legion. This section describes some of the possibilities, ranging from those that may be realised on relatively short time scales using existing technologies to those that depend on longer-term developments of the SP machine. The main emphasis here is on engineering applications but it should not be forgotten that the theory may also have heuristic uses in research, perhaps leading to new insights or suggesting new avenues of investigation in areas such as neuroscience, mathematics or logic.
210:
211: \subsection{Information compression}
212:
213: \index{information!compression|(}
214:
215: Given the central importance of information compression in the SP theory, an obvious application for the SP machine would be in the compression of information. Possible arguments against that kind of development include:
216:
217: \begin{itemize}
218:
219: \item The capacities of computer memories and storage devices are increasing all the time, with no sign of a ceiling, and this will make compression irrelevant.
220:
221: \item Likewise, it may be argued that communication bandwidths are constantly increasing and this will progressively reduce the need for information compression.
222:
223: \item Information compression is already well-enough served by ZIP programs and the like and there is no need for anything different.
224:
225: \item It may also be argued that too much compression is bad---that redundancy in information is needed to guard against errors or loss of information and to speed up processing.
226:
227: \end{itemize}
228:
229: \subsubsection{Compression will not be needed}
230:
231: Considering the first and second of these arguments, similar things were said in the 1970s\footnote{These were the reasons given by the former National Research and Development Corporation (a United Kingdom government quango) for rejecting a proposal that I made at that time to develop the MK10 model for compression applications.} and there is still a need for information compression, despite vast increases in storage capacities and bandwidths. Streaming video over the internet is still a significant challenge as is the repeated archiving, at regular intervals, of the entire World Wide Web (http://www.archive.org/). Our demands for the storage and transmission of information seem always to outpace the available technologies.
232:
233: \subsubsection{Current technologies are good enough}
234:
235: Compression algorithms such as the Lempel-Ziv algorithms used in ZIP programs are designed for speed of compression and decompression on traditional digital computers. This means that the search for repeating patterns that is embodied in these algorithms is relatively simple and not designed to find as much redundancy as possible. The patterns that are found are always coherent substrings within the data and discontinuous subsequences are excluded. Patterns can contain references to other patterns but there is nothing equivalent to the multiple alignment concept and the scope that it offers for the encoding of information at several different levels of abstraction.
236:
237: By contrast, it is envisaged that the SP machine will be designed so that it can, when required, do relatively thorough searches for redundancy in information, including redundancy in patterns that are both discontinuous and coherent, and redundancies at multiple levels of abstraction. High levels of parallelism should allow this relatively thorough search for redundancy---and correspondingly high levels of compression---to be achieved with reasonable speed. Although compression in itself might not justify the use of an SP machine, its capabilities in this area should be a welcome bonus on top of its other uses.
238:
239: \subsubsection{Too much compression is bad}
240:
241: The third argument should not detain us because, as we saw in Section \ref{uses_of_redundancy}, there is no real conflict between information compression in information processing and the ways in which redundancy can be exploited. Compression and redundancy have different r{\^o}les to play and they may co-exist in a single body of information.%
242: \index{information!compression|)}
243:
244: \subsection{Representation and processing of graphical information}\label{maps_diagrams_pictures_films}
245:
246: \index{graphics|(}
247:
248: In the representation and processing of graphical information---maps, diagrams and pictures (both still and moving)---there is a well-developed tradition of object-oriented design and object-oriented programming. In the digital processing of a map, for example, it is natural to use a software `object' to represent each entity such as a church or a historic monument and to exploit class hierarchies with inheritance of attributes to achieve a clean and economical design (Sections \ref{classes_subclasses_inheritance} and \ref{oop_section}). In a similar way, each character in a computer game would naturally be programmed as a software object, inheriting methods and data structures from appropriate classes.
249:
250: Although the main elements of object-oriented design flow naturally from the SP system, this in itself does not provide anything that is not already available in object-oriented languages such as Simula, Smalltalk or C++. The potential of the SP system in this area lies in the way it may combine object-oriented capabilities with others:
251:
252: \begin{itemize}
253:
254: \item {\em Recognition and Scene Analysis}. If the system can be developed as described in Section \ref{2d_patterns_section}, it should serve for `fuzzy' recognition of 2-D images at multiple levels of abstraction, with the flexibility to cope when parts of an image are obscured or when there are variations in sizes. It may also serve for the analysis of a scene into its component parts in a manner that is comparable with the parsing of natural language (Section \ref{framework_examples_section} and Chapter \ref{language_chapter}) but with provision for overlap amongst the components of a scene (Section \ref{scene_analysis_recognition_retrieval}). Although it is not yet clear how the system might best be developed for the representation and processing of 3-D objects (or 2-D images of 3-D objects), there seems to be potential here too.
255:
256: \item {\em Unsupervised Learning of Objects and Classes}. At some point in the future it may be possible to use the system for the automatic or semi-automatic learning of `natural' objects and classes. It might, for example, be possible to scan an existing map and derive a collection of patterns corresponding to the kinds of entities and classes of entities that we would naturally recognise there.
257:
258: \end{itemize}
259:
260: \index{graphics|)}
261:
262: \subsection{The Semantic Web}\label{semantic_web_section}
263:
264: \index{Semantic Web|(}
265:
266: The `Semantic Web' is envisaged as a successor to the current World Wide Web in which web pages contain structured descriptions of their contents that can be processed by computers to provide more `intelligence' in the operation of the web \citep{berners-lee_etal_2001}. One of the most popular approaches to the representation and processing of this `ontological' knowledge is a family of languages based on the Resource Description Framework (RDF), such as RDF Schema (RDFS), the Ontology Inference Layer (OIL) and DAML+OIL (see, for example, \citep{broekstra_etal_2002,mcguinness_2002,horrocks_2002,fensel_etal_2001}). RDF provides a syntactic framework, RDFS adds modelling primitives such as `instance-of' and `subclass-of', and DAML+OIL provides a formal semantics and reasoning capabilities based on `description logics', themselves based on predicate logic. For the sake of brevity, RDF and its associated languages will be referred to as `RDF+'.
267:
268: Although RDF+ is popular, it has some shortcomings. Here, I will suggest that the SP system is a possible alternative with advantages compared with RDF+. In the spirit of `evolvability' in the web, the two approaches may be developed in parallel until their relative strengths and weaknesses are more fully understood.
269:
270: Figure \ref{rdf_plus_example} shows an example of how the class `herbivore' may be described with one version of RDF+ \citep{broekstra_etal_2002}. In summary, this description says that a herbivore is a subclass of the class `animal' and that herbivores eat plants or parts thereof. This sample of RDF+ may be compared with the examples in Sections \ref{scene_analysis_recognition_retrieval} and \ref{cross_classification_multiple_inheritance} showing how class hierarchies and part-whole hierarchies may be represented in the SP scheme.
271:
272: \begin{figure}[!hbt]
273: \fontsize{10.00pt}{12.00pt}
274: \centering
275: \begin{BVerbatim}
276: <rdfs:Class rdf:ID-"herbivore">
277: <rdfs:subClassOf rdf:resource-"#animal"/>
278: <oil:hasPropertyRestriction>
279: <oil:ValueType>
280: <oil:onProperty rdf:resource-"#eats"/>
281: <oil:toClass>
282: <oil:Or>
283: <oil:hasOperand rdf:resource-"#plant"/>
284: <oil:hasOperand>
285: <oil:HasValue>
286: <oil:onProperty
287: rdf:resource-"#is-part-of"/>
288: <oil:toClass rdf:resource-"#plant"/>
289: </oil:HasValue>
290: </oil:hasOperand>
291: </oil:Or>
292: </oil:toClass>
293: </oil:ValueType>
294: </oil:hasPropertyRestriction>
295: </rdfs:Class>
296: \end{BVerbatim}
297: \caption{How the class `herbivore' may be described in one version of RDF+ \citep{broekstra_etal_2002}.}
298: \label{rdf_plus_example}
299: \end{figure}
300:
301: A point of similarity between RDF+ and SP is the use of start and end markers such as `$<$oil:hasOperand$>$ ... $<$/oil:hasOperand$>$' in RDF+ and `NP ... \#NP' or `$<$ ... $>$' in SP. In RDF+, these markers---which are part of the XML foundations of RDF+---are universal, whereas in SP they are not always required.
302:
303: Perhaps the main point of difference between RDF+ and SP is that the SP theory incorporates a theory of knowledge in which syntax and semantics are integrated and many of the concepts associated with ontologies are implicit. There is no need for the explicit provision of constructs such as `Class', `subClassOf', `hasPropertyRestriction', and similar constructs shown in Figure \ref{rdf_plus_example}, or others such as `Type', `hasPart', `Property', `subPropertyOf', or `hasValue' which are also used in RDF+. Classes of entity and specific instances, their component parts and properties, and values for properties, can be represented and integrated in a very direct, transparent and intuitive way, as described in Chapter \ref{rr_chapter}. In short, the SP approach allows ontologies to be represented in a manner that appears to be simpler and more comprehensible than RDF+, both for people writing ontologies and for people reading them.
304:
305: Reasoning in RDF+ is based on predicate logic and belongs in the classical tradition of monotonic deductive reasoning in which propositions are either {\em true} or {\em false}. By contrast, the main strengths of the SP system are in probabilistic `deduction', abduction and nonmonotonic reasoning (Chapter \ref{rr_chapter}). There is certainly a place for classical styles of reasoning in the Semantic Web but probabilistic kinds of reasoning are needed too.
306:
307: As we saw in Chapter \ref{rr_chapter}, the SP system copes easily with errors of omission, commission and substitution in information. This kind of capability is outside the scope of `standard' reasoning systems for RDF+ (see, for example, \citet{horrocks_2002}). It has more affinity with `non-standard inferences' for description logics (see, for example, \citet{baarder_etal_1999,brandt_turhan_2001}). Given the anarchical nature of the Web, there is a clear need for the kind of flexibility provided in the SP system. It may be possible to construct ontologies in a relatively disciplined way but ordinary users of the web are much less controllable. The system needs to be able to respond to queries in the same flexible and `forgiving' manner as current search engines. Although current search engines are flexible, their responses are not very `intelligent'. The SP system may help to plug this gap.
308:
309: Apart from these possible advantages of the SP system compared with RDF+, the framework has potential in other areas---such as natural language processing, planning and problem solving, and unsupervised learning---that may prove useful in the future development of the Semantic Web.%
310: \index{Semantic Web|)}
311:
312: \subsection[Software Engineering]{Software Engineering%
313: \footnote{Based on part of Chapter 6 in \citet{wolff_1991}.}}
314:
315: \index{software engineering|(}
316:
317: In spite of `fourth generation' languages and the slowly maturing CASE
318: tools and integrated project support environments, the process of developing new software and maintaining or
319: upgrading existing software still has problems:
320:
321: \begin{itemize}
322:
323: \item Software development is often {\em slow}. Delays can mean costs and inconvenience.
324:
325: \item Software development is {\em labour-intensive} and correspondingly expensive.
326:
327: \item {\em Incompatibilities} between machines, operating system and
328: languages means difficulties in re-using software in new contexts
329: and difficulties in integrating software systems. The resulting need
330: to translate software or adapt it, or develop interfaces to
331: translate information from one system to another, means complexity,
332: delays, costs and new sources of bugs.
333:
334: \item Software developers need extensive (and expensive) {\em training}.
335:
336: \item {\em Verification}. Notwithstanding the use of formal methods in
337: software development, it is impossible to be sure that any significant
338: piece of software is correct in the sense that it does
339: what its designers intended in all circumstances. Any
340: significant body of software is likely to contain bugs.
341:
342: \item {\em Validation}. System designers can, and often do,
343: fail to understand fully what the users want and, consequently,
344: fail to capture the users' requirements in the system.
345:
346: \end{itemize}
347:
348: In the following sub-sections, I outline some of the causes of these
349: problems and how they may be solved or at least alleviated in the SP system.
350:
351: \subsubsection{Procedural and declarative programming}
352:
353: \index{programming!procedural|(}\index{programming!declarative|(}
354:
355: In software design, there is a long-established distinction between `what' a software system is about and `how' the system will do what is required. The former is knowledge about the world that is encoded in the system (e.g., relevant laws and regulations for accountancy applications or knowledge about fonts, headings, paragraphs and the like in a program for desk-top publishing), while the latter is `lower level' knowledge about how to store information or find it using the underlying hardware.
356:
357: With `procedural'\index{programming!procedural} programming languages like Fortran, Cobol and C, programmers need to consider both the `what' and the `how' of software design. It has been recognised for many years that the process of designing software would be simplified if programmers could concentrate on what the system should be able to do without having to worry about how the machine would do it. Although this has been achieved to some extent with `declarative'\index{programming!declarative} languages like Prolog, it is still necessary to design software in a way that takes account of the step-by-step procedures that the machine will follow.
358:
359: According to the SP theory, the `how' parts of computing are the processes of searching for matching patterns, building multiple alignments and encoding information economically that constitute the SP model. In conventional computers, it appears that SP processes are provided partly in the `core' of the computer and partly in the software (see Section \ref{simplification_of_computing_systems}, especially Figure \ref{conventional_and_sp_computers}). By increasing the generality and power of the SP processes that are provided in the core---as is envisaged in the proposed SP machine---it should be possible to eliminate the need for any `how' programming in the software.
360:
361: To the extent that this vision can be realised, SP patterns that are processed by an SP computer would constitute a truly declarative language that may be used to specify what is to be done without concerns about how the machine will do it. This would mean a corresponding streamlining in the process of developing new software.%
362: \index{programming!procedural|)}\index{programming!declarative|)}
363:
364: \subsubsection{One simple language and one model of computing for all purposes}
365:
366: There are several different computer languages, specification formalisms
367: and design notations in common use today---including diagrammatic notations
368: and formalisms---and there are many other systems that are less commonly
369: used.
370:
371: Associated with these various languages and notations are several different
372: perspectives or `philosophies' about how software and related knowledge
373: should be organised: `entity-relationship models', `data flow models',
374: `entity life histories', `object-oriented design', `logic programming',
375: `functional programming' and others.
376:
377: Training software developers in these different languages, notations and
378: perspectives takes time and money. The lack of clear guidelines about which
379: formalism or perspective is appropriate in which contexts, and how they
380: should be related, if at all, causes confusion and wasted effort.
381:
382: Given the `universal' nature of SP patterns (Section \ref{representation_of_knowledge}), they may serve as a `wide spectrum' language in software engineering with a wide range of
383: potential applications.
384:
385: Using one simple language for all types of software would mean less training
386: and less confusion about how software development should be done. Carried
387: to its logical conclusion it may eliminate all problems of compatibility
388: between systems.
389:
390: \subsubsection{No refinement, verification or compiling}
391:
392: In a typical development project, two, three or more different formalisms,
393: languages or notations will be used in different stages of the
394: development. There may be two or three translations between
395: formalisms---from analysts' models to formal specifications and from formal
396: specifications to program code. There is always some kind of compiling of
397: the code into a form which the machine can use. If proper standards of
398: quality are to be maintained, it will be necessary to check rigorously or
399: `prove' that each of these translations have been done correctly.
400: The correctness of compilers must also be verified.
401:
402: The whole process of translating between formalisms and proving the
403: correctness of translations is labour intensive and expensive. The
404: complexity of the process means there is plenty of scope for making
405: mistakes and there are corresponding problems in maintaining the quality of
406: the final product.
407:
408: The SP machine has the potential to simplify the process of developing
409: software dramatically. SP patterns may be used in all stages
410: and phases of development. An SP data model prepared during systems
411: analysis may be incorporated directly in a software system without
412: modification. A formal specification of a software system expressed as SP patterns
413: may be run immediately without translation into a programming language. All
414: translations and all compiling may be eliminated. Since SP patterns are
415: intended to be executed `directly' without translation or compiling, there
416: should be no need for `verification' or proof that an implementation conforms
417: to its specification.
418:
419: Eliminating all translation between formalisms and all verification that
420: translations have been done correctly can bring four major benefits:
421:
422: \begin{itemize}
423:
424: \item It can save large amounts of labour-intensive work and corresponding expense.
425:
426: \item It can shorten the time needed to produce a working system. This is
427: useful in itself and it facilitates the use of iterative prototyping techniques, giving
428: prospective users good opportunities to validate the developing system and
429: ensure that it meets their needs.
430:
431: \item It should eliminate all errors arising from translation between formalisms during refinement and verification. This is a major source of errors in software and its total elimination would mean a dramatic improvement in the quality of software products.
432:
433: \end{itemize}
434:
435: \subsubsection{Software re-use}
436:
437: The variety of languages and systems that are currently in use and the fact that, often, they do not
438: integrate properly, one with another, means significant difficulties in
439: re-using software in more than one context. Significant resources go into
440: translating between languages, porting software between machines and
441: operating systems or simply re-writing functions from scratch. It should
442: never again be necessary to re-write the standard arithmetic functions but
443: this does still happen.
444:
445: The SP system may facilitate software re-use in four main ways:
446:
447: \begin{itemize}
448:
449: \item By supporting object-oriented class hierarchies with inheritance (Section \ref{class_part_inheritance}): any new class may re-use an existing class by making
450: the old class into a super-class of the new class. In this way, all the information in the old
451: class is inherited by the new class.
452:
453: \item As in any `functional' programming language, an SP `function' can be re-used by `calling' it from two or more different contexts.
454:
455: \item A significant problem in re-using software is finding what is needed
456: within a library of existing modules, functions or classes. The use of
457: meaningful names for functions can help as can the indexing and
458: cross-referencing of functions. The SP system provides the additional facility of
459: powerful pattern matching and searching. This can mean flexible retrieval
460: capabilities comparable with what is provided in the best systems for
461: bibliographic search.
462:
463: \item The `universal' nature of SP patterns (Section \ref{representation_of_knowledge}) should facilitate the integration of diverse kinds of knowledge, making it easier to re-use software in different contexts without the incompatibilities that plague current systems.
464:
465: \end{itemize}
466:
467: \subsubsection{Configuration management}
468:
469: A significant problem in system development is the `configuration
470: management' problem, meaning the problem of keeping track of and managing
471: the several versions of a software system which are typically produced in
472: the course of development. What gives the problem spice is that most
473: systems of any size come in parts, sub-parts and so on and each component
474: at any level may come in several versions. Furthermore, associations must
475: be maintained between source code, object code, requirements
476: specifications, designs and other documentation for all the versions and at
477: all the different levels within each version.
478:
479: The ability of the SP system to integrate class hierarchies with part-whole hierarchies may serve for configuration management (Section \ref{making_haste_slowly}). Versions of a software system may be represented as classes as can the versions of its parts and sub-parts. And different combinations of components or associations between components can be tied together in a flexible manner according to need.
480:
481: These capabilities should be useful in applications other than software engineering, wherever documents are to be developed comprising diverse kinds of knowledge divided into parts and sub-parts with one or more versions for each part.
482:
483: \subsubsection{Automatic programming}
484:
485: There is a well-established principle in software engineering that a
486: well-designed software system should model the domain which it is designed
487: to serve. This principle was cogently argued by \citet{jackson_1975} for data
488: processing, it underpins the practice of using entity-relationship
489: models, data-flow models and entity life histories as a basis for software
490: design and it is a key part of the philosophy of object-oriented design.
491:
492: The anticipated ability of the SP machine to learn new concepts from experience means that, given
493: `raw' data about a domain, the system should be able to create a model of that
494: domain automatically. Given a stream of data, an SP machine should be able to derive a
495: well-structured Jackson diagram or grammar for the data. Information may
496: also be organised into class hierarchies with inheritance of attributes in
497: the manner of object-oriented design.
498:
499: If the modularisation and structuring of software can be automated or semi-automated in this kind of way, this should greatly accelerate the process of designing new software systems.
500:
501: \subsubsection{Modifiability}
502:
503: Most software is far too inflexible. Although most packages give the
504: end-user some scope to set parameters or tailor the package to their
505: individual requirements, this flexibility is usually very limited. In
506: general, a software package is a take-it-or-leave-it item. Buying software
507: can mean a lot of effort in evaluating packages which are nearly but not
508: exactly what one needs. Short cuts in evaluation often mean discovering
509: shortcomings after a package has been bought. The same kinds of problem
510: apply to bespoke software: it is too difficult to modify software to meet
511: changing needs even when that software was originally designed to fit one's
512: specific requirements. All these problems would be reduced if it were
513: easier to modify software to meet one's needs or changes in one's needs.
514:
515: It should be relatively easy to make changes to SP software for three main
516: reasons:
517:
518: \begin{itemize}
519:
520: \item {\em Simplicity} in use. As described earlier, the SP machine should eliminate all processes of
521: translation, compiling and verification. This should greatly simplify the process of changing software.
522:
523: \item {\em Minimal redundancy} in software. The system should remove one of the
524: main difficulties in making changes to conventional programs: a change
525: made in one part of the program often means that corresponding changes
526: must be made in other parts; it can be troublesome finding all the
527: parts that must be kept in step and errors can easily creep in.
528: As with other object-oriented systems which support class
529: hierarchies and inheritance, the SP system should allow software to be designed with a
530: minimum of redundancy; this means that any given change to a program
531: can be made in only one part of the program without the risk of
532: inconsistencies.
533:
534: \item If {\em automatic programming} can be developed as anticipated, this
535: should assist the process of modifying software. Any inefficiencies
536: in a modified software system may be corrected automatically.
537:
538: \end{itemize}
539:
540: \index{software engineering|)}
541:
542: \subsection{Expert systems and intelligent databases}
543:
544: \index{expert system|(}\index{database!intelligent|(}
545:
546: One of the most promising areas of application for the SP machine is where stored knowledge is used as a basis for various kinds of reasoning---like an `expert system' or `intelligent database' running on a conventional computer. We have seen already how the system may be used in such applications as medical diagnosis (Section \ref{medical_diagnosis_section}), fault-finding with a discrimination network (Section \ref{probabilistic_decision_network}), reasoning in the context of a forensic investigation (Section \ref{reasoning_with_rules_section}), and causal diagnosis (Section \ref{causal_diagnosis_section}).
547:
548: Compared with existing systems, the potential advantages of the SP machine include:
549:
550: \begin{itemize}
551:
552: \item Seamless integration of different kinds of knowledge. In a forensic investigation, for example, knowledge about a crime and knowledge about suspects may be expressed in the same format as `expert' knowledge about ways in which crimes are normally committed and `everyday' knowledge about the association between matches and fire, the need to keep dry in wet weather, and so on. This should facilitate the process of finding connections between different kinds of knowledge.
553:
554: \item Seamless integration of different styles of reasoning: probabilistic `deduction', abductive reasoning, nonmonotonic reasoning, and others, as described in Chapter \ref{pr_chapter}, as well as classical kinds of logical reasoning considered in Chapter \ref{maths_logic_chapter}.
555:
556: \item The ability to calculate probabilities for inferences fully in accordance with standard principles of probability theory.
557:
558: \item The ability to learn new knowledge from `raw' data in the manner of `data mining', abstracting rules and organising knowledge into class hierarchies and part-whole hierarchies without the need for human intervention. Of course, there is still a substantial gap between these possibilities and what the current model can do (Chapter \ref{learning_chapter}) but there seems no reason in principle why the system should not be developed along these lines.
559:
560: \end{itemize}
561:
562: \index{expert system|)}\index{database!intelligent|)}
563:
564: \subsection{The storage and retrieval of information and the relational model}
565:
566: \index{information!retrieval|(}\index{database!relational model|(}
567:
568: For applications where the emphasis is on the storage and retrieval of information, the SP system could be an attractive alternative to the relational model (\citet{codd_1970}, see also \citet{connolly_begg_2002}), which is currently the dominant model for database applications (if we discount the network model and its dramatic resurgence in the World Wide Web). This subsection compares the two.
569:
570: \subsubsection{Representation of tables}
571:
572: One of the attractions of the relational model has been the simplicity of the idea of representing everything in tables. Although this idea is easy to grasp and has proved very practical and successful in a host of applications, it is not quite as simple as it may superficially appear. This is because a table in a relational database is not merely an array of columns and rows as it appears on the computer screen. In order to access individual cells efficiently, it is necessary to mark cells and rows with appropriate tags. Normally, these tags are hidden from view but they can be seen when a table is translated into something like XML, designed to facilitate the inter-change of information between computer systems in a form that can be read by people.
573:
574: The difference can be seen by comparing Table \ref{periodic_table_example}---which shows two rows of the periodic table---with Figure \ref{xml_table_example} in which the same two rows are represented using XML. In the latter representation, each cell needs to be marked explicitly with tags like `$<$name$>$ ... $<$/name$>$' or `$<$symbol$>$ ... $<$/symbol$>$' corresponding to the column in which the cell appears. Tags like `$<$row$>$ ... $<$/row$>$' are also needed to mark each row as a distinct entity.
575:
576: \begin{table}[!hbt]
577: \centering
578: \begin{tabular}{l l l l}
579: \em Name & \em Symbol & \em Atomic & \em Atomic \\
580: & & \em Number & \em Weight \\
581: \\
582: Hydrogen & H & 1 & 1.00794 \\
583:
584: Helium & He & 2 & 4.0026 \\
585: \end{tabular}
586: \caption{Two rows of the periodic table.}
587: \label{periodic_table_example}
588: \end{table}
589:
590: \begin{figure}[!hbt]
591: \fontsize{10.00pt}{12.00pt}
592: \centering
593: \begin{BVerbatim}
594: <periodic_table>
595: <row>
596: <name>Hydrogen</name>
597: <symbol>H</symbol>
598: <atomic_number>1</atomic_number>
599: <atomic_weight>1.00794</atomic_weight>
600: </row>
601: <row>
602: <name>Helium</name>
603: <symbol>He</symbol>
604: <atomic_number>2</atomic_number>
605: <atomic_weight>4.0026</atomic_weight>
606: </row>
607: </periodic_table>
608: \end{BVerbatim}
609: \caption{Table \ref{periodic_table_example} represented using XML.\protect\footnote{Adapted with permission from {\em The XML Bible} by Elliotte Rusty Harold, John Wiley \& Sons, 2001.}}
610: \label{xml_table_example}
611: \end{figure}
612:
613: Although there are differences in details, the way in which a table is represented in XML---and more covertly in the implementation of a relational database---is essentially the same as it would be represented in the SP system. Thus, the SP system can represent information in the form of tables and it can do so in a manner which matches the simplicity of relational databases, neither more nor less.
614:
615: \subsubsection{Class hierarchies}
616:
617: \index{class!hierarchy|(}
618:
619: Tables can be a convenient way to represent classes of entity. For example, in a typical data processing application, one might use a table to represent the class of employees, another table to represent the lorries that the company uses to distribute its products, and so on. But if tables are used in an unthinking way, they can lead to unwanted redundancies in a database. For example, the class of employees and the class of customers would both normally have fields for `title', `first name', `second name', `address', `telephone number' and, perhaps, others.
620:
621: It has been recognised for some time that redundancies of that kind can be reduced by abstracting the repeated fields, putting them in a third table (which would, in this case, be called something like `person'), and linking the super-class with its subclasses by the use of reference numbers. In this kind of way, relational databases have provided a basis for the use of `entity-relationship' models in data processing applications \citep{chen_1976}, with hierarchies of classes which are very much like the class hierarchies of object-oriented design.
622:
623: Given that class hierarchies can also be represented in the SP system (Section \ref{class_part_inheritance}), one might think that, with respect to class hierarchies, there was little to choose between the relational model and the SP system. But in this area the SP system has two advantages compared with the relational model:
624:
625: \begin{itemize}
626:
627: \item In the relational model, each attribute of a class---represented by a field or column in a table---is a {\em variable}. There is no provision in the relational model for representing the attributes of a class as literal values such as `furry', `warm-blooded', `has-backbone' or the like. In the SP system, by contrast, the attributes of a class can be any combination of literal values and variables, the latter represented by pairs of ID-symbols such as `title ... \#title', `first\_name ... \#first\_name', and so on.
628:
629: \item In the SP system, the connection between a given class and any one subclass is made via matching symbols in a corresponding pair of patterns. In the relational model, by contrast, the connection between a given class and any one of its subclasses is made via matching reference numbers in the tuples that represent individual instances of those classes. For tables containing hundreds or thousands of rows (which is not unusual in data-processing applications), this system for connecting a class with any one of its subclasses is considerably more clumsy than the comparative simplicity of the SP scheme where classes can be connected to each other directly and not via their individual instances.
630:
631: \end{itemize}
632:
633: With respect to the first point, it may be argued that databases are all about storing information that varies from one instance of a class to another and that there is no need for any information about literal values. This may be true for conventional data processing applications where there is no uncertainty about what class a given entity belongs to. But in applications where one may wish to recognise some unknown entity on the basis of fragmentary information (as described in Chapter \ref{rr_chapter}), then it is important to know as much as possible about each class, including attributes that would most naturally be represented with literal values, not variables.%
634: \index{class!hierarchy|)}
635:
636: \subsubsection{Part-whole hierarchies}
637:
638: \index{part-whole hierarchy|(}
639:
640: Very much the same can be said about part-whole hierarchies as has just been said about class-inclusion hierarchies. Part-whole hierarchies can be represented in a relational database but this is relatively awkward compared with the SP system and does not allow for parts to be described in terms of literal attributes as well as variables. With a relational database, part-whole relations cannot be integrated with class-inclusion relations in the seamless manner that SP allows.%
641: \index{part-whole hierarchy|)}
642:
643: \subsubsection{Retrieval of information}
644:
645: In the SP system, retrieval of information is achieved most naturally by the use of a New pattern representing the kind of Old information that is to be retrieved, with gaps where details are needed. This is essentially the same as `query-by-example' in relational databases, except that the SP system does not require the kind of `wild' symbols that are required in some relational systems (e.g., `?' or `*'), and the SP system is more tolerant of extraneous information than is the case in some implementations of relational databases.
646:
647: Given appropriate patterns, the SP system allows information to be retrieved indirectly via `meanings' as well as via direct matches between the query and stored data (Section \ref{indirection_in_ir}). Relational databases do not lend themselves naturally to this kind of information retrieval.
648:
649: Although current SP models are geared mainly to the representation and retrieval of symbolic information, it is envisaged that the SP machine will be developed to handle numeric information as effectively as conventional computers (Section \ref{sp_machine_other_developments}). In that case, it should be possible to store numeric information and to retrieve it with operators such as `more than' (`$>$'), `less than' (`$<$') and so on.
650:
651: There is nothing in current SP models equivalent to SQL or similar languages for database retrieval. But if the system can cope with the syntax and semantics of natural languages (Chapter \ref{language_chapter}), there seems no reason in principle why, with appropriate patterns stored in Old, the SP system should not accommodate relatively simple artificial languages like SQL.%
652:
653: \subsubsection{Organisation of knowledge}
654:
655: \index{learning}
656:
657: Currently, the organisation or `normalisation' of knowledge in a database is done by human judgement. Although the results are normally good, the process of designing a database can be a significant task, especially where the domain of application is complex.
658:
659: In principle, some or all of this task may be automated. If learning processes like those in the SP70 model can be developed to their full potential, it should be possible to structure an SP database automatically when it is first established and to restructure it at any stage. This should save effort and corresponding expense, and it could conceivably overcome weaknesses in database structures that are created `manually'.
660:
661: \subsubsection{Conclusion}
662:
663: With respect to the storage and retrieval of information, the SP system can represent tables in essentially the same form as they are represented in relational databases, but the system has advantages over the relational model in the representation of class hierarchies, part-whole hierarchies and in aspects of information retrieval. If the SP machine can be developed as anticipated, it should be able to do everything that a relational database can do and more besides.
664:
665: Since, in addition, the SP system can be applied in such areas as natural language processing, probabilistic reasoning, planning and problem solving, it has substantial attractions as an alternative to the relational model.%
666: \index{information!retrieval|)}\index{database!relational model|)}
667:
668: \subsection{Other applications}
669:
670: Other areas where the SP machine may be applied include:
671:
672: \begin{itemize}
673:
674: \item {\em Natural language processing}.\index{language!processing} In Chapter \ref{language_chapter}, we saw how the SP system lends itself to the representation of natural language syntax, to natural language parsing and production and, more tentatively, to the integration of syntax with semantic structures. On this evidence, the SP machine should be a promising vehicle for such applications as understanding and production of natural language in spoken or written form or translations between natural languages.
675:
676: \item {\em Automatic learning of natural language grammars}.\index{learning} If the learning processes described in Chapter \ref{learning_chapter} can be developed as anticipated, automatic learning of natural language grammars, including semantics, may become feasible.
677:
678: \item {\em Planning and problem solving}.\index{planning}\index{problem solving} With further work on planning and problem solving, as outlined in Chapter \ref{pps_chapter}, a range of new applications should open up.
679:
680: \item {\em Project management}.\index{project management} On rather shorter timescales, an SP machine would be a convenient vehicle for the storage and retrieval of information associated with project management, as described in \citet{wolff_1989}.
681:
682: \end{itemize}
683:
684: \section{Conclusion}
685:
686: Whether or not the SP system will be any good at mending socks remains to be seen. Meanwhile, there is a range of possible applications that promise to be useful on shortish to medium timescales. The SP theory provides a new perspective on many issues in computing and cognition and should have heuristic value in neurophysiology (Chapter \ref{neural_chapter}), in cognitive psychology (Chapter \ref{psychology_chapter}), and in mathematics and in logic (Chapter \ref{maths_logic_chapter}).
687: