arctos: no accepted georeferences

[MortenHofft]

@dustymc The location table should most likely fill accepted_georeference_id. Many of the locations have a georeference, but it isn't listed as accepted. So unless they are explicitly discarded/mistrusted georeferences, then accepted_georeference_id should be filled.

See comment that explains when accepted_georeference should be filled

I'm not sure about how this relates to the georeference_verification_status on occurrences. I notice that the wast majority of occurrences have status: unverified. But even those that are listed as accepted have noaccepted_georeference_id.

@tucotuco you might be able to untangle this. I'm not sure what the correct use is.

[dustymc]

accepted_georeference_id

possibly understood and tentatively corrected: I've just mapped georeference. georeference_id and location. location_id to share the same value (because they're part of the same object before being ripped apart for the GUM).

[tucotuco]

Though this won't break anything in the current model or exercise, it isn't rigorously correct in the Unified Model because a Location is modeled as a place and a Georeference as an interpretation of the place as a spatial description. In other words, they are different concepts (classes) and if this ever moved into a semantic realm there would be a logical inconsistency between the two.

@dustymc That having been said, the reason the Georeferences are separate from the Locations in the Unified Model was specifically to handle Arctos. So what did I get wrong?

Can a cataloged item have several Locations in Arctos?

[dustymc]

Georeference as an interpretation of the place as a spatial description

Descriptive data aren't (necessarily) primary, coordinates aren't (necessarily) derived, it's just all different ways of saying "there" - and so we made that the Arctos model. (It's also very good at preserving history and such, but that part wasn't so intentional.)

Can a cataloged item have several Locations in Arctos?

Yep, and in case we could somehow be more clear there are primarily two ways in which this happens.

1. Whatever's represented by the catalog record got around. Mark-recapture, cultural items being made/used/collected, etc., etc. Probably nothing too shocking here, we have one hypothesis regarding where each event occurred.
2. Multiple opinions. Most common use case is that the label data get shipped off for some georeferencing project, we get some stuff back, sometimes it's right, sometimes lichens go pelagic, we now have multiple opinions about where a single (usually...) even occurred, (generally) all with "IDK" as verificationstatus.

[tucotuco]

Given this, in a future iteration of the model I would subsume Georeference back into Location as there is no longer a use case for the separation. This is a very useful outcome.

[tucotuco]

Ah, with the accompanying conclusion that it is fine to use the location_id for the georeference_id.

[tucotuco]

The accepted_georeference_id is now populated whenever appropriate. Closing issue.