Subject: Re: Summary of discussion from ARO session on "Research and Teaching tools for Matlab" From: gvoysey <gvoysey@xxxxxxxx> Date: Thu, 17 Mar 2016 10:56:49 -0400 List-Archive:<http://lists.mcgill.ca/scripts/wa.exe?LIST=AUDITORY>--001a1142771c12f0e2052e3fd75c Content-Type: text/plain; charset=UTF-8 All, We feel the most effective way to promote better sharing of software is to > make a strong link between software and the articles/research it is used > for. We expect that someone browsing through a software database or > website is much more likely to recognize the utility of a piece of > software if he or she can see which articles were based on it. It would > probably be even more efficient if journal articles included a link to a > database in which the software used to conduct the research is freely > available for downloading. However, the latter requires authors to be > comfortable sharing their software at the time of publication. This might > be difficult to achieve in very competitive fields of research. I have been thinking a lot about these issues for several years now -- figuring out how to cite my own code, and figuring out how to attribute a fair share of credit to all other code authors, have been problems I have been directly faced with many times now and I am excited to see that I'm not alone in this. In the recent past, I have become aware of several tools that have the potential to make this job easier: First, if you host your code on GitHub, it is straightforward to assign your repository a DOI and thus make it more easily citeable: you can read about how to do this here <https://guides.github.com/activities/citable-code/>. This makes linking a published article and the code that was used in it very easy; "back-linking" is still a challenge (ie, visitors to your github page do not automatically know which papers used your code). Second, a proposal that I found interesting for attributing credit to software was recently published. It's theoretically interesting as a way of proportional credit assignment, and it may solve some of the back-linking problem if it ever takes off: Katz, D.S. & Smith, A.M., (2015).* Transitive Credit and JSON-LD*. Journal of Open Research Software. 3(1), p.e7. DOI: http://doi.org/10.5334/jors.by Both of these ideas really rely on an open-source approach to research computing. I consider my code and its development history a necessary "trust-but-verify" component of my work, so it seems natural to have it publicly available at time of publication. While that opinion is not universal, tools like the Jupyter Notebook <http://jupyter.org/>, which is "a web application that allows you to create and share documents that contain live code, equations, visualizations and explanatory text.", provide researchers with a fast and easy way to share results quickly and provide a fast verification step. In this way, researchers can keep pace with the rapid progress of a competitive research field, without fully releasing their code until it's ready, while still giving their peers a deeper look into their results than can normally happen with, for example, static figures in a publication. -- Graham Voysey Boston University College of Engineering HRC Research Engineer Auditory Biophysics and Simulation Laboratory Binaural Hearing Laboratory ERB 413 --001a1142771c12f0e2052e3fd75c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra">All, <br></div><div class=3D"gm= ail_extra"><div class=3D"gmail_quote"><br><blockquote class=3D"gmail_quote"= style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p= adding-left:1ex">We feel the most effective way to promote better sharing o= f software is to make a strong link between software and the articles/resea= rch it is used for.=C2=A0 We expect that someone browsing through a softwar= e database or website is much more likely to recognize the utility of a piec= e of software=C2=A0 if he or she can see which articles were based on it.= =C2=A0 It would probably be even more efficient if journal articles include= d a link to a database in which the software used to conduct the research is freely available for downloading. However,= the latter requires authors to be comfortable sharing their software at th= e time of publication.=C2=A0 This might be difficult to achieve in very com= petitive fields of research. </blockquote></div><br></div><div class=3D"gmail_extra">I have been thinkin= g a lot about these issues for several years now -- figuring out how to cit= e my own code, and figuring out how to attribute a fair share of credit to = all other code authors, have been problems I have been directly faced with = many times now and I am excited to see that I'm not alone in this. <br>= <br></div><div class=3D"gmail_extra">In the recent past, I have become awar= e of several tools that have the potential to make this job easier:<br><br>= First, if you host your code on GitHub, it is straightforward to assign you= r repository a DOI and thus make it more easily citeable: you can read abou= t how to do this <a href=3D"https://guides.github.com/activities/citable-co= de/">here</a>.=C2=A0 This makes linking a published article and the code th= at was used in it very easy; "back-linking" is still a challenge = (ie, visitors to your github page do not automatically know which papers us= ed your code).<br><br>Second, a proposal that I found interesting for attri= buting credit to software was recently published.=C2=A0 It's theoretica= lly interesting as a way of proportional credit assignment, and it may solv= e some of the back-linking problem if it ever takes off:<span class=3D""><s= trong> </strong></span> <span class=3D""> =20 Katz, D.S. & Smith, A.M., (2015).<b> Transitive Credit and=20 JSON-LD</b>. Journal of Open Research Software. 3(1), p.e7. DOI: <a href=3D= "http://doi.org/10.5334/jors.by"> http://doi.org/10.5334/jors.by<br></a></span></div><div class=3D"gmail_extr= a"><br></div><div class=3D"gmail_extra">Both of these ideas really rely on = an open-source approach to research computing.=C2=A0 I consider my code and= its development history a necessary "trust-but-verify" component= of my work, so it seems natural to have it publicly available at time of p= ublication.=C2=A0 While that opinion is not universal, tools like the <a hr= ef=3D"http://jupyter.org/">Jupyter Notebook</a>, which is "a web appli= cation that allows you to create and share documents that=20 contain live code, equations, visualizations and explanatory text.", p= rovide researchers with a fast and easy way to share results quickly and pr= ovide a fast verification step.=C2=A0 In this way, researchers can keep pac= e with the rapid progress of a competitive research field, without fully re= leasing their code until it's ready, while still giving their peers a d= eeper look into their results than can normally happen with, for example, s= tatic figures in a publication. <br></div><div class=3D"gmail_extra"><br>--= <br><div class=3D"gmail_signature"><div dir=3D"ltr">Graham Voysey<br>Bosto= n University College of Engineering<br>HRC Research Engineer<br>Auditory Bi= ophysics and Simulation Laboratory<br>Binaural Hearing Laboratory<br>ERB 41= 3</div></div> </div></div> --001a1142771c12f0e2052e3fd75c--