I read, understand, and agree with what some of the above users say.
But:
A collection project is no different than using the EXPLORE option on the main page. Type in what you are looking for and get all observations.
A collection project just allows you to have a 1 click option.
If I go to the EXPLORE option and hit the tab BIRDS, I get 7854926 observations. Birds of the World Project gives me 7854976 (Can not explain the 50 obs difference). This with 2020 Members out of over 3 million users on iNat.
You endorse the project by becoming a member. Other than that, your information is still publicly available to all to see at leisure. Even in different formats.
So, at the end, would it really make a difference to have an exclusion option for a collection project?
taking my last example, there is a big difference between using explore to look at all the native trees nearby, and stumbling across a project which presents them to me and âbrandsâ the search in terms of logging trees. I would view a project page that promotes âchopping down treesâ to be an alarming place to find my observation of trees that I think should NOT be chopped down!
I wonder if it could be implemented with an observation field, and a small change to the way collection projects work. Iâm imagining a field, maybe named something like âexclude from projectsâ, and you enter the project identifiers that you want to explicitly prevent from including your observation. Then all that is needed is to have all collection projects automatically exclude all observations that have their project id in that field.
[edit] Keeping in mind that it would be a rare thing to happen, but if someone sets that field and value, then perhaps an internal toggle in the project gets set so that the system knows it needs to do such exclusions⌠that way the majority of projects have a very simple check to see if they need to, and then carry on as normal⌠so the burden on the system is minimised.
[xtra-edit] and maybe a field value of âallâ might represent it getting excluded from ALL collection projects, and perhaps the ability to have that field and value be default added to all of your observations, so that you literally could stop your observations auto adding to all projects and then go in and delete that field on specific observations so as to control what projects get to add your observations. Remembering here that before collection projects we had the ability to do just thatâŚ
[ultra-edit] And also consider that it would not be done very often, and not be something that people would do by accident or by just playing around with account settings⌠you literally would have a need and be consciously trying to set it up, and in fact could even be an âundocumented featureâ whereby someone says to another iNatter (on an observation or in the forum) âI wish I couldâŚâ and someone says âwell, actually⌠you can do that byâŚâ
Beg to differ. Collection project is different from EXPLORE option in the case of area definition. Especially it concerns sensitive territories. You will not be able to do EXPLORE on, for example Soviet Union. But it is possible to make such collection project (been made for whatever reason). Same with other such projects when you want to name them including certain ideological meaning.
A collection project may have hundreds of rules. It is more convenient to share a project URL than a search URL with hundreds of filter values.
We can search for projects, or just find interesting projects attached to observations. We cannot search for search URLs used by other people.
If you share a collection project URL with someone, the future usage of this URL will take into account the future rules of the project. On the contrary, sharing a search URL will not allow a future update of the search (you would have to share again an updated search URL).
With a project, you can create a search URL using the filter not_in_project (using the project as an exclusion list for your search URL). You canât do this using only search URLs (a search URL cannot specify, as a filter, the exclusion of the results of another search URL).
Basically, I see projects (of all types) as lists of observations. And lists of items are a very basic and most import feature of information technology in general. In other words, if projects did not exist on iNat, it would be necessary to invent them. For this reason, I am not in favor of restricting their usage. They do [have the possibility to] provide an high added value to iNat, in general.
The original proposal of @bouteloua is most interesting, but I am in favor of this other proposal, for the reasons explained above:
A collection project may, with very simple rules, provide as a result a huge amount of observations. Converting it to a traditional project implies adding a huge amount of data in the database (for each observation, a link between the observation and the project would have to be created).
I guess that we will never be proposed to convert a collection project into a traditional project.
I would like to have an ability to restrict certain projects I disagree with from having my observations within them, current way of asking moderator to put you in filters seems not adequate, I donât want to get in contact with those people.
I recently found a project that collects observations specifically from users who have requested their obs not be added to projects by other users. The title of the project is literally âThis user does not allow their observations to be added to projectsâŚâ. This was brought to iNatâs attention and their response was that collection projects are basically a type of saved search and not a real project. But that seems rather nit-picky and trying to exploit a loophole.
The purpose of this project named âObserver does not allow other people to add their observations to projectsâ (and of the other one named âObserver only allows other people to add their observations to projects they have joinedâ) is, and is only, to spare iNat server ressources by filtering out these observations, when searching for candidate observations to be added to these projects and to a few other ones, so that these observations are not downloaded unnecessarily.
This may be useful (for sparing iNat server ressources) for anyone, or for any automated routine, searching for observations to be added to a traditional project.
In other words, some people do not want their observations to be added to projects. As a consequence, I do not want to download these observations, when adding observations to projects. To avoid downloading these observations, I filter them out. For filtering them, I use 2 collection projects and the not_in_project filter.
These lists are uncomplete (I add manually from 10 to 20 usernames everyday). I have no idea about how many observations cannot be added to traditional projects. For sure, there is a huge amount of observations that are unavailable for any work based on traditional projects.
It still seems to be exploiting a loophole, people have many different reasons for not joining projects and many people believe opting out will opt them out of ALL collection type groups. Iâm also unclear on your other projects for the Unknowns, many observations I identified in my state were in the incorrect group, many were in the wrong kingdom. Once they are identified when and how are they removed?
By now, I donât plan to remove observations from the âphylogenetic projectsâ:
Anyway, identified observations can be filtered out, as one wishes.
Some people are interested in the projects statistics.
Not removing observations spares server ressources.
Pushing an observation to one of these projects is not intended to be like an identification. This is just to help people who would like to focus on identifying a taxon in particular (as I do with the Caesalpinioideae project, where I could identify 65% of all observations in the project).
See this journal post for other questions/responses.
I didnât mean storage space after the observation has been pushed to the project. I meant the work for receiving and interpreting a request to the API, then treating this request by accessing the disk for removing an entry in the database, an entry consisting in a record with a record ID, an observation ID and a project ID.
This is just one of the three reasons I see by now, for not removing observations from these projects. If more people use these projects in the future, we will better see what to do next. I would like to get feedback from more people using these projects. Removing observations is by now a theoretical question, that we can answer later.
As I said above, some people are interested in the projects statistics (what are the species, how many observations they identified, whateverâŚ).
I have a mental framework about what data I choose to share and knowing how it might be used matters to me.
I have also seen where adding more options to users about how their data gets used causes confusion and limits functionality on iNat (sometimes in ways that were likely not the intent). People may assume all sorts of incorrect things about the purpose of the exclusion option. More problematically, most users wonât know when their observations are included in unethical or offensive projects.
I would rather see guidelines about what is permissible for projects and flagging used to resolve violations. I realize that is more work for iNat staff. However, it puts the onus back on project admins to comply with the guidelines and not all users to police all potentially relevant collection projects.
This feature should be added. Itâs frustrating to see a userâs observations in a project as though the project is being endorsed by said user without any option to opt out.
