prepared by Eric Ingbar (Gnomon, Inc.)
Contents
Forest Service Paul Claeyssens, Bend, 541-383-5540 (pclaeyss/r6pnw_deschutes@fs.fed.gov) Tom Fulgham, LaGrande, 541-278-3719 (tfulgham@r6pnw_umatilla@fs.fed.us)
Oregon State Historic Preservation Office Kimberly Dunn, Salem, 503-378-5001x230 (kimberly.a.dunn@state.or.us) Le Gilsen, Salem, 503-378-5001x232 (leland.gilsen@state.or.us)
Oregon State GIS Theresa Valentine, Salem, 503-373-7461 (theresa.j.valentine@state.or.us)
Oregon Department of Transportation Hal Gard, Salem, 503-986-3508 (howard.a.gard@odot.state.or.us) Lydia Kachadooriam, 503-986-3504
University of Oregon Tom Connolly, Eugene, 541-346-3031 (connolly@darkwing.uoregon.edu) Kate Kirsh, Eugene, 541-346-4820 (kkirsh@oregon.uoregon.edu)
Confederated Tribes of the Umatilla Indian Reservation Diana Kellas, Pendleton, 541-276-3629 (medellin@ucinet.com)
National Conservation Resource Service Russell Hatz, Portland, 503-414-3235 (hatzr@or.nrcs.usda.gov)
Consultant Eric Ingbar, Carson City, NV, 702-885-2305 (eingbar@gnomon.com)
Meeting goal – get a sense of the desire to have a statewide database that all would contribute to, and that all could utilize. If possible, determine directions to follow to achieve this goal. Toward these ends, the participants have been invited because of their long-term participation in Oregon historic preservation and their use of databases.
USFS Region 6 (Fulgham) - National database effort for cultural resources has been dropped after several years of development; regional sharing and design seems to be the way in which USFS will proceed in the near future. In Region 6, there have been regional design efforts for a database, but these have never reached implementation completely. Now, each forest is essentially responsible for its own database effort. There is a 1995 cooperative agreement between the Region and the OR SHPO.
OR SHPO (Gilsen and Dunn) - Dunn handles historic inventory, Gilsen handles the archaeological inventory. The SHPO goal is wide availability, and ultimately GIS (at least for the historic structure inventory). Standard data elements have been in place for some years for archaeological and structural sites. The OR SHPO has been migrating to MS Access software in the past year, due to a year 2000 problem with Dbase. There have been some problems with query conversion The inventory includes 21,000 prehistoric site forms, 10,000 survey or testing orexcavation reports, a paper map index, a DOE database of eligible properties with about 7500 entries, and a radiocarbon database. Approximately 1500 entries are added to the inventory each year.
UMATILLA (Kellas) - The Umatilla maintain a database of approximately 3500 site forms from OR and 2500 in southeastern WA within Paradox software. Everything is indexed on USGS map sheets; all reports and agency plans within or adjacent (for the plans) to Umatilla lands are held in the archive. The database will migrate to MS Access in the near future. For spatial accuracy and many other reasons, the Umatilla are acquiring a total station and already have a handheld GPS.
Consultant (Ingbar) – The process being initiated today is mirrored in many other western states. In general, the approach has been collaborative (like this) and appears to be moving forward well. Some things to consider are that more complicated database schemes and GIS plans may never get populated to a useful level; too, developing a strategy must precede creating database structures and other implementation issues.
Central OR Heritage Group [COHG] USFS and BLM (Claeyssens and Goodman) - Fairly well-developed (now in iteration #3) system shared between Forest Service and BLM. A single data administrator has been collating each field office’s entries into a master database that is then redistributed. Similarly, GIS is done at the field office level (there is no single, central, GIS coverage for COHG: this is a goal). Other central and southern Oregon forests and districts are either interested in or adapting the COHG design (essentially joining in to COHG). COHG is a work in progress, by its very nature. Some of the current COHG problems include lack of networking between the two agencies, the need to implement a shared database design to alleviate the database manager update demands and the need to make data available in wider forms (i.e., non-expert modes). Of course, there are no field office funds allocated to COHG as a line item.
NRCS (Hatz) - NRCS differs from many agencies in that it operates on lots of private land. Its cultural resource program is project-driven, so that query capabilities are very important to NRCS users.
BLM State Office (Frazier) - Planning is a key to good implementation. Consider the difficulties inherent in the process.
BLM State Office (Witherspoon) - There are existing data sharing memoranda (MOU’s) between agencies and the State of Oregon. These cover the coordinating and sharing activities discussed here. As well, a later comment by Jack is worth summarizing here: any information system has to make sense at the user level and needs to meet the "why" test ("why would I use this thing?").
Oregon State Museum of Anthropology and U. Of. O. Infographics (Connolly and Kirsh) - OSMA would welcome an accessible database of resources and reports. Ther are several resources within the state that might be helpful in this regard, including the Infographics laboratory.
Oregon DOT (Gard) - ODOT Ready for a unified effort and ready to facilitate in any feasible way to aid the process. As potential users of a database, they see big advantages in pulling together to create one.
BLM Roseburg (Barner and Dzialowy) - Roseburg has used ArcSITE (also used at SHPO) faithfully and maintains it for all of Douglas County. The ArcSITE product has become rather creaky in new software environments (for one, it runs poorly under Windows95). Data from the District is shared with the SHPO on a periodic basis.
General Discussion – All participants concurred that it was time to move forward in a statewide effort. This will be a good thing, so it seems. No single participant volunteered to fund the entire effort. There was general consensus that the SHPO should provide the overall direction since SHPO has the widest cross-cutting viewpoint and the legal mandate to maintain records.
Ingbar spoke briefly on the difference between a logical model and the implementation of that model. A logical model specifies how data elements fit with each other to meet user information needs and the process in which information is used. An implementation model specifies how these logical terms will be translated to an actual database platform. Thus, the implementation model is to some degree platform-specific, where the logical model is process-specific. There are several levels of implementation model, ultimately getting to the actual attributes, tables, and relationships between tables or attributes that become "the database". Sound logical models will transcend hardware and software changes more readily than "convenient" but illogical models. The point seemed to be taken quickly by all, so no discussion of it was needed.
There seemed to be a need for four activities:
There was broad agreement that the SHPO should coordinate activities.
Some of the issues that will need to be addressed included (but were not limited to):
Four subgroups are envisioned, one for each activity.
The Core Attribute group has the immediate task of compiling the attributes in ArcSite, COHG, and the "Glorieta standards workshop" lists. From these, and by adding or deleting where needed, the Core data group will make a recommended list of elements that should be included in the database. All of these must pass a reasonable "why" test. The "core" nature of the attributes is intended to signal to all that local additional attributes might be useful and are in no way "forbidden". Core attributes will be consistent statewide. Particular agencies, geographic areas, or topical researchers may create additional attributes for their own use. Membership of the Core Attribute group at present is: Paul Claeyssens, Tommy Fulgham, Scott Goodman, Isaac Barner, Russ Hatz, Hal Gard, and Le Gilsen.
The work of the Costs and Architecture group will in part follow the Core data group. Their role is to examine what an integrated system will cost, how it should be configured so as to be maintainable (e.g., how data will "flow" through the system), and how it can be efficient. The Costs and Architecture group can begin some work now – defining (probably just making explicit) the work processes that the database will fit.
The Implementation and Maintenance group will define the actual installation and what needs to be coded for users and maintainers of the data.
The Memoranda, Policies, and Access group will work on the enabling memoranda (as needed), policies, and access security issues.
All of these groups remain mutable at this point.
The general timeline of actions is to complete drafts of Core Attributes and explore Architecture and Cost issues. These will determine the needs of the other two tasks. The next planned meeting is May 27th, in Salem. There was some discussion of a meeting of the Core Attribute group in late April or early May. An acronym for the group was devised: The Oregon State Cultural Database Advisory Group (OSCDAG). A listserv has been created for the group at oscdag@gnomon.com.
posted 4.20.98 eei