Hey! I just have a small handful of questions, mostly about iNat etiquette.
Is there a reason that, when people will say “please mark as cultivated” etc, they put them as separate comments from their ID, and not just in the notes field for their ID? Besides “because that’s not where it goes,” which is fine.
Is it bad etiquette to create iNat Projects for personal projects? When I say personal I mean I have a lot of projects that aren’t exactly “private” but I also don’t think that anyone else would really care about. Like a list of stray cats that live in my town, that kind of thing. Certainly not anything Official.
2b. If the answer is no, and it’s totally fine to make Projects for personal things, then would it be bad etiquette to add other people’s observations to said Projects? Would I need to talk to them first?
Is it bad etiquette to ask identifiers how they got to an ID, when I am not involved with the observation in any way? Like I’m not the observer, I haven’t added an ID, I just show up randomly and ask questions.
Is it good or bad to put things that are in broad categories into slightly less broad ones? Like if something is ID’d as a “plant” and I know that it is a “vascular plant,” would it be better to leave it alone, or to add the ID for “vascular plants”? In my head, more precise is always better, but I don’t know if that would mess something up and/or come across as “just adding obvious IDs to things to boost my number of IDs”?
I have been marking duplicate observations as “no evidence of organism” on the basis that the duplicate observation is not contributing any new evidence. Does this… make sense? Is this right to do?
If you write anything in the notes with the ID, the system just gives the recipient an alert that there’s an ID, not that there’s a comment with it. Since a lot of people don’t follow up on every ID (especially if it’s agreeing/supporting), adding whatever you’re saying as a separate comment increases the chances people will actually see it. (I don’t believe comments in IDs are searchable either.)
Is it bad etiquette to create iNat Projects for personal projects? When I say personal I mean I have a lot of projects that aren’t exactly “private” but I also don’t think that anyone else would really care about. Like a list of stray cats that live in my town, that kind of thing. Certainly not anything Official.
2b. If the answer is no, and it’s totally fine to make Projects for personal things, then would it be bad etiquette to add other people’s observations to said Projects? Would I need to talk to them first?
You can make a project for basically whatever you want. If people don’t want other people adding their observations to projects they haven’t joined, they can block that. If they haven’t done that, you can add observations to any project that seems appropriate. (And if someone has an observation that seems like a really good fit for your project, a polite comment explaining why you’d like them to join the project is often successful.)
Is it bad etiquette to ask identifiers how they got to an ID, when I am not involved with the observation in any way? Like I’m not the observer, I haven’t added an ID, I just show up randomly and ask questions.
I wouldn’t do it on every single observation you see, but if you’re sincerely interested, go for it. I do this on observations where I’m not sure how to tell Species A and Species B apart, but someone seems really sure it’s Species A, or if it seems like the observer might have been using information that didn’t actually make it into the observation to confirm or rule out an ID.
Is it good or bad to put things that are in broad categories into slightly less broad ones? Like if something is ID’d as a “plant” and I know that it is a “vascular plant,” would it be better to leave it alone, or to add the ID for “vascular plants”? In my head, more precise is always better, but I don’t know if that would mess something up and/or come across as “just adding obvious IDs to things to boost my number of IDs”?
It’s always helpful to give more specific IDs. Although in that particular case, if you can get it to vascular plants, a lot of the time a plant will be pretty easy to ID as an angiosperm (flowering plant) or conifer, which will be even more helpful. So I would try to get as specific as you can and save “vascular plant” for the ones you really aren’t sure about. (There are also vascular non-seed plants like ferns and a few other things, but most of the vascular plant observations will be angiosperms or conifers.)
I don’t think this is consistent with the guidelines for this DQA field, so I don’t do it. However, if I see someone doing this and there is a comment that it is a duplicate, I’m just going to ignore it.
If I notice a potentially verifiable, wild observation marked as “No evidence of organism” without a comment giving a hint as to why, I will ask about it and usually counter the vote. My assumption is that it was clicked by accident until told otherwise.
When I see a duplicate, I usually comment that it is a duplicate with instructions to delete it (frequently linking to the matching observation), then I don’t ID it. I don’t know how many are deleted or DQAed by someone else. Most that stay in Needs ID will eventually be IDed by someone. If so, I ID it to as specific as I can in hope of moving it out of Needs ID eventually.
Yes, the DQA should not be used to make a duplicate observation casual. There isn’t a great way to handle duplicates right now, but they also aren’t a huge problem (as much as they do grate on me). I try to leave a comment explaining the issue. My current stock one is:
“This is a duplicate (same individual) of https://www.inaturalist.org/observations/XXXXX. Please only make one observation for each individual organism you see at a given time. You can combine multiple pics of the same individual into one observation. Please delete this one by clicking the down arrow to the right of the edit button (on its webpage) when you get the chance…thanks!”
Probably 1 in 10 users actually deletes, maybe less. If I see dupes when IDing, I just hit “reviewed” and move on.
If someone makes a duplicate observation RG I usually mention the identifier and ask them to withdraw their ID. But as stated above they really aren’t much of an issue as iNat isn’t used for mapping abundance.
I usually try to give instructions for the app or tailored to the specific method the observer used to upload the observation because most of the time duplicates, observations missing data, and those with multiple species will be from the iPhone app, although I’m not sure this really influences more people to delete the observation. Recently I’ve been just too lazy to even leave a comment though.
No, please don’t do this. Politely ask the user to remove the observation and add the photos to the remaining observation. But “duplicates” aren’t the biggest deal, although they can be frustrating.
4 Plants - if you can, get it to Family that helps. But there is a swathe of obs with broad planty IDs banished to limbo … mostly … dicot despair. Effectively still Unknown, but in a different box with a fresh label. Plants down to Order worldwide 3 million
I clear my Cape Peninsula each day.
5 Duplicates. I ID as Life. ‘Please delete’ Leave a link to obs number of the duplicate (since you have already put in the effort to find and confirm Duplicate) If we can get 2 IDs for Life and DQA as - No good as it can be = Casual, which takes it out of the Needs ID queue, as a courtesy to the next identifiers. But that workaround needs 2 identifiers to agree to Life.
One day we will have 3 categories?
Wild
Not Wild
Obs with probs sent back to the observer to resolve (and taken out of the Needs ID queue while we wait for that observer to bob up again on iNat)
missing date or location or photo
delete duplicate
combine multiple images of one individual
split obs of multiple species
answer hopeful questions from identifier / taxon specialist
My most common approach to duplicates is to make a comment (“duplicate of this: link to older observation”) and mark them reviewed so I don’t see it again. Until we have better tools to DQA these, I just move on after leaving a comment.
In some cases where there is more than one organism in the picture, I will find something else to ID and make a note e.g. “ID’d the plants in the background since the bug in the center is already ID’d here: link to duplicate observation with different ID”). A link to the other duplicate(s) really helps. I’ve seen some cases of duplicates where all of the observations were DQA’d to casual and it was lost from RG entirely when really at least one of them should have been left at RG.
I think the most important part in all this is adding comments what’s going on with the observation for the benefit of those who come across it after you. In many of these cases the observer is inactive and won’t react. You are basically communicating with fellow identifiers who will also look at the observation trying to figure out what to do with it. If I come across one that has already had a comment added that it is a duplicate, I will usually just hit the “reviewed” button and move on.
I personally just ID them as good as I can, hopefully being able to move them out of the “need ID” pool and write a comment stating “duplicate”.
The organism is there, it can be IDed… so the DQA does not really seem fitting. And IDing them to RG moves them out of the pool, so other identifiers do not have to bother with them as well. As stated, the duplicates are not the biggest issue anyways.
BTW. Thanks for getting into the IDing game! Ask away if you have questions about identifications. Iders that would not like to answer them just won´t, but I think most are happy to help you train :-)
Please give us an effective way to deal with duplicates.
You will lose disheartened identifiers and become a nature based instagram with pretty pictures.
If Life is wrong - then it must be No Evidence of Life. And that IS wrong.
I don’t think there will ever be an effective way of dealing with dupes. If you implement such a feature, it will get abused in one way or another.
If there is some sort of a button which sends dupes to casual, or anything that gets them out of the queue, you could just click it on perfectly fine obs. Who’s there to say what’s a dupe and what’s not…
You’d need an entire algorithm which searches the entire database for a perfect match… yeah, that’s just not happening.
Or you’d have to submit dupe links to iNat, and then they’d have to be manualy checked… that’s also not happening.
So I just suggest either ignoring the ob; commenting and ignoring or determining as good as you can and commenting.
I appreciate when people do this, personally. It took me a really long time to even know what “dicot” meant… But I learned because of people doing this. Now I can say “dicot” instead of “plant” when appropriate. I think it’s good to be as specific and precise as possible.
I figure that if I know it’s a duplicate, I also know that it’s the same species as its twin, so I ID it (if I can) to get it out of the Needs ID queue. This doesn’t take any more time than marking it as Life or anything else. If I’m not too tired I also write that this is a duplicate and what it’s a duplicate of. However, sometimes I don’t want to take the time. So I don’t. Since I’m not all that upset by duplicates (observations have so many worse problems!), I don’t feel bad about that.
If someone decided the duplicate problem was worth development effort that would otherwise be spent on other problems then I think there are a bunch of ways it could be addressed.
As an example, how about a Mark Duplicate button that allows you (as the identifer) to select other observations by the same user that you believe are dupes. Maybe an identifier needs to surpass some basic threshold to qualify for this ability. Maybe we have a confirmation step where another identifier or curator confirms that the observations are dupes (with an efficient interface, so this isn’t an onerous task). And maybe we have a notification process so that iNat lets the observer know that the observations will be automatically combined. Assuming no action by the observer, after x days the observations are combined, inheriting IDs from both/all parents and with some logic to handle annotations, DQA votes, etc.
As enhancements:
The Mark Duplicate interface could let you search for observations with identical image file hashes to assist the identifier in selecting the dupe observations.
The hash search process could be automated, so that iNat itself automatically detects existing dupes. There might need to be an exception for observations using identical images where the observer has added IDs that are not close relations. This is to avoid tagging as dupes observations of distinct organisms that happen to use the same photo. So two observations would be auto-merged if they used the same pic of a flower and a beetle and were identified as “Papaveraceae” and “Eschscholzia californica”. If they were identified as “Papaveraceae” and “Coleoptera” they would not be merged.
This logic could be brought forward in the process, to alert users if they’re uploading an image that’s already present in iNat’s database (might also dissuade some copyvio images if handled right).
But… there are several other data quality issues I would prefer to see tackled first. Likely the worst effect of duplicate observations is occasional additional records for a particular organism, and it doesn’t seem that causes much of a real-world issue. Personally, I have stopped worrying about dupes and just ID them both as if they were independent observations. [Edited to fix typos]
If the official staff position is that duplicates should be treated just like any other observation (i.e., not ID’d to “life”, not made casual using one DQA option or another), please put this guidance somewhere on the website, e.g. in the FAQ section.
This is not because I think that experienced users are likely to consult the FAQ, but because it is useful to have a common point of reference when disagreements come up about how to best handle such cases. My experience is that all of the ad-hoc approaches mentioned in this thread are widespread, so if IDers are to be encouraged to change their approach, the recommended best practice needs to be documented somewhere findable (i.e., not in the forum, which is only read by a small fraction of users).
As with multiple species observations, I would prefer to see a formal mechanism for marking duplicates as such, but I’m not holding my breath on that happening any time soon.
…
The biggest issue that I see with duplicate observations is not the duplicate record per se. Duplicate records are unfortunate but something that anyone using a data set is going to have to be aware of and take into account, as there are multiple ways that a record might end up being reported more than once.
Where duplicates often do cause a lot of headaches, at least from an IDer standpoint, are cases where they are not true duplicates – i.e., same photo posted more than once – but different photos of the same specimen that the observer has uploaded in separate observations because they don’t realize they can include more than one photo in an observation.
For taxa that are difficult and often require a variety of perspectives for ID, this multiplies existing challenges because the relevant features are now scattered across different observations. When confronted with such a set of observations, the IDer must now additionally decide whether to consider each observation independently, or whether the likelihood that the photos show the same specimen is great enough that they are comfortable using features visible in one observation when suggesting an ID for another.
On at least one occasion I’ve had a situation where a student doing a project on pollinators has uploaded each photo they took as a separate observation, resulting in several hundred observations with an average of 4-5 observations for each insect that visited a particular plant. Most of these observations were mis-ID’d, because the CV is bad at bees and struggles with uncropped insect photos in general. If the observations only had a general ID, I probably would have ID’d the best photos, left a comment on the others requesting that all photos of the same specimen be put in a single observation, and moved on. But because of the wrong IDs, I and other local IDers were left with a largely unresponsive observer and hundreds of observations that needed fixing – a task that would have been much smaller if there were a way to either mark or combine the duplicate observations in such cases.
(Now, obviously there are other underlying concerns in this particular case – i.e., the fact that the student and/or their advisor clearly did not have previous familiarity with iNat, the lack of appropriate guidance for the student in IDing their own observations, etc. But the example illustrates how this kind of duplicate has an outsized impact on IDing workflows.)