[dataset]: LA MBON Benthic Core Samples 2023

[aalloilla]

Contact details

tsaari@tamu.edu

Dataset Title

LA MBON Benthic Core Samples 2023

Describe your dataset and any specific challenges or blockers you have or anticipate.

GCOOS is working with data on Louisiana benthic core sample data. The raw data is up on GCOOS ERDDAP. I will work on the DwC alignment of this data. I may need help with how to convert/include non-standard variables to DwC.

Info about "raw" Data Files.

The raw data is in the form of .csv files accessible via the ERDDAP file system (https://gcoos4.geos.tamu.edu/erddap/files/mbon_la_2023/). The variables include physical measurements, counts of various organisms in the samples, and descriptions of the sample and the environmental conditions.

[lukenoaa]

@ksil91 This might have eDNA data also.

[MathewBiddle]

FYI, I started poking around with the data hosted on ERDDAP. Should be relatively easy to finish up the DwC alignment.

See initial progress at https://github.com/MathewBiddle/bio_data_guide/blob/la_mbon_benthic_core/datasets/la_mbon_benthic_core/LA_MBON_Benthic_Core_Samples_2_DarwinCore.ipynb

ToDo:

1. Need to figure out a mapping for the following species:

Found 3 matches for Nemerteans
Found 0 matches for Oligochaetes
Found 0 matches for Bivalve
Found 2 matches for Ensis_minor
Found 3 matches for Nereis_splendida
Found 2 matches for Glycera_sp
Found 0 matches for Allia_quadrilobata
Found 0 matches for Allia_trilobata
Found 0 matches for Cumaceae_sp
Found 0 matches for Leech
Found 0 matches for Bug
Found 0 matches for Ephemeroptera_sp
Found 0 matches for Eel
Found 0 matches for Copepod

2. finish up occurrence core table
3. Add other data to eMoF
4. Create event table??

[sformel]

@aalloilla feel free to ping me too if you have questions about where to go next

[laurabrenskelle]

verbatimIdentification	scientificName	aphiaID	LSID	aphiaID_accepted	scientificName_accepted
Nemerteans	Nemertea	152391	urn:lsid:marinespecies.org:taxname:152391	152391	Nemertea
Oligochaetes	Oligochaeta	2036	urn:lsid:marinespecies.org:taxname:2036	2036	Oligochaeta
Bivalve	Bivalvia	105	urn:lsid:marinespecies.org:taxname:105	105	Bivalvia
Ensis_minor	Ensis minor	140734	urn:lsid:marinespecies.org:taxname:140734	140734	Ensis minor
Nereis_splendida	Nereis splendida	334198	urn:lsid:marinespecies.org:taxname:334198	334198	Nereis splendida
Glycera_sp	Glycera	129296	urn:lsid:marinespecies.org:taxname:129296	129296	Glycera
Allia_quadrilobata	Allia quadrilobata	421028	urn:lsid:marinespecies.org:taxname:421028	421028	Allia quadrilobata
Allia_trilobata	Allia trilobata	421030	urn:lsid:marinespecies.org:taxname:421030	421030	Allia trilobata
Cumaceae_sp	Cumacea	1137	urn:lsid:marinespecies.org:taxname:1137	1137	Cumacea
Leech	Hirudinea	2041	urn:lsid:marinespecies.org:taxname:2041	2041	Hirudinea
Bug
Ephemeroptera_sp	Ephemeroptera	235812	urn:lsid:marinespecies.org:taxname:235812	235812	Ephemeroptera
Eel	Anguillidae	125425	urn:lsid:marinespecies.org:taxname:125425	125425	Anguillidae

Here is my best attempt at resolving the aphiaIDs for the problematic identifications you mentioned, @MathewBiddle. I would definitely kick this back to the person who did the identifications from the core if possible to make sure I translated some of the verbatim values properly. I have to point out that "bug" has too many colloquial meanings, and I can't make a confident translation to any specific taxonomic term with that verbatim value. Also, Ephemeroptera refers to mayflies and these are identified as terrestrial/freshwater by WoRMS so this occurrence may not play nice in OBIS. I'm also not 100% sure that Anguillidae is the appropriate mapping for "eel" so, again, feedback from the identifier would be helpful.

[MathewBiddle]

CC: @fgayanilo @codewavenative

[codewavenative]

I’ve created a Colab notebook that fetches this dataset on ERDDAP and generates the required event.csv, emof.csv, and occurrence.csv files, including WoRMS taxonomic lookup.

https://colab.research.google.com/drive/1x1bJCcKLdaztjp0NTEiLHDa7qRNPd6U4?usp=sharing

[fgayanilo]

Very nice, now we only have to wait for the PIs to verify the 'unmatched' species.

@MathewBiddle @laurabrenskelle what is the protocol or next step if we do not have a WoRMS match?

[MathewBiddle]

@sformel any advice?

[laurabrenskelle]

@MathewBiddle @laurabrenskelle what is the protocol or next step if we do not have a WoRMS match?

I think you can use the fixed matches I gave in this table, which just leaves "Bug" without a match because this is a taxonomically ambiguous term. If the PI can't be more specific than "Bug" for these observations, I would drop those occurrence rows.

[sformel]

Very nice, now we only have to wait for the PIs to verify the 'unmatched' species.

@MathewBiddle @laurabrenskelle what is the protocol or next step if we do not have a WoRMS match?

I think you've done what you can and agree with Laura. One alternative to dropping them would be to identify them as 'Animalia' (unless bug might mean bacteria!). This doesn't give very useful information to most people, but it leaves a placeholder record that could be improved by the identifier in the future.

[fgayanilo]

We were able to work with the PI (she is very responsive), but I like the idea of having a category "Animalia' for others that cannot be identified. The PI re-labelled the bug to Insecta, an alternative to Animalia, as proposed by Laura. We should have the data ready for IPT very soon.

[MathewBiddle]

@fgayanilo provided some test files. Below are the files some of my comments.

First off, fantastic job. For the most part, these are about ready to be added to the IPT!

occurrence.csv
event.csv
emof.csv

Event file

• The unique eventIDs in your occurrence file do not match the number of unique IDs in your event file. Somehow you ended up with more events than occurrences observed. I see you are using uuid to generate these identifiers, when trying to debug some of these nuances it's a little easier when the ID's are something a human can read. For example, MBON_LA_nemertea_2023-04-20T11:04:00Z_Barataria_BB1_R1_sub2, then you can figure out where the additional eventID values in the event file are coming from.
  • len(df_occur['eventID'].unique()) = 331
  • len(df_event['eventID'].unique()) = 405
• The following columns could be mapped to the following DwC event core terms. Or you could concatenate them all into one long coherent string and put it in eventRemarks.

event col name	proposed event col name
'basin'	waterBody
'site'	eventRemarks
'replicate'	eventRemarks
'sample_method'	samplingProtocol
'weather'	eventRemarks
'wind'	eventRemarks
'sediment'	habitat
'high_organic'	eventRemarks

Occurrence extension

• What is the acceptedID column? I don't think that is a valid Darwin Core term.
• No need to add columns for acceptedName | phylum | class | order | family | genus as those are already handled by the scientificNameID.
• Similar comment about the eventID and occurrenceID here as above.

Extended measurement or fact extension

• If possible, it would be beneficial to include more information in the measurementType column. Folks might not know what DO or surf_chlor means. Adding human readable text here is beneficial (think similar to long_name attribute in netCDF)
• As a bonus, it would be super beneficial to include identifiers to controlled vocabularies for the different measurementType and measurementUnit. These would be held in new columns measurementTypeID and measurementUnitID and would include uri's to specific terms in a controlled vocab. Typically we've been pointing folks to use the NERC Vocabulary Server (NVS).
  An example:

eventID	measurementType	measurementValue	measurementUnit	measurementTypeID	measurementUnitID
52c2f822-13e4-488e-b4c0-ffdf8f780a1a	Dissolved Oxygen	8.64	mg/L	http://vocab.nerc.ac.uk/collection/P02/current/DOXY/	http://vocab.nerc.ac.uk/collection/P06/current/UMGL/

[sformel]

Form a quick look, it seems like there is no difference between the accepted columns and the valid DwC columns. But if you wanted to add that in the case of scientificName, don't forget that verbatimIdentification can be used to describe initial ID. If it's more complex than that, consider the Identification History extension.

I agree with Matt's assessment on some of these terms for mapping, but others might be more effectively shared through eMoF. To be clear, I don't want precision to get in the way of getting this data out there, so take my advice with a grain of salt.

event col name	proposed event col name	suggestion	suggested identifier
'basin'	waterBody
'site'	eventRemarks	may be more effectively conveyed through structured events + eventType
'replicate'	eventRemarks	may be more effectively conveyed through structured events + eventType
'sample_method'	samplingProtocol
'weather'	eventRemarks
'wind'	measurementType	Map to P01 vocab	http://vocab.nerc.ac.uk/collection/P01/current/WMOCWFBF/
'sediment'	habitat	also Map to CMECS in eMoF	for example sandy == https://w3id.org/CMECS/CMECS_00001676
'high_organic'		Map to CMECS in eMoF	for example: yes, high organic + sediment == muddy use: https://w3id.org/CMECS/CMECS_00000611 no, high organic + sediment == muddy use: https://w3id.org/CMECS/CMECS_00000576