Wikia

Familypedia

Phlox

aka Mak Thorpe

Admin
23,986 Edits since joining this wiki
September 6, 2007


books and apostrophes Edit

I see you met the apostrophe again. Your notes on how to get around that are on {{set ahn}}.

It is a pain. Either we tell contributors to use something weird like ~ tildes instead of semicolons to separate items in a list, or we require the renaming of countless pages on multiple wikipedia's that may have an html entity in the pagename. ~ Phlox 21:16, September 30, 2009 (UTC)

I've copied all the book templates from Wikipedia. Seems pretty straightforward, but there needs to be a Special page Genealogy:Books. Can you as a Bureaucrat make that or do I need to ask Wikia staff? rtol 20:51, September 30, 2009 (UTC)

I would have done this myself earlier but we can't do the books until we have the required extension approved by wikia and then installed. Until then, the templates will be non functional. No worries though- I made this request to wikia staff, so it should be in the pipeline. ~ Phlox 21:12, September 30, 2009 (UTC)
oops. Wrong place for fix note. Anyway, on the books thing, the deal with that is that they are working on something similar and it will be out shortly. If we stick to the CSS conventions and the not print version templates we won't go far wrong. However it might not depend on the wikipedia type templates.... ~ Phlox 05:24, October 1, 2009 (UTC)

A plus (+) instead of a semicolon (;) is by far the best choice, as it is easy to spot on the screen and on the keyboard, and as it somewhat logical wife1+wife2 v wife1;wife2 v wife1~wife2

Wikipedia Edit

I'll start using {{Showfacts interwikis}} soon. Thanks for that.

On uploading Wikipedia, it's easy to copy text, much harder to get the genealogical data into our format. I would do this in stages:

  1. Copy bios from WP to FP for those that have a page on both, and for whom there is a link from here to there. Note also the "Familypedia" template on WP.
  2. Copy bios from WP to FP for those that do not have a page on FP or any relation, and get this into FP shape. Examples include the Imperial Family of Japan, Roman Emperors, and the families of Djenghis Khan and Mohammed. Pretty serious omissions on our part.
  3. Copy bios from WP to FP for those with weak links on FP. Examples include the Romanovs, Celtic nobility, and Byzantine Emperors.
  4. Copy bios from WP to FP with strong links of FP. Examples include British, German, French and Spanish nobility.

At all times, put a marker on these pages for manual checking later. rtol 07:36, October 5, 2009 (UTC)

Thanks for the tips on how to operate WP transfers. Having done over 80,000 xfers for this and the psych wiki, and written data mining software for the last 20 years, it's still true I may have missed a trick or two. Not receiving a specific mention of which area you are most interested in, I shall proceed whereever is convenient. ~ Phlox 07:43, October 5, 2009 (UTC)
I have a lot of faith in your abilities.
The three areas of most active development are the descendants of Charlemagne, the ancestors of Prince Charles, and the ancestors of Will Shade. These are the same family, actually. You're welcome to join in, but I would think you want to test this first with something easy. There no emperors of Japans on Familypedia, so you do not need to worry about merging records. There are a few Russian czars on Familypedia, but a number of daughters and wifes, so that is a grade more difficult. Uploading the Kings of Portugal is a harder still, as they should be connected on all sides. rtol 08:58, October 5, 2009 (UTC)
If you get the Kings of Portugal right, you can safely assume that everything can be uploaded. rtol 09:01, October 5, 2009 (UTC)

Naming conventions Edit

Wikipedia is not particularly consistent in its naming, so I do not feel bound by it. I should, of course, follow the conventions on this site. That said, a genealogy site should refer to people by their family name, not by their job. My name is Richard Tol. It is not Richard, Professor of Economics. But Adalbero I fudged. His family was in flux in this generation. I'll give him the same name as his brother. rtol 07:27, October 13, 2009 (UTC)

Trees Edit

Good stuff.

Will cleverly puts in a link to the next tree. See Ancestors of William Allen Shade (1968) : Pedigree Chart 20-3. rtol 07:25, October 14, 2009 (UTC)

Here is what another contributor was doing in October 2007 about a little known Senator from Illinois. [1]. The structure is not optimal for navigation. Not that continuations would be done that way in the next version. Anyway, I will enhance the scheme after getting the basics in, and verify it is fast enough. We should be able to generate these automagically for everyone's article (probably inserted via bot). I am not settled on the subpage structure yet, but I can get a substantial speed increase on the main pages by putting the time consuming stuff on a "sensor" page. For example, Henry I takes 50 to 70 seconds old style, now takes about 20 seconds new style. ~ Phlox 10:20, October 14, 2009 (UTC)
You're ahead of the curve as usual. rtol 11:54, October 14, 2009 (UTC)

Problem? Edit

I notice that Caroline Polyxene von Nassau-Usingen (1762-1823) is reproting "string too long" for Property:Children-list1, and I am sure there are much longer out there (eg Wilhelm Heinrich von Nassau-Usingen (1684-1718)). Thurstan 01:52, October 15, 2009 (UTC)

Showfacts person-ex Edit

I did not pay attention to Showfacts person v -ex.

Showfacts person-ex is the template I get when I click on a red link from an info page. I fill out the form for the first person, and then copy it down the generations. rtol 17:16, October 16, 2009 (UTC)

Ahn Edit

  • In duplicate, I had a check to verify there are not duplicates between the motherside and the father side ancestors. Currently, it just outputs "duplicate". I recall some talk about inbreeding tests. Was this the purpose of the duplicate check? If so, I vaguely recall you doing inbreeding some other way, so it would seem that this portion of the logic can be tossed. True?

The duplicate check is there to reduce the amount of output. Robin complained about it, as it leaves information out.

{{inbreeding test}}, {{couple ancestors}} and {{Coefficient of Inbreeding}} use the descendants list.

Ok. Set ahn and set dsc don't rely on the same templates. For example, Descendants uses a separate Convert dsc. I am not dealing with set dsc at this point. Perhaps the dsc code is where the duplicate checking that you are recalling occurs because all ahn convert does if the duplicate conditional is true is display "duplicate", and nothing else.
  • Secondly, the 5 generation limit you have in there can be relaxed since the calculation will be on a separate /sensor subpage.

Good. 10 generation is enough I'd say.

If we run into any further performance problems, I can look at doing the cached common ancestors idea. Basically there is no reason to constantly recalc the same trees over and over that are shared. With that sort of optimization, the generation trees would be enormous- we could handle those unusual ones that go back to Egyptian times. But.... for some other day after version 1 is out.
  • What are the templates that interrogate the Ahnentafel property? AFAIK, only set ahn and the showfacts tree thing uses it.

{{show descendants}}, {{common descendants}} and {{lineage}} use Ahnentafel.

Thanks, I will have to look at those.
  • Thurstan prefers "pedigree" as the tab name for where ((t|showfacts tree02}} and possibly ((t|showfacts tree01}} are used. While "pedigree" has a precise meaning for genealogists and is preferable in that context to the ambiguous term "tree", the term "pedigree" is off putting for family history neophytes- what with the "purity"/"class"/dog breeding associations of the non genealogical sense of the term. If we are shooting for a general audience, it seems to me we should not use specialized language in our interface. ~ Phlox 21:45, October 18, 2009 (UTC)

If "tree" is ambiguous, why not use "ancestor tree". While we're on this, "Ahnentafel" is worse jargon than "pedigree"; "ancestor table" is much preferred. rtol 05:21, October 19, 2009 (UTC)

Ancestor tree is fine with me.
The reason why I am fiddling with the ahn structure is that it is very difficult for novices to extract data from it- not to say how inefficient it is using rpos's and sub's to extract stuff. ~ Phlox 06:52, October 19, 2009 (UTC)
Very difficult to manipulate indeed. Descendants mirror ancestors, so I may try to copy & invert the new structure for ancestors to descendants.
By the way, descendant templates use the ancestors property, and ancestor templates use the descendants property. This is because "common ancestors of you and me" is the set of all those people who have both you and me as their descendants. The intersection of your ancestors and mine is faster, but the old property was a string rather than a set. rtol 07:25, October 19, 2009 (UTC)

The ahnentafel property has been an N-ary array since I created it in May[2]. I have fluctuated the article name from a a page to a string occasionally, but the queries on pages use synonyms via the #REDIRECT pages, so it is worth the bother of manipulating them. (By the way, that is why the new simple parsing uses #explode:s with brackets and bars in them.) Anyway, I shall plow on ahead doing converting set ahn to Showfacts set ancestors. The transition will use the old ahn data and convert it to use for the new format Property:ancestors. I am not sure that all of the applications you have in mind can be achieved in templates with current SMW features, but I believe as I have remarked before that Javascript and Ajax will open up new vistas in capabilities since the processing can be done on our own machines, then saving the results back to the server. This has the advantage of offloading the Wikia servers, and allowing contributors to invent algorithms as time consuming as the processing power of their local machines permit. The advantages will be clearer when I create a few hello world type gadgets using the showfacts properties. Development probably won't be as sluggish after first release because with a larger audience we may have more contributors with the inclination and skillset necessary for the mountain of interesting applets that could be created.

We'll see. ~ Phlox 17:08, October 19, 2009 (UTC)

Hi Phlox, Thanks for the message. I just started here at Wikia, and am super excited to meet more community members. I just learned about Familypedia, and am really looking forward to digging in more. I was just thinking over this past weekend how I should really try and learn/record more information about my family history. Feel free to contact me with comments/questions! Cheers, Sarah@Wikia (talk 18:35, October 19, 2009 (UTC)

Descendants Edit

I understand the properties ancestors and descendants are now static. This makes sense for stability. How do I force an update? Sancha de Navarre (c885-?) had the wrong children. Now corrected. Need to update descendants to get the right tree and the right inbreeding. Thanks! rtol 07:32, October 20, 2009 (UTC)

The new properties and their related templates are not complete. After they are tested with the templates you mentioned that depend on them, I shall begin the transition. Until then, continue to use set ahn on the main page as before. The new stuff (ancestors property and the code related to the /sensor page should not be interfering with how ahnentafels were generated in the past from an smw template call from the main page. If that is not the case, let me know. It is true that I created a few test articles that do not have smw template on the main page, and if any of those are needed, feel free to revert them back to their original status.
You will be able to force updates as before. SMW appears to require an edit- save to actually generate the property, so running autowikiabrowser from oldest to youngest would probably be the best way to go about it. When this is sorted out we will need a comprehensive script to run on the site to update everyone's sensor page periodically. ~ Phlox 16:41, October 20, 2009 (UTC)
I've saved Sancha about 10 times now. She's still stuck with the son of her husband's first wife. rtol 17:17, October 20, 2009 (UTC)

Oh. I have an idea about what is happening. Must drive the girls to school though so I will have to look at it when I get back. ~ Phlox 17:25, October 20, 2009 (UTC)

hmmm. It appeared the problem was because it was encoded using info page templates? Because it seems to be ok now that she is encoded using showfacts children. Or am I mistaken. Endregoto d'Aragon (c910-972) + Velasquita d'Aragon (?-?) are now displayed as children of Galindo II d'Aragon (c875-c922), which is correct, right? ~ Phlox 18:19, October 20, 2009 (UTC)
Children are correct. Descendants has Sanche II Garcès Abarca de Navarre (c940-994) (son of her second husband by his first wife) but not Endregoto and Velasquita. rtol 18:37, October 20, 2009 (UTC)

I never was clear about how descendants was intended to work. I'm not sure you want to do descendant analysis that way anyway, but I haven't looked at it. My main concern at this point is to isolate the processor intensive stuff off the main page, and make sure that it could be practically done that way. Ancestor structure generation seems to show that. All info and facts pages are having the sensor and tree pages generated now. Once the ancestor data checks out, the plan is to retire the SMW templates templates from the main page. ~ Phlox 09:37, October 22, 2009 (UTC)

Similar issue with Ramon I Donat de Bigorre (c910-?). I changed his mother's name from Lupa of Navarra to Lupa of Pamplona (as Navarra did not yet exist at that time). As Ramon/sensor, his mother's name is and remains Navarra, no matter how often I save. rtol 12:25, October 25, 2009 (UTC)

False alarm. This is an info page, so I also needed to save the main page a couple of times. rtol 12:47, October 25, 2009 (UTC)
There may be some further optimizations to the way we detect these trees. We almost melted the servers during a bot run on Friday and I had to talk them out of disabling SMW completely for the weekend. I know how to deal with what caused the Friday problem, but in the future I would like to be able to predict better how much load we are putting on the servers.~ Phlox 18:44, October 25, 2009 (UTC)

Temporarily disabling Semantic MediaWiki Edit

Hi Phlox,

For some reason, the way that Semantic MediaWiki is implemented on the Genealogy Wiki is causing our database servers to overload. Our engineers are currently investigating why that is happening and will either try to resolve the issue or work with you to modify the implementation here so that it doesn't impact the performance of the site. Unfortunately, for the time being, we need to temporarily disable Semantic MediaWiki. We believe that we can resolve the issue by Monday and re-enable Semantic MediaWiki then, so it will only be down for the weekend. I apologize for the trouble, and I will let you know if there is anything that you can do to help get it back up and running sooner. Please let me know if you have any questions. --KyleH@Wikia (talk) 18:01, October 23, 2009 (UTC)

This matter resulted from confusion about the cause of a server slowdown. It was created due to a Bot run that was generated large numbers of SMW template calls. The bots were shut down for the weekend and SMW was turned back on a half hour later after the situation was explained to the wikia technical staff. IRC, Contact staff, and Direct email to KyleH was used to resolve this, in case anyone wonders how to resolve this sort of thing in the future....~ Phlox 06:57, October 24, 2009 (UTC)

SuggestionEdit

Upon looking at some articles that were created using the form system, I noticed that it groups the general references together without providing any inline citations in the body of the article to indicate what information is attributable to which source(s). Of course, it's better to have some sources than none, but I thought you may want to keep the citation guidelines in mind as you continue to develop the forms.

Also, is there a reason for including a Contributors field on the form? All contributors can be viewed in the page's history, and advertising contributions seems to promote ownership, which policy frowns upon. Regards —DeGraffJE talk 04:26, October 24, 2009 (UTC)

The form is not for creating the body of text for the article, so it cannot possibly create refs for it.
Perhaps you are unaware that the <ref> tag does not work with parameters inside of templates. They cannot therefore be used for citing any material found in infoboxes or retrieved from properties. Besides recording sources for each discrete event, the form has fields for primary versus secondary versus tertiary sources. Further, the forms autosuggest legal values for person and place names.
Anyway, the body of the article should use refs as in standard wp articles.
The rationale for contributors subsection is that some contributors insist on placing these on articles as is common practice on Genealogy sites. It is sometimes regarded as a marker that "this person 'owns' this article"/ has some kind of special status or authority over the article. I don't want that interpretation to take root here for reasons pretty much identical to WP:OWN, so the idea is to co-opt it. The contributors list is stated to be anyone who has made any substantive edit to the article, and I intend to put in a helper javascript applet to autofill this for anyone that edits using the form.
Hope this helps - ~ Phlox 06:49, October 24, 2009 (UTC)
I am unaware of any such limitations regarding <ref> tags inside templates, as I see it done frequently on Wikipedia (see Barack Obama and the tags used inside Infobox President).
Regarding the ownership issue, I don't think co-opting a policy is good practice. Template:Maintained might be a good compromise, where contributors aren't listed on the article (since that's already on the History) but people can list themselves on the talk page as an expert or point of contact for the article. —DeGraffJE talk 13:01, October 24, 2009 (UTC)
Well, that's one response. Possibly you are unaware of the limitations I described because I don't know what I am talking about. On the other hand, it's easy enough to learn something new and test and see if what I say is true. As a factual matter, ref's are processed prior to expansion so you will find that you cannot for example place a parameter inside them.


Regarding the Contributors section, beginning at the beginning, I am at a loss as to why you find it objectionable since you did not say why you didn't like contributors section other than the idea that it was redundant to article history. Encouraging use of template Maintained is just fine, but you have not addressed the issue of people who want to place "Contributors" on their page and list their name on it as a quiet way of putting redlines around "their" articles. What are you proposing- that "Contributors" section be banned from articles? You will get significant pushback on that. So, your objection is noted, but I don't see that it can be administered in a practical fashion. If you can come up with any way to head off the mountain of WP:OWN issues that will inevitably occur, then I'd love to hear it. ~ Phlox 15:41, October 24, 2009 (UTC)

Reflexivity Edit

{{#if: {{getfact|father}} | {{#if: {{#ask: [[Children::{{PAGENAME}}]] {{showfact|father}}}} | page is fine | not father's child}} | no data for test}} works fine on the page, but not on the sensor page. I guess we want diagnostic tests like this on the sensor page. Any hint? rtol 12:44, October 31, 2009 (UTC)

As usual, asking for help was enough to solve the problem.

{{#if: {{getfact|father}} | {{#if: {{#ask: [[Children::{{BASEPAGENAME}}]] {{showfact|father}}}} | page is fine | not father's child}} | no data for test}} works fine on the sensor page. Silly me. rtol 12:46, October 31, 2009 (UTC)

I notice this phenomenon too. I'm not sure if it is the formulation of the question in concrete terms that does it, or the externalization of the problem so that one is now viewing it from outside. I sense it is the latter, but I have no idea why it is so. Hominids are odd creatures. ~ Phlox 15:50, October 31, 2009 (UTC)
Third alternative explanation: Calling for help exposes vulnerability; the resulting fear stimulates the brain.
Anyway, problem is solved. I added {{reflexivity test}} to {{SMW templates-ex}}. Results at Familypedia:Diagnostics, but no positives yet. rtol 16:39, October 31, 2009 (UTC)
That's better than mine. Rapid modeling of alternative scenarios is essential for risk assessment in a survival situation, so having fear tightly wired to problem solving would be a significant advantage for species that possessed it. In Brilliant Mind, John Nash found a tight link between fear and imagination. But as the story was related, at first his ability to see hidden mathematical patterns had nothing to do with strong perceptions of fear. ~ Phlox 17:00, October 31, 2009 (UTC)

Please see Familypedia:Diagnostics. Loads of pages fail the reflexivity tests. I think the reason is that the sensor pages show children-g2 to -g9, but not children-g1. I would not know how to fix that. rtol 18:54, October 31, 2009 (UTC) For partners, the ++++++ seem to cause the problem. rtol 19:04, October 31, 2009 (UTC)

Those values generated by the lines following reflexivity test in SMW templates are for info page translation only. You should be refering to their true values on the basepage, not the sensor page, since among other things they are not properly formatted as you have noted. There are much more serious flaws, but I am attending to that. The scaffolding code Facts from info pages never brought all info page material over. Fortunately, I am perfecting the info page converter Bot code, so we shall be able to move these over shortly and you will have proper descendants values on the main pages. Until then, you might be able to cobble something together with the children values on the sensor page, but it would be throwaway code. ~ Phlox 20:08, October 31, 2009 (UTC)
It is more basic. {{#if: {{getfact|father}} | father there | father not there}} is a test whether the name of the father is known, rather than whether the father has a page. rtol 21:13, October 31, 2009 (UTC)
works as it should with #ifexist instead of #if rtol 22:14, October 31, 2009 (UTC)
Try #ifeq:getfact father| |.... It might be returning a blank.
Secondly, whether the article exists or not is an unrelated idea. A frequent case is that there is not article, but there is a string in the children articles that indicates the name of the father. They should all be the same string. #ifexist has absolutely no bearing on that determination.
Reflexivity has more than an error check role. If the user does not explicitly state a value in the form, it can be automatically derived from its reflexive property through the sensor page. If you did this sort of checking on the main page, it would be slower than a herd of turtles stampeding through peanut butter. With the sensor page, we can do the check once every month or so, and cache the result so that it can be quickly retrieved for every main page refresh. ~ Phlox 00:56, November 1, 2009 (UTC)
We're talking past each other here. The reflexivity test is on the sensor page. It checks whether the page of the man that I list as my father lists me as a son. Ditto for mother and spouse. That's all. It seems to work. It has not generated any more false negatives, and did already uncover some errors (e.g., between my grandmother and her mother).
Re. siblings: We have no way of checking sibling-ness without a page for the parents. We should be able, however, to create a list of "Pages that should be created" with a query on people that list Adam Smith (1774) as their father while there is no page for Dr Smith. rtol 11:46, November 1, 2009 (UTC)

I understood you were working on the sensor page- my closing remark had to do why I had not incorporated automatic suggestion of reflexive property values prior to getting sensor page infrastructure in place.

My misunderstanding had to do with a wrong assumption about the extent of the reflexivity checks being done. I see this is not referring to the declared Property:siblings. Yes of course you cannot check parent child agreement without the existence of both, but you can do sibling sibling as I assumed you were doing. This does not require an existence check on the parents. Anyway, in my haste I went off in the weeds on that score and I should have just looked at your code before commenting. It probably will not surprise you that I regard this sibling property as an odd beast because it adds redundant declaration- inviting further database inconsistencies. As a practical matter though, it is a simple matter for researcher to include a notation in the siblings field if they have the data on siblings sitting in front of them. Requiring them to do it "right" poses a significant barrier, since they must stop work on that article, create a parent article with the children list.

By the way, doing a #show:FooPage|default=|?Modification date= achieves the equivalent ifexist check without racking up the NewPP expensive parser call count. My engineering guess is that the #show would cost the same as an ifexist, but not knowing the implementation of either SMW or mediawiki, there is a lot of room for me to be guessing wrong. Nonetheless, I am not convinced that there is any real benefit to it in performance. But the metric and instructions I have says that ifexist should be avoided where possible so I started incorporating the show check above in place of ifexist.

Yes, there will always be inconsistent data entered, so a check like this will always be necessary somewhere in the code. It would be a neat trick if we can prevent many of the inconsistencies being entered in the first place. I would think that the check and the automatic inheritance would happen in the same mechanism, but the sensor page has to be in place first. Regarding the Bot gone amuck- This seems to be the final portion of info page run, because that is where the ?-? dates are. This means we are close to eliminating the SMW checks from the main page.

~ Phlox 16:25, November 1, 2009 (UTC)

Bot gone wild? Edit

PhloxBot just created a sensor page for "~Adriaen Breen (?-?)" rather than for Adriaen Breen (?-?) rtol 11:26, November 1, 2009 (UTC)

I haven't looked at the damage yet, but it is a simple matter to delete masses of pages via bot. You can't do it in AWB, but it is simple in pywikipedia. Thanks for the report. ~ Phlox 16:27, November 1, 2009 (UTC)

multi AFN Edit

I notice that notwithstanding my hint here, Property:familysearch afn is not being treated as multivalued. Can {{Showfacts person}} create multiple links when multiple values are given for AFN? Thurstan 22:23, November 1, 2009 (UTC)

I haven't seen any with a "+": they seem to be 3 or 4 alphanums, a dash, and then 3 or 2 alphanums. The examples that I created with /info pages (see Mary Stewart, Queen of Scotland (1542-1586) for example) I coded as "Familysearch afn2" etc, with {{Get references}} supporting up to 6 values. Thurstan 22:43, November 1, 2009 (UTC)

wikipedia:Personal Ancestral File#Ancestral File Number claims to describe the syntax of AFNs. Thurstan 22:49, November 1, 2009 (UTC)

SMW templates Edit

{{SMW templates}} can be removed from the main pages, now that the sensor pages are complete.

There is something very strange going on with ({t|set dsc}}, though. I noticed this on the sensor pages, but I am not sure that this is the cause. I have not been able to figure it out. The main problem is that Property:Descendants is sometimes updated, and sometimes not. A minor problem is that it does not display links.

The main consequences are that {{Inbreeding test}}, {{Coefficient of Inbreeding}} and {{Couple ancestors}} do not work properly.

Should {{Couple ancestors}} be on the sensor or the main page? It gives the common ancestors of husband and wife. I would put that on the main page.

The results of {{Inbreeding test}} and {{Coefficient of Inbreeding}} can be put into the biography and table, respectively. rtol 19:09, November 2, 2009 (UTC)

Where we do calculations is fully decoupled from where we do display, so I am not sure what rationale there would be for putting Couple ancestors on the main page. After doing the calculations on the sensor page, we use a single #show to retrieve stuff from the sensor page, and present it to the user on the main page as a value in a table, in a biography passage or as a category. That is what get globals is for.
I am willing to look at specific examples but I don't support set dsc, nor have I been satisfied that it has ever worked properly. As for the move to the sensor page, the only difference in running on the sensor page is the occaisional PAGENAME needs to reference BASEPAGENAME. If you have some concrete example of something not updating, I can take a look at it, but I really have a lot of other stuff I should be doing with the converting info pages to facts pages. As for any substantial investment of time on these analysis tools, it seems to me that if resources are to be spent on it, it should be spent rewriting this stuff in Javascript so that far more substantial computing resources on the client computers can be used, and because that way the tree can be walked virtually without limit. Doing it server side is continually be getting us in trouble due to the limitations of the wikitext programming language and limited server side computation. So fundamentally it looks like sending good money after bad. I don't mind helping patch something to get you by, but I don't want to spend a lot of time on it until after relaunch. ~ Phlox 22:40, November 2, 2009 (UTC)
I don't think this response is quite satisfactory. Property:Descendants is the driver behind key genealogical variables such as the degree of inbreeding and relationships between parents. Furthermore, it was fully tested and used to work fine until you optimized it for speed, without documenting what you changed and why. rtol 05:49, November 3, 2009 (UTC)
Ok, I went through the set dsc modules and don't see any edits of mine since long before this optimization. Let's get specific. Which modules did I edit, and what specific examples of breakage are you seeing? ~ Phlox 06:16, November 3, 2009 (UTC)
I have yet to put my finger on the main problem. There is one problem that should be simple for you: Why does it display the name but not the link?
The main problem is that Property:Descendants is sometimes updated, and sometimes not. It should append the children's descendants to the parents', and it does on some pages but not on others. Just have a look at a couple of recently added pages and work back through time. My current hypothesis is that {{SMW templates}} on the main page interferes with {{SMW templates-ex}} on the sensor page. Your testing that hypothesis. rtol 18:41, November 3, 2009 (UTC)

Edit conflict- My response to the above notes:

  • The Property:Descendants will now output Page. I don't recall the exact rationale for changing it to the string, but it involves complexity in parsing the field properly since the commas that SMW engine provides are not reliable as a separator due to their possible use within the name of an article. I should have left it alone for descendants because at the time my recollection was that they used the same convert submodule. That sharing was dropped long ago. Anyway, Ancestors does use the Page type, but it also now has 5 fields, compared to descendants that has the original 3 fields. A list of some of the factors on whether to declare names as type string or page as well as others may be found on the Property:Ancestors page. The ancestors scheme is stable enough for now, but I have some performance concerns about how the slow the #sets are to create them. If I do the field as a text field, I can assemble them in a single write- However they are then opaque to the SMW engine.
  • I think the plain text Property:ancestors list and Property:Descendants list on the main page is obsolete. I doubt you are using them, but if you are, let me know.

As an aside, I noted one of the modules was accessing the old property name for parents "coparents". I may have put a synonym check in getfact, so it may not matter. ~ Phlox 19:10, November 3, 2009 (UTC)

Examples of set dsc anomaliesEdit

For example:

  1. Louis Philippe of Orléans (1773-1850)/sensor is fine
  2. his father Louis Philippe II of Orléans (1747-1793)/sensor
    1. descendants: son is missing
    2. re-saved sensor, did not help
    3. re-saved main page, did not help
    4. re-saved sensor, still not there
    5. re-saved main page, put in "SHOWFACTBOX", property:descendants is on the main page but incomplete, children-g1 is correct, ancestors are not on main page
    6. re-saved sensor, descendants still not as they should
    7. had another look at the son. Father is correctly listed as father.
    8. back to father, added {{SMW templates-ex}}; we now have property:descendants and property:descendants list; both wrong
    9. re-saved sensor; did not help
    10. back to son, added {{SMW templates-ex}};we now have property:descendants and property:descendants list; both fine
    11. back to father, resaved main page; descendants is now fine; descendants list is not
    12. checked sensor, now fine

So I guess the problem is that the template works on the main page but not on the sensor page. rtol 19:01, November 3, 2009 (UTC)

First off, the father article was never updated after creation. Purge is not the same as resaving the article. Regardless what the facts box tells you, you will notice that properties returned from a show will not be what they should be unless the article is re saved. But there are much larger questions I have.
Regarding set dsc, I never understood what the purpose of keeping ahn numbers was, or even larger, why use the set dsc parallel structure at all. After all, you can derive descendants from ancestors, so it appears at first glance to be redundant. Example:
{{#ask: [[Ancestors:: ?;>1;?; Mareen_Duvall_(c1630); ?]] }}
Says: give me all the articles where this person is the ancestor of someone (not the first generation). Is set dsc really giving you a lot more than that? Ancestor Ahn numbers can be used for all sorts of things, like fetching all the great great grandchildren. ~ Phlox 19:35, November 3, 2009 (UTC)
Fair enough. Inbreeding and stuff can be redone with ancestors too. The only exception is {{lineage}}. That said, as {{set dsc}} seems to work on the main page but not on the sensor page, fixing it should be less work than rewriting the template that use property:descendants. rtol 06:57, November 4, 2009 (UTC)

You state the son is missing on Louis Philippe II of Orléans (1747-1793)/sensor. The son is not missing. Look at the history of Louis Philippe II of Orléans (1747-1793)/sensor. You state in point two that you resaved. There are only two saves. Initial creation and my edit (which found the son). Reread what I said about purges. They don't work on properties. Also, if you save with a trivial change (trailing space), the wikimedia engine will not resave. This may be what happened if you are positive you weren't using purge. ~ Phlox 07:31, November 4, 2009 (UTC)

Thanks for the tip about saving.
I've removed {{SMW templates-ex}} from the main pages, and property:descendants is wrong again on the sensor page of dad. rtol 08:18, November 4, 2009 (UTC)
If I were to debug it, I would step through verifying that it got children-g1 correctly from the basepage, that secondly it passed it to aux1 correctly, then if it passed it to aux2 correctly. It isn't complicated. Personally, the thing has severe flaws due to the lack of other delimiters, so it would be a lot of work to fix this redundant code correctly. ~ Phlox 08:46, November 4, 2009 (UTC)
It's much easier to run {{set dsc}} on the main page. rtol 08:59, November 4, 2009 (UTC)

It sounds like you just said that you would rather that everyone view the main page significantly slower because you do not wish to debug code that you have been championing. Yes, it is hard, sometimes very hard for engineers to make things easy for others. It is exceptionally easy for an engineer to make things hard for others. Robin, Elrondlair and Bergsmit have complained about how slow the new system has been. They were right. You and I know why. It is because tons of computation was repetitiously happening on the main page for no good reason other than it was easier to code that way. Fundamentally, ancestors present a combinatorial explosion of computation demands the deeper you go in the tree. Set dsc is worse, because the tree branches each generation not by 2's but by as many children as there were. There are many ways to optimize our approach and I think that after I profile the SMW activity on a local machine I will isolate what types of implementation approaches we must avoid. Doing nothing is not an option. Already wikia staff have noticed the load and in fact turned it off and wanted to leave it off for the weekend because of the load on the system. The load caused by what? By the burden of set ahn and set dsc. They may not understand what exactly is causing the drain but they aren't fools- they have 60K wikis and will not let one that is generating low traffic to consume a disproportionate share of server resources. Ultimately it is their server and they can pull the plug at any time. So even if you ignore the complaints of other contributors and they do not block your changes, at the end of the day the approach of ignoring performance problems is a doomed formula. Perhaps that is an end game that you are not considering.

So you couldn't be more wrong when you claim that it is easier to put set dsc on the main page. ~ Phlox 16:50, November 4, 2009 (UTC)

Let's get the facts straight.
The overload was caused by PhloxBot.
{{set desc}} was working well.
You replaced it with {{set dsc}}. The programming is more streamlined, but I do not completely understand it.
{{set dsc}} was working well, until you introduced sensor pages.
There is probably a simple fix, because the problem is a page referral.
As you wrote that part of the code, and as you changed the page setup, perhaps you should spend less time arguing that I messed up thing, and more time helping fix this problem. rtol 06:48, November 5, 2009 (UTC)
Any time that pages requires 60 seconds to update, there is a serious problem. 1000 users hammering on a wiki with 500K pages would generate the same loading problems as PhloxBot did with its puny updates of 500 pages every 6 hours. Blaming Phloxbot is little more than the response of shooting the messenger.
My goal is not to mess up your tools, but to create an environment where folks can create such tools without penalizing the activities of other contributors. I simply do not have the time to debug set dsc or set desc, and I shall not support either.
It's not tough to debug this stuff- it is just time consuming and requires patience and careful logic to deduce the source of bugs. Put a *"{{{1|}}}" or any other paramater you want to sniff at the start of the template modules. I'll bet one of these queries is returning something like /sensor on the tail, and all you have to do is strip it with a #replace. ~ Phlox 07:23, November 5, 2009 (UTC)

Charlemagne Edit

One unanticipated consequence of removing {{SMW templates}} from the main pages is that the descendants of Charlemagne are now longer recognised. I'll run AWB to restore this. This requires saving all sensor pages several times, as this is done generation by generation. Should I use the opportunity to replace {{SMW templates-ex}} with {{SMW templates-ex}}?

Thanks for the hint on set dsc/aux1, by the way. rtol 06:10, November 6, 2009 (UTC)

oops. Didn't send this last night. Too many windows open.
re dsc- I don't know if that is all of the difficulty in set dsc, but it occurred to me when I was looking at some set ahn code.
re rename- your call when you want to do it, rename and move code over. I nuked some of the obsolete checks that I put in there.
Remember reset your awb site name to familypedia. I made a post to the general community about this. Otherwise you will get a log error message about an interwiki redirect. ~ Phlox 18:58, November 6, 2009 (UTC)
No error messages. AWB just ignored all pages. rtol 20:53, November 6, 2009 (UTC)
On the lower right pane, you will see tabs above the "edit" window. Click Logs. You wil see the error message I mentioned on the articles that were skipped (which would have been all of them). By the way, you can select and right click these back into the list pane so that you can have another go at the ones that were saved/ were skipped depending on what you are doing in your workflow. ~ Phlox 20:57, November 6, 2009 (UTC)

Half-Siblings Edit

Do what you need to do to get the fact pages rolling. We can drop the half-siblings until you have time to create that part. Bill Hunsicker 22:23, November 6, 2009 (UTC)

Korvers Edit

The conversion of the Korvers is fine. Any errors are errors copied from the info pages. I'll tidy up after you. rtol 06:40, November 7, 2009 (UTC)

Hiding large runs Edit

We used to have "recent changes", with the option to hide minor edits (incl. my AWB runs) and bots. Now we have an "activity feed" without those options. rtol 06:46, November 7, 2009 (UTC)

No big deal. Just create RtolBot account, and I will give it a bot flag. ~ Phlox 06:50, November 7, 2009 (UTC)
It's easy to create a new account. Getting AWB permission will take some time. I see your point. Run stopped. rtol 07:23, November 7, 2009 (UTC)

You're welcome. Computer does most of the work.

Thanks for the hints.

The run did not crash. I stopped it (and again) because I had not fully tested the templates ... rtol 17:43, November 8, 2009 (UTC)

Well, what I have seen is not really a crash- it just gets out of automatic mode somehow. Never happens with pywikipedia, but does with AWB. ~ Phlox 17:56, November 8, 2009 (UTC)

Tol conversion Edit

The Tol pages that you converted are fine. You have skipped some. My edits after 1600 will catch the rest. rtol 06:09, November 10, 2009 (UTC)

I believe did all the ones in Tol (surname) category that had an info page- that is, all those that had info pages when I did the add tree run last week. ~ Phlox 06:25, November 10, 2009 (UTC)
I must have looked at cached pages then. One of the pages you seemed to have skipped was my dad's, but that one is fine now. rtol 12:53, November 12, 2009 (UTC)

Little formatting problem Edit

I have created Ottilie von Nassau-Dillenburg (1437-1493), with no days in the dates of birth and death (following my source), and when her father Heinrich II. von Nassau-Dillenburg (1414-1451) does a {{showfacts children}} we get an error message. Thurstan 05:07, November 12, 2009 (UTC)

Percolation Edit

A quick look at Project Charlemagne/count shows that Property:Order of Charlemagne is now properly assigned to most descendants. This is surely not a result of the run that I did updating all sensor pages, as I got the order wrong with all the unknown and uncertain birth dates. So, the system must renew properties without saving. rtol 12:50, November 12, 2009 (UTC)

It is a mystery to me how updating is done. Normally when changes that affect a page are made, the cached version of the page is marked as invalidated and requiring an automated refresh by the server. The count of these is what Special:Statistics refers to as the Job Queue. Normally this is zero- but on during times of high load on wikipedia it can be behind by thousands of pages. You will notice that ours is hardly ever cleared out. I theorized this was partly because we were bad boys and the info templates took too much cpu to be constantly updating them. So my thought was well- we'll just refresh them via bot, and do that in a conscientious way so no one would come and pull our plug.
Now it appears that SMW or something is running a process that does update at least the property pages. I suppose if I weren't so lazy I would take a look at the SMW code. It is open source as far as I know, so many of the mysteries would be solved. However I'd probably see a few messes that I'd want to fix and that would divide my attention. Kind of like how I never have picked up a golf club because I have seen many of my reasonably intelligent colleagues go that direction and then they seem to allow it to suck up all their free time. So- golf, heroin and SMW code. Just say no. ~ Phlox 15:35, November 12, 2009 (UTC)

Groups of kids? Edit

Property:Children-g9 seems to have dropped off Charles II of England (1630-1685). I can't see why. Thurstan 04:43, November 18, 2009 (UTC)

Conversion Edit

Have a look at Andrew of Greece and Denmark (1882-1944). Wikipedia links at the info page were not converted to {{showfacts interwikis}}. rtol 06:34, November 18, 2009 (UTC)

There's no rush with this at all. rtol 08:13, November 18, 2009 (UTC)
Ok, then I will incorporate interwiki updates from Wikipedia as part of the regular update rotation bot runs. I will key it off of en wikipedia since its list always seems the most up to date. So long as the english wikipedia article is indicated, I will suck in the others. I might screen out minor wikis if the list is too long. ~ Phlox 08:18, November 18, 2009 (UTC)

Gone Edit

You'll be missed.

I'll have the descendants sorted by the time you come back. Removed a few bugs already, and there can't be too many left.

Do you have big plans for Property:Event? Or can I just add subproperties as I see fit? rtol 19:16, November 19, 2009 (UTC)

The direction I have in mind is twofold- to relate a common family event for a lot of people, like some big chistmas family reunion. Issues- naming conventions for them. The second is to tie people into historical events as they are named in wikipedia. EG: People that participated in a battle, witnessed a natural event like an earthquake or bridge collapse. Some of these events are so huge though that articles would probably be broken into smaller groups. An exploratory article I did had to do with an american civil war battle. In that case, it seemed to me the right way to break it up was by large military units, since they were generally had the same experience of the battle.

I have a form module for doing events that are instanteous (single datetime like for a wedding), and one that is used for timespan events- these are used for migrations and residences. I would make a generalized showfacts event using this form module an the properties associated with it (place, participants, pictures, notes, sources and so on) The only thing different might be an event type- like military, reunion, newsworthy event, and so on.

Big subject. Not sure this answers your question.~ Phlox 20:53, November 19, 2009 (UTC)

Double counting Edit

A quick look at Pietro Candiano (?-976) and Pietro Candiano (?-976)/sensor shows that he is listed twice as descendant of Charlemagne. Once is enough. How do properties get copied from sensor to main page, and could I selectively omit some? rtol 06:43, November 20, 2009 (UTC)

I am thick. I don't see where there is any listing of him as a descendant of Charlemagne, let alone two. Is this a property, or a catefgory or what? In most cases, I would think that values don't really need to be copied to the main page, though it is doing that now for a few properties. Though I am not sure the answer is meaningful, for a direct answer to your query, many values are accessed on the main page with a single call to getglobals. This places the values in a single parameter "global" and string functions are used to unpack property values packed into that string. ~ Phlox 07:14, November 20, 2009 (UTC)
It's property Order of Charlemagne, where the number is the generation (CM = 1) rtol 07:50, November 20, 2009 (UTC)
Order of CM is now removed from {{get globals}}. It probably should be displayed on the main page, but it should not be a property. rtol 07:53, November 20, 2009 (UTC)

Oh I see. You query that property and both the main and sensor subpage come up which is not what you want so what we need to do is make the property name on the main page different than the one on the sensor page. If you want the main page property to be Order of Charlemagne then you will have to resave all the sensor pages. Perhaps easier to rename the property on the main page. The transfer is in showfacts person. look at its history to see the line where I changed the main page property name to "Charlemagne order". Edit Showfacts person and change the property to whatever else if that name stinks. ~ Phlox 08:12, November 20, 2009 (UTC)

Got it now. Get globals gets the values, and showfacts person assigns them.
I'll clean up the inbreeding couples and coefficient in due time. rtol 08:45, November 20, 2009 (UTC)

Yeah, and it assigns some that are obsolete as I recall. But transfer is not the only reason for get globals. You will also see it used at the beginning of other templates- it's in showfacts tabs call and others. Possibly it is an optimization that is not necessary. You could simply have a getfact call on the sensor page for the needed Order of Charlemagne property. Get globals avoids many dozen such largely identical calls to the sensor page by simply using one call and saving the values for later use. I won't know if get globals saves anything until I get set up a test version of the wiki software on my local machine. ~ Phlox 16:47, November 20, 2009 (UTC)

PhloxBot and infobox conversionsEdit

PhloxBot has gotten to converting some of my early pages - thank you! One thing I've noticed though, is that it is adding the city and county to the "places-other" fields, which leads to odd-looking displays - see, for example Josephine McGary (1863-1932). I have few enough pages that I don't mind going in and cleaning this up by hand, as there is other information I'll want to add under the new structure. But a user with a large body of pages under the infobox system might view this as undesirable behavior. Or is there a sound reason that I'm not aware of for putting the information in that way? Bruce Kendall 17:19, November 20, 2009 (UTC)

A quick followup: I've just noticed that the county entry under, e.g., "birth_places-other" includes the state, and so has a valid wiki link, whereas in "birth_county" the state is missing, and so generates a red link. Bruce Kendall 17:31, November 20, 2009 (UTC)

Machine recognition of places is problematic. This example illustrates a couple issues that come up. First, the info page redundantly encoded the places:

Birth place = Norwalk, Monroe County, Wisconsin
Birth town = Norwalk
Birth county = Monroe County
Birth state = Wisconsin

The converter moved Birth place to Places-other, and the town, county and state fields to the correct locations. What seems like it should have been able to do is remove the items that were redundant. My philosophy on doing a manipulation is that if ever there is doubt, don't guess and leave it as is. What doubt can there be? City names can overlap that of a state or a county. eg Honolulu city, Honolulu county. While if you or I said Honolulu, we would think city, whereas on state documents, it could be county. Say "Honolulu" was in Birth Place and Honolulu was in Birth county. Should the converter delete the places other as redundant? How do I know the user didn't mean Honolulu city for Birth Place? Aside from not knowing when a redundant field is redundant, I don't know which slot the locations in places-other fit into. If there are three elements, do I have city, county, state, or do I have county, state nation, or city state nation? If I had lists of Nation and "state" names I could do a bit of this but as of the date of this trancoding, I don't. So this sort of mapping will have to wait.

To add insult to injury, Names indicated by users are nearly always not the Wikipedia name. So a proper conversion would not stop just at state/ nation name lookups. It is going to have to disambiuate names and map names that are redirected on Wikipedia to the proper place name. Norwalk, Michigan is a redirect to Brown Township, Michigan. Next there would have to be correction of mistaken data, or at least a way of flagging the article for possible encoding errors. For example, I see from wikipedia and google maps that Norwalk is not in Monroe county. In addition,

Norwalk, Michigan may not be in Monroe County, but Norwalk, Wisconsin is :-) But I see the larger point. Bruce Kendall 02:19, November 22, 2009 (UTC)

So realy, if the converter was able to do sophisticated lookup of wikipedia names, it would have translated it as:

birth_town=Brown Township, Michigan
birth_county=Manistee County
birth_nation-subdiv1=Michigan
birth_places-other=Norwalk, Michigan

I'm not sure you'd be happy with that outcome even if it could do that sort of lookup. With that said, my intention is to do as much reasonable cleanup is possible in the placename fields for former info pages. Later, these same checks may be run on all facts pages regardless whether they ever had info pages. The reason why is that contributors will often insert a reasonable sounding name not knowing that there are many other places with the same name, or that the name they gave doesn't have the proper classification or the name or location is archaic and it now renamed or part of some other entity. Historical names like Soviet Union or Czechoslovakia can only be used in the places-other field.

Place names are hard, and will be an area of improvement in the coming months. Regard the inadequate way they were translated from info pages as an effort to err on the side of retaining data that could be useful in later reprocessing of the articles when more robust support for detecting errors in place names is in place.

Probably way more than you wanted to know, but I took the opportunity to more fully explain how I see our placename support developing. ~ Phlox 02:32, November 21, 2009 (UTC)


Right, I see. As I recall, the redundant entries were the recommended style when I first started entering data, and were needed because the infobox itself didn't put together the place name components in its display, or at least not in a visually pleasing way - I think I had a bit of a back and forth with Robin and Thurstan about the undesirability of having to enter the details twice, but by then further development of the infobox system had been superseded by the early experiments with the current technology!

As I mentioned, it's not an issue for me, and if there's too much heterogeneity among users then there may not be a robust solution that's better.... Though there's one suggestion I might make:

As I understand it, we use the state to disambiguate the county name (e.g. birth_county=Monroe County, Wisconsin). If the infopage information has the structured information (e.g., Birth county and Birth state), it seems as though it wouldn't be too difficult, and would be beneficial, to populate birth_county with the {county, state} pair. Or is it only US counties that are disambiguated that way? Or worse, am I misinterpreting the fact that when I start typing a county name into a form it suggests a {county, state} placename for autocompletion? Bruce Kendall 02:19, November 22, 2009 (UTC)
The job that the translator did on that article looked bad and my purpose was to explain why I thought it imprudent to attempt to clean it up with such feeble information in the database. It would have been possible to put in some rule of thumb rules that might have worked 70% of the time. For instance, I could have created a rule to remove redundant names except in cases where a name can be for two different government levels for the same location such as Honolulu or New York. But such rules are cockamamie and you need to be doing a more robust method of processing anyway. So this kind of stuff that you don't catch shall be cleaned up, but I need richer information in Familypedia which I shall be importing from Wikipedia. This will tell us information like the containment hierarchy so that if a locality is specified, county and state can be omitted since the system can derive them. All the user has to do is choose from a list of localities (Yes, this means I need to import a LOT of placenames- localities and counties worldwide).
The way autocompletion works is that it has a list of legal county names that are members of a category. That is, when an article on a place uses the "legal county name" category, then only names from that category are suggested. The article name may or may not have the state name. So we only happen to have the state along with the county name because that is what wikipedia does for the US. The convention is not universal, but it doesn't matter because the knowledge of what state/province/oblast that a "county" is in, is stored in Wikipedia infobox articles, and I can extract it. As for the names though, it is hopeless- For example wikipedia:Ammerland, a German district has no such context- The title doesn't say it is a district nor which german state it is in. OTOH all the arrondissements of france have "arrondissement" in the name.
This is all probably clear as mud. Sorry. I'd be happy to explain more but I seem to be rambling too much about things that possibly are of little interest. ~ Phlox 08:18, November 22, 2009 (UTC)

Military events Edit

You may want to cast a quick look at the Battle of Andernach. This now has properties assigned in {{info battle}}, and is linked to the year 939 and the casualties by {{set died at event}}. It should be tied to the locality, but I understand that that is still work in progress. rtol 14:26, November 22, 2009 (UTC)

Good start. This is an example of where we integrate folks into the pageant of microhistory. The possibilities are tantalizing for historians as we exploit these connections and in so doing demonstrate how this is a powerful tool with significantly greater scope than simple genealogies.
Some notes- I personally would generalize as much as possible. For example, military records are often very good so we may know that a person was stationed at a location, or that a military unit was moved at a particular date to a specific new location. That's not a "Battle", so then we would have a "military posting event locality", then a "military deployment locality"? I think not. Let's just have a military event, and then a property:military_event_type with values like battle, redeployment, and so on.
Also we need to follow the encoding conventions of person events. Date should always be a generated field composed of Year, month and day components.
Shouldn't an event also kind of follow the sort of conventions we have for people- for example you have property event= name. Shouldn't we just call it what it is, a name? And if it is a name field shouldn't we just use the convention of have short name, long name and alternative names? As far as the data name, it is the article name, along with redirects (synonyms), so anyone that puts fills in a "participated in event" or death at event" field would have these names offered on the form during autocompletion.
Speaking of autocompletion, you need to create a hidden cat following the same convention for places I suggest Category:Valid name- military event, which would be a subcat of Category:Valid name- event
That's my two cents. ~ Phlox 18:14, November 22, 2009 (UTC)
Thanks. I'll keep chipping at this, following your suggestions and whatever comes to mind. History is people, places, events, and times and we somehow need to create a data structure to capture that. rtol 19:07, November 22, 2009 (UTC)
As complex as it can be to design a decent semantic representation scheme, the easier task is to create the structures. The huge problem is to prevent the structures from getting populated with garbage data. I like the informality of data inline declarations like what you did in the article, but when someone declares where something happened, I would much rather that they pick from a list of legal locations. I know you are no big fan of form input, but it does guide users towards encoding data in ways that will produce meaningful results using SMW. ~ Phlox 21:30, November 22, 2009 (UTC)

Links on Infobox problem Edit

I clicked on the "Wedding" link in the infobox to edit the wedding information, and when I saved it, it created a new infobox and a default sort key error came up. See: Merle Allen Harrington (1894-1978). -AMK152(talkcontribs) 23:01, November 24, 2009 (UTC)

Another problem Edit

For Isabella of England (1214-1241), I have tried to use {{showfacts children}} to show the children from her husband's page. However, that seems to be displaying all her husband's children, regardless of mother. Thurstan 22:46, December 7, 2009 (UTC)

I suspect I know the error but it may be weeks before I can get to a fast enough connection to do the debugging . Right now I am barely running at 5Kbps and we have been without power for over 12 hours. Not ideal circumstances. Howpe you can work around this for the time being. ~ Phlox 03:31, December 8, 2009 (UTC)
It can wait for a solution, just as long it is on your work program. I just hope you survive your primitive environment. Thurstan 20:18, December 8, 2009 (UTC)

EnlightenmentEdit

Will you please explain the "multilingual capabilities on this wiki" to me or point me in the right direction? —DeGraffJE talk 16:32, December 8, 2009 (UTC)

Blowing a limit Edit

I notice that Vilhelmine Marie of Denmark (1808-1891)/tree is in Category: Pages containing omitted template arguments. I take it that that means that {{showfacts tree02}} has blown a size limit. Thurstan 05:04, December 16, 2009 (UTC)

set dsc again Edit

Hope you're fine wherever you are.

Looking at {{set dsc}} again. There are test results at Richard S.J. Tol (1969-)/sensor. The problem is that in the assignment of the property there is a link rather than a string. This link is created in {{Desc convert}} but I can't get rid of it with {{&}}, {{delink}} or manipulating the parameters of {{#sub:}}. Hints appreciated.

Problem solved. Dunno what did it.
I put {{set dsc}} back into {{SMW templates}}. Now rebuilding the database, and from there lineages, consanguinous marriages and coefficients of inbreeding. rtol 12:31, January 11, 2010 (UTC)

Help:Namespce Edit

Dear Phlox, Thank you for your friendly notice from November. I read your argumentation about multilingualism in the Forum(:Language Separation) and i agree with your opinion. If this website would be only for english speaking people I would search for another site. I think in this site is the potential to become a worthily place in the world. Everybody is so precious to become a place in our memory. I have a practical problem. The Help:Namespace site is central stored at wikia and there is a german translation Hilfe:Namensräume (edited by Anne Behrendt) linked about a general language link in the german wikia. I couldn't link it to the origin english version in our familypedia. Could you help me?Cucullus 15:18, December 20, 2009 (UTC)

Descendants tab Edit

See Forum:Descendants tab - so easy, everyone with offspring should have one. I could make head nor tails of the multilingual business with strings -- where do you assign strings to string numbers and properties? The layout of {{detect tabs}} is now messy. rtol 19:45, March 11, 2010 (UTC)

All solved rtol 20:22, March 12, 2010 (UTC)

New Features/ Pain Points Edit

Hello!

I'm Jeska - a Wikia staff member dedicated to Lifestyle and I'm pulling together a list of 3-5 new features that would be helpful for the continued success of Familypedia. These could be something small like a new template form or something more integrated into the site, such as a new background theme or logo. It could also just be a list of "pain points" that you've had that we could design a tool/feature to help alleviate. Please let me know as soon as possible on my Talk page!

Cheers, JeskaD 20:45, August 26, 2010 (UTC)

Help neededEdit

It seems that Wikia changed the forms code and all is chaos. Help would be appreciated. rtol 08:40, November 25, 2010 (UTC)

Property names in genealogy sites and related Edit

I was talking to Robin Forlonge Patterson who said you setup the SMW features on this site.


I was curious because often in reading about the semantic web instead of using something like brother or father, one might use the verb hasBrother or hasFather.

I'm interested in getting a feel for this. It seems like it would be important in some cases to have properties that match what is being used on other sites. The idea of linking data across the web relies on this.

Are there any external vocabularies such as foaf that have been imported to the Familypedia site?

Also, I had the idea of a resume type data content type and was thinking, "should I use 'has skill' or 'skills' or just 'skill' for the name of the property?"

Assuming that people want to be discovered for their skills, it might be good to know what vocabulary terms some semantic searches might recognize.

Let me know if you have any thoughts or insights on this.

Thanks,

Brucewhealton 05:40, December 24, 2010 (UTC)Brucewhealton

A Genealogy Ontology Edit

I found this website that you might find interesting. It had occured to me that since we have FOAF, friend of a friend, as a Semantic Web vocabulary then it only made sense to create a vocabulary for Genealogy. I think it would be a good idea to standardize how we specify properties. I often wonder what are the property names or the predicates used on sites like this - actually I'm not aware of other sites that combine the Semantic Web and an easy tool (wiki) for creating family tree or ancestry sites. Using forms here and because of templates much of the underlying properties, or annotations are hidden from the users.

So, please check out this site:

http://jay.askren.net/Projects/SemWeb/

Let me know what you think about whether this should be discussed on any particular mailing list, such as the SMW list. I guess that would be most appropriate. Isn't there a list associated with this site?

Thanks,

Bruce

Brucewhealton 03:06, May 2, 2011 (UTC)BruceWhealton

KnolEdit

Knol is getting deleted by Google so if you want, you should log on and move your info to WordPress, it just takes one click to do it.


ReflistEdit

I have been trying to edit the template "reflist" so that it incorporates the html tag "small" so it goes dow to 9 point type from the standard. I can't seem to get it to work, can you help? Richard Arthur Norton I 15:25, January 11, 2012 (UTC)

Hi Phlox,

I have a question regarding:

http://familypedia.wikia.com/wiki/File:SJPan.jpg

Do you know the location where the beautiful shot was composed? I've been driving around the area, and I can't seem to find the proper elevation to get this shot.

Thanks,

Ray

99.147.148.121 06:34, February 9, 2013 (UTC)

Around Wikia's network

Random Wiki