Overall: Variable naming conventions

[emilyarobles]

@regnans
Overall, I recommend revisiting the naming conventions used for variables throughout the format templates. The CSV reporting format recommends against using camel case for field names, and we've found that capitalization in names often leads to inconsistencies when users complete their own datasets.

Using the Campaign Summary file as an example, this could include replacing "Project" with "project," "locationDescription" with "location_description." Let me know your thoughts on this.

[regnans]

I think that this standardization is a good idea, but having gone through the process of developing this format, I am not in the position to review all of the variable cases. At the start of this project I did review what other formats were using, and it was a mix, and we did not receive any specific guidance. With the examples you include above, both of those variables were drawn directly from existing ESS-DIVE formats (package metadata and Sample-ID), so that is why they are presented in the way they are. At this point I can review a few variables that you consider are key for functionality or discoverability, particularly if there is already consistency across all of the formats, and this is the only different one, but aside from that I think that achieving variable naming consistency across the formats is a separate project and out of scope of what I can deliver with the UAS format.

[emilyarobles]

@regnans
This makes sense - I wanted to suggest it since we have plans to address convention standardization across the RFs and making a move to lowercase/snake case in the future, and in case you wanted to make any revisions now. However, as you pointed out, this is an issue that many of the formats have and not a firm requirement at this stage.