The tool formerly known as the "Universal Genealogy Transfer Tool"
The goal of Rosetta is to provide support for users of popular genealogy programs to freely and easily move their data from one supported application to another.
Isn't that what GEDCOM is for?
Sort of. According to Wikipedia, gedcom is an open de facto specification for exchanging genealogical data between different genealogy software. GEDCOM was developed by The Church of Jesus Christ of Latter-day Saints (LDS Church) as an aid to genealogical research.
The problems with GEDCOM are:
- It is controlled by one group - the LDS Church. Nothing against them, or their support of GEDCOM, but it is "their" standard and not able to be extended/adapted by others, at least not easily
- GEDCOM was developed in 1984 and last updated in 1996. Things in the technology and genealogy worlds have changed since then, but GEDCOM has not.
- The standard itself is extremely dense and academic. Writing a fully GEDCOM-compliant parser is difficult. No two software products currently on the market read/write GEDCOM exactly the same way, and trying to import a GEDCOM file exported from one program into another program will result in lost data, often without advance warning.
- The GEDCOM specification defines a minimum set of attributes. It does not support all of the data and features added to popular genealogy programs.
- Various attempts to update GEDCOM (primarily v6, and GEDCOMX) suffer from most of these same problems.
- GEDCOM is based on old EDI (Electronic Data Interchange) schemas.
Rosetta to the Rescue!
Rosetta is taking a different approach. Instead of attempting to be an all-encompassing, open format for data exchange, Rosetta is designed as a hub-and-spoke model where a common, open/extensible storage format forms the hub, and pluggable connectors to each supported application act as the spoke. Each application-specific plugin is tasked with handling the work necessary to:
- Read data from the source application by connecting directly to the source database
- Massage that data into the JSON format defined by Rosetta (as specified in the JSON-schema files).
- Pass the massaged data to Rosetta-Core, which will store it on disk
- Receive data from Rosetta-Core
- Massage the data into the format required by the target application
- Write the data directly to the target application database
The goals of Rosetta are simple:
- Simplicity for the end-user. This goal wins over all other considerations
- Openness: open source, open license, open extensibility, open communication.
- Owned by no one and everyone
Architectural / Technical Goals
- Run on Mac, Windows and Linux
- Program will be a standalone executable. Eventually a free web version may be offered.
- Open Source - anyone can contribute. Project leadership will be open to significant contributors who are interested
- Plan for extensibility right from the beginning
-- More information, including design/architecture documents will be posted soon.
Initial plans call for applications to be targeted in the following order:
- Roots Magic 7.x
- Legacy Family Tree 9.x
- Family Tree Maker (version TBD - need a way around their silly encryption)
- Others TBD
Miscellaneous / Other Technical Notes
Rosetta is a work in progress. Here are some random thoughts still to be incorporated into documentation:
- Data will be stored in JSON files
- JSON schemas will follow the tenets of the JSON-Schema project available here: http://json-schema.org/
Interested in helping out? Here's how you can join us:
- Request access to our Slack workspace <-- This is where the team is communicating!
- Join our Facebook Group
The most recent information on milestones is available here: https://github.com/OpenGenOrg/rosetta/wiki/Status
Is this Legal?
Some may wonder whether it is legal for software to connect directly to the database of another proprietary application and import/export data. While we have not officially contacted a lawyer, and are not lawyers ourselves, we believe that there is precedent already in place (Roots Magic importing FTM files) and the law is pretty clearly on our side (at least according to a lay-person's reading of Sec. 103(f) of the DMCA (17 U.S.C. § 1201 (f) - https://www.law.cornell.edu/uscode/text/17/1201 and other legal texts), it is still a possibility that someone will not like what we're doing and so we felt we should mention it. Provided that this remains a non-commercial endeavor used solely for individuals to manipulate their own data, we feel this is not going to be a problem. There is the possibility that one of the applications we are targeting will object to this project as it means that they can no longer lock users into their application, though we think this is unlikely (and narrow-minded and not very user-friendly, either).