Wikipedia talk:WikiProject Elements/Archive 4

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1 Archive 2 Archive 3 Archive 4 Archive 5 Archive 6 → Archive 10

infobox template conversion

I've finally created a set of test-templates on my user page. See here for a complete index of used templates. These temporary working-pages contain all already converted infoboxes: respectively empty spaces to be filled with the remaining boxes (update: strike that :-)

(Added quicklinks, 15:47, 4 Mar 2005 (UTC)) Improve anything in any way you see fit. The data is based on a month-old snapshot and doesn't include the most recent changes and suggestions I'm afraid, but this seems no biggie since it all eventually has to be verified against the articles in any case. The main objective is to determine a consistent structure.

After ensuring that all works reasonably smooth, the final 'live' templates can be created in the Template: namespace, and all "User:Femto/elem" may be replaced with the real name (until then we need to settle on a base name such as "Template:Elementbox_blabla"). Then the code of the boxes can be merged into the articles one by one.

Completely flabbergasted, I report that most of these boxes wouldn't look bad if put into an article right now as they are—with minor exceptions such as the image names (1), or the isotope data which resisted an easy conversion and still has to be included manually. (There's some commented-out semi-converted garbage code which may or may not be useful as a starting point.) See the beryllium box for a proof of concept that the isotope templates work. (update: strike that too, for the most part. There is still some isotope stuff to be done, mainly converting multi-row entries of data which I have no clue about.)

  1. The comma in the "appearance"-image-name (such as "Li,3.jpg") seems to trigger a bug, which causes the (otherwise valid) space before the template parameter delimiter to get parsed into an underscore. Just leaving the space out doesn't always fix it. Any hints? Something with the template? Move/rename these images?

I gather there are different versions of the TableImage.png, one scaled-down, and some thumbnailed TableImage-BIG.png's (which aren't all converted yet..?) What base name can/should be used, or does the fixed extension need to be moved out of the template into the parameters to enable using both versions?

Now would be the ideal time to discuss major rearrangements to the infobox structure, and to include any improvements that were postponed because they would have been too difficult with separate pages. Establish which units are used (this determines which special templates are worth to be created). It's still simple to change all template names, move, split, or merge table entries and such, with just a few global search & replace actions on the temp pages.

Femto 21:37, 16 Feb 2005 (UTC), 14:03, 25 Feb 2005 (UTC)

I think it would be easier with a single template instead of many. For personal training purposes – and perhaps for common use also – I "stole" the shopping list of templates (Chemical element infobox begin, Chemical element infobox entry, etc) and put them all together in one Template:Element. I have made a test element, User:Eddideigel/Hydrogen. Could this be useful? I haven't written the instructions yet, but there are just a few tricky bits, including Title_color (becomes black if undefined), Ionization_potential (potentially difficult in case of multiple potentials), and Isotope_table (verrrry difficult, but good result if filled in properly). --Eddi (Talk) 03:07, 1 Mar 2005 (UTC)

Having worked with all of the data, I've come to the firm conclusion that using a single template (or just a few) in a consistent manner is an outright impossible option. There are too many special cases in the way the data is organized. Some elements have unknown properties to begin with (this could be fixed with a separate template beyond Bk). Some have an image, some don't, some elements don't have a group number associated with them, only 92 give a density, 86 heat of vaporization, 79 electrical conductivity, one/two atomic radii, etc. Each would require a special version of the template to avoid empty parameters and things like "N/A m³/mol".—You'd end up with a separate template for each element (technically, though impractical, this would be an option to keep the code out of the article).

However, the "natural" segmentation within a table is along its rows, both visually and in the code. You lose the (anyway hypothetical) ability to change the format of all articles with a single edit of the 'one template to rule them all'. But if you organize the templates split by entry row it's easy to individually customize each data type as much as it needs—and ONLY as much, that's important! Too little restriction by the templates, and we're back to the old format with different units and writing styles. Too much, and nothing can be improved anymore. For example, I'm going to get rid of many "group-???"s in my data with an additional 'periodblock' template instead of the 'groupperiodblock', without affecting the unified period & block link coding of the latter entry type.

I can't overstate how much it helps working on this data to have it split by type on separate code lines of individually labelled templates. For this reason I'm hesitant to even merge the 'obvious cases' into fewer multi-row templates with named parameters. It's still just a bunch of table rows after all, and by joining them in a fixed order you lose the ability to change it—which is good for format consistency, but bad if you want to add something, or leave out a row whose data turns out to be inapplicable to that element. Also, the template titles are an important part of the data, as a key to what you're editing (like "molarvol_cm3pmol"—which I'm fully aware is an abomination, but the only way to write as a title. This is still better than having no unit description at all with the template, and named template parameters would tend to be even more cryptic).

Regarding translation, the code is as easily translatable as it will get without giving up usability. The ultimate pastability between languages would only be achievable through unified but incomprehensible template titles. Right now, all you need to do is replace all occurences of "molarvol_cm3pmol" for instance with "volumemolaire_cm3pmol", create the template at the French Wiki with the appropriate content, et voilà (at least for this part of the data).

Speaking of other language Wikipedias, anybody taken a look at the elements pages in German? Behold! The future of the TableImage locator map: If I got this to work properly...

In above image, the "Blabla" text, as well as the black locator box, are not part of the image, but overlaid onto it. Far as I can tell, this is a perfectly legal and fully documented use under the HTML specifications. Imagine, instead of maintaining a hundred versions of what is basically the same TableImage, just one base image plus the overlay data as true text out of the article code. Putting smaller images into it such as the crystal structure may be possible too (if not, I'd rather put this particular one as separate image into the appropriate infobox entry anyway).

Femto 19:22, 1 Mar 2005 (UTC)

I thank you for this indepth discussion, and I appreciate your experience working with the actual data. In my opinion, however, a template is both content and layout. It is a description of what should be included, and how it should be presented. Although some properties are missing for some elements, I can't see the reason why they should be presented differently. The presentation of missing properties as "n.a." or "???", or whatever, could actually inspire people to enter them. If some properties are indeed nonexistent for certain elements, then, that's no big deal. The information that an element doesn't have a certain property may even be valuable in itself. Of course there should be a threshold for the number of elements having a property before it's put into the template, but such issues would be readily solved on the template discussion page. Properties that are too special should be described in the body of articles, not in a template. Therefore I still think a common single template should be used, and I think it is possible.
I like the new use of the table image locator map, and it gives ideas for other areas. Wouldn't we need a hundred images for the atomic models and crystal structures, though? --Eddi (Talk) 23:21, 6 Mar 2005 (UTC)
Well, it's more a "concept" than a "use" of the locator, but proven to work on the German pages and definitely worth adapting here. There would only be a dozen distinctive crystal structures to include, no problems from there. But I think the locator image should contain little more than just the navigational information, not only for technical reasons. While a single TableImage makes a natural place to integrate all graphical data, it has proven to be hard to maintain. Two hundred separate images may actually be less work than one hundred combined. Also, the best graphical presentation is of no use without an easy to find description of what it means—for this reason I would like these things to go with the table entries and their links.

I agree that simply 'missing' data should be made an eyesore as much as possible. However in my experience, the common presentation of missing properties like "n.a." or "???" has mostly inspired people only to find even more different notational varieties of writing nothing... I did include some "_nd" template variants that create 'missing' entries, but haven't done much else with them since I couldn't tell the "not known" apart from the "not applicable". This information IS valuable, but it does not exist in the current data. I have no reason to believe that the content would improve with a stricter layout any more than that a better main layout could be created through the individual styles of the content. So you're right, it's both, each approach with its pros and cons. I will continue to work with single row entries though, which also have the advantage that they are easily converted to other layouts if necessary. Femto 16:25, 7 Mar 2005 (UTC)

Rare Earths "stimulate the metabolism"?

Many of the rare earths (see Samarium for an example) are listed as having a biological role of "has no known biological role, but is said to stimulate the metabolism."

This sounds extremely questionable to me, and I have been unable to find any supporting references for this statement. Is there any support for this claim at all? If so, we should indicate who says that Samarium et al. stimulate the metabolism, and link to any available research on the subject. If not, the claim should be removed. There is enough health supplement misinformation on the web as it is without us encouraging people to try taking Samarium-Lutetium pills in order to "stimulate the metabolism".

Egomaniac 21:52, 23 Feb 2005 (UTC)

If one could determine what a stimulated metabolism means in the first place, one could try to un-weasel the "who" part of the phrase. Even then, the fact that every known substance in this world is advertised in one way or another as having health benefits is just non-notable. Femto 18:11, 25 Feb 2005 (UTC)

references, TODO

Status of my converted infoboxes, each of the 116 "_header" lines occurs once (and only once) for each element and has number/symbol/name parameters with the properly spelled and matching content. A fixed-width comment column contains number and symbol of the corresponding element for each line of data. — It's an important milestone since this makes it a breeze to extract any specific entries by type, sort them into separate tables and then finally, check them!

The current system of acquiring the data and entering it directly into the articles does work. However it has one serious drawback: no references—the moment an entry is included into an article it becomes an orphan, reference-wise. Resource links at Wikipedia:WikiProject Elements#General notwithstanding, since the data is scattered over article pages which are subject to lots of the usual wiki-editing, it has become impossible to determine the source of any particular entry without archeological efforts.

A solution will be to collect, check, and maintain the information on dedicated data pages—with all the footnotes and references that are necessary to validate them as authoritative, Wikipedia-internal resources.

Mostly, basic tables should suffice, with simple web link references. More important is to preserve the information of who checked and included which data. As an example, I've checked the already existing list of elements by atomic mass which now is verified data that cites its source. From here, the content can be easily included (not only!) in the Elements articles, and the articles can link back to these data pages as their reference.

TODO

Check and correct these tables! They were extracted from the current content of my working-page data. Once corrected, it can be merged back and those entries may finally be considered verified and done.

  • User:Femto/table navsys an overview of all the number/left/name/right/above/symbol/below parameters from the header, plus the group/period/block/series (partly included in the working-pages)
    • I have previously used the "number", "name", and "symbol" data to build an index, so these should not contain any bad surprises.
    • For now, use a simple minus sign "-" for the 'dead ends'.
    • What should be done with (dead) links to the non-elements like Uqu etc.? Technically, the navigation scheme is correct. Should this data be left out? Or use plain text parentheses like "(Uqu)" for all above 116?
    • Can anything be put into the "group" number for the group elements to avoid creating a separate "groupless" template?
  • User:Femto/table electrons electrons per shell, electron configuration (partly included in the working-pages)
    • This is one of the data that needs references, get checked once again, and then can be used to create a data page, perhaps electronic configurations of the chemical elements? Help. I think I'm horrible at making up these titles.
    • According to the acquisition guide, this was originally taken from http://www.webelements.com/ follow the "Electronic Configuration" link, use the "Ground state electron configuration" and "Shell structure" data
    • ...unless somebody can provide a better source that 1. lists the data in a simple to extract table format, and 2. can be cited as a reference? http://physics.nist.gov/PhysRefData/IonEnergy/tblNew.html Included in the working table. I've done my best to check that the 'per shell' numbers match to the configuration data. I saw no point in abbreviating "1s2" to "[He]", and used the numeric orbital order from the website (some were '654' for instance, that didn't change some subtle meaning about energy levels, did it?)
    • Still to do: everything above(>99) einsteinium, and those funny Pa/U/Np terms.
    • What about the guesses? Maintain the 'based on' info? Whose guess?
  • done list of elements by atomic mass (included in the working-pages)
    • The atomic masses are given with uncertainties in shorthand form, for instance 1.00794(7) which means the actual value may be with reasonable certainty somewhere between 1.00787 and 1.00801. The previous numbers mostly omitted these parentheses and misrepresented the accuracy.
    • Changed Fr/Ra/Pu/Sg/Hs back to mass numbers for lack of easy references. Exact "no stable" isotope masses may be added later.
    • Out of curiosity, I traced back the last digit of silver (107.8683) to a vandal edit of 2004-02-25 13:49 UTC. Central reference pages should make it harder for bogus content to slip through unnoticed.
  • done atomic radii of the elements (data page) created (included in the working-pages)
    • The radius of an atom is not a uniquely defined property and depends on the definition. Data derived from other sources with different assumptions cannot be compared. "No data" templates seem appropriate and ultimate, in this case.
    • changes in cov.rad(Pr/Ho/At), vdw.rad(Rb), calc.rad(He/Be/Ar/Sr/Mo), emp.rad(Be/Sr/Gd/Ho)
  • done melting points of the elements (data page), boiling points of the elements (data page) created (included in the working-pages)
    • I haven't determined a source for the boiling points of astatine, francium, and protactinium and did question-mark their values.
    • All K/°C/°F conversions from WebElements appear OK with rounding errors below ±0.4.
    • If I kept track correctly, there'll be changes in the melting points of H/He/Be/C/N/O/F/V/Cr/Mn/Fe/Cu/Ga/Ge/Kr/Xe/Ce/Pr/Pm/Ho/Er/Hg/Bi/Fr/Th/Pa/U and in the boiling points of H/He/Be/C/N/O/F/Ne/Si/S/Cl/Ar/Sc/V/Cr/Mn/Fe/Cu/Ge/Br/Kr/I/Xe/Ba/La/Ce/Nd/Sm/Eu/Gd/Ho/Er/Tm/Yb/Hg/Rn/Ac/U/Pu.
    • (old:) We're going to need a bigger hammer with these. Take a look for yourself, these User:Femto/table melting point User:Femto/table boiling point are comparison overviews of melting and boiling points as given by WebElements, the CRC handbook, and what is used in the articles (conveniently aligned below each other by given units). The headings are color-coded, green where all seems well, blue where sources disagree, and red where I'm left with no clue where that data came from (hints welcome).
    • Ignore the rounding where my working-data t/°C differs from that in the articles, since it was converted directly from t/K to the nearest degree, for lack of source values.
    • Some values are given as triple point (marked "tp") and are not valid at standard pressure. I also left out some allotrope data for As/Bk/C/P/Se/S/Sn from the CRC.
    • Unless anybody can provide primary-source data, we'll have to make arbitrary selections between which source is used. Important is that it remains retraceable on a data page.
  • done ionization energies of the elements (data page) created. Limited to three entries in the working-pages, with a 'more' link to a separate ionization energies of the elements (created).
    • Apart from one or two exceptions and a few omitted decimal-place zeroes, all values from the articles do agree with http://www.webelements.com/.
    • The WebElements data seems mainly to be converted from values which are quoted in the CRC, without any apparent conversion errors greater than the proper significant-digit rounding.
    • The ionization potential is equal to the ionization energy divided by the charge (of the electron) which is moved through it. Thus, shouldn't the table keys be renamed from "ionization potential" to "ionization energy"?
    • Using up to ten table rows, this is quite a space hog in the articles. With 4 energies given for molybdenum but 30 available, I think instead of trying to find a reasonable cutoff number, this should go on a separate page like ionization energies of the elements. The articles themselves would contain, say, only the 1st, 2nd, and 3rd energy, plus a more link.
Have you used these sources? I don't know a whole lot about it, but it sure looks to me like your numbers are there, too, and probably at least as reliable as your other sources.
[today's date put in by their online example of how to cite this] Gene Nygaard 23:48, 25 Mar 2005 (UTC)
Seems like one of the best references you can get (if you know how to read them). I'm afraid though, my knowledge of anything beyond some very basic definitions of this stuff is as fuzzy as an electron cloud. :( My main objective has been to verify (and make more easily verifiable) the information that gets used in the articles. The most I can do is keeping in mind to add external links when creating a data page, as a starting point for later updates. Femto 12:16, 26 Mar 2005 (UTC)
  • User:Femto/table appearance color/appearance
    • This may not need a data page but is useful as an overview.
    • Used "gray", "color", and "luster" spellings.
    • Many descriptions are verbatim copies from WebElements (no further source given). Unlike pure data citations, these require some minimum of creativity. If used as a whole, might this be a (minor) copyright problem?
  • densities of the elements (data page) created (*) (included in the working-pages)
    • (*) yesterday—seems there was something funny with the server. Pretty sure I did only a section edit below, but that somehow nixed the previous edit of this entry. Oh well.
    • Note that against our claim of using standard conditions in the infobox footers, WebElements and many other sources give the densities at or near room temperature. This may only affect the 3rd or 4th decimal place or so for solids, but it's wrong nonetheless.
    • The allotropes and the liquid densities are also included in the working-pages (and I removed all molar volumes there). Still to find and to do are the densities of the gases.
  • done hardnesses of the elements (data page) created (included in the working-pages)
    • In addition to the Mohs hardness I've included Vickers and Brinell hardnesses (I think technically you're supposed to state the measuring conditions with Brinell. Blame WebElements.)
    • The pairing of Density and Hardness made little sense; I've squeezed the material properties beneath the physical properties for now.
  • done elastic properties of the elements (data page) created (included in the working-pages)
    • Poisson ratio μ (cross-section change), Young's modulus E (length change), bulk modulus K (volume change), shear modulus G (rigidity).
    • Strictly speaking it's not necessary to include all of them, since one can be derived from the others, but they belong together, and by far not all values are available for everything. Also left out some data of Cl/Hg/Br for the same reasons as with the molar volumes.
  • electrical resistivities of the elements (data page) created (included in the working-pages)
    • I'm using resistivity because that's what the sources give, converted from the kludgy µΩ·cm to Ωm with single prefix (preserving the significant digits info). Environmentalchemistry.com's conductivity which was used in the articles is either simply the reciprocal, or they mostly use the 'usual' values anyway; noticed no anomalous conversions.
    • Lange has a problem with the values for C/P/Se. It gives 10*(10^-8 Ωm) for phosphorus for example, which should be more about 10^17*(10^-8 Ωm) if I'm not mistaken. Probably either true errors, or a funky PDF conversion on their side; WebElements also gives 10 here.
    • Choosing the appropriate infobox templates was interesting, since there are quite a few different prefixes and temperature combinations. I'm using one universal "eresist_ohmm" template, plus two for 0 °C and 20 °C that include these temperature conditions (using the value for 20 °C where possible, the data page contains a few representative temperatures to choose from). The unit prefixes are simply part of the parameters, while the "Ωm" is always added by the templates.
    • The data for C/Si/P/Ga/Ge/Se/Tc/Te/Fr/Am still needs work.
  • heat capacities of the elements (data page) created (included in the working-pages)
    • The CRC confusingly gives values for the gas state for iodine and bromine.
    • In the infobox I'm including both the usual per mole values, and the per gram values which were previously used. This requires a line break, and we'd need to calculate some missing values that are difficult to find with undefined isotopic masses. Apart from the hydrogen value, plus one error from the CRC, these are exactly the calculated values to the third digit anyway. If nobody is particularly attached to them I'm going to remove the 'by weight' values.
  • speeds of sound of the elements (data page) created (included in the working-pages)
    • These values come in three flavors, for longitudinal (pressure waves) and transversal (shear waves) in an infinite solid, and for extensional waves (thin rod) as a mix that is influenced by the cross-section elasticity.
    • The speeds of sound can be calculated from the elastic moduli with √(M/ρ), where ρ is the density, and M is substituted with Young's modulus, shear modulus, or plane wave modulus (as compound of Young's modulus and Poisson ratio M=E·(1-μ)/(1-μ-2μ²)). User:Femto/e speed of sound check compares the references with calculated values as expected from the elastic data. Doesn't look too bad, although not being one of the better-referenced data sets; I've exhausted the CRC, and Lange's pulls a blank. Other specialized sources are always welcome. Li/Se/Si/Sb/Yb/Hf may need a second look. — It's clear from the values that those which we use from WebElements are given for the extensional wavespeed in a thin rod. It's essential to note in the tables which value is meant.
  • done vapor pressures of the elements (data page) created (included in the working-pages)
    • The previously used value pairs from EnvironmentalChemistry.com (apparently at melting point temperatures) give some orientation, but aren't really meaningful by themselves. The vapor pressure is not a single nominal value, but a correlation of a wide range of pressure with temperature. The CRC Handbook gives a table in terms of temperatures necessary to reach specified decades (1,10,100,etc) of pressure. This also seems like the most useful way to present the vapor pressure in the infobox, I'm using a simple embedded horizontal table. To check, and out of curiosity, I've computed and included the values in the data page where the vapor pressure equations yield results within the quoted ranges.

Comments? Suggestions? ...Volunteers? Femto 19:09, 7 Mar 2005 (UTC), 15:17, 11 Mar 2005 (UTC), 19:25, 14 Mar 2005 (UTC), 16:59, 18 Mar 2005 (UTC), 19:05, 25 Mar 2005 (UTC), 19:43, 29 Mar 2005 (UTC), 19:13, 10 Apr 2005 (UTC), 11:25, 20 Apr 2005 (UTC), 12:35, 6 May 2005 (UTC), 11:43, 16 May 2005 (UTC), 10:51, 20 May 2005 (UTC), 15:14, 25 May 2005 (UTC), 13:55, 31 May 2005 (UTC), Femto 14:44, 10 Jun 2005 (UTC)

Molar volume for gases

What does the molar volume entry actually mean? Is it molar volume at STP, no matter what phase the substance is in then? Molar volume for all gases should then be about 22.4L/mol, which is not what's on chlorine (it gives there the same far-too-small, undefined number given on WebElements). If it's under some other conditions, what conditions? Is it for solid or liquid? Under how much pressure?

This came up in Helium, where the solid can only be produced under 26 atmospheres of pressure and is highly compressible (30% under laboratory conditions). --Andrew 05:07, Apr 9, 2005 (UTC)

See this entry for some more discussion. The definition WebElements uses for molar volume is here but this does not shed any light on the actual value that they list since helium is definitely not a solid at 298 K unless at extremely high pressures. I think the most usefull definition of molar volume can be found on WP itself. This link is also in the tables used for listing the properties of the elements. This means we should use a value of 22.4 L/mol or something close to it. Using the suggestion above of using the density and atomic mass (as found on WP) to calculate molar volume, I find the following values:
H2 0.0899 g/L and 2.01588 g/mol gives 22.43 22.424 L/mol
He 0.1785 g/L and 4.002602 g/mol gives 22.42 L/mol
N2 1.2506 g/L and 2x14.0067 g/mol gives 22.400 L/mol
O2 1.429 g/L and 2x15.9994 g/mol gives 22.392 L/mol
F2 1.696 g/L and 2x18.9984 g/mol gives 22.40 L/mol
Ne 0.8999 g/L and 20.1797 g/mol gives 22.424 L/mol
Cl2 3.214g/L and 2x35.4527 g/mol gives 22.061 L/mol
Ar 1.784g/L and 39.948 g/mol gives 22.39 L/mol
Ar 1.7824g/L and 39.948 g/mol gives 22.41 L/mol (alternative density from environmentalchemistry.com)
Kr 3.708 g/L and 83.798 g/mol gives 22.60 L/mol
Kr 3.75 g/L and 83.8 g/mol gives 22.34 L/mol (alternative values from environmentalchemistry.com)
Xe 5.9 g/L and 131.293 g/mol gives 22.25 L/mol
Xe 5.88 g/L and 131.293 g/mol gives 22.32 L/mol (alternative value for density found here)
Ra 9.73 g/L and 222 g/mol gives 22.82 L/mol
What does this tell us? Indeed the values are close to 22.4 L/mol, the noble gasses suggest a value of 22.42 L/mol. Significant deviations are found for higher atomic mass, in part due to inaccuracies in the reported densities but maybe also because of deviations from ideal behaviour (especially for biatomic gasses). I think that the densities of Ar, Kr and Xe need an thorough check, since the alternative values floating on the web yield results that are closer to 22.42 L/mol.
Another thing to check is the molar volume for liquids and solids. I'm not volunteering. Jan van Male 09:49, 9 Apr 2005 (UTC)

Coward. :-) User:Femto/molarvolumecheck The colums are: the element (multiple times for allotropes) / the factor of calculated mass vs real mass / the product of molar volume and density / the result / the expected atomic mass. I used the molar volumes from WebElements (which were used for the articles) and the densities from the brand new densities of the elements (data page). Many nice 0.99s and 1.00s in the factors—so there shouldn't be too much to worry, at least with the molvol data for the solids.

Volumes or densities for the molten phase usually are not given anywhere in the articles. The data page also contains densities for the non-solid phases, which could be used to calculate the respective molar volumes. For the gases I'm afraid though that the CRC only gives calculated ideal gas values, and Lange uses a haphazard mix of temperature conditions. But since you can always calculate them yourself anyway, having molar volumes in the articles is nice, but not too high on my list. Still, they should be correct and not misleading.

I very much suspect WebElements to uniformly use data for the solid phase everywhere, tweaking the standard conditions where necessary, but neglecting to tell where. In addition to the 0.19 g/cm³ mentioned in the helium talk, trying the 2.03 g/cm³ for solid chlorine found in some search hit, it's (35.45/2.03=17.46) cm³/mol, which also is awfully close to the 17.39 cm³/mol from WebElements. Femto 20:36, 9 Apr 2005 (UTC)

Impressive! Let me see if I understand correctly. The values we have now for molar volumes (from WebElements) are confusing (if not misleading) for gases, can't be verified for liquids and are correct for solids if we neglect allotropes (which we should not). I was hoping that somebody would come up with a justification for the WebElements that would make their values useful in some context but that hasn't happened. That makes these values redundant: listing a reliable value for the density, also for different allotropes should be sufficient. So the conclusion should be to delete the molar volumes and expand the densities to allow for allotropes. Which is easy, except that it means editing all articles on elements. Agreed?
I'm currently working on an infobox format that uses templates (see # above)—verifying/improving the entries and creating data pages is "only" a by-product, actually. In the course of this, I'm collecting the entries on my user pages (User:Femto/elements_e1 ff.) for the day when they are complete enough to be copied into the articles all in one go. Most of it already is more reliable than what is in the articles, but much are little changes that are not worth many little edits by themselves. For the 'live' articles it should suffice for now to keep what is redundant/not really wrong, and only to remove what is misleading. The molar gas volumes are certainly the latter type. (Has anybody checked the molvols for mercury & bromine yet?) Femto 19:08, 10 Apr 2005 (UTC)
It would still be useful to give molar volumes for the solid or liquid forms of the gases, but there's just no way that'll fit in the infobox, and it'll take some serious research to find it. If we can get accurate molar volumes for gases (that is, accurate enough to see the small deviations from ideal gases) those would be great too. But for the moment, I think we should remove molar volumes from the gases. I'd like to have molar volumes for liquids, too... --Andrew 01:46, Apr 10, 2005 (UTC)
I am still puzzled by the deviations for the noble gasses with a high molecular weight. I don't have access to CRC data until Monday. Does CRC give values that are different from the ones we have on the density of gases? Jan van Male 23:05, 9 Apr 2005 (UTC)
The higher the molecular weight (for a noble) gas, the bigger the atoms and the closer they are together at STP; this makes for minor deviations from the ideal gas approximation. Generally, the closer a gas is to its boiling point, the more it'll deviate from an ideal gas. But it's still a good idea to check the CRC info. --Andrew 01:46, Apr 10, 2005 (UTC)
The CRC only gives what is in the data page (or I haven't found more), that is, only calculated ideal gas density for one, and at a temperature of 25 °C for another—not the usual 273.15 K which mostly appears to be used by the article gas densities; though these don't have a source associated. It may actually be more likely to find authoritative and ready-to-use standard gas densities in a smaller book, since 'real' physicists (read: not me) would be able to calculate any gas value, for any condition, by putting some van der Vaals constants into a standardized state equation, and you only need to publish the parameters to that equation for that gas. Femto 19:08, 10 Apr 2005 (UTC)

I have removed the molar volumes from the gas articles. Femto 19:38, 10 Apr 2005 (UTC)

Minor infobox formatting

elementNAMEleft - elementNAME - elementNAMEright

The infobox would look nicer with a small margin on the left, so that text does not butt right up against it. Images do this, for example, at least in the monobook skin.

elementNAMEleft - elementNAME - elementNAMEright

This version of the table has the margin set, so, provided I blather on long enough, you should be able to see the difference. --Andrew 10:45, Apr 24, 2005 (UTC)

Last time I counted, about 72 of the element articles already contained some margin attribute in one form or another. I hope to standardize this with the templates. For those without (in general, not only for the elements infoboxes), it would definitely be worthwile to include a style="margin-left:0.5em; margin-bottom:0.5em" in the table attributes. Femto 16:34, 24 Apr 2005 (UTC)

Okay, I'll put it in the table for Technetium. --Andrew 22:07, Apr 24, 2005 (UTC)

Problem with the Isotope section of table

I have finally the time to fix the isotope section of the element article. There is some serious problems with the current information included that I noticed during my studies. I am a nuclear engineering student and have noticed that the information is not uniform and sometimes wrong. I am going to go through all the elements and put in all the information included in my copy of the chart of the nuclides.

The one thing that I wonder that might need to change is that "MeV" might want to be in brackets. I put it in brackets in Helium but I want to know why it wasn't done that way originally. I am sure there was a reason. Units on a graph should be in brackets and so should they be in a table, no?

I also want to know if I should move all the tables of all the elements to templates. I think it would make changing them on the mass scale easier. I would like to hear comments.

--metta, The Sunborn ☥ 20:52, 4 May 2005 (UTC)

The isotopes data is already known to need work, so please do update it! Please also use {{inote}} to give a specific reference (that'll help everyone know which ones you've done). In a few cases there are Wikipedia entries for specific isotopes, which you may want to link to. Nuclear isomers are also important (at least for technetium).
If you want to use templates, skim the above section. The conclusion seems to be that templates may be appropriate for rows, but not for whole chunks of the table because the tables are too irregular. But I think having a template for an isotope row would be a good idea; check it out above, I think one may have been written already. Possibly it would be a good idea to have one for the headings too, although beware of irregularities for elements like helium that have abundances that depend where you look - for helium we just gave the most-quoted abundance, which is the atmospheric one. --Andrew 21:17, May 4, 2005 (UTC)
Good, good, I intend to include isomers. I was just starting at the bottom where isomers don't exist. I have linked to specific articles for each isotope. The isotope people want to create an article for each isotope. The template I was talking about was what if we turned the entire dialog box for each element into a template. The periodic table is a template and it is of similar complexity. --The Sunborn
Read #Template conversion for infoboxes and #infobox template conversion. It doesn't seem to be feasible to do all elements with a single template, since templates cannot easily handle missing data and extra hunks (like the two densities for Carbon, the melting point for Helium, or unknown or inapplicable numbers - nobody wants to see "Melting point: N/A K (N/A F)"). And with the variety of templates and grody syntax that would be needed, it's just not a win (and it's a performance hit on the server). --Andrew 04:43, May 5, 2005 (UTC)
Right, see above for the earlier efforts at creating infobox templates, also especially at my user page User:Femto/elements_e1 etc. for my row-based solution which slowly but steadily approaches completion. I plain out won't believe that a single template could be done until I see it done, with all the data. Or if you simply mean to outsource the whole infobox code onto separate template pages, this would bring little benefit either. The periodic table is a template? What do you mean?
For the isotopes section in my data I'm currently using a header template, and two separate parametered templates for stable, respectively decaying types, which each generate one entire row. It may be useful to add separate row types that generate the appropriate link code for alpha decayer, beta decayer, etc., but I know too little about this stuff not to mess it up. Other than that, paradoxically, this data has a simple structure and appears to be one of the easiest to convert.
And there are plans to update and expand the isotope info—not an article for each possible isotope, that would be insane—but I'd very much like to see a full set of separate "isotopes of [element]" or "nuclear properties of [element]" pages, linked to from the isotope section in the infobox. These would not only contain every decay mode, full spectra, parent isotopes, metastates, and all the other stuff which doesn't belong into the main article in full but would be useful to have; these would also serve as a comprehensive reference (if properly referenced themselves) for the information in the main article!
So any endeavor to update the isotope data should start at defining a structure for the "isotopes of [element]" pages, and then populate them with info. From there it's easier to include in the articles than it would be the other way around.
The articles simply don't use (MeV) because nobody knows everything, and it hasn't been top priority to fix it since the infobox structure was initially defined. (I proudly report to use "DE (MeV)" in my user templates. Or maybe change it later to "DE/(MeV)" or something. Dunno.)
Regarding abundance, I would expect and imply any not further referenced abundance to be in compliance with the "representative isotopic composition" as standardized by Isotopic Compositions Of The Elements 1997. I'm against using a rounded 100% He-4 abundance, which discards information and would not be distinguished from a 'true' 100% of Be-9 for instance. The He-3 value is appropriate as long as it's specified 'in air', as its source is. This should better go with the values, not into the heading, but anyway there's nothing in the infobox definition that prevents adding descriptors where appropriate. Femto 14:01, 5 May 2005 (UTC)
There's something to be said for using exactly the data in the IUPAC report (I should think it'd be pretty reliable). We could either include the composition ranges or the representative compositions they give. I think on the element pages we should give the representative compositions they give (and an indication of where to find that representative composition) and on the isotopes of ... pages we should give the ranges as well.
As for the isotopes of ... pages, for some elements (Hydrogen springs to mind) we already have pages for each isotope. So something would need to be done (perhaps a "main article" indicator) to accomodate those cases. --Andrew 15:47, May 5, 2005 (UTC)
It is silly to consider 0.000138% anything but trace. However, I have reconsidered putting notes on concentration amounts. After all, lithium and boron have concentrations that change significantly (over 10% in off-the-shelf samples) so that has to be demarcated. So long as it is only a few characters, it would be appropriate. Also, bolding of the primary isotope seems usless. All now my track my progress on my user page: User:Sunborn/isotopes --metta, The Sunborn ☥ 20:07, 6 May 2005 (UTC)
Of course it's trace, but the amount is valuable, if for no other reason then for the order of magnitude.
I see what you meant now about the templates; I think it's useful if we want to have an "isotopes" page that includes the tables as well. If we decide that it's not useful to have them templatized (it does make editing more cumbersome for users) we can rapidly remove them with subst.
I'm not sure how essential it is to include the number of neutrons in stable isotopes; is that just to fill an unaesthetic blank space? We can't compact the table entirely because some unstable isotopes have natural abundances, so I suppose that it doesn't hurt to put it there, but it looks funny, as if the number of neutrons might be uncertain or irrelevant for unstable isotopes.
For isotopes that don't have individual pages, it may be appropriate to make the isotope a piped link to "isotopes of X".
What are you using as a reference? Please include it in the element pages you use it on. We really need traceable references for this sort of data, and if it isn't there someone will have to go through and redo what you're doing to put in the references. --Andrew 20:25, May 6, 2005 (UTC)
I considered making a general link for isotopes that lack a page of their own. However, the isotope people are currently making a page for all the isotopes (Wikipedia:WikiProject Isotopes). So I will leave the links for the time being. My reference is: Nuclides and Isotopes copyright 1989, General Electric Company. --The Sunborn
Please include a copy of the reference (as below if this is the correct source) on every page you put the data on - we need to cite sources. --Andrew 22:26, May 6, 2005 (UTC)

Successful example of the use of a single template

On the nn: wikipedia we have successfully implemented a single template for chemical element infoboxes. (That is, it's implemented in 24 articles and increasing (*), 39 don't use a template yet, and 48 elements have no article so far. We're a bit slow...) It is identical to Template:Element which I mentioned above, only in Norwegian. Full instructions in English may be found at Template talk:Element, and an example of its use is given at User:Eddideigel/Fantasticum. Notable features include:

  • Ionic radius is included (at nn:, but not here yet).
  • Melting points and boiling points are given in K, C and F (all three here, but only K and C at nn:).
  • The scale of molar volume is cm³/mol because most molar volumes (all except gases) are in the cubic centimetre range, and the scale of electrical conductivity is MS/m because most conductivities (for all metals) are in the megasiemens range. I believe cubic centimetres and megasiemens are within SI.
Sure are! You already might want to prefer the resistivity data from the data pages #references, TODO instead of the currently used conductivity though, due to better references. I gather "ikkje" means "non-" or "not"? So "ikkje SI" is not necessary for "MeV" and "u" since those units are accepted in SI, within their special fields of use. There should be a space between number and °C symbol even in Norwegian I believe. Femto 13:48, 8 May 2005 (UTC)
Yes, "ikkje" means "not" or "non-" depending on context. I'll have a look at the u and MeV, and also the resisitivy data. Regarding °C the space is optional in European nomenclature as far as I know, and is not commonly included in Norwegian. --Eddi (Talk) 16:40, 8 May 2005 (UTC)
The footer of the tables doesn't say "units acceptable for use with SI" in the English Wikipedia; it says "SI units ... are used except where noted". The nynorsk one copied that. So it is indeed proper to note these uses as non-SI.
  • Electronvolts are not SI units.
  • The "unified atomic mass unit" is only acceptable for use with SI under that name, and only with the symbol "u". The "amu" which appear in many of these tables are not only not SI but also not even "acceptable for use with SI".
Furthermore, years are not in the list of units acceptable for use with SI. Days, hours, and minutes are, but not years.
It is nice to see that the Norwegians have figured out that the siemens per meter is the modern SI unit. Are there any elements which have this in the English Wikipedia, where it hasn't been added by me? Gene Nygaard 20:56, 8 May 2005 (UTC)
There (justifiably) hinges quite a bit on the exact wording of that footer. But also on the wording of any notes that refer to it. Having them all say "not SI" (as in "not at all" or "completely outside") for those fringe units doesn't seem fully correct in any language either. Femto 00:19, 9 May 2005 (UTC)
The note "(non-SI)" should perhaps be rewritten to "(*)" or something, along with a more detailed account near the main footnote, "SI units and STP are used except where noted".
There are no comments on SI for half-lives yet, because radioisotopes are not listed for all elements, and those that are may or may not use SI. Can we find a way that fits all, without taking too much space in the table header or table cells? Could the header read, e.g. "Half-life <br> (SI or non-SI)"? --Eddi (Talk) 09:00, 9 May 2005 (UTC)
  • Multiple ionization potentials may be entered in one cell by adding kJ/mol and <br> between each number, but not at the end, e.g. 598.8 kJ/mol <br> 1145.4 kJ/mol <br> 4912.4
  • The isotope table is very flexible and, although the most tricky variable, not too tricky after some practice. For an example see User:Eddideigel/Fantasticum.
  • Background colours of titles, and file names of table images (periodic table locator and appearance), are calculated automatically from the name of the chemical series, chemical symbol and atomic number.
  • A single template.

We haven't tested the template with any radioactive elements at nn: yet, but I think eventually we have to make a separate "radioactive" template without all the unknown properties. Another drawback may be that the template and the articles where it is used can not be easily copied to other wikipedias because all variables have language-specific names. Anyway, I would be interested in your thoughts about the usefulness of this template. Please have a look at some of the articles, and let me know your opinions.
(*) The articles are, in order of atomic number: nn:Hydrogen, nn:Helium, nn:Litium, nn:Karbon, nn:Nitrogen, nn:Oksygen, nn:Fluor, nn:Natrium, nn:Aluminium, nn:Fosfor, nn:Svovel, nn:Kalsium, nn:Vanadium, nn:Krom, nn:Mangan, nn:Nikkel, nn:Kopar, nn:Rubidium, nn:Strontium, nn:Yttrium, nn:Zirkonium, nn:Niob, nn:Molybden, nn:Jod
--Eddi (Talk) 02:05, 8 May 2005 (UTC)

Well, you really chose the easy ones. I still maintain we ought to see all the infoboxes, with all the data, before we can even think about deciding whether a single template is indeed feasible for all elements, and whether it would be of greater usability than separate entry rows. Femto 13:48, 8 May 2005 (UTC)
We started at the top left and continued down and right. Nothing more sinister. I'll keep this forum posted. --Eddi (Talk) 16:40, 8 May 2005 (UTC)
The isotope table is flexible, but at the same time doesn't do much to standardize the format. A set of specialized template rows for each decay, on the other hand, could easily fix the currently five or six different ways in our article tables of coding "beta minus decay", also keeping the entire table code out of the infobox. Femto 13:48, 8 May 2005 (UTC)
Extra templates for isotope table rows are being considered, but they haven't been coded in nn: yet. We will probably have templates for a few or all of α, β−, β+, ε, n, p, γ, IC, and SF. But I don't think template rows will fix everything, because (a) many isotopes have multiple decay modes that should – in my opinion – be presented in one row, not two rows for the same isotope, and (b) some isotopes have complex decay modes like 2·β− or β− + 2·α, and the multitude of combinations cannot all be covered by a small number of templates. --Eddi (Talk) 16:40, 8 May 2005 (UTC)
Right, there should always be a universal template row without restrictions. Specialized ones can and need only take the coding-work off the most common entry types. The isotope table itself would be a dynamic row-based format similar in either approach in any case, so maybe not be the best decision point about the main templates. Femto 00:19, 9 May 2005 (UTC)
I began testing an isotope row template (nn:Mal:Grunnstoff/Radio/Beta), but soon realised that it won't work inside our (otherwise) single template before templates are allowed as template arguments. Case closed until further notice. --Eddi (Talk) 18:07, 9 May 2005 (UTC)
Where do the unknown properties for using a "radioactive template" begin? What about the yet known properties of some, how would they be included? As I said, you'd eventually end up with separate templates for each element, or many awkward non-parameters without content. Femto 13:48, 8 May 2005 (UTC)
Even with the full template, some elements have properties that are left out of the infobox and only mentioned in the body text, while some properties are blank in the infobox of some elements. Still we find the template useful. Likewise with a "radioactive template", it must be less than the maximum and more than the minimum. It's difficult to tell before trying, but the unknown properties have to lie somewhere between nothing and the full template... --Eddi (Talk) 16:40, 8 May 2005 (UTC)
What is or what is not included in the infobox should be determined by the available data, not the other way around by the structure of the infobox. An infobox that leaves out some data may be useful, but it's less useful than an infobox that is not restricted by a single template. The decision of what constitutes a "full template" is arbitrary and unnecessarily restrictive on the used data. The point is, there is no clear threshhold (that is, it's anywhere between lithium and nobelium, depending on how much data one is willing to leave out). Femto 00:19, 9 May 2005 (UTC)
Here lies the crucial distinction between our approaches. Although the infobox should present the core properties of each element, I believe it is most useful to have one selection of properties for all elements, and to tailor this selection for an adequate – not complete – comparison of the elements. With this approach a single template, easy to use but with some flaws, solves the task. As mentioned in an earlier discussion, I think a template is both content and layout. With the approach to include all possible properties and exclude all impossible properties, a single template must necessarily fail. --Eddi (Talk) 09:00, 9 May 2005 (UTC)
What is an 'adequate selection' of properties? This hasn't even been defined yet in a consistent manner for most elements. I want the infobox to be simply, well, a box of info, that provides appropriate notable and available data. I sure don't want to be forced to choose between not including useful information for the sake of layout or else having 'comparisons' of empty "n/a Pa at n/a °C" entries.
A row-based infobox wouldn't be exactly a jumble of entries without layout either, you know. The infobox layout isn't maintained by any templates, but by this Wikiproject and its participants. Template rows can create the same layout as a single template, plus they are unhampered to adapt to the special cases (which make up the majority). Femto 22:32, 9 May 2005 (UTC)
An adequate selection is a matter of debate and no solo show. We are debating properties at nn: and that would be the case here, too, if a single template were to be used. I have presented an alternative that has been tested and passed so far, but of course it needs to develop continuously. --Eddi (Talk) 08:08, 10 May 2005 (UTC)
I say an adequate selection for all elements does not exist, and can not exist. What has been presented already has (and will increasingly continue) to make concessions to the format over the content that are neither necessary nor desirable. Femto 14:52, 12 May 2005 (UTC)
Extra data may not be added simply due to format restrictions, or it is squeezed with <br>s into existing entries. If the liquid density is a sub-part of the density entry, its unit and condition cannot be standardized by the template. How would you keep the material properties out of the gases, yet include those (which are available, but only partially) for the other elements? What do you put in the "Gruppe" parameter for the group elements, or how would you leave it out without affecting the period and block parameters? Femto 13:48, 8 May 2005 (UTC)
To some extent extra data may be added (see e.g. nn:Karbon), and if it can't, put it in the body text. Throw me a liquid density and I'll try to catch it in our template. As to missing data, the hardness and electrical conductivity of gases are generally missing, and more is missing for the noble gases. This is no problem as I see it. By the way, which group elements are you referring to? Don't all elements have a group, a period and a block? --Eddi (Talk) 16:40, 8 May 2005 (UTC)
Densities of the elements (data page)#Density, liquid phase I think it's enough to justify an own entry row, but what would you put into the template parameter for the elements without data? We can't put it all in the body text. Or put it into the "density" parameter and lose the standardized "liquid density"-key and "melting point"-links, and with it one of the main points for using templates in the first place.
The problem is not the missing data, but the data that is not included in the template because of other missing data. A single template cannot both include full sets of material/magnetic/electric properties where available, and leave out all these inapplicable entries for the gases for example. - (I'm referring to the group elements which I believe have no numeric group assigned. If you put their group name instead of their number in the template, there goes another automatically generated set of link parameters, this time the IUPAC numbered groups.) Femto 00:19, 9 May 2005 (UTC)
I've had a look at the liquid densities. They all seem to deviate from STP, and so they should not be included – except for bromine and mercury, which are already covered. Regarding the inclusion and exclusion of data, see my comments on our two approaches above.
The "group elements" (i.e. lanthanides and actinides) should be fine with the IUPAC groups 1-18, fitting well in group 3. --Eddi (Talk) 09:00, 9 May 2005 (UTC)
>> They all seem to deviate from STP, and so they should not be included
Now you're grasping for straws just to accommodate to a fixed template layout. Femto 22:32, 9 May 2005 (UTC)
Please do not ascribe intentions to me that I do not have. --Eddi (Talk) 08:08, 10 May 2005 (UTC)
I merely described what I see. Femto 14:52, 12 May 2005 (UTC)
Most of our solid densities are for room temperature. Neither are the heats of fusion or heats of vaporization at STP (and if they'd be given as enthalpies referring to some standard temperature, it would be the thermodynamic standard of 25 °C, not 0 °C). Try to find heat capacity data that is not for 25 °C or for round kelvin temperatures, etc. This is not a criterion to include or exclude this data. Femto 22:32, 9 May 2005 (UTC)
Good point, although I might conclude differently: Exclude the heats of fusion and vaporisation altogether. --Eddi (Talk) 08:08, 10 May 2005 (UTC)
Exclude all the densities too? The hardness which would be for white tin, not for brittle gray tin? The speed of sound? The thermal conductivity? Femto 14:52, 12 May 2005 (UTC)
I want to include liquid density data, but can't do it in a fixed template without including 46 dummy entries, or having to include 70 unstandardized "liquid density at the melting point" keys and links. This is not a problem with row templates. Femto 22:32, 9 May 2005 (UTC)
With consensus, please do. And with consensus we may even include liquid densities at nn:. --Eddi (Talk) 08:08, 10 May 2005 (UTC)
With or without consensus, the question remains how? There was consensus to include the heats. There was no consensus to put the group elements in group 3 (the current data does not), so this question regarding the template parameters also still stands. And even if there is a workaround, the question would be why? Row templates can do most what a single template can do, plus much what a single template can't do (for example include any form of isotope table or other complex entry types, templated or not, simply as set of sub-rows). I think being able to globally modify the colors or determining the positions of parameters (which are necessarily fixed and partly empty with this solution) are not the things that make the other restrictions worth it.
To illustrate the extent of the irregularities in the data, see User:Femto/data availability. Femto 13:48, 8 May 2005 (UTC)
Will do. --Eddi (Talk) 16:40, 8 May 2005 (UTC)

While row templates may be the best solution in theory, they would not be best in practice. They would be best for including information specific to certain elements or including data incrementally. If a change is made to a main template, all element articles would have to be modified in a short time. That would be easier with row templates. However, the row templates would be hard and confusing to edit. I personally would not want to use them. In the one template it could have descriptive property names like in the {{Infobox isotope}} template see, tritium. There is an advantage to being able to change the format for all the info boxes in one go though. The single template option works all the more cleaner even if we would have more work in adding fields. It is general editing vs. adding more fields. --The Sunborn

In theory and in practice, template rows so far appear to be the only practicable solution proven to work with all elements and their data. The discussion seems to concentrate on how restrictions from one approach could be avoided which are not necessary in the first place with the other.
All the information is specific to certain elements (insofar as almost no data is specifically available to each and every other element) so this should be in favor of row templates. Including data incrementally is what Wikipedia is all about, isn't it? Confusing to edit? What do you mean? And the names of row template entries can be exactly as much or as little descriptive as the parameter names in a single template, this is no reason to choose either of them. Femto 00:19, 9 May 2005 (UTC)

Guidance on formatting needed

I have put in place the first of the isotope tables I have done. Take a look at Oxygen and comment. There are a few formatting qestions that need to be debated.

  1. The first is do we want to have a multiplication symbol in multiple decay structures, like the two proton emissions of oxygen-12? My publication doesn't have a multiplication symbol. We can't do two of the same symbols in a row because that would be confused in betay decay with double betay decay.
  2. Are alpha emissions considered a helium-4 daughter product? Especially in beryllium-6 and lithium-5 according their decay methods they decay to nothing and would not have any decay products. However, these are both considered "Extremely short-lived particle nuclides" and their decay products can only be measured indirectly. So it might mean that they are decaying to helium.
  3. Just to make sure, I am not putting down decay processes that occur less than one percent of the time. They are listed in my publication but they are not common decay processes.
  4. Should the daughter products link to the actual isotope or to the element article? The current system links to the element article.

--metta, The Sunborn ☥ 20:26, 10 May 2005 (UTC)

First of all I'm not sure if all those isotopes should be in the infobox, at least not under the heading "Most stable isotopes". Of course, all of them are more stable than the nonexistent ones, but under that heading I thought there should be some selection. Perhaps the heading should be changed? As to your questions, (I numbered them to comment more precisely):
  1. If there should be a multiplication sign, I suggest · (&middot;) instead of the letter 'x' or × (&times;). Then the choice would be between e.g. 2·p or 2 p or 2p.
  2. In this table I think it may be too specific to link directly to an isotope, e.g. Carbon-14. On the other hand, if there was an article named Isotopes of carbon, I think that would be the appropriate link. If not, link to the element article Carbon, or the subsection Carbon#Isotopes.
--Eddi (Talk) 08:46, 12 May 2005 (UTC)

Wait a minute. With some 3000+ isotopes, assuming only one decay mode for each, it would be about 30 table entries for each element on average. That's definitely too much for this table, which should only contain the naturally occurring isotopes, a few of the most (and only most) stable, plus anything else that are notable and/or referenced from the articles.

All the other data should be made available on the appropriate "isotopes of element" pages. And I mean it when I say the data should be prepared on those pages first as a reference, from where it can be selected for the element article infoboxes. Using one template for both tables makes no sense since the isotope pages can and should contain much more data than the element infoboxes. If the decay probabilities are available for example, why not make them available there? Femto 13:37, 12 May 2005 (UTC)

Alright, what do you consider most stable? For instance, Mercury-207 is listed as naturally occuring (or otherwise available) but has a half life of 2.9 minutes. Because it is a trace isotope it should be listed. However, there are 19 other isotopes with longer half-lives, not including 6 meta states with thier own values. So really we have 25 values for Hg right there. However, if we say include all available data we would have 41 separate entries on isotopes for Mercury. So I don't know what needs to be done. Is 25 too much? I don't think it can be considering that mercury was a random example, I have no idea how many must be listed for other elements.--metta, The Sunborn 14:07, 12 May 2005 (UTC)

The number of entries that are currently given in the infoboxes is about enough, believe it or not, plus a few omissions. The main purpose of this table is not to be anything close to comprehensive but to provide an overview, like a summarization of a sub-article, and to arouse curiosity for more where available. The linked-to isotopes pages themselves, on the other hand, should be as detailed as the work of keeping them a reproducible reference permits. Femto 17:11, 12 May 2005 (UTC)

However there is no hard rule on what gets in an what doesn't. If you can propose a reasonable one I will definately follow it. A suggested guideline is say isotopes within one neutron of naturally occuring isotopes (not including trace ones), then add the trace occurance isotopes and industrial isotopes. I think that is a fair rule on overview data. --metta, The Sunborn 20:12, 12 May 2005 (UTC)

The current guideline from Wikipedia:WikiProject Elements#Isotopic is "Choose all the stable forms and only the most stable isotopes -- Please don't include any isotopes with half-lifes less than a week". It's deliberately on the restrictive side after some concerns that the table would grow too much. (And it may also be from the time back when the table was first proposed, with little discussion since though.) One general rule of thumb could be that any isotope whose application is worth mentioning in the article also should be in the table, and vice versa. Femto 13:49, 14 May 2005 (UTC)

So, how many furlongs will light travel in this half-fortnight? Note that weeks, like the years used in many of these tables, are not among the units acceptable for use with SI. How about a nice, round 0.6 Ms or 0.5 Ms? I'd presume the rules are different for elements which don't have stable isotopes. Gene Nygaard 15:09, 14 May 2005 (UTC)
Well 0.5 Ms == 5.785 days. Besides the nuclear data is done in MeV which as you might know is not an SI unit. Whatever the days, seven or 5.7 the table should then add the trace occurance (including decay chains of natural isotopes)[This is actually where most normal radiation dose comes from] and industrial isotopes (including emissions of nuclear plants)[because these are common in some places]. --metta, The Sunborn 16:20, 14 May 2005 (UTC)
As you and Femto have quite properly pointed out, major reworking of the guidelines under the "Isotopic" subheading are in order. The discussion here should focus on what exactly those circumstances are.
Yes, in most cases electronvolts are used in that other column, but of course they do not have to be. They could well be SI, and perhaps sometimes are. Like the use of years in a different column, those electronvolts are not SI. That fact, of course, should be noted in both cases, as we have promised to do in the footer. Gene Nygaard 16:47, 14 May 2005 (UTC)

Velocity of sound in Krypton and Xenon very wrong

Allmeasures and WebElements

seem to be the references for the velocity of sound p.e. in Krypton and Xenon.

They both state that the Velocity of Sound in Xenon as measured at 20°C or 293.15 K is 1090 m/s and in Krypton at the same values 1120 m/s (look for yourself)

This is clearly wrong. We (Projektpraktikum at the University of Constance) have at the moment a gas bottle with guaranteed 99.997 % pure Krypton in the lab, and measuring the speed of sound at 23°C (room temperature) using resonance in a closed tube we get .

For those of you who rather believe established sources, see for example this Article from BBC. It doesn't state the exact velocity, but gives a general sense of the value to expect.

I haven't found the value in various books at the University Library, so I just put in our value (for Krypton) which is as good as any and deleted the value for Xenon. We can't let a value off more than 500% stand! (134.34.144.57)

WebElements has a nasty habit of claiming to use certain conditions on one page, but then using values for a different state on another page. Those values may be the speed of sound for the solid phase for all we know, or they are indeed just plain wrong. (The value was still there for the xenon article. Pressed 'preview' instead of 'save page'? Anyway, it's removed now too.) If you have some time, maybe take a look at the dreadfully under-referenced speeds of sound of the elements (data page) and see if you can provide a few values from authoritative references. Femto 15:25, 10 Jun 2005 (UTC)

As we found out in "Thermophysical properties of neon, argon, krypton, and xenon / V. A. Rabinovich ... Theodore B. Selover, English-language edition ed. Washington [u.a.] Hemisphere Publ. Corp. [u.a.] , 1988. - XVIII (National standard reference data service of the USSR ; 10)" the values given are for the fluid state of Krypton and Xenon. The value measured by us (the Projectpraktikum at the University of Constance) is at the moment (apart form theoretical considerations) the only experimental data we know of for Krypton gas (after hours of research at our very well equipped library). Well, Krypton IS very expensive, after all. (134.34.144.57)

This is good! Just make sure to also include any stated conditions where possible. (Hours in the science library...I wish I had had so much fun in school. Simply add four tildes ~~~~ to automatically sign a post.) Femto 17:45, 12 Jun 2005 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Elements/Archive_4&oldid=1137385471"