HISTARCH Archives

HISTORICAL ARCHAEOLOGY

HISTARCH@COMMUNITY.LSOFT.COM

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mime-Version:
1.0
Sender:
HISTORICAL ARCHAEOLOGY <[log in to unmask]>
Subject:
From:
"David A. Johnson" <[log in to unmask]>
Date:
Tue, 10 Jun 1997 18:03:59 -0400
In-Reply-To:
Content-Type:
text/plain; charset="us-ascii"
Reply-To:
HISTORICAL ARCHAEOLOGY <[log in to unmask]>
Parts/Attachments:
text/plain (60 lines)
Jim, Mary, et al.:
 
I think the deadline for SHA entries passed June 1, but there may be some
dispensations for special circumstances.
 
I think Mary has hit the nail on the head with her observations concerning
ODBC. Translating, reading, and manipulating various flat and related files
is what database management is all about. The differences between actual
database programs is analgous to the differences between types of
automobiles: whether you prefer to use FoxPro or Filemaker is essentially
the same as if you prefer a Chevy to a Ford. They do pretty much the same
things, but the bells and whistles are in slightly different places. And
they both run on the same gas... or, in this instance, data.
 
Really, the same can be said about CAD programs as well, which brings us to
the topic of GIS architecture.  GIS mavens or not, all archaeologists are
concerned with provenience, and provenience is the spacial relationship
between objects in a given context. When you get past all the techno-double
talk, that's the crux of a GIS. In its physical state, an archaeological
site is a GIS: all GIS shell programs do is mesh alpha-numeric data files
and visual datafiles via a site map.
 
Standardization, while a seemingly nice idea from a conformist perspective,
seems unlikely and largely unnecessary, in my opinion. All archaeological
sites are unique, presenting varried and unexpected challenges in all
aspects of investigation, excavation, and analysis given certain
constraints of budget, context, situation, level of preservation, etc.
These factors must be prioritized according to the research design of the
principal investigator. The collection and management of data is perhaps
the primary consideration of any research design.
 
As professional archaeologists, certain creative processes should have been
cultivated during our graduate studies that enable us to design research
programs to answer the specific questions that initially motivated us to
excavation in the first place. Standardization of data management seems
like a step towards a cookie-cutter methodology that will eventually lead
to a lowest common denominator situation. While it would seem that
information would be more accessible to what ever demographic the masses
may happen to be at the moment, it seems obvious to me that the solution in
this envelope will be loss of quality and also loss of precious,
site-specific data as the two curves merge.
 
I vote that we allow capitalism to run its course here and let the software
industry continue to market their programs with the ever broadening data
compatability issue as the carrot. Such technology is no longer in its
infancy, but is now creatively toddling around and experimenting. We should
watch it and nurture it, but let it grow without short-sighted
restrictions. Data is data, we'll be able to get it from one place to
another... don't worry about that. There's a reason why you have to learn
other languages during your studies, so you can communicate with the
international community of scholars. French, German, Spanish, Italian...
Foxpro, Paradox, Filemaker, Access... it really doesn't matter--
information is information.
 
 
 
David Johnson
Institute of Maritime History
http://www.gate.net/~imh

ATOM RSS1 RSS2