Difference between revisions of "Category talk:Lake Sediments Working Group"
SimonGoring (Talk | contribs) (→How should we report depth -- ~~~~: new section) |
(→How should we report depth -- SimonGoring (talk) 11:33, 29 September 2016 (PDT)) |
||
Line 22: | Line 22: | ||
Maybe it's the "standards" term, maybe it's better to describe "best practices"? | Maybe it's the "standards" term, maybe it's better to describe "best practices"? | ||
+ | |||
+ | ===Re: How should we report depth - Standard vs best practices -- [[User:Jeg|JEG]] ([[User talk:Jeg|talk]]) 20:49, 29 September 2016 (PDT)=== | ||
+ | |||
+ | Thank you for initiating this. As someone who helps build ontologies, I'd be the first to agree that names matter. At the workshop we floated the idea of separate standards for legacy and new data. In my view, the standard for new data should be there to stimulate best practices. My $0.02. |
Revision as of 03:49, 30 September 2016
How should we report depth -- 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"?
Re: How should we report depth - Standard vs best practices -- JEG (talk) 20:49, 29 September 2016 (PDT)
Thank you for initiating this. As someone who helps build ontologies, I'd be the first to agree that names matter. At the workshop we floated the idea of separate standards for legacy and new data. In my view, the standard for new data should be there to stimulate best practices. My $0.02.