Simplifying Name Parsing in Create Observation Form

[nimmolo]

Wanted to start a discussion to get guidance for a potential new PR to improve the following issues in the parsing of Names. I agree with @pellaea that the current functionality could use some simplification:

I think one thing that might help is that [parsing] can be safely simplified a bit now. One of the multiple purposes it was serving was to automagically add authorities to names that didn't have authorities yet. It was, unfortunately, a bad idea that resulted in all sorts of incorrect authorities being added which many, many users have slowly over time had to fix by hand.

In the end, all it's doing is looking up the best name that matches the one the user typed. Honestly, it might even be worth considering changing how that works altogether. Making it so that it only accepts existing names, and if the user want to create a new name, make them create it separately.

That might really help cut down on misspellings and bogus names. (Didn't I just see someone create "Dr jeckyll"??) And it would dramatically simplify this large thicket. Do the same for species lists, too. And remove bulk_name_edit altogether.

Just some ideas. There might have been a good justification for all that complexity in the first few years, but it's way overdue for an overhaul. I bet even Nathan would agree. (That's his code, some of the first code in MO!)

Originally posted by @pellaea in #1082 (comment)

These seem like great ideas:

• Only accepting existing names in naming proposals, with an option to redirect to the Name new/create form
• Eliminating Authority suggestions in the parsers
• Eliminating bulk name edit

I'm currently sketching out a NamesController/NameDescriptionsController "normalization" PR, so I'm in favor of resolving them (or at least improving them) now.

[mo-nathan]

The one that worries me is "Eliminating Authority suggestions in the parsers". I'm not exactly sure what that means. As long as users can use authority to distinguish between names that only differ by the author we should be ok. I think this is particularly important for "sensu Xyz" type authorities and we need to do something regarding "complexes" or "groups". They are actually really important for Fungi in my view and neglected by existing nomenclatural standards. I actually expect one of the consequences of the ML stuff I'm doing will be the need for more groups and complexes.

[pellaea]

Totally agree with Nathan, and I suspect we're just misunderstanding Nimmo's suggestion. But honestly I'm not sure what he does mean in this case! I'm probably forgetting some context from an earlier conversation, sorry, Nimmo!

…

On Sun, Jul 17, 2022 at 4:22 PM Nathan Wilson ***@***.***> wrote: The one that worries me is "Eliminating Authority suggestions in the parsers". I'm not exactly sure what that means. As long as users can use authority to distinguish between names that only differ by the author we should be ok. I think this is particularly important for "sensu Xyz" type authorities and we need to do something regarding "complexes" or "groups". They are actually really important for Fungi in my view and neglected by existing nomenclatural standards. I actually expect one of the consequences of the ML stuff I'm doing will be the need for more groups and complexes. — Reply to this email directly, view it on GitHub <#1096 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYTNNOACH37OYC6VVUXCOTVURTQTANCNFSM532HKAUA> . You are receiving this because you were mentioned.Message ID: <MushroomObserver/mushroom-observer/repo-discussions/1096/comments/3166998 @github.com>

[nimmolo]

I don't know what i'm suggesting either, since I don't understand how it currently works. :)
But I guess as long as we disable "freestyling" a Name in the Create Obs form, these Authority and Sensu concerns are addressed by default.
Autocomplete would suggest valid existing authorities only, and no one would type in Dr. Jekyll when they didn't know and didn't care. Right?

[pellaea]

Yes, for me that is the key: Not automagically filling in authorities or automagically creating new names by simply submitting the form twice. That was great at first, really got our database populated super fast! But it's a real liability these days. Just ask poor Joe and Igor. They are tireless in tracking down and fixing errors in the database, many of which arose from these features, and bogus new names that people are creating because we make it too easy to do so. I would personally like to continue to see a free-style, auto-completed text field for name, but don't let it create the observation until the name matches something unambiguously. If there are multiple versions of a name, continue to suggest them, just like we suggest preferred names or alternate spellings of unrecognized names. But no more creating names automatically. I might even prefer to see MO require the user to create the genus before creating the species, too. After all, all new names should be added to the database with the darned authorities. There is no reason not to require that anymore. We are no longer trying to encourage new names, just the opposite! Automatically creating the genus without an authority or classification or anything just seems irresponsible nowadays. Let's explicitly require users to do it, and encourage them to do it correctly and completely right from the start. Bulk_edit_name is just inviting abuse! Fortunately, most people don't know it exists. :) Maybe we can keep it as an admin tool, just in case a big new genus is added or something and a user comes to us and asks us if there is an easier way to add 100 new names to the database. But my understanding from Joe is that we don't want to do that. The standard for the past several years has been: Do not add the name until it is used by an observation, period. That would disqualify all possible uses of bulk_edit_name, right?

…

On Sun, Jul 17, 2022 at 5:17 PM andrew nimmo ***@***.***> wrote: I don't know what i'm suggesting either, since I don't understand how it currently works. :) But I guess as long as we disable "freestyling" a Name in the Create Obs form, these Authority and Sensu concerns are addressed by default. Autocomplete would suggest valid existing authorities only, and no one would type in Dr. Jekyll when they didn't know and didn't care. Right? — Reply to this email directly, view it on GitHub <#1096 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYTNNM4W4B6TAKJVOLQV63VURZ7TANCNFSM532HKAUA> . You are receiving this because you were mentioned.Message ID: <MushroomObserver/mushroom-observer/repo-discussions/1096/comments/3167195 @github.com>

[nimmolo]

It sounds like what you're proposing is not a change in the parser, then, but a change in form validation behavior for Create Observation.

Is that more or less right?

[pellaea]

I guess I would have to dive into all that code again to answer more meaningfully. No judgment on the code of NameParser or any of that, of course. I just can't imagine why we need any helper classes to do what we're talking about for the new validation behavior. But maybe if I were to actually read the code (or try to do the refactor myself) I would find complexities that necessitate all the extra Stuff. Sorry, I'm really struggling to even keep up with emails right now, let alone review papers, do the favors I've promised people, etc. etc. I wish I could be more help. If you wish to leave everything as is, that is totally fine with me. That's been my decision every time I've considered refactoring that code. My initial position was simply that I would support you if you decided you wanted to refactor that code. And maybe I led you on irresponsibly by sharing my long-held conviction that it could be dramatically simplified.

…

On Sun, Jul 17, 2022 at 6:15 PM andrew nimmo ***@***.***> wrote: It sounds like what you're proposing is not a change in the parser, then, but a change in form validation behavior for Create Observation. Is that more or less right? — Reply to this email directly, view it on GitHub <#1096 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYTNNNH5T2VQ3ZS55WJ5Q3VUSAWVANCNFSM532HKAUA> . You are receiving this because you were mentioned.Message ID: <MushroomObserver/mushroom-observer/repo-discussions/1096/comments/3167347 @github.com>