Data Conversion Notes - Revision history

Dmac: /* Relationships */

2026-03-31T20:38:47Z

Relationships

← Older revision		Revision as of 20:38, 31 March 2026
Line 75:		Line 75:
	There were 2111 people identified in the Family Groups pages of the original wiki who are listed as parents to a person in the database but without LBT numbers. We added them to the Identity table so they would have their own LBT identification numbers and added them to the relationship table as parents of persons in the database.		There were 2111 people identified in the Family Groups pages of the original wiki who are listed as parents to a person in the database but without LBT numbers. We added them to the Identity table so they would have their own LBT identification numbers and added them to the relationship table as parents of persons in the database.
	===Relationships===		===Relationships===
	The database has separate tables for Parents, Children, Siblings, Marriages (dates only), and Partnerships (ie, marriages). All these data were abstracted into a Relationship table linking two people and identifying the relationship type. The resulting table has 12,~~449~~ records detailing two kinds of relationships: spouse and child.		The database has separate tables for Parents, Children, Siblings, Marriages (dates only), and Partnerships (ie, marriages). All these data were abstracted into a Relationship table linking two people and identifying the relationship type. The resulting table has 14,308 records detailing two kinds of relationships: spouse and child.

	For example, [[LEACH, Thomas ‹ LBT 35680 ›\|Thomas Leach]] (35680) is a child from the marriage of		For example, [[LEACH, Thomas ‹ LBT 35680 ›\|Thomas Leach]] (35680) is a child from the marriage of

Dmac: /* Unresolved Issues Still Being Worked On */

2026-03-31T20:37:00Z

Unresolved Issues Still Being Worked On

← Older revision		Revision as of 20:37, 31 March 2026
Line 138:		Line 138:
	Let's illustrate with an example. Take [[BATTERSBY, Katherine ‹ LBT 16225 ›\|BATTERSBY, Katherine ‹LBT16225›]]. Starting with the <code>Parents</code> table, we see her father is 13464 and her mother is 3732. The <code>Partnerships</code> record with those two members is number 6812. The <code>Children</code> table has eight records pointing to that Partnership; those eight include a Katherine but she doesn't get an original LBT number, so her identity is ambiguous. The <code>Parents</code> table has 11409 and 3549 as Katherine's parents, and they are in partnership 5027. On the other hand, starting with the <code>Children</code> table, we see relationship 5027 as the parents of 16225, and working that way, we can see that table has two children of that partnership, Winstanley and a Katherine, who in this case has the LBT number of 16225.		Let's illustrate with an example. Take [[BATTERSBY, Katherine ‹ LBT 16225 ›\|BATTERSBY, Katherine ‹LBT16225›]]. Starting with the <code>Parents</code> table, we see her father is 13464 and her mother is 3732. The <code>Partnerships</code> record with those two members is number 6812. The <code>Children</code> table has eight records pointing to that Partnership; those eight include a Katherine but she doesn't get an original LBT number, so her identity is ambiguous. The <code>Parents</code> table has 11409 and 3549 as Katherine's parents, and they are in partnership 5027. On the other hand, starting with the <code>Children</code> table, we see relationship 5027 as the parents of 16225, and working that way, we can see that table has two children of that partnership, Winstanley and a Katherine, who in this case has the LBT number of 16225.

	In other words, starting with the <code>Parents</code> table, we find one pair of parents who have eight children, but starting with the <code>Children</code> table, we find a different pair of parents who have only two children. ~~This~~ contradiction ~~needs a solution~~ in the data.		In other words, starting with the <code>Parents</code> table, we find one pair of parents who have eight children, but starting with the <code>Children</code> table, we find a different pair of parents who have only two children. After careful study of the records in several tables of the original database, this contradiction was fixed in the data.

	A different example illustrates a consequence of an unfortunate design decision in the original db's schema. Records in the `children` table do not contain parent information - they point to a record in the `partnerships` table and that table has a column for the `LBTManNo` and the `LBTWomanNo` (the lbt numbers for the man and woman united in that traditional partnership). Since the database cannot represent parenthood directly, when the mother is unknown, they could not show the father as the sole known parent. Their solution was to make the children belong to all partnerships of which the known parent was a member.		A different example illustrates a consequence of an unfortunate design decision in the original db's schema. Records in the `children` table do not contain parent information - they point to a record in the `partnerships` table and that table has a column for the `LBTManNo` and the `LBTWomanNo` (the lbt numbers for the man and woman united in that traditional partnership). Since the database cannot represent parenthood directly, when the mother is unknown, they could not show the father as the sole known parent. Their solution was to make the children belong to all partnerships of which the known parent was a member.

Dmac: /* Relationships */

2026-03-31T20:35:07Z

Relationships

← Older revision		Revision as of 20:35, 31 March 2026
Line 77:		Line 77:
	The database has separate tables for Parents, Children, Siblings, Marriages (dates only), and Partnerships (ie, marriages). All these data were abstracted into a Relationship table linking two people and identifying the relationship type. The resulting table has 12,449 records detailing two kinds of relationships: spouse and child.		The database has separate tables for Parents, Children, Siblings, Marriages (dates only), and Partnerships (ie, marriages). All these data were abstracted into a Relationship table linking two people and identifying the relationship type. The resulting table has 12,449 records detailing two kinds of relationships: spouse and child.

	For example, [[LEACH, Thomas ‹ LBT ~~32366~~ ›\|Thomas Leach]] (~~32366~~) is a child from the marriage of		For example, [[LEACH, Thomas ‹ LBT 35680 ›\|Thomas Leach]] (35680) is a child from the marriage of
	[[LEACH, Dryden (bap. 1684 - 1731) ‹ LBT 19861 ›\|Dryden Leach]] (19861) and [[AYRES, Elizabeth (mar. LEACH) ( - 1772) ‹ LBT 04476 ›\|Elizabeth Ayres]] (4476). This is represented		[[LEACH, Dryden (bap. 1684 - 1731) ‹ LBT 19861 ›\|Dryden Leach]] (19861) and [[AYRES, Elizabeth (mar. LEACH) ( - 1772) ‹ LBT 04476 ›\|Elizabeth Ayres]] (4476). This is represented
	by a relationship record of type "spouse" between Dryden and Elizabeth,		by a relationship record of type "spouse" between Dryden and Elizabeth,

Dmac: /* Unresolved Issues Still Being Worked On */

2026-03-31T20:30:55Z

Unresolved Issues Still Being Worked On

← Older revision		Revision as of 20:30, 31 March 2026
Line 152:		Line 152:
	There is a list of 97 of them to be incorporated into the new wiki		There is a list of 97 of them to be incorporated into the new wiki

	~~===Livery Company===~~
	~~Because of its importance, we have listed membership in the Stationers' Company in 2.0; other livery companies will be listed in a later release.~~
	===Life Events===		===Life Events===
	The events in the Births, Baptisms, Deaths, and Burials tables need to be checked back to Events to ensure that all available data have been used.		The events in the Births, Baptisms, Deaths, and Burials tables need to be checked back to Events to ensure that all available data have been used.

Dmac: /* Overview */

2026-03-31T20:28:11Z

Overview

← Older revision		Revision as of 20:28, 31 March 2026
Line 2:		Line 2:
	==Overview==		==Overview==
	Extracting the information from Michael Turner's original Access database was		Extracting the information from Michael Turner's original Access database was
	an example of what we can call digital archaeology: scraping away layers of revised or redundant data, identifying and clearing experiments that didn't work, rejecting partially completed or eventually ignored tables, and incrementally building a script to pull out the gold coins and silver treasures for presentation in this wiki.		an example of what we can call digital archaeology: scraping away layers of revised or redundant data, identifying and clearing experiments that didn't work, rejecting partially completed or eventually ignored tables, and incrementally building a script to pull out the gold coins and silver treasures for presentation in this read-only wiki.

	This description of the process of identifying and extracting the information from the database is not meant to disparage the years of effort that Michael Turner and the rest of the team spent on this project. It is a herculean effort that resulted in 30,906 individuals being described in painstaking detail across hundreds of years of book making history in London.		This description of the process of identifying and extracting the information from the database is not meant to disparage the years of effort that Michael Turner and the rest of the team spent on this project. It is a herculean effort that resulted in 30,906 individuals being described in painstaking detail across hundreds of years of book making history in London.

Dmac: /* Floruit */

2026-03-31T20:26:59Z

Floruit

← Older revision		Revision as of 20:26, 31 March 2026
Line 107:		Line 107:

	Similarly, using the ''floruit'' dates generated from aggregated activity data throughout the database, we've added the "printing trade" and "non-printing trade" people to each year of the calendar. In this way you can see which people were likely to be active in any given year.		Similarly, using the ''floruit'' dates generated from aggregated activity data throughout the database, we've added the "printing trade" and "non-printing trade" people to each year of the calendar. In this way you can see which people were likely to be active in any given year.

			=== Confidence Scores or Grades ===
			A number of calculations were necessary to resolve conflicting references in the data: was this person the child of A or B; how definitive is our estimate that C's career started in 1580. These are detailed in this document, in [[How Floruit is Calculated]], and in [[Relationship Confidence Scores]].

			Please note that a confidence grade or score is NOT attesting to the accuracy of the underlying data, which has been recorded and transcribed from numerous sources, over hundreds of years, by various people, in various formats, for various purposes. Rather it is an effort to digitally score certain of the data which has been entered into this repository relative only to the other data in this repository--as an aid to researchers in assessing reliability. Thus all programmatically determined confidence scores (even a score of 100) are guidelines only. Anyone intending to use the data from this repository is advised to satisfy themselves on the suitability and accuracy of the data for their purposes as the developers and the Bibliographical Society make no such representations.

	===Floruit===		===Floruit===

Dmac: /* Data Quality Issues */

2026-03-29T21:27:55Z

Data Quality Issues

← Older revision		Revision as of 21:27, 29 March 2026
Line 66:		Line 66:

	Furthermore, many data have unexpected comments: "Query location" in an address or "q-?" in a first name. So far, it has been infeasible for us to edit out all these aberrations - we don't know how to resolve any queries or contradictions without full access to all the sources that MJT used over several decades of work. Consequently, we are forced to leave such errors in place and beg our readers' indulgence.		Furthermore, many data have unexpected comments: "Query location" in an address or "q-?" in a first name. So far, it has been infeasible for us to edit out all these aberrations - we don't know how to resolve any queries or contradictions without full access to all the sources that MJT used over several decades of work. Consequently, we are forced to leave such errors in place and beg our readers' indulgence.

			The final issue with data quality is incomplete parsing of the available information. There are comment and note fields throughout the original database that contain information that belongs in actual data structures. Similarly, there are quotes from Plomer, the ONDB, and other sources. For example, some comments in children records have their birth or baptism dates but this information is not found in the `baptisms` or `births` tables. It may be possible to selectively parse some of these data and place them in the appropriate tables.

	===New Person Records===		===New Person Records===

Dmac: /* Data Quality Issues */

2026-03-29T18:34:10Z

Data Quality Issues

← Older revision		Revision as of 18:34, 29 March 2026
Line 64:		Line 64:

	One example is the `parents` table that lists the lbtnumbers for the father and mother of the child identified by their lbtnumber. The redundant data here consists of the father's forenames and surname and the mother's forenames, surname, and maidenname. Of the 30600 records in parents, 413 list names for the father that do not match the names of the people identified by the father's lbtnumber. Is the name correct and the lbtnumber for the father incorrect, or is the father's lbtnumber correct and the name incorrect. Currently there is no apparent way to know without reverting to the original sources and reperforming the research.		One example is the `parents` table that lists the lbtnumbers for the father and mother of the child identified by their lbtnumber. The redundant data here consists of the father's forenames and surname and the mother's forenames, surname, and maidenname. Of the 30600 records in parents, 413 list names for the father that do not match the names of the people identified by the father's lbtnumber. Is the name correct and the lbtnumber for the father incorrect, or is the father's lbtnumber correct and the name incorrect. Currently there is no apparent way to know without reverting to the original sources and reperforming the research.

			Furthermore, many data have unexpected comments: "Query location" in an address or "q-?" in a first name. So far, it has been infeasible for us to edit out all these aberrations - we don't know how to resolve any queries or contradictions without full access to all the sources that MJT used over several decades of work. Consequently, we are forced to leave such errors in place and beg our readers' indulgence.

	===New Person Records===		===New Person Records===

Dmac: /* Overview */

2026-03-28T15:14:29Z

Overview

← Older revision		Revision as of 15:14, 28 March 2026
Line 6:		Line 6:
	This description of the process of identifying and extracting the information from the database is not meant to disparage the years of effort that Michael Turner and the rest of the team spent on this project. It is a herculean effort that resulted in 30,906 individuals being described in painstaking detail across hundreds of years of book making history in London.		This description of the process of identifying and extracting the information from the database is not meant to disparage the years of effort that Michael Turner and the rest of the team spent on this project. It is a herculean effort that resulted in 30,906 individuals being described in painstaking detail across hundreds of years of book making history in London.

	However, there are limits to what we could do to verify and correct the data. Where there are ambiguities, we present them; where there are contradictions, we endeavour to choose the most likely correct version; where there are typos or unparsed data, we present it in the form we found it. It would require much more time than we have available to reperform all the research, check all the references, parse out all the available data into normalised data structures, and present a LBT 3 that is correct and current.		However, there are limits to what we could do to verify and correct the data. Where there are ambiguities, we present them; where there are contradictions, we endeavour to choose the most likely correct version; where there are typos or unparsed data, we present it in the form we found it. It would require much more time than we have available to reperform all the research, check all the references, fix all the typos, parse out all the available data into normalised data structures, and present a LBT 3 that is correct and current.

	==The original database==		==The original database==

Dmac: /* Overview */

2026-03-28T14:17:53Z

Overview

← Older revision		Revision as of 14:17, 28 March 2026
Line 5:		Line 5:

	This description of the process of identifying and extracting the information from the database is not meant to disparage the years of effort that Michael Turner and the rest of the team spent on this project. It is a herculean effort that resulted in 30,906 individuals being described in painstaking detail across hundreds of years of book making history in London.		This description of the process of identifying and extracting the information from the database is not meant to disparage the years of effort that Michael Turner and the rest of the team spent on this project. It is a herculean effort that resulted in 30,906 individuals being described in painstaking detail across hundreds of years of book making history in London.

			However, there are limits to what we could do to verify and correct the data. Where there are ambiguities, we present them; where there are contradictions, we endeavour to choose the most likely correct version; where there are typos or unparsed data, we present it in the form we found it. It would require much more time than we have available to reperform all the research, check all the references, parse out all the available data into normalised data structures, and present a LBT 3 that is correct and current.

	==The original database==		==The original database==