GEPS 015: Repository Research Support - Revision history

Gioto at 02:37, 18 October 2011

2011-10-18T02:37:15Z

Rjt at 15:46, 7 August 2009

2009-08-07T15:46:31Z

Rjt at 15:45, 7 August 2009

2009-08-07T15:45:36Z

Rjt at 15:20, 7 August 2009

2009-08-07T15:20:10Z

Rjt at 15:13, 7 August 2009

2009-08-07T15:13:13Z

Rjt at 14:49, 7 August 2009

2009-08-07T14:49:55Z

Rjt: Add report mock ups

2009-08-07T14:49:35Z

Add report mock ups

Rjt at 14:04, 7 August 2009

2009-08-07T14:04:23Z

Rjt: GEP 014: Repository Research Support moved to GEPS 015: Repository Research Support: Benny got in with another GEPS 014

2009-08-06T17:33:51Z

GEP 014: Repository Research Support moved to GEPS 015: Repository Research Support: Benny got in with another GEPS 014

Rjt at 07:47, 4 August 2009

2009-08-04T07:47:51Z

← Older revision		Revision as of 02:37, 18 October 2011
Line 73:		Line 73:


−	[[Category:GEPS]]	+	[[Category:GEPS\|R]]

@@ Line 56: / Line 56: @@
 For instance:
-  '''key'''      '''value'''
+  '''key'''              '''value'''
   _r_:start_date 1841-06-06
   _r_:end_date   1841-06-07

← Older revision		Revision as of 15:45, 7 August 2009
Line 54:		Line 54:
	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.		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.

		+	For instance:
		+
		+	'''key''' '''value'''
		+	_r_:start_date 1841-06-06
		+	_r_:end_date 1841-06-07
		+	_r_:include True

	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.		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.

@@ Line 34: / Line 34: @@
 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.
+# ''dates'' - if a Source had a start and end date we could match this against the result of ''probably_alive''
 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.
@@ Line 43: / Line 46: @@
 == 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 altogether. Many Sources are not related to documentary evidence and you would not want them 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.
@@ Line 50: / Line 53: @@
 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.

@@ Line 16: / Line 16: @@
 = Reports =
 [[Image:Research_plan_mock.jpg]]
 [[Image:Individual_plan_mock.jpg]]
 = Implementation Issues =
 = Implementation Plan =
 = Testing =

← Older revision		Revision as of 14:49, 7 August 2009
Line 18:		Line 18:

	[[Image:Research_plan_mock.jpg]]		[[Image:Research_plan_mock.jpg]]
		+
		+	[[Individual_plan_mock.jpg]]

	= Implementation Issues =		= Implementation Issues =

← Older revision		Revision as of 14:04, 7 August 2009
Line 16:		Line 16:

	= Reports =		= Reports =
		+
		+	[[Image:Research_plan_mock.jpg]]

	= Implementation Issues =		= Implementation Issues =

@@ Line 27: / Line 27: @@
 = Related Work =
-Jerome's RepositoriesReport is an example what can be done at the moment. This GEP seeks to develop this idea further.
+Jerome's [[RepositoriesReport]] is an example what can be done at the moment. This GEP seeks to develop this idea further.
 [[Category:GEPS]]