@Robert Shaw:

There are actually quite a large number of data interchange standards in addition to GEDCOM, which has been effectively abandoned at version 5.5 since 1996[1]. (FamilySearch's GEDCOM X[2] may fairly be assumed to be the LDS's current model, retaining the nuclear family/individual approach.) GeneWeb's GW format[3] has some support as an interchange, for example Gramps[4] can both import and export .gw. Gramps itself has a more-widely supported Gramps XML[5]. There are an almost uncountable number of GEDCOM extensions, and similarly there is a continuum of personal data standards which are suitable or extensible for purpose, e.g. vCard[6] and iCalendar[7].

Most standards commonly used for genealogy focus on nuclear family units. Another approach is relationships, and a third is event-driven, though all standards involve at least some support for all three. Here are a couple of questions for genealogy data, though: * Locations change name (and nationality) over time - should a genealogy standard take this into account? * Parentage is changing as we learn more about genetics; a child was born recently with genetic material from three individuals.[8] How should this be represented? * In a similar vein, between 1 and 2 percent of humans are neither male nor female by traditional measures[9]. (That is roughly 3x the number of people who have AB- blood type, to give you a comparison. It is also more than the number of genetically redheaded people.) How should this be represented? * Legal issues are also complexifying: there are now many children in the USA, Canada, and elsewhere who list multiple parents on their birth certificates[10], and sometimes non-traditional rôles such as birth mother or donor father. Again, how should these be recorded?

(What's the data product of Wikipedia, for instance?)

Well, taking Wikipedia as an example, there are four primary data products: * The human/machine readable html interface * The two machine-oriented api interfaces * The various formats of database dumps * The definable collection .pdf output.

In addition there are a range of mostly statistical products which are more meta than content. But mostly it is a library of hyperlinked articles about everything.

Find-a-grave is a library of databases of headstones, with optional hyperlinking and text articles and photographs. Ancestry.com is indexes to repositories of documents and GEDCOMs. And so on. Genealogy is a multi-disciplinary effort, and I wonder what areas of it we would be interested in creating and curating: crowd-sourcing transcriptions of Census documents may be one idea, but so is developing a public gene heritage database hosted on Wikidata with DIY mail-in swab kits.

@Sam Wilson: Actually, your arguments about the UNIX way are one of my arguments against Mediawiki for genealogy - MW handles text reasonably well, but not structured data. For that matter, instant commons is an accretion to allow something which MW does not do well - share objects across instances.

The primary benefit of instant commons is offloading the cost of curating the media files, but in exchange for giving a different project (with different goals and missions) control over what media files you may have. This may work well enough for a genealogy project, but it also shows a point at which a genealogy project cannot 'do one thing and do it well.' The concept of involving Wikisource for transcriptions, Commons for source documents, Wikidata for many elements, and then a separate MW instance for the presentation layer sounds great, but I expect it would be pretty brittle and fragile in practice.

@Michael Smith: there are reasons to have hidden/private individuals: living persons and the recently deceased being two of the most obvious. That of course does not defend (nor condemn) private family trees. One thing done by Ancestry.com is to use private trees as a source of 'hints', and to improve the accuracy of hints for both public and private trees - e.g. if a private individual is linked to a given social security number, it is of greater likelihood that an individual in a public tree with multiple close correlations has the same social security number.

Personally I would like to build a series of api which can be knit together - one for people data, one for graves/cemeteries, one for media assets, one for places, one for events... and likely others. These could be MW extension, or maybe Slim[10], but the point being to allow maximum flexibility for data CRUD, and allow many options for presentation - including but not limited to Mediawiki.

[1] https://familysearch.org/developers/docs/gedcom/gedcom55.pdf [2] https://github.com/FamilySearch/gedcomx [3] https://geneweb.tuxfamily.org/wiki/GWformat [4] https://github.com/gramps-project/gramps [5] https://gramps-project.org/xml/ [6] https://tools.ietf.org/html/rfc6350 [7] https://tools.ietf.org/html/rfc5545 [8] https://www.nytimes.com/2016/09/28/health/birth-of-3-parent-baby-a-success-f... [9] http://onlinelibrary.wiley.com/doi/10.1111/nin.12184/full [10] http://www.huffingtonpost.com/2014/02/11/baby-with-3-parents-birth-certifica... [11] https://www.slimframework.com/ (https://github.com/slimphp/Slim)