User talk:Chris Day

The account of this former contributor was not re-activated after the server upgrade of March 2022. ——————————————— Chris' Talk Page ————————————— I am an editor in the biology workgroup | 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, Current talk page (31,501)
The account of this former contributor was not re-activated after the server upgrade of March 2022.	The account of this former contributor was not re-activated after the server upgrade of March 2022. Useful links on Citizendium Myths and Facts Biology Workgroup How to get started How to Edit The current policy outline Forums for discussion Biology forum News Community blog

Notes to self

For catalogs.

• Specific subpage categories are now placed on talk page so do not trail the extended subpage name for every entry when seen in the subpages categories. See {{Talk Always}}.
• Extra/Optional subpages categories are on all subpages except for the default ones. These give lists of all optional subpages in a particular workgroup and thus require the subpagename so they can be distinguished for each article. See {{All Subpage Content}}.
• {{Catalogs header}} is now only used for the header. The footer is not used for anything at present.

• To-Do: Need to consider where the sub-subpages fit into this scheme, should probably do something similar.
• All approved talk pages will need to have the following format for this scheme to work:

#REDIRECT [[Talk:Dog/Draft]] <noinclude>{{Subpages}}</noinclude>

Category:Move def

Category:Need def

Category:Delete def

Category:Definition Only

Category:Related Articles Only

http://en.citizendium.org/wiki/Special:Movepage?wpReason=Testing&wpOldTitle=Article_name&wpNewTitle=Article_name/Sandbox

http://en.citizendium.org/wiki?title=CZ:Proposals/New&action=edit&section=new&preload=Template:Proposal_blank

font-size:0.7em
font-size:0.8em
font-size:0.9em
font-size:1.0em
font-size:1.1em
font-size:1.2em
font-size:1.3em

Category:Metadata to finish

Category:Misplaced subpage

Category:Unexpected subsubpage

Category:Incompatible editor status

Category:No metadata template

Category:Incorrect metadata pagename

Category:Articles_with_Ambiguous_Status

Category:No approval page

Category: No talk page

Category: Orphan subpage

This page uses content from Wikipedia. The original article was at Chris Day. The text of Wikipedia is available under the GNU Free Documentation License.

• Need to ^figure out why basepagename does not work with some characters. Is this a problem for the normal function of the template? Need a way to figure out when basepagename and pagename in metadata template are different. Most likely after a move. Since the old name will still exist as a redirect this error catch will not detect such examples. Chris Day (talk) 19:05, 19 March 2008 (CDT)
• What to do with subpages with out a main article. i.e. Charles, Prince of Wales. And why is this one getting the pagename warning instead of the no metadata/no article warning? Need to readjust these warning plate parameters and add a new template saying no associated article. Possibly have some of the parameters shown on the tempalte so a judgement call can be made as to whether to delete, move or create a new cluster. Possibly make less conspicuous on floating subpages in case that is desirable. Chris Day (talk) 19:47, 19 March 2008 (CDT)
• Turns out that the capitalalization does matter if using subsubpages. The tennis subsubpages is an example. Any time a string such as Template:Article name or Talk:Article name is used it will crash the template. Can catch this by checking for if the subpage is one of the three that can support subsubpages yet gives a misparsed subsubpage. Will be in the unexpected category.

• User:Chris Day/Metadata
• User:Chris Day/Metadata error
• User:Chris Day/monobook.js
• User:Chris day/newmessage
• User:Chris day/papers
• User:Chris Day/pinkwich5.js
• User:Chris day/sandbox
• User:Chris Day/sandbox
• User:Chris Day/sandbox1
• User:Chris day/sandbox2
• User:Chris Day/sandbox2
• User:Chris day/sandbox3
• User:Chris Day/sandbox3
• User:Chris Day/sandbox4
• User:Chris Day/sandbox5
• User:Chris day/sandbox/approval
• User:Chris day/sandbox/doc
• User:Chris day/talk header
• User:Chris Day/talk header
• User:Chris day/talk toc
• User:Chris day/useful links
• User:Chris Day/Userplan
• User:Chris Day/watchlist
• User talk:Chris day/Archive1
• User talk:Chris Day/Archive 1
• User talk:Chris Day/Archive 2
• User talk:Chris Day/Archive 3
• User talk:Chris Day/Archive 4

Keep these template for Template:Subpages2 the vertical version of subpages. I will probably develop this into a workgroup core articles template.

• Template:Approved2
• Template:Button off
• Template:Button on
• Template:Checklist2
• Template:Checklist4
• Template:Checklist5
• Template:Default
• Template:Default button 2
• Template:Metadata
• Template:Optional
• Template:Optional button 2

Note to self: need a subgroup version of Template:Wk gp tbl

[[{{{subgroup}}}|{{{subgroup}}} article]]	[[:Category:{{{subgroup}}} Subgroup|All articles]]	[[:Category:{{{subgroup}}} Subgroup_Draft|Draft]]	[[:Category:{{{subgroup}}} Editors|Editors]]
	Recent changes	Recent changes	[[:Category:{{{subgroup}}} Authors|Authors]]	Mailing list: {{{mlist}}}

Cool template

Check out Sophophora and {{Clade}}. J. Noel Chiappa 11:36, 3 June 2008 (CDT)

what is our comparison way of doing this type of workgroup statistics?

I saw this the the wp:med site http://en.wikipedia.org/wiki/Wikipedia:Version_1.0_Editorial_Team/Medicine_articles_by_quality_statistics

and then inserted in to their "project" here: http://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Medicine

What is the CZ equivalent to that type of stastics table? It seems pretty useful. I especially like how it is easy to get to the "unnaccessed" articles. Tom Kelly 16:21, 3 June 2008 (CDT)

We have the Checklist-generated categories for Health Sciences (see the bottom of the workgroup header). Wikipedia seems to have a bot that counts the number of articles in each category and then updates the table. We'd have to do it manually here is the current state:

805 Articles

4 Approved [0]

46 Developed [1]

289 Developing [2]

395 Stub [3]

63 External [4]

46 Advanced [0-1]

339 Nonstub [0-2]

734 Internal [0-3]

Note that the number of articles is 805 but those with status of 0,1,2,3, and 4 is 797. From this you can infer there are eight Health Sciences articles that do not have a designated status in the metadata template. Chris Day 16:35, 3 June 2008 (CDT)

Just noticed that approved articles are not added into the advanced [0-1] category. I've fixed that now. Chris Day 16:56, 3 June 2008 (CDT)

Definitions meet hover

Check out this, and my reply here. J. Noel Chiappa 11:55, 4 June 2008 (CDT)
PS: Time to archive your talk page! (I just got done doing mine...) J. Noel Chiappa 11:55, 4 June 2008 (CDT)

IsoData and Properties differences

Hi Chris, I looked at your work on the {{Props}} and {{Properties}} templates.

FYI:I changed the {{Properties}} call in {{Props}} back to make it a table entry. Now the problem with the curly braces is back. (the closing braces get included in with the last data "segment".) Curiouser and curiouser. Not sure if this is an indication of what is going on with the data parsing, or if this is an all new wierdness. I also changed some of the {{!}}'s back to pipes, and put a carriage return after each data member in the :List (oh, and I pointed Props back to "Material/Properties/List"...just trying to keep this as simple as possible...

PS: Thanks for taking time to look at these templates...your help is appreciated.--David Yamakuchi 13:15, 5 June 2008 (CDT)

Proteins

Chris, I am not sure quite how to define protein, but they are basic building blocks of muscle, for example, and also cells walls, etc., and of course that still leaves all of the enzymes. David E. Volk 15:56, 5 June 2008 (CDT)

Props

"Credit" where it's due  :-) ...You solved it. Kudos to you Chris. The conditional stuff looks like it works ok now too. --David Yamakuchi 16:12, 5 June 2008 (CDT)

So, I'm curious - what was the problem? I see you put the table inside the conditional - was that it? J. Noel Chiappa 16:26, 5 June 2008 (CDT)

Never mind - I saw your message to David. So it was the table, huh? No idea why that fixed it - unless there's something to my theory about the parser/preprocessor getting confused between the "|" in the table, and the "|" used in template calls to separate arguments. J. Noel Chiappa 16:34, 5 June 2008 (CDT)

Properties Template

I think I may have stepped on your edit...sorry. I think I have the calls to the data pages worked out, but I'm about to walk out the door for the weekend, so I just wanted to put the thing somewhere so someone doesn't duplicate effort.--David Yamakuchi 16:18, 5 June 2008 (CDT)

I'm out for the weekend now if you'd like to keep going. Sorry about the confusion, but I'm late....:-(--David Yamakuchi 16:23, 5 June 2008 (CDT)

Hi Chris,

You asked a couple of good questions...let's take them one at a time...

• would it not be more appropriate at Unobtanium/Properties/Atomic Mass

I thought about this one to the point that I had decided that it was exactly the thing to do...and then I didn't implement it that way. In fact, it was so bad I caught myself a number of times almost errantly introducing exactly that syntax...probably just up too late to be quite frank...sort of like right now...

Anyway, the bottom line that I came to in my reasoning is that when we store these types of data in subpages of a material article, that simple fact in some sense already says that it is a property of the material. Or we can just look at: P.R.O.P.E.R.T.I.E.S. ten letters that are just not really necessary, and then ten more each time you retrieve the data...well you get the idea, why make the name longer than it needs to be?

• why not have all the properties on one page, similar to the switch you have for the isotopes, would that not be simpler?

I think you actually discovered the exact path leading to the move to seperate the properties onto their own pages...Let's see if I can recap...

The physical properties template got big fast...real big. And all indications were that if the scheme were to continue, it was going to get nothing but worse. The real problem with having all the data on a single template with a switch to give only the data called, is that the wiki "compiler" has to load the entire template every time you want even a small bit of info.

This is especially a problem if you are trying to list the whole set of data...the size of the pre-expand data grows at a rate of n squared (each time you add a bit of data, it gets called into memory...with every bit of data) this is perhaps not a good scheme for a large database...maybe it's ok for a small one. It is even more obvious what the answer is when we compare it to the pre-expand size growing at a rate of plain old n if we just store the data in regular pages.

The thing is, as you point out...it seems like there should be one page a reader can go to to see all of the data at once. Of course, by this we don't mean the main article mind you...that one then would be too cluttered. Thus the Isotopes subpage, or the properties subpage, or the MSDS, or whatever you want to call it...I'm not real sure we won't want both an MSDS and a Properties page for most "materials" with some duplicated info in many if not all cases.

Now, if you look closely back at the old versions of the IsoData template, you might find where I first tried this scheme by breaking out the data for ⁶Li in it's own template. I was having trouble with Lead's Isotopes page (Lead, I seem to remember reading somewhere, has the most stable isotopes of any element, and also has a great many long-lived radioactive ones...it was a good test...but one which the scheme failed...miserably...the old n² problem strikes again!)

In any event, it blew up the IsoData template because the pre-expand size was so big. The server would take a half hour to return the page and it was on the edge of crashing things I think. And Isotopes should be easier than physical properties...there are only so many of them. Apparently however, lead has enough of them to cause a problem...or perhaps I should say illustrate the problem.

Now, I'd already had the list idea worked out for the Isotopes, so I just decided to heck with it. If you want to know the Melting point for Foo, it can be found at Foo/Melting point. End of story. Things don't blow up and there is consistency and now that you have helped get the properties template working, we can show them all on a single page...Properties...or whatever people would like to call it. The downside for me is what it means is tossing out a bunch of templates (read as alot of work)...so I've been procrastinating :-)

There was one more thing with these properties tho...It's been buging me for a while and I think this fixes it too.

Let's say for the sake of argument that we want to compare the melting point of Hydrogen to the melting point of Iron. Obviously the actual measurements will be done at least somewhat differently, and probably quite differently indeed. With their own pages each property can easily have a significant amount of "metadata" attached. A :Foo/Melting point/Measurement_method page could give us valuable insight as to how we arrived at some particular measured or calculated number.

Sorry this post is so long but...well you asked. I think I'll copy and paste it into the Talk at {{Props}} for other folks as well.

Adios

--David Yamakuchi 02:25, 8 June 2008 (CDT)

Dismabiguation subpage

Umm, because I'm a moron unimaginative tree-shrew? :-) (The ref is to King Solomon's Ring - not sure if you've read it, wonderful book.) Mostly because that's the syntax WP used, and I didn't think to change it, but you're right, a subpage would be more in keeping with CZ style. Is there any technical advantage, past the ability to use {BASENAME} to get the term being disambiguated, to a "{Basename}/Disambiguation" subpage, over "{Basename} (disambiguation)"? J. Noel Chiappa 16:34, 5 June 2008 (CDT)

PS: I don't see any good reason to have a {{subpages}} header on a disambiguation page. For one thing, there's no main article page at {BASENAME}. For another, there are unlikely to be any other subpages that we need to get to through the subpage navigation bar. And special-casing {subpages} for disambiguation pages will just make it more complex, and for no good reason - it's kind of like making a combination hammer-screwdriver, just so you don't have to put one tool down to pick up another. I think people can deal with the concept that they have to use a different name on disambiguation pages.

I agree that it's a pain to have to put the pagename into {{dabhdr}}, but it we could get the strings: package installed, we could fix that. Still, I'm not against using a subpage - I'd be perfectly fine with either. But if there's a good reason to use a subpage, we should decide quickly, before too many "{Foo} (disambiguation)" pages get created. I'll see if Larry has an opinion. J. Noel Chiappa 06:07, 6 June 2008 (CDT)

Perhaps I got Chris wrong, but I had seen this in the context of the discussion on sub-subpages. So what I understood is that he proposed to have a "Foo" page and to include "Foo (tree)", "Foo (shrew)" etc. as subpages thereof. "Foo (disambiguation)" and what is now sometimes "Foo (general)" could then be put into "Foo" directly, and we would avoid all the redirects. Of course, then, we would require that if the "Foo (shrew)" subpage is open, a click on the "Related Articles" subpage link would automatically lead to "Foo (shrew)/Related Articles", and I have no idea as to whether this is any close to feasible at the moment. -- Daniel Mietchen 06:42, 6 June 2008 (CDT)

I think you misunderstood my idea. I was thinking of having the disambiguation page on a subpage of the disambiguated term not on the term itself. The term would still be a redirect, but in this case to its own subpage. I had not thought much of this new scenario you suggest and that might work too. Chris Day 10:16, 6 June 2008 (CDT)

I'm not sure that's such a hot idea, myself. Those are freestanding article in their own right, not in some sense 'part of' (in information terms) a related group of information; they are related by their names only (usually). Also, they will have their own subpages, etc, etc, so now we'll have some articles with the Biblio subpage at {Foo}/Biblio, and others at {Foo}/{Bar}/Biblio, which I think will also be confusing. J. Noel Chiappa 10:43, 6 June 2008 (CDT)

This was not what i was thinking. My rationale was to have everything the same as now except that Foo (disambiguation) would live at Foo/Disambiguation. The only advantage is that the subpages template can be placed there instead of the disambiguation templates (The disambiguation templates would be placed by the subpages template automatically). So, Foo would be a redirect and nothing else would exist at the Foo cluster (except Foo/Disambiguation), all the original subpages and metadata associated with the old article at Foo would have been moved to the disambiguated article at Foo, bar or Foo (bar). Does this make sense? Chris Day 11:56, 6 June 2008 (CDT)

No, I understood all that - my reply immediately above (at 10:43, 6 June 2008) was to Daniel's idea. I'm still thinking about your idea. My appeal to Larry for comments got no useful response; maybe one of us should have posted it on the Forum instead? J. Noel Chiappa 12:07, 6 June 2008 (CDT)

Ah, crossed wires. I think dialog here to think it through is a good start. If it is desirable then this can be a relatively minor amendment to your original proposal.

You're right that strings would solve some of these issues, at least i think so. Does strings allow us to do an argument along the lines of {{BASEPAGENAME}} - (disambiguation), with the output of Foo from an article named Foo (disambiguation)? Chris Day 12:11, 6 June 2008 (CDT)

Actually, I had to change my proposal a tiny bit in response to unhappiness from some editors, who didn't like having to have to look up and type tree (plant), etc, etc. I had originally proposed what you thought - i.e. pretty much all basenames, with a few exceptions, redirect to the disambiguation page.

However, to keep them happy, I changed it to be 'if there is a most common meaning, the redirect can be set to that meaning'. It basically transfers work from people who write articles, but don't feel like checking their links, to the people who are checking disambiguated names, and fixing articles which refer to them.

Since it kept the heart of my proposal (making it easy to find links to ambiguous terms) intact, I felt it was better to give ground on that, than to have some people unhappy. And once the new system is adopted, perhaps after a while we can revisit the 'set the basename redirect to the most common meaning' issue.

So that's why we have {{dabbox}} in use; on articles where the basename redirect points at that article, rather than the disambiguation page, that header is needed to send people who get there, by going to the basename, to the disambiguation page. J. Noel Chiappa 10:43, 6 June 2008 (CDT)

This makes sense now. It would be better if the template could be added automatically but, unfortunately, I don't see a way to actually detect where a disambiguation redirect points too. Chris Day 12:04, 6 June 2008 (CDT)

As a general rule, I at least would like to be specifically informed whenever any new subpage type is created, and given a pointer to an explanation of why it's needed. As I imply below in response to Richard, we generally require editorial approval for new subpage types. Please see CZ:How to add a new subpage type which is still in effect. I believe this should also be added to CZ:Bold Moves, if not put into CZ:Proposals. So--is there in fact now a "Disambiguation" subpage, and if so, where is it explained? TIA!  :-) And, sorry for not keeping up. --Larry Sanger 09:16, 6 June 2008 (CDT)

new subpage

Can we get a new subpage category called "Primary sources" --the history articles will be using it to include texts of famous documents. Thanks. Richard Jensen 17:23, 5 June 2008 (CDT)

Richard or Chris--please make sure that you run this by the Editorial Council. It does not have to be a big deal (it could be passed by acclamation perhaps), but I do not want new subpage types made simply because one editor asks one technical guy. The general idea looks good to me, as long as we distinguish this type clearly from both Bibliographies and from Works subpages. --Larry Sanger 08:38, 6 June 2008 (CDT)

Wierd bug

Check out {{Dambigbox}} and see if you have any idea why that fix I just made (to allow a blank first argument, and use the {PAGENAME} if so) doesn't work. The odd thing is it works fine when you display {{Dambigbox}} (as you can see), but when you use Dambigbox on some other page, it doesn't. Wierd... J. Noel Chiappa 11:05, 6 June 2008 (CDT)

Wow!!! Do we really need all of this?? Or are you just seeking comments??

Chris, in your test layout of the Chemical Engineering subgroup, we now have:

1. An alphabetic list in two colums of all articles, with the status of each article
2. An alphabetic list in a single column, with the status and the definition of each article
3. A list of all the articles in four columns, one column for each status category (0, 1, 2, 3,or 4) and without the definition of each article
4. A listing of any subcategories in the subgroup (and the articles (pages) in those categories) without the status or definition of each article
5. A listing of the page articles (pages) in the main Chemical Engineering subgroup without the status or definition of each article

For what its worth, I think that the only one we need is item (2) above with the following caveats:

• Put a single space into the single column list to separate articles starting with A from articles with B from articles starting with C .... etc.
• Include a one-line footnote (as I have done on my user page) to explain what each of the little status images indicates.

In other words, we would then not need items (1), (3), (4) or (5). The result would be quite a departure from the current style of listing articles in the various categories (which are modeled after the way it is done in Wikipedia) ... but I think it would be better than the current method. - Milton Beychok 03:43, 7 June 2008 (CDT)

Idea for another subpage

Chris, see Biology's next microscope: Mathematics and its Talk page.

What would you think about a subpage: Citizendium-developed open-access articles?

We could take an open-access article, give ample attrbution to article's originator, open it to group editing, monitored by the main Workgroup (or a select group of its editors).

For the article Biology's next microscope: Mathematics, we could subpage it to Mathematical biology, or subpage it to more than one main article (e.g., Biology, Systems biology, etc.).

Thoughts? --Anthony.Sebastian 23:03, 7 June 2008 (CDT)

Thanks awfully...

...for filling in items at the category:dogs.

I very much like the sorting by status; it's a quick visual and lets editors keep track of how things are coming/what should be worked on.

Naturally, the auto sort into the category in alpha order is vital, too. So I would say, keep at least these two functions. I'll explore the chemical engineering subgroup to see which other ones I like.

Aleta Curry 16:58, 8 June 2008 (CDT)

How to add a 4th category?

Chris, how does one add a fourth category to an article? The Metadata template doesn't seem to allow it. Can we simply add it on the Edit page of the Main page? Or what? Thanks in advance, Milt Beychok

It's not possible at present. Are you thinking about the EPA article? The practice, to date, has been to pick the three most relevant.. There have been a few discussions in the forum. I'll try and root one out. Presumably there are five possible workgroups for this article; in no particulr order, Biology, Health Sciences, Politics, Engineering and Earth Sciences. For the record, if it was me, I would have chosen Biology, Politics and Engineering. Chris Day 03:31, 9 June 2008 (CDT)

Properties Storage

Hi Chris,

Yes, I agree, the lack of a string parser in CZ is going to cause us some asthetic difficulties...almost certainly. But, I'm not clear that it would preclude the scheme I'm proposing.

FYI: The periodic table has become a sort of a back-burner project lately. I seem to have gotten into a much bigger issue here as a result of exploring it, and I think I might like to wait and see if or how this properties thing develops before I decide on how I would like to proceed...

You are of course right that a properties template can be made for each material with a switch/case to call up the relevant data for a user or template, and if we restrict the number of allowed properties, it can work ok...No huge pre-expand problems if the number of properties is kept small. I looked at that approach, and I have two concerns...

1. Restricting the types of properties that work with our scheme just seems like a bad idea at a fundamental level. I'm not sure how inclined I would be to support such a scheme, at least with what I am aware of today. After consideration, I discarded the idea as not being as flexible as what we might hope for.
2. The properties scheme is not just for elements. It seems like it should work for any type of material, and that would make choosing relevant "selected" properties even more difficult.

Also, I'm not sure I agree that the properties values, even for elements, will not change in the future. Someone may discover a new "mass error" or different way of testing/measuring, and things _will_ change...I've become more than certain of it...I guess "resigned" would be a better word.

Finally, I wouldn't be sure which of the properties other authors might want in their tables and charts, and I think if we can avoid restricting folks with "standard" properties vs. special properties we might be a lot better off. I say this in part because of what I have seen going on with the new subpages types which, BTW, I am a big fan of...naturally--David Yamakuchi 04:28, 9 June 2008 (CDT)

I should point out that many of my points are really a devils advocate argument. I do see where you are coming from. Chris Day 11:08, 9 June 2008 (CDT)

Check it out... {{PTofE}}

--David Yamakuchi 16:13, 11 June 2008 (CDT)

Using workgroup template as news feeder?

Hi Chris, what about using {{Workgroup}} (or a derivative) – on individual pages in the user namespace – to display Workgroup news (especially to do lists) that could be edited at a central location (pereferably the individual workgroup's homepage). -- Daniel Mietchen 11:59, 9 June 2008 (CDT)

That's a good idea and should be quite easy to set up. Chris Day 12:19, 9 June 2008 (CDT)

Help help help with metadata page

I'm messing up with Federation Cynologique Internationale. The metadata [[Template:Fédération Cynologique Internationale > Metadata]] doesn't work--is it because of the accents? Are we supposed to use accent marks in naming articles?

Also, this is a tricky naming one since the correct name is in French. It is *never* known by an English language abbreviation, it is ALWAYS the FCI, with non-French speakers struggling to get their tongues around Federation cynologique internationale, so I named it that, but...?

Aleta Curry 17:07, 9 June 2008 (CDT)

I'm not sure of the sequence of events here. But if you name the article with accents then the pagename field must have them too. Your problem was that the metadata page and article name did have accents but the pagename field in the metadata did not. Chris Day 20:58, 9 June 2008 (CDT)

property values

The table is resizable. If there is a need, we can just specify it to be wider and fit however many digits is deemed appropriate. I thought about another "feature" too...

Let's say someday we might want to specify the boiling point as not just a single number, but as a boiling point / pressure curve. The new "property" could be named 2dbp or some such and whatever wiki-wizardry needed to make it happen could be saved for later implementation.

For now, it seems like we fit a decent number of significant digits without the noble gas column running off the right side of my screen.--David Yamakuchi 17:49, 11 June 2008 (CDT)