An SERC committee should study (a) how to involve industry with academia in IKBS research, (b) funding mechanisms for Demonstrator projects, (c) human resources and projects names, interests and availability, (d) funding mechanisms for IKBS in academia.
This group worked to an agenda which covered six key topics, namely communications, software, hardware, support, resource allocation, and dissemination. Each of these topics is discussed individually below.
Good communications were seen as being of paramount importance. There was a strong feeling that some minimal communications facility (perhaps just a mail facility) should be made readily available to anyone with a legitimate interest in IKBS work, rather than the facility being limited to academic grant holders.
Recognising a danger that network provision could be delayed while facilities were debated, the group assigned priorities to network services. The unanimous view was that a network providing mail should be provided immediately even if this network could not support any other services. Subsequently the network should be developed to support file transfer and access to prototype systems, in that order of priority. (Prototype systems is intended here to cover both software systems and new hardware.)
The network will be required to link both the academic and industrial communities, and it was therefore felt that PSS represents the most suitable vehicle. Gateway access to other networks, particularly ARPA, will be required.
It was felt that convenient naming of members of the IKBS community would be useful, and that a global name space should therefore be established (at least for mail) with a white pages directory. This would enable mail to be sent to any member of the community by name, without concern for location.
The group agreed with the views of the common base syndicate. Initially, support should be provided for the following:
Language Systems Lisp (Franzlisp - Berkeley), POP-2 (Poplog - Sussex), Prolog (Pereira's System - Edinburgh)
Implementation Language: C
Operating System: Unix (Berkeley 4.1)
It was felt essential to provide a mechanism whereby the software base available to the community could evolve while remaining properly supported. In pursuance of this, it was felt that there should be powers of contract for the development of the software base, such powers to cover commissioning, evaluation, distribution and maintenance of software.
Since some committee would need to coordinate and supervise such developments, the group coined the name SIGIKBS to refer to such a committee. It was explicitly recognised that the role of SIGIKBS might either be performed by an entirely new committee, or might be undertaken by the existing SIGAI. However it was felt that the latter would need to be supplemented by industrial representatives for the SIGIKBS role.
It should be noted that the group's considerations of software were intended to cover both basic tools and packages. Thus the software base available to the community was seen as evolving both by the provision of new tools and by the provision of packages such as databases or dictionaries.
Again the group agreed with the views of the common base syndicate. For pragmatic reasons the VAX should be accepted as the common base machine, but this should be regarded as the short term delivery vehicle for the common base software. As a matter of some urgency a study should be commissioned on the suitability of the various personal machines for IKBS applications. This study should also consider the local area networks which are associated with such machines.
It was observed that many projects in the IKBS field require exotic and expensive peripheral equipment (robot arms, vision boxes, etc.) There was no clear view as to whether for such peripherals there should be an SERC recommended choice. However it was felt that some care should be taken to ensure that the financial plans for the IKBS programme make adequate provision for the purchase of such peripherals (and any associated control micros or whatever.)
It was felt that the common support for widely-used tools and packages could be more effective if it were distributed rather than centralised. Thus for any tool or package included in the software base there would be a designated support centre. This support centre may or may not be the establishment at which the tool or package was developed. The most important criterion is that the support centre should have an active local user community for the particular tool or package. Examples of possible support centres are Sussex for Poplog and Edinburgh for Prolog.
In addition to such common support facilities which are directed at particular tools or packages, there is a need for local support facilities which are directed at local needs and problems. Experience indicates that such local support can be provided effectively by a two-level system with provision at both the regional and the individual site levels. Examples of centres which currently provide regional support are ERCC and SWURCC. Site support may be provided, for example, by a single person working at a single location. The group envisaged a need for perhaps 10 regional support centres, and felt that perhaps 40 locations would require individual site support.
The most important single resource requirement was identified as some means of relieving researchers of some part of their teaching load. (This is of course in conflict with the need to train more people in the IKBS field. No means of resolving the conflict was offered.)
The group recognised three levels of resource provision as being of interest. The first level of resourcing would simply allow interested parties to gain access to the IKBS community (see section 1). The second level would enable individuals and groups to carry out R & D (this corresponds to the normal academic grant.) The third level would enable distribution of IKBS developments to the community and subsequent support. Each of these three levels was regarded as being important for different reasons, and it was therefore felt that the programme could usefully recognise all three levels. Note explicitly that this would imply that certain resources could be obtained without any need for a successful submission for a research grant.
There was a feeling that provision of resources is sometimes delayed unnecessarily by the need for submissions to a central body. It was felt that such delays could partly be avoided by distribution of infrastructure resources in reasonably large chunks to responsible local bodies. Where appropriate, submissions could then be made to these local bodies who would be expected to provide a relatively fast response. A mechanism for this might be provided by SIGIKBS (see section 2).
Various mechanisms for dissemination were discussed by the group, including the following:
Some members of the group were concerned that the proposed IKBS common base, as discussed in sections 2 and 3, is different from that adopted by the SERC for general usage, and in particular that employed for the Software Technology Initiative. This could raise substantial problems for workers who would like to distribute software - say language processors or database systems - to both the IKBS and Software Engineering communities However, given the present needs of the IKBS community and the established common base policy, no satisfactory solution to the problem could be proposed.
The group was anxious to emphasise that expertise in the IKBS area is a scarce human resource. The appropriateness of plans for Education and Training depends crucially on how efficiently the existing stock of experts is deployed. This implies very careful planning both of student numbers and of the style of interaction with them.
1. TRAINING NEEDS: The group identified the following categories of activity:
Certain Demonstrator projects might have special training needs. these were not considered in detail. they might include:
2. ECONOMISING OF MANPOWER: It was considered crucial to permit the maximum concentration of available expertise on graduate training and on research in the area. Priority in training should be given to training of future research workers. Other training needs should be met partly through spin-off from this advanced training activity, partly through use of appropriate external resources. Measures which could improve the efficient use of specialist expertise included:
3. GRADUATE EDUCATION: The group broadly agreed with the scale of the programme envisaged in the supporting document from the IKBS ad hoc panel. A more rapid expansion in graduate education would have been desirable if practical. Particular points raised:
Letter from the Rapporteur David Park to John Taylor I enclose my report on the Education and Training Group. In our one session we could do little but air our prejudices and a few ideas. With a bit more time we might have come up with conclusions rather better focused - but I hope something valuable can be gleaned nevertheless.
I came away from the meeting preoccupied with the problem of managing the sort of diffuse effort that is likely to emerge, if research funds are available. I like the idea of Demonstrator Projects, but have a suspicion that the best research groups may actually prove rather coy in their willingness to collaborate actively with them. If funding does emerge from Alvey, it will be interesting to see how this situation develops.
The main output from the deliberations of Group 4 was a list of subjects, both within Computer Science and outside it, that should either contribute to any SPP on Intelligent Knowledge-Based Systems, or might benefit from work done in the SPP, or both. The group felt it important to emphasise the potential two-way nature of these interactions.
VLSI This is a good example of two-way interaction. People working in IKBS will need to use VLSI as a tool for producing realistic systems - for example special-purpose chips may be required in speech recognition systems or for symbol manipulation - and at the same time IKBS will contribute to VLSI, for instance with knowledge-based design aids and inference systems for proving the correctness of VLSI designs.
System Architecture IKBS will undoubtedly need access to large amounts of computer power and seem particularly suited to multi-processor architectures. What seems to differentiate IKBS from other large users of computer power is a need for large amounts of data and a tendency to use recursive algorithms. The particular effect of these factors on system architectures is worthy of study. The adoption of rule-based methods of implementing programs needs to be studied also. One feature of all useful knowledge-based systems is likely to be the need for a really well designed MMI, and so all architectures should support high-resolution graphics efficiently.
Programming Languages An interesting phenomenon is the gradual convergence under the banner of rule-based programming of languages for data base manipulation, system specification and system implementation. The influence on programming languages of the highly parallel architecture needed to implement many IKBS needs to be studied.
Software Technology This is another example of a two-way interaction. The developers of IKBS will need the latest techniques of software development in terms of efficient programming environments and languages, but IKBS also has considerable scope for contributing to those techniques. Examples are the use of declarative languages for software specification and the work done on knowledge-based programming aids. Rule-based programminq is itself a significant contribution to software technology. One particular development that group members felt was needed was an efficient interface between the new declarative languages and traditional languages like Fortran, so that the considerable body of software already developed could be accessed easily.
Man-Machine Interface The group felt it important to emphasise that this topic was not merely fancy input-output devices, but embraced the whole concept of what has been termed the Conceptual Machine. It includes the explainability and intelligibility of software (rule-based programming has already made a significant contribution in this area) and methods of informal reasoning. This is an area that needs to be given some priority in the SPP, and should definitely not be left entirely to outside groups.
Total System Evaluation The SPP should take the evaluation of total knowledge-based systems very seriously. (That is evaluation of both the systems themselves and the people using them in real-life situations.) The information thus gained would be invaluable during the design of future systems.
Theoretical Computer Science An area of high importance here is the design and analysis of algorithms for non-Von Neumann machines. A contribution from the AI community to this area is that the specification, transformation and verification techniques developed in connection with theorem proving are now widely applied.
Robotics There is a considerable amount of work needed on the design of robotics languages. It is interesting to note, incidentally, that the increasing use of robots is also having an effect on mechanical engineering design.
Database Technology The IKBS SPP will undoubtedly need access to very large databases, some of them probably distributed. The problem of large distributed databases is an area where this SPP may well need to interface with the Distributed Computer Systems programme. It should be noted that AI also has something to contribute in this area, notably in the fields of Semantic Networks, Integrity Constraints and the problem of incomplete data in databases.
The group thought it very important to make the point that funds from the SPP on IKBS should be available to people outside the Computer Science and Artificial Intelligence communities so that people with the necessary range of skills can be brought into the SPP. Equally it was felt that Computer Scientists and AI people should be encouraged to broaden their outlook by undertaking projects in some of the areas mentioned below. In particular it was felt that people involved in demonstrator projects should be encouraged to undertake a broad range of training courses.
Mathematics Topics in mathematics that have a significant input to the SPP on IKBS include inference, analysis of algorithms, fuzzy logic, theorem proving and algebraic topology.
Psychology Considerable inputs are necessary from psychologists in the area of MMI design and the intelligibility and understandability of programs. It is as important that technologists gain some knowledge in this area as it is that psychologists should contribute their specialised expertise.
Education Education was mentioned as an area likely to benefit particularly from the introduction of knowledge-based techniques.
Sociology It was felt that sociologists could contribute significantly to the evaluation of total systems, as mentioned above. An evaluation of the potential impact of IKBS on society was an essential component of the SPP.
