Form Actions - User Editing of Action Detail

It always seemed like the 9/12 or 6w Census entries were a validation on a Zero age entry.

So why not transcribe them that way? Don’t even try to actually parse that text verification. That is, for 20 June 1860 census, calculate a Birth Event date of “calculated about 1860” having an Event Description of “age '9/12’ logged in 20 June 1860 Census”

To my mind transcription should preserve exactly what you see in the source document / image. You, the transcriber, may believe the information to be wrong, (you may know it is wrong) but it does not alter the fact that in this particular document, that is what it says.
As a user I want “9/12” converting to a date (or date range) in the event so I can, for example, sort events chronologically.
I prefer to have a single Birth event per Person. So using the Event Description would be problematic. You could put the information as an event reference note though, albeit at the cost of duplicating information already entered into the Form. Personally I prefer to avoid duplication of data - sooner or later I always end up with discrepancies!

Lots to think about there. Thanks.

My initial thought is that the form is, in the main, the Transcription today (or at least can be used that way by the user). There are exceptions, for example:

  • the “Name” column which is partly an interpretation by virtue of the user having to choose a Person object.
  • UK census form definitions have a single Age column whereas the source documents have Male and Female age columns

I wonder if having a second “interpretation” table (in many cases, likely to be similar to the original form) would work? The interpretation table could be interleaved with the transcription table (row by row say), or it might bl cleaner to have a separate window (and automatically show the transcription window to help the user). The software can pre-populate the interpretation table based on rules. The user can adjust the pre-populated interpretation data as required and use their knowledge to add additional interpretation data. When the user is ready, they can apply the intepretation to create / update objects in the db. An empty cell in the interpretation table would mean don’t do anything.

Do you think the interpretation data should be stored in the db, or could it be temporary and discarded once used to update the db?

Could you clarify the problem? Each Event has a Description so it wouldn’t necessitate creating multiple Birth events. Wouldn’t you just skip creating a separate Birth Event and merely Share a household Census Event if a Birth Event already exist for a person?

Actually, ALL American Census that log ages instead of dates means Date transcriptions have to be approximations. (The Swedish census turn Americans green with envy.) So storing the Birth event with a calculated Date (including the Quality markers ‘calculated’ & ‘about’) & explicitly including a Description with the original Age entry clad with an explanation seems reasonable.

I agree. Although as you mention the age/sex columns in the UK census definitions don’t really allow this. It is possible to edit the name and it will be stored as an attribute.

We should store the interpretation alongside the transcription.

For example, we may calculate a date from an age and store it in another attribute. It could be displayed as a tooltip over the age, and we could edit it by double-clicking the age field, a context menu or perhaps adding an extra button.

I don’t currently use forms, but I am trying to get into the habit doing as you describe in terms of citing sources first and creating/updating people and events afterwards.

I would add “Translation” as an optional step between “Transcription” and “Interpretation”. For example, when I have a German baptismal record, I create a Note of the type “Transcript” in which I enter the German text (although I use the modern font rather than one that reflects the old orthography). Then I create a separate note of the type “Translation” in which I enter the information in English. One might say that translation is really part of interpretation, and certainly there is an element of interpretation involved in translation (for example, coming with an equivalent meaning of a person’s occupation), but that is not the same kind of interpretation that you mention, which is independent of language.

1 Like

Yes, translation is definitely an extra step. It would also be very useful to include when sharing the transcription with others.

If a single person appears in several years census and two or more have a non-standard Age, you have to decide what to put in the person’s single birth event description field.

It would be possible to amend the form the have a male and female age column for UK census definitions. That would keep the forms closer to a pure transcription.

I’d spotted that the name could be editd. Slightly counter intuitively, you do the interpretation first (by choosing the Person record) and then amend the name back to be the transcription :wink:

Currently a form event stores attributes in both the event itself and the event reference as shown below (1841 UK census)
image

It would be easy enough to add additional attributes to store the interpreted data, for example by suffix of the attribute name:
image

In this example, “Age” is the transcription, “Age_Interpreted” the interpretation (which might be better called “Birth Date”). When it comes to updating the birth event, there are three scenarios

  1. no birth event for the person exists. Create a new event, using the interpreted birth date and add a citation.
  2. a birth event already exists.
  • if the interpreted birth date overlaps the current birth event date, add a citation and optionally narrow the date range for the birth event.
  • if the interpreted birth date does not overlap the current birth event date. It’s not obvious what should happen. Probably nothing

In terms of how the user enters the interpretation data, double click and context menu in the form editor window are not easily discoverable. A button is more discoverable, but one button per form field is a lot of buttons. I was thinking about a parallel window, dedicated to the interpretation data. Modeless so that the form editor window (transcription) could be visible at the same time. Male age and female age columns on a UK census transcription would be “Birth Date” and Gender columns in the interpretation window.

Or is this the sort of place where “Estimated” would be used?

I would argue that ‘Calculated’ is appropriate here (from a UK census anyway). The source document gave us an Age in years. From that a date range was calculated.

Here’s a starting point (it’s only a bitmap so ignore rendering inconsitencies)

Red text is explanatory

The Transcription window is the current Form editor window. The only change would be to potentially remove the Person selector button

The interpretation window can be launched from the form editor window or the forms add-on window.
In the interpretation window:

Name column is read-only. It shows the primary name of the selected person.

Birth Date is the interpretation of the Age column. Perhaps the first three rows could be created by the software, and the user manually added the fourth.

Occupation is the description for an occupation event. The user has interpreted the transcription “Ag Lab”, a common UK census abbreviation, into “Agriculatural Labourer”. Perhaps the software could do common mappings like this.

Where Born is a reference to a Place. Here the user has interpreted the translation “Leicester” to choose the place Leicester in Leicestershire, England. (not that I’m sure how to store the place reference in an attribute).

What’s not covered?

  • creation of families (not relevnt for UK 1841, but later UK census have Head, Wife, Daughter, Son etc)
  • use “Name” to add an additional name and / or citation to an existing additional name

and probably more

The problem I often see with Census data is that Census takers (& those interviewed) rounded up and rounded down ages… even when they weren’t fibbing.

Some prople figured age as of January 1 or December 31… or actually precisely considered the day of the census and their birthday. So Census can only reliably calculate a birth year range.

Calculated implies a level of accuracy that can’t be achieved with Census within the constraints of GEDCOM. And, for better or worse, the GEDCOM specification has influenced design specs for most genealogy software.

The decrepit GEDCOM standard only supports 1 DATE_APPROXIMATED modifier: About, Calculated, Estimated. Or you can also use a DATE_RANGE: Before, After, Between. But it doesn’t permit combining the attributes as an approximated (calculated) range (between).

(If your range fell within a calendar month or year, you COULD imply a range by dropping the day or month. That is fully compatible with the Calculated spec.)

Gramps currently does support combining dates ranges with approximations! And another current thread here is discussing eliminating that for the GEDCOM export because it fails compliance testing.
See

It’s a conundrum.

This was a design decision. I didn’t want the user to enter data and then not link a person.

If I were writing this again, from scratch I would probably store the transcription as a marked-up note rather than in attributes.

Yes, that would work. I was thinking of a prefix such as “%”. e.g. “%Age” or “%DOB”.

Remember that this need to be translated into different languages.

Not a good idea. Users always complain about the number of windows.

Consider creating an interpretation section alongside or below the existing table. It could be created dynamically and contains fields such as “Date”, “Place”, “Transcription”, “Transliteration” etc…

Store the place as a handle.

Not for all. I apparently adapted the forms for “interpretation.” Unfortunately, in manual mode.
My db has a lot of parish register books. First of all, I made castom forms to connect people to one event (baptism, marriage, census). After I started add img of book’s page in forms. This image have notes with type “source_text”. This notes is my “transcription”. Then manually I add in this form’s citation a referense to img’s note (source_text). And now, manually, add in events (birth, death, military, occupation and other) references to form’s citation.
This is tiring. And I look forward to such discussions.

Maybe, “interpretation” forms will created like now “Transcription”, with xml mask? I would like to have an aportunity for make forms with “row=events”.

1 Like

Yes. The aim will be to define interpretation fields in the XML form definitions.

Shouldn’t the Transcibed unstructured text and the interpretation of it be stored as research Notes (Documents)…

And for the dates, maybe see if its possible to make an “Alternative Dates” for Events, with Citation to the source of that date input?
Actually any date is just attributes of an event, so its how it can be used and what kind of metadata that can be added to it thats matter the most…
I think that the important thing with any type of data/information is that its easy to view and easy to compare them to similar data…, and as with Alternative Names, it should be possible to chose the “Prefered” data… (maybe with a forced notation field with why this was chosen over the others…

Often you find “calculated” birth dates in different sources, and instead of storing each of this dates in a seperate attribute or Event, it would be easier to compair them if they all was registered to one Event as alternative dates for that Event…

I know this would be some redesign of Gramps, so its just a thought…

Another feature could be a full featured research log gramplet, where the Trancription, Interpretation and any Translation are done and stored, and with a “transfer to tree” feature when done…
(I mention Clooz 3 as an example)

@Nick-Hall I really like your idea about annotation text and making metadata object that can be linked to entities in the database, and even creating new entities with them…

There are other research tools (not genealogy)out there that do things like that, Histograph is one web solution for crowdbased document annotation that has features like that… and in the photography world, face recognition and object recognition is another appoach…

It would be great if something like that would be possible in Gramps, there are already the internal linking feature for notes, but if that could be extended to be used for annotating source images and PDF’s, that would be a feature that no other desktop software provides, neither in genealogy nor any other humanities research field as I know of, and I have used the last 2 years searching for and creating a zotero database with all types of research tools, archiving tools, publishing tools, database tools, document management tools, excibition tools and so on…

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.