Module talk:Infobox gene
Targeted by drug
Hi @Julialturner: While I am highly sympathetic to allowing links to "targeted by drug" (this is what I do in real life), I think the display of this section of the infbox should be suppressed unless there are relevant entries in Wikidata. It appears that this is what you had in mind since you added the comment "check if any drugs have references if not then don't render the headers" to the template code, but for some reason, the drug header is displayed whether or not there any drugs targeting this protein. I would appreciate if you would check this when you get a chance. Cheers. Boghog (talk) 19:39, 15 July 2016 (UTC)
@Boghog: Thank you. I just noticed this wasn't being suppressed yesterday on some pages and I am working on a solution. Best, Julialturner (talk) 21:20, 15 July 2016 (UTC)
- Julia, thanks for fixing the suppression of the section. Much appreciated. Boghog (talk) 14:33, 2 August 2016 (UTC)
Wikidata citations
Hi @Julialturner:. Another request. I noticed that infobox gene is now staring to display citation data (see for example CNGA1). Unfortunately bare URLs are displayed which is far from ideal. They are not very readable and lead to link rot. They are also ugly. Furthermore I can't locate the citation in Wikidata to see if it is even possible to add a formatted citation. Do you know if formatted citations are supported in Wikidata? If not, I humbly suggest that it may be premature to display this type of data. Cheers. Boghog (talk) 14:47, 2 August 2016 (UTC)
- Some kind of formatted citations you can see here. If that's not what you're thinking about, then you can simply ignore me :) --Edgars2007 (talk/contribs) 16:18, 2 August 2016 (UTC)
- @Julialturner, Boghog, and Daniel Mietchen: Wikidata won't hold formatted references as a string if that is what you are thinking. There is ongoing work to hold all the components of a reference (authors, journal, title, etc.) as structured data there such that a script could automatically compose a formatted string for references. So.. what to do now? The URLs you are referring to appear as references within the corresponding wikidata item. For your example, you can see them at https://www.wikidata.org/wiki/Q17907825 under the corresponding property - e.g. genetic association. In many cases, it seems the link to the database where the information was collected from is the appropriate reference. When the appropriate reference is indeed an online resource - which admittedly is subject to linkrot - what is an appropriate referencing pattern? --Benjamin Good (talk) 21:59, 2 August 2016 (UTC)
- @I9606: Thanks for the response. Actually some of the data database links look OK (e.g., human and mouse PubMed references). At a minimum, the database references should display like these PubMed references where the displayed link is replaced by readable text. The OMIM reference ideally should look like what {{OMIM}} produces. Also In the CNGA1 example, targeted by drug, Dequalinium cites https://www.ncbi.nlm.nih.gov/pubmed/12508052. This reference as well as the references for Genetically Related Diseases (Retinitis pigmentosa) are not contained in https://www.wikidata.org/wiki/Q17907825. Boghog (talk) 06:11, 3 August 2016 (UTC)
- @Boghog: Thanks, clearly we need to work on the presentation of the references. I really hope we can get some help from the people focused on citation like @Daniel Mietchen:. To clarify where things are coming from, the drug interaction and its reference are located on the wikidata item associated with the protein product for that gene https://www.wikidata.org/wiki/Q21105636 under the 'physically interacts with' property. The Lua script that builds the template pulls such interactions by traversing from the gene item to the protein item in the same way that it gets the Gene Ontology annotations. The references for Genetically Related Diseases (Retinitis pigmentosa) are indeed coming directly from https://www.wikidata.org/wiki/Q17907825 . Look for the 'genetic association' property on that item. --Benjamin Good (talk) 18:32, 3 August 2016 (UTC)
- @I9606: OK, thanks. I now see the reference links for Dequalinium and Retinitis pigments (in Wikidata pages, the Safari search tool doesn't seem to search beyond what is visible in the currently displayed browser window). I hope someone is able to come up with a better long term solution to the display of the citations. A partial solution for the PubMed citation would be to parse the bare url https://www.ncbi.nlm.nih.gov/pubmed/12508052 for the pmid and replace the displayed url with "PMID 12508052" that renders as "PMID 12508052". Boghog (talk) 19:49, 3 August 2016 (UTC)
- Hi, @Boghog: I have been adjusting the citation format for genetically related diseases. I created an example here that I think would be a better solution (https://en.wikipedia.org/wiki/User:Julialturner/RELN). What are your thoughts? Julialturner (talk) 04:42, 27 September 2016 (UTC)
- @I9606: OK, thanks. I now see the reference links for Dequalinium and Retinitis pigments (in Wikidata pages, the Safari search tool doesn't seem to search beyond what is visible in the currently displayed browser window). I hope someone is able to come up with a better long term solution to the display of the citations. A partial solution for the PubMed citation would be to parse the bare url https://www.ncbi.nlm.nih.gov/pubmed/12508052 for the pmid and replace the displayed url with "PMID 12508052" that renders as "PMID 12508052". Boghog (talk) 19:49, 3 August 2016 (UTC)
- @Boghog: Thanks, clearly we need to work on the presentation of the references. I really hope we can get some help from the people focused on citation like @Daniel Mietchen:. To clarify where things are coming from, the drug interaction and its reference are located on the wikidata item associated with the protein product for that gene https://www.wikidata.org/wiki/Q21105636 under the 'physically interacts with' property. The Lua script that builds the template pulls such interactions by traversing from the gene item to the protein item in the same way that it gets the Gene Ontology annotations. The references for Genetically Related Diseases (Retinitis pigmentosa) are indeed coming directly from https://www.wikidata.org/wiki/Q17907825 . Look for the 'genetic association' property on that item. --Benjamin Good (talk) 18:32, 3 August 2016 (UTC)
- @I9606: Thanks for the response. Actually some of the data database links look OK (e.g., human and mouse PubMed references). At a minimum, the database references should display like these PubMed references where the displayed link is replaced by readable text. The OMIM reference ideally should look like what {{OMIM}} produces. Also In the CNGA1 example, targeted by drug, Dequalinium cites https://www.ncbi.nlm.nih.gov/pubmed/12508052. This reference as well as the references for Genetically Related Diseases (Retinitis pigmentosa) are not contained in https://www.wikidata.org/wiki/Q17907825. Boghog (talk) 06:11, 3 August 2016 (UTC)
- @Julialturner, Boghog, and Daniel Mietchen: Wikidata won't hold formatted references as a string if that is what you are thinking. There is ongoing work to hold all the components of a reference (authors, journal, title, etc.) as structured data there such that a script could automatically compose a formatted string for references. So.. what to do now? The URLs you are referring to appear as references within the corresponding wikidata item. For your example, you can see them at https://www.wikidata.org/wiki/Q17907825 under the corresponding property - e.g. genetic association. In many cases, it seems the link to the database where the information was collected from is the appropriate reference. When the appropriate reference is indeed an online resource - which admittedly is subject to linkrot - what is an appropriate referencing pattern? --Benjamin Good (talk) 21:59, 2 August 2016 (UTC)
- Would someone please point me to the RfC that allowed integration of Wikidata into this template for distribution throughout Wikipedia's gene articles? Thanks. Jytdog (talk) 21:45, 27 February 2017 (UTC)
PDB links
Hi @Julialturner: The old {{GNF Protein box}} produced PDB links (PDB Ortholog search: PDBe RCSB) based on {{Homologene2uniprot}} so that crystal structures for both human and orthologs in other species were returned. The new {{Infobox gene}} returns crystal structures only for mouse. At a bare minimum, the link should be changed to human from mouse since there are far more human crystal structures (currently 35929 human vs. 5474 mouse). Ideally of course, the crystal structures for all the orthlogs should be returned. Thanks. Boghog (talk) 12:54, 9 August 2016 (UTC)
- Thanks, @Boghog: I will look into the differences between old and new and see if I can make adjustments to the new infobox. Julialturner (talk) 19:41, 9 August 2016 (UTC)
- @Boghog: the PDB link and RCSB should now have both the human and mouse structures returned. Currently, we are only displaying mouse data, but maybe future development could include other species. Julialturner (talk) 21:33, 9 August 2016 (UTC)
Invalid HTML
@Julialturner: It seems this infobox, outputs same incorrect HTML. The parser mostly cleans this up, but it fails sometimes and then the infobox breaks in VisualEditor for instance as it does for BCL2-related_protein_A1. If you go to this page, you can see that the td, and tr elements are sometimes not closed, or closed too often, causing the parser having to go into a bit of a guessing game. —TheDJ (talk • contribs) 14:21, 16 December 2016 (UTC)
- @TheDJ: Thank you for notifying me of this issue I will look into correcting the code. Julialturner
- Hi, @TheDJ: I did some code cleanup and now all the tag elements should be closed. Julialturner (talk) 06:55, 6 January 2017 (UTC)
- I ran into this via some testing as well. The problem is on line 1603 in the module. It emits a table directly inside a tr tag. You are missing a required td tag to wrap the table - only td, th, and captiont can include content in a table. That is at least one thing that I ran into that needs fixing. SSastry (WMF) (talk) 18:17, 21 March 2017 (UTC)
- @Julialturner: In case you didn't see my earlier message. Pardon me if you have seen that and just haven't gotten around to looking into it yet. Thanks. SSastry (WMF) (talk) 16:19, 13 April 2017 (UTC)
- @SSastry (WMF): Thank you for reminding me. I haven't had a chance to fix this yet, but I will try to fix it in the next week or so.76.167.64.98 (talk) 20:09, 13 April 2017 (UTC)
- @Julialturner: In case you didn't see my earlier message. Pardon me if you have seen that and just haven't gotten around to looking into it yet. Thanks. SSastry (WMF) (talk) 16:19, 13 April 2017 (UTC)
renderCaption
@Julialturner: The not yet implemented renderCaption function will indeed have a problem trying to get information dynamically from comments in Commons. Wikidata provides a property media legend (P2096) that is monolingual text designed to carry the image caption and it would be better to add that property manually (or perhaps by a bot fetching comments from Commons?) to each gene entry, as it would then make the image legend available programmatically to all. There's an example of using the property to fetch the image caption in {{Infobox telescope}}, which relies on the getImageLegend call in Module:Wikidata (currently lines 890–963). It implements arbitrary access, preferred ranks (to cope with multiple images) and uses the local wiki language unless an language iso-code is given in the call:
{{#invoke:Wikidata |getImageLegend |FETCH_WIKIDATA |id=Q1513315}}
→ The South Pole Telescope in November 2009{{#invoke:Wikidata |getImageLegend |FETCH_WIKIDATA |lang=lt |id=Q1513315}}
→ Pietų ašigalio teleskopas 2009 m. lapkritį
It should be easy for you to adapt the Wikidata module code to fill in renderCaption so that it gets a media legend (P2096), leaving editors with the job of updating the relevant Wikidata entries in their own time. Hope that helps. --RexxS (talk) 23:10, 28 February 2017 (UTC)
- @RexxS: I appreciate your suggestion very much. I will definitely try to adapt the wikidata module code here and see if I can get the captions into the infobox. Julialturner (talk) 05:20, 1 March 2017 (UTC)
Biomedical content - disease associations and interactions
Please see Wikipedia_talk:WikiProject_Medicine#More_Wikidata_funk_-_infobox_gene Jytdog (talk) 01:28, 5 April 2017 (UTC)
- Not seeing the funk discussion there now, assuming its been resolved. --Benjamin Good (talk) 16:54, 26 April 2017 (UTC)
- Nope it was not. A means of addressing the problem is being discussed below. Jytdog (talk) 17:45, 26 April 2017 (UTC)
Seriously, how do we suppress indiividual fields
So at KCNB1 the infobox had several pieces of content that was WP:Biomedical information that was not sourced per MEDRS, and I couldn't remove it, so I went into Wikidata and removed it there. Some of it has now been restored in Wikidata. I have no desire to get into arguments at Wikidata about content that is appearing in Wikipedia.
So how do we suppress individual fields at a local article? One of the bad fields was "genetic association". The other bad field is more complex as I mentioned above...
I don't want to go nuclear and call for this infobox to be nuked but if we cannot selectively control what comes in, that will be the only option. Jytdog (talk) 06:29, 16 April 2017 (UTC)
- Adding the ability to suppress individual fields based on passing in a parameter like 'nodisease' etc. seems doable. A more general solution would be to consistently identify which kinds of sources were acceptable for the MEDRS folks, tag them as such within Wikidata, and then add code that would act accordingly without the requirement to touch individual infoboxes. We will have a look at both options. By the way, its grossly inappropriate to threaten 'nuclear options' in your discussions here. Please keep your tone under control and we will work together to continue to improve Wikipedia together. --Benjamin Good (talk) 16:54, 26 April 2017 (UTC)
- Thanks for replying! It would not be appropriate to try to enforce en-WP standards in Wikidata, and if someone did, there is no policy basis there to object if someone should revert. I also have no desire to try; I have no desire to edit Wikidata on any kind of regular basis. If folks want to bring in Wikidata for some things in en-WP via infoboxes that is fine of course, but there must be a way to exclude unreliable data from appearing in en-WP, from within en-WP, that is reasonably easy to implement at the template level or on a per article basis. There is nothing inappropriate (much less "grossly") about proposing to delete a template, which is what I will indeed do, if there is no way to control things at field level. I can wait a while but I hope that field-level control will be introduced soon. Thanks again for replying! Jytdog (talk) 17:42, 26 April 2017 (UTC)
- I looked into it and it is indeed fairly straightforward to adjust this template to take in a parameter like |showdisease=false and hide a section. But looking at what you are attempting to conceal, I'm not really convinced its a good idea. Looking at ATG16L1 for example, there is a line in the infobox saying that there is a genetic association between the gene and Crohn's disease. That relationship is supported by a link to the database entry where this information was gathered that in turn links to several journal articles and entries in other databases that support the claim. I think this is useful information to people interested in this gene. I don't see how it is medically dangerous. I'm concerned that adding a 'hide' function to this module will result in good information like that being hidden from view. I'd like to hear more from the biology community e.g. @Boghog: before making a change. --Benjamin Good (talk) 05:22, 2 May 2017 (UTC)
- Thanks for replying! It would not be appropriate to try to enforce en-WP standards in Wikidata, and if someone did, there is no policy basis there to object if someone should revert. I also have no desire to try; I have no desire to edit Wikidata on any kind of regular basis. If folks want to bring in Wikidata for some things in en-WP via infoboxes that is fine of course, but there must be a way to exclude unreliable data from appearing in en-WP, from within en-WP, that is reasonably easy to implement at the template level or on a per article basis. There is nothing inappropriate (much less "grossly") about proposing to delete a template, which is what I will indeed do, if there is no way to control things at field level. I can wait a while but I hope that field-level control will be introduced soon. Thanks again for replying! Jytdog (talk) 17:42, 26 April 2017 (UTC)