HISTARCH Archives

HISTORICAL ARCHAEOLOGY

HISTARCH@COMMUNITY.LSOFT.COM

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

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

Print Reply
Subject:
From:
Mary Ellin D'Agostino <[log in to unmask]>
Reply To:
HISTORICAL ARCHAEOLOGY <[log in to unmask]>
Date:
Tue, 10 Jun 1997 15:45:28 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (65 lines)
The new deadline for SHA papers and symposia in June 23.
 
At 06:03 PM 6/10/97 -0400, you wrote:
>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