.TL
Getting Started with the IFe
.SH
Introduction
.LP
The following terse notes will hopefully get you started
with the IFe.  If (and when) you encounter any problems please
do not hesitate to contact one of the project staff:
.sp 0.5
.TS
center;
l l.
Joe Clarke or Malcolm Lindsay	Damian Mac Randal
Energy Simulation Research Unit	Informatics Department
University of Strathclyde	Rutherford Appleton Laboratory

+44 41 552 4400 X3986 or 3747	+44 235 445403
.TE
.PP
Before starting to work with the IFe we suggest that you take
a little time to read the enclosed report.  We acknowledge that
it too is terse but with a little effort things should become clear.
If you have installed the IFe properly, you can run it as follows:
.IP 1.
Ensure that you have write permission to directory @/ife/lib/uc
where @ signifies the path from root - for example at ESRU this
would be /usr/esru.
.IP 2.
Go to directory @/ife and do "source .iferc_c" if you run csh
or ". iferc_b" if you run sh.  Note that you may firstly
have to change some of the entries of these files depending
on where you install the ife directory.
.IP 3.
Start the IFe by typing "ife_bb".  The IFe top level form,
comprising 4 concepts, should now appear.
.IP 4.
The "User name" concept should already be set (the IFe has asked
the system for the current user name) but can be changed by a left
button click over the entry field.  The "User type" concept
is a pop-up activated again by left button down.  Since only one
user conceptualisation is developed, this concept should be set at
engineer.  The "User level" concept can be set at either of the 
two states on offer.  Finally, the "Project name" concept should
be selected (left button down over entry field) and any character
string entered.  Since the Knowledge Handler predicate corresponding to
each concept is not invoked until a concept is exited (that is a new
concept is selected) it is now necessary to de-select the "Project name"
concept (note that this is actually a flaw in the current conceptualisation).
This is best done by pressing the middle mouse button over the desk.
.IP 5.
We suggest that you then press the "Building_definition" button
and see what happens from then on.
.PP
See Section ? of the report for a description of the meaning of the
mouse buttons and the pop-up menus offered by the IFe.
.PP
Should the IFe crash for any reason, it will probably be necessary
to kill several processes (using the kill -9) command.  The processes
to be killed will each commence with the string "IFE".
.SH
Working with the IFe
.PP
Essentially this involves:
.IP 1.
Defining the graphics interface in terms of concepts the targeted user type
will understand.  (See Dialog Handler and Forms Package sections of
report).
.IP 2.
Developing a related knowledge base to validate user entries and make
any possible inferences.  (See Knowledge Handler section of report).
.IP 3.
Define the data requirements of the targeted application(s) to allow
the IFe to prepare data-sets in the required format.  (See Data Handler section of
report).
.IP 4.
Installing appraisal scripts which the IFE can use to control the
applications to which it will be front-ended.  (See Application Handler
section of report).
.SH
Defining the Graphics Interface
.PP
This is done by the creation of a set of forms, each one
corresponding to a meta-concept (see report).  Typically, this
will involve the identification of the concepts which will
comprise the interface, the gathering together of related concepts on to
a single form, the definition of each form using the IFe's form definition
syntax, the testing of each form and the installation of the form
definition file in the appropriate IFe directory.
.PP
For example the file @/ife/lib/uc/engineer/forms/bld_spec contains
the definition of the high level building specification form
of the engineering conceptualisation.  The file @/ife/lib/uc/initial/forms/master
contains the definition of the special "desk" form from which all other forms
are descended.  We suggest that you study these and the other forms of
directory @/ife/lib/uc/engineer/forms until you grasp the process.
Because all forms must have a desk, to test a new form without starting the IFe do:
.DS
cat @/ife/src/tmp/test_desk form_name | forms
.DE
.LP
where test_desk is an existing file containing the definition of a dummy desk
and form_name is the form definition file you wish to test (this could, for
example, be the file @/ife/lib/uc/engineer/forms/bld_spec.  Remember to
"source .iferc_c" or ". iferc_b" depending on your Shell.
.PP
For a complete listing of the form definition syntax, see 
section 13.2 of the enclosed report.
.PP
After a form has been proved, it can be installed in the
appropriate IFe directory.  For example, in the current "engineer"
conceptualisation this is directory @/ife/lib/uc/engineer/forms.
Alternatively, if you where creating a new conceptualisation, say
for an architect, the form definition would be installed in
@/ife/lib/uc/architect/forms.
.SH
Developing a Knowledge Base
.PP
The next stage is to establish a related knowledge base in Prolog.  While
this is not particularly easy, the IFe helps by offering several
pre-constructed Predicates (see report, section 13.1.3).  We suggest that you
study the entries of the file @/ife/lib/uc/engineer/kbs/bld_spec
which contains the predicates which are matched to the
graphic concepts of the form as defined by @/ife/lib/uc/engineer/forms/bld_spec.
.PP
Note that these knowledge bases fulfill four functions: the coordination 
of the dialogue (focusing and defocusing meta-concepts), the validation
of user entries, inferencing and the
building of the complete problem on the Blackboard.
.PP
Note also that the knowledge bases are structured 
to emulate the forms hierarchy: directories
@/ife/lib/uc/engineer/forms and @/ife/lib/uc/engineer/kbs for
example are matched.  Also, form concepts (field names) have
one or more matching Prolog predicates. 
These are used to check a user input, to supplement
this input by inference (for example, latitude and longitude
can be inferred from a place name), to assert `facts' (that is
store information in the knowledge base for later use),
to post data (user supplied or inferred) to the Blackboard, to
manipulate meta-concepts and to invoke and control applications.
.SH
Defining Application Data Requirements
.PP
Before the application to which the IFe is front-ended can be run, its
data requirements must be satisfied.  This involves:
.IP 1.
Ensuring that the problem description, as built on the Blackboard,
is complete.  Note that the Blackboard has its own syntax which
will allow you to examine its contents at any stage.
.IP 2.
Transforming the Blackboard information into the
form required by the targeted application(s).  There are two
ways to do this:
.RS
.IP -
By using the Data Handler to extract the Blackboard data
and format it as required.  This requires the use of a modified
Bourne Shell syntax to define the application requirements
to the Data Handler - see section 14 of the report.
.IP -
By requesting a `dump' of a particular area of the 
Blackboard.  This results in the Blackboard information
being transferred to file in "IFe" format.  For example, see
the predicate "???" of file @/ife/lib/uc/engineer/kbs/g_form_fill.
.SH
Controlling Applications
.PP
This can be done in one of two ways.  Either an application
can be attached to the Blackboard in the same manner as is
done for the Dialog, Knowledge, User, Appraisal, Data and Program
Handlers or, more typically, a performance assessment `script' is
developed and installed in directory @/ife/lib/uc/appraisals for
use by the Appraisal Handler.  An example of this script, which
should adhere to a Shell syntax, is given, for ESP, in the report.
.sp 3
.PP
Finally, we wish you luck in your attempts to apply the IFe.  At
any time in the future you may wish to visit Strathclyde to
undertake an implementation with our help - you would
be most welcome.
