FSDN (Family Search Developer Network, part of the LDS)
FSDN is rumored to have a genealogical data model that it may make public at some future point.
After the RootsTech meeting of February 2011 there was a large flurry of activity on the FSDN mail group about genealogical data models.
Most of the posts to the mailing list are typical naive huff and puff about what the model MUST be and what the industry MUST do and so forth, but among the chaff there are a few thought provoking points to read. You can join the FSDN and get on the mailing list by visiting https://devnet.familysearch.org/
Valuable analysis by twetmore:
If you register at FSDN you can read their API documentation. There is a great deal of info here that discusses both the details of their APIs and the details of their data model. The model is all described around an XML schema.
The current FSDN API is based on allowing client programs to access and modify the FamilySearch's Family Tree. This is FS's answer to other attempts to define the family tree of humankind. Warning: the FS big family tree is just as junky as everybody else's. GIGO all the way.
They define their API around three modules:
Family Tree -- this is the API that accesses the big family tree.
Authorities -- this is the API that lets you access "experts" in the areas of personal names, dates and calendars, and geographical places.
Identity -- this is the API that allows a client program to gain access to the Family Search back end services.
So the API allows you to download info from the tree, add new persons to the tree, add new facts about persons already in the tree, and so forth. The API for all of these operations involve downloading or uploading information about persons to the FSDN servers. All this information is transmitted in XML format adhering to the FSDN data model. Yes, there is an FSDN data model and you can read about it in detail in their documentation.
That data model is fairly conventional. Its glossary is fun reading to see how they have chosen words and how they contrast to the words we use on Better GEDCOM. For example they use the term "assertion" as the overall word for all PFACTs in the Better GEDCOM terminology. That category is then broken down into different kinds of PFACTs like characteristics, citations (a term they completely wrongly, as a synonym for source), events, and so forth.
Two very interesting things about their model. First includes a "two-tier" system for combining person records. They use the terms "person" and "persona" for this. A "person" can either be a collection of "assertions" or it can be a collection of "personas". Personas are created when users believe that two persons in the family tree are the same person so they request them to be combined. Instead of merging the info from the two persons together, a new person record consisting of the two personas is created. This is really orthogonal to the "evidence and conclusion" process in a strange way.
Second they continue GEDCOM's ultra-simple concept of event as a single-role attribute of a person. In other words the model is still in the dark ages. Every person, even when not made up of multiple personas, is a conclusion object. You can create persons that are in effect evidence persons (from one source), but there is no requirement to do this, so evidence records are really not a concept in this model at all. It therefore is pretty useless as a serious model for research. But then again there is no attempt or apparently economic need to make these large, garbage-based, family trees of all mankind rigorous. It's too bad that Family Search is taking this route, when they could be working on building these mega family trees based on their own combination of information from all the raw evidence sources now available in their databases. Such family trees could be built up using the firm foundation of bedrock data before their contents are tweaked by data coming from untrusted sources. I have written an article about how these very rigorous trees can be build with automatic combination techniques, an article you can find on my DeadEnds web page.
Well, I don't want to go down the path of writing a long description of their model and API, but it is easy to read about, and after awhile you can get used to the documentation. I would recommend anyone interested to register as a FSDN developer. It's free and puts you under no obligation. Once you register you have free access to all their documentation.