Last modified: 2012-07-26 15:20:47 UTC
I would like to request the addition of the two extensions in the directory Chemical (spec.
ChemFunctions.php, SpecialChemicalsources.php and the additional language file ChemFunctions.i18n.php)
to the wikipedia server (the files reside in
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Chemistry/). Could these extensions be
applied in the test wikipedia, and later (if they behave correcly) on the wikipedia? The programme has
been reviewed by Jimmy Collins, and he helped me to remove some errors in my programming.
Why do we want this patch: Within the Wikiproject:Chemicals (and the higher Wikiproject:Chemistry) one
of the issues has for long been the addition of external links to the pages about specific chemical
substances. The extension SpecialChemicalsources adds a special page which loads a special-page like
the special:booksources, but then for chemical identifiers. The extension in ChemFunctions adds the
functionality of a tag for the chemical formulae (which are now a hassle to put into a document), and
additionally links this to the special:Chemicalsources. The addition of the Specialpage should enable
us to remove many (biased) external links, especially those to commercial suppliers.
Installation: copy the three files to the extensions folder, and add lines to localsettings.php:
require_once( "$IP/extensions/ChemFunctions.php" );
require_once( "$IP/extensions/SpecialChemicalsources.php" );
(removing these two lines should disable the functionality again).
Is there any user's guide for that extension?
Or a demo installation?
A user's guide has been written on meta.wikipedia.org (http://meta.wikimedia.org/wiki/Chemistry), but
that is still quite rudimentary. I do not have a demo-installation, can't open my computer for outside
access. Still looking for a publically accessable wiki to test things on (I have a question posted in
the en.wikipedia.org on the chemicals portal
(http://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Chemicals) to see if there is somewhere a wiki
(In reply to comment #0)
Hi. I did not review the complete code. I just fixed some PHP errors.
Demo of the extensions is running on http://chemistry.poolspares.com (thanks Nickj)
I would say it is very important that the template supports InChI too. I looked
up the caffeine example on poolspares.com, but could not find the InChI for
caffeine. Is there such support, or otherwise, would you be open to having such
I worked on some semantic markup for SMILES, CAS number etc . Are you open
for a patch for support for that? It basically works like this: <span
class="chem:inchi">InChI=1/...</span> and <span
class="chem:smiles">CCCOC</span>. It is available as microformat and RDFa.
I wrote a Greasemonkey script  which uses it, and I set up Chemical blogspace
 that picks up the semantics too; The last focuses on blogs, but shows the
automatically make links to PubChem, eMolecules and Google , similarly to the
I also think that this is an excellent proposed new feature.
I completely agree on the relevance of external searches *and* interal explicit
(more or less unique) molecule identifiers like InChI. Why?
First, help to avoid the 'deep web' problem, so we need explicite 'unique'
molecule identifiers on pages and links to external search pages.
Second, how to find a molecule I can draw, but I do not know the name? E.g.
In other words, we need substructure searches, not just cross-links for ID-numbers
I agree with the inclusion of SMILES code and and InChI for Wikipedia,
especially since two recent papers have shown that the SMILES code can be used
as a similarity indices showing comparable (or better) power than the widely
used Tanimoto indices (Hirst etal 2007) and SMILES codes have been used to
directly develop interpretable rules for chemical structure activity
relationships (Karwath and DeRaedt 2006)
What is the status of this request?
(In reply to comment #10)
> What is the status of this request?
I imagine code review is needed.
Bug has been dead for the past 3 years. Extension has not been reviewed
for deployment on Wikimedia sites and there is no apparent consensus for this
extension to be enabled on enwiki. RESOLVED INVALID.
(In reply to comment #12)
> Bug has been dead for the past 3 years. Extension has not been reviewed
> for deployment on Wikimedia sites and there is no apparent consensus for this
> extension to be enabled on enwiki. RESOLVED INVALID.
Of those 3 reasons, only the last one is a reason to resolve a bug INVALID.
So WONTFIX instead then?
INVALID is fine I guess, I'm not trying to bikeshed.
My main point was that we don't close bugs just for being 3 years old, and we don't close bugs just because the requisite review hasn't happened yet.