I’m reviewing the ~50,000 observations that have been submitted to our lab’s traditional project “Never Home Alone.” My goal is to remove observations that don’t meet the project rules (aren’t indoors, etc.), and “confirm” observations that do meet the rules.
I’m trying to decide the best, most efficient way to do this and wanted to know if other users have advice. My current approach (I’ve reviewed a few thousand observations) involves going into the “identify” menu and indicating “reviewed” for observations that meet our inclusion criteria (clicking “R” on the keyboard). This works pretty well, except it’s a bit scary because I don’t think the “reviewed” annotation is actually included in the metadata from iNaturalist data downloads, so I don’t think I have no way of tracking my “reviews” into the future in case something happened to my account. In addition, I can’t share these reviewed/not reviewed annotations with other users (I don’t think?), which makes it hard for multiple different people to review observations (I wouldn’t be able to share with others which observations I have already reviewed).
Some other ideas I have considered:
Make a new private project called “Never Home Alone: Reviewed” where only Never Home Alone curators can submit observations. These curators can then send any “approved” observations to this project. The problems with this are that I don’t think you can quickly (in a single keystroke or two) add observations to a project; plus, I doubt iNaturalist wants lots of projects to start duplicating themselves. Might be confusing from a user’s perspective.
Do something with the observation fields. Perhaps, add an observation field for “Was observation indoors” and then only allow in observations where the user selects “yes.” This isn’t perfect since anyone can add observation fields, not just project curators (I think) but it would at least encourage users to double-check that their observation is indeed appropriate for the project. I’m also not sure how creating a new rule related to an observation field would impact existing project data that don’t follow that rule (it wouldn’t delete all our data would it??).
Maybe something with “tags?” I don’t know a lot about these; maybe we could make an “indoor” tag. But that might have similar issues as observation fields.
Any suggestions folks have would be greatly appreciated!
this information is provided by the API. assuming you have the skills to work with the API (or know someone who can), you can see all the people who have marked any given observation as reviewed.
you can also filter for observations reviewed or not reviewed by a particular person using URL parameters. this is possible even in the Identify screen. for example, if i want to see which observations you have reviewed, I can add &viewer_id=378074 to the URL to specify that I want to see which observations you have reviewed (as opposed to the ones i’ve reviewed).
Ah, ok I didn’t realize that, that’s very helpful. I imagine that I’ll rely on that moving forward.
I guess the one issue with relying on “reviewed” is that providing an ID for an observation automatically marks it as “reviewed,” so classifying observations without being careful to also be noting whether an observation fits inclusions criteria could mess things up. In short, the “reviewed” feature isn’t really designed for the specific use case of approving observations submitted to a traditional project. It would be neat for iNaturalist to provide a bespoke tool for project managers to mark, among themselves, observations that they have confirmed they “want” in the project. If nothing like that currently exists, perhaps this could be a feature request.
since you can force people to add certain observation fields as a prerequisite for submitting observations to your project, i think most people try to handle approval workflows using observation fields. but there is an option to prevent others from adding observation fields to your observations, and in those cases, i’m not sure if that means that other people simply can’t add them, or of it also prevents folks from editing existing observation fields, too. (if you’re allowed to edit observation fields in such a case, then using the API, you could get observations with information about who last edited a particular observation field and which value they selected.)
theoretically, you could create a second account (ex. “home_alone_aprover”) to do reviewing specifically to “approve” items to be included in the project. (techincally, i think this against the terms of service since it’s sort of sockpuppetry, but i personally think you have a reasonable use case here, as long as all that second account is doing is flagging certain observations as reviewed.)
alternatively, you could “fave” observations, if you don’t fave observations usually. there’s not a straightforward way to filter specifically for observations you’ve faved, but most observations don’t get faved at all, and you can filter observations by whether they have any faves, or you can also sort observations by number of faves. (if you use the API, you can also get observations with information about who has faved them.)
this would be useful, i think, but i’m not sure what the right design would be for such a mechanism that would fit all (or most) use cases, and frankly, i’m not sure if there is a design that would be right here.
Is there a reason why you cannot simply delete inappropriate observations? I try to find time to “weed out” irrelevant observations from the projects I administer–usually adding a polite comment to explain why it doesn’t fit.
There are over 50 thousand observations in the project. The problem is not removing inapplicable observations, but determining which ones the curator(s) have already checked to determine whether they are correctly included.
I suppose there isn’t any way to sort by the date added to the project (not date of observation/date of upload)? It seems like that would provide a way to go through the observations and check new additions, but it isn’t part of iNat’s regular search parameters.
Otherwise, perhaps coordinating with other curators to divide up the observations (say, based on geography) would make it easier to keep track of which ones have been reviewed by someone?