Splitting plant obs across
flower
fruit
not doing either
Is equivalent to asking bug guys to ID a beetle
partial view of head, look at those eyes!
bit of wing
diagnostic field mark, brizzles on the squit
Bugs don’t have a ‘body part’ annotation field (afaik), that’s the difference. However, assuming an annotation- and photo-centric concept of iNat (which some tend to favor, it seems), this whole process of body-part-as-separate-obs could start making sense.
On the other hand, bugs already have a ‘life stage’ field, hence the possible reasoning behind the splitting of “observation events” - for example an encounter with an anthill resulting in 2 or 3 observations: “adult caring for a larva” + “larva being cared for by an adult” + “pupa left behind while everybody flees in terror”.
Likely not, and that’s why it is currently discouraged by the iNat rules. However, there is currently nothing wrong with posting 10 photos of the same fox visiting the same garden, if 10 days in a row: it is simply 10 “engaging with nature” events - a stated goal of iNat. As such it does not go against iNat’s “long-term interests” - even though it will definitely clutter scientific datasets, if any :)
I think some of the recent discussion stems from the fact that phenology annotations in plants can be used in several ways. It can be used e.g. as a tool by identifiers filtering for plants in bloom because most field guides and keys require flower characteristics to identify to species. They can also be used by folks studying phenology to determine at which time of the year the plant is blooming or fruiting. These are two different applications of that annotation and sometimes people using it one way (e.g. get pictures of fruits) or the other (e.g. find out peak fruiting time for the species) butt heads with each other over how it should be used. It’s possible to put multiple annotations for phenology on the same observation, unlike IDs. So having pictures of flowers, fruits and two annotations is different from the multiple-species problem, which is impossible to solve by putting both IDs on the obs.
I see that, but this is a rather different situation. In the case I described above, in the (let’s say) five separate “observations”, the encounter would be just one, with the same plant at the same time, in the same place. It is not unusual to find a plant where I’m able to photograph buds, flowers and fruits, together with non-flowering parts (leaves, stem etc.) and the habitat. That would result in five observations, each within seconds of each other of exactly the same plant. I just can’t see how this could be feasible and/or useful.
Not allowed by iNat rules, anyway!
What is feasible (= physically doable + allowed by iNat ‘rules’) and useful (to gain correct photo annotations and phenology data) is to perform these 5 observations over 5 days.
‘Feasible’ because that’s 5 encounters with the same individual (OK), creating 5 observations (OK), each observation recording a distinct organ-phenology annotation/photo (OK).
‘Useful’ because it solves the problem “why am I shown flowers in full bloom, when I ask for fruiting plants?”
Just no, this is not a feasible solution. It makes no sense from a phenology perspective either. If the plant was budding, flowering and fruiting that day, it should all be annotated for that day. What is feasible and correct is to make one observation and put multiple phenology annotations on it. “Annotating” by photo should really not be called an annotation (which is on the observation level) but rather tagging with keywords. It would be awesome if we could put searchable tags on our individual photos to indicate what part of the observation is in them, e.g. stem distal, stem proximal, leaf adaxial, leaf abaxial, close-up of phyllaries, habit etc. Now that would really be useful for sorting some stuff out for IDs. But this is a whole different discussion that should probably happen on one of the many existing threads regarding annotations.
But there are many situations where this is not feasible.
Sure they are thing, but it’s ridiculous to propose they be required in order to add multiple applicable annotations.
What if I am traveling for work and take an evening stroll? I leave first thing in the morning; I can’t visit over multiple days. What if the plant is at the end of a strenuous hike? Fun for one day, but I’m not going to do the same hike 5 days in a row.
I think it makes sense to have photos annotated and the observation’s annotations populated from that. [Note: this would require a method to quickly add annotation to multiple photos in an observation at once, otherwise it would substantially increase the time it takes to annotate.]
Photo 1: Flower shown - annotated as flowering
Photo 2: Fruit shown - annotated as fruiting
Photo 3: Flower buds & flower show - annotated as flower budding and flowering.
Photo 4: Stem photo - not annotated as “no evidence of flowering” because this particular annotation should only relate to the entire organism. In other words, this annotation can only be added in the absence of all other phenology annotations.
From this, the observation (i.e., the entire individual) becomes annotated as flowering, flower budding, and fruiting. So when you filter observations by annotation, you get all observations where the individual has that annotation. But if you are filtering photos on the taxon page, you get only photos with that annotation.
Those are great suggestions but they probably should go into a thread dedicated to discussing and suggesting improvements for annotations, e.g. Let’s Talk Annotations where they will get the on-topic attention they deserve.
When will this field be available for view and use in the Android app? Thanks
And then we need another annotation field for ‘body parts’ (in addition to ‘phenology’), in order to locate photos of non-sexual organs (= not a pic of bud flower or fruit, no matter the actual phenology of the whole individual), in addition to photos of non-flowering plants (= not in bud-/flower-/fruit-ing phenology - which could also trigger automatic annotation as ‘no sexual organs’).
/off-topic
All right, thanks for the reminder.
The (only) direct effect of the flag is that the observation flagged becomes “casual”.
And is removed from the Needs ID pool - which is deliberate.
Since we cannot ID the multiple species and should not ID a chosen one.
Request was February 2019. Five years ago. @graysquirrel
Maybe it would be possible to code it so the “Evidence related to a single subject” flag only shows up in the DQA tab when an observation has multiple pictures. I believe this flag is hardly applicable to observations consisting of a single photo, and it would reduce the confusion for newcomers. On another note, I am welcoming this new addition to the QFA, it’s saving me a ton of time! :)
I think this is an interesting idea, though implementing it would require adding some complexity to iNat. As far as I know, the DQA options are totally consistent across observations currently, and having some disappear or not might cause confusion. This isn’t perhaps as big an issue for the single subject DQA since it is last, but might still be worth considering.
Perhaps after a few months of the DQA being available, it would be possible for staff to check all the observations it has been used in and see how many have only one photo to assess whether this is a problem.
An interesting related DQA issue might be for the Date is Accurate field which I have seen voted for on observations with a Missing Date, which isn’t a good use of this field and can cause problems if a user does edit the observation to add a correct date (as the DQA vote remains with no notification for the date being added).
One issue with DQA options disappearing might be if users are used to ticking the fifth icon down for Recent Evidence and the order changes due to missing options. So instead of making some DQA options only appear when appropriate, it might be better to gray them out and making it not possible to vote.
+1 for graying out unneeded/irrelevant options - better UI design. ‘Hover’ tooltips can help explain the reason.
Since this was launched from
second experiment about accuracy
as @carrieseltzer said in her comment - yes they found the problem, added the solution, and will be monitoring for problems.
Almost due for a third experiment at the end of March?
+1 To this idea too! It’s nice to have a consistent UI design (mouse muscle memory and all ;)
I’ve created a feature request for this here:
https://forum.inaturalist.org/t/prevent-dqa-voting-when-pre-requisite-conditions-arent-met/49859
with some other situations/DQA fields/conditions where I think the principle would apply.
Happy to have any other situations pointed out or refinements!