As I sit here going through sound observations, sending off request after request for users to duplicate their observations for various Orthopterans that are heard calling, I’d like to revisit the issue once again. As of yet, all users seem very happy to duplicate their observations and seem delighted that other species are being found in their recordings. Five years ago, I made a request to allow identifiers the ability to duplicate another user’s observation for the purpose of identifying species other than that identified in the original (https://forum.inaturalist.org/t/duplicate-observation-of-another-user/6292). For example, if the recording is made for an owl, but crickets are heard, the observation could be duplicated for the cricket.This suggested feature was declined. Very recently there was a similar request for a “Request Duplication” button, that would have a similar effect, but require the owner of the observation to do the duplication: https://forum.inaturalist.org/t/add-a-request-duplication-button/52215/8. This was also declined.
There is a treasure trove of valuable observations that could be made, many of which are not in the CV model or, for sounds, the equivalent if sound AI is eventually done, but are stuck behind a cumbersome process of asking users to duplicate their observations. The current process has several disadvantages: 1) it doesn’t work if a user is no longer active or doesn’t have time to address the request, 2) the identifier will often have to look at the observation twice (the first time, followed by the duplication request, then a followup to confirm) which is more time consuming, 3) anyone who has identified the original observation will get a notification of the comment requesting the duplication which will waste their time, and 4) the observer, especially if a beginner, might not know how to duplicate the observation.
On the flip side, what would be the drawback of allowing the identifier to duplicate the observation for the user? The original observer would retain ownership of the duplicated observation, it would add to their observation list, life list, etc. It seems a technologically simple solution that’s a win for everyone. Are there any readers here who would not want somebody duplicating an observation of yours as described above?
As I recall, the original discussion made the point that the observation belongs to the submitter and therefore no mechanism would be implemented to allow another iNatter to duplicate a record that isn’t theirs. Which seems reasonable to me.
I wouldn’t mind this, and it does seem like it could enhance the data collection side of iNat. I think it’s possible that some observers wouldn’t be comfortable with it, though. I recall one person mentioning on the forum that they use iNat only for one type of organism and don’t want their stats to include others. I don’t personally think that’s a good strategy, and I’m sure most people don’t use the site that way, but we should respect observers’ choices anyway.
This is definitely a valid point. However, I would love it if this feature existed as something that could be opted into or out of, just like I’ve chosen to let other people add observation fields to my observations, add my observations to traditional projects, etc. I’ve definitely had enough “bycatch” in my observations (especially the audio ones), that it seems like it would be helpful
I agree with @bugbaer, something like this, but with the opportunity to opt out in the settings might be best. An “Allow other users to duplicate my observations” button in the settings that can be decided by the user.
If that’s still problematic, I think maybe a “request duplication” button on the specific observation’s page might still be helpful, especially if there’s an “approve” option for the user from their home/updates page that would somehow automatically duplicate (rather than the person having to manually duplicate). Could work in a similar way to flags? Though I’m not a tech expert so I don’t know how hard this might be to implement.
I don’t think this is a good idea unless it just takes you to the observation creation/edit page. Manual duplication isn’t difficult, and an automatic system would probably reuse the ID of the first observation, which would not be helpful for the identifier who requested duplication.
An automatic system could be coded to retain the elements from the original observation that we can expect to be unchanged (owner, date, time, location, photos, sounds) and discard those we know should be different (IDs, comments). Properly implemented, it doesn’t need to be worse than a manual duplication system. Really, both of them are just buttons that create partial copies of an existing observation.
I wouldn’t mind there being an “Approve” button or similar, as suggested by @kjerstiandco, but I think it should send you to the observation edit page the same way the current “Duplicate” button does. I don’t see a better way for the new observation to get an accurate ID, unless maybe it was included as part of the request for duplication.
Certainly, if we’re considering a workflow where an identifier can request duplication, then the new observation should not inherit any IDs from its source observation. So, then we need to decide whether we want to automatically add an ID from the identifier that requested duplication and/or from the observer.
It doesn’t seem necessary to automatically add an ID for the observer. They can do that themselves manually as you point out.
For the identifier’s new ID, we have a couple of options:
Leave it for the identifier to manually add an identification to the new observation, perhaps after they get a notification saying “An observation by [observer_id] was duplicated at your request”.
Build in some logic that requests a new ID from the identifier as part of the “request duplication” process, displays that to the observer, and (assuming they agree to duplicate the observation) applies the identifier’s selected ID to the new observation on their behalf.
Option 2 may be a little more informative for the observer, and reduces the number of times that the identifier needs to interact with the observation. But there may be other pros and cons.
My main concern with this is that there would need to be some way to ensure that observations aren’t getting duplicated multiple times. ie, an observer “approves” a duplication of 20 of their observations, then a year later, a different identifier requests the same 20 duplications, and the observer doesn’t remember whether they previously approved those specific duplications, so they approve them again, and now there are duplicates of duplicates of duplicates… Or, as an observer, I post a picture of a bee on a flower and now have to deal with a different identifier “requesting duplication” for the flower every few months, not realizing it was already done. There would really have to be some way to “link” the duplicates together so duplicate-happy identifiers don’t request the same duplications that someone else already requested.
Good point! My way of dealing with this is to sort a user’s observations by observation date in Identify. That way any duplicated observations are right next to the original. Having some sort of link between duplicated observations seems like an obvious need.
This. I would be very unhappy if other people could create new observations in my name whenever they chose – and this is precisely what a function allowing other users to duplicate observations would be. An observation documents an interaction with nature; for me, this also includes the act of uploading it as part of my personal record.
There are any number of reasons why I might not want an observation duplicated: maybe the duplicated organism is a cultivated plant that I intentionally chose not to upload as a separate observation; maybe I already uploaded an observation of the duplicated organism; maybe it happens that I have other, better media of the duplicated organism that I could upload if someone pointed out that it was there.
Another issue is that duplicated observations are not currently displayed in a way that is particularly obvious – there is nothing on the observation page itself that indicates the media has been used in another observation; you have to click on the photo information. Or the observer has to use a tag/observation field to link them. I would support a proposal to make it easier to link up observations and see at a glance whether there are associated observations.
I do understand the desire to be able to convert “bycatch” in observations into data that is useable and searchable, but I don’t think duplicating observations is the way to do it.
The main drawback is that it runs counter to the primary mission of iNaturalist, which is focused on people, rather than data. Allowing identifiers to duplicate other users’ observations (with or without their consent) puts too much emphasis on the data. A much better approach is to directly engage with the observer and suggest ways for them to make more of their observations. As you point out yourself, many users will respond positively to this, but the desired outcome here is not merely to create more data - it’s rather to help each other learn more about nature. This vital social function would be undermined if users could simply duplicate each others’ observations without directly engaging with one another.
For many of the reasons above I also wouldn’t want anyone duplicating my observations.
Hopefully anyone using iNat data for their projects is also storing the relevant data separately already (e.g. as people can delete their entire account at any time or so that they can add additional data to the records). They can then duplicate the record in their database to identify a separate species.
I think making it easier to request duplications, see duplication requests, and perform duplications would all be great, but I think allowing people other than the observer to actually perform the duplication is an idea that could lead to a lot of problems, both accidental and malicious. Spamming duplications could be used as a harassment technique or a way to influence other people’s perception of the original observer, for example.
That said, a duplication request feature seems helpful, if designed to minimize accidents and spam. Ideally it would be limited in how much it can be used; for example, only one duplication request can be active per obs (so a spammer can’t submit 50 requests to duplicate the same photo, and 10 people can’t submit 10 identical duplication requests), and have it strictly require a suggested ID that isn’t the original ID for the duplicate taxon. That might slow things in cases where an observation has 4-5 possible taxa in it, but that seems like a worthwhile compromise; if the observer is responsive to the first request, they’ll likely be responsive to subsequent ones.
And I agree that something on the observation page that very clearly indicates existing duplicates/associated observations (and shows these to anyone requesting a duplication before they are allowed to send their request) would also be necessary to help cut down on unnecessarily repeated requests.
Me. I’m not one of those “record everything” observers. I am very deliberate in what I observe and how many of a given taxon I observe. Rather than reiterate all the reasons @spiphany enumerated, I will just add that all could apply to me, and more.
This isn’t going to happen, I’m sorry. I think we should definitely make it easy to duplicate observations in both the website and the upcoming mobile app and have easily referenced help documents so that someone can ask the observer to do duplicate an observation (and I do this fairly regularly), but there won’t be functionality for someone to duplicate another person’s observations or start the process to do so.