Jump to content

Template talk:Chembox

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by DePiep (talk | contribs) at 22:56, 18 August 2015 (Q Undid revision 676750836 by Leprof 7272 (talk) I do like you. Why di dyou tink otherwise at all? But you are wrong, so I rv.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

WikiProject iconChemistry Template‑class
WikiProject iconThis template is within the scope of WikiProject Chemistry, a collaborative effort to improve the coverage of chemistry on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
TemplateThis template does not require a rating on Wikipedia's content assessment scale.

Ordering Identifiers

I am ordering the Identifiers alphabetically. From random. -DePiep (talk) 19:27, 12 February 2015 (UTC)[reply]

Maybe the current order is according to importance, too. --Leyo 19:29, 12 February 2015 (UTC)[reply]
As you say: maybe. That is not enough. I am looking at it for a year now, and still have not discovered any structure (of course, if importance is in play then that should show). From alphabetic, we could split into a 2nd header "Specific identifiers" like medicine and countries (EU). The generic id's can remain in top. -DePiep (talk) 19:59, 12 February 2015 (UTC)[reply]
IMO CAS number and EC number should be first and second. --Leyo 20:41, 12 February 2015 (UTC)[reply]
And the others? How does one search? Not everybody knows the order of improtance. -DePiep (talk) 20:48, 12 February 2015 (UTC)[reply]
Most readers will be interested in the CAS number, but currently the very specific 3DMet and Beilstein Reference are first. What about waiting for other opinions? --Leyo 20:59, 12 February 2015 (UTC)[reply]
Better options can be made. As it was, it was chaos. Now, when CAS and 3 × EU are in top --somehow--, by what guide will the reader search for another one? Having to look twice up and down and still be insecure? Print it and use a pen? Plus: someone searching for CAS, why would that person not look for the letter "C"? As said, I'd like to learn how the other id's are presented. When I am looking for an id, I do not know how important it is in the list. -DePiep (talk) 21:11, 12 February 2015 (UTC)[reply]
  • These are some options to order the Identifiers (There are 23 optional datarows today):
1. Keep by ABC as it is today (but we could apply list-changes eg 3, 4, 5 below).
2. CAS in top always, with the CAS datarow having a double border line, the rest follows by ABC.
3. Add a new section, the header saying "Special identifiers" or so. This section then has the medical and country-specific id's (ATC, RTECS, EU-defined, DrugBank). This splits up the longer list nicely & systematically. Both sections are by ABC, with/out idea #2 applied.
4. Some rows have images not identifiers (eg Jmol 3D). These links (data rows) belong in the top "Images" section (show as a text row there). However, this can not be done before moving to Lua module (because, today one would have to copy-paste the SMILES id's to the top chembox-section, looking as if they are entered double in Chembox).
5. Abbreviations go to the "Names" section (when in Lua module).
More ideas? -DePiep (talk) 08:19, 13 February 2015 (UTC)[reply]
I'd vote for option 2. I am interested in seeing opinions of other editors, too. --Leyo 20:21, 15 February 2015 (UTC)[reply]
It is not a "pick one out of five" list. Listen. I prepared and asked three questions, and then I spend time on five suggestions to think of. But all you keep replying is: "CAS must be in top". That is not a development. Now, what are your thoughts on the remarks made in this thread? -DePiep (talk) 21:45, 15 February 2015 (UTC)[reply]
Another thought: Certain identifiers are of interest to readers for reasons other than just being the ID in a database/part of an URL (e.g. CAS RN, EC no., ATC, SMILES). Opposite type identifiers include e.g. ChemSpider ID, KEGG, Beilstein, 3DMET. I would say that the former are more important to readers that the latter. --Leyo 23:28, 15 February 2015 (UTC)[reply]
Yes, so this is what I felt but could not point to. Shouldn't these be in a footnote set of links altogether? Or in a reference? I don't think these external links should be in the infobox at all. And we also removed the icon from showing. [1]. -DePiep (talk) 10:18, 19 February 2015 (UTC)[reply]

Let's build a table just to get an overview. -DePiep (talk) 13:14, 19 February 2015 (UTC)[reply]

Table of id's

Table is under construction. Improvements may be added

Template:Chembox/doc/table of identifiers

Revert

Can this ordering (diff) be reverted until consensus has been reached which order to use. --Dirk Beetstra T C 03:31, 4 May 2015 (UTC)[reply]

Question: Where is the discussion on the order, what makes it controversial, and isn't that a little WP:BIKESHEDish? (I'll watch this page for a response, which is why I marked it as answered.) — {{U|Technical 13}} (etc) 14:05, 4 May 2015 (UTC)[reply]
Technical 13 The discussion is above, but to put it in edits: suggestion by DePiep, first concern posted ('Maybe the order is on importance too' by Leyo), 2 minutes after suggestion, and implementation, 8 minutes after a concern was raised, first reply by DePiep 'As you say: maybe. That is not enough. . I am looking at it for a year now, and still have not discovered any structure (of course, if importance is in play then that should show).' Maybe there indeed was not a lot of structure, and that improvements would be needed, but DePiep just bolbly (well, not really, he first started a discussion but did not wait for answers even after trying to figure it out for a year himself) implemented the change without waiting for answers or suggestions on other possibilities. I suggest that we revert to the status quo, and see whether other options should be explored, especially since concerns were raised only 2 minutes after suggesting, and the effect of the quick implementation on any further discussion. --Dirk Beetstra T C 03:37, 5 May 2015 (UTC)[reply]
Short: alphabetical order is better than random order. You all are invited, time ago, to propose improvements on that alphabetical order. No reason to revert. -DePiep (talk) 20:21, 8 May 2015 (UTC)[reply]
Short: Following a strict and unreflected alphabetical order of all parameters mentioned in the table above would not make any sense. Key parameters need to be on top. --Leyo 00:29, 9 May 2015 (UTC)[reply]
This is about the revert only. I think Beetastra intended to continue the discussion below. -DePiep (talk) 07:04, 9 May 2015 (UTC)[reply]
Short: That the implementation of the alphabetical order does not make sense is the whole reason for the revert.

{{subst:Afd top}} DePiep : "You all are invited, time ago, to propose improvements on that alphabetical order." - Can you point me that 'time ago' diff? As far as I can see you suggested to implement alphabetical order and implemented it, without the consideration that maybe the old order did make sense (and, as a matter of fact, at least some of the identifiers were specifically chosen to be in a certain place, even if you did not know that). Can you please Revert your Bold implementation of the alphabetical sorting of the fields, and allow for Discussion on what the order should be (which, I concur, may in the end be even alphabetical). --Dirk Beetstra T C 07:26, 10 May 2015 (UTC)[reply]

I wont go further in this (second) 'your talked wrong' approach. Technical13 saw it. -DePiep (talk) 08:07, 10 May 2015 (UTC)[reply]
I knew that was going to be your response. --Dirk Beetstra T C 11:40, 10 May 2015 (UTC)[reply]

Ordering of identifiers and information

  • Per User:Leyo's points, I don't know if alphabetical order is the way forward and, per above, I do not think that that should be implemented without discussion. For the Identifiers, certainly the CAS number is the most important, and for some of the other databases the amount of useful data they provide gives them some importance (actually over CAS number which does not really convey information further). On the other hand, identifiers like InChI's and SMILES are generated from the 'structures' of the compounds, and although true identifiers, not likely something that we would link out with. IMHO, they should be grouped at the bottom, together with the external calculated structure generator. For other parameters in other subboxes a similar reasoning should/could be made. --Dirk Beetstra T C 04:30, 7 May 2015 (UTC)[reply]
You can propose & discuss any further order improvements, as I started. Alphabetical order is better than random/chaotic order. -DePiep (talk) 20:23, 8 May 2015 (UTC)[reply]
The fact that today the order is alphabetically does not prohibit any change. The fact that I did open a discussion, and clearly spend time on it, can not be contructed into a negative argument.
As I tried to explain before, any sort criteria should be visible to the uninitiated reader. For example, of course we can just put CAS RN in top. However, then there is no visible structure for the list. The level of information may be a good grouping criteria, but that should be visualised. The reader can not see that from the data label (=LH column text). In other words, we can not make a hidden structure. We can think using extra lines or subheaders. -DePiep (talk) 21:25, 8 May 2015 (UTC)[reply]
The order was, to a certain extend, a chosen order (certain fields were in a certain place in the list because of a reason), it was not completely random, it was not completely chaotic. It is only you who says that alphabetical order is better than random/chaotic order. You indeed did open a discussion, but failed to wait implementation, even while someone commented before you implemented. Per Leyo above, I oppose the implementation of the alphabetical order. --Dirk Beetstra T C 07:30, 10 May 2015 (UTC)[reply]
What order do you propose? Can you add that to the table (eg adding a column with numbers or group description)? Then, how could we make that grouping visual? (subheaders, heavier row-bopttom lines, ...)? -DePiep (talk) 08:04, 10 May 2015 (UTC)[reply]
Partially, as it was - CASNo first, the more informative after that, InChI / SMILES last, they do not need to be grouped, the rest maybe in alphabetical order etc. etc. --Dirk Beetstra T C 11:42, 10 May 2015 (UTC)[reply]
Whatever the ordering structure, it must be clear (say, visible) what that structure is. At least and for now, by alphabet has that advantage. If we apply a different ordering structure, we must convey that to the Reader somehow (otherwise, it would be a 'bag of data', as it is called in information. It appears chaotic/random for the Reader). A good example IMO is the current classification (grouping) of names in {Chembox}.
A first rough setup could be to move specified id's to the top, in groups. CAS being "Generic", SMILES being "generated from the 'structures' of the compounds", etc., and any remaining "Others" must be at the bottom (to keep the word 'Others' meaningful).
While we are at it, I think some entries are misplaced and do not belong in the Identifiers section. I guess |abbr= is more of a name. Jmol is an image only not an ID, but at the moment in the SectionN-setup we have it is difficult to reposition that to the top with other images, because it's defined (created in template code) from the SMILES input. There may be other candidates for repositioning, and all repositionings would require a maintenance job (move the parameter from SectionN=Chembox Identifiers to another SectionM=). Can be done, in the longer run. To be discussed per-ID, I suggest.
Another note: I think we should involve all {Drugbox} identifiers in this too (i.e., those not in {Chembox} today). Over there the same issue might play, and of course in the future a request might come along to add such an ID to {Chembox}.
Other subboxes (SectionsN) best be discussed separately I suggest, to prevent unnecessary complication. -DePiep (talk) 12:26, 10 May 2015 (UTC)[reply]
One could argue that for InChI and SMILES (well, we already collapsed them at the bottom until this disturbance which makes the display of them more chaotic), but the others should not be grouped. The identifiers that were in the top of the list were the more commonly used / more informative - most people simply look for the CAS first. They do not have a special status and therefore no further grouping. --Dirk Beetstra T C 03:20, 11 May 2015 (UTC)[reply]
There are about 23. They do need an order, otherwise they appear chaotic. To you they may not do so, because you are that familiar with them, but the Reader needs support.
And I don't find "[they were the] more commonly used / more informative" convincing. Earlier you wrote "to a certain extend", "it was not completely random". So that only applies to some (which?) of the list. At least you could propose an order in the table for all of them. For a classification it must cover all, there is no "I don't mind" class.
About the collapsing: in mobile view, there is no collapsing option and a show/hide table is shown always. So we must design the infobox as if there is no collapsing. After that, collapsing is just a desktop extra. For this, there is no reason to put the foldables at the bottom, that does not clean up the mobile view. (The mobile view for a page can be tested by clicking on a link on the very last row of any article). -DePiep (talk) 10:56, 11 May 2015 (UTC)[reply]
I guess that nobody has any valid argument (i) for a strict alphabetical order and (ii) against CAS RN being the first identifier. --Leyo 20:40, 11 May 2015 (UTC)[reply]
@DePiep: - Wikipedia does not always follow mathematics, rules, etc. - we have free editorial choice. The order has been like this, seemingly random, for years, and NO-ONE has ever even asked a question why. You barge in, and without waiting for remarks or answers you suggest ánd implement an ordering that had no consensus. Now that is fine, but when opposition exists, then that edit should be reverted and the order should be discussed. And if no consensus exists for a new order, then the status quo stays and a change is not implemented. I've asked before, I'll ask again, can you please revert and get consensus for a new order. --Dirk Beetstra T C 03:28, 12 May 2015 (UTC)[reply]
Actually, looking more at it, the original order follows quite well an importance-ish order. CASNo (best known), pubchem (large, very well known), ChemSpiderID (large, of another big publishing house), drugbank (large, well known for drug information) are the 'bigger identifiers', 3DMet (now at the top) and Beilstein are more specialised information, and as I explained SMILES and InChI are at the bottom. For the drugbox I expect that CASNo and drugbank are high up in the list of identifiers, pubchem probably, and then ChemSpiderID. So your random order, DePiep, was actually not that random (actually, if the list was ordered by 'size of database', or 'age of organisation behind the database' (not counting SMILES and InChI, which are of a different type and therefore chosen to be at the bottom), you would likely get a seemingly very random list, still it is an order - and that order will not be far from what it was). --Dirk Beetstra T C 03:42, 12 May 2015 (UTC)[reply]
By the way, ABC is just an order, it is not necessarily organised. I still argue that the previous order was more organised than the current alphabetical order, and I disagree with the alphabetical order being organised. --Dirk Beetstra T C 05:43, 12 May 2015 (UTC)[reply]
re Leyo: that might be correct, but it is not an answer to the main quest here: by what system should we classify/order all the identifiers?. Please reread earlier notes I wrote on this, for example this and look at the Names-section as example. If things are unclear, please ask. About your reply here: your post leaves open all other questions but that CAS one. If you really want to say "I don't mind all the others", does that imply you leave it to others (like me) to choose anything sensible? -DePiep (talk) 09:58, 12 May 2015 (UTC)[reply]
re Beetstra 1/2: You are still trying to construct my edits and even discussion openings as bad faith edits. Stop it. There will be no revert. As wiki works, you are invited to propose and discuss improvements. -DePiep (talk) 10:12, 12 May 2015 (UTC)[reply]
No, I do not construct them as bad faith, I construct them as Bold edits, but without consensus - Bold edits without consensus should be Reverted until consensus to perform them is formed (or, if no consensus to perform them is formed, the old status quo stands). The current situation is not an improvement, IMHO the old situation was way better. I have hence proposed and discussed the improvements over the current version: reversion to the old situation. --Dirk Beetstra T C 11:01, 12 May 2015 (UTC)[reply]
Whatever. I planned reply 2/2 for content responses, but it puts some work on me to separate useful contributions from useless sidetracking in this thread. -DePiep (talk) 17:03, 12 May 2015 (UTC)[reply]
Not to charge the discussion, but to buy me extra time: I am puzzled by Beetstra's intention to revert to the old sequence with possibly some structure, argued that structure is not that needed (my words). -DePiep (talk) 21:07, 18 May 2015 (UTC)[reply]
@DePiep: - my statement is just that - that structure is not that needed anyway, but actually, there was more structure in it than you saw in the original version, and certain things were certainly placed in certain places for a reason. I am puzzled that you, when you did not see any structure, decided that alphabetical structure was the one to go for, and implemented that without considering that maybe there was a structure that you did not notice (nor did you bother to ask, nor did you bother to consult the community). I keep insisting, the old version can be improved on, but is way better than the current one. --Dirk Beetstra T C 06:11, 19 May 2015 (UTC)[reply]
Bad news: absence of (visible) structure is not good for ~23 items. That's just not how we should present info in this encyclopedia.
Good news: structuring criteria you did mention are great. Of course CAS NR can be in top, by being category "seneral" or "universal". In development, we could have a single second category "Others" with the other 22.
later more. -DePiep (talk) 22:11, 21 May 2015 (UTC)[reply]
Beetstra, a working proposal. I can put a table below here, with those ~23 Identifiers and their properties (like groups, ..), old & ABC order, etc. Then shall we both improve that into a better ordering, here? -DePiep (talk) 22:25, 21 May 2015 (UTC)[reply]
"absence of (visible) structure is not good for ~23 items." .. first of all, who says that there is no (visible) structure, and second, who says that absence of (visible) structure is not good (per the argument I made above: "The order has been like this, seemingly random, for years, " You barge in, and without waiting for remarks or answers you suggest ánd implement an ordering that had no consensus."). To me, the structure/order was quite clear, and seen the lack of questions and/or remarks about this, it bothered no-one. Here you implement the alphabetical order, and immediately you have two people arguing that that is not optimal. See the difference? Again, there was structure, the order was not random, and even if it was, there is no Wikipedia rule to state that that is a problem, and in any case, it did not bother anyone. And the order now is way more random than what it was.
I have a quite optimal order: the one that was in there before you alphabetized it. The more used above, InChI/SMILES-like ones at the bottom, and the rest in the middle. You can put that table with the old order here, and we may chose to swap one of them, but that is about it - they were reasonably ordered 'by importance', seemingly random but actually not. --Dirk Beetstra T C 03:36, 24 May 2015 (UTC)[reply]
In general, I see again your statements that the old order was better without substantiation. You also repeat that the timing of me opening the talk here frustrated discussion, but that does not hold because you have not come forward with any arguments and cooperation WRT the change since (instead, you did find time & energy to stab a PA elsewhere). In other words, if I'd left the change in the sandbox since Feb 12 for fourteen weeks until today, you'd still not have made a useful contribution. (For example: "To me, the structure/order was quite clear, ..." may be true, but why didn't you elaborate and start explaining? "To me ... it is" is not an argument). I also not that your shouted "no one" is incorrect, because quite clearly I did note the issue, and Leyo has written approvements for parts; I might also find contradictions or unclearities in your contributions. Given that you put so much effort in the opening paragraphs, I'd invite you to set up that overview table you finally mention. -DePiep (talk) 12:11, 26 May 2015 (UTC)[reply]

CAS RN in top

Having reread this whole topic & thread: I conclude that best and undisputed is to put CAS RN in top of the identifiers, nothing objects. It follows Leyo's first comments [2], [3]. This can be done without extra visual effects (I otherwise would require). It is good for our Readers, looks intuitive, and no harm in sight.

Below CAS RN all other ~20 ID's alphabetically, undiscriminated. So the order is: CAS RN, 0, ... 9, A, B, C, ... Z. Absent any categorizing criteria (I am still looking for), we have no subgrouping. Also, any further grouping requires some visual clue (like a subheader: "Special ID's:"). All this can be added later, once we agree on categorizing/grouping/presentation. None of this prejudices putting CAS RN in top. -DePiep (talk) 21:29, 22 June 2015 (UTC)[reply]

 Done -DePiep (talk) 22:00, 22 June 2015 (UTC)[reply]

Broken supplemental ATC codes, redundant entries

Both {{Chembox Identifiers}} and {{Chembox Pharmacology}} support ATC codes and DrugBank identifiers. I think it is redundant to include these identifiers in both locations. I propose they be removed from {{Chembox Pharmacology}}, leaving the identifiers only in {{Chembox Identifiers}}.

Additionally, the supplemental ATC codes (|ATC_Supplemental) do not work for either {{Chembox identifiers}} or {{Chembox Pharmacology}}. See Nicotine for an example of how they are presently working in the {{Drugbox}}. See Ethanol (data page) for an example of how they are presently not working for the Chembox. The values are present in the infobox for the data page but the supplemental values do not appear. Sizeofint (talk) 02:49, 16 April 2015 (UTC)[reply]

Yes, yes. Later more. -DePiep (talk) 06:56, 16 April 2015 (UTC)[reply]
Question: is ATC code an identifier? Shouldn't it be in Pharmacology, as just a (medical) property? -DePiep (talk) 16:59, 16 April 2015 (UTC)[reply]
Same for DrugBank: why not under "Pharma"?
 Fixed |ATC_Supplemental= now shows (se Nicotine). -DePiep (talk) 17:50, 16 April 2015 (UTC)[reply]
Thanks! ATC code suggests that it is a classification rather than an identifier as I had assumed. You are probably right about keeping it under Pharmacology. Sizeofint (talk) 18:40, 16 April 2015 (UTC)[reply]
Yes, classification is the right word for ATC. Now DrugBank is an identifier, but at least in {{Chembox}} I'd expect it with medicine/pharma still. That's a more specific place. -DePiep (talk) 18:55, 16 April 2015 (UTC)[reply]
I'd be in favor of that. I'm more interested in eliminating the redundancy than which template it ends up in. Sizeofint (talk) 23:48, 16 April 2015 (UTC)[reply]
 Done. See section below. -DePiep (talk) 11:46, 18 April 2015 (UTC)[reply]

ATC and DrugBank deprecations

ATC parameters: deprecated in {{Chembox Identifiers}}. Should be in

|SectionN = {{Chembox Pharmacology | ATCCode = ... }}

DrugBank parameters: deprecated in {{Chembox Identifiers}}. Should be in

|SectionN = {{Chembox Pharmacology | DrugBank = ... }}

Offending articles are listed in: Category:Chemical infoboxes with misplaced or deprecated parameters.

Also, all articles with depecated parameters are listed in Category:Chemical articles with unknown parameter in Chembox

Maintenance task: any input should be moved from a SectionN = {{Chembox Identifiers to SectionM = {{Chembox Pharmacology. Example: [4] for this article. The maximum number of articles is about 450 for |ATC..= and 450 for |DrugBank..=; previous numbers in the categories (i.e. before these were added): 475 articles in "misplaced & deprecated", 522 in "unknown parameter". Note that multiple categorisation reasons (say, "A" and "T") result in a single category listing, under an arbitrary letter).


When this cleanup is done, the parameters will be removed from {{Chembox Identifiers}} code (will not show in that section any more). -DePiep (talk) 11:46, 18 April 2015 (UTC)[reply]

I partially disagree with this - drugbank number uniquely identifies a certain compound (generally a compound/mixture with a pharmacological activity), and should hence be in the identifiers section. I am not too familiar with the ATC-codes, but I do indeed not think that a certain ATC-code is uniquely identifying a compound, it is more of a classification.
Please do not move the drugbank parameter to the pharmacology section, the pharmacology section should be for things like activities, LD50s (though that could also be a hazard-parameter) etc. --Dirk Beetstra T C 07:08, 19 April 2015 (UTC)[reply]
For now, it is only 'deprecated' in documentation/intention: it still shows when editcode-entered in section Identifiers (said shortly).
For argument: I disagree with Beetstra. Yes DrugBank is an identifier (dozens are), but it is very specific to pharmacology. Chemical--human interaction. So we should put it there. More specific = better. -DePiep (talk) 19:53, 19 April 2015 (UTC)[reply]
Im with Beetstra - identifiers in the top (and collapsed but not CAS). And IMHO I think ATC should not be in the infobox at all. I do not thin its helpful to the reader of chemicals. We have for some years ago removed a lot of entrys because the infobox was pretty big, but would like to have NMR data back again. Christian75 (talk) 20:17, 19 April 2015 (UTC)[reply]
Sigh. Those commentors only showing up afterwards, and never ever putting forward an improvement. Never, ever. -DePiep (talk) 20:30, 19 April 2015 (UTC)[reply]
No its 3-4 four days since your made the suggestion. You should wait at least a week for big changes. Many people doesnt read Wikipedia daily. Christian75 (talk) 21:12, 19 April 2015 (UTC)[reply]
As I said: no improvement ever. -DePiep (talk) 22:54, 19 April 2015 (UTC)[reply]
It is because of you and your attiTude, Christian75, that I choose not to spend extra time on big templates like {{Drugbox}} and Template:TlF. Because: whatever I do, editors like you always come back afterwards to throw shit. -DePiep (talk) 23:23, 19 April 2015 (UTC)[reply]
No, when I (we) come afterwards its wrong, when we come when you are "programming" we should wait because we are interfering with your work?[5][6]. And if its before, the answer is later. I only "complains" about the big things. But I really think that this infobox is crazy. You never know when to use camel case or _ (or both), and all the _ref could be done a lot more smoothly, and some times the words are spelled out, sometimes not. E.g. melting (which it has been for years) was changed to MeltingPt - the reference is called MeltingPt_ref (no big R in ref, and a _ to separate the two words, despite melting point are two words too, and point is normally written pt (with small p)... Just some comments to show that I have a lot of opinions about the changes to the box, but normally doesn't write anything about it - just watching. Christian75 (talk) 10:59, 20 April 2015 (UTC)[reply]

And as I said, drugbank is an identifier, it is not pharmacological data. Identifiers with identifiers, pharmacological data in the pharmacology section. There are a LOT of chemicals that are identified in the drugbank where the majority of the data and content of the article is purely chemical, and for which the pharmacological data is just a minor part of the article. Please put it back in the identifier section, where it belongs, and I will read up on ATC code. --Dirk Beetstra T C 04:24, 20 April 2015 (UTC)[reply]

I disagree with Beetstra, with reasons already mentioned above and more (eg, data-independency). But alas since Beetstra seems to be Director of Knowledge on Wikipedia, I can not win any argument. -DePiep (talk) 19:17, 22 April 2015 (UTC)[reply]
Clearly, as with the 'lethal dose' vs. 'median lethal dose' situation, your argument is that you should have full freedom to implement the changes in whichever way you want them, and we should not even counter your arguments, nay, we should not even interfere with that - we should just be grateful that you inform us beforehand. I actually even wonder why you are here asking these things, after all you know that implementing 'lethal dose' was the right choice, as that you here simply have decided that drugbank, even though it is an identifier, should be in the pharmacology section as that is where people who want to know about drugs would want to find that identifier. --Dirk Beetstra T C 07:37, 24 April 2015 (UTC)[reply]
Why talk with Beetstra when he edits their way anyway? The point is, Mr Beetstra know-it-all&do-it-all, that you edited without discussion, and now you come back here to join an early discussion to discuss your edit afterwards. That is not wiki. That is leapfrogging. Or let me spell it out: editing without joining the discussion is editwarring. -DePiep (talk)
I don't know, you suggested this on 18, I was here on 19 objecting to a part of the change, I have not touched this part, just commented on a part that you discussed before implementing. This section is about a.o. the drugbank identifier, and you obviously do not have consensus to move that into the pharmacology section. The rest of the reply will be in the appropriate section, I suggest that you keep your comments there as well. --Dirk Beetstra T C 03:56, 29 April 2015 (UTC)[reply]
Concur with Dirk @Beetstra:, and note that M. DePiep has a long history of resistance to consensus when it disagrees with his opinions, and a parallel history of personal disrespect in such discussions. If this gets elevated to a noticeboard for discussion, ping me, please. Le Prof Leprof 7272 (talk) 03:19, 1 May 2015 (UTC)[reply]
Leprof 7272, this is concerting in bad faith. You could withdraw this. -DePiep (talk) 22:21, 3 May 2015 (UTC)[reply]

ATC and DrugBank deprecations reversion

As this implementation (diff, diff, as well as documentation, and some implementations on pages) clearly did not receive consensus, can this please be reverted back to the earlier state, and then properly discussed. Thanks. --Dirk Beetstra T C 11:21, 3 May 2015 (UTC)[reply]

Done Please update the documentation yourself as is appropriate. — {{U|Technical 13}} (etc) 14:11, 4 May 2015 (UTC)[reply]
Denied. Can someone stop talk-deaf Beetstra, please? -DePiep (talk) 03:02, 5 May 2015 (UTC)[reply]
No, AFAIK my account is not compromised. Btw, are you sane yourself? Beetstra --a friend of you then-- is behaving weird. Beetsra is in an "revert-dont-talk" mode. That's bad! Can you talk to him, help him? -DePiep (talk) 03:23, 5 May 2015 (UTC)[reply]
@Technical 13: You say that edit warring is strange for DePiep, see another discussion above (the point what DePiep is alluding to in his above reply), and history of Template:Chembox LD50 and history of Template:Chembox LC50, as well as the way of implementing the ordering of identifiers (see Wikipedia_talk:Chemical_infobox#Ordering_Identifiers). --Dirk Beetstra T C 03:42, 5 May 2015 (UTC)[reply]
Who put that {{edit template-protected}}} here? -DePiep (talk) 04:05, 5 May 2015 (UTC)[reply]
I did, you could have seen that from the history. I hope you understand why I took that approach. --Dirk Beetstra T C 04:49, 5 May 2015 (UTC)[reply]
  • @DePiep and Beetstra: I am sane enough, never suggested either of you were not. You should know by now, as an introvert, I have no friends; so no, Dirk isn't my friend. Based on my previous interactions with DePiep, this kind of edit warring is fairly unusual. The template is fully protected for now, and I'm going to bed. Since I don't really care what arguments are or aren't in this template, I'll happily work with everyone that has commented on this and try to help determine the consensus and request an admin make ay changes that consensus supports. In the meantime, I'd suggest you both take a break from this topic and WP:CALM yourselves down remembering this is only Wikipedia and not a matter of life or death. Good night! — {{U|Technical 13}} (etc)
Tech13 and Beetstra will go free -- admins. -DePiep (talk) 04:18, 5 May 2015 (UTC)[reply]
@Technical 13: - If you go through the threads, I think you will notice more editors (Christian75, Leyo, Leprof 7272) are involved in this situation. Anyways, I am looking forward to arguments from DePiep supporting the changes they suggested. --Dirk Beetstra T C 04:49, 5 May 2015 (UTC)[reply]
  • I did notice there were multiple editors in this discussion, and DePiep was going right at wheel warring to push their preferred version through. I decided after the third revision to request full protection (so neither him nor I can change the template directly at this point) to prevent this from getting to a point where DePiep was liable to loose his  Template editor privileges and be blocked for 3RR (although he may still loose TE). Anyways, I'm going to kind of sit back a little and watch while discussion unfolds (too busy with finals this week to really interject much). — {{U|Technical 13}} (etc) 20:13, 5 May 2015 (UTC)[reply]
lol: Prof 7272 is a troll, of course. That's your friend, Beetstra. -DePiep (talk) 04:56, 5 May 2015 (UTC)[reply]
  • I'd consider that a PA DePiep unless you can back up that claim with evidence, I need to ask you to retract that comment. Let's please keep this civil and discuss what changes need to be made here and why and figure out how to get it done. Thanks. — {{U|Technical 13}} (etc) 20:13, 5 May 2015 (UTC)[reply]

- revert this edit, which was not discussed, and which does not contain any relevant edit summary. Christian75 (talk) 05:36, 5 May 2015 (UTC)[reply]

@Christian75: - that was a self-revert by DePiep to the version implemented by Technical 13 above after my edit request. --Dirk Beetstra T C 05:43, 5 May 2015 (UTC)[reply]
Oops my mistake. Christian75 (talk) 06:30, 5 May 2015 (UTC)[reply]
(edit conflict)This is edit warring, really. -DePiep (talk) 05:48, 5 May 2015 (UTC)[reply]

ATC and DrugBank deprecations new discussion

So after these shenanigans the original question still stands. We currently have redundant entries for ATC code and the DrugBank identifier in the "Identifier" and "Pharmacology" sections. Should this redundancy be eliminated and if so which sections should these entries be placed in? Sizeofint (talk) 00:06, 6 May 2015 (UTC)[reply]

  • As per above comments, 'drugbank' is an identifier, and should be in the identifiers-section, and if I understand correctly, ATC-codes are more classifications, it tells you something about a drug. If that is so, it indeed is not an identifier, and this one should be in another section - I guess the Pharmacology section is more appropriate. --Dirk Beetstra T C 03:16, 6 May 2015 (UTC)[reply]
Sandbox demo available at Template:Chembox/testcases2#EC_Number. -DePiep (talk) 11:24, 19 May 2015 (UTC)[reply]

The external links in these subtemplates are broken. The respective search query at http://echa.europa.eu/information-on-chemicals should be linked instead. BTW: Do we really need both templates? --Leyo 23:09, 18 May 2015 (UTC)[reply]

Note: spelling should be consistent wikiwide, most likely "EC Number" table 2.2 (capital N, though ECHA uses lc in places). (see subsection below)
If I see this right, those registry systems (databases) and their institutions have merged & moved in recent years. Since today they lead to the same database (internet source), there is redundancy as Leyo notes. I propose to put both input options |EINECS= and |EC-number= into the single data row EC number with the link as given. |EINECS= then be declared deprecated (input keeps working OK, but not advertised any more. No need to edit articles). With this, the word "EINECS" does not appear in the labels (infobox LH-side column). Sandbox demo will follow. -DePiep (talk) 09:41, 19 May 2015 (UTC)[reply]
I indeed think that they are not both necessary and can be merged as DePiep suggests.
Regarding the link - I did not find any way to get a proper working URL with the EC-number as one of the parameters, it is handled by JAVA it appears. I am afraid that they are going to loose a lot of incoming links. --Dirk Beetstra T C 10:59, 19 May 2015 (UTC)[reply]
Yes, we want the link to open some data page (data sheet) for the substance. If we can not create that link, I think the ECHA site should be linked as a source: EC Number | 200-815-3[1]
-DePiep (talk) 11:11, 19 May 2015 (UTC)[reply]
Hmm, that would mean that every page needs the ref to be attached (you can not template references, unless that changed recently). Anyway, the primary reference is already accessible through EC Number. --Dirk Beetstra T C 11:21, 19 May 2015 (UTC)[reply]
The link I added would be added by the template, because it is the same for all. And a bit meaningless as a source. This is the URL when I searched for (ethylene) 200-815-3: [7] (URL fails). If I can compose that URL from the EC Number input, it's a source (but still not a data sheet). -DePiep (talk) 11:32, 19 May 2015 (UTC)[reply]
That is what I mean, AFAIK, if you make a template containing the text "<ref>blah</ref>", and transclude that template on a page, then the reference does not come through on the page (it does not appear in the list of refs), and likely will be parsed as a 'ref #1' by default (it is the first and only ref on the template). It would only come through if you put it as a plain link in the template. --Dirk Beetstra T C 12:20, 19 May 2015 (UTC)[reply]
Our preferences, by prio: 1. Automated link to a data sheet. 2. Automated reference link to the source. 3. free input by editor. To facilitate option 3 I'll add |EC-number_comment= for free text. -DePiep (talk) 11:57, 19 May 2015 (UTC)[reply]
I agree, though I think that 2 is not possible in ref-form - only in 'plain link' form (vide supra). For free input the comment field is good, and that can then take alternative references (though .. which). I think between 2 and 3 we should just rely on the 'general disclaimer' for the infoboxes. We do not need to reference data that is not expected to be challenged (WP:V), and if a specific case is challenged for some reason, then that is where the free-comment-field is for (the challenge in itself needs a reliable source to be verified, otherwise it is just a 'and I say it is 42'-type of challenge). --Dirk Beetstra T C 12:20, 19 May 2015 (UTC)[reply]
I'm confused. IMO when the external link (el) leads to a data sheet, we link the text. (e.g. ATC for aspirin: A01AD05). But when it is only a source defining the number, it should be in a reference superscript number:[1]. Both can be created by the template (we hope), no extra userinput should be required. -DePiep (talk) 17:44, 19 May 2015 (UTC)[reply]
The problem is not the preference, the problem is (was?) technical - A couple of years back when I tried it, I could not include a reference from a transcluded template .. of course, a <sup>http://example.org could solve the problem as well. --Dirk Beetstra T C 03:24, 20 May 2015 (UTC)[reply]
Not any more. I've added links, see sandbox demo, just to test this (not proposed for live this way). Problem left is that we have nothing to link to (because we can not compose an URL using the input EC number). That would mean no external link at all. -DePiep (talk) 08:05, 20 May 2015 (UTC)[reply]
My point is in the top-left example - you link in the left column to EC number (should be EC index, but that is another part of the discussion below), telling you what it is and where you can find it and what it means for a compound, and in the right column of that box you have a reference to the search engine .. which in a way is just a tad better than 'go find it on google to see whether it is correct, here is a link to google'. I am still not sure whether that 'reference' there is needed.
Good to see that references can now be transcluded from templates, that has changed in the mediawiki setup. --Dirk Beetstra T C 13:12, 20 May 2015 (UTC)[reply]
re 1: don't worry, that was just a wiki-technical proof to show: we can add ref links nowadays. I removed this goofy link already.
re 2: Yes. Since we can not link usefully, I propose to add no external link to the right-hand side for EC number. Because we do not have a useful one.
re 3: You say 'EC Index' not 'EC number'? Are you sure? These are different numbers (200-815-3 vs. 603-055-00-4 is [7] vs [9]!) I say this should be 'EC number'. More about 'EC Index' below, of course. Mistake? -DePiep (talk) 21:27, 20 May 2015 (UTC) re#3 added -DePiep (talk) 21:27, 20 May 2015 (UTC)[reply]
You're right, I am getting confused. EC number is what we are talking about here. --Dirk Beetstra T C 03:34, 21 May 2015 (UTC)[reply]
All right. Current sandbox demo = proposal by now. I will ask formally tomorrow etc.. -DePiep (talk) 21:48, 21 May 2015 (UTC)[reply]
  • Concluding, I think this is a point of consensus and so I propose to change the data row into (the example is ethylene):
EC number | 200-815-3

Note that the actual EC number is not linked. More tests are shown in testcases. @Leyo, Beetstra, and Christian75: pinged. -DePiep (talk) 14:05, 23 May 2015 (UTC)[reply]

Looks good, but I would name the parameter EC number. EC-number may remain an allowed alternative. --Leyo 19:13, 24 May 2015 (UTC)[reply]
OK, parameter is |EC number=. Kept for compatibility: |EC-number=, |EINECS=. Deleted: |EINECSCASNO=. Also added |EC number_Comment= in pattern of other identifiers. (I was using the don't-space habit as in |ATCCode=; it's arbitrary). -DePiep (talk) 11:56, 25 May 2015 (UTC)[reply]

spelling

About spelling, all mention of EC number (in the link) spell it EC number but tabel 2.2. Its a little bit strange to have the abbreviation EC Number, when the full title is European Community number (with small n). Christian75 (talk) 11:46, 19 May 2015 (UTC)[reply]
ECHA and it's predecessors are not very consistent (also not in writing CAS NR). Best is to find the defining document. So far, the hyphen is out. -DePiep (talk) 11:54, 19 May 2015 (UTC)[reply]
The capital on the N seems a bit silly, even Wikipedia itself is inconsistent there. IMHO, 'number' is not a given name, so no capital .. I think 'EC' is a good compromise for 'European Community' here, as that is what they use themselves as an abbreviation and it does not wrongly suggest something else (though .. Enzyme Commission number?). The hyphen can be out in the display, though maybe the different variety-possibilites of the parameter in the chembox should include the one with hyphen. --Dirk Beetstra T C 12:20, 19 May 2015 (UTC)[reply]
Spelling should be copied from the definition by the source (i.e. an E.C. document), but we have not found that. Second option is to copy the EC (-institites') habit, which is mixed uc/lc in this case. I get the impression lowercase "n" more often. So I'll set it to "EC number". -DePiep (talk) 20:02, 19 May 2015 (UTC)[reply]
Sure the Enzyme Commission number "EC number" is creating ambiguity, esp. since it touches chemistry too. The actual number pattern differs, which helps a bit against confusion (for the initiated). WP:Accessibility and WP:DAB do not help me out in this. We could spell EC out here, in the label: European Community number, but for who is this clarifying? I think labeling it EC number is acceptable. -DePiep (talk) 20:02, 19 May 2015 (UTC)[reply]
EC number we'll write. Weird that the EC is not stable themselves. -DePiep (talk) 00:23, 22 May 2015 (UTC)[reply]
 Done. See #Template edits 7 June 2015. -DePiep (talk) 11:40, 8 June 2015 (UTC)[reply]

subsection for references

Parameters EINECSCASNO and EU index

I found two more parameters and data rows that are (possibly) related.

Same issue: broken link, same EC Number identifier. Does not look useful to me. Propose: merge into EC Number as above (with correct link), and delete this data row from {Chembox} completely.
Early conclusion: After edits [8] and Special:Diff/663063605 not used any more in articles. Following discussion below, this parameter+data row will be deprecated and removed. -DePiep (talk) 12:15, 19 May 2015 (UTC)[reply]
 Done and deleted. -DePiep (talk) 11:40, 8 June 2015 (UTC)[reply]
EINECSCASNO is indeed related, you can link into the EC-database using the CASNo .. Don't think it is necessary to keep using it, depracate, rename and delete.
EUIndex might be the third number in e.g. this document for propylene oxide ("EC Number 200-879-2; CAS-No 75-56-9; Index Number: 603-055-00-4). They describe here "INDEX number: The INDEX number (format XXX-XXX-XX-X) is a European number attributed to substances listed on Part 3 of Annex VI to CLP Regulation (List of harmonised classifications and labelling)." I also see the designation "Annex VI Index number". Ah, that gives:

Entries in Part 3 are listed according to the atomic number of the element most characteristic of the properties of the substance. Organic substances, because of their variety, have been placed in classes. The Index number for each substance is in the form of a digit sequence of the type ABC-RST-VW-Y. ABC corresponds to the atomic number of the most characteristic element or the most characteristic organic group in the molecule. RST is the consecutive number of the substance in the series ABC. VW denotes the form in which the substance is produced or placed on the market. Y is the check-digit calculated in accordance with the 10‑digit ISBN method. This number is indicated in the column entitled "Index No".

in this document. It is a classification of compounds (hence not an identifier, I am not sure whether this is by definition unique for a compound). I guess we want to reproduce this number somewhere in the infobox (a google search on "603-055-00-4" nicely also includes Wikipedia as a result; though I must confess that I don't know how many people would search by this number - maybe people are interested in 'which compounds are classified by EU Index number starting with "603").
This brings up a possibility - do we want a sub-template 'classifications' for the chembox, containing this type of information (ATC-code, EU Index, ..)? --Dirk Beetstra T C 10:59, 19 May 2015 (UTC)[reply]
Since the index number is not even given in the C&L inventory (for your example above), I don't really think it's worth having it in Wikipedia. --Leyo 16:17, 19 May 2015 (UTC)[reply]
When used, there should be an article EU Index (or a section in EC Number) for this. wrt a proposed new section "Classifications", I prefer not to separate classes but to keep them close to their specific topic (so ATC Code with medicine/drugs/pharmacology), as that is where a reader will search & expect it. This way, the extra information "ATC is drug related" is added with no extra cost. -DePiep (talk) 17:33, 19 May 2015 (UTC)[reply]
I think it should link to EU Index, which either is an own article, or a redirect to a section in EC Number (the latter case preparing for when s.o. converts the redirect to an article, though that is not a big issue since now the links are just one template, and the template is easily changed when article contents changes. --Dirk Beetstra T C 03:24, 20 May 2015 (UTC)[reply]
Simple: we know that 'EC Index' exists in real life. If enwiki article/redirect EU Index / EC index does not lead to an article or section with substance, it is not worth mentioning in {{Chembox}}. -DePiep (talk) 21:38, 20 May 2015 (UTC)[reply]
It is that simple, but I think that EC Index should be mentioned on Wikipedia, looking around, the numbers are used by other organisations as well, so it seems that the chemical community finds it useful. --Dirk Beetstra T C 03:34, 21 May 2015 (UTC)[reply]
I'm sort of waiting for you to create that link+text content, the lefthand label EC index (I myself am not familiar with that chemistry content). Then I'll make it link in the {Chembox} datarow. Choose capital for Index/index as you think best. -DePiep (talk) 21:42, 21 May 2015 (UTC)[reply]
I'll see if I can get to that. I think it is funny that you state here 'I myself am not familiar with that chemistry content'. It is perfectly in line with your lack of understanding that the old order of identifiers was actually more ordered than you think, and puts into perspective your insistence that the order should be visible. --Dirk Beetstra T C 03:41, 24 May 2015 (UTC)[reply]

Remove 'EU Index' from Chembox

  • As may be concluded from the above thread, and supported by separate contributions by #here by Chemistaddict, there is no usable definition for EU index, nor is there a source that associates numbers with substances. All in all, this is not useful and sourceable data. I propose to remove data |EUIndex= and its datarow from {{Chembox}} completely. -DePiep (talk) 14:19, 22 June 2015 (UTC)[reply]
checkY prepared. |EUIndex= will be deleted. -DePiep (talk) 23:21, 24 June 2015 (UTC)[reply]
 Done -DePiep (talk) 22:27, 7 July 2015 (UTC)[reply]

Change MSDS to SDS

The United Nations Globally Harmonized System of Classification and Labelling of Chemicals (GHS) calls for the harmonization of data sheets for chemicals, using the name "Safety Data Sheet" (SDS). It's not a law or regulation, but a guideline that countries should adopt. All large, English-speaking countries have adopted the guidelines—the EU (UK & Ireland), US, Canada, Australia, & New Zealand—and the sheets formerly known as Material Safety Data Sheets (MSDS) will now be called SDSs in these jurisdictions (see also Talk:Safety data sheet#Move to Safety Data Sheet). I have moved the Wikipedia article on this subject from material safety data sheet to safety data sheet, given the UN guidelines and use in all large, English-speaking countries.

Template:Chembox, Template:Chembox Hazards, and any other relevant infoboxes need to be adjusted to use the term SDS, replacing MSDS (this appears in the "Hazards" section of the Chembox template). I plan to make a request at Wikipedia:Bot requests to change other occurrences in articles (eg. on data pages such as Methanol (data page)), so please note anything that could be included in the request (such as changing all occurrences of "ExternalMSDS" parameter to "ExternalSDS", if that is appropriate). AHeneen (talk) 08:06, 28 May 2015 (UTC)[reply]

If the article is moved, then I would suggest that all templates calling that should just be changed to reflect that. --Dirk Beetstra T C 08:15, 28 May 2015 (UTC)[reply]
Implemented, moved the templates, renamed the calling. Please check if something is missing. --Dirk Beetstra T C 08:21, 28 May 2015 (UTC)[reply]
The template documentation needs to be updated. AHeneen (talk) 08:37, 28 May 2015 (UTC)[reply]
@AHeneen and Beetstra: We need to be clear on the spelling of data page subsection: Safety data sheet or Safety Data Sheet, because it now differs while we use automated linking. This is urgent because of the BOT request. My only preference is consistency. -DePiep (talk) 12:15, 30 May 2015 (UTC)[reply]
The article is currently called 'Safety data sheet', so I guess no camel case throughout, then. --Dirk Beetstra T C 03:38, 31 May 2015 (UTC)[reply]

SDS handling

  • A question not about this change, but about SDS and how we show it in the infobox. The template code now says/does:

"When the {{PAGENAME}} (datapage) exists, link to [[{{PAGENAME}} (datapage)#Safety Data Sheet|External SDS]], and do not show any |ExternalSDS= input." Example: for Ammonia, the datapage exists so the link shown is to Ammonia_(data_page)#Safety_Data_Sheet, labeled "External SDS". And existing input |ExternalSDS=[http://www.inchem.org/documents/icsc/icsc/eics0414.htm ICSC 0414] (anhydrous) is not shown or used. The question is: do we want this?

I also note that when the datapage exists, an extra section is added to the infobox: "Supplementary data page", so that page is linked more often from the infobox. There are ~150 such datapages, see Category:Chemical articles having a data page.

Minor notes: 1. The wikilabel "External SDS" does not sound correct, it is a wiki page. 2. The targeted #section name is changed here to SDS, but not in the actual data page. -DePiep (talk) 15:05, 28 May 2015 (UTC)[reply]

Note that I have made a request for a bot to change the chemical data pages, changing the section titles from "Material safety data sheet" to "Safety data sheet" (Wikipedia:Bot requests#Change MSDS to SDS). Someone familiar with the chemical infoboxes needs to coordinate with those who respond to the bot request what (if any) changes should be made to the infobox text in chemical articles...for example, should the "ExternalMSDS" parameter be changed to "ExternalSDS"? If yes, then a bot can edit all the articles to change the parameter name. I am not familiar with template coding (except navboxes), so this is something that an editor familiar with these infoboxes needs to coordinate. AHeneen (talk) 01:40, 29 May 2015 (UTC)[reply]
|ExternalMSDS= is deprecated but not eliminated. It will not be documented. |ExternalSDS= is the new parameter. There is no requirement to edit that name in the articles.
Do you have an opinion on my main point: when datapage exists, any input |ExternalSDS= is not shown. eg Ammonia. Do we want that? -DePiep (talk) 10:37, 29 May 2015 (UTC)[reply]

I am not in favor of the “External(M)SDS” parameter anyway. IMO any non-self-evident value should be referenced using ref tags.
There are cases, where some values are included in an external SDS, while others are found in a different SDS. Hence, it does not make sense to link to one SDS only. --Leyo 12:26, 29 May 2015 (UTC)[reply]

Could that be written into a proposal, for the SDS's? -DePiep (talk) 13:11, 29 May 2015 (UTC)[reply]
I don't understand, sorry. --Leyo 22:39, 29 May 2015 (UTC)[reply]
Can you start a proposal on how we should handle & show SDS's? We have:
... (data page) as infobox section, ... (data page)#Safety data sheet as internal link - labeled External SDS confusingly, and |ExternalSDS= parameter (likely having external links; weirdly not showing when (data page) exists.).
Or else: how would you set SDS up from scratch, for this infobox? -DePiep (talk) 22:48, 29 May 2015 (UTC)[reply]
IMO any non-self-evident value needs to have a <ref>…</ref> behind. --Leyo 11:33, 30 May 2015 (UTC)[reply]
Very well. But SDS is not a value, it's a page (data sheet); that's internal and/or external links. How should it look like in the infobox? For ammonia:
SDS | ICSC 0414 (anhydrous)
SDS | SDS (data page)
I see no use to add a <ref> to such a link (internal or external). -DePiep (talk) 12:07, 30 May 2015 (UTC)[reply]
I was referring to parameters such as melting point, density or solubility that should have <ref>…</ref> after the value. --Leyo 19:36, 30 May 2015 (UTC)[reply]
SDS does not need to be referenced, data pulled out of a specific SDS would need to be referenced to the specific SDS it comes from. --Dirk Beetstra T C 03:38, 31 May 2015 (UTC)[reply]
Yes, that is what I meant. --Leyo 09:47, 31 May 2015 (UTC)[reply]

A quick repair

Current presentation of SDS has two flaws (demo's from ammonia). I propose to correct them.
1. The internal link to the a data page is wikilabeled (shows text):

SDS | External SDS Red XN

This is incorrect text, it is not external. I propose to make that

SDS | Data page

2. When a data page exists that one is linked to OK, but then any regular input for |ExternalSDS=/|ExternalMSDS= is not used & not shown at all. I don't see why that is. I propose to have that input value shown:

SDS | ICSC 0414 (anhydrous)

See demo at Testcases. To check datapage-detection: use ammonia Preview with SectionN={{Chembox Hazards/sandbox. Other improvements in discussion (see section above, eg by Leyo) can be added later on without prejuduce. Comments? -DePiep (talk) 12:48, 30 May 2015 (UTC)[reply]

Todo/willdo: no repetition of SDS in LH label. -DePiep (talk) 13:05, 30 May 2015 (UTC)[reply]
Maybe the LH label should now be written out (I agree that the word 'external' should go)
Safety data sheet | Data page
The abbrev. is not actually needed there, there is enough space, and readers don't have to go the extra step to see what SDS actually stands for. --Dirk Beetstra T C 03:38, 31 May 2015 (UTC)[reply]
All right. And when both, it looks ~like:
Safety data sheet | Data page
                             | ICSC 0414 (anhydrous)
-DePiep (talk) 23:52, 2 June 2015 (UTC)[reply]
Done, both will show. See the Testcases. Also added: parameter |Hazards_data_page= to set (and overwrite) an exsting data page. So: |Hazards_data_page=[[Main page]] will overwrite Ammonia (data page). -DePiep (talk) 12:10, 5 June 2015 (UTC)[reply]
 Done. See #Template edits 7 June 2015. -DePiep (talk) 11:40, 8 June 2015 (UTC)[reply]

Current status

As of 23:18, 22 June 2015 (UTC)

An existing |PAGENAME (data page))= automatically appears in SectionN= {{Chembox Hazards|...}} (see Ammonia)
An existing |PAGENAME (data page))= automatically appears as "Supplementary data page". (again; see Ammonia)
In Section {{Chembox Hazards}} one can add |ExternalSDS=.
Optionally, in {{Chembox Hazards}} |data page= overwrites an existing data page name.
-DePiep (talk) 23:18, 22 June 2015 (UTC)[reply]

Adding LCLo and LDLo

Hello all, I was wondering what people thought of adding LCLo and LDLo values to the chembox. I think it could be a useful addition, especially in situations where there isn't literature with an LC/LD50 and there is just a LD/LCLo. Best, Emily Temple-Wood (NIOSH) (talk) 01:40, 29 May 2015 (UTC)[reply]

I see no issue with this, I'm given to believe that LD50 isn't really a useful value anyway (when would you even want to kill half of a group of things?). Lowest published lethal dose does seem much more relevant. However, if this goes ahead can I request that some work be done on Lethal dose. Lowest published lethal dose should probably be merged into it, and redirects created for LCLo etc. likewise our articles on PEL and REL could do with some modernizing. Emily is doing an excellent job of adding huge amounts of data, so we should make sure that terms used are easy to find and well explained and references. --Project Osprey (talk) 08:29, 29 May 2015 (UTC)[reply]
What would be the exact lefthand text for these? And how do should they relate to existing LD50 and LC50 data rows (sequence, in one row, ...)? -DePiep (talk) 10:00, 29 May 2015 (UTC)[reply]
I propose either:
Hazards
LCLo (Lowest lethal dose) e.g. 50 ppm, 50 mg/kg
or
Hazards
LCLoTooltip Lowest published lethal dose e.g. 50 ppm, 50 mg/kg
Units should not be automatically added (the value might have one of several possible units (ppm, or mg/kg etc), so the freedom to add such units would be needed). I would suggest adding it on own row, just below LD50 in chembox. --Project Osprey (talk) 10:38, 29 May 2015 (UTC)[reply]
I'd prefer the top one. Can use subscript: LDLo. There are two new data to position, LDLo below LD50 and LCLo below LC50 I guess? -DePiep (talk) 10:48, 29 May 2015 (UTC)[reply]
I agree, but lets wait and see what @Emily Temple-Wood (NIOSH): thinks, it's her idea after all. --Project Osprey (talk) 11:14, 29 May 2015 (UTC)[reply]
I'm thinking of this: both LC-values together in one box:
Hazards
LC50 (Lowest published lethal dose)
LCLo (Lowest lethal dose)
11,900 mg/kg
50 ppm, 50 mg/kg
-DePiep (talk) 19:09, 29 May 2015 (UTC)[reply]
Text in LH label are getting long. They shoudld be hinting, not defining. Also, LCLo has no target page.
All together, this is getting very detailed. I expect more LD... types of data. Would it help if we add a general-purpose data row: |LD_label= for free LH label text, and |LD= for its data?
Anyway, here is a first sandbox demo. See also Testcases10. Params for now are |LDLo=, |LCLo=. -DePiep (talk) 19:58, 29 May 2015 (UTC)[reply]
demo 1
Hazards
Lethal dose or concentration (LD, LC):
11,900 mg/kg
10 mg/kg
1234 ppm
50 ppm, 50 mg/kg
@DePiep and Project Osprey: Sorry it took me so long to get back to you - this looks great and I'm so glad you're both on board with this idea! Thank you both so much. :) Emily Temple-Wood (NIOSH) (talk) 01:54, 30 May 2015 (UTC)[reply]
Please read the points I noted in my last post. It is getting very detailed & long. -DePiep (talk) 10:06, 30 May 2015 (UTC)[reply]
@DePiep: I don't think there are any more LD types of data, so I'm not sure a general-purpose data row would be helpful particularly. Emily Temple-Wood (NIOSH) (talk) 20:26, 30 May 2015 (UTC)[reply]
Emily and others, I disapprove of this LD/LC-set of four, as it is now. Texts are too long, the topic area is fuzzy (see Category:Toxicology), the lefthand (LH) labels take toooo much space, into three lines even (they should just describe or hint, not define the indicator!), and LCLo does not even have a wikilemma. (Why would we note a value that does not even have a wiki link?). -DePiep (talk) 23:21, 30 May 2015 (UTC)[reply]

@DePiep: We could pipe the links, which would solve the problem of them being so wordy. LCLo should absolutely have an article and I will put it on my to-do-asap list. (perhaps it will even be done by the time you see this message! :D) Emily Temple-Wood (NIOSH) (talk) 02:16, 31 May 2015 (UTC)[reply]

New: Lethal concentration low. -DePiep (talk) 13:54, 5 June 2015 (UTC)[reply]
@DePiep: - You could do without the written out fieldname (just call it LD50, LDLo, LC50 and LCLo respectively), though I prefer the written out name since it is more clear to the reader ('Median lethal dose' is more informative and gives the reader an idea what is being talked about). --Dirk Beetstra T C 03:50, 31 May 2015 (UTC)[reply]
I would favour the use of Template:Abbrlink (e.g. LDLoTooltip Lowest published lethal dose). --Project Osprey (talk) 17:48, 31 May 2015 (UTC)[reply]
@Project Osprey: I didn't even know that existed - that seems like a good solution! Emily Temple-Wood (NIOSH) (talk) 16:40, 1 June 2015 (UTC)[reply]
@Project Osprey: - I think that is a great solution! --Dirk Beetstra T C 06:10, 2 June 2015 (UTC)[reply]
re Leyo: 1. It's not an abbreviation, it's a quantity (a qualified one). 2. Though w3c introduced it for abbreviations, it is not intended for other tooltipping usage. 3. In mobile view, it appears as a regular link. No abbr-effect available. 4. WP:ACCESS: we should not require a secondary action (like click or hover) to show information.
re short LD50 only: In general, the texts "LD50" etc. are not commonly known, so we should add information.
But I don't think it should be a full definition, a descriptive addition is OK. So I propose pattern like:
Lethal dose LD50
Actual linking (=the wikilabel) might change. -DePiep (talk) 11:19, 2 June 2015 (UTC)[reply]
I agree with the first part, I'd prefer the terms to have a visible explanation. But per the comparison of LD50 and LDLo - The term 'Lethal dose' is not enough and confusing, it has to include 'median' and 'Lowest' at the least to distinguish between the two. --Dirk Beetstra T C 11:52, 2 June 2015 (UTC)[reply]
Yes it's very very subtle. Compare Readers' view:
Lethal dose LD50
Lethal dose LDLo
Of course, the target links will differ. I like most of it though, good links added. -DePiep (talk) 23:58, 2 June 2015 (UTC)[reply]
The point was not to rely on the target links. I think that the difference is too subtle - a reader will read the text, not interprete the subscript on the identifier. --Dirk Beetstra T C 11:26, 3 June 2015 (UTC)[reply]

(arbitrary break, introducing sublevels)

The only work-around I can think of would be to break the data into sub-tables. Is this possible and convenient? --Project Osprey (talk) 12:48, 2 June 2015 (UTC)[reply]
Demo 2 - Project Osprey
Lethal concentration
Median LC50 1234 ppm
Lowest LCmin 50 ppm, 50 mg/kg
Lowest published LCLo 2ppm
Lethal dose
Median LD50 11,900 mg/kg
Lowest LDmin 10 mg/kg
A good and fresh approach I see! A clear and convincing view! Unfortunately, in {Chembox} this is to be in the "Hazards" infobox section, so "Lethal dose" can not be at that level. The colored section header is not a sub to Hazards, this way. A 3-leveled {Chembox} is a good topic too, but hard to talk in here. Note, I ask, how good the short wording reads & looks for us and for our Reader. (I add: good to drop the wikilinking for now). -DePiep (talk) 22:12, 2 June 2015 (UTC)[reply]
This is an approach worth discussing - it could be used elsewhere as well. As long as the second-level template is handling it completely (it should not require another 'sub-box' definition in the sub-box). We do have to adapt these sub-headers so they are distinguised from the 'Hazards'-sub-box-level header, otherwise we might get situations like:
Hazards
Lethal dose
Median LD50 11,900 mg/kg
Lowest LDmin 10 mg/kg
Next hazard Deadly
One could consider:
Hazards
Lethal dose
Median LD50 11,900 mg/kg
Lowest LDmin 10 mg/kg
Next hazard Deadly
(i.e. drop the bolding of the sublevel, giving it a somewhat different (lighter?) colour). Still, how to make clear that the three 'belong' together, and that the fourth one is something else. Making the separator lines different (e.g. dotted or dashed between these three), or forcing the fields that need a sub-header to be at the bottom (so that there are no unrelated fields without an own subheader below them)? --Dirk Beetstra T C 11:26, 3 June 2015 (UTC)[reply]
Yes, good to add the concept of "subsection" to {{Chembox}}. Later more. -DePiep (talk) 23:35, 3 June 2015 (UTC)[reply]
...Second thoughts. In general, the infobox could use the option of sub-sections. Already the Names and NIOSH use them in some form. However, so far with the Lethal data we are talking about, it is not right. The examples use subheader as "Lethal dose". That is just a grammatical construction to move words from the label (lefthand text) to a common row. The true grouping that might deserve a subheader, would be named like "Lethality" (or "Lethalness"?). We could explore that route, but immediately we see that this does not reduce the wording per data row enough (we'd still need something readable like a label '(Lowest published [lethal] dose) LDLo': no useful text-length reduction).
Apart from this, building a good subheader option takes some serious time (follow {{Infobox}} habit, apply for Names and NIOSH too, keep mobile view in mind, ...). This surely could yield a result, but after a longer development time. To add those two new parameters LCLo and LDLo more quikly (so that requestor Emily can add the data), I repeat my earlier proposal to use shortened wording for these not the full 3-lines definition wording. But hey, I can't enforce this, but I ask you all to reconsider this as a speedy solution. -DePiep (talk) 13:21, 5 June 2015 (UTC)[reply]
Preparing other changes to {{Chembox}}. This topic's demos (the sandboxes) are temporally disabled (demos won't show intended meaning). Expect days not weeks of disturbance. -DePiep (talk) 23:14, 6 June 2015 (UTC) - REstrored the demo. -DePiep (talk) 09:09, 9 June 2015 (UTC)[reply]

Hi, I'm really sorry I lost track of this discussion. DePiep, I think the shortened wording is okay as a quick solution to get this information in sooner rather than later, and subheadings can come later. Thanks so much for all your work on this. Emily Temple-Wood (NIOSH) (talk) 18:33, 16 June 2015 (UTC)[reply]

i.e. support for shorter wordings by OP. Will imply this shortly. -DePiep (talk) 18:36, 16 June 2015 (UTC)[reply]
Again, about bad target links. At the moment, the target links (lefthand side) are, irrespective of the label text shown:
LD50Median lethal dose (live)
LDLoLowest published lethal dose (R to Minimum lethal dose)
LC50Median lethal dose (live)
LCLoLethal concentration low
My comments:
LD50 -- OK
LDLo -- No definition of LDLo. No notion that LDLo is/is not LDmin.
LC50 -- Not to subsection like "LC50". LC50 is only mentioned sideways, not even a complete paragraph. Looks like LCt50 is more signifying.
LCLo --Sloppy lede. Article title not present in bold.
Over all, why are the definitions not written more parallel? Sure the two Lo's must mean something similar, but that doesn't show in the texts. Same for C and D. I repeat, if the target definitions are this sloppy or absent, we should conclude it's not worth mentioning that data in an infobox at all. (Options: we can consider rewriting and adding paragraphs, merging, use a #-link like [[Median lethal dose#Lethal concentration]] by sectiontitle or by {{anchor}}). -DePiep (talk) 12:42, 18 June 2015 (UTC)[reply]
Yeah, these articles need work. I need to run shortly but I think the solution is to have an article for "lethal dose" and then 4 subsections explaining each one. I'll implement that later tonight when I'm not on a time crunch. Emily Temple-Wood (NIOSH) (talk) 16:11, 18 June 2015 (UTC)[reply]
Sounds like a good plan (esp the no-stress part ;-) ). -DePiep (talk) 16:59, 18 June 2015 (UTC) + peek preview.[reply]
I took the no-stress part very seriously and took forever to even do a simple merge but all 4 articles are now combined into lethal dose. It needs a lot of work just in general, but a lot of that is due to the quality of the articles in the first place. It's an item on my to-do list but it may be a little while until I get to fully redoing the whole thing. However, I think it's good enough for linking from the chembox. Emily Temple-Wood (NIOSH) (talk) 05:35, 19 June 2015 (UTC)[reply]
Great improvement. Yes I'll surely use that in the Lethal subsection. (testcase). As you can see, I'm playingresearching with the subheader-thing. I'm confident this will go forward (but not expected this week). -DePiep (talk) 10:04, 19 June 2015 (UTC)[reply]
Thank you so much! I really appreciate your help! Emily Temple-Wood (NIOSH) (talk) 01:40, 20 June 2015 (UTC)[reply]
checkY Ready for deployment. -DePiep (talk) 09:21, 22 June 2015 (UTC)[reply]
 Done. Parameters available. May I suggest to try to reduce bulk-of-data in this like in DDT? -DePiep (talk) 11:37, 23 June 2015 (UTC)[reply]
I can't thank you enough! Emily Temple-Wood (NIOSH) (talk) 01:11, 24 June 2015 (UTC)[reply]

Chembox structure additions

Useful link: Chembox/testcases11

in Template:Chembox Structure there seems to be parameters to describe the crystal structure. But some commonly published info has no parameters, The extra ones I want to use are the number of formulas per unit cell, commonly termed Z, and the unit cell volume V. Also it would be good to have another field in case the temperature was not 25° or standard pressure. Also some materials can have different forms. So far I have repeated the template, but that is not the best solution. For the purposes of data extraction it would be good to have a reference field separate too. Graeme Bartlett (talk) 07:40, 4 June 2015 (UTC)[reply]

As long as we use this SectionN= structure, repetition is acceptable because it produces the right outcome. (When going to {{Infobox}} later this century, the change process must cover such situations). We can introduce indexes though, like we have with |CASNo2=, if deemed important.
{{Chembox Structure}} has a full example in the documentation. Any interesting example article(s)?
First throw, we can add these params:
|UnitCellFormulas=
|UnitCellVolume=
Better names possible? Does one have a common/standard unit (default)? Any other structure in the data we could use?
Then, we need wikilinks and labeltext for the lefthand sides (two new data rows).
For |UnitCellFormulas=: text="Number of formula". Link = Formula unit
For |UnitCellVolume=: text="Unit volume". Link to Crystal structure#Close packing. (Atomic packing factor is not the same, but it uses this V).
As elsewhere in {{Chembox}}, ref and comment (freetext, unedited) can be added at the end:
|Structure_ref=, |Structure_Comment=
However, do you need these with every parameter? Or just once for the structure section? -DePiep (talk) 07:29, 5 June 2015 (UTC)[reply]
re myself: after second reading, it looks like the whole crystal structure section describes one single structure |CrystalStruct=. Always entered. We can add |CrystalStruct_ref=, |CrystalStruct_Comment= to that top data row then. -DePiep (talk) 07:34, 5 June 2015 (UTC)[reply]
That proposal looks OK. Replicating the sections sounds OK to me.One comment per section would be fine, and usually one reference will have everything. Sometime a reference will miss the number of formulas or unit cell volume or density. Density can be calculated from the volume, molecular weight and formulas, but it is often published too. But density appears elsewhere anyway. Often the theoretical density can be different to the measured, perhaps because of gaps, defects, inclusion of extra substances, such as solvent. My example is indium sulfate. Graeme Bartlett (talk) 23:24, 5 June 2015 (UTC)[reply]
So we can assume that |CrystalStruct= is always present in the ~1600 Chembox Structure pages.
Can you provide links for the two new data: "number of formulas per unit cell, commonly termed Z", and the "unit cell volume V"? That would be the lefthand link it the data row. At least, write a new article or section for them somewhere. If there is no wikilink available, it is questionable why we would mention that data at all.
btw, in indium sulfate I see: "Coordination geometry: 6 formula per cell". Isn't that what you asked for? -DePiep (talk) 13:14, 6 June 2015 (UTC)[reply]
It does not belong in coordination geometry — coordination geometry is how things are arranged in the molecule, or around a central atom. Unit cell volume should point to Lattice constant as it can be derived from the numbers in the box next to that eg a*b*c for an orthorhombic, or a^3 for cubic. I will write a section. Graeme Bartlett (talk) 13:39, 6 June 2015 (UTC)[reply]

Sandbox demo

re Graeme Bartlett some questions:

Parameter names |UnitCellFormulas= |UnitCellVolume= are most connvenient for editors (like you)?
LH link+text for Formulas todo.
There are three lattice constant data rows possible now. I will make them into one cell (mentioning 'Lattice constant' only once). Todo.
You can suggest other improvements. Any data-structure to be used/added (eg, same unit always, link to FCC crystal image like we do in {{Chembox element}} see Aluminium? ).
Please take a checking look at the order of data rows. Can be better?
Postponed for now: reference and comment additions. Will add those later.
-DePiep (talk) 10:51, 9 June 2015 (UTC)[reply]
We could abbreviate this more to |UnitCellZ= for formulas, and |UnitCellV= for unit cell volume. Actually while checking up it seems that writers prefer molecules per cell about 1000× more often. This is despite many crystals not actually containing molecules, but rather an arrangements of ions, or atoms. So instead of |UnitCellFormulas= you could have |UnitCellMolecules=. For Unit Cell Volume I now have a section at Lattice constant#Volume. For α β γ the units are always °. For a b c the units are mostly Å, but some authors like nm (nanometers). Graeme Bartlett (talk) 11:38, 9 June 2015 (UTC)[reply]
re: about supporting the editor, not being perfect. I'd not use Z and V here. For less-familiar editors, that still is a mental step extra to remember or look up. |UnitCellMolecules=: can change. Is that the most known & specific word then? 'Molecules' is used everywhere, so could be less meaningful (less distinctive) here for that same half-familiar editor. -DePiep (talk) 11:51, 9 June 2015 (UTC)[reply]
Do all lattice-changes look OK to you for the variants?
Are the new parameters named OK |UnitCellFormulas= |UnitCellVolume= for your fellow chemistry editors? (Just thinking, not like |LattConst_Formulas= |LattConst_Volume= then.)
Volume and Formulas are free text, shown unformatted. But the 6 constants themselves are structured & formatted in the infobox. So we need extra params like |LattConst_ref= and |LattConst_comment= then to position that info correctly. Where do I put those two? Once for all 6 constants at the end or two options, #1 after a-b-c and #2 after alpha-beta-gamma? -DePiep (talk) 09:20, 16 June 2015 (UTC)[reply]
←→
I like UnitCell in the name more than LattConst, but that is just my opinion.
Free text is fine as for volume then we can have units of our choice, I use Å3 for volume. A LatticeConst_ref would be good, just insert it after the last of a b c or α β γ as the same reference should cover all of this. Graeme Bartlett (talk) 11:39, 16 June 2015 (UTC)[reply]
Done. _ref follows the 6 values directly, _Comment starts with a newline. (Note that _Comment can have its own ref added, being anytext). Pls take a good look, also for punctuation & variants. If you agree, I'll put this live (my secondary notes, below, can follow later). -DePiep (talk) 13:32, 16 June 2015 (UTC)[reply]
  • checkY Processing deployment. New parameters:

| UnitCellFormulas = | UnitCellVolume = | LattConst_ref = | LattConst_Comment =

-DePiep (talk) 09:40, 17 June 2015 (UTC)[reply]

Secondary changes

Apart from the Volume and Formulas additions (see above), some more questions and suggestions arose.

  • Structure: change section title into "Crystal structure"? If all data rows are descriptions of the crystal, we can do this. (Dipole is?).
  • Also, is all data is crystal related, we can present the |CrystStruc= parameter as subheader (bold, over infobox width).
  • Pearson symbol: add extra data row? Could help Indium(III) sulfate. -DePiep (talk) 09:43, 16 June 2015 (UTC)[reply]
Structure could also be describing molecules, in which case shape, symmetry and coordination come into play. I will take a look at more possible values that might be useful. Dipole moment will normally describe one molecule. Graeme Bartlett (talk) 12:34, 17 June 2015 (UTC)[reply]
No urgency, I understand. Just let us know if you see improvements. One from me: we should {{nowrap}} each if the six lattice values. -19:37, 17 June 2015 (UTC)

Hello everyone,

I am new here as editor, but I often read and use Wikipedia articles for my studies.

I have noticed that the link to EC number in Chemical infobox point to ESIS web site which has been closed for more than 6 months.

For instance for Formaldehyde that gives EC number 200-001-8 which link as: http://esis.jrc.ec.europa.eu/lib/einecs_IS_reponse.php?genre=ECNO&entree=200-001-8

Why not to remove such link to any EC number or even better to update as direct link to another chemical information system like chemsub online with link as format http://chemsub.online.fr/ec_number/EC number.html like for formaldehyde: http://chemsub.online.fr/ec_number/200-001-8.html I found only this web site having a direct access to chemical data sheet via EC number.

Thank you.

--Chemistaddict (talk) 13:55, 6 June 2015 (UTC)[reply]

Welcome. This was discussed last weeks here. Proposed demos are here, do they look good? Within a few days, the new version will be put live. -DePiep (talk) 18:14, 6 June 2015 (UTC)[reply]
I must add: that discussion, and you too, conclude that there is no automatable link to a EC number site page. That is why that number is unlinked (in the demo). Can you explain why 'chemsub' would be a trustworthy alternative? Your example for 200-001-8: [9]. -DePiep (talk) 22:45, 6 June 2015 (UTC)[reply]
The changes I pointed to are made. See #Template edits 7 June 2015. -DePiep (talk) 11:39, 8 June 2015 (UTC)[reply]
Thank you DePiep, sorry, I do not know really if I'm respecting rules of editing, I hope so. I do not know if chemsub is a trusted source, but it's so far the only one which provides direct link to any EC number (pointing to the right chemical substance). I'm more than 65 and dealing with EC numbers for ore than 30 years. I have been using ESIS since its start in 2002 if I remember well, it was the reference. But now, we count on you. Thank you.--Chemistaddict (talk) 14:30, 9 June 2015 (UTC)[reply]
First and foremost, you did not trespass anything. Instead you are welcome to mention any idea & concern as you did.
I'm not that familiar with the EC number (who could be?), but the essence is that we want to link to the publishing authority's site. That is called Authority control, and we prefer using template {{Authority control}} (originally about libraries that standardise names like for Princess Diana). These days this template will be expanded with chemical & medicine institutes that decide & publish id's.
And so, since ECHA does not have a site accessible (not even a definition for EC number I found, to link to), we can not link to that authority source. (A good example is the CAS RN, we can link automatically to [10] (for ammonia).
To make things worse, I got the impression that not long ago the setup was changed (eg, EINECS was merged into EC number, a bit). And the earleir websites & links now are dead, as we know.
The site you propose to link to, chemsub.online.fr, is only using that EC number, not defining it. If we use that link, this wikipedia would become a 'link farm' instead of providing information & sources. This is why the EC number is not linked.
Actually, since you are familiar with EC number, you could help the chemical infobox of course. As I said, we are in need of ECNA/EC number sources and maybe even an entrance to their database by EC number. The situation is even worse for "EC Index", of which we don't have any useful definition or link (this way, it will be removed from the infobox {{Chembox}} completely). In other words: what are the EC number people doing, actually? -DePiep (talk) 15:51, 9 June 2015 (UTC)[reply]
To DePiep: Concerning the merged you talked about, actually EINECS and EC number are the same. Official EC number includes EINECS, ELINCS and NLP (for a total of 106 199 chemical substances).
There is no proper definition of EC number, even was not the case in the ex ESIS. Consider just that a EC number is for Europe what is a CAS number for US.
Concerning EC index, it's as you know totally different issue.
And for the EC number people, which whom I had different exchanges and personally with the person who has developed ESIS, they "do not exist" as such, they might work in other activities.
It's all I can say so far concerning this subject. EC number was a good key for accessing chemicals, especially EU chemicals, anyway. --Chemistaddict (talk) 13:00, 22 June 2015 (UTC)[reply]
Yes this is how I understand it.
EC number now shows inputs |EC number= and |EINECS= in {{Chembox}} as being the same. But we can not link to a database page for a substance.
Of EC index we do not have a definition and no source that defines these numbers. So that datarow will be removed from {{Chembox}} completely.
If you see any strange things in this topic in articles, please note. -DePiep (talk) 14:13, 22 June 2015 (UTC)[reply]
The proposal to delete |ECIndex= is #here. -DePiep (talk) 20:36, 22 June 2015 (UTC)[reply]

Following this {{Drugbox}} discussion:

  1. Many IUPHAR ligand values (ID's) have been systematically added by @Boghog, IUPHARcurators, and Snipre:. 974 to Drugbox, 475 to Chembox. Now in total ~2000/16000 articles have this ligand, linked el.
  2. I will add the option to index IUPHAR_ligand parameters, each with a IUPHAR_ligand_Comment option. This is parallel with indexes like CASNo, CASNo1, ... CASNo5 and |CASNoindex_Comment=.
  3. |IUPHAR_ligand_Other= is added (once) by the same set pattern: allows any text after all indexed input (unlinked, unedited by {Chembox}).
  4. Existing |IUPHAR_ligand= keeps functioning & showing unchanged. It has added option |IUPHAR_ligand_Comment= just as well.
  5. See Chembox/testcases2. Full parameter set for the IUPHAR ligand data row:
| IUPHAR_ligand= 
| IUPHAR_ligand_Comment= 
| IUPHAR_ligand1= 
| IUPHAR_ligand1_Comment= 
| IUPHAR_ligand2= 
| IUPHAR_ligand2_Comment= 
| IUPHAR_ligand3= 
| IUPHAR_ligand3_Comment= 
| IUPHAR_ligand4= 
| IUPHAR_ligand4_Comment= 
| IUPHAR_ligand5= 
| IUPHAR_ligand5_Comment= 
| IUPHAR_ligand_Other= 
checkY - preparing. -DePiep (talk) 09:22, 18 June 2015 (UTC)[reply]
 Done -DePiep (talk) 09:53, 18 June 2015 (UTC)[reply]

Add onset and duration of action to pharmacology section

{Drugbox} has |onset= and |duration_of_action=. I think these could be useful in the pharmacology subsection of {Chembox}}. Can these be added? Sizeofint (talk) 20:14, 18 June 2015 (UTC)[reply]

See the testcases (drugbox added to compare). Questions:
What is the right order for the rows?
What & where with those 'routes of admin'?
Are the lefthand texts OK? (read)
Are the lefthand targets OK? (click)
Since this all must make sense, they willl be be made the same in {{Drugbox}}. Exception: metabolism vs drug metabolism. -DePiep (talk) 21:10, 18 June 2015 (UTC)[reply]
Perhaps this order?
| AdminRoutes = 
| Bioavail =
| ProteinBound = 
| Metabolism = 
| Metabolites = 
| OnsetOfAction =
| HalfLife = 
| DurationOfAction=
| Excretion = 
The lefthand texts and targets look mostly fine. I note that "Elimination half life" redirects to "Biological half life". The target should be changed to "Biological half life". I don't have an opinion as to if the text should be changed as well. Sizeofint (talk) 22:18, 18 June 2015 (UTC)[reply]
Fine. Done in testpage. -DePiep (talk) 23:19, 18 June 2015 (UTC)[reply]
Biological half-life to be the lefthand text, after reading the article. Word 'elimination' does not even appear, and 'biological' is clear to me (but that could be because I work on isotopes too...). -DePiep (talk) 07:49, 19 June 2015 (UTC)[reply]
Added a subheader, linking to pharmacokinetics. Same in {{Drugbox}}.
checkY Ready for deployment. See the testcases. -DePiep (talk) 09:20, 22 June 2015 (UTC)[reply]
 Done. Parameters added. -DePiep (talk) 11:35, 23 June 2015 (UTC)[reply]

Upcoming presentation changes

Following data additions requested (pharmacokinetics here and LCLo here), I've prepared some useful/needed presentation changes (layout, order, format, whitespace).

  • Introducing subheader for a set (group) of data rows. This allows to present as a group e.g. the data LD50, LC50, LDLo, LCLo under a single subheader titletext. It uses indenting and a subtle shift of bg color (grey a bit darker).
Applied to pharmacokinetics, lethal amount, NIOSH data (demo/testcases for pharma, hazards).
  • Re-add the border to the yellowish headers. This moves away from the more white-ish (bleaker) {{Infobox}} style, but is needed to have consistency over various situations (no images, separate header from subheader, ...) in {{Chembox}}. See the hazards demo.

I plan to deploy this shortly. Any remarks? -DePiep (talk) 09:18, 22 June 2015 (UTC)[reply]

Looks good! Thanks Depiep! Sizeofint (talk) 15:04, 22 June 2015 (UTC)[reply]
 Done. -DePiep (talk) 11:35, 23 June 2015 (UTC)[reply]

NIOSH and Lethal (LD50) data revisited

1. FYI: As {{Chembox}} is organised today, we easily track which articles use certain data input. That could help us. These lists are:

2. Note: To me it looks like the data entered can be too much or too detailed, for example DDT and I saw a 12-item list somewhere. I can not judge on scientific importance (well, being DDT ...). But for information presentation I suggest that it be summarized in the infobox, and maybe expanded in the text by relevance. We don't need to reproduce the complete source research! Emily Temple-Wood (NIOSH)-DePiep (talk) 21:24, 24 June 2015 (UTC)[reply]

Ooh, it's good to know how many articles are using the data! (My nerdy heart just skipped a beat). I'm not sure the best place for these things is in prose, perhaps in a table in a safety section? I think having lethal data is really important and people are much more likely to come here than to NIOSH or whoever for it. (Sorry if this is incoherent, I just woke up from an accidental nap) Emily Temple-Wood (NIOSH) (talk) 01:08, 25 June 2015 (UTC)[reply]
Yes, these numbers 500+700 are really great! (from <200 total?). I don't want to discourage you editing at all. I do want to point, here in the open, to the 'relevance delution' for this encyclopedia. Of course, this exists for the whole infobox (with 500 parameters=potential data points...). I don't know a delimiter criterium, but somewhere there is a limit on infobox size. -DePiep (talk) 00:51, 26 June 2015 (UTC)[reply]
Definitely, and I think that's a problem facing the project with chembox in general. If safety data starts to become a problem, I'm sure we can find an alternative solution! :) (And hopefully Wikidata will enable units soon so we have another place to put data!) Emily Temple-Wood (NIOSH) (talk) 08:57, 29 June 2015 (UTC)[reply]
The safety data should stay in the infobox :-), but I think we should discuss some of the other parameters (especially all the indentifers and the pregnancy* and legal* (do not eat chemical compounds eat the "diluted" drugs). Christian75 (talk) 11:34, 29 June 2015 (UTC)[reply]
I am not proposing to "remove the safety data". I am questioning the size of the entries and its relevance. -DePiep (talk) 11:39, 29 June 2015 (UTC)[reply]

Minor task force: parameter checking

In case some of you need a relaxing and life-fulfilling activity: please help emptying this maintenance category: Category:Chemical articles with unknown parameter in Chembox. Atthe moment there are ~100 {{Chembox}} articles that have an unknown parameter (by typo, misunderstanding, wrong Section, ...). I invite you to try & fix a few articles.

Tip & help: if you Edit and then Preview, the offending parameter is shown at the top of the page, in red (plus its section like "Chembox Hazards") . All correct parameters are in this list. -DePiep (talk) 23:26, 25 June 2015 (UTC)[reply]

 Done empty now. -DePiep (talk) 14:27, 26 June 2015 (UTC)[reply]

German drug law

I'm not sure if there's a "english speaking countries only" policy for the chembox template, but I thought asking won't hurt:

What about making "legal_GER = Anlage I" (and Anlage II and III) link to Drugs controlled by the German Betäubungsmittelgesetz? Aethyta (talk) 20:29, 1 July 2015 (UTC)[reply]

It's not a policy, but I'll draw the line for English speaking countries indeed. An improvement on this line could be welcome. But not all 200 countries this way. Maybe there is an alternative, say using iw or wd? -DePiep (talk) 21:08, 1 July 2015 (UTC)[reply]
Its English-speaking Point Of View. I propose to remove small countrys like New Zealand. Germany should definitely be included with its population of 80 million. (@Aethyta:, do you still think it should be included?) Christian75 (talk) 17:21, 7 July 2015 (UTC)[reply]
Generally yes, although I randomly derped and meant to post this on the drugbox template as I prefer that one. Aethyta (talk) 17:25, 7 July 2015 (UTC)[reply]
Actually, Christian, it is not WP:EPOV (your link). As that section describes, EPOV denotes a preference for England and its culture as a POV. Maybe even your proposal to exclude NZ is an illustration. But the question is about which countries to include for their law and jurisdiction. This still being an English language WP, choosing English speaking countries is a quite systematic non-POV choice. But as said, there may be a better rule for inclusion/exclusion. Your suggestion to use country size would need working out to be made appicable. RE Aethyta, sure {{Drugbox}} reaches many more drugs articles, but the two templates use the same input-options and data-setup ;-). -DePiep (talk) 22:43, 7 July 2015 (UTC)[reply]
quote first line from WP:EPOV: "Also be careful to avoid an English-speaking Point of View. Although country-specific and similar POVs are often easy to spot, this can be harder to spot." - choosing English-speaking-countries as a criteria is country-specific and POV. The text are using more time describing culture-specific because, as it says, its harder to spot. Christian75 (talk) 22:54, 7 July 2015 (UTC)[reply]
Read more that the first line. It is only about the English-spoken history view etc. OTOH, an English-language wikipedia is not country-specific. Anyway, choosing all English-speaking countries is not country specific. The English language in itself is not a POV. (Leaving out NZ is country specific). It is wiki-specific though. Now, what is your better criteria? -DePiep (talk) 23:26, 7 July 2015 (UTC)[reply]
Would this not be an issue for de.wikipedia? I feel I should point out that they don't use Drugbox in any event. --Project Osprey (talk) 15:25, 8 July 2015 (UTC)[reply]
The enwiki page provided by Aethyta has no iw at all... Maybe we are supposed to serve the German-speaking countries too ;-). But seriously. There can be an argument to describe German law by drug (or, say, the law on cocaine in Afghanistan and Colombia). It's just: there are 200 countries. I am interested to learn by what criteria we could select countries for that list. -DePiep (talk) 18:00, 8 July 2015 (UTC)[reply]
Well, what about countries that have a list of their banned substances on Wikipedia? That would be extremely few. Aethyta (talk) 18:03, 8 July 2015 (UTC)[reply]
(edit conflict) re Project Osprey: Found more. {{Infobox drug}} does iw to de:Wikipedia:Formatvorlage Arzneistoff. Looks like a drugbox to me ("Arzneistoffe", nice). Is this an answer? -18:12, 8 July 2015 (UTC)
Good suggestion by Aethyta. -DePiep (talk) 18:34, 8 July 2015 (UTC)[reply]
The English Wikipedia should have a world-wide perspective. However, right now the infobox covers a few of the 67 sovereign states where English is an official language, and I do not suggest to add all countries in the world. Maybe by size or something less random than what its now. Christian75 (talk) 23:23, 13 July 2015 (UTC)[reply]

Template edits: Deprecation of parameters

I have prepared to step up the deprecation of parameters:

Major changes

Major changes imply required removal/change in code and in articles. Must actively be checked and edited. In practice, the articles are listed in maintenance category Category:Chemical articles with unknown parameter in Chembox. Using AWB or AWB-script, the deprecations can be edited. Always, unknown parameters (=those deprecated) are listed in red when showing a Preview.

  • All temperatures: must have "Pt" suffix, as in "MeltingPtC". For MeltingPt, BoilingPt, FlashPt, AutoignitionPt. See full documentation at CalcTemperatures. (At last we can get rid of parameter name variants).
  • Data removed: EUIndex. See #Remove EUIndex.
  • Data removed: ExactMass (discussed 2012)
  • Data removed: EINECSCASNO
  • Identifiers EC-number, EC numberEC_number and EC_number_Comment.
  • Properties: MassRoundMolarMassRound (into regular name pattern)
  • Names: PIN_hidden, IUPACName_hidden (unused)
  • Identifiers: CASNosCASNoOther; all eight: CASNos, ChEMBLs, ChemSpiderIDs, ChEbIs, InChIs, PubChems, SMILESs, UNIIs
  • Pharma: legal_Legal_ uc
  • Pharma: pregnancy_Pregnancy_ uc
Minor changes

These won't change showing, just changing parameter name to a preferred name. In general, no edit required; do when major edits are performed. May have been removed in earlier edits.

  • Hazards: NFPA-ONFPA-S (NFPA-704 -Special, not -Other)
  • Hazards: NSFA_RefNSFA_ref
  • Hazards: ExternalMSDSExternalSDS
  • Explosive: ExplosiveVDetonationV
  • Related: OtherFunctn, Function, OtherCpdsOtherFunction, OtherFunction_label, OtherCompounds (no shortcut spellings)
  • Some exhausted maintenance-trackings will be removed.
-DePiep (talk) 14:25, 7 July 2015 (UTC)[reply]
checkY Processing. -DePiep (talk) 14:25, 7 July 2015 (UTC)[reply]
 Done. Tracking category empty now. -DePiep (talk) 21:36, 7 July 2015 (UTC)[reply]
You say no shortcut spelling, but OtherFunctn is a abbreviation for other functional group. And when its changed, it would be better to name it Related* which is the text in the infobox. Btw. Autoignition has earlier been changed to AutoignitionV, which is very strange when the name is either autoignition temperature or kindling point. It should be changed back to Autoignition. Christian75 (talk) 17:16, 7 July 2015 (UTC)[reply]

Metling_notes to MeltingPt_notes

Several of the Infoboxes are wrong because there is written a comment in "Metling_notes" which should now be "MeltingPt_notes". For example on BaCO3 there was Melting point = 811°C, but the note was "polymorphic transition". Or for SrCO3 the note was "decomposes". So often the comment is mandatory to understand the value. It is the same for BoilingPt_notes and Boiling_notes. --134.94.163.208 (talk) 13:45, 14 July 2015 (UTC)[reply]

You are right. This went wrong somehow: Articles using deprecated parameters like |Melting_notes= and |Boiling_notes= (even having them without value) should be listed in Category:Chemical articles with unknown parameter in Chembox and should give a red message when shown in Preview. This did not happen for Barium carbonate. I'll have to research this automated parameter checking. -DePiep (talk) 20:12, 14 July 2015 (UTC)[reply]
Parameter check does not function as expected in subtemplates (like {{Chembox Properties}}). I restored as accepted parameters |Melting_notes= and |Boiling_notes= (they will show). Those pages are listed in the category for edit. MAybe later the parameter check can function as expected. -DePiep (talk) 22:11, 14 July 2015 (UTC)[reply]

InChI: show just one, and how to show that?

Over at this Drugbox talk, Beetstra raises this point: we should only mention one InChI (preferably the Std of course). A secondary issue is how to show that InChI, if at all, and how to handle external searches. Of course this is major to {{Chembox}}. For now, please discuss there not here. -DePiep (talk) 21:04, 16 July 2015 (UTC)[reply]

Duplicated SMILES

SMILES block is duplicated (after IUPHAR_ligand block and after RTECS), in {{Chembox Identifiers}}. --Jmarchn (talk) 16:27, 4 August 2015 (UTC)[reply]

Not exactly. |SMILES= is used twice: for Jmol-3D and for SMILES. But not repeated in the infobox. For example, see ammonia. -DePiep (talk) 22:46, 4 August 2015 (UTC)[reply]

Poor current citation precedent: I will state again, strongly...

what I did in an earlier, now archived discussion:

The linking of the infobox as a whole to a list of citations is poor scholarly writing, and entirely un-encyclopedic. The fact that this list is poorly formatted, and a largely URL-only list—the Infobox references—further emphasizes this conclusion, but the key issue is with the lack of clear correspondence between facts and sources.

There will be—as long this manner of citation remains in place—no way for a reader or editor to easily verify content, or to follow up WP reading with deeper research into the sources of WP content.

The current manner in citing most infobox source material needs to fundamentally change, to a system where each and every infobox entry (field, datum, fact) is directly tied to its single source (in the case of a number), or small set of sources (in the case of more general facts). Alternatively, each infobox field could be listed at the page the reader is taken to by the Infobox references link, and alongside each field listed could be the single source form which the field is filled. If more than one sources are used to fill the field, the statement, "No single source; see article citations." would appear, and a citation at the article would then fully establish the fact's source.

If a reader cannot go straight from a datum/field to a source, we revert to "just trust us" writing, which—however much a current consensus may be raised against this truth—is contrary to WP:VERIFY and WP:ORIGINAL RESEARCH. (If we send interested experts off, repeatedly, on mare's nest / rabbit trail searches that, for practical reasons cannot, in any reasonable length of an editor's time, yield the verified information, then the cited fact is reasonably termed unverifiable, must be seen as the original knowledge/work of an editor, and therefore is a policy violation.)

Le Prof Leprof 7272 (talk) 20:46, 11 August 2015 (UTC)[reply]

First of all, stop shouting and lecturing. Second, be more specific. There are a large number of available links in this infobox, many of which are self documenting. Adding sources to support each and every link is redundant and not practical. Wikipedia policy is to use common sense. Boghog (talk) 21:08, 11 August 2015 (UTC)[reply]
I now realize what you may be referring to is Wikipedia:Chemical_infobox#References. I repeat, you need to be such more specific and concise in your statements. The post at the start of this thread is as clear as mud. I also note that the reference section in question is in project and not article namespace and hence the policies that you quote do not necessarily apply. But I agree that the sources should be brought in-line. Boghog (talk) 21:20, 11 August 2015 (UTC)[reply]
Thank you for having the patience to come to understanding, and for stating your agreement that the "the sources should be brought in-line". Otherwise, I deny defenders of the status quo the "bye" that WP policies do not apply in project namespace—WP:V and WP:OR apply to article content, whether the violation occurs via a simple edit or through use of a project-generated template to install unverifiable text—but, but, will (absolutely) not argue this point further with you. Le Prof Leprof 7272 (talk) 04:34, 12 August 2015 (UTC)[reply]
Based on the link that you failed to provide but Dirk provided below it is now clear that you are not talking about the Wikipedia:Chemical_infobox#References, but about physical constants of chemicals listed in chemboxes. Insisting that each and every value is sourced is not realistic. This data is normally obtained from tertiary sources as ChemSpider that are also linked in the infobox. I would strongly oppose mass deletion or tagging of such data. If this really bothers you, add the citations yourself. Boghog (talk) 11:42, 12 August 2015 (UTC)[reply]
@Leprof 7272: A reiteration of last time, differently worded: WP:VERIFY requires that data that is likely to be challenged to have references - we do not need to have a reference on everything. Most of the data in infoboxes is of a level that it can be found in tertiary sources - 'grass is green', 'the sky is blue', 'the melting point of water is 0°C' is information that is unlikely to be challenged, it does not need to be sourced, or it can be 'blanket sourced' (and the latter is what the infobox does). Not every number in the infobox needs that specific a source. That is not in violation of WP:VERIFY, and it has nothing to do with WP:ORIGINAL RESEARCH (which may be a problem with data on compounds for which there is only one primary source - the people who made the compound and measured a property). Moreover, we require that information is verifiable, not that you, on the spot, are capable to see the original source (which may be behind paywalls, which may be in an obscure book in a Tibetan library, or where ever - that does not make a fact untrue). Only if you can reasonably challenge the data (which would require that you come with a proper source showing that you are right in that the data is wrong) and it is not available from the blanket sources that we have, then you make a case for that the data is wrong (but since you have a proper source then, you have all reason to change the number and provide the source - that there was another number shows that the number may be challenged).
Hence, there is for a lot of that information no need to have that fundamentally changed. Some data are not that general, and for those it would be good to have them properly sourced, especially if for a specific data you can show that that data is not available from the blanket sources.
I can agree that the data in the chemical infoboxes that are not reasonably found in the CRC handbook, online chemical databases (many are linked through the identifiers) , the common catalogues, or other tertiary source should have an inline reference, which can be easily added (some field have a specialised 'ref' field, or anyway a possibility to include the <ref>-marks at the end of the data).
LeProf 7272 - this is a wiki, if you think that certain data needs a specific source over the 'blanket sources', you can add it yourself. There is no-one here who discourages that addition, nor has anyone ever discouraged that addition, nor has anyone ever removed said references for data that was there. If that happens/happened, without proper reason, I will revert those edits and possibly block that editor (I have done that, especially if the editor is no). I will also revert editors who, without proper reason, change data. I will also revert editors who, without proper reason, remove data that is unsourced. And if someone finds a reference stating that certain unreferenced data that we have in a field is wrong, I expect them to change the data and supply the proper source. And I expect that if someone adds data that cannot be easily found in our blanket sources to add a reference where they found that number. I strongly encourage you to do the same, and I will also not stop you, or anyone, if you add that information on other numbers that you verified (even if there is no requirement on having the reference if it is not likely to be challenged, there is also nothing wrong with having it on there either) - this is a collaborative project. --Dirk Beetstra T C 05:42, 12 August 2015 (UTC)[reply]
(due to (edit conflict)) - I deny your claim that the data is unverifiable if it does not have a reference - data with a reference is verifiable, data without reference is not necessarily unverifiable, and that is a misinterpretation of WP:V. --Dirk Beetstra T C 05:42, 12 August 2015 (UTC)[reply]
Up until this point in the talk flow, this is a reopening of a similar post by Leprof 7272 as was linked to. Being an editor who edits {{Chembox}}, I follow this closely. Given the earlier (linked) discussion, right now and here, IMO no new points were added. Even better, the responses here are more than adequate, wrt WP:V, WP:OR, WP:RS. I will not add. Below, I open an "arbitrary" new subsection to allow for an interesting follow-up discussion. -DePiep (talk) 21:15, 13 August 2015 (UTC)[reply]


Abitrary break #1

You should have a look at Wikidata. Wikidata has sources for each statements, which should allow to generate proper linking to the source of informations if taken on Wikidata for the Infobox fields. TomT0m (talk) 10:34, 12 August 2015 (UTC)[reply]

And we could source that at some point .. --Dirk Beetstra T C 11:06, 12 August 2015 (UTC)[reply]
Yep, this should be the way to do now ... everything is in place to be able to render references as Wikidata items with arbitrary items. For those who contribute on severals linguistic versions, note that you'll have to source only once in Wikidata and that the source will automitically added in all the projects, when the infoboxes will all be adapted. TomT0m (talk) 12:52, 12 August 2015 (UTC)[reply]
Wikidata does not have a reference for every statement (but a possibility do add it - like the chembox's). And a of the "references" (on Wikidata) are like "imported from: English wikipiedia". Christian75 (talk) 13:18, 12 August 2015 (UTC)[reply]
@Christian75: This is the current situation ... but it's best to focus on a project than splitting the efforts. Wikidata is best suitable for automated work when possible (data import from other databases for example, this become sourced by the database) so this can change very quickly, and it's a place for interlanguage cooperation, as it's language agnostic and that the information can be used by any Wikipedia. In short, when adding a new reference now you this will show up in this Wikipedia, and in others. When someone of another language will add a reference, this will show up as well. The imported from <Wikipedia> statements are used to trace to the original wikipedia reference if there is one to copy it directly in Wikidata. So everybody wins by focusing on Wikidata. TomT0m (talk) 14:45, 12 August 2015 (UTC)[reply]
  • I would like to provide you with some kind of outside view: In de.wikipedia, the parameters that need an inline reference are defined (tick mark or ref in the last column). All articles transcluding the chembox do actually have inline references for all defined parameters. There was quite some work to have this completed some time ago. --Leyo 20:39, 12 August 2015 (UTC)[reply]
  • @Beetstra. Just a comment about the fact that everyone can add proper reference to each data of the infobox. We had similar discussion in the past in WP:fr and from that experience don't expect that contributor will do more than what is done usually. People work by mimicry and if the trend is to refer to a general list of references people will do the same.
The main question is to know which is the choice of the project: do you want to increase the data quality by offering for each value the source or do you want to stay with the current system ? What is the objective for the future data ?
From personal point of view your system isn't the best one because you separate value and source and this is contradictory behaviour for a reference work using quite a lot of different sources. Snipre (talk) 07:51, 13 August 2015 (UTC)[reply]
@Snipre: - I don't expect them to (realistically). I know that even with tagging there is no follow-up on it (and that goes in general). I agree that an academic standard requires that one actually states upon writing a statement where that statement is from, but that is not how Wikipedia works (actually, that is more about attribution than verifiability). Most editors however will not include a reference when adding a 'fact' (even when they copy it from another source!). I know that a set of general references for the 'facts' in the chemboxes/drugboxes is not the best, but it is better than what most editors supply (no references at all, and that is not because the chembox has general references, they don't do it in prose either). And as I said, verifiability is about the possibility to verify facts that are likely to be challenged, and about the ability to check a fact, not that one has to be able to read a fact and go to the source and double check it on the spot immediately etc.
I do think that good editing is 'hmm, I don't know whether <fact> is true, it does not have a reference, let me see what I can find' (in line with WP:AGF), and not 'hmm, I don't know whether <fact> is true, it does not have a reference, so I better delete this' (this is not a BLP, and even there the latter action is controversial - it took a lot of debate to get to that and still the former action should be preferred). The latter amounts to vandalism when it is applied consistently while the facts are generally true, and (albeit with (maybe significant) effort) verifiable. --Dirk Beetstra T C 03:50, 16 August 2015 (UTC)[reply]