Synonym not showing, marked Redundant=YES in warehouse

[Sam-Amy]

Sphagnum denticulatum should be a synonym of Sphagnum auriculatum, but the synonym is not showing on iRecord either in data antry forms or explore pages (the only option given is a different taxa, Sphagnum denticulatum s.l.). Although Sphagnum auriculatum is available on the website forms (and via the Explore pages), neither this nor the synonym are available on the app (I have listed this as a separate issue here, though the two may be related?).

They are listed correctly in the UKSI , but in the Indicia Warehouse, although S. denticulatum is listed as a synonym of S. auriculatum, it is also marked Redundant = YES (as is one other synonym, S. auriculatum var. auriculatum) despite not being so in the UKSI. I think this is an error, because in the UKSI 'redundant' is usually applied to whole organisms (i.e. preferred name and all synonyms).

[kazlauskis]

/projects/irecord/taxa/taxa_list_for_app.xml app report doesn't return it, so maybe one of the web/indicia devs can have a look into theis.

[johnvanbreda]

This taxon was imported from UKSI with the allow_data_entry flag set to true, but it was changed to false on 01/06/2023. I can't see anything in the new incremental updates that would have caused this.

@burkmarr do you recall why this flag was changed? It's got your ID in the updated_by_id on the taxa_taxon_lists record (ID 113288).

[burkmarr]

On June 1st I updated a bunch of taxa, setting preferred = FALSE, allow_data_entry = FALSE where preferred = TRUE and search_code != external_key as we discussed in this issue: https://github.com/BiologicalRecordsCentre/iRecord/issues/1476. So I think this will have happened then.

[johnvanbreda]

Thanks @burkmarr - you are correct.

We could easily write a script which resets the allow_data_entry flag for any taxa that were updated by the action on the 1st June, by comparing with the data imported from UKSI in April. This query returns the list of IDs that will be changed:

select cttl.id
from cache_taxa_Taxon_lists cttl
join taxa_taxon_lists ttl on ttl.id=cttl.id
join iss_1476_affected_ttl i on i.id=cttl.id
join uksi.prepared_taxa_taxon_lists p on p.id=i.id
where p.allow_data_entry<>cttl.allow_data_entry
and ttl.updated_on='2023-06-01 14:26:01.947163'

However, in #1476 the request was that Nephus redtenbacheri (TVK NBNSYS0000008306) should be marked as not for data entry but if we run the proposed script, it will actually undo that requested change. @robin-hutchinson are you able explain why this particular synonym should have been marked as not for data entry? There are lots of synonyms that have the same set of flags in UKSI which we do allow data entry so I wonder if it was correct to mark these names as not for data entry at all?

[Sam-Amy]

Robin described that "Nephus redtenbacheri appears in the UKSI twice, but with different TVKs and organism keys as one of the names is a junior synonym of Nephus limonii/redtenbacheri agg.: https://uksi-sandbox.nhm.ac.uk/taxonbrowser.php?txtSearch=Nephus+redtenbacheri".

Should the Nephus redtenbacheri under the aggregate (NBNSYS0000008306) be deprecated in the UKSI? It actually has the same authority as the other one, and presumably shouldn't be a synonym for the aggregate at all?

[kitenetter]

My understanding of the Nephus redtenbacheri issue is that this is a valid species that has always occurred in the UK, but with the recent separation of Nephus limonii as a full species (rather than a form of redtenbacheri) many records now need to be moved to Nephus limonii/redtenbacheri agg., hence the UKSI pointing the old version of Nephus redtenbacheri to the new aggregate, and then setting up a new version of Nephus redtenbacheri for use with any fully confirmed segregate identifications.

We'd need to check with Chris Raper but I don't think it is usual practice for the old version of a species in these circumstances to be deprecated in UKSI.

The problem for iRecord users was that both versions of Nephus redtenbacheri were being displayed identically, so when adding records it was impossible to know which was the genuine segregate Nephus redtenbacheri, and which was the synonym for the aggregate.

Normally when iRecord displays an older synonym it says that it is a synonym and gives the current name, but that wasn't happening for Nephus redtenbacheri, and that is what led to #1476

I agree that normally we don't mark synonyms as "not for data entry" - it may well have been me that suggested it as a solution for the Nephus redtenbacheri example and I was probably wrong to do so. But we do need to ensure that recorders can see which of the two options they are choosing, and I think that will happen as long as the old version of Nephus redtenbacheri is no longer marked as preferred?

[Sam-Amy]

Where this kind of thing has happened for bryophytes a distinguishing qualifier has been added e.g. for Leucobryum juniperoideum when L. albidum was discovered in the UK the existing concept had 'sensu Smith 2004' added as a qualifier whilst the new concept has 's.str.', so I don't know if this would help here?

My understanding is that in the UKSI 'deprecate' just means removed from being offered for data entry, but that this is not the same as redundant (which is reserved for whole concepts, rather than individual names).

[johnvanbreda]

Just for info - UKSI has the concept of a taxon version (i.e. a name) having a date range (taxon_version.date_to), so it can be marked as no longer valid. It can also be marked as deleted. An organism can also be marked as deleted or redundant. We map all these to the taxa_taxon_lists.allow_data_entry field, but also store additional info about the UKSI state in the taxon table (though don't really do much with that info at this point).

@kitenetter's synopsis is spot on - we didn't need to mark these taxa as not for data entry as the reason why the synonym name didn't have the accepted name shown was due to the incorrect setting of the preferred flag. I also agree with @Sam-Amy in that it might have helped to have the s.s. and s.l. attributes applied to the 2 versions of Nephus redtenbacheri.

I will run the proposed script to reverse the changes to the allow data entry flag then when I can get onto the warehouse1 server which is in use at the moment.

[robin-hutchinson]

Thank you everyone - this all makes sense! As Nephus is in the ladybird family, I'll ask Helen if she is happy for the UKSI to be updated with s.l. and s.s., or if she and Peter have a preferred way for these two names to be stored.

Looking back at the iRecord emails, this was in response to a forum request: https://irecord.org.uk/forum/feedback-and-suggestions/taxon-name-duplicate-nephus-redtenbacheri

This species used to have a 3 next to it for recording difficulty but it doesn't any more so I think the record cleaner rule is being applied to Nephus redtenbacheri "s.l."

[Sam-Amy]

Possibly the same problem with Rhagonycha limbata or Rhagonycha nigriventris (see new app issue #271). Another example of a species (and synonym) not showing on the app, despite showing on the website. I notice again there is a single synonym marked redundant visible in the warehouse (though not sure if this proved to be relevant above?).

[sacrevert]

@burkmarr Can this issue be closed?