Both of these queries require some way of matching a Person to a Source. There are two types of source meta-data that could be used for doing this matching:
* ''dates'' - if a Source had a start and end date we could match this against the result of ''probably_alive'' * ''places'' - places are trickier, what we want to ask is ''is this person likely to have lived somewhere in the region covered by this source''. An initial implementation might associate a Place object with a Source and match if the Person has any Place or Address references that match all of the fields that are set in the Sources Place. So for a Census the Source's Place would say England and if any of the Addresses on the Person also had England it would be a match. Source might need to have multiple Places and the matching algorithm might need to be rather fuzzy. A 'default place' might be need to cover all the People that have no Address or Place references.
I think that the ''date'' matching is clearly simpler than the ''place'' matching and should be the initial target.
To be able to produce these reports it is going to be necessary to record additional information in the database. Most of this additional information is recorded against Sources but some will also be needed against people and possibly against Repositories.
== Important issues ==
# It must be possible to exclude Sources altogether. Many Sources are not related to documentary evidence and you would not want
the cluttering up the reports.
# It must be possible to exclude Sources on an Person. If you know that you have checked a Source for an Individual you want to exclude that Source from showing up next time you run the reports.
It should be possible to make a start on this by storing the Source meta-data in the key/value data of the Source. This will allow an initial proof-of-concept of the reports without touching the database schema.
A more general version of probably_alive would be needed that can take a range and decide if the Person might be alive during that period.