search

tdwg / dwc-for-biologging

Darwin Core recommendations for biologging data
Creative Commons Attribution 4.0 International
13 stars 3 forks source link

Release events #14

Open peterdesmet opened 5 years ago

peterdesmet commented 5 years ago

@jdpye we're running into a problem with separate capture and release events. In your use case you describe a release event and note:

NB: the release Event record does not represent a distinct Occurrence record from the capture event. Holding periods, movement of the animal while captured, and other confounding circumstances preclude this record from being considered a natural occurrence of the animal. See: Béguer-Pon et al. ...

So an Event without an associated occurrence. Or if one is associated, it is the capture occurrence.

I can agree with that, but how do you relate that Event to the animal in question? I think you tried to solve this with an occurrenceID in your Event (see your table):

Defined by the capture event, Relates this record to the prior capture event of this animal

But an occurrenceID is not one of the fields available in Event. 😄

jdpye commented 5 years ago

I thought occurrenceID was available in Event, and that was our little innovation on the case 6 De Pooter scheme. Hmm.

Barring that, the only other authoritative field we could use to solve this would be organismID? How else to clarify that the animal is present, but only because we put them there.

peterdesmet commented 5 years ago

organismID is a property of Occurrence (well, Organism actually) as well and thus not in the Event Core either. The only solution I see is to create a related Occurrence: yes, we put it there, but it was there, with the intent for it to swim away from that location?

We have the same problem with surgery/tagging, which is another separate Event. So the order is: Capture > Surgery/tagging > Release. They are all about the same animal, so the only way to express that is by having associated occurrences I think.

jdpye commented 5 years ago

That's about the right tack for the Occurrence in question to take, but now we have this class of Occurrences that most people doing analyses might prefer to avoid harvesting alongside the natural ones.

Antonarctica commented 5 years ago

I thought occurrenceID was available in Event, and that was our little innovation on the case 6 De Pooter scheme. Hmm. The invention there was to have both an eventID and an occurrenceID in (extended) Measurement or fact. So in that way of working you would still need to have an occurrence extension and a EMoF extension. OrganismID would then be part of the occurrence extension.

I though in another tread (or a discusion with Peter in person). is that they differentiate between handling event and tag reported observations by using humanobservation and machineobservation For BasisOfRecord. but that might not be the solutions your looking for...

peterdesmet commented 5 years ago

@antonarctica that is correct. So the solution I see is:

Capture

Tagging/surgery

Release

Detections

peterdesmet commented 5 years ago

We could use LivingSpecimen to indicate those occurrences that are not natural. Those basisOfRecords are known to be avoided when modelling. I’ve updated the example above. But would also like to get @tucotuco’s take on this.

The alternative is just calling the first 3 HumanObservations, which makes it less complicated.

sarahcd commented 5 years ago

'not natural' occurrences can also include the machine observation events. should we have one of our use cases be an experimental dataset to get through how to deal with that? the HumanObservation solution seems worth trying for this example.

peterdesmet commented 5 years ago

You are right, it’s for MachineObservations too. Then I suggest to express the above as HumanObservations (that’s what they are) and find another way/term to express that they are “not natural”

peterdesmet commented 5 years ago

“establishmentMeans: managed” comes to mind.

sarahcd commented 5 years ago

establishmentMeans looks good. I'd need some terms outside that controlled vocabulary, e.g. to cover relocations, e.g. homing experiment = introduced? reintroductions = also introduced? other experimental manipulations, e.g. to test hypotheses about olfactory or magnetic field influences on navigation = ??? Looks like we could use free text, might want to think through use cases and consider proposing 1-2 new terms to the controlled list that might be mostly specific to tracking-type data. Sorry, we've published data from lots of homing pigeon studies :)

tucotuco commented 5 years ago

Hi folks. Sorry for the delay. It seems to me that the capture would be a LivingSpecimen too, with the establishmentMeans being appropriate to show if it was taken from the wild or not. While in hand I would use "captive" for establishmentMeans. Other than that, it all makes sense to me.

jdpye commented 5 years ago

Using the term 'captive' is very attractive to me as well, and covers most of my constituency's weird cases (holding periods, transportation, etc.)

peterdesmet commented 5 years ago

I like establishmentMeans:captive too, but would keep basisOfRecord:HumanObservation for all pre-detection records.

I know I suggested LivingSpecimen before, but I think it will make everything needlessly complicated. For other (observation) datasets we publish, we also have occurrences were animals (insects, etc.) were captured in the wild, identified, and then released or ended up dead. We always assign HumanObservation to these, as these don't end up as a living or dead specimen in a collection or we don't have information about it. LivingSpecimen for me implies collection management (and information about it), which is not the case here. @tucotuco and co, would you be fine with that?

tucotuco commented 5 years ago

Actually, yes, that sounds quite sensible to me.

On Fri, Apr 12, 2019 at 5:41 AM Peter Desmet notifications@github.com wrote:

I like establishmentMeans:captive too, but would keep basisOfRecord:HumanObservation for all pre-detection records.

I know I suggested LivingSpecimen before, but I think it will make everything needlessly complicated. For other (observation) datasets we publish, we also have occurrences were animals (insects, etc.) were captured in the wild, identified, and then released or ended up dead. We always assign HumanObservation to these, as these don't end up as a living or dead specimen in a collection or we don't have information about it. LivingSpecimen for me implies collection management (and information about it), which is not the case here. @tucotuco https://github.com/tucotuco and co, would you be fine with that?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tdwg/dwc-for-biologging/issues/14#issuecomment-482490810, or mute the thread https://github.com/notifications/unsubscribe-auth/AAcP6wKJrV72GkN-0AsxUhOM3vzUxVpZks5vgEahgaJpZM4cXtRp .