1

Topic: Name Matches - big frustration

The new recorder name matching in version 6.30.0.291 of Recorder 6 is extremly frustrating. After edits to the source data finanly managed to import some records from iRecord.

1) Recorder 6 can now say there are multiple possible entries for a name. However, there is only one extact match, and various other fuzzy matches. If there is an exact match, then Recorder 6 should use that. I am not interested that there are other vague matches. I don't know and I don't care that "J Smith" may be or maybe not "John Smith" when I already have a "John Smith" entry. Unless I know the person, and they have a rare name, I just don't whether they are the same person or two different people.
My rule, is that if there is not an exact match, create a new person. I tried in the past to clean up the database to remove duplicates, and it was too much hard work for too little reward.

2) People with double barrel surnames are a pain to enter into Recorder 6, as there seems to be no format that Recorder 6 understands. the real issue is that Recorder 6 can treat comma to mean either surname, forename or recorder 1 and record 2. The standard should be comma means "surname, forename". I usually find out there is a problem, when Recorder 6 wants to create a person with just their forename.

Harry Clarke
Surrey County Butterfly Recorder

2

Re: Name Matches - big frustration

The complaint was that Recorder was too free in the way it would match or automatically create a John Smith or just match a John Smith to an existing John Smith  when there were several other possiblibilties which it could be eg J.Smith, Mr Smith etc. This was leading to matches being made which were not correct, without the user being given the opportunity to check.  With the new matching it is possible to get a lot more information about the recorders in the system, which can help with deciding who the correct one is, or if a new Recorder is required. There are multiple views on this issue.  Some believeing that the accurate allocation of a person to a record is as important as knowing the date recorded. These users do not want the system making spurious choices for them.  Others just recording the name because it is there and not caring if the person could ever be indentified from the information. This  is perhaps something which needs to be debated via Trello. From a systems point of view it is hard to justify allowing the system  to make decisions for users when there is insufficient or conflicting information. Name matching has as far as possble been brought into line with species matching in that where there appear to be multiple possibilities then the onus is on the user to make the choice.

I agree with your point on hypenated names. The parser doesn't handle these very well. Various solutions were propsed in the JNCC days, but all have drawbacks. I will go back through the work done on this and see if we can now see a way forward.

Mike Weideli
Littlefield Consultancy - IT Consultants