Response to "Some generic issues to consider"

Fri May 12 16:33:37 2000

A comment by Diane E. Lane about

Some generic issues to consider

by Jonathan C. Matti

Having finished being occupied much of the last two weeks with 
our Publishing2000 conference of almost 300 people, I can 
finally address these generic issues. There have already been
so many good answers posted though that I doubt the following
are original!

(a)  Can we develop slt standards on continent-wide basis?

Maybe!  As someone else in this forum pointed out, we at the USGS
have been fairly strict about adhering to standards for
stratigraphic nomenclature.  It is a matter of deciding on
the standards and making a committment to them.  The committment
is a matter of putting the needs of the organization and the
audience ahead of one's personal idiosyncracies, though.

(b) Can we do this at a level deeper than "granite vs. basalt"?

If the answer to (a) is "maybe," I guess I can't say yes here,
but maybe.  I think that the need for committment means that
the standard cannot be too fine-grained, but if too coarse it
won't be worth doing.

(c)  What role do regional geologic differences and mapping
traditions play in the development of slt standards?

I think that we should take advantage of these differences and
traditions to survey the variety that is out there and choose 
what seems useful to most of us.

(d)  One standard or multiple ones?

Possibly one standard per sub-discipline.  We need to inventory
what standards are used for what and then settle on the best or
most acceptable.  This would result in a library of standards.

(e)  What kinds of scientific queries should be supported by standard
terminologies at the national, regional, and local levels,
and should a single slt structure support each and all levels.

I really don't see why one would want to make a distinction
here.  The inquirer probably won't make such a distinction.
Perhaps I am misunderstanding the question.

(f)  To what audiences will the data-model science language
speak on behalf of our various agencies? More than one

Both technical and non-technical!  By two languages, I wonder
if you mean that a map unit coded very specifically as a rock
type detectable only under the microscope might also be coded
by a more general field name.  Actually, I think this could
be a good idea.  The database could contain information that
the general term x is used to refer to more specific terms y and z.

(g)  What does each map producing agency expect to query?

See 20 questions.

(h)  What kind of geologic information will the typical geologist
expect to put INTO the data model and retrieve FROM it?

Lithology (composition, texture, color, weathering, alteration),
contact relationships, bedding charactistics, paleontogoical
data, ages, structural features, generations of structures,
 facies relationships,thickness of units, geomorphic characteristics,
stratigraphic relationships and correlation, geographic locations,
sample locality information, mine and prospect data, mineral resource
potential.  A look through some typical publications should
provide even more information about what is being reported.

(i)  What kinds of interdisciplinary science should be inforporated
into the data model science language?  

I hope we have some representatives for those disciplines here
because they definitely should be included.  Many map products
include information about geophysical data and geochemical data
especially, in addition to meat-and-potatoes geologic data.

(j)  What kinds of feature-level locational-accuracy issues
should be address by our science language?

As I said in another post, the USGS has standards for what we
mean by "approximate" and "inferred" as those terms are
applied to lines on a map.  Yes, these terms and their
definitions need to be addessed in the model.

(k)  What kinds of feature-level scientific-confidence issues
should be address by our science language?

The current metadata standard provides for these statements.

(l)  Feature-level data-origination issues?

Ditto for the metadata, I think.

Context of this discussion

This page is part of a discussion of Some generic issues to consider:

Further discussion of Response to "Some generic issues to consider" (this page):

(No comments about this document have been posted.)