Dataset - Nearshore Macrophyte Stable Isotopes - BC Central Coast

[hakai-it]

Nearshore Macrophyte Stable Isotopes - BC Central Coast

https://cioos-siooc.github.io/metadata-entry-form/#/en/hakai/Q7WjoEJM1Sc9HrFLJCRgKAtMzTH2/-NsA_gSeGW0tjiLNE8PB

Best Practices Checklist

In General

• No previous versions of this metadata record exist (eg for earlier versions of the data, if so update that record rather than creating a new one)

Data Identification

Dataset title:

• No version information in the title
• Frontloaded (with the most important information first)
• Include the geographical region the data apply to
• Short – aim for 60 characters including spaces
• Does not include acronyms – put these in the keywords
• Does not include the word “dataset”
• Time series datasets should include “time series” at the end of the title

Abstract

• Abbreviations have been expanded upon at first mention
• Abstract describes how, when, what, where, why of data collection and is limited to no more than 500 words

DOI

• A DOI has been drafted for this record
• DOI has been updated via the form after review and changes to record
• DOI has been manually edited on datacite fabrica
• DOI status has been changed from Draft to Findable

Spatial

• Ensure that Depth or Height Positive is correctly selected

Contact

• ROR and ORCID(s) are included and linked properly where applicable
• For datasets where DFO is a partner, ensure 'parent' ROR is added (https://ror.org/02qa1x782). DFO 'child' organizations (i.e. CHS) and their ROR are optional.
• Include Hakai Institute as Publisher and include data@hakai.org as email
• Make sure email address is provided if the role is 'Metadata Custodian' or 'Point of Contact'
• Add contact affiliation where known including ROR
• If resource is (partially) generated by Hakai researchers, include 'Tula Foundation' (with associated ROR) with 'Funder' role. Be sure to uncheck 'include in citation' for Tula Foundation.

Resources

• Resource links go to specific dataset download (not generic platform like waterproperties.ca)
• Readme, changelog, data dictionary, protocols included in data-package (for tabular text based data)
• An archive folder, or other means, for older data versions is included in the data package if the version is not 1.0
• Links work
• All files in the data package can be opened and are not corrupt
• No executable files in the data package. Files should be open formats and standards (.csv, .txt for example)

[timvdstap]

@Tyr30 This outstanding issue caught my attention. Please note that the link above is outstanded, but there seem to be three related records:

In draft:

• Nearshore Macrophyte Stable Isotopes - BC Central Coast (Copy): This is for version 1.1.0 -- the published version (1.0.1) is listed below.
• Nearshore Macrophyte Stable Isotope - BC Central Coast

Published:

• Nearshore Macrophyte Stable Isotope - BC Central Coast. I think that the published version captured the data from 2014 - 2019, which is recorded in Dataset - Nearshore Macrophyte Stable Isotopes - BC Central Coast - 2014-2019 #57 right?

I'm guessing that

1. the copy in 'Draft' can be removed?
2. Did you intend to update the version of the published record to 1.1.0?

[Tyr30]

Hey @timvdstap, sorry for this confusing mess! The draft dataset (1.1.0) is the current version, it's meant to be updated to that. I can go through and double check it's all good.

[Tyr30]

It wasn't any changes to the data. I updated the taxonomic coverage, contact list, and a few other things.

[timvdstap]

Thanks for looking into it @Tyr30 ! Just to confirm with you though:

• Do you intend for there to be two separate metadata records in the Hakai Catalogue, one for version 1.0.1. and another for 1.1.0? If data collection and processing methods are the same across versions, as well as contributors/authors (which it seems like there is), it's recommended to update only the published record to reflect the latest version, and populate the 'revised date' field under 'Resource Identification' to show the date when the newest version was published.

I would recommend this because currently the DOI (10.21966/q31x-qg72) is linked to both the published record (version 1.0.1 - here) and the submitted record (version 1.1.0 - here) even though it lists the same authors and covers the same timeframe.

So my proposal would be:

• Remove the copy record as it adds a bit of confusion (at least on my end)
• make sure that the metadata information currently in the submitted version 1.1.0 is migrated over to the published record (given that you're the author of the record you should be able to make changes to it directly)
• populate 'revision date' field to indicate when the repository that includes 1.1.0 data package was made public
• make sure that the primary resource link points to the correct data package
• ping me and I can review that updated record
• once verified that the published record is accurate and points to version 1.1.0 data package, we can remove the submitted record.

What do you think about that?