Hello Phil,
First of all, a thank you for the screenshots. I don’t use the Forms Addon here, and I only looked at it for a short time to help a fellow user in England.
When I look at the 1st, I see that every line shows data for a person, and when I see that, my 1st thought is, that eveything on that line should then also be stored as such, in an object that may be a bit simpler than the usual person that we can find in the tree, but still a person, and not some random list of attributes, stored in event reference attributes.
I call these random, because their names, the column headings, are sort of random. You enter these in the form definition, in such a way that they reflect the field names in the actual form. And that is nice for you at 1st glance, but it also means that there is no concistency in that, because another census, for another year in the UK, or for the US, where I see most censuses from (on Ancestry), has other columns. Some may have two columns for the name, a single column for the person’s age, one for sex, or not at all, because the sex is implied by the role, or the name. They’re also useless to users who don’t speak English, should you ever export your data to those.
This goes the other way too, meaning that when I define a form that mimics local records, which are often birth, marriage, and death records, no census ones, I will use Duch column names, and although some of those may still be easy to recognize for you, like Naam, others probably will not, like Beroep, or Beruf in German, which means Occupation.
You can get around this, by storing all data in a person(a) object, with separate GIVN and SURN fields, and fields for BIRT.PLAC, OCCU, and SEX. You may even convert the age to a calculated BIRT.DATE storing just a year. I am deliberately using GEDCOM tag names here, but for Gramps, it is probably better to use the field names that we already know from the person and event objects. And this is most likely what Ancestry and FamilySearch do, in the forms that they have for data entry, done by volunteers.
With such a change, you can still have forms, but like in the person and event forms for Gramps, there is some logic behind every field, so that it is stored in the proper database column, or object property. And in those forms, all headings can shown in the user’s language, with the data stored in such a way that everyone can understand it, and the software can also extract it for automated matches and reports. And in some cases, like for the Name, the logic can also use the comma that you enterd to separate it in GIVN and SURN parts.
There is another possible change too, and that is, that you store these evidence persons, or personae, to be attached to tree persons later, which is what the indexers working for FamilySearch do. And that’s quite easy in Gramps, because you can already create a source and citation without needing to connect it to a person or event, and you can attach the source/citation to a location object too, because in most cases, you know where the record was made. Place fields in the form can not be stored like that, because they can be ambigious, and that’s OK.
And with an independent person object, you can even go a step further, like for the index cards that I can find on the Amsterdam archive site, which not only list person data for the head, spouse, parents, and children, but also a list of addresses with dates, which can easily be stored in embedded residence events, or facts.
With such a change, it is quite easy to mimic what you see on Ancestry or FamilySearch in Gramps, including features for detaching evidence persons when you discover that you attached them to the wrong person in the tree. And like I wrote above, you can also delay that, and just enter loads of form data, before you start trying to find conclusions for the persons involved. And because the data is all stored in standard objects, all Gramps users can see things in their own language.
