transfer and reuse, uncertainties regarding data ownership, and ad hoc data management strategies. As we look to the future, a key question arises: How do we change the state of this ineffective practice, particularly while literally being inundated with project-related data? The problem could be resolved easily if every stakeholder utilized the same relational database for storing and managing da t a , a da t aba s e wi th standardized field titles, content format, etc. Although this may be a noble goal, it does not reflect reality. An alternative to a standard relational database for storing, managing and/or transferring data is the eXtensible Markup Language (XML), a common language used by computer scientists, which defines a set of rules so that data may be stored easily in files. This is where DIGGS enters the picture. How DIGGS Works DIGGS was originally envisioned by a coalition of government agencies, universities and industry partners with the goal of it becoming an international transfer standard for the geotechnical and geoenvironmental data that is routinely needed for transportation-related projects. DIGGS is not a database, but rather a specific set of instructions to organize and represent data using an XML framework. This approach allows data to be trans- ferred or shared by any number of software applications, including established databases. In a simple sieve analysis, for example, DIGGS provides the instructions on how the relevant data for this test should be stored, as well as rejecting test results that are missing basic data, such as the size of the sieve screen openings. Most data of interest to geopro- fessionals has a spatial and/or geometric component (i.e., coordinate location and elevation and potentially structures and features that can be modeled with geometric shapes such as lines or polygons). Because of this, DIGGS was developed with a Geography Markup Language (GML) application schema. This schema utilizes standardized XML grammar for encoding geospat ial information. XML and GML provide the rules for communicating data across the internet and between software systems, regardless of how the data are generated. By selecting XML and GML as the language-of- choice for developing the DIGGS schema, platforms, reported, having such standards will “enable developers to make all types of sensors, transducers and sensor data repositories discoverable, accessible and useable via the Web.” Therefore, using industry-accepted protocols, equipment vendors and users will be able to easily export GML-compliant DIGGS data files from their equipment. Data that are not generated using sensors are often collected manually and recorded electronically. These data can similarly be used to generate GML-compliant DIGGS data files for electronic transfer. Easing Import to Different Software. DIGGS serves as a framework that ensures nothing is “lost in translation” when storing and transferring data. the following two significant hurdles for acceptance and adoption were addressed: Simplifying Data Export. Data are In 2005, the Federal Highway Admin- istration funded a pooled fund study for DIGGS development, which the Geo- Institute (G-I) of the American Society of Civil Engineers became involved in in 2013. DIGGS became operational in 2016, and is managed by the DIGGS Devel- opment Team of the G-I. By design and intention, DIGGS is open source, freely available and requires no proprietary software to use. DIGGS serves as a framework that ensures nothing is “lost in translat ion” when storing and transferring data. It defines the names and properties of standardized fields for values to be stored. It also defines which fields are required to have meaningful information. 98 • DEEP FOUNDATIONS • MAY/JUNE 2020 often generated in the field or in the laboratory as millivolt signals, amperage readings and frequency measurements on data collection and recording equipment (e.g., survey total stations, piezometers, load cells, flow meters, slope inclino- meters, pressure transducers, etc.). Some of this equipment is attached to drill rigs to provide instant feedback to the operator. After signal processing, these analog or digital signals can be converted to engineering units and stored for eventual transmission to a readout unit, text file, data storage device, etc. At this point, the equipment vendor or user could simply elect to generate a DIGGS XML file that contains the collected results. As the Open Geospatial Consortium (OGC), an international group of companies, governmental agencies and universities seeking to develop similar open-source Once data are collected, they need to be processed, viewed, stored and managed. Typically, professionals utilize proprietary spreadsheet formats, local databases or customized computer software programs for these activities. If these software products can accept DIGGS files for import, and export data in a DIGGS format, then the data can be seamlessly transferred without manual re-entry into a vendor-specific format. In this way, the data becomes “software agnostic” and users need not change from their current favored software. Among other advantages of DIGGS data is users’ ability to implement new and better tools that may come to market without worrying about data compatibility issues. Owners can also require that all consultants and contractors submit valid DIGGS files as part of project delivery so that the owner now has all data from all projects in a consistent format. Not only is this a significantly more efficient way of doing business, it also addresses many problems of previous data man- agement strategies. In effect, DIGGS becomes the common language that facilitates communication among any number of software applications. DIGGS v 2.5.a is readily available for use by the geoprofession. DIGGS has already been used to implement dozens of test procedures. In addition, its schema is continually being expanded with more tests and procedures, including construction and performance data regarding deep foundations. DIGGS is available at a website managed by G-I at www.diggsml.org.
