I am sad that I missed RootsTech 2011, but am excited to see that it has stirred up ideas and there is a spirit of innovation that seems to be sweeping through the genealogy/technology community.  Some are having discussions about a new data format to bring GEDCOM into the 21st century and make sure it plays well in the online world of collaboration and social networking. One place you can find this is the BetterGEDCOM Wiki and another is the e-mail list for the FamilySearch Developer Network (FSDN).

Much of the recent discussion on FSDN has been around the main sticking points of the data model and whether the structure should be people-based or record-based. As a developer, I often want to jump down into the details of the problem and gnaw on it until I figure it out. But lately I am changing. I prefer to look at it from a user’s perspective. Call it product management or User Experience (UX), but if in the end the data model doesn’t allow the software to do what I think it can and should do, then I think a great opportunity would have been missed.

So back to GenPerfect. What do I think it should look like? What implications does that have on a data model? As a user, what is my vision of the perfect genealogy software?

Get Started

I have an empty database, what do I do first?  How about quickly enter in my name and those of my family members along with their birth information. Nothing new there. Or maybe I choose to select my family members from my list of Friends on Facebook or some other social site.

Record Questions

For each person, I would like a list of questions generated including:

• What is Worth Tucker’s birth date and place
• Did Worth Tucker marry?
• When and where did Worth Tucker get married and to whom?
• Is Worth Tucker still living?
• When and where did Worth Tucker die?
• Where is Worth Tucker buried?

There could be more questions based on age and locations where he lived:

• Did Worth Tucker serve in the military during WWI?
• Was Worth Tucker affected by the 1918 Influenza epidemic?

But then for each person, I could add my own questions:

• What did Worth Tucker look like (height, weight, eye color)?
• What were Worth Tucker’s occupations?
• In what locations did Worth Tucker live?

I like the idea of being able to add a question about a relative/ancestor at any time and to have one place to keep that list.

Capture Sources

The next thing that I would like to do is add source documents. These could be scanned images of birth and marriage certificates, links to images that live online, a typed family history in pdf format, photographs, or many other forms. If the document is typed, then it would use OCR to create a transcript. In terms of the Genealogical Proof Standard (GPS) and Evidence Explained (EE) this is a derivative source as opposed to an original source. Now I have two sources that make up part of a source provenance. When a new source is added to the system, then by answering a few questions you can indicate if that source is original and if not then how it is or may be related to the original. Depending on the type of source entered, then using EE templates I will know the important information that I need to record about that source. This becomes my citation.

On websites such as FamilySearch, Ancestry, or even family history blogs then clicking on a single link I can download the source image, the citation, and even the data into my database. For example, for a census result on Ancestry, I could choose to download information for a single household (names, relationship to head of household, ages, calculated birth year, gender, can read, can write, birth place, etc.) or for all households on this census page and the previous and next pages. They would be imported as single household clusters as well as being related to specific source pages.

For any source, I can choose to create a transcript or an abstract of the document. Either on the original or a derivative, I can highlight or annotate names, dates, places, or events and they would become part of searchable/accessible data in my database. For each source, I can indicate informants (either specifically like “Moses Tucker” or generally, “probably a doctor”). Knowing the informant(s) for a document, we can start to understand who might have provided which information (ex: death certificate can have both a doctor and family member as informants). Information is provided by either an eye witness or participant making it primary information or someone that received the knowledge from someone else which we call secondary.

Research Projects

Once I have the basics entered into the system for the first 1-3 generations, then I can move on to researching specific ancestors. I can take one of the questions associated with an individual and click to create a research project with that as the objective of the research. I could also use a statement or hypothesis as the objective of the research project. The project allows me to look at a subset of sources as they pertain to a specific goal. As I enter information or add sources, these will be recorded in a research log associated to the project.  I can add additional questions that I want answered as part of the project. EE defines evidence as being direct, indirect, or negative and that relates to how  well a piece of information in a source answers the research objective.  In these terms, then you cannot have evidence unless you also have a way to associate information to an objective.

Let’s say that I am collaborating on this project with others. I want a data format that allows me to share not only people, places, dates, events, and relationship but also objective, research log, sources, information, evidence, and questions. What if there are specific tasks that can be identified, then split among many participants.

Loosely-Linked People

What I mean by this is that just because I found a Worth Tucker in a document doesn’t mean that he is my Worth Tucker. There could also be different spellings of the same name in different documents. I would like to be able to link these individuals together and enter a reason why I think they are the same. Throughout the system, they would appear as one individual. For example, one research project could be about his birth and another about his death. But when I look at him in the system, I would see one individual (with possible name variations) and two events: birth and death. But I need to easily be able to get back to the list of “persons” that make up this person in case I discover that I am on the wrong track with one of the sources. I can then easily unlink them.

People/Names List

My database now contains multiple names for a single ancestor or even names for witnesses, neighbors, or people appearing in the same sources as your ancestors. With a single click, I can see a list of names of just ancestors or a list of names of people that haven’t been associated with a tree meaning they haven’t been proved as ancestors or that they are (or possibly are) associates of your ancestors. If I could list them in order of the number of times they appear in the system, I might be able to learn which ones my ancestors associated with most and ones that I might want to consider as research leads. Clicking on one of these names will allow me to create a research project for this individual. Sometimes the best ways to overcome brick walls in the research of our ancestors is to research someone they knew.

Resolve Conflicts

I need an easy way to list all conflicts for a specific research objective. By having all the conflicts in one place, I can makes notes by each one trying to resolve the conflict until I come up with the most plausible conclusion. At this point in time, based on the research that I did I can summarize my research as a conclusion. This will affect which information shows as the default on screen (and in reports) for an ancestor. Let’s say a research project to determine Worth Tucker’s birth date and location leads to many possible answers but as I go through each conflict, I feel best about 30 Nov 1870 and Laurel Township, Ashe County, North Carolina. So I indicate that that is my conclusion. When I look at Worth in the system, I see that as his birth date, but can also choose to see the other possible dates and places. The objective of the research project has been reached and I have a conclusion. The status of the project indicates that I have reached a conclusion on a specific date.

A year later, I get additional information about this research objective so I re-open the research project and add the information. This might lead to a different conclusion which now shows as the default. But in the research project, I can look at the research logs, questions, information, sources, conflicts, and conclusions separately.

Online Backup & Sync

Even though I may be doing the work on my desktop software, I want my work constantly backed-up to a secure location online so that I don’t loose any of my data or artifacts. In addition, I may choose to sync the data to an online database or peer-to-peer databases to protect my information and allow for collaboration.

Data Model

If we take the above as use cases or user stories of what GenPerfect should do, then we can understand that the data model needs to support:

• People and/or Names
• Relationships
• Dates
• Places
• Events
• Sources (GPS)
• Source Provenance
• Citations (EE Templates, GPS)
• Association of People, Dates, Places, etc. to a Source
• Projects
• Questions (also Statements and Hypothesis)
• Objectives(GPS)
• Conclusions(GPS)
• Research Logs
• Tasks
• Collaborators
• Analysis: sources, information, evidence (GPS)
• Media
• Tree

What would be in your GenPerfect? What else should be in the data model?

Source, Information, & Evidence

According to Evidence Explained by Elizabeth Shown Mills, ”sources are artifacts, books, digital files, documents, film, people, photographs, recordings, websites, etc.” (see page 24)  Information is the content of the source.  Evidence “represents our interpretation of information we consider relevant to the research question or problem.” (see page 25)  So in order to classify evidence we need both information and a research objective.  Even though the Genealogical Proof Standard (GPS) does not include a step to define research goals, I’ve included it as part of the Genealogy Research Process Map because it is implied.  Step one of the GPS states:

“We conduct a reasonable exhaustive search in reliable sources for all information that is or may be pertinent to the identity, relationship, event, or situation in question.”
The BCG Genealogical Standards Manual, page 1.

How do we know which sources to search if we don’t have a research objective?  The definitions of direct and indirect evidence also points to the need to have a defined research objective:

Direct evidence – relevant information that seems to answer the research question or solve the problem all by itself.
Indirect evidence – relevant information that cannot, alone, answer the question;
Negative evidence – an inference we can draw from the absence of information that should exist under particular circumstances.
Evidence Explained, page 25

Even the definition for negative evidence hints at a research objective.

So how can we set the citation quality value for evidence in RootsMagic or any other genealogy software unless we have a research objective?

A research objective can be in the form of a question, statement, or hypothesis.  The following are all valid research objectives:

• What was Worth Tucker’s birth date and place?
• Where was Worth Tucker born?
• Worth Tucker was born 30 Nov 1870 in Ashe County, North Carolina.
• Was Worth Tucker born in 1869 or 1870?

How specific the research goal depends on the researcher and what they want to discover.

In RootsMagic, a source can be associated with a person, family, or fact:

And for each citation of a source you can specify a value for citation quality for source, information, and evidence.  But to classify evidence, what is the research objective implied or otherwise?

Let’s say we have a book that we use as a source.  It was created by its author and is an original source.  The source information is entered in the Master Source section and appears in the Master Source List.  A specific page of that book is specified in the Source Details section and some information from that page is entered as part of the Source Detail Text.  This information then needs to be evaluated based on who provided that information: the informant.  If the informant was a participant or eyewitness, then we can say that the information is primary, otherwise it is secondary.  Now we come to evidence.  We take that piece of information and compare it to our research objective, but since we don’t have one we must infer it from what the citation is related to: person, family, or fact.  It is important to note that it is usually the researcher that should determine the research objective and not the software. 

Since we don’t have research objectives, only what the citation is associated with, then we must imply the research objective.  This can be tricky. 

Evidence for Fact Citation

Since a birth fact allows you to enter date, place, and place details does information in the source we are citing need to contain all of this information before we can say that it is direct?  Put another way, is the implied research objective:

What is the date, city, county, state, and specific place of Worth Tucker’s birth?

or it is

What is the date and place of Worth Tucker’s birth?

Do they both mean the same thing?  There is room for ambiguity.  Not to mention the fact that as a researcher, maybe I wanted the research objective to be a statement or a hypothesis:

Worth Tucker was born 30 Nov 1870 in Ashe County, North Carolina.

Depending on the fact, the software ask us to enter different information:

• Birth – date, place, place details
• Alternate Name – given names, surname, prefix, suffix, name type, nickname, date
• Education – date, place, place details, description
• DNA – DNA results
• LDS Baptism – date, temple, status, live/temple

One workaround for fact-based citations is to define a guideline that the citation quality can be marked as direct only if all possible entry fields for that fact type are filled in completely.  If a date or place is only partially filled in or the information doesn’t allow all fields to be filled in, then it is indirect.

Evidence for Person Citation

What would be the implied research objective for a citation associated with a person?

When you add a new person it asks for given name(s), surname, prefix, suffix, sex, and nickname plus some vital facts.  So I guess the workaround for this situation is to have the research objective be:

What is the complete name, sex, and optional nickname of Worth Tucker?

If the information from the source can answer all the parts, then it is direct; otherwise it is indirect.

Evidence for Family Citation

Now what about the implied research objective for a citation associated with a family?

What are the complete names of both parents and all children as well as the birth order of the children for the marriage of Worth Tucker and Florence Abby Pulsipher?

If the information in the source can answer all parts of the question, then the evidence is direct.

An Eye to the Future

Part of the reason for the current implementation in RootsMagic 4 and similar software could be the decades-old focus on research results and not research analysis.  My first genealogy software was a DOS version of PAF.  Before using that software, all research and any conclusions I came up with were done on paper.  Even the first versions of PAF only allowed you to enter a single date for birth, christening, death, and burial.  So the software was intended only to record the results of your research.  Modern genealogy software allows you to enter multiple facts/events of the same type and associate a source citation to it.  That way, you could have half a dozen birth entries containing different values or different levels of detail as the your research required. The software is able to keep track of ongoing research, and not just results.  I think genealogy software will continue to innovate and allow more and more research collection and analysis to occur in the software.  That is the direction that citation quality is pointing in RootsMagic 4 and the similar feature in Family Tree Maker 2009.  The next logical step is to allow the software to define research projects each with their own research objectives.  These research objectives would then be associated with source citations and citation quality therefore clarifying the use of the classification of evidence as direct or indirect.

I strongly encourage users of RootsMagic to use this feature, but in its current implementation there are a few gotchas and workarounds that need to be followed.

The Genealogical Proof Standard & Evidence Explained define research analysis classifications for a source, information, and evidence. A source is an object (or person) that contains (or has) information. A source can be classified as original or derivative. An original source is in its first oral or recorded form. Everything else that comes from an original (or another derivative) is a derivative. For example, a book is an original. Let’s say that it is a census enumerator’s book that he carried from house to house to take the census. Now let’s say that book is microfilmed and stored at an archive. The microfilm copy is a derivative. The digitization of the microfilm is a second generation derivative of the original. Without getting into the special cases of image copies, duplicate originals, and record copies, it is relatively easy to start uncovering the provenance or ancestry of the source you are using for your research back to the original source. The classification of a source as original or derivative helps to answer the question “Is there a better source?” and helps in your analysis as original sources usually carry more weight than derivative.

In RootsMagic 4 on the Edit Source screen, you see both the Master Source and Source Details sections.  The information in the Master Source section is independent of the details recorded when a specific source is cited for a person, family, or fact. 

When you click on the Quality button you see the three categories for sources, information, and evidence with their possible values:

Mapping this screen to the previous, the Source category refers to the Master Source section and the Information category refers to the Source Details section.  I’ll discuss the Evidence category in another gotcha.  What this is saying is that a source is original or derivative independent of the information that it contains.  The book, A History of Emery County, is an original source written by Edward A. Geary and it remains an original regardless of the degree of knowledge (firsthand or secondhand) of the informant that provided the information contained on page 179 or any other page. I can understand putting all three categories on the same screen to simplify things for the genealogists using the software.

In the current implementation in RootsMagic 4 (version 4.0.3.0) the problem is that all three categories are associated with the Source Details section.  This is a problem because this source appears in the Master Source List and can be used to cite multiple sources:

What that means is that if you set the Source as Original for the first citation, it will not be reflected in subsequent citations.  Creating a second citation from that same Master Source List entry will default the Source to “Don’t know” and it must be set independently.  Let’s suppose you have 10 citations (different Source Details) for a single Master Source List entry.  You could have 5 set to Original, 3 to Derivative and 2 to Don’t know.  And if you change the value for one citation it is not reflected in the others.  Worst case, this is confusing plus requires extra work to make sure all of the sources are consistent.

The current work around is to add a Master Source Comment indicating that this source is original or derivative and then each time you cite this existing source, check the comment before setting the quality classification for Source.

It is my hope that in a future release, there will be a way to set the source as original or derivative from the Edit Source screen off the Master Source List:

Then when that source is cited again the Quality screen would default the Source to that same value.  The Source in the Quality screen could be read-only or if editable any changes would be reflected in all citations derived from that same master source.

I hope this constructive criticism is taken how it is intended: to make an important feature the best that it can be.

One of the challenges that need to be solved for online source citation is the ability to give structure to digital assets. Think of an online book that consists of a hundred images each representing a page. There are other images for the cover, title page, etc. There might even be text documents, audio files, or video associated with it. How do we keep track of all those individual files and relate them as a single digital entity? That is part of the problem that METS is trying to solve. In online citations, we also have the issue of source provenance. Where did the digital image file for the census come from? It came from a microfilm copy of the original census. Is it possible that METS can help keep track of this provenance? What about complex sources that are part of a collection in a series part of a record group at an archive? Can MET be used to keep track of this hierarchal information?

Let’s explore the basics of METS to see if we can find some answers.

Metadata Encoding & Transmission Standard – METS

Basically a METS document consists of 7 major sections:

1. METS Header
2. Descriptive Metadata
3. Administrative Metadata
4. File Section
5. Structual Map
6. Structual Links
7. Behavior

METS is usually used to manage digital assets where there is at least one digital file, but it doesn’t have to. The sections that are interesting for our discussion are Descriptive Metadata, Administrative Metadata, and Structual Map.

The Descriptive Metadata section either wraps or references metadata about the source and can be in various formats including MODS, DC.

“The descriptive metadata section of a METS document consists of one or more (Descriptive Metadata Section) elements. Each
element may contain a pointer to external metadata (an element), internally embedded metadata (within an element), or both.”

(see http://www.loc.gov/standards/mets/METSOverview.v2.html#descMD)

A dmdSec element has an ID attribute that can be referenced elsewhere in the document.

Among other things, the Administrative Metadata section can contain a sourceMD section that describes (also using MODS, DC, etc.) the source
that the digital representation came from. For example a digitized Census image could be described as a dmdSec while the microfilm that it was digitized from could appear in the sourceMD.

The Structual Map section can describe the physical or logical (or both or other) structure of the source.

“The organization may be specified to any level of granularity (intellectual and or physical) that is desired. Since the element is repeatable, more than one organization can be applied to the digital content represented by the METS document. The organization provided by the may be purely intellectual or logical (such as a book divided into chapters), purely physical (a book divided into sequences of pages), or a mixture of logical and physical (a book sub-divided into chapters and subsequently divided into a sequence of pages).”

(see http://www.loc.gov/standards/mets/METS%20Documentation%20final%20070930%20msw.pdf page 36)

If there are digitized files described in the File Section, these can be referenced using file pointers (fptr elements) in the structual map. The structure map can also contain child METS pointers to another METS document (mptr elements).

Here is an example of a structMap hierarchy for a book:


<mets:structMap TYPE="physical">
<mets:div TYPE="book" LABEL="Martial Epigrams II" DMDID="DMD1">
<mets:div TYPE="page" LABEL="Blank page"/>
<mets:div TYPE="page" LABEL="Page i: Series title page"/>
<mets:div TYPE="page" LABEL="Page ii: Blank page"/>
<mets:div TYPE="page" LABEL="Page iii: Title page"/>
<mets:div TYPE="page" LABEL="Page iv: Publication info"/>
<mets:div TYPE="page" LABEL="Page v: Table of contents"/>
<mets:div TYPE="page" LABEL="Page vi: Blank page"/>
<mets:div TYPE="page" LABEL="Page 1: Half title page"/>
<mets:div TYPE="page" LABEL="Page 2 (Latin)"/>
<mets:div TYPE="page" LABEL="Page 3 (English)"/>
<mets:div TYPE="page" LABEL="Page 4 (Latin)">
<mets:div TYPE="page" LABEL="Page 5 (English)"/>
<mets:div TYPE="page" LABEL="Page 6 (Latin)"/>
<mets:div TYPE="page" LABEL="Page 7 (English)"/>
</mets:div>
</mets:structMap>


Notice that the values of the TYPE attributes of (structMap, div) are up to us to define.

Here is another example using a multivolume book:


<mets:structMap TYPE="physical">
<mets:div TYPE="multivolume book" LABEL="Martial Epigrams I & II" DMDID="DMD1">
<mets:div TYPE="volume" LABEL="Volume I">
<mets:mptr LOCTYPE="URL" xlink:href="http://www.loc.gov/standards/mets/documentation MatrialEpigrams.xml"/>
</mets:div>
<mets:div TYPE="volume" LABEL="Volume II">
<mets:mptr LOCTYPE="URL" xlink:href="http://www.loc.gov/standards/mets/documentation/MatialEpigramsII.xml"/>
</mets:div>
</mets:div>
</mets:structMap>


There is not a limitation on the number of levels represented by div elements.

Profiles

METS Profiles can be created for different types of documents or for different purposes.

“By making use of all the components, an institution not only declares how it builds a METS document of a certain digital object type, or for a specific application or purpose, but can also provide an implicit description of the data model used for internal METS document creators, METS tool developers, and external recipients of their METS documents. This information can be an invaluable means to convey succinctly the critical information necessary to disaggregate a METS document for disposal within another institutional repository, for instance, or for the use of searching, navigating, displaying, and rendering applications or tools.”

(see http://www.loc.gov/standards/mets/METS%20Documentation%20final%20070930%20msw.pdf page 74)

Here are some interesting METS Profiles:

Library of Congress METS Profile for Bibliographic Records
http://www.loc.gov/standards/mets/profiles/00000020.html

UCSD Complex Object Profile
http://www.loc.gov/standards/mets/profiles/00000017.html

Here is an article that describes METS from the perspective of a Metadata Librarian implementing METS at UCSD:
http://gort.ucsd.edu/dlpwg/dletters/issue8.pdf
It seems possible that METS could help us solve some of the problems of citing online sources. Still more research to done.

In this post, we continue our exploration through existing bibliographic standards to see how they might work as a format for online sites to easily share citation information.  To see the journey we have made so far, visit the page, A Better Way to Cite Online Sources.

From the Library of Congress standards page for MODS, we see the following description:

Metadata Object Description Schema (MODS) is a schema for a bibliographic element set that may be used for a variety of purposes, and particularly for library applications.

On the MODS overview page, we get more details:

As an XML schema it is intended to be able to carry selected data from existing MARC 21 records as well as to enable the creation of original resource description records. It includes a subset of MARC fields and uses language-based tags rather than numeric ones, in some cases regrouping elements from the MARC 21 bibliographic format. This schema is currently in draft status…
…the schema does not target round-tripability with MARC 21. In other words, an original MARC 21 record converted to MODS may not convert back to MARC 21 in its entirety without some loss of specificity in tagging or loss of data. In some cases if reconverted into MARC 21, the data may not be placed in exactly the same field that it started in because a MARC field may have been mapped to a more general one in MODS.

Compared to MARC, MODS is simplier and uses word tags (like name, titleInfo, and originInfo) instead of numeric tags (100, 245, 260).  There is not a 1 to 1 mapping between MARC and MODS, so conversion between the two might introduce some challenges.

Let’s look at the book example used in the analysis of the other standards:

Geary, Edward A. A History of Emery County. Salt Lake City: Utah State Historical Society, 1996.

The Library of Congress represents this book in MODS here.

The three key pieces of information (author, title, and publication) are represented in MODS as follows:


<titleInfo>
  <nonSort>A </nonSort>
  <title>history of Emery County</title>
</titleInfo>
<name type="personal">
  <namePart>Geary, Edward A.</namePart>
  <role>
    <roleTerm type="text" authority="marcrelator">creator</roleTerm>
  </role>
</name>
<originInfo>
  <place>
    <placeTerm type="text">Salt Lake City</placeTerm>
  </place>
  <publisher>Utah State Historical Society</publisher>
  <dateIssued>1996</dateIssued>
</originInfo>


Especially compared to MARC, this is much easier to understand. The title is shown between the titleInfo elements and splits the title into the non-sorting (/filing) portion and the rest of the title. The author’s name is contained in the name section identifying it as a personal name with the actual name contained in the namePart element.  The role\roleTerm is used to identify that the name is the creator of the source which by implication for a book is its author.  The originInfo section includes the publication information including publication place (place\placeTerm), publisher, and publication date (dateIssued).

Something else I noticed about this compared to MARC is that extra punctuation (commas, periods, colons, and semicolons) are not included as part of the field values. This separates the formatting from the data which makes more sense to me.  I also like the ability of MODS to break out the name and describe the individual parts:


<name type="personal">
  <namePart type="given">Edward A.</namePart>
  <namePart type="family">Geary</namePart>
</name>

 This can give more flexibility when displaying the name in the Source List Entry (surname first), First Reference Note (given name first), and Subsequent Note (surname only).

When citing a book with multiple authors and those authors have a name prefix (ex: Dr.) and/or a name suffix (Jr., III, etc.) is becomes necessary to break out those name parts as well to aid in forming the citation.  This can be done in MODS as follows:


<name type="personal">
  <namePart type="termsOfAddress">Dr.</namePart>
  <namePart type="given">Benjamin Franklin</namePart>
  <namePart type="family">Gates</namePart>
  <namePart type="termsOfAddress">III</namePart>
</name>


Notice how both the name prefix and suffix are identified by the same namePart type attribute of “termsOfAddress”.  In MODS, the order of the elements does not imply any display order so for a computer program to know that the first termsOfAddress is a prefix and the second is a suffix it would have to parse the actual text value.  In my opinion, it would be more helpful if MODS identified them like this:


<name type="personal">
  <namePart type="prefix">Dr.</namePart>
  <namePart type="given">Benjamin Franklin</namePart>
  <namePart type="family">Gates</namePart>
  <namePart type="suffix">III</namePart>
</name>


There is more investigation of MODS still to be done to determine how it might represent additional citation details that isn’t usually found in the Source List Entry. Remember page number for book? Additional sample citations from Evidence Explained would need to be put to the test to see if MODS is a good fit. I do like the ability of XML to add additional namespaces to qualify elements and attributes. This could be a means of extending the MODS standard for any additonal details required.

Previous posts have explored a better way to cite online sources (Part 1), how citation information can be stored as a file using GEDCOM format (Part 2) and MARC format (Part 3). This post takes the next logical step and discusses MARC XML.

MARC was created as a machine-readable format many decades ago. In the last decade, eXtensible Markup Language (XML) has been developed as a standard format to allow validation, processing, and transformation of data. MARC XML takes the MARC format and represents it as XML. This is done in a lossless way so that conversions between MARC and MARC XML will not lose any data.

A book represented as a Source List Entry in Evidence Explained looks like this:

Geary, Edward A. A History of Emery County. Salt Lake City: Utah State Historical Society, 1996.

That same book listed with the Library of Congress is shown here as MARC XML.

Let’s quickly compare the MARC entries for author, title, and publication with the corresponding representation in MARC XML.

MARC

100 1#
  $a Geary, Edward A.,
245 12
  $a A history of Emery County.
260 ##
  $a Salt Lake City :
  $b Utah State Historical Society ;
  $c 1996.


MARC XML

  <datafield tag="100" ind1="1" ind2=" ">
    <subfield code="a">Geary, Edward A.,</subfield>
  </datafield>
  <datafield tag="245" ind1="1" ind2="2">
    <subfield code="a">A history of Emery County.</subfield>
  </datafield>
  <datafield tag="260" ind1=" " ind2=" ">
    <subfield code="a">Salt Lake City :</subfield>
    <subfield code="b">Utah State Historical Society ;</subfield>
    <subfield code="c">1996.</subfield>
  </datafield>


The three fields (author, title, publication) are each represented by a datafield element with corresponding tag and indicators (ind1, ind2).  The only difference being in my reformatting of MARC, indicator spaces were represented by the # sign.  Instead of the $ delimiter for subfields, each datafield element has a separate subfield element with the appropriate code letter.

The MARC XML representation is easier to read by a person (software developer) than the raw MARC file and is more easily processed due to most programming languages’ ability to work with XML.  XML is more descriptive and therefore file sizes would be larger for MARC XML than for MARC.  But the size is not likely to be an issue.

Because MARC XML is just a rendering of MARC into XML, the observations and questions from Part 3 apply.

MARC XML could also be a possible format to represent online source citation information.

Over the past few months, I have shared an idea about how to make citing online sources easier.  You can find out more about this on the page, A Better Way to Cite Online Sources.  Some of the suggestions that came from the survey and posts Details Part 1 and Details Part 2 (GEDCOM) was why not use an existing standard. 

One of the suggestions was using Metadata Object Description Schema (MODS).  MODS is a “schema for a bibliographic element set that may be used for a variety of purposes, and particularly for library applications.” and is maintained by the Library of Congress.¹

 Now I suspect I will talk more about MODS in a future post, but the reason I bring it up now is because immediately in researching MODS I came across another acronymn, MARC. MARC stands for MAchine-Readable Cataloging and the MARC formats are “standards for the representation and communication of bibliographic and related information in machine-readable form.”² Most of the discussion I came across dealt with MARC 21 which (according to Understanding MARC Bibliographic: Machine-Readable Cataloging) is “the standard used by most library computer programs.”

 Now let’s return to the specific case identified in the video, “A Better Way to Cite Online Sources.”  We have a website that identifies a book source.  One of the three representations of a citation found in Evidence Explained is a Source List Entry or in other words a bibliographic entry:

So the book, A History of Emery County would look like this:

Geary, Edward A. A History of Emery County. Salt Lake City: Utah State Historical Society, 1996.

 The main parts (or fields) of the entry are:

1. Author
2. Title (main & sub)
3. Publication (place, publisher, year)

It should not be too surprising that the Library of Congress has a listing for this book and one of the ways that you can view it is in MARC format.  The description earlier indicates that MARC is a machine-readable format.  To make it easier for us to read, I have reformatted it:

000 01322cam a2200361 a 450
001 3055493
005 19970121124949.7
008 960403s1996 utuab b l001 0 eng d
035 ## $9 (DLC) 96060167
906 ## $a 7 $b cbc $c copycat $d 2 $e opcn $f 19 $g y-gencatlg
955 ## $a pb06 to hlcd 11-04-96; lk50 11-07-96; lk03 to sl 11-15-96; lj04 11-15-96
955 ## $a pn05 04-03-96; OCLC import pb06 11-04-96
010 ## $a 96060167
020 ## $a 0913738050
035 ## $a (OCoLC)35206145
040 ## $a USl $c USl $d DLC
042 ## $a lccopycat
043 ## $a n-us-ut
050 00 $a F832.E5 $b G43 1996
082 00 $a 979.2/57 $2 21
100 1# $a Geary, Edward A., $d 1937-
245 12 $a A history of Emery County / $c Edward A. Geary.
260 ## $a Salt Lake City : $b Utah State Historical Society ; $a [Castle Dale] ; $b Emery County Commission, $c 1996.
300 ## $a x, 448 p. : $b ill., map ; $c 24 cm.
440 #0 $a [Utah centennial county history series]
500 ## $a Series statement from jacket.
504 ## $a Includes bibliographical references (p. 423-426) and index.
651 #0 $a Emery County (Utah) $x History.
710 2# $a Utah State Historical Society.
710 1# $a Emery County (Utah). $b County Commission.
920 ## $a **LC HAS REQ’D # OF SHELF COPIES**
922 ## $a ad
991 ## $b c-GenColl $h F832.E5 $i G43 1996 $t Copy 1 $w BOOKS

Now lets trim that down to just what we need to represent author, title, and publication information:


100 1#
    $a Geary, Edward A.,
245 12
    $a A history of Emery County.
260 ##
    $a Salt Lake City :
    $b Utah State Historical Society ;
    $c 1996.


Without going into a lot of detail, I will explain the parts of the MARC format as it pertains to the source.  To get a better understanding of MARC, consult Understanding MARC Bibliographic: Machine-Readable Cataloging.

The 100 tag indicates a main entry for a personal name (in other words, the primary author). The 1# identifies two indicators the 1 describes the personal name as being a surname type whereas the # is a placeholder to show that the second indicator is undefined.  Any $ followed by a letter represents a subfield and $a specifically identifies a personal name with the value: “Geary, Edward A. ,”

The tag 245 is for a title statement. The first indicator with a value of 1 means that this is a title added entry because there is an author. The value of 2 for the second indicator means to skip the first 2 characters when sorting or filing this entry so the “A ” will be skipped thus starting at “history”.  The $a subfield identifies this as a proper title with a value of “A history of Emery County.”

The 260 tag indicates publication information. The ## indicators mean that there are not multiple publication entries so no sequence number is needed (the first indicator) whereas the second indicator is undefined.  The $a subfield identifies the place of publication, $b is the publisher’s name, and $c is the date of publication.

As can be seen, the information needed to represent a book following the Source List Entry from Evidence Explained can be represented using MARC.

There is still much I don’t know about MARC in the few hours that I have explored it, but I have a few observations and questions.

 Observations

• MARC was originally created in the 1960′s by the Library of Congress (LOC) so it has been in use for many decades.
• It has acceptance by at least the LOC & Library and Archives Canada.
• MARC has some ability to be extended by local entities: libraries, vendors, systems.
• It can be used for the following types of materials:
  • language material (including books)
  • printed music
  • manuscript music
  • cartographic material
  • manuscript cartographic material
  • projected medium (including video recordings)
  • nonmusical sound recording (audio recordings)
  • musical sound recording
  • 2-dimensional nonprojectable graphic
  • computer file (electronic resources)
  • kit
  • mixed materials
  • 3-dimensional artifact or naturally occurring object
  • manuscript language material
• Has the ability to identify resources in print, microfilm, microfiche, and electronic form.
• The MARC format is compact using numbers and letter codes to encode information.
• The file contents is difficult to read by a person without first being formatted by a computer program.
• Not the easiest file format to code against. (Not complaining, just an observation)
• Additional punctuation (commas, periods, colons, semicolons) at the end of field values should be part of the bibliographic entry formatting and would have to be removed to get to the real field values.
• It would be useful to be able to break up the author’s name into parts: first name, surname, prefix (Dr), and suffix (Jr, III). This doesn’t appear possible with MARC.
• The publication, Understanding MARC Bibligraphic, has been published in at least the following languages which could indicate its use internationally:
  • English
  • Arabic
  • French
  • Korean
  • Portuguese
  • Russian
  • Spanish

Questions

• How much is MARC used nationally and internationally?
• Is it able to handle the sources specific to genealogy research?
• EE indicates that for a book, Full and Short Reference Notes include a page number. Is there an existing MARC tag for that?  My hunch says no as it was created for bibliographic entries and online card catalogs.

 1. http://www.loc.gov/standards/mods/

2. http://www.loc.gov/marc/

I plan to e-mail a copy of the results to all those who took the survey and provided an e-mail address.  If you took the survey, didn’t provide your e-mail, and still want a copy of the results, contact me via this contact link.

As time permits, I will write about the survey results and some of the feedback I received.

I am grateful to the many bloggers and podcasters that spread the word about this effort.  Thank you for all that watched the video and participated in the survey.  I am excited to see how this effort continues over the next months and years.

Sincerely,

Mark Tucker

In Better Online Citations – Details Part 1 we examined how the QuickCheck model for “Book: Basic format” from Evidence Explained was coded in Family Tree Maker 2009, Legacy 7, and RootsMagic 4. From the screens we were able to identify implementation differences between the three applications. There are also differences between the applications in how citation information is conveyed via a GEDCOM export. The individual fields shown on the template screens are lost in the standard GEDCOM export making it impossible to create a rich EE-style citation in one application, export it to GEDCOM, and import it into another application while retaining that richness. In all cases (except when the exporter and importer of the GEDCOM is RootsMagic 4), the citation is changed from a “Book: Basic format” to a generic “old-style” (pre EE) format with important details lost.

In the previous post I skipped all details of the file format needed to support online downloadable source citations. From my own observations, from survey feedback as well as comments on this blog and through e-mail there are two main camps when it comes to this topic. One group feels that the best approach to take is an extension to the existing GEDCOM 5.5 standard (which was released in 1996). They feel that it is the best choice to lower the barrier of adoption and avoids YAFF (Yet Another File Format). See the comments from Tamura Jones from Part 1. The second group is open to a new file format based on XML (Extensible Markup Language) which has wide support among programming languages. As a programmer I lean slightly to the side of XML and that is what I used in the prototype shown in the video. But I am open to either view.

In that spirit of openness, I will first look at how the three applications that support EE-style citations represent those citations in an exported GEDCOM file. In this post, we will look at sections of GEDCOM which is a little technical but there will be plenty of explanations for readers of all levels. From the previous post we saw differences in how each application implemented the EE-style QuickCheck model and this post will show differences in how each exports them. You will also see some forethought in the export from one vendor.

For those who have never seen a GEDCOM file, each line starts with a number: 0, 1, 2, etc. A zero is the beginning of a new record and higher numbers are “nested” under lower numbers. It is a way of grouping information together. In the GEDCOM fragments I show here, I will indent the lines to make them easier to understand. I have also done some slight rearranging of lines to make the comparisons easier. After the number, each line has a tag which is a shortened identifier of the information contained on that line. You can see definitions of the standard tags here.

A GEDCOM file starts with a header that describes the software application that generated the file as well as the version of the GEDCOM standard:

Family Tree Maker 2009

0 HEAD
	1 SOUR FTM
		2 VERS Family Tree Maker (18.0.0.305)
		2 NAME Family Tree Maker for Windows
		2 CORP The Generations Network
	1 DEST GED55
	1 GEDC
		2 VERS 5.5
		2 FORM LINEAGE-LINKED

Legacy 7

0 HEAD
	1 SOUR Legacy
		2 VERS 7.0
		2 NAME Legacy (R)
		2 CORP Millennia Corp.
	1 DEST Gedcom55
	1 GEDC
		2 VERS 5.5
		2 FORM LINEAGE-LINKED

RootsMagic 4

0 HEAD
	1 SOUR RootsMagic
		2 VERS 4.0
		2 NAME RootsMagic
		2 CORP RootsMagic, Inc.
	1 DEST RootsMagic
	1 GEDC
		2 VERS 5.5.1
		2 FORM LINEAGE-LINKED

The first line starts the header record which contains a source program (SOUR) that generated the file and a destination program or format (DEST) that will use the file. The level under source shows the program, version and company information. The GEDC or GEDCOM tag identifies that the file adheres to the specified GEDCOM version and format. FTM and Legacy shows 5.5 whereas RM shows 5.5.1. GEDCOM 5.5.1 was published as a draft in 1999 but the changes between it and GEDCOM 5.5 do not affect our discussion. The rest of the header record was removed as it is not important for our comparison. Even though the numbering and abbreviations take a little getting used to, the file format is pretty straight forward. The rest of the file is just as understandable.

As you might remember from the video, we have my great grandfather Worth Tucker who owned property in Elmo, Emery, Utah. The source of this information was a book. From the book we have 4 images: three that go with the source entry and one for a specific page that should be associated with the citation or source detail. Lastly, there is an extract from a page added as the citation text.

Here is what part of that looks like:

Family Tree Maker 2009

0 @I00001@ INDI
	1 NAME Worth /Tucker/
	1 SEX U

Legacy 7

0 @I1@ INDI
	1 NAME Worth /Tucker/
		2 GIVN Worth
		2 SURN Tucker
	1 SEX U

RootsMagic 4

0 @I1@ INDI
	1 NAME Worth /Tucker/
		2 GIVN Worth
		2 SURN Tucker

These next lines start an individual (INDI) record (notice the 0 prefix). The ID between @ characters (ex: @I00001@) uniquely identifies this person record from any other person records in the file. The name of the person is indicated in one or two ways. The NAME tag requires the full name with the surname between “/” characters. The name can also be broken in given name and surname as represented by GIVN and SURN. Some formats set the gender or sex to U for unknown or don’t include the tag unless it is set.

Included in the individual record is the property ownership event:

Family Tree Maker 2009

1 EVEN 80 acres
	2 TYPE Property
	2 DATE 1908
	2 PLAC Elmo, Emery, Utah

Legacy 7

1 EVEN 80 acres
	2 TYPE Property
	2 DATE 1908
	2 PLAC Elmo, Emery, Utah

RootsMagic 4

1 PROP 80 acres
	2 DATE 1908
	2 PLAC Elmo, Emery, Utah

FTM and Legacy choose to use generic event tag with a corresponding qualifying type of “Property” whereas RM simplifies it by using the property tag. Both are equivalent. Each includes the property description of “80 acres” and the date and place of ownership.

GEDCOM supports the concept of a master source with its information and multiple citation details corresponding to an event. In part 1, this concept was shown in the application screens in two screens (FTM 2009 and Legacy 7) or a single screen with different colored top and bottom sections (RootsMagic 4). The way this is represented in the GEDCOM format is to have a separate source record with a unique id and to reference that source record for the specific event being cited. Additional citation details are then given. Notice that the below section starts at level 2 and appears in the file at the same level as PLAC and right below it. This signifies that the event being cited is the parent level 1 or the property ownership event.

Family Tree Maker 2009

2 SOUR @S00002@
	3 PAGE 179
	3 DATA
		4 TEXT In 1908 Eliza Oviatt filed on eighty acres and Worth Tucker purchased
			5 CONC eighty acres of an adjacent school section. These properties became
			5 CONC the Elmo townsite, platted into lots that were sold to prospective
			5 CONC residents for $10.

Legacy 7

2 SOUR @S4@
	3 PAGE 179.
	3 DATA
		4 TEXT In 1908 Eliza Oviatt filed on eighty acres and Worth Tucke
			5 CONC r purchased eighty acres of an adjacent school section. The
			5 CONC se properties became the Elmo townsite, platted into lots t
			5 CONC hat were sold to prospective residents for $10.
	3 OBJE
		4 FORM jpg
		4 FILE C:\Users\mtucker\Documents\RootsMagic downloads - test\historyofemerycounty-page179.jpg
		4 _SCBK Y
		4 _PRIM Y
		4 _TYPE PHOTO

RootsMagic 4

2 SOUR @S1@
	3 PAGE 179
	3 DATA
		4 TEXT In 1908 Eliza Oviatt filed on eighty acres and Worth Tucker purchased e
			5 CONC ighty acres of an adjacent school section. These properties became the E
			5 CONC lmo townsite, platted into lots that were sold to prospective residents f
			5 CONC or $10.
	3 OBJE
		4 FORM jpg
		4 FILE C:\Users\mtucker\Documents\RootsMagic downloads - test\historyofemerycounty-page179.jpg
		4 _SCBK Y
		4 _PRIM Y
		4 _TYPE PHOTO
	3 _TMPLT
		4 FIELD
			5 NAME Page
			5 VALUE 179

The source tag (SOUR) here references the source record with the unique id between the “@” characters. We will look at its details in the next section. The level 3s and higher are for the citation detail. This citation is from page 179 of the source and text from that page is represented by the TEXT tag under the DATA tag. The concatenation tag is used to break up lengthy text onto multiple lines. Both Legacy 7 and RootsMagic 4 export the directory path to the image file of page 179. This is done with the object (OBJE) tag which specifies that the format of the file is jpg. The next three tags begin with an underscore character “_” which means that they are custom extensions to GEDCOM made by applications and that other applications are not required to support them. It appears that both Legacy and RootsMagic have chosen to support these tags. The _SCBK tag indicates if this image should appear in the scrapbook or media viewer inside the application with a Y value signifying “yes”. The _PRIM tag indicates if this is the primary image which is shown in the application in situations where only one image about the citation is shown. The _TYPE tag identifies this as being a photograph as opposed to some other media type. RootsMagic 4 has done something above and beyond the other vendors. It supports a custom template tag (_TMPLT) which we will investigate in a minute.

Before we continue it might be helpful to review page 646 from Evidence Explained to see how the Book: Basic format is represented as a source list entry, full reference note, and short reference note:

Take just a minute to examine the fields for each type, formating, as well as the ordering and contents of the author field.

The final section of the GEDCOM file that we will examine is the actual source record:
Family Tree Maker 2009

0 @S00002@ SOUR
	1 TITL Geary, Edward A., A History of Emery County
	1 NOTE
		2 CONC Geary, Edward A..  A History of Emery County:  .  Salt Lake City:
		2 CONC Utah State Historical Society, 1996.

Legacy 7

0 @S4@ SOUR
	1 ABBR History of Emery County
	1 TITL A History of Emery County
	1 AUTH Edward A. Geary
	1 PUBL Salt Lake City: Utah State Historical Society, 1996.
	1 OBJE
		2 FORM jpg
		2 FILE C:\Users\mtucker\Documents\RootsMagic downloads - test\historyofemerycounty-frontcover.jpg
		2 _SCBK Y
		2 _PRIM Y
		2 _TYPE PHOTO
	1 OBJE
		2 FORM jpg
		2 FILE C:\Users\mtucker\Documents\RootsMagic downloads - test\historyofemerycounty-titlepage.jpg
		2 _SCBK Y
		2 _TYPE PHOTO
	1 OBJE
		2 FORM jpg
		2 FILE C:\Users\mtucker\Documents\RootsMagic downloads - test\historyofemerycounty-copyrightpage.jpg
		2 _SCBK Y
		2 _TYPE PHOTO

RootsMagic 4

0 @S1@ SOUR
	1 ABBR History of Emery County
	1 TITL Edward A. Geary, A History of Emery County (Salt Lake City: Utah S
		2 CONC tate Historical Society, 1996), [Page].
	1 _SUBQ Edward A. Geary, A History of Emery County, [Page].
	1 _BIBL Edward A. Geary. A History of Emery County. Salt Lake City: Utah S
		2 CONC tate Historical Society, 1996.
	1 OBJE
		2 FORM jpg
		2 FILE C:\Users\mtucker\Documents\RootsMagic downloads - test\historyofemerycounty-frontcover.jpg
		2 _SCBK Y
		2 _PRIM Y
		2 _TYPE PHOTO
	1 OBJE
		2 FORM jpg
		2 FILE C:\Users\mtucker\Documents\RootsMagic downloads - test\historyofemerycounty-titlepage.jpg
		2 _SCBK Y
		2 _PRIM N
		2 _TYPE PHOTO
	1 OBJE
		2 FORM jpg
		2 FILE C:\Users\mtucker\Documents\RootsMagic downloads - test\historyofemerycounty-copyrightpage.jpg
		2 _SCBK Y
		2 _PRIM N
		2 _TYPE PHOTO
	1 _TMPLT
		2 TID 372
		2 FIELD
			3 NAME Author
			3 VALUE Edward A. Geary
		2 FIELD
			3 NAME Title
			3 VALUE A History of Emery County
		2 FIELD
			3 NAME SubTitle
		2 FIELD
			3 NAME PubPlace
			3 VALUE Salt Lake City
		2 FIELD
			3 NAME Publisher
			3 VALUE Utah State Historical Society
		2 FIELD
			3 NAME PubDate
			3 VALUE 1996

FTM takes a shortcut and using the format specified for source list entry, puts that as the source note. The title (TITL) comes from how FTM automatically named the source when it was created. There are two things to note about the NOTE text: 1) it does not have a way to indicate that the book title should be italicized and 2) there appears to be extra periods and spaces in it.

Legacy 7 takes the approach of trying to stuff the EE-style citation into the fewer fields available for the “old-style” citation. There are 6 parts of a source list entry citation for a basic format book:

1. Author
2. Main Title
3. Sub Title
4. Place of publication
5. Publisher
6. Year

Legacy 7 implements the basic book template with the following fields (the last two pertaining to the citation detail):

1. Author Last Name
2. Author Given Name(s)
3. Author Suffix
4. Title
5. Short Title
6. Publisher City
7. Publisher State
8. Publisher
9. Publish Date
10. Volume Data
11. Page
12. Volume

The standard fields available in GEDCOM are:

1. Title
2. Author
3. Publication

So Legacy makes the following matches:

• GEDCOM Title = Title
• GEDCOM Author = Author Given Name(s) + Author Last Name + Author
• GEDCOM Publication = Publisher City + Publisher State + Publisher + Publish Date

Note that there is some formatting according to the source list entry and can be seen in the PUBL tag as it follows the order of fields and contains the colon and comma in the correct location. Also, the abbreviation (ABBR) tag is used to name the source in the master list after it is imported. The rest of the GEDCOM contents from the Legacy 7 file specify the 3 media files associated with the source. Nothing new there.

I have yet to do additional experiments to determine how the translation to “old style” citations works with more complicated citation formats.

Finally we look at RootsMagic 4. It also uses the abbreviation and object tags in the same way as Legacy 7. But some interesting things are happening in the rest of the file. Notice that the title tag follows the format for a full reference citation complete with parenthesis, commas, and colons. The title is between special formatting tags < i > and < /i > to indicate that it should be italicized. Where the page number should go is the textual placeholder “[Page]”. The custom subsequent tag (_SUBQ) contains the short note format although it should just contain the author’s last name. The custom bibliography tag (_BIBL) contains the source list entry format. It appears that a bug in the export is causing the bibliography entry to not show author with last name first. It is important to note that any application that imports a RM4-generated GEDCOM will get only the contents of the title tag and will have to manually edit it to remove the italicization indicators which they don’t support.

Now let’s get to the part where RootsMagic 4 has shown some innovation in their GEDCOM. Remember the custom template (_TMPLT) tag we saw for the citation:

3 _TMPLT
	4 FIELD
		5 NAME Page
		5 VALUE 179

There is also one in the source:

1 _TMPLT
	2 TID 372
	2 FIELD
		3 NAME Author
		3 VALUE Edward A. Geary
	2 FIELD
		3 NAME Title
		3 VALUE A History of Emery County
	2 FIELD
		3 NAME SubTitle
	2 FIELD
		3 NAME PubPlace
		3 VALUE Salt Lake City
	2 FIELD
		3 NAME Publisher
		3 VALUE Utah State Historical Society
	2 FIELD
		3 NAME PubDate
		3 VALUE 1996

Now compare that with the source entry screen:

Notice that in the yellow Master Source section, there are 6 entry fields: Author, Title, Sub-title, Publish Place, Publisher, and Publish Date. These correspond to the 6 template (_TMPLT) field name entries in the GEDCOM: Author, Title, SubTitle, PubPlace, Publisher, and PubDate. In the green Source Details section Page corresponds with the field name entry is the citation section: Page. The value tags contain the actual value. That way the details of knowing individual fields and values is not lost. Completing this is the template id or TID tag that is a unique number used internally by RootsMagic 4 to always refer to this template. That is why you can never edit existing templates in RootsMagic 4.

Here are the details of the template for id 372 as shown in the Source Templates screen:

It is interesting that each field is given a type to indicate if it is a Name, Place, Date, or Text. This could come in handy in future situations. Imagine searching all sources not just for the text “White” but for all sources that contain a name that contains “White.” Searches like that would return more appropriate results.

So what have we discovered is that the current three applications that support EE-style templates do so slightly differently on the input side (part 1) and vary greatly when it comes to GEDCOM output. As it stands today much is lost in the GEDCOM export rendering rich citations into blobs of text. RootsMagic 4 solves this problem in a proprietary way using its own template id and template fields names.  Currently no real interoperability exists between these applications when it comes to EE-style source citations.
This post is already long enough and I will likely expound on my ideas in a follow-up post. But imagine the RM4 implementation standardized and universally accepted. What a world of interoperability that would open up!

There is so much to think about. What do you think?

Instead of singing:

Que Sera, Sera,
Whatever will be, will be
The future’s not ours, to see

I sang:

Que Sera, Sera,
Whatever will be, will be
The future’s not hard to see

This personal joke has been used many times since then and has never failed to deliver a cheerful effect.

I think that the author and design leader, Bill Buxton, would agree that the “future’s not hard to see.” In his book, “Sketching User Experiences: getting the design right and the right design,” Bill stresses the importance of looking at least 5 years down the road when designing user experiences and adds:

Now most people say that you cannot predict the future, much less five years out. They use this as an excuse for not making the effort, or even contemplating it. I believe that this reflects a lack of training, technique, or responsibility on the part of design or management. (page 209)

He then goes on to quote William Gibson from an NPR interview on 30 November 1999:

… the future is already here. It’s just not very evenly distributed.

Buxton gives two examples. The first computer mouse was built in 1964 but didn’t reach widespread use until about 1995 – 30 years later. The idea for the CD came around 1965 but it wasn’t until 25 years later in 1990 that the industry reached $1 billion. From idea, to design, to prototype, to first production, to ubiquity takes time.

Bill then makes this statement that I would like us to consider:

If history is any indication, we should assume that any technology that is going to have a significant impact over the next 10 years is already 10 years old. (page 215)

 This made me wonder if this could be applied to genealogy software. What has happened over the last 10 years that could affect the design and innovation of genealogy software over the next 10 years?

At first nothing came to mind, but then I thought of Elizabeth Shown Mills’ book, “Evidence! Citation and Analysis for the Family Historian” which was published in 1997. In 2007, the much expanded “Evidence Explained: Citing History Sources from Artifacts to Cyberspace” was released. We are now beginning to see specific examples of Elizabeth’s work showing up in genealogy software. In a podcast interview by Dick Eastman, Elizabeth Kelley Kerstens indicated that the software Clooz version 2.x was influenced by handouts she received from Elizabeth Shown Mills. Another example is from a podcast by DearMYRTLE where she interviews Geoff Rasmussen about Legacy version 7. In this interview, Geoff gives a sneak peek of one of the major new features which is source citation following the standard set by Elizabeth Shown Mills. There is still much work that needs to be done in this area such as online databases providing better source citations. I talk about this in my previous post about Jumping Curves. So you see, the future is not so hard to see.

Another area that I want to point out is the Genealogical Proof Standard which was also created in 1997 by the Board for Certification of Genealogists. Other than its use in the certification process, you don’t hear much about it. But this standard is useful to researchers of all levels to help them get as close to the truth as possible. At some point genealogy software designers and developers will realize this and incorporate it into future genealogy software.

There are probably many more examples of ideas, technology, and methodology that exists today that will help us better see the future of genealogy software.

What things should be added to this list?

As a genealogy community, I hope we aren’t thinking:

Que Sera, Sera,
Whatever will be, will be
The future’s not ours, to see

Share your thoughts as the future is ours to see.  I hope that is not hard to see.