Last edited 26 August 1997 by Steve Draper. Comments welcome ( email

Temporal and Situated Aspects of Data

Contents (click to jump to a section)

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

Details of the research project

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.

Outline of the key ideas

Temporal aspects of data

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.

Situated aspects of data: reasoning about variable validity

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.

Application domain: basic accountancy

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.)

Data modelling

We addressed considerable numbers of problems concerning temporal and situated issues, and developed and applied three central constructs:
  1. Time varying functions of money
  2. Status variables (user-defined enumerated types)
  3. 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.)

Diverse Techniques

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.

Summary of Achievements

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).