Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deployment date range issues #11

Open
albenson-usgs opened this issue Oct 24, 2018 · 5 comments
Open

Deployment date range issues #11

albenson-usgs opened this issue Oct 24, 2018 · 5 comments

Comments

@albenson-usgs
Copy link
Contributor

albenson-usgs commented Oct 24, 2018

What should deployment date range be populated with if you don't know when the deployment ends? Should it have a date range? If so, what do you put as the end date? What happens if the animal is not recaptured?

@jdpye
Copy link
Member

jdpye commented Oct 24, 2018

In my world, things like estimated battery life are necessarily fuzzy and shouldn't be taken as hard end-dates. Other tags are hard-programmed to be shut off at date X.

Further to not knowing about an end date at all, what should we do if we have a general idea but not a specific one? Especially looking for an option that doesn't upset ISO standards.

@albenson-usgs
Copy link
Contributor Author

Once a decision is made on this, the wiki needs to be updated with that information in the Data Guidelines section under eventDate.

@peggynewman
Copy link

It seems sensible that the guidelines point out the way in which it was determined that the deployment ended, or even if it did at all.

@sarahcd
Copy link

sarahcd commented Sep 11, 2019

If we want/need to include an end date for a track, realistically that date will commonly represent many different things:

  • the removal of the tag by a human,
  • a scheduled automated release,
  • the last available data point,
  • the end of the time the data can be reliably associated with the live animal,
  • the time that the animal is captured or confined (even if the tag remains attached),
  • the end of a segment of data that is meaningful to the data owner (e.g. the end of a foraging trip, migration, or experimental run, like a homing flight)

When dealing with bio-logging data, typically a specific end datetime needs to be chosen to define which data records to include/exclude even if, say, the likely date of death remains fuzzy.

I agree we need a guideline and examples for this. One idea is to recommend creating an event and occurrence for the end of each track with

  • an ISO compliant timestamp
  • describe the type of deployment end in occurrenceRemarks (Occurrence table) and eventRemarks (Event table)

We could also propose a controlled list. In Movebank we have deployment-end-type with options captured, dead, equipment failure, fall off, released, removal, unknown, described at
http://vocab.nerc.ac.uk/collection/MVB/current/MVB000084/
I don't think these options are complete, so if we came up with an improved list I could update our vocabulary too. In this case we'd want a place for a controlled value and a place for other notes.

@jdpye
Copy link
Member

jdpye commented Sep 11, 2019

Love the idea of a controlled list for these, I'll see if I have anything that falls outside of the stated examples, to help extend the vocab.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants