02. Announcing Changes to Projects on iNaturalist


Announcing Changes to Projects on iNaturalist

We’ve introduced some new functionality for projects on iNaturalist! One of the most-requested features related to projects is the ability to automatically include all observations in a particular place or taxon across all time and in a continuously updating manner. Unfortunately, associating observations with projects has been a computationally expensive process, so we have limited “the aggregator” to a small subset of trusted projects, or to time-bound bioblitz projects, to protect site performance. Another common request is the ability to associate two or more projects together under an umbrella, such as all of the projects associated with a single organization.

Starting next week, users can create two new types of projects using automatic collection and umbrella projects. Here’s what the page will generally look like when you go to create a new project (some text will still change):

We can convert many existing projects to the new ‘collection’ project type, providing that its parameters match those on Observations Search, such as taxa, places, dates, and users. We are not able to convert projects that have a “Must be on list” rule. Existing projects that meet the criteria above can be converted to the new ‘collection’ project type by project administrators when you go to edit your project by contacting help+projects@inaturalist.org with the URL of the project you would like to convert (updated on 4/25/18).

Existing projects (let’s call them traditional) came in several flavors. Most (82%) are ‘regular’ with a significant minority (12%) as ‘bioblitz’. A tiny fraction (<4%) were some experimental project types that never really worked well.

The vast majority of projects are created for one of these purposes:

Run a BioBlitz (i.e. collect all observations within space and time boundaries).

Collect interesting observations which couldn’t otherwise be found using Observations Search (e.g. Amazing Aberrants, Observation of the Day).

Gain access to true locations of obscured/private observations and/or filter observations identified by project curators.

Collect additional data using observation fields.

Create a repository of all observations for a place and/or taxon that can be branded, shared, and used for outreach (e.g. to encourage participation in a park or observations of specific taxa).

For educators to assemble observations made by students.

The status quo for projects has been especially difficult for the last two purposes. The limits on the aggregator have been frustrating for people who want all observations from a given place and/or taxon continuously updated. As a result, project owners, managers, and/or curators have had to manually add observations or rely on users to add their observations themselves. Educators have had to rely on students adding their observations to a specific project, which is laborious for the students and/or the educators. New ‘collection’ projects should be an improvement for both of these purposes because you can use standard search parameters to automatically include observations by date added or observed, place, or user (and more).

For example, a professor could add the usernames of all of her students to a project that will automatically capture all observations made and added to iNaturalist during the semester. Then all student observations from the entire semester will be easily visible for her review, enabling her to ensure that the observations are appropriate and identified.

These changes were made in advance of the upcoming City Nature Challenge (organized by the citizen science teams at the Natural History Museum of Los Angeles County and the California Academy of Sciences), which is a perfect use case for an umbrella project. Sixty-four different metropolitan areas around the world will submit observations to iNaturalist made during April 27-30. The umbrella project allows you to easily compare the numbers of observations, species, and participants across several projects at once. For an immediate sense of what it will look like since the event has not started yet, we also created an umbrella project for last year’s City Nature Challenge.

In the near future we plan to include the ability to use observation annotations as additional project parameters, e.g. to only pull in observations from a particular insect life stage. We plan to combine this feature with improvements to the observation search filters tool.

As with any new features, there are always trade offs, and we know that these new projects will not work for all projects and needs. Here are some major differences with new, collection projects (compared to traditional projects):

Collection projects do not provide access to private and obscured coordinates for project admins.

No links on individual observations to the collection projects in which they are included.

No ability to associate additional observation fields with collection projects (fields can still be added to individual observations).



66. Interactions, Relaties, Verbondheid

more details here: https://forum.inaturalist.org/t/add-interactions-to-species-pages/433/16 here are many ways. Have a look at

Now a lot depends on your philosophy.

For instance you can just add an interaction (one of the many fields): and name the other side of the interaction.
But that assumes that you know the other organism, and that if you have it wrong you will fix it, and that if the name changes taxonomically, then you will fix it.

see https://www.inaturalist.org/projects/specific-animal-plant-interactions

My philosophy is that you put both as observations and then link them: that way the community takes care of the identifications, and the link will remain no matter what.
If you follow my philosophy look at:

How can we get this higher up the “desired” list of features?
Both the New Zealanders and southern Africans have projects dealing with this.
Ours is visible at https://www.inaturalist.org/projects/interactions-s-afr 4

Basically, we record only the active interaction (i.e. “a eats b”, not “b is eaten by a” - the latter just being the reciprocal of the first), although user pressure has resulted in us adding a passive field for the reciprocal observation, given that observations fields link only one way, so that these observations do not display their hosts) as:

Visiting flowers: https://www.inaturalist.org/observations?field:Visiting%20a%20flower%20of:%20(Interaction) 6
Eating: https://www.inaturalist.org/observations?field:Eating:%20(Interaction) 5
Parasitizing: https://www.inaturalist.org/observations?field:Parasitizing:%20(Interaction) 1
Attached to: https://www.inaturalist.org/observations?field:attached%20to:%20(Interaction)
Carrying: https://www.inaturalist.org/observations?field:Carrying:%20(Interaction) 1
Associated with: https://www.inaturalist.org/observations?field:Associated%20with:%20(Interaction)
& the passive

Note that in each case the field value is the url of the interacting observation. Unfortunately we cannot use this is a query to summarize the interactions.
We can ask
“What flowers does the Cape Sugarbird Visit?” - https://www.inaturalist.org/observations?place_id=113055&subview=grid&taxon_id=13442&field:Visiting%20a%20flower%20of:%20(Interaction)= 3
but we will only see the bird, and not the flowers, even though all the urls to the flowers are in the field - see: https://www.inaturalist.org/observation_fields/7459 2.

In over 5 years of using this “set” of interactions, we have never had a request to add additional interactions (e.g. Eating = preys on = killing to eat - i.e. “killing for fun” has not cropped up), although it would be nice to have a hierarchical dictionary of interactions (e.g. visiting a flower > pollinating a flower (> for nectar, pollen, oil, gum)/robbing a flower/, etc

I’m happy to leave the test=interactions thing available, I’m just not going to make it visible by default or integrate it into the UI. I don’t think we need to ice this topic, as I think the title sums up what we want pretty well. Personally, I think the Feature Requests category is a way to gauge what kinds of things people are interested in, and not necessarily specific implementation plans, so it’s valuable to me to know how many people chose to upvote this. In fact, I will spend one of my votes on it right now

plant Lantana camara apparently “visits flowers of” 46 species of insects, rather than the other way around https://www.inaturalist.org/taxa/50333-Lantana-camara?test=interactions 13). Is it a functionality you can leave available, or are there reasons not to do so?

We investigated this when we redesigned the taxon page in 2016 (yikes, that was a while ago). I just made it so you can see what we did by appending test=interactions to any taxon page URL, and I’ll use examples to explain why we didn’t develop this any further.

The big problem looming over this whole feature is that observation fields are a bad way to model interactions. Since they represent a totally uncontrolled vocabulary, they’re rife with synonymous fields, so it’s hard interpret situations where, for example, there are both eats and preys on interactions, e.g. https://www.inaturalist.org/taxa/117520-Enhydra-lutris-nereis?test=interactions 28. What’s the difference? Why are both supported?

Another problem is that using observation fields to model interactions means that one of the two taxa in the interaction is not subject to crowdsourced identification, so anyone can say that oaks eat humans and there’s nothing the community can do to correct that. As an example, here’s a butterfly that supposedly eats itself: https://www.inaturalist.org/taxa/51097-Papilio-zelicaon?test=interactions 16. It doesn’t, this is just due to an erroneously added observation field. Site curators could just delete this field, but that’s generally not how we like to perform quality control at iNat.

On top of that, we really wanted to incorporate data from GLoBI 12, since we like them and we think it’s cool that they incorporate iNat interaction data, but mapping taxonomies and field semantics proved a hassle, and again it presents the problem of data that the iNat community can’t correct if they find errors.

What we’d like to do is to make a new feature for interactions where an interaction is a relationship between two observations with clear and controlled semantics (to the extent that that’s possible). So instead adding an obs field that says an obs of an oak represents that oak eating a human, you would create an interaction and have to choose two observations, one of an oak and another of a human, and choose “eating” from a menu of interaction types where “eating” means “taxon A is putting all or part of taxon B inside its body for the purpose of personal metabolism” or something. Other users could then vote on whether that was the correct interaction type, and the two observations could be independently identified. We could try and pre-populate this new kind of data with observation fields, or at least make a tool that helps people review their own interaction obs fields to make new-style interactions out of them. That’s a lot more work, though, and it hasn’t really been a priority, so we haven’t gotten around to it.

Anyway, that’s a long way of saying that I agree this would be cool, but doing it right will take considerable effo

Publicado el agosto 31, 2018 02:48 TARDE por ahospers ahospers


No hay comentarios todavía.

Agregar un comentario

Acceder o Crear una cuenta para agregar comentarios.