Add earlier (Ediacaran) period to our Geological Age options

[jimallman]

@pdpolly, This issue is related to #23. I'm adding this here so we don't lose track of it.

Dan Ksepka sent this email:

[T]he earliest age available in the dropdown Geological Age section is Cambrian. However, we do have a few fossils from the the time period immediately older than this one, the Ediacaran. Is it easy to add that option to the drop-down? I am simply labeling all Ediacaran fossils as Cambrian for now and can go back and fix that handful when this is resolved.

This is all driven from the database, so we'll need a full accounting of the Ediacaran period. This means database records for this period, plus each epoch and age within it. I’m attaching the records for the Cambrian period as a reminder of the kind of information we need. If you can provide a similar table of values for the Ediacaran, I’ll enter this in the next couple of days.

[jimallman]

@pdpolly, @Ksepka: Just a reminder that this one will be pretty easy to do, once I have data like the table above.

[pdpolly]

@jimallman, @Ksepka @jimparham Here's information from Gradstein et al. 2012 for the Ediacaran.

Note that there is a minor terminology problem in the field titles. The word "System" should technically be "Era" because it is being used for the larger time unit encompassing the Period time unit. The term System technically applies to rocks that define time, so in a technical sense the Cambrian Period is associated with the Cambrian System, but the Cambrian Period is a subunit of the Paleozoic Era, not the Paleozoic System. Also note that Ediacaran is a Period-level time unit, equivalent to Cambrian in the example table. Dan and Jim can decide if they want to subdivide Ediacaran into its epochs and ages.

From Gradstein et al. 2012 (http://www.geol.umd.edu/~hcui/Reference/GeolTimeScale2012/Ch18-Ediacaran.pdf)
Age: Ediacaran
Epoch: Ediacaran
Period: Ediacaran
System: Neoproterozoic
Start age: 635
End age: 541

[pdpolly]

@jimallman @Ksepka BTW, the database field name does not have to be changed from System to Era. It would only matter if someone saw the label, which doesn’t actually appear on the user interface….

[jimallman]

Correct, this never appears to the user, but thanks for the heads-up. I can add a comment in the database for the benefit of future maintainers who might be confused.

UPDATE: Added this comment:

ALTER TABLE `geoltime` 
  CHANGE `System` `System` varchar(50) NOT NULL COMMENT 'technically Era (time unit)';

[jimallman]

@pdpolly: Using the dates above from Gradstein, it seems there will be some overlap between the Ediacaran (end age = 541 Ma) and Cambrian (start age = 543 Ma), as currently defined in FCDB. This will confound some of our search-by-geological-time logic.

Looking at the Cambrian chapter of Gradstein, am I correct that he's moved the start of the Cambrian Period to 541 Ma?

[Ksepka]

I've dug up my copy of The Geological Time Scale (Gradstein et al. 2012). The Ediacaran starts at 635 and ends at 541. This does not match the Cambrian dates in the FCD, which sets the start of the Cambrian at 543. What is the source for the dates in these tables?

I did not notice this before, because the dates are not visible in either the data-entry menu or the results.

Before getting bogged down in this, I would say that the dates are currently not going to make a difference. I have just been labeling fossils to an Epoch when entering calibration and considering them text tags, since the precise dates of interest are in the min/max justifications.

My feeling is simply adding an Ediacaran Period is sufficient - I do not think we need to further divide this period up by stages. We currently have no calibrations older than Ediacaran, but we could in theory get one in the future. So, it may make sense to add the other ancient Periods. None need be further divided. They would be:

System Neoproterozoic
Ediacaran 541-635
Cryogenian 635-850
Tonian 850-1000

System Mesoproterozoic
Stenian 1000-2000
Ectasian 1200-1400
Calymmian 1400-1600

System Paleoproterozoic
Statherian 1600-1800
Orosirian 1800-2050
Rhyacian 2050-2300
Siderian 2300-2500

[jimallman]

I have just been labeling fossils to an Epoch when entering calibration and considering them text tags, since the precise dates of interest are in the min/max justifications.

Good point! The search actually returns results based on the hierarchy of nested time units and not on their assigned ages. So the ages are mostly used to properly order these periods in the Search-page menu.

So, it may make sense to add the other ancient Periods.

Again, the current menu (in Search page) is ordered chronologically, so this would add lots of "empty" periods at the top of the menu. But it's fairly easy to add these -- just let me know.

For now, I've added just the Ediacaran with the starting/ending ages above, and nudged the Cambrian Period (and relevant subdivisions) start time to 541 Ma.

[pdpolly]

@jimallman @Ksepka Good catch, Dan: the time scale currently in the database is GSA 2009. It dates to the first version of the FCD that I programmed sitting in an airport lounge without internet access. The only time scale on my hard drive was GSA 2009, so I used it.

I'm going to send the ICS 2014 time scale by e-mail as a replacement in a table with the same format. It is close to the Gradstein, but not exact. I prefer the ICS as the best international standard, but I leave it to Jim and Dan whether they prefer Gradstein.

BTW, looking at my files reveals that I was the one who introduced the System field. Good to know I can catch my own mistakes, even if it takes a couple of years.

[jimallman]

@pdpolly has provided the ICS 2014 time scale, along with some comments and questions (these and my responses copied here from email):

Here’s the ICS 2014 time scale. [not included in this GitHub issue] A few important notes:

1. The names of the geological units are different from what is currently in the FCD table. We’ll need to check whether any existing calibrations are associated with a deprecated unit. Jim A: can you run some kind of UNION query that will give us a list of all the geological units that have currently been linked to a fossil?

I would guess that some names and start/end ages have changed, yes? If a unit is recognizably “the same thing” — ie, if a given fossil would still be assigned from its old to new name + bounds — we can probably just leave the fossil data alon since the primary GeolTimeID should keep the right assignment.

In any case, I’ve run two queries that generated the attached files [not included in this GitHub issue]:

USED-geoltime-records.txt
This lists the 42 time units that are currently assigned to at least one fossil (of a total of 132 Ages, Epochs, and Periods).

UNUSED-geoltime-records.txt
This lists the remaining 90 time units that are not assigned to any fossil.

2. For the Precambrian, I rearranged the columns so that Period = Age, Era = Epoch, Eon = Era. This substitution follows the graphic representation of the ICS timescale (http://www.stratigraphy.org/index.php/ics-chart-timescale). This should be ok for FCD because we don’t report the hierarchy labels, so user will simply see Ediacaran, Neoproterozoic, Proterozoic, Precambrian…. unless some of the calibrations need to be assigned to a subunit within one of the Precambrian Periods.

I believe I understand. Essentially, you’re shifting all the columns (for Precambrian only) by two “ranks”, effectively trading unused small units for larger units like Eon. (Apparently there are two “layers” of Eon? Funky.)

We can certainly do this, since as you point out, the time-unit ranks (Age, Era, etc) should never appear in the user interface. It does mean that the Precambrian units will appear in the drop-down Geological Time menu, but indented as if they were the equivalent to the Periods, Epochs, and Ages below them. I’m guessing that’s not a big deal..?

Also, a reminder: Currently the coarsest time units do not currently appear in the drop-down menu — that is the Systems/Eras, and now also the coarsest Precambrian Eon will not appear. We’ve talked about adding these, but I can’t recall where we ended up.

[jimallman]

This issue highlights one of the difficult aspects of the FCDB project: Which data are "background" stuff that's unlikely to ever change, and which need user-friendly tools to maintain over time?

The former includes pretty static lists like:

• countries (e.g. 'Afghanistan')
• fossil locations relative to a calibrated node (e.g. 'Crown')
• phylogenetic justification types (e.g. 'Apomorphy')
• time scales (e.g. 'GSA 2009')

But it seems like everything else is likely to change over time, stuff like:

• fossil collections (acronyms and names)
• geological time units (names and bounding dates)
• the NCBI taxonomy

This naturally leads to "feature creep." I'm hesitant to propose an editor for the geological-time units, but I suppose a case could be made. As I've mentioned, these tables can also be modified using mysql command-line tools, or a web GUI like PHPMyAdmin. This should be done by fairly skilled hands, but it's not rocket surgery. Something to discuss, perhaps.

I'd like to postpone any further work on this issue until I can confer with @kcranston. For now, we have the Ediacaran in the latest Geological Time menu -- hopefully that will help with your immediate needs.

[Ksepka]

A few comments:

• For any data I have entered, I do not believe the name of the Geological Age would be different between GSA2009 and ICS2014 scales. So, they can all keep their Geological Ages regardless of where the numerical boundaries go.
• I don't think we need to add Systems / Eons. Too coarse to care about.
• It is not a big deal if Precambrian intervals are indented in a non-standard way.
• Currently the two key pieces of temporal data are housed in the minimum and maximum age fields. We don't explicitly tie these dates to the time scale anywhere. So, I feel the boundaries of the Geological Age dropdown are a "behind the scenes" aspect that will not be seen by the users in this generation. I feel it is not a major issue to worry about for launch but would like to hear others opinions. Making dates auto-shift with geological time scale updates is probably a second generation target.