Familypedia
Register
m (→‎Notes and sources: note about repeating elsewhere)
 
(24 intermediate revisions by 4 users not shown)
Line 2: Line 2:
   
 
<!-- Please put your content under this line. Be sure to sign your edits with four tildes: ~~~~ -->
 
<!-- Please put your content under this line. Be sure to sign your edits with four tildes: ~~~~ -->
  +
{{tocright}}
{{tocright}}'''Semantic mediawiki status''': Familypedia support is "pre-alpha". (Experimentation is welcome, but there may be radical changes). ''Users need not be concerned that their contributions will be wasted, since their articles will eventually be upgraded to the new format without loss of data.''
 
 
:'''''Archiving the first month of discussion; see [[/Archive 2009-05]].'''''
  +
:''See [[/Archive 2009-07/]] for most of the material that preceded the upgrading of most of the articles that used info pages.''
   
'''This page is intended to be the main question and discussion forum for [[Genealogy:Semantic MediaWiki]] (which has shortcut link: "[[SMW]]"). It is starting with copies of extracts from existing discussions. Please feel free to start new sections about specific pages on their talk pages, but please come here for at least a link back if the discussion broadens at all or if it might interest other contributors.
+
'''This page is intended to be the main question and discussion forum for [[Familypedia:Semantic MediaWiki]] (which has shortcut link: "[[SMW]]").''' (It started in May 2009 with with copies of extracts from existing discussions.) '''Please feel free to start new sections about specific pages on their talk pages, but please come here for at least a link back if the discussion broadens at all or if it might interest other contributors. '''
   
It is preferable not to have user-talk pages containing more than the briefest of question-and-answer dialog(ue) on SMW. If your question could interest two or more contributors, please put it here (with heading and edit summary both meaningful) then use user talk pages merely to tell your respondent(s) that the question is here.'''
+
'''It is preferable not to have user-talk pages containing more than the briefest of question-and-answer dialog(ue) on SMW. If your question could interest two or more contributors, please put it here (with heading and edit summary both meaningful) then use user talk pages merely to tell your respondent(s) that the question is here.'''
   
 
''Main information pages (list to grow as their number does)'':
 
''Main information pages (list to grow as their number does)'':
*[[Help:Semantic MediaWiki]]
+
*[[Help:Semantic MediaWiki]] and [[Help:Semantic forms]]
 
*[[Query]] (redirect)
 
*[[Query]] (redirect)
 
*[[Special:UnusedProperties|Unused properties]]
 
*[[Special:UnusedProperties|Unused properties]]
 
*[[User:Phlox/2009 05 notes]]
 
*[[User:Phlox/2009 05 notes]]
*[http://genealogy.wikia.com/index.php?title=Special%3AAllPages&from=&to=&namespace=303 Property talk pages]
+
*[http://family.wikia.com/index.php?title=Special%3AAllPages&from=&to=&namespace=303 Property talk pages]
*[http://genealogy.wikia.com/index.php?title=Special%3AAllPages&from=&to=&namespace=305 Type talk pages]
+
*[http://family.wikia.com/index.php?title=Special%3AAllPages&from=&to=&namespace=305 Type talk pages]
*[http://genealogy.wikia.com/index.php?title=Special%3AAllPages&from=&to=&namespace=307 Form talk pages]
+
*[http://family.wikia.com/index.php?title=Special%3AAllPages&from=&to=&namespace=307 Form talk pages]
*[http://genealogy.wikia.com/index.php?title=Special%3AAllPages&from=&to=&namespace=309 Concept talk pages]
+
*[http://family.wikia.com/index.php?title=Special%3AAllPages&from=&to=&namespace=309 Concept talk pages]
  +
*[[Special:SearchByProperty]] - basic search; try "Birth year" "1900" and play around with it
  +
----
  +
==Other forums touching on this subject==
  +
===Forms===
  +
*[[Forum:Do you use the forms?]]
  +
*[[Forum:No such special page]]
  +
*[[Forum:Problem with new person form]]
  +
*[[Forum:Links for People Pages]]
  +
*[[Forum:Converting a non-form page to an "Edit with form" page]]
  +
*[[Forum:Questions about forms]]
  +
*[[Forum:Where is tech support? - here, looking at our problem forms]]
  +
===Other===
  +
*[[Forum:Concepts]]
  +
*[[Forum:How we fix slow articles]]
  +
*[[Forum:SMW articles update]] - September 2009
  +
*[[Forum:Diagnostics]]
  +
*[[Forum:Factsbox off by default]]
  +
*[[Forum:SMW on Familypedia]]
 
----
 
----
 
:'''''Archiving the first month of discussion; see [[/Archive 2009-05]].'''''
 
 
 
==Summary of where we are at==
 
:''copied from a user talk page''
 
Currently, we are revising the way that we centrally store information, so everything you are learning about info pages and showinfo etc will be still work and all- it just will be obsolete. ... We will be encouraging people to use the new mechanism and be converting data over for them.
 
 
We are using semantic mediawiki extensions, something I believe that WP will eventually have. The new templates and properties are not yet ready for prime time, but if you are curious, you can see them demonstrated in article [[George Spencer Geer (1836)]] instead of the error prone process of editing info pages (a mechanism of my creation), the new scheme uses forms. See the edit with form item in the menu bar. This stores information directly in MySQL relations so that we can do databasey things like search for people born in location, with birth date greater than somedate and less than other date. This sort of thing is partly activated due to a hack I put into the info page mechanism. Those pages go away in the future, and pages more resemble those of the geer article. -[[User:Phlox|<span style="font-family:Trebuchet MS">''<font color="#0A9DC2">''~''</font>'''''&nbsp;<font color="#0DC4F2">Ph</font><font color="#3DD0F5">l</font><font color="#6EDCF7">o</font><font color="#9EE8FA">x</font>'''</span>]] 01:21, 1 June 2009 (UTC)
 
 
==Even clearer indication from Phlox==
 
:(Extracts from recent conversation on another forum)
 
 
:What I and other "followers" would like is an assurance that the info put into [[info page]]s will not be wasted but can be converted to SMW facts etc by a [[bot]] or similar automatic process. — [[User:Robin Patterson|Robin Patterson]] [[User talk:Robin Patterson|(Talk)]] 02:37, 14 June 2009 (UTC)
 
 
'''Nothing will be wasted, and info pages have given us a huge head start because the data is directly transferable'''. ... everything will be transferred over from info pages. ... Mind you, some of the info page values have been used in odd ways, such as place names in date fields. People ... will really want to correct these problems to get the most out of the SMW features.
 
 
William, I think you will see/find that form entry is vastly superior to the error-prone info pages method. And the volume and detail of information one can enter has been increased as well. What is particularly attractive is that when you are entering place names, the Familypedia will autocomplete the entry for you. So if a county name is in 3 different states, you will be made aware of that as you are typing in. This autocompletion is also active for all file and article fields, so there is no problem with typos as with info pages. '''Some of this stuff is working and you can create your own articles using [[Form:Person]]. People are welcome to try creating their own articles using it.''' Understand that it is under construction and it is not ready for prime time yet... .
 
 
'''Certainly if anyone would like to stay with the info pages, they are welcome to.''' The SMW can coexist perfectly well with info pages. Of course, contributors making that choice will not be able to access any of the new features such as a rich set of database queries, and dynamic categories. For example, one could have a table on one's Userpage that dynamically displays all changes to articles for all surnames the contributor is interested in since the last time the contributor logged in.
 
 
I think everyone will be pleased with the features that SMW will deliver for Familypedia. -[[User:Phlox|<span style="font-family:Trebuchet MS">''<font color="#0A9DC2">''~''</font>'''''&nbsp;<font color="#0DC4F2">Ph</font><font color="#3DD0F5">l</font><font color="#6EDCF7">o</font><font color="#9EE8FA">x</font>'''</span>]] 04:45, 14 June 2009 (UTC)
 
 
:I intend to start testing the forms on new Person articles soon. Will the conversion from info pages be done automatically at some time in the near future and will contributors who wish to stay with info pages (not me right now - I want to check out the forms first) be able to indicate that they don't want their articles converted? [[User:Animebill|Bill Hunsicker]] 05:27, 15 June 2009 (UTC)
 
*'''As Familypedia policy regarding bots''', all site wide automated conversions (this one included) take place only after there has been adequate public notice to the community and there has been opportunity for objections to be raised. To your question, the answer is yes- Contributors will have the opportunity to specify articles they have been the primary contributor on to opt out of this conversion phase. I shall provide details when we are closer to the conversion phase. Although a bot run could easily transfer all info pages in a few hours, the conversion will be gradual, rather than a single massive push. This will allow us to notice any shortcomings in the conversion, and more importantly, the SMW structures that they are being converted into.
 
*'''SMW is not in beta test yet''': Bill, I am glad you realize that this should be used for testing only at this point. The [[Form:Person]] may look polished, and the query pages may deliver interesting results but believe me, the SMW pages are very much a construction site with heavy equipment slamming into structures every now and then. If to fix something I need to rename some templates or parameters, that means any SMW test articles may partially break. For example, as thurstan noted last night, birth-state was recently renamed to birth-subdivision1. Well, that sort of thing is trivial to fix in test articles (just renaming a parameter in an article), but I don't have the time to go back and fix test articles other than the ones I use, so you are on your own until SMW goes into beta test. We simply aren't there yet, and if you want to use it as your primary input means that is fine, but understand that you may have to go back and fixup articles, so it is not for the faint of heart. There are enormous numbers of things to tweak, but at this point what we need to understand is if there are any major structural errors- like missing the capture of some information, how we are doing events, or multilingual, and so on.
 
*Regarding the timing of the conversion, I am in no big hurry and shall remain reluctant to do this until the structure is more tested and mature. I would have liked us to have a more complete geographic knowlegebase prior to the conversion, but I suppose we could do it as a post process cleanup by marking the origin of the smw pages and later going back to translate geographic names more properly. For instance, Greene county ->[[Greene County, Alabama]] rather than [[Greene County, Arkansas]]. In any case, we will need this database prior to going into beta, because while autocompletion sort of works now, it is using an unclean database that uses categories were never intended for this purpose- you get suggestions like map of XX county for a county name autocompletion. This geographic knowlegebase bot run shall not be modest and the main purpose is to generate autocompletion lists. A byproduct will be substantially more of the auxilliary articles on places. I figure we should have all villages and towns mentioned in wikipedia, not to mention the counties and subdivision1's.
 
::-[[User:Phlox|<span style="font-family:Trebuchet MS">''<font color="#0A9DC2">''~''</font>'''''&nbsp;<font color="#0DC4F2">Ph</font><font color="#3DD0F5">l</font><font color="#6EDCF7">o</font><font color="#9EE8FA">x</font>'''</span>]] 17:41, 15 June 2009 (UTC)
 
 
::I have created one test Person page ([[Abraham Hunsberger (1786-1860)]]) and although the page looks sparse compared to the info page I like the layout of what is there. I also created a Biography Template that works with the facts on this page. Thank you for your assistance with that. I think that I will create another page with a Person who has a family to see what that looks like. Otherwise, I will be patiently awaiting developments. [[User:Animebill|Bill Hunsicker]] 21:02, 15 June 2009 (UTC)
 
 
==More wonders==
 
I'm beginning to get the hang of this. See [[Descendants of Charlemagne (couples)]] for another demonstration of the powers of SMW. The same structure can be used to construct lists of, say, Franco-Italian couples. [[User:Rtol|rtol]] 09:42, 14 June 2009 (UTC)
 
 
==Listing in birth order==
 
Rtol will see that I have indeed looked at the abovementioned [[Descendants of Charlemagne (couples)]]. It lists children in birth order: great; but does that risk omitting some, or has that problem been fixed? — [[User:Robin Patterson|Robin Patterson]] [[User talk:Robin Patterson|(Talk)]] 14:07, 14 June 2009 (UTC)
 
 
:Children in birth order works fine. There are problems with the first column only. [[User:Rtol|rtol]] 18:32, 14 June 2009 (UTC)
 
==We are not in Beta test mode yet==
 
Observations on cosmetic improvements of course are are welcome, but the attention at this point is on isolating any required improvements to the structure of the data we are capturing.
 
 
Note also that [[Form:Person]] very intentionally at this point does not meet familypedia's requirements we had for the Person page and Simple page. A simple form will subsequently be derived from this exhaustive presentation. So folks shouldn't be alarmed that I am cramming a kitchen sink of properties that people may only rarely fill out into the Person form. (Just wait until I get to the genetic (YSTR mitochondrial DNA) subform- I'll bet we get only a few takers in the near term on that one). The goal is to push the envelope and specify classes of properties that potentially could require rethinking the basic structures. At some point when things are stable, we will present the simple forms as a default. The advanced/ expert mode forms will probably be implemented as something that appears when a CSS property is set- like how I showed Fred how to do red bars. People would copy a little value into their monaco.css and voila, they would always be presented expert forms rather than have to always click a link to get them. -[[User:Phlox|<span style="font-family:Trebuchet MS">''<font color="#0A9DC2">''~''</font>'''''&nbsp;<font color="#0DC4F2">Ph</font><font color="#3DD0F5">l</font><font color="#6EDCF7">o</font><font color="#9EE8FA">x</font>'''</span>]] 19:11, 15 June 2009 (UTC)
 
 
==Transition plans: some proposals==
 
(For background, see [[User talk:Phlox#More kids (redux)]]).
 
 
At present the template {{t|Set facts from info/family}}, which puts the list of children into an SMW property only handles the first 9 children in each group. This is unsatisfactory, because it means that all the planned features which depend on properties [[:Property:Ahnentafel|Ahnentafel]] and [[:Property:Descendants|Descendants]] will not work reliably across big families. On the other hand, we do not want to increase server load unduly. For a "normal" person page with an "/info" page, the present code retrieves the children twice: once for display, and once to load the properties. One solution is:
 
 
'''Proposal 1''': Take the "children" code out of {{t|Set facts from info/family}}, and modify {{t|Showinfo children}} so that it sets the property for each child as they are displayed.
 
 
''Discussion'': there would need to be a flag to make the "property setting" conditional, since {{t|Showinfo children}} is occasionally used to "show siblings". Since this is the much less common case, I propose that the default value for the flag should be "on". Note that (possibly at the expense of another flag) this change could also fix the case of the children being stored on the spouse's /info page.
 
 
Once we have started on this line of thought, we realize that {{t|Set facts from info/family}} retrieves other values which have already been displayed, so we have:
 
 
'''Proposal 2''': Modify {{t|Showinfo person}} so that it sets (most) of the values that is retrieves into the corresponding properties, leaving {{t|Set facts from info/family}} to handle just the values that are not displayed.
 
 
You may take it as read that I am volunteering to implement these proposals.
 
 
[[User:Thurstan|Thurstan]] 03:35, 16 June 2009 (UTC)
 
:Cool idea. You understand the need to minimize wikia server load, so I trust your judgement. One request: When you come across a field like baptism that could have both a date and a location, please stick it in street-address. They should display fine in showfacts person and we will automatically know that any values in those fields are likely from xferred infopages even if the marker category is dropped, and be able to post process them with bots. -[[User:Phlox|<span style="font-family:Trebuchet MS">''<font color="#0A9DC2">''~''</font>'''''&nbsp;<font color="#0DC4F2">Ph</font><font color="#3DD0F5">l</font><font color="#6EDCF7">o</font><font color="#9EE8FA">x</font>'''</span>]] 03:59, 16 June 2009 (UTC)
 
 
::Okay, though that's really "Proposal 2": I'll do the children first. [[User:Thurstan|Thurstan]] 04:14, 16 June 2009 (UTC)
 
 
:Well, I have done "Proposal 1" <small>(documentation still to be done)</small>. I will wait for the dust to settle before doing anything more. [[User:Thurstan|Thurstan]] 06:57, 16 June 2009 (UTC)
 
 
:::"Showinfo children" now assigns properties. Unfortunately, "showinfo children" is also used to show siblings (even though there is a template "showinfo siblings") so that siblings (and self) are listed as children and hence as descendants. Have a look at [[Floris I van Holland (1030-1061)]] who is his own father, grand-father, great-grand-father ... Amazing that the system has not blown up yet. 05:25, 18 June 2009 (UTC)
 
 
::::I foresaw that: you have to code <nowiki>{{Showinfo children|{{Get father}}|prop=}}</nowiki> to show siblings (and similarly in any other context where you don't want to set properties, like on documentation pages). The problem is, it is not easy to find instances where this is needed. Can we frame an SMW query to find the people who have become their own children? [[User:Thurstan|Thurstan]] 05:57, 18 June 2009 (UTC)
 
 
:::::Noted. I don't think this is a robust solution. We should just use {{t|Showinfo siblings}} if we want to show siblings.
 
:::::{{t|Show ancestors}} has a basic query on the descendants list. [[User:Rtol|rtol]] 06:00, 18 June 2009 (UTC)
 
 
:::::Trouble with {{t|Showinfo siblings}} was that its clever inventor forgot to tell the rest of us it existed. It is uncategorized and is linked from only one of his templates and a dozen individuals' pages, mostly Dutch. I'll substitute it on the info article template. — [[User:Robin Patterson|Robin Patterson]] [[User talk:Robin Patterson|(Talk)]] 11:41, 19 June 2009 (UTC)
 
 
::::::A search on "{{showinfo children|{{get father}}}}" finds well over a 500 pages. Rather than changing all of these, I would suggest that we change the template {{t|showinfo children}} back to what it what. {{t|info categories}} already adequately turns the children into properties anyway. [[User:Rtol|rtol]] 17:05, 25 June 2009 (UTC)
 
 
==More thoughts on "where are we going?"==
 
I notice a recent remark on converting [[User:yewenyi|yewenyi]]'s pages [I can't find it again just now: where did I see it?] got me thinking about "what are we going to do with all the existing pages that use "old" styles?". What is our "vision" for the "SMW" future? Will all pages use the "set facts" templates? See [[User_talk:Thurstan#Recent_changes_on_Kable_pages]] for a contributor asking me not to convert "his" pages to (my) "standard" form. I think the developers of SMW pictured a very simple usage which didn't involve lots of templates, and I think we could use it like that on some of the "old" pages: see what I have done with [[Alfred Edward Latter (1868-1952)‎]]. We could use this style on any pages using {{t|childbox}} and the old "simple person" model, and any other format that results in a "list of facts" (either in an infobox, or in the main text). [[User:Thurstan|Thurstan]] 03:58, 17 June 2009 (UTC)
 
:Actually I marked up just such an article a month ago in the same way. This led me to simplify the naming of the properties so that they would be easier for such inline use [[User:Phlox/2009_05_notes#SMW_does_not_mean_ancestors_are_reduced_to_statistics|background here]]. SMW doesn't care whether we use forms or not, or whether we even use templates. The "facts" properties can be used perfectly fine without a single template, and if lots of folks get excited about doing it that way, I won't argue with them. You of course are welcome to document that method, but I am skeptical of the reception. Philosophically, the SMW guys think in the same mode as the microformats crowd, that if you keep metadata inline with regular text that people will keep the information up to date because they are always looking at it. Wikipedia has an audience of contributors that have no trouble with wikitext and SMW like nerdy markup. Should we expect that the audience of folks interested in genealogies and family history will get over the Frankenstein reaction to text junked up with weird wikitext syntax and even weirder SMW property names? They may well wonder why they should bother putting any of those square brackets around dates or correctly labeling one as death date as opposed to the remains date. The inline thing syntax displays the date just fine. Also, they can make the date appear as they want. As with any square bracket syntax, the right hand operand is the format that is displayed. THey may not understand that SMW allows dates to be formatted according to the user's preferences, but only if the contributor does not use the right hand operand for display text. So ok- maybe they favor month first, or day first, or maybe they really really like YY/MM/DD format. But what the heck- it's a free world, right? Most folks will never get anywhere near this comfortable with wiki syntax and find wikitext baffling. The fact is, we have trouble attracting people to wikia for the very reason that even syntax that is much more simple than SMW declarations puts them off. SMW authors may run in a crowd of folks that have a high tolerance for wikitext like syntax, but typical folks do not. That is why wikia is going in the opposite direction- introducing an editor that further hides the complexity of such syntax. There is not much harm in offering thhis mode of entry, but we should be realistic. SMW syntax is not pretty and we can't dream that we can appeal only to folks comfortable with double colons and square brackets.
 
 
:The question "What are we going to do with all the "old styles" has been asked in various forms a long time before SMW appeared. Implicit in some people's phrasing of the question is that maybe it is a good idea from a kind of egalitarian point of view to have lots and lots of article styles. At the end of the day, this question of the multiple styles has nothing to do with SMW or any other technology for that matter. It has to do with polish- a common look and feel. From an editorial perspective, no other wikia of our size has anywhere near as disorganized a presentation of information, with such a bewildering mishmash of looks to the articles.
 
:My opinion is that the sooner Familypedia makes up its mind about a standard look and feel to articles, the better. I can sympathize that some folks will want to keep their little fiefdoms in one particular format. Well whatever- if 80% of our content would adhere to a common look, I think we will have made a great leap forward in establishing this as a quality site. This is the way wikipedia has gone, and it makes sense to settle on one common styleguide. -[[User:Phlox|<span style="font-family:Trebuchet MS">''<font color="#0A9DC2">''~''</font>'''''&nbsp;<font color="#0DC4F2">Ph</font><font color="#3DD0F5">l</font><font color="#6EDCF7">o</font><font color="#9EE8FA">x</font>'''</span>]] 07:08, 17 June 2009 (UTC)
 
 
::Thank you for your thoughts. I would like there to be a "standard" style, since I do often fiddle with "other people's" pages, and it would be easier if they all had a common infrastructure for the metadata (I know that this rather contradicts what I said above, but we can't all be consistent all the time!). [[User:Thurstan|Thurstan]] 07:22, 17 June 2009 (UTC)
 
:::Our edits crossed- there were updates to my prior note. It's a delicate line. You want folks contributing, so you don't want to irritate them by telling them they can't use the clever floral borders that really do look very professional and truly set their articles apart from those of others. Then there are guys that have been doing this for decades and you can't tell them anything about how to do a table with genealogy information. They made up their minds about that years ago and they will do it their way come hell or high water. Genealogy folks are an odd breed- I suppose Robin oftentimes feels like he is herding cats. It takes tack and diplomacy, something that the good father did not issue me in great quantities, so I am glad others are around to move us along towards a common standard. -[[User:Phlox|<span style="font-family:Trebuchet MS">''<font color="#0A9DC2">''~''</font>'''''&nbsp;<font color="#0DC4F2">Ph</font><font color="#3DD0F5">l</font><font color="#6EDCF7">o</font><font color="#9EE8FA">x</font>'''</span>]] 07:50, 17 June 2009 (UTC)
 
 
===Standardizing page look===
 
I agree with you chaps on the whole. And AMK152 was also keen on reducing the variety. Our only easily-found "simple" model includes in its introduction a suggestion that users might save time by choosing info pages (with a hint of the form/fact future). One move that might be easy is to see whether the "simple" page could be tweaked to look even more like the newer standard and maybe to vary its input parameters if they differ from the modern ones. That might facilitate later upgrading. — [[User:Robin Patterson|Robin Patterson]] [[User talk:Robin Patterson|(Talk)]] 14:44, 17 June 2009 (UTC)
 
 
:I, too, would like to see a standardized page look that can be easily modified to give contributors a feeling that they can "have it their way" while keeping things within a broad standard. Visitors will be confused and possibly put off if information is in radically different places on different pages. I have no strict preferences on page look as long as there is some uniformity so that visitors can easily find the information they are looking for. The main purpose of the Biography templates is to streamline the process of putting some kind of narrative on each of the pages with minimal effort. I would be happy to see ideas and improvements to the Biography templates to make them as great a value for Familypedia as possible. [[User:Animebill|Bill Hunsicker]] 02:01, 20 June 2009 (UTC)
 
 
==Improvements in forms and biography==
 
===Feedback on Robin's father-in-law's page===
 
See [[Talk:David Brian Carrad (1916-2003)]] for some notes about progress. — [[User:Robin Patterson|Robin Patterson]] [[User talk:Robin Patterson|(Talk)]] 01:03, 19 June 2009 (UTC)
 
 
==The Denobulan Gazette==
 
Here's the main news for the past few days:
 
*A method was discovered for reliably allowing wikitext in a property. Prior schemes would lock up the page when particular templates were used. This allows Description, Source and Notes properties to use standard wiki links and other markup. Note that complex templates like {{T|Citation}} may become translated internally into a subst'd form. I am not doing this- the Semantic Forms engine is doing it in order to protect SMW from potentially disruptive wikitext in properties. However, the value in the form retains its original form and may be edited normally. Use templates with caution and report any tricks or unusual problems to me. Citation in particular is very valuable for serious genealogists and use of its various forms should be encouraged in the Familypedia Manual of Style.
 
*The new page editor's interaction with typical Familypedia pages was investigated. The first huge problem is that we have large numbers of pages with embedded comments, and the new editor does not like them. I describe a method of using dummy templates in place of embedded comments at wikia central, but the developers may have support for comments [[wikipedia:real soon now|real soon now]]. In the meantime, all our standard template articles can't be edited in the new editor and default to the old. See other observations esp regarding their informal forms at [[w:Forum:New_editor#embedded_comments.2F_guidance_to_new_contributors|wikia central]].
 
*Some demonstration work was done with drilldown filters. See [http://genealogy.wikia.com/wiki/Special:BrowseData/Facts_articles-_person?_single Drilldown example for the trial articles]. I imagine our filtering will be more along the lines of the dynamically created gallery at [[The_Hague/1900-1919]] or query tables either static on a page, or generated from [http://genealogy.wikia.com/index.php?title=Special:Ask&offset=0&limit=20&q=%5B%5BBirth+street-address%3A%3AThe+Hague%5D%5D+OR+%5B%5BBirth+locality%3A%3AThe+Hague%5D%5D+OR+%5B%5BBirth+county%3A%3AThe+Hague%5D%5D+OR+%5B%5BBirth+subdivision1%3A%3AThe+Hague%5D%5D&p=format%3Dbroadtable&po=%3FSurname%0A%3FBirth+date%0A%3FDeath+subdivision1%3DDeath+state%0A&sort=Birth%20date&order=ASC the query page like this one] that is linked to via Births nav link in [[The Hague]] article. This is a showcase article for locations, similar to the showcase articles I use for persons- [[George Spencer Geer (1836)]] or [[Henry I, King of England (1068-1135)]] for stress tests and multilingual cases. It is not as fully developed as the person articles have taken precedence.
 
*PhloxBot did a run correcting a number of errors in the trial articles:
 
**Non existent parameters were deleted. There is no "Day" parameter. It is part of "date"
 
**Date parameters did not use the proper format. Script, Bot and template contributors may paste the following pattern for accurate translation from a wide variety of input formats. For instance, <nowiki>{{subst:#time:Y/m/d|12 May 1847}}</nowiki> converts to the required "1847/05/12".
 
**There is no "state" geographic unit anymore. The parameters now use the term "subdivision1" instead.
 
**Other random transformations none of which are particularly interesting.
 
 
Folks may wish to view their articles to see if anything got mucked up. They may require refresh's for changes to appear. -[[User:Phlox|<span style="font-family:Trebuchet MS">''<font color="#0A9DC2">''~''</font>'''''&nbsp;<font color="#0DC4F2">Ph</font><font color="#3DD0F5">l</font><font color="#6EDCF7">o</font><font color="#9EE8FA">x</font>'''</span>]] 18:24, 21 June 2009 (UTC)
 
 
:Template:Age (smw) has crashed in Template:Biography SMW on [[Abraham Hunsberger (1786-1860)]] but works on [[Jacob Kolb Detweiler (1763-1847)]]. Also, for some reason the biography is displaying twice on the page. Template:Age (smw) is also producing some strange results in Template:Biography on pages with info pages. See [[Samuel Hunsicker (1672-1717)]], [[Unknown Klemmer (1672-1717)]], [[Melchior Hunsicker (1645-1722)]], and [[Elizabeth Hunsicker (c1732-1789)]]. [[User:Animebill|Bill Hunsicker]] 01:01, 23 June 2009 (UTC)
 
::Thanks Bill. Abraham is working now. I cleaned up Image width but cleaned up too much from that article. Your Biography SMW thing is in the header for now. The header is a default thing for newbies and experience folks would just use the contents possibly removing biography if it was redundant to their own hand written bio. As for the info pages, these unfortunately only had partial data in the "birth date" and "death date" fields and Age (SMW) assumes full dates in those two fields. The info page versions have a single year in the SMW date fields. It is supposed to be YYYY/MM/DD or nothing at all. The thing that makes info pages (sort of) work with SMW needs more sophistication to generate more proper dates for {{T|age (smw)}} to work properly but that was not the goal of that scaffolding code. Anyway, the bot driven process would perform this conversion properly. -[[User:Phlox|<span style="font-family:Trebuchet MS">''<font color="#0A9DC2">''~''</font>'''''&nbsp;<font color="#0DC4F2">Ph</font><font color="#3DD0F5">l</font><font color="#6EDCF7">o</font><font color="#9EE8FA">x</font>'''</span>]] 05:12, 23 June 2009 (UTC)
 
 
==Ancestry autocat==
 
There is now a SMW-based {{t|Ancestry from Byzantium test}} that autocats same. It's part of {{t|info categories}}, and needs to be initialised at emigration. Easy to copy to other ancestries. I used "autocat" rather than "autoprop" because one can have multiple ancestries.
 
 
Would be cool if someone figures out how to replace the boring "Ancestry from Ireland" with the Irish flag. [[User:Rtol|rtol]] 13:30, 22 June 2009 (UTC)
 
 
:Nice idea in principle but inappropriate replacement unless you use a pre-1921 flag, because this wiki uses "Ireland" to mean the whole island. — [[User:Robin Patterson|Robin Patterson]] [[User talk:Robin Patterson|(Talk)]] 10:22, 24 June 2009 (UTC)
 
 
::A [[Image:SmallShamrock.png]] it is then [[User:Rtol|rtol]] 17:17, 24 June 2009 (UTC)
 
 
=="Edit this page" vs. "Edit with form"==
 
I checked out the SMW feature some time ago with my great-great-great grandfather, [[Thomas A. VanBuskirk (1848-1915)]]. I entered data on the form, looked at how it was displayed on the infobox, but I noticed there was no link to edit the form, like on [[George Spencer Geer (1836)]]'s article. How is this displayed? And in the future, what are we going to do about the "Edit this page" links? -[[User:AMK152|<font color="blue">AMK152</font>]]<sup>([[User talk:AMK152|talk]] • [[Special:Contributions/AMK152|contribs]]</sup>) 15:47, 29 June 2009 (UTC)
 
:It is unnecessary to manually copy paste stuff over from info pages. There is some scaffolding code which moves the data into properties. You can then remove the scaffolding template and subst in some code that will transfer the data to a page. This is a manual process for experimentation only. A real bot run would execute a more thorough check on values, since there is a '''lot''' of erroneously coded information on the info pages that needs more sophisticated code than what can be done practically in a template. If you'd like to try the manual method, see [[Template:Set_facts_from_info/doc#Converting_to_standard_smw_fields this documentation]]. To answer your question, you need to employ the showfacts family of templates on the page for the Edit with form menu item to appear. Examples may be found on the [[:Category:Facts articles- person]]. The header and footer templates are really for novice users, and would be included in a boilerplate preload page that the form uses for new articles. More sophisticated authors might like to delete the biographies template in the header and use their own, or rearrange the placement of sources sections that is performed in {{T|footer}}. -{{User:Phlox/Sig}} 21:04, 29 June 2009 (UTC)
 
 
::The other thing about the "edit with form" option is that I have found it not appearing until after a couple of saves after the templates have been put in. [[User:Thurstan|Thurstan]] 21:52, 3 July 2009 (UTC)
 
 
 
==Order of listing person articles==
 
I wonder whether some of our recent work is losing or neglecting the DEFAULTSORT function. Have a look at http://genealogy.wikia.com/wiki/Special:BrowseData/Facts_articles-_person?_single and see all the Catherines and Dorothys listed under surnames. Are they or should they be the exception - or the rule? Is their listing there determined by anything to do with SMW? — [[User:Robin Patterson|Robin Patterson]] [[User talk:Robin Patterson|(Talk)]] 04:49, 3 July 2009 (UTC)
 
:Uh. "Be bold?" Why not just fix it? Thurstan and Rtol are not timid about it and have made several improvements. {{User:Phlox/Sig}} 16:59, 3 July 2009 (UTC)
 
 
==Report from the Medical labs==
 
It is not at all obvious what the nature of the progress in the Phlox laboritories has been, but there has been some very good news in the past few days that ought to be reported.
 
#A way was developed to eliminate the double flush thing for typical users (I assume that the mass of typical users will use forms). Folks doing automated stuff may have problems due the way #declare works, but maybe if that is the source of the difficulty I will just eliminate use of #declare.
 
#There was success with forms component transculsion experiments. This means the localization nut has been cracked, and I also have a way to share code between detailed forms, an EZ form, and the kitchen sink form. (The current Form:Person represents the kitchen sink- to be replaced with an ultra simplified EZ form. Folks that want to enter more esoteric data will be invited to open more detailed forms or to go to the kitchen sink version.)
 
#A second optimization point is that we now have a way of cutting RTE edit load time down from 45+ seconds to the typical 3-5 seconds that it takes for articles with no fancy templates.
 
 
These changes will take quite a few days to fully manifest in code. {{User:Phlox/Sig}} 21:10, 6 July 2009 (UTC)
 
   
 
==Categories==
 
==Categories==
Line 167: Line 49:
 
::::I'd say we make a decision soon to speed up the servers. [[User:Rtol|rtol]] 10:42, 9 July 2009 (UTC)
 
::::I'd say we make a decision soon to speed up the servers. [[User:Rtol|rtol]] 10:42, 9 July 2009 (UTC)
 
::By the way, there are substantial Wikipedia categories that we may like to keep as categories in order to avoid constant translation back and forth between our content and theirs. I can see this might be the case with certain geographic categories that are necessary for familypedia's functioning, but do not represent our core content. {{User:Phlox/Sig}} 17:33, 9 July 2009 (UTC)
 
::By the way, there are substantial Wikipedia categories that we may like to keep as categories in order to avoid constant translation back and forth between our content and theirs. I can see this might be the case with certain geographic categories that are necessary for familypedia's functioning, but do not represent our core content. {{User:Phlox/Sig}} 17:33, 9 July 2009 (UTC)
  +
==="Concept" (nee Category) Navigation===
 
In place of the jumble of categories at the bottom of a person page, we possibly will we want to have a collapsible navbox that organizes Concepts thematically. EG-The births box in the following collapsible navbox would have a table like the one below with each bullet point linking to a concept page with the stated contents.
 
In place of the jumble of categories at the bottom of a person page, we possibly will we want to have a collapsible navbox that organizes Concepts thematically. EG-The births box in the following collapsible navbox would have a table like the one below with each bullet point linking to a concept page with the stated contents.
 
{{Navbox
 
{{Navbox
Line 233: Line 116:
 
*The concept statement text can be hidden with a span display none statement. For an example, see [[Concept:Born in New South Wales]].
 
*The concept statement text can be hidden with a span display none statement. For an example, see [[Concept:Born in New South Wales]].
 
{{User:Phlox/Sig}} 02:40, 15 July 2009 (UTC)
 
{{User:Phlox/Sig}} 02:40, 15 July 2009 (UTC)
  +
  +
:I agree. I would show only three columns (by date, by location, by surname) rather than six or seven ((by date, by location, by surname, by date and location, by data and surname, by location and surname, by data location and surname). [[User:Rtol|rtol]] 04:45, 15 July 2009 (UTC)
  +
::That's fine since we have 10K odd persons total. I am projecting out a few more chess moves. If World Connect has a couple million names, and it is not an exaggeration to expect we will be doing the same, then it's not hard to see that our visitors will have a hard time keeping up with the 10s of thousands of Jonses without the ability to narrow the search sets down considerably. Tables like this is one UI way of narrowing. Perhaps we will do a sidebar selector. That's a pretty familiar method- eg Google where you just check off some boxes. IMHO we shouldn't trouble our visitors with the fact that they are querying a database. Wikipedia users certainly aren't interested that this is what they are doing on every page view. Not sure why we should expect our visitors to be weighed down with jargon that has no value to them. {{User:Phlox/Sig}} 08:52, 16 July 2009 (UTC)
  +
:::I stand corrected. Three basic columns with four hideable ones would be a good solution. [[User:Rtol|rtol]] 09:08, 16 July 2009 (UTC)
  +
  +
===Categories are not multilingual. Concepts are===
  +
Note also that the restriction that all categories be in English is now bypassed by Concepts. Concepts can be in any language and retrieve the exact same results as the English category or concept. For example, [[Concept:Mort en Austrasie (.fr)]] and [[Concept:Died in Austrasia]]. {{User:Phlox/Sig}} 08:52, 16 July 2009 (UTC)
   
 
==Info Categories slowdowns==
 
==Info Categories slowdowns==
Line 239: Line 129:
 
Of general interest to SMW users is one possible generalized solution to these sorts of computationally intensive projects. Familypedia wants to welcome these features, while not slowing down the browsing experience of visitors to the site. One way we could do this is to ask such projects to create a subpage to the main article where the calculations can then be made. Genealogical relationships present problems most of which require [[wikipedia:Exponential time|exponential explosions of time]] for calculation. What does this mean in laymans terms? It means that calculating descendants is 2 times the cost of the first, then four times (2^2) for the next generation, then eight (2^3), 2^4, 2^5 and so on. You get out to 16 generations and the calculation is potentially 65,000 times slower than the first generation calculation. Although most everyone's tree of known descendants is typically more sparse, and there are nowhere near this number of operations, these calculations tend to get progressively slower for each added generation. This applies to other kinds of family history relationships such as for [[wikipedia:Six degrees of separation|Six degrees of separation]]/ "human web" type features- For example, "My great great, great grandfather was best friends with your great great grandfather". Anyway, if such calculations are performed at times other than when the viewer is looking at the main article, this calculation penalty is substantially reduced. The researcher then may add time consuming calculations without being constrained by concerns of community objections about article rendering speed. Only viewers of that particular project page would experience the slowdown. {{User:Phlox/Sig}} 16:44, 10 July 2009 (UTC)
 
Of general interest to SMW users is one possible generalized solution to these sorts of computationally intensive projects. Familypedia wants to welcome these features, while not slowing down the browsing experience of visitors to the site. One way we could do this is to ask such projects to create a subpage to the main article where the calculations can then be made. Genealogical relationships present problems most of which require [[wikipedia:Exponential time|exponential explosions of time]] for calculation. What does this mean in laymans terms? It means that calculating descendants is 2 times the cost of the first, then four times (2^2) for the next generation, then eight (2^3), 2^4, 2^5 and so on. You get out to 16 generations and the calculation is potentially 65,000 times slower than the first generation calculation. Although most everyone's tree of known descendants is typically more sparse, and there are nowhere near this number of operations, these calculations tend to get progressively slower for each added generation. This applies to other kinds of family history relationships such as for [[wikipedia:Six degrees of separation|Six degrees of separation]]/ "human web" type features- For example, "My great great, great grandfather was best friends with your great great grandfather". Anyway, if such calculations are performed at times other than when the viewer is looking at the main article, this calculation penalty is substantially reduced. The researcher then may add time consuming calculations without being constrained by concerns of community objections about article rendering speed. Only viewers of that particular project page would experience the slowdown. {{User:Phlox/Sig}} 16:44, 10 July 2009 (UTC)
   
:{{t:Show VIA}} is a simple query. This does not slow down anything. [[User:Rtol|rtol]] 07:51, 12 July 2009 (UTC)
+
:{{t|Show VIA}} is a simple query. This does not slow down anything. [[User:Rtol|rtol]] 07:51, 12 July 2009 (UTC)
  +
  +
'''UPDATE: the said subpage was introduced shortly after the above discussion. See [[Help:Sensor page]].''' — [[User:Robin Patterson|Robin Patterson]] [[User talk:Robin Patterson|(Talk)]] 04:43, May 31, 2010 (UTC)
  +
  +
==Ancestors and descendants==
  +
Note that the lists of ancestors and descendants are becoming too large for some people. This means that the pages of these people behave in peculiar ways. Working on it. [[User:Rtol|rtol]] 07:27, 20 July 2009 (UTC)
  +
  +
:Solved, actually, already a while ago. [[User:Rtol|rtol]] 19:54, 4 August 2009 (UTC)
  +
  +
==Questions==
  +
Sorry for the many questions, but I'm getting very confused here.
  +
Q: So when we use SMW, we won't need info pages? -[[User:AMK152|<font color="blue">AMK152</font>]]<sup>([[User talk:AMK152|talk]] • [[Special:Contributions/AMK152|contribs]]</sup>) 02:39, 3 August 2009 (UTC)
  +
:A: We won't "need" them, but it is up to the community to keep using them if they wish. My opinion is that there is no justification for their continued existence and that they should be phased out entirely. -Phlox
  +
Q: Will all the information just be stored on the page using the templates that are generated from using form data? -[[User:AMK152|<font color="blue">AMK152</font>]]<sup>([[User talk:AMK152|talk]] • [[Special:Contributions/AMK152|contribs]]</sup>) 02:39, 3 August 2009 (UTC)
  +
:A:Yes, although the templates can be used separately from the forms, and edited directly as one edits infobox parameters -Phlox
  +
Q:Since it's hard for me to load the form page on my computer, will I be able to edit just using the templates without messing up the page? -[[User:AMK152|<font color="blue">AMK152</font>]]<sup>([[User talk:AMK152|talk]] • [[Special:Contributions/AMK152|contribs]]</sup>) 02:39, 3 August 2009 (UTC)
  +
:A: Yep, that is what Thurstan has been doing. I'm not sure he even knows what the forms look like. -Phlox
  +
  +
Q: I read somewhere about the possibility of a search feature once the SMW system gets going. Will this allow us to eliminate some of the categories? If so, which ones? -[[User:AMK152|<font color="blue">AMK152</font>]]<sup>([[User talk:AMK152|talk]] • [[Special:Contributions/AMK152|contribs]]</sup>) 02:39, 3 August 2009 (UTC)
  +
:A: We will be able to eliminate most of the categories we use for narrowing down subjects. EG: Born in London, Births/ Deaths/ Marriage/ <you name the event> in the 1910s.... This uses an SMW "Concept" which at this point not much more than a fancy term for "persistent query". Technically, a Category is itself a persistent query. Concepts expose the ability to make aggregate categories from constituent parts. For example, [[Concept:Born in the 1750s]] creates a Category like list. The major visible difference is that it is a flat list- there are no subcategories. This particular concept is formed by querying a single property, but a concept listing may use categories as well in combination with properties ([http://semantic-mediawiki.org/wiki/Help:Selecting_pages docs on queries here]. The advantage of this is that people don't have to write a template that is used in every single article to create a new "category". Maybe some bloke is interested in ancestors born in Greene county, Ohio in the 1860s. With a single like expression, he would have this on a concept page. I am of the opinion that the Navboxes I created for places will be upgraded to link to these sorts of concept pages. They could also be used to link to direct queries. An example of direct queries instead of concepts may be found in the navbox for [[The Hague]] article. Click on Births or Deaths. I am not happy with this design for a couple of reasons, but it is another option for an alternative to how we were formerly using info categories, and the combinatorial problem we were sort of hoping would go away.
  +
  +
Q: Once the SMW system for creating people pages is ready to be used on a large scale, will the quality of the resulting articles be as good as it was with the info page system? -[[User:AMK152|<font color="blue">AMK152</font>]]<sup>([[User talk:AMK152|talk]] • [[Special:Contributions/AMK152|contribs]]</sup>) 02:39, 3 August 2009 (UTC)
  +
:A:Much better. But it isn't at all ready yet, and it is fair for folks to be skeptical about how soon it will be ready and/or how desirable it will be when the real (as opposed to promised) features can be examined. At the risk of belaboring a point I have repeated often, I must emphasize folks should not hold their breath thinking that the SMW replacement of info pages are just around the corner and there is no reason to create info pages. Info pages work now, and articles using them will convert directly over to SMW articles without much effort so everyone should just behave as SMW didn't exist. Folks are welcome to use the provisional SMW code that has been created, with the understanding that it is in a pre-alpha state subject to wild changes in configuration that could break articles. SMW forms and articles may appear to be polished but in fact the underlying design is undergoing substantial changes that will affect how useful they are as Familypedia grows to significant dimensions.
  +
  +
:There are a number of limitations of the Info page system that are blown away by SMW pages, not the least of these is performance cost. I put many optimizations in when I built Info Pages, but they are inherently slow because they are entirely implemented in templates. From an engineering perspective, the key is that since indirection is extremely cheap, the expressive power is significantly greater. That the core reason that SMW utterly leave info pages in the dust. Does this make categories obsolete? No. We need them for compatibility with imported WP articles, and there are some esoteric techniques that require the use of categories. For example, a category like [[:Category:Valid name- locality]] will be needed for autocompletion in SMW forms. This is because autocompletion can use values from subcats if a category is used.
  +
  +
:As usual, I have probably given too much information. Just try creating some Concepts, and I think it will become clear why the way we were doing info categories is no longer necessary. [http://semantic-mediawiki.org/wiki/Help:Concepts the docs are here]. {{User:Phlox/Sig}} 17:47, 3 August 2009 (UTC)
  +
  +
::I think Phlox is too modest. SMW works better, is more finished and is more stable than one would get from the answers above. It is also downward compatible with info pages (but not with older formats). [[User:Rtol|rtol]] 15:37, 4 August 2009 (UTC)
  +
:Right. The limitations I was speaking about are not those of the SMW extensions, but of the so called "facts pages" family of templates I have been working on since May as a comprehensive replacement to the "info page" family of templates. Sometimes the two get associated but folks are free to use SMW features as they wish separate from the way facts pages use the features. Rtol's ancestor and descendants templates in fact do just that. {{User:Phlox/Sig}} 17:51, 4 August 2009 (UTC)
  +
  +
::Exactly. While we may change the source of the information about "mother", and may introduce aliases like "Mutter" and "mere", Property:Mother is stable and <nowiki>{{getfact|mother}}</nowiki> is a lot quicker than <nowiki>{{get|key=mother}}</nowiki>. Similarly, Property:Surname is a lot more versatile than Category: (surname). [[User:Rtol|rtol]] 19:49, 4 August 2009 (UTC)
  +
  +
'''UPDATE: most of the 7,000-odd info pages were worked on a few months after the above discussion, not being changed themselves but producing sensor subpages. The articles were put in a category indicating the upgrade. Some quirks can be manually adjusted. For example, most of the places were collected in a box at the bottom of each place section rather than being assigned to "Locality", "County", etc. They appear in quote marks in the infoboxes. Just move into correct field boxes when editing with the form.
  +
  +
==Notes and sources==
  +
The form format leads people to think that what they put in the "sources" box will be displayed separately from what they put in the "notes" box. It isn't; and that can lead to some absurd display results, e.g. at [[William Gibson Patterson (1915-1974)]].
  +
  +
I can see that there would be more complex coding (and potentially far more headings - or twice as many labels - on the display) needed to give sources and notes separate headings. Right now they have no headings! (That's for the last few weeks. Also, as noted elsewhere, the explanatory notes or symbols to the left are replaced with unhelpful link-like things.)
  +
  +
Before anyone goes to too much trouble to restore the heading, let's discuss options.
  +
#Give them separate headings despite the extra coding; and put "sources" first in every part of the forms, as they are for "children", and in the displays.
  +
#Combine them into one box on the form, so that users realise that sources need some distinguishing word(s).
  +
  +
--- Robin Patterson ([[User talk:Robin Patterson|Talk to me]]) 12:19, April 1, 2011 (UTC)
  +
  +
Nobody has answered this here. So I've created a separate [[Forum:Person notes and sources]]. -- [[User:Robin Patterson|Robin Patterson]] ([[User talk:Robin Patterson|Talk]]) 13:42, January 3, 2012 (UTC)
  +
  +
==N-ary properties==
  +
N-ary properties have been re-enabled. That means that ancestor and descendant lists work again, and all the properties that derive from those (particularly inbreeding). 10:36, June 1, 2011 (UTC)
  +
 
:Good work, whoever! -- [[User:Robin Patterson|Robin Patterson]] ([[User talk:Robin Patterson|Talk]]) 04:19, June 2, 2011 (UTC)

Latest revision as of 13:42, 3 January 2012

Forums: Index > Help desk > SMW


Forums: Index > Watercooler > SMW


Archiving the first month of discussion; see /Archive 2009-05.
See /Archive 2009-07/ for most of the material that preceded the upgrading of most of the articles that used info pages.

This page is intended to be the main question and discussion forum for Familypedia:Semantic MediaWiki (which has shortcut link: "SMW"). (It started in May 2009 with with copies of extracts from existing discussions.) Please feel free to start new sections about specific pages on their talk pages, but please come here for at least a link back if the discussion broadens at all or if it might interest other contributors.

It is preferable not to have user-talk pages containing more than the briefest of question-and-answer dialog(ue) on SMW. If your question could interest two or more contributors, please put it here (with heading and edit summary both meaningful) then use user talk pages merely to tell your respondent(s) that the question is here.

Main information pages (list to grow as their number does):


Other forums touching on this subject[]

Forms[]

Other[]


Categories[]

After SMW and the forms are implemented into people articles, what categories are we getting rid of and what categories are we keeping? -AMK152(talkcontribs) 21:44, 7 July 2009 (UTC)

That's a community choice. A property generally can do everything a category can do plus a bit more. There are some limitations though. Properties are generally nicer than properties because they are expressed as a flat list and contributors don't have to go poking around in sub cats and sub sub cats to find all the hits. However, while the query engine understands super properties (that is, you can search on death location because death county is a subprop of death location), it has can't be used for the things you would have thought you could. If you want to tell a form to autocomplete using a property, then it doesn't use the subproperties (as of the time of this writing)- just the values that encode using that specific property. For this reason, if we have a placename hierarchy tree of valid place names and their relationship to each other (this would be derived from wikipedia for all languages), it would have to be a category if you wanted to use it for the autocomplete feature in sematic forms. However, if it turns out that we don't need to force people to know the classification of placenames, then this would be a flat namespace and we could as easily use a property. Sorry for the slightly off topic remarks, but I know you were interested in various containment hierarchies earlier and although I was going that direction, I am thinking we may want to make it much simpler for the user. So long as they use disambiguated Wikipedia names, we can derive the containment hierarchy- and we don't need to force them to know obscure stuff like the fact that Moscow as a "Federal city" is actually a subdivision1.
The short answer is that we are probably going to turn all the Married in/ Born in cats that used to be generated by {{info categories}} into properties and "concepts". ~ Phlox 01:05, 8 July 2009 (UTC)
Ditto for surnames. No need to categorize them anymore. Variations of names and noble houses can be concepts. I would argue that we should also create a property with the surname of the partner. rtol 07:07, 8 July 2009 (UTC)
I'd say we make a decision soon to speed up the servers. rtol 10:42, 9 July 2009 (UTC)
By the way, there are substantial Wikipedia categories that we may like to keep as categories in order to avoid constant translation back and forth between our content and theirs. I can see this might be the case with certain geographic categories that are necessary for familypedia's functioning, but do not represent our core content. ~ Phlox 17:33, 9 July 2009 (UTC)

"Concept" (nee Category) Navigation[]

In place of the jumble of categories at the bottom of a person page, we possibly will we want to have a collapsible navbox that organizes Concepts thematically. EG-The births box in the following collapsible navbox would have a table like the one below with each bullet point linking to a concept page with the stated contents.

Births crossreferences
By date Jones births by date Births in NSW by date Jones births by location
  • 19th century
    • 1870s
      • 1876
  • 19th cent. Jones
    • 1870s Jones
      • 1876 Jones
  • 18th century births in New South Wales
    • 1870s births in New South Wales
      • 1876 births in New South Wales
  • Jones births in Australia
    • Jones births in New South Wales
      • Jones births in Sydney
  • This navbox would also contain a default sort statement, since as you will notice Concept pages otherwise will sort by the title of the person articles (first name order).
  • Concept pages hold 200 pages at a time, as with categories.
  • The concept statement text can be hidden with a span display none statement. For an example, see Concept:Born in New South Wales.

~ Phlox 02:40, 15 July 2009 (UTC)

I agree. I would show only three columns (by date, by location, by surname) rather than six or seven ((by date, by location, by surname, by date and location, by data and surname, by location and surname, by data location and surname). rtol 04:45, 15 July 2009 (UTC)
That's fine since we have 10K odd persons total. I am projecting out a few more chess moves. If World Connect has a couple million names, and it is not an exaggeration to expect we will be doing the same, then it's not hard to see that our visitors will have a hard time keeping up with the 10s of thousands of Jonses without the ability to narrow the search sets down considerably. Tables like this is one UI way of narrowing. Perhaps we will do a sidebar selector. That's a pretty familiar method- eg Google where you just check off some boxes. IMHO we shouldn't trouble our visitors with the fact that they are querying a database. Wikipedia users certainly aren't interested that this is what they are doing on every page view. Not sure why we should expect our visitors to be weighed down with jargon that has no value to them. ~ Phlox 08:52, 16 July 2009 (UTC)
I stand corrected. Three basic columns with four hideable ones would be a good solution. rtol 09:08, 16 July 2009 (UTC)

Categories are not multilingual. Concepts are[]

Note also that the restriction that all categories be in English is now bypassed by Concepts. Concepts can be in any language and retrieve the exact same results as the English category or concept. For example, Concept:Mort en Austrasie (.fr) and Concept:Died in Austrasia. ~ Phlox 08:52, 16 July 2009 (UTC)

Info Categories slowdowns[]

Rtol has been working hard on a feature implemented using SMW that allows Familypedia to display things like very important ancestors automatically in all articles on descendants. There has been objection that these computations make the general article on individuals too slow. The discussion of this issue is on the Info categories talk page, for details on how that issue is resolved, contributors are invited to contribute their opinions there.

Of general interest to SMW users is one possible generalized solution to these sorts of computationally intensive projects. Familypedia wants to welcome these features, while not slowing down the browsing experience of visitors to the site. One way we could do this is to ask such projects to create a subpage to the main article where the calculations can then be made. Genealogical relationships present problems most of which require exponential explosions of time for calculation. What does this mean in laymans terms? It means that calculating descendants is 2 times the cost of the first, then four times (2^2) for the next generation, then eight (2^3), 2^4, 2^5 and so on. You get out to 16 generations and the calculation is potentially 65,000 times slower than the first generation calculation. Although most everyone's tree of known descendants is typically more sparse, and there are nowhere near this number of operations, these calculations tend to get progressively slower for each added generation. This applies to other kinds of family history relationships such as for Six degrees of separation/ "human web" type features- For example, "My great great, great grandfather was best friends with your great great grandfather". Anyway, if such calculations are performed at times other than when the viewer is looking at the main article, this calculation penalty is substantially reduced. The researcher then may add time consuming calculations without being constrained by concerns of community objections about article rendering speed. Only viewers of that particular project page would experience the slowdown. ~ Phlox 16:44, 10 July 2009 (UTC)

{{Show VIA}} is a simple query. This does not slow down anything. rtol 07:51, 12 July 2009 (UTC)

UPDATE: the said subpage was introduced shortly after the above discussion. See Help:Sensor page.Robin Patterson (Talk) 04:43, May 31, 2010 (UTC)

Ancestors and descendants[]

Note that the lists of ancestors and descendants are becoming too large for some people. This means that the pages of these people behave in peculiar ways. Working on it. rtol 07:27, 20 July 2009 (UTC)

Solved, actually, already a while ago. rtol 19:54, 4 August 2009 (UTC)

Questions[]

Sorry for the many questions, but I'm getting very confused here. Q: So when we use SMW, we won't need info pages? -AMK152(talkcontribs) 02:39, 3 August 2009 (UTC)

A: We won't "need" them, but it is up to the community to keep using them if they wish. My opinion is that there is no justification for their continued existence and that they should be phased out entirely. -Phlox

Q: Will all the information just be stored on the page using the templates that are generated from using form data? -AMK152(talkcontribs) 02:39, 3 August 2009 (UTC)

A:Yes, although the templates can be used separately from the forms, and edited directly as one edits infobox parameters -Phlox

Q:Since it's hard for me to load the form page on my computer, will I be able to edit just using the templates without messing up the page? -AMK152(talkcontribs) 02:39, 3 August 2009 (UTC)

A: Yep, that is what Thurstan has been doing. I'm not sure he even knows what the forms look like. -Phlox

Q: I read somewhere about the possibility of a search feature once the SMW system gets going. Will this allow us to eliminate some of the categories? If so, which ones? -AMK152(talkcontribs) 02:39, 3 August 2009 (UTC)

A: We will be able to eliminate most of the categories we use for narrowing down subjects. EG: Born in London, Births/ Deaths/ Marriage/ <you name the event> in the 1910s.... This uses an SMW "Concept" which at this point not much more than a fancy term for "persistent query". Technically, a Category is itself a persistent query. Concepts expose the ability to make aggregate categories from constituent parts. For example, Concept:Born in the 1750s creates a Category like list. The major visible difference is that it is a flat list- there are no subcategories. This particular concept is formed by querying a single property, but a concept listing may use categories as well in combination with properties (docs on queries here. The advantage of this is that people don't have to write a template that is used in every single article to create a new "category". Maybe some bloke is interested in ancestors born in Greene county, Ohio in the 1860s. With a single like expression, he would have this on a concept page. I am of the opinion that the Navboxes I created for places will be upgraded to link to these sorts of concept pages. They could also be used to link to direct queries. An example of direct queries instead of concepts may be found in the navbox for The Hague article. Click on Births or Deaths. I am not happy with this design for a couple of reasons, but it is another option for an alternative to how we were formerly using info categories, and the combinatorial problem we were sort of hoping would go away.

Q: Once the SMW system for creating people pages is ready to be used on a large scale, will the quality of the resulting articles be as good as it was with the info page system? -AMK152(talkcontribs) 02:39, 3 August 2009 (UTC)

A:Much better. But it isn't at all ready yet, and it is fair for folks to be skeptical about how soon it will be ready and/or how desirable it will be when the real (as opposed to promised) features can be examined. At the risk of belaboring a point I have repeated often, I must emphasize folks should not hold their breath thinking that the SMW replacement of info pages are just around the corner and there is no reason to create info pages. Info pages work now, and articles using them will convert directly over to SMW articles without much effort so everyone should just behave as SMW didn't exist. Folks are welcome to use the provisional SMW code that has been created, with the understanding that it is in a pre-alpha state subject to wild changes in configuration that could break articles. SMW forms and articles may appear to be polished but in fact the underlying design is undergoing substantial changes that will affect how useful they are as Familypedia grows to significant dimensions.
There are a number of limitations of the Info page system that are blown away by SMW pages, not the least of these is performance cost. I put many optimizations in when I built Info Pages, but they are inherently slow because they are entirely implemented in templates. From an engineering perspective, the key is that since indirection is extremely cheap, the expressive power is significantly greater. That the core reason that SMW utterly leave info pages in the dust. Does this make categories obsolete? No. We need them for compatibility with imported WP articles, and there are some esoteric techniques that require the use of categories. For example, a category like Category:Valid name- locality will be needed for autocompletion in SMW forms. This is because autocompletion can use values from subcats if a category is used.
As usual, I have probably given too much information. Just try creating some Concepts, and I think it will become clear why the way we were doing info categories is no longer necessary. the docs are here. ~ Phlox 17:47, 3 August 2009 (UTC)
I think Phlox is too modest. SMW works better, is more finished and is more stable than one would get from the answers above. It is also downward compatible with info pages (but not with older formats). rtol 15:37, 4 August 2009 (UTC)
Right. The limitations I was speaking about are not those of the SMW extensions, but of the so called "facts pages" family of templates I have been working on since May as a comprehensive replacement to the "info page" family of templates. Sometimes the two get associated but folks are free to use SMW features as they wish separate from the way facts pages use the features. Rtol's ancestor and descendants templates in fact do just that. ~ Phlox 17:51, 4 August 2009 (UTC)
Exactly. While we may change the source of the information about "mother", and may introduce aliases like "Mutter" and "mere", Property:Mother is stable and {{getfact|mother}} is a lot quicker than {{get|key=mother}}. Similarly, Property:Surname is a lot more versatile than Category: (surname). rtol 19:49, 4 August 2009 (UTC)

UPDATE: most of the 7,000-odd info pages were worked on a few months after the above discussion, not being changed themselves but producing sensor subpages. The articles were put in a category indicating the upgrade. Some quirks can be manually adjusted. For example, most of the places were collected in a box at the bottom of each place section rather than being assigned to "Locality", "County", etc. They appear in quote marks in the infoboxes. Just move into correct field boxes when editing with the form.

Notes and sources[]

The form format leads people to think that what they put in the "sources" box will be displayed separately from what they put in the "notes" box. It isn't; and that can lead to some absurd display results, e.g. at William Gibson Patterson (1915-1974).

I can see that there would be more complex coding (and potentially far more headings - or twice as many labels - on the display) needed to give sources and notes separate headings. Right now they have no headings! (That's for the last few weeks. Also, as noted elsewhere, the explanatory notes or symbols to the left are replaced with unhelpful link-like things.)

Before anyone goes to too much trouble to restore the heading, let's discuss options.

  1. Give them separate headings despite the extra coding; and put "sources" first in every part of the forms, as they are for "children", and in the displays.
  2. Combine them into one box on the form, so that users realise that sources need some distinguishing word(s).
--- Robin Patterson (Talk to me) 12:19, April 1, 2011 (UTC)

Nobody has answered this here. So I've created a separate Forum:Person notes and sources. -- Robin Patterson (Talk) 13:42, January 3, 2012 (UTC)

N-ary properties[]

N-ary properties have been re-enabled. That means that ancestor and descendant lists work again, and all the properties that derive from those (particularly inbreeding). 10:36, June 1, 2011 (UTC)

Good work, whoever! -- Robin Patterson (Talk) 04:19, June 2, 2011 (UTC)