Jump Over Left Menu
Group 1: Research Programmes and Projects
- 8 syndicates had reported an average of about 5 or 6 topics that would merit research. Individual topics were not discussed by the Group.
- Instead, the Group concentrated on how some of these topics were related eg:
- Multi-level planning in vision and robotics
- Architecture needs of knowledge rep. and declarative languages
- Linking of conventional databases; PROLOG type access.
- Research, driven by the application domain, versus research into the tools to build IKBS, was debated but no agreement was reached.
- The Group was against the creation of permanent AI centres/centres of excellence/multi-disciplinary centres, but did not exclude temporary Application centres forming around projects.
- Interested parties argued for demonstrator projects that emphasised the use of their own expertise, eg Automatic Assembly and Design, Speech Understanding/Transcription/Synthesis.
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.
Group 2: Infrastructure
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:
- Electronic newsletter It was observed that such a service cannot be provided cheaply, since it requires editorial effort, but may nevertheless be worthwhile.
- Workshops, short courses and summer schools. The importance of industry participation was emphasised.
- UK Travel There was a widespread feeling that travel in the UK for discussion, collaboration, workshops, etc., should beeasy. Attention should be paid both to ensuring that sufficient funds are available and that the mechanism for UK travel support is as simple as possible.
- Apprenticeships Academic personnel should be able to 'serve apprenticeships' in industry, and vice versa.
- Long term research posts Some vehicle is required whereby people can conduct research in IKBS with security of employment for a significant period and without any teaching obligations. Many people see this as a key to retaining our experienced personnel in the UK (and possibly even attracting back some researchers who have left the UK to work in other countries.)
- A BTG By-pass It was felt that dissemination of products into industry would sometimes be easier and quicker if BTG could be by-passed.
- Multi-project sites Although the idea of an IKBS institute (or even several) met with some scepticism, it was generally felt that multi-project sites should be encouraged. Such sites would be recognised centres of activity, and in return for such recognition should be required to make adequate provision for visitors, including academic, industrial and overseas visitors.
7. A Common Base Concern
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.
Group 3: Training and Education
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:
- Training of future research workers
- Industrial needs - training for those concerned with design and development of IKBS systems.
- General awareness - affecting recruitment into the area, and wide discussion of social and economic consequences.
Certain Demonstrator projects might have special training needs. these were not considered in detail. they might include:
- Training of experts from other disciplines - whose collaboration might be essential to the design of certain expert systems.
- Training for potential users of Expert Systems.
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:
- Coordination with universities via the UGC and Computer Board to finance teaching and administrative assistance relieving research workers of academic responsibilities unrelated to progress in the area. [Such measures are understood to have been taken in connection with research programmes in the microelectronics area.]
- The financing by SERC of demonstratorships tenable by research students - bearing in mind the graduate assistanceship arrangements prevalent in North American universities.
- Employment contracts for research workers returning from abroad sufficiently generous to attract an appreciable proportion of those who would be eligible.
- The use of intensive 2-3 week courses widely available to to the research community and to workers in peripheral areas - as an efficient means for communicating up-to-date information in active research areas. Such courses could enhance, though not substitute for, graduate education in the conventional style.
- Assistance in preparation of material for use in industrial and general awareness courses, by cooperation with the Open University and/or with the Department of Industry Unit responsible for the CAD/CAM initiative.
- The provision of a centralised Development/Information Centre available to workers from industry and/or universities.
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:
- There is a heavy demand for graduate places on courses devoted to AI, so that a very rapid expansion is relevant AI graduate education could be achieved by raising the number of studentships allocated to appropriate university AI centres. the demand for Computer Science-based courses is not so strong.
- Between 3 and 5 MSc Courses based on IKBS topics should be
developed and planning for these could start immediately. Universities mentioned were
- Open University
- Collaboration between universities on a core curriculum would be appropriate.
- Courses should have status as conversion courses. There would be a significant interdisciplinary component whatever the undergraduate background of students.
- Courses would require significant funds for both hardware and software support - though these requirements were not quantified.
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.
Group 4: Interfaces with other Areas
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.
Areas within Computer Science
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 proqramminq 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 explainabilitv 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.