The OpenScience Laboratory The Open University

iSpot Forum

Order of LikelyID and dictionaries

In the past (before Sept 2014) the dictionary updates were not easy but they were trivial. All that happened is that new species were added.
There were no instructions. So we found out the hard way.

  • Dont change a name. If the old dictionary had Genus speciesA and the name changed, dont change the name, because iSpot will show the old name as the ID and then inexplcably link to the new name. The correct thing to do is retain the old name but make it a synonym of the new name.
  • Do not use an old number for a new name. Everything will go horribly wrong.
  • Do not decide that the beetle taxonomy borrowed from CoL is terrible and delete them all and start again with new numbers. All the old IDs will become lost and disconnected from the dictionary and then have to be reidentified as the same name to link them to the new numbers.

But why is it trivial?
Because with each dictionary update, proper curation will be to change the IDs from the old names (synonyms) to the new names. It may be nifty to merely use a lookup to display Protea mellifera as Protea repens, but users - especially non-biologists will get confused. An intelligent site will display the new ID with an explanation.
But on iSpot with “Agreements” this is an issue. A workaround is to - every time a dictionary update is done - to Curatorially add the new name as a Revised ID, carrying over each Agreeer, so that the old ID and the new ID have the same number of votes. Because of the “changes” (if they ever get our unread changes working) all agree-ers will be notified of the change and can then decide to go with the new name or the old. And any users who dont care, have left or have died, will not mean that the old name will thus forever the the Likely ID on iSpot.
Similarly, species that are subdivided need to be re-evaluated, and agree-ers should be informed that the observations need to be re-evaluated. This is more tricky as iSpot wont know which of the new names (or the old) to reassign the observation to. But a curatorial comment will alert everyone, and a list of observations to be reassessed can be posted. Yes, disinterested and lost users will be a drag, but hopefully enough users can be found to update the names.

Why is it missing? Prior to Sept 2014 iSpot had a dedicated programmer who handled these things. Now the IT department managers iSpot and none of them even know how the dictionary works, let alone how to update it.

Our problems now are exactly the same as in 2014. Too few programmers, not enough money, and time and money ran out before the programming was completed. So dictionary updates were simply never got to. Along with curation. And about 50 significant bugs. And everything had to wait for 2 months because of the Xmas recess when the IT department shut down.

This time it is changes, forums and curation that have lucked out. And it does not appear that many of the over 500 bugs are being got to neither. And everything has to wait for ? months because of the summer recess when the IT department shut down.

What iSpot needs is a proper Admin Team. That is iSpot’s problem. Almost no one on the Admin team cares about iSpot. Those who do care are ignored. No one is accountable. What is needed is a Steering Committee of iSpotters to oversee iSpot!!!

Are you prepared to sit on a Steering Committee for iSpot?

I just think that ispot is seriously lacking if it does not have a specification of how to cope with dictionary changes. As much as can be done automatically should be along with a clear protocol to fix the others. Maybe you have to mothball the not-likely ids and fix the likely and future ones. I’m not a professional botanist so I don’t know the minutiae of dictionary updates but I was once a professional programmer so I have some idea what could be done. But isn’t.

iSpot has an Admin team?
Having experienced a similar apparent lack of interest, or progress, in other areas of my life in the past, it is hard not opine that someone would quite like the site to fail. Perhaps it’s become too much of a burden to adminster, but no-one has the nerve to openly say “let’s shut it down”?
(Just because I’m paranoid, that doesn’t mean they’re not out to get me…)

Admin team in IT. Yes, they probably dont want it! But apparently they have full say as to what happens - the OU iSpot team sounds like they request bug fixes and the IT team vets them.

No, the specs were quite simple, I can reel most of them off the top of my head - having spent over a month twice a year since 2012 updating the dictionary (although the last time iSpot used it was in Sept 2014).
The were:

  • iSpot_SANBI_number
  • Name (= taxon)
  • Rank (=taxonomic rank: which is why I know that “group” in the dictionary and browser pages is just lazy programming.)
  • iSpot_Group (have 16 in our database, but collapse them into invertebrates and plants, during export)
  • Type (= Scientific or Vernacular (iSpot calls it common, and at one stage English Name, but we objected with 11 official languages)
  • Status (= Recommended or Synonym - we dont have any recommended Vernacular names which causes a major issue with the Quiz, because despite having our dictionary for 2 years on iSpot, the developers of the quiz did not know that we did not have recommended names and so southern Africa did not have a quiz for over a year after the other communities)
  • Parent_iSpot_SANBI_number (the parent taxon of the Name - e.g. a genus for a species, or a tribe or family for a genus, and for common names the taxon for that name (e.g. Thistle for Sonchus or Common Sugarbush for Protea repens).

and then there were some fields that did not make sense. To my mind they were totally redundant. They were

  • Recommended Name
  • Recommended Rank
  • Recommended iSpot_SANBI_number
  • Recommended Parent_iSpot_SANBI_number
    (I just generated these from my iSpot dictionary database during export - for status = R they were the same, for status = S they were the parent)

And then at SANBI we insisted on the following being added:

  • Sensitive Taxa (this is used to determine which taxa may not have their localities displayed in detail)
  • Language (the Language of the Vernacular name: this was never incorporated into iSpot - so if the name was English, Afrikans, Sotho, Tsonga, Xhosa or Zulu - or any other language, is not specified in iSpot).

But there is no manual as to how the dictionary is used, and what the constraints on the fields are.

It seems to me that the following fields would be useful (yes, they can be constructed real time, but why - they are constant text fields):.

  • higher taxonomy (i.e. the taxonomic list; e.g. for Recurvirostra avosetta = Animalia / Chordata / Vertebrata / Tetrapoda / Amniota / Sauropsida / Diapsida / Archosauromorpha / Archosauria / Aves / Charadriiformes / Recurvirostridae / Recurvirostra)
  • the full taxonomy (i.e. the taxonomic list; e.g. for Recurvirostra avosetta = Animalia / Phylum = Chordata / Subphylum = Vertebrata / Clade = Tetrapoda / Clade = Amniota / Clade = Sauropsida / Clade = Diapsida / Clade = Archosauromorpha / Clade = Archosauria / Class = Aves / Order = Charadriiformes / Family = Recurvirostridae / Genus = Recurvirostra)
  • ID box display (e.g. following a search of Name, what to show - e.g. on finding “pro mell” display “Protea mellifera - synonym of Protea repens”)
  • ID box save (i.e. what to store in the ID box if a name is selected - i.e. the Recommended Name for a Scientific Synonym, or the same name for Scientific-Recommended name).

What would be useful is a manual of how the dictionary is used and what the different fields are used for and any limitations of the size and type of data.

Thanks for the details of the dictionary. I would agree with your suggested additions. And that a manual would be good. It might also be helpful if there were instructions for the programmers on how to incorporate a new dictionary.

Thats the one - although there are now c 10 known sites for it in the county

By way of update - I have now put my Norfolk comfrey down as ‘Indet Comfrey’ with some explanatory text, so at least now anyone searching for comfreys can find the thing. Not a terribly satisfactory solution though, especially for these newly identified taxa or hybrids when we want as many people as possible to know what they look like in order to get a better handle on distribution.

Please complain about the out of date dictionary …

I am biding time until other more pressing things are ‘fixed’ - but then yes, I will.

Hell will freeze over …

EN NOU:: Dictionary page not recording pages.

Just got this: Askidiosperma chartaceum !!!

But look in the dictionary page:

Note its poisition 1 in the carousel.
But note Askidiosperma chartaceum = 0 Null, Non, Empty, Zit, Zull, Zero, Nothing, Nada!!!

It is just a comedy of bugs! If only it were funny! And these programmers are happy to show their faces in public? I would be too ashamed …

BUT WAIT IT GETS BETTER: There it is: So it is there after all!

But it is also missing on the SURFER:
Sorry “Browser”: it is not there - missing in action!
(PS: excuse the beetles: did not know at the time of the Sept 2014 update that Hydrophilus was a hemihomonym and the beetles got coded as restios having the same genus name).

Likely ID still generating corrupt data:

knowledgeable trumped by a five star upstart:

When is the dictionary and the ID bugs and the Likely ID bugs going to be fixed?

No longer the case as someone has agreed with you (makes a change!) But it appears to be a Bad Code Error.
Despite this (which popped in)

I give you this
TIRED of Waiting?
Copy from the address bar and paste into a new Browser page - almost instant result

And see the blue?
This is the Chrome Extension Button Clean My Chome 1.0.1 If you have it, like I did, then it will cause trouble.

Most queries of Chrome for this maintain that it is malware …

I suspect you are right - thanks…

another Likely ID instance of a bug. Expert trumped by a two badger.
Reputation of 1000 points is less than reputation of 5 points!!!
Tell me that this is not a bug!

PS: with track these are getting harder to get to you before someone agrees or removes their agreements.

another version of the Likely ID and badging bug?

the observation stayed a plant (perhaps because the user does not have enough reputation for a likely ID …

ISpot must know that the observatoin is a plant, and that therefore this ID must be a plant too. Making it a NOT PLANT is not acceptable

If I agree, then my plant badge does show, so why does Raquel’s plant badge not also show?

?? cos the name is not in the dictionary