BUG IN BROWSER: Browser index not correctly updating: How can the same observation be the icon observation** for both a family and a genus at the same time?
It appears that when the ID was updated from Pyralinae to Bostra the iconic list was not updated. This needs to be fixed.
Alternatively, what is happening is that iSpot is selecting a child to represent the ID Pyralinae, instead of one of the observations actually identified as Pyralinae - which leads us to another 2 bugs:
1 There is no way to find observations identified as Pyralinae - any attempt to find these brings up all the children. Which means that an expert helping out with identifications has to wade through all the lower ranking IDs to find those few observations only identified to the target rank.
In other words iSpot tells us that the ID to subfamily is the biggest category in the family, but then adds everything if one tries to look at this taxon.
Thus (from our data dump: it would take days to work this out on iSpot, this is approximate as it is based on the current AVAILABLE iSpot dictionary, not the Sept 2014 version which is used on iSpot):
- Pyralinae has 26 IDs, of which 18 are Likely IDs (i.e. 18 instances) - this is what I would expect to get if I clicked on the thumbnail! (and do all the extra unnecessary steps to get the observation list)
- Pyralinae has children: 0 to tribe, 13 to genus and 47 to species - this is what I get in addition to the above if I click on the thumbnail (and do all the extra unnecessary steps to get the observation list)
Thus to find the 18 identifications to subfamily one has to manually go through 78 observations. Our experts do not have time for such an inefficient system
2 The iconic observation for the Pyrolinae should be the following which has 2.9897EE:
(it is iconic for the species Pyralis farinalis with 7 observations - see the 8th observation in the browser) But why is the observation above the iconic species and not this? Clearly a bug somewhere in the updating process.
Most likely the bug is that the former was elected as iconic for the subfamily when the subfamily ID was made, but when the ID was updated to genus, the iconic taxon was not updated. It seems therefore that the iconic observation for any taxon depends (to some degree) on it having been identified as that taxon in the past. In which case there are one or two bugs:
- the iconic observation is not removed if the ID is changed (or at least changed to a child) - and no reassessment is done to a relevant index of iconic observations.
- the iconic observation is not assessed properly: there is a bug in the evaluation process that does not look at all children only at past identifications.
** iconic observation:
the iconic observation is supposed to be the observation for that taxon that has the most votes (not number of votes, but reputation points = sum of reputation of all the voters). These two observations have 1.5EE (or 1500 votes, where an expert = 1000 votes ; EE = Expert Equivalents) and 2.9897EE (almost 3 experts), respectively.