Data Item Categories

The term ‘Data item’ used here to denote a kind of information object; in other contexts these might be called entities or objects. Each item corresponds to a feature or observation type that specifies a collection of properties. The purpose of this classification is to analyze the information of interest into types that will use the same data schema, delivery mechanisms, and metadata schema.  Initial data types were identified and draft content models developed by surveying project partners at the beginning of the project. The approach was bottom up, based on the kinds of information the state geological surveys reported in their holdings. A summary of this initial survey is available here.

The Data Items are grouped into higher-level information categories that correspond to the 4 main categories of services in the system architecture. These are:

Observation – an information resource representing the event of observing or measuring and recording properties of some feature (Open Geospatial Consortium, Observations and Measurements (O&M), http://www.opengeospatial.org/standards/om). Observations represent the basic data that are the foundation for the other information categories. The content model includes: a result, which is the measured or observed value; a feature of interest, which is the feature the observer wishes to characterize; a procedure, which includes information on who made the observation and how it was made. A sampling feature may be specified to record what part of the feature of interest was the actual target of the observation. The observation model allows modeling composite observations, which may represent the aggregation and interpretation of one or more input observations. At least initially we will be using a flattened, simplified version of the full O&M schema that can be served using OGC simple features.

Feature – an information resource representing some identifiable thing of interest in the world. A feature is described by a collection of attributes that are typically each the result of one or more observations. Features present a more aggregated or interpretive view of the world than observations (although a feature can be modeled as the result of an observation). Features will be delivered via OGC Web Feature Services (Open Geospatial Consortium, Web Feature Service, http://www.opengeospatial.org/standards/wfs) or other similar services. Typically, features have a geographic location.

Document -- A packaged body of intellectual work; has an author, title, some status with respect to review/authority/quality. ‘USGS peer reviewed’ would be a 'status property'. We will have to account for gray literature, unpublished documents, etc. A document may have a variety of physical manifestations (pdf file, hard-bound book, tiff scan, Word processor document...), and versions may exist as the document is traced through some publication process. They may be map, vector graphics, or text. Sound, moving images are included as document types.

Coverage – A dataset that reports the values of some continuously varying property over some spatial or temporal extent. Examples include well logs that report the values of resistivity, density, or some other property along the well bore, gravity maps that report measured (perhaps by extrapolation) values of gravity over some geographic region. A coverage may be the result of one or more observations. A coverage may also be associated with an individual feature, such as a map showing the thickness distribution of a geologic unit or the average temperature at some depth in a Geothermal system.

The discussion of data items in the Statement of Work spreadsheet, DataItems tab assumes familiarity with the basic Open Geospatial consortium (OGC) service architecture. Geologic Unit and Geologic Structure are used as defined for the GeoSciML xml markup language (http://www.geosciml.org/geosciml/2.0/doc/), and system implementers are strongly encouraged to become familiar with that specification as well.

In general, measured quantities should be reported in the units of the original measurement, as well as in units that will be requested for data integration. We propose that the original data provider is most likely to provide accurate unit conversions, as opposed to leaving unit conversions to the data consumer or service provider.