{{Showfacts residences}} is one of several templates designed to create an infobox on a person page, in addition to the "general" infobox ({{showfacts person}}), the "offspring" infobox ({{showfacts children}}), and the "siblings" infobox ({{Siblings}}), which were the only three developed by April 2018. Because the original three are now familiar, with several of us able to tweak them as desired, developing another should be within our capabilities. User:Phlox has been invited to help but had made no response by March 2018.
In October 2015 the template looked like this (if you added a few line breaks for easier display):
<includeonly>{{#if: {{REVISIONID}}
||<center>'''Move this template to the
location in the article where you wish
the table to appear.'''</center>
*"Showfacts residences" displays
residences of an individual in a table.
If no data, this template does nothing.
*To add data to this template or
change data, choose the "edit with form"
menu item and click the
Residences form button.
(Coming soon -
see [[Familypedia:Residences template]] and
[[Help:Properties for persons (showfacts)]])}}
</includeonly><noinclude>
Purpose: Lists residences.
{{documentation}}
[[Category:Facts templates]]
</noinclude>
See also Template talk:Showfacts residences.
How we start[]
We have experience with place-settings(!). Street address, locality, county, nation-subdiv1, nation, and other places. We can assemble them in the same way as we do for other events. Dates seem to be even easier if we use only day, month, year.
However, "residence" has a duration too, so we should ideally bring "end" year, month, day in as well, a total of one or two dates per residence. (See recent edit to Template:Showfacts residences/doc.) Help:Properties for persons (showfacts) (near the bottom of the table) has some properties with end-dates. See subpage properties available for complete list.
In some cases no date may be known or even reasonably estimatable. We should be able to handle that just as we do for other events that have no stated date.
It may be best to use a separate "subform" in much the same way as we have a separate subform for children. That seems to have been Phlox's plan when he wrote "click the Residences form button". Compiling the "_date" and "_place" properties should probably be part of that rather than overloading "showfacts person".
See the talk page for detailed ideas.
To match the style of {{showfacts children}}, we can use {{showfacts formbuttons}} in the same way as that does.
Display options[]
Initially a heading, similar to what {{Siblings}} produces. (Introduced in 2018)
All could display in one table because they would not have separate headings as child groups do. More of them than child groups, though, almost certainly. Some people, e.g. soldiers and fostered orphans, moved around a lot. Options:
- street, locality, county, nation-subdiv1, nation, other place, start-date, end-date
- place, start-date, end-date
- just start-date and place, as suggested below - or maybe place and end-date using the properties on Help:Properties for persons (showfacts)
The dates can be compilations from the various subproperties, structurally the same as we have in the general infobox. "Place" could presumably be a similar sort of compilation, as we have in existing infoboxes; "other place" might be better at the start, because it's often a building rather than an obsolete country name.
See sections below this for more working-out.
"Street"/"address" and "other places"[]
The intended use of the "street" or "address" fields and the "places-other"(?) fields needs more work because their relationship is not clear to users. See my talk page; but I think it should be on a forum. Forum not working properly, so I've sent a Wikia Contact message. -- Robin Patterson (Talk) 02:45, March 3, 2013 (UTC)
Clarified subsequently but may need even more thought. -- Robin Patterson (Talk) 01:31, November 3, 2014 (UTC)
Overlapping "residences"[]
One may:
- know that a man arrived in the United States in 1880 (from shipping or other records) and that he said on his deathbed in 1911 that he had never left the country, but
- have definite knowledge of his residence in Greene County, Ohio only from 1899 until his death.
The US residence could be recorded as 1880-1911, but that would lead to overlapping residences. Keeping the US to 1880-1899 could be simpler and more logical.
The next edit to his page, however, could lead to overlaps: if new evidence shows his residence in the county began no later than the 1890 census, the county period would be changed, but there should be some way to ensure that the US residence period is correspondingly altered.
The above problems could be removed if no "end date" were coded or formally displayed.
Suggested form layout[]
A way to ensure no overlaps: make a person's record consist of, for example:
- known or assumed date of birth + place, if known, assumed to be 1st residence until evidence of move
- date of known or assumed 1st move + 2nd known or assumed new residence
- date of known or assumed 2nd move + 3rd known or assumed new residence
- date of known or assumed 3rd move + 4th known or assumed new residence (and so on, for as many residences as known)
- known or assumed date of death (place as for the last move)
The form could therefore have each move and its resulting residence field in a single section, much as we do for marriages, with full standard options for dates (including the approximation prefixes) and (six-possible-field) places. Overlaps are prevented because, e.g. someone changes the "date of known or assumed 2nd move" from 1899 to 1890 the program will automatically shorten the "2nd known or assumed new residence". Somehow the program will be able to display that "2nd...residence" by picking up its start-date and the start-date of the "2nd". That will require some digging into text strings, which we can do.
Unknowns and anomalies[]
Where a date is unknown it will be stated so. The extreme case will be a person whose birth and death places differ with no indication of any place at any other time. They have:
- birth date (known or unknown) + 1st residence (= birth place)
- unknown date of 1st (and presumed only) move + 2nd (and last) known or assumed new residence
- known or unknown date of death (place as for the last move)
There will be occasional anomalies, such as death on holiday trip or birth during mother's holiday trip or birth or death in transit (usually at sea in past centuries); they should not spoil the overall system. Census-takers treat trains and ships as residences, no matter how transitory; we could too, and can write guidelines for whatever policies we agree on.
A coding problem may arise from discovery of a new residence to be inserted in the list. If we have (as we should have?) coded the move and residence numbers we will need to change any that follow the insertion. At present we need to go through a manual edit for changes of marriage etc, so the same sort of procedure should apply to residences. Similarly, anyone with more residences than our form allows for will need manual work.
Display details[]
Expanding on the earlier-written "options" section above:
On a person's page[]
(under a "Residences" heading - same style as "Siblings" so that it shows even if no programmed data, allowing free-text manual data addition) could be very like the input form with two columns or could be easier to absorb by having three columns - place, start-date, end-date. Maybe the notes and sources displayed in the same row instead of away down the page - for more direct linking to dates and places.
On bdm pages[]
The "Resided in" sections will want to display start-date and (calculated from the start-date for the next place) end-date. If the travel took more than a day, there will be a strong temptation to count the ship or covered wagon etc as a residence so as not to get incorrect start-dates or end-dates.
- "Unknown" dates will show as unknown. Attempts to list, or report the number of, Familypedia people residing in a certain place on a certain date (i.e. an extension of bdm pages) will be muddied by unknowns. It may be wise to exclude unknowns from any calculated totals. With a definite start-date or end-date, however, residences with just one unknown date can be counted for the known date. That could produce useful trends in mass-migration, e.g. a table showing how many people arrived in a particular county in a particular year, maybe combined with columns for births and deaths by year. As we could have billions of such tables, their construction should be clearly documented so that contributors can publish their own tables for the places that interest them.
Do not categorize as migration[]
We would have to resist the temptation to categorize people automatically by migrations based merely on residences because a category for people migrating from "USA" to a part of USA would not be sensible. We are already miscategorizing people as migrating from their birthplaces to their deathplaces where they did not migrate that way but had two or more separate "migrations" (one of which might have been merely going "home" with one's parents, e.g. from a diplomatic posting); it would be even sillier to have possible non-migration counted as migration. -- Robin Patterson (Talk) 01:31, November 3, 2014 (UTC)