Lifestyle
 
[Phlox]

Phlox 22,994 edits since September 6, 2007

22,994

User talk:Phlox/Archive 4

From Familypedia

Contents

(All of May 2009 - the first month of SMW and some AWB)


[edit] Properties

I see you are creating properties. Very good. I guess these can be used to create couples. For instance, Married cousin 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. -~ Phlox 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. -~ Phlox 05:31, 2 May 2009 (UTC)

[edit] 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. -~ Phlox 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)

[edit] 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. -~ Phlox 17:36, 8 May 2009 (UTC)

[edit] 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.
-~ Phlox 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. -~ Phlox 17:33, 10 May 2009 (UTC)

[edit] 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)

[edit] 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. -~ Phlox 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... -~ Phlox 06:16, 14 May 2009 (UTC)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] "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. -~ Phlox 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 Donner PartyImage:Wp_globe_tiny.gif 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. -~ Phlox 06:53, 17 May 2009 (UTC)

[edit] 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, {{#ask: [[Children::Richard S.J. Tol (1969-)]]}} returns my parents, but {{#ask: [[Children:{{#ask: [[Children::Richard S.J. Tol (1969-)]]}}]]}} 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)

[edit] 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. -~ Phlox 08:51, 17 May 2009 (UTC)

[edit] 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? -~ Phlox 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. -~ Phlox 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. -~ Phlox 17:55, 17 May 2009 (UTC)

[edit] 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. -~ Phlox 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. -~ Phlox 08:16, 20 May 2009 (UTC)

[edit] 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. -~ Phlox 08:12, 20 May 2009 (UTC)
No worries. I'll hold off for a while. rtol 08:53, 20 May 2009 (UTC)

[edit] 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. -~ Phlox 08:44, 21 May 2009 (UTC)

[edit] 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)

[edit] Ahnentafel

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

Did some experiments. {{#ask: [[Ahnentafel::→;Charlemagne (747-814);6]] }} return the set of people to whom CM is the maternal grandfather, while {{#ask: [[Ahnentafel::→;Charlemagne (747-814);*]] }} returns all descendants.

More importantly, {{#ask: [[Ahnentafel::→;Charlemagne (747-814);*]] [[Ahnentafel::→;Alfred the Great (849-899);*]]}} 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 {{#ask: [[Descendantlist::→;Charlemagne (747-814);*]] [[Descendentlist::→;Alfred the Great (849-899);*]]}} 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. -~ Phlox 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? -~ Phlox 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. -~ Phlox 18:45, 24 May 2009 (UTC)

[edit] 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
{{#ask: [[Juliana van Oranje-Nassau (1909-2004)]]|link=none|default=none|?Children-s1= }}, and make one piece of the puzzle work- like chopping. Then later I replace the "Juliana.."whatever test page with the generalized value (like {{PAGENAME}} in this case. -~ Phlox 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. -~ Phlox 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 {{Set desc}}. 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? -~ Phlox 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. -~ Phlox 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. -~ Phlox 16:04, 24 May 2009 (UTC)

[edit] Shortcut for us

{{SMWintro}} --— Robin Patterson (Talk) 05:09, 24 May 2009 (UTC)

[edit] DO YOU MEAN THIS ?

[edit] 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. -~ Phlox 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. -~ Phlox 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. -~ Phlox 05:38, 26 May 2009 (UTC)

[edit] 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. -~ Phlox 08:21, 24 May 2009 (UTC)

[edit] 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 -~ Phlox 18:54, 25 May 2009 (UTC)

[edit] Charlemagne

If you have sufficient faith in {{set desc}} then we can get rid of the autocat for Charlemagne's descendants and relieve the servers. The query {{#ask: [[Descendants::→;{{BASEPAGENAME}};*]]}} returns all ancestors. If we put Charlemagne and other key people in a Category:VIA then {{#ask: [[Descendants::→;{{BASEPAGENAME}};*]] [[Category::VIA]]}} 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.

[edit] 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. -~ Phlox 01:20, 26 May 2009 (UTC)

[edit] 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? -~ Phlox 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  Phlox File:Check yes small.png seal of approval. I'm sure that will impress the hell out of them. -~ Phlox 07:32, 27 May 2009 (UTC)

[edit] 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. -~ Phlox 06:21, 27 May 2009 (UTC)

[edit] 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::{{PAGENAME}}]] 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. -~ Phlox 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)

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. -~ Phlox 07:45, 27 May 2009 (UTC)

[edit] 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....-~ Phlox 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. -~ Phlox 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. -~ Phlox 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)

[edit] 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.-~ Phlox 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. -~ Phlox 19:36, 28 May 2009 (UTC)

[edit] 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. -~ Phlox 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)

[edit] 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 : "{{#ask: [[partner::Ellen Levingston (1833-1911)]] | ?surname = }}" 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. -~ Phlox 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:
...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. -~ Phlox 16:38, 31 May 2009 (UTC)

[edit] 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)

[edit] 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? -~ Phlox 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. -~ Phlox 07:46, 31 May 2009 (UTC)
Retrieved from "http://familypedia.wikia.com/wiki/User_talk:Phlox/Archive_4"