Digital Mapping Techniques '04— Workshop Proceedings
U.S. Geological Survey Open-File Report 2004–1451

Implementing NADM C1 for the National Geologic Map Database

By Steve Richard,¹ Jon Craigue,² and Dave Soller³

BACKGROUND

This report is a summary of progress on implementing the NADM C1 conceptual model (NADMSC, 2004) as a production-scale prototype for a U.S. Geological Survey –Association of American State Geologists (AASG) National Geologic Map Database (NGMDB, Soller and Berg, 2003). The implementation uses standard relational database technology, and is designed to function as an ESRI geodatabase or as a standalone, non-geographic database. The implementation is designed for depth of knowledge representation and flexibility, not for simplicity or performance. The NGMDB will be a data archive for geoscience information, with provision to record alternative interpretations, evolving terminology and science paradigm, uncertainty, incomplete knowledge, and metadata pertaining to data acquisition, processing, and automation. The objective is integration of geologic data from published maps by different authors at different scales, as well as newly acquired field data.

In more concrete terms, the objective of the project is to design and implement a scalable database for storing geologic descriptions, particularly those related to geologic maps (e.g., geologic units, lithology, and geologic structures), as well as the location and geometry of mappable features. Development has been ongoing for several years. The development of an underlying conceptual model and science vocabulary has taken place in a community arena (the North American Data Model Steering Committee, http://nadm-geo.org/) in order to achieve some level of standardization. Physical implementation has been guided by discussions with mappers in the U.S. National Cooperative Geologic Mapping Program. Implementation of an enterprise-scalable database requires that we address business rules for security, ownership, and authority of data contained in the database. Integration of geologic data from different authors will require the maintenance of documentation (metadata) for each data object, such that the original source of information can be determined. Because it is critical for users to get data into and out of the database, considerable effort is being spent to develop a software interface to the NGMDB prototype database

NADM MODEL

Our underlying framework for information system development is the NADM C1 conceptual model(NADMSC, 2004). This model specifies the basic kinds of geologic things of interest and how they are described. It does not specify a database implementation. Table 1 summarizes significant concepts from the NADM C1 model that are used in the NGMDB implementation.

IMPLEMENTATION

Issues-Extensions in NGMDB Model

Because the NADM C1 model is conceptual, it does not specify the details that must be implemented in a database. The following discussion lists some of the property extensions and implementation decisions that were made in developing the NGMDB prototype.

Numerical measured quantities may be represented by specifying a typical value, for example when an analysis requires a single ‘best’ value for the quantity. Alternatively, minimum and maximum values may be used to specify bounds on an uncertainty envelope (either symmetric or asymmetric about the typical value), or the upper and lower bounds on a value range. Measurement units are specified from a standard set of terms. A quantity type term in the database indicates whether the value is an average with standard deviation bounds, a range value, a value with asymmetric uncertainty bounds, or a single value with no uncertainty estimate.

The NADM C1 model does not provide for schema representing basic field observation locations for newly acquired field data. The NGMDB model has an abstract ObservationLocation feature type that is the supertype for field data acquisition sites—Station for point data, and Section for observations along a track (line) and AreaOfInterest for observations pertaining to an area. These model elements are based on the XMML site and specimen model by Simon Cox (2004, https://www.seegrid.csiro.au/twiki/bin/view/Xmml/SitesAndSpecimens/). An observation location may have one or more associated structure observations (measured orientations of structures), text descriptions, images (sketch, photo), or samples.

Boreholes are not accounted for by the NADM C1 model. NGMDB implements a simple model for borehole data based on XMML, in which a borehole is modeled as a subtype of Section, a kind of observation location. The borehole collar point feature represents the XYZ location of the intersection of a borehole with the Earth surface. A borehole may be reentered with new boreholes drilled as splays from an existing borehole. Thus, one or more boreholes may be associated with a single borehole collar. Each borehole may be associated with an ordered collection of borehole segments that constitute an XMML interval log. Each borehole segment may have associated structure observations, text descriptions, images, or samples.

The Morphology property of GeologicUnit (see Plate 3, NADMSC, 2004) is implemented through links to a standard list of geologic unit morphology terms, and in the case of lithostratigraphic units, to a numerical value for thickness. The GeometricDescription property of GeologicUnit in NADM C1 has been expanded for lithostratigraphic (bedded) units to describe bedding style and bedding pattern with standard terms, and bedding thickness with either a standard term or a numerical thickness value. After discussion with geologists who are mapping surficial deposits (mostly in the arid southwest of North America), the descriptive properties associated with surficial geologic units were expanded to include terms for degree of dissection, surface armoring (pavement development), soil development, clast weathering character and style, and varnish development. Additional properties are probably necessary to fully describe surficial deposits in glacial, polar, temperate, and tropical environments.

The NADM particle geometry description (see Plate 2, NADMSC, 2004) has been implemented with additional properties grouped as particle shape and particle size descriptions. Particle shape properties include roundness, form, and degree of crystal face development. Particle size description may include quantitative specification of particle diameter (mean, median, maximum, etc.), as well as terms specifying sorting, particle size (diameter), and particle size range.

The NGMDB implementation allows multiple values to be assigned for many properties, through an attribute relationship correlation table. This mechanism allows qualifiers and metadata to be associated with each attribute value assignment. Qualifiers provide information on frequency that a value is observed, confidence in value assignment, and intensity of development of an attribute. Ability to assign a frequency to some value allows the expression of negation, i.e., the fact that a particular value is not allowed. The ability to express confidence allows representation of specific, estimated or guessed property values at low confidence, and less specific generalized property values at higher confidence. Metadata associated with attribute value assignment can record the measurement procedure, or more detail on evidence for assigning a value (e.g., why the environment attribute is assigned as ‘fluvial’).

In a distributed information system, data from many sources may be integrated for a single analysis, and evaluation or interpretation of results will require knowledge of the provenance of individual units of data. The feature level metadata (tracking) implemented in this database allows for the recording of links to citations for published sources, the person, organization, and project responsible for original data acquisition, and the processing steps involved in automating the information.

NGMDB Implementation Framework

Based on previous experience with geologic map database design and implementation, especially the evolution of implementations based on the Johnson et al. (1998) model version 4.3 (see http://nadm-geo.org/ for examples listed under “Data Model Design Team”), it became apparent that a widely applicable geoscience database implementation must be adaptable to evolving data requirements. In order to provide the flexibility and expressiveness required for a widely applicable geoscience information system, we are implementing a relatively abstract logical model that allows different users to configure the data structure to include entities and properties appropriate for their requirements. The underlying goal is to code the semantics of the data into the database to the maximum extent possible, as opposed to structurally incorporating semantics into data design. This requires including vocabularies that define terminology in the data, and encoding the data schema in the data. The most extreme version of such a design results in a one-table database (see design of the Protégé knowledge tool database backend, http://protege.stanford.edu/doc/design/jdbc_backend.html). This results in maximum flexibility and minimum comprehensibility of the raw data store. The NGMDB design documented in this paper includes a relatively small number of physical ‘base tables’ for standard kinds of geologic descriptions, and a standardized mechanism for extending these with properties of interest for a particular application.

The implementation builds on Arizona Geological Survey (AZGS) designs documented in Richard (2003) and Richard and Orr (2001), the Canadian Cordlink 5.2 design (Brodaric et al., 1999), and previous NGMDB prototype designs (Soller et al., 2002; Brodaric and Hastings, 2001, 2002). The design has been influenced by the Ontology Web Language (OWL), analysis of the data structure used by the LegendBurster tool (http://www.georeferenceonline.com/LegendBurster/), and various models proposed as part of the International Organization for Standardization Geographic Information/Geomatics project (ISO TC211, http://www.isotc211.org/), especially the Geography Markup Language (GML, Cox et al., 2004) and Exploration and Mining Markup Language (XMML, https://www.seegrid.csiro.au/twiki/bin/view/Xmml/WebHome/).

The NGMDB implementation of the NADM C1 conceptual model revolves around three logical elements—Vocabularies, Description Schema, and Data Instance (Figure 1). Vocabularies are collections of terms and text definitions, analogous to GML Dictionary and Definitions (Cox et al., 2004). A Vocabulary constitutes an enumeration of things thought to exist in a domain or of possible values for properties. A Vocabulary also may include relationships between the represented concepts (terms), in particular a ‘kind of’ or subsumption hierarchy where appropriate. A mature vocabulary also might include thesaurus type relationships, to allow users to map terms between different vocabularies, and search for similar or related terms within a vocabulary. The Description Schema is an explicit representation of the implemented data model that is part of a dataset; analogous to an XML schema contained in a .xsd document. The Description Schema represents the data model, including kinds of objects, their properties, relationships between objects, and rules that determine valid database conditions. Data Instances are valid descriptions based on the Description Schema, each of which specifies attribute values for some entity of interest.

Figure 1. Logical framework for NGMDB implementation.

Vocabulary Tables

Vocabulary tables contain collections of terms with associated text scope notes or definitions. If appropriate, the terms may be structured with parent-child links in the vocabulary table to define a tree hierarchy. The vocabulary defines a collection of shared concepts that may be used to classify observations, or to specify attribute values. The terms in the vocabularies are used to populate pick lists in the user interface that is under development. Each vocabulary table includes a unique identifier for each concept, the preferred name (the term) by which the concept is communicated between human users, a text notes to convey to users the meaning of the concept, and a link to a tracking record that supplies information on the source of the term and its definition.

Table 2 is a summary of the vocabulary tables implemented for the NGMDB prototype. Because the structure of each of these tables is the same, they could all be implemented in a single physical table. They have been implemented in separate tables to make them more portable – different vocabularies will be useful in different environments depending on the audience and the purpose for the geologic data. The geologic unit vocabulary will include names for geologic units that are found in the area of interest, and the terms required in the standard lithology and mineral vocabularies are determined by the kinds of Earth materials that are found. Different geologic time scales will require different vocabularies of stratigraphic eras. Richard et al. (2003) discuss some issues with integrating data using different vocabularies. The basic rule is that data integration is simplest if everyone is using the same vocabulary. Conflation of data using different vocabularies will require a thesaurus that matches terms in one vocabulary with those in the other, and may involve information loss.

The science language vocabulary is really a collection of many vocabularies that enumerate kinds of phenomena, or terminological values that may be used to quantify properties. It includes vocabularies for kinds of geologic structures, geologic process, geologic units, physical properties and geologic relationships. Examples of included property value vocabularies include Earth Material genesis terms, particle size terms, particle sorting terms, particle form terms, geologic unit rank terms, consolidation degree terms, and metamorphic grade terms.

Data Schema

The NGMDB implementation includes tables that explicitly store the data schema (Figures 1, 2, and 3). This approach is similar to that used for XML documents, which have an associated schema document (xsd file) that specifies the structure of data instances, and is similar to the schema information recorded by the internal tables (‘GDB_’ tables) in ESRI geodatabases. The schema identifies a collection of entities (ESRI ‘object classes’), a collection of properties (the property vocabulary mentioned above), associates each entity with a set of properties, and specifies a value domain and cardinality for the property in that entity. In a standard relational database implementation, each entity would be a physical table, each property associated with the entity would be a field in the table, and for properties that are specified using terms the list of terms used to populate the field might be a separate table. In the NGMDB implementation, each entity is implemented by a physical table in which each row corresponds to an instance of the entity. Attribute values are associated with entity instances through AttributeRelationship instances. Each AttributeRelationship instance (row in the AttributeRelationship table) correlates an entity instance with an attribute and a value for that attribute (Figure 2), along with observation-related metadata. Attribute values are specified by value specification instances that may be a science language term, measured quantity instance, text description, or instance of another entity. The ValueEntity attribute in the AttributeRelationship table specifies the kind of value specification used.

Figure 2. Diagram showing connection of logical attributes to a description through the AttributeRelationship correlation table. The AttributeRelationship table has attributes that specify the kind of attribute, and the entity type that contains the value specification. Observation-related metadata fields in AttributeRelationship are not shown.

The Data Schema tables identify the base table associated with each entity, enumerate the properties associated with each entity, indicate how each property is specified, and specify the domain associated with each property in each entity (Figure 2, Table 3). Data Schema tables all have names with the prefix ‘Entity’.

Figure 3. Data schema tables. Lines in the diagram represent foreign key relationships between tables. The field names at the end of lines adjacent to the table boxes indicate the field that is the key in the table at that end of the relationship. The EntityPropertyDomainNodeList table is used to enumerate data instances available in the pick list for a particular attribute. The SelectedVocabularyNodeSysGUID links are to any table that contains data objects that may be made available in pick lists; most commonly these will be vocabulary tables—ScienceLanguage, StandardLithology, StandardMineral. Science language link is shown here for example. The VocabularyNodeEntityGUID identifies the table that contains the referenced node.

Data Instances

Data instances are implemented by a row in a base table, possibly with additional attributes associated through relationship table correlations. In the simplest case, the base table implements a single entity specified in the Data Schema. In more complex cases, multiple, related entities may be implemented in a single base table (similar to ‘object subtypes’ in ESRI geodatabase); entities that are implemented through a shared base table are referred to as logical entities. Base tables that implement logical entities include an attribute that specifies the entity type for each data instance (row) in the table. The structure of a data instance is specified by the associated entity type defined in the Data Schema.

Each Data Instance is a collection of attributes assigned to some object of interest represented in the database. The Data Instance has an associated Entity specification in the data schema tables that dictates what attributes are associated with instances of the entity, and how values for these attributes are specified. Standard, physical tables in a relational database structurally associate a data instance (row) with a collection of single-valued (0..1, depending on cardinality defined in Data Schema) attributes, each specified in a field in the table. Values may be assigned directly by numbers or strings in the field, or the field may contain a foreign key to a more complex value specification. Because the data schema is implemented directly in the table structure, entities implemented as physical tables do not require an explicit link to their entity type.

The base table for a group of logical entities (e.g. GeologicUnitDescription) contains single-valued attributes that are required by all of the logical entities implemented through that base table. The distinct logical entities implemented by a single table may have different AttributeRelationship associations, attribute domains, or cardinality constraints. Attribute values assigned through AttributeRelationship instances may have 0 to many values. Even a single-valued property may be specified using multiple AttributeRelationship instances with different observation properties. For instance a particular geologic unit may be assigned a Proterozoic age with high confidence based on stratigraphic relationship, and a middle Proterozoic age (more specific within the value range) with low confidence based on lithologic correlation. Each logical entity instance must have as one of its attributes a link to the entity definition that specifies its structure.

Base data tables are discussed in groups based on their content and use. The groups include value specification tables, GIS feature classes, section location tables, sample table, description tables, and relationship tables. The value specification tables represent observations of some individual property value specified by a numeric measurement, text, an image, or geometry. GIS feature classes represent located geographic data. Section location tables have to do with locations along observation tracks—boreholes, traverses, flightlines. The sample table catalogs physical specimens. Description tables are the base tables for standardized description of geologic objects, including EarthMaterialDescription, Geologic-UnitDescription, GeologicAge, and GeologicStructure-Description. Relationship tables are correlation tables used to establish semantic relationships between other data instances, and include several specialized tables with different relationship properties.

Value specification tables

Value specification tables record individual property values specified by a numeric measurement, text, an image, or geometry. Table 4 lists the various value specification tables. These tables are the leaf nodes in description tree structures that specify the basic units of observation and description—numbers, text, pictures, locations. Vocabulary terms that specify property values may also be viewed as leaf nodes in description tree structures, but they are shared by many descriptions. Instances in the value specification tables are unique to some particular description or location context, and if that context object is removed from the database, the value specification become useless and should be removed as well.

GIS feature classes

Table 5 summarizes ESRI geodatabase feature classes used to specify location in the NGMDB implementation. All spatial data tables include fields to specify a default text label and symbol to use in map displays if no other symbolization is specified. This is to simplify the rapid display of spatial data. GeologicSurfaceTrace and GeologicUnitOutcrop are line and polygon feature classes whose locations represent observable geologic phenomena in or on the Earth. ProjectExtent is a simple polygon feature class used to define the area of interest for a project. By defining an area of interest, a spatial search can be done to locate existing data that may be of use for a project—for instance, which geologic units have been mapped in the area. AreaOfInterest, SectionLine, and Station are polygon, line, and point feature classes used to define extents associated with observations in the sense of GML Observation and Measurement (Cox et al., 2004). They represent features that are located based on where observations are made, and do not (inherently) represent the location of observable phenomena.

Section location tables

In a variety of situations, observations are located relative to a section line—for example, locations in a borehole are typically specified in length from the top of the hole. These types of locations are treated specially in the NGMDB implementation (Table 6). Although borehole, traverse, and flightline (all kinds of sections) might be considered feature classes, the actual geometry of a borehole can not reliably be represented by the 2-D geometry available in the ESRI geodatabase structure. Each type of section is related to a SectionLine feature (Table 5) that represents the projection of the 3-D section onto a map horizon (typically the Earth’s surface). Coordinates of locations along a section line are not simply related, in general, to length along the projected line. Thus, each kind of section includes a property that specifies the origin and metric for the coordinate reference system used to specify intervals and intercepts in that section. For instance, in a borehole the coordinate system typically is measured in linear length units downward from the ground surface or kelly bushing. In a measured stratigraphic section, the metric is thickness of strata traversed from the base of the section. A section interval is a location specification based on a start and end coordinate along a section line using the reference system defined for that section line. Section intercepts are points located by a single coordinate along a section. To convert SectionInterval and SectionIntercept locations to a true three-dimensional location, the 3-D geometry of the section must be known. For example, knowing that a sample is from 10,205 feet down in a bore hole does not fully locate the sample unless the geometry of the bore hole is known—if the hole is gently inclined, the surface projection of the sample location may fall at a significant distance from the borehole collar location.

Sample table

The sample table contains data instances that represent particular, identifiable masses of material. In this sense, they are similar to geologic units (as defined by NADM C1). The difference is that a geologic unit represents a mappable body of material—its location in the Earth is part of its identity, whereas a sample is from some location, but its identity is based on the collector’s act of identifying that material by writing a number on it or putting it in a container. Many sorts of analytical data (e.g. chemical analyses, isotopic age dates) are associated with particular samples.

Description tables

Description tables (Table 7) contain data instances that are the base instances for complex descriptions of geologic units, Earth materials, structures and geologic age interpretations. Each description table listed in Table 7 includes a collection of attributes common to all of the description tables, along with attributes that are common to all descriptions of the particular type represented by that table.

Attributes common to all description tables specify the purpose and context (spatial and non-spatial) of the description, the described concept, and the structure of the description (see GenericDescription in Appendix Table 33). The description purpose attribute (DescriptionPurposeTermGUID) makes the intended function of a description explicit, e.g., default description, necessary property description, identifying property description, or instance description. The context specifies the domain within which the description is valid for the stated purpose. This domain may be spatial—some particular region of the Earth, or it may be human—e.g., a particular project or person, some organization, or some published authority (e.g. the Glossary of Geology. . .). These properties are included to solve the problem of distinguishing normative and instance descriptions, by recognizing that the distinction is always context and purpose dependent.

The link from a description to a ‘described concept’ (ConceptTermGUID) identifies the most specific term from an associated vocabulary that is consistent with the attributes specified in the description. For instance, an Earth material description of an indurated material of igneous origin, composed of 30% each of quartz, K-feldspar, and plagioclase would be associated the term ‘Granite’ from the standard lithology vocabulary. For identifying, default, or necessary property descriptions, this term will name the concept defined by the description. In this case, the vocabulary term may serve as a proxy for the attributes specified by the description. Any particular instance description need only specify attributes that are explicitly observed; other attributes may be inherited from the default description (if there is one) for the described concept. The structure of the description is defined by association with an entity definition in the Data Schema tables as described above. This entity definition may be used to validate the description before committing to the database, and for configuring the user interface during data entry or querying.

The GenericDescription table includes only the basic description property fields described above. This table serves as a base physical table for descriptions that do not have required attributes, or are deemed to not need a separate physical table. In the current implementation, the GenericDescription table is used for description of bedding fabric, genesis (geologic history), geologic event, particle shape, and particle size.

The GeologicAge table provides a mechanism for geologic age specification in as much or little detail as necessary to the user. Each GeologicAge instance represents an interpretation of one or more observations/measurements, and may be used to locate one or more other data objects (geologic units, structures, geologic events) in time. These different observations are unified in this table with a best guess numerical minimum and maximum time coordinate (for analysis), and a DisplayName that summarizes the interpretation (for a data browser). The individual observations are linked to the GeologicAge base table instance through AttributeRelationship instances, and may include time coordinates (age dates), stratigraphic eras that represent intervals (time ordinal eras in GML terminology), or individual geologic events (also from a vocabulary). Figure 4 schematically shows the data instances in various tables involved in a relatively detailed geologic age specification.

Figure 4. Example of geologic age instance showing foreign key relationships between tables involved in age specification.

Description tables for compound Earth materials (rocks and unconsolidated materials), geologic units, and geologic structures include all the basic description attributes (purpose, context, described concept…), as well as a small set of attributes required in all descriptions of each kind. For compound Earth material, all descriptions must specify a consolidation degree, degree of crystallinity (crystalline vs. granular), grain discernibility, and representative size. Geologic unit descriptions have an age attribute. Geologic structure descriptions must specify pervasiveness, geometric aspect, and characteristic dimension. For details see the field descriptions in the Appendix.

Relationship tables

Relationship tables (Table 8) may be grouped into two types. AttributeRelationship, FractionalPartRelationship, and ObservationRelationship record information pertaining to observation and measurement of phenomena in the world, and include attributes for specifying metadata pertaining to the relationship instance. SimpleRelationship and MetadataRelationship are correlation tables that implement asserted data cardinality connections between data instances. For more information on these correlation tables, see the field descriptions in the Appendix.

The AttributeRelationship table contains data instances that link property values to a description. Property values are specified through links to a science language term, a value specification instance, or to another description instance (Figure 5). The value type and allowed values are specified in the data schema tables (see Data Schema section, above) by the Domain attribute of the EntityProperty associated with each AttributeRelationship instance. Each EntityProperty instance that may be referenced by AttributeRelationship has an associated ESRISubtype attribute integer value that is used in the ESRI geodatabase environment to specify the entity (i.e., geodatabase object class and subclass) that contains the value instance, and to specify the domain of possible values for that EntityProperty. The ESRI geodatabase domains are generated from the domain definition tables either during geodatabase setup, or dynamically with customized geodatabase behavior. Attribute relationship links are owned by a description instance in that if the description is deleted, the associated attribute links are deleted.

Figure 5. Association of property values to a geologic unit description using AttributeRelationship correlation links. Each box represents a row (data instance) in a table. Different shapes and line patterns indicate different tables. Identifiers for each row are 32 hexadecimal digit globally unique identifiers. These are abbreviated to ‘ID nnnnn...’ in the boxes. Table names are underlined. Some tables have ‘subtypes’ identified here by a name followed by a colon before the table name. These are subsets of rows in the table that have different value ranges defines for some fields, and may have different collections of attributes associated through AttributeRelationship links. Lines between boxes represent foreign key relationships between rows. AttributeRelationship instances (abbreviated AttributeRel.) are linked to a description through their ‘owningItem’ foreign key, and to a value specifier through their ‘PropertyValue’ foreign key. Property values may be specified by TextDescription, MeasuredQuantity, ScienceLanguage, GeologicAge or GenericDescription data instances.

The FractionalPartRelationship table is used in geologic unit description and compound material description to represent compositions. The table includes a measured quantity representation (typical value, minimum, maximum, measurement method, etc.) for recording the proportion to the whole of a given part of the aggregation. Each part instance also has part type and role attributes. “Type” specifies the nature of each part. For example, in an Earth material, the mineral constituents may occur as ‘clast’, ‘fossil’ or ‘crystal’. Role specifies the relationship between one part and the aggregation as a whole, for example a mineral constituent may be of type ‘crystal’, and have a role that is either ‘phenocryst’ or ‘groundmass’. Classification of a part type is (at least conceptually) possible if the part is removed from the aggregation, whereas roles are dependent on the aggregated state of the compound material.

The ObservationRelationship table contains data instances that record observed or inferred relationships between geologic phenomena. A relationship type attribute specifies the semantics of the relationship. The ESRISubtype attribute is used in the geodatabase environment to constrain valid source and target entities for each relationship instance.

Metadata tables

Feature-level metadata is recorded principally in the Tracking table. Each tracking record has a display name, a free text description, a link to an Activity, a processing method description (similar to ‘processing steps’ in FGDC metadata), and for information derived from publications, links to one or more citations to published literature (see implementation described in Richard [2003]). Table 9 summarizes the various database tables used to implement feature-level metadata. Activity is a description that specifies one or more people involved in the work, each associated with an organization and a sponsoring project. Every data object has a link to a Tracking record that records where the data object came from (known as “origin tracking”).

Rules for the use of tracking records depend on business requirements. Given the long-term objective of a distributed and seamless database with information from a variety of sources, for both scientific and legal reasons, it seems necessary to at least be able to trace the origin of any declarative data to the original publication or individual responsible for the scientific observation or interpretation.

PHYSICAL DATABASE

The physical database for the thematic (non-spatial) tables currently being used for NGMDB software tool development has been implemented both in SQL server 2000 on a Windows 2003 server and a stand-alone Microsoft Access 2000 database. An ESRI Geodatabase version (which includes the feature classes and internal database tables required to function as an ESRI Geodatabase) is being tested using a personal geodatabase (Microsoft Access 2000 file) generated from a Visio UML document using the ESRI CASE tools (ESRI, 2002). When records are inserted in the thematic tables (e.g., when a new map area is delineated, its extent modified, or attributes added), the SQL server version calls a user function to generate a new unique identifier (see below), whereas the personal geodatabase uses a custom class extension to generate new identifiers. Each table in the database includes a collection of standard ‘system’ fields, which are summarized in Table 10.

This design has evolved in a major step from related predecessor databases (Richard, 2003) by adopting globally unique identifiers (GUIDs) as the relational database key. These are 32 hexadecimal-digit (128 bit) numbers generated by the operating system (available on all major operating systems), guaranteed (or at least highly probable) to be globally unique (Leach and Salz, 1998). Use of these identifiers simplifies generation of unique keys for database relationships in a distributed environment. Because the information system is intended for use in a GIS environment, and because a majority of GIS systems use ESRI software, compatibility with ESRI data formats is considered essential. Standard GUIDs are binary numbers, and are incompatible with ESRI coverages used through Arc/Info version 7, version 8 Geodatabases, and ESRI shape files (which use dBase table format for thematic data). In order to maintain backward compatibility with these common data formats, GUIDs are converted to strings, formatted with hyphens according to a commonly used format (e.g. DA1AB9C6-A5D3-41DA-B3E2-66303CF231B2, hyphens after digit 8, 12, 16, and 20) to produce a 36-character string. These long strings are inefficient as keys, and in a large database would cause a performance problem, but it is anticipated that with release of ArcGIS v.9, the system will migrate to binary GUIDs for enterprise implementation, with the string GUIDs reserved for export to legacy systems and data interchange.

ENTERPRISE DATA MANAGEMENT

Because the National Geologic Map Database will be distributed in nodes maintained by various state geological surveys and the U.S. Geological Survey, some mechanism is necessary to manage data in the various nodes. The entire system is envisioned as a hierarchy of repositories (Figure 6). Each repository would be a self-contained collection of data, some of which is local to the repository, and some of which is ‘inherited’ from parent repositories. Each repository would include the collection of tables outlined here, and possibly additional tables defined in the data schema tables for the repository.

Figure 6. Schematic repository hierarchy. Higher-level hierarchies aggregate data from lower level hierarchies.

Figure 7 is an object diagram for the proposed repository structure. A Repository is a data store composed of a TableCollection that aggregates tables (with associated domains, relationships, and constraints) defined by a standard NGMDB data schema and tables defined by local schema extensions. Each repository is contained in a physical database artifact, which is typically a file in a computer system. A repository is associated with one or more projects that use data contained in the repository. Security policies that control data entry and editing permissions are associated with projects and repositories. The repository data schema is an aggregation of schema elements from the standard NGMDB data schema (outlined in this paper), and local schema elements required for other business requirements. The tables (with associated domains, relationships, and constraints) that compose a repository realize the repository’s data schema. A repository uses a science language vocabulary that is an aggregation of shared vocabulary terms from the NGMDB standard vocabularies, other standard vocabularies from the organization and project level, and locally defined vocabulary terms. The terms that are not included in the NGMDB standard vocabularies must be defined according to the process described in Richard et al. (2003).

Figure 7. UML diagram for Repository. UML classes have dropshadow, Class instances and artifacts do not have drop shadow. Solid fill aggregation symbols indicate that the lifetime of the member objects is linked to the lifetime of the container object (Cascade delete).

Each repository will indicate some level of authority, and migration of data from a lower level repository to a higher-level repository will involve a publication process that includes scientific and logical review and approval. Each repository will have an owner who determines policies and procedures for inclusion of data in that repository. Access by individual users, projects, and repositories for reading, adding, and updating data are to be determined and controlled by the repository owner.

Self-contained bodies of data from one or more repositories may be ‘published’ as a snap shot, a read-only stand-alone dataset that may be transported into other database environments (along with the feature level tracking information for the data). Data from one repository may be linked into another repository (the owning repository is an attribute of all data instances), but if any updates are made, the repository in which the updates are made becomes the owning repository (i.e., it is responsible for the scientific content of the updated or modified information).

CONCLUSIONS

The data in an archive that is based on this design will almost certainly require some pre-processing for use in standard relational database systems with SQL-based queries. The data could equally undergo pre-processing for analysis by a description logic engine such as Racer (http://www.racer-systems.com/). The implementation is essentially an implementation of a description logic (Baader et al., 2003) for science information. The description structure is assembled by links between data objects, and can be thought of as a directed acyclic graph, similar to an XML document (network data structure), so Xpath type search specification (Clark and DeRose, 1999) probably will also be useful. We are moving ahead with the implementation of a knowledge representation system that moves beyond the SQL-based relational database with the understanding that current technology must mature to fully reap the benefits of this approach. Given the inherently long lead time in implementing, testing, and finally populating the data in such a system, we are confident that the necessary analytical tools under development in the semantic web community will allow full utilization of the data for new and exciting applications of geoscience information.

REFERENCES

Baader, F., Calvanese, D., McGuinness, D., Nardi, D., Patel-Schneider, P., eds, 2003, The Description Logic Handbook—Theory, Implementation and Applications: Cambridge, UK, Cambridge University Press, 574 p.

Brodaric, B., Journeay, M., Talwar, S., and others, June 18, 1999, CordLink Digital Library Geologic Map Data Model Version 5.2 (Web Page), accessed June 13, 2001, at http://cordlink.gsc.nrcan.gc.ca/cordlink1/info_pages/English/dm52.pdf.

Brodaric, B. and Hastings, J., 2001, Evolution of an Object-Oriented, NADM-Based Data Model Prototype for the USGS National Geologic Map Database Project [web page, abstract]: Annual Conference of the International Association for Mathematical Geology, IAMG2001, Cancun, Mexico, accessed June 14, 2001, at http://www.kgs.ku.edu/Conferences/IAMG/Sessions/I/brodaric.html.

Brodaric, Boyan, and Hastings, Jordan, 2002, An object model for geologic map information, in Richardson, D., and van Oosterom, P., eds., Advances in Spatial Data Handling, 10th International Symposium on Spatial Data Handling: Heidelberg, Germany, Springer-Verlag, 562 p.

Clark, James, DeRose, Steve, 1999, XML Path Language (XPath), Version 1.0, W3C Recommendation (16 November 1999), accessed November 18, 2004, at http://www.w3.org/TR/xpath/.

Cox, Simon, Daisey, Paul, Lake, Ron, Portele, Clemens, Whiteside, Arliss, eds., 2004, OpenGIS Geography Markup Language (GML) v. 3.1.0, Implementation Specification: OpenGIS Recommendation Paper, Document OGC 03-105r1, ISO/TC 211/WG 4 Document 19136, 02-07-2004, 601 p., accessed November 28, 2004, at http://www.opengeospatial.org/specs/?page=recommendation.

ESRI, 2002, Building Geodatabases with CASE Tools: Redlands, CA, ESRI, 72 p., accessed November 29, 2004, at http://downloads.esri.com/support/downloads/ao_/CASE_Tools_CaseTools.pdf.

Johnson, B. R., Brodaric, B., and Raines, G. L., 1998, Digital Geologic Maps Data Model, V. 4.3 (Web Page), AASG/USGS Data Model Working Group report, accessed at http://www.nadm-geo.org//dmdt/.

Leach, P.J., and Salz, Rich, 1998, UUIDs and GUIDs, WebDAV Network Working Group Internet Draft, accessed November 29, 2004, at http://www.webdav.org/specs/draft-leach-uuids-guids-01.txt, or at http://ftp.ics.uci.edu/pub/ietf/webdav/uuid-guid/draft-leach-uuids-guids-01.txt.

NADMSC (North American Data Model Steering Committee), 2004, NADM conceptual model 1.0, A conceptual model for geologic map information: U.S. Geological Survey Open-File Report 2004-1334, 60 p., accessed at http://pubs.usgs.gov/of/2004/1334/.

Richard, S.M., 2003, Geologic map database implementation in the ESRI Geodatabase environment, in Soller, D.R., ed., Digital Mapping Techniques ‘03—Workshop Proceedings, U.S. Geological Survey Open-File Report 03-471, p. 169-183, accessed at http://pubs.usgs.gov/of/2003/of03-471/richard2/.

Richard, S.M., and Orr, T.R., 2001, Data structure for the Arizona Geological Survey Geologic Information System-Basic Geologic Map Data, in Soller, D.R., ed., Digital Mapping Techniques ‘01—Workshop Proceedings, U.S. Geological Survey Open-File Report 01-223, p. 167-188, accessed at http://pubs.usgs.gov/of/2001/of01-223/richard2.html.

Richard, S.M., Matti, Jonathan, Soller, D.R., 2003, Geoscience terminology development for the National Geologic Map Database, in Soller, D.R., ed., Digital Mapping Techniques ‘03—Workshop Proceedings: U.S. Geological Survey Open-File Report 03-471, p. 157-167, accessed at http://pubs.usgs.gov/of/2003/of03-471/richard1/.

Soller, D. R., and Berg, T. M., 2003, The National Geologic Map Database: Overview and Progress, in Soller, D.R., ed., Digital Mapping Techniques ‘03—Workshop Proceedings, U. S. Geological Survey Open-File Report 03-471, p. 57-77, accessed at http://pubs.usgs.gov/of/2003/of03-471/soller1/.

Soller, D.R., Brodaric, Boyan, Hastings, J.T., Wahl, Ron, and Weisenfluh, G.A., 2002, The central Kentucky prototype: An object-oriented geologic map data model for the National Geologic Map Database: U.S. Geological Survey Open-File Report 02-202, 39 p., accessed at http://pubs.usgs.gov/of/2002/of02-202/.

Struik, L.C., Quat, M.B., Davenport, P.H., and Okulich, A.V., 2002, A preliminary scheme for multihierarchical rock classification for use with thematic computer-based query systems: Geological Survey of Canada, Current Research 2002-D10, 11 p., accessed at http://www.nrcan.gc.ca/gsc/bookstore/free/cr_2002/D10.pdf.

APPENDIX

Tables 11–42, showing additional concepts, tables, and fields in the NGMDB implementation of NADM C1 (Tables 1–10 are contained in the text).

Conventions for Field Names in NGMDB Tables

• GUID—used as suffix to indicate a field contains a Globally Unique IDentifier, a 32 digit hexadecimal number calculated by the operating system based on an algorithm that produces theoretically unique values.
• Field names with the suffix SysGUID indicate fields that are foreign keys to the primary key in another entity.
• Field names with the suffix TermGUID are foreign keys to a vocabulary table, and identify a term used to specify a property value.
• FieldNames with the suffix EntityGUID are foreign keys to the Entity table, and identify an entity (physical or logical table). These are normally associated with a SysGUID foreign key that identifies a particular data object (record) in that entity (table).
• FieldNames with prefix ‘Is’ are boolean fields that may have a true or false value.

List of Tables

• Table 11. Fields in Entity table.
• Table 12. Fields in EntityProperty table.
• Table 13. Fields in EntityPropertyDomain table
• Table 14. Fields in EntityPropertyDomainNodeList table.

Quantity Value Specification Tables (see also Table 4 in text):

• Table 15. MeasuredQuantity.
• Table 16. StructureObservation.
• Table 17. TextDescription.
• Table 18. DocumentLink.
• Table 19. Extent.

Spatial Data Tables (see also Table 5 in text):

• Table 20. NGMDBFeature.
• Table 21. ProjectExtent.
• Table 22. AreaOfInterest.
• Table 23. Station.
• Table 24. SectionLine.
• Table 25. BoreholeCollar.
• Table 26. GeologicSurfaceTrace.
• Table 27. GeologicUnitOutcrop

• Table 28. Section.
• Table 29. Borehole.
• FlightLine.
• Traverse.
• Table 30. SectionInterval.
• Table 31. SectionIntercept.
• Table 32. Fields in Sample Table.

Description Tables (see also Table 7 in text):

• Table 33. GenericDescription.
• Table 34. GeologicAge.
• Table 35. EarthMaterialDescription.
• Table 36. GeologicUnitDescription.
• Table 37. GeologicStructureDescription.

Relationship Tables (see also Table 8 in text):

• Table 38. AttributeRelationship.
• Table 39. FractionalPartRelationship.
• Table 40. SimpleRelationship.
• Table 41. ObservationRelationship.
• Table 42. MetadataRelationship.

Quantity Value Specification Tables (see also Table 4 in text):

Spatial Data Tables (see also Table 5 in text):