Understanding the difference between recordID and occurrenceID

[mpitblado]

Good morning everyone,

I was hoping for some help understanding the difference between how Symbiota uses occurrenceID and recordID.

Current interpretation

1. occurrenceID is intended to be used as defined in dwc::Occurrence::occurrenceID.
2. occurrenceID is able to be used through the occurrence api route (occurrence/{occurrenceID})
3. recordID is generated automatically by symbiota upon record creation, it follows the UUID 4 specification
4. If no occurrenceID already exists, recordID will be copied to occurrenceID.

Questions

1. What is the conceptual and technical purpose of having a recordID separate from occurrenceID?
2. What is the mutablity of both recordID and occurrenceID (i.e. can they be edited, and, if so, by whom)

[themerekat]

Great questions, @mpitblado !

In the database, occurrenceID and recordID are separate fields in the omoccurrences table. OccurrenceID is editable in the user interface (see the occurrenceID Override field in the occurrence editor). RecordID is not editable by anyone in any front-end interface. When the data are presented (i.e., in the public display) or downloaded, the value shown as the dwc:occurrenceID depends on the collection's specification:

• If a snapshot collection, occurrenceID = occurrenceID field
• If a live-managed collection, the collection can choose between (a) occurrenceID = occurrenceID field (first option in the image below), (b) occurrenceID = catalogNumber field (second option below, not recommended), or (c) occurrenceID = occurrenceID field if full, but if NULL, recordID (third option in the image below)
  

I'm not 100% sure why this is the case, but it might relate to your question #2. There are no interfaces for editing or overwriting the value for recordID, but occurrenceID is like any other field, so it can be edited. Having the recordID field separate from the occurrenceID field ensures that we have a safe unique identifier for live-managed collections.