Archive for February, 2012

February 29, 2012

Wordless Wednesday – What You May Want To Do on the iPhone? — #Mobile, #Technology

by C. Michael Eliasz-Solomon

Here’s an interesting App (Flipboard – don’t forget to add this blog to your Flipboard pages !!)

Also, I know there are some tech types amongst the readers and those who use Big Tech in their genealogy. Try this URL (web link) to Tech Visualizer

– Stanczyk

February 28, 2012

Dying For Diacriticals … Beyond ASCII — #HowTo, #Genealogy, #Polish

by C. Michael Eliasz-Solomon

Stanczyk mused recently upon a few of the NAMEs in my genealogy:

Bębel, Elijasz, Guła, Leszczyński, Kędzierski, Wątroba, Wleciał, Biechów, Pacanów, Żabiec

If you want to write Elijasz (or any of its variants) you are golden. But each of the other names require a diacritic (aka diacritical mark). Early on, I had to drop the diacritics, because I did not have computer software to generate these characters (aka glyphs). So my genealogy research and my family tree were recorded in ASCII characters. For the most part that is not a concern unless you are like John Rys and trying to find all of the possibly ways your Slavic name can be spelled/misspelled/transliterated and eventually recorded in some document and/or database that you will need to search for. Then the import becomes very clear. Also letters with an accent character (aka diacritic) sort differently than  letters without the diacritic mark. For years, I thought Żabiec was not in a particular Gazetteer I use, until I realized there was a dot above the Z and the dotted-Z named villages came after all of the plain Z (no dot) villages and there was Żabiec many pages later! The dot was not recorded in the Ship Manifest, nor in a Declaration of Intent document. So I might not have found the parish so easily that Żabiec belongs to. I hope you are beginning to see the import of recording diacritics in your family tree.


The rest of my article today teaches you how to do this. Mostly we are in a browser, surfing the ‘net, in all its www glory. After my “liberal indoctrination” (aka #RootsTech 2012), I have switched browsers to Google’s Chrome (from Mozilla Firefox) browser. Now I did this to await the promised “microdata” technology that will improve my genealogical search experience.  I am still waiting,  Mr Google !!!   But while I am waiting, I did find a new browser extension that I am rather fond of that solves my diacritical problem: Virtual Keyboard Interface 1.45. I just double-click in a text field and a keyboard pops-up:

Just double-click on a text field, say at . Notice the virtual keyboard has a drop down (see “Polski“), so I could have picked Русский (for Russian) if I was entering Cyrillic characters into my family tree.

But I want to keep using my browser …            OK!  Now I used to prepare an MS Word document or maybe a Wordpad document with just the diacriticals I need (say Polish, Russian, and Hebrew) then I can cut & paste them from that editor into my browser or computer application as needed — a bit tedious and how did I create those diacritical characters anyway?

I use  Character Map in Windows and Character Palette -or- Keyboard Viewer  on the MAC:

Now if I use one of these Apps, then I can forgo the Wordpad document  ( of special chars. ) altogether and just copy / paste from these to generate my diacritical characters.

What I would like to see from web 2.0 pages and websites is what Logan Kleinwaks did on his WONDERFUL website. Give us a keyboard widget like Logan’s, please ! What does a near perfect solution look like …

Logan has thoughtfully provided ENglish, HEbrew, POlish, HUngarian, ROmanian, DEutsche (German),  Slavic, and RUssian characters. Why is it only nearly perfect? Logan, may I please have a SHIFT (CAPITAL) key on the BKSP / ENTER line for uppercase characters? That’s it [I know it is probably a tedious bit of work to this].

Beyond ASCII ?

The title said  beyond Ascii. So is everything we have spoken about. Ascii is a standard that is essentially a typewriter keyboard,  plus the extra keys (ex. Backspace, Enter, Ctrl-F, etc.) that do special things on a computer. So what is beyond Ascii? Hebrew characters (), Chinese/Japanese  glyphs (串), Cyrillic (Я), Polish slashed-L (Ł), or Dingbats (❦ – Floral Heart). You can now enter of these beyond ascii characters (UNICODE)  in any program with the above suggestions.

Programmer Jargon – others  proceed with caution …

The above are all UNICODE character sets.  UTF-8 can encode all of the UNICODE characters (1.1 Million so far) in nice and easy 8bit bytes (called octets — this is why UTF-8 is not concerned with big/little endianess). In fact, UTF-8‘s first 128 characters is an exact 1:1 mapping of ASCII making ascii a valid UNICODE characters set. In fact, more than half of all web pages out on the WWW (‘Net) are encoded with UTF-8. Makes sense that our gedcom files are too! In fact UTF-8 can have that byte-order-mark (BOM) at the front of our gedcom or not and it is still UTF-8. In fact the UTF-8 standard prefers there be no byte order mark [see Chapter 2 of UNICODE] at the beginning of a file. So please FamilySearch remove the BOM from the GEDCOM standard.

If FamilySearch properly defines the newline character in the gedcom grammar [see Chapter 5, specifically 5.8 of UNICODE] then there is nothing in the HEAD tag that would be unreadable to a program written in say Java (which is UTF-16 capable to represent any character U+0000 to U+FFFF) unless there is an invalid character which then makes the gedcom invalid. Every character in the HEAD tag is actually defined within 8bit ascii which can be read by UTF-8 and since UTF-8 can read all UNICODE encodings you could use any computer language that is at least UTF-8  compliant to read/parse the HEAD tag (which has the CHAR tag and its value that defines the character set). Everything in the HEAD tag, with the exception of the BOM is within the 8bit  ascii character set. Using UTF-8 as a default encoding to read the HEAD will work even if there is a BOM.

February 27, 2012

#PA #Genealogy – Access To Vital Statistics — Public Access, Privacy Law, PA Act 110, SB 361

by C. Michael Eliasz-Solomon

PA Act 110 – Public Records (formerly known as Senate Bill 361)

This bill amends the Act of June 29, 1953 (P.L. 304, No. 66), known as the Vital Statistics Law of 1953, to provide for public access to certain birth and death certificates after a fixed amount of time has passed. This legislation provides that such documents become public records 105 years after the date of birth or 50 years after the date of death.

This is a mixed bag, but at least its consistent. I wish it was 72 years  (like the census) instead of 105. Also the 50 years after death is way too long. Dead is dead. Maybe you could make a case for 5-10 years. By doing greater than 30-35 years you are forcing genealogy research to skip generations since the current generation would die before gaining access. Genealogists will have to will research plans to children in PA.

The indexes (I hate the word indices) are here: Birth Index (1906 — so far that’s it) | Death Index (1906-1961).   By the way, you will need the American Soundex of the last name as this is how the records are sorted:  American Soundex of Surname, followed by alphabetical on FirstName. Use Steve Morse’s Soundex One-Step page.

February 26, 2012

Responses – Exploring Gedcom — #Technology, #Genealogy

by C. Michael Eliasz-Solomon

Mail Room

The mailroom received three emails / comments from the “Exploring Gedcom” article.

Tamura Jones (Modern Software Experience), Louis Kessler (,  and  Stan Mitchell ( / ezGED Viewer).

Good solid GEDCOM experts all (unlike this jester who is only a journeyman apprentice to these fine men) and as you can see they are also bloggers themselves.

Here’s my summation:

  1.  WHITESPACE – All three disputed the whitespace proposal. Even though it was an optional feature accessed via on/off check-box — I yield to what I see as rising tide that I cannot swim against. I assume that XML will also be treated as badly by all for EXACTLY the same reasons — too verbose and makes for a poor data transfer mechanism because of  the bloat.
  2. UNICODE – Tamura pointed out that it was in the 5.5.1 standard. I said maybe so, but hardly implemented, needs to be mandatory. I also hate the two-hexabyte binary debris that makes an otherwise TEXT file into a partial binary file. Tamura points out that this byte-order indicator is commonly hidden (I am old school and use vi — nothing hidden) by PC editors. Besides, the HEAD tag CHAR sub-tag could be used to determine character set and keep file textual. Tamura said that would be a catch-22 (since you do not know the files encoding). Tamura points out that everyone does as I suppose and use ASCII (or UTF-16LE or UTF-16BE) to determine encoding.  Documentation needs to be updated too. Really almost no support for generating UNICODE chars in app — should be required, otherwise data entry is limited to clever users (i.e. tech-types or their friends).
  3. DATES – nobody liked DATES (or NAMES) as a zero level. I can live without dates, as I can always create a dimension with every possible date to slice & dice my genealogy facts. Names was also not part of my vision, other than I want a bunch of AKA names for an INDI.
  4. LOCN – Everyone agreed, the PLAC tag did provide a minimalist capability. 2/3 saw a good reason to have LOCN at the zero level, as I proposed. Let’s hope this feature gets in.  We may need to keep PLAC tag for backwards compatibility until all gedcoms have been converted.
  5. EVENTS as a zero level tag seemed to interest people, as MULTI-PERSON events (aka EVENT_TYPE_FAMILY) is NOT adequately dealt with in GEDCOM 5.5.1. I also think people want to standardize these events as much as possible and leave open the ability for a user to add their own events. EVENTS was also related to GROUPS which people seem to want in some fashion. The need to analyze a social network needs to have some better GROUP/EVENT/ROLE visibility that the current standard provides. I think we really we need EVENT and EVENT_TYPE tags to keep from adding a new GEDCOM tag every time someone says we need a new event (BIRT | CHR | BAPM | BARM | BASM | BLES | SLGC). All TYPE tags should be from a standard list that a user can add to. The list should be allowed to be localized (into a native langauge). This keeps parsing to a minimal while allowing for expansion. OLD tags are kept for backwards compatibility until a gedcom is upgraded to a later version. I think we also need a ROLE_TYPE to replace ROLE_IN_EVENT and add more standard roles, (i.e. GodMother, GodFather, Witness, Neighbor, MidWife, Rabbi, Brother, Sister, Aunt, Uncle, Cousin, Border, etc.) and this should also be localized and user upgradeable. Keep  EVENT_TYPE_FAMILY and EVENT_TYPE_INDIVIDUAL for backwards compatibility.
  6. DOCUMENTS (deferred) – The case was not made nor was the concept adequately explained. To Stanczyk this is related to multimedia and is for making it possible to locate all documents of a certain type (i.e.  Declaration of Intent) with its date and location and a locator to the multimedia  representation and pull these documents out in their own right regardless of the individual or family or group.
  7. GROUPS (deferred) – Some interest in defining a non-family group (ex. military unit, college fraternity/sororiety, religious society, etc.). These groups would be interesting in their own right to study. At RootsTech 2012, this seemed to be a novel idea that had a positive feel to the audience.

GROUPS is not intended for a non-traditional family unit which needs some thought and design in this Modern Family World.

Tamura chided me that many of my “wants” are a part of an offshoot of GEDCOM called GEDCOM 5.5EL (Extended Location GEDCOM derived from version 5.5). The only difference is  I want to get rid of the need for _LOC (a custom tag under GEDCOM definition) and use LOCN instead. Also I would want their undefined tag called NAMC (possibly renamed NAMA for NAMe Alias or NAMe Altertnate) be 0:M; meaning that you can have zero, one or many alternate/alias names for this LOCN (or INDI why not?).

Also the NAMC (or NAMA) should have a subtype FONE and FONETYPE (soundex, DM, Bieder-Morse, etc.) to aid in advanced searches or Google searches. But this is the argument for NAMES at zero level. The last names are usually where the  soundex/phonetic matching need to be stored. We do not need to repeat this data for each individual (INDI) just for each unique last name or alternate name. These things get created in Surname Index pages – how much easier if the NAMES (re surnames and alternate surname) had a zero level with the FONE, FONETYPE and the INDI had an XREF pointing to each NAME/NAME ALTERNATE s/he had used during their life. One might even hope that the zero level name had an XREF to each INDI too. If I were the Data Architect for GEDCOM, I have a zero level NAMES (for SURNAMES) and their soundex/phonetic codes, plus XREFs back and forth to INDI.

I need to cut this response short, but a great thanks to all who read the article and the above three for improving my thoughts by their comments/emails.

P.S. – If you follow the GEDCM 5.5EL link, you will notice they show their gedcom indented and then go on to say about the whitespace:

” improves readability … should (and will) not be performed at real Gedcom-output.”

My sentiments exactly. Sometimes you just need to show the gedcom (and indentation improves the presentation and understanding). I too never intended it to be processed into the gedcom output/exported to a file for transport (just for my own personal examination or writing purposes). However, I have capitulated on whitespace — so please no more email on whitespace and bloat.

February 24, 2012

London, England – WDYTYA — #Polish, #Genealogy, #TV,#Show

by C. Michael Eliasz-Solomon

At the London “Who Do YOU Think You Are?“, the largest genealogy event in the English-speaking world will be held this Friday, Saturday, and Sunday in London, England @ a three-day expo at the Olympia Exhibition Hall (February 24-26, 2012).

Between February 24 and 26 the Kresy-Siberia Foundation will have a stand at the “Who Do You Think You Are?” — the world’s biggest family history show.

Tens of thousands of Poles imprisoned in Russian labour camps or “gulags” across the far reaches of Siberia between 1940 and 1941 were freed in 1941, when Russia decided to become an ally of Great Britain in 1941 the prisoners were freed to form the Polish Second Corps — who fought so heroically in North Africa and the Italian campaign of 1943-44, (i.e. battle of Monte Cassino).

Many of these men settled in and adopted as their home, the communities in Bath, Trowbridge and Bristol. Perhaps this event will lead to new connections between these displaced families and their ancestors/descendants in other parts of the world.

Stanczyk wishes to note that the Polish Second Corps included: Wojtek soldier bear – mascot of 22nd Artillery Supply Company, who I have written about a few times.


February 23, 2012

Meme: Exploring GEDCOM – Gedcom Lines — #Genealogy, #Technology, #Mashup

by C. Michael Eliasz-Solomon

Stanczyk wants to introduce a new meme,  “Exploring GEDCOM“.   I was musing upon why is the state of a GEDCOM standard,  … so CHAOTIC?    GEDCOM has languished for about a decade and a half now with no new standard  – hence my article, “Is GEDCOM dead?” (2/5/2012) .  I was left in a perplexed state after RootsTech 2012. Why is FamilySearch working on a “standard” in a vacuum? Why is there so little communication with the existing software vendors — the purveyors of GEDCOM and why do the end users have no voice into what is needed in a GEDCOM standard?

So I decided that GEDCOM needed an Evangelist. I believe there are already a plethora of GEDCOM Evangelists so perhaps I will just add to the milieu (or is it the meme). To be frank, most GEDCOM Evangelists are really GEDCOM complainers — nay, I think we are all complainers, because there are no GEDCOM complimenters, not even amongst the GEDCOM purveyors. Even FamilySearch, which “owns” GEDCOM (how can that be a standard) wants to make their latest effort (GEDCOMX) a “clean sheet” project. No backwards compatibility even!

Is GEDCOM  just an ugly baby whose parentage is in doubt?

So this meme is on Exploring GEDCOM. What is it? How can it be improved? What should a TRUE gedcom  standard include?  I’ll probably write once to three or four times a month on this meme until I have exhausted myself on this topic. My goal is ultimately, is to get this to be a part of RootsTech and to be an OPEN STANDARD with an open, transparent definition and process for change, which I hope to have tied to RootsTech attendees voting on this, possibly via the RootsTech App.

Allow non-attendees to vote if they register who they are and their role: genealogist, technologist, software vendor, etc. and why they want to be a voter. I think conference attendees (genealogists, technologist, or vendor-of-any-kind, organizer) get an automatic vote, prior attendees get a vote, gedcom software vendors get a vote. All prior voters get to vote in all future votes on the open standard (as long as their email address works or when it is corrected again). OPEN STANDARD means that all stakeholders need to have an opportunity to influence the standard.

Let me start the Meme by revisiting graphic syntax diagrams  …

I started with this railroad track (2/16/2012) to define a gedcom file. Our discussion will focus upon gedcom v5.5.1 and launch from that rocket pad into some far flung future gedcom feature(s). This diagram was derived from the standard in PDF form. I have attempted to make the standard more “grammatical” and formularize/define ambiguities to my genealogical/technological world view. We see a HEAD tag, a TRLR tag and an option SUBN tag with a whole bunch of “gedcom lines”.

Gedcom Line

A V5.5.1 Gedcom Line

This is what a gedcom line looks like. I have added a wish for optional whitespace at the beginning of a line. That is my first proposal. The number at the beginning of each line is meant to be “an outline level”. So I wanted the option of outputting lines with leading blanks corresponding to the level of indentation appropriate for the outline level — to aid readability of seeing what inner outline indentations go  with which outermost level. Make the whitespace a checkbox on export (directed at you software vendor guys) and default it to off.

We see that a gedcom line at its (current) core describes: families, individuals, notes, repositories, sources, submitters & their multimedia (digital documents, notes, memories, etc.). This is still a very high level discussion. We have only spoken of 3 of the 136 tags. But already this jester has a suggestion/complaint.  Let me defer a discussion of Multimedia_Records to its own article as this requires many words, a lot of which are jargon. The complaint – we need more zero level tags!

So deferring multimedia, we have six types of records. A software vendor might think six different tables (or objects) that need to be described and stored as we “parse” each gedcom line in the file that stores our family tree. Do not lose sight that these files are family trees of some researcher — not abstract or theoretical data. These are research from current or prior genealogists and they need to be preserved …  without loss.

At its inner core is a set of individuals (INDI tag). I once wrote a PERL script to pull out all individuals with their vital data (B/M/D). Very easy thing to do. I mention this now to illustrate that these compact files are at the intersection of genealogy and technology. These gedcom files are emblematic of the technology / genealogy mashup that is RootsTech! They are also the way we can interface our genealogies with other non-family tree tools to do additional things. Lets call those gedcom ADD-ONS (or PLUG-INS or APPs) that,  I am hopeful, that with a standard API to be able pull this info out, just like my PERL script pulled out the individuals.  That is the essence of an INDIVIDUAL gedcom record.

There are also FAMILY gedcom records that are defined by FAM,  FAMC,  FAMS and the temple ordinance (i.e. LDS) FAMF tags. Likewise, we have NOTE (NOTE), SUBMITTER (SUBM),  and REPOSITORY (REPO)/SOURCE (SOUR) records too. I mentioned the FAMC/FAMS tags in addition to FAM which really equates to the FAMILY-RECORD, in order to point out that an individual is part of two families. S/He is a part of a family where they are a child(FAMC) and they are also part of the family where they are a parent (re SPOUSE, hence FAMS). This is evident when you realize that we are speaking of a family tree and that a tree really goes forward and backward linking the present to the past (and logically,  vice-versa).

What’s Missing? – A Proposal (the first of many)

I am still ignoring MULTIMEDIA — so that is not it. If we believe in Jay Verkler‘s RootsTech 2012 vision for genealogy, then we need to conform (i.e. standardize):  Dates, Locations, Names. I would also add: Events, Documents,  and possibly Groups. So that is six more zero level RECORDS.

DATES I assume need to be standardized because of the many problems: missing date, partial date, estimated date, various calendars, etc.

NAMES are also a problem area. For example, how do I record my ancestor’s name? Do I conform his name to ENGLISH (i.e. does Piotr become Peter)? Should I record it in his context, (i.e. Pawel for Paul)? Should I record it in the language of the record (my ancestors come in Latin (Paulus), Polish, and Russian. Oh, some of those names do not translate to the other language, so we have adopted names/name changes/nicknames. Latin alphabet versus Cyrillic characters versus Hebrew characters or even just recording diacritical letters like slashed-l (ł ).

UNICODE support is a MUST in any new standard.

We also need Locations, Events, Documents, and Groups as zero level “records”, so that we can pull those out of the file, just as I pulled Individuals out of the file. Locations (i.e. Biechów, Busko, Kielce, Poland) that is the administrative hierarchy of one of my ancestral villages. Of course, it changed over time or by whoever occupied Poland (or should I view it as Congress Poland/Vistulaland as a part of the Russian Empire’s many gubernias). Clearly locales have a time component.

I deferred MULTIMEDIA because it is technical and also because I want to make the case that we need EVENTS and/or DOCUMENTS instead and that MULTIMEDIA are just NOTES that are not textual and often this is congruent with the fact that this digital media is a representation of some document(s) that documented an event. I also propose GROUPS as a record because people want to record connections to MILITARY units, CHURCH SOCIETIES,  SCHOOLS, BUSINESSES/ORGANIZATIONS, REUNIONS, or GOVERNMENTAL/HISTORICAL units that may be of a historical or a strong emphasis within a family history. I think the GROUPS could all be user-defined, with maybe a conformed group-type (i.e. military, religious, government, historical, etc.). This does not feel like the same level of importance as the others: Names, Dates, Locations, Events or Documents.

Summary of Proposed GEDCOM Enhancements

(excluding MULTIMEDIA)
  1. whitespace – for readability
  2. UNICODE support so proper nouns can be recorded in their context with diacriticals or character sets (that are not Latin).
  3. New Zero Level TAGS:  NAME, DATE (not mine, but Jay Verkler’s emphasis)
  4. New Zero TAGS (that Stanczyk wants):  EVNT,  DOCS, &  LOCN (Jay also wanted locn).
  5. Possibly GRUP – to support development of non-familial group memberships in trees

The new zero level tags are to support future CONFORMATION (standardization) efforts and also are the most likely to be sought after via any future API for enhanced analyses or specialized output in reports/charts.

Stanczyk views the Zero Level TAGs as possible dimensions for slicing-dicing a genealogy cube, what Data Architects see as OLAP analysis/reporting   sorry that jargon just slipped out.

The vision is cross family tree bumping or cross website bumping of gedcom data against databases to accomplish new and novel approaches to searching, merging or analyzing. This genealogy data could also be of use to historians or scientists as new sources of data to be mined for their research.

That’s the gedcom exploration for today!



Please read the comments too. Apparently, I was wrong. There is a GEDCOM Evangelist who is not a gedcom complainer.

February 22, 2012

Wordless Wednesday – What Do You Do On Your iPhone? — #Mobile, #Technology

by C. Michael Eliasz-Solomon

Here’s what I do …

Home - 1st Screen -- most used Apps

2nd Screen - Social, Genealogy, & Informed

3rd Screen - Some Tools & Some Classes

There’s still 3 more screens and part of another that I’ll spare you from …

What do you do on your iPhone?


February 21, 2012

Pączki Day – A Fat Tuesday Remembrance — #Polish, #Culture

by C. Michael Eliasz-Solomon

Pączki Day – In the Detroit area suburbs, we always waited for Fat Tuesday to come around. Because, on the last day of Mardis Gras (Fat Tuesday) we would queue up in long lines — typically at an Oaza Bakery to buy our Pączki Donuts.

Now it has been over two decades since then and we do not have any Oaza Bakeries out here on the East Coast and there are few and far between Polish bakeries/delis of any kind around and none near where I live. I used to buy a few dozen Pączki Donuts and bring them into work to introduce the non-Poles to some Polish culture. Always a hit!


Tomorrow, Ash Wednesday,  is the beginning of the austere Lenten season. The forty day season of preparation celebrating the arrival of God’s Good News & Holy Spirit  into our midst that culminates in Easter. Alleluia !


I miss the Pączki Donuts. Fastnachts are just not the same. One year, I thought I would make Pączki Donuts for the family, so I gathered an authentic,  “Old Busia”, recipe and bought a fryer and made my dough for the Pączki.   I picked out my favorite fruit fillings and fried my little masterpieces and sprinkled the warm donuts with powdered sugar.  These were passable  substitutes for the beloved Polish culture that I had left behind in MI. For a few years I carried proudly my scar of an oil burn caused by one of my over zealous little Pączki helpers. The scar has long since disappeared, but the memory remains.


Have A Blessedly Happy Lenten Season Everyone!

February 19, 2012

Meme: #RootsTech — #Genealogy, #Technology

by C. Michael Eliasz-Solomon

A while ago, Stanczyk bemoaned iOS5. Therefore, I owe it an update …

  • Portable Genealogy is sound – Ancestry App better than ever
  • The Camera App in iOS5 does have a zoom. In fact if you use the familiar “pinch-gesture” you can zoom in/out and the old zoom slider appears too. Also you can use the Volume Up button (on the side of the phone to take a picture — helpful when the camera is rotated.
  • Just having the iPhone was very useful during the #RootsTech conference as my note taking device. Until iPad2(3) arrived(s) and it has both WiFi/G3 (LTE) I would have been without blogging capabilities in the Salt Palace convention center when its WiFi would go down. I utilized the #RootsTech App (for iPhone & there was one for Android too).
  • In the library it was my digital  camera.
  • In fact the ImageToText App came in handy to OCR an image of text for me
  • I used the Ancestry App to enter the transcribed text from the microfilm images right into the evidence (note area) of the app of an indivividual and attached the iPhone picture too.
  • In one case, I was able to get an immediate shaky leaf as a result of my data entry — much to my disbelief (and it was correct). So I could do an immediate on-site analysis and do further microfilm searching as a result.
  • I used the Bump App to swap contact info with one genealogist. I cannot wait until all genealogists become mobile-enabled and lose my business cards altogether. Hint to RootsTech Vendors you should use Bumps too to collect user info. Why do I have to drop a business card into a fishbowl??? Do a BUMP,  get a chotsky (swag). Leave the fishbowl for  the Luddites.
  • Are you a Slavic (Czech, Pole, Russian, etc.) genealogist? Then you must be dying for diacriticals. You could add an international keyboard. But why? In iOS5, just press and hold down the ‘ l ‘ key and up will come a list including the slashed-l. Just slide your finger over onto the slashed-l to enter that. Likewise, for entering ‘S, E, A, Z, C, N, etc.’ too — works upper/lower case. Of course if you have German ancestors, you can get your umlauts too in the same fashion. That trick is a Latin Alphabet data entry trick (sorry Cyrillic or Hebrew readers — try the International Keyboard trick).
February 18, 2012

Blog Bigos – Mount Vernon Cemetery (Philadelphia) …

by C. Michael Eliasz-Solomon

Stanczyk once did  a RAOGK to Mount Vernon Cemetery (Philadelphia) . Sharon DuBois wanted to know more and sent a comment to my original article (5/31/2010). Sharon, you are calling the phone #:  215-229-6038 (from Find-A-Grave — see first link above), I assume correct?

Back in 2010, I was met by a caretaker named Norman (last name unknown to me). I felt for Norman. It was obvious he had taken over caretaker duties and his budget was less than “shoestring”. The cemetery back in 2010 had become overgrown. I was kind to Norman and effusive in my thanks for allowing me to commune with the Seipp family — which he led me to [ You would not be able to find anything without Norman's help].

It reminded me of the cemetery crisis that happened in MI a few years back. In the last 18 months a few other Philadelphia cemeteries have been “saved” or at least adopted. My advice is to start with Philadelphia City Hall – Orphan’s court to find who has “ownership”.

I hate to to tell Sharon that her deed for two lots, are at present,  probably worthless. The area is a bit decrepit. As I said the cemetery is unkempt and overgrown — not the kind of place that I would want for me or any of my ancestors for all eternity. I cannot see myself ever going back to it.

Perhaps the funds are now gone and there is no longer any caretaker. I cannot say, since it has been two years since I visited the cemetery.

In a related comment, I would like to tell an email/Find-A-Grave contributor named Meges that I did request an update to Elizabeth Seipp  d. 19-October-1918, with the obit you found from the Philadelphia Inquirer — I cut/pasted what you sent me. This was a memorial for the Seipp family who are buried at Mount Vernon Cemetery.


February 16, 2012

1940 US Census – Blank Forms — #Genealogy, #US, #Census

by C. Michael Eliasz-Solomon

Legacy Family Tree has release blank US Census Forms (page1 | page2) for the 1940 US Census. April 2nd is coming, are you prepared? Is prepared?

At #RootsTech 2012, the 3rd keynote was an Ancestry talking-head panel. They joked about whether the website could withstand the crush on April 2nd. Let’s see how this experiment goes.

This is the first US Census to be released in an all digital format.


February 16, 2012

GEDCOM “RailRoad Tracks” (aka Graphic Syntax Diagram) – #Genealogy, #Technology

by C. Michael Eliasz-Solomon

The above diagram is what Stanczyk had been jabbering about since the #RootsTech conference. Isn’t that much easier on the eyes and the grey matter than a complex UML diagram? Who even knows what a UML diagram is or if it is correct or not?

What does it say is in a GEDCOM file (ex.  Eliasz.ged)?

A HEAD tag  optionally followed by a SUBmissioN Record followed by 1 or more GEDCOM lines followed by a TRLR tag.

ex. gedcom lines  that can be “traced” along the railroad tracks at the top.

 1 SOUR Stanczyk_Software
 1 SUBM @1@
 2 VERS   5.5.1
 0 @1@ SUBM

OK Stanczyk_Software does not exist, but was made up as a fictitious valid SOURce System Identifier name. The GEDCOM file (*.ged) is a text file and you can view/edit the file with any text editor (vi | NotePad | WordPad | etc.). I do not recommend editing your gedcom outside of your family tree software, but there is certainly nothing stopping you from doing that ( DO NOT TRY THIS AT HOME). If you knew gedcom, you could correct those erroneous/buggy gedcom statements that are generated by so many programs — that cause poor Dallan Quass to ONLY acheive 94% compatibility with his GEDCOM parser.

Have you ever downloaded your gedcom from ANCESTRY and then uploaded it to RootsWeb? Then you might see all those crazy _APID  tags.   It is a custom tag (since it begins with an underscore  – GEDCOM rules dear boy/girl).   It really messed up my RootsWeb pages with gobbledygook. I finally decided to edit one gedcom and remove all of the _APID tags before I uploaded the file to RootsWeb. Aaah that is SO much better on the eyes. Oh I probably do not want to re-upload the edited gedcom into ANCESTRY, but at least my RootsWeb pages are so much better!   The _APID is just a custom tag for ANCESTRY (who knows what they do with it) so to appeal to my sense of aesthetics, I just removed them — no impact on the RootsWeb pages, other than improved readability. [If you try this, make a backup copy of the gedcom and edit the backup copy!]

Now obviously the above graphic syntax diagram is not complete. It needs to be resolved to a very low level of detail such that all valid GEDCOM lines can be traced. It also requires me/you to add in some definitional things (like exactly what is a level# — you know those numbers at the beginning of each line).

I have a somewhat mid-level  graphic syntax diagram that I generated using an Open Source (i.e. free) graphic syntax diagrammer, as I said in one my comments, I will send it to whoever asks (already sent it to Ryan Heaton & Tamura Jones). You can get a copy of Ryan Heaton’s presentation from RootsTech 2012 and compare it to his UML diagram (an object model). I think you will quickly realize that you cannot see how GEDCOM relates to the UML diagram — therefore it is difficult to ask questions or make suggestions. A skilled data architect/data modeler or a high-level object-oriented programmer could make the comparison and intuit what FamilySearch is proposing, but a genealogist without those technical skills could NOT.

I am truly asking the question, “Can a genealogist without a computer science degree or job read the above diagram?” and trace with his finger a valid path of correct GEDCOM syntax [ assuming a whole set of diagrams were published]. The idea is to see how the GEDCOM LINES (in v5.5.1 parlance FAMILY_RECORD, INDIVIDUAL_RECORD, SOURCE_RECORD, etc.) are defined and whether or not what FamilySearch is proposing something complete/usable and that advances the capabilities of the current generation of software without causing incompatibilities (ruining poor Dallan Quass’s 94% achievement). Will it finally allow us to move the images/audio/video multimedia types along with the textual portion of our family trees and keep those digital  objects connected to the correct people when moving between software programs?


GEDCOM files are like pictures of our beloved ancestors. They live on many years beyond those that created them. Let’s not lose any of them OK?

February 15, 2012

Wolf / Wolvovitz – Come to Philadelphia from Maramoros, Hungary — #Jewish, #Genealogy

by C. Michael Eliasz-Solomon

Stanczyk  made some interesting finds in Salt Lake City, UT a couple of weeks ago. I found multiple Wolvovitz ancestors coming to Philadelphia.

Now I had one of my wife great-uncles (grand-uncles for purists) whose American name was Harry Wolf, but his name had changed from Herman Wolsevitz. So as I prepared my research list (Excel Spreadsheet), I added the microfilm #’s for Philadelphia HIAS (Hebrew Immigrant Aid Society). Now these HIAS microfilm were mainly to find Solomon, but I made a mental note to see if any Wolf were in the list. Imagine my surprise to see Wolvovitz. My brain said not Wolf, but I have seen that name before — so I whipped out my Ancestry App on my iPhone and scanned my family tree for Harry Wolf to see if this matched his name on his Petition for Naturalization. Close.

The cards I found matched enough markers to suggest I may have found my wife’s maternal grandmother’s family. They all agreed on the region they came from … Maramaros … Hungary (and came to Philadelphia). Today that region is called  Maramures and depending on the village either Romania or Ukraine. But with shifting borders, it was Hungary (Austro-Hungary), then Czechoslovakia, then Hungary and now either Romania/Ukraine. The villages are so close to the border it may be both Romania & Ukraine. So I did some quick checking of the area to find what kind of Jewish genealogy resources might be available.

Then I find that one of the #RootsTech speakers, a Brooke Ganz, is a lead contact for the Jewish Indexing project in this area. I had just heard her speak  on  her project called LeafSeek and the underlying Solar/Solarium (open source tools from Apache) technology. The Internet makes this a very small world indeed.

Love those HIAS cards …

February 13, 2012

Blog Bigos …

by C. Michael Eliasz-Solomon

Stanczyk added a new Page (Tech Diary) to record my technology doings.

While doing that and reading from my blogroll (and emails), I discovered some history about the “defacto standard GEDCOM” (wiki: GEDCOM ). Now I strongly recommend you start from “defacto” link rather than the wikipedia link.

  • RootsTech 2012 – had two GEDCOM presentations by Ryan Heaton (FamilySearch, GEDCOMX project).
  • RootsTech 2012 – had one open source GEDCOM parser presentation by Dallan Quass. Dallan was quite remarkable in his efforts to achieve a 94% commonality amongst 7,000 different GEDCOM files. Dallan Quass has a GitHub project for his Open Source GEDCOM parser.
  • Modern Software Experience (Tamura Jones) had a couple articles that caused me to write this article. His most recent GEDCOM article that caught my eye was:  BetterGEDCOM (2/2/2012). I also noticed he had a GEDCOMX article from 12/12/2011. These two articles provide a good discussion. I also noticed that the BetterGEDCOM project had their own project blog. [also see his Gentle Introduction to GEDCOM  article].

I believe those provide the most recent current thoughts on GEDCOM (that I have not penned).

  • I have been studying GEDCOM v5.5 (the last GEDCOM standard).
  • I produced a partial Graphic Syntax Diagram of GEDCOM v5.5 [what I had been calling "Railroad Tracks"] just to demonstrate how I thought this diagram was a better vehicle to communicate the standard [than say UML object models].
  • I could not resist making slight tweaks to GEDCOM v5.5 even in my preliminary studies. Mostly so we could discuss GEDCOM in a readable fashion (i.e. whitespace for formatting, and comment lines ) or because the language cries out for consistency (i.e. requiring the HEAD tag to be a zero level, just like the TRLR tag).

My  Graphic Syntax Diagram of GEDCOM v5.5 was produced using an open source tool. It is partial and still high level. I did put in a construct so that you can clearly see all 128 standard tags. The Graphic Syntax Diagrammer is an excellent tool. I will have to offer the author a suggestion for the PNG images that it outputs. I need to take my diagram and manually edit it to make the drawing a better fit for 8.5″ x 11.0″ (aka A1) paper. I need to graphically wrap the railroad tracks and to add page breaks so that the image is itself usable for viewing/discussions. I will offer this sample drawing to any interested parties — including emailing the edited product to Ryan Heaton and Dallan Quass [who since they did not request it -- can feel free to ignore it].

My goal is to make minor tweaks to  GEDCOM v5.5 via this diagram [not programming] and try and get DallanQ to produce a one-off parser for it (call it, say GEDCOM 5.5.999) and hope that my tweaks will not lower Dallan’s hard work of achieving 94% compatibility. If it turns out to have virtually no effect on Dallan’s 94% compatibility in his Open Source parser, then I can think about  getting some software vendors to utilize the enhancements (via end user requests), since they are trivial, just to move the standard forward and to open an interest in the vendors to looking at how we create a new Open Standard for GEDCOM.


Thanks to Tamura Jones, I now know I need to update my diagram to GEDCOM v5.5.1 first

February 12, 2012

GEDCOM Standards – Where Genealogy Meets Technology — #Genealogy, #Technology, #Standards

by C. Michael Eliasz-Solomon

Stanczyk, has been churning since about November of last year (2011).  I have a number of ideas rummaging around my brain for genealogy apps. For over a quarter century, I have been a computer professional and used and/or developed a lot of  programs using a myriad of technologies. At my core, I am a data expert: design it, store it, query it, manage it, analyze it and protect it. It being the data.

Before going to #RootsTech 2012, I knew GEDCOM was the core of our hobby/business/research. GEDCOM is our defacto standard. It is how data in exchanged between us and our various programs. I say defacto because as a standard goes it is not a very open standard (one organization “owns”   it, and  the rest of us go along with it). It also has not changed in about decade and a half; So Ryan Heaton was correct in calling it “stale”. It does still work .. mostly. Although if a standard does not progress then you get a lot of proprietary “enhancements” that prevent the interchange of data completely — since one vendor does not know how to deal with another vendor’s file in totality.

At present, GEDCOM maxes out at version 5.5, although there are various other variations you might  see. But 5.5 was the last standard version. I counted 128 total tags and a provision for creating non-standard tags (they start with an underscore).

[Mike thanks to Tamura Jones! Even though GEDCOM v5.5.1 was never finalized, it IS the defacto max version of GEDCOM. GEDCOM v5.5.1 added 9 tags, removed the BLOB tag, so we now have a total of 136 tags.   -- I will need to update even my high level graphic syntax diagram]

Tags are like:

INDI,   FAMC,   FAMS,   SOUR,   REPO,   HEAD,   TRLR    etc.   -or-      ALIA,   ANCE

The first bunch is familiar and are probably in your family tree (if you ever exported the GEDCOM file). The ALIA tag is one that Dallan Quass said was universally used wrong by all programs. After seeing its definition, I can see how it  is confusing.  As for the ANCE, tag I do not recall seeing any program letting me do any functionality that might utilize this tag. This tag is probably one of those tags that Dallan said is not used at all.

I looked at the “MULTIMEDIA” section of the standard. It looks like it is woefully out of date and probably not used at all (at least not in any standard way), which is probably why our pics, audio, and video (or any other media file like PDF, MS Word) do not move with the GEDCOM. Has any program ever used the ENCODING/DECODING of a multimedia file? The standard seems to imply a buffer of only 32K (for a line) and even if you used a large number of  CONC tags strung one after another you need 100 lines to store a 3.2MB file in-line in the GEDCOM. I do not think I have seen that in a GEDCOM. They probably stored these binary large objects (BLOBs) outside the gedcom and refer to their path on the computer/network.  I did some noodling. I have 890 MB (or approximately  890,000 KB) in pictures and scanned source documents for about 1,000 people in my family tree. So I use nearly a gigabyte (1GB) for my family tree and all other multimedia — and I do not have any audio or video!  So I use almost 1MB/person.

If we did have this magical new GEDCOM standard that could carry all of our multimedia from one GEDCOM program to another GEDCOM program, the copying would take a long time. If I uploaded/download it to/from the Internet, I might incur an overage on my ISP’s usage charges, if this were technically feasible!   Imagine if I did this multiple times a month (as I got updates). I am beginning to understand why no vendor has tackled the problem. I would also like to store PDFs and other documents besides GIF/JPG/PNG which can be displayed on the Internet web pages natively in a browser. Those are not a part of the existing GEDCOM standard. Let me sling some jargon — I’d want to store any file type that there is a MIME type definition for,  that I can currently embed in emails,  or utilize in Java programs or that the HTML5 standard will allow for multimedia.

The GEDCOM 5.5 was in its infancy on dealing with character sets. It was predominantly ASCII with some funky ANSEL coding of characters to handle latin alphabet diacriticals, although it is not clear how I would do the data entry for those and it looks incomplete. It did mention UNICODE, but only cursory and just to remind us that the lengths in the GEDCOM standard were in  ‘characters’ not bytes –which was correct. Although those multibyte characters (say in Hebrew, Russian or Japanese or Chinese) would quickly use up the 32K byte line buffer  limit, which would effectively become about 8K characters per line. In fact, GEDCOM 5.5 says it will only deal with LATIN alphabets and leave Cyrillic, Hebrew and Kanji for some far flung future. Stanczyk  is Slavic, I need UNICODE to represent my ancestor’s names and places. Fortunately, I do not feel the need for Cyrillic (Russian, Ukrainian, Belorussian, Macedonian, etc.) or I’d be out of luck. I’ll just use the Polish version of those names in their ‘Latinized’ forms.

Oh that is another area the standard needs to be enhanced. NAMES. Dallan mentioned that Personal Names do not get a thorough treatment in the standard (I am refusing to read the data model and I am a Data Architect). Location Names get almost no treatment — they do give you a place to store your locations  (PLAC tag). What language should I use, after all my ancestors are from POLAND for God’s sake. Besides the obvious Polish, I have German, Russian and Latin to deal with and being American I prefer English. Slavic names often do not translate well. For example Wladyslaw is Ladislaus in Latin, but in English there is no equivalent — maybe that is why my ancestors use ‘Walter’ instead. But the point is, how should I store the name? Can I store all of the equivalents and search on any of them? Nope.

Damn, Russian is Cyrillic.  GEDCOM doesn’t deal with non Latin alphabets;  And even though I can read the Russian genealogy records, I ‘d rather not nor would I want to try and do data entry that way either. Besides, the communists reformed the language in 1918 (making War & Peace considerably shorter in Russian); That reform eliminated several characters. Most modern software is not aware of the eliminated characters  much less able to generate them. This whole Language/Unicode/Name thing is complicated and I have not even mentioned the changing borders or the renaming of cities in different languages or over time or their changing jurisdictions. I cannot fault GEDCOM for all of these woes. I have them in my own research and I have not yet found any satisfying way to  handle them. I find it helps to have a very good memory and keep these things in my head — but there is no backup for that.

How are we ever going to arrive at the vision Jay Verkler put forth at #RootsTech?  GEDCOM needs to become an open standard. Once it is standardized again, then it needs to become modern again and deal with the current technology, so we can get around to the tough problems of conforming: names, places, sources/repositories, calendars/dates  and doing complex analyses like Social Network Analysis as a way to gather wayward ancestors into a family for which we lack documentation to prove (Genealogically). I hope the future includes Bieder-Morse phonetic matching and can deal with folding diacritical characters into a base character (ex.  change ę into e) for searches.

FamilySearch, if you are going to register GEDCOM tools, then please do a few more things for the NEW standard. First, make each vendor add to an APPENDIX the name and complete definition of their NON-STANDARD tags, in case anyone else wishes to implement or deal with them. Put a section in the header (HEAD tag) that lists all NON-STANDARD tags (just once each) along with its vendor so that someone else can go look at the standard and see what these tags mean and possibly implement the good ones. Forget that two byte thing before the HEAD tag. Just make the HEAD tag ‘s  CHAR sub-tag indicate the character set (ANSI | ANSEL | UNICODE ).  Please administer a #RootsTech keynote to vote on annual changes to the GEDCOM standard. Provide a GEDCOM validator and also a GEDCOM converter webpage to allow users/vendors to validate/convert their gedcom file(s).

Make multimedia be meta-data and allow users to define “LOCATIONS” where multimedia files can be found using either a PATH or a URL (or a relative path / URL). Make it a part of the standard that the meta-data must move, but the multimedia files can optionally stay put. Multimedia should be able to be placed on a LOCAL/NETWORK, or on the INTERNET or on a multimedia  removable volume(s) [thumb drives, CDs, DVDs, etc.]. Make the multimedia “LOCATIONS” editable so a user can switch between LOCAL/NETWORK, INTERNET, or REMOVABLE including using some of each type of LOCATION. Allows these files to exist or not (show “UNAVAILABLE” or some equivalent visual clue, if accessed and they do not exist).  The mapping between an Individual (INDI) or a family (FAM) or some other future GROUP and its multimedia file(s) must move as a part of the meta-data (even if the multimedia file(s) do not). That way the end-user need only edit his LOCATIONS meta-data (and ensure the files are in that/those location(s)) when he runs the software.

Define an API for GEDCOM plug-ins so that new software can access the GEDCOM without parsing the gedcom file. The API should give the external plug-in a wrapped interface to the underlying data model without having to know the data model, just the individual, family, or location, or a name list of individuals, families, or locations. This will allow new software to provide additional functionality to a family tree or to provide inter-operability between trees/websites. Obviously security/privacy rules would limit this kind of  plug-in access.

That’s Stanczyk’s vision of the GEDCOM future!

February 12, 2012

#RootsTech Research – 2012 — #Polish, #Genealogy

by C. Michael Eliasz-Solomon

Stanczyk, prepares for going to an archive or research library. So when I was awarded the prize of going to #RootsTech, I immediately started my preparations.

I favor the microfilm which are free to read in the Family History Library in Salt Lake City.

Biechów –  MF # 1257788 (parts 8-10) which covered the years 1875-1877

Pacanów – MF #’s 1192352,  1192351 which covered 1876-1877   &  1875 [respectively]

Beszowa – 1257787

Tumlin – 1808856, 939955

Olesnica – 1807620 (parts 4-10)

Opatowiec – 1807620 (parts 11-16),  1192351 (parts 1-7)

Stopnica – 1807635 (parts 1-6)

Swiniary – 939951

And those were just the Polish villages (there were many more in the USA, but that is another floor).

Some of the above are because I am expanding the search for records to surrounding parishes. That is called a proximity/circle search. As it turned out, the proximity also included nearby parishes where affiliated families said they were from. So I was looking for GAWLIK in Opatowiec and GRONEK in Stopnica/Olesnica.  I always checked for ELIJASZ/LESZCZYŃSKI/WLECIAŁOWSKI in all villages. I was disappointed that I did not find KĘDZIERSKI in Tumlin.

I had prepared for some books (and/or maps) too. Sadly, many of these items were not located in the library and my three levels of assistants all failed to find them or even to explain why they could not be found:

943.8 E7sh (Malopolska cadastral. This was a high priority, so it was disappointing not to be able to locate these).

943.84 R2e (a register of Landowners — also not locatable).

A couple of books I did find, were a disappointment because they did not contain any of my family. Cest la vie — that too is a part of the research. All told I had 10 spreadsheet pages of  Family History Catatlog Items!  That may seem like a lot; But it is always better to be over prepared because as you see some items cannot be located, some are dead-ends, and some quickly show they do not contain what you are looking for after all. Being under prepared is just a time waster, but they do have PCs available to do catalog look-ups — so it is not a show stopper.

I dutifully check them off, as I use them and some times I note my findings (or lack there of).

Future Research

Next time I will have to search more thoroughly through Beszowa and exhaustively too [for Paluch]. I will also search Dobrowoda parish too [for Major]. I will have to dedicate a lot of time to Swinary too [for Elijasz, Leszczynski, Kordos, etc.] and also Szczucin.

I will have to find a way to get to Buffalo and find my great-uncle Franciszek Leszczynski’s records and hopefully his brother Jan (aka John) Leszczynski too.

I of course need to get to Poland and visit the actual archives and parishes of my ancestors to see those records that have not yet been microfilmed — I need to write down this research plan. I already know where the civil and diocesan archives are and of course the parishes themselves. I will need an abundance of time there to get around the language and customs and the learning curve of using these resources.

How do you prepare for your genealogy trips?

February 11, 2012

Genealogical Finds From #RootsTech (Family History Library)

by C. Michael Eliasz-Solomon

Stanczyk was in Salt Lake City, UT for RootsTech a week and a half ago. I thoroughly enjoyed the intersection of my two intellectual pursuits: technology & genealogy. I was not the only person at RootsTech who said they had a foot in each world. I think the conference planners think this is a mash-up between users & developers; And it definitely is that. But there are a large number of us tech savants, who are also avid  genealogists.

Success 1

In an earlier article  (7-Feb-2012), I wrote about an exciting find of two of my great-grandmother’s siblings marrying each other (a Major & a Paluch). Because it was not an Elijasz nor a Leszczynski record and yet I found it because of an Social Network Analysis experiment I conducted last year, I investigated that record and made an outstanding find.

Today I wanted to talk about a cousin of mine from TN whose grandmother turned out to be a cousin of my grandfather. My cousin Kim showed me her grandparent’s marriage records (both civil & church) and we discovered that her great-grandmother was my great-grand-aunt. We also saw that her grandfather (Adam Gawlikowski) was from Opatowiec in the Polish Church Record (Sweetest Heart of Mary Church in Detroit). Well there were a couple of Opatowiec — so I took the opportunity of being in Salt Lake to narrow down which parish might be the correct one.

Success 2

1st part of Rec #27 - Antoni Gawlik

I found my cousin Kim’s great-grandparent’s having children in Opatowiec (in the Kazimierz Wielka powiat, old woj. Kielce — LDS MF# 1192351 & 1807620). In fact, I found her great-granduncle Antoni Gawlikowski ‘s birth record with the correct parents: Martin Gawlik & Maryanna Lisowskich. In fact, if Kim is reading my blog, you should rent LDS MF # 1192350 and you may be able find your great-grandparents’ marriage record and many other Gawliks/Lisowskich, potentially all the way back to 1614 !     MF# 1192351 & 1807620 were in Russian, but I am betting that almost all of MF # 1192350 (1614-1870) will be in Latin.   Sadly, it appears her grandfather Adam was born after the end of the last year in MF 1807620. But I did find three siblings of Adam (besides Antoni) that we did not know of  before:  Jan Gawlik,  Ludwik Gawlik, and Maryanna Gawlik. I also saw that the Gawlik name was written without the ‘ski’ at the end. Sadly both Ludwik and Maryanna died in 1880. Perhaps Jan survived into adulthood. He may have stayed in Poland and took care of his parents. I am sorry that Antoni’s birth record fell across two pages in the church book, requiring two camera shots.

2nd part of record #27 - Antoni Gawlik

February 10, 2012

Pacanów Parish 1881 Marriages (from the index) – #Polish, #Genealogy, #ChurchRecords

by C. Michael Eliasz-Solomon

Stanczyk would like to apologize. This posting is a month old and then was further delayed when I went to the RootsTech 2012 conference.

Here are the 40 Married couples from the 1881 Church Book of Pacanów parish (parafia):

  1. Wojciech Banas & Marianna Wieczorkowna   Akt # 1
  2. Antoni Buzon & Julianna Banasionka              Akt # 9
  3. Walenty Begaszcz & Joanna Orzechowna      Akt #20
  4. Adam Banas & Franciszka Duponczyna          Akt #28
  5. Jozef Czernecki & Franciszka Nowakowska     Akt # 2
  6. Jozef Elijasz & Marianna Piotrowska              Akt #29
  7. Ignacy Gurgol & Marianna Czapliakowna        Akt #19
  8. Antoni Grelia & Katarzyna Zhiczowna             Akt #26
  9. Kasper Izak & Teressa Bieliatowna                  Akt # 3
  10. Wawrzyniec Juszczyk & Franciszka Gulowna  Akt #17
  11. Wojciech Jarosz & Marianna Przeworszczonka Akt #17
  12. Franciszek Kosatka & Agnieszka Sugojowna    Akt # 4
  13. Antoni Krawczyk & Katarzyna Waliasowna      Akt # 6
  14. Jan Kobac & Marianna Stachurska                  Akt #16
  15. Stanisław Krupa & Katarzyna Kordosowna      Akt #30
  16. Wawrzyniec Kierop & Katarzyna Wojciechowska Akt #36
  17. Stefan Lewinski & Agnieszka Wierzbowska       Akt # 5
  18. Jan Mulszie & Agnieszka Tomczykowna           Akt #27
  19. Jan Miotlowski & Marianna Dudzionka              Akt #38
  20. Wojciech Madziak & Marianna Zhigliczka          Akt #39
  21. StanisławNowak & Marianna Wiestranowska    Akt #10
  22. Ludwik Nowitzki & Katarzyna Subisnow           Akt #40
  23. Konstanty Piotrowski & Urszula Lewinsnow     Akt # 7
  24. Wladysław Pytka & Katarzyna Nowakowska   Akt #21
  25. Wawrzyniec Pietryka & Marianna Murodzionka Akt #25
  26. Martin Porada & Rozalia Wawrzykiewicz           Akt #31
  27. Andrzej Poliniak & Jadwiga Soltyskowna          Akt #37
  28. Kazimierz Siwiec & Marianna Zasuczowna         Akt #11
  29. Michal Sliski & Marianna Kordosow                   Akt #12
  30. Tomasz Stopiniszcki & Antonina Zhilioniow       Akt #23
  31. Jozef Stempnik & Lucija Wuszczykowska        Akt #32
  32. Jan Ksabowski & Marianna Bursowna              Akt #33
  33. Wojciech Szymaszski & Tekla Borczykow        Akt #14
  34. Marek Szelmaszski & Franciszka Wierzbyczkowna Akt #24
  35. Wawrzyniec Wieczorek & Katarzyna Szelmanikowna Akt #13
  36. Kazimierz Wielgus & Julianna Szylmanikowna    Akt #18
  37. Leon Wojtiak & Katarzyna Kolpakowna            Akt #22
  38. Walenty Zdyb & Katarzyna Pojioniow              Akt #15
  39. Julian Zabkowski & Franciszka Wtorek             Akt #35
  40. Jan Zhigliczki & Eleonora Wojtysiowna             Akt # 8

Many of the above names are spelled incorrectly. They were transliterated from Russian Cyrillic to a Polish name, but my translation is very suspect in many cases. Caveat Emptor!


Get every new post delivered to your Inbox.

Join 368 other followers

%d bloggers like this: