Release events

[peterdesmet]

@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]

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]

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]

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]

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]

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

Capture

• Event: capture time and place
• Occurrence: HumanObs for captured animal in the wild / LivingSpecimen for animal grown in hatchery
• eMoF: facts about capture and animal, e.g. body measurements

Tagging/surgery

• Event: surgery time and place (often same as capture)
• Occurrence: LivingSpecimen for same animal, because its location is decided by humans
• eMoF: facts about surgery and tag added

Release

• Event: time and place of release (often after some holding period and at different location)
• Occurrence: LivingSpecimen for same animal, because its location is decided by humans
• eMoF: facts about release

Detections

• Event: some way of defining deployments (of receivers or tags?)
• Occurrence: MachineObs of animal for every detection
• eMoF: facts about detection or deployment event

[peterdesmet]

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]

'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]

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]

“establishmentMeans: managed” comes to mind.

[sarahcd]

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]

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]

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]

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]

Actually, yes, that sounds quite sensible to me.

…

On Fri, Apr 12, 2019 at 5:41 AM Peter Desmet ***@***.***> 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 <#14 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAcP6wKJrV72GkN-0AsxUhOM3vzUxVpZks5vgEahgaJpZM4cXtRp> .