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)[reply]

@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)[reply]

Julia, thanks for fixing the suppression of the section. Much appreciated. Boghog (talk) 14:33, 2 August 2016 (UTC)[reply]

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)[reply]

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)[reply]

@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)[reply]

@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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

Not seeing the funk discussion there now, assuming its been resolved. --Benjamin Good (talk) 16:54, 26 April 2017 (UTC)[reply]

Nope it was not. A means of addressing the problem is being discussed below. Jytdog (talk) 17:45, 26 April 2017 (UTC)[reply]

Seriously, how do we suppress individual 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)[reply]

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)[reply]

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)[reply]

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)[reply]

@I9606: Unfortunately in the example you give, the association between ATG16L1 and Crohn's disease is supported in the Gemma database by three primary studies and one secondary (a meta-analysis). It is not acceptable per WP:MEDRS to have a situation where biomedical claims are made though an indiscriminate process that does not guarantee that secondary sources are used. You will note that the article ATG16L1 does not present an association as fact, although the Crohn's disease article discusses associations in greater detail. A bald assertion that gene X is genetically related to disease Y, without any assurance that the conclusion is based on anything more than a primary study, breaches MEDRS and is completely unsuitable for inclusion in an infobox where information must be clear-cut and not subject to caveats. --RexxS (talk) 12:12, 2 May 2017 (UTC)[reply]

User:RexxS do you think we should just exclude the disease field from this template? Checking its output article by article is unreasonable, probably. Jytdog (talk) 13:22, 2 May 2017 (UTC)[reply]

The Gemma database does have a "Quality code" that might help us restrict the associations to only those supported by high quality sources. Unfortunately they don't seem to discriminate between primary studies and meta-analyses which all received one star. The OMIM tertiary source received three stars and I am not sure how critical OMIM is. Boghog (talk) 13:48, 2 May 2017 (UTC)[reply]

@Jytdog: I'd prefer to develop methods of marking the Wikidata with a field indicating quality of evidence, so we could filter the data returned, but we're a long way from that at present. I'd agree that in the meantime, we ought to seriously consider leaving out of infoboxes any claims that don't meet our own policies of V, RS and MEDRS. It's just making a rod for own backs when we're trying to import reliable data. @Boghog: You only have to look at the 7 sources that OMIM cites: 1 mouse study, 2 comparative studies, 3 research studies and 1 meta-analysis. The meta-analysis concluded "the ATG16L1 T300A polymorphism was associated with CD risk in Caucasians ... no significant association was found in Asians." How are you going to fit that can of worms into an infobox? --RexxS (talk) 16:22, 2 May 2017 (UTC)[reply]

I wasn't suggesting that we cite OMIM, just suppress associations with low quality as a potential way of increasingly the reliability. But it looks like Gemma database quality ratings are too crude for that purpose. Boghog (talk) 16:35, 2 May 2017 (UTC)[reply]

User:RexxS For what its worth, its far from an indiscriminate process and that information is vastly more likely to be of use to people looking for information about that gene than it is to cause some sort of medical harm - which as I understand it is the main motivation behind the MEDRS approach. But i'm not going to continue that particular argument here. I concur with your sentiment about developing "methods of marking the Wikidata with a field indicating quality of evidence" and I don't see why its so far off. In fact we already have code in place that prevents unreferenced statements from appearing in the infobox. The claim in question here has references saying the claim is stated in Phenocarta and in a journal article, both of which have items in Wikidata. All we would need to do would be to add a property to those items indicating that they were 'MEDRA approved references' or something like that and then we could build a filter into the template that would automatically hide any claims that did not meet the criteria. Another approach that could be implemented right now without creating any new properties or tagging anything would be to use the determination method qualifier property on the claim. In this case, the claim is made based on evidence from a genome wide association study or 'GWAS'. If we can decide on what forms of evidence are suitable for inclusion of a given kind of claim - e.g. 'genetic association', we could use that as a filter immediately. --Benjamin Good (talk) 17:03, 2 May 2017 (UTC)[reply]

The Gemma database ratings are precisely what I was describing as indiscriminate - which for our purposes, they are if a 3 star rating means "1 mouse study, 2 comparative studies, 3 research studies and 1 meta-analysis with conflicting conclusions". Without taking the time to evaluate each entry in the Gemma database against MEDRS, how do you propose we eliminate the possibility that a Wikidata claim may be insufficient to support a biomedical claim by our standards? If people find the information in Phenocarta (Q22330995) interesting, then they can read it there. We have no need to include information indirectly via Wikidata that falls short of what we require from any source used directly in an article. I've invested a lot of time and effort over the last few years in creating and refining tools to facilitate the import of information from Wikidata, and the last thing I want to see is it being thrown away because of knee-jerk reactions by the community to accusations that "Wikidata is not a reliable source" and "Using Wikidata breaches our Verifiability policy". To get an idea of what we're going to be up against, take a look at Wikipedia:Wikidata/2017 State of affairs #Perceived disadvantages of using Wikidata on enwiki – or at the edit war to force inclusion of the phrase "The lack of reliable sourcing means that imported Wikidata text violates WP:V and WP:BLP". Are you sure it's a good idea to add "violates MEDRS" as ammunition for the nay-sayers? --RexxS (talk) 18:02, 2 May 2017 (UTC)[reply]

User:RexxS why is it better, in your opinion, to put out a blanket deletion of content than to formalize and clarify the reasons for not showing it? How else do you imagine bridging the gap between structured content and Wikipedians? Wikidata has, and will continue to have, a variety of different sources for the information it contains. We need to develop mechanisms for taking advantage of its infrastructure to provide the community of data consumers (Wikipedia here) with ways to use it as they see fit. I would much rather have the MEDRS people make a definitive statement like "we don't think GWAS studies provide enough evidence to justify showing the resultant content in Wikipedia" and encode that logic in a combination of wikidata statements and template code then I would like to see people simply deleting infoboxes or data in wikidata. Do you have an alternative plan for the future here? --Benjamin Good (talk) 19:20, 2 May 2017 (UTC)[reply]

It is better, in my opinion, not to display a field in an infobox than to display information that falls short of what is required by our guidelines on sourcing. I have difficulty understanding your reasons for taking the opposite view; perhaps you could explain them to me? If you would kindly elucidate what you mean by "the gap between structured content and Wikipedians", I might better be able to see why you are taking your position.

WP:MEDRS is not a person, but a Wikipedia guideline that enjoys project-wide community support. We are all "MEDRS people" just as we are all "NPOV people", etc. so there's no reason why you can't make the definitive statement yourself: it would carry the same weight (i.e. one person's opinion).

If you want to "encode that logic in a combination of wikidata statements and template code", then I'm all in favour: please go ahead and do it. Let me know as soon as you've finished, and you'll have my support for importing the filtered data into {{Infobox gene}}. In the meantime, how do you suggest we suppress individual fields in this infobox, as the topic of this thread asks? If we can't ensure that the infobox doesn't include dud information from Wikidata, nor remove the offending claim from Wikidata, what solution are you offering now? --RexxS (talk) 20:25, 2 May 2017 (UTC)[reply]

As someone working here in en-Wikipedia, User:I9606 you are obligated to follow en-WP policies and guidelines and as RexxS noted MEDRS has broad and deep consensus in en-WP. We all know that there is no similar thing in Wikidata and as I noted way above, I have zero desire to try to change Wikidata or enforce en-WP policies and guidelines there. But the differing policy/guideline environments, is why care must be taken moving data between the two projects. Jytdog (talk) 20:31, 2 May 2017 (UTC)[reply]

so at this point i am asking that the "diseases" field and the field that produces "interacts with" be removed from this template. Both get into health content that we cannot rely on to be MEDRS-sourced in Wikidata. The purely biochem data, I don't mind. But these two should go. Would you please remove from them from the output? (here is the corresponding thread at WT:MED that I had opened. There have been a bunch of discussions at WT:MED about these kinds of fields in Wikidata. See for example this one which was probably the most clear about the concerns). Thanks. Jytdog (talk) 17:50, 2 May 2017 (UTC)[reply]

I removed the offending information from the infobox. The change should percolate. More later on a strategy for moving forward and why I think this was not such a great move. --Benjamin Good (talk) 21:07, 2 May 2017 (UTC)[reply]

Thank you!!! That was a great move. Jytdog (talk) 22:23, 2 May 2017 (UTC)[reply]

That change just made more than 11,000 articles less informative, losing the community value produced by a lot of people's hard work here, in wikidata, and elsewhere. I personally don't think that was a positive change. I did it as a temporary patch while a pattern that is more satisfactory to the majority of WP editors can be constructed. Benjamin Good (talk) 03:36, 3 May 2017 (UTC)[reply]