Some UNIGEDS rules

[Uncle Buddy]

The purpose of UNIGEDS is to correctly define the relationships among primary genealogical data elements. The definition of relationships, i.e. "cardinality", refers to whether a pair of data relate to each other on a one-to-one, one-to-many, or many-to-many basis. By limiting the scope of UNIGEDS to only primary data (elements of the real world which pre-exist genealogy such as persons, place, events, sources, names, assertions, citations, etc.) UNIGEDS becomes a naturally universal genealogy data structure which can serve as a data storage-and-retrieval back-end for any number of new and revamped genealogy applications, and can also replace GEDCOM so that only secondary data needs to be imported and exported between applications by means other than UNIGEDS. Fortunately, most secondary data only serves the needs of the application that generates it, its graphical interface, its vendor, and its user, and should not be imported or exported at all. By limiting the scope of UNIGEDS to importing primary genealogy data, and by carefully defining the relationships among its elements to conform to the relationships between the real-world elements represented by the data, we can ensure the universality of UNIGEDS.

Fortunately we have many years of the growing GEDCOM problem to study as we design UNIGEDS to not mimic the inadequecies of GEDCOM. These shortcomings are due to GEDCOM's not knowing its own limits, not following its own patterns consistently, trying to solve problems by adding complexity instead of simplifying, and not accurately reflecting the relationships among real-world elements (cardinality). The obvious absurdity of incrementally improving GEDCOM till it finishes ruining computer genealogy as a pursuit-worth-doing means that the time is now to bite the bullet and switch to UNIGEDS, accept the pain of transition, and stop relying on GEDCOM as the primary data transfer tool between applications.

For the UNIGEDS transition to be feasible, it is necessary to follow the rules when using it. 1) Vendors can't add columns to native unigeds.db tables. 2) Vendors can add tables to unigeds.db only when reference to unigeds.db primary keys is necessary. 3) Vendors must store secondary data that makes no reference to unigeds.db primary keys in a separate structure from unigeds.db, such as a different SQL database, text files, JSON, or whatever.

The power of UNIGEDS is not that it enables importing and exporting of data, but that it makes importing and exporting of data unnecessary. When two applications use the same back-end for their data, they can open and use each others' databases as-is. That's not importing and exporting, that is real sharing.