About Ontological Setch Models (OSMs)
An excerpt from Blandford
and Green (1998)
An Ontological Sketch Model (OSM) describes the domain and device
from an individual user's perspective. It is a user-centred model,
not an abstract domain model. For example, if we were analysing a
spreadsheet program from the perspective of a lecturer who wanted to
use it for collating students' marks, we would want to consider
entities such as marks and marking schemes, and how well they can be
represented and worked with in the spreadsheet, whereas if we were
considering the same spreadsheet program for use in a small business,
we would need to consider product types and costs, bills and
An OSM describes:
- the user's view of domain;
- the view of the domain that might be inferred solely from the
device, referred to for short as the device's view of the
- the user's view of the world of the device;
- the interface's representation of the device's operations and
An OSM is not a performance model. It is a 'cognitive competence'
model, in the same sense as that used by Payne and Green (1986); it
describes what a user needs to know, not necessarily what that user
does nor the cognitive processes required in the doing.
An OSM comprises:
- entities which possess attributes and may be created or
- attributes of entities. Attributes cannot exist in isolation
so they cannot be created or deleted; they can only be
- actions that change the state: creating or deleting an entity,
or changing an attribute value.
- relations and constraints that hold between entities,
attributes and actions.
(It is well-known in data-modelling that, on occasion, the choice
between representing a concept as an entity or as an attribute is
hard to make, but we have no reason to think that the problem will be
crucial in OSM.)
Entities and attributes may be relevant to the domain of
application or just to the device, and they may be accessible to the
user only, device only, or shared. There are four main values:
- user-private: a concept that part of the user's domain
model, but not directly represented in the device. For example,
the user may be making an overhead transparency. That concept is
not explicitly represented in a conventional word processor,
although it is explicit in a presentation package.
- shared/domain: a concept that is explicitly represented
within the device, that is also domain-relevant, and is also known
to the user. For example, as represented in a conventional word
processor, the concept of "word" is shared, whereas the concept of
"subordinate clause" is user-private. (Note: advanced packages
often explicitly represent expert-level domain concepts that are
unknown to some users. For convenience we ignore these.)
- shared/device: a concept that is explicitly represented
within the device, is not part of the user's domain model, but
which the user has to know about to be able to manipulate the
domain concepts effectively. For most application domains, the
concept of a 'file' is shared/device: domain objects, such as
graphics or stories or programs, are stored in files, which must
be copied, deleted, renamed, etc.
- device-private: a concept from the device world that
the user has to know about, but cannot change easily and may not
even be able to see, such as the file store. It is possible for an
entity and its attributes to have different properties: for
example, a shared/domain entity may have some shared/domain
attributes and some user-private ones. Also, for a tool such as a
shared calendar there can be other values &emdash; such as an
attribute that is private to another user.
Observe that all communication from the user to the device takes
place through the two classes of shared concept.
We are concerned with four types of relationships and
constraints, because they are used in reasoning about particular
- consists-of: this relationship holds between entities,
asserting that one entity consists-of others. For example, a
paragraph consists-of sentences, and a sentence consists-of
- affects: this relationship holds between actions and
entities or attributes, and is concerned with possible side
effects of actions. Side effects can often cause difficulties, as
they may not be noticed by users.
- domain-constrains: this expresses a domain constraint
that might apply, and that the user might have to work to satisfy.
In the case study of time management discussed below, an obvious
domain constraint is that one individual can only be in one place
at a time.
- device-constrains: very occasionally, we come across
situations where the device itself imposes a constraint that can
force users to do more work; for example a floppy disk has a
maximum capacity, and this constrains the numbers and sizes of
files that can be stored on it. This type of constraint is less
common, but forces the user to find "work arounds".
Four types of activity are required when constructing an OSM.
These may be interleaved ad lib; they are not successive stages,
although the tendency is to perform them in something approximating
to the following order (with the exception of misfit analysis, which
generally takes place in parallel with other activities).
- Shared description: Modelling starts with the obvious
&emdash; describing the entities that are explicitly represented
in the device, together with any intuitively obvious user-private
entities. For an existing product, this description can be
constructed by extracting information from the user manual, with
or without reference to the device itself; for a proposed product,
it is derived from the specification.
- Adding domain information: In a few cases, there will
be enough information in the user manual, or the analyst will be
familiar enough with the domain, to construct an adequate OSM
without extra consideration of the domain. In practice, this is
rare, and a much more thorough and useful analysis can be achieved
by eliciting knowledge from users. Here, the aim is to gather an
account from users of how they actually use the device and what
domain concepts and relationships they are working with. This part
of the analysis should also consider the context of usage, and
what other tools or devices relate to the device of interest.
- Expanding the device description: While the core of OSM
analysis focuses on the ontology, it is sometimes useful to unpack
the device description, describing conceptual actions in terms of
the interface objects (such as buttons and menu items) that are
- Misfit analysis: As analysts are constructing this
description &emdash; or when they have completed an initial
description &emdash; they can be assessing it for possible
misfits. A misfit is any aspect of the OSM that is likely to cause
a user difficulties. The biggest causes of such difficulty are
user-private and device-private entities that the user has to work
with and manipulate through the device.