1 Reply by DaveSlade

  • DaveSlade
  • Veteran
  • Offline
  • Registered: 15-05-2006
  • Posts: 332

Re: duplicates in the FUNGI & LICHEN checklist

Back in February I discovered that the majority of Fungi in our version of the FUNGI & LICHEN checklist have two entries, one from the original BMS version of the list, and one from the updated NHM version. I had assumed at the time that this was due to my messing about with the dictionaries, but from discussions with Mike Weideli and Sally Rankin it appeared that it was not my fault.

The last message I had on the subject was from Mike:

The problem is in the Dictionary or the way in which Recorder 6 handles Taxon_List_Versions.  The Fungi and Lichen list does have multiple Taxon_Determinations attached to  the same Taxon_Version, which is unusual, but I thought  acceptable.

The two  entries show up  when you do search. One can be found, but  the other causes an error. The  parent keys are not there for the ones causing error.

I don’t fully  understand  how this should work,  but it would seem that  both  Taxon_List_Item _Keys are valid.  In which case Dave does not have a problem but just needs to use the one which works for future entries.  Existing records should be ok.

To demonstrate the problem search the Fungi and lichen list for Abrothallus cetrariae

To be perfectly honest I had completely forgotten about this issue as I have not done any data entry myself for some time, and it is only with recent staff changes that it has resurfaced. It does not represent a major problem, but I would be far happier if there was only one entry in the dictionary for our data entry staff to choose from. Does anyone know whether the problem has been looked at? It seems fairly simple to only allow data entry screens to access the taxon with the greater Taxon_List_version...

Dave Slade
Senior IT & Records Officer,
15 Talbot Road, Talbot Green, Pontyclun, CF72 8AD
www.sewbrec.org.uk, www.sewbrecord.org.uk

2 Reply by wilkin_s

  • wilkin_s
  • Administrator
  • Offline
  • Registered: 31-03-2006
  • Posts: 87

Re: duplicates in the FUNGI & LICHEN checklist

Hi Dave
Sorry for the delay. I have a had a go at replicatoinng this here and cant. I get a single return for that species when I search the list. Can I check:
- what setting you have under options for "restrict taxon searches to"
- that you have a fully updated species dictionary (ie. what is the value of Dict Seq in settings)
Best wishes
Steve

3 Reply by DaveSlade

  • DaveSlade
  • Veteran
  • Offline
  • Registered: 15-05-2006
  • Posts: 332

Re: duplicates in the FUNGI & LICHEN checklist

Hi Steve,

My Dict Seq value is 0000000E. If Preferred Checklists are chosen then I get two options for Abrothallus cetrariae. If Unrestricted is selected then I get four choices, two of which are from the FUNGI & LICHEN list.

Dave

Dave Slade
Senior IT & Records Officer,
15 Talbot Road, Talbot Green, Pontyclun, CF72 8AD
www.sewbrec.org.uk, www.sewbrecord.org.uk

4 Reply by wilkin_s

  • wilkin_s
  • Administrator
  • Offline
  • Registered: 31-03-2006
  • Posts: 87

Re: duplicates in the FUNGI & LICHEN checklist

Hmm - odd. I cant remember whether this was something fixed in the latest version - but have a strong feeling it might have been. So - again - sorry - can I sugest you upgrade and see if this is still a problem.
Best wishes
Steve

5 Reply by DaveSlade

  • DaveSlade
  • Veteran
  • Offline
  • Registered: 15-05-2006
  • Posts: 332

Re: duplicates in the FUNGI & LICHEN checklist

That will teach me to keep up with the upgrades - the issue has indeed been resolved.
Many thanks,
Dave

Dave Slade
Senior IT & Records Officer,
15 Talbot Road, Talbot Green, Pontyclun, CF72 8AD
www.sewbrec.org.uk, www.sewbrecord.org.uk

6 Reply by DaveSlade

  • DaveSlade
  • Veteran
  • Offline
  • Registered: 15-05-2006
  • Posts: 332

Re: duplicates in the FUNGI & LICHEN checklist

Although this problem has been fixed within recorder, my copy of the database has two valid preferred names for every species in this list. Is it possible to get this list updated so that there is only on preferred name within the list for the given species? I don't mind doing this myself in Access if that is what it takes, but I feel it should probably be done centrally.

Species    TLIK    PREFERRED    TAXON_LIST_ITEM_KEY    PREFERRED_NAME
Absidia coerulea    NHMSYS0001389325    -1    BMSSYS0000035452    BMSSYS0000035452
Absidia coerulea    NHMSYS0001389325    -1    NHMSYS0001389325    NHMSYS0001389325

As I say this is not affecting the functionality of Recorder, but does affect my manipulation of the data in Access.

Dave Slade
Senior IT & Records Officer,
15 Talbot Road, Talbot Green, Pontyclun, CF72 8AD
www.sewbrec.org.uk, www.sewbrecord.org.uk

7 Reply by CharlesHussey

  • CharlesHussey
  • Veteran
  • Offline
  • From: The Natural History Museum
  • Registered: 11-05-2007
  • Posts: 174

Re: duplicates in the FUNGI & LICHEN checklist

Dear Dave,

I have just been checking through items outstanding from 2008 and see that I had flagged up this thread.

It looks like you are still waiting for an explanation of why there are apparently duplicate preferred names.

There are two versions of the BMS list held in the Species Dictionary (one dating from 2002 and the other from 2005 with subsequent amendments). Your query is pulling up both versions of the list and that is why some names will be duplicated. So you need to introduce the appropriate key for TAXON_LIST_VERSION into your query in order to restrict the results to a single List Version.

I hope that this helps.

Best wishes,

Charles Hussey

NBN Species Dictionary Project Manager (Retired!) smile

8 Reply by DaveSlade (edited by DaveSlade 06-01-2009 12:23:08)

  • DaveSlade
  • Veteran
  • Offline
  • Registered: 15-05-2006
  • Posts: 332

Re: duplicates in the FUNGI & LICHEN checklist

Dear Charles,

Thanks, I can see that this would solve the problem. However it does beg the question as to why there should be two preferred names for the same taxa? By definition, surely there should only be one?

TAXON_LIST_ITEM_KEY                               BMSSYS0000035452                   NHMSYS0001389325
TAXON_VERSION_KEY                                BMSSYS0000000013                   BMSSYS0000000013
TAXON_LIST_VERSION_KEY                       BMSSYS0000000001                   NHMSYS0001389291
PREFERRED_NAME                                       BMSSYS0000035452                   NHMSYS0001389325

So in the example I used above, there are two taxon list Items that refer to the TAXON_VERSION_KEY  BMSSYS0000000013, and each has a different Preferred Name. Is there any reason (apart from time/resources) that the database can not be updated so that both have the same preferred name?

Regards,
Dave

Dave Slade
Senior IT & Records Officer,
15 Talbot Road, Talbot Green, Pontyclun, CF72 8AD
www.sewbrec.org.uk, www.sewbrecord.org.uk

9 Reply by CharlesHussey

  • CharlesHussey
  • Veteran
  • Offline
  • From: The Natural History Museum
  • Registered: 11-05-2007
  • Posts: 174

Re: duplicates in the FUNGI & LICHEN checklist

Dear Dave,

I started to write out a reply to you but abandoned it because the matter is best explained over the phone (basically, the database is doing the job that it was designed for but, unless you understand how things fit togther, it can look confusing).

If you care to let me know your telephone number by e-mail (to c.hussey@nhm.ac.uk), we can have a conversation about this.

Cheers,

Charles

NBN Species Dictionary Project Manager (Retired!) smile

10 Reply by wilkin_s

  • wilkin_s
  • Administrator
  • Offline
  • Registered: 31-03-2006
  • Posts: 87

Re: duplicates in the FUNGI & LICHEN checklist

Just to complete this post - for others - at least as I understand it. The preferred name here is probably (?) the preferred name within a list. Differeent lists may have different views on what the preferred name for a species is. However, the NAMESERVER is the thing that brings things together into a single preferred name (ie. makes an objective decision on what the preferred name should be) and allows consistent reporting across lists.
Steve