Never one to refuse a challenge, here are some starting thoughts. To my mind these could apply to any genealogical "wiki" more-or less irrespective of its specific purpose. NB according to the wiki (disambiguation) page on wikipedia: https://en.wikipedia.org/wiki/Wiki_(disambiguation) "A wiki (or wiki wiki) is a collaborative website." and I feel they probably ought to know! Hopefully this stalking horse has enough flesh that anyone interested can add / challenge what's there... NB I have indicated whether the option is currently fully available in Familysearch (Y), partially available (P) or not available (N) 1. 2. Moderation by appropriately experienced genealogists i.e. having had at least two articles published in peer reviewed journals. Rationale - we are borrowing those journals' due diligence procedures: in time we could probably add our own. (FS _ N) 2. ability to nominate specific "owner" moderators with power to review all changes before they take effect. (NB this effectively requires a parallel data set showing the effect of unapproved changes) (FS - N) Within this, electronic import of data ONLY permitted after such data has been reviewed by a moderator. Rationale - we don't want to make life needlessly difficult but we don't want wholesale import of rubbish. (FS - no controls I think) 3. Data to be structured so as to allow: a. each element to be sourced. (FS - P) b. multiple alternates for elements such as dates, places, names etc. (FS - P) c. identification of individuals in long-form e.g. "Mary Smith who was married to John Smith of Somewheresville at some point in the 15th century according to Surtees" (FS - N) d. merging that preserves data as alternates (FS - N) e. bitlock style data history to ensure auditability (FS - P) f. data deletion to require justification (FS - P) g. ability to "watch" individuals / families with notification of others' changes (FS - Y) h. ability to reserve individuals that users are working on. (FS - N) i. provision for alternate "universes" where data is capable of more than one interpretation, ideally with ability to view side-by-side (FS - N) j. automatic recognition / translation of old and new style dates in appropriate periods (FS - N) k. multiple fields / flags for "families" and or "lines" to help with searching e.g. "descendant of charlemagne" or "ancestor of pilgrim father" (FS - N) 4. data elements to be colour-coded according to source: e.g. reddish - no source; orangey - secondary source; yellowy - primary source transcription; greeny - primary source viewed; bluey - primary source image attached. Fixed formats for sources defined by moderators. (FS - N). 5. A separate place name database, subject to similar rules as regards sources, with different matrices e.g Saxon shires & hundreds, Domesday, English historic, English administrative pre-1973, registration districts etc. with relevant dates. (A particular bug-bear of mine stemming from being a Geographer at heart) (FS - P) 6. ideally linked archive of sources in public domain to permit internal rather than external links. (FS - P) 7. Users wishing to link "out-of-period" or "not famous" descendants to a tree on a different platform should be required to show evidence for the link and where appropriate make their tree viewable on the other platform. (FS - N) Have Fun James

On 04/07/16 12:56, WJH wrote: > d. merging that preserves data as alternates (FS - N) Aaaargh! You don't merge people - it's a nonsense concept. So you can't merge records of people, otherwise you have a data model that doesn't model what it sets out to model. Admittedly this is a factor that seems to be ignored by just about all genealogical software, but then they all seem to have the same problem. If you make an error how do you demerge them? If you have two source records which you think apply to the same person you have a record for each. You also have a record for the person you think they represent. You then have link records which link the source records to the people records*. If you then decide one of the links is wrong you can simply deprecate it or even delete it entirely. A huge problem with existing genealogical software, be it structured or wiki-based, is that it facilitates, if not positively encourages, jumping to conclusions. Genealogical research starts with evidence. If we are to start a collaborative approach let's have one that starts with evidence. *I oversimplify. What you actually need is a record or records for the text and/or image of each original document, supported by a hierarchy of records giving its provenance. You then need a record for each individual named as playing a role in the source. Even deriving these isn't as easy as it seems: without digging out the exact text I have a record dealing with the disposal of the property of a John Godard d 1328. It mentions the property of John Godard in a context which doesn't make it clear whether this is the deceased (e.g. the said John Godard) or another and in the context I'd keep them as separate references. You then have a separate set of records which represent the people you think existed and link these to the name records from the texts. Apart from being a non-destructive option to merging it enables you to express possible alternative interpretations. In the example I gave above I know from other records that there was a second John Godard, son of the deceased so it would be feasible to link the role record to both of these. -- Hotmail is my spam bin. Real address is ianng at austonley org uk

On Wednesday, July 6, 2016 at 1:16:20 PM UTC+1, Ian Goddard wrote: > On 04/07/16 12:56, WJH wrote: > > d. merging that preserves data as alternates (FS - N) > > Aaaargh! You don't merge people - it's a nonsense concept. So you > can't merge records of people, otherwise you have a data model that > doesn't model what it sets out to model. Admittedly this is a factor > that seems to be ignored by just about all genealogical software, but > then they all seem to have the same problem. If you make an error how > do you demerge them? > Well Familysearch seems to be able to demerge people and my guess would be that the bitlock technology I've mentioned would also allow it since it retains every change made to the data. > If you have two source records which you think apply to the same person > you have a record for each. You also have a record for the person you > think they represent. You then have link records which link the source > records to the people records*. If you then decide one of the links is > wrong you can simply deprecate it or even delete it entirely. > > A huge problem with existing genealogical software, be it structured or > wiki-based, is that it facilitates, if not positively encourages, > jumping to conclusions. > > Genealogical research starts with evidence. If we are to start a > collaborative approach let's have one that starts with evidence. > > *I oversimplify. > Thankyou! I accept I was envisaging a database of "people" comprised of data "fields" (e.g. name) linked to "sources" whih might be refernces or might be scanned images, largely because as you say that's how most genealogical databases are structured, at least on the surface. What you're suggesting below, if I understand you aright is that the sources should stand separately from the people and the genealogists' job would be to link them together. For me the ironic thing is that this almost exactly describes how Familysearch is structured. They have records datasets e.g. a census which in some cases link to images on their or another site. They also have a list of people to whom you can link the records and if the record contains new data for the individual, it will populate it for you, based on what has been transcribed (which in most cases is less than is available if you can see the image). What you can't do (at the moment) is link the same record to two people at once. What I don't know is how genealogists can add sources in a way that makes them viewable by others, but that's because I haven't got to that stage yet. Perhaps it would be worth you taking another look at FS, if only so that you can correct any misunderstanding... > What you actually need is a record or records for the text and/or image > of each original document, supported by a hierarchy of records giving > its provenance. > > You then need a record for each individual named as playing a role in > the source. Even deriving these isn't as easy as it seems: without > digging out the exact text I have a record dealing with the disposal of > the property of a John Godard d 1328. It mentions the property of John > Godard in a context which doesn't make it clear whether this is the > deceased (e.g. the said John Godard) or another and in the context I'd > keep them as separate references. > > You then have a separate set of records which represent the people you > think existed and link these to the name records from the texts. Apart > from being a non-destructive option to merging it enables you to express > possible alternative interpretations. In the example I gave above I > know from other records that there was a second John Godard, son of the > deceased so it would be feasible to link the role record to both of these. > > -- > Hotmail is my spam bin. Real address is ianng > at austonley org uk