Last edited 26 August 1997 by
Steve Draper.
Comments welcome ( email steve@psy.gla.ac.uk).
Temporal and Situated Aspects of Data
This is the main page for a research project. The research lies at an
intersection of HCI, data modelling (database research), and basic accountancy.
The aim was to advance ideas in data modelling by applying a strategy more
usual in HCI: pick a small application domain, study actual user requirements,
bring in techniques from many places to build superior computational support
for that domain, generalise especially about the data modelling techniques.
That is, it was an application-centered approach, and one that focussed on
utility to actual users.
The key ideas are outlined below, and described more fully in the papers.
This "page" (web document) includes below
a summary of the key ideas,
and
and a summary of achievements.
Grant application
Paper 1 "Implementing advanced support in a basic accounting application"
[Working title; in preparation] This paper will focus on the actual
implementation.
Paper 2 "An advanced data model for basic accountancy" [Working title; in
preparation] This paper will focus on the application domain, and how our work
solves the issues this raises compared to previous approaches.
Paper 3 "Modelling temporal and status aspects of data" [Working title; in
preparation] This paper will focus on the data modelling constructs, and their
scope.
Final report
This research project was funded by
EPSRC
(grant GR/K25021) for about
£86,000 and ran April 1995 - May 1997. The funding mainly paid for
2 years of an R.A., Sheila Rock. Three associated M.Sc. projects were also
done by Neil Munro, Chris Snazell, and Roy Stuart in May-Sept. 1996.
Stephen W. Draper,
Richard Cooper
Departments of Psychology
and Computing Science
University of Glasgow
Glasgow G12 8QQ U.K.
Temporal issues occur in many ways in this domain: time stamps for data
entry actions, time in the world the database describes, both past and future
(in plans), the sequence of states many objects move through (e.g. an invoice
being sent, authorised, paid etc.), and the time periods (e.g. monthly, for the
tax year, for a project year) a user specifies when requesting a report or view
of the data.
The data in a database depends for its validity on the human procedures
that relate it to the real world it is describing (modelling). Putting a
number or string into a database doesn't make it true: that relationship (of
truth, validity, correspondence) depends on the human procedures that create,
or fail to create, a systematic correspondence. Thus to a greater or lesser
extent the meaning of data is "situated", dependent on context. This validity
varies in quality. In our application domain, this is not only because of user
errors, but because plans have to deal with lesser certainty than past actions,
and because time delays in actions (such as a supplier paying in your cheque)
impose delays beyond the user's control. In our work, we store and use
explicit information about these relationships of "situatedness" and their
effect on degrees of validity.
By basic accountancy we mean managing a personal bank account, the
budget for a small research grant, or for a small department or company with
2-3 people. A key insight into this domain is that the central user task is
not recording payments, nor doing arithmetic calculations, but comparing actual
expenditure to date with planned expenditure and using that to make decisions
(revise plans). That is comparison and plan revision are the central
activities, not keeping records or producing reports. Another key notion is
that most of the objects the user deals with evolve through time: they are not
simple money amounts, but things that not only persist but evolve e.g. a cheque
begins as a proposed expenditure, gets issued, disappears towards the
recipient, eventually (but unpredictably) reappears as a withdrawal from the
account. (See paper 2 for more.)
We addressed considerable numbers of problems concerning temporal and
situated issues, and developed and applied three central constructs:
- Time varying functions of money
- Status variables (user-defined enumerated types)
- A formula DAG: a network (a Directed Acyclic Graph) representing the
relationships of the formulae for calculating totals and subtotals.
(See paper 3 for more.)
Reason Maintainence Systems from Artificial Intelligence to provide
"explanations".
Fisheye views, from the HCI literature.
The view that there are two distinct approaches to modelling time, and both are
necessary: qualitative (order relations, but no durations of specified
magnitude), and quantitative.
For more details, see our papers.
This project aimed to study a number of problems in data modelling,
particularly those associated with the treatment of time and with varying
validity in the data. The strategy was to use one particular problem domain as
the focus and attempt to solve as many problems as possible that occurred in
that domain; and the domain chosen was that of simple accountancy: for
instance managing a personal bank account, the budget for a research project,
or the accounts of a small company.
Interviews with experienced users in our domain produced a number of insights
into the domain, the most important of which is that users'central task here is
not storing a record of past events, nor doing arithmetic, but managing an
account by comparing current data against plans for the same objects (e.g.
budget subheadings).
We developed a data model based on three types of object: time varying
functions of money, status variables, and an explicit representation of the
network (DAG) of formulae linking money items. We can show how these are
sufficient to solve many issues in our problem domain, supporting facilities
useful to users and far in advance of what can be accomplished by spreadsheets
or indeed many complex accounting packages. We have implemented a program
incorporating these objects and demonstrating their application to accounting,
and how they solve in this particular domain a variety of data modelling
problems of wide interest.
For instance, plans and historical data use the same structure (represented in
the DAG), with alternative instances of the nodes which can be compared.
Furthermore an object representing, for example, a cheque may have a status
variable allowing its state to progress through the set: written, signed,
sent, presented (paid in) by the payee, cleared from the payer's account. Such
variables allow both cleared-funds (the bank's view) and commitment accounts
(how much you really have free to spend) to be calculated from the same data
set. By representing not sums of money but objects like cheques that evolve in
time, a single representation supports multiple views which the user selects by
specifying the time the view is to represent and status values to filter
objects (e.g. view only paid items, or view all commitments in the pipeline).