Arctos Power Georeferencers (returning to who georeferenced that locality and when?)

[Jegelewicz]

If you want the long history - read ArctosDB/arctos#1705

Today during office hours we worked our way from geography to locality and georeferencing. It still bothers me that it is not easy to see who assigned coordinates to any specific locality and that in some cases the locality change history can be misleading. If I edited the locality using someone else's georeference everyone will only see my name associated with the change. The separation between any given locality and the "verification status" of an event seems far to large to connect the event assigner with the georeferencing (and nobody outside of Arctos would ever get that?).

It appears to me from the final comment in ArctosDB/arctos#1705 that the intended answer to this issue was to create a locality attribute. I am not sure that would solve the problem, but maybe it would be enough. Let the discussion begin. @wellerjes @jebrad @campmlc

[DerekSikes]

I've long been in favor of something like this. I want to know who decided those lat/longs belong to that place name.

Attributes could work - name, date, remarks... people could leave comment attributes perhaps? If disagreement arose about a place a comment could be left to explain the solution - eg multiple localities for this place name exist because we need each with different coordinate uncertainty values (which may stem directly from different collection methods, eg, I collected this fly exactly here vs I collected this fly somewhere within 1km of here). etc.

-D

On Tue, Jul 26, 2022 at 12:38 PM Teresa Mayfield-Meyer < @.***> wrote:

If you want the long history - read ArctosDB/arctos#1705 https://github.com/ArctosDB/arctos/issues/1705

Today during office hours we worked our way from geography to locality and georeferencing. It still bothers me that it is not easy to see who assigned coordinates to any specific locality and that in some cases the locality change history can be misleading. If I edited the locality using someone else's georeference everyone will only see my name associated with the change. The separation between any given locality and the "verification status" of an event seems far to large to connect the event assigner with the georeferencing (and nobody outside of Arctos would ever get that?).

It appears to me from the final comment in ArctosDB/arctos#1705 https://github.com/ArctosDB/arctos/issues/1705 that the intended answer to this issue was to create a locality attribute. I am not sure that would solve the problem, but maybe it would be enough. Let the discussion begin. @wellerjes https://github.com/wellerjes @jebrad https://github.com/jebrad @campmlc https://github.com/campmlc

— Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/4866, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACFNUM2MTKLP6HOH2UIAM6DVWBEELANCNFSM54XIH7IQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

--

+++++++++++++++++++++++++++++++++++ Derek S. Sikes, Curator of Insects, Professor of Entomology University of Alaska Museum (UAM), University of Alaska Fairbanks 1962 Yukon Drive, Fairbanks, AK 99775-6960 @.*** phone: 907-474-6278 he/him/his University of Alaska Museum https://www.uaf.edu/museum/collections/ento/

• search 357,704 digitized arthropod records http://arctos.database.museum/uam_ento +++++++++++++++++++++++++++++++++++

Interested in Alaskan Entomology? Join the Alaska Entomological Society and / or sign up for the email listserv "Alaska Entomological Network" at http://www.akentsoc.org/contact_us

[dustymc]

intended answer to this issue was to create a locality attribute.

Yes, that's my recommendation.

I am not sure that would solve the problem,

Adding one locality attribute solves the problem, whatever it is, to precisely the same extent that adding columns to the table could, but it doesn't force anyone else to denormalize (=deal with lots of spatially-identical data objects).

I'm not sure what another extent might do, but as an attribute it can't force denormalization on others so I'd probably be OK with that too.

[campmlc]

I still feel this is more important than attributes. It shouldn't be optional. It should integrated into the model like we do with identification - we should have integrated metadata for who IDd, when, remarks.

On Tue, Jul 26, 2022, 7:32 PM dustymc @.***> wrote:

• [EXTERNAL]*

intended answer to this issue was to create a locality attribute.

Yes, that's my recommendation.

I am not sure that would solve the problem,

Adding one locality attribute solves the problem, whatever it is, to precisely the same extent that adding columns to the table could, but it doesn't force anyone else to denormalize (=deal with lots of spatially-identical data objects).

I'm not sure what another extent might do, but as an attribute it can't force denormalization on others so I'd probably be OK with that too.

— Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/4866#issuecomment-1196168788, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBCH2BZ3EWSUDFVEJDDVWCGQ7ANCNFSM54XIH7IQ . You are receiving this because you were mentioned.Message ID: @.***>

[wellerjes]

I still feel this is more important than attributes. It shouldn't be optional.

Agreed. I want this information to be connected with the locality.

When we have a locality shared by more than one institution, we either clone or fork-edit to create a separate locality ID for just our collections. However, we tend to work on one collection at a time, so something that has the same locality (i.e., a specific city) in one collection could be just a decimal place off in another collection. It would be great to have some kind of consistency with locality georeferencing within all collections within a single institution.

[Nicole-Ridgwell-NMMNHS]

Could name and date be added to Georeference Source and have the history of that field either show up on the locality page, or accessible via link? I agree that the advantage of it being a main field is that we can make it required.

[ccicero]

Agreed, we need to resurrect the who/when part of the georeferencing process (required). I like the suggestion of adding the metadata to Georeference Source.

[dustymc]

more important than attributes

Perhaps this is the same view that lead to https://github.com/ArctosDB/BackBurner/issues/7?

Attributes - of any kind - are not second-class data, and any views of them as such are simply wrong. The opposite is true - eg 'sex' used to be a "fact," there was exactly one assertion and you can take it or leave it, same as every other system. Arctos now supports multiple assertions/opinions/determinations, allows specific dates, provides a mechanism for asserting method, gives credit to determiners, etc., etc. - it's just an unequivocally more powerful, "better" approach. One of the ways in which it's better is that is doesn't force our diverse users, some of whom have no interest whatsoever in the idea, to say "HEY WE DON'T REALLY CARE!!" - they can just not use the things that don't matter to them. (And I think Arctos is probably diverse enough so that EVERYTHING doesn't matter to someone, at least occasionally.)

I don't see any way in which this could be seen as different; locality attributes are exactly the same structure and idea, just attached to a different parent.

Could name and date be added to Georeference Source

Excellent suggestion. The top ~200K values are NULL, 'unknown' , and 'not recorded,' then a bunch of single-character values ([ is my favorite - force people to type something and you get "something"), then a bunch of verbose things that might have benefited from more structure. There's clearly a better path, one which allows users to record method and doesn't make them type ? when they don't know anything, provides attribution, and I think perhaps addresses the core of this Issue. So...

PROPOSAL: Let's MOVE Georeference Source to a locality attribute - that involves a place for who and how and has meaning beyond 'somehow magicked a shape onto a map.'

(And https://github.com/ArctosDB/arctos/issues/4384 might provide a mechanism for collections who want to force values of any kind to exist.)

[Jegelewicz]

Let's MOVE Georeference Source to a locality attribute - that involves a place for who and how and has meaning beyond 'somehow magicked a shape onto a map.'

That would be a giant step forward - but this should also be REQUIRED when coordinates are supplied

[Nicole-Ridgwell-NMMNHS]

Whatever we end up doing, it would be helpful if the coordinate converter auto-created a georeference entry. That way whatever you enter into the coordinate converter is just saved rather than relying on the user to correctly retype what they entered into that tool.

[dustymc]

REQUIRED

I'm still not seeing any justification for the MY WAY OR THE HIGHWAY!!! approach to this. There are lots of reasons to prefer normalization, denying that ability to other users does not make any sense to me.

coordinate converter auto-created a georeference entry

Need more info - I'm not sure what this means??

[Nicole-Ridgwell-NMMNHS]

Need more info - I'm not sure what this means??

Original data entered into the coordinate converter disappear after you click "use these coordinates" They need to not disappear. It would be nice if the original data automatically get added/appended to georeference source.

[dustymc]

Thx. One can also type those coordinates into the bulkloader, from where they get stuffed into collecting event "as entered." Same thing, or close enough? If so, would be good to reconcile those (and I don't think your procedure involves a collecting event) - forcing a user to guess what path you took in order to find data doesn't sound ideal, but maybe those really are different things (eg, you can manually edit the results of the converter before saving) and if so maybe they should not be mixed up??

[Nicole-Ridgwell-NMMNHS]

and I don't think your procedure involves a collecting event

correct

Same thing, or close enough?

Not sure. Probably requires feedback from folks who use the bulkloader for locality data.

[Jegelewicz]

PROPOSAL: Let's MOVE Georeference Source to a locality attribute - that involves a place for who and how and has meaning beyond 'somehow magicked a shape onto a map.'

Creating a new issue.

[dustymc]

I think this is fully addressed by https://github.com/ArctosDB/arctos/issues/5120 and https://github.com/ArctosDB/arctos/issues/5133, closing.