JewishGen Cemetery Database - Database Field Description: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Warren Blatt, 3/2000, 6/2001, 6/2002, 3/2003, 4/3003. The JewishGen Cemetery Database is a two-table system: - Burial Table - Cemetery Table The Burial Table contains one row for each burial. The Cemetery Table contains one row for each cemetery. The relationship between the two tables is accomplished via a unique "CemeteryID" field for each cemetery. Both the Burial Table and Cemetery Table contain a CemeteryID column. In the Cemetery Table, this number is unique per row (per cemetery). Each row in the Burial Table will contain a CemeteryID field pointing at the correct cemetery in the Cemetery Table. CEMETERY TABLE: - CEMETERYID (CHAR 9) - CemeteryID (Key field - unique identifier) - CEMNAME (CHAR 50) - Cemetery Name (e.g. "Beth Israel Memorial Park") - LANDS_NAME (CHAR 50) - Landsmanshaft or Section Name (e.g. "First Pinsker Benevolent Society") Cemetery Location: - COUNTRY (CHAR 20) - Location Country (e.g. "USA" or "Poland") - CITY (CHAR 25) - Location City (e.g. "Chicago, IL" or "Pinsk") - STREET (CHAR 50) - Location Street Address - USBGN_CODE (CHAR 12) - USBGN Feature Code (geographical coordinates of cemetery) - REGION (CHAR 20) - ShtetlMaster Region (e.g. "Suwalk" or "Illinois") Landsmanshaft Location: - LANDS_CITY (CHAR 25) - Landsmanshaft City (e.g. "Pinsk") - LANDS_CTRY (CHAR 20) - Landsmanshaft Country (e.g. "Poland") - LANDS_USBG (CHAR 12) - Landsmanshaft USBGN Feature Code - LANDS_REGN (CHAR 20) - Landsmanshaft Region (e.g. "Suwalk") Donor Info: - DONOR_ID (INT) - Data Contributor - person who submitted data - JGFF ID - DONOR_NAME (CHAR 35) - Data Contributor - Full Name - DONOR_MAIL (CHAR 35) - Data Contributor - Email Address (Note that this last two field will disappear after CURE). Cemetery Description: - NUM_BURS (INT) - Number of Burials - NUM_PHOTOS (INT) - Number of Tombstone Photographs - COMMENTS (MEMO) - Description (address, contact information, etc.) - INSTR (MEMO) - Instructions to JOWBR Team Administrative: - DATE_DONOR (DATE) - Date Donor Agreement Received - DATE_DATA (DATE) - Data Data Received - DATA_LIVE (DATE) - Date Data was made live - ADMIN_NOTE (MEMO) - Administrator's Notes BURIAL TABLE: A - Plot / Location within Cemetery (plot / section / row / number) B - Surname C - Given Name(s) D - Place of Birth E - Date of Birth F - Place of Death G - Date of Death (English) H - Date of Death (Hebrew) I - Age at Death J - Date of Burial K - Hebrew Name L - Spouse's name M - Father's name N - Mother's name O - Other Surnames P - Photo Filename Q - Comments/Notes *R - CemeteryID (identifies which cemetery this burial is in) Note that virtually any of these fields may be blank for any particular record. The only mandatory field in both tables is the CemeteryID. Even "Surname" is not mandatory for every burial, since many pre-20th-century Jewish tombstones don't include a surname. Details on individual fields in the BURIAL TABLE: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ *** NOTE: These descriptions of the Burial Table fields are now out of date... the latest versions are at < http://www.jewishgen.org/databases/cemetery/JOWBRinstructions.htm >. A) Plot / Location within Cemetery -- Since each cemetery has their own unique way of identifying its burial plots, no attempt is going to be made to force an artifical system for this database. Therefore, this is a free-form text field. Each cemetery has its own style. Some possible examples: - "Row 2, Plot 4" - "Section IV, Lot 3, Number 21" - "Children's section, Grave 14B" - "Greenwoods, Block 2, Line 4, lot 16" This field may be left blank for some cemeteries, such as remnants of Eastern European cemeteries, where there is no apparent numbering/location plan. B) Surname -- The surname (last name) of the deceased, preferably in all capital letters. This field should contain the surname, the whole surname, and nothing but the surname. No other data should be included in the field, or the indexing and soundexing won't work. C) Given Names -- All given names (i.e. forenames, first/middle names) of the deceased. Some possible examples: - "Max" - "Chaya Sarah" D) Place of Birth -- E) Date of Birth -- Birthdate of the deceased. This data is not present on all tombstones. As with "Date of Death", use the format "dd-mmm-yyyy" (e.g. "12-Mar-1925"). Spell out the three-letter month abbreviation, and always use four-digit years. F) Place of Death -- G) Date of Death (English) -- The data of death, in the form "dd-mmm-yyyy" (e.g. "12-Mar-1925"). (There are problems using "dd/mm/yyyy" or "mm/dd/yyyy" formats, as you are never sure whether it is dd/mm or mm/dd). Therefore, spell out the three-letter abbreviation of the month, and always use four-digit years, to dispell ambiguity. If the tombstone contains only the year, then write only that four-digit year. If the tombstone contains only a Hebrew calendar date, convert it to the Julian calendar. H) Date of Death (Hebrew) -- I) Age at Death -- Some tombstones provide an age at death rather than a birthdate. If the age is expressed in years, then just put the number of years. For ages expressed in units other than years (i.e. days/weeks/months), write out the words, e.g. "6 months", or "6 mos.". J) Date of Burial -- The date of the actual burial, if provided in the burial records. Please use the format dd-mmm-yyyy, with three-letter English month abbreviation. K) Hebrew Name -- The transliteration of the deceased's Hebrew name from the tombstone. This may or may not include the patronymic. An example of a name without a patronymic is "Yehudah". Examples of names with patronymics are "Yehudah ben Tsvi", "Sara bat Alter", etc. We will not impose any transliteration standards. L) Spouse's Name -- Enter the Spouse's Full Name, in the format "SURNAME, GivenName(s)". In some modern cemeteries, the names of both spouses are engraved on the tombstone when the first one dies. In this case, or if the cemetery records show Living owners of plots, include a Burial record for the living individual and enter 'Living' in Comments/Notes (field Q). M) Father's name -- The deceased's father's secular name, in the form "Surname, GivenName". The surname can be omitted if unknown, or if it's the same as the deceased's. If present, the surname should be in all capital letters. If the surname is different from that of the deceased, it should also be added to the "Other Surnames" field, below. N) Mother's name -- The deceased's mother's secular name, in the form "Surname, GivenName". The surname can be omitted. If present, the surname should be in all capital letters. If the surname is different from that of the deceased, it should also be added to the "Other Surnames" field, below. O) Other Surnames -- This field contains any and all surnames *other* than the principal surname in the "Surname" field. For example, the father's surname if different that the primary surname in field 9, or the maiden name of the mother as in field 10. This field can hold as many extra names as you like, separated by spaces and slashs, in the format "SMITH / JONES / BROWN / MACNAB". This field will *not* appear on the results display -- it is an internal field used only so the Daitch-Mokotoff soundex searches will work. P) Photo Filename -- If a photograph of the tombstone accompanies this burial, this field should contain the filename of that photograph (i.e. a computer file name, ending with ".gif" or ".jpg"). If there's no tombstone photograph (which is the usual case), leave this field blank. Each cemetery can have its own naming convention for the photograph filenames, as long as each filename is unique within a cemetery. This field should contain only the filename, not the full pathname. Try to keep the filenames short, and they must end with ".gif" or ".jpg". Q) Comments/Notes -- Any miscellaneous notes about this burial, which don't neatly fit into any of the other fields. A free-form memo field, optional. This might include the entire tombstone inscription, a physical description of the tombstone and any pictoral engravings, notes on the condition of the tombstone, notes on language, the name/address of survivors listed in the cemetery office, name of funeral home, death certificate number, etc., etc. Every dataset has different data. *R) CemeteryID -- Mandatory field. This is the "SQL foreign key", which links the two tables together. It points at the appropriate row in the Cemetery Table, thereby identifying which cemetery this burial is in. This field is probably filled in by the database administrator after the database is recieved. NOTE: These above descriptions of the Burial Table fields are now out of date... the latest versions are at < http://www.jewishgen.org/databases/cemetery/JOWBRinstructions.htm >. Details on individual fields in the CEMETERY TABLE: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Cemetery Table contains one row (one record) for each cemetery. *) CemeteryID -- This is this table's primary key field -- the unique identifier for each cemetery. It is a simple monotonically increasing integer, with no external visibility or meaning to end users. Each row in the Burial Table also contains a CemeteryID field, to identify which Cemetery in the Cemetery Table that burial is in. This CemeteryID field provides the linkage between the two tables. *) Cemetery Name -- The formal name of the cemetery, such as "Woodland Cemetery" or "Beth David Memorial Park". For many East European cemeteries, the cemetery has no formal name, so this field can be left blank. Note that there might be multiple entries in the Cemetery Table with the same Cemetery Name, for cases of data from different burial societies / landsmanshaftn within the same large cemetery. (See next field). *) Landsmanshaft / Organization Section Name -- In many large North American Jewish cemeteries, sections are owned by landsmanshaftn (immigrant organizations), or other organizations. If the dataset being described by this record is for a landsmanshaft plot, or some other burial society / fraternal / synagogue organization, then put the name of the landsmanshaft or synagogue or organization here, such as: "First Pinsker Benevolent Society", "Chevra Ahavas Achim Anshe Kushnitz", "Independant Opoler Benevolent Association", "Erster Samborer Kranker Unterstitzung Verein", "Congregation Knesseth Israel", etc. This field should be left blank for smaller cemeteries, for those cemeteries not divided into smaller plots, and for those cemeteries without formal names. NOTES about cemetery sub-sections and CemeteryIDs: Each landsmanshaft or organizational plot within a larger cemetery usually gets its own unique CemeteryID number -- especially if the data for a landsmanshaft is coming from a separate source. On the other hand, if we get all the data for an entire large multi-organizational cemetery from a *single* source, we *could* assign all of them the same CemeteryID number. (But then we'd loose the place-of-origin links to the "All Country" databases for the component landsmanshaftn). The purpose of the CemeteryID field is to identify the *source* of the data -- where it came from, who created it, etc. If it all came from the same source (i.e. the same contributor), then they *could* all have the same CemeteryId... However, in this case, the "Location within Cemetery" field (Field #2, the "Plot Number" in the Burial Table) would then need to contain precise information for locating the grave within the larger cemetery, i.e. it might need to include the landsmanshaft name. It's somewhat flexible. But if the data for a sub-section of a cemetery is from a distinct source, or is for a particular landsmanshaft, then it should have it's own distinct CemeteryID. The next five fields descibe the LOCATION of the Cemetery: *) Location Country -- The name of the country where the cemetery is located, e.g. "USA", or "Poland", or "France". Use the modern name of the country, where the cemetery is located *today*. Follow the standard JGFF locality naming conventions: < http://www.jewishgen.org/jgff/jgff-faq.html#q4.2 >. *) Location City -- The name of the city where the cemetery is located, e.g. "Chicago, IL", "New Orleans, LA", "Pinsk", "Warszawa". For localities in the USA and Canada, follow the name of the city with a comma and the two-letter state/province postal abbreviation. For localities in Europe, use the *modern* town name. Follow the standard locality naming conventions used in the JGFF database: < http://www.jewishgen.org/jgff/jgff-faq.html#q4.2 >. *) Location Street Address -- The street address of the cemetery within the city, or other location description. *) USBGN Feature Code -- The U.S. Board on Geographic Names' numeric "Feature Code"; The geographical coordinates of the cemetery location. This is a future feature, and this column may be left blank for now. *) Region Code -- Number identifying what historical region this location is in, for the future ShtetlMaster project. See the regions in: < http://www.jewishgen.org/projects/desc/ShtetlMasterRegions.html > This is used only for localities in eastern and central Europe; For regions outside of eastern/central Europe, put a "0" here. If you can't determine which region a town is in, you could consult with the data's contributor, and if they're clueless, ask me (Warren), and I'll help figure it out. The next four fields describe the location of the Landsmanshaft Town of Origin, if this is a Landsmanshaft plot. *) Landsmanshaft town name / country / coordinates / region -- If this dataset is for a landsmanshaft organization (see #3 above), then this field should contain the name of the landsmanshaft's town of origin. Use the modern town and country name, following the standard JGFF locality naming conventions: < http://www.jewishgen.org/jgff/jgff-faq.html#q4.2 >. Examples (using the sample organizations in #3 above): "Pinsk, Belarus", "Kuznica, Poland", "Opole, Poland", "Sambor, Ukraine". Cemetery Description: *) Number of Burials -- Approximate number of burials in the cemetery. Should equal the number of rows in the BurialTable which have this CemeteryID. *) Number of Tombstone Photographs -- Leave blank or enter zero if there are no associated tombstone photographs for this cemetery. *) Contributor ID -- Identifier of the person who submitted this data. A JGFF Researcher Code Number. *) Contributor Name *) Contributor Email Address (Note that these last two fields will go away once CURE is implemented). *) Description -- A large free-form memo field, for other information about this dataset. Might include the cemetery office's address and phone number, the name of the book which provided the information (full bibliographic citation), the name(s) of the providers/transcribers of this data with contact info, notes on the history and condition of the cemetery, inclusive dates of the burials, name of caretaker, a URL with further information about the cemetery, etc., etc. [We might consider making some of this into separate fields, as long as they don't become sparse fields.] *) Instructions to JOWBR Team -- Memo field. Administrative Fields: *) Date Donor Agreement Received *) Data Data Received *) Date Data was made live *) Administrator's Notes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Just FYI... Fields used in IAJGS' Cemetery Project CD database: 1 - last name 2 - first and other names 3 - death date (use a 4-digit number for the year) 4 - place of death 5 - birth date (use a 4-digit number for the year) 6 - birth place 7 - cemetery 8 - location in cemetery 9 - father/mother 10 - informant/relation 11 - comments 12 - funeral home 13 - spouse ===================================================================== ===================================================================== Ideas for the DISPLAY of the cemetery data: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 11/29/00 There are three different display screens in the OWBR database: 1 - Search Results Summary (Table of matching burials) 2 - Detailed View (For one individual burial) 3 - Cemetery Information (Info about a cemetery) 1 - Search Results Summary: This is the table of burials matching the search criteria, in our usual format: a table of hits, in columns. We need to limit the number of columns displayed, so that it all fits on one line without horizontal scrolling. I suggest: Surname, Given Name(s), Date of Death (English), Age at Death, and Cemetery name/location/link. 2 - Detailed View: When you click on an individual in the above Search Results Summary, you will then get the "Detailed View" for that one individual, containing ALL of the 18 fields in the record, including the tombstone photograph (if any). This view could also perhaps include the entire "Cemetery Information" screen at the bottom. 3 - Cemetery Information: When you click on the name of the Cemetery in the far right column of the Search Results Summary, you will then get the "Cemetery Information" display, containing ALL of the information about the cemetery, stored in one row of the Cemetery Table. We could optionally also append this display to the "Detailed View" above, to save the user one mouse click, and have all information about a single burial displayable on one page. Note that he above Burial Table template has since been revised in the "official" OWBR version: . Since there are now *18* columns in the OWBR's Burial Table template, there are far too many fields for all of them to be displayed horizontally on one line of a results table, without scrolling. Most of these 18 fields are "sparse", i.e. they won't be filled in for the majority of records, therefore there's little point in having them displayed in the initial results table. There are several approaches we can take: Stack some of the fields vertically, or eliminate some of the fields from the initial "summary" display, and have them be accessible only in a separate "detailed" display for an individual record. The "detailed" display would also include the tombstone photograph, if one is attached. Each line of the initial "summary" display should indicate whether or not there is more information available in the "detailed" display, via the presence of a hyperlink. If there is no additional information, then no hyperlink would be created in the "summary" display. This is similar to the existing Bristol Cemetery Database, where there is an optional hyperlink when there is a corresponding tonstone photograph. The "Summary" Display -- would contain only a handful of important fields -- fields which would almost always be present; eliminating those sparse fields which we believe would be infrequently filled in. This list of fields should be kept short, so that everything fits on one line without any horizontal scrolling. These primary fields are: - 3: Surname - 4: Given Name(s) - 8: Date of Death (English) - 10: Age at Death - 00: Cemetery [link] The "Cemetery Link" cell would be a hyperlink, linking to full information about that particular cemetery (i.e. that row in the Cemetery Table). The visible text of the "Cemetery" cell should be taken from fields 2, 4 and 5 of the Cemetery Table: Cemetery Name, Location City, and Location Country. Or perhaps just the City and Country, separated by a comma. The "Surname" or "Given Name" column could be a hyperlink to the "detailed" display, as it is in the Bristol Cemetery database. In the "Detailed" display... Some ideas for field stacking: Stack fields which are sparse (i.e. infrequently used), and somewhat related to each other: - Fields 5, 6, 7, 11: Place of Birth, Date of Birth, Place of Death, Date of Burial - Fields 8, 9: Date of Death (English) and Date of Death (Hebrew) - Fields 13, 14, 15: Spouse's name, Father's name, Mother's name These stackings should perhaps NOT be separated by a horizontal rule (HTML
), as that takes up too much vertical space. - Fields 1, 16 and 17 (Burial Record ID, Other Surnames, and Photo Filename) are "non-displayed" fields, and are used only for internal purposes. The "detailed" display could also include the full "Cemetery Table" information for the cemetery. Note that the standard OWBR template defined at does NOT include the foreign key "CemeteryID" column, which links each burial record to its Cemetery (in the CemeteryTable). This column is supposed to be added by the OWBR Project Manager, before submitting to the database. ===================================================================== ===================================================================== Records with no surnames: ~~~~~~~~~~~~~~~~~~~~~~~~ Many records will lack a surname -- this is especially prevalent on pre-20th-century East European tombstones, which are entirely in Hebrew, and do not contain a surname. We need to be able to search for and display these records, so search criteria other than "Surname" needs to be implemented. We can implement searches on "Town" or "Given Name", (in addition to the "Global Text Search" option)... but these will likely result in TOO many records being matched, and we do not want to return more than a certain percentage of the database, for security / data mining purposes. For example, a search for "Town = New York" or for "Given Name = Abraham" would return thousands of records -- which we don't want to happen. I think that a special interface will need to be developed for Given Name or Town-based searches, which forcibly limits the scope of the search to a specific town or cemetery. For example, they could do a search for all records with the given name "Abraham" (in either the 'Given Name' or 'Father's Given Name' field) WITHIN a specific town or cemetery. That would sufficiently limit the scope of the matched and returned results. (Of course, if Town = "New York", it's too much... that's why I suggested it might also be limited to a particular cemetery... it really depends upon the number of records). Other filters could also be implemented to help users limit the number of matches: Date of Death (e.g. limit it to say a 10-year time frame), or other criteria. The searches for Given Name be selectable as either Exact-Spelling or Soundex based... (or even tied to Jerry Esterson's Given Names Database in the distant future, in some limited way...) There are lots of things to think about here... all manageable... and can be developed and refined over time. 6/10/2002 ===================================================================== ===================================================================== Warren Warren Blatt JewishGen Webmaster Boston, MA Last updated 4/8/2003