§11.1 Expert Systems

What is an "expert system"?

• Perhaps, a computer program using knowledge and inference mechanisms to solve problems which, when tackled by humans, require significant expertise

Prolog more or less by definition meets part (i) of this; how about part (ii)?

• That depends on the application domain

• But it is achievable, given the will!

• e.g a wine selecting program.

How might we assess an expert system?

• often an expert will be unaware of their breadth of knowledge brought to a task

• trivial example: will you take 52 474?
  • a class at University of Strathclyde
  • 52 xxx ... a Computer Science class
  • 52 4xx ... a final honours class
  • 52 474 ... "Databases 2"

• often, as here, the knowledge is meaningless out of its proper context!

So, what criteria for assessing - or establishing - an expert system? Perhaps:

• nature of task accomplished

• difficulty of task

• intelligence - fundamental domain principles, often with weak reasoning

• expertise - high level rules, avoidance of blind search, general performance

• reasoning - symbolic manipulation

• reformulation - conversion from 'expert' to 'computer' format

• self-reasoning - essential ability to supply explanations

Between them, these reflect characteristics of:

• adaptability to new domains

• ability to justify or explain

• knowledge application at "right" time

• use of inexact knowledge

• handling of imprecise data

We can recognise features of Prolog - but they (should!) leave us uneasy

• Prolog is, despite the aims for declarative freedom, essentially goal driven

• in Prolog we are fanning out to the leaves of the computational tree as we tackle
  • ?- A:- B, C.

• in Prolog forward chaining, or fanning in, is more tricky:
  
  • we know B and C, what can we deduce?

In fact Prolog proves useful for small scale systems, or for prototyping, or for simple experimentation.

§11.2 Databases

So, if there are difficulties with expert systems, how about something less sophisticated?

Clearly, Prolog database systems are possible:

• Provided we generate rules and data in distinct chunks (i.e. files), we can mix and match them at will - giving us a database shell.

• This gives a useful general rule for the maintenance of Prolog code ... software is reusable!

As for expert systems, the possibility is there, especially in a prototyping context.

Much depends on what we want to achieve, and on the tools available

• for example, the great strength (or weakness!) of being able to adjust facts and rules and queries, can be overcome by generating a compiled, free-standing package

• let's look very briefly at the problems of using C-Prolog, for example to generate a network-wide database at no software purchase (as opposed to construction) cost

More or less by definition, we generate a relational database
- relation and predicate are essentially synonymous!

And the extent to which data is normalised is up to us

• all occurrences of a record type must have same number of fields
  - Prolog doesn't care, but use of a context-sensitive editor will guarantee it.

• a non-key field must describe only a whole key (not just part of it)

• a non-key field must describe only a key field (not a non-key one)

... these are self-discipline, not Prolog.

Where we run into difficulty is in terms of control:

• how do we define (restricted) user views?

• how do we provide security?
  • Remember: given
    • salary([p₁, ..., p_n], value_1)
    • salary ([p₁, ..., p_n+1], value_2)

  • it is easy to deduce salary(p_n+1, Value)

• how do we guarantee data integrity?

• how do we provide a locking mechanism for updates?
  Curiously easy, that! But limiting.

• how do we undo or redo a transaction?

Yet all these can be tackled, successfully, if we wish.