User talk:Phlox

 Feel free to Drop me a note. Archived talk: 1 | 2 | 3 ending April 2009 | 4 | 5 | 6

Properties
I see you are creating properties. Very good. I guess these can be used to create couples. For instance, shows people who married their first cousin, but not who they married. Should really be displayed as Arie Korver x Anna Korver. If Arie has the property "married cousin" this can be done. rtol 10:39, 1 May 2009 (UTC)
 * You would be able to do this dynamically via a query. It would be a single #ask, so for all practical purposes it would look like a property anyway.  I left some breadcrumb links over the help forum in future of info pages thread.  There are some example wikis that have used it and some good examples/discussions.


 * In db design the rule is not to redundantly code something that can be derived (easily). To do otherwise introduces database inconsistencies.  With that said, wikis are fundamentally unstructured databases.  Anyway, that is my first reaction to the cousin married thing.  We could also hard code stuff like property lived in New Hampshire.  I rather think that "had residence" whose property was "has location in state" is a more proper way to encode this kind of structure.


 * Everything I am doing now is very makeshift, so don't assume too much about what is happening with it. I haven't formulated strong opinions yet.  I plan to be doing a few approaches and then will release a tool so that everyone can convert over stuff as they please.  I am mostly interested that we do this right, and that our decisions will establish familypedia as the premier semantic genealogy site.  Everyone else is playing the quantity game of piling on gedcoms.  We need to play with different rules if we are to dominate.  Our strength is collaboration and quality- that will in the end crush everyone.  So I am of the opinion that we should move towards having a very friendly version of a hard core evidence based system that operates from the notion that genealogies represent multiple and often conflicting believed realities.  All of our so called facts are really just assertions with varying degrees of certainty.  To add a formal semantic layer over fundamentally contradictory knowledge is just GIGO (garbage in, garbage out).  Anyway, that is my thinking as of today.  - ~  Ph l o x   16:20, 1 May 2009 (UTC)


 * Got it, and look forward to these enhancements. rtol 18:26, 1 May 2009 (UTC)


 * I know that it is early days, but I have a suggestion about "Property names": there is an asymmetry in using "Spouse", "Spouse2", "Spouse3" etc which complicates the templates. I would prefer the series to be "Spouse1", "Spouse2", "Spouse3" etc, and so on for the various "multivalued" properties (eg AFN). Thurstan 04:18, 2 May 2009 (UTC)
 * Yeah, I did that ordinal numbering thing in a clumsy way. I am on it. - ~  Ph l o x   05:31, 2 May 2009 (UTC)

Simple creation person-page with info-page

 * If I may interject here, my opinion is that every responsible contributor should have the option of running a bot if they want. The trouble is that the bot software that we use is too complicated for most people to figure out.  I posted some documentation on how to run pywikipedia python tools, but only AMK was brave enough to try, and admittedly, it is tough for even technically minded contributors.  I have a solution to this problem, but it requires some additional work to adapt to info pages and the new structures.  It is very easy to use and is compatible with most Apple and Windows (XP or newer) systems.  I expect I may have something in a month or so- hopefully you can manage until then.  In the meantime, feel free to post an inquiry on my talk page.  PhloxBot can easily perform thousands of transformations.   Usually if I have a text file in the form (old name)(tab)(new name) I can do this.  Give me an example though because it depends on if you need text in the articles changed as well.  - ~  Ph l o x   16:18, 5 May 2009 (UTC)


 * I would be brave enough to try it, but I don't have even Windows 2000, let alone XP. Does py work with Ubuntu? — Robin Patterson (Talk) 10:56, 9 May 2009 (UTC)


 * what I wanted and discussed with Richard Tol, you did for a part with the procedure "Simple page for person" but what I also wanted was the automatic fill in of surname, given name, fullname, short name, article name, YOB, YOD. Fred Bergman 08:03, 6 May 2009 (UTC)

I just discovered that the possibility of simple creation perhaps longer existed. It is not mentioned in the dutch edition of the frontpage, in enlish I saw it !Fred Bergman 09:10, 6 May 2009 (UTC)

flakey navobx- note to self
Tnavbar seems to be the source. If navbar= plain, then the title bug goes away. Maybe same problem with wikiabanner. - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x  17:36, 8 May 2009 (UTC)

Pioneer George of New York
Page looks impressive, to say the least. I see no toolbar as described, but I saw the thing that opens a can of yummy spaghetti.

I've posted his page to my profile on Facebook, with the following introduction:
 * Semantic MediaWiki is moving Familypedia up a gear! (This page is a "Beta" version but pretty impressive.) Swiss ancestry certainly has its good points.

— Robin Patterson (Talk) 11:01, 9 May 2009 (UTC)
 * By edit bar, I meant the wikia bar that says edit this page, leave a message, history, etc. Before the "Edit this page" is the Edit with forms, so you obviously found it.
 * The thing I found was a show/hide thing about half-way down. I'll try top left next time. — Robin Patterson (Talk) 13:48, 10 May 2009 (UTC)
 * Editing with this long form is probably not the preferred mode for users. Perhaps they will learn to click just on the bit that they want to change, like birth, wedding, children, and what not.


 * Perhaps you did not see, but on each of the events is a place for images. Adding an item here guides the user through an upload, and the resulting file name is stored with the article for the contributor.  Further, the size of the image can be set by default, so they don't have to know anything about how to jam it into an infobox.  In similar ways, we can control the decoration to names of counties, surnames and so on.  I am not going to mess with the minutiae yet.  I just want to press to make sure it can do all the hard stuff, or whether there will emerge some hidden obstacle that blocks us from using SMW.  There is a bunch of stuff I find annoying, but all and all, much more usable for normal contributors, and for sophisticated users, I think they will welcome the departure from the frail and impenetrable obscurity of my Info templates code.


 * - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x  16:04, 9 May 2009 (UTC)


 * Please don't disparage the info templates code. Great work, which now is well enough documented to get most new users diving in successfully without specific invitation. You will have to persuade them that there's a better way. — Robin Patterson (Talk) 13:48, 10 May 2009 (UTC)


 * If the three wikis you've been trialling or discussing SMW on are not enough, try http://thirdturn.wikia.com/wiki/User_talk:DaNASCAT#blank_pages for a starter into that real-life subject to see if maybe Uberfuzzy can help you get some value from their experience. I listed a couple of other possibles on the Help:SMW page. — Robin Patterson (Talk) 13:48, 10 May 2009 (UTC)


 * Well, as a doting parent of course I am proud of the info pages approach. They are powerful and I am pleased with their success with new users.  SMW encoding may be an unwelcome transition for some and of course it is up to the community whether this radical departure from info pages merits attention.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   17:33, 10 May 2009 (UTC)

Internal error
Why do I get this when trying to save a page on which I have just typed SCat and nothing else? Internal error From Genealogy Jump to: navigation, search

Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information. — Robin Patterson (Talk) 10:15, 12 May 2009 (UTC)

Most peculiar. I got it again when trying to save the above. Now I can see that the above worked, but my surname page hasn't appeared. — Robin Patterson (Talk) 10:34, 12 May 2009 (UTC)

Internal error
Why do I get this when trying to save a page on which I have just typed SCat and nothing else? Internal error From Genealogy Jump to: navigation, search

Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information. — Robin Patterson (Talk) 10:36, 12 May 2009 (UTC)
 * I saw some weird formatting but it appears to have cleared itself. The template is not doing anything odd, so it is likely some wikia staff maintenance activity on the server producing hiccups.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   17:10, 12 May 2009 (UTC)

Angela sorted it out in a few minutes, as you may have noticed from the mailing list. --— Robin Patterson (Talk) 05:56, 14 May 2009 (UTC)
 * I have been keeping my head down and not paying attention to what's happening anywhere else. i figure you will tap my shoulder if there is an avalanche or something heading our direction...  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   06:16, 14 May 2009 (UTC)

OS
I use Windows Millennium Edition. Thinking of upgrading to Ubuntu unless, or if, I get a new machine. — Robin Patterson (Talk) 05:56, 14 May 2009 (UTC)

New contributor
hmm well i wont create a username and all, i just found this wikia thing by chance, it is sooo similar to wikipedia, is it related somehow??? has all the same formatting etc.... i have a username on wikipedia though... 24.0.43.144 17:15, 13 May 2009 (UTC)

New page
Excellent progress on the Semantics stuff. However, if I now start a new person page, I only get a form -- even if the info page of that person already exists. While forms are great for the uninitiated, we should also be able to do things without them. rtol 07:59, 15 May 2009 (UTC)


 * happened at Engeltrude de Fezansac (?-?) rtol 08:05, 15 May 2009 (UTC)


 * no worries rtol 08:06, 15 May 2009 (UTC)

"Dude" in relation to Hoorn
Concise Oxford Dictionary, 10th ed: "... N. Amer. informal n. 1 a man. 2 a dandy. ... ORIGIN C19: prob. from Ger. dial Dude 'fool'"

This man not born or married in Hoorn and unlikely to die there.

Am I right in thinking info pages are a key feature of our use of SMW? — Robin Patterson (Talk) 04:51, 17 May 2009 (UTC)
 * In the vernacular of western united states subculture, a dude is a person of sterling character, and or outstanding accomplishments.
 * The SMW stuff is temporarily dependent on info pages for their data. I put in a patch so that we have a mirror of many (but not all) of the fields in the info pages.  This sort of jury rig was necessary so that I could quickly do some volume tests.  The SMW approach is to have what we think of as info data on the same page as the article, as is the case on the George Spencer Geer (1836) prototype page.  The Geer article wikitext is what SMW pages will look like in the future.


 * As I was remarking this morning, the Geer article is what a largely tabular article would look like. However, it is possible to set the values inline in a text passage like with the robert hester example I was referring to in the 2007 article.  Some folks may prefer this style, and that is in many respects preferable to the tabular form that tends to perform a life-sucking reduction of people's lives into a table of vital statistics.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   05:55, 17 May 2009 (UTC)


 * Thank you for all of that. I'd better check that I've read all your recent replies and essays before I ask too much more. Seems we have at least three of us working on this, with one doing over 99% but the others making an effort. It must be a good thing. I've mentioned it on two of my Squidoo lens updates now and copied to Twitter and Facebook. — Robin Patterson (Talk) 06:41, 17 May 2009 (UTC)
 * I am scouting out way way ahead of the main party on some of this, so if I lost you, just ignore me. I just want to make sure I don't set it up a certain way that will wind up coming back to bite us.  Speaking of which, did you follow what I was saying about the  migration kmz files?  Next time you are at an internet cafe, check out google earth and how it displays the notes.  Each one of the notes can have linkbacks to the genealogy wikia article.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   06:53, 17 May 2009 (UTC)

Nested and recursive queries
Hoping to build a query "What is the relationship between Ms Smith and Mr Jones?". As a first step, I'd need the intersection of the sets of ancestors of both. So, returns my parents, but  returns an error rather than my grandparents. Any hints? rtol 07:55, 17 May 2009 (UTC)


 * Your married cousin test answers my question. rtol 08:10, 17 May 2009 (UTC)

So I can't exactly put it in his article?
http://genealogy.wikia.com/index.php?title=Henry_I,_King_of_England_(1068-1135)&action=history

— Robin Patterson (Talk) 08:45, 17 May 2009 (UTC)
 * I don't see what's wrong, should be ok, but I have to turn in. I'll check it tomorrow.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   08:51, 17 May 2009 (UTC)

Test
Template:OrderCMTest9 works fine in general, but not for Emma de Limoges (c960-c991). I guess this is because she's a daughter from her father's second marriage. Thanks! rtol 11:39, 17 May 2009 (UTC)


 * The problem in OrderCMTest9 was Children-S2 v Children-s2. The latter works. rtol 16:51, 17 May 2009 (UTC)


 * Note that I also made children-s2 a subproperty of "family member". This may be wrong. rtol 17:01, 17 May 2009 (UTC)
 * No. Should be a subprop of children.  Not sure why you are explicitly probing children-s2 anyway.  Children-s2 is a sub property of Children, so you should be picking up all children-s2, s3 etc.  If this is not the case, point me to a specific example.  Thanks.  Also, by the way, don't get too attached to these field names.  We are at the learning curve stage and so everything should be regarded as makeshift and experimental, that could be radically revamped with new names or different approaches?  OK?  I expect we should have things substantially sorted in the next month though.  For permanent work, no one should be encoding assuming the current SMW fields except for experiments.  If people use Info fields, they are safe.  Ok?  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   17:03, 17 May 2009 (UTC)


 * Have a look at Emma de Limoges (c960-c991). "children-s2" returns her dad. "children" returns empty. I agree that "children" should be a superset of "children-s1", "children-s2" ... (just think of the test Married third cousin) but it is not at the moment. rtol 17:13, 17 May 2009 (UTC)
 * I'll look at that. Hopefully it is not a flaw in SMW, because the superprop stuff does work sometimes for these depth searches.
 * Problem fixed. Thanks! rtol 17:51, 17 May 2009 (UTC)
 * By the way... there is a bottom up search for cousins by following the parentage links rather than the children links. The weakness of this approach is that folks usually add bunches of children but don't bother declaring the child nodes.  Again, we could deal with this if AWB is easy enough to be used by adept folks such as yourself.  Right now, the latest release gets hung on wikia, at login, but I'll deal with that if the awb devs don't get to it soon.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   17:22, 17 May 2009 (UTC)
 * Cousins is easy enough. 13th cousin twice removed is hard. rtol 17:51, 17 May 2009 (UTC)

(undent) Good. Yes. An issue to be sure, and exponential expansion problems are generic to this problem set. There is a caching approach that I am considering that will alleviate some of the server load issues. - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x  17:55, 17 May 2009 (UTC)

Query depth
I created a "Married third cousin test". This apparently fails (or rather, always returns true) because I nest 4 queries. Is that too much? The "married second cousin test" works fine. rtol 20:16, 17 May 2009 (UTC)
 * There is a query maximum nesting depth setting for the extension. You could have run into it, but that doesn't seem like a lot of queries to me.  15Queries to get to each set of gg grandparents, so 30Queries max, right?  You are in new territory here.  Let me know if you come up with anything.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   01:21, 18 May 2009 (UTC)
 * Pls have a look at Isabella of Portugal (1397-1472) (experiments). The first query correctly returns Edward II. The second query returns an alphabetic list of everybody. Should be empty. Thanks! rtol 05:38, 18 May 2009 (UTC)
 * I didn't answer this but shall know more when I finish with a radically different approach to this. May make whatever this bug is irrelevant. - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   08:16, 20 May 2009 (UTC)

Numbers and info pages
Two questions:
 * 1) I'm a bit lost on the birth and death years. There are properties date-y, but all the info pages have year rather than date-y. If birth year and death year were both properties, I should be able to do death year - birth year to get age at death, right?
 * 2) I know how to write age at death to the page at which I call the function that computes it. How do I write this to a different page, say the \info page?

Age at death is a simple start. If I understand how this works, I'll add inbreeding indices and stuff. rtol 07:52, 20 May 2009 (UTC)
 * The naming conventions of the fields are all screwed up, so I am renaming them soon. The renaming has to do with following uniform rules so that the naming is predictable, also a lot of ordering. Eg so that postpending numbers for events is more simple eg date wedding1, date wedding2, etc. rather than wedding1 date, wedding2 date.
 * Info pages have not been converted properly yet. The current values derived from info fields is very makeshift for the purposes of volume tests on the software only.  That is, Template:Set facts from info is a hack, and not part of anything permanent.  It's just scaffolding that may have some role in the transition, but is not a permanent thing.
 * Date-y and date-m are permanent fields and will be in the final version. These are for partial dates only.  When day month and year are available, these fields are irrelevant.  The reason for the redundancy is that the full "date" field will provide a day even if the user didn't state one.  This usually is = to the day when the user edited the box.  Very prone to error= so we have these partial things.  Anyway, when the info page has all three values, these will get into the date field, not the date-y and date-m fields.  Okay?
 * Really, it might be a good idea to hold off a bit longer on your inbreeding templates. There is something that is not yet done yet that will be very useful for efficient processing of this sort of analysis.  That is, if it works.  If you wait a day or two, I may have something stable for you to work with.  Of course, you may do as you please, but I just think you may have to do substantial rewrites before this thing is stable.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   08:12, 20 May 2009 (UTC)


 * No worries. I'll hold off for a while. rtol 08:53, 20 May 2009 (UTC)

Oldest paternal ancestor
It's crawling. Found by great-great-granddad so far.

Please confirm or correct my understanding:
 * 1) To initialise, this puts a tag on my page that says my oldest ancestor = my father.
 * 2) It checks whether my oldest ancestor's father is there and if so, it changes the tag on my page that says that my oldest ancestor = my oldest ancestor's father.

In all this, "oldest paternal" is a local variable in the template.

If I get this correctly, it can be used for many useful things. rtol 07:37, 21 May 2009 (UTC)
 * Yeah. All property values are "local" and they aren't persistent.  If you execute template code that skips saving the property value- even if you did nothing to it, the value goes away.


 * Variations: you could make another that crawls matriarchal line or jumps more generations, or save more info at each generation. As you noticed, if we try to do too many queries we run into server load limits. At first we would have thought that imposed some hard limits about how many generations we could go back due to computation complexity but actually this approach suggests that is not so.  So this shows how you can do a bit of the problem then save intermediate results for processing at the next save.  That suggests that no problem is intractable.  We could achieve immense descendants or ancestors lists compiled by successive saves.  The template code could get a little complicated, but it could be entirely done in templates if necessary.  I rather think that client side processing with AWB would be more efficient and less ugly code, but this technique can be used for lots of useful things.  Have fun with it.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   08:44, 21 May 2009 (UTC)

Broken
When clicking on the red link, it says: Add Person (short form): Robert I, Count of Flanders (c1032-1093) From Genealogy Jump to: navigation, search

Error: no form page was found at Person (short form).

rtol 07:22, 22 May 2009 (UTC)


 * No worries. Fixed now. rtol 07:49, 22 May 2009 (UTC)

Ahnentafel
Admiring your new ahnentafel. Great work. I'd put "set ahn" in "showinfo person".

Did some experiments. return the set of people to whom CM is the maternal grandfather, while returns all descendants.

More importantly, returns all common descendants of CM and AG. This is easily put into a common descendants template. (Will do later this weekend.)

Now, if we'd have a property that works the other direction with a template "set desc" then would return all common ancestors of CM and AG -- or rather, would show that the two are not related as far as we know. rtol 08:28, 23 May 2009 (UTC)
 * You understand the power. Yes, the inverse descendants lists are useful and should be plugged in.  Using math on the ahnentafel numbers, you will be able to do very distant relationship analysis.  Take a look at the log calculations that i doc'd on the ahnentafel convert documentation page and you probably can do all you want.  It doesn't seem to break, but I will continue an exhaustive build up to some present day ancestors.  We may lose some digits of precision, but I have a way of dealing with that problem if it arises.


 * The only trouble with this approach is how much time it takes to percolate new information throughout the tree.  If the property storage does not have some hidden limit, then it should be possible for descendants to do AND queries to find nearest common ancestors.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   08:45, 23 May 2009 (UTC)


 * Common descendants works like a dream. See Louis the Pious (778-840)/descendants rtol 10:37, 23 May 2009 (UTC)

High numbers now look much better, but the numbering itself is now longer correct. Self = 1, father = 2, mother = 3 ... rtol 17:57, 24 May 2009 (UTC)
 * I don't understand. Do you see something undesirable with the data I am generating, or data you are generating? - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   18:05, 24 May 2009 (UTC)


 * Sorry for being unclear. If you look at my Ahnentafel at Richard S.J. Tol (1969-), you see that my father has number 3 (not 2), and his father has number 7 (not 4). My mother has number 3 too. I look at a number of your Ahnentafeln, and the father has number 3 on all that I checked, while the list was too long to show the mother. Probably a simple error. rtol 18:40, 24 May 2009 (UTC)
 * Oops. Thanks- I know what I did- it was after a scan for duplicates I put in.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   18:45, 24 May 2009 (UTC)

Descendants
Template:Set desc works, sort of. See Emma von Waldeck-Pyrmont (1858-1934). It only works for people with a single child, though. I guess I have to add a line for every possible child? Or is there a short-cut? rtol 15:53, 23 May 2009 (UTC)
 * That's because the query for father or mother only generated one value. If you chop up the multiple values and feed them to your aux1, it will work fine.  There are three ways to do chopping.  The easiest is arraymap, but this technique has a problem if you cannot get the output to use something other than commas.  That might be the case with dumping out children.  The second technique is to use template output.  I think I showed that in one of the demos.  The third way is to use string functions, but this can create very opaque code as you saw in the aux routines.  Wherever possible, if you can write it so that it not only works but is easier for someone following you to figure out, then try and go the extra mile and find an easy to read way.
 * Let me know if you'd like further assistance. Basically, the way I develop these is see what I get from a basic query, like


 * , and make one piece of the puzzle work- like chopping. Then later I replace the "Juliana.."whatever test page with the generalized value (like  in this case.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   16:27, 23 May 2009 (UTC)


 * Arraymap is easy but does not solve the problem. I won't solve this tonight. Feel free to experiment. I'll have another go tomorrow. rtol 19:35, 23 May 2009 (UTC)
 * It's your puppy. I could take care of this, but really I have to focus on making sure all the big tasks are solvable.  I don't need to solve them, just know that we could do what we want with a particular database structure.  So if really immense ahnentafel tables work then the descendants thing should work too.  I not yet sure that the way I used N-ary properties is the best way.  I really would like it if the engine could treat these multivalued N dimensional lists as if they were top level lists (that you could sort on each element, etc.)  Possibly we can get around those limitations for 85% of the things we want to do.  I don't know yet, so the bot will be cranking out more of these ahnentafels before I am more confident that things won't break when we do this for all individuals. - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   19:49, 23 May 2009 (UTC)


 * It is now working, building a set of descendants and which can be used to build a list of ancestors and common ancestors. See Richard S.J. Tol (1969-).
 * In the end, I reverted to "Get|Key=Child1", using the slightly confusing fact that Set=Element adds Element to Set. The auxiliary templates do not work on sets anyway, so code would have to be repeated in either case. There is no simple way to get an element from the set return by #ask or #maparray, so I reverted to the older and simpler method.
 * Lists of descendants are larger than lists of ancestors, so I guess you want to do a volume test before we announce this. Just add . rtol 07:46, 24 May 2009 (UTC)
 * It generates names in a descendants field, but what is the use of the calculated number? How does children2, children3 etc groups work?  Why do you need an n-ary array for this?  If you did store ahnentafel numbers, can you think of any useful purpose for being able to retrieve them when searching descendants?  If so, how would they best be calculated/ stored? - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   08:49, 24 May 2009 (UTC)


 * 1 = self, 2 = children, 3 = grandchildren, 4 = great-grandchildren and so on
 * The main purpose is the detection of common ancestors and thus relationships. A side benefit is the construction on ancestor lists by generation. rtol 09:16, 24 May 2009 (UTC)

I will be more blunt. You understand the generation numbers, but not the relationship (the pathway eg maternal grandfather etc.) to the individual. It seems to me that is an unnecessary deficiency. - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x  09:34, 24 May 2009 (UTC)


 * Recall that I'm a Frisian. Bluntness is a virtue.
 * The Ahnentafel stores the exact relationship (e.g., paternal grandmother) already. Generation can be deduced (3 < Ahnennumber < 9), but this gets awkward for greater distances. Descendants stores generation number. Much easier. Exact relationship can be looked up in Ahnentafel anyway, so why store it again? rtol 09:40, 24 May 2009 (UTC)
 * Business is about efficiency, and competing to deliver products that consumers want more of. It could be said that Info pages stores the descendants already.  Has for a long time.  The difference is how accessible the information is.  Suit yourself.  If you see no need for it, that's fine.  Others will.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   16:04, 24 May 2009 (UTC)

Shortcut for us
SMWintro --— Robin Patterson (Talk) 05:09, 24 May 2009 (UTC)

Gerard II van Gelre (c1098-c1131)
You marked Otto II van Gelre (c1215-1271) as Generation 15 Charlemagne descendant, so presumably this is by way of Gerard II van Gelre (c1098-c1131)'s possible mother, Clémence of Aquitaine (1060-1142). I have recorded this as being the predominant theory in Gerard II's info page. If this is incorrect, then please change it back. I don't know anything about the subject. If it is correct, then 12. Gerard II van Gelre (c1098-c1131), 13. Hendrik II de jongere van Gelre (c1117-1182), 14. Otto I van Gelre (aft1145-1207), 15. Gerard IV van Zutphen en van Gelre (c1185-1229). However this would make Gerard IV's son generation 16, not 15. - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x  03:42, 24 May 2009 (UTC)


 * Gerard is a disputed descendant. His father was married twice. There is no evidence that Clemence is his mother. rtol 10:17, 24 May 2009 (UTC)


 * Yes. I saw that.  I am ok with whatever "predominant theory" is.  Is it the dominant one?  That's all I was asking, and I realize it is subjective- something to be arrived at among genealogists who care about the issue.  Simply because one link is disputed does not place one link in a different class.  They are all of the same class- of being theoretical due to many problems we are aware of- the proverbial issue with the postman/ milkman/ plumber, fragmentary and erroneous original documents and the intense "wannabe nobility" impulse of past periods.  IMHO, with Y-STR and mitochondrial DNA evidence some of the lineages now accepted as fact will crumble.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   17:06, 24 May 2009 (UTC)


 * Our panel of experts for anything before about 1600 should be the contributors to Newsgroup: soc.genealogy.medieval. We have at least two of them here but I want to encourage more. — Robin Patterson (Talk) 04:59, 26 May 2009 (UTC)

Like the spine of a book, these lines provide crucial structure for our wiki. They are prime real estate and we need to make sure they are very high quality. Once people connect to an existing network of relationships, the will find some satisfaction in claiming thus and such celebrity is a distant cousin, etc. etc. The richer the pictures, and the more solid the genealogical evidence, the more traffic we will generate. These spines will form the solid structure upon which we will hang the more flimsy inputted personal gedcoms. - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x  05:38, 26 May 2009 (UTC)

Lineage Charlemagne to Otto II

 * 1) Charlemagne (747-814) = CHARLEMAGNE Karel I der Franken 742-814
 * 2) Louis the Pious (778-840) = Lodewijk I de Vrome CAROLINGIAN 778-840
 * 3) Rotrude (800-?) = Hildegardis van Francië (Hildegard) der KAROLINGERS ca 803-860
 * 4) Ranulf I, Duke of Aquitaine (820-866) = Ranulf I van AQUITANIË ca 820-866
 * 5) Ranulf II of Aquitaine (850-890) = Ranulf II van AQUITANIË, Poitiers 848/855-890
 * 6) Ebalus of Aquitanie (c870-935) = Ebalus II van AQUITANIË 870/872-930/934
 * 7) William III of Aquitaine (c900-963) = Willem I van AQUITANIË 900/915-963
 * 8) William IV of Aquitaine (937-994) = Willem II "Ijzeren Arm" van AQUITANIË ca 937-993/995
 * 9) William V, Duke of Aquitaine (969-1030) = Willem III 'de Grote' van AQUITANIË 969/992-1030
 * 10) William VII, Duke of Aquitaine (1023-1058) = Willem V van AQUITANIË 1020/1023-1085/1087
 * 11) Clémence of Aquitaine (1060-1142) = Clementia van POITOU 1048/1055-1142
 * 12) Gerard II van Gelre (c1098-c1131) = Gerard 2,3 van GELRE ca 1098-ca 1131
 * 13) Hendrik II de jongere van Gelre (c1117-1182) = Hendrik II de jongere van GELRE ca 1117-1182
 * 14) Otto I van Gelre (aft1145-1207) = Otto I van GELRE 1145/1150-1207
 * 15) Gerard IV van Zutphen en van Gelre (c1185-1229) = Gerard 3,4 van ZUTPHEN en van GELRE ca 1185-1229
 * 16) Otto II van Gelre (c1215-1271) = Otto II de lamme van GELRE ca 1215-1271

Fred Bergman 08:13, 24 May 2009 (UTC)


 * Right. Clementia van Poitou is Clémence of Aquitaine (1060-1142).  The generation numbers seemed off because your first list begins with 1 while the generation cats begin numbering at 2. - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   08:21, 24 May 2009 (UTC)

Another test
I just completed the line from Holland via Hainaut to Burgundy. It was included in the Ahnentafels without any problems. I also checked the double descents, which are correctly hidden. rtol 18:40, 25 May 2009 (UTC)
 * Robin requested something on this score in my 2009_05 notes. take a look at his interjection and my response- there is something else you might want to add to set ahn where it says duplicate.  I don't want the notes article to turn into a talk page, it's just notes for my own use- if you have any responses, take it to the talk page or respond here.  thanks - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   18:54, 25 May 2009 (UTC)

Charlemagne
If you have sufficient faith in then we can get rid of the autocat for Charlemagne's descendants and relieve the servers. The query returns all ancestors. If we put Charlemagne and other key people in a Category:VIA then returns a list of Very Important Ancestors -- and people can look at the Ahnentafel to sort out the exact relationship, unless we find a way to display that in the list. rtol 18:40, 25 May 2009 (UTC)
 * To be honest I haven't looked at set desc much. Others may wish to add a few things in the future, but it seems like a great start.  No rush to get rid of your old autocats if you have some use for them.  You decide when to make the jump.  I think we both agree the dynamic query is a much more versatile way to go.

More use of Phloxbot?
We would be able to skim "Recent changes" more easily if bulk testings were done by bot and therefore hideable. How much more difficult would that be for you? — Robin Patterson (Talk) 01:03, 26 May 2009 (UTC)
 * Well, I am doing bot runs a new way, but the tool I am using needs an admin flag or wikia approval or it won't be allowed to run. I put in a request to have PhloxBot put on the AWB approved list- probably that will happen in the next day and I won't be doing anything huge until later anyway...  The volume test was successful.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   01:20, 26 May 2009 (UTC)

Slight
"I didn't intend in any way to slight the good work that you and Yewenyi have done with the gedcom thing." No offense taken. Yewenyi's code is hard to work with, but my main frustration is the quality of the average GEDCOM file. rtol 05:46, 27 May 2009 (UTC)
 * AWB shall be no picnic either, in particular there is no gedcom back end. Anyway, AWB does a heck of a lot of other useful things. Have you tried it out yet?  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   06:31, 27 May 2009 (UTC)
 * One's needs admin rights for AWB, correct? rtol 07:04, 27 May 2009 (UTC)
 * No. Go to this page at central and post a request.  I think it is unnecessary, but let them know that this has the  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x  [[File:Check yes small.png]] seal of approval.  I'm sure that will impress the hell out of them. - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   07:32, 27 May 2009 (UTC)

Template:T
Are you aware of the Wikia invention T? Easier to type than tlx or tl and does the same job for single templates. — Robin Patterson (Talk) 05:47, 27 May 2009 (UTC)
 * Thanks robin. tlx will be a hard habit to break.  Kind of like typing the- it just kind of happens so fast by the time I realize I could have typed T I am on the next thing.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   06:21, 27 May 2009 (UTC)

Special characters in page names
Have a look at the "Ahnentafel" property for Antoine L'André (c1771-1811): the "'" seems to be generating a comma which is breaking the string operations on his descendants. Thurstan 06:24, 27 May 2009 (UTC)
 * Looks to me like you discovered an SMW bug. If you just try and do a Ahnentafel:: on it, you will see they are trying to use an html entity for the apostrophe.  Unfortunately for them, these are terminated with semicolons which they also happen to require for n-ary delimiting and they are obviously not masking in their parse.  So unless the docs tell of a way to set these n-ary values, we will have to hack around it until someone fixes this bug.  Could you document it and report it to those guys?  They like to see an example of the bug on their sandbox wiki.  Just set up some bogus n-ary property like what ahn is doing, then do the declare on a page with an apostrophe.  They'll get it real fast.  Hopefully a temporary hack around this problem will be satisfactory for whatever you are doing with this particular article. Not sure- I suppose a temporary rename is the most brutal.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   06:53, 27 May 2009 (UTC)

Okay, I'll see if I can do that. A quick scan shows that at least the following pages are affected by this: Thurstan 07:36, 27 May 2009 (UTC)
 * Albrecht II d' Alsace (?-1038)
 * Antoine L'André (c1771-1811)
 * Bouchard IV d'Avesnes (1182-1244)
 * Charles d'Aquitaine (c827-863)
 * Dirk d' Alsace et de Lorraine (c1100-1168)
 * Geraud d'Aurillac (856-909)
 * Guy d'Avesnes (c1253-1317)
 * Jane O'Brien (1792-1826)
 * K'ung Te-ch'eng (1920)
 * Matthäus d' Alsace (c1137-1173)
 * Nicole d'Aubigny (1206-1240)
 * Pepin I d'Aquitaine (797-838)
 * Pepin II d'Aquitaine (823-aft864)
 * Philippe d'Alsace (?-1191)
 * Ranulphe I d'Aubusson (872-926)
 * Thetberge d'Aurillac (895-?)
 * Unknown d'Auvergne (?-?)
 * It looks like a special case hack for an apostrophe. They probably are using it for an internal use marker.  Maybe not.  Other articles like Иван_Лемзин_(1941) might require url encoding, but it works fine.  No, I think they have been naughty.  It's just an apostrophe hack. - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   07:45, 27 May 2009 (UTC)

Year and extra property
Can you have a look at Counts of Holland? I ordered them at Birth year, but this is a string, not a number, so that those born in the first millennium come after those from the second millennium. Even if that is fixed, then the order is not correct as the county was twice inherited by an uncle. I would think we need a property titles (as someone like Philip the Good had about 20) and a subproperty number (as in First Lord of Brentford). rtol 11:59, 27 May 2009 (UTC)
 * We have a property named titles- you mean Duke of aquitane, Earl or york, Gran Poobah of fennick... right? The list of properties defined is not the authority, Form:Person long form and Genealogy:Multilingual_messages is (don't bother translating these yet- I am not sure we will do multilingual this way because we will blow the message cache- they all need to be held in memory, otherwise all pages on the site load 50-70% slower). Also many of them have not yet been renamed to new versions.  I am still learning some things that affect naming conventions, but since my list is getting smaller and I am changing it much less often, I think we are getting closer to a final version soon.
 * Regarding titles, it seems to me that what I have now- a simple string is not good enough. Seems like we actually need a paired value so that placenames and titles are used uniformly, and in a multilingual form.  Do you have an exhaustive list in dutch?  EG: english: count, earl, duke, etc etc....- <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   16:36, 27 May 2009 (UTC)
 * We now have a list. I guess we need an N-ary triple: Title, Place, Number. Philip the Good would be Duke, Burgundy, 7; Count, Holland, 24; Viscount, Nevers, 11; and so on with a display that says 7th Duke of Burgundy, 24th Count of Holland, 11th Viscount of Nevers. rtol 18:20, 27 May 2009 (UTC)
 * Ok. I was just coming at it from the perspective of the importance of keeping the placename usage disciplined.  I understand the information value of the iterator (7th, etc), but why should it be in a property and not in the free text? Are people really going to search on that sort of thing?
 * Also note that there is complexity in presenting this information in natural language form for each language. We are going to have to display in a more "tabular" form.  I personally am not going to write the code that transforms it-  It's a pain in the neck. eg.  "le Quatrieme Duc d'Orleans".  4->quatrieme, correct gender for article, contraction of preposition de.  Instead, display will look kind of rigid eg: Duc: Orleans (4)  Of course if anyone wants to transform it for their language, that will be their option, but I personally am only going to do the default (non language specific) case.  If that's ok with you, I'll do the triple as you suggest.  I suppose we do the title portion in english and we'll have a big #switch statement on each language form to display the correct equivalent.  eg Duke->Duc on the fr infobox template. - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   18:49, 27 May 2009 (UTC)
 * The number would be for display purposes, rather than searches. Show me all Dukes of Orleans in the right order is a sensible query. Show me all 7th Dukes is not. rtol 19:42, 27 May 2009 (UTC)
 * Makes sense. It is a pain that there is no post retrieval sort on return sets from n-ary arrays.  Maybe they will add it later.  There might be some option on sortable tables to default sort a particular column.  I didn't see it on a quick overview of the docs, but that doesn't mean it isn't there.  If you find any such feature, please let me know.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   20:01, 27 May 2009 (UTC)

Wikipedia has (and we have imported) succession templates. Can they help with any of the above? — Robin Patterson (Talk) 03:16, 31 May 2009 (UTC)

AWB and descendants lists
AWB works well for me. For importantly, last night's edit of "set desc" seems to have removed the instability in the results. Testing with AWB but no weirdness so far. rtol 10:30, 28 May 2009 (UTC)

Can you let me know when you will indeed nuke all the wplinks? If "set desc" is indeed stable, it should be put back into "info categories" before that to initialise values. rtol 14:33, 28 May 2009 (UTC)
 * Good to hear you were able to begin AWB runs so quickly. Maybe you can help others with questions/ improve the help.  I am hoping that motivated contributors will be able to help with routine maintenance (eg spell check, normalizing layouts) using it.
 * If and when you do need to directly change large numbers, you should set up a bot account. This gives no special privileges really- it just allows people to hide bots in the recent changes list.
 * Regarding wplinks- this issue has mainly to do with copies of Wikipedia articles. I need to touch all those articles fix their parameters so that our location properties get loaded up with proper values.  These will be used for autosuggestions and querying.  Although there is use in some person articles, I shall not be touching anything that has the info categories template anyway, so I think there is no tie between them.
 * Unless I am missing something, I don't see why you need to wait on anything happening with wplinks.- <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x  17:07, 28 May 2009 (UTC)
 * I will put "set desc" in "info categories", so that when anyone saves a pages, the values get updated. I've been testing all day. The latest is Beatrijs van Vlaanderen (c1253-1296) -- see common ancestors. I'm now convinced that it works, so nuke away.
 * By the way, this also allows a cheaper test for "married cousin" and a simple test for "married first cousin twice removed". rtol 17:43, 28 May 2009 (UTC)
 * Great work. We should probably take this time to do the switchover now on parent property naming.  I did a quick change of the set facts from info template and it appears to work.  Didn't hammer it hard though- but it should be better because it uses get spouse which verifies parent names as being current.  Anyway, the change in terminology is because spouses aren't always spouses (eg concubines), and there is a weird situation with adopted children, so we are going more abstract. Instead of postpending -s1 we postpend -g1 (for family "groups"). So children-s2 becomes children-g2 and Spouse2 becomes coparent-g2.  Actual Mediawiki:fm-coparent label might be displayed as "Spouse/Partner", or whatever is appropriate for the different languages.
 * If these get popular, we should probably should think of a way to have people put in requests to more quickly propagate particular descendant trees. Those that don't understand how to use AWB may find it time consuming to resave articles in order to see the full list of descendants. - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   19:36, 28 May 2009 (UTC)

Help with Cyrillic characters
Please look at Talk:Fraser Robinson, Jr. (1912-1996)/info to see whether it's appropriate. — Robin Patterson (Talk) 06:36, 29 May 2009 (UTC)
 * Seemed like a fly by random comment. The message just said we had a nice "forum" and typo'd the word for "here".  Hard to understand why they chose that particular article to make a comment on.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   15:43, 30 May 2009 (UTC)


 * OK, that's probably a Wikia-wide vandal, like (or the same as) we had earlier. — Robin Patterson (Talk) 02:06, 31 May 2009 (UTC)

Coparent
Can we please have an alias for coparent? I know that spouse is not 100% correct, but at least it is an intuitive term. Coparent is not, and it reduces marriage to having kids. Is partner an alternative? rtol 20:17, 30 May 2009 (UTC)
 * I suggested "partner" many days ago. — Robin Patterson (Talk) 02:06, 31 May 2009 (UTC)
 * No problem. Just now I aliased coparent 1-4 as partner.  I'll get around to the rest soon enough, or you can do it.  As far as what users see, these fields are listed as Spouse/partner in the infobox and forms.  There are other fields I have not yet added aliases for.  Regarding "partner", this arrangement allows : "  " which gives you:


 * I thought partner was a better solution than spouse but then I came to the conclusion partner is wide of the mark too. I suppose none will ever be perfect.  I have a grandmother who had 20 or so partners.  None of them are particularly relevant to Familypedia except two.  One did not "have kids" with her but was a parent.  Gay couples do not biologically "have kids" so in strict genealogical terms they would be excluded. But from the perspective of a familypedia these families certainly deserve no less attention than any other family.  Further, cases like the orphans of Dickens novels are sadly not all that rare and there are cases of foster children with multiple serial parents each of which were not partners with the others.  Regarding partners: I suppose there is a lurid interest in enumerating all partners, but at the end of the day I don't suppose we really are interested in a tabloid wiki or a place to post lists of romantic conquests.  Your point is well taken though- there are marriages and other partnerships that involved no parenting whatever but were biographically significant.  In any case, the meaning you give is dominant in the UI- this field is labeled in the UI as Spouse / Partner, and the important idea is to list those relationships that are biographically significant from the POV of the adult.  From the POV of the child, the individual who parented them is important.   Anyway, lots of our fields are in the same boat.  For instance "County", "State" and "Country" are intuitive, but misleading.  England is in fact a constituent country of the UK, and UK is not a country, but in their parlance, a "sovereign state".   So should we generalize away from state/ country and call them respectively "subdivision1" and "sovereign state"?  I am now leaning towards the naming philosophy of being more abstract/ "less intuitive" in the internal names because users don't see them.  For the labels they do see, they should all be intuitive/conformant to what readers in that language/culture would understand as coving 90% of the cases.  So for this particular field, the user sees Spouse/ (partner) in the infobox and forms, and only template writers see "subdivision" and "coparent".  In debug mode, we are seeing these labels in the dump of the facts tables, but normally these would not be displayed.  I expect most person articles would use the _NOFACTBOX__ magic word.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   04:46, 31 May 2009 (UTC)
 * It might be argued by some hard core genealogists (those interested solely in true blood lines) that this introduces "noise"/ junk into the database.  Realistically speaking, the numbers of individuals with coparents who are not biological due to adoption or foster parenting will be practically infinitesimal compared to the very large problem of false paternity that is now determinable with DNA genealogy metrics.  DNA researchers frequently estimate the probability of these events at 10%, but even if one accepts the conservative figure of 5%, the implications are staggering when multiplied across generations.  This is apparently described well in appendix C "False paternity" of Some Family: The Mormons and How Humanity Keeps Track of Itself summarized  this way:
 * <blockquote style="border: 1px solid blue; padding: 1em;">...the most distressing part of the book for anyone who believes in family history is Appendix C,Appendix C, “False Paternity”. Anyone who takes pride in a distant ancestry or joins a lineage society ought to read this part of the book, or Appendix E, “Genetics as Genealogical Evidence”, which discusses ways DNA testing is transforming the creation of family histories. These appendices are the best parts of the book-and unlike anything else this writer has seen in print. Akenson presents a study from West Islesworth, in southeast England, where a specialist obstetrician’s blood-tests of the children he delivered indicated that some 30 percent of them were not the offspring of the man named as the father. He notes the “10 percent incidence [false paternity] that was the minimum level generally accepted as conventional wisdom in medical and genetic teaching in England” and “the number most frequently taught in US medical schools.” After addressing recent studies showing a lower, 4 percent rate of non-paternal births, he arrives at a 5 percent false-paternity average and draws a devastating set of conclusions. Based on Akenson’s average, it is more likely than not that a “non-paternal event,” that is, an amourous brother, neighbor, or milkman, has broken the genetic lineage of every family line within fourteen generations. In short, “mommy’s baby, daddy’s maybe.” Thus, anyone who has paid dues to join the Descendants of Charlemagne ought to consider asking for a refund. An Acadienne who traces her lineage back to Charles LaTour or an American who basks in the Pilgrim’s pride of Mayflower ancestry-that is, anyone claiming a lineage extending fourteen generations or more-will want to read this disturbing book. As Launcelot observed in The Merchant of Venice (a line Akenson tellingly quotes), “It is a wise father that knows his child.”
 * So really, the source of the large amount of noise in genealogy databases are actually from well established, excruciatingly thorough genealogies prepared and jealously defended by professional researchers.  Entry of data about non biological parents due to adoptions (as the coparent scheme permits) are miniscule at this point  This is not to minimize the value and importance of establishing blood lines and interest in establishing certain predilections for certain behaviors due to dna biases.  There shall be a checkbox as well as a field for the name of biological parents when known.  Whether the biological parents are known or not, the checkbox value would be set for all figures whose father or mother has been established by dna testing to be different than the "coparent". This field may be largely ignored by our audience, but will allow bloodline analysis to cull these false positives from returned queries.
 * Why this field may not be all that important to the bulk of our audience is a philosophically supportable POV, and not necessarily an indication of their propensity for self delusion. Who we are is a lot more complex than such dna determinism, and the personal narrative of who various kings thought they were and who their followers thought they were was key to many of their achievements.  Aye, the blood of kings runs in this one's veins... etc.  In many respects it is somewhat of a footnote if it was actually discovered that this king was in fact completely unrelated to the blood line.  The collective narrative that people believed to be true was what was important.  As it is to us.  I relate to Swiss and Scottish values, but the fact of the matter is that due to dilution, I am as about as much Swiss or Scott as Obama is a French Huguenot. What matters as much as the DNA is what the person's perceived familial descendants were.  It is less ambiguous for non adoptive children only because they are not aware of the high probability of non paternal events, and they are not aware that their identity has far more to do with nurture and their psychological parents than nature and their biological nature.  But it is a debatable point.  Some think we are basically wired by dna and there is not much that nurture really adds.  Never cared much for Skinner and his crowd anyway.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   16:38, 31 May 2009 (UTC)

SMW genealogy for the last 15 months
http://roux.co.za/index.php/User:Robin_Patterson

Have you checked them out? — Robin Patterson (Talk) 02:06, 31 May 2009 (UTC)

SMW users mailing list
Do you see it? — Robin Patterson (Talk) 02:06, 31 May 2009 (UTC)
 * No, I have not participated in it- don't know anything about it. Frankly, I have not been terribly impressed by any of the SMW sites I have seen and so I just figure things out for myself. Is there any talk of anything of note? - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   03:30, 31 May 2009 (UTC)


 * The person I imagine is the chief developer of SMW regularly contributes. Latest item of note (relevant to something you said in the last day or so) is :
 * Hello,


 * I'm very pleased to announce another addition to Semantic MediaWiki - you can now query to get a list of all the pages that have their coordinates within a certain distance from a specified point. This code was created by Thomas Fellows, with some minor modifications from me. The syntax uses the "::~" operator, which now works not just for strings but for coordinates as well. You can see an example of this new kind of query here:


 * http://discoursedb.org/wiki/Proximity_query ...


 * — Robin Patterson (Talk) 06:05, 31 May 2009 (UTC)
 * The ~ operator is disabled on wikia for performance reasons. However, if it turns out that this is disabled when we get the version enabled on wiki, it is likely that this would not be a performance hog and we could get it working for genealogy.  The reason why is that fuzzy string searches require lots of operations, but coordinate search doesn't.  All these guys are doing with lat/ longitude fuzzy search is ask in the case of a half of a degree of proximity for matches with X-.5 <X< X+.5   and Y-.5 <Y< Y+.5.  This is not rocket science, I think we'll have this functionality one way or the other.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   07:46, 31 May 2009 (UTC)

Locality
Just looked at your changes to The Hague. All fine. However, you opted for human readable latitude and longitude of minutes and seconds, while Google Maps uses real numbers. Going back and forth between the two is not that difficult, so that we can automate the use of Google Maps.

When the localities are done, we should also be able to automate maps as these: Richard S.J. Tol (1969-)/ancestors which shows were all my known ancestors were born. The code of the map is simple but tedious, just the sort of thing you would want the computer to do in your stead.

Keep up the good work! rtol 05:59, 1 June 2009 (UTC)
 * The coords for The Hague were automatically extracted from WP infobox code. Personally I prefer decimal.  The infobox extraction templates are in preparation for very high volume transfer of placename data from the wikis.  Regarding digital vs dms- Actually the plan was to run bots to normalize them all into decimal form.  However, this may be unnecessary since the lat/ long proximity search (see Robin post from yesterday) has been added to SMW and will likely be available to us soon.


 * I did some demo work with the googlemaps extension immediately after I got it activated here, and I recall you could set pushpins with popup text right? Yeah- All that sort of stuff we should be able to automate.  Also coming down the pike for visualization aids is the semantic timelines extension.  No word from uberfuzzy yet on when that will go through inspection.  It's pretty neat- you can just dump in a bunch of dates with annotations and it sorts it all out and makes it pretty.


 * On the language front, the tech heads have no great solution to the logged out user problem, so my view is that we do multiple pages for multiple languages rather than a single page for multiple languages. The former approach is demo'd in Barack_Obama_(1961)/fr.  A logged out user will see the content in french.  The latter approach uses mediawiki messages eg I internationalized the person template with them so if you change your language, the table rows will at least display in the correct language eg .  The latter scheme is the worst because we require the users to set up an account to see things in their native language.  That's too high a barrier.  So the other experiment with the Hague that I am doing is using SMW properties to store the alternate language versions of the placenames, and we use those for matching foreign language versions of places in Gedcoms.  Side benefit is greater support for foreign language visitors.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   06:49, 1 June 2009 (UTC)


 * Even better than I had hoped. rtol 07:10, 1 June 2009 (UTC)

Karehana Bay and Camborne
I see that you saw my second "form" locality. Not sure if you saw the first one. I'm sure the system will be fine eventually. Tell me when you want it tested again.

I've lived in this house since it was completed in 1976. I know the city well. My children did get taken on a few trips further afield, including one trip to the "Mountain" (Ruapehu).

— Robin Patterson (Talk) 02:06, 4 June 2009 (UTC)

Ahnenbug?
Ingeltrude de Paris (?-?)‎‎ has Charlemagne with ahnnumber 10. On Descendants of Charlemagne (Generation 4), the query "all CM's descendant with ahnnumber 10" returns empty. I can't figure it out. rtol 17:09, 1 June 2009 (UTC)
 * The subject did not have a birth date property value, and this confused the sort. I commented the sort out to demo this.  Sounds like a bug to me.  Did you report the other one regarding apostrophe's in the article name? - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   22:34, 1 June 2009 (UTC)
 * Thurstan reported the apostrophe to you. I did not report anything to anyone. rtol 05:11, 2 June 2009 (UTC)
 * Bug confirmed. With the sort on birth date, CM has 17 kids. Without the sort, CM has 20 kids.
 * Birth date sorts correctly, by the way, unlike birth year which is a string. rtol 05:15, 2 June 2009 (UTC)
 * I put a ? as Ingeltrude's birth year. This did not change matters. rtol 08:19, 2 June 2009 (UTC)


 * Oh I thought you reported the apostrophe thing. Sorry.  Regarding birth year as a string... Heh heh.  Obviously the partial date values should be numeric, be default zero and the form template should set a year value derived from the full date value when available.  Sorting using the full date field isn't what you want regardless of the Ingeltrude bug.  Default year zero is ok since it is an illegal year.  That will keep sort happy- which from what you say seems to toss illegals as if they didn't exist.  Seems to me that unknowns should be very rare though. If a parent or child is known you always know an approximate date usng "before" or "after".  For instance an unknown child birth must have Birth Year >mother father birth plus at least 13-15 years. Similarly for unknown parent.   Lots of little things like partial dates have not been attended to, and part of the reason I keep saying the SMW stuff is not yet ready.  It is a housekeeping thing- I'd have done it already except that extracting year requires #time and that function has a bug that requires some elaborate code that I have not yet moved over.  Anyway, you understand that you are starting to live in a house that doesn't yet even have a roof on it.  On that score progress looks good- the fundamentals are beginning to stabilize.  I don't expect that much radical will happen after the multilingual thing is sorted out.  I am pretty much of the mind that all templates and forms will be hard coded in other languages rather than rely on Genealogy:Multilingual messages.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   16:32, 2 June 2009 (UTC)
 * SMW may not be ready, but it is too much fun to wait. rtol 17:36, 2 June 2009 (UTC)

Kids
Property:Children used to be the union of children-s1, children-s2, .... This does no longer seems to be the case for children-g1, children-g2, .... rtol 12:30, 2 June 2009 (UTC)
 * Now solved and tested. Thanks! rtol 17:36, 2 June 2009 (UTC)

Admin assist
Can you please remove the auto-Wikilink-the-dates functionality on Template:Cite web. (It's a protected page, so I can't do it myself.) EN-Wikipedia no longer wikilinks dates, and doing so here is probably impractical and just adds a bunch of red links. Happy to discuss of the template's talk page if you think others would disagree, but I don't think most others would care. Thanks. —DeGraffJE talk 00:28, 3 June 2009 (UTC)
 * [[File:Check yes small.png]] done. - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x  07:29, 3 June 2009 (UTC)
 * Thanks for your help! —DeGraffJE talk 23:47, 3 June 2009 (UTC)

Broken again
I now get the long form when clicking a red link, but the "edit without form" does not work, and neither does typing in the page title in Firefox. rtol 18:04, 4 June 2009 (UTC)
 * I turned it back off on the ones I was testing, so you shouldn't see that anymore. Let me know if that is not the case.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   18:37, 4 June 2009 (UTC)

GEDCOM
http://genealogy.wikia.com/wiki/Help_talk:Loading_Gedcoms#GEDCOM_upload_under_SMW — Robin Patterson (Talk) 05:03, 5 June 2009 (UTC)

Need crumb
I still don't understand how you write the "facts" box at the bottom of the page. I'd like to add some diagnostic checks comparing people's birth dates to their parents' and so on. Could you write a simple "age at death" template? Does not work with the birth and death years at the info page because these are strings. Thanks! rtol 18:07, 8 June 2009 (UTC)
 * Ok. See Age (smw).  George_Spencer_Geer_(1836)'s age at death was.


 * BTW- I don't write the facts box (though this could be done). The facts box is a standard feature of SMW (that can, and probably should be turned off once we are exposing all these values in the article(s)).  The shutoff wikitext is like NO TOC,  a __Magic Word__ that is in the SMW docs and on my notes page.


 * Date math is not especially simple, especially given that we allow for two different kinds of date fields (actually 3), but for this purpose there is the precise date versus approximate Year and month. The function should calculate the age correctly except for dates in a weird segment of time between 100BCE and 100AD that the #time function does not support.  I'll fix this later- it is more involved.  You basically add a large number then subtract it when you are done, but it turns already ugly code even more ugly.


 * George_Spencer_Geer_(1836)'s age at death was . I put in some sparse docs but it probably should be decorated with esoteric and explained a little less briefly.  Maybe we should vector to this one from the Age template if the article is an SMW article.  Anyway, please doc and / or improve as you see fit.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   21:14, 8 June 2009 (UTC)


 * Thanks man! I thought I asked for something simple. I'll have a go at mother's age at child birth. rtol 21:39, 8 June 2009 (UTC)
 * Actually it just looks complicated. Anyway, for your variation you can do this simply by replacing the top level function.  Instead of the ask sending one query to the aux routine, call the aux routine directly with parameters from 6 asks.  The first three are mothers b date, b date-y, b-date-m.  The second triple for the child is used as the end date in place of death.  No need to mess with the math routine. - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   22:34, 8 June 2009 (UTC)


 * age mother at birth correctly returns my mum's age when she gave birth to me. Will come in handy as a diagnostic, but the info-page version is expensive, right?
 * age (smw) is now deployed at biography. rtol 08:00, 9 June 2009 (UTC)
 * the cost of age (smw) is practically nothing. The rest of the info based stuff that biography is doing is a little expensive and should be converted to smw calls.  Doesn't facts from info recover all the properties you need for biography?      - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   08:13, 9 June 2009 (UTC)


 * It does. I'll have a close look at age (smw) to find out how to display smw info. rtol 08:24, 9 June 2009 (UTC)

inquiry from a drive by contributor
I have never found this website before. What is it and is it free genealogy or what?

Category talk:Multilingualism
I would appreciate your spending 20 seconds in the next few days to give your followers a clue about my note at Category talk:Multilingualism. — Robin Patterson (Talk) 02:59, 12 June 2009 (UTC)

ahnentafel bug
I believe I understand the bug that produces "Expression error: Unrecognised punctuation character "&".

Have you seen any cases where it happens with an article that does not require an html entity for it's page name? The problem is that in the ahnentafel and descendants templates, I used a semicolon to delimit fields. This is evil because unbeknownst to me, smw will substitute html entities in these strings, and of course they are terminated with semicolons.

Unfortunately, the fix will require regeneration of all these trees. -~ Phlox 16:57, 12 June 2009 (UTC)


 * That's progress. I've only ever seen this show up where there was supposed to be NAME (YOB-YOD). rtol 17:53, 12 June 2009 (UTC)

Set desc v set dsc
My primitive understanding is that a template like "set desc/aux1" or "set dsc/aux1" only works one page at a time. "set desc" retrieves children one by one and passes them into "set desc/aux1". "set dsc" retrieves groups of children and passes them into "set dsc/aux1" as a group; only the first child is processed. I could not solve this, or get SMW to give me one child at a time, so I resorted to the parser calls. rtol 05:19, 13 June 2009 (UTC)


 * I see that you replaced "set desc" with "set dsc" in "info categories". It's faster but not faultless. Mysterious errors, like skipping a generation, or just ignoring information even after a triple flush. rtol 06:11, 14 June 2009 (UTC)
 * A 100 parser count for a function that doesn't produce accurate results is a little pricey. Let's straighten out set dsc rather than resort to gets on info pages.  I know what that thing is doing, and it is horrifying how much work the wikia servers are doing to generate these lists that way.  Now, as I pointed out in note to you, "Set desc" does not handle the two children of the test case for set desc let alone more esoteric test cases.  If you put in monitoring messages into set dsc, you will find that set dsc does the same sequence of calls that set desc does.


 * The difference is that set dsc operates off of smw info transfered from info pages. I expect this is the source of the errors.  If you can point to a specific test case I would like to isolate what is going on here. - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   06:32, 14 June 2009 (UTC)


 * My bad. Sorry. I apparently did not flush systematically. All seems fine with "set dsc". rtol 06:24, 14 June 2009 (UTC)

Generation numbers
Robin insist on is rather keen on the idea of displaying the generation number of descendants of Charlemagne.

There are three ways of doing this.
 * 1) Take the ahnnumber of Charlemagne from the person's page and convert this to a generation number.
 * 2) Take the generation number of the person from Charlemagne's page.
 * 3) Introduce Property:Order of Charlemagne and set it equal to min(Father's order, Mother's order)+1.

Option 3 is the simplest (I thought), but I can't even do Father's order+1. I retrieve the generation correctly, but when I passed it to a template to be increased, it returns Expression error: Unrecognised punctuation character "[".

I've been wrestling with Set Order of Charlemagne and trying it out on Amaudru (?-?). rtol 10:39, 13 June 2009 (UTC)


 * Got rid of the error message. Now it just does not pass on the info. rtol 12:34, 14 June 2009 (UTC)


 * One other way is to do it manually. rtol says that's not an option. It will work (and would be a small part of what's needed to create any person's page unless we get seriously mechanized). It's the fallback solution if no others work. I hope one of them does. But a semi-automatic option could be to use something like Set Order of Charlemagne or the older, potentially costly, Descent Charlemagne test in 10-generation lots instead of 42 generations. So we do generations 6 to 15 using that, and if it's with the latter it's only about 20 parser calls per page instead of 80-odd. Then when gen 6 is "complete", we adjust the template to get a little further down the tree. — Robin Patterson (Talk) 11:53, 15 June 2009 (UTC)


 * If we sort out how to do it automatically, we can do it for all generations. I now compute the generation number correctly, but still cannot assign it to Amaudru (?-?). rtol 05:57, 17 June 2009 (UTC)

Dark Red instead of dark brown.
thank you! but the wikia lifestyle and the button stays brown Fred Bergman 06:24, 14 June 2009 (UTC)


 * Pardon? doesn't anything turn red?  What browser are you using? - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   06:34, 14 June 2009 (UTC)

Yes it is okay, but I would change also the leftside above Wikia Lifestyle colour and the right upside More button to the same colourFred Bergman 07:14, 14 June 2009 (UTC)
 * There are other logo files. More information on how to customize may be found at help wikia - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   03:24, 15 June 2009 (UTC)

More kids (redux)
May I add more kids to Set facts from info/family? Even one of your test cases, John Piper (1773-1851) has "lost" 4 children. Thurstan 08:09, 14 June 2009 (UTC)
 * I'm surprised that more shortcomings have not been noticed. I wrote this in a few hours and never went back to update it.


 * My thinking was that this scaffolding code would have an "exhaustive" flag that would access every attribute that could possibly have been set on an infopage and map it to some smw property. AutoWikiaBrowser would then stop by the article, save a temporary version with the exhaustive flag, then reload the article and replace the Info categories with the subst code at Set facts from info.  AWB isn't really necessary- this could be done manually fairly rapidly, but AWB allows you to do a few hundred at a sitting as opposed to fa few dozen.  That is an outline of the conversion process, and many (in particular simple use info templates like freds) can be done right away since I believe I am moving all the fields those simple ones are using.  Anyway, this conversion process allows human eyeballs on the conversion process and any contributor can do it.  Have you tried AWB yet?


 * Not having a stable design for properties at the time, this was premature. Now with a stable property schema, it is now possible, and somewhat forced at least in the case of children due to the fact that set descendants needs an exhaustive list.


 * So the short answer is go ahead and create an exhaustive version of the family subtemplate, but please do it conditionally on an exhaustive flag passed to the subtemplate. That way if the NewPP cost gets too high we can shut it back to the nonexhaustive list.  Putting ultra heavy cost code in every article slows the entire site down.  Let's be more sensitive to that.  I am the most guilty of anyone because I wrote the info templates in the first place, so I am not blaming anyone except myself for the situation of slow articles.


 * Also, feel free to expand beyond the family subtemplate and move more of the info fields over to smw cats if you would like to lend a hand. I'll review whatever you do.  It is fairly straightforward, and I think you can figure out the schema from the existing properties used in Form:Person.  Some info categories are ambiguous, eg :Baptism field was used to record both time and place.  Some of the dates in these fields use date templates so they could be extracted reliably using mw:Extension:StringFunctions, or by setting a marker in the date template, shoving the entire value into baptism locality, then using AWB to post process the locality value, and split the time off either into a date-y date-m partial date field or to store them in the full baptism date field if it is complete.  I haven't given it any in depth thought, but I prefer the more AWB reliant path since you can use regex and more complex conditionals useful to automatic processing.   Of course I am talking about the worst cases here, and most fields are not this challenging.  The less ambiguous fields like Wikipedia-es etc are straightforward.  Do what you feel like doing if you have the time.  Not fun to code this sort of thing, but there you are.  Life in the fast lane.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   17:08, 14 June 2009 (UTC)

Please see Forum:SMW Thurstan 03:37, 16 June 2009 (UTC)

Married oneself
William Waite (1832-?) is married to himself according to facts but not according to info ... rtol 09:29, 14 June 2009 (UTC)


 * That's because of errors in Susanna Harrington (1835-?)/info: both "Article" and "Full name" are wrong. Thurstan 09:54, 14 June 2009 (UTC)


 * Good man! Now fixed. rtol 11:20, 14 June 2009 (UTC)

Quick Query
I have finally started the process of converting my script to produce /info pages to use SMW instead, and I notice a discrepancy: Set birth set a property "birth subdivision1", while Set death, Set baptism and Set remains set properties "xxx state" at the corresponding point. I assume from the general discussion that "state" has been superceded by "subdivision1", so these templates need to be fixed. Thurstan 05:21, 15 June 2009 (UTC)


 * Set wedding1 uses "state" too. Thurstan 05:34, 15 June 2009 (UTC)
 * Yeah. Recent change, also there was a change of "had people" to the more general/inclusive "involved people".  Actually true for all non birth event templates- weddingX, migrationX, residenceX.  By the way, there is no need to be in any hurry to switch over right away. There is a slight advantage to SMW if you are able to extract higher detail information, like place divided by governmental unit, attendees and so on.  Otherwise, I don't see why using info pages as an intermediary poses any problems.


 * Just curious- this script of yours- what is the source data you are converting from? - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x  08:51, 15 June 2009 (UTC)


 * I export GEDCOMs from PAF and import them into LifeLines (http://lifelines.sourceforge.net/), where I can run scripts. Thurstan 09:28, 15 June 2009 (UTC)
 * That's reasonable. These paf files seem to have more info than what is displayed on familysearch- eg links to ancestry.com, and the BDS refs. Presumably you will move over the sources references as you are now to the info pages.  I just don't think anyone is going to bother to post process the locations or person names.  That's why I want to import via AWB and normalize on the spot into to familypedia/wikipedia placenames, where the user can verify that the place is really the place the algorithm guesses, and the person article linked to is really the folks they have in mind.  Of course that is months off if ever, so your approach looks pretty good for the interim.

Okay, you have changed the "Set" templates. Now you have to change Showfacts person, because it is obvious using "state", not "subdivision1" (I would fix it except that I am still haivng trouble reading the SMW code). Thurstan 09:42, 15 June 2009 (UTC)
 * When did you write this? I did that. Actually, it was in a poorly named get-ex template, not showfacts person.- <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   04:02, 16 June 2009 (UTC)


 * Okay, I see it working now (for example Thomas Edward Avery (1858-1921)). I think I was being fooled by the number of saves it took to show. Thurstan 04:12, 16 June 2009 (UTC)

Coparents
We're having trouble counting at Descendants of Charlemagne (couples), and the query depth prevents a solution with current properties. Would I break anything if I make a Property:Coparent-g1 (etc) a subproperty of Property:Coparent? rtol 07:35, 17 June 2009 (UTC)


 * Solved. Property:Partner already existed. rtol 15:12, 17 June 2009 (UTC)

Inbreeding
It would be better to replace Category:Married cousin with a Property:Married with value cousin. The test, however, is on co-parentage, not marriage. How would you call this property?

For the values, I would use sibling's child rather than nephew/niece and parent's sibling rather than aunt/uncle. rtol 07:42, 17 June 2009 (UTC)
 * I dunno. My request is you stay away from ordinal forms 2nd cousin, 3rd, etc.  It makes code exceptionally messy.  Maybe 2cousin, 3cousin?  But I don't envy you your task. It's tricky to be intuitive to novices, technically accurate, and easy to use for coding.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   08:10, 17 June 2009 (UTC)

Showfact v Get
Descendants::→;;3 works but Descendants::→;;3 does not rtol 15:40, 17 June 2009 (UTC)
 * "Showfact(s)" templates are for display and may have hidden formatting. They are not for general database retrieval tasks.   If you want a get, use the standard SMW database command (the ironically named) #show.  eg:   Certainly you or I could put that in a getfact template, but it would be a pretty trivial wrapper.  OTOH, maybe for novices we should have something like that.  Anyway, the problem you ran into is that showfact produces a more complex string that cannot be used for certain operations- in your case setting it as the value of a property.  There are embedded control strings that smw puts in there.  Just for fun, Do a #pos for "SMW" on a showfact string with an intro or outro that apparently does not have these values, and lo and behold- it will tell you SMW is indeed in there.  - <font color="#0A9DC2">~  <font color="#0DC4F2">Ph <font color="#3DD0F5">l <font color="#6EDCF7">o <font color="#9EE8FA">x   17:25, 17 June 2009 (UTC)
 * Ta. The inbreeding test will be faster. rtol 18:45, 17 June 2009 (UTC)
 * Did you try Descendants::→;;3 ? It returns a database error! rtol 20:58, 17 June 2009 (UTC)
 * Autoprop for Married:Relative works, by the way, but I'll wait with the second cousin once removed until this thing is solved, because there are quite a few gets in Inbreeding test rtol 20:58, 17 June 2009 (UTC)
 * You are passing a pagename with square brackets, not a string. You should have used |link=none for what you are doing there.  I think I will make getfact's default link=none, (unlike SMW's default=all) because most often people will manipulate strings, right.  If that is not a save assumption, let me know.