I think you can. My understanding is that the “fieldspace” is a free-for-all. Tags on the other hand can only be applied by the observation owner. At least, this was the case when I started, it may have changed since. But because it is literally a free-for-all, it would only work if there was concensus on what field name would be used, and a degree of consistancy in it’s application. I’m thinking back to how I implemented the “similar observation set”, only to discover some time after that the idea had been already implemented as “observation group” by someone else (and to be honest, I think it was from having seen that implementation subconsciously that led to my coming up with my own version much later!). In that case it didn’t matter, because both kinda work independantly.
I don’t think it is possible to have a collection project pick up on fields and their values, so we would be looking at manually adding to a traditional project. So it would be either doing it by a field/value OR dong it by manually adding to a traditional project. Remembering the idea is just to “group” the observations somehow to make them easy to find when some future means to process them comes up.
I’ll just add, that they don’t have to be processed. Someone made an observation, and it doesn’t fit the model that iNat goes by, but it doesn’t break the system to just treat it as if it never was made in the first place! Of course, if these “not quite right” observations can be made valid it is better, but I don’t think we need to stress about it too much. We are better off focusing on the value of the observations that DO fit.
The analogy that I like to use here is of wanting to collect a container of rainwater. We can set up a tarp between two trees and direct the rain into the container, and assuming of course there is enough rain, we don’t need to catch EVERY SINGLE DROP! I think iNat observations are a literal torrent these days, compared to when I first joined!