Linked Earth Wiki - User contributions [en]

Category talk:Chronologies Working Group

2016-09-29T18:50:31Z

SimonGoring: /* 14C recomendations -- ~~~~ */ new section

== 14C recomendations -- [[User:SimonGoring|SimonGoring]] ([[User talk:SimonGoring|talk]]) 11:50, 29 September 2016 (PDT) ==

There are more recomendations in Grimm et al., coming out of the 2014 Belfast workshop:

http://www.pages-igbp.org/download/docs/calendar/2014/Age%20Models,%20Chronologies,%20and%20Databases%20Complete%20Report.pdf

This addresses the issues with Age Model version reporting. For example:

> The program versions, metadata, and ideally scripts should be stored to enable reproduction of chronologies

> It is recommended that producers of age modeling software provide all data necessary for reproducing chronologies in easily storable scripts or “age model definition” files.

> Instantaneous sedimentation events (slumps, thick tephras), hiatuses, and sharp changes in sedimentation rate create difficulties for classical single-solution age models, and investigators have often created ad hoc chronologies for these situations. Chronologies from these age models are particularly challenging to reproduce. It is recommended that developers of age modeling software formally incorporate these situations into their
modeling framework. Some programs already do.

Simon Goring

2016-09-29T18:37:24Z

SimonGoring: Added PropertyValue: Subscribes To = Category:Chronologies_Working_Group

[[Category:Person_©]]{{#set:
Current Affiliation=University of Wisconsin - Madison|
Current Position=Assistant Scientist|
Email ©=goring@wisc.edu|
Expertise=Paleoecology,_pollen,_Neotoma_related_records|
Github ID=SimonGoring|
Has User ID=SimonGoring|
Name ©=Simon Goring|
OrcidNumber ©=0000-0002-2700-4605|
Subscribes To=Category:Chronologies_Working_Group|
Subscribes To=Category:Lake_Sediments_Working_Group|
Twitter ID=@sjGoring|
Website=http://goring.org}}

Simon Goring

2016-09-29T18:37:14Z

SimonGoring: Added PropertyValue: Subscribes To = Category:Lake_Sediments_Working_Group

[[Category:Person_©]]{{#set:
Current Affiliation=University of Wisconsin - Madison|
Current Position=Assistant Scientist|
Email ©=goring@wisc.edu|
Expertise=Paleoecology,_pollen,_Neotoma_related_records|
Github ID=SimonGoring|
Has User ID=SimonGoring|
Name ©=Simon Goring|
OrcidNumber ©=0000-0002-2700-4605|
Subscribes To=Category:Lake_Sediments_Working_Group|
Twitter ID=@sjGoring|
Website=http://goring.org}}

Simon Goring

2016-09-29T18:37:01Z

SimonGoring: Added PropertyValue: Website = http://goring.org

Simon Goring

2016-09-29T18:36:52Z

SimonGoring: Added PropertyValue: Github ID = SimonGoring

Simon Goring

2016-09-29T18:36:47Z

SimonGoring: Set PropertyValue: Twitter ID = @sjGoring

Simon Goring

2016-09-29T18:36:43Z

SimonGoring: Added PropertyValue: Twitter ID = sjGoring

Simon Goring

2016-09-29T18:36:38Z

SimonGoring: Added PropertyValue: Current Position = Assistant Scientist

Simon Goring

2016-09-29T18:36:33Z

SimonGoring: Added PropertyValue: Current Affiliation = University of Wisconsin - Madison

[[Category:Person_©]]{{#set:
Current Affiliation=University of Wisconsin - Madison|
Email ©=goring@wisc.edu|
Expertise=Paleoecology,_pollen,_Neotoma_related_records|
Has User ID=SimonGoring|
Name ©=Simon Goring|
OrcidNumber ©=0000-0002-2700-4605}}

Paleoecology, pollen, Neotoma related records

2016-09-29T18:36:09Z

SimonGoring: Creating new page

[[Category:Expertise]]

Simon Goring

2016-09-29T18:36:09Z

SimonGoring: Added PropertyValue: Expertise = paleoecology, pollen, Neotoma related records

[[Category:Person_©]]{{#set:
Email ©=goring@wisc.edu|
Expertise=Paleoecology,_pollen,_Neotoma_related_records|
Has User ID=SimonGoring|
Name ©=Simon Goring|
OrcidNumber ©=0000-0002-2700-4605}}

Simon Goring

2016-09-29T18:35:45Z

SimonGoring: Added PropertyValue: Name © = Simon Goring

[[Category:Person_©]]{{#set:
Email ©=goring@wisc.edu|
Has User ID=SimonGoring|
Name ©=Simon Goring|
OrcidNumber ©=0000-0002-2700-4605}}

Simon Goring

2016-09-29T18:35:38Z

Simon Goring

2016-09-29T18:35:10Z

Simon Goring

2016-09-29T18:34:48Z

SimonGoring: Added PropertyValue: Has_User_ID = SimonGoring

Simon Goring

2016-09-29T18:34:47Z

Category talk:Lake Sediments Working Group

2016-09-29T18:33:53Z

SimonGoring: /* How should we report depth -- ~~~~ */ new section

== How should we report depth -- [[User:SimonGoring|SimonGoring]] ([[User talk:SimonGoring|talk]]) 11:33, 29 September 2016 (PDT) ==

I think this isn't necessarily the right framing. The question should start with "how is depth reported".

There is legacy data in Neotoma (for example) that uses top or midpoint, but the depth basis isn't always clear. My preference would be to see both a depth field and a second "depthSectionBasis" field that would indicate "top" or "midpoint", followed with "thickness". From this you would then be able to obtain either top/bottom or midpoint, depending on your preference.

It would also allow you to manage legacy data, since these would not have the assigned "depthSectionBasis" terms. People could either revisit the primary literature and add the field, or you could treat "blank" fields in some special way.

The second element here seems to be that you haven't discussed depthBasis (I'm sure you've got a term somewhere). What is the depth baseline? Some of the cores in Neotoma use a depthBasis from the Lake Surface. This means they start at 2+m in some cases. This would also need to be defined in this schema.

In Goring et al., 2012 we specifically used only depth (and then the related geochronological data), from records that used pollen as a sensor.

We needed:

* sediment surface depth
* sample depth
* sample thickness

In a second proposal we suggested also knowing the basis of the depth measurement - is this from a single drive, or a composite record. Then you'd need to know the method for record alignment, the identity of the "upper" core section (possibly the identity of the next core section, but you could get that with a reverse lookup), the depth of alignment with the upper core section, & the depth of alignment within the target core section.

I'm worried by some of the conversation that says "we need to establish a standard", the standard should be full reporting, not stating that something is measured from lake floor. If we apply a standard then we fail with legacy data where reporting may not be fully describing the record.

Maybe it's the "standards" term, maybe it's better to describe "best practices"?

User:SimonGoring

2016-06-23T21:51:27Z

SimonGoring: create user page