• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Want to get organized in 2022? Let Dokkio put your cloud files (Drive, Dropbox, and Slack and Gmail attachments) and documents (Google Docs, Sheets, and Notion) in order. Try Dokkio (from the makers of PBworks) for free. Available on the web, Mac, and Windows.



Page history last edited by PBworks 16 years, 4 months ago

This page is for discussing the fields which might be good in databases for helping after an upheaval. For the moment, it is also discussing more general points in respect of database set-up and operation. (Skip down to "Notes specific to fields" if that is the area of your interest.)

Looking at the excellent Gulf Coast News database, it would seem that some mechanism is needed to consolidate records applying to a single individual. For example, there could be a "Looking for J Smith" record AND a "J Smith alive and well and in Arkansas" record. Somehow, other than by repeated re-searches, the person looking should be able to hear of the "alive and well" entry. This could be quite a thorny problem.

For a taste of the scope of the problem, call up a page of the Gulf Coast News database, search on one surname, click on the "First Name" column heading to sort the records by first name... then scan the list.

To get the "best" design, you need to ask yourself what need are you addressing. The database could be....

a) To announce someone is alive and well.

b) To seek information on someone.

Perhaps the data should be kept two databases, each optimised for it's role.... but then how do you manage the issues of "found" people not being struck from the "missing" list, and of notifying people who are looking when people are found?

Although it plays havoc with programmatic matching of records, for human scanning of the lists, entries like "Smith, Bill and Mary and kids" are great for people looking for them, or for OTHER Bills and Marys. Maybe there's a way to list records both ways?

At the least, some mechanism is needed for removing "We are looking for..." when the person is found. But how do you protect the database against the scum who would remove things "for fun"?

I understand that some problems have arisen even in the region hit by Katrina with entering the names of people. Not everyone is named Smith. (In Katrina there are many names of French origen.) What happens if the next upheaval is in an area which does not routinely use a Latin alphabet?

Notes Specific to Fields

I think we might want to get help from the family history people with this. They, after all, have been working on finding "needles" in "haystacks" of names and personal information.

If you go to WorldConnect's site, you can see one of their seach engines. Is this sort of data too complicated for use in an upheaval?

The Red Cross/Red Crescent has a major effort underway. Their answer does not attempt to break peoples' first and family names into separate fields. I'm not sure why. Their search is also very literal. If you search for Andrew Dennis, or A Dennis, you won't be told of the A C Dennis who IS in the database. You can either argue that the Red Cross/ Red Crescent are extremely experience in handling disasters, and must have good reasons for setting things up this way, or you can say that they are not subject to the competitive pressures of, say, World Connect, and have not produced the best possible search.

Please: I'm not out to denigrate anyone's effort... but "our" "best" answer must make choices, and looking at what has been done elsewhere may be food for thought.

By the way: Search World Connect for:

Surname: Boyd

Given name: Thomas Lunham

Click through to the "tkb-wldc-tlb" database, and at the top of that page you'll see an eddress for me... but it is in a form that cannot be harvested programmatically by spam engines and the sort of low-lifes which could abuse a post upheaval database.

What do you think? I think that "Father's Name"/ "Mother's Name"/ "Spouse's name" (where known) may be quite good fields to help database users to know if the Joe Smith they've found in the database is the Joe Smith they want. The information should be known to most who need to know, and is often available(?) from other sources... putting it in the upheaval database will(?) do little to compromise individual's privacy?

I think that putting date of birth in the database may be unwise... but YEAR of birth alone should serve to help confirm identities without giving too much data away?

Should there be fields to indicate the source of the data entries? Where individuals put their own data in directly, there's little benefit... but perhaps the system will grow to the point that trained operators with laptops will be deployed by, say, the state police, and even people passing through an aid centre can be logged. In such a case, a primary field designating, say, the Louisianna State Police could be present, and a secondary field, organised as that agency saw fit, could be used to record details of the circumstances of a whole batch of records, e.g. "Subject was at Aid Station 4, Biloxi, 1 September".

The same fields could be used to help soften the blow of "This person has died." Instead of that being immdeidately visible in the database, the "Source of Data" fields could connect people to the agencies handling the dissemination of that information in the most humane way possible.

(Click here to go to discussion's home page)

Comments (0)

You don't have permission to comment on this page.