David A. Johnson 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
 
David posting sounds like the basis for a white paper, suitable for a
roundtable at SHA or as a regular presentation. Please note that the
deadline for SHA paper and session submittals has been extended to June
23.
Jim Gibb
Lost Towns
Annapolis, MD