WikiTree:Treehouse/Archive 1

From WikiTree, the Family Tree of Humankind

This is an archive of old discussions, for the currenttreehouse see Wikitree:Treehouse.

Contents

WikiTree is awesome

  • I imagined something like this a few years ago, but only found disappointing commercial sites. Today I searched, and amazingly came upon WikiTree!! I hope soon everyone can learn how closely related we all are. Krubo 08:20, 15 May 2005 (CEST)
So did I, in recent months, and I thought I would go try to develop one of my own before I actually found WikiTree. Glad to be here. And thanks to whoever set this thing up! — FJ | hello 22:40, 18 May 2005 (CEST)
  • Good to see you here, soulmates. I got totally frustrated by the fact that even though genealogical information is so popular around the Internet, it is very hard to get anything useful without having to go through login procedures and even then getting only a glimpse of the content before being asked for money. Enchanted by the beauty that is Wikipedia, I then looked for a place that would provide genealogical information that is free for anyone and free to edit by the the very people who contribute to it. Since I did not find any, I started WikiTree. Let's make it into a great resource and tool, so that other people find it useful and get involved. --Vacilando 00:12, 20 May 2005 (CEST)
  • WikiTree page views in May 2005
    Enlarge
    WikiTree page views in May 2005
    26. May 2005: WikiTree is one month old! Thanks to everybody who has so far contributed to the growth and refinement of its vision and the community. It has been an amazing success so far in terms of interest in the idea, contribution, and access (the server logs report 3410 unique visits and 24583 page views so far). Let's keep the good work going! --Vacilando 00:33, 27 May 2005 (CEST)

Publicity & branding

Help! How can we increase publicity of WikiTree?

  • I have linked from the Genealogy page of the English, Spanish, French and Portuguese Wikipedias. Where to try next? Krubo 02:45, 17 May 2005 (CEST)
  • I have added links to other language versions of Genealogy, and to several language versions of Family tree. --Vacilando 21:09, 28 May 2005 (CEST)
  • If we can get InterWiki to work (see below), then WikiPedia articles can also be a form of publicity. — FJ | hello 23:24, 18 May 2005 (CEST)
  • Great! --Krubo 03:54, 19 May 2005 (CEST)
  • Hmm, would it be possible to tweak the template used for biographical entries in Wikipedia so that it automatically (using InterWiki?) links to WikiTree? Anybody knows how to go about that? --Vacilando 01:06, 20 May 2005 (CEST)
  • By making the basic data entering (and any instructions) extremely straightforward and quick. That will mean more people who visit will contribute. Growth (in size and in complexity) itself will be a great publicity for WikiTree. --Vacilando 00:38, 20 May 2005 (CEST)
  • By placing links to WikiTree (http://www.wikitree.org) on other web pages - mention it on your websites, blogs, discussion forums, wherever relevant. That will increase the Google PageRank (or equivalent in other search engines) and so boost visibility. --Vacilando 01:02, 20 May 2005 (CEST)
  • I asked someone I know to consider placing WikiTree favorably somewhere in the Yahoo Directory (today it doesn't appear anywhere in a dir search). I'm reasonably sure it will be done this week. — FJ | hello 05:09, 20 May 2005 (CEST)
  • Check it out. I guess it's technically from the users of Wikipedia though...
  • Not totally correct about the "creator of Wikipedia" but who cares? This is very good!! --Vacilando 08:02, 25 May 2005 (CEST)
  • We need a sexy logo for WikiTree. Anybody with the right skills plus a very good idea - show us your proposals! --Vacilando 22:52, 20 May 2005 (CEST)
  • This always happens to me - I was just looking at a user page for the guy who did many of the other Wiki sister project logos, even perhaps the current WikiPedia logo, and he sounded quite open to that kind of thing. BUT I didn't note his name! I will try to retrace my steps. — FJ | hello 01:59, 25 May 2005 (CEST)
  • Cool! In the meantime I asked an artist friend, who on top of that is also a community creation professional, if he can supply some proposals for logos. It would be best to have several candidate images and vote on them over a period. --Vacilando 08:02, 25 May 2005 (CEST)
W over T, doubling as a three-level ancestry? Mysha 18:09, 2 Jun 2005 (CEST)
You mean something like this? I know there'd be names, but I was just trying to get a visual idea put up here for it. Janizary 04:56, 3 Jun 2005 (CEST)
Just to add to the madness, I think a logo something like this may be nice.
Of course the names and fonts are not the big thing, but I think having a curved leaf would be nice to have within the icon used in the header. A snippet of tree in the background with a leaf behind the name looked nice, so I thought I'd toss it out there for consideration. Of course, a real artist would be able to make a nicer looking one. I just made a cheap picture so I'd not have to try to describe my idea too much. Janizary 02:29, 3 Jun 2005 (CEST)
  • Mysha, Janizary: good thinking! To me, the first is a good idea, but the second also looks visually very pleasing, also thanks to the font. One important reservation for both of them (wanted to answer Mysha yesterday already): I guess it is important not to rely on English language for the logo. So if there is text in the logo, it could be thai, russian, chinese, hebrew and latin... perhaps. Or maybe we can go away from text altogether. --Vacilando 07:59, 3 Jun 2005 (CEST)
(Yes, something like that.) Janizary's own idea is probably a step in the right direction. Having the text on the leaf makes the text a bit harder to read, though, and indeed depends on the language. The leaf showing as generation-0 of a family tree (partially shown), with the name just below the leaf? The tree could have the names just showing as bars. Mysha
  • Janizary - I thought maybe we could use your logo for the time being - until we have any better idea; what do you think? For that, we would need you to post a png version with transparent background (not white). And maybe you could change the script of some of the names - e.g. Chinese, Russian, Arabic or Thai, or even Egyptian, for fun --Vacilando 12:55, 12 Jun 2005 (CEST)
  • Unfortunately I didn't keep the graphic of the leaf or anything after I made it, since it was just to display an idea. I could make another, but it would turn out different. Would you like me to? Janizary 04:08, 13 Jun 2005 (CEST)
  • I consider it a good idea for the logo to have some sort of visual similarity to logos of some other wiki projects. An example would be combine Janizary's logo with the Wikipedia logo: a globe of interlocking puzzle pieces with the family tree from Janizary's logo proposal "wrapped" onto it, the font would be the same as the Wikipedia logo's font, and the caption would be Vacilando's page subtitle ("WikiTree, the Family Tree of Humankind"). This is just one idea, and maybe too difficult to flesh out, but it's what crossed my mind. --JohnAlbertRigali 09:02, 24 Jul 2005 (CEST)
  • I have added subtitle "From WikiTree, the Family Tree of Humankind" that now appears on all pages. Is the text OK - comments? --Vacilando 14:45, 4 Jun 2005 (CEST)
  • It's an excellent subtitle! Very catchy! --JohnAlbertRigali 09:02, 24 Jul 2005 (CEST)

Multilingualism

  • We should welcome all contributors regardless of language. Sharing one WikiTree makes it far easier to include as many records as possible. Fortunately, the essential content of WikiTree (vital statistics) is very simple, and can lend itself to language-neutral presentation (either symbols or automatic translation). For now the most pressing task is probably translating the main page into as many languages as possible. Krubo 12:25, 16 May 2005 (CEST)
  • Absolutely, this has high priority. But I think before we start translating, we need to get the main page to a very stable state. It is still very rough and wordy and many of its components are bound to change. I propose to reduce its size by moving some (esp. those that are likely to change often) to separate pages (such as the external links, etc) and keep just the most important stuff - presentation of what WikiTree is and aims to become, and the entry points such as alphabet / category browsing, and the entry formatting (that will be the same in all languages, or the multilingualness can be solved automatically by a smart template). --Vacilando 01:15, 20 May 2005 (CEST)
  • True, I don't want to waste our time translating things that are about to change. I'm just a bit worried, because I want us to steer far away from the problems of WikiSource, which recently voted overwhelmingly for dividing into language subdomains, and WikiSpecies, where many people are already complaining about the English-dominant setup. --Krubo 14:17, 20 May 2005 (CEST)
  • Without knowing the software, it seems to me that on pages with multiple translations, the software should be able to return whichever translation is appropriate based on a user's language settings, so links from untranslated pages (like Treehouse) do the right thing for all users. --Krubo 14:17, 20 May 2005 (CEST)
  • If we agree we have a good basic structure for the Leaf code I think we can focus more attention on the translations / language variants. First of all, I propose to fix the Main Page asap so that we are all happy with it. It should be short, contain crucial information, be as timeless as possible. As soon as we are there, I will immediately translate it to Slovak, Czech, Dutch, maybe French. I am sure others will be able to contribute other languages. Major world languages will be important - including Spanish, Russian, Chinese. Then we can start translating it. We can make subdomains (e.g. en.wikitree.org) in the way Wikipedia does. What do you think? --Vacilando 09:19, 26 May 2005 (CEST)
  • Yes, a translated main page is immensely valuable. Once we are there, I'll work on Spanish, Portuguese and others. As for subdomains, I certainly don't want subdomains, because I hope all of us can collaborate on the same WikiTree. I think the content pages, like Vincent van Gogh should be just one content page for everyone, not :en:Vincent van Gogh, :es:Vincent van Gogh, etc., whereas the subdomains in wikimedia (wikisource, etc) make each language fully independent of the others. In fact, I have not found a wikiproject that deals with multilingual content presentation very well at all. So, my dream is to make WikiTree a pioneering project in this.
I'd like to have a system where interface language is set by each user, or automatically set from browser settings (wikimedia bug 1135), so that http://wikitree.org/ can show up in the appropriate language for everyone, automagically. Translated pages, like the main page, could be located at http://wikitree.org/Main_Page/en, /es, etc., and the main page /Main_Page itself could hold an extension to display the appropriate language version if available...
If we are to be one community, then talk pages and places like the Treehouse need to be multilingual, meaning comments are welcome in any language, as well as requests for/translations of comments where needed. --Krubo 17:07, 26 May 2005 (CEST)
  • It really should be possible to link to pages other than en: under the "Wikipedia link" code. --Hattrem 23:10, 28 May 2005 (CEST)
  • I've posted a patch for this on Talk:Leaf Extension Code. The syntax will be "Wikipedia link = es:Diego Rivera" or "Wikipedia link = es:". Also, I suggest we should try to avoid the current English-default syntax. --Krubo 00:29, 29 May 2005 (CEST)
  • And I just got the patch to work, so now this functions as requested - see my comment there. --Vacilando 12:35, 29 May 2005 (CEST)
  • Great - I see WikiTree has now also a Spanish front page! Two comments: 1) before translating to languages I know, I have updated, shortened and (hopefully) improved the text on the Main Page. Please comment if anything is wrong or should be changed. 2) I think the box with the languages should be changed or placed differently because now it visually clashes with the "WikiTree wants You" box. What do you think? --Vacilando 14:42, 4 Jun 2005 (CEST)
  • WikiTree has now also a Russian front page! And I think that subdomains is not a bad idea. It'll be not looking good when you go to other page, which accidentally at other language because your language is absent (sorry for poor English). --Phoenix 16:23, 7 Jun 2005 (CEST)

Discussion page name

  • I called it Treehouse on a whim. Post preferred names if you like. Krubo 08:20, 15 May 2005 (CEST)
  • I think it is excellent for a start! If a more suitable arboreal metaphor pops up in the future, we can always rename it. --Vacilando 00:45, 20 May 2005 (CEST)

Privacy

  • I wonder how we can deal with Privacy issues. I know people who certainly don't want any biographical or genealogical data about them posted while they're alive. Maybe the 'edit' page copyright warning should also warn something about this? Krubo 08:20, 15 May 2005 (CEST)
  • This notice would be a good first step. Would it be feasible or advisable to set up a way to mask leaves or branches from anyone but the creator of an entry, and put this into effect only for individuals who are alive and opt for it? Might even be worthwhile pushing to have this be default, since we are living in the age of identity theft and minimal information is all that's needed. — FJ | hello 22:37, 18 May 2005 (CEST)
  • I guess I'm a fan of privacy being the exception, not the rule, but we'll watch out for this issue. Also, if someone doesn't want their data available, perhaps it shouldn't go in WikiTree at all (so we aren't a valuable hacking target). --Krubo 03:54, 19 May 2005 (CEST)
  • I think the rule of thumb is: if the source information is public, it can be re-published. Besides, all we aim to display in the basic profiles is name, DOB / DOD and at least some family links. (Anyway, only a fool would put an e-mail address or other sensitive stuff plain on the Internet nowadays.) --Vacilando 00:24, 20 May 2005 (CEST)
  • I totally agree with you guys, BUT since DOB/maiden name info is all that's needed for a resourceful ID thief to get started, we should at the very least define WikiTree's policy, perspective and guidelines somewhere because there will be many paranoid inquiries I am sure. — FJ | hello 02:02, 20 May 2005 (CEST)
  • Is it possible for WikiTree to become a target for lawsuits, if indeed it does become a people information goldmine for marketers and thieves? I think this should be cleared up earlier rather than later - could we lean on the folks over at WikiPedia or WikiMedia who worked on the licensing and copyrighting areas? I strongly suspect that WikiTree will end up recommending that people do NOT include living person data, sooner or later. — FJ | hello 23:14, 20 May 2005 (CEST)
  • Indeed we should get this cleared up sooner rather than later. But I certainly hope we can include living people: my vision is for any pair of people to be able to discover they are fourth cousins-in-law, and I expect most such paths depend on links through various other living people... --Krubo 05:24, 21 May 2005 (CEST)
  • I read that there are relatives of Adolf Hitler living in Austria and the United States (childs of nephews or something like that). They changed their name and of course they want to stay unknown. Please provide a clear warning that every information about living people can only be inclued if they agree or if the data has already published with their agreement I know in Wikipedia people already try to sue because somebody put information about their real name and age into an articles. You better avoid this - there are enough dead people and those who don't mind so focus on these only!
  • Thinking about the privacy issue.
How about issuing a unique number to those who want to be in the tree but not their actual full name? Especially for those still alive.
How could this be made to work?
  • Unique numbering is certainly one alternative. Another is a "shield" concept (maybe with a leaf icon in place of name and details?) whereby "owners" of the living person data are entitled to view its details but no one else. Individuals below or above this level reserve the right to shield or not shield their data, and also control who else may be permitted to see it. If they happen to die before unshielding...I don't know. This sounds like a big effort to me, but again I think it's one of those things which could make a world of difference. — FJ | hello 02:04, 25 May 2005 (CEST)
  • The unique numbering thing is a good idea. I think unique numbering is needed for the page URLs anyway to avoid duplications and such. Once a number is assigned, it could be used for other bits on the page as well. --Joeljkp 23:10, 4 Jun 2005 (CEST)

If you don't have someone's real/full name accessible to all then what is the benefit of the entry? If person 'A' adds details of, say, their parents, but for some reason doesn't want anyone else to know that their mother was famous so makes the mother incognito in some way then what happens when someone else comes along and creates a record for the mother in her own right as someone famous? As I see it, there isn't any way for the software to automatically recognise that these two people are the same. In the other aspect, there are an awful lot of med by the name of "John Smith". The only fair way to organise them is to allocate an 'accession number' when the record is first created so that there is no priority between the different people (ie. if two John Smiths are born in the same year - and hundreds will have been - how will you deal with arguments of who is more important if you use any other method?) It would be very dangerous to use the DoB/DoD in the naming anyway as there might be subsequent corrections which would mean page/link moves (and this doesn't just apply to actors who lie about their DoB!). Can I also throw in a comment about how does one deal with adoptions? --VampWillow 11:23, 25 Aug 2005 (CEST)

  • According to Dutch law, it is illegal for people in the Netherlands to publish genealogical data of living persons in most cases. I think more countries have laws like this which may cause legal problems. And if they don't cause legal problems they definitely cause ethical problems: Taking the Netherlands as an example: it is only 25 years ago that somebody who spoke 6 languages and was graduated cum laude from the prestiguous University of Leiden was turned down for a job at the Dutch Ministry of Foreign Affairs. In his file was written: "excellent candidate but his father is a baker". I would suggest to refrain from publising data on living persons unless they perform public roles, like politicians, singers, actors etc. Rood bloed 21:06, 30 Aug 2005 (CEST)

Images

  • Would be great to install an images module, to enable family/individual portraits. — FJ | hello 22:44, 18 May 2005 (CEST)
  • OK, image upload is now allowed - see e.g. Vincent van Gogh :) However, uploading should be reserved for people uploading their own pictures. In cases like this we should be able to include the Wikimedia Commons image without having to duplicate duplicate and upload it. Is there a clean way to do it? --Vacilando 22:31, 20 May 2005 (CEST)
  • I find that we cannot include Wikimedia Commons images in WikiTree directly. One option is to include external images (it is enough to enter an URL of an image; this server allows it), but we would not be able to resize them on the fly. See this page for more info. However, I can see that it is technically possible to write a plugin for WikiTree that will allow on-the-fly inclusion of Wikimedia Commons images with resizing. --Vacilando 23:39, 20 May 2005 (CEST)
  • A note about pngs, the wiki module seems to completely destroy them when it tries to compress them in any way, an image I put up called adolphusboothandabigailstonehouse.png looks terrible once the site has gotten it's grubby little mits on it. I suppose that means we should only use jpegs. Janizary 00:58, 6 Jun 2005 (CEST)
  • I am not sure why is that... because your other image, Image:Proposal.png (the logo) displays just fine. Could it be that some version of PNG plays a role here? We need to find out whether other WikiTree or MediaWiki users have this problem. --Vacilando 22:19, 6 Jun 2005 (CEST)
  • I am pretty sure it is just the module's attempt at compression, the image handling for other formats like gif and jpeg seem to work fine, only pngs larger than 100kb seem to be so drastically effected. I encountered the same on the Uncyclopedia. Janizary 00:12, 7 Jun 2005 (CEST)

Graphical tree display

  • How difficult would it be to impliment some kind of graphical tree display that is better than the below? Would this entail RDF encoding or something? I suspect as WikiTree grows this will be high on the Feature Request list. — FJ | hello 22:57, 18 May 2005 (CEST) 
       Grandparent______Grandparent
                    ↓
                ______
                Parent_______Parent
                          ↓
               _________________________
               Child 1, Child 2, Child 3
  • Personally, I've always found graphical family tree display to be problematic, even on paper, so I'm afraid I'm not much help on this question. -- Krubo 03:54, 19 May 2005 (CEST)
  • I think we could usefully achieve dynamic display of any part of the global tree (whatever shape, size, extent) in Scalable Vector Graphics (SVG) format. Plus a version in raster (best PNG) would serve those without SVG plugin. Another good format is SWF, since so many people have Flash plugin installed. --Vacilando 00:33, 20 May 2005 (CEST)
I don't think usage of flash would be the best option if you want to be "open friendly", Macromedia's support of anything not Windows is rather lack-luster. 65.94.62.132 11:10, 26 May 2005 (CEST)
  • A first approximation of the graphical tree has been born - see the <tree> extension here. --Vacilando 00:25, 5 Jun 2005 (CEST)
  • @rbre 3D display could be also used. The philosophy of the project @rbre (under development) is very near to the one of wikimedia. It uses not only wiki, but P2P. @rbre is seeking for partners and contributors. Olivier Auber 01:41, 28 Jul 2005 (CEST)
Hello, just for fun i've created a family tree over three generations in HTML. See here. Don't mind the other text which is in Dutch and is a work in progress - still needs a lot of work. Harm 16:31, 18 Jul 2005 (CEST)

Data imports

  • Another future must-have: data imports. There are probably many genealogical enthusiasts out there who would feel daunted by moving to the wiki platform due to the technial aspects. Permitting GED or similar flat file imports would not only be valuable for that "non-techie" audience, but would obviously also make the process of adding content much faster. I assume this would be a big project in and of itself though. — FJ | hello 23:03, 18 May 2005 (CEST)
  • Yes, we will surely want data imports. I think first we ought to iron out technical issues about how our data is represented on pages and in the database (see below). My hope would be to make some technical decisions while we still have only a few hundred people in the tree, so it can be feasible if we need to modify all existing records. -- Krubo 03:54, 19 May 2005 (CEST)
  • I am also aware we need to import stuff from free databases and so attract users and contributors. One of the obvious sources is Wikipedia - we can regularly or even dynamically (on-the-fly - do you have ideas how to do that?) import basic info (DOB, name, maybe even relation) from biographical entries. There are several other free sources that come to mind. There might be other sources we might consider partnering with in some way - either on a regular basis or just once. --Vacilando 01:20, 20 May 2005 (CEST)
    • No, you can not import content from Wikipedia since that is licensed under the GFDL, which is not compatible with the Attribution-NonCommercial-ShareAlike license used here. Angela 07:49, 29 May 2005 (CEST)
  • Can we list websites / resources featuring free genealogical from which we could consider an import to WikiTree? --Vacilando 18:00, 28 May 2005 (CEST)
  • Basic information from Wikipedia biographic entries - of course!
  • Who's Who in International Organizations: the UIA (for which I work) has nothing against publishing personal names and DOB (information comes from public domain). Over 30,000 entries. Unfortunately, children names are not tracked.
  • To expedite the import of files, what about this idea: We use external programs to convert files such as GEDCOM to Wikitree loadable format. The Wikitree format will then be the current leaf design with a very easy to recognize separator in between the leaves. In addition each leaf will also get a incremental number and child nodes must use these numbers to uniquely identify links to children. When loaded the number could then just be added to whatever is the current Wikitree number. This has the following benefits:
    • It's already in leaf format and each record can easily be identified using the separator.
    • It provides an unique number which, for example, GEDCOM doesn't currently have.
    • Even entry level programmers could write a file conversion program to this format in which ever language they choose.
    • The file conversion programs could strip out the unused information that Wikitree does not store. This would decrease the file size for loads over slow modem connections.
    • Tokens could be used instead of the text in the current leaf format.
    • It's easy to load.Superdooperhero 08:34, 13 Jun 2005 (CEST)
Hello, just for fun i've created a family tree over three generations in HTML. See here. Don't mind the other text which is in Dutch and is a work in progress - still needs a lot of work. (Harm - 212.159.203.212 16:22, 18 Jul 2005 (CEST) - not registered here, but can be reached under that name on the site mentioned earlier)

InterWiki

  • I just updated WikiPedia's Interwiki map with a link to WikiTree. Since I am not familiar with how this actually works, I merely cloned a similar link and am hoping for the best. They say "A script has been written to copy this list into the database, and this should be done on a semi-regular basis," so I am crossing my fingers that this will work today. — FJ | hello 23:22, 18 May 2005 (CEST)
  • Hmm it looks like my experiment didn't work. Anyone know if the problem is on WikiPedia, WikiTree, or me? — FJ | hello 05:27, 20 May 2005 (CEST)
  • Judging from other comments on the Interwiki map talk page, I think you did it just right. Unfortunately, it sounds like Wikipedia is slow at best on enabling interwiki's. --Krubo 06:07, 21 May 2005 (CEST)
  • Be aware that someone's entry on WP may not be in the same name as their birth name (indeed, applies to myself). Maybe use "Yes" only where the WP-entry is named exactly the same, and entering the target name if not? --VampWillow 11:30, 25 Aug 2005 (CEST)

Automation / Representation of data

  • I'd like to tweak how we are representing data, with goals of:
    1. eliminating redundancy: any piece of data (examples: a parent-child relationship, a birth date) should be entered in only one place. This can make entering data faster and solve synchronization problems.
    2. making data access fast: our internal data structure should make it easy/fast to do processing like 'find closest bloodline connection from me to you' or 'watch recentchanges on my closest 1000 kin'
    3. improving display / navigation: making it easy to get from one person's page, to the page of any close relative
For the moment, I have a couple concrete ideas, presented below. --Krubo 03:54, 19 May 2005 (CEST)

System tweaks

  • link types: the database table of links should know which links are parent-to-child links and other special links. For example, perhaps any line of the form "C:[[link]]" should represent a parent-to-child link, and the software should know that.
  • auto-display of nearby kin: at a minimum, it would be nice to see a person's parents on the person's own page.

-- Krubo 03:54, 19 May 2005 (CEST)

Kinship tweaks

WikiTree has a good answer to the most fundamental relationship: parent links to child. Derived relationships (like siblings, derived as being two children of the same parent(s)) don't need to be entered (but may be displayed, see above).

Important non-derived relationships (like marriage) are unanswered, because in a symmetric partnership, it is unclear who should link to who. To eliminate redundancy, only one should link to the other (perhaps which one can be left undefined?), and the link should be displayed on both their pages (see system tweaks above). We may need a list of relationships for the software to know about. Intercultural NPOV may complicate this. -- Krubo 03:54, 19 May 2005 (CEST)

Some cultures (Zulu) also allow multiple marriage partners. Superdooperhero 22:51, 12 Jun 2005 (CEST)

I have a problem: I set up my father (Joshua Lauber) and my mother (Rachel Nelson), but I also added R.N. as Rachel Lauber. It says on Joshua that Rachel is her spouse! So I would like to have Rachel Lauber deleted. Speedy deleted. And fix that automatic-spouse-(mis)feature! --66.91.79.69 00:36, 25 Jul 2005 (CEST)

Identical names

How are we to handle identical names? Middle names certainly help, but should we be including birth-death years in parentheses in the entry name, and create disambiguation entries pointing to each? — FJ | hello 08:10, 20 May 2005 (CEST)

Sounds good. If necessary, place of birth could also go in parentheses. To lessen the problem, we should probably make names as complete as possible--including middle names, maiden and married names where applicable, suffixes like Jr....--but this will only get us so far. Perhaps all article titles should have (YYYY-) or (YYYY-YYYY) and the redirection/disambiguation entries could be created automatically, based on everything outside parentheses? --Krubo 14:17, 20 May 2005 (CEST)
I think the best way to solve the issue of multiple people with the same name is to have all the entries be an alphanumeric id (ie: 00000001 through zzzzzzzz) - unforunately that makes it harder to manage the wiki itself, as you only really get one column you can search through instead of several like a normal database. 65.94.62.132 10:46, 26 May 2005 (CEST)
Perhaps setting up a name page that indexes those with the same name, then have a seperate page for each. That makes sense to me. Janizary 08:57, 27 May 2005 (CEST)
When adding a new page, the wiki should assign a new unique number, then at the top it should say "This profile will be assigned #99194851; use this number to refer to this person" or whatever. To link to that page, the editor will just need to open the profiles and copy the numbers. --Joeljkp 23:14, 4 Jun 2005 (CEST)
Unique numbers might complicate the Gedcom import, since I dont think that currently has such a number. Althought i agree that its probably the only way of uniquely identifying someone. Superdooperhero 23:01, 12 Jun 2005 (CEST)
Unique numbers can be found in GEDCOM imports, and is a part of the specification (although poorly implemented in most applications). Certainly it should be a part of the GEDCOM export, if that is ever done, and tied into the index number assigned by Wikitree, in case the data is re-imported into Wikitree with modifications. The problem is more manifest when you are trying to combine multiple large databases, each with its own unique identification structure. Automated links to other on-line resources (if known) would make a valuable resource as well, especially if it is a link to that specific person or data about them. Keep in mind that the number of people (estimated from the LDS Family History Library) that have ever lived on the Earth... at least from about 6000 B.C. onward, is about 80-90 Billion people. Of that number, I would offer a guess that roughly 20 Billion have some sort of lineage-linking information about relatives in writen records of some sort. Those are huge numbers to deal with, and there are also dozens of computerized databases that have this information as well. RHorning 19:25, 28 Jun 2005 (CEST)

I am realizing that due to the nature of the Leaf code (specifically the Leaf Extension Code) the page name value is becomes rather informational. That means we do not have to worry too much about its correct syntax - whether they contain DOB, and if DOD as well, if they have brackets, etc... I would propose to use just full names (as Krubo said, "as complete as possible") as long as there is no conflict due to identical names. If there are identical ones, well, something has to be added, DOB, DOD, maybe Jr., or even title. But the syntax is not critical as long as the data inside the Leaf code are OK. --Vacilando 23:21, 27 May 2005 (CEST)

  • Note: My understanding is, the page name is crucial because the parent's Child = [page name] needs to match the page name---otherwise it would be a broken link. In recognition of this, we may be abandoning the "other names" field. --Krubo 02:01, 30 May 2005 (CEST)
  • Sure. I wrote that comment long ago (relative to the current pace of WikiTree :-). Now after the change of approach discussed here (getting full name from page name) this is no longer an issue. --Vacilando 09:04, 30 May 2005 (CEST)
  • Name collisions may not be an issue anymore, but I think there's a value to having uniform (and simple!) URLs. I think the only way to do this is to assign each person a unique number. --Joeljkp 23:16, 4 Jun 2005 (CEST)
  • I suggested above that we should use married names for people (like many American women) who use(d) their married name during their life. But I think I'm the only one doing so in the tree. Should I stop? Should everyone else start? I'm happy to follow consensus on this---just wanted to make sure we consider the above concerns before deciding. Thoughts? --Krubo 02:01, 30 May 2005 (CEST)
  • Speaking for myself, no, I have not given enough thought to this question. My gut feeling is that maiden names are more basic. If you ask an average father to write down the names of his daughters he will probably write their maiden names. Maiden names also allow creating matrilineal trees. Also, using maiden name in surname automatically creates a category, which is in fact a focus for a family. I would propose to treat married names as a kind of given names. But I am not clear on where should they be specified. We cannot just say use maiden name - dash - married name; that is only usual in some cultures. Maybe we need a strict rule saying women if married should have page name equal to full maiden name and with married name in brackets? We need to discuss this more, and perhaps in a special section. --Vacilando 10:02, 30 May 2005 (CEST)
  • The name situation is further complicated by the fact that in some countries (e.g. in Slavic countries such as Slovakia, Czech Republic, Russia, etc.) the names of women actually look different from the surname of their man or father: they usually have a suffix "-ova" or "-ová" which somewhat (not that clearly) indicates belonging to the man's family. For example, my mother's maiden name in English Gabriela Krupitzer but correctly in Slovak it is Gabriela Krupitzerová (and since she got married her name is Gabriela Fülöppová). In such cases, when looking for family relations, we will have to be able to use only root of the word - "Krupitzer" or "Fülöpp". --Vacilando 10:10, 30 May 2005 (CEST)
  • to use only root of the word - not a very good point. A root wouldn't help very much. The matter is not just adding but also changing the ending in female surnames, like e.g. in Polish surnames male ending with -ski, and female ending with -ska (Ostrowski/Ostrowska). The same scheme applies for Russian -ский (male) / -ская (female) (Островский/Островская). Just dropping the ending and leaving the root may give us (less likely though) a unique surname Остров, for which a female form would be Острова. Ad if we drop just a changing part of the suffix we would get Островск that rather looks like a place name, not a surname. Moreover, in Lithianian, surnames look even more different and there are separate forms for unmarried (-iute/-aite/-yte) and married (-iene/-ene) women, while male form would end with -ius. A proper use of categories when female form is included into the main (male) surname form may be a solution? --- 213.170.65.38 10:01, 19 Jul 2005 (CEST)
  • Yes, we should certainly use maiden/unsuffixed/family names in the Surname= field, so Gabriela has Surname=Krupitzer and appears in the right spot of the index. My question is: my grandmother's Surname=MacDonald, but I've titled her article as her full current name, Margaret Frances MacDonald Getaz, for reasons above. Is this better, or should I omit "Getaz"? We may need to answer this question separately for every culture's naming scheme (would "Gabriela Krupitzerová Fülöppová" even be possible in Slovak?) --Krubo 04:48, 31 May 2005 (CEST)
  • "Gabriela Krupitzerová Fülöppová" would sound extremely unnatural in Slovakia, where we use married names only. But in Belgium, for example, the same name would be acceptable, but with a dash: "Gabriela Krupitzer-Fülöpp". I have an idea - what if we adopt a similar approach as with the surname, i.e. we make a leaf variable for maiden name and encourage people to specify maiden name (however it is done in their culture) in the page title. In that way we would get a lot of flexibility - when searching for family, for example, we could try both Surname and Maiden name (if not equal) and so get to the woman's ancestors, etc. And if it is in the page title, well, then we know how to remove it / or add. Thoughts? --Vacilando 00:47, 1 Jun 2005 (CEST)
  • What do you think of having a separate page or section for reporting bugs?
  • Is there any progress on the identical name problem? It seems to me that this is hindering serious use of the Tree. --Joeljkp 00:26, 19 Jul 2005 (CEST)
  • Some of this is being worked out over at http://wikitree-dev.ballsome.org. I am attempting to create a system that works by assigning unique numbers to each person. If anyone's interested in helping out over there, we can see if it'll work. --Joeljkp 16:45, 4 Aug 2005 (CEST)
  • Possible Scheme:
There are going to be countless problems with a parenthetical system, so the best (POV) solution is numbering the nodes (people). We can use ascending numbers based on time contributed, or we can have a meaningful system. The benefits of the former are that they can be assigned by the software and needn't confuse the editor. The downside is that the editor will need to find which unique number identifies each person that they are referencing in each new node. The upside of a meaningful scheme is that the numbers contain information, therefore the editor can extrapolate information from the number about each other person they are referencing.
  • Meaningful Numbers:
    Gödel will provide. For each person their unique number is the product of square of their fathers number, the cube of their mothers number and the fifth power of which sibling they are (chronologically). This may seem complex, and that is because to a certain degree it is.
    • Pros:
      Dynamic entry point; it doesn't matter whether my father already has a number, or I already have a number... The numbering can be based off of any /one/ point in a family history.
    • Cons:
      Assignment. This is a /huge/ hurdle, and one that I cannot answer at the moment. My first step would be to divide it by family (Ross-234.1234 etc.) but this wouldn't help when there were multiple families with the same name which don't share ancestery...Possibly a solution will involve numbering surnames based on /something/ and working from their, but thought would have to be put into this.
      Collision. Unless we start from /1/ family and work out (not possible at the moment) the numbers cant be accurate. When my family collides with another family their numbers will not be accurate unless they number based off of the person who collides with my family as well. Once again, thought will be needed on this.
  • Another Scheme
    Creating a meaningful number based on requisite, unchanging information (DOB, Surname, Given name, Country and City of origin) We can easily develop a numbering method from these pieces of information by devising a letter to number conversion (for names and placenames) which would ensure consistency, and the collisions would become less of an issue. This wouldn't provide a means of relating data points, but would uniquely and meaningfully identify individuals in an automatable way.
    • Pros:
      Easy, automatable, immediately implementable.
    • Cons:
      Doesn't relate data.
      Eventual collisions (when all data points are equal, if another John Smith was born in Boston on the same day...)

I am sure there are further schemes, but those can be discussion points anyway.
- TheDaveRoss 20:27, 7 Jun 2005 (CEST)

  • Dave, I was thinking along the same lines last weekend - even thought of Gödel! I am in favor of a solution like this. — FJ | hello 23:18, 7 Jun 2005 (CEST)
  • Sequential Numbering
    I would advocate a simple sequential numbering method, by which the first entry is numbered 1, and the number is incremented for each additional entry.
    • Pros:
      Easiest to implement, no identifying information necessary (siblings, parents, DOB, etc.), guaranteed uniqueness; bonus: automatic tally of number of people in the tree
    • Cons:
      Not possible to guess a URL for a specific person
      (I don't see this as a problem, though. Most people will not guess the permutation of a name, they will search or browse to find it anyway)
--Joeljkp 21:18, 10 Jun 2005 (CEST)
In such a case I would suggest *not* starting at #1 because of the "prestige" of such a number... —Muke Tever 08:45, 12 Jun 2005 (CEST)
I second (third, fourth) the proposal for using a sequence generator to produce meaningless but unique numbers to identify the pages. That's how databases do it; they say it's important for the unique identifier to be meaningless so that you never have to update it. In pages I write myself I use FLastyyyymmdd to identify people, but that's going to produce collisions once I get a couple thousand entries, and I have to rewrite lots of stuff when I find I got the birthdate wrong.
But you've got to solve the problem of matching new people to old people already in the system. Part of that is you have to be able to combine existing pages. Another part is, whenever someone adds someone new, you should prompt them a list of possible matches. If first-last-DOB match, you've probably got a match. If first-last match, that's probably not a match. DOB and/or city should be given with every name, otherwise there's no hope of later doing matches to that name correctly. Oh, and it ought to be possible to correct a someone's first-last-DOB. I just added Mina lowry, realized I should have added Mina C. Lowry instead, and can't do it because the system's using Mina lowry now as a unique identifier.

This is an essential issue as the Germanic part of Norther-Europe used (and in some areas still uses) patronomens. This means that children are named after their father or grandfather causing a tremendous amount of people with the same name (which has both problems and advantages when researching a genealogy). I am in favour of storing profiles under unique record numbers. Next, pages for each name could be made like Wikipedia's system for disambiguation (eg [[1]] ). These pages can link to the various "John Smits"-profiles. Rood bloed 10:34, 31 Aug 2005 (CEST)

In terms of the maiden name disscusion, a problem with the idea of labelling married women who changed their name with their maiden name:

  • Some people would search for the person using their married name, and if they're ONLY listed by maiden name, it'll be harder to find.

Data Structure

  • What kind of data structure are we using to store the genealogical information? Is there any way to get a diagram of our tables, attributes, and relationships? What database is being used to store the information? I'm curious as to how well the current implementation will scale as we get hundreds of millions of entries. Database design interests me, but unfortunately I don't know php yet.

--Xela 04:03, 19 Aug 2005 (MDT)

  • The database format is pretty much decided by MediaWiki, the wiki software we're using. Each profile is stored as <leaf></leaf> text, and the relationships are generated on the fly on viewing. As for scaling, Wikipedia.org uses the same formats, and has scaled to millions of entries. The relationship searching is going to be the bottleneck, for sure. Another scaling issue is profile naming. You can only have so many variations on "John Smith". I'm not real sure how to reduce the search times except to code all the relationships into each profile, but it may not even be an issue. --Joeljkp 00:23, 20 Aug 2005 (CEST)

System Administration

Who is our sysop? Can I apply to be a sysop? How can we tweak internal system code, if we agree to make tweaks?

  • I'm fairly new to wiki-land, though I know some php; can someone point me in the right direction? -- Krubo 03:54, 19 May 2005 (CEST)
  • You certainly have my vote for taking on that role! — FJ | hello 21:37, 19 May 2005 (CEST)
  • Absolutely: Krubo, you are a sysop now! --Vacilando 00:56, 20 May 2005 (CEST)
  • Anybody who wishes to acquire administrator (sysop) rights, please place a request (here, for the time being). We will need you to prove you have serious interest in this project, so make sure you contribute considerably before you apply. It is of course extremely helpful if other WikiTree contributors vote for you. --Vacilando 00:56, 20 May 2005 (CEST)
  • I have an interest in being a sysop. See my blog piece on wikitree here. I have php experience, and am working with mediawiki for another personal project. --Joeljkp 23:21, 4 Jun 2005 (CEST)
  • Welcome, Joeljkp! I have read your ideas and found them interesting and full of good energy. Let us discuss them here at WikiTree. As for the extra rights - sysop status would allow you more efficient management of WikiTree (e.g. reverting vandalized pages), adjustment of protected pages, etc. Please give us some time to let you know before we do that. As for working on the extensions / coding, we could definitely use another good programmer. For a start, could you show us some of your work / code, or even better, try to propose improvement / bug fixes for the code that already exist - all descriptions and sources are here. --Vacilando 00:22, 5 Jun 2005 (CEST)

Vandalism

  • 24.239.248.21 has been repeatedly posting a link farm on 5 pages, apparently ignoring a warning. I suppose we will have to block them... --Krubo 14:17, 20 May 2005 (CEST)
  • A number of pages vandalized by 24.239.248.21 has been detected (and reverted) earlier today. This IP has now been blocked for 30 days. --Vacilando 00:10, 23 May 2005 (CEST)
  • What a mess! -- Krubo 18:25, 23 May 2005 (CEST)
  • I hope this linkspam may stop if we're sure to revert it quickly. I got tired of hitting "reload" on recentchanges, so I made a page that pops up a javascript alert every time a change is made. Maybe you can watch it at times, as I can't very well revert changes while I'm asleep or away from the computer... What do other projects do about this? (For example, could we auto-reject edits that look like linkspam? Is it even worth fighting?) --Krubo 02:54, 24 May 2005 (CEST)
  • Okay, here's a better answer: If we edit /includes/LocalSettings.php to include the line 
 <?php
    $wgSpamRegex = "p2l\.info" 
 ?>
then our problem just may go away, at least for now. --Krubo 04:29, 24 May 2005 (CEST)
  • OK, I have done this now; hope it works as expected. The fight against spam should get easier once we implement the auto-updated blacklist they talk about at WikiMedia. --Vacilando 09:30, 24 May 2005 (CEST)
  • Oops -- my line of php was wrong; please amend it to: 
  $wgSpamRegex = "/p2l\.info/";
Note regex delimited by slashes, and semicolon to end line. --Krubo 15:16, 24 May 2005 (CEST)
  • Corrected now, thanks. --Vacilando 18:52, 24 May 2005 (CEST) 
  $wgSpamRegex = "!p2l\.info|azzacash\.com!";
Also, note that we're using rel="nofollow" so the spam should be useless to the spammers. --Krubo 15:18, 26 May 2005 (CEST)

Modifying Code

  • I'm slowly reading up on MediaWiki, but would appreciate any suggestions. :) --Krubo 14:17, 20 May 2005 (CEST)
  • Templates in MediaWiki are very powerful. And I think everything else can be achieved by writing smart extensions. There are few things you cannot do with them. Modifications of the system code are of course possible, but we should avoid them, since they would make upgrading MediaWiki a nightmare. --Vacilando 23:39, 20 May 2005 (CEST)
  • It looks like a good place to start would be an extension to show the links-to-here on each page, rather than having to just link to them. This page tells how to set up an extension. I downloaded the MediaWiki codebase to look through, but I don't have apache, let alone mysql, so...is there a place I could work on such a thing? A dev-wiki, perhaps? Or would it be workable to develop an extension right on wikitree.org? -- Krubo 00:46, 22 May 2005 (CEST)
  • Maybe it depends on the type of development. Personally I would be ok with some dev work directly on wikitree.org, provided it's only visible to the developer and there's minimal risk of it being 'accidentally' invoked by a non-developer. But if we're really in need of dev space let me know and I might be able to loan some out on my personal web space. — FJ | hello 01:36, 22 May 2005 (CEST)
  • I think the most trustworthy people working should be able to add extensions to WikiTree.org directly. Working on the live server has the obvious advantage of being able to do testing on real data. But it is dangerous as well. How should we judge applications for such access? Ideas? How does Wikipedia do that? --Vacilando 00:20, 23 May 2005 (CEST)
  • Some checkoffs that come to mind:
  1. need for access: for example, sysops don't need shell access; in a system with elaborate testing facilities, even developers might not need shell access, but with the current system developers probably do need access. As the project grows, this guideline should become more stringent.
  2. trustworthiness: there should be no reasonable doubts in the community about trusting the person to tread lightly, not break the server or damage data, but do things that need to get done
  3. community consensus for the person to have access, considering prior commitment to the project
Also, we should keep secured backups of the database and all code, to make sure even someone with shell access couldn't do permanent damage.. --Krubo 05:23, 24 May 2005 (CEST)
  • What exactly do you mean by "links-to-here" on each page, Krubo? --Vacilando 00:17, 23 May 2005 (CEST)
  • He means a list of the pages which link to the current page, as opposed to the current link which generates another page with that list. I am in favor of this. How about as a floating box of some kind, out of the way of the main body? — FJ | hello 02:20, 23 May 2005 (CEST)
  • I didn't mention my reason for prioritizing this: kinship links need to be both human- and machine-readable, and I think the best way to iron out potential problems with machine-parsing is by starting to write parsing code. Like, if your page says Child: Me, then my page could automatically say Parent: You.. --Krubo 05:04, 23 May 2005 (CEST)
  • I have just finished working on two extensions that do just that! Two new tags have been introduced: <child> and <findparents>. Tags <child></child> wrap around the [[Child Name]] (inside double square brackets as usual in wiki local links) and <findparents></findparents> that has to contain the name of the profiled person (unfortunately it cannot be fed in automatically, since code in extension tags cannot have wiki markup... but perhaps we will find a fix for that later). See my update in the template on the Main Page. The result is very pleasing - see e.g. Vincent van Gogh and his parents! So, what kind of functionality should we think of developing next? --Vacilando 22:08, 24 May 2005 (CEST)

Designing extensions

Extension developers should let the other developers know as soon as they start and stop working on any of the extensions. Preferred method is posting a message on the other developers' talk pages - if they are on WikiTree, they will see it immediatelly. Other ways, such as IRC or other chat systems, e-mail, SMS should be used only if there is a good chance that the other developers are checking them at the moment.

Apart from extensions, there is file called "functions.php" that is to contain any multi-purpose functions and classes used by more than one extension. The code is here.

alphalist

Shows either the list of surnames that start with the current page name (if page name is "M", all surnames starting with "M" will be listed like this. If there is an argument, e.g. "S", even other pages (that do not have page name "S") can display list of surnames starting with "S". If the argument is "all", a list of all existing surname initials is displayed, so as on the Main Page. Syntax: <alphalist>possible argument</alphalist>. Code of the extension is here. --Vacilando 14:03, 29 May 2005 (CEST)

  • A lot of new functionality has been added to <alphalist> today. Review of parameters: to show all surname initials, use "all_names" (the old parameter "all" does not exist anymore), to show all surnames starting e.g. "C" use "C" as parameter. If no parameter is given, the program takes the page title (e.g. "C") and looks for surnames starting with that. New: parameter "births" looks over all recorded birth years and creates a table of birth centuries. Clicking on any century one goes to the Births page that allows retrieval of personal profiles of people who were born in that century and a selected year. There is also a mirror parameter "deaths". Both these browsing tools have now been added to the Main Page. Bugs? Comments? --Vacilando 23:42, 4 Jun 2005 (CEST)
    • My sole complaint with the alphalist setup is that it currently doesn't sort names listed alphabetically, it just sorts them all. I think once that is smoothed out there's not much that can be complained about. I love the bracketed gender and date displays, maybe adding in nation next to both birth and death years would be nice. Janizary 22:45, 5 Jun 2005 (CEST)
      • Fixed now - both indices and contents of all three existing browsing modes are now sorted alphabetically. About adding the nation - one of the other things we should do is make the alphalists in several columns, and not in one (see a Wikipedia example), and for that we need space. So we need some kind of compromise. Perhaps some information could be in a mouse-over? Or should we use two-line results? --Vacilando 09:49, 12 Jun 2005 (CEST)
  • I have tinkered with the alphalist extension for the past several days. The two original different modes (surname and century/year browsing) had been using different programming approaches, so I had unified them. Moreover, with the growing complexity and size of the site, speed started to be an issue, so I have done lots of tests and found and implemented several optimization measures. I have achieved about 50% increase in page generation speed, though more should be possible - comments, programmers out there? The arguments were harmonized to "all_surnames", "all_centuries" -> "centuries_of_birth" and "centuries_of_death". A new browsing tool has been added - countries of birth and death, with arguments: "all_countries" -> "countries_of_birth" and "countries_of_death". This is a very useful one also for weeding country name variants... click e.g. on Countries of birth - U and see in how many different ways the USA has been named. --Vacilando 10:00, 12 Jun 2005 (CEST)
  • Got a complaint with it now, when you use the alphalist for specific returns it uses English within the output, those should be left out so that other language users know what's going on. Janizary 23:58, 11 Jun 2005 (CEST)
    • Thanks, Janizary. I was aware of it but working on far more basic issues I left it for later. Now this is solved - the "all_countries" and "all_centuries" parameters can accept specification of the row names by adding "|births|deaths" (thus delimited by pipe signs). --Vacilando 10:12, 12 Jun 2005 (CEST)

createpage

Takes care of the form we need when users add a new personal profile. Without argument (<createpage></createpage>) the input box is displayed and with argument "submit" the submit button appears. Code of the extension is here. --Vacilando 14:20, 29 May 2005 (CEST)

  • I've recreated the button now with a new extensions that works for MediaWiki 1.7 and higher. It's called CreateArticle and does the same in a easier way. I will release it asap for the Wikitree -- Powerzite 11:32, 14 October 2007 (PDT)

leaf: basic entry

Because this part was growing too fast, I have relocated it to the discussion side of Leaf Design. Code of the extension is here. --Vacilando 22:20, 25 May 2005 (CEST)

php_highlight

Highlights php code snippets we need to discuss on WikiTree. Usage: <php_highlight>(PHP code comes here)</php_highlight>. Code of the extension is here. --Vacilando 14:03, 29 May 2005 (CEST)

php_highlight_extension

Highlights php extensions so that we can discuss them on WikiTree and further develop collaboratively. That also means that newest code written by extension developers does not need to be manually published. Usage: <php_highlight_extension>(extension name, e.g. "leaf", comes here)</php_highlight_extension>. Code of the extension is here. --Vacilando 14:03, 29 May 2005 (CEST)

statistics

Since many WikiTree pages do not contain more than the basic <leaf> extension, the standard Special:Statistics page does not count them correctly. To get a rough number of personal profiles that are present in WikiTree, you can use the <statistics> extension with parameter "count pages", thus: <statistics>count pages</statistics>, which now produces: 54002. ("Rough" because the function does not count normal pages (such as the main page, categories, etc.), it does not count generated pages, and it does count mentions of <leaf>...</leaf> (even if it is not a genuine personal profile), but well, it is a sound estimation.) In the future, this extension, with other parameters, can be used for other statistical calculations. Code of the extension is here. --Vacilando 20:41, 5 Jun 2005 (CEST)

tree

Creates family trees based on a given person, with selectable look and content. It is a part of <leaf> but can be used separately as well. Usage (e.g. for table view, male gender, name Ellis Lawson Banister): <tree>Ellis Lawson Banister|male,table</tree>. Code of the extension is here. --Vacilando 22:38, 3 Jun 2005 (CEST)

Submitting new profiles

Wow!! I have just finished a totally new system for creating new pages - check it out... no hassle anymore! Comments / further ideas? --Vacilando 22:33, 27 May 2005 (CEST)

  • I have some ideas for unique keys, if we decide to go that route. --Joeljkp 23:21, 4 Jun 2005 (CEST)
  • I have seen what you proposed at your site. Can you repeat / elaborate on it here so we all can consider it. Me personally, I use unique IDs everywhere - it really solves a number of problems. However, I do not see yet how such system could be made user friendly in the MediaWiki environment. --Vacilando 00:09, 5 Jun 2005 (CEST)
  • Let's also talk about submitting the new data by form and not using the template. This is certainly easy to do, but we would need to figure out how would the updating of such profiles work. Editing an existing profile, would people see the form and an edit window, or the current template, or just the form? --Vacilando 00:29, 5 Jun 2005 (CEST)
  • Ok, here's what I was thinking:
A unique number or key would only need to be used to link between profiles. This would mean that whenever someone edited a profile, he or she would have to open the profiles they want to link to in new windows, then copy/paste the ID. This requirement could be spelled out in big bold letters at the top of the Edit window. It would also mean that any linked profiles would need to be created before they could be referenced, so that the number could be determined. I guess the easiest way to assign keys would be to just start with 1 and increment by 1 for each added profile.
I don't see these added steps to be that big of a deal. Once the system gets big enough, people will have to open up the profiles they want to link to anyway to find out how they were named.
As for creating a new profile, the assigned key doesn't really matter, because the profile won't link to itself. The system would just assign one once the user pressed Submit, and would add a little ID: #### line at the bottom of the page, below all the personal info.
If I were doing this myself (and I knew how to implement everything), I'd go with a form for new profiles as kind of a guide for new users, and with a standard edit box for later changes. Though, the more I think about it... if the form was flexible enough, that might be a better way. You could prevent certain types of data (e.g. biographies for living people), and it would give more structure and uniformity to the whole thing without others having to jump in to fix little mistakes.
Maybe the best way would be to use a form for profile creation and a form for basic editing, but to have an "Advanced Edit" button that would lead to a regular edit box.
--Joeljkp 01:20, 5 Jun 2005 (CEST)

Navigation / locating persons in WikiTree

  • Friends: more news. I have created an extension called <alphalist></alphalist>. This is to be used on pages containing surnames starting with a particular initial letter. For example, on page B the extension lists all people with surname starting "B". If an argument is provided, such lists can be displayed on any page - e.g. surnames starting with "F" would be handled by <alphalist>F</alphalist>. This means we all have less work with manual creation of the index pages - and can focus on other things! --Vacilando 22:48, 27 May 2005 (CEST)
  • Moreover, if you use parameter "all" (thus <alphalist>all</alphalist>), the extension will create a row index of all surname initials that exist in the database. This is already implemented on the front page. But there is an important thing for us to do. Only surnames (personal profiles) that use the Leaf code are recognized! Surnames appearing in the old entries from the time when we did not have a standardized Leaf code are simply not included. Therefore, we need to quickly finish converting the personal pages that were created using the old systems. Here is the old, manual list. I propose this system - every time one of us finishes converting all people under one letter, s/he adds the letter here in alphabetical order. In that way we will quickly know what is left to do and when we are finished! --Vacilando 23:12, 27 May 2005 (CEST)
  • Old code => Leaf conversion we still have to do or check (please use the complete list of pages for the work): A B C D F G H J K L M N O P R S T V Z
  • Looks really good! I just updated everything I could (minus some of your entries, Vacilando, as I thought you might be experimenting). I do have a few observations about places where the leaf appears to break - see Leaf Talk page. — FJ | hello 06:16, 28 May 2005 (CEST)
  • Great! I am updating some thirty more I have now found and that should be everything. --Vacilando 10:04, 28 May 2005 (CEST)

Joining efforts with similar projects and ideas

  • To my surprise, today I have discovered several proposals, discussed at WikiMedia pages for a few months, for projects with aims similar to those of WikiTree! I think it is good news - imagine that best of these ideas and the motivated people behind them will work in synergy with our own efforts and ideals. Let's explore these pages, talk to the people, try to come up with a future that is best for the project aims!
  1. Wikipeople and its talk page,
  2. GlobalFamilyTree and its talk page,
  3. Wikimorial and its talk page (identical with Wikifamily).
There already was a comment on Wikipeople talk here about WikiTree. Since the contributor expressed some doubts as to who runs the project, I considered it important to publish a small memorandum - this is its copy:
  • Hi - my name is Tomáš J. Fülöpp and I am a database programmer, social anthropologist and journalist from Slovakia (more), currently living in Brussels, Belgium (working for an international NGO). It was me who initiated the WikiTree project just over a month ago, on April 26, 2005. I would like to state very clearly that I am not in it for any profit. I am thrilled by the idea of joining lonely-growing family trees into one free Wikipedia-like project. The project tries to follow all applicable guidelines successfully set forth in Wikipedia and other WikiMedia projects. The aims of the project are to be met by the community of people, not by myself. Therefore, if the community decides it is important to change the strategy, refine the aims, or even change name, etc. - as long as it is for the benefit of the project, it can be done. It is only now that I see the WikiPeople proposal and yes, indeed, the overlap is considerable. I therefore invite all contributors of the WikiPeople idea to review, participate and discuss at the WikiTree Treehouse the possibilities of meeting the aims of both WikiPeople and WikiTree. Sincerely --Tjfulopp 20:55, 28 May 2005 (UTC)
  • What would it take to actually bring these projects together under WikiTree? I note that GlobalFamilyTree and Wikipeople do not have project or talk updates since 2004 (not including your comments). — FJ | hello 23:39, 7 Jun 2005 (CEST)

Licensing

Have you considered alternative licenses, such as CC-BY-SA or the GFDL, rather than CC-BY-NC?. The current content of this wiki is not compatible with Wikipedia, any other Wikimedia projects, or Wikicities. Attribution-NonCommercial-ShareAlike is not a free license in the strict sense of the term since it does not allow free re-use for any purpose. Angela 07:47, 29 May 2005 (CEST)

  • No problem by me. I think compatibility with WikiMedia projects is important. What do other people think? If there is a consensus, we can sure do the switch. --Vacilando 12:14, 29 May 2005 (CEST)
  • Welcome Angela! Yes, licensing is tricky. I think the current CC-BY-NC-SA has some advantages. I wonder if CC-BY-SA is too permissive for us, as it allows people to sell WikiTree's work for profit, and I don't see that it requires such vendors to provide copiable copies of the work. I wonder about problems with the GFDL, but it could be the best answer for compatibility with WikiMedia. Finally, fair use should cover snippets of info people get from WikiTree, and a lot of info we might get from Wikipedia---even Google uses their birth dates. Anyway, I can be flexible on this according to community opinion. What do others think? --Krubo 16:10, 29 May 2005 (CEST)
  • Thanks for the GFDL problems info, Krubo - it definitely makes one think. Angela, could you please point us to whatever prohibits use of GFDL-licensed material in CC-BY-NC-SA projects? I am sorry I do not know these things myself but the truth is that I am much less interested in the legal stuff than I am in the project goals itself and in collaboration with other free projects and their communities. Thank you. --Vacilando 16:58, 29 May 2005 (CEST)
    • The reason GFDL-licensed material can't be used in a CC-BY-NC-SA project is because the GFDL explicitly allows commercial use, and does not allow additional restrictions to be placed on the material, so you can't take content from Wikipedia, make modifications to it, and then claim people can not use it commercially. Angela 01:47, 8 Jun 2005 (CEST)
    • Yes the GNU Free Documentation License probably has its faults, but the one you're using unfortunately has a great big one. I'm sure you want to collaborate with other free projects, and that's great, but the trouble is that this is not a free project in the usual sense of the term. Prohibiting commercial use definitely precludes that. Richard Stallman would be ashamed!
  • On further thinking, I realize we are always able to make our licensing more restrictive with community consensus (though the change would not be retroactive), whereas making it less restrictive would require unanimous consent from everyone who has submitted data---a task that becomes impossibly hard as we get more anonymous contributors. This is a strong argument for moving ASAP to less restrictive licensing, until we know better where the project is going. In this light, the best thing we could do may be to dual-license everything under CC-BY-SA and GFDL, and revisit the issue later if we want to become more restrictive. More thoughts? --Krubo 02:44, 30 May 2005 (CEST)
  • I would think moving either way needs in theory unanimous community approval? Hmm, would such dual license not be too confusing? I would not mind changing the licencing to GFDL for the time being to be clearly compatible and we can discuss more restrictions later and more widely. What do you think? --Vacilando 09:17, 30 May 2005 (CEST)
  • I am not a lawyer, and it shows. Everything I post here seems to be not quite right... Please advise. :-) --Krubo 14:38, 30 May 2005 (CEST)
  • I propose to switch to GFDL, to make WikiTree compatible with the license of Wikipedia and other WikiMedia projects, on June 1st (GMT), unless, by that date, there are other comments that would speak against it. --Vacilando 15:56, 30 May 2005 (CEST)
    • I myself completely hate the GFDL and on my wiki accounts elsewhere usually comment that all my contributions are public domain, simply because I do not like the rediculous restrictions imposed by the GFDL. Janizary 20:32, 31 May 2005 (CEST)
  • If you are considering a switch to a free license, if I was you I would tend to prefer the CC-BY-SA. The GFDL is a bit of a mess. I'm not sure how compatible it is with the GFDL, you would have to ask the Wikimedia people, but I bet if Wikipedia had started up when the CC-BY-SA was available they would have chosen that instead. Dual licensing takes you into extra-complicated territory!
  • ...reading some more info: [2] [3] [4] [5] --Krubo 23:14, 30 May 2005 (CEST)
    • The GFDL isn't compatible with CC-BY-SA yet. I'm hoping version 2 of the GFDL will be, but there's no guarantee of that even though Jimmy Wales has been discussing this with the FSF and CC. Angela 01:47, 8 Jun 2005 (CEST)
  • For me, I am more a BSD licence kinda guy. I think stuff like this should be free without restrictions and that due credit should be maintained in any reproductions or dirivatives. Janizary 19:45, 31 May 2005 (CEST)
    • Would you be happier with CC-BY-SA, Janizary? (As listed here) --Krubo 22:01, 31 May 2005 (CEST)
      • Honestly, I don't find it much better than the GPL itself, in that it forces you to release anything added to it under the same terms. It is better than some of the licenses which absolutely forbid commercial derivatives - but it is still making you give up something by force, rather than allowing for more usages of the information. I put stuff on wikis and submit things to websites for people to use, not for them to use as long as they let everyone use what they make of it. While I do prefer to be as liberal as possible, I understand that some people don't like that idea and it won't stop me from submitting data to something like this even if it were GFDL. Janizary 22:28, 31 May 2005 (CEST)
        • Yes, I also want my submissions to be usable as much as possible. I've thought the main benefit of share-alike licensing for wikis is to ensure that contributed data will remain free, even if the original wiki were destroyed. For example, even if I'm suspicious of Wikipedia's administration, I'm happy to contribute knowing that because of the license, any contribution that is preserved by a mirror, for example, will still be freely available. Could that be ensured without share-alike licensing? --Krubo 04:12, 2 Jun 2005 (CEST)
          • Kind of, if something is released as public domain or under a licence like the BSD one the original version remains free, however, a person can set up a mirror of that exact information with no additions what so ever that is copyrighted by themselves. That new mirror of copyrighted information would not be released public domain nor BSD unless they equally chose to make it so. Even through ignorance, if someone set up a mirror and did not list a specific copyright or isssue a proper release, it would be copyright that individual. Equally, if they did set up a mirror and did not list the approprieate copyright information then they would be in violation of copyright and the mirror would illegal. But without using one of the viral claused licences, you cannot make something stay "free" perpetually. Janizary 08:40, 2 Jun 2005 (CEST)
        • it forces you to release anything added to it under the same terms — Correct. The GFDL intentionally spreads freedom like a virus. it is still making you give up something by force — Correct. It is making you give up the power to impinge upon or to restrict the freedoms of others. I put stuff on wikis and submit things to websites for people to use, not for them to use as long as they let everyone use what they make of it. — Then you aren't helping to spread freedom as the FSF would have you do, since you are allowing people to take your works and to use them to restrict the freedoms of third parties, because you are allowing those people to use your works in ways that prohibit others from then in turn making use of the result. Put another way: You are allowing people whose intention is not to allow people to use their work, unlike your own intention, to prosper on the back of your work. Uncle G 17:00, 4 Jun 2005 (CEST)
          • I do not believe in these percieved freedoms of yours and Mr Stallman, infact, I disagree strongly with the lack of freedoms involved with the GNU movement. I am giving information to the people, not to the people that will help me, not to the people that I like, but to everyone. If a person that hates my guts wants to use this information to in some way ruin my life, I want them to have that ability. Freedom is not some vague concept of everything not costing money, nor of everything being open, it's allowing for the ability to do anything with what you have. Janizary 18:40, 4 Jun 2005 (CEST)
  • I guess I would now prefer CC-BY-SA as it seems to be more modern and generally acceptable. But my question is - would that preclude us from sharing information with WikiMedia projects? --Vacilando 22:48, 31 May 2005 (CEST)
    • I think if we're taking data piece-by-piece, like Mao Zedong's birth date, it could be okay as fair use in any case. But if we want bulk data-dumps, we would need to use a compatible license (currently just GFDL). On the other hand, Wikipedia holds only a tiny fraction of humankind, so this perhaps shouldn't be our main concern here. --Krubo 04:12, 2 Jun 2005 (CEST)
  • Another consideration: in Genealogy, there is a significant difference between transparent data (example: leaf-code or GEDCOM) and opaque data (example: Family Tree Maker, other proprietary software, and non-data-dumpable websites). GFDL requires transparent data to be provided with any derivative work, while CC-BY-SA may not. --Krubo 04:15, 1 Jun 2005 (CEST)
  • Just chiming in a little late, to say that based on what I'm seeing here I have to agree with what appears to be a general consensus to go with the CC-BY-SA license, even if there appear to be minor annoyances which may or may not become an issue down the road. How does one create a new license, by the way?  :) — FJ | hello 08:21, 2 Jun 2005 (CEST)
    • Oh no, never make a new licence. There far too many as it is, while I think the rule of KISS should always apply with information and I think things like the GFDL and the CC are not simple (unless you can read it and understand it exactly without need for a translation, it is not simple), I would rather they be used than everyone make up their own. Janizary 08:40, 2 Jun 2005 (CEST)
  • Is there a reason to not make this project completely Public Domain? (Assuming it's based in a country that has PD.) On the other hand, if WikiMedia offered the servers, rather than setting up a similar project itself, would we be interested? If so, it could be preferable to start-out with GFDL. (Remember, the traffic is related to the number of people in the tree. It might increase quite a lot.) Mysha
    • I think if we start with PD, we could still move to another license later, by deciding to place future edits under the new license. Is that right? --Krubo 14:20, 3 Jun 2005 (CEST)
      • Technically speaking, you cannot relicence something via replacing the licence with a new one without the agreement of all previous contributors. That said, the public domain is not a licence, it is a waiving of licence. That means that you no longer claim anything over the released thing. In this situation what you would have to do is to ammend the site to say that anything added it contributed under the new licence, then replace older works with new ones. Even when it is as trivial as a spelling correction. So if you wanted to, you could put a copyright and licence on your own copy of a public domain thing and other people could still take the original public domain thing and do the same. Janizary 22:06, 3 Jun 2005 (CEST)
  • The prohibitions on commercial re-use are problematic for this site, as they restrict freedom. I prefer the GFDL for Wikitree. It's the simplest option. Creative Commons Attribution Share-Alike is not GPL/GFDL compatible (or indeed compatible with anything but itself) and, more importantly, is not free. If it helps, I for one have no objections to my (comparatively meagre) contributions up to this point being considered to be licenced under the GFDL. Uncle G 17:00, 4 Jun 2005 (CEST)
    • You sir buy into Richard Stallman's horsefeaters far too deeply. The GNU licenses are not simple options, they are highly complecated and restrictive. As I have previously mentioned, I do not believe in enforcing what someone else believes is their right to have everything, I do not believe in communism. The ability for someone to make use of information that I am giving away is something I like, I do not put things out here to make other people do the same, I put it out here to have them make use of it. If you restrict what people can and cannot do with it, you severely limit who will even consider using it. Also, you note the Debian Project's view of the Creative Commons, yet they prefer that to the GFDL as well, see [6] for the reasons. Janizary 18:34, 4 Jun 2005 (CEST)
  • The main point to decide before settling on a license is whether you are going to need to use content from Wikipedia, and if so, whether that content is copyrightable. If you're only taking facts from there (such as someone's date of birth) rather than the expression of those facts, then you may be able to do so without worrying about license compatability. Angela 01:47, 8 Jun 2005 (CEST)
    • If we're taking data like that from elsewhere we would still have to note the source of the information, it is better to not go looking for random people and adding them to this site, instead allowing people that know them or are related to them do so. Thus preventing any possibility of plagerism. Unless of course we set up a bibliography section of the wiki and make sure people know to add sources to it. Janizary 10:59, 8 Jun 2005 (CEST)

As far as I can see, switching license will mean wiping the database and starting anew. We can't change the license on what is already there, as the current license doesn't allow for that. (In case we switch to GDFL, can we consider becoming part of Wikimedia at the switch?) Mysha 16:01, 30 Jun 2005 (CEST)

If we do make a switch, anything contributed by people agreeing to the switch can stay, but other than that it'll all have to go. But that would be alright aways - it would clean everything out and this would have been like a beta test for the wikibase for the final site. Janizary 19:04, 26 Aug 2005 (CEST)

Practical Commercial Use of this Wiki

(originally a rebuttal to something above, but got long enough that I decided to put it into a new section).

I happen to enjoy commercial reuse of stuff, and the philosophical ideas behind the GPL and GFDL are IMHO quite sound. Here is a concrete example on how I would like to use some of the information here on a commercial basis: I am a private consultant doing geneological research on a professional basis for hire. I compile information from various sources for a client, and I happen to come across WikiTree as a potential geneological database to obtain this sort of information. I do a quick glance and see, yes, there is some original information here that I haven't found elsewhere. I glance down at the license information with cc-by-nc-sa and think "wow, I can't use this at all." What I'm doing is commercial in nature and therefore this is useless. Indeed it is worse than useless and it would be to my best interest to avoid this wiki altogether. Not just not contribute but strongly discourage any of my clients or collegues from ever using this as a resource. With this under the GFDL it has to opposite effect: I will be encouraged to not only use this information, but if I am searching other sources (hopefully original material and old manuscripts that are PD information) much of that information could be folded back in. At the very least, I would have to inform the people I'm giving this information to that this is public information available under the GFDL.

Contrast that with sites like [Family Search] and you find a positively draconian licensing arrangement with the data. Unfortunately, I have contributed over 3000 names to *that* website and I am barely named as a contributor, and I'm not even allowed to use the data that I researched out myself litterally going through old manuscripts and countless hours behind a microfilm reader. At least with Family Search they specifically permit use of the data by professional geneologists for a client. CC-by-NC-SA does not.

The viral nature of the GFDL would be put to the test with a project like this. Many commercial ventures do compile and work with geneological information, and they would have to seriously have to start rethinking those licensing arrangements if they used data from this website. As it is, with the current license, they simply could not use this data and it would be ignored unless somebody separately discovered the original source used to create the data on this website. The current license simply is going to throw the people working here on this information into a marginal backwater. With something like the GFDL it would force commercial ventures into either going with the GFDL, or they would have to strongly segragate their data between commercial data and GFDL stuff. I would bet over time that these companies would convert as much as they could to GFDL instead, particularly if this becomes a popular website.

The suggestion that the license be simply PD until a formal license can be agreed upon is a sound one, and the issue that they are dealing with at WikiNews. They want something like the GFDL, but don't like the restrictions that the GFDL puts on them right now, as it is inappropriate with the sorts of people they would like to see use the information on that website. The same thing applies here, and I would not dismiss commercial users of geneological information. They can be a valuable resource and asset (without selling your soul to the devil). As it is currently, the batch of data already put in is perhaps going to need to be scrapped if you decide to switch licensing. For the most part you probabally won't have to lose _all_ of it, but it may be easier. Going from PD to something else is much easier. Switching from the current license to GFDL is much more painful and unless you get permission from everybody who has contributed to this, it leaves at least the chance that somebody will file a lawsuit against this Wiki, and potentially any administrators involved in the switch. I stongly suggest that the switch be done ASAP if the mood is to make the switch.

BTW, I love WikiTree specifically because it could put a huge dent in the IP armor of "Intellectual Reserve, Inc." in regards to geneological data. The fine print there makes you think it was written by IBM or Microsoft. How the Geneological Society of Utah got perverted in regards to Intellectual Reserve is a weird story, but that is a wholly separate issue. Licensing is going to be a huge issue, and can make or break this project. With the current license I simply can't justify putting the data I already possess into this database, but something that is more "free" I would strongly consider contributing.

Also, take a strong look at Family Search in terms of numbers. That is the size of a "mature" geneological project, and you are going to have to consider that this Wiki could grow to that magnitude. Indeed Family Search is heavy in North American research, touching on 19th and 18th Century Europe to a large extent as well, but missing most of the rest of the world, owing to its roots in America. That is one area where WikiTree could be substantially different. RHorning 09:59, 11 Jun 2005 (CEST)

Navigation bar menu modifications

  • Hi again, Paul. One small issue - I have noticed you have changed the "Discussion" link in the "navigation" box to "Treehouse/Discussion". I would actually vote for using just "Treehouse" in that place. The reasons are 1) the slash in the name does not look nice and is good to avoid, 2) the link is too long this way and most importantly 3) in my browser (latest IE) and medium font size (default with most users) the "n" at the end is cut off because of lack of space. I think "Treehouse" alone is ok - if people do not know it from seeing the green info box they will be curious because of the name and click it anyway. What do you think? --Vacilando 22:03, 23 May 2005 (CEST)
  • Sounds good to me. Note that I actually have done it in a bad way: using MediaWiki:Currentevents and MediaWiki:Currentevents-url. Someday we'll find better ways to customize this. --Krubo 01:28, 24 May 2005 (CEST)
  • Great. Looks much better now. We shall look into a better way to customize it later - need to read up on that. --Vacilando 07:52, 24 May 2005 (CEST)
  • P.S. Friends don't let friends use IE...try Firefox :-) --Krubo 13:56, 24 May 2005 (CEST)
  • I have added "Add new profile" to the left bar menu so that people do not have to go to the Main Page to find it. Let me or other sysops know if the title, mouseover or position should be changed in any way. --Vacilando 15:40, 29 May 2005 (CEST)
How is that localised? It currently shows up in Dutch as "Add new profile". Also, I hope "profile" is a common term for the English (language) non-expert, as personally it doesn't tell me anything genealogy-related. To me a profile is series of personal settings in a computer program or operating system. Mysha
  • Mysha, good point about the localization. Not yet implemented. It is related to the system we choose for the general page language variants. As for "profile" - what other suggestions would you have? "Add new person?", "New person?", "Add new?", "Submit new?". --Vacilando 12:43, 4 Jun 2005 (CEST)
"Submit Person" would be more accurate, but "Add new person" is probably clearer. Mysha
  • I have added "About" - though it did exist previously - to the navigation menu. In that way we can free some space on the main page. --Vacilando 12:44, 4 Jun 2005 (CEST)
  • Added the much needed "Refresh" link to the navigation page and removed it from the Leaf Extension Code. --Vacilando 12:52, 4 Jun 2005 (CEST)

Wikification of and handling of dates

Wikitree should support wikification of dates, and the date format option in user preferences. Wikitree should also be tolerant of different date formats in dates of birth and death, generating the automatically added category names using a uniform representation of dates. Uncle G 17:16, 4 Jun 2005 (CEST)


Importing data from other applications

This may or may not be feasible, but it would greatly expand the amount of data we could add at a time. There are standard formats for genealogical data (such as the format used by Family Tree Maker). Would it be possible to set up some type of system were a file could be uploaded and the profiles automatically created and linked? This is probably a feature to look at after everything else is done. --Joeljkp 01:24, 5 Jun 2005 (CEST)

  • This idea was logged already above, under WikiTree:Treehouse#Data_imports. I think it may be a bit lower of a priority at this time, but it's certainly worth looking into as soon as we can get to it. — FJ | hello 23:47, 7 Jun 2005 (CEST)
  • Import from other databases can be set up - we just need to identify 1) what content are we free to import (copyright, licensing considerations), 2) study its structure, 3) make the import programs. Can we start a list of possible candidates for (1)? --Vacilando 10:30, 12 Jun 2005 (CEST)
  • It might be a strain to accommodate different data formats right from the get-go. Since the standard universal genealogical database format is GEDCOM (more info at http://homepages.rootsweb.com/~pmcbride/gedcom/55gctoc.htm), and most genealogy software can export to GEDCOM format, I propose that WikiTree start out by only supporting GEDCOM uploads for a while and see how well it works. If the GEDCOM support proves itself, and WikiTree still stands to benefit from supporting uploads of other data formats after such proving, then that additional support can be added at that time. --JohnAlbertRigali 08:43, 24 Jul 2005 (CEST)
    • There are already a host of sites that support GEDCOM - using that format would enable many genea enthousiasts to just simply re-use their info without extra hassle. Easy way to add 100,000's of names!! 62.192.96.58
  • The problem with any of this is going to be merging the information into the existing tree. Is there already a way to merge two profiles? Maybe it would be possible to display a tree of the GEDCOM alongside the WikiTree and let the uploader specify the links? --Joeljkp 20:42, 24 Jul 2005 (CEST)
  • Since there are many thousands of GEDcoms on the web containing perhaps millions of names, might it not be better to change the Wikitree leaf to conform to Gedcom standards rather than expect the multitude to adapt? Ruszewski Ruszewski 13:05, 16 Sep 2005 (CEST)

Duplicate names (how to handle?)

I have a father and son with the same name (John Knaggs). When I try to add the son, I get an edit page for the father. What do I do?? There will be thousands of people called John Smith!!

  • You are not alone. :) This is being looked at under WikiTree:Treehouse#Identical_names. — FJ | hello 23:44, 7 Jun 2005 (CEST)
    • This is a common problem in personal name databases. We need to look into experiences of others - e.g. what is Wikipedia's strategy to deal with this? Basically, identical names need to be made unique by adding something to them. I guess we need a list of possible things that can be added to the personal name, ordered by priority. Year of birth is a good candidate, for example, because it is almost always known. But year of death is less good, because no living person knows it (well, it is an assumption, I know :). The other option is to add a unique number at the end of any name, but that would mean each name would have to be looked up in a list... which would make the whole wiki less human and editor friendly. So, I think let's research the WP approach first, let's learn from colleagues who had to deal with it already. --Vacilando 10:25, 12 Jun 2005 (CEST)
      • I'd like to point out that often it is easier to determine the date of somebody's death as opposed to the year of their birth. There is an old widow of a U.S. Civil War veteran (still getting pension benefits in the 21st Century... actually just qualified) who doesn't have very good documentation about when or where she was born. When you are born in frontier areas, meaningless things like birth documentation just wasn't a priority. I have several of my ancestors where this is the case, but as they moved to (or had grow up around them) cities with stronger governments, records of their death was much more accurate and verifiable. When dealing with Chinese ancestry (I had to work with some people going this route) the only information you had to uniquely identify the person was their family connections. In other words, Chung Li, son of Chung Hu, son of Chung Mao. Chinese geneologies can go back 300 or more generations, where one book of royal geneologies I saw was about 1.5 meters by 3 meters by 40 cm. (not cm, but meters or yards for those in the USA). I can't imagine all of the names in that book, but every person mentioned in that geneology list was related to every other person in that book through very clearly defined relationships of father, son, brother, wife, husband, daughter, etc. relationships. And very few dates. RHorning 06:37, 13 Jun 2005 (CEST)
    • Just to give an idea of the scale of the problem. In 1901 in England & Wales, the births of 155 people named simply John Smith were registered (source FreeBMD) - so just birth year is not good enough. These people would have died over the following century, and at least two of them must have died in the same year - so combination of birth year and death year is not good enough. Knaggs 11:40, 12 Jun 2005 (CEST)
  • I just put up an entry for Elizabeth Tudor. She had an aunt also Elizabeth Tudor. I thought I could edit the first to Elizabeth I Tudor. Also her father, Henry Tudor could be Henry VIII Tudor, to distinguish from his son, Henry Duke of Cornwall. How do I actually edit my entries Elizabeth Tudor and Henry Tudor to put in the roman numeral designation?
    • If you are logged in as a registered user you can move an entry, moving it to whatever new name you'd like. Janizary 07:43, 7 Jul 2005 (CEST)

Multiple contributions for the same person? I would never edit someone elses contribution, perhaps it is possible to link them with the contributors mutual consent?

  • I'd always feel free to modify someone else's content about a relative of mine. [[User:DavidBoden][DavidBoden]

Duplicate Countries

I've noticed that there's already a small problem developing with country names:

  • United Kingdom
  • United Kingdom of Great Britain and Ireland
  • United Kingdom of Great Britain and Northern Ireland
  • England
  • Scotland
  • Wales
  • Northern Ireland

Some people specify their country of birth as England and some as United Kingdom. Any ideas how to standardise this?

How about the interesting situation of ancestors who were born in countries that have now changed boundaries or perhaps gone out of existence? Yugoslavia is a recent example. There are many more examples if you go back a bit further in time.

This has been discussed a little bit under WikiTree:Treehouse#Place_Names. I think the best method would be to just keep watching and fixing things according to whatever consensus we arrive at. I feel that the best way to do place names would be to use the name at the time the event occured. So if the person was born in Yugoslavia when it was still called that, you would use that name. As for the length of the name... I would say that the short formal name would be appropriate. This means "United States", "China", and "United Kingdom" instead of "United States of America", "People's Republic of China", and "United Kingdom of Great Britain and Northern Ireland". Does that sounds OK? --Joeljkp 16:00, 29 Aug 2005 (CEST)
Yep, sounds good. --Bjwebb 19:25, 30 Aug 2005 (CEST)

Bio Box

What's the deal with the 'Wikipedia link = yes' line? This causes a box to be generated with a useless link to the Wikipedia article about the rock group "Yes". Should this be 'Wikipedia link =' ?

  • There was a bug ( my fault, sorry :-( ) in the Leaf extension code for a couple of hours yesterday which caused this. Now it is solved. The "Wikipedia link" parameter can accept name of the Wikipedia article to link to, "yes" to link to Wikipedia article that has the same title as the name of the current page, and "" (nothing) or "no" that results in no link box to Wikipedia. --Vacilando 10:17, 12 Jun 2005 (CEST)
Shouldn't that setting be 'no' by default? I see most people leave them 'yes' and later editing their own biography in Wikipedia. Malafaya 22:43, 6 Jul 2005 (CEST)

Initials instead of names

I think that entries such as K S Han are just asking for trouble. If you don't know the name, you shouldn't add it.

Oh, and can we have one of those PLUS signs at the top of this page, so that we can add new sections without editing the whole thing. Knaggs 17:59, 14 Jun 2005 (CEST)

Page deletion

Is there any way how to delete an individual? Josef Sábl 12:57, 16 Jun 2005 (CEST)

  • Good point, I don't think we have a vfd template set up. Right now you can just add messages to sysops' talk pages and have them do it themself, but we should make sure that we have a delete system in place. If you have something that needs to be deleted, you can drop me a message for now. Janizary 02:37, 17 Jun 2005 (CEST)
    • {{delete}} and {{deletebecause|whatever reason}} work now. Janizary 22:05, 26 Aug 2005 (CEST)

Some problem

(Sorry for my English) While adding some persons in family, I found a problem: two womans has the same surnames, first has surname from her father and second has surname from her husband. Won't there be any conflict, if I add a person, who is a brother of first and husnand of second? --DeSnajpa2k5 11:20, 29 Jun 2005 (UTC +1.00)

Put down the woman's birth name. People will be able to infer her married name by seeing who she is married to.--Dustinasby 23:55, 19 Jul 2005 (CEST)
Do you normally make that assumption? The married name might be the same as the maiden, it might be hyphenated (husband-wife, wife-husband), it might be the man's name...
This is what a Notes section or an "Other Names" section would be used for. The current genealogical standard is to use maiden names for women. --Joeljkp 06:57, 30 Jul 2005 (CEST)

Suggestions

  • Using the What link's here table of the software is a good idea, but for good performance pure genealogy data (surname, maiden name, first name(s), birth data, death data, gender, and even marriage data, address...) should be stored in a separate, fast db, all additional information should go into the article page.
This would solve a lot of problems (see Automation / Representation of data), make data access fast, use unique numbers in the db, but informational titles in the articles...
  • Is there a possibility to view ../wikitree_db_init.php like all the extensions ?

--J.e 08:06, 30 Jun 2005 (CEST)

Deciding on Switching

We now seem to have these arguments:

  • Compatibility with WikiMedia projects is important:
    • If we want to include content from WikiMedia, rather than information.
    • If we want to be able to become a WikiMedia project.
  • Implicite rights are not the same world-wide:
    • Fair use does not exist worldwide.
    • PD does not exist worldwide.
  • We want to be able to use the license with other projects
    • CC-BY-NC-SA does not allow commercial use, which makes it hard to use with other projects.
    • GDFL has its faults, but it does allow using with other projects.
  • Freedom
    • Our contents needs to become more free to convince people to contribute existing research.
    • Our contents should be free without restrictions and due credit should be maintained (BSD).
    • I don't believe in the right to restrict the right of others to restrict access, as GDFL does.

And proposals:

  • Switch to GFDL
  • Switch to PD
  • Switch to BSD
  • Switch to CC-BY-SA (commercial use permitted)
  • Switch to CC 2.5 (almost identical to BSD in this context)


Now that everybody has had their say, what happens? Are we tired enough of this discussion to aacept the original proposal (GFDL), are we going to convince everyone = never switch, or do we need a system for deciding on this? Mysha

  • I don't think it's too far fetched that we switch over to another license. What should be done is set up a poll to decide what people want to do, have the poll to decide if we switch or not then if the people agree that we want to switch to another license, we then do a vote for which works the people want the most. Let each poll last like a week. Hell, we could do them both at the same time even to save time. Anyone that doesn't vote in both polls or disagrees with the results of the poll should it be to change licenses, delete their entries and let new ones be added later by another person under the new license. Janizary 02:17, 1 Jul 2005 (CEST)
  • The problem right now is the potential issue of what to do with existing content in a license switch. On the whole, this is a new project and I don't think it will kill the project too much to start over if necessary. It could get ugly if somebody strongly insists on the current license requirements. I guess that is the real question, and that is who is defending the current CC-BY-NC-SA? I concurr with Janizary that a poll should take place among registered users, and particularly noting the defenders of the current license scheme. Make it a separate page, and restrict to just voting for each license. Comments should be made here or outside of the voting area. An attempt to work out the license by concensus rather than pure majority rule should also be made, particularly if the vote is close. In addition, put a link to this voting page right on the main page, or even override content on all pages (as is currently happening at Wikimedia projects to elect new board members). RHorning 10:24, 5 Jul 2005 (CEST)
  • I dunno anything about these licensing agreements, but I think becoming a part of the Wikimedia project would get us a lot of links from Wikipedia. Imagine, every biography page has something like, "find out who's related to **** at WikiTree," or year entry's, "see who else was born this year at WikiTree." I think that would do a lot for getting the word out. Furthermore, I'm not to keen on the idea of someone profitting off of information that I work on gathering and putting up.--Dustinasby 00:07, 20 Jul 2005 (CEST)
    • Becoming a Wikimedia project may be tougher than you think. The one thing this project does have going for it is that it is currently up and running with a fairly healthy group of users who are contributing, clear distinction as to what content ought to go into this project, its universal nature and appeal to ordinary people in general, and the ability for ordinary people to contribute content (you don't have to have a PhD in geneology to know information about your grandparents). If the bugs are ironed out right now, a switch, if everybody including the project founder (Tjfulopp) wants to make the move, can happen to Wikimedia. That is the subject of another topic and not simply trying to decide the license (which I hope does get a difinitive answer). --RHorning 07:59, 31 Jul 2005 (CEST)
Personally I think it would be best to go public domain, as soon as possible. I don't think anyone is supporting the current liscence and PD would allow us to change liscences at a later date (if we wanted to), which would be usefull, especially if we want to become a WikiMedia Project. It also allows anyone to use the material on this site - afterall, shouldn't genealogical information be TOTALLY free.
I think the best way to change would to be to start afresh BUT keep a archive of the site as it is under the CC-BY-NC. We could then transfer all DATA and exactly copy any contributions by users who consider their work liscenced under PD (or the new liscence).
We NEED to start again as soon as possible so that there is as little information as possible to re-do. As I said above, we should switch to PD, if no agreement can be made VERY SOON, then we can switch to a liscence. --Bjwebb 15:39, 3 Aug 2005 (CEST)
P.S. I release my contributions so far into the public domain.
  • If we're switching to a new system, may I suggest changing more than the license? I've created a development branch at http://wikitree-dev.ballsome.org. The goal is to work seperately from the current tree to try to work out some of the kinks this one has (duplicate names, data validation, etc.), as well as getting the whole thing ready for MediaWiki 1.5. The code for this site doesn't seem to be going anywhere in the past couple weeks, as far as I can tell. Right now wikitree-dev is under BY 2.5, but that can be changed. If you want a sysop account, let me know. --Joeljkp 19:17, 3 Aug 2005 (CEST)
  • Yes, I would like a sysop account. Can content under BY 2.5 be reliscenced under another liscence?
  • Yes, I believe it can. It's not Share-Alike. See your Talk page for sysop details. --Joeljkp 16:24, 4 Aug 2005 (CEST)


  • Vote Now! - I created a polling station for the license debate. Take your discussion and your votes there. --Joeljkp 20:21, 9 Aug 2005 (CEST)

About Page

The about page is absolutely blank. I was trying to find out more about this project, when it was started, why I hadn't heard about it yet. I actually came accross this because I was browsing around Wikipedia looking for a good area to propose the idea of a Wikitree. Thanks for beating me to it guys! It's nice to see so many names up already. --Dustinasby 20:14, 19 Jul 2005 (CEST)

Unsure Dates

Often birth years are approximated from reported ages on census records. I have started following the practice of using "<" and ">" around years that might be off by 1 or 2 years. However, there needs to be some standard before people start using al kids of notations, e.g. "~"year, year"?", "{"year"}", etc.--Dustinasby 20:27, 19 Jul 2005 (CEST)

Maybe it would make sense to use a template for usure years, so people for sure what do do and we could change them all on will. I've created Template:Unsureyear. Dates are entered like this: 
{{Unsureyear|''Year''}}

For example: 

{{Unsureyear|2005}}

To give:

Template:Unsureyear

Thoughts?

Another possibility is to use templates to enter years and have the ability to choose display method in prefrences. Is this possible?

Well, I think it would be good to look at current genealogical practice before we decide anything. If you browse through the pages of the Alden Genealogy Project (which is a somewhat professional endeavor, I believe), they use qualifiers for dates: "about 1630", "before 13 July 1764", "after June 1658", "12 October 1732/1733".
It should be possible to parse these qualifying words. We could probably even get away with ignoring any wording before a date at all. Then we'd only need to be able to parse the / notation for uncertain years.
--Joeljkp 17:51, 1 Aug 2005 (CEST)

Sources

Citing sources is pretty important in both genealogy and some wiki, how can we impliment that here?--Dustinasby 20:29, 19 Jul 2005 (CEST)

ALong these same lines, how can we ensure accuracy. I mean, Wikipedia comes to the most widely agreed upon truth, but how many people know if I really have an Aunt Nessie or not and if she is or isn't the cousin of Alfred Hitchcock? Well I don't, but who's going to delete that under suspicion that it's false? I think there will be a lot of adding, but little deleting and merging. We need some sort of verification method.--Dustinasby 23:45, 19 Jul 2005 (CEST)

Place Names

We should come to a consensus on which place name to put on a profile: the current name, or the name at the time the event (birth, death) happened?

Personally, it makes more sense to me to name places according to how they were known at the time: a caveman born in Mesopotamia instead of Iraq, for example. If we agree on this, it may take some more work for a lot of profiles, though. For a person born in Plymouth, MA in 1650, it would be changed to Plymouth Colony, Kingdom of England, or whatever it happened to be called at the time.

Thoughts?

--Joeljkp 20:11, 26 Jul 2005 (CEST)

Your suggestion makes sense to me. --Bjwebb 22:12, 31 Jul 2005 (CEST)
I also agree. If desired by others, maybe we could put the modern names of these places near the bottoms of the articles? JohnAlbertRigali 05:48, 3 Aug 2005 (CEST)
Yeah, sure, maybe in a "Notes" section. Eventually it would make sense to be able to add a modern name in parentheses after the old name, but I don't think the leaf code would like that in its current state. --Joeljkp 19:21, 3 Aug 2005 (CEST)

30th Century

There is a link to deaths in the 30th century on the main page. I think this needs removing, but I'm not sure how. --Bjwebb 21:25, 31 Jul 2005 (CEST)

I agree. This points out a more general problem of data validation, certain things are obviously wrong, for example a data in the future. Somewhere (perhaps in the save process) there needs to be some elementary checks for data, that is on its face wrong such the date being in its future etc. I can think of several obviously wrong things that could be checked:

1. Dates in the future.

2. Persons whose death date is before their birthdate.

3. Persons whose spouse was born after the person died, or whose spouse died before the person was born.

4. Persons whose death date is more than 123 years after their birth date.(Ignoring the bibical Methusala etc.)

5. Women who have children too young or old i. e. they must be at least say 10 years old and no older than say 62 (which I think is current record).

6. Men who father children before the age of puberty (say 10 years old at least).

7. Probably before recent times (or at least a do you really mean this question), spouses of the same sex.

8. Dates of the year 0. 0 not existing in the western numbering system.

9. Other date verification, a month day # less than 1 or greater than 31 etc.

10. "Wikipedia = yes" when there is no article.

11. A person who is their own ancestor or descendant (goes to the identical name problem).

Checking the data is, of course, a good idea. However we should be careful not to limit the possibilities too much. There have been, are, and will be extremes. There has been a girl who gave birth at 5. There will be people who will exceed 123 years of age. If you include artificial insemination, there might be people who's father died before their mother was born.
Extremes happen, and Wikitree has to be able to cope with them.--JadziaLover 20:49, 3 Aug 2005 (CEST)
  • I agree. Most of this can be caught be people watching the Recent changes list. If we decide to limit these things, we should do it very carefully, and very slowly. --Joeljkp 20:56, 3 Aug 2005 (CEST)

Archive

This page is getting pretty long, could some of it be archived (in a WikiTree:Treehouse/Archive 1 or WikiTree:Treehouse/Old page.) I would do it but I'm not sure which discusions are active. --Bjwebb 15:36, 2 Aug 2005 (CEST)

Category:Births by year and Category:Deaths by year

I think that these categories should just contain the nth century births/deaths which will contain births/deaths by decade which will contain the years. I think this will help unclutter the categories and stop years belong to a category and its parents (which is bad practisce). Is anyone against me doing this? --Bjwebb 15:45, 2 Aug 2005 (CEST)

External Development Efforts

I've started a development project at http://wikitree-dev.ballsome.org. I'm intending to use it to explore some new directions and fix some issues I've seen crop up here. Note that this isn't intended as competition for the main WikiTree, but simply as a sandbox to try out different ideas. I'm also running MediaWiki 1.5 betas, so we can test out new features that might effect this site.

If you'd like to help, sign up there and I'll give you sysop privileges.

--Joeljkp 21:01, 3 Aug 2005 (CEST)


Mailing Lists

I've started a couple of mailing lists:


Fictional Characters

Assuming it hasn't happened already, it's probably only a matter of time until people start adding family trees of fictional characters. If we want to allow this, perhaps it should be required that all fictional characters be put in something like Category:Fictional or Category:Fictional Character? Alternatively (or in addition to this), we could have categories for different literary milieus, such as the Harry Potter series, Orson Scott Card's Ender series, or Neal Stephenson's books. Interesting borderline cases are religious texts like the Bible. --NeuronExMachina 06:16, 10 Aug 2005 (CEST)

Fictional characters are outside of the scope of this wiki. This project is billed as "the Family Tree of Humankind"; fictional characters don't belong to the human family tree. Anyone that is interested in contributing to the family trees of fictional characters should visit [7]. JohnAlbertRigali 07:47, 10 Aug 2005 (CEST)

Ok, that makes sense. How about cases like the Bible though, where people argue about whether or not it's fictional? Indeed, I think some people today claim to be able to trace their lineage back to figures in various religious texts. --NeuronExMachina 22:13, 10 Aug 2005 (CEST)

I'd say people who are commonly thought to be real (like many people in the Bible) should be included. If scientific opinion changes for some reason, it can be noted. --Joeljkp 22:21, 10 Aug 2005 (CEST) 


Headline text ==

Fictional Characters, Mythical, Legendary and Descent From Antiquity (DFA)

Related to the above someone has entered Julius and August Ceasar, very real persons who have a very real genealogy at least in part, a few generations of desscendants are known and I believe that the Ceasars could trace their descent remotely from the Roman Kings, who have a "genealogy" that traces their descent from the Roman Gods (or at least Venus). Similarly their are genealogies of Jesus Christ, and Mohammed who trace their descent from Abraham (the genealogoies and time frames of these two are such that both can not be correct). During the middle ages there were a number of "genealogies" concocted traceing the anscestry of various kings and nobility back to the Ceasar or various bibical persons. The general concensus is that these are all bogus and nobody has a valid genealogy from modern times back to antiquity (one possible exception with some missing generations is through the Byzantine Emperorers to Kings of Armenia and even this is disputed). This subject of "Descent from Antiquity" (DFA) is the touchstone for charlantism. This has been discussed a lot in the soc.genealogy.medieval news group. Its a real can of worms with "true believers" and realist both certain they are right, The topic is a real "kook" attractor and the cause of much bickering and nonproductive arguing. Even in many midieval genealogies there is much open to dispute and valid differing interpretations, but DFA is much worse. soc.genealogy.medieval avoids the worst of it by pointing out that before 500 AD is offtopic there. I would suggest that we should seriously consider the possibility of not accepting dates before 476 AD (the ususal cut off for DFA) or of requiring some special procedure (very high standards of proof) for adding them. On the other hand there are very real genealogies for portions of antiquity (e. g. Egyptian Kings) they just can't be validly connected with modern day descendants. I think if we make a policy decision to prohibit dates before 476 AD we can avoid many problems, bickering, religious disputes, and the bad preceptions that come from having what many/most people would consider clearly false or bogous genealogies. I invite discussion as I think this is an important policy dececion that could save much trouble in the future.

  • I think banning anything before a certain date is an extreme move on our part. As you say, there are groups of ancient kings and such that have their own seperate genealogies, but that can't be reliably connected to anything modern. I'd say that's still a valuable addition to the site, and that they don't need to be connected to anything to make it work. I'd say a possible solution to this is to let these people play, but to require a notice on each of these pages that says something to the effect of "This is a possibly fictional person. There are no current records that can prove the accuracy of this page. Use at your own risk." It will be even easier if people get in the habit of putting their sources on each page.
In short, I'm of the opinion that any strict ban is bad, and that we should wait and see what happens. Notices can be placed on disputed pages, and abusive people can be banned. Let's stick with that for now. --Joeljkp 19:50, 11 Aug 2005 (CEST)

I don't think that this wiki needs a strict ban on certain leaves or any disclaimers on the leaves. However, maybe contributors should be made aware that it's incumbent upon them to contribute data that is well substantiated. This wiki is intended to be an authoritative source of data, but it can only inherit such authority from the sources of data that feed it. Bad leaves will yield a bad tree; good leaves will yield a good tree. Perhaps this point should be mentioned in an introductory blurb that gets distributed to all new users. JohnAlbertRigali 07:31, 12 Aug 2005 (CEST)

Perhaps on the "Add new profile" page? --Joeljkp 19:48, 12 Aug 2005 (CEST)

Let's keep mythology out of here. This should stick to straight, confirmed data. We should keep entries for the likes of Jesus, Moses, Noah, Eve and Adam to bible study sites. The same goes for King Arthur and other local legends for regions. 65.94.52.193 01:25, 24 Aug 2005 (CEST)

If you deal with direct lineage linked information from the Bible, you can get up to 2000 different people that are linked together. Some apochraphal books can extend those geneologies a little bit more, and if you prune the generations before Abraham it only gets rid of about 100 people. That at least gives you some realistic people who did live in antiquity, and is not mythology as you so state. I've seen some credible extensions of biblical geneologies that may push to as late as 1000 A.D., but you must be very skeptical for any real links to modern individuals. Many European kings (notably Charlemaign... Karl the Great, etc.) "claimed" ancestry that links back to Bibical times, but those links are tenuous at best. Linking to the Bible will be tempting to almost anybody, particularly those who are trying to gain legitimacy.

As far as links to medeval kings, I think that is much more plausable, and you might discover that many of those kings were the "father of their country" in more ways than one. Especially as people intermarried and over the course of dozens of generations, including "illigitamate" relationships and lines of 4th and 5th sons that failed to recieve inheritance, so were religated to the periphery of royal society and occasionally married commoners. What I'm suggesting is that perhaps somebody could claim decent from royalty and be a rather ordinary person. Claiming ancestry from the Bible or the Pharoahs of Egypt, on the other hand, is a lot less likely. --RHorning 12:18, 25 Aug 2005 (CEST)

Fictional works don't give factual ancestries, the Bible is a fictional work, it has just as much a place in here as Yacko, Wacko and Dot. We must either stick to straight data or we will end up with chaos and entries for the likes of Harry Potter and Thomas Marvolo Riddle. Using the Bible to make a geneology would be like making a line of all the Emperors of Japan, who are decent in a straight, unending line from an island god - it just doesn't work. Janizary 18:28, 25 Aug 2005 (CEST)
I don't know why you have this viseral hatred of religion or an incredibly narrow and shortsighted view of the Bible as a historical record and as literature. I am willing to conceed that documentation for Bibical geneologies before Abraham is questionable at best, as is any outside documentation as if the people really existed prior to that patriarch. I was willing to conceed that point completely, but that only gets you through the first couple of chapters in Genesis, not the whole contents of the Bible. I am contending that Abraham (or Abram as he was called earlier) has outside historical and archeological evidence, and as you move forward in the chronological record of the Bible the collaborative evidence as to the historcal existance of the people described in the Bible increases to the point of absurdity. Whether the people performed the miracles and other "wonderous" events of the Bible is subject to interpretation and belief, but I have no reason to doubt the existance of King David any more than I have reason to doubt the existance of Julius Ceaser, Adolph Hitler, or your mother, Janizary. These are not just random fictional geneologies, but a substantial body of research material that is of similar quality to many other published geneological records. I know this because I've actually entered into geneological programs this data, and I have a GEDCOM file of these people from the Bible, if you really are interested. I'm not the only one who has done this either. I've also seen the archalogical evidence, and the Bible not only contains records of the Hebrews, but in a few cases the lineages of kings and monarchies of bordering kingdoms as well, together with references of neighboring countries and external events of those countries. Ignoring the Bible and similar materials from your realm of literature also ignores the historical roots of modern events, including the American war in Iraq and the 9/11 attacks, as well as the events going on right now in modern Israel. That will leave you a very poor in knowledge person indeed to ignore this record and why people are doing what they are doing in a critical part of the world, when it will have a very direct impact on your life regardless of what country you are from. Comparing the historical existance of Solomon to Harry Potter is just going a little bit over the top as well as a completely false and misleading statement. --RHorning 03:42, 27 Aug 2005 (CEST)
Religion has it's place, science isn't it. That the books the Old Testiment were based on were written by 12 Rabbi long after these events are purported to have occured means there is no way that the information contained therein is accurate. These geneologies are based on worse than second hand, it's oral tradition that was written down long after it took place. These cannot be taken as fact even if you dismiss the various nonsense about miracles and people living hundreds of years. The New Testiment is no better, being written more than a hundred years after the events describing Jesus, by people that spoke with the followers of Jesus, not the followers themselves, then being translated over and over so that all meaning of the original documents are lost. This isn't meant to be personally insulting, but I think of the Bible as as much of a historical document as the Lord of the Rings. Hitler existed within the lifetime of people that are still walking this world, we have images of him which were talken with trusted equipment - there is no question involved. Julius Ceaser's existance isn't in question, though all details of him are put to a level of question, the reason I trust in Caeser is because the Romans actually documented things extremely well. The nomadic Jews did not document things while wandering the desert, they didn't have cameras; they spoke, talking to eachother. Have you ever played a game of Telephone?Janizary 05:34, 27 Aug 2005 (CEST)
Far from being nomadic people by the time of King David, they had established cities in the fertile crecent, traded with the Phonecians, Egyptians, Babylonians, Greeks, and other peoples in the area, established diplomatic relations, and behaved like many of the other monarchies that existed in the area at the time. Again, I'm not talking specifically the pre-Abrahamic times, and I will openly admit that before the establishment of the Hebrew monarchy that the details were rather sketchy at best. As far as the "12 rabbis" are concerned, I would like to see a legitimate souce on that point, and also point out that oral traditions are still a significant factor in passing human knowledge of the past from one generation to another in many parts of the world. My brother-in-law is of direct Ghanian ancestry and almost none of his ancestral history (besides what he has recorded himself) has actually been put down on paper or recorded in any other fixed medium. For people who don't rely on paper and pencil for recording information, an incredibly large amount of information can be passed down from one generation to the next without written records. And there have been written copies of almost every book in the Bible that can be found on the dead sea scrolls, with portions of the book of Deuteronomy that date back to at least 1000 B.C or earlier that have been scientifically dated and verified.<p>Unfortunately there has also been a very systematic destruction of all things Jewish throughout the world that has gone on with the governments of many countries, including Rome itself. Most of the Temple of Herod and all of its sacred writings and other records were specifically destroyed and then buried in the middle of the Mediterranean by the Roman Navy. Herod himself was no slouch and specifically burned all of the geneological records of the Jewish people that had traced almost every Jew clear back to Judah himself with details that are only hinted about through Biblical records. The Jews were a very literate people and to call them a bunch of mindless nomads is also quite insulting. I know of the 'net law of mentioning Hitler, but in this case it also pertains especially to Jewish records, becasue the Nazi party also did specific disinformation campaigns to modify historical records and to try and finish the job that the Romans started a couple of centuries earlier. That through this deliberate action on the part of governments with essentially unlimited resources have not completely destroyed all records of the Jews is in many ways remarkable by itself. I'm not asking that the Bible be treated any different than any other ancient historical document, but to compare it to the "Lord of the Rings" is insulting at the very least, and worse, perpetuates injustices done by what ammounts to be actions of evil governments of the past. "Lord of the Rings" was always from the beginning a fictional work, and people alive know the individual who put the words down on paper. The Bible, on the other hand, has always purported to be a historical document, and certainly comes from antiquity regardless of what you think of its authorship. I would also question strongly the critics of the Bible as a historical document as much as I would question the apologists, in part because of this historical bias on the part of governments both past and present. --RHorning 02:27, 6 Sep 2005 (CEST)
The Torah, Nevi'im and Ketuvim are the three works which collectively make up your Old Testament. The Jews have kept pretty good track of the people that were the ones that put them down; Psalms was written down by King David and Ten Elders of Israel, Proverbs was written down by the men of Chizkiah, a king of Judah, Job was written down by Moses, and it goes on. After these original works were made they were then collected together by this group of rabbi that sorted through what was official and what was not - just like has been done many times with the Christian Bible, so that parts were added, removed and modified to suit needs. The fact that archealogical data point out the religious origins of Judaism going back to a time when god had a wife should tell you something about how accurate and exact these details remained over time. Oral traditions are not a basis for fact, they can only ever be a basis for an investigation to disearn fact. Janizary 06:47, 6 Sep 2005 (CEST)

Deletion Request

I don't know if this belongs here, but I haven't found a proper deletion page to put this...

I created pages for several of my relatives under the surname McMerchant: Joseph McMerchant, Richard McMerchant, Christopher McMerchant, and Abigail McMerchant. The problem is that the correct surname is actually Macmurchie (evidently, I severely misheard!).

Yesterday, I moved all the incorrect pages to their proper names. However, the McMerchant pages still exist as redirects, and need to be deleted. Thanks in advance! -- Miranda Jackson (Talk) 01:47, 13 Aug 2005 (CEST)

  • You can delete a page by replacing the contents with {{delete}}. To view a redirect, visit the page, then click on the title in the "redirected from title" line. --Joeljkp 20:20, 13 Aug 2005 (CEST)

I'm running through the queued up deletes right now, things shouldn't be so bad any longer. Janizary 06:26, 22 Aug 2005 (CEST)

Search

I think that the search page should have a message saying 

There is no profile which matches this search, why not Create It

when no results are returned. Like on Wikipedia.

Edwin Webb

I have a problem with my family tree, on Edwin Webb it says that his children are his siblings - why?. His son has the same name, which might be the problem, but I named him Edwin Webb (1900). What should I do? --Bjwebb 12:13, 16 Aug 2005 (CEST)

"Personendaten" in the German Wikipedia

You might be interested in the Personendaten-Projekt at German Wikipedia as I wrote about [http//en.wikibooks.org/wiki/Wikimania05/Paper-JV2 here]. I extracted data of 47785 people in the German Wikipedia into a database: http://wdw.sieheauch.de/people_today.php As soon as you switch to GFDL or CC-BY-SA you can use the data. -- JakobVoss 18:02, 25 Aug 2005 (CEST)

Bug in determining spouse

Not sure if this is the right place for reporting bugs; is there (or should there be) a special section for bug reports?

Using the van Gogh family as an example: 

 1 Theodorus van Gogh had a child Theo van Gogh
 2 a couple of generations later Johan van Gogh had a child also named Theo van Gogh
 3 the display screen for Theodorus shows Johan as the spouse of Theodorus.

This is despite the facts that 

 1 there is no overlap in dates (Theodorus 19th century, Johan still living)
 2 both are male
 3 the younger Theo has his birth date in parentheses (1957) after his name

Hope this provides evidence for someone to improve the code and apologies for being incapable of fixing it myself. -- Ruszewski

This is the same problem as #Edwin Webb above. See Talk:Leaf_Extension_Code#Database_Worries. --Bjwebb 11:28, 2 Sep 2005 (CEST)
And I proposed a patch to fix it months ago, to no avail. Best thing to do in the meantime is to make everyone unique for the full length of the name. That is, change Edwin Webb to Edwin Webb (blah). --Joeljkp 17:19, 2 Sep 2005 (CEST)
Have you fixed it on Wikitree dev? Also, could you try changing the tree code to show maternal ancesters there as well. --Bjwebb 18:09, 2 Sep 2005 (CEST)
Yeah, that part will be fixed for sure. See the Treehouse page over there for some decisions we have to make before I can do parent/spouse stuff. --Joeljkp 02:23, 3 Sep 2005 (CEST)

Retrieved from "http://wikitree.org/index.php?title=WikiTree:Treehouse/Archive_1"
new profile