Arctos Power Georeferencers (returning to who georeferenced that locality and when?) #4866
Comments
Jegelewicz
added
Priority-Normal (Not urgent)
|
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
<#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
<#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
<#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
|
Yes, that's my recommendation.
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. |
|
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
<#4866 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADQ7JBCH2BZ3EWSUDFVEJDDVWCGQ7ANCNFSM54XIH7IQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
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. |
|
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. |
|
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. |
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.
Excellent suggestion. The top ~200K values are NULL, 'unknown' , and 'not recorded,' then a bunch of single-character values ( 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 #4384 might provide a mechanism for collections who want to force values of any kind to exist.) |
That would be a giant step forward - but this should also be REQUIRED when coordinates are supplied |
|
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. |
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.
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. |
|
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?? |
correct
Not sure. Probably requires feedback from folks who use the bulkloader for locality data. |
Creating a new issue. |
If you want the long history - read #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 #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
The text was updated successfully, but these errors were encountered: