Users change picture after the first ID is made

[spiphany]

@amatala

If I am not fast enough in detecting the mistake, sometimes flags it as being related to multiple subjects and then I have to chase them to remove the flag

No you don’t. You can counter the “no” vote with a “yes” vote of your own and the observation will go back to being Needs ID, though if you mostly use one of the apps you may need to log on to the website to vote on the DQA. If you are using one of the apps there is de facto a draft mode (you can create observations while offline and then sync later), though it is not called such by staff and it lacks some of the features that people have been asking for in a draft mode.

@amatala

There could be an extra notification being sent to followers when photos are getting added/changed/removed from an observation.

As I understand it, staff are not currently accepting feature requests for notifications, as there is a plan to completely revamp the notification system. It has been several years at this point, however, so I am not holding my breath.

While automatic notifications would help in cases where observers fail to comment when they change something, it would not really solve the underlying problem, which is that there is no record of the change in the observation itself. Edits to observations are relevant to more people than those who might be subscribed to it and people who only see the observation later may still find it helpful to know that something was edited.

[amatala]

@spiphany

No you don’t. You can counter the “no” vote with a “yes” vote of your own and the observation will go back to being Needs ID, though if you mostly use one of the apps you may need to log on to the website to vote on the DQA.

Yes, I know that, but there can be 2 votes against too, it has happened before when I did not realize the mistake quickly enough. I always use the website, not the apps, that’s where the draft option would be useful for me.

[amatala]

@DianaStuder

But draft mode - definitely - people are in the field, and need to get back to good internet. Or to have time to to research their ID.

I am actually mainly referring to the web site, as I never upload on the field or from the app. I usually create the observation as soon as I find a good photo, then go through other photos and add/replace some as I find better ones. By that time some IDs are already in so I would prefer to keep that on hold until I am sure the observation is in its final state.

[DianaStuder]

Draft mode in the field is not for me.

I use the website. But I sort my photos first - then upload the appropriate batch - and don’t have issues.

[cthawley]

I would suggest changing your workflow in this case. Routinely uploading an observation with a low amount of info and then changing the amount of information with additional pictures isn’t optimal for other iNat users. They may need to totally revisit your observation and address it twice, their previous IDs may look silly if multiple pics with important IDs are added, etc. I would suggest waiting to submit until you are reasonably sure that your observation is in its final state. If you are routinely adding more/deleting pics to/from observations, I would definitely suggest adding basic comments saying something like “three pics added” which will at least notify IDers of the change and leave a record. Again, that’s not ideal as IDers need to notice the notifications for comments and then revisit an observation, but it’s preferable to changing the pics without any notification.

[einsum]

the last time this happened to me as IDer, I raised a bug report here asking if inat is confusing observation pics in display lol. some have replied there that it happened to them when they are working through higher observations occasionally.

the observer was adamant that they havent changed pics, while I and CV are certain there was a different pic the day before from different kingdom. maybe inat has logs of reality regarding pic edits so we cant always say what happened until a staff checks those first before concluding observer is inadvertently editing pics of older observations hmm.

[anastasiiamerkulova]

At least in the export creation form, there is a ‘updated at’ column. I’m not entirely sure how it works, though

[einsum]

i think the updated_at is anything that updates the observation - from new comment, new id, new or changed annotation, new observation field, … so still no one aside from staff can say if observation pics are edited or not (when any of those updates also happen, which often will be, to make me as an IDer notice there is something different suddenly - aka from other IDs disagreeing with me or new comments).

edit: maybe I can rely on photo id and see how the adjacent photo IDs observations timeline is

[anastasiiamerkulova]

I’d like to add that sometimes I replace photos after some time, often when identifications have already been made. For instance, I might swap a photo for a higher-quality camera shot of the same organism. Every time I do this, I worry that someone could abuse this feature or simply make a mistake. We need a mechanism that quickly and easily highlights these recent changes

[cthawley]

This (swapping photos) can definitely be an issue for IDers, so I would recommend against doing it unless there is a need. If you do edit pictures, it would be helpful to leave a comment that you have done so which will a) make the history clear and b) notify IDers if they wish to reevaluate their ID as the evidence has changed.

[einsum]

suppose, iNat implements a hardcheck in code, where

1. when they are editing observation and “removing” photos, first remove will trigger a headsup popup with something like “you cant remove all photos to swap to another species than current xyz ID” if there was a community ID already on observation. But it allows editing after “Ok” press
2. The remove edits can happen, but at the end, last photo will be locked to never get removed from that observation ever. Ever in the sense that that photo will get same locked rights for future edits too.

is there any issue with such hardchecks via code? even though it looks one can say there are extreme cases where they wanted to remove all photos out of privacy concerns or such (say if the background is indicative of obscured location), and upload fresh cropped in photos or such (atleast in android classic app I can crop within app without swapping out photos), the costs of creating new observation over keeping it when changing ID is not that big deal. any other thoughts?

notice this check is only for observations which already got community ID. so, if one has a manual workflow where they upload one observation, duplicate it for filling other details that are similar, swap out the photos of new observation … wont get hampered as the new duplicated observation will not have community ID in most cases until they save with new photos itself.

[spiphany]

1. There are various legitimate reasons for needing to edit photos. It is not unusual for even experienced users to accidentally end up with photos of different organisms in an observation. If they edit the photos, the ones that remain may or may not be the ones to which the current ID on the observation applies. Ideally people would leave the applicable photos and put the non-applicable ones in a new observation, but for various reasons this doesn’t always happen – maybe the observer was interested in one organism and the IDer chose to add an ID for the first photo instead; maybe they made a mistake when selecting which photos to keep (the interface on the website is not particularly intuitive), etc. So locking one of the photos would not necessarily ensure that the community ID still applies after the photos have been edited. It is also irrelevant whether the observation has a community ID in this case; even if it has a single ID, that ID might still be wrong after some of the photos are removed.

2. In some cases a user may want to replace a photo with a new version of the same photo. Some users have a workflow that involves uploading a back of camera photo while in the field to capture the time/location and subsequently uploading the original file once they get home. Or maybe they later make edits like adjusting the color balance or saturation or cropping and want to replace the original version with a new one. Arguably people could be encouraged to keep the photo they first uploaded and add the new version as an additional photo, but some people are likely to feel that this is unappealing (e.g., it makes the observation seem messy).

3. I imagine the number of cases users deliberately delete all photos from an observation is vanishingly small and observations without media are always casual, so I don’t see why it would matter whether there is a community ID or not.

Ultimately I think this requires some kind of version history and notifications if major changes are made, not automatic restrictions on editing ability.

@einsum

if one has a manual workflow where they upload one observation, duplicate it for filling other details that are similar, swap out the photos of new observation

I hope that nobody has a workflow that involves duplicating and uploading observations and then replacing all the photos once the observations are in iNat’s database, rather than using the duplicate function and editing the relevant details prior to upload. It also seems like duplicating observations with media just to get the location/date information even though there is no shared media in the two observations is a really bad idea that is asking for errors to happen.

[einsum]

@spiphany

It is not unusual for even experienced users to accidentally end up with photos of different organisms in an observation.

Isnt that precisely the exact reason they should not simply swap out photos to correct it and is the entire point of this thread, if a mistake is to such serious level of necessitating entire photo swap, they should be encouraged to rather create new observation of those new correct photos. so If they make mistakes in photo selection itself, they should never have ability to swap out all photos discounting the existing community ID effort already made.

@spiphany

maybe the observer was interested in one organism and the IDer chose to add an ID for the first photo instead;

well that still is a subset case of atleast one photo locking. Maybe by some means the removed photos can indeed invalidate an existing observation ID as in your subset example where the last photo was another species the observers wants to edit and eventually keep, but that is still a subset case and partly mistake of other IDers, since if they have multiple species or photos, the others can atleast not make direct such uncertain ID or use notes or use DQA of multiple organisms or any such cases where multiple valid IDs case applies than committing to uncertain ID. Aka in those cases, the community ID that is turning out to be invalid isnt really going to get effected by implementing locking to atleast one original photo in first place, because there is no argument by IDer to be made that they were cheated suddenly. It is them who committed to uncertain ID in first place under initial evidence.

But this thread is about the broader case, where a genuine community (non owner) IDs are going to be invalidated purely by entire observation photo swaps to another species which is superset of that specific case.

anyway, I am not sure how many has workflow as point 2 and how locking will effect their behaviours and perceptions. But the point remains where the workflow 2 is to be blamed than not locking? as an upload that is public on iNat implies to the IDers, it is the first evidence they are gonna use to ID, and just because an observer doesnt feel their initial photographic evidence is appealing and they want to process the image and swap entirely, no matter how messy leaving the original/raw photographic evidence is, that initial photo is still objectively the prima facie evidence where any IDs that happened before such edits relied upon. So an observer’s appealing personal preferences to swap out “entire” initial photos is not really a clean thing and should actually be locked out too.

iNat classic app I use already provides offline upload “without sync”, and those swapping out workflows should rather rely on such options or even offline tagging things, instead of letting community IDers work interim just to swap out later. Yes, maybe some are genuine usecase and swap is not a different species to existing ID, but iNat also has policy of how much editing is acceptable, so consider a case where sequence of IDs turned an observation to RG, and then from observer appeal of photographic preferences, they edited and swapped the entire earlier photos evidence, is the end result even valid? notice none of the past IDers even know whether their IDs should even remain valid let alone if the new edit is an acceptable photo edit to this RG observation unless such observer notifies by comment of those new edits.

@spiphany

I imagine the number of cases users deliberately delete all photos from an observation is vanishingly small and observations without media are always casual, so I don’t see why it would matter whether there is a community ID or not.

But this thread is not about purely full deletion, but swapping photos to another species where ~~a community ID~~ maybe I should have said “ID apart from observation owner” exists.

[spiphany]

I don’t think you read my post correctly.

My third point was responding specifically to your example of a user wanting to delete all images from an observation; given that this makes observations casual, I fail to see why users should be prevented from doing so in the rare situation that they might choose to do so, regardless of whether the observation has 0 IDs, 1 ID, or multiple IDs.

My first point was not about users wanting to swap out all photos, but rather some portion of them (because they accidentally mixed up organisms and several of the photos had a different species). My experience is that in such cases it is not entirely predictable which photos the observer decides to keep and which ones they put in a new observation. It may happen that the observation has been given an ID of species X by the observer or another user, which correctly applies to some portion of images, but when the observer edits the observation, they only keep the photos of species Y.

Eg: photos 1, 2, 3 and 6 are species X; photos 4, 7, and 8 are species Y. Observation is given an ID of species X. Someone comments that the photos are not all the same species. Observer edits the photos and keeps 4, 7, 8. Observation now has an ID (species X) that does not apply to the photos (species Y). It is irrelevant whether this ID was entered by the observer or someone else.

Your solution of locking one photo would not fix this, because there is no way to automatically determine which ID belongs to which photos.

The result is still a wrong ID on the observation and no notification about it, and no record of what was changed except for the comment about the photos needing to be fixed. IDers do not always immediately mark the observation as containing different species in such cases (because the observation becomes casual and if the observer does not comment that they have edited the photos, nobody is informed that the issue has been addressed and thus the observation remains casual forever).

My second point was that there are some circumstances where people might wish to swap one version of a photo for a better version of the same photo and would likely be unhappy about being prevented from doing so. While it is not ideal, changing photos in such a case does not have major negative implications for the ID (though it might cause confusion if there are comments about photo quality).

Locking photos doesn’t solve these situations because it doesn’t address the underlying issue – namely, that iNat does not record edits to observations and it does not generate notifications for edits even in cases where it might be desirable (such as some of the photos being changed).

[einsum]

@spiphany

My third point was responding specifically to your example of a user wanting to delete all images from an observation; given that this makes observations casual, I fail to see why users should be prevented from doing so in the rare situation that they might choose to do so, regardless of whether the observation has 0 IDs, 1 ID, or multiple IDs.

Because those IDs are relying on atleast one of those image in first place. If they want to remove all supporting evidence in first place, the correct operation is rather removing observation in first place. Even if such entire deletion made the observation casual does not mean the casual ID itself is allowed to be made semantically invalid and to be preserved as disconnected state in such a way by full photo deletion. so, I dont see why locking atleast one photo is irrelevant to this case.

@spiphany

Your solution of locking one photo would not fix this, because there is no way to automatically determine which ID belongs to which photos.

The point I am saying by locking is not to fix such misidentification issues in first place, as I said in that case the blame is on IDer who committed to any such uncertain IDs given conflicting evidence that existed in first place, so the IDer cannot feel cheated and things will proceed anyway in similar fashion whether locked or not - aka their IDs are going to be trumped eventually on valid edits. That issue cannot be solved by locking or not locking and it is outside of such locking feature goal itself. The atleast one photo locking goal is simply to prevent silent post-hoc replacement of all supporting photo evidence which can collapse the justification context of prior ID decisions and IDers effort.

@spiphany

would likely be unhappy about being prevented from doing so.

the point remains that if someone IDed on existing evidence, any such silent “full” swaps should not be allowed. as I already explained via clear example if RG swaps are done to another species. Yes, some swaps are harmless but the point of locking is to prevent such harmful swaps per se and the system should prioritize integrity of existing consensus and community effort over unconstrained edit flexibility when any of those edits can retroactively change evidence scope. so rather than artistic preferences of any workflows which they can change anyway easily, as explained already, the system should value community effort which is precisely what locking atleast one photo does, and since there is no easy way to say any full swap is harmless or harmful, the locking to keep atleast one photo would still be real integrity option to prevent harmful swaps as this thread topic.

@spiphany

it doesn’t address the underlying issue

yes obviously, getting notified is gonna give headsup always, but still the swapping out photos as an issue remains if that is gonna discount the IDers effort.
and also implementing such one photo lock check is relatively easy to push if coder effort is to be considered, so as interim tradeoff, such locking is neither subpar nor wasteful nor irrelevant as it addresses a real issue. But, anyway its not like either locks or edit notifications are going to be implemented by staff anytime soon, and this is all just interesting banter here

tldr: In colloborative identifier effort, IDs are grounded to specific photographs evidence in first place, when that evidence is entirely swapped out, the IDs lose their anchor no matter whether the system provides notification of such edits or not. The clean way to swap such entire things is to rather create new observation, and ideally not even make such interim placeholder observation in first place wasting community effort if that evidence is going to be swapped in time for aesthetic reasons, and such lock is not gonna effect multiple photos with multiple species argument as its not about solving that issue in first place, instead of seeing it as restricting edit freedom it should be viewed as about preserving data integrity and effort.

[spiphany]

@einsum

The atleast one photo locking goal is simply to prevent silent post-hoc replacement of all supporting photo evidence which can collapse the justification context of prior ID decisions and IDers effort

But locking will not do this. Because if an observer of an observation with multiple species removes those images to which the original ID referred (while leaving at least one image that then gets “locked”), all evidence and justification connected with the prior ID – which is still attached to the observation – is removed even though at least one of the original images is still there.

I am not saying that it is the correct action of the observer to remove the photos to which the ID referred in such a case. Or that it was correct for the IDer to provide an ID that originally referred to only a subset of the photos. But both of these things happen not infrequently in practice, often unintentionally, and your proposal will not prevent this from continuing to happen.

[einsum]

@spiphany

But locking will not do this.

Ok sorry yes any system that allows unconstrained edits can never prevent total justification collapses, but the lock is a proposal on accountability and minimal continuty constraint, and that one photo still acts as thread to connect IDers effort and prior context, even if there is some collapse in this chain under ur example, it still offers the minimum persistent provenance one can achieve.

The log or notification is not on equal minimum provenance unless such log is standardized in first place (and I doubt there is anything standard in biodiversity datasets to check such case of total evidence swaps as some standard log entry, “git versioning” obviously superior here but maybe complex for all biodiversity data handlers), I doubt a random log with intent message of “user swapped out all photos” is any more clean or offers stronger provenance on downstream tasks as lock is and neither the notifications are - there are myriad real examples on forum and platform comments, where users can miss or not see notifications, infact I have a pending bug report case here, where another change altogether failed to generate notification.

@spiphany

all evidence and justification connected with the prior ID – which is still attached to the observation – is removed even though at least one of the original images is still there.

keeping that one locked photo is simply “not all evidence and justification is removed”, and is infact a strong minimal thread connecting that evidence-justification-id chain one can ever aim for. The alternate of allowing all photo swaps is actually completely breaking this chain of actions.

consider all these cases and lets call the main action “A photo swap to another species happened, but single photo is locked” simply as X.

1. action X → a researcher going through that RG set from gbif has higher chance of finding such swaps now with that one locked anchor photo to realise there is such problematic wrong swap.
2. Identifiers IDed (as is the topic of this thread) as ID y → action X → any future identifier can infer this past reasoning thread, and so they can act upon what is happening and raise staff action if its dominant for that user, which is now realizable.
3. A data auditor can catch these X with that one lock as X is now identifiable no matter the all other data standards and fields and logs are.

@spiphany

and your proposal will not prevent this from continuing to happen.

but I never said the lock proposal is to fix those other things. in fact no method via code can ideally fix an overzealous IDer mistakenly adding IDs on such conflicting evidence however unintentional. so it is mute to argue on a random point towards another proposal, and is as equivalent as “you are teaching me Newton laws in high school to pass current class in education, but the world is run with Einstein relativity for my GPS, so lets talk about Einstein relativity and such and discount this Newton laws topic as there is another interesting solutions” - Newtonian mechanics are just as valid and enough under their main context just as what I am talking of for such lock context is.

[s-e]

@anastasiiamerkulova

sometimes I replace photos after some time, often when identifications have already been made. For instance, I might swap a photo for a higher-quality camera shot of the same organism.

Agree with cthawley, instead of swapping your photos after they’ve been ID’d, you could just ADD the enhanced photos… you can even change the order afterwards, so that lower quality pictures appear after the rest.

Not sure if IDers are notified when someone just adds pictures to an observation, though?

Otoh even though I almost always do some basic editing like cropping, resizing, adjusting brightness, I sometimes upload different versions of the same photo from the start, to show both the original and the enhanced/zoomed in version, as this might help identifiers to understand why something doesn’t look “natural”…

[anastasiiamerkulova]

Since English is not my native language, there might have been a misunderstanding. By ‘replacement’, I meant adding a new photo while keeping the old one, but making it so the old photo is no longer shown first

[pisum]

@chbluete

What is iNats recommendation how to handle the following situation:

I often have users changing their pictures in the observation to a completeley different species after I have made a first ID from unknowns to a species.

if you notice this, then i think the best thing in most cases is just withdraw or make a different identification. you could also ask the observer whether / why they changed their photos, if you’re certain there’s an issue.

short of completely preventing users from modifying observations after submittal, there’s really no other systematic option that will provide a reliable workflow that all folks can depend on.

if you see that a user is doing this in a way that looks purposely trolly, this might be something that requires curators or staff to look into on a case by case basis.

the only time i’ve ever noticed anything like this is when i came across an obviously suspendable photo on an old observation. the community usually seems to be quick to flag such photos. so i remember that case being one where the observer probably replaced the original photo some time after uploading the observation originally.

that said, i would think that this sort of thing occurs so infrequently that it’s probably not worth spending too much time thinking about it. the existing workflows are fine. you’ll never be able to prevent every possible bad action.