Software and the Core Description Process

Data Capture

I considered three approaches to capturing the data represented in the core description diagrams:

• Eliminate the diagramming altogether and have the scientists enter the data directly into spreadsheets.
• Post-process the diagram images and extract the data using image analysis.
• Provide an interactive drawing environment to capture the data as the diagram is drawn.

The scientists rejected the first approach because it was too different from the drawing process they were familiar with, and it eliminated the diagrams—the de facto standard in conveying the core description. The second approach was promising because it did not require changing the existing process, and it held the potential to work with existing diagrams and those from future expeditions. Ultimately, I rejected this approach because of its inherent inaccuracy. There was too much variability, in both structure and style, between the few example diagrams I was provided to expect any reasonable success rate with image-analysis techniques.

I settled on providing an interactive drawing environment and capturing the core description data as the diagram is drawn. This required the development of a custom drawing environment, no small task, but preserved the diagrams and drawing process the scientists were familiar with. It also had the potential to simplify the description process because the environment could be customized specifically to drawing core-description diagrams. The software could provide specialized tools for drawing geological features (like lithostratigraphic intervals) instead of forcing the scientist to represent these features with simple graphical objects (like rectangles and circles). The software and scientist could work at the same semantic level.

Before I could begin work on the software, which would ultimately be called "Paleontological Stratigraphic Interval Construction and Analysis Tool" (PSICAT), I spent several months working directly with scientists to learn the specialized vocabulary, concepts, and requirements of core description. I reverse-engineered dozens of actual core description diagrams to determine what data was encoded in them and how the data was visually represented. I also observed the scientists actually describing core. Once I had a handle on the types of data and tasks involved, I began work on modeling these in software.

Data Model

Core description diagrams like Figure 1 display a wealth of different data. Many of the data types share common properties. For example, lithostratigraphic intervals and stratigraphic units each have an associated top and a base depth. Each data type also has unique properties—stratigraphic units have identifiers associated with them, whereas intervals do not. To accommodate these various data types and those that have not yet been identified, PSICAT (portal.chronos.org/psicat-site) required a flexible model and representation scheme for the data.

[Click image to view at full size]

Figure 1: An example core description diagram.

Each high-level data type in PSICAT, such as lithostratigraphic intervals, stratigraphic units, and sedimentary structures, is represented by Model objects, which are associative arrays of key-value pairs. The associative array data structure was chosen for its simplicity and expressiveness—most, if not all, high-level data types can be represented as a collection of named properties. Each Model has two implicitly defined properties: an id, which uniquely identifies the Model; and a type, which identifies the high-level data type of the Model. Beyond these two implicit properties, Models can have an arbitrary number of other properties. Models are also hierarchical in nature and may contain nested Models, indicating a parent-child relationship.

This data model is flexible enough to be serialized to many different representations. PSICAT currently records the data model as an XML file using something like Example 1.

<models>
    <model id="0" type="Project" parent="">
       <property name="name">Sample Project</property>
    </model>
    <model id="1" type="Interval" parent="0">
       <property name="depth.top">0.00</property>
       <property name="depth.base">0.58</property>
          ...
    </model>
    <model id="2" type="Interval" parent="0">
       <property name="depth.top">0.58</property>
       <property name="depth.base">1.12</property>
          ...
    </model>
    ...
</models>

However, there are two oddities in Example 1. First, if the data model is hierarchical and XML is hierarchical, why is the XML representation of the data model flat? During the development of PSICAT, I ran into a situation where deeply nested model trees were overflowing the stack because of too much recursion when parsing the data. In response, I switched to this flat structure, then "treeified" the data model after parsing.

The second is less an oddity and more a limitation of the data model and XML serialization. In Example 1, no type information is persisted about the individual properties. This means the value "number" is just as valid as "1.12" for the depth.base property. This can cause problems when a property value represents a data type other than a character string—a number, for instance. To address this, PSICAT applies a mapping action where it maps the generic Model object to a specialized subclass of Model based on the value of the type property. This specialized Model is still backed by the associative array but can define helper methods; for instance, double getBaseDepth() and void setBaseDepth(double depth), for accessing the property values using native data types.