62
A. Voorrips
6
6. T
HE
AMOUNT
AND
KIND
OF
STANDARDIZATION
OF
DESCRIPTION
IN
AN
EIS
IS
COMPLETELY
DEPENDENT
ON
THE
RESEARCH
DESIGN
Standardization of description always has been a topic of discussion in
archaeology, and probably will be so forever. After all, each description is a
form of classification, and classification is one of the major themes in our
discipline. A description is a, sometimes simple, classification, because as-
signing an interpretation or a name to an archaeological event – like “this is
(the remnant of) a ditch”, “this is a Mousterian point”, “the size of the tem-
per of this sherd is coarse” – is the identification of a real-world phenom-
enon into one of the classes of an ideational classification. A classification
itself is “…an exhaustive set of mutually exclusive classes, where each class is
defined as a number of properties” (V
OORRIPS
1982), and the same should
hold true for a descriptive system.
There are no ‘natural’ classifications or descriptions. At the same time,
every archaeological project in COP, POP or ROP, on whatever scale, must
develop a consistent system for description and storage. The definition of a
classification or a descriptive system depends on the specific research goals,
on the overall amount of knowledge about the phenomena which need to be
identified into the system, on the convictions of the researcher, on the finan-
cial means, and, often, on the requirements of bureaucracy. It is interesting
that most ‘official’ systems, by which I mean systems that somehow are sup-
ported by governmental bodies, seem to exist in the museum world and the
world of rescue archaeology, the COP and the POP. Systems for excavations
and surveys that can said to belong to the ROP rarely, if ever, have been
forced into the use of general standards, and whenever this has happened it
invariably proved to be a bad policy. No two projects are exactly the same,
have exactly the same purposes, or have exactly the same type of data.
To communicate the ‘why’ of the decisions made about data descrip-
tion, be it to colleagues or to the public, it seems logical to make available in
some form or another the research design for the project, which absolutely
has to address this subject. The ‘how’ is communicated by the structures and
dictionaries (code books) of the databases created.
Some descriptive systems can be shared by different projects, or within
a large project by different sub-projects, but only on a very basic, most of the
time administrative level. A common setup for the registration of geographi-
cal location, municipality, primary geological, pedological and geomorpho-
logical categories is feasible, as is a common setup for the documentation of
the circumstances in which observations were made, like date, time, and
weather conditions – although the choice between classes like ‘hot’, ‘warm’,
and ‘cool’ for the registration of temperature is a rather subjective one. Also
a descriptive system for primary material categories – ceramics, glass, stone,
77
Electronic Information Systems in archaeology
7
obsidian, flint, bone, wood, textiles – can be shared, as it is independent
from research goals and real-world situations in that almost no special knowl-
edge is required to make the identification, and the distinction is at the basis
of nearly every archaeological enterprise.
In the end, it is a matter of resolution. A descriptive system that can be
shared by different projects or sub-projects has a resolution that is sufficiently
low to enable the users to unambiguously identify into it all the different
observations made. It is part of the research design to select the resolution
appropriate for the research goals, and to define descriptive systems consist-
ent with that resolution.
Of course, different levels of resolution for different kinds of observa-
tions can be defined within a research design, but one should be aware that
overall comparison of observations only can occur at the lowest level.
7. T
HE
USE
OF
A
WELL
-
DESIGNED
RELATIONAL
DATABASE
IN
AN
EIS
MAKES
DISCUSSIONS
ABOUT
DATA
ENCODING
OBSOLETE
It is sometimes disputed whether, when entering and storing data into
an EIS, codes – numeric, mnemonic, or whatever – are to be preferred over
more-or-less complete textual descriptions. When using a relational data-
base, such disputes are unnecessary. First, when the database is well-designed,
which means that its tables are in the third normal form, internal codes are
used to prevent unwanted duplication of information. These codes, whose
actual form is determined by the database designer, are the primary keys of
separate tables, which at least should contain meaningful textual labels and/
or mnemonics, but also can hold, or refer to, the complete textual descrip-
tions. Second, in well-designed input- and report forms, it can be up to the
user to decide what she/he wants to work with: code, mnemonic, textual
label or full textual description.
8. A G
EOGRAPHIC
I
NFORMATION
S
YSTEM
IS
NOT
NECESSARILY
THE
BEST
TOOL
FOR
THE
ENTRY
,
EDITING
AND
STORAGE
OF
SPATIAL
DATA
The spatial data collected in the course of an archaeological project
should be digitized and stored in the EIS as soon as possible. The major
reason for this is the correction of mistakes. The length of time and the
amount of effort required for correcting mistakes in a field situation is al-
ways an exponential function of the length of time between the making and
the detection of a mistake. While this is true for all kinds of data, the situa-
tion is even worse for spatial data. Correction may be impossible because in
the time between the making and the detection of the mistake the informa-
tion necessary to correct it has been destroyed by the ongoing fieldwork. In
58
A. Voorrips
8
order to be able to detect mistakes as soon as possible, digitizing the field
drawings is not enough. They must be entered into the EIS which allows the
archaeologist to combine the spatial information in various ways and to search
for inconsistencies.
Another reason for immediately incorporating spatial data into the EIS
is to allow the researcher to aggregate the data and to make decisions regard-
ing the course of the project based on the outcomes of such aggregations.
Whenever possible, preliminary outcomes of analyses of attribute data should
be linked to the spatial data in this process.
Digitizing is a tedious procedure even under the best circumstances.
Digitizing routines built into GISs tend not to be very user-friendly or sophis-
ticated (e.g., J
OHNSON
1996, chapter 9), and some GISs do not support digi-
tizing at all. An example is Idrisi, the purchase of which so far (1997) in-
cludes the separate digitizing package Tosca. For digitizing plans and draw-
ings of excavations, which are in a Cartesian coordinate system, packages
like AutoCAD work much more smoothly, and it is not too complicated to
transfer the digitized and cleaned data to a GIS. When dealing with spatial
data covering larger areas, e.g. topographic maps, which are registered in
some non-Cartesian coordinate system, the advantage of using the digitizing
routines provided by a GIS is that, in general, the data are stored right-away
as the accurate real-world coordinates.
An interesting development is the addition of GIS capacities to CAD
systems. The package AutoCAD Map, for example, combines the full power
of AutoCAD with all standard GIS functions, including the querying of at-
tribute data located in an external relational database, and a limited number
of analytical tools (Autodesk 1997). While not exactly cheap, such a combi-
nation makes the separate purchase of digitizing software and GIS software
unnecessary, and simplifies the overall design of the EIS.
9. A
RCHAEOLOGICAL
ANALYSIS
OFTEN
REQUIRES
SPECIAL
ANALYTICAL
TOOLS
WHICH
ARE
NOT
INCLUDED
IN
GENERAL
PROGRAM
PACKAGES
The archaeologist who wants to describe and analyze archaeological
data needs a fair knowledge of ‘standard’ statistical methods and familiarity
with at least one general statistical program package. The initial steps usually
involve uni- and bivariate analysis, but the characteristics of many of our
data demand an approach along the lines of exploratory data analysis (EDA),
a methodology which, by now, has been incorporated in many general statis-
tical packages. All such packages permit the import and export of data in a
variety of formats, and it is therefore not difficult to have an EIS communi-
cate with them.
There are a number of archaeological problems, however, for which
70
Electronic Information Systems in archaeology
9
methods of analysis have been developed which are not, or incompletely
covered by general packages. One of the first and probably best examples is
seriation, but also various forms of cluster analysis and methods for the evalu-
ation of the clusters ‘found’ by some analytical technique (e.g., K
INTIGH
1988;
W
HALLON
1990), methods for estimating the number of vessels represented
in a sample of sherds (O
RTON
, T
YERS
1992), etc., are not generally available.
To a large extent, this problem is being addressed by the Bonn Archaeo-
logical Statistics Package (BASP), which tries to collect special archaeological
analytical methods, to present them in a consistent manner, and to make
them available at low costs to the archaeological community (S
COLLAR
1997).
Like the general statistical packages, BASP recognizes a number of different
data-formats. There may be other methods which an archaeologist wants to
use in the context of a large project, however, which only exist as individual
programs or in small program packages. If these require specific input for-
mats and/or produces specifically formatted output, the information man-
ager of the project may want to add an interface to the EIS which can handle
the program’s demands.
One would expect that every GIS contains routines for a variety of
spatial analyses, but in practice the possibilities are restricted. Most spatial
analyses are performed using raster-data, so it is not surprising that, for ex-
ample, MapInfo has not much to offer in this respect. Idrisi, on the other
hand, contains a fair amount of rather sophisticated analytical tools. ArcInfo
has a module ArcGrid, which offers a number of raster-based analysis rou-
tines, but for specialized analytical work it is often linked to a special subset
of the general statistics package S+, named S+SpatialStats (SPLUS 1997).
In my opinion, archaeology has not done much yet in the area of devel-
oping analytical tools for spatial analysis, although there are exceptions (e.g.,
K
VAMME
1997; V
ERHAGEN
, M
C
G
LADE
1997). It might be worthwhile consider-
ing whether such tools can and should be incorporated in a package like
BASP.
10. A
N
EIS
IS
NEITHER
A
CATALOGUE
,
NOR
AN
ARCHIVE
After the completion of a project, the results need to be made public in
one form or another, and the collected information needs to be archived. It
may be tempting to consider the EIS of a project as the replacement of the
written monograph and/or catalogue and of the card files and drawings in
the archive. This, however, would be overrating and underrating the func-
tion of an EIS simultaneously.
It would be overrating, because the EIS itself is not the instrument by
which the information it contains gets interpreted, it only simplifies access to
the information, and can be used to present relations between different kinds
53
A. Voorrips
10
of information. It remains the task of the archaeologist, or other specialist,
to provide the reasoning to explain the information and its relationships. It
might be possible to add such reasoning and resulting interpretation to the
EIS in the form of a knowledge base, structured along the lines set out by J.-
C. Gardin (e.g., G
ARDIN
1987). Such an expanded EIS could indeed replace
other forms of publication, but at present this seems still too far-fetched to
me, however.
It would be underrating, because the capabilities of an EIS are much
more than is needed for an archive. After all, an archive is ‘only’ our last
resource for the recuperation of information that has been lost by some dis-
aster, and, while it of course must be well-ordered, the multitude of manners
in which data can be accessed in an EIS is not really functional in this respect.
At the same time, a well-structured EIS is an invaluable tool and re-
source for researchers, cataloguers, exhibition builders and archivists. It ena-
bles each of them to access with ease the data from their different points of
view and to extract what they need for their specific purposes.
11. D
ISCUSSION
OF
SOME
PROJECTS
WHICH
USE
EIS
AND
GIS
The six projects I have been asked to discuss – the short descriptions of
them follow this paper – can be divided into three types. Four of them:
‘Ateliers céramiques gallo-romains d’Argonne’ (1), ‘Archaeomedes’ (2), ‘Noord
Oostelijke Verbinding Betuwelijn’ (3), and ‘Landscape and habitation along
the Dutch Meuse-valley in the early Middle Ages’ (4b) concern themselves
solely with archaeology on the regional level. Project (1), (3) and (4b) are
typically POP: their aim is the production of maps of archaeological poten-
tial, to be used in CRM-type decision making processes for protecting the
archaeological heritage (1), (4b) and/or for the selection of sites to excavate
(3). Basically, the method utilized in (1) and (3), and probably also in (4b), is
a form of predictive modeling, with emphasis on environmental variables
like soils and/or geology, distance to water, etc. Project (2) is more ROP, and
its aim is not so much prediction as the investigation of the processes which
led to (changes in) settlement pattern, a pattern that is apparently already
known. Besides ‘standard’ analyses of distance to water and soil properties,
the study of road networks play a role in the analysis as well.
All four projects use standards for description that were developed
independently, and from the short overviews it is not clear whether or not
this is a successful approach.
It is interesting to note that projects (1) and (3), both of which started
in 1996 and use ArcInfo, as well as project (4b), which starts in 1995 and
uses MapInfo, make no mention of a separate RDBMS for storing the at-
tribute data, in contrast to project (2), which started in 1994 and uses GRASS
Documents you may be interested
Documents you may be interested
