1 / 16

Unless otherwise indicated slides licensed under

Software Information and Scientific Publications doi : 10.6084/m9.figshare. 678226 Beyond EMI: A Roadmap to Open Collaboration 9 April 2013, EGI Community Forum, Manchester Neil Chue Hong (@ npch ) ORCID: 0000-0002-8876- 7606 N.ChueHong @software.ac.uk.

calix
Download Presentation

Unless otherwise indicated slides licensed under

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Information and Scientific Publicationsdoi: 10.6084/m9.figshare.678226Beyond EMI: A Roadmap to Open Collaboration9 April2013, EGI Community Forum, ManchesterNeil Chue Hong (@npch)ORCID: 0000-0002-8876-7606N.ChueHong@software.ac.uk Unless otherwise indicatedslides licensed under

  2. Software is no longer easy to define, let alone sustain

  3. Boundary • What do we choose to identify: • Workflow? • Software that runs workflow? • Software referenced by workflow? • Software dependencies? • What’s the minimum citable part?

  4. Granularity Function Algorithm Program Library / Suite / Package …

  5. Versioning • Why do we version? • To indicate a change • To allow sharing • To confer special status Public v1 Public v2 Public v3 Personal v3 Personal v3a Personal v1 Personal v2 Personal v2a Personal v2a

  6. Authorship Authorship • Which authors have had what impact on each version of the software? • Who had the largest contribution to the scientific results in a paper? • http://beyond-impact.org/?p=175 OGSA-DAI projects statistics from Ohloh

  7. 5 Stars of Research Software • Community • There is a community infrastructure • Open • Software has permissive license • Defined • Accurate metadata for the software • Extensible • Usable, modifiable for my purpose • Runnable • I can access and run software C R O E D • c.f. • 5 Stars of Linked Data (Berners-Lee) • 5 Stars of Online Journals (Shotton) “Golden Star” Originally by Ssolbergj CC-BY

  8. Publishing metadata about software makes it easier to reuse and maintain

  9. Discoverable Software • To grow a community around software, first it must be discoverable • For users, wanting to find a solution • For developers, wanting to reuse or extend • For funders, wanting to promote or feature • For sustainability • Provide useful information • Make it easier to attract and add contributors • Enable dormant projects to re-activate?

  10. Software Hub Prototyping How do people search for software? What information is useful? Do both provider and user benefit? What can be imported from other sites? What metadata must be collected to produce this information? Is it possible or easy to collect?

  11. Types of Metadata • Name • Provenance and Ownership • Functionality and Constraints • Content and Composition • Environment and Dependencies • Location • See also: • Significant Properties of Software (Matthews et al) • Software Ontology (Malone et al)

  12. Journal of Open Research Software http://openresearchsoftware.metajnl.com

  13. Ten tips for citing scientific software • Describe any software that played a critical part in your research, so that a peer can understand, repeat, validate and reuse your research. • There are many options for describing the software you have used: footnotes, acknowledgements, methods sections, and appendices. • Be aware that a license may place you under an obligation to attribute the use of software in your publication. • Cite papers that describe software as a complement to, not a replacement for, citing the software itself. • In the first draft of a paper, always put software citations in references or bibliographies. • Be prepared to debate with reviewers why you have cited the software: you want to acknowledge the contribution of the software's authors and the value of software as a legitimate research output. • Inform reviewers if you are legally obliged to cite the software because of a clause in the software's license. • If a reviewer disagrees with a formal software citation, you can still make a general reference to the software in the paper. • Recommended citations may not have enough information to accurately describe the software that was used - you may need to add more detail yourself. • If the software has a DOI (digital object identifier) use it to cite the software. If the software has its own website, use the website's URL for the citation. http://www.software.ac.uk/how-cite-and-describe-software

  14. Alternative Impact Stories Forking analogous to citing GitHub Repository Direct measure ofsoftware citation? Requires user IDs, repository IDs, APIs Starring as a means of recommendation

  15. We must describe and cite software otherwise we cannot benefit from and reward reuse and refinement

  16. SSI at EGI CF13 • Community Engagement (Lead: Shoaib Sufi) • Wed 10th, 16:00 Engaging the software in research community • Thu 11th, 14:00 Champions workshop: SSI Fellows • Consultancy (Lead: Steve Crouch) • All Week Ask Steve / Mike at the SSI booth • Policy and Publicity (Lead: Simon Hettrick) • Wed 10th, 16:20 Building sustainable software for science: why good code is only the beginning • Training (Lead: Mike Jackson) • Thu 11th, all-day Software Carpentry Taster Sessions • doi: 10.6084/m9.figshare.678226 • Collaboration between universities of Edinburgh, Manchester, Oxford and Southampton. Supported by EPSRC Grant EP/H043160/1.

More Related