1 / 9

Policy & Organisation

Policy & Organisation. eHumanities address Software and Tools Sustainability KNAW Trippenhuis , Amsterdam, 10 April 2013. Questions. What services are to be sustained? Who (which organizations(s), groups) are or should be responsible for what aspects of the matter?

devlin
Download Presentation

Policy & Organisation

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. Policy & Organisation eHumanities address Software and Tools Sustainability KNAW Trippenhuis, Amsterdam, 10 April 2013

  2. Questions • What services are to be sustained? • Who (which organizations(s), groups) are or should be responsible for what aspects of the matter? • What consequences can be drawn from that for the future (model of) funding of maintenance, accessibility, etc.? • Is a separate (sub-)organization required; should software/tools be collected actively or passively? • (how to go about the funding for sustainability of software that resulted from past projects –for which nothing was organized yet-)? • Are there in policy/organizational solutions ehumanities’ specifics?

  3. Jan Odijk: What services are to be sustained? • speaks from experience in CLARIN/CLARIAH. • different classes of tools and services, reflecting the research lifecycle: • software to support data creation • processes to enrich data • store data and generate metadata • annotation tools • analysis tools • visualisation tools • make the different classes of tools interoperable • it only appears afterwards whether a tool is successful or not • Main goal: re-use of the tools

  4. Neil: making tools more generic is not a viable strategy, unless the leap is small • Jan: nevertheless we see that some linguistic tools are being used in historical research • Jacob: is it feasible to rationalise tools for eHumanities? • Jan: yes (example – Stevin project, followed by CLARIN) • Neil: is it possible to identify the best tools that are used by the community? • Jan: yes – for some tasks (quality/flexible/supporting team/modifiable) • Demetrius: how can you make the user community bigger? • Patrick: who are your clients? individual researchers or bigger (b2b) projects? • Jaap: if you want to be really innovative, the tool is usually not mainstream and very much dedicated • Jan: we need first of all an overview (registry) of the tools that are around. • Jaap: and this is of course dynamic. And we need criteria to decide whether to maintain the tool or not

  5. Marc Dupuis: Who (which organizations(s), groups) are or should be responsible for what aspects of the matter? • Many things are moving in the area of (open access to) publications and data, and different groups are claiming a role • Does not the same apply to software? • Is it the funding organisations that should take care of this, or is it the research organizations themselves? • Jan: distinguish different tasks • Making it visible/accessible: stable centre • Bugs, improvements: a dedicated community • Neil: you need to invert the question. The research community should be in the center; how to organise the decision? From that comes the next step about funding. • Patrick/Jan: discuss about requirements about software documentation • Marco: maintaining the outcome of the Catch+ programme is an issue (report). You cannot evade the question about who.

  6. Patricia: most tools of Catch+ are maintained by the (heritage) organizations where they were developed for their own use. • Peter: is enforcing maintenance feasible? • Neil: it is, but… If software is successful, it takes about 7 years before it is generally taken up. Key time for follow-up is 2-4 years after ending the project.

  7. Peter Doorn: Do we need a Dutch Institute for Software Sustainability? • An existing organisationor a joint effort? • community driven (CLARIN, Catch)? • across communities and disciplines? • Big Science is more self-supporting than the humanities! • Candidates? • How to pay? • Which functions? • expertise • software preservation / maintenance / exploitation / running the service? • setting criteria for sustainability: a “Seal of Approval for Sustainable Software”? Software Sustainability Plan? • active or passive acquisition of tools?

  8. Neil: some striking parallels with thoughts in the UK (eg. 5 stars of software quality; software management plan) • Jan: CLARIN has CLARIN centers • Peter: but many of them have trouble with maintaining externally developed software for free • Patrick: a coalition between NLeSC and DANS, possibly extended with others (CLARI-N/-AH, DEN, Catch, 3TU.DC?) seems very well possible • Jaap: CLARIN and Catch are front runners, followed by other humanities • Proceeding with quality guidelines and management plans: international collaboration would strengthen it. • Neil: you could also use quality criteria to decide which software to support and which not (6 criteria: research impact, timeliness, enthusiasm) • Jan: It helps to have a core set of very successful, widely used tools that everyone wants to be compatible with

  9. Who pays • Jan: CLARIN centers get some financial stimulus for preparing to curate data and tools according to CLARIN standards

More Related