Accommodating taxonomists with more ID specificity

[Joseph T Lapp]

Hi everyone!

I'm seeing numerous calls on Twitter for more taxonomists to get engaged with iNaturalist. iNaturalist should survey taxonomists for how they might better leverage them.

I'm a taxonomist specializing in crab spiders. I have attempted to help identify specimens on iNat but stopped after learning that iNat would not capture my effort in a way that prevents me from having to constantly repeat that effort.

I am trying to use custom fields to solve the problem, but so far I'm not seeing how to use them to help.

I need to solve two problems:

(1) I can sometimes ID a specimen with more specificity than any formal taxon but less specificity than any single genus or species. For example, white female Misumessus and Misumena vatia often cannot be distinguished except by looking at genitalia. There are 126 described species of crab spiders north of Mexico, and I can reduce a specimen to one of two species, but iNat only lets me ID to the family thomisidae, therefore specifying it as one of 126.

(2) I can sometimes recognize specimens as belonging to undescribed species, particularly ones I'm in the process of describing. I need to be able to mark these so that I can pull them up by type of undescribed species.

The reason for solving these problems is to save me time and make me efficient. The solutions therefore need to work well with searching and filters. Here are some example searches I need to be able to perform:

(a) Show all specimens that are marked as confusingly either Misumessus or Misumena vatia.

(b) Show all specimens ID'd as thomisids but not having a more specific complex ID (e.g. not also marked as "Misumessus/Misumena").

(c) Show all specimens that I labeled as being of a particular undescribed species.

Without these filters, I see the same specimens over and over when I visit iNat to ID the latest photos. For a while I tried using the "Mark as reviewed" feature to prevent clutter, because I can filter on that, but this doesn't give me search (a) above, which I need for the following reasons:

- To double check my prior IDs (because my ID is only in comments)

- To double check other people's IDs to these confusing complexes (because their IDs are only in comments)

- To revisit prior IDs as understanding of field characters improves

- To locate these groups for research purposes, such as when I want to pull up all possible Misumessus or all possible Misumena vatia (without pulling up all specimens best ID'd to thomisidae)

Charlie Hohn suggested that I try to accomplish such things with observation fields. I made an attempt, but I haven't figured out how to make them helpful.

I created a new observation field called "Best ID complex (spider)" to capture complex IDs such as the following:

- Misumessus/Misumena vatia (all-white non-males often indistinguishable)

- Castianeira crocata/descripta (indistinguishable for some color forms)

- Mecaphesa/Misumenops (indistinguishable in Mexico and southern FL)

- Mecaphesa asperata/carletonica (indistinguishable where range overlaps)

When creating the field, it appeared that I could either leave the field open-ended, or I could pre-specify the available values. I left it open-ended. When adding the field to specimens, I found that it would not autocomplete to values previously specified. I had to know exactly how the complex was written and type it from memory.

I also could not figure out how to restrict searches to just a particular complex. Beyond that, I'm also going to want to be able to restrict searches to specimens for which no complex was provided (so I can only look at specimens requiring further ID).

There is already a field called "tag name" for naming undescribed species. I had the same trouble with it.

The alternative appears to be to create a field with predefined values. I'm okay with that, as long as I can edit the possible values. I'm worried that iNat won't handle this well, because it asks to input the possible values on a single comma-delimited line, whereas there are potentially many ID complexes and undescribed species. It'll certainly be hard to manage the list from a single line.

Can you see how it doesn't make sense for me to put a lot of effort into IDing things on iNat if iNat can't capture much of what I can determine in a way that prevents me and others from duplicating that effort later (often repeatedly!)?

Any suggestions on how I proceed? I would like to be able to use iNaturalist for future research. I made extensive use of BugGuide when creating the new key to crab spiders north of Mexico. Note that BugGuide does capture complex IDs by creating artificial placeholder taxa (e.g. http://bugguide.net/node/view/615582).

Thanks for your help!

~joe

[Charlie Hohn]

A few things though I am just one curator and already have been discussing that.

-I really would love to see more experts on iNat! The 'population' of users is exploding ,especially newer amateurs. This is awesome but without recruiting experts (whether formally trained or self trained) at the same rate, we will lose a lot of the value iNat has to offer.

1) There have been many calls for a way to classify similar looking species between species and genus. I know one concern is that there will be too many unofficial designations. However it seems like an important and frequently mentioned issue which at least could use another look and perhaps soem further progress? Especially with Scott's 'taxonomy curator' idea... I know for plan ts there are several times I'd use this, for instance there are two species of Lonicera that are both invasive and look almost identical, I want to be able to map these but don't want to ID to species level if I don't really know and alternatively if i ID just as 'Lonicera' then it mixes with the native ones and makse iNat useful for tracking these invasive species. I also really want to sedge sub-genus units added and I know one or two have been added but maybe we can find a good global reference and add them all. They are VERY useful for tracking and identifying sedges.

2) The undescribed species issue is one worthy of more consideration too. It's a shame if people DISCOVERING NEW SPECIES are driven away from iNat when they could be welcomed here. This is such a great and egalitarian place for people to start the process of describing new species! I know some have said they were advised not to share observations of undescribed species for some reason... it's sad that we are at that point.

The issue of open ended vs pre populated fields came up for me in a similar case. If you use open ended ones, then slight misspellings or inconsistencies ruin the data. Alternatively if you use pre populated ones it's a pain to add new ones. The biggest issue for me is there is no page to get an index of all field values with links to a query for each. In my case I was interested in tracking species by natural community type (in Vermont we have standardized ones) and by 'unnatural community' ie roadside, etc (needed to create my own types as placeholders for now). In both cases there is no easy way to get to the query, you have to find an observation that already has the required value and click on the field, or else you have to manually 'hack' the URL. I wanted to track the field and its values and links with the iNat wiki but was asked not to do this so i didn't. I am therefore trying to track them with journal entries i repeatedly edit. This is not ideal for a variety of reasons but works for now.  See http://www.inaturalist.org/journal/charlie/11323-vermont-natural-community-field-link-index and http://www.inaturalist.org/journal/charlie/11257-unnatural-community-tracking-update-and-list . I am slowly populating these with values and links over time. Once complete this will create an invaluable index of each natural community in Vermont, where you can sort observations by (non standardized) frequency of occurrence or by taxa... very helpful for species ID searches, mapping natural communities, and ecology research. 

I would love to see a way to search for observations without a field too. For that matter, I would love if all my observations default to 'Natural Community' field as added but blank, and then I can fill them out or enter N/A for each and every one of my observations. But that may be too niche to be useful.

Lastly, Joe, i really hope you stick around. I am fascinated by spiders but know almost nothing. Experts like you are an important part of iNat!

Hoping others have thoughts to add here too...  

[Joseph T Lapp]

Thanks Charlie!

So it sounds you're saying that if I create a field with a restricted set of values:

(1) I can later add values to the same field.

(2) There's no limit on the length of the line specifying field options, at least in practical terms.

(3) It is possible to search for all specimens having that value, but doing so isn't straightforward, and there's no way to do a combined search that simultaneously constrains this field and constrains other fields.

(4) There's no way to search for all specimens not having a particular field set. (This would only be of value with (3) anyway.)

Without the combined search filter, I wouldn't benefit from the field. I'd only be using the field in hopes that someday features would be added that make having used it finally useful.

~joe

[bouteloua]

For #3, I'm not 100% sure what you mean by "combined search". I tested out adding 2 fields to an observation. It appears the URL works correctly when 2 fields are added:

http://www.inaturalist.org/observations?field:How%20many%20plants%3F=1&field:Natural%20Community=Landscaping%2FGarden

For #4, I don't think there is a way to search for absence of a field directly on the UI on the website or through manipulating the URL directly. But you can definitely download to CSV 1) the observations that have the spider complex field and 2) all observations of spiders, and then remove duplicates to find the observations lacking that field. Definitely not ideal, but "Searching for absence of data is generally a lot slower than searching for presence, so we rarely make filters like that."

cassi

[Joseph T Lapp]

Oh wow! That's awesome! How did you add these fields? I see no way to do it on the search filter. Did you manually append them to the URL?

[cassi saari]

Yep, just added to make a frankenstein URL! Like Charlie says you can get the URL for any field by clicking from any observation with that field value:

Which leads to http://www.inaturalist.org/observations?place_id=35&field:How%20many%20plants%3F=1

Then add more fields to the URL by adding an ampersand and the next field/field value (e.g. +  &field:Natural%20Community=Landscaping%2FGarden) to form:

http://www.inaturalist.org/observations?field:How%20many%20plants%3F=1&field:Natural%20Community=Landscaping%2FGarden

Making a journal entry like Charlie has done (or a folder system of bookmarked URLs) is probably the easiest way get back to these.

cassi

--
You received this message because you are subscribed to a topic in the Google Groups "iNaturalist" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/inaturalist/nSXEUKwKvSI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to inaturalist+unsubscribe@googlegroups.com.
To post to this group, send email to inatu...@googlegroups.com.
Visit this group at https://groups.google.com/group/inaturalist.
For more options, visit https://groups.google.com/d/optout.

[Joseph T Lapp]

That works! Here's one I've started:

http://www.inaturalist.org/observations?iconic_taxa=Arachnida&place_id=any&subview=grid&field:Best%20ID%20complex%20(spider)=Misumena%2FMisumessus

A bit of a pain, but I can live with it for now. I second Charlie's request to make all this more convenient.

Thank you!

cassi

To unsubscribe from this group and all its topics, send an email to inaturalist...@googlegroups.com.

[Joseph T Lapp]

Okay, I've created a journal entry as suggested. The entry further explains the need for the field:

http://www.inaturalist.org/posts/11424-about-the-field-best-id-complex-spider

Thank you for your help everyone!

[Joseph T Lapp]

I wonder if I should rename this field to something more intuitive. Possible options:

- Best ID complex (spider)

- Best ID grouping (spider)

- Best field ID (spider)

None perfectly capture the nature of this field, but it would be nice to choose a field name that other people are inclined to use for other taxonomic groups.

[Joseph T Lapp]

Or maybe:

- Improved ID (spider)

[Jon Sullivan]

Interesting discussion.

It reminds me of a problem analogous to Charlie's Lonicera with New Zealand's two "poroporo" species, Solanum laciniatum and Solanum aviculare. They can only be reliably identified to species as adults when flowering or fruiting so we have to identify juveniles and vegetative adults as just Solanum. That's a huge genus so isn't very informative. To get around this, we made a field "It's a poroporo" which we set to "yes" for appropriate observations. We can see these juveniles using http://www.inaturalist.org/observations?place_id=any&taxon_id=50641&field:it%27s%20a%20poroporo=Yes

It's a bit clunky but it works.

There's also the field "Probably this species" (http://inaturalist.org/observation_fields/7180) and "Otherwise this species" (http://inaturalist.org/observation_fields/4948) that I set up recently but I think could be generally useful for situations like this. Both of those fields are taxon lookup fields so you get linked into the iNat names database.

Undescribed species are a trickier Pandora's box. There's been a temptation to add those all onto the official names tree, but that would make a mess. I think it's better to keep them aside in Observation fields until a new name is described. As an example, here in New Zealand we're waiting for our Lycaena butterflies to be revised. Tag names for several undescribed species have been suggested by the entomologists most familar with the genus. We've bundled those up into three fields with drop-down lists of their tag names (http://www.inaturalist.org/observation_fields/2129, http://www.inaturalist.org/observation_fields/2130, and http://www.inaturalist.org/observation_fields/2131) for the three groups of Lycaena we have here. When the revision is complete and published, observations with those tag names that are supported and named in the publication can be easily found and properly identified.

Cheers,

Jon

[Charlie Hohn]

Good stuff! Joseph, you're correct in your statements but Cassi beat me to it :)  Jon, that is helpful too. However there are more cases than just the Lonicera so I don't want to make a special Lonicera field for just that case. In cases where it's one of two species, perhaps one could create two fields to deal with that, but sometimes there are more than two options, like when you know a sedge is in the 'vesicariae' group. So maybe a 'best ID complex (plants)' field is the way to go. In the case of plants there may be too many of them for the dropdown to be useful, so i may create yet another journal entry for this.

Also maybe i'm mentally a teenager but I found this phrase in the blog post hilarious: " Users rarely post genitalia to iNaturalist..."

ha!

[Joseph T Lapp]

I found a page on BugGuide referring to one such ID complex as a "holding bin."

[Charlie Hohn]

I like that phrase.  But i already went and created a field:

http://www.inaturalist.org/observation_fields/7184 and http://www.inaturalist.org/journal/charlie/11436-best-id-complex-plant-field-index

of course not much time is invested in it yet so if you change yours i should change mine to match. Might as well be consistent about this. 

[Joseph T Lapp]

I found a second page on BugGuide that uses the term "holding bin." Yeah, we should be as consistent as possible. Let's make the switch before it's a big deal. Mine will be:

- Holding bin (spider)

--
You received this message because you are subscribed to a topic in the Google Groups "iNaturalist" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/inaturalist/nSXEUKwKvSI/unsubscribe.

To unsubscribe from this group and all its topics, send an email to inaturalist+unsubscribe@googlegroups.com.

[Joseph T Lapp]

Okay, I've renamed it to "holding bin." That changed the title of my post too! New link:

http://www.inaturalist.org/journal/arachnojoe/11424-about-the-field-holding-bin-spider

[Charlie Hohn]

thanks! plant one is updated too.

http://www.inaturalist.org/journal/charlie/11436-holding-bin-plant-field-index

On Sunday, September 3, 2017 at 11:37:17 AM UTC-4, Joseph T Lapp wrote:

Okay, I've renamed it to "holding bin." That changed the title of my post too! New link:

http://www.inaturalist.org/journal/arachnojoe/11424-about-the-field-holding-bin-spider

On Sun, Sep 3, 2017 at 10:22 AM, Joseph T Lapp <arach...@gmail.com> wrote:

I found a second page on BugGuide that uses the term "holding bin." Yeah, we should be as consistent as possible. Let's make the switch before it's a big deal. Mine will be:

- Holding bin (spider)

On Sun, Sep 3, 2017 at 10:07 AM, Charlie Hohn <naturalis...@gmail.com> wrote:

I like that phrase.  But i already went and created a field:

http://www.inaturalist.org/observation_fields/7184 and http://www.inaturalist.org/journal/charlie/11436-best-id-complex-plant-field-index

of course not much time is invested in it yet so if you change yours i should change mine to match. Might as well be consistent about this. 

On Sunday, September 3, 2017 at 11:04:31 AM UTC-4, Joseph T Lapp wrote:

I found a page on BugGuide referring to one such ID complex as a "holding bin."

--
You received this message because you are subscribed to a topic in the Google Groups "iNaturalist" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/inaturalist/nSXEUKwKvSI/unsubscribe.

To unsubscribe from this group and all its topics, send an email to inaturalist...@googlegroups.com.

[phidippu...@gmail.com]

Added for 'True Bugs' as well

https://www.inaturalist.org/journal/carnifex/11440-about-the-field-holding-bin-true-bugs

[Joseph T Lapp]

@bouteloua did some experimenting and found that we CAN use drop-down lists of allowable values, even when there are thousands of values. Charlie and I have changed the plant and spider holding bins to use drop downs.

It looks like we've got quite a trend going now -- plants, spiders, true bugs, amphibians, and birds, so far.

https://www.inaturalist.org/observation_fields?utf8=%E2%9C%93&q=holding+bin&commit=Search

[myxomop]

I'm very new to iNat, and am attempting to adapt this for use with fungi.  The biodiversity site to which I have devoted the majority of my time, Mushroom Observer, allowed for the creation of sensu lato names, and this allowed us to distinguish between them and their sensu stricto counterparts.  An example might be Agaricales Underw., which at one time contained all gilled fungi.  That is no longer the case, as gills developed independently in many, many lineages, and gilled fungi can now be found in several orders.  Agaricales Underw. remains active and valid, while Agaricales sensu lato serves as an important way to designate/refer to gilled fungi despite the ongoing changes in taxonomy.  The same is true for puffballs/gasteroid fungi, who all once lived inside of the name Gasteromycetes Fr., a group we now know to be artificial and highly polyphyletic.  Calling them "Gasteromycetes" Fr. (note quotation marks) on MO has let us acknowledge that they belong to a particular body form, and not just until they are further identified, but alongside that identification, so that anyone wishing to query the site for puffballs -- no matter their level of identification -- may do so.

With fungi on iNat, I'm finding that no such distinction mechanism exists.  Unknown gilled mushrooms are IDed as Agaricales s.s., whether or not they truly belong there, and any unknown puffballs are placed in the defunct Lycoperdaceae (Agaricaceae is the current family).  Similar issues exist for a wide range of fungi.

Simply put, is there a way that the holding bin feature -- or any other site tweak/workaround for that matter -- could help with these fungi-specific issues on iNat?

[Scott Loarie]

You could certainly use observation fields for tagging observations with names that don't fit into the iNaturalist taxonomy. This could include non-taxonomic groupings never meant to map to taxonomies like 'tree' or names  like "Gasteromycetes" that as you say maybe no-longer are taxonomic groupings but maybe once were.

But Identifications should be reserved for referring to nodes on the 'iNat taxonomy'. 

The iNat taxonomy changes all the time (iNat curators are in charge of this) and the system does a pretty good job of keeping everything in sync after a change is made. I'll quickly describe how the iNat taxonomy deals with this taxonomic concept issue you've raised. On iNaturalist taxa can be active or inactive.  'iNat taxonomy' is the set of all active taxa and the relationships among them (ie how they are grafted to one another). Each taxon is (or should be if the clade is sufficiently well known) explicit about its concept. This can happen in several ways:

1) Distribution information

taxa can be associated with taxon ranges, listed taxa, and atlases http://www.inaturalist.org/pages/atlases

each of these can imply the taxonomic concept we're referring to

2) Taxonomic Schemes

A taxonomic scheme can be used to track which taxa are represented in which external sets of  taxa. For example, on this taxon change http://www.inaturalist.org/taxon_changes/23206 on the left hand side of the change beneath Rhinella marina 67129 (aka Rhinella marina sensu lato) under 'schemes' you can see that this same concept is represented in the following taxonomic schemes IUCN Red List of Threatened Species. Version 2012.1, Amphibian Species of the World 5.6, Amphibiaweb. 2012,  etc.

meanwhile Rhinella marina 553515 (aka Rhinella marina sensu stricto) on the right side is in Amphibian Species of the World 6.0

3) By implication based on position on the tree (ie descendants, ancestors, and siblings)

Click on the taxonomy tab here http://www.inaturalist.org/taxa/32049-Elgaria

and note that there are 7 members of the genus Elgaria and theres a *new* badge that says this genus is complete (ie all the relevant species should be accounted for). IUCN and some other sources consider lizards on Los Coronados to be the distinct species Elgaria nana (http://www.inaturalist.org/taxa/32057-Elgaria-nana). But by implication, since there's only 7 members of Elgaria listed and Elgaria nana is missing, we could imply that the iNat concept of Elgaria multicarinata must also contain lizards from Los Coronados (aka Elgaria nana)

iNat uses this distribution information, taxonomic schemes, and implication via the structure of the tree together in order to try to be explicit about the taxonomic concept that each taxon is referring to.

If the taxonomy changes, iNaturalist curators generally make a new inactive taxon referring to some different concept, make that concept explicit using 1,2,&3 above and then make a taxonomic change to inactivate the old concept, activate the new concept and move all the observations and other content accordingly to keep everything in sync.

For example, above I referred to this taxon change http://www.inaturalist.org/taxon_changes/23206 which split Rhinella marina (sensu lato / sensu Amphibian Species of the World 5.6 and others) http://www.inaturalist.org/taxa/67129-Rhinella-marina into Rhinella marina (sensu stricto / sensu Amphibian Speices of the World 6.0) http://www.inaturalist.org/taxa/553515-Rhinella-marina and Rhinella horibilis

Note that Rhinella marina (sensu lato) has a different taxon_id: 67129 than Rhinella marina (sensu stricto) with taxon_id: 553515

these different taxonomic concepts both coexist in iNaturalist but only one is active (Rhinella marina sensu stricto with taxon_id: 553515)

Re: our earlier discussion of author citations, its unclear how this would help in this task of distinguishing taxonomic concepts. For example, the proper author citation for Rhinella marina is (Linnaeus, 1758) regardless to whether we're referring to Rhinella marina (sensu lato) http://www.inaturalist.org/taxa/67129-Rhinella-marina or Rhinella marina (senus stricto) http://www.inaturalist.org/taxa/553515-Rhinella-marina so including (Linnaeus, 1758) won't help distinguish these. As I described above, iNat can use taxonomic schemes to be able to distinguish Rhinella marina (sensu Amphibian Species of the World 6.0) from Rhinella marina (sensu Amphibiaweb. 2012) etc., but thats not really the same as author citations in the formal sense.

Best,

Scott

--
You received this message because you are subscribed to the Google Groups "iNaturalist" group.
To unsubscribe from this group and stop receiving emails from it, send an email to inaturalist+unsubscribe@googlegroups.com.

To post to this group, send email to inatu...@googlegroups.com.
Visit this group at https://groups.google.com/group/inaturalist.
For more options, visit https://groups.google.com/d/optout.

--

--------------------------------------------------
Scott R. Loarie, Ph.D.
Co-director, iNaturalist.org
California Academy of Sciences
55 Music Concourse Dr
San Francisco, CA 94118
--------------------------------------------------

[Joseph T Lapp]

Interesting! Where can I read more about the scheme structure?

So I have a question that relates both to the original topic and your last response. The problem creates a bit of a mess in iNat IDs.

The crab spider genus Coriarachne was split by Ono 1988 into Coriarachne and Bassaniana on the basis of Bassaniana having a hood on the female genitalia. Crab spider taxonomists know that Bassaniana does not have a hood. The split is invalid, but no revision has been published making this correction. Instead, Charles Dondale and I say that this division is dubius in our recently published key to the thomisidae north of Mexico.

Meanwhile, the ranges of the North American species designated Coriarachne and Bassaniana overlap in the region of the Rockies, and so far we don't know how to distinguish the species except by examining genitalia. Given that the genus Bassaniana is invalid, we have 3 different ways to label records of this group:

- Coriarachne (across the entire range)

- Bassaniana (eastern North America)

- Thomisidae (Rockies)

In the latter case, we would use the new "Holding bin (spider)" field to indicate "Bassaniana/Coriarachne."

But that's two or three equivalent ways to provide the same genus-level ID, depending on the location. This makes mapping and monitoring this group problematic.

How are such issues resolved in the iNat taxonomy? The simplest resolution is to eliminate the genus Bassaniana, despite the fact that Coriarachne has not been revised again to correct the mistake. Then there would be only one way to label all records across North America.

More generally, what's the process for incorporating taxonomist wisdom into the iNat taxonomy?

[Scott Loarie]

Hi Joe,

Well with regard to spiders, the current iNat curator policies

http://www.inaturalist.org/pages/curator+guide#policies

are to use the World Spider Catalog as iNat's External Source Taxonomy for Spiders.

Thats Approach 2 of the 3 approaches I described in this thread earlier today:

https://groups.google.com/d/msg/inaturalist/_xoTyeyfuiM/fMYmmaTbAwAJ

It looks like World Spider Catalog still considers Bassaniana split from Coriarachne

http://www.wsc.nmbe.ch/search?sFamily=&fMt=begin&sGenus=Coriarachne&gMt=begin&sSpecies=&sMt=begin&multiPurpose=slsid&sMulti=&mMt=contain&searchSpec=s

So under the current iNat curator policies for Spiders, we probably shouldn't lump Bassaniana into Coriarachne since this would involve deviating from the External Source Taxonomy for a clade thats going with Approach 2.

Alternatively, iNat could take a different approach for spiders. For Amphibians, we had a similar situation where people mostly were okay with using Amphibian Species of the World, but there were a few places where the curator community was reluctant to embrace it as the single External Source Taxonomy. So I came up with this alternative (Approach 3) which I've been experimenting with for amphibians:

http://www.inaturalist.org/journal/loarie/11101-internal-reference-taxonomies-amphibian-pilot

essentially, it involves mostly anchoring to an external source taxonomy while being extremely explicit about any deviations and tracking these in an Internal Reference Taxonomy. So far, I think its working pretty well but no question it involves a lot of work from the person in the role of Amphibian czar (me in this case)

But there's certainly nothing stopping expanding this approach for other taxa. For example, the iNat curator policies for spiders could be Approach 2 (ie World Spider Catalog) for all spiders except Thomisidae and for Approach 3 for Thomisidae. But that would depend on a Thomisidae czar like you stepping forward, getting buy in from the community, and taking on the work of constructing the Internal Reference Taxonomy, keeping abreast on and getting buy in for deviations from the Word Spider Catalog and keeping iNat in sync with it.

Best,

Scott

P.S. There's also nothing set in stone with these 3 approaches. Very curious to hear alternatives. iNat essentially started out with just Approach 1, but because it produced lots of arguments about taxonomy things mostly pivoted to Approach 2. I introduced Approach 3 with my amphibian experiment last month as an exploration into alternatives

--

You received this message because you are subscribed to the Google Groups "iNaturalist" group.
To unsubscribe from this group and stop receiving emails from it, send an email to inaturalist+unsubscribe@googlegroups.com.
To post to this group, send email to inatu...@googlegroups.com.
Visit this group at https://groups.google.com/group/inaturalist.
For more options, visit https://groups.google.com/d/optout.

[Patrick Alexander]

As a taxonomist with friends who think highly of iNaturalist, there are a few reasons I haven't so far been tempted to join the platform and, on looking into things a bit more today, do not see it as likely to be a workable platform for me. Some of those have been touched on by other posts in this thread. Here's my list:

1) I need to be in control of my own nomenclature, including ad hoc groupings. I don't really care what the default iNaturalist nomenclature is or have any interest in changing it, I just need to have the ability at minimum to apply my own names to my own data. As an example of how this might work, in my job I have to interact with the USDA PLANTS names. So I have a table that translates from my names to the USDA PLANTS names. Ideally, you'd have a database that includes all published names and then, for each of an indefinite number of particular taxonomic systems (from public sources as well as one-off uploads by users), a set of accepted names and synonymies indicating the disposition, in that system, of each published name. Ad hoc groupings could just be names, marked in some fashion as names of convenience rather than formal scientific names, accompanied by a list of subsidiary taxa. What I would want on my end is the ability to upload and use my own nomenclatural system from csv. Manually creating new observation fields in iNaturalist to handle each taxon or ad hoc group not included in iNaturalist's default nomenclature, as discussed above, sounds like a kludge for trying to do taxonomy in a data structure that is very much not built for that purpose. That kind of flexibility should be built in from the ground level. Done correctly, the response to "what taxonomy do you use?" is, "well, what taxonomy do you want to use?" No one needs to argue about what the right name is if we can specify what the right name is for our own use. So long as iNaturalist has a built-in List of the Right Names, we should be arguing about what those right names are.

In the Rhinella marina example given above, if I upload a user-defined taxonomy in which Rhinella horribilis is a synonym of Rhinella marina, you know I'm using the name Rhinella marina in the broad sense; if I upload a user-defined taxonomy in which the two are not synonyms, you know I'm using Rhinella marina in the narrow sense. If I just say "Rhinella marina" with no further clarification, we rely on whatever way of parsing it out is built into iNaturalist. If I sometimes want to use the broad sense and sometimes want to use the narrow sense, my user-defined taxonomy should include the two names as non-synonymous, with a third ad hoc name, e.g. "Rhinella cf. marina", defined as "Rhinella marina or Rhinella horribilis". If I want to see data reported out one way or the other, that also should be possible. "67129-Rhinella-marina" appears to be a way of saying "Rhinella marina or Rhinella horribilis" and thus a synonym of my "Rhinella cf. marina". It logically includes all observations of either 517119-Rhinella-horribilis or 553515-Rhinella-marina. However, it appears that the taxonomic database in iNaturalist doesn't understand this. If I wanted to see all observations attributable to 67129-Rhinella-marina, I would have to look up all observations under 67129-Rhinella-marina, 517119-Rhinella-horribilis, or 553515-Rhinella-marina. This seems to me like a really odd way of managing the data, to me. Rhinella marina is one name and its scope is defined by what other names are synonymous with it. Instead, iNaturalist has Rhinella marina as two names, apparently defines the relationship between those two names and Rhinella horribilis appropriately, but in managing the observation data acts as though each is an independent name with no relation to the other two!

I suspect this would a big issue for many taxonomists. Personally, I can't imagine having the primary home of my data be a database where I don't have any control over the nomenclature. That's a total non-starter. Even as a mirror just used to push my data out into the public, it's not appealing. I want people to at least have the ability to see my observations under the names I believe to be correct.

2) I would need the ability to upload pictures from csv; e.g., a field in an observation table with a URL pointing at the relevant picture. Uploading pictures one at a time is fine if you only have a few dozen, beyond that it becomes unworkable. Editing EXIF consistently across multiple years / many photos is also prohibitive. In my particular case, my photos are already online and linking observations to URLs is either already complete or trivial. That's probably an unusual case, but I'm sure anyone with a big pile of observations is going to run into the same problem. I'm not sure if there's a great universal solution.

3) I would need to be able to update my records from csv uploads. The "upload to the web, then manage in the web" model means that you either commit yourself to using a clunky web-based interface that you don't really have any direct control over, or leaving orphaned data around piled around different parts of the internet that you can't effectively update or do anything with. Neither option is appealing. Ideally, I have my own tables in whatever format, maintain those tables as my own primary data storage / management method, can specify a record ID field that is consistently used within those tables, and can periodically upload data in a form that would add new observations and update existing observations. This also includes pictures; if I update a photo in some way, there needs to be an automated way of dealing with this, not a manual web-based delete and reupload process. In any case, one way or the other I am going to maintain my own data storage / management and iNaturalist will be useful to the extent it can be kept updated from my data.

4) I would need to know how to deal with data that has been entered into multiple interacting biodiversity databases. For instance, I have pictures on SEINet and USDA PLANTS, both basically orphaned data because I can't really manage them effectively on those platforms (SEINet has a clunky web interface... USDA PLANTS, well, last I checked, any update relied on emailing the sysadmin!). SEINet pulls some data from both USDA PLANTS and iNaturalist. So, suppose I upload some observations to iNaturalist that duplicate observations in SEINet. What happens? I have no idea. Does it just end up duplicated on SEINet? If I correct the ID or other data in one platform, will it propagate to the other? Or does the propagation only happen in one direction, so I need to choose that system in which to make any updates? Or am I stuck trying to update each system independently?

I realize that this probably just sounds like me kvetching (which, to some extent, is exactly what it is!) and I realize that no one at iNaturalist has any obligation whatsoever to care about or address any of my concerns. So, please ignore as you see fit! I also realize that I know little enough about iNaturalist at this point that it is entirely possible some or all of these concerns are addressed in a way I am not aware of. In any case, if the question is, "How do you get taxonomists to use iNaturalist?" well, for me, as one particular taxonomist, my answer is that I'd be a lot more likely to use it if I believed there were good solutions to the problems I highlight above. It basically boils down to: taxonomists need to be able to run their own taxonomy, and anyone with a large pile of data that is already in some kind of organized form is going to need good tools for uploading that data to iNaturalist and synchronizing iNaturalist with the local data as needed.

[Charlie Hohn]

Hmm I don't understand how #1 would work. As i understand it you want to create your own parallel taxonomy that would not match that which others are using? I don't see how that would work as then you couldn't share things to the same database unit as others would have used it, which would mean you effectively couldn't share biodiversity information, which defeats a large part of the purpose of this site.  If you want to use fields it seems like a clear case for using fields, maybe we should focus on making the fields interface better rather than having everyone use taxonomy differently.

But maybe i am just misunderstanding :)

[Patrick Alexander]

You can share data easily & transparently so long as the database understands how one taxonomic system maps onto the other. Here's a simple example. Suppose we have a set of five names:

Phemeranthus aurantiacus

Talinum aurantiacum

Talinum angustissimum

Talinum aurantiacum var. angustissimum

Talinum whitei

Now suppose we have two alternate taxonomic systems for these five names, which differ both in how many species are recognized and what genus should be used.

System 1:

Accepted name: Phemeranthus aurantiacus; synonyms: Talinum aurantiacum, Talinum angustissimum, Talinum aurantiacum var. angustissimum, Talinum whitei

System 2:

Accepted name: Talinum aurantiacum; synonyms: Phemeranthus aurantiacus, Talinum angustissimum, Talinum aurantiacum var. angustissimum

Accepted name: Talinum whitei; synonyms: [null]

If each observation in the database is associated with one of these five names, and you want to allow users to use whichever of these two systems each prefers, the database just needs to have the synonymy information above and search / report information accordingly. For instance, if I'm using system 1, a record associated with the name "Talinum whitei" should be displayed to me under the name "Phemeranthus aurantiacus". If I'm using system 2, that same record should be displayed to me under the name "Talinum whitei" The problem you'd run into here is that records entered under the name "Phemeranthus aurantiacus" by a system 1 user would not be assignable by synonymy alone between Talinum aurantiacum and Talinum whitei. Unless there's an effective way to use other data (e.g., geography as in the Rhinella marina example) to sort that out, all records entered under the name "Phemeranthus aurantiacus" by system 1 users would have to be displayed as "Talinum aurantiacum or Talinum whitei" to system 2 users. This now requires that each observation in the database be associated both with one of these five names and with the taxonomic system used by the observer.

These kinds of issues can get pretty messy, of course. However, I think any database that wants to really be used by taxonomists is going to need to tackle this at some point. At present, what you have to do is, of course, all the same sorting and interpretation of synonymies I describe above... but in your head, rather than in the software! And for researchers who work on particular taxa and have strong opinions about the correct taxonomy, the approach above allows the two to interact with and share the same data transparently. Going with the List of Right Names approach, on the other hand, basically requires iNaturalist to decide which one of those researchers is correct and tell the other one, "Sorry, you're wrong." Now one of the two researchers can work easily with the data, and the other is basically told to shove off. That's not good.

[Charlie Hohn]

To me that sounds like an absolute database nightmare. But i'm an ecologist not a programmer, and I'm not an iNat admin, so it's not my call.  

Taxonomy is a mess.

[cassi saari]

Regarding your last question, unfortunately not :( 

Though you can get a scientific names only view if you choose an obscure language in your site settings. See 

https://groups.google.com/forum/#!topic/inaturalist/2gTDmvIlCPU

https://groups.google.com/d/msg/inaturalist/y7bfvoa4m2I/zuAGwIOABAAJ

cassi

On Fri, Sep 8, 2017 at 1:48 PM, Patrick Alexander <paal...@polyploid.net> wrote:

From a database side, I think any fully functional implementation of taxonomic names needs to include explicit information about synonymies and the ability to use that information in entering, searching, and reporting observations. This is definitely not prohibitively difficult, since various online databases have precisely that kind of functionality - for instance, if I search for "Boechera stricta" on SEINet, I get back all observations identified as Arabis drummondii as well, because SEINet knows that Arabis drummondii is a synonym of Boechera stricta. In the simplest case, this just requires a taxon table that has one field for "taxon name" and a second field for "synonym of". Once you have that kind of functionality, implementing different taxonomic systems minimally requires allowing there to be multiple taxon tables and a user-controllable switch somewhere telling the database which one to use. To deal with things like the "Talinum aurantiacum or Talinum whitei" example described above, presumably you need the ability to compare two taxon tables to identify cases in which a single taxon in table 1 maps onto two taxa in table 2, and each observation would need to include an ID field indicating which taxon table was in use by the observer.

So long as I'm here and poking at you all, is there a switch in my user settings somewhere to change between a "common names and scientific names" view and a "scientific names only" view? That's another thing that, as a taxonomist, is kind of immediately off-putting. The user interface is very common-name-centric.

--
You received this message because you are subscribed to a topic in the Google Groups "iNaturalist" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/inaturalist/nSXEUKwKvSI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to inaturalist+unsubscribe@googlegroups.com.

[Patrick Alexander]

From a database side, I think any fully functional implementation of taxonomic names needs to include explicit information about synonymies and the ability to use that information in entering, searching, and reporting observations. Various online databases have that kind of functionality - for instance, if I search for "Boechera stricta" on SEINet, I get back all observations identified as Arabis drummondii as well, because SEINet knows that Arabis drummondii is a synonym of Boechera stricta. In the simplest case, this just requires a taxon table that has one field for "taxon name", a second field for "synonym of", and the ability to do lookups between those two fields. Once you have that kind of functionality, implementing different taxonomic systems minimally requires allowing there to be multiple taxon tables and a user-controllable switch somewhere telling the database which one to use. To deal with things like the "Talinum aurantiacum or Talinum whitei" example described above, presumably you need the ability to compare two taxon tables to identify cases in which a single taxon in table 1 maps onto two taxa in table 2, and each observation would need to include an ID field indicating which taxon table was in use by the observer. 

With the exception comparing taxon tables, this is all stuff that I've implemented myself in Excel or know exactly how I would implement. Comparing taxon tables is clearly doable in Excel but would probably take me a few hours to figure out. I assume that anything a botanist can figure out how to do in Excel a programmer would find fairly trivial in real databases.

So long as I'm here and poking at you all, is there a switch in my user settings somewhere to change between a "common names and scientific names" view and a "scientific names only" view? That's another thing that, as a taxonomist, is kind of immediately off-putting. The user interface is very common-name-centric.

[Scott Loarie]

 for instance, if I search for "Boechera stricta" on SEINet, I get back all observations identified as Arabis drummondii as well, because SEINet knows that Arabis drummondii is a synonym of Boechera stricta.

iNat does that too: http://www.inaturalist.org/taxa/search?utf8=%E2%9C%93&q=Arabis+drummondii

 

--

You received this message because you are subscribed to the Google Groups "iNaturalist" group.
To unsubscribe from this group and stop receiving emails from it, send an email to inaturalist+unsubscribe@googlegroups.com.
To post to this group, send email to inatu...@googlegroups.com.
Visit this group at https://groups.google.com/group/inaturalist.
For more options, visit https://groups.google.com/d/optout.

[Scott Loarie]

Hi Patrick,

You've raised a couple of interesting issues here. Re: uploading and updating photos from CSV - I agree that could be useful for folks in your position.

Re: taxonomy. I think you've raised 2 important topics: (1) tools for folks who want to opt out of the iNat taxonomy and do their own thing (2) ways to improve coming to a consensus iNat taxonomy that we all use

Re: (1) tools for folks who want to opt out of the iNat taxonomy and do their own thing, iNat already has pretty good tools to do this. For example, here's an obs that I uploaded using the 'placeholder' feature as 'Rhinella cf. marina'. I can enter any placeholder I want and not be bothered by the iNat taxonomy at all. I've also opted out of the Community ID on my account settings which means no IDs added by the community will alter or contribute to the name I'm giving this observation. As was also mentioned in this thread, you can also use tags and observation fields to enter custom names independent of the iNat taxonomy. Both are searchable too. I'd actually recommend rather than using a placeholder, adding an ID of your 'common ancestor' with the iNat taxonomy (in this case maybe Rhinella or Bufonidae) and then using tags or observation fields to enter your custom name so that your observation both interacts with the iNat taxonomy AND preserves your custom name. This is sort of what GBIF does when it harvests data from partners like iNat. It preserves the name provided by the partner, but attaches the record to the nearest ancestor it can find on the GBIF Backbone Taxonomy (ie if it can't find Rhinella cf. marina it attaches the record to the Genus Rhinella, if not that Bufonidae and so on...)

Re: (2) ways to improve coming to a consensus iNat taxonomy that we all use, iNat has a system for maintaining synonyms on taxa. For example, in the example you gave, the name Arabis drummondii is maintained in iNat as an invalid synonym of Boechera stricta check the Taxonomy tab here under Names: http://www.inaturalist.org/taxa/75824-Boechera-stricta 

So while the iNat taxonomy only has one Valid name for each taxon, it is aware of the invalid synonyms and will respond to searches for Arabis drummondii by directing to Boechera stricta etc. Of course for issues where the mapping is not 1-to-1 (ie splits and lumps) synonyms become a bit more complicated. 

But in all cases, iNat is explicit about what concepts the iNat taxonomy is referring to: e.g. Rhinella marina (sensu lato) vs. Rhinella marina (sensu stricto). Only one is 'active' at any time in the iNat taxonomy (at the moment its Rhinella marina (sensu stricto) since the taxon was recently split) but if you want you can still use Rhinella marina (sensu lato), just be aware that that taxon is inactive. For example, here's an obs of Rhinella marina (sensu lato) http://www.inaturalist.org/observations/7615884 ID'd by someone who opted out of the community ID. The only difference is that iNat indicates that this is an inactive taxon with regards to the iNat taxonomy.

While people can do their own thing on iNat (and often do) much of the spirit of the site is to have people working together to paint a larger global picture of life on earth that we've all contributed to. If everyone were doing their own thing, this would be hard to achieve. For example if you posted and obs of a Boechera and I identified it as a camel because according to my taxonomy camels includes lamas, alpacas and mustards that would cause a huge mess even if the mapping was totally explicit between every possible tree from every possible user. Just to say that the spirit of iNat is to allow folks to do their own thing but also to encourage coming to a consensus around things like taxonomy, and other shared things on the site that effect everyone (ie conservation statuses, standard places, annotation values etc.)

In terms of coming to consensus around certain clades, you seem to have alot of expertise with Boechera. Currently iNat is using external sources (like the Plant List) for the iNat taxonomy in most places. But you could certainly imagine having more community control over clades where there's enough expertise and commitment from iNat curators. For example, I did a quick 'excel' check and it looks like there are alot of discrepancies between the list of Boechera on FNA (which includes all but 1 or 2 russian species) and the Plant List. I've attached a table comparing these. From someone like yourself who is familiar with this group - what should the consensus taxonomy be fore this group that, even if its not perfect, we can all use as a common reference for posting obs and making identifications?

Best,

Scott

[Charlie Hohn]

one other note, unless i am mistaken, currently the placeholder is erased if another user adds another ID, which has caused me and others problems before. We should make sure to fix that, if we haven't yet.

[Scott Loarie]

Not if you've opted out of the CID - so would work fine for the use case I described, let's use that other thread for the placeholder issue/use case you're concerned about which I can't remember off hand

Sent from my iPhone

--

You received this message because you are subscribed to the Google Groups "iNaturalist" group.

To unsubscribe from this group and stop receiving emails from it, send an email to inaturalist...@googlegroups.com.

[Patrick Alexander]

Yes, iNaturalist knows that Arabis drummondii is a synonym of Boechera stricta, but searching for Boechera stricta won't pull observations identified as Arabis drummondii because iNaturalist won't let you identify something as Arabis drummondii. That's an important distinction.

To unsubscribe from this group and stop receiving emails from it, send an email to inaturalist...@googlegroups.com.

To post to this group, send email to inatu...@googlegroups.com.
Visit this group at https://groups.google.com/group/inaturalist.
For more options, visit https://groups.google.com/d/optout.

[Scott Loarie]

correct - you can identify your own observations as Arabis drummondii but if you try to ID other people's observations as Arabis drummondii iNat will redirect that to Boechera stricta (the active taxon)

To unsubscribe from this group and stop receiving emails from it, send an email to inaturalist+unsubscribe@googlegroups.com.

To post to this group, send email to inatu...@googlegroups.com.
Visit this group at https://groups.google.com/group/inaturalist.
For more options, visit https://groups.google.com/d/optout.

[Patrick Alexander]

Hello Scott,

None of the tools you mention allows for "Rhinella cf. marina" as defined above ("Rhinella marina or Rhinella horribilis") to be used meaningfully. There are two sides to this; first, to really be meaningful, a name has to interact with the rest of the taxonomy. Placeholder names don't do that; a placeholder name "Rhinella cf. marina" doesn't mean "Rhinella marina or Rhinella horribilis", it doesn't have any meaning outside of just a series of letters. Identifying an observation as Rhinella and then using a tag of "Rhinella cf. marina" is better but still wrong, because this means in effect that "Rhinella cf. marina" means "any Rhinella", not "Rhinella marina or Rhinella horribilis". Further, supposing there is a way to cobble together the various available parts here into a meaningful taxonomy, it's just clearly going to be an awful kludgy mess.

Second, supposing I want to deviate from the iNaturalist taxonomy -and- interact with the iNaturalist data & community (and if I don't want to do the latter, I don't know why I'd be on iNaturalist in the first place!), it's not just an issue of what taxonomy I want to use on my own data, it's a matter of what taxonomy I want to see on the data of others. So, e.g., I should be able to search for "Rhinella cf. marina" and pull records of both Rhinella marina and Rhinella horribilis. I assume there is a kludge that would have this general effect iNaturalist, but I'm going to bet it's convoluted and not really workable in practice. :-)

As I noted before, iNaturalist does have a taxon with precisely the meaning of my "Rhinella cf. marina"--67129-Rhinella-marina--but you can't really work meaningfully with that name and iNaturalist's data structure apparently does not understand that 67129-Rhinella-marina means "either 517119-Rhinella-horribilis or 553515-Rhinella-marina", even though that clearly is the meaning of the taxon name. So far as I can tell, the only thing I can do with 67129-Rhinella-marina is, if I've identified one of my observations under that name prior to the name being inactivated, and I've opted out of community ID, then I can keep storing that observation under that name.

I think what you're saying here is basically that, yes, people can opt out of the iNaturalist taxonomy in certain (limited and kludgy) ways, but we should really all be working together and using the same taxonomy. What I'm advocating is the third way: working together using parallel and transparently interoperable taxonomies.

Regards,

Patrick

[Patrick Alexander]

I also don't think there'd really be any problem if you wanted to identify a Boechera stricta as a camel provided that your meaning of "camel" is appropriately defined and interpreted in iNaturalist. In my taxonomy, your "camel" would show up as something roughly like "eukaryote". So you should see an ID of "camel" on that observation, and I should see an ID of "eukaryote" on that observation. If the camel ID makes you happy, well, so what? I don't see how the eukaryote ID hurts any. It'd be entirely correct, just unhelpful. Yes, Boechera stricta is a eukaryote. :-)

For a couple of simple examples in poking at some IDs today, being able to call plants Grusonia clavata and Cerocarpus breviflorus would make me happy. Assuming I could upload a taxon table telling iNaturalist how to interpret my use of those names, presumably I could identify things as Grusonia clavata and Cercocarpus breviflorus to my heart's content, and you'd just see my IDs as Corynopuntia clavata and Cercocarpus montanus var. paucidentatus. We could communicate clearly and easily, while each using different names. No problem.

[krancmm]

Added for "Moths"

https://www.inaturalist.org/journal/krancmm/11499-about-the-field-holding-bin-moths

Monica

[Patrick Alexander]

Sorry for the repeat posting here, but another thing occurs to me. Most of my observations (ca. 65,000) are not associated with photos of particular plants, but are associated with pictures of sites. Supposing a way to upload photos via csv (with a field in the csv indicating a picture URL) existed, would the site photos be appropriate for iNaturalist? And would / should there be a way of marking them as site, rather than taxon photos?

[Charlie Hohn]

There's not currently functionality for this but when i do things like this i just ID as one of the plants visible in the photo, and then use tags or something else to mark the site.

[jesse rorabaugh]

For landscape I just post photo spheres to Google. I believe the same works with normal photos. Google Earth is so commonly used for that purpose that it makes little sense for iNaturalist to get in that area.

[Patrick Alexander]

Jesse - 

So far as I can tell, Google Earth is a platform for uploading photos of places. It's not clear to me that it has any worthwhile functionality as a way to share or manage biodiversity observations, whether those biodiversity observations are associated with photos of places or not.

Charlie -

That's a kludge. :-) I could also upload the photo as many times as there are species at the site and identify each photo as one of those species, but that might be worse.

I realize that this particular kind of biodiversity observation data is not really what iNaturalist is intended to work with, though. 

Returning to the subject of taxonomic / annotation functionality, I think the basic message here is that Joseph Lapp and I have similar kinds of functionality we want to make iNaturalist workable for managing biodiversity data, and the suggested solutions amount to creating a parallel taxonomic / annotation database by way of tags & observation fields and whatnot, and kind of duct-taping that alongside iNaturalist's taxonomic / annotation database. I think that's clearly the wrong approach. The solution would be to build a full-featured taxonomic / annotation database into iNaturalist, not to ask particular users to cobble together their own out of some spare parts lying around.

Having played around on iNaturalist a bit more, I think some aspects of it are really well thought-out and implemented. However, the parts that work well seem to be oriented primarily at casual naturalists, not taxonomists, and towards intuitive ease of use and social networking rather than efficient data management, taxonomic precision, or taxonomic flexibility. To me, this makes it great as kind of a biodiversity-oriented facebook but not particularly functional in terms of online biodiversity data storage, sharing, & management. I'm sure iNaturalist's success at the social network aspects has played a major role in getting the project off the ground and generating a large user base. I think getting iNaturalist to be effective as a biodiversity data platform is going to take more work.

[Charlie Hohn]

That right there is the main challenge of this site I think. Making it accessible to most people while also making it work from a scientific standpoint. My gripes mostly have to do with mapping and app fnctionality not taxonomy, but I agree that it's a hard balance. And I don't always agree 100% with what is chosen but I think iNat does a really good job. In fact for what it does, I haven't found any 'professional' tools that work better! The other ones I have tried are much worse. 

[Joseph T Lapp]

Thank you Scott for explaining my options. Unfortunately, the thomisidae are a bit of a mess and there really isn't one cohesive, commonly-accepted worldwide understanding about the relationships among groups. Consensus just isn't possible yet. We basically have a taxonomist free-for-all.

What we do have is just a snapshot of how papers have most recently left things. The moment we put thought into whether the subfamilies are right, we discover problems that require a bit of work to resolve.

That's how things are in the formal naming. In each locality arachnologists have to make some sense of things to be able to sort specimens. That sense often isn't captured in writing anywhere. It's also gradually developed and somewhat distributed. Each locality has specialists in each group, and arachnologists lean on each other for those ID insights that one another have that just can't seem to get conveyed in writing. And when there are multiple specialists in a group, they don't always agree. I'm aware of ongoing taxonomy arguments in even well-studied groups, such as salticids.

Through worldwide contacts, a taxon czar would get a sense of the thinking in each region, but wouldn't often be able to document a consensus taxonomy. The czar would instead be choosing whose thinking to accept. And that doesn't help specialists work on iNat if they happen to go by other thinking.

I think the best iNat can do is gradually generate a community taxonomy of multi-taxa groups, based on field characters rather than genitalia. That's the kind of taxonomy needed on iNat, and it's the kind of taxonomy members are capable of collaboratively producing. BugGuide is a model of this approach. It's just that their site is aging and hard to use and doesn't give us all the niceties and helpful presentations that iNat does.

~joe

[Charlie Hohn]

Joe, the 'field characters' idea is a really interesting one. With plants, genetics is finding a lot of 'cryptic taxa' with literally no visible difference, or at least absolutely minute differences. People want to split these into species sometimes. (I don't understand why the subspecies concept isn't used way more ,especially for things that freely intergrade, but that's a whole other rant). However, broadly, one of the main purposes of taxonomy is to name things. We need to be able to name things in the field, or at least soon after going in the field with reasonable tools (ideally a hand lens, maybe a dissecting scope). That isn't to say cryptic species don't matter, but for applied ecology and for what most people care about, we need a system for identifying things in the field that doesn't involve 'backing to genus' when the genus has 100 species and we know it's one of two. Perhaps even more important, land managers and policymakers need to be able to collect data in a systematic way (plant plots, invertebrate sweeps, bird counts, etc etc etc) and use that data for conservation planning and land management. We can't bring genetic sequencers in the field (yet) and as it is we miss tons of stuff because in most places there is no one season when every species can be identified with certainty. "Backing up to genus" is again not an option especially when that includes a big bag ranging from horrific invasives to common field species to critically endangered species. We need something better. It needs to have some phenological anchor of some sort, and it needs to crosswalk to the 'real' taxonomy. In short, understanding the evolutionary relationships of species is important to understanding ecology, but destroying the ability for land managers to collect field data is not a price worth paying to that end. 

I really think in an ideal world iNat could be a pioneer in developing this new 'parallel taxonomy'. We have the user base, we have the ability for strong crosswalking with the robust database, we have the data, and we have the will. What we need next is a body of people willing to take this on. It would be best if the admins would let us add some database functionality because if we have to rely on fields it may not happen here. It will happen somewhere else.

On a fun scifi note i think if we ever reach other planets with life, we will have to create a form-based parallel taxonomy to track things with similar forms - because evolutionary convergence is a much more powerful force than some think. I actually think while we'd see some highly alien organisms, on an earth-like planet we'd find a lot of life that looks a LOT like earth. Because Earth and presumably other similar planets have had billions of years to 'figure out what works'.  We'll see... maybe.

[Patrick Alexander]

Charlie, I agree with your thoughts here, and that's a large part of the issue I see with the current iNaturalist system. For instance, locally, I want to be able to ID things as "Gutierrezia microcephala or Gutierrezia sarothrae"; those two are easy to tell apart if you have a good view of the flower heads, but for parts of the year you're just out of luck. And there is some important ecologically relevant signal in distinguishing the two, since they tend to occur on different soils. So I wouldn't want that coarser ID to replace the species-level ID, but I think it's doable to have both; if you can ID to species, ID to species; if you can't, it should be possible to specify "it's one of these two" in a way that is still integrated into the taxonomic / annotation database rather than kind of tacked alongside. The other main issue is that people are going to disagree about taxonomy. If I'm IDing Opuntia, I'm going to use the taxa in the Flora of North America / Flora Neomexicana treatments. Other people who certainly know a lot about the genus, probably much more than I, are going to want to split them into smaller taxa, as in the treatment on opuntiads.com. Those folks may well be right and I wouldn't want my coarser IDs to override theirs because that could be losing valuable information, but I think it should be possible for them to ID things according to their understanding of taxonomy and me to ID things according to mine... iNaturalist would just have to have the two systems in parallel and know that when I say "Opuntia engelmanniI", to them it means "Opuntia engelmannii, or Opuntia discata, or Opuntia arizonica, or Opuntia riparia (or whatever exactly the list is, I'm not sure)" and when they say "Opuntia discata", to me that means "Opuntia engelmannii". So long as the translation back and forth can live in the iNaturalist backend, I would just need to specify which system I'm using and all the information is there to do the translation back and forth. I don't know what the situation looks like globally--it's probably a mess--but within U.S. plants there are already several of these taxonomic systems well-enough developed that it would presumably just be a data formatting issue to import them into iNaturalist, provided iNaturalist had the appropriate slots to stick it into the back end. There are also plenty of cases where there's no disagreement about how many taxa there are, but some disagreement about what the right name is. I don't think it helps iNaturalist to try to arbitrate all of those disagreements and decide that one is the right name and must be used. There are already plenty of lists that attempt to do exactly that, and all of them have their own quirks & whatnot. The last thing we need is another list trying to do the same thing, duplicating effort and still giving a result that some users, especially taxonomists but also just folks who learned it under an old name and don't want to be bothered trying to keep track of the changes, are going to find a hindrance to interacting with iNaturalist.

[Charlie Hohn]

I am not a programmer but i feel like that kind of background parallel nomenclature would be a horror to program. I could be totally wrong. But i also feel like it would be more confusing to newbies than how things are now. "This cactus has three names and i have to choose a taxonomy??? huh???"  

What about just upgrading and expanding the tools to track synonomy. No matter what someone won't like the name that is chosen, but as long as we can avoid taxonomic pollution like "Chamaepericlymenum canadense" I think we can make that work.

[Joseph T Lapp]

I actually have a solution to the problem of proliferating taxonomies and have even written it up as a detailed technical specification, as-yet unpublished.

The solution is conceptually simple but radical. My solution imposes taxonomies on the entities of other data sources from the outside, doing so in a way that allows taxonomies to evolve and compete under collaborative development. This allows each data source to impose any taxonomy of its choosing, while allowing outside entities to re-interpret the taxonomies.

I started the company Instar Earth, LLC, for the purpose of realizing this vision. Unfortunately, I was unable to find a way for it to fund itself, and I'm currently off pursuing a more realistic source of income. I'm continuing to work on the taxonomy ecosystem as I find time and hope to eventually hire people to help me pursue it more aggressively.

~joe

--
You received this message because you are subscribed to a topic in the Google Groups "iNaturalist" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/inaturalist/nSXEUKwKvSI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to inaturalist+unsubscribe@googlegroups.com.

[Patrick Alexander]

Hello Joe,

I'd be interested in hearing about your solution in more detail. Here's a more detailed example, using the cactus genera Grusonia & Corynopuntia, of the kind of system I'm envisioning, modified from an email I sent to Scott Loarie a while ago:

Let's suppose we have one table that is just a list of names, each with a specification of what type of taxon it is:

Corynopuntia|genus
Corynopuntia clavata|species
Corynopuntia emoryi|species
Corynopuntia grahamii|species
Corynopuntia schottii|species
Grusonia|genus
Grusonia clavata|species
Grusonia emoryi|species
Grusonia grahamii|species
Grusonia schottii|species

Now let's suppose that we have a second table, indicating how these names are related to each other--the name on the left, the species with which it is a synonym or genus to which it belongs on the right:

Corynopuntia clavata|Grusonia clavata
Corynopuntia emoryi|Grusonia emoryi
Corynopuntia grahamii|Grusonia grahamii
Corynopuntia schottii|Grusonia schottii
Grusonia clavata|Grusonia
Grusonia emoryi|Grusonia
Grusonia grahamii|Grusonia
Grusonia schottii|Grusonia
Corynopuntia|Grusonia

Rewritten in a more human-readable form, that's:

Grusonia
   Grusonia clavata, syn. Corynopuntia clavata
   Grusonia emoryi, syn. Corynopuntia emoryi
   Grusonia grahamii, syn. Corynopuntia grahamii
   Grusonia schottii, syn. Corynopuntia schottii

Let's call that "taxonomy 1". Now let's suppose we have a second table following the same format:

Corynopuntia clavata|Grusonia clavata
Grusonia clavata|Grusonia
Grusonia emoryi|Corynopuntia emoryi
Grusonia grahamii|Corynopuntia grahamii
Grusonia schottii|Corynopuntia grahamii
Corynopuntia schottii|Corynopuntia grahamii
Corynopuntia emoryi|Corynopuntia
Corynopuntia grahamii|Corynopuntia

Rewritten in a more human-readable format, that gives us:

Grusonia
   Grusonia clavata, syn. Corynopuntia clavata
Corynopuntia
   Corynopuntia emoryi, syn. Grusonia emoryi
   Corynopuntia grahamii, syns. Grusonia grahamii, Grusonia schottii, Corynopuntia schottii

Let's call that "taxonomy 2". Relative to taxonomy 1, it has a split at the genus level and a lump at the species level.

If a user of taxonomy 2 provides the following identifications:

Corynopuntia grahamii
Grusonia clavata
Corynopuntia emoryi
Corynopuntia

those map onto taxonomy 1 as follows:

Grusonia grahamii or Grusonia schottii
Grusonia clavata
Grusonia emoryi
Grusonia emoryi or Grusonia grahamii or Grusonia schottii

If a user of taxonomy 1 provides the following identifications:

Grusonia clavata
Grusonia schottii
Grusonia grahamii
Grusonia

those map onto taxonomy 2 as follows:

Grusonia clavata
Corynopuntia grahamii
Corynopuntia grahamii
Grusonia or Corynopuntia

If we want to create a custom taxonomy, we'd just need to create a new synonymy table. Doing this en masse for large numbers of species would be a pain. I would expect that most taxonomists would want to do it for a few focal genera, and be fine leaving the rest of the stock iNaturalist taxonomy as-is. I think I'm probably well out towards the anti-stock-taxonomy end of the spectrum, but even I probably wouldn't want to mess with more than maybe a couple hundred names... and I already have those pretty much marked and defined in my own taxon table, so it'd really be more of a reformatting task than anything else.

If we want to have a one-to-one relationship between identifications in different taxonomic systems--for instance, we need to be able to map a particular observation of Corynopuntia grahamii sensu taxonomy 2 onto Grusonia schottii sensu taxonomy 1, that's going to be difficult and likely only solvable within a database in cases where there is an unambiguous geographic boundary separating the two and a module you can feed that line into and have it sort by location. It'd be great to be able to do it, but in most cases it's not realistically feasible. We're not going to be able to gain precision when we translate from a less precise to a more precise taxonomy. I don't think there's any data-handling requirement for one-to-one relationship between identifications in different taxonomic systems, either. You just need a one-to-one relationship between the identification event and the name, plus a many-to-one relationship between a particular synonymy table and all the identifications using that synonymy table.

I know there are a few issues I'm gliding over here either because I haven't thought about them in any detail or just assume (perhaps naïvely) that they aren't problematic. So, since it sounds like you've thought through this in more detail, I'd be interested in hearing your thoughts.

To unsubscribe from this group and all its topics, send an email to inaturalist...@googlegroups.com.

[Patrick Alexander]

Hello Charlie,

With regard to newbies, I don't think we would want or need them to have any particular interaction with the multiple taxonomic systems unless they choose to poke under that part of the hood. I'm basically imagining that each user starts out assigned the default taxonomy, and has the option to say, "Nope, I want to override that default taxonomy in such and such ways." So if I want to call Rhus trilobata a separate species from Rhus aromatica, I go in and do that in my user-specific settings and I'm happy. If I identify A. Newbie's observation as Rhus trilobata, and the accepted name in the default taxonomy is Rhus aromatica, A. Newbie just sees my identification as "Rhus aromatica" and does not have to know or care one bit that I actually used the name "Rhus trilobata" on my end of the interaction. The taxonomic database just handles that translation job in the background.

Regards,

Patrick

[Charlie Hohn]

as long as the range maps still work :)

[Joseph T Lapp]

Try hitting me up next week. I'm too far behind my schedule right now to chat right now.

To unsubscribe from this group and all its topics, send an email to inaturalist+unsubscribe@googlegroups.com.

[Patrick Alexander]

How about now? :-) It's been more than a week, I guess.

This week's rant along the same lines as my comments above follows:

The more I use iNaturalist, the more I realize I really like the concept and think it could be incredibly useful for a wide range of purposes. For instance, one of the fundamental problems in ecological research is this: ecologists do not collect specimens. Taxonomists have been telling them for years, "Hey, people down the road are going to need some documentation of what taxa you were actually working with." No dice. There are some exceptions, but as a rule ecologists simply will not collect specimens. Something like iNaturalist could really fill that void. It's not perfect, but it's so much more user-friendly and streamlined than dragging a plant press around that we might actually get people to do it. Now we're not talking about citizen science, we're talking about just plain science science. There's a need here, and iNaturalist looks like, basically, the right tool for it. There's really no shortage of cases in scientific research where something more than just "so and so said he saw..." but not as time-consuming and logistically demanding as a big pile of specimens would be valuable.

But, the taxonomy has to work. If it's going to work for science, it needs to be able to accommodate differing opinions. We can't just tie researchers to the whims of the iNat taxonomic database. No one's created the mythical one list of right names and iNaturalist isn't going to do it, either. So... don't try. We need to work with disagreement, not try to nail it down.

I want to figure out how to move forward on this.

[tony rebelo]

But should we be accommodating taxonomies that have not been published?  I understand the issues of alternative published schemas, but unpublished ones should not be entertained.  With time hopefully alternative schemes will be resolved (but perhaps not always), but unless a taxonomy has been scientifically published it should not be "published" on websites.

I do agree with you about iNat being wrong to publish only the accepted name.   So in the Cape we have Erica mammosa into which a taxonomist has sunk Erica gilva.  But gilva is quite a distinct taxon.   I dont mind it being summarized and displayed as a synonym of mammosa, but I do object to my identifications of it as Erica gilva being changed by iNat to Erica mammosa.  I am happy for those who disagree with me to ID the observation as Erica mammosa, but I want those who agree with me that it is distinct to be able to do so, and not to be forced to ID it as Erica mammosa.  I would also like to be able to search for Erica gilva and get out those observations identified as Erica gilva without it being included in Erica mammosa.

So two issues here.  One is being forced to use the current name, when the synonym might be a valid taxon.   And the second is not being able to get a summary for the synonym - only for its current name.

After all, in a few years time another taxonomist might revive the synonym as a species, but meantime all the identification data has been corrupted to just the ex current name.

[cassi saari]

Tony, in your account settings, uncheck this box:
 
Taxonomy Settings
 Automatically update my content for taxon changes
When taxa are merged or renamed on iNat, your observations, listed taxa, identifications, etc. will be automatically updated to the new taxa if the change is unambiguous. If you opt out or the change is ambiguous (e.g. a split), you will receive an update about the change linking to a tool you can use to manually update your content if you choose.

[Patrick Alexander]

Hello Tony,

Regarding unpublished names--I think they should be clearly marked as such, but so long as that is the case I don't see any issue with including them in iNaturalist and some definite advantages to allowing it. For researchers who are in the process of doing taxonomic work, it's ordinary practice and quite helpful to organize and look at physical specimens grouped by provisional names as the taxonomy is refined. I don't see any reason not to do that for digital observations as well. The main difference is that physical specimens can only be filed one way, while digital observations can be simultaneously filed many ways. So, one person going through and sorting things into provisional taxa need not interfere with others working with the same observations using only the published names.

Regards,

Patrick

[Charlie Hohn]

My understanding is that adding unpublished names is counter to the current iNat taxonomy policy, and they should instead be tracked via fields or some other method. I don't feel terribly strongly about that particular issue either way, but there is the potential for clutter of huge numbers of unofficial names if it isn't laid out really well, and i'm not sure how unofficial taxa would work without causing problems.

[Patrick Alexander]

Yeah, it'd add some complexities to think through... I think being able to have unpublished names in there would add some useful functionality, but I don't see it as a real necessity. Being able to handle different taxonomies with published names, though, I think is necessary.

[Patrick Alexander]

So, maybe something to think about more if/when everything else gets sorted out nicely...

[Scott Loarie]

Hi Patrick,

Appreciate your interest in coming up with ways for systems to con-currently manage multiple different taxonomies. Definitely interesting ideas.

But in the mid-term, iNaturalist has always had single global taxonomy and there are no plans to change this in the midterm (ie ~3 year). First, its unclear whether we'd want to change our current 'globalist' vision of a shared taxonomy. And even if we did, we don't have the staff or resources to take on the complexity of building something like you propose in the midterm.

That said, we're very, very interested in short-term activities to improve the iNaturalist global taxonomy thats better curated, has more buy in/is more useful to more people, and is more compatible with other efforts out there. We're in the final stages of laying out some broad brushstrokes to kickoff a community driven process to work towards this in the next week or so an will appreciate your feedback / contribution towards that process.

Best,

Scott

--
You received this message because you are subscribed to the Google Groups "iNaturalist" group.
To unsubscribe from this group and stop receiving emails from it, send an email to inaturalist+unsubscribe@googlegroups.com.

To post to this group, send email to inatu...@googlegroups.com.
Visit this group at https://groups.google.com/group/inaturalist.
For more options, visit https://groups.google.com/d/optout.

--

--------------------------------------------------
Scott R. Loarie, Ph.D.
Co-director, iNaturalist.org
California Academy of Sciences
55 Music Concourse Dr
San Francisco, CA 94118
--------------------------------------------------

[tony rebelo]

UNPUBLISHED NAMES:

A lot of taxonomists are paranoid about unpublished names being "published" before they are properly described in the published literature.

There is the complication that if they are seen as publically used then they might become unavailable see  https://en.wikipedia.org/wiki/Unavailable_name 

Unavailable or rejected names include those not validly published - and if someone decides that this is published, or if someone uses the name in a another publication based on this  - then these become nomina nuda or excluded or rejected names (depending on the code - zoo, bot or bacteria - applicable).

[Patrick Alexander]

A concern about accidentally publishing names makes sense, but it's just a wrinkle to be sure is addressed, not a show-stopper. It's not a problem so long as the names are clearly marked as what they are--informal names that are not intended to be code-compliant, formal names. For instance, I don't suppose anyone has worried that usage of the name "sticky snakeweed" on iNaturalist constitutes publication of a nomen nudum under ICNafp, because it's obviously not intended to be an ICNafp name. Although I'm much less familiar with ICZN, I think the same applies. BugGuide uses informal names, clearly marked as such, e.g.:

https://bugguide.net/node/view/957261

https://bugguide.net/node/view/1092516/tree

In a plant context, I think it's adequately done with some simple formatting, e.g.: Arabidopsis thaliana vs. Arabidopsis 'incognita'.

Judging from Scott Loarie's post above, I suppose this is somewhere on the "not even thinking about it" list, but I don't think there's any reason unpublished names can't be used.

[tony rebelo]

It is not what iNaturalists do, but what other people may do.  Take a picture from iNat and publish it in a magazine with the name and edit out the formatting, and it is a nomen nudum.  Even if the original author has an MS in press, the name becomes illegal.  

It is not a show-stopper - serious taxonomists do not allow their names out until they are published.  (Although I have encountered a few irate authors when a taxonomist decided not to use a "manuscript" name and published another name instead).

[Charlie Hohn]

sounds like yet another problem with how taxonomy is dealt with, rather than an iNat problem

[Patrick Alexander]

Hello Scott,

I'm curious what near-term ideas you have in mind, but I have to admit I think the "list of accepted names" windmill has been sufficiently tilted at.

It only really makes sense for iNaturalist to create and curate its own list of accepted names if we think the problem is a shortage of lists of accepted names. So far as I can tell, we have the opposite problem. There are already too many competing lists of accepted names out there. I don't see what any of us have to gain from adding another to the pile. 

https://xkcd.com/927/

Regards,

Patrick

To unsubscribe from this group and stop receiving emails from it, send an email to inaturalist...@googlegroups.com.

To post to this group, send email to inatu...@googlegroups.com.
Visit this group at https://groups.google.com/group/inaturalist.
For more options, visit https://groups.google.com/d/optout.

--

[tony rebelo]

That depends. For some regions iNat has good species lists. But for instance we added nearly 10 000 current plant species names last week for southern Africa, and many more synonyms.  

However, for individuals to start adding their own lists?  I agree - stay with a few global lists, and add regional lists when these are inadequate.  

[Patrick Alexander]

Hello Tony,

To be clear, I'm 100% in favor of lists of names, the more the better, including from individuals, but we need to have data handling that can manage those lists intelligently, and right now we don't.

I don't really see the point in iNaturalist trying to create "the" list of accepted names, though. Just for plants in the U.S., we've got at least three of those online at the national level... and all of the published floras, perhaps 100-200 for states and other regions in the U.S., includes its own list of accepted names. Each of those is intended to be the one true list of accepted names, and of course none of them are. It's hard for me to see the point in iNaturalist having a go at it. We don't need a new competing standard, we already have too many competing standards. We need a good way of translating among competing standards.

To work with any one of these taxonomic resources efficiently, you have to create a mental model of the taxonomy and remember things like, "Flora Neomexicana III calls this plant Talinum aurantiacum but USDA PLANTS and iNaturalist call it Phemeranthus aurantiacus". Keeping things like that in your head is really a pointless use of limited mental resources. Basically, what I'm suggesting is that the database should know, "Flora Neomexicana III calls this plant Talinum aurantiacum but USDA PLANTS and iNaturalist call it Phemeranthus aurantiacus", so I don't have to.

Even less useful, of course, is sticking the following into my head: "Flora Neomexicana III does not provide a common name for Talinum aurantiacum, but USDA PLANTS calls it orange fameflower and iNaturalist calls it orange flameflower". If handling alternate taxonomies isn't within the realm of possibility in the nearish future, perhaps iNaturalist could at least be taxonomist-friendly in using scientific names (e.g., perhaps a button in account setting somewhere, "only show scientific names"), rather than making us to try to keep track of both the iNaturalist taxonomy and the iNaturalist common names. It's, like, two new competing standards for the price of one.

Regards,
Patrick

[cassi saari]

"Basically, what I'm suggesting is that the database should know, "Flora Neomexicana III calls this plant Talinum aurantiacum but USDA PLANTS and iNaturalist call it Phemeranthus aurantiacus", so I don't have to."

"perhaps iNaturalist could at least be taxonomist-friendly in using scientific names (e.g., perhaps a button in account setting somewhere, "only show scientific names"), rather than making us to try to keep track of both the iNaturalist taxonomy and the iNaturalist common names."

cassi

To unsubscribe from this group and all its topics, send an email to inaturalist+unsubscribe@googlegroups.com.

[cassi saari]

I realize that is just when entering the data... and it would be nice to be able to set your "preferred taxonomy" as an account setting somewhere to be able to focus mental resources on more exciting things :) 

I forgot to mention that the common names feature is a checkbox in your account settings. Not sure how to provide a link since the link to account settings seems to be specific to my user ID. I think if you click this it will bring you to yours anyways: https://www.inaturalist.org/people/8882/edit 

cassi

[Patrick Alexander]

Hello Cassi,

Well, now I feel silly for missing that checkbox. Thanks for pointing it out, that's a dramatic improvement!

Is this new? I could swear I asked whether there was such a feature earlier and got a "nope, sorry".

And, yup, I'm aware of the synonymy in iNaturalist. It is nice for entry, but not really ideal.

Regards,
Patrick

[bouteloua]

It is new -- I was the one who said nope! 

The various threads asking for that feature should probably be updated.

c

cassi

cassi

<a href="https://maps.google.com/?q=55+Music+Concourse+Dr+San+Francisco,+CA+94118&entry=gmail&source=g" target="_blank" rel="nofollow" onmousedown="this.href='https://maps.google.com/?q\x3d55+Music+Concourse+Dr+San+Francisco,+CA+9

[Patrick Alexander]

OK, so I think I'm gradually circling around back to the suggestions that were made near the beginning of this thread... which are, in effect, ways to use observation fields and the like to create parallel taxonomic functionality that does not interact with iNaturalist's real taxonomic database. We need parallel taxonomy but it's not going to happen in the iNaturalist taxonomy database, so although this is clearly not the right way to do it I guess it's what we've got.

This leads me to some logistical questions. I'm sure these are answered somewhere else on iNaturalist, but I'm not sure where, so my apologies for asking potentially silly questions:

Is there a limit to the number of allowed values in the pipe-separated list?

Is there a way to store a table in iNaturalist in a way that would make it fairly permanently accessible and associated with an observation field? My alternative thought is to just put the table online elsewhere and provide a URL in the description field.

Do observation fields come with a changelog functionality analogous to that provided for taxon IDs? I'm not necessarily concerned about whether I can interact with such a functionality at the moment, the issue is basically, if I annotate a specimen via an observation field, will that annotation remain stored in and theoretically accessible in iNaturalist even if overwritten by subsequent modifications.

Is there a way to lock an observation field or limit its editability in a way that would make it more suitable as a stable data container? I don't expect anyone would intentionally just mess with things but, you know, if I'm relying on something to store real data it'd be nice to have some assurance someone can't just accidentally bump into it and knock it over.

cassi

cassi

<a href="<a href="https://maps.google.

[Patrick Alexander]

Ooh, next question: Is there a way to do a bulk update of observation field values? E.g., for a given observation field, replace all values of "GLUNW" with "ANUNW".

cassi

cassi

Visit this group at <a href="https://groups.google.com/group/inatural

[bouteloua]

I think an admin might need to answer some of those questions, but here's a few:

Based on trying it out, I do know that the field can fit at least 8,000 entries (26,000 characters).

I think right now, any curator can edit an observation field.

You might be able to edit a bunch of fields at once using the batch edit feature on your observations page> Batch Edit. (though I'm not very familiar with that tool and have never used it for that purpose)

There was some similar discussion here: https://www.inaturalist.org/journal/charlie/11436-holding-bin-plant-field-index

[Patrick Alexander]

Greetings, Joe,

I'm still very interested in hearing more about your approach to taxonomy.

Regards,

Patrick

[Joseph T Lapp]

On Tue, May 8, 2018 at 5:42 PM, Patrick Alexander <paal...@polyploid.net> wrote:

I'm still very interested in hearing more about your approach to taxonomy.

​Sorry, this thread overwhelmed me and i stopped following. I'm trying to decide the best way to share the vision. I'm thinking of starting a blog or just creating a website that describes the approach. There are many pieces. The idea would be to motivate people to work on the pieces in open source.

~joe​

[jdmore]

Patrick, I'm glad you bumped this thread.  You and I seem to have the exact same vision of how alternate taxonomies could be implemented in the back end of iNaturalist, increasing the scientific utility of the platform without disrupting the non-taxonomist user base.  I tried to describe that vision in your later thread "It's about time to figure out taxonomy" (https://groups.google.com/forum/#!topic/inaturalist/tibJbs4oWrw), but you did a great job of describing it more explicitly here with your examples.  As long as iNaturalist uses back-end technology that includes efficient table indexing and look-up (how could it not?), I would think any performance hits would be small, if any.  I'm sure someone will correct me if I'm wrong about that...

The bigger issue is probably the human effort needed to implement.  But to me that should be almost entirely community-driven.  If one user feels strongly enough about a particular taxonomic scheme to create and maintain it, then "all" iNaturalist needs to do is provide the tools to allow that, and to make it interoperable with other existing schemes (via user-specified mapping).  The scope of a user's scheme could be as limited or large as they wished to expend effort to create, and the default "standard" iNaturalist taxonomies would still be there in the background for things outside of that scope.

Other than the programming, one necessary up-front effort might be crosswalking the existing "standard" schemes in iNaturalist where they overlap, to the extent that may not have been done already.  Hopefully community help could be recruited for that as well.

Jim Morefield (jdmore)

[Patrick Alexander]

Hello Joe,

No worries. I am very interested in pursuing this further and contributing to more structured discussion or pursuing specific tasks, but the limitation I have personally is that I have expertise in taxonomy and have spent a lot of time figuring out how to interpret and work with tables conceptually and specifically in the context of excel manipulations... but if the need is coding... I would like to be there but I can't even see there from here. I feel like I'd need several years to go back to school and get a computer science degree in order to make any kind of meaningful contribution to an open source project. I can cobble together a really appalling relational database in excel, but I can't even get mysql to install--and I spent a few hours yesterday trying. If I kept going, I'd probably have a complete list of the possible error messages, but no idea what to do about any of them.

Regards,
Patrick

[Patrick Alexander]

Hello Jim,

I'm glad the discussion here is useful! I guess at this point I'm just not sure how to move forward. As my response to Joe probably indicates, I'm on board when it comes to developing or working with taxonomic schemes, but I think there's a significant coding workload that I don't feel qualified to engage in and am not sure if there's sufficient interest or time among the core iNaturalist developers to get things to a point where I would be able to contribute effectively.

Regards,
Patrick

[Nicola NEWBERY]

Can I please unsubscibe from this thread discussing the nitty gritty of developing and running the iNaturalist programme?

 

Many thanks

 

Nicola

Hong Kong

--

You received this message because you are subscribed to the Google Groups "iNaturalist" group.

To unsubscribe from this group and stop receiving emails from it, send an email to inaturalist...@googlegroups.com.

[Patrick Alexander]

I have faith in your abilities. :-)

[Scott Loarie]

This Google Group is specifically for the purpose of discussing the
iNaturalist platform. I don't think you can unsubscribe from this
thread without unsubscribing from the whole group

But that said, I can say from the staff side of iNat that our thinking
on our capacity to take on managing multiple different taxonomies
hasn't evolved from my comments on this thread on 11/17: "Definitely

interesting ideas. But in the mid-term, iNaturalist has always had
single global taxonomy and there are no plans to change this in the
midterm (ie ~3 year)."

So since such a system isn't relevant to iNat in the short (~3year)
term, could I suggest that conversations about designing such a system
be taken off this group? But if a clear proposal is hashed out (like
the website that Joe envisioned) I'm sure folks here would be very
eager for you to share a link to it back on this Google Group so we
can read about it and think about it in the context of iNat
development down the road.

Sound good?

Scott

--
--------------------------------------------------
Scott R. Loarie, Ph.D.
Co-director, iNaturalist.org
California Academy of Sciences

[jdmore]

I've been picking up vibes that taxonomy may be getting higher priority for attention soon from iNaturalist, and that input from taxonomists will likely be welcome and helpful.  So stay tuned.  I don't imagine either of us will be getting asked to do any coding. ;-)

--Jim

[jdmore]

Sorry, never mind my last post, which crossed with Scott's.  What he said.  --Jim

[Patrick Alexander]

Augh. This is not helpful. Do I hope for progress within the context of iNaturalist, or do I view iNaturalist as a dead end and hope for a replacement platform that does taxonomy?

[jdmore]

Much as I share this particular disappointment, iNaturalist remains hugely useful to me for all the other great things it does and will do.  Let's keep helping to make it greater, and see what priorities emerge after a longer period of rapid growth.  I can do personal taxonomy on exported data with my own reference tables, if that is the best option available.  Much better that than nothing.

--Jim

[Patrick Alexander]

I have mixed feelings. I appreciate iNaturalist immensely for the things it does well. Unless taxonomy is one of those things I can't help but feel it is, ultimately, a dead end. I'll stay here because there's nowhere else to go, sure, but where do we go from here? Do we expect iNaturalist to solve the problem eventually? Is there at least a good path towards complete data export so that we can move to iNaturalist's successor if iNaturalist -doesn't- solve the problem? Or do we just expect the nth iteration of "here's a new platform, you'll have to upload your observations one by one by one by one and oh god how many of these things do you have?"

[Patrick Alexander]

OK, I'll go be a pessimist outside for the next three weeks or so. And I'll contibute observations to iNaturalist, and I'll kind of feel bad about it. Whatever. :-)

Seriously, Scott, can we at least have a complete--media included--export option? I'm OK with iNaturalist being a dead end if I can at least get my data out. The taxonomy issue is going to be solved sooner or later, and if it isn't iNaturalist that does it, I want to have some assurance that I can move my data to the platform that does.

[Nicola NEWBERY]

OK, thanks. I'm just an ordinary person who took part in the HK City Challenge (a first for me - it was a wonderful 4-day Treasure Hunt through one of Hong Kong's wilderness areas).

I post the occasional photo of something unusual onto the i-Naturalist site. I'm not sure how I ended up in this group, I must have asked a question during the City Challenge. As a non-specialist, I would like to unsubscribe from this group, while still receiving emails from the HK i-Naturalist team about the HK-based competition results, and posts of photos taken in Hong Kong.

How do I unsubscribe? I've tried clicking on one of the links, but am still receiving posts that are way over my head that I cannot contribute to.

Warm regards

Nicola
Hong Kong

[jdmore]

I'll take a shot at answering your question Nicola, but no guarantees I know what I am talking about.  This is based on being logged in to the Google Groups web interface on a PC -- it may not be the same on a phone etc.

Short of leaving the group completely, go to the top of this thread, and look in the upper left where it shows something like "89 posts by 13 authors".  There should be a down arrow right next to that.  Drop down that arrow, and look for an option that says, "Cancel my email updates."  If you find that option, then select it, and hopefully you won't receive further updates from this thread.  If that doesn't work, then I'm out of my depth.

--------------------------...

[Nicola NEWBERY]

Many thanks, will give this a go!