User talk:David Yamakuchi

Welcome!

Welcome to the Citizendium! We hope you will contribute boldly and well. You'll probably want to know how to get started as an author. Just look at CZ:Getting Started for other helpful "startup" links, and CZ:Home for the top menu of community pages. Be sure to stay abreast of events via the Citizendium-L (broadcast) mailing list (do join!) and the blog. Please also join the workgroup mailing list(s) that concern your particular interests. You can test out editing in the sandbox if you'd like. If you need help to get going, the forums is one option. That's also where we discuss policy and proposals. You can ask any constable for help, too. Me, for instance! Just put a note on their "talk" page. Again, welcome and have fun! Dan Nachbar 08:52, 29 December 2007 (CST)

Hi David

Regarding this, to get new content-area workgroups going, go to CZ:New Workgroup Requests. What's going to happen in the near future is that a whole bunch of new workgroups are going to be created all at once. There'll probably be a community-wide call, discussion, and then I think all the new ones that emerge are going to the editorial council for a vote. In the meantime, no need to let lack of a workgroup halt up work. Just pick something sorta close for now. Stephen Ewen 01:04, 31 December 2007 (CST)

See Special:Log/delete. CZ:Dance Workgroup might be a good part of a proposal for the workgroup, though. Stephen Ewen 01:21, 31 December 2007 (CST)

Hi Stephen,

Whoops!! I hope I didn't cause you too much trouble, I just hit the edit button and there I was adding a new workgroup :-) It all looked so easy until I found I had to make all the pages for it....then it was more of a :-{ Thanks for the guidance. --David Yamakuchi 01:29, 31 December 2007 (CST)

Not any problem at all. I put a plug in for your idea at CZ_Talk:Workgroups#Performing_Arts_section_for_workgroups. Stephen Ewen 01:33, 31 December 2007 (CST)

welcome to history

Welcome to the history workgroup--we really need your help. My daughter just signed up today for a course in fluid mechanics so maybe we'll be calling on help for that too! Richard Jensen 22:23, 6 January 2008 (CST)

Fluid Mechanics...ack! I just wanted to fill in the last couple missing Presidents with some blatently copied (albeit from public domain) material :-) Hey now that you mention it tho, my brakes have been a little spongy lately, maybe your daughter could help me!!!

But seriously, thanks for the note. I'm not great with history, but I got on a roll today and I'm still sorta having fun with it...--David Yamakuchi 22:48, 6 January 2008 (CST)

Calls for citations...

David: Just a heads up. I removed your citation needed template from the Lao Tse article. Larry is vehemently against ever using that or the fact template that you see at Wikipedia. This is based partly on the presumption that since we are vetted experts in our various fields, we know what we're talking about. I created one early on and it was summarily deleted within minutes, with a reprimand from several other editors...that's why you couldn't find it here.

As for that reference, it'll show up. I am compulsive about referencing, and you will rarely see me write something for which I cannot find some source. Blessings... --Michael J. Formica 06:38, 19 January 2008 (CST)

Michael: I did see the lack of a citation needed here, and I've never actually used one before _but_, the statement you made that Lao Tse was born in 604 B.C. is not really verifiable. While I will agree that you'll be able to find some references that says this is true, I will be able to find just as many references that say this is not. If you read the Stanford reference (and you might want to pack a lunnch for that BTW), you will find that there are more than one account of things.

Now, in terms of being vetted experts, and with all due respect to Mr. Sanger, my original entry was poo-poohed (sp?) for being a little wishy-washy in terms of the dates. I believe I said something like 600-200B.C., to which Larry responded "can't we do better?" The simple answer as I see it is NO! If we can't even be sure that the person existed, and there are conflicting accounts of the "real" history, my opinion is that is encumbent upon us as "experts" to present all sides of the story...which is at this point uncertain.

You sir, have stated as a fact something that was originally in the article as debated, _and_ removed my data that represents years of research on the subject. I am dissapointed. I will also point out that even though the data was immediately questioned by the Editor-In-Chief himself, it was not removed. We can't just go deleting things we don't like in articles. Consider the Holocaust entry, eh? The Talk page is used for that, and when that fails the Constables, I'm told, will be more than happy to assist.

That said, I am absolutely _not_ an expert on anything...except maybe my own experiences which I am attempting to selectively share so that we can all benefit from them. But what I can say with ceretainty is that (and since I believe _you_ were the one that added this article to the Religion workgroup, I'm sure you can understand) people can get kinda funny when you start misrepresenting their religion. Lao Tse is revered by many, and dismissed by many others. It's important that we try to consider everyone's opinion here, and not just the opinion that was taught at one particular school.

I'm going to copy this discussion over to the Talk page of the article in the hopes that we can avoid someone else having to go through this again.--David Yamakuchi 11:36, 19 January 2008 (CST)

Recommendation for templates

Consider using the "show preview" button when you make a slight change-- that way it won't flood the "Recent changes" page as much. Template:Codewink --Robert W King 10:45, 28 March 2008 (CDT)

Thanks, I usually _do_ use that for editing regular articles, but I don't in the case of a template.

Sorry about the long history page but "c'est la vie" as they say. Perhaps I will be able to find an admin willing to help me delete the mess once I've learned what I would like to know.--David Yamakuchi 12:28, 28 March 2008 (CDT)

Your version of the infobox

David, see Template_talk:Elem_Infobox_test1. I think it's possible that I may want to slide maybe one or two pieces of information into my original version, but I feel as they get more complex they only become more meaningless to the average person (who is really the target, anyway). --Robert W King 09:06, 31 March 2008 (CDT)

Of course, feel free to use what you like and I agree that it is too complex to use as it is. I like the idea that's going around about the subpage approach, but do believe (obvoiusly) that the infobox can have lots of useful info packed in a small area.--David Yamakuchi 14:32, 1 April 2008 (CDT)

The wikilinks seem like a good solution to implement until something more obvious but less crowded can be implemented. Good job though! Put it into the main Elem_infobox template. Also, I'm not sure that every criteria should be directed to the subpage table. Certainly there should be some very basic things listed, but sorting all the stuff like MSDS, complex properties, etc should definately go on a subpage. Maybe we can get Chris to create a new subpage type. If you can figure out the #IF logic required so that only elements of the table display when they are filled (including the title elements) that would be aces. --Robert W King 17:38, 3 April 2008 (CDT)

info box

What do you think of the recent changes I made? I think if the periodic table picture is designed specifically for this infobox, i.e. <200px it should look pretty good, rather than a shrunk down version. Let me know if there is anything you want put back the way it was previously?

As far as the element specific periodic tables are concerned we can write code that enters the right table automatically based on the element name. Something a long the lines of.

{{#ifexist:Image:Periodic table {{{elementname}}}.jpg| [[Image:Peridic table {{{elementname}}}.jpg|center|135px]]}}

Or what evenr the field name is for the element nane. Chris Day 13:00, 4 April 2008 (CDT)

switch/case is the thing you want there IMHO, but we need the .jpg's yet. Maybe if a few folks get to see the one you did for the template we might have some more to work with soon? I really like the way you got it to come out...thanks again. Now there was just one more thing...:-)--David Yamakuchi 01:36, 5 April 2008 (CDT)

Great work

David, great work on the template. It looks terriffic! --Robert W King 09:45, 8 April 2008 (CDT)

Duel identity

Hi David, I have really cut down the content in the ele template, hopefully nothing to damaging. Also, what is the logic of the duel identities, see the following elements for examples?:

{{#ifeq:{{{elSym}}}|Th|
{{!}}{{ele|{{#if:{{{elementColor|}}}|color={{{elementColor}}}|color=#828200}}|alphaOp=100|elOpacity=1|b=0|elSym={{{elSym}}}}}|
{{#ifeq:{{{elClass}}}|Transition Metal|
{{!}}{{ele|color=#ff00ff|alphaOp=60|elOpacity=.6|b=0}}|
{{#ifeq:{{{elClass}}}|Actinide|
{{!}}{{ele|color=#0000FF|alphaOp=60|elOpacity=.6|b=0}}|
{{!}}{{ele|color=#0000FF|alphaOp=10|elOpacity=.10|b=0}}
}}}}}}

{{#ifeq:{{{elSym}}}|La|
{{!}}{{ele|{{#if:{{{elementColor|}}}|color={{{elementColor}}}|color=#00ae00}}|alphaOp=60|elOpacity=.6|b=0|elSym={{{elSym}}}}}|
{{#ifeq:{{{elClass}}}|Transition Metal|
{{!}}{{ele|color=#ff00ff|alphaOp=60|elOpacity=.6|b=0}}|
{{#ifeq:{{{elClass}}}|Lanthanide|
{{!}}{{ele|color=#00ae00|alphaOp=10|elOpacity=.1|b=0}}|
{{!}}{{ele|color=#00ae00|alphaOp=10|elOpacity=.10|b=0}}
}}}}}}

In the above two cases why do you want the Th and La lighting up in the ff00ff colour when the element is one of the transition metals?

{{#ifeq:{{{elSym}}}|Ge|
{{!}}{{ele|{{#if:{{{elementColor|}}}|color={{{elementColor}}}|color=#828200}}|alphaOp=100|elOpacity=1|b=0|elSym={{{elSym}}}}}|
{{#ifeq:{{{elClass}}}|Post-Transition Metal|
{{!}}{{ele|color=#0000FF|alphaOp=60|elOpacity=.6|b=0}}|
{{#ifeq:{{{elClass}}}|Metalloid|
{{!}}{{ele|color=#a5a5a5|alphaOp=60|elOpacity=.6|b=0}}|
{{!}}{{ele|color=#0000FF|alphaOp=10|elOpacity=.10|b=0}}
}}}}}}

{{#ifeq:{{{elSym}}}|As|
{{!}}{{ele|{{#if:{{{elementColor|}}}|color={{{elementColor}}}|color=#00ae00}}|alphaOp=60|elOpacity=.6|b=0|elSym={{{elSym}}}}}|
{{#ifeq:{{{elClass}}}|Non-Metal|
{{!}}{{ele|color=#00ae00|alphaOp=60|elOpacity=.6|b=0}}|
{{#ifeq:{{{elClass}}}|Metalloid|
{{!}}{{ele|color=#a5a5a5|alphaOp=60|elOpacity=.6|b=0}}|
{{!}}{{ele|color=#00ae00|alphaOp=10|elOpacity=.10|b=0}}
}}}}}}

{{#ifeq:{{{elSym}}}|Br|
{{!}}{{ele|{{#if:{{{elementColor|}}}|color={{{elementColor}}}|color=#ffae00}}|alphaOp=60|elOpacity=.6|b=0|elSym={{{elSym}}}}}|
{{#ifeq:{{{elClass}}}|Halogen|
{{!}}{{ele|color=#ffae00|alphaOp=60|elOpacity=.6|b=0}}|
{{#ifeq:{{{elClass}}}|Non-Metal|
{{!}}{{ele|color=#00ae00|alphaOp=60|elOpacity=.6|b=0}}|
{{!}}{{ele|color=#ffae00|alphaOp=10|elOpacity=.10|b=0}}
}}}}}}

It appears you want they to highlight differently depending on the element. But why would you want them to light up in two different circumstances and with two different colours? Chris Day 22:39, 8 April 2008 (CDT)

The idea was that if you called the template for say Br, you could declare it part of the Halogens (elClass=Halogens) from infobox and show those, or you could declare it a nonmetal (elClass=Non-Metal) and lite up those squares. Same for Lanthanides and actinides, which can be designated as those, transition metals, or rare earth metals along with Y and Sc.--David Yamakuchi 22:46, 8 April 2008 (CDT)

It just didn't make sense to me to light up the Non-Metals and _Not_ light up the halogens...the halogens are nonmetals...aren't they?--David Yamakuchi 22:48, 8 April 2008 (CDT)

Why use different colors? Couldn't they show up when defined as non-metals yet still be coloured as halolgens? Also doesn't no-metal in tnhis usage have a very deifinite meaning rather than the in a general sense? This is not rhetorical, I really don't know. Chris Day 22:56, 8 April 2008 (CDT)

When I looked at a bunch of different tables that's what I saw. Sometimes one way sometimes the other. Tables can't even agree on where the transition elements end. I think we might not be done with this one for a while. But what we can do for now is be ready with a mechanism that supports whatever classification system tomorrow brings...I think--David Yamakuchi 23:03, 8 April 2008 (CDT)

modify periodic style

I assume you are going to mess around with the style of the different cells. I think Robert is already thinking about colors. FYI, colors for each element can be defined at {{Elem_Infobox}}. The cell styles, including cell size, line thickness and color, as well as the opacity values, can be defined at {{Ele it}} for the black cell that marks the specific element‎, at {{Ele off}}‎ for those cells in the background of unrelated elements to the black one and at {{Ele on}} for cells that have related elements.

Feel free to change anything I have done. I'm taking a back seat again for now. Chris Day 11:29, 9 April 2008 (CDT)

Catalog pages

• the catalog subpage is actually supposed to be the root for catalogues, e.g. Colors/Catalogs/Red. Also, these catalog pages need to be seriously organized in some way. I suggest we get David Volk involved. --Robert W King 19:57, 9 April 2008 (CDT)

If/when we implement that, the links in the infobox will need to change.--David Yamakuchi 00:00, 10 April 2008 (CDT)

Template Recursion

Hi, I was about to leave Chris Day a message and I saw your message to him. You might want to check out this help page on Meta, and also this. I also have a list of helpful template documentation pages on my User: page. J. Noel Chiappa 01:15, 14 April 2008 (CDT)

PS: Your comment about C: Templates have a lot of the look-and-feel of a programming language, but they aren't, so don't be misled. 'Calls' of templates aren't calls in the normal sense. All templates do is replace one (sub-)string with a different (sub-)string: in the evaluation of template(s), one string gets turned into another string, which usually then gets turned into another, and so on. Sometimes the order in which stuff gets done can be confusing; the fact that it's replacement means things can happen in odd (i.e. counter-intuitive, confusing, complex, and hard to understand) ways; e.g. whether the arguments get evaluated before the 'code' (e.g. conditionals). See Migration to the new preprocessor for examples of the kind of thing I'm talking about, where changes to the preprocessor changed what you get from certain 'odd' template syntax. J. Noel Chiappa 01:27, 14 April 2008 (CDT)

There's a "strings" package for MediaWiki, which we don't have installed yet. I seem to recall one one of those pages I have links to, people talking about ways to do some of the strings stuff without it, such as this. Does that Help:Advanced templates have any kludges that are applicable? J. Noel Chiappa 14:55, 14 April 2008 (CDT)

I tried some kind of {{#explode:}} template that I found in the MediaWiki docs. It claimed it would parse a string for me by a delimiter value I gave it, but the page just spit it back out at me in grey :-(--David Yamakuchi 19:49, 14 April 2008 (CDT)

#Explode is part of "strings". J. Noel Chiappa 10:56, 15 April 2008 (CDT)

Editorial Council loop

Haha! Good one. The problem is that Category:Editorial Council includes the template {{Editorial Council}}, which... adds the page which includes it to the category.... Category:Editorial Council. Whee! Where's Bertrand Russell when you need him? Alas, no simple way to fix this... other than remove the template. J. Noel Chiappa 22:30, 18 April 2008 (CDT)

Hi, I just saw your message on my User talk: page - the above was prompted by seeing you upload the image.

What's underlying this is that in MediaWiki, a category is two things: an internal list of pages which have that category tag on them (actually, it's just 'what links here' for the category page), and an actual page (of the form "Category:Foo"). When you ask for that 'page' to be displayed, it concatenates the actual page content with a nicely formatted listing of the pages which are in that category (i.e. link to it) and displays the whole works.

What's going on, basically, is that this AJAX thing (which I don't have on my computer) is trying to expand the tree-structure of the categories (which it does by chasing down pointers). Alas, the Category:Editorial Council category contains a link to.... itself - which of course drives a tree-walker berserk, because it doesn't expect a loop in the tree-structure. J. Noel Chiappa 22:44, 18 April 2008 (CDT)

Yeah, to fix it, you'd need to an an optional "nocat=" argument to {{community}} (and changes to that template not to include the category tag when it was set), and then you'd need to modify {{Editorial Council}} to accept and pass along a "notcat=" argument, and finally modify the call to {{Editorial Council}} in Category:Editorial Council to be {{Editorial Council|nocat=yes}}... all of which seemed like it was too much work to be worth bothering with when there's so much else to do! J. Noel Chiappa 23:32, 18 April 2008 (CDT)

That works too. I didn't know {{Community without category}} existed. J. Noel Chiappa 23:43, 18 April 2008 (CDT)

one source

I like the idea of one source for the physical properties and had been mulling such format. The only issue might be if so many calls cause the download to be slow or the page to be too big.

The only potential clash that I see in your system, compared to what I had in mind, is the color scheme (I should add my ideas were still embryonic so i had not really formulated a specific plan to date). Yours is currently hardwired for solid/liquid/gas/synthetic. And this is good, however I also wanted to have it possible to use the same template and have the colour schemes variable for different properties. For example, metal/non metal/metalloid as one colour scheme. Another based on melting temp (possibly a blue to red range) or other variables such as density, electronegativity etc. I was envisaging each physical property can be represented as a catalog page with distinct colour schemes based on the range of the elemental property values. This would allow a quick visual for how the given physical property varies throughout the Periodic table. For one, this will allow trends to be more obvious.

In the long term I was thinking along the lines of co-opting the {{subpages2}} button system to toggle through the various catalogs. Toggling easily through the various catlogs to see the different property trends and element characterisations will be a useful tools for becoming familiar with the characteristics of the various elements.Chris Day 11:56, 21 April 2008 (CDT)

That color scheme switch is looking good. That should allow us a lot of different presentation variables. Chris Day 09:24, 23 April 2008 (CDT)

Article specific subpage

Check out cadmium and the Cadmium/MSDS subpage. The subpage is created by using tab1=MSDS in the metadata. We could also add tab2=Isotopes and one other tab3=?. This might be more intuitive than having all the chemical information in a Catalog subpage. I tweeked the {{Elem Infobox}} so the headers now link to the MSDS subpage. I plan to write this up as a proposal so we can get approval from the editorial council. I just want to get your feedback before I start on this. Chris Day 15:46, 24 April 2008 (CDT)

Project

I know you might be busy on other things, but I want to see if you're interested in helping with a project I've tasked myself with. I've also messaged Steve to see if he wants to join the effort. The project is somewhat described over at CZ_Talk:Workgroup_Weeks, see the "What else" section. Drop me a line if you think this is something you'd like to get involved in. --Robert W King 09:31, 25 April 2008 (CDT)

MSDS

It seems kind of silly to have the elem infobox on the MSDS page when it's also right on the main page, no? --Robert W King 11:47, 25 April 2008 (CDT)

David, is everything all right over there with the physical properties template? --Robert W King 14:10, 25 April 2008 (CDT)

Ok, just making sure, because you have some things like Template:/Physical Properties/Physical Properties‎; which is a little odd. --Robert W King 14:25, 25 April 2008 (CDT)

Physical properties

Hey, keeping the per-element physical properties in a template is a fabulous idea. One question, though; in {{Physical properties}}, why are you passing the element name in, as "|Material = <whatever"? Would't {BASEPAGENAME} or something give it to you? J. Noel Chiappa 20:38, 29 April 2008 (CDT)

It is not clear to me how easy it is to update the centrally stored values. It is important that they are as reliable as possible and: (i) people can make mistakes in entering them and (ii) values can change by better measurements. In both cases updating should be easily done by all. Further, definitions are not always as clearcut as you may think they are. There are different definitions (and scales) of electronegativity, for instance. Your template should clearly state which are the ones listed. --Paul Wormer 08:47, 1 May 2008 (CDT)

It's pretty easy to change them; anyone can just go to [[Template:<element>/Physical Properties‎]], e.g. Template:Lead/Physical Properties‎, and edit away. It is precisely to deal easily with typing errors, better values, etc that storing them in only one place is better. J. Noel Chiappa 16:26, 4 May 2008 (CDT)

I've been watching your progress although not following it in detail. I notice you have hit upon a problem that I had too. Some values are calculated to many significant figures and because we have no strings there is no way to automate rounding off the numbers. My solution was to do it manually, clearly not the way to go. Any news on whether strings will be added? Chris Day 11:29, 1 May 2008 (CDT)

Just so you know, the Isotpes page in Lead was an intentional misspelling. I was testing an error checking method to help us catch typos when people use the tab1-tab3 feature. You can change it back to Isotopes if it is causing a problem. Chris Day 11:35, 1 May 2008 (CDT)

Actually, I just went ahead and fixed it. So it is at its correct home now (Lead/Isotopes. Chris Day 11:47, 1 May 2008 (CDT)

Having a list of the compounds on the /Physical Properties‎ metadata (as you currently do at Template:Lead/Physical Properties‎) is not good (it can cause pages which include that to render more slowly, as they have to parse, and ignore, all that stuff). But I suspect you have already worked this out, given the existence of Template:Lead/Compounds‎? J. Noel Chiappa 16:41, 4 May 2008 (CDT)

{{pressure}}

David, thanks a bunch for making that {{pressure}} template for me ... I really appreciate that. As for a units converter, there are dozens of such converters on the Internet and I am not sure that a Wiki version is needed. What bothers me about such converters is that it would take hours and hours to verify whether or not they contain errors. I don't like using "black boxes" blindly. For that reason, I am not sure that a Wiki version would be useful. Perhaps you could start a thread on the forums about your idea?

Now that the {{pressure}} template exists, do you have any ideas on how to broadcast the fact that it is available? - Milton Beychok 12:13, 12 May 2008 (CDT)

I would say that if you placed it in the first few places where you looked and said "hey, we need a {{pressure}} table here", that would be a good start. Folks who notice it there can then copy it easily.--David Yamakuchi 15:34, 12 May 2008 (CDT)

Listing subpages

Special:Prefixindex/YourPageName. :-) J. Noel Chiappa 14:53, 15 May 2008 (CDT)

New templates

Hi, don't forget, once you've put a new template into service, to add it to CZ:Templates (which is now much better organized, and somewhat updated). J. Noel Chiappa 14:13, 4 June 2008 (CDT)

Isotopes hackery

Hi, those templates were all so complex they made my head spin. If you could isolate/construct a simpler example that displayed the same behaviour I'd be more likely to be able to help.

You could also try asking Chris to see if he can help - he does a lot of that intricate stuff too. Do you know about Special:ExpandTemplates? J. Noel Chiappa 15:13, 4 June 2008 (CDT)

PS: Is there some reason that {{!!}} consists of two calls to {{!}}, and not just two 'pipe' characters? J. Noel Chiappa 15:13, 4 June 2008 (CDT)

I typed a long message, but on further reflection/investigation, I think it's all BS, so I'm holding it for now.

I found a minor syntax error in {{Props}}; you'd omitted the closing '}}' of the call to {{Properties}}.

Oddly enough, I had tried sticking {{Props|Material=Unobtanium}} into a window and hitting "Show preview", and I got basically the same output before and after I fixed that! Try it, and note the '}}' in the box with "Atomic Symbol".

To see why it may be happening, try sticking "{{Props|Material=Unobtanium}}" (without the "'s, of course) into Special:ExpandTemplates and look at the output. See the line with "|Atomic Symbol}}" on it? That could produce that "Atomic Symbol}}" box output, no?

I wonder if somehow either the preprocessor or parser is getting confused, and not evaluating the call to {{tl|Properties}? If so, don't ask me what happened to the box with "{{Properties" in it - or perhaps that got eaten somehow when {{Properties}} didn't evaluate properly?

Another possibility is that the parser and preprocessor are mstaking the "|" characters which are the argument separators for the arguments to {{Properties}} for the "|" characters which separate table elements? (The perils of 'operator overloading'...) That could be breaking the template invocation up into chunks, which might be causing the failure to evaluate {{Properties}} properly...

Anyway, a lot of guesses and confusion, but hopefully some of it will be useful. J. Noel Chiappa 20:13, 4 June 2008 (CDT)

PS: For more grins, try sticking:

 {{Properties
 |Atomic Number
 |Atomic Mass
 |Atomic Radius
 |Atomic Symbol}}

into Special:ExpandTemplates... But I don't think we're to that problem yet! I don't think {{Properties}} is even being called. J. Noel Chiappa 20:13, 4 June 2008 (CDT)

I was just messing around and I really don't see why properties is not called in that context. Properties itself works if the parameters are in the actual template but when transcluding the parameters it does not. But as you say, it works fine for IsoData so why not here? I'll think some more. Chris Day 03:45, 5 June 2008 (CDT)

Sorry for leaving it in a mess. It was late :) What a strange problem. There is no obvious reason why calling those parameters from a different page should break the properties template. Let me know if you figure something out. I'll keep thinking but nothing short of starting from scratch with a new approach has hit me yet. Chris Day 14:40, 5 June 2008 (CDT)

I solved the problem, but I'm unsure why it works. You need to have the table from {{Props}} within an argument. I placed it within an ifexist argument (are these called arguments?), with an option to creat the physical properties template if it does not already exist. i.e. similar to what you have in {{Isotopes}}.

I checked to see if removing the same ifexist argument from {{isotopes}} causes the {{IsoData}} template to fail in the same way, and it does. Maybe Noel will know why? For the record, this is reminiscent of the line break problem we had when directly transcluding definitions. That was why the {{def}} template had to be created, rather than transcluding the definition directly. Chris Day 15:32, 5 June 2008 (CDT)

That was the version of {{properties}} i was looking for, or at least similar to it. I'll let you carry on adding all the if: statements. Chris Day 15:59, 5 June 2008 (CDT)

I'll stop editing so there are coherent edits going on. Chris Day 16:21, 5 June 2008 (CDT)

There are some bugs with the old preprocessor, one of which you can see here, source here. For more, read this. I suspect this may be another one. Just living with it is the best we can do, sigh. Anyway, glad we finally got it working. Remember Special:ExpandTemplates for next time, hunh? J. Noel Chiappa 06:40, 6 June 2008 (CDT)

Properties storage

I just realised that you are using subpages such as Unobtanium/Atomic Mass for each different property. First, would it not be more appropriate at Unobtanium/Properties/Atomic Mass? Second, why not have all the properties on one page, similar to the switch you have for the isotopes, would that not be simpler? I'm not saying your plan is wrong, just interested to hear your thought process. Chris Day 07:11, 7 June 2008 (CDT)

Gotta agree with Chris on this one - put them all on one page, with a selector - unless there's a good reason for separate pages (which I can't off the top of my head see). J. Noel Chiappa 05:39, 8 June 2008 (CDT)

So just how big would the properties pages get? What pages do you envisage will be using this information? Obviously the elements pages will be using it but I assume yu have others in mind too? Chris Day 08:41, 8 June 2008 (CDT)

Never mind answering this. I remember now, it's for adding the info to the cells in a periodic table, such as atomic mass. My solution was to manually add the values as parameters for each cell. This had the added advantage that I could round to five significant figures (or less). Now if we had strings that might be a different matter but that is the only way I know how to do that at present. While i can see this might be a problem for a parameter that varies, such as population for a city, it should not be such an issue with periodic tables since the properties will not change in the future. Alternatively we why not just restrict the separate subpage (or subsubpage) entries for properties that might be used in such tables and just add the others directly to the Material/Properties subpage, or do you envisage using them all in this way on various pages? Chris Day 22:11, 8 June 2008 (CDT)

This just seems like a waste of computer resources to have separate pages as place holders for singles variables. There must be a more elegant way to do this. David might better spend time thinking of a solution to this problem before making all of these pages. Does CZ have any kind of look-up-tables at present, other than the live article count? Could something like that variable work? David E. Volk 08:36, 10 June 2008 (CDT)

It adds to the page count significantly, I agree. But it also reduces the load on the wiki engine to a minimum in the sense that it only has to retrieve the needed information, not all the properties to display just one.

Further, each specified number can come with a qualifying statement...(see Hydrogen/Periodic table of elements), and history...(see any of the entries that I fat-fingered on the first try.) --David Yamakuchi 12:49, 13 June 2008 (CDT)

property values

So for the really large values of atomic mass you are going to just use the rounded versions until strings is activated? The PTE looks great. Chris Day 17:35, 11 June 2008 (CDT)

Property values are still greatly inflated these days :-P --Larry Sanger 21:51, 11 June 2008 (CDT)

What is the reason for the density units in the current formatt (gpcm3nrt and gpcm3mp)? Is that commonly used now? Chris Day 21:04, 12 June 2008 (CDT)

Summary of what you're doing

Hi David, can you point me to a page that shows how all this data you're adding to the wiki is actually used?

I'm intrigued... --Larry Sanger 21:51, 11 June 2008 (CDT)

template lens

Is that the strings function working there? Chris Day 11:35, 17 June 2008 (CDT)

I tried to use something similr in {{Subpages2}}

{{ #ifeq: {{#expr: {{#len:{{{{BASEPAGENAME}}|info=pagename}}}} > 20 }} | 1 
                  |'''[[{{{{BASEPAGENAME}}|info=pagename}}|Main Article]]''' 
                  |'''[[{{{{BASEPAGENAME}}|info=pagename}}]]''' }}

but it did not seem to work then. Although in that case the #len part might require strings, I forget. Let me know if it works. Chris Day 11:56, 17 June 2008 (CDT)

Spelling of darmstad(t)ium

Hi, David. I noticed that among all the periodic table data there are several subpages spelled "Darmstadium". Shouldn't this be "Darmstadtium"? That's how the Britannica spells it. (Presumably it's named after the city of Darmstadt, which ends in a "t".) Thanks. Bruce M.Tindall 13:35, 18 June 2008 (CDT)

Maybe the Darmstadium is where the local football team plays :) Bruce M.Tindall 13:54, 18 June 2008 (CDT)

hello

Hello Mr. David Yamakuchi. Can you read & speak Japanese? Hideki_Kajimura is one of the articles I'm currently working but I can't find anything about him in English. Thank you. (Chunbum Park 16:51, 22 June 2008 (CDT))

Gas density units

David, I just happened to stumble upon a posting of yours on Chris Day's Talk page about densities in Chemboxes. I would like to point out that it is very important, when stating a gas density in any units, to explicitly state the references temperature and pressure at which that stated density was measured or calculated. Merely stating STP or Standard conditions can lead to confusion because there are no universally accepted standard conditions of temperature and pressure (see Reference conditions of gas temperature and pressure).

Please excuse me for this intrusion into your discussion with Chris, but I thought you should be aware of the importance of always explicitly stating the references temperature and pressure when stating a gas density. For example: the density of Foo gas is XXXX g/L at 0 °C and 100 kPa.

Regards, Milton Beychok 18:03, 25 June 2008 (CDT)

Beautiful article

My congratulations for this entertaining article on Lead. The quality of your prose gave me an idea: this article could eventually become a video article.

Pierre-Alain Gouanvic 15:52, 1 July 2008 (CDT)

Thanks Pierre, but the words were not mine. The real author worked for the EPA in the 1980's and I believe he wrote the paper as part of his official job function (making it public domain). When I saw that there was not a CZ article for Lead, all I did was edit the thing a little to try and make it read as current. I'm glad to see you enjoyed it as much as I did tho...--David Yamakuchi 23:45, 9 July 2008 (CDT)

Good move! -- Pierre-Alain Gouanvic 01:01, 10 July 2008 (CDT)

Hydrogen bond

See hydrogen bond--Paul Wormer 06:10, 15 July 2008 (CDT)

It's a party, and you're invited!

Hi ! Your CZ Write-a-Thon MC here. Please head over to the Party Room and add yourself to the list of revelers in whatever category you think appropriate. Thanks for contributing! Aleta Curry 19:01, 6 August 2008 (CDT)

From your friendly neighbourhood mistress of ceremonies

I signed you in at The August Party Do join us on Wednesday September 2nd for what I hope will be a very active party with music, music, music. Theme: "My Favourite Band" (or, 'ensemble' or 'group' or 'orchestra' or 'singer' or 'recording' or...? Aleta Curry 23:35, 7 August 2008 (CDT)

Properties

I just added some categories to the AS-Properties footer template. This is important for tracking the article specific subpages. One question. Is there an easy way to add properties? i.e. a list of properties not included and a preload for the format of each? At present, if I want to add a new property, it would not be so obvious, i know how, but would others? Chris Day 17:09, 30 August 2008 (CDT)

MSDS/Properties

I notice that the properties for lead are listed on the MSDS subpage. Since the three article specific tabs are already used up we need to consider how to make room for the properties subpage tab in the header. One of the four Article Specific-subpages will need to be added as a permanent subpage. Which do you think is the best to nominate? Or should we add functionality to the subpages template to allow a fourth AS-tab? Chris Day 12:39, 5 September 2008 (CDT)

I agree with all your points. I understand the snowed under feeling. Chris Day 10:05, 8 September 2008 (CDT)

Check this out

User_talk:Chris_Day#How_do_I_increase_the_cellpadding_in_a_Wikitable.3F

This is another change that happened to tables at the same time. Clearly tables are not functioning as they used to. I don't know what the root of the problem is. Chris Day 00:05, 25 November 2008 (UTC)

Still driving you nuts? Just so you know. I'm stumped too. Chris Day 22:16, 7 December 2008 (UTC)

David, is there any reason why that list in {{Props}} can't just be fully inclusive? Something similar to this, without actually transcluding the list from a subsubpage (such as Iron/Properties/List)? As far as i can tell values only appear in the table if the appropriate value subpage exists anyway so a customised list is not really required. Is there any specific need for the /lists subsubpage to limit the number of fields? Chris Day 00:27, 8 December 2008 (UTC)

Is it a need? No. Would it be nice? Yes, most definitely.

I think I had something like the server having to check for say, Sulphr Dioxide/Atomic Number in mind. It wouldn't make sense. The template is much more general if you can tell it what the properties are. Consider, could a taxonomist come up with "properties" for say, mammals?--David Yamakuchi 18:47, 8 December 2008 (UTC)

I see what you're saying, but what would be a practical limit to the number of fields. Couldn't it be hundreds or would that be too much CPU time? Chris Day 05:51, 9 December 2008 (UTC)

Dunno about the CPU implications, I suppose that's a consideration as well. {{Properties}} currently only evaluates the first 50 anyway. The 51'st and onward would simply be ignored, although that number can be arbitrarily large...it would get very large...and unnecessarily bloated.

I think I've convinced myself at any rate. The simple solution is the most elegant here. Let Iron->Properties->List tell us what 50 fields we need to check for in the case of Iron, Mammals->Properties->List for mammals. We could call it Mammals->Properties->ls if you prefer ;-)

Sadly however, our latest and greatest wiki version does not seem happy with the technique where the old one did. Sort of seems like we moved backwards, _but_ I did however, notice numerous "template expand" type bugs when I searched the Bugzilla listings on MediaWiki for previous builds, I guess it would be kinda optimistic to expect a new build without them. The expand templates page doesn't expand the template as advertised. I contend that that is a bug that could be fixed.

So, I would like to propose the following: fix with your "central list" patch so that the various pages function for now and don't look like doo doo. Continue that way until such time as the wiki's template logic is repaired. I will put in a bug report to try and help effect the repair.--David Yamakuchi 06:42, 9 December 2008 (UTC)

Sounds good and i agree the versatility of having a specific list will make it more generally applicable. You may well be right that this will be fixed in an upcoming version. Are you going to set up a sentinel template on your talk page so we know when the expand is working correctly? Chris Day 06:51, 9 December 2008 (UTC)

See Lithium/Isotopes. I pulled the Isotopes out of the Metadata so there won't be a link to it from the main article. This one could be a sentinel where it is, or I could move it as you suggest. It uses the same technique.--David Yamakuchi 16:06, 9 December 2008 (UTC)

element definition problems

David, look at Halogen > Related Articles and see what a mess these templated elemental definitions turn into when they are not on the actual elements' home cluster. Is there a way to fix this? David E. Volk 16:41, 8 December 2008 (UTC)

Whoops! There, I think that should do it. That fix was relatively straightforward. I simply hadn't anticipated the defs being included like that into other clusters. My bad :-)--David Yamakuchi 18:48, 8 December 2008 (UTC)

That seems to work. Now could you reduce the lenghth of the definition to the something like 80 character limit so they fit nicely on 1 line of text? David E. Volk 19:08, 8 December 2008 (UTC)

OK, done. If you would like to tweak the template further yourself it's called {{Basic elemental def}}. I won't be mad.--David Yamakuchi 06:46, 9 December 2008 (UTC)

Most Wanted - chemical elements

Hi David, I am thinking of ways to make Special:WantedPages more useful. Since many chemical elements are listed on top there, I'd appreciate your comments. Years are a similar case, and I have seen your comments on that at CZ Talk:History Workgroup. --Daniel Mietchen 07:52, 28 April 2009 (UTC)

I am fully aware of {{Basic elemental info‎}} or {{Basic elemental def}} and think they are a great foundation for an article but an encyclopedic entry would certainly have to cover more than these basic facts. From the top of my head, it would appear to make sense to include, for instance, information on the kinds and global distributions of natural resources (certainly on Earth, but possibly even on other stellar objects) containing the particular elements, on the processing chain needed to purify them, on the economic, medical, biological or other importance, and on waste disposal. In addition, it would of course help the reader if all this were wrapped up into a didactive narrative, especially if the basic facts are already available at a glance via your infoboxes. No need to worry about the empty elements pages to clutter Special:WantedPages (years are much worse in this context), but using it as a guideline on which article to start next would probably be a good idea. It would be even greater if you could come up with a similar corporate design for the elements' pages themselves, integrating them with the facts templates. --Daniel Mietchen 22:05, 1 May 2009 (UTC)

About the border around the table in Water

Hi, David: Is there any way for you to center the table within the border that you created? I think it would look better if it were centered. Milton Beychok 15:47, 13 May 2009 (UTC)

It would seem the best way to get it centered is to view it in Firefox instead of IE  :-) I spent about 1/2 hour yesterday before I saved the changes to get it to center correctly on my screen... Apparently there are still some rendering inconsistencies between the various browsers. Who knows what the right way to deal with this issue is, I'm not sure. The first couple of things I tried today didn't work. I suppose I can start by copying this over to the talk page. It seems to me that either Chris Day or Robert King (or both) had managed to solve this one before. FYI: Firefox seems to handle the right-side justification a little more smoothly also...um, just mentioning ;^)--David Yamakuchi 00:34, 14 May 2009 (UTC)

Periodic tables

Hi David,
There are a lot of periodic table templates around, many of which you seem to have been involved in the creation of.
I've been sorting out the current mess of templates, and I'd really like to reduce the number of periodic table templates to just one (or perhaps two, the normal one and a small one for use in infoboxes).
Not having been involved in them, and not being a physicist... I thought I'd better ask you for advice or assistance.
Basically, I feel that there should be one main template, and then if the same logic is repeated for each cell then that logic should be included in a subpage of the main template. It shouldn't be necessary to have more than a couple of these subpages, I shouldn't think.
Caesar Schinas 17:01, 18 May 2009 (UTC)

I think the same thing. There are just too many properties subpages. One home for them all makes a lot more sense. Also has the advantage of for each new chemical the fixed properties only have to be added to one subpages rather than tens of subpages. Chris Day 17:04, 18 May 2009 (UTC)

Well, my chief concern at the moment is that it could end up being a rather cumbersome subpage for some materials that have many, many properties. But since the properties indexing scheme I was trying to get going seems to have been broken by the wiki update some months ago, I don't really feel like I have a strong argument (or a reliable system with which) to continue down that path. The properties subpages plan to enable PTofE display of properties just didn't work I guess. C'est la vie. Perhaps you should start deleting the work as you like...--David Yamakuchi 14:31, 19 May 2009 (UTC)

Oh! and don't forget to check the "what links here" for each one, I seem to recall a lot of cross-linking :-)--David Yamakuchi 14:53, 19 May 2009 (UTC)

Hmm... well, to start with there are the following templates. So far as I can make out they are all unused except by each other. I confess to not being entirely sure where any of them would be used...

• Cel
• PTofE
• PTofE/Sandbox
• Periodic Table of Properties
• Periodic cell
• PropertyCell
• Resizable Periodic table of elements
• Resizable periodic cell
• Rpc
• Rpc color
• Rpcc

Then there's Periodic, which is used in Elem_Infobox.

Then there are all of the following, which I would love to delete... :-)
As I see it, they should at least all be merged into one. They seem to be used by Periodic.

• AEM on
• AEM off
• Actinide off
• Actinide on
• Alkali metal off
• Alkali metal on
• Ele it
• Ele off
• Ele on
• Element on
• Halogen off
• Halogen on
• Let it
• Let off
• Let on
• Letter on
• Lanthanide off
• Lanthanide on
• Metalloid on
• Noble off
• Noble on
• Nonmetal off
• Nonmetal on
• PTM off
• PTM on
• Retro
• Retro off
• Retro on
• Transition off
• Transition on

Do you have specific suggestions about any of these? Caesar Schinas 15:55, 19 May 2009 (UTC)

What exactly is the aim of the periodic table template? When would it be used and how would it vary from one page to another? Would the only difference be to highlight one particular cell each time? Caesar Schinas 15:57, 19 May 2009 (UTC)

Try looking at the documentation for Unit, Props and PTofE, for what I was trying to do. That should give you a view from the "bottom level" (unit) to the "top level" (PTofE). Props (which Chris Day mentions above) was more or less a "gimme" when the properties for the elements were indexed as I have begun doing them. It would be used to display all the different properties for a particular element (or arbitrary material).

The original idea was that the template user would be able to select which information (melting point, electronegativity, density, etc.) to display on the table. I even was able to get the scheme to color code the cells of the PTofE based on the particular parameter (that's what Unit enables), and to provide a link to various properties to facilitate property data entry (see Periodic Table of Properties or Resizable Periodic table of elementsfor details for more details on that).

Further, there exists Periodic which as you mentioned is used in Elem_Infobox. His job is to display the little PTofE in the infobox currently used in the elements articles and highlight the particular element and (possibly the) group in the table. See Carbon, Phosphorus, Hydrogen, etc. for details. You really would have to consult Chris Day or Robert King about the inner workings of that one and their "sub-templates", but it seems to work pretty well so I would be hesitant to want to change it drastically without going over again what the desired result was. It seems to me that somehow by splitting it up so, they were able to get a much "smaller" (and therefore more computationally efficient) main template that didn't cause the page to load slowly.

Note also that this has not been done with PTofE and his brethren Periodic Table of Properties, and Resizable Periodic table of elements. They branched a little earlier from the Periodic template and had different desired outcomes. These templates need significantly more computational power than is available on the current servers to load quickly. Be patient when loading these pages. They are functional templates. Just sloooooooowwwwwwwwwww ones.

See the Talk pages of the various templates too, particularly Elem_Infobox and Props. There is significant discussion of the design approach and desired functionality.

I hope this helps...--David Yamakuchi 20:30, 19 May 2009 (UTC)

Well... I can't work out how Unit or Props are related to PTofE! Props doesn't seem to be used on PTofE... I think I can understand what Props is for and how it is used, but not PTofE. You can't have a periodic table with different information shown in it, can you? I thought they were always the same... :-(

This seems more complicated than I thought!

You didn't mention all those on/off templates, but I'm pretty sure they would be much better as one template. It's very inefficient to include that many different templates into another one.

Caesar Schinas 16:03, 20 May 2009 (UTC)

"Ethyl" Anecdotes

(Copied more or less from my Talk page to here)

Hi Milton,

It seems that in your work on the Lead and Tetraethyl lead articles, some of the little anecdotal stories about Kettering and the material's manufacture at the Ethyl Corp. seem to have been eliminated. I kind of liked those, and it leaves me to wonder: do you feel that they were not accurate? --David Yamakuchi 14:45, 19 May 2009 (UTC)

Hi, David. If you will read the dicussion pages of both the Lead and the Tetraethyl lead (TEL) articles, you will see that:

• I first expressed my opinion that the TEL history section ("Lead as a fuel additive") of the Lead article was was much too long , about 35-40% of the article. After all, that article was about the element Lead ... not about the liquid compound TEL. I proposed shortening that section a great deal and creating a separate, stand-alone article about TEL. Chris Day, Joe Quick and Ro Thorpe all agreed and told me to go ahead ... so I did.

• When I created the new, stand-alone TEL article I included a sub-section header for History (with two excellent references to online articles about Midgley, Kettering and the early history of TEL). Then in the Talk page of the TEL article, I noted that more work was need on the TEL article and I hoped that someone knowlegeable about TEL would work on it. If nobody steps forth to review the article and write that History section in the next few weeks, then I will try my hand at it.

I just felt that I had done enough and that someone else could add the finishing touches. However, I do feel that the TEL history section should be more concise and shorter than the section that was once in the Lead article.

Would you like to try writing that History section of the new, stand-alone TEL article? Please feel free to do so. Regards, Milton Beychok 15:26, 19 May 2009 (UTC)

I might add that I think the two TEL history articles that I referenced in the TEL article are, in my opinion, better source material than the EPA article that was used for the original history writeup in the Lead article. As one who was already working in oil refining and gasoline manufacturing industry in the 1940s and 1950s, I found that EPA writeup somewhat disjointed and a bit too boastful of the EPA's role. In those early days, when I interfaced with them a few times, many of EPA's technical staff were sorely incompetent and unknowledgeable. Milton Beychok 16:43, 19 May 2009 (UTC)

I think that is perhaps a "yes" eh? That's ok, I did sort of suspect the text as being a little slanted, considering the source and all, but was hesitant to remove stuff because I thought it was a good read. I will say tho, that the few paragraphs I read of the links you included seemed to be written from perhaps a slightly different perspective. I suppose I will have to refer to your inside knowledge of the industry and go with your recommendation of deleting the EPA's version of the story. Absent a more thorough knowledge of the petroleum industry myself.

Perhaps I will make an attempt in the future of adding to the Lead article my inside knowledge of the electronics industry's use of Lead in manufacturing and the long-term impact of the material. I'm not sure what kind of reception my opinions on the subject would get tho...outside of Europe that is. We will have to see what I will be able to contribute to CZ in the future.--David Yamakuchi 20:49, 19 May 2009 (UTC)

I hope that you decide to change that "perhaps" a yes to a "definite" yes as to working on the TEL article's history section. I have also asked Anthony Argyriou to work on that section. As for adding a discussion of the electronic industry's uses of lead to the Lead article, I think that's a good idea no matter whether it is U.S. centric or European centric. Regards, Milton Beychok 21:32, 19 May 2009 (UTC)

If you were any kind of Mannitol, you would insist he change perhaps to yes! David E. Volk 23:41, 19 May 2009 (UTC)

And to the military and, of course, rocket scientists, TEL is transporter-erector-launcher. Howard C. Berkowitz 23:52, 19 May 2009 (UTC)

If I were a sugar alcohol???? You lost me, David. Milton Beychok 23:58, 19 May 2009 (UTC)

Element subpages

Hi David, glad to see you back. There have been quite some discussions on the future of the elemental subpages, and it was a pity that you were not there to answer questions. In any case, it seemed obvious to everybody that you put a lot of effort into this, but the overall structure is not obvious at all, and the templating may be inefficient. I did not pay closer attention than that, but I would suggest that you ask for input on the forum before simply continuing on your path. Thanks! --Daniel Mietchen 22:55, 7 February 2010 (UTC)

Just as an update, since this seems to have been discussed a lot in many different places recently.

I too did a lot of work on these templates and I think the idea is solid. Possibly we need some tweaks here and there but overall the big concept is one of maintainability. No standard value should ever be typed into an article, if possible. It is best that we promote a standard practice of 'reading' them from a central location.

While we could and should debate the format of the central location, we shouldn't get drawn into the use of stand alone values. This could lead to incorrect information being propagated throughout the encyclopedia, something that is hard to copy edit for on a large scale. One central value, used by all pages, is key to having a reliable and maintainable product. Chris Day 20:48, 8 February 2010 (UTC)

I responded on the Forum, but it looks like I need to respond here too. First and foremost, I would like to request that anyone wishing to address the technical aspects of how to implement what we are talking about here read this: http://en.citizendium.org/wiki/Template_talk:Props

That said, I think a central location for these discussions would be helpful, and I'm starting to be of the opinion that the issue may have outgrown a forum called "Deadend pages". Any suggestions?--David Yamakuchi 21:10, 8 February 2010 (UTC)

Certainly a fresh start would be good. i have not been around a lot recently and you have not either. Consequently, there is a lot of confusion about the goals of what was being done at the time. For example, using the values to color code the periodic table has not even entered the discussion. This is a lot more to this than just having the correct information in an article.

Certainly I have forgotten many of the details, and I'm not sure where we are currently with regard to functionality. Are the problematic tables working again now? Maybe we need to summarise where we are at, and where we want to go, before we discuss the details. When I read the many different discussion I get the feeling that we are all discussing this from different perspectives. Chris Day 21:22, 8 February 2010 (UTC)

By the way I'll reread http://en.citizendium.org/wiki/Template_talk:Props i have vague memories but nothing concrete. i need to get back into the details again. Chris Day 21:25, 8 February 2010 (UTC)

Agreed. There is a lot of confusion here perhaps because others have sort of jumped in where we left off, but with a not-exactly-identical outcome in mind. Sadly, I recreated the Lithium/Isotopes "sentinel" as best I could and it does indeed seem that the bug which broke the generic "list" for properties is still alive and well.

In any event, I suppose as you suggest, I should clearly state where I was hoping the developments would lead us:

The Mediawiki markup language is powerful enough to enable not just cataloging or "encyclopedizing" scientific information in a text format, but _can_ be used as a type of numeric database as well. See here:[1] Melting points, density, etc. are important information about materials, and I would like to see CZ incorporate a plan that allows these data to be entered, and used in computations on numerous pages. I feel this will enhance our presentation options [2] [3], and help differentiate us from "that other wiki". The data, by convention, should not be replicated in every page it is used in, it should be referenced from a central source. Then when we get better data, updated measurements, or a contradictory finding, all instances will automatically be updated by a single correction.

But there is more to these numbers than just sticking a value into a page or template. The measurement conditions and dependencies, units, procedures, etc. may indeed need to be specified, disputed, revised, sent to subcommittee, re-disputed, lost, found again, and will hopefully, eventually, be correct. There are also related technical issues of units, measurement conditions, and precision/accuracy.

It is for these reasons that I had been pursuing the "subpages" approach. It seemed to me the most obvious solution to the technical problems inherent in implementing what I've suggested here...and it works.--David Yamakuchi 22:22, 8 February 2010 (UTC)

About the Freezing point in the Water article's table of properties

David, I don't intend to make an issue of this. But I really don't see why the words "Not Measurable" need to be explained by linking to a new page Water/Freezing Point by using yet another template that many of us are unfamiliar with. The same thing could have been done by simply adding a reference (footnote) to the words "Not Measurable" and having the explanation be in the reference section at the bottom of the article ... rather than having to go to that new page.

I also don't understand why you use "Freezing Point" instead of "Freezing point" when we already have "Normal boiling point", "Critical point" and "Melting point". Seem inconsistent, doesn't it?

As I said, I don't intend to make an issue of this. I simply ask that you consider using a brief footnote reference instead of a new page. Milton Beychok 06:55, 9 February 2010 (UTC)

Hi Milton, it's actually technically not a template. I guess they call this a subpage with a "transclusion". I know, it sounds like a $5 word to me too, but there it is.

What I think is clear is that the need for a subpage in this case (or at very least a lengthy discussion) is caused by the need to explain that the freezing point of water is "not measurable". Sitting here in Chicago this morning looking out at the snow falling, I think some folks will want to know more about how we can say this. But it really doesn't make sense to me to clutter the main article with it...it's kind of obscure. Paul Wormer and Richard King arrived at this same conclusion in 2007. A discussion doesn't really seem to fit well in the "references" section either. That would be for a reference to some non-CZ work or publication. A subpage is the only logical choice, unless we want to include the discussion in the main article...which it appeared you did not. Or unless you have other suggestions?

Also, I'll move the subpage to "Freezing point" as you (most correctly) suggest. I had forgotten the convention on capitalization.--David Yamakuchi 15:21, 9 February 2010 (UTC)

More about the freezing point in the Water table of properties

David, the the value of the Freezing point now reads as 0 C* . What happened to the "Not measurable" that I thought was wanted there? Wasn't that the main thrust of your original comment about the Freezing point in the Talk page of Water? Milton Beychok 05:26, 11 February 2010 (UTC)

More about the freezing point in the Water table of properties

David, the the value of the Freezing point now reads as 0 C* . What happened to the "Not measurable" that I thought was wanted there? Wasn't that the main thrust of your original comment about the Freezing point in the Talk page of Water? Milton Beychok 05:27, 11 February 2010 (UTC)

Chris Day has now reverted it back to "Not measurable". So all is now well (if it just stays that way). Milton Beychok 06:18, 11 February 2010 (UTC)

Yes, Peter Schmitt had changed it. You can look at the history to see who changed what if you have these questions in the future. He also deleted the Water/Freezing Point redirect to Water/Freezing point, which broke the table in Water. I have now repaired it.

This is the reason I want to reiterate how frustrating it can be for folks to just go around deleting stuff.--David Yamakuchi 15:38, 11 February 2010 (UTC)

David, I understand such frustration. Perhaps rather than the free-for-all wiki environment, we need to look more to software engineering. From a UNIX-ish standpoint, it sounds like articles using your templates might need the equivalent of a makefile, with source code control flagging potential deletion of a component.

It's not generally realized that software editing is different than content editing. --Howard C. Berkowitz 15:58, 11 February 2010 (UTC)

The process we have at CZ seems to be (almost perfectly) preventing this type deletion. Most of the subpages that are in question have survived despite numerous attempts to delete them. There have been a few exceptions, and so far it hasn't been too difficult to correct them on a case by case basis. Educating the CZ Constabulary would likely fix this entirely...If it were not for a few folks that seem bent on removal of others (and their content)...we wouldn't be having this discussion--David Yamakuchi 16:06, 11 February 2010 (UTC)

In the long term, it isn't going to be the Constabulary's job to make the decisions as to what will go and stay. Just as we have content editors, I believe we will need to have an equivalent software function. This isn't to single you out; there have been other surprises from bots and templates, which can have wide-ranging and unexpected impacts.

I've been a developer and development manager long enough to be cautious of software changes that neither address a stability/performance need, or a need expressed by the end users. While I agree there should be a "general science and technology" group assessing things that cross workgroups, I am puzzled why there is insistence on implementing a feature that the Chemistry Editors don't seem to want. Howard C. Berkowitz 16:41, 11 February 2010 (UTC)

(reset indent)

The technique is a solution to a number of problems that _has_ been asked for by users like this:

http://en.citizendium.org/wiki/Talk:Water#Freezing_point

and this:

http://en.citizendium.org/wiki/Talk:Periodic_Table_of_Elements#visibility...pt1 It also enables a whole range of things we haven't even considered yet...I think.--David Yamakuchi 17:03, 11 February 2010 (UTC)

A reminder

David, may I kindly remind you that -- as far as I remember -- it has not yet been resolved whether single properties should be stored on subpages or not. --Peter Schmitt 20:16, 10 May 2010 (UTC)

However, while the debate rages on (or not), I seem to be able to make useful progress in the meantime.--David Yamakuchi 20:19, 10 May 2010 (UTC)

I would also prefer a more cautious approach. For instance, if we go by the single-properties pages, I think it is better for them to be integrated into the {{subpages}} system, which would work best if the titles were Europium/Properties/Atomic mass instead of Europium/Atomic mass. Also, I think the formatting of the sources of information could be improved (suggestion), and there are probably more things to consider. So I strongly suggest that you stop creating those single-properties pages and instead choose one element on whose cluster we can discuss and test possible ways of structuring this information. Once we have reached consensus there, existing clusters will have to be reformatted accordingly (which will probably involve bot activity, for which your help would be very welcome), and then we can go on with elements for which no cluster has been started yet, possibly even by means of dedicated preload templates. --Daniel Mietchen 23:58, 10 May 2010 (UTC)

Daniel, I believe I understand your preferences. But the idea of Material/Properties/(specific property) was examined at length nearly two years ago here[4] and here[5]]. Two years later and I am hearing (again) that I haven't spent enough time thinking about this. :-( Also, the /Properties subpage _is_ supported in the subpages system. It should be working in conjunction with the /Properties/List "subpage", but there is a bug in CZ's template rendering logic that prevents that (see here[6]). I've been waiting for that entire time (nearly two years)...it would seem...and we have failed to reach a consensus. And, as you point out, bots can easily rearrange the data in whatever way is desired...but only after the data is entered! So I intend to proceed at my own discretion.

As for formatting of sources, we could see if we could get {{unit}} to pass references properly (yet another CZ template bug if I recall), and *that* would allow us to pass the "sources"...as "references" to whatever page eventually uses the data...

The sad fact is that in the time it took me to review the two year old discussions, address your points, and find and re-read and link to everything that's already been said, we could have had a cluster for every element...with definitions, a nice little info box (if I do say so myself), and lots of the basic info that we are going to want somewhere in the article cluster regardless.

If you'd like to go ahead and _work_ on some other ideas on how to store properties, let me encourage you to review here[7]...I think you may have seen this one previously...--David Yamakuchi 00:57, 11 May 2010 (UTC)

Sorry, repetition is part of a community project — I was not part of most of those discussions back then, and knew next to nothing about templates. I do not doubt that you have thought deeply about this structure, but if the reasoning is obvious for you, this does not mean that it is for others. If you find bugs in templates, please file them via Bugzilla, so that we can work systematically on them and track progress. I agree about the bot restructuring requiring data entry first. I do not like your _underscored statements_ — I know that "the /Properties subpage _is_ supported in the subpages system" and wouldn't have made my suggestion otherwise (again, I am not aware of all the prior discussions), while I don't know whether to take the second one as an accusation or assignment, neither of which I find appropriate. --Daniel Mietchen 02:02, 11 May 2010 (UTC)

OK, now I'm sorry. I was frustrated. I could conceivably complete a stub article with all "standard" subpages for every element today...but I got sidetracked here and with Ormus.

My poorly worded passage _was_ an accusation...but not a very valid one. I see that you are doing a lot here at CZ, so please accept my apologies. It's just frustrating to have people keep saying "Hey! Why not try..." and then suggest something I've already pulled my hair out about for weeks. And that's just from the ones that think the {{subpages}} was a good idea in the first place. From everyone else it's just "I don't understand" (with the subtext "...and I don't want to".)

BTW, I think I actually tried entering the bug in Bugzilla back then too. I _will_ make it a point to "ping" that again, but probably not today :-) Cheers! --David Yamakuchi 02:58, 11 May 2010 (UTC)

(unindent)
David, the difference between your project and some other project is simply that it involves creating hundreds of subpages before it is decided whether they are welcome or not. Making decisions in a community always is a slow process, but you should be aware that it is even more slowed down by the effort to ratify a Charter, and that you are using a governance vacuum for your activities. Certainly they would require review by EC or MC, but unfortunately they are not functional now.

As for the subpages template: I do not think that it is a good solution, and I am in good company (Daniel and others). Thus it is reasonably certain that it will be reviewed, and probably replaced. Property subpages will only complicate the transition -- another reason to wait with them.

And last but not least: Editors from chemistry and physics are not happy with this system.

--Peter Schmitt 12:40, 11 May 2010 (UTC)

Peter, you say my contribution is different and that the subpages are not wanted, but you seem to ignore the fact that the information they contain is! Daniel himself placed the template that put the info into play on the live wiki. I did not do that because I wanted to see at least one other person that endorsed the end result. I now have that.

Yet again I am receiving the message "your contributions are not welcome here." So yet again I will return the challenge:"If you have a better way to accomplish the same functionality, then by all means present it!" Unless you present a working alternative, I will continue in this pursuit.

Frankly, I don't care if you'd like to call it bold or balderdash. FYI my opinion is that your suggestion that I am "exploiting a vacuum"...well...sucks!...not to put too fine a point on it. Or perhaps what I mean to say is that it's nonsense...totally unfounded. Don't hate the guy that has something that works just because you don't. There, now we all have voiced our opinions. The system I developed is working, and would work even better if we could get the template rendering bugs fixed. I encourage you to focus your efforts on real, actual problems, that we face, and ask you to please stop interfering with progress unless you have constructive suggestions. Thank you.--David Yamakuchi 16:40, 11 May 2010 (UTC)

David, why do you tend to get unfriendly when one tries to argue with you? I did not say you should stop because I do not like it. I said that this is a matter that requires a community decision (or at least a decision by the relevant workgroup editors), that such a decision has not been made, and that (unfortunately) it will likely not be made in the near future. And that you should not take advantage of this fact. --Peter Schmitt 17:34, 11 May 2010 (UTC)

I frequently try, when I have a little time, to fill in "wanted" pages in general, and certainly things that are red links for my articles. Now, I'm not a Chemistry Editor, but I was an undergraduate chemistry major, and do a number of Military and Engineering things where elements are important. Nevertheless, just for some feedback on usability, I have not created any element pages, even when redlinked from an article of mine, because the learning curve -- and pure data entry of multiple subpages -- is too steep for me to justify the effort.

Perhaps if there were a forms preprocessor that let the data be entered without the need to create and save every subpage, I'd pull out some of my chemistry handbooks and fill in a few. Right now, however, the subpage properties system is daunting for someone who would use it occasionally -- and no, computer literacy isn't the issue. As a long-time software developer, I tend to be cautious in introducing new features, especially when there is no requirements review and approval. Howard C. Berkowitz 18:25, 11 May 2010 (UTC)

Howard, If you'd like to create the Tin article, it's now the only element left red-linked. Also, I've already written the data entry tool you speak of. It is called {{Periodic Table of Properties}}. Currently set up for density numbers, it works for any general property type. If the documentation does not make it easy to use, please let me know and I will attempt to improve it. Personally, I have been using "Open in new tab" in Firefox, which actually lets me enter the data pretty quickly. Moreover, once entered, all information can easily be centralized with a bot as Daniel points out above, and I certainly have no objection to helping with that...I understand that is how we would like it to be.

Problem is it currently can't work that way in terms of multiple "views" of the same data...like periodic tables *and* "properties" subpages both displaying the same specific datum. In the mean time, I have chosen to begin including the data. I see this as being constructive. --David Yamakuchi 20:07, 11 May 2010 (UTC)

Nice piece, Electronegativity

Informative, thanks. Anthony.Sebastian 15:26, 17 June 2010 (UTC)

It is kinda negative, though. :-) Howard C. Berkowitz 16:19, 17 June 2010 (UTC)

Nothing in particular

Hi, Dave, it's just always nice to see you around! Aleta Curry 22:49, 16 January 2011 (UTC)