Changes to Age and Lithology

[aazaff]

Lithology

I have used the following collections as examples of how to map Age and Lithology information. I start with lithology mappings.

collection_no	lithadj	minor_lithology	lithification	lithology1	fossilsfrom1	lithadj2	minor_lithology2	lithification2	lithology2	fossilsfrom2
234	NULL	NULL	lithified	"limestone"	Y	glauconitic	NULL	lithified	sandstone	NULL
3234	hummocky CS,burrows	silty	lithified	sandstone	NULL	NULL	NULL	NULL	NULL	NULL
28282	gray,green	carbonaceous	unlithified	sandstone	Y	brown,gray,yellow	carbonaceous	unlithified	claystone	NULL
134134	NULL	NULL	lithified	not reported	NULL	NULL	NULL	NULL	NULL	NULL

I convert these into the following example (abridged) collections json payloads. I added in some other key-pairs, just for realism/context. The only part that really matters for this issue is the "lithology" array.

Collection 234

{ "data": {
    "name": "example collection 234",
    "coordinates": {
             "lat": "34",
             "lng": "88"
             },
    "lithology": [
         {
            "major": "\"limestone\"",
            "fossils": "true",
            "lithification": "lithified"
             },
        {
            "major": "sandstone",
            "adjectives": ["glauconitic"],
            "lithification": "lithified"
             }
        ],
    "formation": "Riley"
    }
}

Collection 28282

{ "data": {
    "name": "example collection 28282",
    "coordinates": {
             "lat": "-20",
             "lng": "118"
             },
    "lithology": [
         {
            "major": "sandstone",
            "minor": "carbonaceous",
            "adjectives": ["gray","green"],
            "fossils": "true",
            "lithification": "unlithified"
             },
        {
            "major": "claystone",
            "minor": "carbonaceous",
            "adjectives": ["brown","gray","green"],
            "lithification": "unlithified"
             }
        ],
    "formation": "Some Formation"
    }
}

[aazaff]

Ages

Although there are many, many age-related fields. There are actually only two different age concepts that we really need to worry about.

1. Relative Age -- A high-level age based on stratigraphic inference. This is required for all collections. It is directly analogous to the PBOT collection age information. At first glance, all you need for this is a timescale and a maximum interval (with minimum interval being optional).

It seems like it would be an easy matter to represent that is as a "stratigraphic age" object in the collections JSON. However, that is a little bit tricky BECAUSE we derive the numeric equivalent of the age AND the timescales from an external dictionary - i.e., we are conceptually using foreign keys. In other words, there will need to be a dictionaries.timescales and dictionaries.intervals tables. that we FKEY. Given our ruling that foreign keys always need to be outside of the JSON, then this age information needs to live at the table level. More on this later.

2. Direct Age -- A specific age based on one or more laboratory measurements of an actual fossil or rock taken from the collection. Most collections do not have this information, but it is valuable when it exists and needs to be captured. So it is optional. Unlike the relative age, this will not have a foreign key to any other table and can live in the JSON.

{ "data": {
    "name": "example collection 28282",
    "coordinates": {
             "lat": "-20",
             "lng": "118"
             },
    "lithology": [
         {
            "major": "sandstone",
            "minor": "carbonaceous",
            "adjectives": ["gray","green"],
            "fossils": true,
            "lithification": "unlithified"
             },
        {
            "major": "claystone",
            "minor": "carbonaceous",
            "adjectives": ["brown","gray","green"],
            "lithification": "unlithified"
             }
        ],
    "formation": "Some Formation",
    "age_measurements": [
        {
            "age": "12",
            "error": "1",
            "unit": "ma",
            "method": "fission track"
            }
        ]   
    }
}

Note I do not think it is necessary to specify direct, max, or min as in PBDB since max and min are implicit. Just add age_measurement objects freely, then take the max and min as max and min.

The following is a real example from collection 19586. Notice that there is only a direct measurement and a max measurement. There is not min_ measurement, but, if there was, you would just add another object to the array.

    "age_measurements": [
        {
            "age": "17.03", // direct_Ma
            "error": "NULL", //direct_ma_error
            "unit": "ma", // direct_ma_unit
            "method": "paleomagnetic" // direct_ma_method
            },
        {
            "age": "17.9", // max_ma
            "error": "0.3", // max_ma_error
            "unit": "ma", // max_ma_unit
            "method": "K-AR" // max_ma_method
            }
        ]

[aazaff]

Actually migrating the age information from the MariaDB is complicated for two reasons.

Redundant levels of the hierarchy

First, geologic Intervals follow a hierarchy just like taxa. In PBOT we simply find the most granular (highest number) and use that. PBDB, however, records multiple. This means that we need to create logic that will find the most granular recorded age and extract that.

1. Eon
2. Era
3. Period
   1. emlperiod_max + period_max = early_age
   2. emlperiod_min + period_min = late_age
4. Epoch
   1. emlepoch_max + epoch_max = early_age
   2. emlepoch_min + epoch_min = late_age
5. Subepoch (not sure where they put this?)
6. Stage/Age
   1. If international age intage and locage are both present, only take locage. If only one is present, use that one.
   2. emllocage_max + locage_max = early_age
   3. emllocage_min + locage_min = late_age
   4. emlintagge_max + intage_max = early_age
   5. emlintage_min + intage_min = late_age
7. Zone -- relevant pbdb columns are (zone and zone_type)
   Here are examples from collections 234, 3234, and 28282

collection_no	period_max	epoch_max	locage_max	zone
234	Cambrian	Upper (note: bad data!)	Dresbachian	Dunderbergia
3234	Silurian	Llandovery	NULL	NULL
28282	Tertiary	Miocene	Burdigalian	NULL

For our purposes, we theoretically only want to extract the finest level resolution - e.g., Dunderbergia for 234 and Llandovery for 3234 - because the higher levels of the taxonomy are theoretically implicit in the timescale.

Missing intervals

~~The second problem for conversion is that in PBOT we use the Macrostrat intervals and timescales (e.g., macrostrat.org/api/v2/defs/intervals). However, PBDB has a LARGE number of intervals that do not map to Macrostrat (csv attached). ~~

Nevermind the above, we use the defs table inherent in pbdb, scale_data and intervals_data

missingintervals.csv

[aazaff]

Relevant table changes are in 803c500

[mclapham]

I think it's best to keep the direct, max, and min ages separate because they are conceptually different.

The max age field is for when there is a direct date some distance below the fossil-bearing unit in the stratigraphic section, so it provides a maximum constraint on the age rather than a direct one. Or it could be used for detrital zircons, where we know the deposit can't be older than the age, but it could be younger than it.

Min age is for when the dated bed occurs above the fossil-bearing one in the stratigraphic section, so the fossils cannot be younger than that age but are some amount of time older than it.

Direct date is for when the age comes from the exact bed containing the fossils, such as radiocarbon dates for Pleistocene/Holocene things, or deeper time beds dated by strontium directly from the shells, or U-Th coral dates, or for when the volcanic ash bed directly buries the fossils.

[aazaff]

Then it might be good to distinguish, explicitly between ages that refer to the parent stratum versus the fossil specific bed.