Spring2004 M5 - Add search functions and automatically gather genealogical information

Requirements

1. Extend the graphical user interface you built for M4 to enable a user to search for individuals who meet specified search criteria. Search criteria may include any of the kinds of information that can be entered interactively about individuals via your M2 and M4 interfaces, excluding notes. The simplest way to do this is probably to use something that looks like your data entry form as a search specification form. For now, a "match" is defined as an individual whose stored information exactly matches the search criteria.
2. Searches of genealogy data often return multiple results since, for example, names definitely aren't unique. You must figure out some way to present multiple matches in a way that will be useful to a user of your system.
3. Exact matching as specified in requirement 1 is actually not very useful in working with genealogy data. Issues like incomplete of information and spelling variations make really useful matching more complex than simple string matching. Spellings that are close can be considered a possible match, though with less certainty than exact matches. An initial and a first name that starts with that initial are a likely match. Names with and without middle initials can match one another. Differing first names do not eliminate the possibility of a match, since immigrants to the US often became know by English versions of their names (Johan -> John, Isabella -> Elizabeth). Birth and death dates can give clues about matches, but different genealogy sources may give varying dates and places for these events. Exact matches of birth and death info can strengthen the probability of a match. Dates that vary by decades or centuries are an easy way to eliminate the possibility of a match, but small variations are common in what should be considered matching records. So, you must implement an inexact matching function that ranks possible matches by how "close" they are to the information specified in the search template. The design of this matching algorithm is up to you. Be creative!

1. There is a great deal of genealogy information available on the Web, much of it in freely accessible databases. In this part of your project, you must provide a user with the capability to search for genealogy information on the web. Search criteria should be specified in the same way as for local searches. It also should be possible to use the information stored in a particular Person object as search criteria.
2. Your web search feature must be able to get data from at least two different web sites.
   • these websites may be any 2 sites of your choosing, please provide your ta with the names & addresses of the websites in a readme file. Here's a starting point, you're free to find and use any other sites as well: http://genealogy.about.com/cs/free_genealogy/a/free_sites.htm
3. Candidate matches must be ranked as they are for local searches and presented to the user in an appropriate way.
4. The user must be provided with a way to indicate that data from the results of a web search should be added to the information about an existing Person in a Genealogy or that it should be used to create a new Person in a Genealogy.

Turn-in

Grading

Grading

• 5% Updated ECoDE CRC CARDS representing a good behavior analysis: Reasonable names, understandable and clearly defined responsibilities, useful comments.
• 5% Updated ECoDE SCENARIOS (About Scenarios) described from specific examples that touch on every major function in the system from the user's point of view.
  • Clear descriptions for each scenario are written for a non-computer-science audience.
  • Good assignment of responsibilities impelemented by CRC Cards that satisfy each scenario.
• 10% Updated UML CLASS DIAGRAM reflecting your analysis and design.
  • A quality design covering all the features of the project.
  • Detailed and understandable names and comments.
  • All the classes are connected with responsibilities.
• 5% Updated TEST PLAN (About Test Plans) with clear linkages between scenarios and test cases and expected results. We should be able to verify that your test plan covers all of the system requirements.
• 5% Well-documented & good style source code
  • Reuse of existing code
  • Effective Commenting
• 15% Quality of the design and implementation
  • Code matched design
  • Usable interface
  • The users (your TA) like it.
• 55% Working system:
  • 25% Local searching
    • 12% Provide a search interface and find an exact match to search criteria
    • 3% Support display of multiple individuals that match the search criteria
    • 10% Implement inexact matching and present multiple results ordered by "quality" of probable match (you must implement a reasonable matching algorithm to get full credit)
    • 2% extra credit for including Soundex codes as part of your inexact matching algorithm
  • 25% Web searching
    • 2% Initiate web search from search interface
    • 3% Initiate web search by using data from a Person
    • 10% Ability to obtain data from two different web sites
    • 10% Abiltiy to update an existing Person or create a new Person from web data
  • 5% SUnit tests which cover all non-ui classes and methods

Links to this Page

• Spring 2004 Project Milestones last edited on 17 February 2004 at 11:50 am by lawn-199-77-204-204.lawn.gatech.edu
• Team Name Pending Cases Page last edited on 29 April 2004 at 12:00 am by r70h21.res.gatech.edu
• Milestone 5 - Searching and automatic information gathering last edited on 30 April 2004 at 3:41 am by r75h82.res.gatech.edu