You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks @peterdesmet. I've made these changes for V3 of the Mahoney use case. Should we come up with a controlled list of samplingProtocol values for our bio-logging guidelines? I'm now using capture, bio-logging sensor recovery, bio-logging sensor deployment. (Note I don't have separate capture & release events associated with the start of deployment.)
I'm (shamelessly) using all these refinement suggestions to make a better blue shark product today. I really appreciate the work @sarahcd put into this example, and the digging and refinement suggestsions that @peterdesmet 's laying out here. It'll go a long way to making my default OTN data product better.
In "Mahoney-data-DwC-A-test-2" currently used to differentiate between elements, but should stick to http://dublincore.org/documents/2010/10/11/dcmi-type-vocabulary/, more restricted https://dwc.tdwg.org/terms/#dcterms:type or actually just
Event
for everything. The current values could be moved elsewhere as follows:capture
: samplingProtocolcapture
recovery
: samplingProtocolrecovery
deployment
: samplingProtocolgps tracker deployment
or similar. More details about the sampling could be described the MOF, see Where to describe equipment and protocol used for machine observations #10measurement
: these records should be removed, see Associate acceleration measurements to deployment, not to separate event for each #6gps fix
or similarThe text was updated successfully, but these errors were encountered: