great points, I agree with all of them, and the fungal ones would help me to repeat and learn the life stages of rusts better :)
How about sporophytes - yes/no for mosses?
Well, I’ve certainly done that! And been annoyed at the (slight) effort it takes to not hit the wrong button.
I don’t do much with annotations, so apologies if this has been answered somewhere else.
I just noticed that when I add an ID to an insect which disagrees with the current Order, the “Larva” annotation disappears. Specifically, Sawfly larvae (Hymenoptera) are frequently misidentified as caterpillars (Lepidoptera), and I’ve been seeing that when I add an ID of Sawfly to a larva previously ID’d as Lepidoptera, the “Larva” annotation vanishes. I assume this is because the new CID becomes “Pterygote”, and not all pterygotes have larvae, so “Larva” isn’t an option for “Life Stage” at the “Subclass Pterygota” level.
I can’t imagine that this is a good thing to have happen, because usually one can be more certain that they’re looking at a “larva” than they can about which insect order the larva belongs to. So all the life-stage-annotating that someone performs can be undone if the Order ID was wrong at the time it was annotated.
I can think of two solutions-
- Add “larva” as an option to annotate observations at Subclass Pterygota, since knowing something is a larva is very often possible without knowing what order it’s in.
- Institute “Superorder Holometabola” as a taxon on iNat, since (as far as I know) all holometabolous insects, ie ones with a larval stage, form a single monophyletic clade. This way, two disagreeing IDs on a larval insect’s order will put the CID at the level “Holometabola”, which includes all orders which do have a larval life stage, rather than “Pterygotes”, which includes many orders that lack larval stages.
I’m sure there’s some reason why neither of these things has happened, but I figured I’d ask since I’m not seeing the logic of the current setup.
Thanks!
I think that the reason for this is that in some groups of insects the juveniles are not called larvae. Maybe nymphs? Anyway, there isn’t a consistent word so the option just isn’t there.
Right, this makes sense as to why “pterygotes” can’t be annotated as larvae, but all insects with a true larva form (as opposed to nymphs, naiads, etc.) are one monophyletic group (usually called Holometabola), so it seems it would make sense to have them included as one taxon to prevent this annotation change from happening.
Specifically, the following orders recognized in iNat’s taxonomy under “Pterygote” all form a single clade, and all have immature stages called “larvae”, which then form a “pupa” before becoming an “adult”:
Beetles Order Coleoptera
Flies Order Diptera
Ants, Bees, Wasps, and Sawflies Order Hymenoptera
Butterflies and Moths Order Lepidoptera
Scorpionflies, Hangingflies, and Allies Order Mecoptera
Alderflies, Dobsonflies, and Fishflies Order Megaloptera
Antlions, Lacewings, and Allies Order Neuroptera
Snakeflies Order Raphidioptera
Fleas Order Siphonaptera
Twisted-wing Insects Order Strepsiptera
Caddisflies Order Trichoptera
All other insect orders listed in iNat’s Pterygote taxonomy are outside of this clade, and have immature forms with other names (some are colloquially called “larva”, but they aren’t true larvae in the strict sense). It’s often clear that an insect is a larval form of one of these orders, but unclear which one. It seems like it would be useful to be able to annotate something as a larva without having to commit to it being specifically a fly larva or a beetle larva, for example. But since iNat currently recognizes no taxonomic level between Pterygote and Order, there’s no way to do this, as the next available level above Order is so broad that it includes orders with no larval form at all.
1 Like
This has come up a few times. I don’t know if there is a good solution for it.
https://forum.inaturalist.org/t/life-stages-missing-in-subclass-pterygota/53617/
https://forum.inaturalist.org/t/quickly-find-caterpillar-images/22397/
One possibility is to add such observations to this project: https://www.inaturalist.org/projects/larvae-of-endopterygota
Also, there are some observation field values that are linked to annotations. What this means is if you add an observation field with a relevant value (“caterpillar”, maybe “larva”), a corresponding annotation will be added to the observation once the observation has a community ID for which the annotation is valid.
2 Likes
Unfortunately it’s not that easy, I did some testing on our test server today. I annotated something IDed as Pterygota as larva, which worked. Then I added an ID of Odonata, which ideally should have gotten rid of larva but it didn’t. Changes would have to be more wide-ranging for it to work well. I do think it’d be nice to annotate anything in Insecta as larva and then have that disappear once the observation is IDed as something that doesn’t fit larva. And for the situation you describe, which I also come across pretty often.
Doing this would force many millions of observations to be reindexed. Would probably have to be done during a fairly long downtime.
Just did some playing around with the annotations and it seems like the annotations are being kept but not displayed when the community taxon changes to something that ‘can’t’ have that annotation. E.g. if an observation has an annotation of larva, and then the community taxon changes to something where larva is not an option (e.g. it gets pushed back to Insecta), the ‘larva’ annotation disappears but still seems to exist. It is impossible to add a different life stage annotation, and if the community taxon returns to something which can have larva as an annotation, it returns. I’m assuming this is an unintended feature?
(And for what it’s worth, I strongly support adding in the insect superorders, although I understand it’s a huge reindexing job and simply may not be feasible)
3 Likes
For bird annotations, is there an option for feather for the evidence of presence annotation? If not, I think it would be super beneficial to have that option for bird observation posts.
Never mind, there is the option. :)
To add on to the bird annotations, there should be an annotation for the feather type, such as the wing feathers and the body feathers (I have zero knowledge about feathers tbh), but that would make a great annotation for birds.
For mushrooms, there a lack of annotations that will be extremely important to add. Annotations for mushrooms should include the features of the mushroom present in the observations. The included features that should be included in the mushroom annotations should be gills, shape of the cap, the stalk rings, the attachment to the stalk, the general shape of the mushroom, location of the reproduction of the spores, location of the mushroom, if the mushroom is edible or poisonous, and spore color. These are just ideas of mine that I believe to be very important annotations for mushroom observations and they might be more annotations to be added if anyone wants to chime in on the ideas, please do!
1 Like
There’s an observation field for this: https://www.inaturalist.org/projects/found-feathers/journal/29878-using-the-feather-placement-observation-field-for-learning.
3 Likes
Please note the criteria in the second post in this thread: annotations should be attributes that can be determined independently; they should describe the observation as a whole (not individual photos); they should be broad enough to be applicable to a wide range of organisms.
Annotations are meant to describe basic aspects of organism that was observed (i.e., life stage, whether the evidence was direct or indirect, whether it was alive or dead, etc.). The main purpose is to provide relevant context about the presence and phenology of the organism that was observed.
Annotations do not describe what features are visible in the provided evidence. This would make the number of annotations impossibly long and unmanageable, since morphological features vary enormously across the different kingdoms and orders.
Please also note that annotations can currently only be edited by the observer or the annotater. So it is not easy to correct mistakes.
“Edibility” depends on the ID. This means that if the ID changes, the annotation would also need to be updated automatically; otherwise you would end up with many inaccurate annotations. If a user wants to determine whether a mushroom is edible, they would be better advised to compile a list of edible species for their region.
I also think it would be highly problematic for iNat to make claims about edibility vs. poisonousness in connection with observations that have been ID’d from photos by users who may or may not be qualified to correctly recognize mushroom species.
You could consider documenting things like this using an observation field. There are already a variety of observation fields for fungi that might be useful.
5 Likes
Is there a similar thread for discussing observation fields? I mean best practices, since observation fields differ from annotations in that any user can create them. I have seen some entirely redundant observation fields. “Damselfly life stage” – redundant, because when an observation is identified as a damselfly, the life stages appear as available annotations. “Damselfly species” – redundant, because when a damselfly observation is identified to species, that information is already there. If someone needed this information for a project, couldn’t they set up the project to use the annotations or ID rather than observtion fields?
My understanding is that the point of observation fields is to add useful information that is not provided by the identification, annotations, and metadata. I feel that discussion of best practices for creating identification fields would be helpful.
Any reason you can’t do a forum search yourself to determine whether there is such a thread?
My understanding is that observation fields were intentionally not standardized. This does sometimes result in what may appear to be redundancy, but people create and use observation fields for lots of different reasons. Some may indeed be the result of not understanding how to make full use of the available functions of iNat – or they may reflect a particular user’s needs and workflow that they find convenient. It may seem messy and inelegant, but I don’t see why it is a major problem from a data management perspective: if people find that an observation field is useful and meaningful, it will get a lot of use. If not, it won’t.
1 Like