Author Archives: Meik Poschen

About Meik Poschen

Twitter: @MeikPoschen

Ways of approaching an RDM Service

A few weeks back an interesting discussion took place on the JISCMRD mailinglist, picked up on this blog under the main question of ‘ What are the requirements an RDMI has to cover?’.

One of the conclusions was that requirements gathering, scope and application obviously depend on a number of factors, one major one being the remit of the project: implementing a system for (pilot) audiences is different from getting an institution-wide service into place and running. The MaDAM project between 2009 and 2011 implemented a pilot RDMI for users from the biomedical domain – and was followed up by  MiSS (MaDAM into Sustainable Service) in autumn last year. Whilst having all the crucial experience, findings, contacts and committed stakeholders through MaDAM to build upon, it was clear that a set of new challenges would arise in implementing a RDMI as a service for the whole (and benefit) of the University.

1) Especially having the main stakeholders on board for such an endeavour is of utmost importance – but soon we realised that this process basically never stops: aims, benefits and plans have to be mulled over, renegotiated and agreed upon. There is always one office and internal project more to be included.

2) The University of Manchester also released their RDM Policy in May this year – and also other internal endeavours change structures (research offices), infrastructure (storage, eDMP) and processes. As a research project implementing a service we have to closely liaise with all those stakeholders to be on the same page and coordinate our efforts (and integrate with existing systems and the IT landscape) – despite a small core project team.

3) Outreach, awareness raising and training become more and more important. To this end (also including the points made before) we had to draw up a communication plan, collaborate and plan for an interim service and training for staff. We always strived to hold as many presentations as possible for various audiences at the University about our projects – now we have to start organising dedicated events e.g. at the moment on DMPs. Also: tangible benefits have to be communicated to all audiences!

4) One major challenge for the devleopment of the service and how it will look like lies in balancing the generic with the specific needs. Trying to gather and negotiate as many views, feedback and concerns is a huge task and some evolvement over time is needed – especially as only a system (service!) in use shows all the specifics required for every user, group and discipline. The service coming into life in about a year’s time will be a ‘thin layer’ across the whole RDM lifecycle, but the development is a continuous one and the RDM Service will get more tailored, sophisticated and mature while running.

Meik Poschen  <meik.poschen@manchester.ac.uk>
Twitter:  @MeikPoschen

What are the requirements an RDMI has to cover?

The idea for this post came through a discussion Tom Parsons (ADMIRe project, University of Nottingham) started on the JISCMRD mailinglist about the ‘Requirements for an RDM system’. As we all know there are a lot of challenges involved in figuring out what requirements have to be covered by a Research Data Management Infrastructure. What is it an RDMI has to deliver in the end, what functional specifications have to be defined and on what scale?

Requirements have to be gathered on different levels from various researchers, research groups and other stakeholders. Approaches, case studies and outcomes are depending not only on projects’ remits (e.g. pilot projects vs. 2nd phase projects implementing an institutional wide service), but also on resources, buy-in from stakeholders and varying needs of the target audiences. The wider the field to play on, the harder it gets to balance out disciplinary specific and generic needs and to decide what parts of the research lifecycle can/have to be covered.

At the same time the institutional landscape has to be taken into account as well, especially the IT landscape and systems already existing – Tom pointed to the danger of “straying into the territory of a research administration system when we are thinking about an overall RDM system”. Trying to inter-connect with existing systems across the institution is something e.g. the MiSS project is doing at the moment, integrating existing infrastructure while adhering to the existing IT framework at the University of Manchester; this means the project initiation and accounting systems will be connected to the MiSS RDM core system (as will eScholar as the dissemination platform) and e.g. DMPs are automatically transferred into the active data stage. The temporary downside of this approach – creating an RDMI across the whole lifecylce, but with a thin layer for a service to start with – is that certain specific needs can only be addressed over time. Then again, such a new infrastructure needs to be able to evolve in use anyway.

To round up this post, here are some thoughts mentioned in the discussion:

Chris Morris pointed to a “concept of operations for research data management for a specific domain, molecular biology: http://pims.structuralbiology.eu/docs/beforePiMS.html” and also “got one general suggestion, which is not to start with use cases about deposition, but with retrieval. There is no scholarly value in a write-only archive.”

Some examples for use cases provided by Joss Winn: “https://github.com/lncd/Orbital-Core/wiki/Case-Studies. He remarks that those are very high level looking at them now and provides another link with “more detail from our project tracker, although it may not be as easy to follow: https://www.pivotaltracker.com/projects/366731. Basically, other than the usual deposit, describe, retrieve functionality, our two pilot research groups are looking to use the RDM platform for data analysis, such that is is a working tool from the start of the research project, rather than a system for depositing data at the end of the project.”

Steve Welburn addresses another important question, namely what technical framework to choose and how they came to choose DSpace: http://rdm.c4dm.eecs.qmul.ac.uk/platform_choice

Thanks to everyone mentioned for their links and thoughts!

Meik Poschen  <meik.poschen@manchester.ac.uk>
Twitter:  @MeikPoschen

Revisited: Meeting (Disciplinary) Challenges in Research Data Management Planning

The JISCMRD Workshop on ‘Meeting (Disciplinary) Challenges in Research Data Management Planning’ (March 23, 2012, London) saw the projects in this strand present their interim outputs; the development of DMPonline (now in v3.0), disciplinary templates and further institutional approaches rounded up the event.

The discussion circled around a number of issues and questions, some covered, some yet to be fully answered as Steve Hitchcock points out in his excellent blog piece (e.g. What is a DMPs scope, defined by whom? Where to best host a DMP? To what extent and how to (pre-)populate DMP records?).

Overall it is fair to say that a lot of good progress has been made on the DMP front – but challenges remain, especially as the implementation of funder requirements, data management policies and therefore DMPs has gained speed on institutional level:

  • For researchers/research groups “changing RDM culture is (going to be) hard work” as pointed out by Simon Dixon (SMDMRD project), representative of the overall discussion. Sticks AND carrots are needed (in a positive way: show benefits!).
  • Along with disciplinary working practices and cultures the requirements from DMPs in use are further evolving – not bound by project schedules and implementation time lines.
  • Furthermore, time is always a constraint for filling out DMPs, we have to try to mitigate the duplication of effort for data already stored electronically.
  • Good practice is not at all easy to implement and in connection to that training and documentation has to be a part of it all.
  • In the end, DMP tools not only need to mature in general, but the DMP as such has to be a dynamic thing (vs. a static snapshot only) in a running project before it will be put to rest in an archive at the end of the research lifecycle.

Meik Poschen  <meik.poschen@manchester.ac.uk>
Twitter:  @MeikPoschen

Commonalities & Differences: Requirements & Disciplines

Within our remit to identify themes and trends in the JISMRD Programme and to enable collaboration and synergies between its projects, exploring commonalities and differences is a key area with a multitude of angles. Diverse endeavours, domains, institutions and scopes on the project side entail a number of approaches, methods, user communities, research practices & cultures, data life cycles, workflows and therefore actual needs, requirements, benefits, data infrastrutures and policies. Knowledge transfer in the programme is crucial to not to re-invent the wheel (at least not every time), learn from previous experiences, discuss emerging topics, collaborate and hence (mutually) benefit from all those differences and commonalities.

In the weeks and months to come I shall focus on commonalities and differences on this blog under different aspects, starting with the requirements and disciplinary angle (albeit I am aware that a lot of areas are overlapping: requirements gathering involves methods as well as research practice and perceived benefits, which again have an impact on costs, et cetera et cetera). The thought would be to ideally start a discourse, get feedback and input from projects and people, gather documentation and discussion topics, facilitate and provide support. A workshop at some later stage might be an activity spawning from that, if deemed useful.

My own project related hat is that of the user liaison & researcher, e.g. gathering requirements, including looking into research practice and benefits of diverse communitites at the University of Manchester previously in the MaDAM project (JISCMRD phase 1; see here for outputs) and now in MiSS (JISCMRD02; see resources section). Our requirements approach in both projects is user-driven, iterative and based on close collaboration between RDM specialists, users/researchers, other stakeholders (high-level buy-in is especially important) and the project team/developers. In MaDAM we were focussing on pilot users from the Biomedical domain – in MiSS the RDMI will have to cater for the whole of the University with the challenge of establishing a balance between a generic, easy-to-use eInfrastructure and providing a system open enough for discipline specific needs (plug-in points). We have user champions in each faculty: Life Sciences (Core Facilities and MIB – large and diverse data), Engineering and Physical Science (Henry Mosley Centre, Material Sciences & MIB – large data), Medical and Human Sciences (sensitive data!) and Humanities (CCSR, applied quantitative social research – data service and diversity) and will also open up a user committee to the wider University for input and feedback in a few weeks. We just have completed our baseline requirements phase, so please watch out on this channel for more details and the report!

But back to you, the JISCMRD projects’ fields of interests and needs:

How do you approach your requirements process?

What are particular challenges, e.g. in specific disciplines?

What are particularly enthralling lessons learned (already)?

How to achive benefits and synergies between projects?

What would be your ideas on how to facilitate (by us) any exchange on such issues, any ideas are welcome!

Meik Poschen  <meik.poschen@manchester.ac.uk>
Twitter:  @MeikPoschen

Please allow me to introduce myself..

..not sure wealth and taste will have something to do with our Evidence Gatherer roles in JISCMRD02, but I definitely have been around for a while – as have Laura and Jonathan – playing with tools and notions of Research Data Management (RDM). BTW, thanks for the great intros Laura!

With the begin of the JISCMRD Programme in 2009 I started working on the MaDAM project as a ‘user liaison’, trying to understand users’ requirements in their research domains along their data lifecycle, working closely with users and the whole project team on developing a pilot RDM infrastructure covering a technical system, support for Data Management Plans and Policies and embedding all this for our pilot user groups at the University of Manchester, taking into account the institutional landscape and all players – and raising awareness. MaDAM ended mid-2011, but based on the increasing need for a University-wide RDM Service Infrastructure and the pilot’s findings and experiences (MaDAM outputs) we are able to continue our journey with the second phase project MiSS – MaDAM into Sustainable Service. I myself am also a researcher (working at the Manchester eResearch Centre, MeRC at University of Manchester) interested generally in socio-technical systems, RDM, disciplinary differences, processes of adoption and evolving use. My approach with users is a more qualitative one grounded in studies of working practice, iterative system development and user-driven design.

Our Evidence Gatherer role will be very exciting as it involves taking into account the various views and needs of the JISCMRD projects, which means collaborating, learning, identifying themes and trends together and providing lessons learned from our previous endeavours. At the JISCMRD launch event (see Laura’s post below) and also at the IDCC11 in Bristol we talked to many colleagues from the other projects (and the community in general) and already noted topics close to their heart: Sarah Jones commented on Laura’s ‘The Three Monkeys’ post pointing out an important question raised for us in one of the launch event’s breakout sessions “about whether commonalities lie within disciplines or if we should be comparing workflows and processes across disciplines as researchers from different areas may have similar needs”. Similar points from other participants alluded to the need to identify disciplinary differences and commonalities across institutions and in terms of methodological approaches. We are looking forward to helping to ‘link up’, ‘build on previous work’ and ‘create mutual benefits’ through our work as Evidence Gatherers.

Meik Poschen  <meik.poschen@manchester.ac.uk>
Twitter:  @MeikPoschen